Tym razem z znowu z cyklu ?na forach?? Jakis czas temu ukazał się ciekawy artykuł (sztuczki)

Na jednym z forów o negocjacjach i o biznesie IT pewnego serwisu przetoczyły się burzliwe dyskusje na ten temat. Co ciekawe, były także głosy godzące się z tym, że sztuczki dotykające manipulacji partnerem są dopuszczalne. Część dyskutantów traktowała to jako ?oko za oko? inny twierdzili wręcz, że to rodzaj strategii korporacyjnej.

Nie będę dalej wgłębiał w meandry etyki bo o czym innym chciałem tu napisać. Pomyślałem, że podejmę próbę wyjaśnienia tego zjawiska, mogę jednak stwierdzić, że nieuczciwe metody wabią każdego bo są tańsze i pozwalają ukryć niekompetencję. Jest to prosty mechanizm: kupujący system IT robi to raz na ok. 5 lat, jak projekt będzie porażką to po pierwsze nie przyzna się (akcje spadną…:)?) po drugie szybko o tym zapomina, dostawca zaś korzysta z tego, bo nie robi sobie antyreklamy, a do tego jako firma bardziej doświadczona w branży, zawsze ma tu przewagę nad kupującym. Znam przypadki gdy naprawdę bardzo kiepski projekt pojawiał się na liście referencyjnej wykonawcy bo klientem była znana i duża firma!

ANALIZA W PROJEKCIE IT

Wyobraźmy sobie sytuację, w której na rynku budowlanym inwestorem jest nabywca, tenże nabywca nie ma kompetencji budowlanych a jednak zleca wszystko, w tym analizę i projektowanie, wykonawcy.

Na rynku IT zawalenie projektu nie powoduje śmierci setek osób dlatego nabywca płacze po cichu a prokurator też nie ma co robić. Co ciekawe jednak oprogramowanie np. dla sprzętu medycznego jest robione po bożemu i bez kantów… dlaczego? Inny przykład: swego czasu widziałem proces developerski oprogramowania dla telefonów komórkowych, w porównaniu z ERP to kosmos jakości i dokładności. Zapytałem kierownika projektu z tej firmy co ich skłania do tak wysokiej jakości skoro to podnosi koszty? Odpowiedział: ?Wyobraź sobie, że nagle coś nie wyszło w najnowszej partii telefonów wypuszczonych na rynek…… siwy dym i wszyscy wiedzą, a jak coś się zawali w produkcie czołowego dostawcy systemów ERP na rynku to nikt o tym nie wie więc po co się starać? :)).

Moim zdaniem mamy do czynienia z pewnym paradoksem epoki: firmy inwestują w oprogramowanie nie raz setki tysięcy złotych i więcej, statystyka wdrożeń pokazuje, że podczas wdrożenia najprawdopodobniej dopłaci drugie tyle jednak firmy te (za obopólną zgodą z dostawcą oprogramowania) oszczędzają z górą kilkanaście procent planowanego budżetu projektu wykreślając z projektu analityka, prawnika i negocjatora. Moim zdaniem jest to lobbing dostawców IT, którzy generalnie zarabiają na niekompetencji i braku doświadczenia kupujących (nie wszyscy na szczęście). Rozumiem, że wiedza ekspercka ma wartość na rynku (sam na tym rynku funkcjonuję) ale nie rozumiem wykorzystania tej wiedzy przeciwko własnym klientom?

KTO TYM KIERUJE

Dobry szef IT to przede wszystkim dobry manager (moim zdaniem). Wydaje mi się, że mechanizm początków patologii jest taki: Prezes (niech mi ktoś powie dlaczego) uważa, że szef IT to omnibus (podobnie jak np. syn prezesa, który wszystko wie o komputerach :)), tenże szef IT za nic w świecie nie dostanie budżetu na doradztwo i ekspertów bo w oczach Prezesa to on powinien to robić.. wobec tego robi to sam i swoimi ludźmi, efekty są najczęściej opłakane (gdyby nie umowy o poufności wiele znanych mi analiz wykonanych przez pracowników pionów IT zasiliło by blogi typu humor zeszytów).

Bardzo często manipulacja ze strony dostawcy polega właśnie na tym, że wmawia się klientowi, że gotowa implementacja procesu (modele referencyjne w gotowym oprogramowaniu ERP) jest dobra, co nie raz nie jest prawdą bo jednak firmy się między sobą istotnie różnią. Różnią się nawet w tej samej branży gdyż na tych właśnie różnicach budują swoją przewagę 🙂 nad konkurencją. Znam przypadki, gdy efektem wdrożenia “oprogramowania wiodącego dostawcy na rynku ERP” była utrata posiadanej przewagi i upadek firmy.

