Wymagania na coś dużego – w czym problem?

Katgoria: WIADOMOŚCI / Utworzono: 26 marzec 2012

Wymagania na coś dużego – w czym problem?

Zapytania o produkt mający wdzięczną nazwę „Analiza potrzeb i opracowanie wymagań na system ERP” (w miejsce ERP można wstawić dowolny innych skrót w rodzaju CRM, BI, SCM, workflow itp..) najczęściej rodzą oczekiwania w postaci „lista wymagań funkcjonalnych i poza-funkcjonalnych”.

REKLAMA

Lista taka jest znana z inżynierii oprogramowania i jest powszechnie stosowana do projektowania i wytwarzania tego oprogramowania. Ale jest pewien problem gdy celem jest zakup gotowego oprogramowania, bo w końcu gotowego nie projektujemy, bo podobno ma być tańsze niż pisanie od początku.

Niedawno napisałem:

Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu, bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą Martina Fowlera: grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każdą przyszłą partią.

Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć dla użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną „obsłużone”. (Czym jest to co modelujesz w oprogramowaniu? Model dziedziny systemu jako wymaganie.).

Wydawało by się, że wszystko jasne. Ale? Popatrzmy na poniższy diagram:

Czas trwania analizy i specyfikowania (pracochłonność, więc także koszt) rośnie liniowo w takt kolejnych dni pracy nad analizą. W miarę powstawania kolejnych udokumentowanych szczegółów, ryzyko, że wybierzemy zły (niepasujący nam) produkt maleje. Jednak ryzyko jest, jak widać, funkcją nieliniową (jest to prawdopodobieństwo złego wyboru, które nigdy nie dojdzie do zera) zaś wzrost kosztów jest liniowy. W efekcie od pewnego momentu, dość bliskiego początkowi tej pracy, koszty takiej analizy rosną szybciej niż korzyści z jej szczegółowości. Tak więc w typowym projekcie w zasadzie skazani jesteśmy na kompromis i uznanie pewnego (nie tak małego) ryzyka, że jednak wybór będzie zły (mimo, że produkt spełni skończoną listę wymagań).

Przekroczenie pewnej umownej granicy „rozsądku” – analizy i spisywania szczegółów – popycha taki projekt w kierunku projektowania nowego systemu, a miało być tanio, bo chcemy kupić system gotowy. Krótkie wyliczenie: typowy system ERPII to ok. 6 tys. cech. Samo ich spisanie ze zrozumieniem to:

opis jednego wymagania to 500 znaków (średni wynik z kilku znanych mi dokumentów)
jedna strona maszynopisu to 1800 znaków
6 tys cech to 6000 x 500 znaków / 1800 strona = 1667 stron tekstu •z rozmów z wykonawcami analitykami wiem, że efektywnie piszą ok. 7 merytorycznych stron dziennie (to dość optymistyczne założenie)
w efekcie 1667 stron / 7 dziennie = 238 dni roboczych, stawka bardzo taniego konsultanta to np. 1000zł/dzień, otrzymujemy: 238 tys. złotych i ponad roczny projekt. •Jeżeli uznamy, że jednak specyfikowanie jest poprzedzane analizą, dla uproszczenia (znowu bardzo optymistycznie) przyjmę, trwająca tyle co spisywanie jej wyników, mamy dwa lata pracy i pół miliona złotych.
Skrócenie tego poprzez zatrudnienie nie jednego a np. czterech analityków podniesie koszty o ok. 30% (znam takich, którzy by tu dodali 50% i pewnie mają nie raz rację) na koordynację, kontrolę zgodności, poprawki wynikające z „uspójniania pracy różnych autorów”.

Urealnienie tych wyliczeń (choćby stawki analityków) wywinduje ten budżet na kwotę znacznie ponad milion złotych! Na to sobie mało kto sobie pozwoli. W większości przypadków nie jest robiona tak długo trwająca analiza i za nie takie pieniądze. Zaryzykuje tezę, że – obserwując statystyki projektów IT – nie ma to, takie podejście, żadnego sensu. Tak więc tak opracowane specyfikacje, są jednak upraszczane z uwagi na koszty, są z zasady niekompletne!

Teraz przyszła pora na mojego serdecznego przyjaciela, który zjadł zęby na korporacyjnym rynku IT (wybaczycie mi Państwo, że dane jego zachowam dla siebie). Oto co mi niedawno powiedział podczas podobnej dyskusji:

Nawet przy kupnie konkretnej kiełbasy kryteriów wyboru sklepu może być wiele i zakładamy, że ktoś ma czas/pieniądze aby je wszytkie zastosować, by podjąć decyzję. Przy kupnie samochodu czy komórki ilość funkcji, które trzeba porównać jest tak duża, że porównywanie to już spora praca. Nie zawsze ma się zasoby, aby ją wykonać. Nabywca z dobrym działem zakupów ma schematy oceny wielokryterialnej skomplikowanych towarów i usług, Ale kto poświęci 2 godziny na decyzję, jaki kupić sobie długopis? Pewnie nikt, ale na podjęcie decyzji kupna komórki 2 godziny to stanowczo za mało, choć błędna decyzja jest kosztowna lub wiąże nas na 2 lata z modelem, który nie spełnia oczekiwań.

