Wstęp

Swego czasu brałem udział w burzliwiej dyskusji (zresztą niejednej) na temat sensu prac analitycznych i projektowych przy okazji wdrażania systemów ERP, czyli gotowego oprogramowania (przeczytaj artykuł). Większość dostawców tego oprogramowania, z jakimi miewam kontakt, uważa, że analiza owszem ale w celu opracowania koncepcji wdrożenia, czyli dokumentu mówiącego jak dostosować system ERP do potrzeb klienta z naciskiem na słowo kompromis. Pojawia się prędzej czy później święte słowo kastomizacja, które po protu oznacza najczęściej przerabianie gotowego produktu (nie raz bardzo dobrego do momentu gdy się go nie popsuje tymi przeróbkami, przeczytaj i ten artykuł).

Kastomizacja a parametryzacja

Niedawno pisałem, że

gotowe oprogramowanie należy zostawić nietknięte (nie licząc okienek konfiguracji) a brakujące funkcjonalności opracować, zaprojektować i zintegrować.

Z reguły jak tylko wypowiem tę kwestię, lecą na mnie gromy ze strony konsultantów dostawców ERP. Jednak warto te metodę stosować co potwierdzają nie tylko moje doświadczenia:

Eksperci podkreślają bowiem, że większość kosztów generowanych przez projekt wdrożeniowy nie ma nic wspólnego z kosztem samego oprogramowania. ?Średnio trzy czwarte budżetu pochłaniają koszty wdrożenia, modyfikacji standardowej funkcjonalności oraz modernizacji sprzętu? ? czytamy w raporcie Panorama Consulting Group. […] O systemach klasy ERP coraz częściej mówi się, że są zbyt rozległe, ociężałe i ograniczają możliwości biznesu, od którego wymaga się zwinności i elastyczności. Czy czasy takich systemów już przemijają?? (źr. IDG, 2010r)

Stale śledzę to co się dzieje na rynku systemów IT wspomagających zarządzanie obserwuję taki własnie kierunek rozwoju:

Systemy zintegrowane ERP będą pewnymi zestawami gotowych funkcjonalności, zbudowanymi w oparciu o szkielety oprogramowania zaś integracja będzie bazowania nie na współdzieleniu danych a na wymianie ich pomiędzy modułami i zewnętrznymi systemami na równych prawach. Rozwój systemu w takim przypadku polega na tworzeniu nowych modułów tym środowisku a nie na modyfikacji już istniejących.

Kierunek ten już widać od ok. dwóch lat na rynku (ja o tym pisze od ponad pięciu), prace te więc trwają zapewne  znacznie dłużej. Widać to na stronach niektórych dostawców, liderów na rynku:

Dynamics AX 2009. Framework (szkielet, przyp. mój) to zestaw wzorców projektowych, interfejsów, gotowych bibliotek i innych narzędzi. Elementy te dają wsparcie programistom. Najlepszą praktyką jest sięganie do tych zasobów i wykorzystywanie ich zamiast tworzyć własne podobne. Tu opisano framework, podsystemy i funkcjonalności Microsoft Dynamix AX (źr. Frameworks Introduction).

Obecnie standardem jest stosowanie w framerworkach, przeznaczonych do tworzenia oprogramowania biznesowego w środowisku przeglądarek WWW, (i nie tylko) wzorca projektowego MVC:

Wzorzec MVC pomaga tworzyć aplikacje rozdzielając trzy różne aspekty oprogramowania: interfejs użytkownika, logikę biznesową oraz zachowanie systemu, poprzez zachowanie minimalnych wzajemnych zależności. Wzorzec opisuje gdzie każdy z elementów tej logiki umieszczać. Interfejs użytkownika obsługuje widok (view). Sterowanie aplikacją obsługuje kontroler (controller). Logika biznesowa zawarta jest w modelu (model). Ta separacja pomaga zarządzać złożonością oprogramowania podczas jego tworzenia, ponieważ pomaga skupić się w danym momencie na jednym tylko aspekcie problemu.  (źr. MSDN MVC Overwiew)

Inny przykład podejścia do otwarcia się:

Tu mamy coś w rodzaju fasady ([[wzorzec projektowy fasada]]) dla IFS Application (materiały z publicznej strony WWW), którego nowa wersja to już nie środowisko procedur w Oracle DBMS a serwer aplikacyjny Java J2EE (ciekawe ilu programistów Java mają na etatach dostawcy IFS’a). Zapewne powyższe to nie jedyne przykłady tego rodzaju rozwiązań ERP na rynku (firmy chcące uzupełnić ten artykuł mogą mi przesłać stosowne materiały).