Na forach: [Ja] Dobrą praktyką jest by analityk wykonał analizę biznesową i opracował wymagania na oprogramowanie a po nim dopiero był wyłaniany dostawca, który opracuje plan wdrożenia.

[Oponent] Nie jestem przekonana, że taki podział ról jeszcze obowiązuje 🙂 chyba jednak przy dużych ERP-ach rolę analityka biznesowego pełnią konsultanci, którzy realizują wdrożenie – to już rzadko są ludzie “od IT” raczej od biznesu (ci których znam nie są informatykami, tylko ekonomistami, logistykami itp.). Ale nie znam przecież wszystkich firm na świecie 🙂 może są i takie o jakich piszesz, gdzie wdrożeniowiec jest tylko od ustawiania parametrów w systemie…

[Ja] Ten podział ról, który opisałem, nie obowiązuje, on jest optymalny. Problem w tym, że taki “analityk dostawcy” podczas rozmów z klientem jak usłyszy, że klient wystawia fakturę na której wpisuje numer buta (załóżmy bardzo potrzebny z uwagi na specyfikę klienta) klienta słyszy od tego “analityka”, że tak się nie robi.

[forumowicz] Czytam i strach mnie coraz większy ogarnia. To co piszesz to przecież dokładnie to co się dzieje u nas z wdrażanym ERP – z litości nie wymienię dostawcy. Próbują nas przekonać, że ręczne nadawanie numerów dokumentów to właściwa metoda, że nie ma potrzeby podłączać korespondencji do realizowanych spraw a dzisiaj się dowiedziałem, że projekt sprzedażowy bez analizy ryzyka (w sytuacji gdy taka analiza wynika z określonych wymogów) może się spokojnie toczyć bez alarmowania zainteresowanych o braku tejże analizy – aż do podpisania umowy.

Dotychczas informacje o porażkach we wdrożeniach systemów biznesowych traktowałem jako czarny PR lub dziennikarskie kaczki ale odkąd przeżywam to na co dzień to zaczynam wierzyć, że większość takich wdrożeń się nie udaje.

POWOLI COŚ SIĘ ZMIENIA

Firmy mają już drugi a nawet trzeci system i wiedzą na co zwracać uwagę.

W USA niedopuszczalne jest np. by dla administracji państwowej projekt systemu wykonał jego przyszły dostawca, to są osobne przetargi a dokumentacja powinna być taka by dowolna firma stosująca standardy mogła na jej podstawie wykonać system lub w dowolnym momencie przejąć projekt. U nas ta cecha jest pierwszym elementem, który ubije integrator IT.

Czasami słyszę, ze najlepszy analityk to własny bo wtedy podczas wdrożenia on wie o co chodzi, ano właśnie: i jak firma paprze to przekazanie projektu innemu wykonawcy jest niemożliwe i o to chodzi!

Na szczęście widuje coraz częściej przetargi oddzielnie na analizę i dokumentacje a oddzielnie na realizację. W efekcie podniesienie kosztów projektu o ok. 10-20% (przeciętny koszt analizy i specyfikacji wymagań) chroni przed stratami rzędu 100% projektu i więcej.

Nie zmienia to faktu, że wielu klientów skreśla analizę licząc, że jego ta porażka nie dotknie: to jest jednak próba wygrania w totolotka.

Na koniec: niestety wiele analiz wykonywanych metodą SDD (Student Driven Development ;)) i ich jakość jest tragiczna więc skreślenie takiej (nie raz kosztownej) analizy ma sens i koło się zamyka….

Widuję analizy wymagań wykonane za ciężkie pieniądze a będące niespójnym tekstem prozą na dziesiątki stron niemalże bez żadnego diagramu. Wtedy pytam klientów: czy wyobraża Pan sobie remont Pana mieszkania wykonany wyłącznie na podstawie opisu tekstem przekazanego firmie remontowej? I zapada cisza.

Ciekawe dlaczego wykonawca w budowlance dostaje projekt od architekta w postaci modeli (rysunki techniczne, rzuty, wizualizacje itp.) 🙂

No to wygląda na to, że myślimy tak samo a kwestia takich czy innych doświadczeń w IT to już kwestia techniczna raczej… nie zmienia to faktu, że na wielu szkoleniach, nie tylko z negocjacji, nastawia się ludzi na walkę, jak nie znasz takich trenerów (w co wątpię) to być może zaraz tu poznasz kogoś kto wychodzi z założenia, że na rozmowę idzie się z pałką a coś takiego jak Win-Win w kontraktach nie istnieje.

Mam taka swoją, analityczną (jestem także analitykiem rynku, zajmuje się doradztwem strategicznym), teorię którą praktyka potwierdza:

