VIII Konferencja PLOUG
KoS
cielisko
Pax
dziernik 2002
Opracowanie modyfikacji do standardowej
funkcjonalnoS
ci Oracle E-Business Suite -
metodologia podejS
cia, opieka nad
wdrożonymi zmianami
referat sponsorski
Edyta Łakomy
Softbank S.A.
e-mail: [e-mail]
Abstrakt
Wdrożenie systemu zintegrowanego może być realizowane w różny sposób, jednak zawsze konieczne są mniejsze lub większe zmiany oraz
dodatkowe raporty, które przybliżą system do wymagań użytkowników. Podobnie jest w przypadku Oracle E-Business Suite, czyli zintegro-
wanego pakietu do zarządzania przedsiębiorstwem firmy Oracle. Specyfika tego pakietu warunkuje metody, które mogą być wykorzysty-
wane w procesie przygotowywania rozszerzeń i modyfikacji systemu. Czy w takim razie różni się wdrożenie systemu krajowego producen-
ta, od wdrożenia systemu produkowanego przez Oracle? Jak specyfika wdrożenia wpływa na prace programistyczne wykonywane podczas
projektu? Jakie są dopuszczalne metody modyfikowania systemu i jakie mogą być skutki ich stosowania?
 Opracowanie modyfikacji do standardowej funkcjonalności Oracle E-Business Suite... 233
