Przedstawiciel Microsoft prognozuje, że niesłabnącym zainteresowaniem nadal będą cieszyć się duża elastyczność oraz skalowalność rozwiązań, a także rozszerzanie funkcjonalności istniejących bądź nowych wersji systemów IT. (żr. wnp.pl Po kryzysie firmy IT musiały przeformułować ofertę. Wirtualny Nowy Przemysł – Informatyka. Informatyka dla przemysłu.)
Zaciekawiło mnie to, gdyż z obserwacji moich wynika, że Microsoft, w przeciwieństwie do wielu konkurentów, uznał fakt rynkowy: wdrażane systemy ERP są modyfikowane i rozszerzane. Daleki jestem od reklamy tego konkretnego rozwiązania ale jest to jakiś znak na rynku :). W strategii jednak tej firmy, znalazło się dodawanie funkcjonalności poprzez “dopisywanie” dedykowanych modułów. Nie będę się w tym artykule wgłębiał w szczegóły tego jak dodać nową funkcjonalności do gotowego ERP, w każdym razie należy to zbadać (analiza wymagań), zaprojektować (opracowanie koncepcji i proof-of-concept) i wykonać (zlecić do implementacji firmie wybranej np. w przetargu).
W jednym z poprzednich artykułów (przeczytaj) przytoczyłem fragmenty rozmowy z reprezentantem dostawcy znanego systemu ERP. Teraz rozmowa z odbiorcą na temat dedykowanych rozwiązań. Przypomnę, że rozwiązanie dedykowane to nie koniecznie nowy ERP napisany od zera (tego się raczej nie robi), dedykowane rozwiązanie to nowy moduł reprezentujący dedykowane potrzeby, napisany by nie “niszczyć” (nie “kastomizować”) gotowego oprogramowania ERP.
Trudno odrzucić “głos ludu” w takich dyskusjach. Na pytanie, zadane na pewnym ogólnopolskim forum dyskusyjnym, o dedykowane rozwiązania, pewien pracownik dużej polsiej firmy napisał (mam nadzieję, że pozostawione slangowe elementy wypowiedzi nie będą przeszkadzały), pytania jakie zadałem na liście pogrubione:
Wypowiem się jako przedstawiciel klienta, który wdrażał rozwiązania dedykowane, obserwował i obserwuje wdrażanie systemów pudełkowych z półki na niezłej wysokości. Dodatkowo mam za sobą specyfikację wymagań przetargowych do systemu dość wymagającego i ocenę ofert, w których były i rozwiązania pudełkowe i dedykowane.
1. Mamy kilka systemów dedykowanych od wielu lat. Niektóre są napisane przez wewnętrzne komórki rozwoju i są ciągle dokładane kolejne funkcjonalności. Zakres jest bardzo unikalny, użytkownik jest bardzo wymagający i takie podejście do systemu (to jest system typu inventory zawierający również warstwę planowania, często się pojawiają nowe nazwijmy je ‘technologie’, które muszą mieć użytkownicy natychmiast zamodelowane w systemie) mu bardzo odpowiada. Koszt kilku programistów jest nieduży w porównaniu z tym, co życzą sobie firmy outsourcingowe.
2. W pewnym momencie padło z góry hasło migrujmy wszystko do jednego narzędzia typu jedno ERP na wszystko. Było nawet podane super drogie i podobno mające niesamowite możliwości narzędzie, do którego mielibyśmy zmigrować nasz ‘home-made’. Koszty były ogromne, a co śmieszne – część rzeczy musieli byśmy sami napisać. A system stworzony podobno specjalnie pod kątem takich obszarów działania, jak my mamy.
Generalnie nie ma szans. Ten system podpada pod kategorię, którą Jarek [to odpowiedź na mój post, przypis mój] zdefiniował jako bardzo unikalne kompetencje i strategia działania. Pudełka nie pasują. Na szczęście udało się tego uniknąć. Business Case w żaden sposób się nie zamykał.
3. Narzędzie finansowe. W firmie było jedno pudełkowe narzędzie A na obsługę całego procesu finansowego: od zamówienia zakupu poprzez odbiór i rozliczenie faktur i księgi finansowe. Ma to sens i jest logicznym procesem przepływu finansowego. Jakiś kretyn wylobbował wprowadzenie innego narzędzia dla etapu zamówienia zakupu. Bo jakoś wyszło, że analizy pokazały, ze dla obszaru zamówień zakupu najlepsze jest narzędzie X, dla części środkowej tego procesu, gdzie inna organizacja najwięcej robi – najlepsze jest narzędzie Y, a dla obsługi faktur – najlepsze narzędzie Z. Wszystkie 3 (X,Y,Z) i A są narzędziami gotowymi. Obserwowałam obie opcje – samo narzędzie A i działanie 3 narzędzi X,Y,Z. I niestety kombajn 3 narzędzi był gehenną dla użytkowników i kupę kasy i błędów kosztowały integracje, mimo że składał się z niby lepszych elementów. Narzędzie jedno na cały proces finansowy (ale tylko finansowy, a nie wszystko, co jest w firmie) nawet ciut gorsze – sprawdzało się lepiej. Łatwiej raportować, mniej błędów przy integracjach. Strumień danych przepływający przez te integracje jest na tyle duży, że to jest bez sensu. Dużo lepiej sprawdzało się 1 dedykowane rozwiązanie A do obszaru finansowego.
4. Prowadziłam przetarg na system. Wymagania były bardzo dokładnie wyspecyfikowane. Oferty były z rozwiązań pudełkowych jak i dedykowanych. W komisji przetargowej byli przedstawiciele komórki stricte IT, więc mogłam z bliska i na znanym obszarze zaobserwować ich sposób działania i podejście do wyboru. Rozwiązania pudełkowe: część ofert nie spełniała wymagań (wielu! kluczowych). Część spełniała. Była nawet oferta pudełkowa, która miała najlepsze oceny techniczne, prawie ideał, według oferty muszą dorobić tylko 3 funkcjonalności na ok 25. Oferty dedykowane – mające lub nie część już gotowych komponentów. Były firmy z dedykowanymi rozwiązaniami, które szczegółowo opisali, że np wymaganie x możliwe do spełnienia w trochę inny sposób, niż napisane ze względu na użytą technologię (lub cokolwiek innego).
No i wybór na sort liście: dedykowane i pudełkowe, oceny techniczne różnią się w 3-4%. Wycena implementacji (w tym jednorazowy zakup licencji): pudełkowe o ok 60% droższe w zakupie jednorazowym. To jeszcze pół biedy, można tłumaczyć, że pudełkowe- potem dodawanie nowych funkcjonalności prawie nic nie kosztuje (chociaż dla mnie to nie jest takie pewne). Ale, koszty utrzymania w pudełkowym są kilkakrotnie droższe niż dedykowanego i ta kwota różnicy stanowi 70% kosztów implementacji systemu dedykowanego. Wychodzi na to, że nawet jak się walnęliśmy o prawie 100% w specyfikacji wymagań, to przy dedykowanym rozwiązaniu oszczędzamy tyle przez 1,5 roku, że możemy od nowa system napisać.
Pudełkowe są cholernie! drogie. Nie mówię już o ofertach pudełkowych, które kosztowały czterokrotnie więcej niż rozwiązanie dedykowane.
-Argument, że w pudełkowych wiele firm składa się na rozwój systemu do mnie nie przemawia, bo patrząc na ceny mam wrażenie, że w pudełkowych każdy klient płaci tyle ile kosztowało ich wyprodukowanie tego. Po prostu przy drugim kliencie mają już czysty zysk.
Obserwowałam preferencję i sposób wyboru narzędzia przedstawicieli stricte-IT [ja mam informatyczne wykształcenie i doświadczenie, ale nie jestem w komórce IT, stąd takie określenie]. Teoretycznie, tylko oni mają kompetencje i mogą wybierać rozwiązania informatyczne]. Podejście na dzień dobry :
[JZ] Pudełkowe jest lepsze, bo rozwiązania “będące standardem na rynku” są lepsze, stabilniejsze; więc wniosek – rozwiązania pudełkowe są standardem rozwiązań.
Rozwój dedykowanych kosztuje więcej niż pudełkowych (co jak widać powyżej i w kilku innych przypadkach jest nieprawdą:).
– za każdym razem się łudzą, że tak będzie tym razem, a tak nie jest 😉
– popełnili błąd najgorszy – nie próbowali zrozumieć wymagań biznesu. Oceny były według sympatii do firm. Mi (bo ja definiowałam wymagania po rozmowach z użytkownikami) powychodziło, że oferta x nie spełnia zupełnie tego wymagania, a od nich ocena była 5, a innych 2-3 mimo, ze spełniali wymagania.
Więc takie decyzje o wyborze z góry, rozwiązania pudełkowego mogą być powodowane brakiem kompetencji w ogóle w tym, co robią ci co wybierają.
– mit podtrzymywany cały czas, że utrzymanie i rozwój będą dla pudełek tańsze. – A jak obejmie jeszcze inny obszar firmy i ich procesy (bo faktycznie takie narzędzie może to zrobić), to efekt skali spowoduje, ze koszty utrzymania będą tańsze u pudełkowych. Guzik, pudełkowe mają bardzo często licencje per liczba użytkowników + jeszcze roczny support tych licencji. Więc przy dodaniu kolejnego obszaru, nawet jak nie ma potrzeby nowych funkcjonalności, to dochodzą nowi użytkownicy => koszt jednorazowy zakupu licencji + wzrost rocznie kosztów utrzymania (a miał być podobno spadek, bo koszty niby się rozkładają).
[JZ] O wadach i zaletach “kastomizacji” czyli wprowadzaniu modyfikacji do gotowego i przetestowanego oprogramowania, “odchodzeniu” od dystrybucyjnej ich wersji (utrata korzyści skali)
Mieliśmy taki, upgrade do nowej wersji pudełka jest w zasadzie niemożliwy. Trzeba pisać wszystko od nowa – po prostu nowy projekt zrobienia systemu+jeszcze ogromne koszty migracji danych. I tak stoi np system pudełkowy już X lat, cały czas chodząc na Oracle 6.
[JZ] O wadach i zaletach nienormalizowanych baz danych i integracji systemów (systemy gotowe i dedykowane)
Wypowiem się tylko o normalizacji i denormalizacji. Mamy ten system z pkt 1 jako inventory+narzędzie do planowania. I mamy oddzielnie hurtownię, która przechowuje dane statystyczne z obiektów zawartych w tym systemie. Nie ma szans, żeby to działało jako jeden system. Nie miały by szans takie analizy, które są przeprowadzane na hurtowni. A integracja tych systemów jest nieduża.
Zresztą tu nie widzę o czym dyskutować, systemy transakcyjne służą do zupełnie innych rzeczy niż systemy hurtowniane.
[JZ] O niezawodności i ryzyku systemów pracujących na danych rozproszonych i danych skupionych w jednym miejscu.
Jeśli tu chodzi o system np. jeden ERP na wszystko , jedna megabaza ze wszystkim. To nie widzę sensu chociażby dlatego, że pewne obszary mają nie za dużo punktów styku i generalnie funkcjonują w dość różnych płaszczyznach. Takim skrajnym przypadkiem jest np system bilingowy, system finansowy (opisany wyżej) i bazy dla techniki. Wszystko dotyczy np stacji bazowych, ale pod zupełnie różnymi kątami: w systemie finansowym – tylko nr code stacji i jej adres i wszystkie aspekty finansowo zakupowe; w systemie techniki nr stacji, jej adres i absolutnie wszystkie parametry techniczne, sprzęt i soft zainstalowany tam plus planowany. W bilingu w ogóle stacji jest potrzebny tylko nr code, zeby wiedzieć, która stacja obsługiwała rozmowę.
Mieszanie wszystkiego do jednego kotła chociażby przez to jest bez sensu.
Dodatkowo, systemy mogą operować na podobnych danych, ale wymagają różnych poziomów utrzymania. System zakupowy może działać 8-17/5 dni, a system obsługi klienta musi działać 24/7 czy nadzoru sieci. I awaria takiego systemu 8-17/5 nie jest aż tak dramatyczna, jak tego drugiego, ale we wspólnym systemie może pociągnąć za sobą de facto awarię dla obszaru 24/7.
Uff.
Dodam też, ze widziałam dużo systemów drogich i zupełnie do kitu jak pudełkowych tak i dedykowanych. Ale tam głównie winę bym z baaardzo dużym prawdopodobieństwem położyła po stronie tzw analityków, co albo uważają, że wiedzą lepiej niż uzytkownik, albo są najzwyczajniej w świecie głupi i niekompetentni.
Z innej strony nie zupełnie mnie to dziwi, bo nadal są firmy, które uważają, że informatykowi ty 2000-2500 PLN brutto to jest wystarczająca pensja. Sorry, ale w takim przypadku tak niska jakość ich pracy mnie nie dziwi.
A i jeszcze nt kombajn czy komponenty.
Jak mamy kombajn (vide przykład z narzędziem finansowym) firma się poczuła bardzo pewnie i nawet włączanie kolejnych funkcjonalności w pewnym momencie zaczęli wyceniać na ogromne kwoty.
Monopol nigdy nie jest dobry, w żadnym przypadku.
I właśnie, przy zakupie pudełka, oferty które widziałam albo systemy już działające pudełkowe – zapłacono więcej niż by kosztował dedykowany. Z myślą, że kupujemy więcej niż teraz potrzebujemy, żeby potem tylko pewnym parametrem zmienić funkcjonalność. A w praktyce się okazywało, że trzeba dokupić jeszcze moduł B (licencje do niego), a za włączenie funkcjonalności C zapłacić i niemało. W zasadzie nie wiesz, co dokładnie kupiłeś jako nadmiarowe: jak ktoś trafnie porównał – kupujesz wiaderko lego, żeby zrobić samochód. Tylko w tym przypadku nie wiesz, co pozostało w tym wiaderku i nie wiesz, czy możesz czy nie zrobić z reszty bagażnik dachowy.
Może to wina źle skonstruowanej umowy, ale chyba i tak w firmie kupującej ktoś musi dobrze poznać całe narzędzie (nawet nieużywane komponenty), aby nie pozwolić tak się wykorzystać.
Wypowiedź na blogu IDG
Reasumując ? nie wierzę w udane wdrożenie bez modyfikacji systemu. Jeżeli system ma usprawnić funkcjonowanie firmy, jego wdrożenie nie może abstrahować od jej struktury, unikalnych procesów i kultury korporacyjnej. Niektóre rzeczy można załatwić wykorzystując mechanizmy konfiguracyjne. Niestety nigdy nie są one wystarczające i nie można bać się doróbek. Sądzę, że klapa niejednego wdrożenia to skutek kurczowego trzymania się dogmatu o nienaruszalności systemu ERP. Narobił on już wystarczająco dużo szkody ? zapomnijmy w końcu o nim.
Źr. http://projekty.erpstandard.pl/2010/09/14/erp-owym-purystom-mowimy-stanowcze-nie/