Dobrze zarządzana firma ma wiedzę o swoich produktach, rynku na nie i chłonności rynku. Plan sprzedaży jest oparty na tych danych i jest realny. Wielkość sprzedaży zależy głównie od cech produktów. Kiepskie firmy nie radzą sobie z marketingiem i usiłują realizować plany sprzedaży na siłę. Wtedy zatrudnia się sztab pozbawionych skrupułów desperatów zmotywowanych groźbą zwolnienia i nazywa się ich “sprzedawcami, kupcami itp.” Aby byli skuteczni wysyła się na różnego rodzaju szkolenia z manipulacji, walki itp. i wmawia się im, że nie istnieje win-win.

Drugi rodzaj firm to firmy nie radzące sobie z zarządzaniem, małpują wszystko co się da: cudze strategie, cudze wdrożenia, cudze ceny, wszystko, w efekcie maja koszty bliskie cenom rynkowym więc w zasadzie nie mają zysku. Ci na granicy ze światem zewnętrznym (dostawy i zakupy) stawiają więc na “negocjatorów”, którzy za wszelką ceną zbijają ceny zakupu zaopatrzenia i podnoszą ceny sprzedawanych dóbr bo to jedyny sposób na dodatni wynik finansowy.

Paradoks polega na tym, że tego typu firmy nie budzą zaufania i są skazane na takie, kosztowne jednak praktyki, i spirala się nakręca.

Tak więc jest to temat o negocjacjach i ich roli w strategii firmy: jedni negocjują długoterminowe porozumienia ku obopólnym korzyściom inny wysyłają negocjatorów na wojnę.

Jako strateg i analityk modeli biznesowych powiem tak: strategie długoterminowe oparte na wiedzy i świętym spokoju są najskuteczniejsze (mało kosztowne) wymagają jednak głębokich analiz i pokory. Prowadzenie wojen jest kosztowe.

Obecny kryzys pokazuje ciekawą rzecz: firmy których pozycja na rynku to długotrwałe partnerstwa mają się dobrze, firmy wojenne przegrzały i mają kłopoty. Te drugie to np. telekomunikacja czy niestety wiele firm IT. Znakiem walczącej strategii (dużych kosztów tego procederu) jest fajny parametr: rotacja klientów. To zjawisko ma miejsce głównie tam, gdzie klient po dokonaniu transakcji (zawarciu umowy) poczuł się oszukany i za wszelka cenę szuka sposobu zmianę dostawcy. Z reguły znajduje, walczące firmy by nad tym panować angażują kosztownych prawników bu “trzymać klienta umową” a to dodatkowo podnosi koszty tu znowu spirala kosztów i droga do nikąd. Znam sytuacje gdy duży churn (rotacja klientów) jest traktowany jako bardzo zły wskaźnik jakości zarządzania i zarządu.

Oczywiście nie ma obowiązku godzenia się z tym co tu piszę i każdy broni swojej strategii. Uważam, że mamy wybór, w końcu żyjemy w wolnym kraju a decyzje menedżerskie podejmują menedżerowie a nie analitycy 🙂 (Ci niestety są oceniani za jakość rekomendacji, nic za darmo) nie ma znaczenia czy mam rację, znaczenie ma to, że są firmy o jakich pisze…

ZWROT Z INWESTYCJI

Jak Tu postrzegasz ROI? Rentowność etapów projektu, zasobów (np. analityka), czy rentowność całego projektu?

Pewien mój klient pogonił pewnego sprzedawcę z dużej niebieskiej firmy po tym jak mu ten sprzedawca po wiedział w negocjacjach: “jak Pan u mnie zamówi oprogramowanie to dam Panu 50% upust na usługi”. Na co usłyszał: “czyli od pół roku próbował Pan mnie naciągnąć? Do widzenia.”

Zwróć uwagę, że każdy dobry projekt wdrożeniowy ma trzy zasadnicze etapy:

1. analiza biznesowa (tu odpowiadamy na pytanie jak firma chce osiągnąć cele biznesowe?)

2. analiza wymagań (tu odpowiadamy na pytanie jakich funkcjonalności oczekujemy od oprogramowania, które ma nam pomóc osiągnąć cel)

3. analiza przed wdrożeniowa i wdrożenie (tu odpowiadamy na pytanie: co i jakim kosztem należy zrobić z naszym oprogramowaniem by realizowało wymienione funkcjonalności)

Są to trzy rozłączne etapy i tylko ten trzeci w całości MUSI wykonać dostawca oprogramowania. Argument w rodzaju tylko my wiemy jak wdrożyć nasz system jest prawdą ale jak się to ma do celu projektu którym dla zamawiającego jest np. skrócenie czasu dostawy? Jak się to ma do wcześniejszej analizy z której wynika, ze właśnie skrócenie czasu dostawy a nie obniżenie kosztów zaopatrzenia jest kluczem do sukcesu? Nijak.

