Download - ERP jako system systemów
© Jarosław Żeliński IT-Consulting 2
O mnie…Od 1991 roku w branży IT i zarządzaniaOd 1998 roku jako niezależny analityk, projektant i firma IT-Consulting.plDziesiątki publikacji w prasie branżowej i gospodarczejCzłonek Stowarzyszenia Doradców GospodarczychWykładowca Katedry Systemów Informacyjnych Wydziału Przedsiębiorczości Akademii Morskiej w GdyniKilkudziesię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 ABWOd 2009 doktorant na KIG SGH
Projekty analityczne między innymi dla…
Publikacje między innymi w …
Cel referatu
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.
Trendy i oczekiwania…
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ę liczba CIO, 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?)
Agenda
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
© Jarosław Żeliński IT-Consulting 6
Specyfikacja wymagań…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.
7
Szczegółowość analizy i jej koszt
Lic
zba
pozn
an
ych
szc
zeg
ółó
wCzas trwania
Ryzyko źle określonych wymagańKoszt a
nalizy i projektowania
Kompromis ryzyka i budżetu
Wzrost kosztów jest większy niż spadek
ryzyka
Liczba iteracji w procesie analizy
ALE UWAGA! Ograniczeniem może być albo budżet
albo maksymalne
akceptowalne ryzyko.
Z reguły tu warto zakończyć analizę
Opracowanie własne, Jarosław Żeliński
© Jarosław Żeliński IT-Consulting
Co mówi rynek…
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śla Tomasz Bejm, Technology Consulting 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…
Czas to pieniądz…
„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)
Tradycyjny System Zintegrowany
Modułowy podział systemu
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
„Zlecanie przetwarzania i pytania”
Dane
Aplikacja jako usługa
Aplikacja użytkownika
Dane
XW 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)
Analiza wymagań
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.
IIBA: produkt Analizy Biznesowej
Etap modelowania organizacji
Etap specyfikowan
ia funkcjonalno
ści
Etap specyfikowania dziedziny
Produkt analizy wymagań
Wymagania funkcjonalne
© Jarosław Żeliński IT-Consulting 16
Wymagania – specyfika organizacji
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.
Wymagania na oprogramowanie biznesowe
Dziedzinowe – komponenty dziedzinowe
organizacyjne
indywidualne
Analiza dziedziny systemu
Analiza Biznesowa zawiera tak zwany model dziedziny
Obiekty bizneso
we
ERP CRM
WMSSCM
Cloud Computing… cóż to jest
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.
Korzyści:
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.
© Jarosław Żeliński IT-Consulting 20
Pytania…?Dziękuję za uwagę…
Jarosław Żeliński – Analityk [email protected]://IT-Consulting.plGSM: 0-608 05 90 20