2010.05_Wdrożenia SAP – droga przez mękę_[Aplikacje Biznesowe].pdf - Aplikacje Biznesowe - Kapy97

Aplikacje biznesowe

droga przez mękę?

Co może się nie udać?

Wdrażanie systemu SAP jest przedsięwzięciem wymagających ścisłej

współpracy ze strony firmy wdrożeniowej i klienta. Rozwiązania typu

SAP posiadają z reguły gotową funkcjonalność podstawową ogólną lub

dedykowaną dla danej branży.

Dowiesz się:

• Jak wygląda proces wdrożenia systemu SAP

Business One;

• Jakie problemy możesz napotkać w proce-

sie wdrożenia SAP.

Powinieneś wiedzieć:

• Podstawowa wiedza z zakresu zarządzania

projektem informatycznym;

• Podstawowa wiedza z zakresu wdrożeń sys-

temów klasy ERP

• Etap rozwoju rozwiązania biznesowego

w systemie SAP.

Każdy etap składa się z faz. I tak, etap

przedwdrożeniowy obejmuje dwie fazy:

Poziom

trudności

a produkty poszczególnych etapów uzgod-

nione z klientem.

Organizacja procesu wdrożeniowego jest

z reguły poniekąd narzucona przez produ-

centa rozwiązania SAP BO – który, ba-

zując na doświadczeniu wielu projektów

wdrożeniowych oraz wypracowanych naj-

lepszych praktykach, udostępnia partne-

rom (czyli z punktu widzenia klienta, fir-

mom wdrożeniowym) metodologię wdro-

żeniową.

W niniejszym artykule przedstawimy

opis metodyki wdrożenia systemu SAP Bu-

siness One (oparty na dokumencie Zinte-

growanej koncepcji wdrożenia i funkcjono-

wania opracowanej przez SAP AG).

• Faza 0 - Przygotowanie sprzedaży sys-

temu. W tej fazie wykonywana jest

ocena projektu wdrożeniowego SAP

BO przez irmę wdrożeniową oraz po-

dejmowana decyzja o zakupie syste-

mu. W wyniku fazy powinna powstać

wstępna ocena projektu wdrożenio-

wego – czyli m.in. dokument opisu-

jący zakres organizacyjny, opis proce-

sów biznesowych, które zostaną obję-

te rozwiązaniem SAP oraz dokumenty

zarządcze w postaci wstępnego harmo-

nogramu oraz budżetu.

• Faza 1 – Określenie wymagań. Celem

tej fazy jest pozyskanie wymagań klien-

ta co do zakresu i funkcjonalności roz-

wiązania SAP. Wymagania te będą sta-

nowić podstawę projektu wdrożenio-

wego. Identyikacja wymagań może

być wykonana na dwa sposoby: poprzez

opracowanie dokumentu Opis wyma-

gań lub przeprowadzenie szczegółowej

analizy, wyniku której powstaje doku-

ment Analizy Przedwdrożeniowej . Opis

wymagań jest zestawieniem wszystkich

wymagań klienta i obejmuje zazwyczaj:

procesy biznesowe danej organizacji,

które mają być wspomagane systemem

SAP, dokumenty tworzone w systemie,

raporty wykorzystywane przez użyt-

kowników końcowych, specyikę da-

nych przetwarzanych przez system.

ki powinien być odpowiednio

skonfigurowany, dostosowany

do potrzeb danej organizacji i - jeśli zacho-

dzi taka potrzeba - rozszerzony dodatko-

wymi modułami. Dopiero wtedy realizuje

procesy biznesowe klienta i w pełni spełnia

oczekiwania użytkowników.

Zaniedbanie którejkolwiek z kluczo-

wych czynności przewidzianych w metody-

ce wdrożeniowej może spowodować nie tyl-

ko opóźnienie w realizacji projektu, ale i cał-

kowite jego fiasko.

Niniejszy artykuł przedstawia wybrane

problemy mogące pojawić się w trakcie re-

alizacji projektu oraz sugerowane sposoby

ich rozwiązywania.

Podobnie jak w przypadku standardo-

wych projektów wytwarzania oprogramo-

wania, proces wdrażania nie może odbywać

się ad hoc , bez określonych zasad, reguł i wy-

