ERP – Strona 5 – Jarosław Żeliński IT-Consulting

Mega projekty czyli jak zjeść słonia

Post author:Jarosław Żeliński
Post published:22 marca 2013
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:21 maja 2021

Uszczegóławianie wymagań odkładamy "na ostatni moment". W ten sposób "kwartał po kwartale" doprecyzowujemy wymagania na kolejny etap i realizujemy go. Co zyskujemy? Nie wyrzucamy do kosza nadmiernie szczegółowej i rozległej dokumentacji wymagań, nie ponosimy koszów projektowania czegoś co może "wylecieć" z zakresu za pół roku z powodów np. zmian na rynku, możemy w dowolnym momencie zmienić kolejne planowane komponenty, usunąć jedne i opracować nowe bez ryzyka zbędnych kosztów.Pierwszy etap ma pewną cechę: tworzy jeden wspólny model wszystkich projektów dla danej organizacji o wdzięcznej nazwie Architektura Korporacyjna. Kolejne konkretne komponenty architektury IT to kolejne projekty, cechujące się umiejscowieniem w całości organizacji i wiarygodnym, spójnym z całością zakresem.Dlatego z reguły nie mają sensu:wdrożenia departamentowe oderwane od reszty (np. Dział Handlowy sobie funduje sam system CRM), projekty trwające dłużej niż trzy kwartały (ostatni kwartał to kolejne planowanie budżetu na kolejny rok czyli planowanie zmian), mega projekty ERPII czyli "all in one" dla firmy w ramach jednego projektu. Więc jak zjeść słonia by się nie udławić? Powoli i po kawałku...

Czytaj dalej

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

Post author:Jarosław Żeliński
Post published:30 grudnia 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:2 stycznia 2013

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

Wdrożenie ERP – koszt czy zysk?

Post author:Jarosław Żeliński
Post published:13 grudnia 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:22 kwietnia 2016

Pokusa wdrożenia systemu połączonego z "modyfikowaniem pod potrzeby klienta" ładnie brzmi, ale nawet gdyby się to udało, to system taki usztywni firmę, zabierze jej więc jej kluczową zaletę: zwinność! Tak więc dla MSP owszem nawet duży system ERP ale z bogatym menu i swobodą dostępu do niego. Po drugie "wielkie zintegrowane zwierzę" będzie się wdrażało długo bo jest wielkie. Znacznie bezpieczniejszą dla MSP strategią jest wdrażanie funkcjonalności ERP etapami, mieszczącymi się w granicach roku budżetowego, nawet jeżeli miało by to oznaczać, że poszczególne moduły będą pochodziły od różnych dostawców (pisałem o tym nie raz tu).Nie ma możliwości łatwego udzielenia odpowiedzi na przytoczone dwa pytania na zadawane na konferencjach, bez zrozumienia tego co trapi daną firmę, jednak nasz kraj przoduje w sprzedaży leków bez recepty i mam wrażenie, że analogiczne zjawisko ma miejsce na rynku oprogramowania: po co nam jakaś analiza czy audyt, idziemy i kupujemy tego "erpa" bo mówią, że pomaga a firma sprzedająca obiecała, że pomoże.

Czytaj dalej

Ile tego ma być … analiza i model procesów biznesowych

Post author:Jarosław Żeliński
Post published:16 listopada 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:28 lipca 2018