1. Wstęp
Systemy zintegrowane, rozwiązania z półki, tej górnej, dolnej czy też średniej, są sprzedawane
jako gotowe rozwiązania, z wbudowanymi najlepszymi praktykami biznesowymi, uwzględnionymi
optymalnymi procesami wypracowanymi podczas licznych wdrożeń itp. Najczęściej rzeczywiście
posiadają te cechy, lecz pełne ich wykorzystanie zależy też od możliwości przeprowadzenia zmian
w przedsiębiorstwie nabywcy systemu. Zaś nie każda zmiana jest tak łatwa przeprowadzenia, jak
zaplanowano.
Rozszerzenia i modyfikacje funkcjonalności wprowadzane podczas wdrożenia są swego rodza-
ju kompromisem, między zachowaniem specyfiki firmy, dotychczasowych procedur, a zmianą i
dostosowaniem się do systemu.
Warto jako w tym miejscu porównać wady i zalety wyboru gotowego pakietu zintegrowanego
w stosunku do budowy systemu na zamówienie.
Po pierwsze, jeśli kupujemy system, to możemy go przed zakupem zobaczyć, przetestować, co
jest niewątpliwą zaletą w porównaniu do pisanych od początku rozwiązań, które można obejrzeć
dopiero po koniec procesu produkcji oprogramowania.. A jeśli użytkownicy zamawiający system
nie zostaną w pełni zrozumiani przez analityków, to efekt może być zaskakujący.
Po drugie, w przypadku większych i bardziej skomplikowanych przedsiębiorstw, zakupi wdro-
żenie gotowego systemu powinny być znacznie mniej kosztowne od przygotowania porównywal-
nego rozwiązania na zamówienie.
Po trzecie wreszcie, utrzymanie i rozwój gotowego system po wdrożeniu jest cały czas wspie-
rane przez jego dostawcę. System jest rozbudowywany, przygotowywane są nowe moduły, nowe
wersje, system jest dostosowywany do zmieniających się wymagań biznesowych i prawnych. Błę-
dy w systemie są naprawiane w ramach asysty technicznej. Nie jest więc potrzebny zespół utrzy-
mujący napisaną na specjalne życzenie aplikację. A w szczególności nigdy nie zaistnieje syndrom
niezastąpionego informatyka  a przecież jeszcze teraz niektóre bardzo poważne instytucje opiera-
ją swoją działalność na systemie napisanym przez jedną osobę, która nie miała nigdy czasu przy-
gotować dokumentacji....
Systemy pisane na zamówienie mają jednak jedna niezaprzeczalną zaletę mogą być dokładnie
takie jak chcą ich użytkownicy. Mogą mieć rożne bardzo specjalne funkcje, wyglądać tak, żeby
użytkownikom się podobało i mieć wbudowane właśnie te algorytmy, którymi posługiwali się jego
użytkownicy przed wdrożeniem systemu. Dlatego cały czas powstają systemy pisane na zamówie-
nie, bo bardzo wielu problemów nie da się rozwiązać zunifikowanym oprogramowaniem.
Mając w pamięci powyższe przesłanki zobaczmy, jak wdrożenie systemu przebiega i w którym
momencie zwyczajowo wykonywane są zmiany funkcjonalności.
2. Wdrożenie systemu zintegrowanego
Wdrożenie systemu zintegrowanego może przebiegać na różne sposoby, każda firma wdrażają-
ca, producent systemu posługują się swoimi metodami. Zasadniczo można podzielić systemy na
dwie grupy:
" Systemy wdrażane przez wiele firm, nie tylko producenta, zwykle duże, parametryzowane,
w których modyfikacje funkcjonalności w ramach wdrożenia są nieznaczne. Do takich sys-
temów należy Oracle E-Business Suite
234 Edyta A
akomy
" Systemy, których wdrożenie sprowadza się w znacznym stopniu do przepisania lub dopisa-
nia funkcjonalności. Zwykle są to małe systemy, choć zdarzają się również duże, wdrażane
tylko przez producenta.
2.1. Jak związek ma wdrażanie systemu przez wiele firm z modyfikowa-
niem systemu?
Dostawcy systemów zintegrowanych zapewniają opiekę nad wdrożonym systemem . Opieka
oznacza co najmniej poprawianie zgłaszanych błędów, a często także udostępnianie nowej funk-
cjonalności oraz nowych wersji systemu.
Jeśli dostawca musi opowiadać na pytania i rozwiązywać błędy w systemie wdrażanym przez
kilkunastu partnerów, to nie mogą oni zmieniać tego systemu w trakcie wdrożenia. Producent prze-
cież nie wie co się działo podczas wdrożenia i nie może rozwiązywać błędów np. w dopisanej
funkcjonalności. Dlatego systemy wdrażane przez firmy trzecie są zmieniane w minimalnym stop-
niu.
Natomiast jeżeli system jest wdrażany tylko przez producenta to podjęcie decyzji o zmianie
systemu jest znacznie łatwiejsze, bo programiści, którzy napisali system mogą go również zmienić,
a odpowiadanie na zgłoszenia błędów jest możliwe, gdyż formalna lub nieformalna dokumentacja
zmian jest w posiadaniu producenta.
Trzeba również pamiętać o aspekcie skali. Jeśli system jest wdrażany przez jedną firmę to licz-
ba wdrożeń ogółem na świecie jest o wiele mniejsza, niż gdy tych firm w skali światowej jest kil-
kadziesiąt.
2.2. Metodologia wdrożenia
Projektanci i programiści realizujący zmiany funkcjonalności systemu zintegrowanego dołącza-
ją do zespołu projektowego w określonym momencie realizacji projektu i zwykle nie są obecni
przy uruchamianiu systemu i oddawaniu do eksploatacji. Drugim momentem w cyklu życia syste-
mu zintegrowanego, w którym projektanci programiści pracują nad rozszerzeniem lub modyfikacją
funkcjonalności jest okres po uruchomieniu systemu. Najczęściej po dwa, trzy miesiące po uru-
chomieniu systemu, kiedy użytkownicy nabrali już pewnej wprawy w korzystaniu z funkcjonalno-
ści, pojawiają się nowe potrzeby wynikające z lepszego zrozumienia systemu przez użytkowników.
Najczęściej w tym czasie są opracowywane dodatkowe raporty.
Z punktu widzenia projektantów i programistów projekt wdrożenia systemu zintegrowanego nie
jest ciągły, chronologiczny i może sprawiać wrażenie chaotycznego procesu, w skutek którego
użytkownicy są niezadowoleni. Dlatego dla zrozumienia z
ródeł problemów i trudności związanych
z tworzeniem modyfikacji funkcjonalności systemu, dodatkowych raportów, ważne jest zrozumie-
nie metody wdrożenia i stosowanego podejścia.
Wdrożenie Oracle E-Business Suite zwykle przebiega według schematu pokazanego na rysunku
nr 1, charakteryzującym się wykorzystaniem prototypu systemu W różnych metodach wdrożenia
Oracle E-Business Suite prototyp ten pojawia się albo bardzo szybko, albo z pewnym opóz
nie-
niem, ale zawsze jest.
W następnych punktach zostały opisane poszczególne etapy projektu.
 Opracowanie modyfikacji do standardowej funkcjonalności Oracle E-Business Suite... 235