Tak więc da się, trzeba nie tylko chcieć ale i potrafić. Tu mała łyżka dziegciu do garnuszka integratorów i dostawców ERP: najczęściej nie potrafią i mam wrażenie, że nie chcą bo, jak już w poprzednim artykule pisałem, nie jest to w ich interesie.

Model biznesowy dostawców gotowego oprogramowania to w większości przypadków brak kosztów tworzenia własnego produktu i jego rozwoju i budowanie marży na cudzym produkcie. Oferowany jest cudzy produkt wraz usługą  jego wdrożenia. Firma taka stanowi kanał sprzedaży producenta tego oprogramowania. Problem w tym, że od pewnego czasu rynek się zmienia: gotowe produkty bez modyfikacji nie mają tu (zarządzanie) racji bytu a mam wrażenie, że dostawcy ERP starają się za wszelka cenę unikać dostosowań. Dlaczego? Bo ich model biznesowy własnie w większości przypadków nie przewiduje utrzymywania bardzo kosztownego zespołu analityków, projektantów i programistów.

Czy mam rację? Przejrzałem co nieco ogłoszeń o prace dostawców ERP, z tego co zebrałem skompilowałem najczęściej powtarzające się oczekiwania:

Konsultant systemów ERP

Osoba będzie członkiem zespołu biorącego udział w procesie wdrażania systemu ERP (analiza, konfiguracja, szkolenia) oraz zapewniającego bieżącą obsługę i serwis istniejących wdrożeń.

Opis stanowiska pracy

• współpraca z klientem oraz doradztwo merytoryczne
• udział w analizach wdrożeniowych
• zaawansowane wsparcie dla obecnych klientów systemów
• udział we wdrażaniu systemów
• przeprowadzanie prezentacji produktów u klienta
• prowadzenie szkolenia dla klientów
• wsparcie użytkowników systemu
• prowadzenie dokumentacji technicznej,
• zarządzanie zmianami w systemie,
• szkolenie końcowych użytkowników,

Oczekujemy:

• 2-3 letniego doświadczenia we wdrożeniach systemów klasy ERP
• zdolności analitycznego myślenia
• umiejętności rozwiązywania problemów
• doświadczenie we wdrażaniu systemów
• ogólna orientacja w procesach biznesowych i chęć pogłębiania tej wiedzy,
• znajomość metodyki zarządzania projektami wdrożeniowymi
• znajomości SQL

To ostatnie (SQL) pojawia się od czasu do czasu, to kompetencja wymagana do tworzenia nowych raportów w systemie. Gdzie tu jest inżynieria oprogramowania? Czy w państwa wdrożeniach poza konsultantami brali udział analitycy projektanci i programiści czy tylko konsultanci wpadający po to by pozmieniać coś w systemie (powodując nie raz uszkodzenia w innych jego częściach)?

Tak więc co mogę poradzić? Bardzo dokładne przyglądanie się rozdziałom oferty pod tytułem Dostosowanie systemu, Koncepcja wdrożenia oraz ile oczekiwanych przez Państwa  funkcjonalności to te, których system w swej wersji standardowej nie oferuje. Powinny one być po dokładnej analizie, zaprojektowane i zaimplementowane.

Jeżeli Konsultanci zaczynają negocjować rezygnację z części oczekiwań lub oferują coś podobnego w systemie, to pierwszy sygnał, że powinien ktoś im zacząć patrzeć na ręce, i nie mam tu na myśli ich przełożonego.

Na zakończenie list jednego z moich klientów, nazwał bym to typowym problemem:

Planujemy wdrożenie nowego oprogramowania, chcemy tym razem uniknąć presji ze strony dostawcy oprogramowania. Poprzednim razem dostawca oprogramowania upraszczał sobie pracę, już na etapie analizy, którą wykonywał sam. Analiza wymagań polegała na wywiadach i warsztatach grupowych, skończyła się zwykłym opisem, tabelkami i kilkoma nieczytelnymi schematami. Podczas analizy i wdrożenia stale wmawiano nam, że „tego nie można”, „to należy uprościć” albo „tak się nie robi” my zaś nie potrafiliśmy tego ocenić. Wiele naszych potrzeb odkrywaliśmy dopiero podczas instalacji kolejnych prototypów, zaś dostawca unikał wprowadzania zmian i obiecanych dostosowań. Dostaliśmy w efekcie nieprzydatne i niezgodne z biznesowymi potrzebami oprogramowanie. Czy może nam Pan tym razem pomóc?

P.S.

Nie jestem w żaden sposób związany z dostawcami produktów wymienionymi w artykule. Ich nazwy zostały wskazane wyłącznie z szacunku dla praw autorskich cytowanych treści.