Zbyt często nie czytamy takich gorących nowinek, jednak warto wiedzieć, że o większości takich porażek nigdy się nie dowiemy z powodu zapisów o poufności w umowach miedzy dostawcami oprogramowania a ich klientami. Tym bardziej taka informacja jak ta, jest warta uwagi z uwagi na sam fakt, że się pojawiła w prasie: najwyraźniej komuś puściły nerwy :):
Po siedmiu latach przygotowań, które pochłonęły 500 mln euro, największa w Europie sieć marketów spożywczych Lidl przerwała prace zmierzające do zaimplementowania systemu SAP do zarządzania towarem w sklepach. ?Strategicznych celów zdefiniowanych na początku nie dało się osiągnąć przy akceptowalnych kosztach? ? napisał w liście do pracowników szef koncernu Jesper Hoyer. 1
Wiele gazet i portali opublikowało niemalże tę samą informację prasową, część redaktorów dodała komentarze od siebie. Tu kilka moich komentarzy.
W 2010 roku pisałem
celem dostawcy gotowego systemu ERP jest wdrożyć go bez żadnych modyfikacji bo (jej koszty) zjadają marżę dostawcy. Celem kupującego oprogramowanie ERP, jest wsparcie swoich procesów biznesowych a nie kopia cudzych. To dwa sprzeczne interesy. Silna firma wymusi na dostawcy ERP zmiany, słaba nie raz poddaje się wierząc tezom dostawcy, że nowy system uporządkuje stan ich organizacji i da przewagę nad konkurencją. Kto tu ma rację? 2
a artykuł kończyłem słowami:
To jest to co różni mnie od wielu dostawców ERP, ale też nie ja jeden tak uważam (polecam M.E.Porter ? Strategia konkurencji, napisał tam, że firmy kopiując technologie od kogoś tym samym podejmują decyzje że zrezygnowały już z konkurowania na rynku). Źródłem przewagi rynkowej jest tylko to co odróżnia firmę od jej konkurentów. Studiuje także literaturę z zakresu zarządzania i marketingu: nigdzie na świecie nie potwierdza się teza, że skopiowanie metod konkurenta daje cokolwiek poza ustawieniem się za nim.
Na stronie Hacker News, kilka dni temu, wywiązała się dyskusja na temat tej porażki (polecam całą dyskusję)3, pokazuje ona jak różne (i nie raz sprzeczne) są cele dostawców i odbiorców oprogramowania, ale tu także padło stwierdzenie:
Don’t customize software to your process unless the process is your competitive advantage. 3
(nie dostosowuj oprogramowania do swojego procesu, chyba że proces ten jest Twoją przewagą konkurencyjną).
Popatrzmy jak na tym tle wygląda przypadek LIDL’a. (cytaty pochodzą z COMPUTERWORLD1).
Łącznie w prace zaangażowanych było przeszło 1000 specjalistów: pracowników Lidla, SAP, jego partnerów oraz zewnętrznych konsultantów. SAP miał zostać wdrożony we wszystkich oddziałach Lidla, także w Polsce.
Zawsze zastanawiała mnie w tego typu projektach taka armia osób zaangażowanych ludzi. Bardzo często widuję mega-zespoły pracujące z użyciem współdzielonych folderów na dysku, maila jak głównego narzędzia komunikacji w projekcie, armii studentów zatrudnionych jako młodszych konsultantów. Ich praca niemalże w całości opiera się na prowadzeniu wywiadów z pracownikami zamawiającego, spisywaniu ich treści, porządkowaniu i przekazywaniu jako wymagań swoim programistom. To droga do klęski. To moje obserwacje z audytowanych wdrożeń a nie opis tego projektu dla LIDLA (nie podano składu zespołu).
Dostawcy systemów ERP (SAP nie jest tu wyjątkiem) wysyłają w trakcie analizy i wdrożenia rzesze konsultantów, każdy wyspecjalizowany w swoim module (dziedzinie) i każdy pracujący niezależnie od pozostałych. Kastomizacje także są wprowadzane przez nich od siebie niezależnie, w efekcie nie raz bywają sprzeczne a błędy sypią się jak domino.
Czytam, że:
W kwietniu 2017 roku SAP uhonorował Lidla nagrodą dla jednego z najlepszych klientów
Jak znam producentów systemów ERP, nagroda była wynikiem wartości kontraktu a nie merytorycznych osiągnięć w toku wdrożenia… Co widać i tu. Warto o tym wiedzieć, czytając w prasie o takich nagrodach.
Dziwi mnie, że nie wykonano analizy i projektu (gdyby powstał, wiadomo było by jakich funkcjonalności nie da się wdrożyć akceptowalnym kosztem), pilotowego wdrożenia w jednym, mało ryzykownym dla firmy oddziale, opracowaniu wniosków i procedury roll-up (parametryzowane powielanie). Wdrożony jednak osobno w kilku lokalizacjach i mimo kłopotów, nadal brnięto w projekt i koszty.
Według analityków zasadniczych przyczyn porażki należy szukać w nastawieniu Lidla, którego zarząd miał nie godzić się na jakiekolwiek zmiany w organizacji procesów firmy, tak aby dostosować je do architektury systemu SAP.
I tu widzę klucz do wyjaśnienia: z jednej strony zamawiający często bronią jak niepodległości tezy, że nie zmienią swoich dotychczasowych zwyczajów, z drugiej strony dostawcy forsują swoje rozwiązanie, ale też Ci dostawcy (znając potencjalne skutki!) godzą się na kastomizacje, pod warunkiem rozliczeń godzinowych za ich wprowadzanie, przerzucając tym samym wszelkie koszty i ryzyka z tego tytuły na zamawiającego.
Praktyka potwierdza, że:
Źródłem przewagi rynkowej jest tylko to co odróżnia firmę od jej konkurentów (M.E.Porter, Strategia konkurencji).
Dlatego przygotowanie firmy do wdrożenia jakiegokolwiek oprogramowania wspomagającego zarządzanie, to pewne minimalne kroki do wykonania:
- Przeprowadzić analizę całej firmy i opracować model jej działania.
- Wskazać obszary stanowiące o przewadze rynkowej, w pozostałych wprowadzić (zaplanować, opracować) standaryzację.
- Opracować dokładne wymagania na oprogramowanie wspierające obszar budujący przewagę rynkową.
- Zapomnieć, że jakikolwiek jeden wielki zintegrowany system sobie z tym poradzi.
O LIDL’u czytamy, że w końcu:
Zarząd koncernu zapowiedział, że nie tylko firma zostanie przy starym systemie Wawi, ale będzie on nadal rozwijany przez wewnętrzny dział IT, który zatrudnia ok 1200 osób, połowę poza Niemcami.
Jeżeli po całym tym okresie, wydaniu 500 mln EUR, firma dokonała porównania kosztów utrzymania własnego systemu z systemem GOTOWYM, oferowanym przez SAP, i doszła do wniosku że dedykowany jest bardziej rentowny to było to drogie badanie.
Od siebie na zakończenie mogę powiedzieć: nie znam przypadku by jakikolwiek gotowy system był tańszy we wdrożeniu i utrzymaniu, gdy wdrożenie dotyczy obszaru stanowiącego o przewadze rynkowej firmy, taki obszar to z zasady niestandardowe procesy i reguły. Co zrobić? Po zrozumieniu jak firma działa i wyróżnieniu w niej dziedzinowych obszarów specjalizacji (jest ich najwyżej kilka), wdrożyć w każdym z nich standardowe dziedzinowe oprogramowanie dostępne na rynku a obszar niestandardowy obsłużyć zamówionym, dedykowanym dla siebie, oprogramowaniem.
Ten wpis to nie jest analiza tego przypadku, za mało danych mamy i pewnie oficjalnie nigdy nie poznamy szczegółów. Ten wpis to raczej „memento”, dla kupujących systemy ERP, którzy:
- wierzą, że dostawca jest bezstronny w toku prowadzenia analizy wymagań na wdrożenie tego co sam oferuje, że posiada właściwe kadry do wdrożenia,
- wierzą, że jako kupujący zaawansowane usługi, sami sobie poradzą z nadzorem ich dostawcy (jak widać nawet własna armia 1200 specjalistów IT nie pomogła LIDL’owi).
W 2010 roku w artykule Kto jest winny porażki wdrożenia ERP, o przyczynach porażek wdrożeń ERP pisałem:
Po pierwsze: należy dobrze poznać własną firmę zanim cokolwiek, nie tylko wdrożymy, zanim podejmiemy decyzje by cokolwiek wdrażać.
Po drugie: należy wdrażać (kupować) system w ?kawałkach? po 20-50 funkcjonalności zamykających się w kilku całych procesach biznesowych (a nie działach czy pionach), zamiast setek funkcjonalności wraz z całym systemem ERP za jednym zamachem.
Po trzecie: z czystego bezpieczeństwa projektu i zarządzanie ryzykiem ? wymagania (a konkretnie specyfikacja tego co ma zostać dostarczone) i nadzór nad ich realizacją, to nie jest praca ani dla dostawcy ani dla kupującego, pierwszy najprawdopodobniej będzie koloryzował swój produkt a drugi posłuży się stereotypami.. 4
Ciśnie mi się na usta: A nie mówiłem? 🙂 Jednak nie cieszy mnie to, że mogę tak napisać.
Dziwi mnie, że wszystkie te, doświadczone porażką, firmy mają dostęp do tej samej wiedzy co np. ja, a mimo to zarządy tych firm wierzą bezgranicznie dostawcom oprogramowania i wierzą, że opisywane od lat przyczyny porażek u nich nie wystąpią…
[…]Dziwi mnie, że wszystkie te, doświadczone porażką, firmy mają dostęp do tej samej wiedzy co np. ja, a mimo to […]
Panie Jarku – tę samą wiedzę można interpretować różnie – w zależności od tego jak je przedstawią doradcy, jak bardzo życzeniowo myślimy, jak bardzo nam przeszkadzają klapki na oczach itd itp :). Przypadek bardzo pouczający i dający do myślenia…
Doradcy, zawsze mnie fascynowało, że wielu z nich to ideolodzy nie lubiący faktów. Jeżeli są doradcy, którym z każdej analizy wychodzą te same trzy literki jako rekomendacja… to to są lobbyści… Ale Ja zawsze uważam, że za zarządzanie firma (także projektami) odpowiada jej Zarząd a nie doradcy czy konsultanci czy analitycy.
Często Firmy czy ich Prezesi podejmują decyzje wdrożenia systemu autorytatywną decyzją, co negatywnie wpływa na organizacje. W konsekwencji organizacja traci dynamizm oraz orientacje na Kliencie. To ludzie od Systemu zaczynają generować procesy, niezależnie od zdobytych doświadczeń oraz wypracowanych wraz rozwojem organizacji tzw?best practices?. Popełnianie błędów jest ludzkie, ale tylko naprawdę wielcy potrafią się przyznać do błędów i powiedzenia stop. Lidl pokazał klasę i dojrzałość organizacji. Doszedł do wniosku, że w długofalowej strategii wdrażany system zaszkodzi w dalszym rozwoju.
LIDL, a tak na prawdę konkretny prezes, na pewno pokazał, że nie boi się podejmowania takich decyzji i to publicznie. Poprzednik brnął… Jednak biorąc pod uwagę czas trwania projektu i skale strat, podejrzewam, że nie była żadnej analizy i projektu, a umowa z SAP była na „współpracę”…. Z drugiej strony pisanie samemu całego ERP tez ma średni sens, bo standaryzacja obszarów ściśle regulowanych prawem to pierwszy sygnał, by pewne wybrane funkcjonalności (czyli jakieś 80% 🙂 kupić jako gotowe oprogramowanie na rynku, „tanio” czyli bez żadnych kastomizacji….
SAP nigdy nie był gotowym systemem z półki. Jego wdrożenie zawsze wiąże się z pracami projektowo programistycznymi
SAP pisze co innego 🙂 (pomijam kwestie ustawienia wymaganych parametrów) o czym można przeczytać w dokumencie Metodyka wdrażania ASAP.
SAP to kod, który „działa” plus środowisko pozwalające na dodawanie nowych funkcjonalności (ABAP, obecnie wersja 5.xx obiektowa, i środowiska developerskie plus API do głównej części systemu). No i rzecz w tym, że „projektowanie i programowanie” powinno odbywać się poza oryginalnym kodem dostarczonym przez SAP, wtedy upgrade nie niszczy wykonanej pracy.
W LIDL, jak wynika z krótkiego z opisu, popełniono chyba wszystkie błędy jakie można było popełnić, co starałem się krótko opisać. I nawet gdyby prawdą było to, że „SAP to nie jest gotowe oprogramowanie z półki”, to nie było to przyczyną tej porażki.
Nie mogę się bardziej niezgodzić z większością w zasadzie tez z tego artukułu…
Tworzenie szczegółowego projektu w tak rozbudowanych wdrożeniach to droga do nikąd, po pierwsze w każdym z lokalnych oddziałów, znajdziemy X wyjątków do obsłużenia, przez co budowanie globalnych reguł się zwyczajnie nie uda i skończymy z księgą w 70 tomach, której nikt nie będzie w stanie przeczytać a co dopiero zrozumieć i ogarnąć.
Po drugie sam proces tworzenia projektu zajmie 5 z tych 7 lat pewnie…
Po drugie, używanie kilku systemów, po jednym dla każdej krytycznej komórki/procesu. Każdy integrator wie, że spinanie więcej niż dwóch systemów to męka, a spinanie „kilku” systemów to już droga przez siódmy krąg piekieł, na dodatek sprawa niesamowicie problematyczna jeśli chcemy, żeby wszystkie te systemy się rozwijały, a pewnie chcemy, bo za każdym razem musimy także „rozwinąć” tą „integrację”.
Po trzecie, definiowanie procesów wewnątrz organizacji…
O ile zgadzam się, że absolutnie kluczowe jest posiadanie „po drugiej stronie” osoby która potrafi opisać a w zasadzie zrecenzować szczegóły wszystkich procesów działających w organizacji, to jestem absolutnie pewny, że żaden pracownik klienta, nie zna „nowego” systemu a wdrażając nie potrzebuję opisu na poziomie suchych faktów, potrzebuję konkretnego i spójnego odniesienia do funkcji wdrażanego systemu – chyba, że chcesz taki opis procesów potraktować jako powieść i posadzić do niego analityków, którzy post-factum przetłumaczą go na „język systemu”, więc biorąc pod uwagę, że analitycy i tak muszą być w ciągłym kontakcie z pracownikami klienta, de facto robisz tą pracę dwa razy. A dodatkowo zapominasz chyba, że mówimy tu nie o jednej firme a o kilkudziesięciu „organizacjach w organizacji”
Po czwartek: kupowanie systemu w kawałkach?!
Każdy dostawca wyśsie cię do cna.
Pierwszy kawałek x zł, Drugi kawałek 2x zł, trzeci 4x a później już pewnie x^x
Jak można wchodzić w projekt nie znając kwoty? Standardowo można założyć 15-25% ryzyka i być przygotowanym na czarny scenariusz, ale w takim ujęciu?
Przecież nie dasz rady wziąć nowego wykonawcy do każdego fragmentu, a jeśli taki jest plan to w ogóle krzyż na drogę..
No i na koniec nadzór poza organizacją…
dostawcy zależy na jak najwięszej ilości spalonych godzin
konsultingowej firmie dokładnie na tym samym
i tylko biedny klient zamiast płacić (i pilnować) jednego wykonawcy (dostawcy) pilnuje dwóch…
1. w takich projektach nikt normalny nie robi szczegółowego projektu bo to nie ma sensu, ale to nie znaczy, że NIE ROBI SIĘ PROJEKTU (tu polecam artykuł Cykl życia… na tym blogu).
2. Integracja, może 15-20 lat temu było to piekło, dzisiaj jak się to potrafi, to nie ma problemu (np. SAP dostarcza dedykowane, darmowe narzędzie), integracja kilku jest zawsze tańsza od kastomizacji jednego.
3. procesy analizuje się na poziomie „co i po co” a nie „jak” to się robi, wtedy jest ich kilkanaście a nie kilkaset i pomagają najpierw opisać wymagania a potem wdrożyć system.
4. kupowanie w kawałkach: powiem tylko tyle, że każdy przypadek gdy sprzątam po kilkuletnim nieudanym wdrożeniu monolitu ERP, udaje mi się wdrożyć ekwiwalent składający się z 3-4 dedykowanych systemów w ciągu góra roku…
5. dobrej konsultingowej firmie zależy na dużej licznie projektów a nie na ciągnięciu jednego w nieskończoność… drugi przypadek to pasożyt.
Wdrożenia, które robię są kilka, a nie kilkadziesiąt razy tańsze niż te poprzedników, a zawsze przede mną był jakiś monolit ERP a ja projektuję i wdrażam w jednej firmie systemy od 2 – 3 producentów i dostawców.. w 100% bez pudła..,
Lista referencyjna na pierwszej stronie bloga…
Po czasie ale zgadzam się z RobertMiernik.
1) Trochę systemów SAP wdrożyłem. Zasada jest prosta – albo wszystko albo nic. Nie da się w dużej firmie wdrożyć części funkcjonalności na raty.
2) Największą bolączką jest właśnie integracja – unikać jak ognia
3) Nie ściągać drugiego dostawcy do nadzorowania pierwszego, bo skończy się wielkim niedogadaniem. Trzeba sobie zatrudnić osoby z innych organizacji, które już wdrażały system nie mające pojęcia o naszej organizacji. To one będą torpedować zbędne customizacje.
4) Unikać jak ognia dodatkowych niepotrzebnych zmian i skupić się tylko na tych najważniejszych używając programów i modułów funkcyjnych dostępnych w systemie.
5) Nie ma dobrych firm konsultingowych – są co najwyżej dobrze podpisane umowy z firmami konsultingowymi.
To co pisze Jaroslaw Zelinski to rozwiązania dla mikrusów, a Pan Jarosław coś tam wie, ale nie ma pojęcia o dużych skomplikowanych wdrożeniach.
1. Mam przed sobą SAP w jednej z największych firm w Polsce: ograniczony tylko do FK reszta to zewnętrzne aplikacje zintegrowane z SAP, jest takich instalacji w Polsce wiele.
2. tak było 20 lat temu, SAP ma od lat bardzo dobre narzędzie integracyjne i pokaźną listę partnerów, z których oprogramowaniem się świetnie integruje.
3. bo customizajce są zbędne i odradza to SAP w swojej metodyce aSAP.
4. nic nie zmieniać, nowe funkcje pisać w w środowisku ABAP i integrować
5. słowo przeciwko słowu
Pan Jarosław niestety jest angażowany nawet przez największe firmy w Polsce i nie tylko, specjalizuje się w integracji systemów ERP (nie tylko SAP), z innymi, naprawia i audytuje po dostawcach największych systemów ERP. Lista tych mikrusów na stronie głównej.
P.S. Dalsza dyskusja po rezygnacji z bycia anonimowym, proszę też podawać źródła swoich tez (o integracji SAP).
I jedna ciekawostka: minimalny budżet na wdrożenie systemu ERP na poziomie SAP czy Dynamix AX, to milion zł. i harmonogram na ok. 3 lata. Wdrożenie dziedzinowego systemu wraz z jego integracją w średniej firmie to maks. ok. 250 tys, zł.i kwartału do pół roku. Dane z mojej praktyki.
Druga ważna rzecz: gotowy system ERP jest (z reguły) licencjonowany „per user” i jest bardzo kosztowny bo jest uniwersalny (co strasznie podnosi koszty projektu i developmentu), dedykowany kosztuje tylko tyle co jego wytworzenie…. i jeżeli powstaje z użyciem dzisiejszych technologii i nie musi być uniwersalny (a nie musi) jest ZAWSZE znacznie tańszy niż uniwersalny „z półki”…
uzupełnieniem dyskusji może być ten wpis:
https://it-consulting.pl/autoinstalator/wordpress/2012/07/20/re-duzy-erp-czy-integracja/
Niestety nadal – nie
2. nie wiem o jakiej integracji mówisz, ale na pewno nie o takiej o jakiej ja myślę, SAP dostarcza gotowe narzędzie i jak to Ci pomoże dostać się do danych systemu dedykowanego (jednego z kilku) to nadal koszty i niebezpieczeństwa. Chyba, że integrujesz SAPa z SAPem, wtedy jasne.
3. tak można analizować procesy w firmie z jednym oddziałem i 200 pracownikami, tutaj masz firmę działającą w kilkudziesięciu państwach, globalne/ogólne procesy można tak przenalizować i może wyjdzie z tego dokument możliwy do „ogarnięcia”. Niestety tutaj masz minimum kilkadziesiąt analiz „w jednej”. Skala nieporównywalna i dokument taki absolutnie nikomu i do niczego się nie przyda. Trzeba przyjąć cele strategiczne które później zespoły w konkretnych obszarach będą przekuwały na konkretne działania, nie da się mikrozarządzić takim projektem.
4. znam firmę, która wdrożyła sobie ERPa w excelu w miesiąc, czy to świadczy o tym, że powinniśmy tak robić? To co działa w dniu uruchomienia, albo 3 miesiące później, to nie jest stabilny i przyszłościowy system. Niestety patchworkowe zszywki rozlezą się zwykle dużo szybciej niż byśmy chcieli/zakładaliśmy – oczywiście jak każda prowizorka, czasem będą działać i 10 lat ale to wyjątek potwierdzający regułę i w życiu bym się nie zgodził zapisać to na liście „dobrych praktyk”
5. dobrej konsultingowej firmie, zalezy żeby mieć mnustwo klientów, dla każdego wyprodukować mnustwo dokumentacji, zafakturować mnustwo złotówek i „narobić” się przy tym jak naj mniej. I później klient dostaje po spotkaniu „notatkę” na 40 stron a4, 80% to bełkot, 15% rzeczy oczywiste, 5% merytoryczne uwagi
Lista referencyjna to lista projektów z pierwszej strony? Bo widzę same analizy, brak wdrożeń…
– wszystkie moje analizy to projekty tego co ma powstać i nadzór nad wykonawcą, który nie ma nic do gadania w kwestiach wymagań… ma je realizować
– SAP oferuje API, które umożliwia skuteczna integrację, i to działa
– analizując różne firmy osobiście nie widzę różnicy pomiędzy firmą 200 osób a 20.000 tysięcy osób.. czym innym jest to jak wystawić fakturę a czym innym to ile osób to robi i jak często,
– podobno w excelu można wszystko 🙂 … (ale to nie ja napisałem)
A tu:
” dobrej konsultingowej firmie, zalezy żeby mieć mnustwo klientów, dla każdego wyprodukować mnustwo dokumentacji, zafakturować mnustwo złotówek i ?narobić? się przy tym jak naj mniej.
tu proszę mówić za siebie, a dyskutując z kimkolwiek, warto choć chwile poświęcić by sprawdzić kim jest rozmówca…. ja sprzątam po firmach jak wyżej…
Jeżeli „klient dostaje po spotkaniu ?notatkę? na 40 stron a4, 80% to bełkot, 15% rzeczy oczywiste, 5% merytoryczne uwagi””
od tego momentu niemerytoryczne i nie poparte faktami uwagi wycinam…
No cóż, jeśli cenzura wchodzi w grę, to pozostaje przyznać rację i się pożegnać…
Powodzenia życzę
Raczej jeden analityk by nie podołał analizie w tak rozbudowanej organizacji. Czyli musiał by to być całkiem spory *zespół* analityków. Czy wyobrażasz sobie sprawnie działający zespół analityków, którzy jako wynik swojej pracy dają dokument spójny (a nie zlepek efektu pracy każdego z analityków z osobna), o możliwej do ogarnięcia wielkości. Przyjmuję jako oczywistość, że treść jego będzie wartościowa, bo zakładam, że to dobrzy analitycy byli.
Gdy w grę wchodzi wielu dostawców, którzy będą musieli swoje systemy (często konkurencyjne) integrować ze sobą to jak trudne jest stworzenie umowy jasno regulującej zasady współpracy między nimi? Z naszego doświadczenia (skromnego) wynika, że firmy nie chcą ze sobą współpracować i już. Musisz mieć lepsze w tym względzie doświadczenie.
1. jeden dobry analityk podoła każdej analizie, i nie jest to kwestia czasu a wyboru poziomu architektury, wynikiem pracy dowolnej analizy powinien być dokument nie przekraczający 100 stron… każdy większy jest porażką… (dobry analityk nie napisze więcej… bo wie, że nie ma to żadnego sensu)
2. nie wyobrażam sobie i nie widziałem (od 20 lat) by jakikolwiek zespół analityków zrobił coś spójnego …
3. jeżeli w jakiejkolwiek firmie cokolwiek robią dostawcy konkurencyjnych systemów to jest to dramat projektanta … integracji nigdy nie powinien projektować dostawca systemów integrowanych, integracja to wymaganie …
4. z mojego doświadczenia wynika, że dostawca ma realizować projekt, wykonany przez kogoś innego, nie ma mieć nic do gadania w kwestii wymagań…
Przestrzegam tego i dlatego od 15 lat nie zaliczyłem porażki…. Tak firmy nie chcą współpracować dlatego moi klienci zatrudniają mnie a ja im w tym „pomagam” 🙂 … w moich projektach grzecznie współpracują albo wylatują bez pieniędzy za drzwi… brutalne ale skuteczne.
„mustwo” wiedzy ma P. Robert !
Ja nie widzę problemu (jak i setki firm które odeszły od opasłych systemów „do wszystkiego” do mikroserwisów) w integracji kilku czy nawet kilkunastu systemów.
Osobiście nie lubię SAP, szczególnie za jego wielkość, wydajność, cenę, koszt ich analityków, za wsparcie , za to , że „tego się na da zrobić” i wiele, wiele innych.
Nono, jeden chłop miałby zaorać całego Lidla?
Na jakim poziomie ogólności musiał by być ten dokument, aby w tych 100 stronach się zmieścić, a jednocześnie zawrzeć konkretne wymagania na soft?
Skoro narzuconym ograniczeniem mamy wielkość dokumentu analizy (przyjmijmy stałą wartość 100-200 stron) a zmienna jest wielkość analizowanej organizacji, to siłą rzeczy aby analiza miała sens (czyli wartość dodaną, na podstawie której dokonujemy wyboru softu) musi jakoś się dostosować do wielkości klienta. Inaczej w takim razie wyglądać będzie dla firmy 100 osobowej, a inaczej dla 20000. W czym w takim razie tkwić będzie różnica? Na zwiększaniu poziomu abstrakcji (ale wtedy coraz dalej od wymagań uciekamy)?
Po liczbach jakie padają w artykule (1200 pracowników IT) wynika, że to niezły bigos. Lidl wyhodował państwo w państwie i pewnie chciał 'obniżenia kosztów’ przez zastąpienie tej ekipy SAPem.
1. każdy projekt to piramida ról z jednym wierzchołkiem, niezależnie od tego czy powstaje domek jednorodzinny czy drapacz chmur, architekt jest jeden
2. im większy projekt tym trwa dłużej i tym bardziej nie ma sensu spisywanie detalicznych wymagań, polecam ten wpis: https://it-consulting.pl/autoinstalator/wordpress/2017/01/13/wymagania-umarly-rozwiazaniem-jest-cykl-zycia-produktu/
(wymagania na dedykowane oprogramowanie, wytworzone kosztem 250 tys. netto, opisałem na 35 stronach, pod moim nadzorem: projekt zakończony w terminie w budżecie, bez sporów)
3. LIDL uwierzył konsultantom SAP’a… ot tyle…
Od pewnego czasu nie jest to już na NDA: jeden chłop i system UR kopalniach KGHM:
http://szkolaeksploatacji.pl/sesja/panel-dyskusyjny-warsztat-izip-w-kghm-2/
Panie Jarku może zaprojektuje Pan system dla Lidla?
Jak poproszą ;)… Pomagałem Echo Investment, Pomagam KGHM, im też mogę… 😉
Projekt trwa nadal i potrwa do przyszłego roku. System działa od ponad roku w czterech krajach (Austria, Serbia, Irlandia Północna oraz USA). Wszystkie procesy zostały zaimplementowane i system gotowy jest do rolloutów do pozostałych lokalizacji. Szkoda że nikt w tej dyskusji nie wspomniał o „polityce” wewnątrz firm tak dużych jak Lidl – wdrożenie rozpoczął inny prezes, kończy także inny, nie bez znaczenia są także opory potężnego działu IT który chętnie rozwijałby system autorski. Nie wydaje mi się także że ktokolwiek poza grającymi razem w golfa dyrektorami LIDL i SAP znał prawdziwe powody przepalenia 500 mln EUR na niedokończone wdrożenie.
mimo wszystko coś jednak poszło nie tak 😉
Nie ma wątpliwości że coś poszło nie tak, ale nasze rozważanie na ten temat można porównać do obserwowania dzikiego słonia przez lornetkę i zgadywania co mu zaszkodziło, pewnie zjadł coś niedobrego w ciągu ostatnich 6 lat :).
Owszem, jednak są pewne fakty:
1. siedem lat od podpisania umowy do jej wypowiedzenia
2. wydano 2 mld. złotych
3. SAP nagrodził (czyli wyróżnił) w 2017 roku LIDL jako czołowego swojego klienta (a klient to projekt)
4. umowę rozwiązano i podano przyczynę: nie udało się zrealizować celu projektu.
Tak więc:
1. wielkie korporacje także miewają porażki wdrożeniowe,
2. SAP, mówiący o sobie że jest dużą doświadczoną firmą mającą wysokiej klasy specjalistów, potrafi się mylić aż siedem lat.
3. Kastomizację uznano za jedną z przyczyn porażki.
Reszta to spekulacje o słoniu, bo nie mamy wiedzy innej ponad to. To, że ten projekt nadal trwa, to tylko konsekwencja tego, że takie projekty mają także proces wychodzenia z umowy, a to nie trwa kilku sekund ;).
Nic nowego, to się zdarza. Oczywiście nie znam szczegółów ale moje doświadczenie mówi że LIDL po prostu przeliczył sie z zakresem customizacji. SAP jest pod tym wzgledem zupełnie nie elastyczny i takie rzeczy załatwia się aplikacjami zewnwętrznymi.
Pytanie brzmi kto i jak zarzadzał ryzykiem w tym projekcie i kto był nad ta osobą 500 mln euro w błoto…. gratuluję.
BTW – informacja ma juz ok 3-4 miesiace
Jestem podobnego zdania, niestety tak wygląda większość wdrożeń RP jakie znam, kwestia strat :)… Tu LIDL chyba wychodzi na lidera roku :D.
o takie przyziemne pytanie czy jakaś nasza rodzima firma brała udział przy analizie i pracowała jako podwykonawca dla SAP ?
nie napisali
Panie Jarku bardzo lubie Pana analizy i z wieloma rzeczami sie zgadzam, ale co przeszkasza mi od zawsze to Pana wewnetrzny poziom samouwielbienia i nieomyslnosci. Trafia Pan w punkt z przyczynami problemow, ale Pana rozwiazania….dokument analizy na 100 stron, jeden analityk od wszystkiego…to juz albo kula w plot albo nachalna reklama samego siebie 🙂 ale i tak bede czytal dalej
Dziękuję za opinię. Są święta to na spokojnie się powynurzam :).
Z opiniami takimi jak Pana opinia: „Pana wewnętrzny poziom samouwielbienia i nieomyslności”, spotykam się regularnie w trakcie szkoleń, w tracie zajęć ze studentami zaocznymi i dostaję takie listy mailem.
Tak więc jestem zobowiązany do wyjaśnienia :). Do tej pory robiłem to głównie odpowiadając na sali szkoleniowej lub wykładowej pytającemu, lub na maile kierowane bezpośrednio do mnie. W końcu przyszła pora odpisać na publicznie zadane pytanie (cieszę się, że w końcu padłu tu).
Mam pełną świadomość, że z boku tak mogę być postrzegany. Ale:
1. generalnie stosuję w 100% standardy, opieram się w 100% na oryginalnych specyfikacjach,
2. z powodu wielu zarzutów o zarozumiałe krytyki książek, nawet tych uznawanych za „biblie”, od pewnego czasu, zarówno na szkoleniach jak i na wykładach na uczelni, posługuję się wyłącznie oryginalnymi specyfikacjami notacji (UML, BPMN, inne),
3. z powodu zarzutów jak wyżej, od pewnego czasu na blogu staram się przywoływać wszelkie znane mi źródła opisujące najlepsze praktyki, studia przypadków, itp. by pokazać, że nie odkrywam tymi artykułami ameryki i nie wymyślam sam, a jedynie przywołuje cudze lub swoje (zbliżone do cudzych) doświadczenia i wnioski.
Dokument na 100 stron: proponuję teksty (nie licząc jednego autcytowania), które cytuję w artykule Wymagania umarły. W swojej kilkunastoletniej karierze widywałem setki opracowań na setki stron, praktycznie za wszystkie zapłacono (nie mało), w zasadzie żaden nie został w pełni wykorzystany. Nie jest to tylko moje doświadczenie. Moje dokumenty nie są tanie i proszę mi wierzyć, rzadko przekraczam 100 strom (i od ok. 2005 roku praktycznie w ogóle, i na żadnym etapie, nie używam pakietów biurowych do ich tworzenia!)
Jeden analityk od wszystkiego: przeciętny architekt budowlany po politechnice, praktykujący swój zawód, to osoba, która potrafi zrozumieć i opisać biznes swojego klienta, wykonać prezentacje 3D wieżowca w oprogramowaniu CAD, wykonać projekt architektoniczny, poprowadzić na budowie nadzór autorski. To jest właśnie Jeden od wszystkiego. Organizacja IIBA w BaBOK zaleca dla produktu wykonanie: analizy biznesowej udokumentowanej modelami, opracowanie logiki produktu jako „białej skrzynki” udokumentowanej modelami, zaleca stosowanie sformalizowanych standardowych notacji (BPMN, UML< itp.), zakłada że autor analizy i projektu nadzoruje wykonawcę. W opisie cyklu dojrzałości analityka IIBA, wskazuje że jest to zadanie dla jednej osoby. Wśród tak zwanych PM'ów od wielu lat krąży porzekadło, o wielu osobach do jednej roboty, że dwie kobiety nie urodzą dziecka w 4,5 miesiąca. Co jest na rzeczy... Ja nie widziałem NIGDY dokumentu który byłby spójny, przydatny i byłyby to setki stron wykonane zespołem kilku analityków. Polecam artykuł Sabotaż.
Na koniec:
1. zajmuję się badaniami naukowymi w obszarze budowania abstrakcji systemów w analizie systemowej, metodologiami projektowania, za to nikt mi nie płaci, to moje koszty,
2. zarabiam na życie prowadzeniem analiz i projektowaniem oprogramowania i nadzorem nad wykonawcami, dla nie raz dużych i ryzykownych projektów, praktycznie zawsze po kimś…
3. niemalże wszystkie moje projekty realizuję dla średnich i dużych firm, niemalże w 100% są objęte zakazem publikacji tego co i dla kogo robię, dlaczego zakazem? Bo praktycznie w 100% robię to jeszcze raz po specjalistach największych trzyliterowych (i nie tylko trzy) firmach na świecie, nie raz mam nadzory nad nimi (dwa obecnie w toku). Żaden mój klient tego publicznie nie napisze.
Czy to reklama samego siebie? Też, ale przede wszystkim to promocja narzędzi i metod pracy, szkoleń, wystarczy czytać coś poza komunikatami prasowymi wielkich korporacji (to nie jest przytyk bo nie wiem co Pan czyta i co robi), by wiedzieć, że nie jestem odosobniony w tym co robię, jak to robię i że robię to w projektach sam.
„Trafia Pan w punkt z przyczynami problemów, ale Pana rozwiązania?.” są po prostu skuteczne i nie są moje. Moje rozwiązania to metamodele, architektury systemów, systemy standaryzacji jakie nie raz opracowuję jako dedykowane, dla moich klientów. Ale metody pracy, a o nich piszę na blogu, to coś o czym można przeczytać nie tylko u mnie. Ja tylko się cieszę, że nie raz dochodzę do wniosków, do których już inni doszli. Mój dawny profesor mawiał: gdy dwóch mówi to samo to nie jest to samo.
Na prawdę dziękuję za krytykę, zmusza mnie do pokory ale także do uporu w pisaniu o niepopularnych rzeczach… Taką niepopularną rzeczą jest między innymi to, że przytłaczająca większość firm doradczych i wdrożeniowych, w tym tych największych, wykorzystuje bardzo pracochłonne i ryzykowne metody pracy oparte na pakietach biurowych i poczcie elektronicznej mimo tego, że świat zna narzędzia CASE i wyrafinowane repozytoria plików. Koszt tych narzędzi per osoba to ok. 800USD a wiec trzy rynkowe dniówki analityka z poważnej firmy. O czym my tu rozmawiamy?
W kwestii zaś tego, że tworzenie wielkich dokumentów analiz nie ma większego sensu, polecam także nie moją literaturę, książkę cytowaną na końcu tego artykułu (dotyczy wielomiesięcznych analiz i tworzenia korporacyjnych modeli danych danych – czegoś bardzie niepotrzebnego, milionów dolarów wyrzucanych w błoto na takie wielkie analizy, także w Polsce):
https://it-consulting.pl/autoinstalator/wordpress/2017/02/03/biznesowy-model-danych-nie-chcemy/
Sap przede wszystkim wymaga porządnej implementacji, dla firmy, która wcześniej nie korzystała z podobnego systemu. My współpracujemy aktualnie z sid i póki co wszystko idzie sprawnie, ale jeszcze kilka ważnych zmian przed nami.
Czym jest „porządna implementacja”? Programy ERP (takie jak SAP i podobne) są już konkretną implementacją z konkretnym modelem danych zbudowanym w oparciu o relacyjny model danych.
Świat jest paskudny, spotkanie wielu ważnych dyrektorów finansowych i nie tylko, zaowocowało takim oto wnioskiem:
„Wtedy ? 15 lat temu ? chcieliśmy, aby wdrażany system miał ?wszystko?, tyle funkcjonalności, ile da się wycisnąć z danego software?u. No i też chcieliśmy, aby system ? mimo że to standard ? dostosował się naszych procesów, bo ?nasze procesy są takie unikatowe, inne niż gdziekolwiek indziej?.
W efekcie wdrożyliśmy ciężkie rozwiązania, wymagające wysoko wykwalifikowanych kadr, kosztowne, gdy cokolwiek trzeba zmienić w nich. Są to systemy właściwie nie do wykorzystania przez biznes bez stałego wsparcia specjalistów IT. Już nie mówiąc o tym, że każdy upgrade, każda integracja to wielkie zamieszanie w firmie, niepewność efektu, ryzyka związane z ciągłością, itd.
Dzisiaj dojrzali menedżerowie mówią ? wdrożymy tyle, ile jest absolutnie konieczne. Jak będzie trzeba, dołożymy więcej, zostawiamy taką możliwość. Technologia staje się rozwija, może za chwilę dane rozwiązanie będzie w standardzie, nie trzeba będzie go dodatkowo rzeźbić i za nie dopłacać.”
źrodło:
Ja ostatnio własnie starałem się dowiedzieć czegoś o SAP. Słyszałem, że wdrożenie takich systemów pomaga w wielu procesach wewnętrznych firmy, ale też np. może ułatwić współprace z klientem. Według mnie ciekawa sprawa dla wielu firm.
Warto zawsze sprawdzić odsetek wdrożeń zakończonych sukcesem, a sukcesem nie jest to że projekt zafakturowano a to, że osiągnięto cel określony w dniu rozpoczęcia: termin i zakres oraz cel biznesowy.