Wyniki wyszukiwania dla „ERP” – Strona 35 – Jarosław Żeliński IT-Consulting

Analiza wymagań na oprogramowanie czyli opisanie czy zrozumienie

Istnieje coś takiego jak zasada SOLID projektowania oprogramowania (jedna z kluczowych cech dobrych projektów oprogramowania). Cóż to jest SOLID? To rozwinięcie od ang. Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion (więcej na stronie SOLID (object-oriented design) – Wikipedia, the free encyclopedia).

Dzisiaj tylko o skutkach zaniedbania jednej, kluczowej chyba własności, która dotyczy całej aplikacji: Open-Close, która oznacza: aplikacja powinna być zamknięta na zmiany i otwarta na rozbudowę. Dla wielu na początku ta zasada brzmi wręcz kuriozalnie ale ona jak najbardziej jest możliwa do realizacji. Proszę zwrócić uwagę, że takie własnie są dobrze zarządzane firmy, nie ma w nich rewolucji organizacyjnej co roku, one się rozwijają a nie zmieniają.

Oprogramowanie, jeżeli w wyniku analizy wymagań opracowano nie tylko raport z wywiadów ale także model logiki działania, też spełni te zasadę. Czym grozi jej niespełnienie w stosunku do oprogramowania? A tym, do czego przyznał się jeden z programistów podczas pewnej dyskusji na forum:

kilka razy doświadczyłem sytuacji, że aby spełnić nowe proste wymaganie trzeba było się namęczyć zarówno z modelem danych jak i aplikacją, Oczywiście można w takiej sytuacji zarzucić, że system był źle zaprojektowany, nieskalowalny, nie przestrzegał SOLIDów, nie korzystał z wzorców itd ale to już jest inna bajka.

Na co ja odpowiedziałem: nie, to jest właśnie ta bajka o nazwie analiza wymagań i projektowanie, które powinny być zrozumieniem a nie tylko stenogramem. Wtedy nowe funkcjonalności oprogramowania można dodawać bez potrzeby przebudowy jego wewnętrznej struktury. Nie raz jest z powodu tych kosztów po protu niemożliwy jest rozwój systemu. Oceńcie teraz Państwo sami, Ci którzy tego doświadczyli, skutki wdrożenia np. systemu ERP z kastomizacją…. niestety ogromna większość tego oprogramowania nie spełnia zasady SOLID. Dlaczego? Bo model relacyjny baz danych, jeżeli obejmuje wszystkie dane systemu, niestety nie spełnia tej zasady z założenia. A dostawcy tych systemów wręcz cieszą się z tego reklamując się: “nasz system jest w pełni zintegrowany poprzez pracę na wspólnej bazie danych”…. Jak to przeczytasz, nie kupuj tego…

Czytaj dalej

Dlaczego nie podoba mi się klasa Pracownik?

Swego czasu pod artykułem Business Model vs. System Model, wywiązała się dyskusja, po tym jak napisałem, że oprogramowanie reprezentuje narzędzie pracy, więc projekt tego oprogramowania raczej powinien zawierać pojęcie (klasę) Karteka Pracowników a nie Pracownicy. Jeden z czytelników napisał wtedy (dociekliwym polecam w tym momencie cała tę dyskusje pod artykułem):

… byt Pracownik jak najbardziej ma sens. Przecież tu jest zdefiniowane jego zachowanie (część jedynie z real world, ale jednak). Pracownik.pijeKaweRano().. przeciez nie KartotekaPracownika.pijeKaweRano() (Business Model vs. System Model).

Gdzie problem?

[…]

No więc dlaczego nie podoba mi się klasa Pracownik? Bo pracownik to Aktor Systemu, a System ten przechowuje wybrane dane o tym pracowniku. Są to dane potrzebne np. do identyfikowania osób wystawiających dokumenty z Systemu, a do tego potrzebne są jedynie Karty Pracowników a nie Pracownicy. System (oprogramowanie) zastąpił papierowe Kartoteki Magazynowe dlatego są one teraz w Systemie, ale towary są w nadal magazynie 9a nie w Systemie), system “ma w środku” Kartę Towaru (zastąpiła papierową) zawierająca opis towaru i jego ilość w magazynie. Kartoteka Magazynowa to pudło zawierające Karty Towarów. Faktura VAT to obiekt w systemie, można ją wydrukować lub wysłać jej egzemplarz w postaci elektronicznej kontrahentowi.

