"Dziedzinowe obszary systemów: separacja dziedzinowa czyli Bounded Context" Jarosław Żeliński analityk biznesowy, projektant systemów

Transkrypt

1 "Dziedzinowe obszary systemów: separacja dziedzinowa czyli Bounded Context" Jarosław Żeliński analityk biznesowy, projektant systemów

2 O mnie Od 1991 roku w branży IT i zarządzania jako analityk projektant rozwiązań Od doradca IT w kilku spółkach akcyjnych Od 2004 roku jako niezależny ekspert i analityk Dziesiątki publikacji w prasie branżowej IT i gospodarczej Członek stowarzyszenia doradców gospodarczych Były wykładowca katedry systemów informacyjnych wydział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. Poświadczenie bezpieczeństwa wydane przez ABW Były ekspert analityk biznesowy przy gabinecie komisji nadzoru finansowego Wykładowca Wyższej Szkoły Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk Projekty analityczne między innymi dla Publikacje między innymi w

3 Agenda Trendy na rynku Wymagania Kontekst jako zgodność granicy obszaru wymagań i obszaru implementacji aplikacji

4 Trendy i oczekiwania 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?) 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).

5 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)

6 Modułowy podział zwykłego systemu ERP Takiego systemu nie da się ani używać ani wdrażać w kawałkach Tradycyjny System Zintegrowany Dokumenty sprzed. Dokumenty HR - Operacja na danych - Operacja na danych Dokumenty prod. - Operacja na danych Dokumenty fin. - Operacja na danych Dokumenty Bo integracja jest realizowana poprzez współdzielenie danych - Operacja na danych DANE

7 Specyfikowanie czy testowanie Specyfikowanie złożonych systemów jest kosztowne i czasochłonne, jest także narażone na pomyłki proporcjonalnie do stopnia jego złożoności Przekazanie dostawcy systemu, zamiast takiej specyfikacji, celu, kontekstu wykorzystania oraz testu czy cel jest spełniony, pozwala uniknąć ryzyka pomyłki: Zamiast specyfikować szczegóły tego jak ma być wspomagana czynność wystawienia faktury bezpieczniej jest zażądać tego, by fakturę tę testowo wystawiono dostarczonym narzędziem co jest dowodem spełnienia naszych oczekiwań (wymagań).

8 Kompromis????????? Zamawiamy schody, po których możliwe będzie wniesienie na pierwsze piętro szafy o wymiarach 200x60x80 cm Określenie celu (planowanego użycia) gwarantuje spełnienie wymagania. Zakup gotowego produktu to rezygnacja z pewnych szczegółów na korzyść krótkiego terminu dostarczenia i niższego kosztu w porównaniu z tworzeniem dedykowanego.

9 Skuteczne postępowanie Opracowanie modelu organizacji: mapy procesów powiązane z wzorami dokumentów, które dają kontekst użycia narzędzia jakim jest oprogramowanie Kolejny krok to analiza obszarów dziedzinowych: Model dziedziny - opisujący jakimi informacjami i jak zarządza organizacja, Identyfikacja spójnych oraz luźno powiązanych obszarów dziedzinowych, Wyszukanie na rynku gotowego oprogramowania spełniającego wymagania dziedzinowe (tak zwane COTS: Commercial of the shelf) Opisanie wymagań na podsystemy dedykowane, te których nie ma na rynku a są wymagane.

10 Integracja logiki a nie danych Granica kontekstu Aplikacja dziedzinowa 1 API API Aplikacja dziedzinowa 2 X Dane Dane

11 Analiza dziedziny systemu granice kontekstu Obiekty biznesowe, silnie powiązane wskazują na spójne moduły. Analiza Biznesowa wskazuje na tak zwany model dziedziny niosący kontekst

12 Dziedzinowy podział systemu Obiektowy System Zintegrowany - Dane Dokumenty HR - Operacja na danych Dokumenty sprzed. - Dane - Operacja na danych Dokumenty fin. Nowoczesne systemy ERP po refaktoryzacji to systemy obiektowe o wyodrębnionych kontekstowo modułach - Dane Dokumenty prod. - Operacja na danych - Dane - Operacja na danych Dokumenty - Dane - Operacja na danych

