Ten artykuł dedykuję sponsorom projektów wdrożeń systemów ERP.

Wprowadzenie

Konstrukcje mechaniczne mają cykl życia nadal liczony w latach: są to mosty i domy, tu raczej dziesięciolecia, ale są to także pojedyncze lata, a nie raz nawet miesiące (drobny sprzęt domowy). Jednak inżynieria zaś staje się coraz bardziej interdyscyplinarna. Kiedyś pralka była w 100% mechanicznym wyrobem, obecnie szkielet to nadal obudowa, wirnik i silnik, ale programator to już nie jest mechanizm zegarowy a komputer czyli: procesor, pamięć i oprogramowanie. To ostatnie teraz decyduje o kluczowych funkcjonalnościach pralki.

Komputer, definiowany w filozofii informatyki jako uniwersalny mechanizm, zastępuje coraz więcej mechanicznych i elektromechanicznych urządzeń lub ich podzespołów: był takim zegarek, telefon, programatora pralki, mechaniczny arytmometr i wiele innych. Jeżeli jakaś praca stanowi powtarzalny zestaw czynności, np. obliczenia czy tworzenie treści dokumentów, komputer jest w stanie te prace wesprzeć a nie raz w całości przejąć na siebie. W tym momencie pisząc komputer mamy na myśli oprogramowanie czyli program: dokładny opis tego co ma sie wydarzyć.

Każda organizacja jest jak ta pralka: postęp powoduje, że wiele rzeczy jest w niej nadal jak kiedyś, ale niektóre zastępujemy komputerem: składy dokumentów, sterowanie maszynami, operacje księgowe itp. To nie jest łatwe i to już nie będzie jeden program. [wprowadzenie dopisane w 2022].

Duża organizacja to duży projekt

Jak wygląda projekt informatyczny w przypadku dużej organizacji? Szkielet organizacji to jej zasoby materialne (budynki, maszyny, itp.) i zatrudnieni ludzie. Te zasoby mają w organizacjach wieloletni cykl życia. Jednak logika biznesowa to na bieżąco ustalane zasady, zmieniające się prawo a nie raz reakcje ad-hoc. Czym jest oprogramowanie wspomagające pracę organizacji? To jak zawsze, system zarządzający informacją, tu jednak obowiązują reguły biznesowe, które zmieniają się coraz częściej.

Problem analizy i projektowania dużych systemów informatycznych wymyka się tradycyjnej inżynierii oprogramowania opartej na bazach danych i funkcjach. Kluczowym powodem jest rosnąca szybkość zmian na rynku i to, że oprogramowanie z zasady służy do realizacji określonej logiki biznesowej, a ta, jak widać, szybko się zmienia. Niedawno pisałem:

Rynek zmienia się szybko, więc nie ma sensu szczegółowe projektowanie czegokolwiek z uwagi na czas jaki zajmie takie projektowanie i ryzyko, że taki projekt stanie się szybko nieaktualny. Nikt rozsądny nie namawia dzisiaj do czegoś o wdzięcznej nazwie ?waterfall?.  Co więc zrobić? Dla dużych projektów tworzymy architekturę, opisujemy mechanizmy działania, politykę rozbudowy i opis cyklu życia.  Czyli to co pozwoli rozwijać rozwiązanie metodą iteracyjno-przyrostową, w razie potrzeby pozwoli na przeprojektowanie, ale jako całość nadal będzie spójne, nie będzie wymagało wymiany całości gdy zmienią się warunki na rynku. ¹

Czy nadal mówimy o zintegrowanym systemie? Tak. Czy zintegrowany to to samo co stanowiący jedną fizyczną całość? Nie.

Duże monolityczne systemy powstawały w czasach, gdy zmienność rynku była relatywnie mała. Bazy danych składające się z tysięcy powiązanych na stałe tablic, stanowią sobą coś, czego nie da się zmienić inaczej niż przeprojektować i dokonać migracji ze starej do nowej struktury. Tylko, że taki proces to nawet nie miesiące a lata. Logika biznesowa zaszyta w tych strukturach to coś na podobieństwo mechanicznego programatora będącego integralną częścią starej pralki.

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ć. ²

Tak więc na tym etapie projektu inżynieria oprogramowania to projektowanie architektury a nie tradycyjnie rozumiane zbieranie wymagań. Taka architektura to dziedzinowe podsystemy, zintegrowane na poziomie wymiany kluczowych dokumentów, które opisywałem tu już wielokrotnie:

Każda firma, szukając sposobu na uzyskanie przewagi rynkowej, stara się pewne obszary operacyjne budować wg, własnej strategii. To między innymi powoduje, że każde wdrożenie jest inne i nie ma jednej jedynie-słusznej architektury IT. ³

Zarządzanie projektem

Zarządzanie projektem związanym z wdrażaniem oprogramowania wspomagającego prace organizacji, ma dwa etapy i wymaga podziału na role. To co teraz napiszę nie jest żadną tajemną wiedzą, to raczej zbiór dobrych praktyk.

Dziwi mnie, że wszystkie te, doświadczone porażką firmy, mają dostęp do tej samej wiedzy co np. ja, a mimo to zarządy tych firm wierzą bezgranicznie dostawcom oprogramowania i wierzą, że opisywane od lat przyczyny porażek u nich nie wystąpią? ⁴