Tak więc analiza organizacji i opracowanie jej modelu to trudna, praca, nie raz długa, ale nie powinny to opasłe księgi. Dobry model organizacji to właśnie broszurka, która odpowiada na pytanie "dlaczego". Jeżeli wynikiem analizy są opasłe księgi to znaczy, że mamy jedynie dziesiątki nagrań kolejnych partii szachów a nie reguły tej gry... a wtedy nadal nie wiemy "dlaczego".Co ciekawe, każda organizacja ma, lub powinna mieć, taką instrukcję: jest to lista stanowisk (struktura organizacyjna) i reguły gry w postaci wewnętrznych zarządzań i procedur. Ale powinna ona być spójna i kompletna. Przypomnę, że każda organizacja jakoś funkcjonuje, a mało która ma mapy procesów biznesowych. Po co więc te modele procesów?Wróćmy do wspomnianej na początku "piramidy". Jej szczyt to cele, model biznesowy: chcemy grać w szachy i wygrywać. Jej najniższa warstwa to figury i reguły gry. Czym jest środkowa warstwa, czym są te modele procesów biznesowych? Dobry szachista ma pewne z góry przewidziane scenariusze, są to "gotowe" rozwiązania na pewne powtarzająca się sytuacje na szachownicy. One oczywiście nie są w stanie zastąpić szachisty, ale bardzo ułatwiają mu grę, raz przećwiczone i uznane za "dobre" i skuteczne scenariusze, stosuje zawsze gdy napotka "standardową sytuację".Organizacje także je mają, to właśnie procesy biznesowe, ale nie jest to recepta na pracę firmy, takiej nie jesteśmy w stanie stworzyć. Procesy biznesowe, te udokumentowane by służyły firmie, to wszystkie te przewidywalne, powtarzające się scenariusze, które stanowią tak na prawdę nasze organizacyjne know-how. Cała reszta to kompetencje naszych pracowników a tych nie modelujemy, z nich korzystamy.

Czytaj dalej

Projekt wykonany – co było robione

Post author:Jarosław Żeliński
Post published:3 października 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:29 sierpnia 2022