13 Korzyści: Możliwość etapowego wdrażania systemu Możliwość realizacji wymagań metodą doboru gotowych lub dedykowanych podsystemów zamiast kosztownej i ryzykownej kastomizacji Wielkiego Zintegrowanego ERP Warunek: Posiadanie całościowego opisu organizacji (model procesów biznesowych i model informacyjny).

14 Pewna firma na pewnym forum W przypadku mojej firmy mamy kupiony system sprzedażowomagazynowo-księgowy, które zintegrowaliśmy z kupionym systemem zamówień mobilnych, platformą b2b i z systemem specyficznych analiz napisanym przez nas od zera. I to wszystko całkiem nieźle działa. Teraz pracuję nad integracją z terminalami inwentaryzacyjnymi z Windows CE. Gdyby to zlecić do napisania od zera, jeszcze byśmy tego nie mieli w ogóle uruchomionego, a koszty byłyby 5-10 razy większe. Mamy trochę funkcji nadmiarowych, ale tak jak napisałem na początku bilans ostatecznie jest lepszy niż w przypadku zintegrowanych rozwiązań. Jeszcze jednym plusem jest to, że w razie potrzeby mogę zmienić jeden z elementów systemu na innych, bez konieczności rozkopywania pozostałych części. źr. (najczęściej wybierane systemy ERP - forum na grupie Systemy ERP - strona 3 - GoldenLine.pl).

15 Wymagania c.d. Powodem wielu porażek i nieudanych projektów wdrożeniowych jest: zbyt wiele nacisków dostawcy na kompromisy podczas wdrażania gotowego, parametryzowanego oprogramowania w postaci jednego zintegrowanego pakietu: oprogramowanie staje mało przydatne zbyt wiele nacisków kupującego na dopasowanie (kastomizację): znacznie rosną koszty i odsuwa się termin jego wdrożenia a nadal nie ma gwarancji powodzenia. Wiele specyfikacji jakie obserwuję to lista setek pozycji, opisujących jak ma ten program działać, typowe efekty: Lista cech dużego systemu ERP to ponad 600o pozycji Optymistycznie patrząc można liczyć na zgodność własnej takiej listy z gotowym produktem na rynku w 80% Pozostaje więc 20% cech brakujących, to jest 1200 cech Jedna nowa funkcjonalność to optymistycznie licząc dwa dni pracy konsultanta i programisty, przy koszcie 1200zł/dzień wychodzi 2,88 mln. Kupując oprogramowanie gotowe nie projektujemy go, a specyfikujemy to do czego będzie używane: wskazujemy które procesy system ma obsłużyć i jakiego produktu procesu oczekujemy. Kluczowe wydaje się wydzielenie tych procesów, które są najistotniejsze dla firmy a ich wparcia nie oferuje gotowe oprogramowanie, pozostaje rezygnacja lub umiejętne zaprojektowanie ich jako aplikacji dedykowanej. Jarosław Żeliński IT-Consulting 15

16 Ile powinno być tych wymagań? Lista funkcjonalności typowego kompletnego pakietu ERP II może obejmować nawet ponad 6 tys. cech! Planowanie ich wdrożenia a wcześniej wyspecyfikowanie, wybór produktu i jego dostawcy nie może być typowym procesem wyboru oprogramowania: nikt nie jest w stanie zarządzać taką liczbą wymagań w jednym projekcie. Jeżeli zgodność gotowego oprogramowania z naszymi szczegółowymi wymaganiami osiągnie przypadkiem 80% (mało prawdopodobne!) to pozostanie 20% do kastomizacji 1200 cech, Gdyby na jedną poświęcić tylko jeden dzień (mrzonka) a dzień konsultanta kosztował 1000zł (?!) to projekt osiąga wartość 1,2 mln! Dlatego wymagania na gotowe oprogramowanie powinny być krótką listą tego do czego będzie ono używane a nie mega listą tego jak ma wyglądać

17 Granica kontekstu użytkownika Opis logiki biznesowej i dokumentów (dane wprowadzane, zasady ich przetwarzania, dane oczekiwane wynik przetwarzania) Opis podziału kompetencji pomiędzy użytkowników i system (kto policzy VAT na fakturze?)

18 Dziękuję za uwagę PYTANIA? Jarosław Żeliński IT-Consulting 18