W ostatnim czasie zastanawiałem się, jak daleko zaszła ewolucja systemów ERP. Gdy zaczynałem karierę, narzędziami programisty były głównie ABAP w SAP czy pierwsze IDE w Navision i Axapta – systemy wyglądały zupełnie inaczej. Dziś mamy wbudowane środowiska programistyczne i rosnącą rolę tzw. citizen developers, co pokazuje, jak wiele zmieniło się w podejściu do rozwoju oprogramowania.
Z drugiej strony pełna chmura i standaryzacja niosą ze sobą nowe wyzwania – utratę elastyczności czy uzależnienie od dostawcy. Dlatego warto docenić, że własne IDE w ERP daje nam wciąż większą swobodę i kontrolę nad rozwiązaniami.
Na początku lat 80. na rynku powstała innowacja - język skryptowy ABAP jako wewnętrzne narzędzie systemu SAP. Taka zmiana wyniknęła z potrzeby dostosowywania raportów do potrzeb użytkowników systemu w znacznie większym zakresie, niż można to było zrobić za pomocą parametrów. I tak rozpoczęła się epoka systemów ERP, których cechą podstawową i zarazem najważniejszą, jest zdolność do ciągłego rozwoju oprogramowania wraz z rozwojem przedsiębiorstw.
W latach 90. Na rynku pojawiły się programy takie jak Navision Financials, Concorde, Great Plains Dynamics czy Damgaard Axapta. Wszystkie te systemy miały wbudowane IDE (ang. Integrated Development Environment), czyli zintegrowane środowisko służące do budowy i rozwoju systemu ERP. Już wcześniej zrodził się wniosek, że przedsiębiorstwa różnią się od siebie tak bardzo na poziomie szczegółów procesowych, że rozbudowywanie predefiniowanej wersji standardowej funkcjonalności systemu ERP nie jest wystarczające, a podstawa funkcjonalna też musi umożliwiać zmiany najbardziej podstawowych elementów systemu i tym samym być napisana w dostępnym IDE.
Od 1996 roku wraz z zespołem zajmowaliśmy się lokalizacją i wdrożeniami systemu Navision Financials w Polsce. Po kilku wdrożeniach szybko zauważyliśmy, że trudno sobie wyobrazić możliwość wdrażania w firmie programu zamkniętego. Brak możliwości modyfikacji choćby podstawowej funkcji księgującej, w celu sprytnej automatyzacji dekretacji jakiegoś specyficznego dla klienta dokumentu, była zbyt ograniczająca jak na potrzeby jakie spotkaliśmy na rynku. Dodatkowo, sprawy nie ułatwiało nasze państwo, które dbało o coraz ciekawsze pomysły wymagające szybkich i nagłych zmian w zakresie księgowości i nie tylko😉. Dostosowywanie w pełni funkcji systemu do procesów operacyjnych firm produkcyjnych, okazało się bezcenne.
Pod koniec ubiegłego wieku miałem okazję prowadzenia kilku wdrożeń opartych na systemie Navision Financials oraz równolegle prowadziłem projekt budowania dużego systemu bazodanowego, za pomocą narzędzi (wówczas) standardowych do budowania aplikacji takich jak .net czy Delphi. Miałem możliwość porównania budowy i wdrożenia systemu w obu metodykach. Czas i skuteczność wdrożenia systemu Navision była nieporównywalna. Przez okres budowania i wdrażania systemu pisanego w narzędziach niskopoziomowych wdrożyliśmy z sukcesem w kilkunastu firmach system ERP, cały rozbudowany i dostosowany do potrzeb klienta. Wspominając jednak o fakcie późniejszego utrzymywania systemu i możliwości jego rozwoju - mimo zakończonych z sukcesem wdrożeń, dalsza rozbudowa tak dużego systemu, napisanego od podstaw w języku niskopoziomowym, była praktycznie niemożliwa.
Dlatego w roku 2000 zdecydowaliśmy się na krok w stronę innowacji - rozpoczęliśmy pracę nad własnym środowiskiem rozwoju. Już w 2002 roku przeprowadziliśmy testy pierwszej wersji kompilatora języka QLX opartego na drzewie wywołań. Wyniki prędkości obliczeniowej tego języka były 12 razy lepsze od języka X++ zawartego w systemie Axapta. Jednak szybko przekonaliśmy się, że o wydajności systemów tego typu stanowi tylko i wyłącznie prędkość bazy danych. I jest tak do dziś. Zdolności obliczeniowe samej aplikacji działającej na grubym kliencie lub serwerze aplikacyjnym dla systemów ERP mają wtórne znaczenie. Ważniejsza w tym wszystkim jest możliwość zmiany warstwy logiki aplikacji przez partnerów merytorycznych. Im więcej osób może rozwijać system, tym lepiej. W latach 90. widzieliśmy jak rozwijały się sieci partnerskie, które wdrażały systemy z IDE typu SAP w Europie. Jedym z przykładów jest Optimus Poznań w którym miałem okazję pracować. Był on w tamtym czasie jedynym NSC (Navision Solution Center) w Polsce, kiedy w tym samym momencie w samych Niemczech było około 75 takich NSC. Wszystkie te firmy zajmowały się W głównej mierze sprzedażą rozwiązań (czyli usług), a nie tylko dystrybucją nie swojego oprogramowania.
Nawet po 20 latach w Polsce trudno jest zrozumieć niektórym producentom oprogramowania klasy ERP sens takich działań, podczas gdy dla całego świata, przez ostatnie 40 lat, był to dość oczywisty kierunek. Dlaczego mieliby wytwarzać technologię rozwoju systemu i dawać ją innym parterom.
Nie zważając na lokalne trendy i niezrozumienia, w 2004 roku przeprowadziliśmy pierwsze wdrożenie systemu retailowego opartego na platformie GardensAM (Gardens Application Model) z naszym językiem QLX na pokładzie. W 2006 roku mieliśmy już pełną funkcjonalność systemu Gardens ERP. Premiera odbyła się na targach Cebit w Hanowerze. Od 2007 roku do dziś wdrażane są nowe wersje systemu Gardens ERP w firmach polskich o różnych profilach branżowych. Dzięki temu, że razem z system dostarczana jest wbudowana platforma rozwoju IDE, każdy z tych wdrożonych systemów rozwija się do dziś razem z przedsiębiorstwem. W wielu przypadkach Gardens ERP rozwijany jest wewnętrznie przez powołanych do tego pracowników tych firm lub innych niezależnych partnerów.
Podejście oparte na wysokim poziomie środowiska rozwoju generuje inną metodykę wdrażania takich systemów. Jako Gardens-Software mamy oczywiście różnego rodzaju doświadczenia w projektach wdrożeniowych tego typu – od negatywnych, takich jak „psucie” systemu rozwijanego przez dostawcę oraz przez zasoby wewnętrzne do bardzo pozytywnych. Za pomocą dobrego środowiska rozwoju i narzędzi do zarządzania nimi można zapanować nad niespójnością merytoryczną różnych osób wprowadzających zmiany. I mimo czasem pojawiających się problemów technicznych, których wystąpienie jest niemalże nieuniknione w przypadku tak dużych projektów – w efekcie końcowym rozwój systemu jest o wiele lepszy i bardziej organiczny.
Cała logika systemu GardensERP napisana jest w języku wysokiego poziomu QLX, a wszystkie obiekty źródłowe (okna, widoki, raporty, narzędzia wymiany danych, struktury danych, czy pakiety funkcji) zapisane są w repozytorium bazy danych. Dzięki temu sama aplikacja dla klienta jest tylko przeglądarką (lub RunTime ) i wszystkie nowsze wersje systemu mogą pracować na całym zasobie funkcjonalności od lat wykorzystywanej przez wielu klientów, którzy posiadają własne repozytoria systemu.
Z citizen- developerami, czyli osobami pracującymi w danej organizacji, które modyfikują wewnętrznie system w firmie, jest tak samo jak z każdym programistą, niezależnie od jego zatrudnienia. Wśród nich znajdą się tacy, którzy wykonają dobrze swoją robotę i tacy, którym wyjdzie to gorzej. Znamy firmy, które rozwijają wdrożony system ERP we własnym zakresie i właśnie takie firmy są najbardziej zadowolone zarówno z rozwoju oprogramowania do zarządzania firmą jak i z wynikającej z tego restrukturyzacji przedsiębiorstwa. Jest to jednak stabilny, w miarę stały koszt zatrudnienia jednego lub dwóch developerów, który jest nieporównywalny i nieprzerwanie wygrywa w porównaniu z kosztami generowanymi przez, niekiedy nieprzewidywalnych, dostawców oprogramowania ERP.
Należy się zastanowić jaki stan mamy obecnie, gdzie wszystkie wdrożone systemy klasy ERP próbuje się zamienić na oprogramowanie sprzedawane subskrypcyjnie w chmurze. Czy tego typu rozwiązania będą mogły być w przyszłości łatwo dostosowywane do potrzeb indywidulanych? Teoretycznie to tylko zmiana technologii i nikt nie widzi przeszkód w tym, żeby aplikacje dostępne zdalnie były customizowane za pomocą różnego rodzaju środowisk wysokiego poziomu. Jednak w praktyce wygląda to inaczej. Wyobraźmy sobie, że wprowadzana zmiana systemu powoduje błędy nieprzewidziane wcześniej na testach. Jest to sytuacja znana każdemu, kto miał do czynienia z procesem wdrożenia systemu. W przypadku chmury mamy wtedy czasowy paraliż firmy uzależnionej w 100% od infrastruktury zdalnej, na którą nie mamy żadnego wpływu. W przypadku dostępu do lokalnego IDE możemy mieć wiele programów awaryjnych, np. przywrócenie jednej zmiany bez zatrzymywania systemu, którą firma może wykonać własnymi zasobami. W praktyce posiadanie takich narzędzi wymusza również na firmach pewne kompetencje techniczne - w przypadku chmury takich kompetencji nie będzie w ogóle w szeregach firm. Drugi czynnik to sama polityka licencjonowania. Sprzedawane subskrypcje czasowe zdejmują w dużym zakresie odpowiedzialność z jakości wprowadzanych zmian i dostosowywania systemu do indywidualnych potrzeb firm.
Podsumowując, należy przypuszczać, że systemy ERP w chmurze sprzedawane w modelu SaaS to kierunek, który będzie naturalnie standaryzował rozwiązania zamiast je personalizować. Myślę, że z tym jest trochę jak z samochodami elektrycznymi. Oczywiście nie przyjmą się w pełnej skali. Właściwa droga dla systemów ERP to systemy z własnymi narzędziami rozwoju, dostępnymi i otwartymi dla osób kompetentnych bez znaczenia na jakich serwerach będą one instalowane, a model sprzedaży zawsze będzie musiał być zgodny z oczekiwaniami klienta.
Autor artykułu: Robert Wojtkowski, CEO Gardens-Software