Osobiście świadomie sugeruję swoim klientom by dostawca oprogramowana sam sobie nie określał wymagań… 🙂 bo jest prawie pewne, że zrobi to pod siebie.

Niestety nie raz byłem świadkiem “przelewania” w negocjacjach kosztów projektu pomiędzy tymi etapami a nawet coś w rodzaju “jak Pan kupi system to analiza będzie za darmo”. Taki argument świadczy wyłącznie o tym, że ktoś próbuje po prostu ugrać coś za wszelką cenę bez żadnego merytorycznego uzasadnienia i liczy na to, że druga strona nie ma pojęcia o kosztach projektów (co czasem bywa zresztą prawdą ale nie jest to dla mnie powód do wykorzystywania tego bo i tak w końcu się dowiedzą ile co kosztuje).

Tak więc w kwestii tytułu wątku: opisane w artykule sztuczki dla mnie, to nic innego jak zabawa w podchody kto tym razem jest większym bałwanem.

OPEN SOURCE

Dyskusje o open source to nie kończące się dywagacje pomiędzy twórcami, kontestatorami, zwolennikami i przeciwnikami.

Dla mnie absolutnie nie ma znaczenia sposób licencjonowania oprogramowania. Oprogramowanie to zasób, który wspiera jakiś proces w firmie. Proces ten ma jakieś określone znaczenie dla firmy zaś użyte oprogramowanie, jego dostawca itp. stanowią jakieś ryzyko dla ciągłości i jakości funkcjonowania tego procesu. Ponoszony koszt powinien być adekwatny do ryzyka przed jakim się chronimy.

Jednym ze sposobów zarządzania ryzykiem jest dzielenie tego ryzyka, pomiędzy nas i podmiot dostarczający nam oprogramowanie. Innymi słowy w dobrej umowie jeżeli coś nie zadziała to straty ponosi użytkownik i dostawca oprogramowania np. poprzez rekompensatę strat, bezpłatnie świadczoną usługę naprawy (gwarancja) itp..

O ile wiem nie jest możliwe zawieranie umów ze społecznościami open source, dostawca takiego rozwiązania może być podmiotem w takiej umowie ale nie ma praw regresu do twórcy kodu i będzie się chronił przez odpowiedzialnością inną niż za własną usługę.

Sam używam oprogramowania open source i komercyjnego. Większość stron internetowych pracuje u mnie na bazie wolnego oprogramowania, system operacyjny mojego notebooka, oprogramowanie takie jak system CASE, którego używam do prowadzenia analiz, czy też to którego używam do zarządzania rachunkami to komercyjne oprogramowanie na które mam umowę z dostawcą te zaś zobowiązuje się w nim do rozwoju tego oprogramowania, wsparcia technicznego i mam prawo roszczeń w przypadku zaniedbań dostawcy.

Moje ryzyko z tytułu używania wolnego oprogramowania do obsługi serwisów WWW jest znikome, funkcjonalność jest ta sama co kilka lat temu, jak coś sam zepsuję to w ciągu 15 minut odtwarzam wersje działająca z kopii zapasowej. Nie dopuszczam jednak tego przy rachunkach i tam gdzie ja się przed klientem do czegoś zobowiązuję bo on ma prawo do roszczeń w stosunku do mnie jak coś nawali.

Ostatnio moja strona WWW, której używam do działań z pogranicza CRM i zarządzania projektami zaczęła stwarzać problemy i nie mam do kogo się zwrócić pomoc (pewna społeczność już nie rozwija tego oprogramowania, pewnie skończyli studia i każdy ma swoją pracę). Dlatego następny system CRM u mnie będzie komercyjnym oprogramowanie.

Mam wrażenie, że cześć orędowników bezpłatnego oprogramowania to ludzie wyznający zasadę “nie będą płacić za jakieś oprogramowanie skoro sobie leży i można je wsiąść”, “należy tworzyć wspólne dobro i nie brać za nie pieniędzy”, inne. Jest to moim zdaniem mylny pogląd, mam wrażenie że wręcz anarchistyczny.

Oprogramowanie to taki sam twór jak zdjęcie, książka, odkurzacz czy luksusowy samochód. Do czegoś nam służy, zaspokaja jakieś potrzeby. To użytkownik ocenia jakie to potrzeby i jaką one mają wartość dla niego (lub jakie stwarzają ryzyko).

Dlatego wybór oprogramowania nie ma w moich oczach nic wspólnego z poglądami a jedynie z dorosłością wyboru.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).