tycznych. Firma wdrożeniowa nie może po

prostu zainstalować produktu SAP w środo-

wisku klienta bez uprzedniej analizy wyma-

gań, zaprojektowania rozwiązania i przete-

stowania go. Cały proces powinien być sta-

rannie zaplanowany, podzielony na etapy,

Metodyka wdrażania SAP BO

Metodyka dzieli projekt wdrożeniowy na fa-

zy, w ramach których realizowane są kroki

wdrożenia ze szczególnym uwzględnieniem

kamieni milowych, związanych z powstawa-

niem konkretnych produktów projektu oraz

ich odbiorem przez klienta.

Jednym z kluczowych założeń realiza-

cji projektu wdrożeniowego według przed-

stawionej metodyki jest współpraca klienta

(szczególnie grupy wdrożeniowej) z zespo-

łem konsultantów firmy wdrożeniowej.

Metodyka wdrożeniowa SAP Business

One obejmuje trzy etapy:

Analiza przedwdrożeniowa charakteryzu-

je się większym stopniem szczegółowości,

niż sam opis wymagań. Podstawowym jej

celem jest identyikacja procesów bizneso-

• Etap przedwdrożeniowy;

• Etap wdrożenia;

05/2010

Wdrożenia SAP –

W trakcie wdrożenia produkt ta-

Wdrożenia SAP

wych oraz funkcjonalności objętych plano-

wanym wdrożeniem. Analiza ta skupia się

na określeniu procesów i powiązań mię-

dzy nimi. Obejmuje nie tylko procesy, któ-

re będą objęte wdrożeniem i są realizowa-

ne w standardzie SAP BO, ale i wymagają-

ce specjalnych rozwiązań poza standardem

SAP BO. W wyniku analizy przedwdroże-

niowej określane są również interfejsy do

innych systemów oraz raporty i dokumen-

ty produkowane przez projekt wdrożenio-

wy. Analizę wykonuje zespół wdrożeniowy

(dostawca SAP BO), wymagana jest jednak

ścisła współpraca klienta.

W wyniku fazy 1 powstaje dokument

Opis wymagań lub dokument Anali-

za przedwdrożeniowa, uzgodniony przez

klienta i firmę wdrożeniową. Kolejnym eta-

pem jest etap wdrożenia. Obejmuje on na-

stępujące fazy:

dukty dostawcy wspomagające standar-

dową funkcjonalność SAP). Prace insta-

lacyjne dokumentowane są w Dokumen-

tacji projektu klienta.

• Faza 3 – Szkolenie grupy wdrożeniowej

(czyli użytkowników ze strony klienta).

Zakres szkolenia jest inny w zależności

od odbiorców – cała grupa wdrożenio-

wa otrzymuje ogólną prezentację syste-

mu SAP BO, natomiast specjaliści da-

nego obszaru (np. Kadry i Płace) biorą

udział w warsztatach funkcjonalnych

przedstawiających dany obszar oraz po-

wiązania z innymi modułami rozwiąza-

nia.

• Faza 4 – Przygotowanie rozwiązania

biznesowego w SAP BO. Polega to na

opracowaniu koncepcji rozwiązania

biznesowego(rozumianego jako spo-

sób realizacji procesów), odpowiedniej

koniguracji systemu SAP BO i ewentu-

alnym przygotowaniu elementów roz-

wiązania poza standardem SAP (w ra-

mach Dokumentacji projektu klienta ),

przygotowaniu scenariuszy testowych

i przetestowaniu gotowego systemu.

W zakres prac wchodzi też określenie

i skonigurowanie ról oraz uprawnień

użytkowników. Dostosowanie systemu

do wymagań oraz koniguracja jest za-

daniem irmy wdrożeniowej; testy na-

tomiast powinny być wykonane przez

klienta.

• Faza 5 – Przygotowanie systemu SAP

BO do pracy. Celem tej fazy jest przygo-

towanie rozwiązania do produktywnej

pracy w organizacji klienta. Zadanie to

obejmuje: sinalizowanie przygotowa-

nia raportów i dokumentów, przygoto-

wanie interfejsów oraz migrację danych

z dotychczasowych systemów. Dodat-

kowo, dostawca (lub sam klient – zależ-

nie od ustaleń) opracowuje dokumenta-