Powyższe jest zgodne z zaleceniami OMG.org (https://www.omg.org/mda), audyt to etap CIM a projektowanie przypadków użyci i modelu dziedziny to etap PIM.Wykonanie takiej analizy jest pracochłonne i wymaga dużego doświadczenia, umiejętności analiz procesów biznesowych, projektowania obiektowego i dobrego narzędzia CASE, jednak modele te pozwalają także przeprowadzić analizy wpływu (zależności pomiędzy procesami, skutki i podatność na awarie oprogramowania itp.) oraz zredukować do minimum prawdopodobieństwo przekroczenia terminu i kosztów (statystyki wskazują na średnie przekroczenie kosztów o 60% i terminów o 200% projektów z niskiej jakości specyfikacji wymagań). Praktyka autora wskazuje, że warto taką analizę przeprowadzić dla projektów, których budżet przekracza 50-70 tys, zł i większych.

Czytaj dalej

RE: RE: Duży ERP, czy integracja c.d.

Post author:Jarosław Żeliński
Post published:6 sierpnia 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:8 sierpnia 2012

Pojęcie ERP samo z siebie nie ma ścisłej definicji więc nie ma mowy o "upośledzaniu czegoś jako ERP". Komentując dalej: ERP dla mnie nie jest żadną religią, jest jednym z wielu dostępnych na rynku pakietów oprogramowania. Skór ERP występuje w tak wielu nazwach produktów, tak wielu dostawców, że traktowanie go, moim zdaniem, jako cokolwiek więcej niż "zestaw oprogramowania kompleksowo wspomagający zarządzanie organizacją" jest chyba trudne do uzasadnienia. A skoro i tak do "ERP" dodaje się dziedzinowe rozwiązania (logistyka, produkcja, HR, wiele innych) to chyba dowodzenie, że to "monolit" w jakiejkolwiek części do niczego nie prowadzi.Z ust adwersarza padło stwierdzenie:Wszelkie rozwiązania polegające na tym, że jakiś podzbiór funkcji z wyżej wymienionego jest osobnym systemem rejestrującym zdarzenia osobno od centralnej bazy danych i przesyłającym je później do niej w celu zarejestrowania upośledza system jako ERP.Dziwi mnie to, bo np. prosty proces zatwierdzania kosztów mający co najmniej dwa etapy: rejestracja faktury obcej oraz jej zatwierdzenie (lub odrzucenie) i uznanie w księgach to co najmniej dwuetapowy proces i nie ma tu większego znaczenia miejsce przechowywania pośrednich statusów bo w rzeczywistości i tak "księgi" widzą efekt ostateczny (uznanie na kontach) a poprzedzające etapy weryfikacji kosztów (proces biznesowy) "dzieją się" poza księgami.Moim zdaniem brak ścisłej definicji pojęcia "System ERP" czy dalszą dyskusję bezwartościową. Oprogramowanie SAP nie jest żadnym referencyjnym produktem ERP (choć wielu próbuje tej tezy bronić) i posługiwanie się jego przykładem jako "wzorem" w moich oczach nie jest żadnym argumentem. Nie twierdze, ze SAP to produkt zły. To po prostu produkt jeden z wielu na rynku... ma swoje wdrożeniowe sukcesy i ma porażki jak inne.

Czytaj dalej

Ach ten opluty wodospad… czyli lessons learned ERP

Post author:Jarosław Żeliński
Post published:22 lipca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:23 lipca 2012

Opisane tu podejście często nazywane jest "kaskadowym" (waterfall - wodospad). Jest ono dość często wskazywane jako powód porażek projektów, ale moim zdaniem jest to pewna demagogia, gdyż tak na prawdę przyczyną większości problemów jest nie tyle "wodospadowe" podejście, ono jak widać z powyżej opisanego procesu, ma głęboki sens, co wzięcie sobie na barki projektu (zawarcie umowy z dostawca na trzy lata to przyjęcie w dniu jej zawarcia harmonogramu łamiącego opisana powyżej zasadę) na lata zaniedbując zupełnie fakt, że otoczenie rynkowe obecnie zmienia się nawet co kwartał.Mamy więc kuriozalne zestawienie: podjęcie projektu od razu od ostatniego etapu (wybór dostawy, produktu i realizacja) i zaplanowanie go od razu na np. trzy lata. To projekt w rodzaju "nie wiem co tu jest grane ale kupujemy [ten system] i wdrażamy go". To nie ma prawa się udać...A nasze "lessons learned"? No właśnie, znane mi projekty zakończone kłopotami, to właśnie projekty na skróty. Projektu prowadzone w myśl powyższych zasad (krótkie i dobrze zaplanowane etapy) są znacznie bardziej odporne na kłopoty.

Czytaj dalej

RE: Duży monolityczny ERP czy integracja

Post author:Jarosław Żeliński
Post published:20 lipca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:21 sierpnia 2022

Pojawiła się polemika do mojego artykułu Duży monolityczny ERP czy integracja (fragment, gorąco polecam cały wpis): Witam Kolegę Blogera i na powitanie mam małą polemikę. Otóż nie mogę się zgodzić na tak szeroko postawione pytanie "Duży ERP, czy integracja" gdyż na nie odpowiedziała już Historia. Od ERP nie ma odwrotu! (RE: Duży ERP czy integracja - ERP -view.pl - System ERP, CRM, ERP, Business Intelligence, MRP).?*? Jako, że zostałem wywołany do tablicy :), odpisuję. Zakładam, że powyższą lekturę już Państwo mają za sobą, jeżeli jednak nie, cytuje treści, które omawiam. Na początek proponuję uzgodnić jedną rzecz: definicję…

Czytaj dalej

Duży monolityczny ERP czy integracja

Post author:Jarosław Żeliński
Post published:14 lipca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:12 maja 2019

Tym razem krótko. Praktycznie za każdym razem moje rozmowy z potencjalnymi klientami dotykają problemu: jeden zintegrowany system ERP czy kilka dziedzinowych rozwiązań. Ja zawsze powtarzam to samo: im większy monolityczny system tym większym ograniczeniem i kosztem staje się dla firmy, tym większe uzależnienie od jednego dostwcy. Na rynku ścierają się stale dwie grupy opinii: "duży ERP jest lepszy bo od jednego dostawcy i od razu zintegrowany", kontra teza "duży ERP monolityczny wymaga wielu prac dostosowawczych i bardzo trudno zmienić w nim jedno nie ingerując w resztę". [...] "lepszym rozwiązaniem będzie wdrożenie systemów dziedzinowych i ich zintegrowanie"...