Wydawcy strony Business Process Trends Associates⁵ prezentują od lat trójwarstwowy model organizacji. Autorzy dzielą strukturę opisu na trzy warstwy: opis strategii rynkowej (rola organizacji na rynku: procesy end-2-end), opis wewnętrznej strategii (jak realizowana jest strategia rynkowa: wewnętrzne procesy biznesowe) oraz implementacji (jakie zasoby są wykorzystywane: procedury, reguły biznesowe i systemy IT).

Małe wdrożenia (projekty w jednej lokalizacji o wartości poniżej 100 tys. zł netto) z reguły dotyczą pewnych określonych i wąskich obszarów działania i wąskiej grupy zasobów. Ich wdrażanie najczęściej nie wymaga żadnych ingerencji w organizację pracy organizacji, stanowią one pewne elementy automatyzacji określonej pracy.

Projekty stanowiące wyzwanie to te, które skutkują zmianą wewnętrznej strategii. Tu zwrócę uwagę, że praktycznie każde kompleksowe wdrożenie oprogramowania to zmiana procedur, nawyków, nie raz całych procesów biznesowych, bywa, że całkowite przemodelowanie procesów biznesowych wewnątrz organizacji. Wynika to z tego, że wdrażanie nowych narzędzi pracy wymaga zmiany procesów ich wykorzystania. Wprowadzenie elementów automatyzacji bardzo często całkowicie zmienia niektóre procesy.

Powyższe powoduje, że projekty takie powinny być poprzedzane analizami, projektowaniem nowego stanu rzeczy i testowaniem skutków tych zmian. Główne role w tego typu projektach to: sponsor i beneficjent czyli organizacja, która wdraża nowe rozwiązania oraz  firma wdrażająca. Sponsor najczęściej zna swój problem i cel biznesowy, ale z reguły nie ma kompetencji do opisania (zaprojektowania) rozwiązania, dostawca rozwiązania zaś musi wiedzieć co ma dostarczyć. Pojawia się potrzeba zaangażowania nowej, trzeciej kompetencji: analityk projektant rozwiązań. Któż to jest?

Potocznie ta rola nazywana jest Analityk Biznesowy⁶, jednak produkt jaki powinien powstać na tym etapie to najpierw opis działania organizacji (procesy i reguły biznesowe, struktury zarządzanej informacji) a potem projekt (opis) rozwiązania czyli tego jak, co wdrożyć, jak zmienić organizację, by osiągnąć cele biznesowe założone przez sponsora projektu. Całość można przedstawić tak:

Sponsor to kierujący organizacją, te można opisać na trzech poziomach jak na powyższym diagramie. Pierwszy etap to analiza i modelowanie organizacji (procesy i reguły biznesowe), zwieńczeniem tego etapu jest projekt rozwiązania stanowiącego sposób osiągnięcia celu biznesowego zdefiniowanego przez Sponsora. Tym rozwiązaniem często jest model wymaganego oprogramowania rozumiany jako specyfikacja usług jakie ma ono świadczyć i logika ich relacji (oprogramowanie opisane jako Platform Independent Model).

Zakresy dużych projektów stanowią sobą opis architektury całego systemu oraz opis role poszczególnych jego komponentów (pamiętamy, że mamy także opis logiki biznesowej). Powyższy diagram obrazuje sposób realizacji dużego projektu:

1. Sponsor, wskazując cel biznesowy, zleca Analitykowi analizę biznesową i projekt rozwiązania.
2. Powstała dokumentacja służy jako materiał do wyłonienia dostawcy opisanego rozwiązanego, ten jako pierwszy krok, opracowuje  Studium wykonalności (Koncepcję wdrożenia).
3. Treść koncepcji zawiera (powinna) harmonogram wdrożenia poszczególnych komponentów rozwiązania, z uwagi na to, że całość trwa w czasie, proces ten jest realizowany iteracyjnie (przyrostowo).

Role w projekcie:

1. Analityk projektant, jako autor rozwiązania, nadzoruje realizację zarządzając zmianami w projekcie i uzupełniając go o opracowywane w toku realizacji i wdrożenia szczegóły. Z reguły jest to jedna osoba sprawująca nadzór merytoryczny.
2.  Dostawca rozwiązania to cały zespół specjalistów (kierownik projektu, konsultanci, programiści, wdrożeniowcy, testerzy itd.) odpowiedzialny za wdrożenie.
3. Sponsor sprawuje pieczę nad całością, zabezpiecza środki i bieżący dostęp do wymaganych materiałów na temat organizacji (pamiętamy, że czas płynie a takie wdrożenia trwają przeciętnie od trzech do pięciu lat).

Podsumowanie

Opisałem tu sposób w jaki realizuję projekty. Jest to, jak widać, znane w literaturze podejście. Taki podział na etapy i role pozwala na jednoznaczne określenie odpowiedzialności. Osobiście nie nie mam przekonania do dużych zespołów konsultantów doradców po stronie Sponsora, gdyż szybo dochodzi do rywalizacji pomiędzy nimi a członkami zespołu dostawcy rozwiązania. Z drugiej jednak strony dostawca powinien mieć świadomość, że jego rola to wykonanie implementacji rozwiązania a nie jego projektowanie. Cały projekt to dwie strony: Sponsor czyli zamawiający wraz z Analitykiem projektantem, oraz dostawca rozwiązania. Taki podział upraszcza zarządzanie projektem i jasno wskazuje odpowiedzialność stron. Pierwszym produktem jest model CIM i PIM⁷ a drugim dostarczone zgodnie z projektem i i udokumentowane rozwiązanie. To są tylko dobre i sprawdzone na świecie praktyki…