Celem referatu jest pokazanie systemu ERP_II jako złożonego środowiska usługowego wspomagającego zarządzanie firmą (organizacją), w którym korzystanie z rozproszonej architektury wymaga specyficznego podejścia.

1. JarosławŻeliński – Analityk Biznesowy, kontraktor

2. © Jarosław Żeliński IT-Consulting 2
Od 1991 roku w branży IT i zarządzania
Od 1998 roku jako niezależny analityk,
projektant i firma IT-Consulting.pl
Dziesiątki publikacji w prasie branżowej i
gospodarczej
Członek Stowarzyszenia Doradców
Gospodarczych
Wykładowca Katedry Systemów
InformacyjnychWydziału Przedsiębiorczości
Akademii Morskiej w Gdyni
Kilkudziesięciu odbiorców usług doradczych,
małe, średnie i duże firmy zarówno
informatyczne jak i ich klienci oraz
administracja publiczna.
Poświadczenie bezpieczeństwa wydane
przez ABW
Od 2009 doktorant na KIG SGH
Publikacje między innymi w …

3.  Celem referatu jest pokazanie systemu
ERP_II jako złożonego środowiska
usługowego wspomagającego zarządzanie
firmą (organizacją), w którym korzystanie z
rozproszonej architektury wymaga
specyficznego podejścia.

4. Z badania przeprowadzonego przez IBM na grupie ponad 3000 dyrektorów działów IT
wynika, że w ciągu najbliższych pięciu lat, 60% organizacji zamierza wprowadzić
rozwiązania opartych na chmurze.W opinii respondentów doprowadzi to do dalszego
rozwoju ich firm i pozwali osiągnąć przewagę konkurencyjną. W stosunku do
badania przeprowadzonego w 2009 roku podwoiła się liczbaCIO, którzy chcą
wprowadzić rozwiązania cloud computing, co świadczy o tym, że sprawdzają się
one w wielu firmach na całym świecie. (źr. Chmura wg badania IBM CIO Study).
Przedstawiciele co trzeciej brytyjskiej firmy (35 proc.) przyznają, że byliby skłonni
zastąpić wykorzystywany obecnie system klasy ERP bardziej elastycznym
rozwiązaniem o podobnej funkcjonalności. (źr. Czego najbardziej brakuje
systemom klasy ERP?)

5.  Metoda analizy zalecana przez IIBA
(International Institute of Business Analusis)
 Model dziedziny jako kluczowy element analizy
 Cloud Computing jako wewnętrzna architektura
(tu będzie mowa o tak zwanej chmurze
prywatnej)
 Jak wskazać obszary firmy jako kandydatów na
klientów „odrębnego systemu”
 Wymagania na system ERP jako projekt systemu
systemów
 Co w podstawowym pakiecie ERP a co nie

6. Aby zminimalizować ryzyko projektu Zamawiający powinien w specyfikacji wymagań dokładnie określić
czego potrzebuje, dostawca na tej podstawie dopiero określi co musi dostarczyć i jakim kosztem jest w
stanie tego dokonać . Ale jak opisać to czego naprawdę potrzebujemy?
Inżynieria oprogramowania to tworzenie i dostarczanie oprogramowania
spełniającego oczekiwania, w tym także wdrożenie gotowego
oprogramowania jeśli spełnia te oczekiwania. Pierwszym podstawowym
problemem do rozwiązania nie jest jednak spisanie tych oczekiwań w
postaci specyfikacji wymagań, bo to jest drugi krok, a odkrycie „jak
naprawdę pracujemy” oraz „w czym i jak oprogramowanie ma nam
pomagać” bo z tego będzie wynikało to czego oczekujemy.
6© Jarosław Żeliński IT-Consulting

7. Czas trwania
Opracowanie własne, Jarosław Żeliński
7
© Jarosław Żeliński IT-Consulting

8. Integracja dziedzinowych podsystemów jako metoda tworzenia systemu

9.  Monolityczne rozwiązania wspierające zarządzanie to przeszłość. Dziś
liczą się: wszechstronność, otwartość na zmiany, prostota obsługi,
możliwości integracyjne.Wybór najlepszego systemu ERP staje się coraz
trudniejszy. (Biznes wychodzi z objęć systemu – Computerworld).
 Uniwersalność oprogramowania wspierającego zarządzanie powoduje,
że zacierają się historyczne podziały branżowe. „Wcześniej myślano o
systemach klasy ERP jako o narzędziach dających przewagę
konkurencyjną. Dzisiaj rozwiązania tego typu stały się bardziej
powszechne. Standaryzacja poprzez ERP nie daje przewagi nad
konkurencją” – podkreślaTomasz Bejm,TechnologyConsulting Leader w
firmie PrcewaterhouseCoopers. (Biznes wychodzi z objęć systemu –
Computerworld).
 System ERP, jeżeli chcemy osiągnąć przewagę, musi być elastyczny i nie
może być sztampą… teoria procesów referencyjnych
zaimplementowanych w jednolity system ERP nie sprawdziła się,
przewagę buduje się robiąc coś „najlepiej”, czyli ewidentnie inaczej
niż konkurencja…

