Standardowy system informatyczny dla przedsiębiorstwa produkcyjnego – modyfikować czy nie? Kastomizacja oprogramowania

Gdy ponad 20 lat temu zaczynałem swoją życiową przygodę z systemem klasy ERP (z ang. Enterprise Resources Planning) dominującym trendem i zarazem opinią było to, że duże systemy informatyczne zawierające wiele modułów obsługujących różne aspekty biznesowe przedsiębiorstwa produkcyjnego całkowicie wyprą małe, lokalne pisane pod potrzeby firmy programy: magazynowe, księgowe i te do wystawiania faktur. Głównym powodem takiej dominacji miało być to, że te gotowe, duże systemy miały też w standardzie w pełni zaspokajać potrzeby różnych branż i różnych przedsiębiorstw i nie wymagać modyfikacji.

Zanim zagłębimy się w dywagacje na temat modyfikacji, kilka słów o samym oprogramowaniu informatycznym

System informatyczny dedykowany dla przedsiębiorstw produkcyjnych (ERP 4FACTORY) to zintegrowane narzędzie informatyczne, które służy do zarządzania i automatyzacji procesów biznesowych związanych z produkcją, dystrybucją, sprzedażą i obsługą klientów. Zintegrowany system zarządzania może obejmować różne moduły, takie jak planowanie produkcji (APS 4FACTORY), zarządzanie zapasami (WMS 4FACTORY), zarządzanie relacjami z klientami (CRM 4FACTORY), systemy utrzymania ruchu (EAM 4FACTORY), jakością (QMS 4FACTORY) i wiele innych.

Głównymi cechami systemu informatycznego dla przedsiębiorstw produkcyjnych są:

• Integrowanie różnych procesów biznesowych w jedną platformę,
• Automatyzacja procesów biznesowych, dzięki czemu możliwa jest ich szybsza i efektywniejsza obsługa,
• Dostarczanie informacji biznesowych w czasie rzeczywistym, umożliwiając lepszą kontrolę nad procesami i szybsze podejmowanie decyzji,
• Optymalizacja zarządzania zasobami, co pozwala na efektywne wykorzystanie zasobów firmy,
• Ułatwienie monitorowania wyników finansowych przedsiębiorstwa, umożliwiając lepsze zarządzanie kosztami i zwiększenie rentowności.

Dobrze zaprojektowany i wdrożony system informatyczny dla przedsiębiorstw produkcyjnych pomaga w osiągnięciu lepszej efektywności, zwiększeniu konkurencyjności oraz poprawie wyników finansowych firmy.

Dzisiaj wszyscy wiemy, że w aspekcie wypierania małych kastomizowanych programów pisanych przez lokalnych informatyków przez duże zintegrowane systemy informatyczne – przepowiednia się spełniła. Jednak tam, gdzie duży system informatyczny ma „braki” w funkcjonalności i personalizacji – pojawia się konieczność wytwarzania modyfikacji – a jeżeli takowa nie powstanie to luka funkcjonalna będzie przez użytkowników kompensowana za pomocą arkuszy kalkulacyjnych lub innych zewnętrznych narzędzi.  Trzeba mieć świadomość, że żaden system informatyczny nie jest w stanie obsłużyć wszystkich procesów przedsiębiorstwa. Pozostaje więc pytanie: modyfikować czy nie?

Modyfikacja funkcjonalności systemu informatycznego dla przedsiębiorstwa produkcyjnego: czynniki decydujące i wyzwania

Podjęcie decyzji o tym, czy modyfikować system informatyczny, zależy od wielu czynników:

1. Potrzeby przedsiębiorstwa: należy dokładnie przeanalizować potrzeby przedsiębiorstwa. Może okazać się, że standardowe rozwiązanie w pełni zaspokaja potrzeby przedsiębiorstwa, a modyfikacja nie będzie konieczna.
2. Koszty: modyfikacja systemu informatycznego wiąże się z kosztami. Należy dokładnie przeanalizować koszty modyfikacji, w tym koszty wdrożenia, szkolenia pracowników i utrzymania systemu i modyfikacji.
3. Integracja z innymi systemami: jeśli system informatyczny jest zintegrowany lub w trakcie wdrożenia będzie integrowany z innymi systemami, modyfikacja może okazać się skomplikowana i kosztowna. W takim przypadku konieczne może być dokładne przeanalizowanie skutków działania modyfikacji dla innych systemów.
4. Wydajność systemu: jeżeli rozważana do implementacji modyfikacja systemu informatycznego przedsiębiorstwa dotyczy zmiany sposobu obsługi procesu lub wpływa na wiele danych z wielu obszarów systemu to konieczna jest analiza wpływu tej modyfikacji na wydajność całego systemu.
5. Bezpieczeństwo systemu: standardowy system informatyczny praktycznie zawsze zapewnia wysoki poziom bezpieczeństwa. Przygotowując modyfikację tego systemu trzeba zdawać sobie sprawę, że nie może ona pogorszyć tego stanu i zagrozić bezpieczeństwu danych lub stabilności całego systemu.