cję dla użytkowników końcowych oraz

realizuje zaplanowane szkolenia. Wy-

konywane są też całościowe testy roz-

wiązania celem weryikacji popraw-

ności funkcjonalności. Zakończeniem

prac jest wykonanie audytów – przygo-

towania użytkowników do pracy z sys-

temem oraz samego systemu: jego goto-

wości do pracy w środowisku produk-

cyjnym.

• Faza 6 – Nadzór nad pracą produktyw-

ną systemu. Polega na wyłączeniu do-

tychczasowych systemów (które zosta-

ły zastąpione rozwiązaniem SAP BO)

i przejściu na obsługę procesów wdro-

żonym systemem SAP. Zaleca się rów-

nież, by dostawca czuwał nad zamknię-

ciem pierwszego okresu rozrachunko-

wego w działaniu systemu. Zakończe-

niem fazy jest protokół zamknięcia pro-

jektu wdrożeniowego SAP BO.

• Faza 1 – Organizacja projektu. Celem

tej fazy jest zorganizowanie projektu

wdrożeniowego – w zakresie zarządza-

nia, zasobów, logistyki, etc. Faza ta roz-

poczyna się określeniem Sponsora pro-

jektu oraz powołaniem przez klienta

Koordynatora projektu i grupy wdro-

żeniowej odpowiedzialnej za wdroże-

nie SAP BO w organizacji. Ze strony

dostawcy powoływany jest Kierownik

Projektu oraz zespół konsultantów. Kie-

rownik Projektu opracowuje dokument

Karty Projektu wdrożenia SAP BO, któ-

ry obejmuje m.in. strategię wdrożenia,

podstawowe i dodatkowe cele bizneso-

we projektu oraz jego uzasadnienie biz-

nesowe, krytyczne czynniki powodze-

nia projektu, ryzyka, zakres (na podsta-

wie wyników etapu przedwdrożenio-

wego np. Analizy Przedwdrożeniowej),

ramowy oraz szczegółowy harmono-

gram, procedury oraz środowisko tech-

niczne projektu. Ponadto, Kierownik

Projektu inicjalizuje Dokumentację pro-

jektu klienta (czyli rozwiązań projekto-

wych) oraz Dziennik Projektu (czyli do-

kument realizacji projektu). Dokumen-

ty te będą w dalszym ciągu uzupełnia-

ne przez konsultantów. W fazie 1 okre-

ślane są również potrzeby szkoleniowe

grupy wdrożeniowej i użytkowników

końcowych systemu.

• Faza 2 – Instalacja systemu SAP BO.

Celem tej fazy jest zainstalowanie roz-

wiązania SAP w środowisku klienta.

W tej fazie przygotowywane jest śro-

dowisko techniczne (na podstawie wy-

ników analizy potrzeb sprzętowych dla

wdrożenia systemu wykonanej w fazie

przedwdrożeniowej), po czym insta-

lowane oprogramowanie SAP BO oraz

