24 lutego, 2017

Postawmy wóz przed koniem


„Chodzi o to, że poszukiwanie decyzji optymalnej będzie bezwartościowe, jeżeli postawienie problemu nie zostało zoptymalizowane. Jest zrozumiałe, że straty spowodowane błędami tego rodzaju będą tym większe, im większy system podlega optymalizacji.” (M.Mazur)
W poprzednim wpisie  ("Coś z niczego") pozwoliłem sobie trochę pożartować. Mam cichą nadzieję, że było to zauważone. Z góry przepraszam tych, którzy tego  nie dostrzegli i poczuli się dotknięci.

Choć cały post był intencjonalnie napisany w konwencji a rebours i z przymrużeniem oka, jeden z jego fragmentów był jak najbardziej na poważnie. Chodzi a „analizę wsteczną” i rolę „syntetyka biznesowo-systemowego”. Wiem, brzmi to jeszcze głupiej , ale cierpliwości.

Kilka lat temu miałem okazję pracować dla  firmy produkującej jeden z podstawowych produktów pierwszej potrzeby („każdy Polak kocha C2H5OH”).

Firma stanęła w obliczu wymiany systemu ERP oraz przebudowy technicznej infrastruktury IT ("waliła" się serwerownia).
Zgodnie  ze sztuką,  opracowałem listę wymagań funkcjonalnych i poza funkcjonalnych (ok. 3000+), dodałem parę prostych ograniczeń architektonicznych i technologicznych, wszystko potraktowałem metodą Kano, spakowałem do  exela, wsadziłem w RFP i rozesłałem do czołowych polskich dostawców tychże rozwiązań ERP. Trochę dla zabawy dodałem „nice to have” wymóg wsparcia dla referencyjnego modelu SCOR®.

Po pewnym czasie spłynęły oferty -  12 sztuk. Po odrzuceniu błędnych formalnie, na placu boju pozostało 6.
Jaki obraz roztoczył się przed komisją przetargową, czyli przede mną?
Wszystkie lepiej lub gorzej spełniały wymagania funkcjonalne. Koszty (te ujawnione) wszystkich ofert przekraczały 1 mln. PLN (te najdroższe oscylowały bliżej 2.), czyli nawet niedużo, ale i takie sumy nie chadzają piechotą.
Żadne autorskie polskie rozwiązanie (a były to produkty z górnej polskiej półki) nie spełniało prostego technologicznego wymogu – nie było osadzone w jakimkolwiek serwerze aplikacji (sic!). Były to bardziej lub mniej „modułowe” mastodonty robiące wszystko co trzeba, ale zabetonowane dla użytkownika - bez dedykowanych usług dostawcy ani rusz. Tylko on wiedział co kryje się „pod maską” i dlaczego tak drogo kosztują jego usługi rozwojowe.
Wszystkie rozwiązania bazujące na zachodnich produktach działały w jakimś serwerze aplikacyjnym (kontenerze). Wszystkie one za frico umożliwiały grzebanie w środku ( w pewnym zakresie), oczywiście po stosownym przeszkoleniu, z  uwzględnieniem i poszanowaniem praw autorskich.
Żadne rozwiązanie nie zapewniało (jeszcze) wsparcia dla SCOR®.

W trakcie indywidualnych negocjacji wszystkim uczestnikom przetargu proponowałem, że gdy już wybiorę i wdrożę ich rozwiązanie, firma zlecająca ma zostać ich partnerem / przedstawicielem / agentem z zamiarem oferowania usług wdrożeniowych na ich rynku, argumentując, że skoro mamy wydać ok. 2+ bańki, chcielibyśmy trochę się odkuć. Jest to klasyczny tzw. offset. Oczywiście wszyscy spoglądali na mnie jak na idiotę i tylko przez grzeczność nie parskali śmiechem.

Wrrrrrróć. Prawie wszyscy. Jedna z firm, oferująca rozwiązanie zagraniczne, odparła: „OK, pomysł bardzo nam się podoba, bo mamy problemy z zaspokojeniem popytu na usługi wdrożeniowe”. No to jestem w domu. Nie dość , że firma dostarcza prawie dokładnie to co chcę, jeszcze daje zarobić.
Ale z ust sympatycznej Pani Przedstawicielki Handlowej padła dodatkowa propozycja, która z kolei  zaokrągliła moje oczy: oferują wdrożenie o połowę taniej jeśli zgodzimy się wdrożyć tzw. prekonfigurowany wariant systemu, a wdrożenie ma trwać o połowę krócej niźli w wariancie tradycyjny, bo bez analizy i  bez adaptacji (choć z parametryzacją). Gdzie tkwi haczyk? – myślę sobie. Był jeden wymóg : to sposób działania firmy należy dostosować do sposobu funkcjonowania systemu (sic!), co i tak ma zawsze miejsce również przy klasycznym podejściu, a o czym zbyt głośno na etapie ofertowania dostawcy raczej nie wspominają.

Wstrząśnięty choć niezmieszany słuchałem dalej.