Decyzja o modyfikacji systemu informatycznego pracującego dla przedsiębiorstwa produkcyjnego powinna być dokładnie przemyślana i oparta na analizie konkretnych potrzeb, kosztów i skutków modyfikacji dla modyfikowanego systemu i innych systemów działających dla tego przedsiębiorstwa.

Dostosowanie oprogramowania do potrzeb użytkownika: modyfikacje i kastomizacje systemów informatycznych

Modyfikacje często nazywane są również kastomizacjami (z ang. Customization) – chociaż w moim prywatnym słowniku te dwa pojęcia lekko się różnią od siebie.

• Kastomizacja to poprawa ergonomii programu, układu pól, dodanie pola lub zmiana kolorystyki raportu, dodanie przycisku lub filtra w raporcie innymi słowy jest to stosunkowo niewielka zmiana nie wpływająca procesy obsługiwane przez system.
• Modyfikacja to coś co zmienia proces, dodaje lub modyfikuje istniejącą funkcjonalność. Z założenia jest to więc o wiele większa ingerencja w działanie systemu mająca na celu uzupełnić, rozszerzyć lub zmienić standardową funkcjonalność systemie informatycznego.

Zarówno modyfikacje jak i kastomizacje systemów informatycznych, czyli generalnie dostosowywanie oprogramowania do indywidualnych potrzeb użytkowników, stają się coraz bardziej popularne w dzisiejszych czasach. Oferują one szereg korzyści, w tym zwiększenie wydajności, ułatwienie pracy oraz poprawę ergonomii interfejsu. W dalszej części tego artykułu przyjrzymy się bliżej modyfikacjom i kastomizacjom systemów informatycznych oraz opiszę jakie są zalety i wady ingerowania w system informatyczny oraz zmieniania jego sposobu działania.

Modyfikacje i kastomizacje systemów informatycznych to proces wprowadzania zmian w oprogramowaniu, który umożliwia użytkownikom dostosowanie interfejsu, funkcjonalności lub sposobu działania do swoich potrzeb.
Mogą to być np. zmiany w układzie menu, dodatkowe pola, zupełnie nowa kartoteka do wprowadzania danych czy też funkcjonalność automatyzująca kilka procesów wykonywanych zawsze jeden po drugim.

Zalety i wady kastomizacji oprogramowania oraz modyfikacji systemów informatycznych

Zalety opisanych powyżej rozwiązań są liczne. Przede wszystkim pozwalają one użytkownikom na dostosowanie oprogramowania do ich indywidualnych potrzeb, co może poprawić wydajność i efektywność pracy.
Możliwość dostosowania interfejsu do potrzeb i preferencji użytkowników również zwiększa ergonomię i komfort pracy.

Warto również zwrócić uwagę na fakt, że zarówno kastomizacja jak i modyfikacja mogą ułatwić pracę z nowym oprogramowaniem, które nie zawsze jest intuicyjne i łatwe w obsłudze. Modyfikacją może być też dostosowanie systemu do wymagań przedsiębiorstwa lub specyficznych wymagań kluczowych klientów przedsiębiorstwa. Dzięki takim zmianom obsługa procesów nie wymaga już generowania dodatkowych danych poza systemem, zwiększając tym samym funkcjonalność, efektywność i wydajność pracy użytkowników i samego systemu. Zwiększenie konkurencyjność to kolejna z zalet modyfikowania systemu informatycznego. Dobrze przygotowana i przemyślana modyfikacja może pozwolić organizacji na wyprzedzenie konkurencji poprzez wprowadzenie bardziej dopasowanego i efektywnego systemu informatycznego.

Jednak, jak każde rozwiązanie tak i kastomizacje oraz modyfikacje mają również swoje wady. Przede wszystkim, jeśli wprowadzone zmiany są zbyt duże, mogą one wpłynąć negatywnie na stabilność systemu i jego bezpieczeństwo. Dodatkowo kastomizacje mogą utrudnić pracę innym użytkownikom, którzy nie zostali zaznajomieni z wprowadzonymi zmianami. Modyfikacje systemu informatycznego mogą prowadzić do zwiększenia jego złożoności, co może prowadzić do problemów związanych z utrzymaniem, konserwacją i rozwojem systemu. W połączeniu z niskiej jakości dokumentacją dotyczącą modyfikacji oraz rotacją użytkowników, którzy uczestniczyli w procesie tworzenia i wdrażania modyfikacji może w konsekwencji prowadzić do „erozji” wiedzy – czyli stanu, w którym nikt w przedsiębiorstwie, które zamówiło modyfikacje i za nią zapłaciło – nie wie do czego ona służy i po co powstała. Liczne modyfikacje mogę również prowadzić do problemów z okresową aktualizacją systemu. Duże systemy informatyczne takie jak systemy klasy ERP 4FACTORY, które obejmują swoim działaniem wiele procesów regulowanych prawem jest okresowo aktualizowana w celu dostosowania ich do zmieniających się wymagań prawnych. Źle zaprojektowana i wykonana modyfikacja może w przyszłości utrudnić lub uniemożliwić okresową aktualizację systemu. Innym zagrożeniem związanym ze wdrożeniem modyfikacji jest nieprawidłowy proces jej testowania, który może doprowadzić, że błędy lub całkowita awaria systemu wystąpi dopiero po jakimś czasie użytkowania modyfikacji na produkcyjnej wersji systemu informatycznego.

Warto więc rozważyć zrównoważone podejście do wprowadzania zmian do systemu informatycznego, które uwzględnia zarówno potrzeby użytkowników, jak i bezpieczeństwo oraz stabilność systemu.

Modyfikacja tworzona jest przez ludzi i jeżeli została ona dobrze zaprojektowana, kompleksowo przemyślana i poprawnie zrealizowana to z dużym prawdopodobieństwem można stwierdzić, że przyniesie ona więcej korzyści niż problemów. Znamienne jest jednak to, że mało doświadczeni konsultanci wdrożeniowi decydują się na tworzenie modyfikacji, które w wielu przypadkach w ogóle nie powinny powstać lub też, jeżeli są w pełni uzasadnione biznesowo – to specyfikacja opisująca nowe rozwiązanie jest zbyt ogólnikowa i nie zawiera analizy ryzyka związanego z wdrożeniem zaproponowanej zmiany.

Przykłady dobrych praktyk

Jaka jest więc BEST PRACTICE w zakresie projektowania i implementacji modyfikacji bezpiecznych i o wysokiej jakości:

1. Obie strony, tj. użytkownicy kluczowi ze strony klienta jak i konsultant biznesowy ze strony dostawcy oprogramowania – tak długo współpracują, wymieniają się wiedzą, doświadczeniem oraz dyskutują nad rozwiązaniem aż obie strony bardzo dobrze zrozumieją proces i wymagania związane z jego obsługą jak również bardzo dobrze poznają i zweryfikują dostępne w standardzie rozwiązania oferowane przez system informatyczny. Oczywiście w przypadku wdrożenia nowego systemu w przedsiębiorstwie, gdzie użytkownicy po wstępnych szkoleniach dopiero poznają funkcjonalność oferowaną przez oprogramowanie to ciężar odpowiedzialności za dopasowanie rozwiązań, czy to standardowych, czy też modyfikowanych, spada na barki konsultanta.
2. Po spełnieniu pierwszego warunku zarówno użytkownik (klient) jak i konsultant (dostawca rozwiązania) wspólnie dochodzą do wniosku o konieczności zastosowania modyfikacji lub kastomizacji systemu.
3. Przygotowywana jest specyfikacja rozwiązania (modyfikacji/kastomizacji), czyli dokument zawierający następujące elementy:
   • Opis wymagań biznesowych klienta
   • Opis standardowych rozwiązań oferowanych przez system
   • Opis proponowanych zmian wraz z informacją o parametrach modyfikacji, zakresie modyfikowanych funkcji, programów i danych systemowych.
   • Opis ryzyka związanego z implementacją zmiany.
   • Scenariusz testów. Każda modyfikacja systemu przed wdrożeniem jej do użytkowania na produkcyjnej wersji systemu informatycznego musi zostać przetestowana na środowisku testowym lub programistycznym. Scenariusz z jednej strony umożliwia przeprowadzenie testów jeszcze na etapie kodowania zmiany przez programistę z drugiej strony pozwala na przeprowadzenie efektywnych testów pozwalających na podjęcie decyzji o wdrożeniu modyfikacji na produkcyjnej bazie systemu informatycznego. Dobrze przygotowany scenariusz daje pewność zarówno klientowi jak i dostawcy rozwiązania, pewność, że modyfikacja jest bezpieczna i działa zgodnie z założeniami.
   • Wycenę kosztów wytworzenia modyfikacji lub kastomizacji, koszów wdrożenia i utrzymywania modyfikacji przez dostawcę.
4. Przygotowany dokument specyfikacji powinien zostać przedyskutowany przez cały zespół wdrożeniowy ze strony klienta i dostawcy (na etapie wdrożenia jak i po jego zakończeniu). Bardzo istotna jest świadomość wpływu przygotowywanej modyfikacji na inne obszary Systemu Informatycznego oraz jego integrację z innymi systemami. Świadomość ta powinna zostać uzyskana przez zespół jeszcze przez tym, gdy sama modyfikacja zostanie zlecona programistom do wykonania.
5. Przed dostarczeniem i instalacją modyfikacji w środowisku klienta każda modyfikacja musi zostać przetestowana przez autora specyfikacji – czyli przez konsultanta, który wraz z klientem zaprojektował rozwiązania.
6. Po pozytywnym zakończeniu testów wewnętrznych przyszedł czas na testy z klientem.  Czasem etap ten może być realizowany samodzielnie przez klienta, ale w większości przypadków konsultant prowadzący ma za zadanie zaprezentować działanie modyfikacji i nadzorować przebieg testów.
7. Wszystkie błędy i nieprawidłowości wykrywane podczas testów zarówno przez klienta jak i konsultanta zgłaszane są do programisty, który ma za zadanie w jak najkrótszym czasie skorygować wykryte nieprawidłowości w działaniu modyfikacji i dostarczyć do kolejnych testów poprawioną wersję modyfikacji.
8. Po zakończeniu testów (dowolna iteracja poprawek i kolejnych testów) i potwierdzeniu prawidłowego działania modyfikacji – przychodzi czas na instalację modyfikacji na bazie produkcyjnej.
9. Asysta powdrożeniowa. Każda modyfikacja instalowana na wykorzystywanym produkcyjnie systemie informatycznym objęta jest miesięczną lub kilkumiesięczną asystą. Nawet najbardziej dokładne i przemyślane testy mogą nie wykryć wszystkich problemów generowanych przez wprowadzoną zmianę. W przypadku wykrycia drobnych problemów już na systemie produkcyjnym – przygotowywana jest nowa wersja modyfikacji, która ponownie testowana jest na testowej wersji systemu i dopiero po weryfikacji działania poprawki – wgrywana jest ona na produkcyjną wersję systemu informatycznego. W przypadku wykrycia dużych błędów, których analiza wymaga czasu – najlepszym rozwiązaniem jest wycofanie instalacji modyfikacji z produkcyjnej wersji systemu i dogłębna analiza przyczyn niewykrytych na wcześniejszych etapach testów ponownie na wersji testowej.
10. Dokumentacja powykonawcza i instrukcje stanowiskowe dla użytkowników. Każda modyfikacja po przejściu wszystkich opisanych powyżej kroków i pozytywnym wdrożeniu jej do użytkowania na produkcyjnej wersji systemu informatycznego powinna zostać szczegółowo opisana w zakresie jej parametryzacji jak i obsługi. Dokumentacja taka będzie nieodzowna w przypadku szkolenia nowych pracowników jak i przy aktualizacji systemu informatycznego do jego najnowszej wersji.

Podsumowując, modyfikacje i kastomizacje systemu informatycznego mogą przynieść wiele korzyści, ale należy podejść do nich z rozwagą i przeprowadzić je z wykorzystaniem najlepszych praktyk i narzędzi, aby uniknąć poważnych zagrożeń związanych z funkcjonowaniem systemu. Warto również pamiętać, że duże modyfikacje funkcjonalności systemu powinny być przeprowadzane tylko wtedy, gdy istnieje wyraźna potrzeba, a korzyści z zastosowania takiej modyfikacji w zdecydowany sposób przeważają nad potencjalnymi zagrożeniami.

Jeszcze jednym aspektem branym pod uwagę podczas podejmowania decyzji o przygotowaniu modyfikacji systemu informatycznego powinien być rozwój systemu poprzez wdrożenie dodatkowej funkcjonalności lub całego dodatkowego modułu rozszerzającego funkcjonalność systemu. Po co pisać modyfikację do systemu ERP 4FACTORY obsługującą magazyn narzędzi, skoro taka funkcjonalność dostępna jest w gotowym module EAM 4FACTORY (ang. Enterprise Assets Management).

Odpowiadając zatem na tytułowe pytanie tego artykułu. Tak, modyfikować, ale rozsądnie i zgodnie z przytoczoną przeze mnie procedurą i tylko gdy nie ma możliwości wdrożenia rozszerzenia systemu, które pokryje dodatkowe wymagania. Im rozwiązanie informatyczne bliższe jest standardowej wersji – tym łatwiej i taniej jest je utrzymywać, obsługiwać i rozwijać.