Producenci różnych rzeczy zdają sobie sprawę, że koszty podjęcia właściwej decyzji przy skomplikowanych produktach są spore i ludzie będą podejmować decyzje błędne, to pozwala działać na rynku firmom, które w przeciwnym wypadku by upadły.

I jak teraz wyglądają w Państwa oczach zakupy i wdrożenia dużych gotowych systemów? Czy to znaczy, że kupno gotowego systemu nigdy nie ma sensu? Ależ ma ale…

Gotowe oprogramowanie jest adresowane z zasady do wielu różnych odbiorów, skazane jest więc na znaczny nadmiar funkcjonalności ”na zapas” (popatrzmy z jakiej części cech telefonów czy pakietów biurowych korzystamy). Skoro więc potrzebujemy czegoś co ma 100 potrzebnych nam cech a wybieramy coś gotowego na rynku co ma ich 1000, ale zawiera te potrzebnych nam 100, to sama nasuwa się teza, że powyżej pewnego progu uniwersalne rozwiązanie kosztuje więcej (uwzględniając koszty decyzji) niż korzyści z cech wymaganych i zapewne nie raz warto wykonać coś „pod nasze potrzeby”. I tu pojawia się haczyk: należy te potrzeby bardzo dobrze – z minimalnym ryzykiem – opisać. Bo wszyscy wiemy jak się kończą projekty programistyczne, w których „klient nie wie czego chce”.

Jak to robić lepiej? Po pierwsze nie kupować „dużych i drogich zintegrowanych systemów” bo to duże ryzyko, kupować mniejsze, łatwiejsze do opisania, projektować i tworzyć te, które są zbyt dużym ryzykiem w przypadku złego wyboru. Jeżeli już z powodu ryzyka mamy poświęcić duży budżet na kosztowne specyfikowanie oprogramowania to sygnał, że należy je za te pieniądze po prostu zaprojektować i wykonać.

Niestety nie ma prostej odpowiedzi na pytanie jak to robić „dobrze”. Chyba, że będzie to propozycja następującego procesu: 1.analiza biznesowa, 2.zdefiniowanie celu, 3.zaprojektowanie architektury systemu (to jako system należy rozumieć organizację wraz z wspierająca ją informatyką), tu zmierzamy w kierunku tak zwanej architektury korporacyjnej, 4.zidentyfikowanie oczekiwanych od oprogramowania usług (wymagania), podzielić je na odrębne ale spójne obszary dziedzinowe, 5.dla każdego obszaru dziedzinowego opracować wymagania na oprogramowanie, 6.wybrać rozwiązania.

Zwracam uwagę na drobny szczegół: wyboru produktu i jego dostawcy dokonujemy na końcu, nigdy na początku! A kto i dlaczego nas przekonuje, że należy najpierw kupić a potem analizować?

Źródło: www.it-consulting.pl
Autor: Jarosław Żeliński

Najnowsze wiadomości

Customer-specific AI: dlaczego w 2026 roku to ona przesądza o realnym wpływie AI na biznes

W 2026 roku sztuczna inteligencja przestaje być ciekawostką technologiczną, a zaczyna być rozliczana z realnego wpływu na biznes. Organizacje oczekują dziś decyzji, którym można zaufać, procesów działających przewidywalnie oraz doświadczeń klientów, które są spójne w skali. W tym kontekście coraz większe znaczenie zyskuje customer-specific AI - podejście, w którym inteligencja jest osadzona w danych, procesach i regułach konkretnej firmy, a nie oparta na generycznych, uśrednionych modelach.

Czytaj całość

PROMAG S.A. rozpoczyna wdrożenie systemu ERP IFS Cloud we współpracy z L-Systems

PROMAG S.A., lider w obszarze intralogistyki, rozpoczął wdrożenie systemu ERP IFS Cloud, który ma wesprzeć dalszy rozwój firmy oraz integrację kluczowych procesów biznesowych. Projekt realizowany jest we współpracy z firmą L-Systems i obejmuje m.in. obszary finansów, produkcji, logistyki, projektów oraz serwisu, odpowiadając na rosnącą skalę i złożoność realizowanych przedsięwzięć.

Czytaj całość

SkyAlyne stawia na IFS dla utrzymania floty RCAF

SkyAlyne, główny wykonawca programu Future Aircrew Training (FAcT), wybrał IFS Cloud for Aviation Maintenance jako cyfrową platformę do obsługi technicznej lotnictwa i zarządzania majątkiem. Wdrożenie ma zapewnić wgląd w czasie rzeczywistym w utrzymanie floty, zasoby i zgodność, ograniczyć przestoje oraz zwiększyć dostępność samolotów szkoleniowych RCAF w skali całego kraju. To ważny krok w modernizacji kanadyjskiego systemu szkolenia załóg lotniczych.

Czytaj całość

Wykorzystanie AI w firmach rośnie, ale wolniej, niż oczekiwano. Towarzyszy temu sporo rozczarowań