Dostawca miał bardzo bogate doświadczenie we wdrożeniach w branży reprezentowanej przez mojego pracodawcę. Na podstawie tychże doświadczeń stwierdził, że większość firm z branży działa bardzo podobnie, wręcz identycznie. Po co zatem za każdym razem wymyślać koło raz jeszcze skoro wystarczy je użyć. Opracował „standardową” powtarzalną  architekturę procesów i model wdrożenia. Dowodem słuszności jego podejścia miały służyć przypadki klientów, którzy dali się przekonać -  funkcjonują i mają się dobrze, co było do sprawdzenia (wizyty referencyjne w pakiecie).  Firma policzyła i uznała, iż działając tradycyjnie i generując większe obroty w ramach jednego "dużego" wdrożenia globalnie wcale więcej nie zarabia (czas i  zasoby zaangażowane w projekt kosztują, a konkurencja nie śpi). Ich zysk netto wzrastał w przypadku większej ilości krótszych i tańszych wdrożeń prekonfigurowanych. Jako, że już wtedy trochę liznąłem rachunek przerobowy, skumałem od razu, o co chodzi. Co prawda marzył mi się jeszcze SCOR®, ale to co usłyszałem i tak wprawiło mnie w osłupienie. Mój szok wywołało jeszcze coś innego – na polskim rynku ktoś odważył się myśleć  "pod prąd". Wtedy w branży ERP obowiązywała zasada: wdrożenie ma być długie i drogie,  a usługi rozwojowe świadczone tylko przez dostawcę. 
Jeśli ktoś czytał mój poprzedni wpis ("Coś z niczego"), od razu załapał, że wyglądało  to na klasyczny przypadek "analizy wstecznej", czyli poszukiwanie uzasadnienia dla wdrożenia określonego rozwiązania „z puszki” (w świecie "materialmym" nazywa się to podejściem COTS). Zadanie dla analityka, czyli dla mnie,  zatem brzmiało: dostosuj organizację do systemu IT.
Bardziej ogólnie zadanie można sformułować następująco:

dostosuj przedsiębiorstwo do otoczenia, w którym oferta prekonfigurowanych rozwiązań IT jest integralną częścią tegoż otoczenia.

Przedsięwzięcie oczywiście upadło. O ile właścicielowi było wszystko jedno, Prezes lekko się obruszył: nie będzie go jakaś firma informatyczna pouczać , jak ma działać „jego” firma. Albo robią po bożemu i „uwzględniają specyfikę przedsiębiorstwa”, albo fora ze dwora. No to ze dwora.

Dzisiaj Prezes (słuch o nim zaginął) miałby jeszcze większy zgryz. Produkty czołowych dostawców rozwiązań ERP nie dość, że standardowo stosują modele referencyjne, to jeszcze z podziałem na branże, modele operacyjne i parę innych cech przedsiębiorstwa. Już po odejściu z wyżej opisywanej firmy zetknąłem się z jednym z takich produktów, w którym przed wdrożeniem dokonuje się automatycznej prekonfiguracji: na diagramie wybiera się model procesów SCOR® dla zadanej branży i typu przedsiębiorstwa, robi się „click”, coś miga, prycha, kicha i prekonfiguracja zakończona. Potem trzeba jeszcze zadać parę tuzinów parametrów i po zabawie. Można zacząć wdrażać, czyli zmieniać firmę.  Oby tylko prezes (i załoga) dał się przekonać.

- A gdzie inżynieria wymagań, gdzie analitycy? – zapyta ktoś z troską.

-  Nie ma, ale są za to syntetycy!

Wasz,

M.


4 komentarze:

  1. Opracowanie 3000+ wymagań nigdy nie miało sensu :) bo tym się nie da zarządzać, do końca projektu dociera tylko część, koszt ich opracowania bywa monstrualny...

    Tu "inne" podejście:
    http://www.computerworld.pl/news/372047/Od.czego.zaczac.wdrozenie.html

    OdpowiedzUsuń
    Odpowiedzi
    1. Oczywiście, że nie miałoby sensu, gdybym miał to robić „ręcznie” od zera. Poszedłem na łatwiznę - zaopatrzyłem się w gotowce z portalu TEC (https://www3.technologyevaluation.com). Koszty nie były aż tak monstrualne. Założyłem (czy słusznie , to inna sprawa i temat na odrębną dyskusję), że „moja” fabryka nie jest jakimś unikalnym w skali wszechświata przedsiębiorstwem i ludzkość (TEC), nabrawszy trochę doświadczeń praktycznych, jest w stanie wyobrazić sobie, jak powinna funkcjonować i jakie cechy funkcjonalne (features) powinien mieć system do jej zarządzania. Gdyby miało być inaczej, to znaczy gdyby „specyfika przedsiębiorstwa” czyniła zeń jakieś curiosum, to należałoby najpierw sprawdzić czy zarząd/ właściciel wie, co robi.

      Usuń
  2. dlatego właśnie zdrowe podejście to "tu poprosimy jak wszędzie a tu mamy swoje 10 wymagań"... :) .. i wtedy wymagania mają 10 stron a nie 1000 :D

    OdpowiedzUsuń
    Odpowiedzi
    1. „Tekstowa” część RFP liczył tylko kilkanaście stron. Wymagania funkcjonalne i poza funkcjonalne dostałem w Excelu (3000+ wierszy) elegancko pogrupowane tematycznie i można je było obrabiać „maszynowo” – filtrować , sortować, agregować, rangować itp. W sumie obróbka była łatwiejsza niż 100 stron worda. Można do tego było również użyć specjalnej aplikacji, ale kierownictwo firmy trochę „przyoszczędziło”.

      Usuń