Przyczyn tego stanu rzeczy może być wiele, jednak nie chcemy ograniczać się z dostarczaniem naszych rozwiązań tylko dla wybranych wersji systemu. Doświadczenia wynikające z przeprowadzonych projektów pokazały nam, że zawsze trzeba być wrażliwym na różnice występujące w standardzie SAP, w zależności od wersji systemu. Odpowiedni zestaw komponentów oraz wyselekcjonowane narzędzia są kluczem do sukcesu. W kolejnych akapitach omawiamy nasze podejście do projektowania naszych rozwiązań.
Spis treści
Konfiguracja techniczna i merytoryczna
Projektując architekturę rozwiązań naszej firmy zawsze staramy się dawać możliwość wykorzystania komponentów oraz ulepszeń znajdujących się w nowych wersjach systemu SAP. Jednocześnie chcemy zachować kompatybilność ze starszym wersjami sytemu tak, aby dać możliwość skorzystania z oferty wszystkim zainteresowanym. Proces projektowania produktów Fintiery opieramy na następujących założeniach:
1. Architektura rozwiązania jest dzielona na małe moduły.
Każdy z modułów odpowiada za wydzielone funkcjonalności oraz elementy procesu. Podzielenie rozwiązania na odseparowane od siebie moduły daje nam elastyczność, w przypadku potrzeby modyfikacji/ dostosowania funkcjonalności. Takie podejście pozwala Nam wykonywać modyfikacje poszczególnych elementów rozwiązania, bez konieczności ingerencji w pozostałe składowe procesu.
Obserwuj nas na LinkedIn
Obserwuj nas
2. Działanie rozwiązania opieramy na dwuczęściowej konfiguracji, w której skład wchodzą:
a. Konfiguracja techniczna – zestaw tabel konfiguracyjnych dotyczących technicznych aspektów rozwiązania, zawierających między innymi wpisy sterujące wersjami modułów, które będą wykorzystywane w rozwiązaniu. Konfigurację techniczną wykonujemy zazwyczaj raz na początku wdrożenia i jej zmiany odbywają się bardzo rzadko.
b. Konfiguracja merytoryczna – zestaw tabel konfiguracyjnych dotyczących merytorycznych aspektów rozwiązania, wykorzystywanych przede wszystkim do układania procesów. Ta część konfiguracji może zmieniać się częściej niż konfiguracja techniczna, na przykład w sytuacji, kiedy zajdzie potrzeba zmodyfikowania procesu (dodanie lub pominięcie kroków, zmiana kolejności). Taki sposób układania procesu umożliwia modyfikację kolejnych kroków bez ingerencji w kod źródłowy produktu.
Może wydawać się, że dla projektów składających się z dużej ilości modułów, procesów, wykonanie i utrzymywanie konfiguracji złożonej z wielu tabel może być problematyczne oraz czasochłonne. Dlatego podczas wdrożeń korzystamy z autorskich narzędzi zintegrowanych z arkuszami kalkulacyjnymi, które pozwalają usprawnić proces przygotowania, utrzymywania oraz archiwizacji konfiguracji na systemie klienta.
Dwa elementy docelowego rozwiązania
3. Architekturę rozwiązania dzielimy na dwie części nazywane przez nas „CORE” oraz „CUSTOM”.
a. CORE – surowy trzon rozwiązania w wybranej wersji. Zawiera standardowe dla produktu raporty, tabele, struktury oraz funkcjonalności. Tą część rozwiązania przenosimy na system klienta transportem zewnętrznym z naszego systemu źródłowego.
b. CUSTOM – wszelakie dostosowania produktu pod konkretny system klienta. Część architektury nazywana przez nas CUSTOM to zmiany „zetowe” wykonywane na systemie deweloperskim klienta. W tej części rozwiązania w zależności od projektu i potrzeb klienta wykonujemy dodatkowe prace takie jak:
- Modyfikacje modułów dostarczanych w standardzie rozwiązania
- Utworzenie dedykowanych raportów
- Obsługa połączeń i wymiany danych z webservice’ami
- Wykonanie dodatkowych rozszerzeń w standardzie SAP
- Dodawanie nowych funkcjonalności
- Obsługa niestandardowych plików charakterystycznych dla klienta
W celu zachowania zgodności kodu źródłowego tych samych wersji produktu, u naszych klientów części CORE nie modyfikujemy bezpośrednio na systemie klienta. Nie oznacza to tego, że nie możemy wykonać w niej żadnych modyfikacji. W przypadku zapotrzebowania na nową funkcjonalność lub modyfikację istniejącej w standardowej wersji produktu podchodzimy do zagadnienia w następujący sposób:
- Jeśli modyfikacja jest charakterystyczna dla procesu tylko u jednego klienta to wykonujemy ją w części CUSTOM tworząc nowy moduł, modyfikując istniejący przy użyciu mechanizmów programowania obiektowego lub standardowych dla SAPa operacji rozszerzania oraz dostosowujemy konfigurację.
- Jeśli modyfikacja ma potencjał zostać nową funkcjonalnością lub udoskonaleniem produktu, wówczas zmianę wcielamy do części CORE oraz wgrywamy ją u klienta jako „łatkę” do standardowej części rozwiązania.
Podsumowanie
Podsumowując powyższe założenia można zauważyć, że struktura naszych produktów w pewnym wymiarze przypomina wykorzystywane w wielu językach programowania – frameworki. Taki sposób przygotowania produktu przekłada się na większą elastyczność podczas wdrożenia. Najczęściej początkowy etap wdrożenia, którego zadaniem jest uruchomienie produktu, składa się z dwóch kroków – wgrania rozwiązania w wersji CORE oraz przygotowania konfiguracji. U znacznej mniejszości klientów pojawia się potrzeba dostosowania produktu do wersji systemu lub rozszerzenia go o zestaw dodatkowych, charakterystycznych dla klienta funkcjonalności. W przypadku wystąpienia potrzeby modyfikacji, dzięki przedstawionemu podejściu do projektowania produktu, możemy je w prosty sposób wprowadzać do rozwiązania.
Autor: Cezary Seta