ewentualnie inne aplikacje (np. pro-

Ostatnim etapem projektu wdrożeniowe-

go jest etap rozwoju rozwiązania bizneso-

wego w systemie SAP BO. Rozwój obejmu-

je jedną fazę:

• Faza 1 – Przygotowanie i uruchomie-

nie funkcjonalności rozszerzonej SAP.

Obejmuje to określenie zakresu funk-

cjonalności rozszerzonej i sporządze-

nie odpowiedniej umowy pomiędzy

stronami, opracowanie funkcjonalności

rozszerzonej oraz procedur testowych,

przetestowanie rozwiązania i przeka-

Analiza przedwdrożeniowa

Analiza przedwdrożeniowa realizowana jest w czterech krokach. Oto one:

1. Przygotowanie się klienta do wywiadów

Zanim irma wdrożeniowa przystąpi do wywiadów umożliwiających wykonanie analizy,

klient musi się odpowiednio przygotować. Obejmuje to zebranie następujących informacji:

schemat organizacyjny przedsiębiorstwa klienta, przebieg procesów biznesowych, obieg

dokumentów oraz raportów.

2. Przeprowadzenie wywiadów

Przeprowadzenie wywiadów jest zadaniem irmy wdrożeniowej. Celem wywiadu jest zebra-

nie informacji niezbędnych do określenie procesów biznesowych i funkcjonalności objętych

wdrożeniem oraz interfejsów stałych, raportów, formularzy i dokumentów. W ramach anali-

zy przedwdrożeniowej należy również ustalić wymagania sprzętowe dla wdrożenia systemu

SAP BO. Prowadzący wywiad powinni także umieć na bieżąco wychwycić niespójności oraz

próbować wyjaśnić ewentualne wątpliwości (np. co do zakresu wdrożenia).

3. Opracowanie dokumentu Analizy przedwdrożeniowej

Informacje zebrane w trakcie wywiadów są podstawą do opracowania dokumentu Analizy

przedwdrożeniowej. Przygotowanie dokumentu jest zadaniem irmy wdrożeniowej.

4. Akceptacja dokumentu Analizy przedwdrożeniowej

Samo przygotowanie dokumentu Analizy przedwdrożeniowej nie stanowi podstawy do

podjęcia dalszych prac projektowych. Dokument musi być zatwierdzony przez klienta oraz

irmę wdrożeniową.

www.sdjournal.org

Aplikacje biznesowe

zanie rozszerzenia do pracy na produk-

cji. W razie konieczności wykonywane

jest też wyłączenie starych systemów,

zastępowanych przez funkcjonalność

rozszerzoną. W wyniku fazy otrzymu-

je się funkcjonalność rozszerzoną syste-

mu oraz protokół zamknięcia projektu

wdrożenia funkcjonalności rozszerzo-

nej systemu SAP.

kanie ewentualnych luk lub problemów (np.

procesów, których SAP nie wspiera, brakują-

cych danych) i wspólne z klientem znalezie-

nie rozwiązania.

Ustalone i zaakceptowane wymagania

stanowią podstawę do zaplanowania prac

i opracowania projektu rozwiązania – dla-

tego też niezmiernie ważne jest, by były

określone prawidłowo i kompletnie. Odpo-

wiedzialność identyfikacji wymagań leży

w głównej mierze po stronie firmy wdroże-

niowej, jednak nie jest możliwa bez ścisłej

współpracy klienta. I tu pojawia się kolejny

problem – brak zaangażowania przedstawi-

cieli klienta w prace związane z projektem

wdrożeniowym. Brak zaangażowania nieko-

niecznie musi wynikać z lekceważenia całe-

go przedsięwzięcia lub negowania potrzeby

i zasadności wdrożenia – zazwyczaj wiąże

się po prostu z brakiem czasu pracowników

klienta. Nie każda firma chcąca wdrożyć

SAP BO ma możliwość oddelegowania ze-

społu pracowników do wspierania prac do-

stawcy – czasem, by nie zaburzać stabilno-

ści i ciągłości bieżącej pracy, pracownicy wy-

stępują jedynie w roli konsultantów, mogąc

poświęcić dostawcy wyznaczoną ilość cza-

su (i ani godziny więcej), wykonując jedno-

cześnie swoje normalne obowiązki. W przy-

padku wdrożeń realizowanych w dużych or-

ganizacjach, obejmujących wiele złożonych

procesów biznesowych, może to nie wystar-

czać – i firma wdrożeniowa skazana jest na

długie oczekiwanie na odpowiedź w kluczo-

wych kwestiach, lub na domyślanie się prawi-

dłowego rozwiązania.

Poniżej opisano dokładniej najczęściej po-

jawiające się problemy oraz możliwe sposo-

by przeciwdziałania im.

Ryzyko w implementacji

systemu SAP BO

Problemy z wdrożeniem systemu SAP BO

mogą pojawiać się na kilku płaszczyznach.

Najczęstszymi – i jednocześnie najbardziej

krytycznymi dla powodzenia projektu – są

zagrożenia związane z prawidłowym pozy-

skaniem i zaimplementowaniem wymagań.

Określenie wymagań wymaga dogłębnego

zrozumienia procesów biznesowych w orga-

nizacji klienta, zidentyfikowanie procesów,

które mogą być objęte rozwiązaniem SAP

BO, zweryfikowanie, w jakim stopniu SAP

umożliwi realizację tych procesów, wyszu-

Brak zaangażowania

przedstawicieli klienta

Zdarzają się sytuacje, w których klient zle-

ca dostawcy wdrożenie systemu SAP BO,

dostarcza wstępną listę wymagań, po czym

uważa, że jego rola w procesie się skończy-

ła – a reszta należy już do firmy wdrożenio-

wej. Zdarzają się również sytuacje, w któ-

rych klient nie zapewnia wystarczające-

go wsparcia swoich pracowników w proce-

sie analizy przedwdrożeniowej, wychodząc

z założenia, iż rolą dostawcy jest opracowa-

nie analizy lub – po prostu – nie chcąc od-

rywać swojego personelu od właściwych za-

dań. W wyniku takiego podejścia, dostawca

nie jest w stanie poprawnie zidentyfikować

wymagań i, co za tym idzie, zaimplemen-

tować rozwiązania odpowiadającego ocze-

kiwaniom odbiorców. Argumenty w stylu

„potrzebujemy wsparcia Waszych pracowni-

ków, by określić, co dokładnie system ma ro-

bić, jakie procesy wspierać, jakie dokumen-

ty i w jakiej postaci produkować” nie zawsze

odnoszą pożądany skutek.

Co można zrobić?

Najlepszą metodą jest po prostu uświa-

domić klientowi złożoność i mnogość do-

stępnych w SAP funkcji – wiele z nich nie

jest klientowi potrzebnych, inne muszą zo-

stać odpowiednio dostosowane do potrzeb

i oczekiwań użytkowników. Dostawca nie

jest w stanie przewidzieć wymagań wyni-

kających ze specyfiki danej branży i przed-

siębiorstwa – nawet jeśli posiada spore do-

świadczenie we wdrażaniu rozwiązań SAP

BO w danym obszarze. Może zaproponować

rozwiązanie, dostarczyć swoich uwag – ale

to klient jest stroną decydującą o ostatecz-

nym kształcie wymagań.

Dostawca powinien uświadomić kliento-

wi, iż bez jego wsparcia projekt jest z góry ska-

zany na niepowodzenie – określić ryzyko wy-

nikające z niepełnej lub niepoprawnej identy-

fikacji wymagań, jego późniejsze skutki w po-

staci zmian do funkcjonalności, opóźnień

wynikających z konieczności poprawy czy

zmiany dotychczasowych wymagań etc.

Rysunek 1. Etapy projektu wdrożeniowego

Rysunek 2. Dokumenty projektowe

05/2010

Wdrożenia SAP

Nieadekwatna

dokumentacja systemu

Załóżmy, że jesteś Kierownikiem Projektu

mającego na celu wdrożenie systemu SAP

BO u klienta. Twój zespół zaczyna groma-

dzić wymagania systemu od użytkowni-

ków. Po uzyskaniu wszystkich potrzebnych

informacji, dochodzisz do wniosku, iż po-

siadasz wystarczające dane do implementa-

cji „docelowego” systemu. A ponieważ ro-

zumiesz działanie „docelowego” systemu,

wiesz, jak ma funkcjonować i jakie są wyma-

gania względem niego – zapominasz o udo-

kumentowaniu „bieżącego” systemu (czy-

li systemu, który będzie zastąpiony rozwią-

zaniem SAP).

Podczas testów akceptacyjnych okazuje

się, że system nie spełnia oczekiwań użyt-

kowników końcowych, a uczestnicy testów

UAT nie są w stanie walidować Twojego roz-

wiązania. Klient jest rozczarowany propono-

wanym rozwiązaniem – a Ty musisz teraz

udowodnić, że zaimplementowane rozwią-

zanie SAP jest zgodne z potrzebami bizne-

sowymi i wymaganiami. Znajdujesz się w sy-

tuacji, w której nie możesz wyjaśnić, w jaki

sposób nowe rozwiązanie SAP ma taką sa-

mą – lub rozszerzoną – funkcjonalność po-

przedniego systemu. Padają pytania – jak

SAP zastępuje funkcjonalność starego syste-

mu, i czy w ogóle to robi?

Co można zrobić?

Określ, czy istnieje dokumentacja w po-

staci specyfikacji funkcjonalnej, diagramów

architektury, diagramów przepływu proce-

su opisująca obecną funkcjonalność syste-

mu. Współpracuj z klientem – w szczegól-

ności z programistami, którzy projektowali

stary system – by zrozumieć niuanse i ob-

szary wysokiego ryzyka w systemie, który

będzie zastępowany rozwiązaniem SAP. Do-

kumenty, które zgromadzisz, pozwolą po-

znać obecny system oraz w dużym stopniu

zdeterminować sposób zastąpienia starego

systemu nowym.

Opracuj wstępne przypadki testowe, któ-

re w szczególności weryfikują, w jaki sposób

przetestować funkcje starego systemu zastą-

pione rozwiązaniem SAP. Przypadki te po-

winny być skontrolowane przez uczestni-

ków testów UAT. Dokumentuj każdą infor-

mację zwrotną od recenzentów i (w miarę

możliwości) postaraj się stworzyć prototyp

docelowego rozwiązania – tak, by umożli-

wić użytkownikom końcowym wgląd w no-

wą funkcjonalność i jak najszybsze dostar-

czenie uwag co do stopnia spełnienia oczeki-

wań wobec systemu.

Wymagania powinny skupić się na tym, co

system będzie robił – i to dość dokładnie.

Organizacje, które przymierzają się do

wdrożenia SAP BO, często zaczynają od

określania wymagań – zamiast najpierw

zorientować się w funkcjonalności systemu

– i w efekcie wymagania mają się nijak do

możliwości systemu SAP.

Niektóre firmy mają w zwyczaju doku-

mentować wymagania w postaci plików

Excel – to utrudnia śledzenie wymagań

(zwłaszcza historii zmian), zmiany treści

wymagań i efektywne komunikowanie ich

do zaangażowanych osób, określanie właści-

cieli wymagań, tworzenie RTM (macierz śle-

dzenia wymagań), wreszcie – zarządzanie

cyklem życia wymagań.

Instytucja wdrażająca SAP jest później

obarczona zadaniem interpretacji wyma-

gań spisanych w Excelu, planowaniem im-

plementacji wymagań i weryfikacji stopnia

pokrycia wymagań testami. Dostawca SAP

zamiast skupić się na uszczegóławianiu wy-

magań, traci wiele czasu na zarządzanie sa-

mą listą i niemal na ślepo próbuje imple-

mentować wymagania w treści określonej

przez klienta – nawet jeśli niektóre z nich są

niepotrzebne, niezgodne z funkcjonalnością

SAP lub wręcz niemożliwe do realizacji.

W czasie testów, lub później – po insta-

lacji systemu SAP BO, często rozpoczynają

się debaty na temat funkcjonalności rozwią-

zania – które nie spełnia wymagań określo-

nych w Excelu, a użytkownicy końcowi tra-

cą zaufanie do aplikacji.

Co można zrobić?

Jeśli organizacja, w której wdrażasz SAP BO,

wykonuje testy oparte na wymaganiach, za-

proponuj narzędzie zarządzania wymaga-

niami ( Requisite Pro, Caliber-RM ). Dopracuj

wszystkie wymagania, upewnij się, że każde

jest wystarczająco zrozumiane i dla każdego

można określić atrybuty: wykonalność, ko-

nieczność, spójność, kompletność, priory-

tet, poprawność, możliwość śledzenia, jed-

noznaczność.

Zaprezentuj swoje (i zespołu wdroże-

niowego) zrozumienie wymagań za pomo-

cą diagramów przepływu procesu oraz po-

przez sesje przeglądowe. Wymagania, które

nie mogą być zaimplementowane, powinny

być oznaczone jako wyłączenia. Wymagania

spoza zakresu projektu wdrożeniowego na-

leży komunikować zespołowi .

Najprawdopodobniej wymagania nie osią-

gną nigdy stanu „perfekcji” (gdyż to mogło-

by sparaliżować projekt), lecz powinny być

zdefiniowane jasno i zrozumiałe – tak, by ze-

spół mógł kontynuować prace z akceptowal-

nym poziomem ryzyka (w przeciwieństwie

do prowadzenia prac implementacyjnych na

podstawie wymagań będącym jedynie hasła-

mi). Po osiągnięciu akceptowalnego poziomu

ryzyka, zespół funkcjonalny może rozpocząć

konfigurację systemu, a zespół techniczny

– implementację nowych aplikacji.

SAP – ale po co mi to? Korzyści.

SAP to nie tylko sprawniejsza rejestracja i wystawianie dokumentów. To nie tylko repozyto-

rium danych.

Sedno korzyści z systemu SAP polega na zupełnie nowej jakości i szybkości informacji, któ-

re kierownictwo otrzymuje do dyspozycji. Dzięki tym danym można decydować o zmianach

cen, ofert, dostawców, można również zapobiegać zmniejszeniu płynności inansowej.

System SAP umożliwia wyraźną poprawę gospodarki środkami inansowymi. SAP wspiera za-

rządzanie budżetem poprzez prognozy kosztowe i przepływowe. Prognoza płynności wspo-

maga decyzje w zakresie inansowania działalności bieżącej. Raporty prezentowane przez

system mogą w dowolnym momencie dostarczyć informacji o planowanych datach wpły-

wu należności i koniecznych płatnościach – co pozwala zarządzać bieżącymi rozrachunkami

z klientami i dostawcami. Dzięki temu można świadomie i kompleksowo kształtować polity-

kę kredytu kupieckiego, bez obaw o utratę płynności.

Ogromną korzyścią rozwiązania SAP jest możliwość stworzenia kompleksowego, efektyw-

nego systemu kontrolingu, w odróżnieniu od tradycyjnych aplikacji księgowych, niezinte-

growanych z obszarem zaopatrzenia i sprzedaży irmy. Dzięki SAP można w pełni realizo-

wać postulat kontrolingu – sterowanie wszystkimi działaniami w irmie, które dają podstawę

efektywnego podejmowania decyzji i w efekcie pozwalają na osiągnięcie zysku.

System SAP zapewnia precyzyjne i aktualne informacje o rentowności poszczególnych pro-

duktów, usług, działów, segmentów rynku – dzięki kalkulacji kosztów i przychodów na nie

przypadających.

„Ile kosztuje dany produkt?”, „Ile kosztuje dana usługa?”, „Jaki wpływ będzie miała zmiana

cen produktów przez dostawców?” - to niektóre z pytań wpływających na stan inansowy

i przyszłość irmy. Na te pytania SAP daje odpowiedź – poprzez zawarte w systemie mechani-

zmy symulacji i kalkulacji kosztów produkcji oraz jej rentowności. Stosując różne modele wy-

ceny i alternatywne zestawy składników (produktu, usługi) kierownictwo danego przedsię-

biorstwa może precyzyjnie zaplanować koszty danego produktu lub usługi i na bieżąco mo-

nitorować rentowność działalności. Analiza rozbieżności (odchyleń danych rzeczywistych

od danych planowanych) umożliwia szybką identyikację słabych punktów i podjęcie odpo-

wiednich decyzji naprawczych.

Dużym udogodnieniem są zestawy narzędzi typu business intelligence, czyli elastycznych

dodatków umożliwiających samodzielne kreowanie raportów.

Niedopracowane wymagania

Wiele organizacji (szczególnie związanych

z administracją) produkuje setki wymagań

formułowanych jako „system powinien…”.

www.sdjournal.org

Aplikacje biznesowe

Wymagania powinny być określone dla

każdego obszaru implementacji SAP BO

– nie tylko dla funkcjonalności dotyka-

jących tej implementacji. Kategorie wy-

magań obejmują: bezpieczeństwo, work

flow , raporty, interfejsy, formy, wykona-

nie, archiwizację, użyteczność etc. Określ

wszystkich udziałowców oraz przydziel

właścicieli wymagań dla każdego obszaru.

Wymagania, które spełnione są automa-

tycznie (poprzez rozwiązanie produktowe

SAP) i nie wymagają tworzenia przypad-

ków testowych, powinny być jasno przed-

stawione klientowi (np. poprzez prezen-

tację demo aplikacji). Należy jednak pa-

miętać, iż samo zaprezentowanie kliento-

wi sposobu, w jaki produkt SAP spełnia

wymagania, nie wystarcza – należy upew-

nić się, że akceptacja jest oficjalna i udoku-

mentowana.

Opracuj RTM, który wykaże, że wszystkie

wymagania mają pokrycie i są zmapowane

na przypadki testowe.

problemy z implementacją rozwiązania

SAP), relacje z klientem ulegają szybkiemu