Czytaj dalej

Czym jest jakość oprogramowania… a może od czego ona zależy?

Post author:Jarosław Żeliński
Post published:26 czerwca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:26 czerwca 2012

Coraz częściej utożsamiam analizę z projektem gdyż w sumie produktem analizy jest jakiś projekt czyli model tego co analizowano, model tego co rekomenduję by powstało. Analiza sama z siebie nie jest samowystarczalna (to znaczy samo analizowanie nie jest wartościowym produktem samym w sobie). Problemy z projektami obserwuje nie ja jeden. W każdym kolejnym projekcie staram się szukać przyczyn, zrozumieć problem i podjąć próbę rozwiązania. Problem w zasadzie jest znany. [...] Dalej mamy same dobre rady, z którymi trudno polemizować:Wysoka modularność, współpraca wielu niezależnych, lub luźno powiązanych elementów, możliwość wymiany małych części, lub tworzenie różnych wariantów tego samego modułu, to podejścia, które przyniosą nam wartość dodaną. Ludzie mający do czynienia z monolitami (układ: jedna wielka baza danych i do tego wielki serwer aplikacyjny) z reguły postrzegają podejście rozproszone (dziesiątki lub setki małych kawałków fruwających gdzieś w koło) jako trudniejsze, bardziej skomplikowane i przez to gorsze i bardziej ryzykowne. Takie spojrzenie to postawienie sprawy do góry nogami.I tu moim zdaniem autor ma 100% racji. Nie ma chyba nic gorszego niż uznanie, że "jeden wielki zintegrowany system" to zaleta tego Systemu, jest to jego największa wada.

Czytaj dalej

Prawo a wymagania …

Post author:Jarosław Żeliński
Post published:11 czerwca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:13 lutego 2013

Podstawową korzyścią z wyodrębnienia reguł biznesowych i słownika pojęć jest uporządkowanie słownictwa w dokumentacji i uczynienie jej jednoznaczną oraz weryfikacja ewentualnych sprzeczności regulacji wewnętrznych (Zarządzeń, Prawa). Powoływanie się na Reguły biznesowe na modelach procesów biznesowych, pozwala zachować ich prostotę nie tracąc szczegółowości wiedzy o procesach. Tak wykonana dokumentacja procesów nie wymaga częstej i kosztownej aktualizacji, z reguły aktualizowane są procedury i reguły biznesowe, na które modele procesów się powołują.Tak więc akty prawne to zakazy i nakazy, reguły biznesowe. Oprogramowanie, zależnie od przyjętej konwencji, nie powinno ograniczać ani nawet utrudniać postępowania zgodnego z prawem, może pojawić się oczekiwanie by nie pozwalało łamać prawa. Szczegółowa analiza aktów prawnych, w moich oczach, ma sens gdy projektujemy oprogramowanie. Gdy stawiamy wymagania przed już istniejącym oprogramowaniem, zakładamy że kupimy gotowe, wystarczy wymagać zgodności z prawem w obszarze stosowania oprogramowania. Jeżeli np. oprogramowanie ma pozwalać na wystawianie faktur to znaczy, że powinno być możliwe wystawienie każdej faktury przewidzianej prawem w sposób zgodny z nim. Możemy dodatkowo zażądać by nie było możliwe wystawienie faktury niezgodnej z prawem.

Czytaj dalej

Czym jest to co modelujesz w oprogramowaniu? Model dziedziny systemu jako wymaganie.

Post author:Jarosław Żeliński
Post published:8 marca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:28 lipca 2018

zły model to złe oprogramowanie....Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą [[Martina Fowlera]]: grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każda przyszłą partią.Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną "obsłużone".

Czytaj dalej

Koniec treści

Nie ma więcej stron do załadowania

Nowsze wpisy

Starsze wpisy