Wykorzystanie sztucznej inteligencji w firmach rośnie, ale tempo realnych wdrożeń pozostaje znacznie wolniejsze od wcześniejszych oczekiwań rynku. Dane pokazują, że z rozwiązań AI korzysta dziś wciąż niewiele przedsiębiorstw, a menedżerowie coraz częściej wskazują na bariery regulacyjne, koszty oraz brak powtarzalnych efektów biznesowych. W praktyce technologia jest testowana głównie w wybranych obszarach, a kluczowe decyzje nadal pozostają po stronie człowieka. Również w firmach, które wdrożyły AI, nierzadko towarzyszą temu rozczarowania.

Czytaj całość

Europejski przemysł cyfryzuje się zbyt wolno – ERP, chmura i AI stają się koniecznością

Europejski przemysł średniej wielkości wie, że cyfryzacja jest koniecznością, ale wciąż nie nadąża za tempem zmian. Ponad 60% firm ocenia swoje postępy w transformacji cyfrowej jako zbyt wolne, mimo rosnącej presji konkurencyjnej, regulacyjnej i kosztowej. Raport Forterro pokazuje wyraźną lukę między świadomością potrzeby inwestycji w chmurę, ERP i AI a realną zdolnością do ich wdrożenia – ograniczaną przez braki kompetencyjne, budżety i gotowość organizacyjną.

Czytaj całość

RAPORT ERP

Katalog rozwiązań IT

Katalog firm

Najnowsze artykuły

5 pułapek zarządzania zmianą, które mogą wykoleić transformację cyfrową i wdrożenie ERP

Dlaczego jedne wdrożenia ERP dowożą korzyści, a inne kończą się frustracją, obejściami w Excelu i spadkiem zaufania do systemu? Najczęściej decyduje nie technologia, lecz to, jak organizacja prowadzi zmianę: czy liderzy biorą odpowiedzialność za decyzje czy tempo jest dopasowane do zdolności absorpcji oraz czy ludzie dostają klarowność ról i realne kompetencje. Do tego dochodzi pytanie: co po go-live - stabilizacja czy chaos w firmie? Poniżej znajdziesz 5 pułapek, które najczęściej wykolejają transformację i praktyczne sposoby, jak im zapobiec.

Czytaj całość

SAP vs Oracle vs Microsoft: jak naprawdę wygląda chmura i sztuczna inteligencja w ERP

Wybór systemu ERP w erze chmury i sztucznej inteligencji to decyzja, która determinuje sposób działania organizacji na lata- a często także jej zdolność do skalowania, adaptacji i realnej transformacji cyfrowej. SAP, Oracle i Microsoft oferują dziś rozwiązania, które na pierwszy rzut oka wyglądają podobnie, lecz w praktyce reprezentują zupełnie odmienne podejścia do chmury, AI i zarządzania zmianą. Ten artykuł pokazuje, gdzie kończą się deklaracje, a zaczynają realne konsekwencje biznesowe wyboru ERP.

Czytaj całość

Transformacja cyfrowa z perspektywy CFO: 5 rzeczy, które przesądzają o sukcesie (albo o kosztownej porażce)

Transformacja cyfrowa w finansach często zaczyna się od pytania o ERP, ale w praktyce rzadko sprowadza się wyłącznie do wyboru systemu. Dla CFO kluczowe jest nie tylko „czy robimy pełną wymianę ERP”, lecz także jak policzyć ryzyko operacyjne po uruchomieniu, ocenić wpływ modelu chmurowego na koszty OPEX oraz utrzymać audytowalność i kontrolę wewnętrzną w nowym modelu działania firmy.

Czytaj całość

Agentic AI rewolucjonizuje HR i doświadczenia pracowników

Agentic AI zmienia HR: zamiast odpowiadać na pytania, samodzielnie realizuje zadania, koordynuje procesy i podejmuje decyzje zgodnie z polityką firmy. To przełom porównywalny z transformacją CRM – teraz dotyczy doświadczenia pracownika. Zyskują HR managerowie, CIO i CEO: mniej operacji, więcej strategii. W artykule wyjaśniamy, jak ta technologia redefiniuje rolę HR i daje organizacjom przewagę, której nie da się łatwo nadrobić.

Czytaj całość

Composable ERP: Przewodnik po nowoczesnej architekturze biznesowej

Czy Twój system ERP nadąża za tempem zmian rynkowych, czy stał się cyfrową kotwicą hamującą rozwój? W dobie nieciągłości biznesowej tradycyjne monolity ustępują miejsca elastycznej architekturze Composable ERP. To rewolucyjne podejście pozwala budować środowisko IT z niezależnych modułów (PBC) niczym z klocków, zapewniając zwinność nieosiągalną dla systemów z przeszłości. W tym raporcie odkryjesz, jak uniknąć pułapki długu technologicznego, poznasz strategie liderów rynku (od SAP po MACH Alliance) i wyciągniesz lekcje z kosztownych błędów gigantów takich jak Ulta Beauty. To Twój strategiczny przewodnik po transformacji z cyfrowego "betonu" w adaptacyjną "plastelinę".

Czytaj całość