Czasami metafory i analogie pomagają nam spojrzeć na problem z innej strony, inaczej niż przedstawiają go dostawcy ?mega kubełków? z klockami. Swego czasu w dyskusji o wdrożeniach gotowych parametryzowanych systemów pojawiła się analogia do klocków LEGO w celu wskazania korzyści z gotowych modułowych i parametryzowanych rozwiązań. Problemem w rozmowie okazało się to czy faktycznie duży wielomodułowy system jest tańszy, szybszy we wdrożeniu i lepszy od rozwiązań dedykowanych: głos na forum.

Widzę to tak — kupiłem dziecku Lego w pudełku i gotowy CRM do firmy, chcę coś zbudować, np.: domek z garażem i firmę na większych obrotach. Nadal mam stertę problemów do przeanalizowania, np: jak domek ma wyglądać i z czego się ma składać, żeby mi klocków starczyło; jak dostosować CRM i firmę, żeby zrealizować swoje konkretne wymagania.

Lego standardowo można kupić w postaci gotowego zestawu klocków np. “lokomotywa” jednak w pudełku są klocki, które pozwalają na zbudowanie w zasadzie konkretnej lokomotywy bo inne pojazdy wymagały by większego wyboru klocków. Można nabyć całe wiaderko klocków, które pozwala na znacznie większą swobodę, tu zbudujemy inną wymarzona lokomotywę jednak wiele klocków – za które zapłaciliśmy kupując “megakubełek” – pozostanie w wiaderku niewykorzystana. Jeżeli stać nas na permanentną zabawę w tworzenie coraz to nowych innych pojazdów to nie ma problemu.

Jeżeli jednak nas na to nie stać to co? Warto rozważyć inne rozwiązanie: idziemy do kolegi (koleżanki) z podwórka, który ma taki ?mega kubełek? i po zbudowaniu z ich klocków naszej kochanej lokomotywy zabieramy ją do domu bez potrzeby posiadania całego kubła klocków niewykorzystanych. Taki kumpel z klockami to doświadczona firma programistyczna z wypracowanym zestawem komponentów i frameworków. Brakuje tu tylko analityka – inżyniera, który z nami ustali jaka lokomotywa ma powstać a programistom powie o jakie klocki chodzi.

Czasami metafory i analogie pomagają nam spojrzeć na problem z innej strony, inaczej niż przedstawiają go dostawcy ?mega kubełków? z klockami.

Od pewnego czasu fotografuje, mój sprzęt ewoluuje i rozrasta się, moje potrzeby na jego przenoszenie także. Na początku miałem aparat i jeden obiektyw, mieścił się w niedużej torbie. Kolejny ruchem była większa torba z przegródkami na rzepy pozwalająca dopasować przegródki do mojego sprzętu. Obecnie wymagania fotografii reporterskiej wymuszają na mnie kolejny etap: skomponowanie zestawu kieszeni i pokrowców tak, by mieć swobodę natychmiastowego użycia każdego z elementów mojego zestawu sprzętu fotograficznego. Tu niestety już nie uda się (i nie ma sensu) szukania uniwersalnej torby bo postępująca ich uniwersalizacja powoduje niepotrzebny rozrost.

Teraz wybiorę się do sklepu, wybiorę małą systemową torbę jako bazę i dobiorę kilka kieszeni na obiektywy na rzepy. Nie ma sensu kupować całego ich zestawu by użyć tylko kilku. Na początek zaś muszę utworzyć i precyzyjnie przeanalizować scenariusze użycia mojego sprzętu tak by wybrać optymalny zestaw kieszeni na sprzęt i akcesoria czyli przeprowadzić porządną analizę wymagań.

Tak więc firmy u progu rozwoju mogą i nie raz powinny nabywać raczej rozwiazania standardowe, których jest duża podaż i wybór. W miarę rozwoju firmy i nabierania specjalizacji na rynku, standardowe rozwiązania zaczynają przeszkadzać a koszty ich dopasowania niszczą rentowność takich inwestycji. Panuje przekonanie, że jeżeli produkt wymaga przeróbki ok. 30% funkcjonalności koszty tych przeróbek przekraczają stworzenie nowego systemu. Jednak jeśli planujemy korzystanie z takiego produktu w dłuższym okresie czasu i planujemy jego uaktualnienia od dostawcy to każda, nawet niewielka przeróbka podczas wdrożenia pozbawi nas możliwości łatwej i bez-kosztowej aktualizacji w przyszłości.

Zwracam uwagę, że ?nowy system? to nie oprogramowanie pisane ?od zera? ale tworzenie go z komponentów (bo czym innym są szkielety programowe czyli tak zwane Frameworki). Warto taki scenariusz rozważyć zawsze jeśli koszt oprogramowania ERP wraz z modyfikacjami to kwota już nawet rzędu 200-300 tysięcy. Jeżeli to mniejsze projekty z grupy CRM, rozbudowanych stron WWW i podobnych, tym progiem są nie raz kwoty o rząd mniejsze. W takich przypadkach zawsze warto po prostu wysłać zapytania ofertowe także do firm programistycznych a nie tylko do dostawców gotowego oprogramowania.

Jednym z argumentów są badania ankietowe pokazujące, że koszty ukryte w projektach wdrożenia gotowych systemów stanowią średnio 70% a w projektach developerskich tylko 30%. Innymi słowy, jeżeli całkowity koszt projektu po jego zakończaniu to 100 jednostek, to pierwotna oferta i budżet na system gotowy opiewała na 30 jednostek a na dedykowany 70 (dane z materiałów konferencyjnych firmy IBM).

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).