11. „W poprzedniej epoce firmy wiązały się na wiele lat z jednym
dostawcą systemów IT, rozprzestrzeniając wybrane systemy w
całej organizacji, czego efektem było często powstanie trudno
zarządzalnej, sztywnej infrastruktury, w niewielkim stopniu
podatnej na zmiany. Analitycy Gartnera są zdania, że
rozpoczęła się epoka projektów, które trzeba będzie
rozpoczynać bez znajomości wszystkich wymagań
użytkownika, aby nie spóźnić się na rynek z nowym produktem
i wykorzystać sposobną chwilę, która może się nie powtórzyć.
Przed nami epoka systemów, które budowane są z myślą o ich
ustawicznych modyfikacjach w odpowiedzi na zmieniającą się
sytuację rynkową.” (źr. Gartner/ERPStandart)

12. Tradycyjny System Zintegrowany
Dokumenty fin.
- Operacja na danych
Dokumenty sprzed.
- Operacja na danych
Dokumenty HR
- Operacja na danych
Dokumenty prod.
- Operacja na danych
Dokumenty …
- Dane
- Operacja na danych
Integracja poprzez
współdzielenie
danych
Moduły typowego
systemu ERP

13. Dane
Aplikacja jako
usługa
Aplikacja
użytkownika
Dane
X
W chmurze ma miejsce integracja poprzez wymianę danych a nie ich współdzielenie.
APIAPI
W chmurze wymagana jest standaryzacja danych,
można ją osiągnąć odpowiednio projektując system
(metody obiektowe i DDD)

14.  Opracowanie modelu organizacji: mapy procesów
powiązane z wzorami dokumentów i regułami
biznesowymi
 Model dziedziny systemu: model pojęciowy opisujący
informacje jakimi zarządza organizacja
 Identyfikacja spójnych oraz luźno powiązanych
obszarów dziedzinowych
 Wyszukanie na rynku (w sieci) gotowego
oprogramowania spełniającego wymagania
dziedzinowe (tak zwane COTS: Commercial of the
shelf)
 Opisanie wymagań na podsystemy dedykowane.

15. Etap
modelowania
organizacji
Etap
specyfikowania
funkcjonalności
Etap
specyfikowania
dziedziny
Produkt analizy wymagań
Wymagania
funkcjonalne

16.  Poza podziałem wymagań na funkcjonalne i pozostałe warto te funkcjonalne podzielić na:
 Dziedzinowe czyli specyficzne dla branży lub typu działalności, powielane niemalże w każdej firmie (np.. finanse i księgowość,
kadry, …)
 Organizacyjne czyli specyficzne dla danej organizacji pracy, z reguły są to niuanse obiegu dokumentów, uprawnień
pracowników itp..
 Indywidualne czyli kluczowe, specyficzne wymagania budujące przewagę rynkową np.. specjalny, inny niż u konkurencji, sposób
obsługi klientów, specyficzna niszowa działalność, dla której nie powstały produkty (oprogramowanie) masowe itp..
 Podział ten służy do oceny zakresu projektu i ewentualnego podziału na podsystemy, który zawsze należy rozważyć:
 Wymagania dziedzinowe z reguły zaspokaja standardowe, dostępne na rynku oprogramowanie
 Wymagania organizacyjne najczęściej można zrealizować wdrażając dostępny na rynku systemu przepływu pracy i
dokumentów (jeżeli nie da sobie z tym rady standardowy program)
 Wymagania indywidualne, w tych przypadkach bardzo często wdrażane są systemy (podsystemy) dedykowane. Wielu
dostawców gotowego oprogramowania zaleca taki sposób postępowania dostarczając w swoich produktach bogate interfejsy
integracyjne
 Powodem dla którego zawsze warto rozważyć powyższy podział jest to, że powodem porażek. wielu nieudanych
projektów wdrożeniowych jest zbyt wiele kompromisów podczas wdrażania gotowego, parametryzowanego
oprogramowania w postaci jednego zintegrowanego pakietu.
© Jarosław Żeliński IT-Consulting 16
Wymagania na oprogramowanie biznesowe
Dziedzinowe – komponenty dziedzinowe
organizacyjne
indywidualne

17. Analiza Biznesowa zawiera tak zwany model dziedziny
Obiekty
biznesowe

18.  Przedstawiona architektura może być znana, tak mógłby wyglądać system po projekcie integracji.
Integracja jest jednak postrzegana jako droga i pracochłonna.
 Pojawiła się SOA jako metoda integracji. Jako architektura polega na uporządkowaniu i standaryzacji
interfejsów i jest „tania”.
 Cloud Computing to powrót do idei tworzenia dedykowanych, usługowych połączeń znanych z idei
obiektowych systemów komponentowych.

19.  Możliwość etapowego wdrażania systemu
 Możliwość realizacji wymagań metodą
doboru gotowych lub dedykowanych
podsystemów zamiast kosztownej i
ryzykownej „kastomizacji”
 Warunek:
 Posiadanie całościowego opisu organizacji np. w
postaci modelu procesów biznesowych, systemu
reguł biznesowych, modelu dziedzinowego.

20. Dziękuję za uwagę…
© Jarosław Żeliński IT-Consulting 20