Budowa modyfikacji i rozszerzeń
Przygotowanie
Analiza i Wprowadzenie systemu
i przetestowanie Testowanie
projektowanie do eksploatacji
prototypu
Konwersja danych
Rys. 1. Schemat przebiegu projektu wdrożeniowego typowego dla OeBS
2.2.1. Analiza i projektowanie
W czasie analizy odbywają się spotkania z kluczowymi użytkownika mi systemu, wstępne
szkolenia pokazujące możliwości systemu. Kluczowi użytkownicy to te osoby, które zostały wy-
brane, jako najlepiej znające sposób funkcjonowania firmy w zadanym obszarze, są oni również
odpowiedzialni za opiniowanie proponowanych przez zespół wdrożeniowy rozwiązań. W przeci-
wieństwie do klasycznego projektu tworzenia oprogramowania na zamówienie nie musi w tym
przypadku być opracowywana analiza sytuacji obecnej, natomiast są opisywane, analizowane i
uzgadniane przyszłe procesy biznesowe. Wynikiem tego etapu projektu jest wynikająca z proce-
sów biznesowych konfiguracja systemu i specyfikacje dodatkowych ekranów i raportów. Specyfi-
kacje te będą w następnym kroku zostaną przekazane projektantom/programistom do realizacji.
W tym właśnie momencie pojawia się największe niebezpieczeństwo z punktu widzenia powo-
dzenia projektu. Konsultanci wdrożeniowcy bardzo często nie mają za sobą doświadczenia pro-
gramistycznego, najczęściej to osoby, które wcześniej zajmowały się obszarami merytorycznymi,
w których teraz wdrażają system. Tacy właśnie konsultanci wdrożeniowi najłatwiej znajdują
wspólny język z kluczowymi użytkownikami i dobrze rozumieją ich problemy. Są bardzo dobrymi
konsultantami wdrożeniowymi, ale nie wiedzą jak system działa  od środka i mogą zgodzić się na
pozornie proste zmiany funkcjonalności, które jednakże są nie wykonalne z punktu widzenia logiki
działania systemu. Te pierwsze specyfikacje funkcjonalne dla modyfikacji i rozszerzeń są krótkimi
opisami pożądanej funkcjonalności. Jednakże jeśli zostaną zaakceptowane przez kluczowych użyt-
kowników, a potem okaże się, że nie można ich zrealizować, to najprawdopodobniej zespół wdro-
żeniowy zostanie oskarżony o niekompetencję, nieznajomość systemu, a atmosfera pracy nad
wspólnym sukcesem pozostanie tylko wspomnieniem.
Czy można temu zaradzić?
Można uniknąć takiej sytuacji, jeśli konsultanci wdrożeniowi będą świadomi, że nie wszystko
jest technicznie możliwe (dlaczego o tym potem), a jednocześnie mają możliwość zasięgnięcia
opinii specjalisty, który będzie w stanie oszacować stopień trudności problemu i koszty jego reali-
zacji oraz oczywiście wykonalność.
Konsultanci wdrożeniowi muszą pamiętać, że system, który wdrażają ma swoje ograniczenia.
Jeśli od początku projektu będą w obawie przed zawodem i niezadowoleniem użytkowników za-
236 Edyta A
akomy
pewniać, że system wszystko posiada o co użytkownicy zapytają, to prezentacja prototypu będzie
wielkim rozczarowaniem.
2.2.2. Przygotowanie i przetestowanie prototypu
Przygotowany prototyp, czyli system sparametryzowany zgodnie z potrzebami określonymi w
czasie analizy, powinien być wystarczająco wypełniony danymi, aby umożliwić przejście w syste-
mie wszystkich procedur. Testy prototypu powinny być wykonane przez kluczowych użytkowni-
ków i mają one na celu weryfikację poprawności opracowywanego rozwiązania. Czasem zdarza
się, że testy te są wykonywane przez konsultantów wdrożeniowych. Zwykle taka sytuacja jest wy-
nikiem nie włączenia w prace projektowe kluczowych użytkowników i jest zapowiedzią kłopotów,
które objawią się nie akceptowaniem rozwiązania na testach akceptacyjnych, a potem strachu
przed pozostawieniem użytkowników sam na sam z systemem po zakończeniu wdrożenia.
Testy prototypu pokazują, jak w rzeczywistości system będzie działał i jeśli nawet w czasie
analizy konsultanci opowiadali o dostępnej funkcjonalności, a kluczowi użytkownicy przeszli sto-
sowne szkolenia, to zwykle pojawiają się uwagi dotyczące funkcjonowania systemu. Część z nich
będzie zrealizowana zmianami w parametryzacji, a inne zostaną opisane w specyfikacjach rozsze-
rzeń.
W prawidłowo prowadzonym projekcie wdrożeniowym na tym etapie kończy się zgłaszanie
modyfikacji i rozszerzeń funkcjonalności systemu w czasie wdrożenia, kolejne specyfikacje po-
wstaną już po oddaniu systemy do użytkowania.
2.2.3. Budowa
" W tym właśnie etapie powstają rozwiązania rozszerzające, modyfikujące funkcjonalność.
Przygotowywane są też interfejsy łączące aplikację z systemami zewnętrznymi. Budowa
modyfikacji i rozszerzeń może przebiegać w ogólnie znany sposób pokazany na rysunku nr
2, gdzie tworzony jest najpierw projekt funkcjonalny, potem projekt techniczny. Po czym
powstaje kod z
ródłowy, który jest testowany i odbierany.
Uzyskanie
akceptacji
użytkowników
Przygotowanie Przygotowanie
specyfikacji specyfikacji Programowanie Testowanie
funkcjonalnej technicznej
Uzyskanie
akceptacji
użytkowników
Rys. 2. Standardowy cykl przygotowywania programów
Często w takim podejściu inne osoby realizują wszystkie trzy elementy:
" projekt funkcjonalny  opracowuje konsultant wdrożeniowiec,
" projekt techniczny  opracowuje analityk/projektant systemowy,
" programowanie  opracowuje programista.
 Opracowanie modyfikacji do standardowej funkcjonalności Oracle E-Business Suite... 237
Ubocznym skutkiem takiego podziału zadań jest odsunięcie programisty realizującego zlecenie
od z
ródła tych wymagań i wprowadzenie dwu poziomów pośrednich. Analityk/projektant w pro-
jekcie przygotowania systemu na zlecenie analizuje wymagania użytkownika i po zakończeniu
analizy ma wizję działania systemu Na ile ta wizja jest zgodna z wyobrażeniami użytkowników
okaże się po napisaniu systemu w trakcie testów. W przypadku dopisywania niewielkich zmian do
systemu zintegrowanego (najczęściej są to raporty) osobą, która ma wizję efektu końcowego jest
kluczowy użytkownik, który zgłosił brak konkretnej funkcji.
W opracowywaniu zmian i rozszerzeń funkcjonalności systemu Oracle E-Business Suite warto
więc przyjąć inną organizację pracy. Pierwszy etap, czyli przygotowanie specyfikacji funkcjonal-
no-technicznej wykonują razem konsultant wdrożeniowiec i analityk/projektant, lub sam konsul-
tant o ile dysponuje wystarczającą wiedzą techniczną. Ich zadaniem jest opracowanie specyfikacji,
która byłaby z jednej strony możliwa do zaakceptowania przez kluczowego użytkownika zlecają-
cego pracę, a z drugiej byłby możliwa do wykonania od strony technicznej. W takiej organizacji
pracy konsultant wdrożeniowiec ma rolę tłumacza i mediatora, pośrednika umożliwiającego poro-
zumienie użytkownika z projektantem.
Uzyskanie
akceptacji
użytkowników
Przygotowanie
specyfikacji funkcjonalno - Programowanie Testowanie
technicznej
Uzyskanie
akceptacji
użytkowników
Rys. 3. Cykl przygotowywania rozszerzeń i modyfikacji funkcjonalności aplikacji
Skraca się również czas, w którym kluczowy użytkownik traci z oczu zleconą przez siebie mo-
dyfikacje. Każdy zabieg, który zbliża w skali czasu projekt z jego testami, jest bardzo korzystny z
punktu widzenia uzyskania aprobaty wykonanego programu.
Inną zmianą, która może ułatwić przygotowywanie modyfikacji jest połączenie roli anality-
ka/projektanta i programisty. Zwykle w projektach wdrożenia Oracle E-Business Suite nie ma
wielu modyfikacji i prace mogą być zrealizowane przez jedną, dwie doświadczone osoby. Jeśli
więc role projektanta i programista są rozdzielne, to nie będą mieli zapewnionej ciągłości pracy w
jednym środowisku, co zawsze wpływa ujemnie na rezultaty prac. Ponadto najczęściej wymagane
poprawki są niewielkie i programowanie każdej z nich zajmuje średnio około 4 dni. W taki przy-
padku czas poświęcony na przekazanie informacji, oraz zapoznanie się programisty ze specyfika-
cją (około 1 dzień) zaczyna być znaczący. Dodatkowo bardzo często przygotowanie dobrej specy-
fikację wymaga wskazania odpowiednich tablic, kolumn, formularzy, czy raportów, a stąd tylko
krok od napisania.
238 Edyta A
akomy
2.2.4. Testowanie
Testowanie składa się z dwóch części: przygotowania planu testów i jego wykonania. Dla po-
trzeb testów poprawności konfiguracji modułów przygotowywane są testy akceptacyjne. Zaakcep-
towanie ich wyników będzie równoznaczne z akceptacją sposobu działania systemu, a więc także
jego parametryzacji. W odróżnieniu od testów prototypu, testy akceptacyjne powinny być prze-
prowadzone na systemie zasilonym wcześniej prawdziwymi danymi przy wykorzystaniu wszyst-
kich zdarzających się w rzeczywistości przypadków. W ten sposób będą jednocześnie testować
poprawność danych po konwersji i funkcjonowanie programów ładujących je do systemu. Testy
akceptacyjne muszą również obejmować wszystkie elementy dopisane do systemu i jego modyfi-
kacje. W ten sposób modyfikacje zrealizowane z etapie budowy rozszerzeń zostaną po wstępnych
testach przetestowane w rzeczywistym środowisku.
Jest to szczególnie ważne w przypadku modyfikacji wprowadzających dane do systemu. OEBS
jest systemem skomplikowanym i łatwo mogą umknąć uwadze operacje, które typową są wykony-
wane na wstawianych danych ze znacznym opóz
nieniem (np. faktura korekta, czy zwrot towaru w
ramach gwarancji). Jeśli się w jakiś sposób zaburza naturalną logikę systemu, to trzeba bardzo
uważnie przetestowanć wszystkie możliwe operacje na danych. Dlatego modyfikacje muszą sta-
nowić część testów akceptacyjnych.
2.2.5. Konwersja danych
Etap konwersji danych obejmuje przygotowanie danych historycznych do załadowania i próbną
konwersja danych. Z doświadczenia wynika iż konwersja danych jest jednym z krytycznych punk-
tów projektu, musi być wcześnie przygotowana i starannie przetestowana. W szczególności dane
historyczne przed wprowadzeniem do systemu trzeba przejrzeć, zweryfikować i wyczyścić. Za
przygotowanie danych historycznych do konwersji odpowiedzialny jest odbiorca systemu. Kon-
wersja danych jest osobnym bardzo ciekawym tematem, jednakże ma niewielki wpływ na modyfi-
kacje i rozszerzenia systemu.
2.2.6. Wprowadzenie systemu do eksploatacji
Uruchomienie systemu następuje po udanym zakończeniu testów akceptacyjnych. W tym czasie
zostają również przeszkoleni wszyscy przyszli użytkownicy systemu. Dostarczana jest także do-
kumentacja systemu  podręczniki użytkownika dla każdego typu stanowiska oraz dokumentacja
techniczna dla dopisanych elementów systemu i opis parametrów dla wszystkich wdrożonych mo-
dułów.
Pierwsza prawdziwa weryfikacja poprawności wykonanego wdrożenia, a w szczególności wy-
konanie modyfikacji i rozszerzeń następuje z chwilą zamknięcia pierwszego miesiąca obrachun-
kowego. Drugi przełom to pierwsze zamknięcie roku. Dotyczy to wszystkich modułów, gdyż w ten
czy inny sposób spotykają się one w księdze głównej, która dla Oracle E-Business Suite jest ją-
drem systemu. Chodzi tutaj o weryfikację poprawności algorytmów realizowanych przez system w
tle. Na koniec miesiąca następuje pierwsze podsumowanie i weryfikacja krzyżowa informacji w
systemie, dlatego dopiero wtedy jest szansa na wychwycenie np. błędów zaokrągleń przy automa-
tycznym rozliczaniu kosztów dopisanym specjalnie na życzenie klienta.
Bardzo często przez pierwszy miesiąc praca prowadzona jest równolegle w dwu systemach sta-
rym i nowym. Każdy kto wdrażał system zna to uczucie paniki, kiedy po szczęśliwym zamknięciu
miesiąca i wydrukowaniu raportów ze starego i nowego systemu okazuje się, że się nie zgadza.
Pierwszą reakcją jest oczywiście podejrzenie, że nowy system z
le działa. Więc zaczyna się żmud-
ne sprawdzanie poprawności wszystkich modyfikacji, które mogły wpłynąć na wynik. Jeżeli mo-
dyfikacje okazują się poprawne, to przystępujemy do kroku drugiego, czyli analizy porównawczej
 Opracowanie modyfikacji do standardowej funkcjonalności Oracle E-Business Suite... 239
raportów i dochodzenia do tego, gdzie się nie zgadza i dlaczego. A potrafi się nie zgadzać bo na
przykład stary system błędnie zaokrąglał dane po przeliczeniu z waluty na złotówki.
3. Rozszerzenia i modyfikacje  w czym leży trudność
W poprzednim rozdziale omówiliśmy trudności organizacyjne i metodologiczne w wprowadza-
niu zmian do Oracle E-Business Suite. W tym punkcie skoncentrujemy się na aspektach technicz-
nych.
Bardzo wiele osób zna świetnie narzędzia programistyczne Oracle. Sposób wprowadzania
zmian jest też opisany w specjalnej dokumentacji udostępnianej przez Oracle. Dodatkowo w apli-
kacji można sprawdzić dla większości wyświetlanych pól, jakim kolumnom w bazie danych odpo-
wiadają. W skład systemu wchodzi też wiele raportów, które można zmieniać zamiast pisać nowe
od początku. Czemu więc wykonywanie modyfikacji jest trudne?
Pierwsza trudność leży w ograniczeniach stawianych programistom, których złamanie grozi
utratą przez klienta wsparcia aplikacji przez Oracle. Nie można zmieniać bazy danych, modyfiko-
wać i dodawać wyzwalaczy, warunków. Jest specjalna biblioteka udostępniona programistom,
która zawiera elementy do modyfikacji. Często zdarza się, że pozornie prosta do realizacji zmiana
staje się na skutek tych ograniczeń bardzo trudna do przeprowadzenia. Jeszcze trudniej jest wymy-
ślać drugie, bądz
trzecie rozwiązanie, jeśli wszędzie napotyka się na zakaz realizacji.
Druga trudność leży w przekonaniu doświadczonego programisty, że inaczej nie można. To
znaczy, że niezależnie od sensowności reguł ustalonych przez Oracle, musi ich przestrzegać, bo
jeśli zacznie się coś złego dziać z systemem to firma, w której system działa zgłosi błąd do asysty
technicznej Oracle. Jeśli okaże się, że system został zmieniony w nieautoryzowany przez Oracle
sposób to firma straci prawo do zgłaszania błędów do Oracle i otrzymywania rozwiązań. Nikt nie
zagwarantuje również, że uda się przejście do następnej wersji. A przecież między innymi właśnie
dlatego został kupiony system. W takim przypadku firma wdrażająca znajdzie się w poważnych
tarapatach. Klient może zażądać zadość uczynienia, przejęcia wsparcia aplikacji, lub wykonanie
jeszcze raz modyfikacji, tym razem w zgodzie z warunkami określonymi przez producenta syste-
mu.
Ryzyko takich rozwiązań bierze się głównie z faktu, iż aplikacje są napisane w ogólnie znanych
narzędziach programistycznych, a wiele osób, które programują modyfikacje do Oracle E-Business
Suite wcześniej pisało własne programy w tych samych narzędziach. Często są to także programu
o takiej samej tematyce. Trudno się dziwić, że jeśli ktoś kto napisał już samodzielnie moduł należ-
ności będzie nawet podświadomie czynił pewne założenia co do sposobu funkcjonalności
analogicznego modułu w Oracle E-Business Suite, a stąd już tylko krok do kłopotów.
4. Pożyteczne wiadomości
Oczywiście zmiany daje się bezpiecznie wprowadzać do Oracle E-Business Suite, wystarczy
tylko pamiętać o następujących punktach.
" Należy przeczytać Application Developer Guide.
" Wszelkie zmiany najlepiej jest wykonywać za pomocą raportów i wykorzystując możliwości
pól definiowalnych przez użytkownika w systemie (ang. descriptive flexfields). Dają one
bardzo duże możliwości sprytnych obejść systemu.
240 Edyta A
akomy
" Wprowadzenie przeliczonych danych do systemu najlepiej jest wykonywać poprzez stan-
dardowe interfejsy w systemie, nawet jeśli po przeliczeniu i zaczytaniu trafią do tej samej
tablicy. Zdarza się to na przykład w księdze głównej.
" Jeśli trzeba dołożyć kolumnę, tablicę to nie można dodawać jej do aplikacji, łączyć z stan-
dardowymi tablicami, nawet słownikowymi. Jedynym bezpiecznym rozwiązaniem jest napi-
sanie oddzielnego moduł lub mikro modułu (jednej tablicy i formatki do wprowadzania oraz
przeglądania danych).Moduł ten powinien się komunikować z standardową aplikacją po-
przez dostępne w aplikacji standardowe tablice interfejsowe, wykorzystując wbudowany w
Oracle E-Business Suite mechanizm zaczytywania z nich informacji.
" Należy unikać jak ognia wstawiania, modyfikowania danych bezpośrednio do tablic aplika-
cji.
" Nie można wykorzystywać kolumn, tabel, które są  puste , to znaczy nie zawierają żadnych
wierszy, a nie zostały opisane w dokumentacji jako definiowane na potrzeby konkretnego
użytkownika podczas wdrożenia. Taka tablica może być wstępem do jakiejś funkcjonalno-
ści, która pojawi się dopiero w następnej wersji systemu. A może stanie się potrzebna, gdy
zostanie zainstalowany nowy moduł Oracle E-Business Suite, który będzie ją wykorzysty-
wał do łączenia się z pozostałą częścią aplikacji.
" Jeśli modyfikacja jest trudna, lub też jest bardzo dużo różnych mniejszych zmian to oprócz
przeczytania dostępnych podręczników warto jest poprosić Oracle o weryfikację propono-
wanego rozwiązania.
" Jeśli przerabiamy raport to pozostawiamy pierwotną wersję, a nową dodajemy, nie zastępu-
jemy.
" Najlepiej jest opracowywać zmiany na kopii aplikacji produkcyjnej. Nawet ta sama wersja
zainstalowana w dwóch miejscach może się różnić w wyniku wgrania lub nie patcha.
" Przed zainstalowaniem zmiany na działającym już systemie należy zawsze wykonać kopię
zapasową. Jeśli użytkownicy zaczną pracować i aplikacja zacznie się zachowywać w dziwny
sposób ławo będzie można wrócić do stanu pierwotnego.
" Zawsze należy zostawić zamawiającemu dokumentację wykonanej zmiany.
5. A może nie trzeba?
Zanim zacznie się wprowadzać zmiany do aplikacji należy zadać sobie właśnie takie pytanie:
 A może nie trzeba? Zmiany często są wprowadzane dlatego, że system obsługuje daną funkcję w
