Niedawno prowadziłem krótką ale ciekawą dyskusje na temat podejścia do oferowania oprogramowania ERP, wdrożeń, ich dokumentowania i zapisywania wymagań. Osoba, z którą dyskutowałem to były konsultant dostawcy oprogramowania ERP światowego lidera w tej branży. Rozmowa potwierdziła jedną rzecz: celem dostawcy gotowego systemu ERP jest wdrożyć go bez żadnych modyfikacji bo (jej koszty) zjadają marżę dostawcy. Celem kupującego oprogramowanie ERP, jest wsparcie swoich procesów biznesowych a nie kopia cudzych. To dwa sprzeczne interesy. Silna firma wymusi na dostawcy ERP zmiany, słaba nie raz poddaje się wierząc tezom dostawcy, że nowy system uporządkuje stan ich organizacji i da przewagę nad konkurencją. Kto tu ma rację?

Drugie pytanie: Po co wykorzystywać np. notację formalną UML czy BPMN przy wdrożeniach gotowego oprogramowania? Po pierwsze po to by dostawca mógł sprawdzić czy oprogramowanie, które oferuje przetwarza takie dane i tak jak chce tego kupujący. Po drugie jeżeli tylko należy dodać brakujące funkcjonalności to trzeba je najpierw zaprojektować a potem zaimplementować. Niestety obserwuje, że to właśnie dostawcy gotowego oprogramowania łamią wszelkie reguły tego procesu: pomijają etap projektowania nowych elementów systemu, często pracują ?na żywioł? ? wpada analityk dostawcy ERP i ?coś robi? od razu ?w systemie?. Potem jest tylko lawina błędów?

Wróćmy więc do rozmowy:

[Konsultant znanego na rynku międzynarodowym systemu ERP. Wiele lat pracowałam jako konsultant księgowy przy wdrożeniach systemów ERP, teraz pracuje jako administrator modułowy. W obszarze moich zainteresowań jest głównie procesowe ujecie przedsiębiorstwa, ale również analizy przedwrożeniowe oraz koncepcje wdrożeniowe. Chciałabym Pana zapytać, jak w praktyce sprawdza sie dokumentacja UML na potrzeby wdrożeń? Z tego co zaobserwowałam, a także z rozmów, dyskusji doszłam do wniosku, że UML jest narzędziem pracochłonnym, czasochłonnym, za mało „przeźroczystym”.

[Jarosław Żeliński] UML to narzędzie formalne (notacja), wymaga więc pewnej wiedzy teoretycznej (podobnie jak programowanie z użyciem jakiegokolwiek języka programowania). Pracochłonność? Model UML (np. diagram klas) jest (zależnie od szacunków) wielokrotnie mniej pracochłonny w wykonaniu niż odpowiadający mu kod, przekłada się to także na testowanie kodu i oceny kosztu danego rozwiązania. Jednoznaczne opisanie np. formatu danych opisowo (?prozą?) jest praktycznie niemożliwe. Tabele są znacznie bardziej pracochłonne niż diagram klas i maszyny stanów im odpowiadające.

[Konsultant] UML moim zdaniem nie wspomaga wdrożeń, aby taka dokumentacja była wartościowa musi być aktualizowana.

[JŻ] UML to nie jest narzędzie do wdrożeń gotowych systemów ERP, to jakieś nieporozumienie, UML to narzędzie projektowania oprogramowania, zaś w przypadku gotowych ERP ma sens jedynie do modelowania obiektów biznesowych i interfejsów na etapie specyfikowania wymagań bo obiekty takie (np. faktura, zlecenie załadunku itp.) są przetwarzane w systemach ERP (dokumenty itp.).

[Konsultant] Pan wie ile to zabiera czasu.

[JŻ] Znacznie mniej niż testowanie prototypów na żywym kodzie.

[Konsultant] Specjaliści z branży źle sie wypowiadali o UML twierdząc, że jest bardziej narzędziem akademickim, świetnie uczące filozofii programowania, natomiast zupełnie niepraktyczne.

[JŻ] Obawiam się, że nigdy nie korzystali z dokumentacji formalnej, korzystali ze źle wykonanej (w większość jaką widuję) lub nie potrafili sami jej wykonać w UML. Prawdopodobnie krytykowali coś czego nie używali, jak przekazuję dokumentacje z użyciem UML to programiści klaszczą z radości, zaś na widok wymagań w postaci prozy od razu dodają 40% zapasu na ryzyko …

[Konsultant] A Pan korzysta z UML’a. Jak do tego podchodzą klienci? Nie jest to prosta notacja i pewnie nie do końca zrozumiała dla każdego. Jakie są Pana spostrzeżenia w tym temacie?

[JŻ] UML to narzędzie analityczne i prototypowe, klientom nie pokazuję kodu programu i diagramów UML (po co??). Czy tłumacz na chiński daje swoim klientom tekst tłumaczenia do zatwierdzania? Nie – daje go chińczykom do czytania. Jest wiele nieporozumień wokół UML i BPMN. Krytykują go chyba tylko Ci, którzy nie znają i nie potrafią użyć. Podam taki przykład: wymagania w postaci opisu i diagramów UML są realizowane przez programistów w zasadzie z bardzo małym ryzykiem, wyceny kosztów implementacji nie mylą się bardziej niż 10%, testowanie przypadków użycia na diagramach jest nawet 10 krotnie tańsze niż kodowanie i testowanie prototypów.

Typowe błędy jakie spotykam:

– złe modele (nie spełniające zasad notacji, błędne projekty – w zasadzie nieprzydatne obrazki) faktycznie nikomu nie pomagają (a wiele jest niestety złych, podobnie modele procesów, wiele z nich to złe modele pozbawione zasad pragmatyki)

– stosowanie UML do gotowych systemów ERP jest nieporozumieniem za wyjątkiem dokumentowania danych oraz nowych funkcjonalności

– nie da się wykonać w postaci opisu słownego skutecznego (jednoznacznego) opisu dedykowanego systemu podobnie (lub jakiejkolwiek dedykowanej części gotowego) jak nie da się tą metodą opisać projektu biurowca – robi sie rysunki techniczne, których nie rozumie mieszkaniec tego biurowca, ale te rysunki nie są dla niego, on dostaje wizualizacje (w inżynierii oprogramowania matryce ekranów – mockupy).

Z mojego doświadczenia wszelkie formalizmy (UML, BPMN, inne) krytykują:

– ci którzy ich nie rozumieją

– ci którym przeszkadzają (zbyt jednoznaczna dokumentacja pozwala ściśle rozliczyć wykonawcę, czego niektórzy nie chcą)

Dla przykładu. Większość ludzi nie lubi geometrii ale też nie potrafią oni niczego narysować tylko z pomocą cyrkla i linijki, muszą mieć wzorniki do rysowania figur geometrycznych a na geometrię narzekają, że trudna i teoretyczna. Geometrie zna bardzo dobrze za każdy architekt, musi. Niestety zawsze będą projekty, w których mała i skończona liczba gotowych figur wzornika nie wystarcza i potrzebne są inne… ktoś to musi zrobić a naginanie wszystkiego do kilku figur na wzorniku to zły pomysł…

Po drugie: niezależnie od tego co wie analityk piszący wymagania prozą, struktura programu jest struktura formalną i kompilator jest bezwzględnym sędzią, podobnie jak potem przyszły użytkownik. To czego nie zweryfikowano na etapie projektowania i tak trzeba zrobić na etapie kodowania, tylko tu jest to o wiele droższe w przypadku popełnienia błędów.

Niewątpliwie analiza i projektowanie (UML to narzędzie dokumentowania projektu i tworzenia modeli do testów) są trudne ale to tak jak z modelami samolotów w tunelu aerodynamicznym: nikt przy zdrowych zmysłach nie testuje wszystkiego na gotowych samolotach tylko na modelach bo to po prostu taniej (i bezpieczniej).

Zapewniam Panią, że tam gdzie płaci się „za dzieło” stała kwotę coraz częściej modeluje się i projektuje na papierze np. w UML, a potem dopiero koduje.

[Konsultant] Do tego miejsca wszystko jest dla mnie piękne, ale znając życie, reszta już nie jest taka piękna. Powstaje prototyp i trzeba go przetestować. Jakoś nie wyobrażam sobie, aby nawet najbardziej doskonale wykonana dokumentacja UML pozwoliła nam pominąć ten etap. W 2004 roku przez około pół roku brałam udział we wdrażaniu systemu dedykowanego, pamiętam etap testów, jak wiele pojawiało sie błędów, pamiętam ogrom pracy jaki nagle pojawił sie na tym etapie. Gdyby wówczas miało dojść do tego jeszcze bieżąca aktualizacja dokumentacji UML to pewnie termin zamknięcia projektu przesunąłby sie daleko, daleko..

[JŻ]Mamy trzy podstawowe etapy tworzenia oprogramowania:

– analiza wymagań, jej produktem jest specyfikacja wymagań

– projektowanie

– implementacja

Testowanie dotyczy praktycznie każdego etapu:

– specyfikacje wymagań testujemy na mapach procesów i to jest proste jeżeli mamy dobry model procesów biznesowych: każdy biznesowy dokument powinien „przejść” przez model procesów, na nim wskazujemy miejsca, w których oczekujemy interakcji z oprogramowaniem (sam diagram wskaże kontekst)

– projekt (w szczególności model dziedziny) testujemy w ten sposób, że dla każdego przypadku użycia wykonujemy model sekwencji: ta metodą przetestujemy czy mamy wszystkie klasy i ich metody czyli przetestujemy całą logikę systemu

– teraz ma miejsce implementacja i tu testujemy kod każdej klasy (wewnątrz klas lub metodą testowania interfejsów, zależy od przyjętej metody, polecam poczytanie o TDD), bo one same z siebie, klasy i ich logika przetestowana na etapie projektowania, są OK a projekt jest spójny bo przeszedł testy logiki na modelach.

I literatura i programiści potwierdzają, że wykrycie błędu w projekcie jest co najmniej o rząd (albo nawet dwa, jak twierdzą niektórzy) wielkości tańsze do poprawienia niż błędy wykryte w kodzie. Dotyczy to także wprowadzania zmian.

[Konsultant] Aby Pan mnie źle nie zrozumiał, nie kwestionuje korzystania z UML’a, raczej w kontekście swoich doświadczeń nie spotkałam sie z wielka aprobatą u praktyków tego narzędzia. Dla mnie za bardzo „chce być bohaterem” w tej sztuce jakim jest wdrożenie. Za bardzo absorbuje w procesie implementacji.

[JŻ] Podtrzymuje, że na UML (a konkretnie projektowanie przed kodowaniem) narzekają Ci którzy programują „na żywioł”, analogie do procesu w budownictwie są moim zdaniem jak najbardziej na miejscu.

[Konsultant] Mogę się mylić. Pan jest pierwszym praktykiem jakiego poznałam, który korzysta z UML’a i twierdzi, że jest to dobre podejście, dlatego zapytałam Pana jak to wygląda w życiu.

[JŻ] W życiu jest tak, że moimi klientami są głownie „firmy po przejściach”, te które doświadczyły wdrożeń bez etapu projektowania. Ostatnio coraz częściej kontrakty związane z oprogramowaniem są „fixed price” (stałe zakres projektu, koszt i termin realizacji) i nie opłaci się wykonawcy „kodować i testować w nieskończoność”, kodowanie bez projektu jest w zasadzie nieprzewidywalnym procesem (dokładnie tak jak złożona budowa bez projektu). Po drugie znam innych ludzi używających UML, są to najczęściej ludzie związani z dobrymi programistami .NET, JAVA (J2EE) a także projektantami baz danych, korzystający z wzorców projektowych i generalnie obiektowych metod tworzenia oprogramowania. Praktycznie każda firma korzystająca z metodyki RUP (lub lżejszej ICONIX) używa UML w jakiejś postaci. W przypadku gotowych systemów ERP jest to (UML) doskonałe wręcz narzędzie do opisania tego jakie dane o dokumentach należy przetwarzać i jak je przetwarzać.

[Konsultant] Ale tak sobie myślę, że Pan dostarcza dokumentacje UML programistom, oni się cieszą bo maja kawal roboty juz zrobionej, ale czy później po zrobieniu prototypu ta dokumentacja jest dalej uaktualniana? Jeśli nie, to jej żywot jest skończony, właśnie ten etap powstawania systemu jest dla mnie momentem, gdy zastanawiam się nad sensem tworzenia pracochłonnej dokumentacji w notacji UML, ale mogę sie mylić.

[JŻ] Po pierwsze dobry przetestowany projekt nie jest zmieniany podczas implementacji 🙂 bo taka jest jego rola (jak dostanie Pani dobry projekt architektoniczny domku, to domek jak powstanie jest taki jak projekt i nie ma co uaktualniać), ważne by utrzymać szczegółowość projektu na właściwym poziomie, nie powinien wykraczać zbytnio poza samą logikę działania. Moim zdaniem wiele projektów UML jest przesadnie szczegółowych a w wielu miejscach są zbyt ogólne.

[Konsultant] Jednak chciałabym wrócić do gotowych systemów ERP bo takimi sie zajmuje. Wracam do artykułu. Dlaczego gloryfikuje Pan przedsiębiorstwo i jego potrzeby? Czytając Pana artykuł odnoszę wrażenie, że potrzeby przedsiębiorstwa uznaje Pan jako jedyne słuszne. A gdyby tak było, to nie byłoby szansy wdrażania gotowych systemów, a trzeba by dla każdej firmy pisać dedykowane oprogramowanie. Bez sensu.

[JŻ] Osobiście uważam, że zamawiający jest głównym źródłem wymagań ale pod tym pojęciem rozumiem sponsora projektu i to jego biznesowy cel jest nadrzędny bo to on za swoje pieniądze realizuje strategię swojej firmy. Jestem gorącym zwolennikiem tezy, że to menedżer (prezes, itp.) jest autorem celu biznesowego i to on stawia cele dostawcom systemów ERP. Jeżeli jest ryzyko, że tu jest „problem z zamawiającym” (a nie raz bywa) to konieczne należy tu umieścić usługę „doradztwa biznesowego i strategicznego”, która da uzgodnione wymagania i cele biznesowe.

Wdrażanie gotowego oprogramowania w dużych firmach bez modyfikowania go jest w praktyce bez sensu bo firmy się różnią. Na wdrożenie gotowca bez uwag może sobie pozwolić mała firma kupująca system fakturowania z pudełka za 1000zł, ale firma mająca swoje zwyczaje i strategię? Nie. W moich projektach zawsze (po ewentualnym uporządkowaniu) szanuję wewnętrzne zwyczaje firm, powstaje model procesowy całej firmy (dość ogólny), na nim wydzielane są te obszary, które są kandydatem na gotowy rynkowy system ERP (z reguły obszar finansów i produkcja czasami inne) a to co wymagałoby zmian w danym systemie ERP kandyduje na dedykowany podsystem. Proszę zwrócić uwagę na to, że praktycznie każdy system ERP jest, podczas wdrożenia, parametryzowany a bardzo często także modyfikowany. Jeżeli więc w ofercie widzę, że koszt modyfikacji (dostosowania do potrzeb klientów, wprowadzenie nowych funkcjonalności) to np. 30% wartości oferty, to ten obszar rozważam jako materiał na dedykowany podsystem. Potem nie raz okazuje się, że dostawca ERP doda brakujące funkcje za np. 200 tys., a dedykowany system wraz z integracją kosztuje nie raz mniej niż 100 tys. (zaznaczam, że oba te warianty wymagają zaprojektowania i testowania wiec to nie jest argument przeciwko projektom w np. w UML).

[Konsultant] Widzi Pan, poznając wiele polskich przedsiębiorstw zdałam sobie sprawę, że w Polsce panuje bardzo dziwny zwyczaj (jeśli to można nazwać zwyczajem). Ktoś zdobywa pieniądze i postanawia założyć firmę. W okrzepłych wolnorynkowych państwach (zachód) w takiej sytuacji właściciel finansów poszukuje specjalistów, menadżerów. Przekazuje im pałeczkę, czuwa, dowiaduje się ale jeśli się nie zna na biznesie, to sie nie wtrąca. U nas jest inaczej: mam kasę, tworze firmę, mianuje się jej prezesem i wtrącam się wszędzie, wszystko wiem najlepiej. Efektem jest stworzeniem jakieś dziwnej, indywidualnej strategii przedsiębiorstwa. Nie raz słyszałam z satysfakcją wypowiadane słowa: Takich rozwiązań nie spotkacie nigdzie! Ale to zupełnie nie o to chodzi. Nie chcę się rozpisywać. Chciałabym jednak Panu powiedzieć, że oferta gotowego systemu, zawiera w sobie bogatą bazę uwag, poprawek zdobytych w trakcie wielu, wielu wdrożeń. Moment wdrożenia sytemu informatycznego w przedsiębiorstwie jest bardzo dobry, aby zrewidować strategie i założenia biznesu, jak jest realizowany w firmie. Może warto właśnie skorzystać z tego co oferuje system, a nie upierać sie, że moje rozwiązania są najlepsze i tak musi być! Niestety często tak jest w praktyce.

Proponuje Pan zbyt idealistyczne rozwiązanie. Sądzę że tutaj potrzebny jest mądry kompromis między tym co proponują systemy, a potrzebami firm i brakuje mi jednego: ujednolicenia.

[JŻ] To jest to co różni mnie od wielu dostawców ERP, ale też nie ja jeden tak uważam (polecam M.E.Porter – Strategia konkurencji, napisał tam, że firmy kopiując technologie od kogoś tym samym podejmują decyzje że zrezygnowały już z konkurowania na rynku). Źródłem przewagi rynkowej jest tylko to co odróżnia firmę od jej konkurentów. Studiuje także literaturę z zakresu zarządzania i marketingu: nigdzie na świecie nie potwierdza się teza, że skopiowanie metod konkurenta daje cokolwiek poza ustawieniem się za nim (nigdy przed). Tak więc jeżeli firma decyduje się na rozwój i chce sobie w tym pomóc wdrażając nowe technologie to właśnie po to to robi, by być jeszcze trudniejszym do dogonienia. Ja także bardzo często słyszę „Takich rozwiązań nie spotkacie nigdzie” i to jest główny cel projektu! Ujednolicenie firm to dla nich Walec Drogowy, który po nich przejedzie i wyrówna! Owszem trzeba zweryfikować i ewentualnie zoptymalizować organizację firmy (i po to się robi dobry model procesów biznesowych, by to przetestować i go ewentualnie optymalizować) ale potem właśnie takie „dedykowane rozwiązanie” należy zaimplementować bo ta firma najprawdopodobniej dzięki niemu właśnie jest liderem w swojej branży (to nie jest przypadek, że niektóre procedury są tajemnicą firmy) i usunięcie tego jej lokalnego zwyczaju może nawet zabić firmę.

[Konsultant] W temacie wdrożeń panuje taka różnorodność na każdym etapie prac, że doprawdy trudno się w tym połapać. Nie tworzymy wspólnych platform, nie mamy „punktów wyjścia”, każde wdrożenie to praca od początku. Dla mnie to jest zupełnie nie tak.

[JŻ] A dla mnie jest to właśnie sens nowych technologii IT i oprogramowania wspomagającego zarządzanie. Polecam literaturę o architekturze korporacyjnej, ukazała się niedawno książka „Architektura korporacyjna jako strategia”. W niej autorzy pokazują na przykładach wielu firm, liderów rynkowych, że właśnie kultywowanie własnych unikalnych „struktur” dało im przewagę na rynku i sukces.

Notatka: Polecam także ciekawy wpis na blogu Computerworld: ERP-owym purystom mówimy stanowcze nie.