pogorszeniu – z punktu widzenia klienta

system nie spełnia swojej roli, z perspektywy

dostawcy wymagane prace zostały wykona-

ne poprawnie i według dokumentacji.

Co można zrobić?

Ustal produkty prac oraz kryteria odbio-

ru. Klient weryfikuje i zatwierdza produk-

ty zgodnie z owymi kryteriami. Brak akcep-

tacji produktu lub zweryfikowanego już wy-

magania, musi być udokumentowany i roz-

wiązany.

Zdarzają się sytuacje, kiedy po implemen-

tacji SAP wdraża się system o funkcjonalno-

ści zgodnej z wymaganiami, podejmowana

jest decyzja GO LIVE, system zostaje zain-

stalowany w środowisku produkcyjnym, po

czym klient uskarża się, iż oprogramowanie

nie spełnia jego potrzeb – przy czym nie do-

starcza na to konkretnych dowodów. Stwier-

dzenia w stylu „system nie robi tego”, „sys-

tem nie jest tak dobry, jak poprzedni”, „sys-

tem jest skomplikowany” nie mówią nic.

Klient powinien przekazać konkretne przy-

kłady na to, że zaimplementowane rozwią-

zanie nie spełnia potrzeb biznesowych czy

wymagań przed podpisaniem zgody na