inny sposób niż ten, do którego przywykli użytkownicy. Jeśli obydwa sposoby są równoważne,
albo dane jakie pozornie tracimy w wyniku rozwiązania proponowanego przez system, można
znalez
ć w innym miejscu, to watro poświęcić czas dyskusje z kluczowymi użytkownikami.
Najłatwiej jest wdrożyć standardową wersję systemu w firmach, które powstają. Wynika to z
prostego faktu, że jeśli kluczowi użytkownicy nie jeszcze przyzwyczajeni do sposobu działania
firmy, to łatwiej jest się im przystosować do procedur oferowanych przez system. OEBS ma duże
możliwości dostosowania się do wymagań użytkowników i dlatego we wdrożeniach wykonywa-
nych dla nowych firm, lub firm młodych duchem i skłonnych do zmian swoich procedur, modyfi-
kacje aplikacji daje się ograniczyć do dopisania dodatkowych raportów.
Warto w tym miejscu zwrócić uwagę na bardzo istotny aspekt wdrożenia, którym jest firma
wdrażająca. Zwyczajowo firmy o korzeniach informatycznych, integratorzy, producenci oprogra-
mowania łatwiej się zgadzają na wprowadzanie zmian do aplikacji niż firmy konsultingowe. Wy-
nika to z trudniejszej obrony własnych propozycji przez firmy specjalizujące się w usługach in-
 Opracowanie modyfikacji do standardowej funkcjonalności Oracle E-Business Suite... 241
formatycznych. Stwierdzenie:  Ja was nie pouczam jak macie pisać systemy, więc wy mi nie
mówcie jak mam robić moją pracę. lub  Ja od 20 lat się tym zajmuję. zamyka każdą dyskusję
merytoryczną. Można jednak spróbować włączyć do współpracy ekspertów specjalizujących się w
danej dziedzinie. Dla przykładu dla finansów może to być audytor firmy. Zwykle specjaliści, kon-
sultanci widzieli różne rozwiązania, które przyjęły firmy dla których pracowali. A
atwiej będzie ich
przekonać do nowego podejścia, a im z kolei łatwiej będzie przekonać użytkowników, że nowy
sposób będzie równie dobry i jego zastosowanie nie grozi zawaleniem się całego działu.
5.1. Raportowanie
Raportowanie jest ogromnym polem do tworzenia modyfikacji do standardowej wersji system.
W tym przypadku jak i poprzednio należy spytać, czy jest to konieczne. Najczęściej nie. Dużą
część wymagań użytkowników mogą oni zrealizować we własnym zakresie wykorzystując wyspe-
cjalizowane narzędzia. Z Oracle E-Business Suite współpracują dwie grupy narzędzi:
" Narzędzia oparte o wielowymiarową bazę danych Oracle Express. Najczęściej spotkanym
przykładem jest Oracle Financial Analyzer, połączony z księgą główną, z której dane zaczy-
tuje. Służy do tworzenia analiz finansowych w oparciu o dane przedstawiane w układzie
planu kont. Strukturę planu kont projektować również z myślą o informacji zarządczej, wte-
dy osoby odpowiedzialne za przygotowywanie i analizę informacji zarządczej będą mogły
potrzebne zestawienia realizować samodzielnie. W narzędziu tym można również przygoto-
wać zaawansowany system do budżetowania, w przypadku jeśli nie sprowadza się ono do
budżetowania na kontach, które może być zrealizowane w księdze głównej.
" Narzędzia oparte o Oracle Discoverer. W oparciu o tę technologię został opracowany Oracle
Business Intelligence System, który jest integralną częścią Oracle E-Business Suite, i obej-
muje swym zakresem prawie wszystkie moduły min. w Oracle HRMS, Oracle Sales Online,
Oracle Maketing Online. Narzędzie to zapewnia dostęp do przygotowanych roboczych ob-
szarów, w których użytkownicy widzą dane rejestrowane w systemie i mogą wykorzystywać
je w budowie raportów.
5.2. Oszukać system
Sposobem realizacji modyfikacji, który wymaga bardzo dobrej znajomości aplikacji, a jedno-
cześnie żyłki odkrywcy-tropiciela jest oszukiwanie systemu, czyli wykorzystywanie standardo-
wych mechanizmów w niestandardowy sposób. Wymaga to ze strony konsultantów wdrożenio-
wych świetnej znajomości systemu i poświęcenia czasu na przeszukanie standardowo nie używa-
nych opcji, które są niekiedy eleganckim rozwiązaniem problemu. Konsultanci muszą też mieć
czas na doskonalenie swojej znajomości poszczególnych modułów systemu oraz zmian wprowa-
dzanych przez kolejne wersje.
Takie poszukiwania kończą się niekiedy znalezieniem rozwiązania, które mogło być użyte w
zakończonych już projektach. Najczęściej tak jest w przypadku wdrażania bardzo nowej wersji.
Nie ma jeszcze doświadczeń związanych z jej wdrażaniem, zaś dodatkowa funkcjonalność nie jest
dość wyczerpująco opisana w dokumentacji.
6. Utrzymanie zmian
Zmiany, które zostały wprowadzone do systemu wymagają konserwacji. Nie wynika to tylko z
nowych wymagań użytkowników, ale też z konieczności dostosowania ich do zmieniającego się
systemu. Oczywiste jest, że zmiana wersji systemu może spowodować konieczność przepisania
modyfikacji, czemu poświęcony jest następny rozdział. Należy też pamiętać, że każda instalacja
242 Edyta A
akomy
łatki dostarczonej przez producenta może spowodować problemy związane z poprawnym wyko-
nywaniem się modyfikacji. Zwykle wygląda to w ten sposób, że w jakiś czas po zgłoszeniu błędu
do działu wsparcia technicznego Oracle otrzymujemy łatkę, która powinna ten błąd zlikwidować.
W takim przypadku robimy kopię bazy produkcyjnej i na tak przygotowanym środowisku testo-
wym instalujemy przysłaną łatkę. Po zakończonej sukcesem instalacji trzeba przetestować, czy
system działa poprawnie i czy zniknął zgłoszony błąd. Nie będziemy tutaj rozpatrywać wszystkich
możliwych przypadków tego, co się dzieje dalej. Z punktu widzenia modyfikacji, najciekawszy
jest przypadek, kiedy wszystko działa oprócz zmiany zrobionej w systemie. W takim przypadku
trzeba oczywiście tę modyfikację poprawić (o ile ktoś z niej korzysta).
Jeśli taka sytuacja zdarzy się podczas wdrożenia, to wykonanie zmian w modyfikacji spada na
firmę wdrażającą. Natomiast po zakończeniu wdrożenia zmiana może zostać wykonana przez
technicznego opiekuna systemu, firmę która pierwotnie wykonała zmianę lub inną firmę. W każ-
dym z tych przypadków do szybkiego naniesienia zmiany niezbędna jest dokładna i rzetelna do-
kumentacja. Zadaniem wykonawcy wdrożenia jest ją dostarczyć, a klient jest zobowiązany do do-
pilnowania jej jakości i istnienia.
6.1. Inne moduły
Zdarzają się sytuacje, w których wdrożenie nowego modułu Oracle E-Business Suite zmienia
działanie systemu i powoduje, że wykonana modyfikacja przestaje działać. Szczególnie duże ryzy-
ko takiego problemu pojawia się w sytuacji kiedy dodatkowy moduł jest doinstalowywany po za-
kończeniu wdrożenia.
Oczywiście wzrasta wtedy także ryzyko utraty stabilności przez aplikację, ale nie będziemy tu-
taj omawiać tego aspektu.
Najlepszą metodą zabezpieczenia jest w takim przypadku wykonanie instalacji wszystkich do-
celowo wdrażanych modułów na początku projektu, mimo że w pierwszej fazie wdrożona zostanie
tylko część z nich.
6.2. Zmiana wersji systemu
Zmiana wersji systemu prawie zawsze wiąże się z przerabianiem przynamniej części modyfika-
cji. W przypadku poprawnie wykonanych zmian w systemie nie powinny występować problemy
z przeniesieniem bazy danych rozumianej jako zbiór obiektów występujących w standardzie. Po
przejściu do nowej wersji można spróbować zainstalować po kolei modyfikacje testując każdą
z nich oddzielnie.
Trzeba się jednak liczyć z koniecznością przerobienia modyfikacji i zastanowić się przed zmia-
ną wersji systemu kto i jak ma to zrobić.