Czytaj dalej

Przetarg czyli wycena projektu…

O przetargach napisano tak wiele krytycznych tekstów, więc po co ten? Nie będę się tu pastwił nad nimi. Zastanawia mnie co innego, i tu mała krytyka... W prasie pojawiły się…

Czytaj dalej

Tablice decyzyjne – fakty a nie procesy

Tak więc, reguły biznesowe to ogólno-organizacyjne ograniczenia. Tablice decyzyjne to rodzaj “wiedzy” wpisanej w punkty podejmowania decyzji. Na modelach (diagramach) procesów biznesowych modelujemy jedynie skutki, czyli reakcje na podjęte – zgodnie z tablicą – decyzje.

Gdyby modelować powyższe na diagramie np. BPMN, mielibyśmy bramkę z czterema wyjściami, każde wyjście reprezentował by wiersz Działań. Jak widać spodziewać się należy tu bramek XOR (alternatywa wyłączna) lub OR (alternatywa “zwykła”). Na diagramach BPMN za bramką byłyby czynności nazwane tak jak działania w wierszach. Aby nie komplikować nazewnictwa tych diagramów, tablica decyzyjna użyta z diagramem BPMN miała by wiersze Działań nazwane np. odpowiednio Wariant-1, Wariant-2 itd. a czynności były by umieszczone już na diagramie.

Tego typu tablice doskonale nadają się do modelowania systemów rabatowych, lojalnościowych, wartości kredytów kupieckich, wag scoringu kredytów i wielu innych, w których kombinacje skończonej liczby czynników tworzą deterministyczną, skończoną liczbę dopuszczalnych zachowań. Na diagramie procesu powołujemy się wyłącznie na nazwę tablicy (np. kojarząc ją z konkretną czynnością) zamiast modelować skomplikowane przebiegi. Dlaczego? Bo warto pamiętać, że

decyzja – nawet bardzo skomplikowana – nie jest procesem a zaistniałym faktem, odpowiedzią na zastane warunki

Jak widać, reakcja kierowcy na sygnalizator, to nie proces a fakt. Jest to konkretna reakcja na konkretną kombinację kolorów świateł na sygnalizatorze.

W przypadku analizy wymagań, stosowanie tablic decyzyjnych, jako narzędzia specyfikowania pewnych zachowań systemu, jest bardzo wygodne bo po pierwsze: jest jednoznaczne, po drugie tablice decyzyjne to już standardowe narzędzie w inżynierii oprogramowania i nie trzeba wymyślać ich implementacji (np. w postaci maszyny stanowej: reguły to zdarzenia a działania do przejścia).

Czytaj dalej

Architektura korporacyjna z OMG.org

Mamy więc pomysł o wdzięcznej nazwie Architektura Korporacyjna. Po nam to? Po co nam taka dokumentacja? Przykłady korzyści z jej posiadania:

mamy “na tacy” model systemy zależności (analizy wpływu) pozwalający natychmiast ocenić ryzyka związane z wzajemnym wpływem na siebie procesów, ludzi, zasobów (np. jakie skutki będzie miało wyłączenie konkretnego serwera czy spóźnienie do pracy konkretnego pracownika),
mamy “na tacy” wymagania na oprogramowanie, bez niepotrzebnego “zwinnego” ich poszukiwania metodą prób i błędów, niezależnie od tego czy kupujemy nowe czy wymieniamy (niestety, tak zwane zwinne metody to nie raz bardzo duże koszty “zarzuconych bocznych ścieżek” odkrywanych burzą mózgów),
od razu zauważymy, że idea posiadania monolitycznego systemu ERP II nie bardzo ma sens (to usztywnia organizacje oraz tworzy potężny [[“single point of failure”]], złośliwi dodają “single point of big cost” :)),
i najważniejsze: jak tylko przeprowadzimy analizę i wykonamy model AK szybko wychwycimy tak zwane osierocone wymagania na oprogramowanie, osierocone stanowiska pracy, osierocone procedury, … (osierocone: niewykorzystywane), to nie raz źródło samo w sobie – eliminacja “sierot” – ogromnych oszczędności,
i inne …
Jak tym zarządzać? Na pewno nie ręcznie, bez oprogramowania CASE w zasadzie nierealne. Czy to kosztowne? Hm… kłania się analiza ROI, więc każda organizacja ma swój próg rentowności. Jednak od siebie powiem tak: oszczędności pojawiają się natychmiast w postaci identyfikacji “sierot”. Kolejny etap oszczędności to reorganizacja kosztów i ryzyk zarządzania organizacją, kosztów posiadania oprogramowania, kosztów jego rozwoju, kosztów zakupu i tworzenia. Dobra wiadomość: początek każdy już ma w postaci prowadzonej dokumentacji w dziale HR.

Czytaj dalej

Reguły biznesowe – projekt zabija ich bezsensowna ilość…

Bardzo często spotykam się z ogromną złożonością (liczba i ich podziały) wymagań. Problem tkwi nie raz w tym, że “narosła” przez lata “sterta zarządzeń”, która zamiast zostać najpierw uporządkowana, jest “wprost” traktowana jako “wymagania”. Takie podejście to krok w stronę klęski projektu.

Procesy biznesowe są konsekwencją między innymi reguł biznesowych. Większość zarządów firm nie ma na półkach regałów map procesów, a firmy działają. Jednak każda firma ma zarządzenia Zarządu i to one tak na prawdę kształtują “procesy biznesowe”. Podobnie jak np. w muzeach: mamy duże sale i wiele możliwości przejść przez nie. Co decyduje o tym, jaką drogę przejdziemy przez sale pełne eksponatów? Linia na podłodze? Nie! Barierki! Czym one są? To ograniczenia! Zarządzenia Zarządu stwarzają ograniczenia, ich konsekwencją są takie a nie inne procesy biznesowe. Dlatego zrozumienie i uporządkowanie reguł biznesowych jest ważne, a nie modelowanie procesów. Te są ich skutkiem. Modelowanie procesów to odkrywanie ścieżek wyznaczonych ograniczeniami. Jeżeli jednak pozwolimy utrzymać opisany bałagan to modele procesów biznesowych (ścieżki postępowania) przybiorą postać zawartości monstrualnego talerza spaghetti.

A tak na prawdę polecam wystawę w Zamku Królewskim (Warszawa): Polska za czasów Jagiellonów oraz drugą: Historia krzyża Maltańskiego.

Czytaj dalej

Procesy referencyjne czyli kto żyw niech ucieka

Na pewnym wysokim poziomie abstrakcji można mówić o procesach referencyjnych, a raczej dobrych praktykach np. proces tworzenia nowego produktu powinien mieć następujące kroki: opis pomysłu, analiza SWOT produktu na rynku, oszacowanie ceny sprzedaży, kosztu wytwarzania i planowanego poziomu sprzedaży, prognoza przepływów gotówkowych. Ale to “ogólny opis” a nie “prototypy procesów i mapy procesów”.

Tak więc są na pewno pewne pryncypia, można je znaleźć np. w książkę M.E.Portera “Strategie konkurencji” (autor koncepcji rynkowego łańcucha wartości) czy P.Druckera “Praktyka zarządzania”.

Jednak jak nam ktoś funduje system ERP z “wbudowanymi procesami referencyjnymi” to należy rozumieć: “szykuje się totalna rewolucja”, czy ja przeżyjemy?

Czytaj dalej

O narzędziach CASE – rzadko ale jednak piszę

Prawdę mówiąc "zabraniam" przynoszenia komputerów na moje szkolenia, wymagam papieru i ołówka. Powody są dwa: Narzędzia CASE pomagają tylko wtedy gdy diagramów jest wiele i model jest złożony, na szkoleniach takich modeli się…

Czytaj dalej