wdrożenie produkcyjne.

Firma wdrożeniowa oraz klient powin-

ni ustalić kryteria zakończenia ( exit crite-

ria ) dla fazy testowania oraz testów akcep-

tacyjnych. Umożliwi to uniknięcie proble-

mów z interpretacją wyników etapu testów

i pomoże w podjęciu decyzji co do dalsze-

go działania (np. decyzji GO LIVE ). Zale-

ca się, by uczestnicy UAT wykorzystywali

część poprzednio użytych w testach integra-

cyjnych scenariuszy testowych. Tym sposo-

bem, wykonując testy akceptacyjne, weryfi-

kowana jest zarówno poprawność wyników

wcześniejszych faz testowania. UAT jest do-

skonałym momentem na wskazanie wszyst-

kich problemów zauważonych w rozwiąza-

niu SAP przed wdrożeniem na produkcję.

Mimo to nadal wiele organizacji nie przykła-

da do testów akceptacyjnych należytej uwa-

gi i woli raczej polegać na demo systemu ja-

ko dowodzie spełnienia wymagań użytkow-

ników – a przecież UAT to okazja, by udo-

stępnić aplikację prawdziwym użytkowni-

kom końcowym.

Brak weryikacji zakresu

Relacje pomiędzy firmą wdrażającą SAP BO

a klientem mogą ulec radykalnemu ochło-

dzeniu, przerodzić się wręcz we wrogość

– jeśli klient ma poczucie, że zaimplemento-

wane rozwiązanie nie pasuje do jego potrzeb

biznesowych, a użytkownicy końcowi nie są

w stanie wykonać czynności, które wykony-

wali z łatwością za pomocą starego systemu.

Problem pojawia się, gdy klient zgłasza

defekty i usterki do systemu SAP BO, któ-

re dotyczą obszarów czy funkcji nie będą-

cych w zakresie prac wdrożeniowych, lub

nieudokumentowanych w wymaganiach do

systemu. Kiedy firma wdrożeniowa identy-

fikuje takie błędy jako żądania zmian (a nie

Rysunek 3. Fazy etapu 1

Rysunek 4. Rezultaty wstępnej oceny projektu wdrożeniowego

Nieudokumentowane założenia,

ryzyka, ograniczenia

Zdarzają się projekty, w których w fazie po-

czątkowej dokumentuje się ryzyka, założe-

nia i ograniczenia bardzo pobieżnie, w zasa-

dzie tylko pro forma. Takie – stworzone po-

niekąd z przymusu – dokumenty umiesz-

cza się gdzieś, zaś o miejscu ich przecho-

wywania, a czasem i o samej ich obecności,

szybko się zapomina.

05/2010

2010.05_Wdrożenia SAP – droga przez mękę_[Aplikacje Biznesowe].pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: