Zapraszam wszystkich, którzy szukają pomocy, wiedzy oraz wsparcia w swoich projektach informatyzacji. Działam od 1991 roku, mój Blog działa nieprzerwanie od 1998 roku.
Jeżeli nie potrafisz czegoś narysować to znaczy że nadal tego nie rozumiesz. Jeżeli potrafisz coś narysować to potrafisz to także zbudować.
Na podstawie dobrych praktyk inżynierii systemów oraz analizy procesowej (przedstawionej m.in. w artykule na stronie JZ IT Consulting – Fast Start!), modele referencyjne pełnią rolę sprawdzonych wzorców i struktur opisujących najlepsze praktyki branżowe.
Oto kluczowe zalety ich wykorzystania:
Oszczędność czasu i redukcja kosztów (Fast Start)
Brak “pustej kartki”: Zamiast projektować architekturę lub mapę procesów od zera, organizacja startuje z gotowego szkieletu dopasowanego do danej branży.
Niższa pracochłonność analizy: Wykorzystanie wzorca znacznie skraca czas trwania analiz biznesowych i wdrożeniowych, co bezpośrednio przekłada się na mniejsze koszty usługi doradczej oraz szybsze uruchomienie systemu IT.
Łatwiejsza identyfikacja obszarów do optymalizacji
Benchmarking: Model referencyjny stanowi punkt odniesienia, z którym firma może porównać swoje obecne działania.
Wykrywanie wąskich gardeł: Pozwala szybko zidentyfikować luki, nieefektywności oraz miejsca wymagające usprawnienia lub cyfryzacji.
Standaryzacja i wysoka jakość procesów
Zgodność z najlepszymi praktykami: Oparcie działań na uznanych standardach rynkowych zwiększa przewidywalność i jakość operacyjną firmy.
Unikanie ponownego “odkrywania koła”: Standardowe procedury (szczególnie w obszarach wspierających, takich jak back-office, księgowość czy HR) są już zoptymalizowane i gotowe do wdrożenia bez zbędnych modyfikacji.
Skupienie na unikalnej przewadze konkurencyjnej
Podział na procesy główne i wspierające: Pomaga odseparować działania standaryzowane od obszarów kluczowych dla firmy.
Alokacja zasobów: Pozwala firmie skupić się na precyzyjnym modelowaniu i dostosowywaniu jedynie tych unikalnych procesów operacyjnych (Primary Activities), które budują jej rzeczywistą przewagę na rynku i stanowią chronione know-how.
Elastyczność i możliwość adaptacji
Modyfikowalność: Gotowy model referencyjny nie jest sztywnym dyktatem — można go łatwo dostosowywać poprzez zmianę kroków procesowych, terminologii czy specyficznych wymagań branżowych.
Ewolucyjność: Modele rozwijają się wraz z rynkiem, uwzględniając nowe technologie i zmiany regulacyjne.
Wspólny język i precyzja komunikacji
Lepsza współpraca z dostawcami IT: Zmniejsza ryzyko nieporozumień na linii biznes – dostawca oprogramowania, dostarczając jednoznaczną i precyzyjną dokumentację wymagań.
Ochrona własności intelektualnej: Precyzyjny opis procesów i architektury w oparciu o model referencyjny ułatwia formalno-prawną ochronę know-how organizacji.
Zapytanie ofertowe
“Mam pytania ale nie chcę jeszcze ujawniać swoich danych”
Anonimowy czat: Korzystając z czatu oświadczasz, że akceptujesz fakt jawności umieszczanych tu treści. Czat nie służy do udzielania konsultacji i świadczenia usług doradczych, stanowi miejsce spotkań i rozmów na tematy usług które oferuję oraz do proponowania tematów nowych artykułów.
Latest Message:3 days, 22 hours ago
guest_7639 : Jest Pan naukowce, jak Pan podchodzi do tematu doktoratu w Polsce. dlaczego takowego nie posiada?
Jaroslaw Zelinski : guest_7639 Dla mnie doktorat to takie powiedzenie sobie "sprawdzam". Po trzech podejściach do doktoratu, każde na innej uczelni, zrezygnowałem z powodu biurokracji i jakości środowiska naukowego w Polsce, a "sprawdzam" to teraz dla mnie recenzowane publikacje naukowe poza Polską, na razie mam dwie w USA wydane przez przez IGI Global, obie są wiec w Bibiotece Kongresu USA.
Jaroslaw Zelinski : guest_8648, sposób wykorzystania dowolny
guest_7840 : Kojarzy lub może polecić Pan firmy gdzie można się zatrudnić i szlifować analizę i projektowanie w oparciu o MDA, pracę na CASE?
Jaroslaw Zelinski : guest_7840 , jeżeli wierzyć statystykom, to jest to mniej niż 10% jeśli chodzi o firmy... paradoksalnie głównie przemysł, bo tam maja nawyki projektowania, inne to raczej przypadkowe projekty, w których ktos uznał, że jednak v-model a nie agile..
Jaroslaw Zelinski : guest_7840 , c.d. wiele firm (ich zarządy) uważają, że szkolenie pracowników to zbędny wydatek, dlatego jak ktoś chce to raczej uczy sie sam lub z pomocą
guest_4195 : To może być głupie pytanie ale, Pana zdaniem, lepiej najpierw doszlifować wiedzę o notacjach czy o VisualParadigm i na nim uczyć się dalej?
guest_9242 : W historii chatu widzę bardzo ciekawą dyskusję o BPMN i UML i modelowaniu procesu "ludzkiego" oraz "maszynowego". Chciałem jeszcze zapytać o BPMS/ Camunda BPMN- jak bardzo należy rozpatrywać w kategorii błędów kardynalnych użycie takich diagramów w dokumentacji? Szczególnie tam, gdzie proces ludzki naturalnie miesza się z tym maszynowym.
Jaroslaw Zelinski : guest_4195, najpierw notacje, ale bez przesady, podstawy, kluczem jest raczej rozumienie tego czym jest architektura aplikacji
Jaroslaw Zelinski : guest_9242, nie ma czegoś takiego jak proces ludzki zmieszany z maszynowym, tak samo jak nie ma czegoś takiego jak "proces tokarski" zmieszany z ludzkim, jest człowiek i jest narzędzie, którego używa, pozostaje ustalenie co robi narzędzie
guest_668 : Dzień dobry,Czy uważa Pan, że draw.io, MIRO, paint, i jakiekolwiek inne narzędzia niebędące VP/EA degradują znaczenie wytworzonych schematów, jeśli spełniają swoją funkcję, którą w istocie jest (dla większości firm IT),
guest_668 : Ucięło, - w istocie jest wizualizacja procesów dla całej firmy.
Jaroslaw Zelinski : guest_668 problem w tym, że ta wizualizacja bez walidacji ma mały sens... te narzędzia powstały do tworzenia grafiki prezentacyjnej a nie do projektowania. Czym jest ta "wizualizacja" skoro nie jest testowalna? Kto w podróży korzysta z mapy nie mając pewności że ona nie kłamie? Tak większość firm IT pracuje na obrazkach i ta większość walczy z odkrywanymi wymagania każdego dnia..... Jaką Wartość ma "wizualizacja procesów całej firmy" skoro powstała na bazie subiektywnej i niezweryfikowanej wiedzy pracowników? Jak sprawdzić kompletność, spójność i niesprzeczność tych "wizualizacji"?
Jaroslaw Zelinski : guest_668 c.d. Mam teraz kolejny projekt, w którym od klienta dostałem takie wizualizacje jako materiał wejściowy. Te obrazki powstawały na wielodniowych warsztatach z pracownikami. Teraz z pomocą VP sa formalizowane i walidowane, okazało sie te wizualizacje są dziurawe jak ser szwajcarski, i nie mam prawie połowy tego sie dzieje w firmie za to jest masa zbędnych detali. Dlaczego zwrócili sie do mnie? Bo prezesowi puściły nerwy gdy zobaczył kolejna fakturę za zmiany i poprawki, bo za każdym razem odkrywają cos czego nie było na wizualizacji a jest potrzebne, bo te wizualizacje w MIRO nie pokazują żadnych zależności między procesami i żadnych związków tych procesów z aplikacjami. Mają te wizualizacje w projekt szedł jak szczur w labiryncie. Ja na diagramach w VP wyłapuje teraz wszystkie błędy logiki zanim powstanie choć jedna linijka kodu.
guest_5103 : 1. jaką literaturę Pan poleca aby szlifowac czy też zrobic konkretnie mocne fundamnety dot analizy biznesowei i analizy systemowej
Jaroslaw Zelinski : guest_5103, proponuje od mojej książki :))), jest tam także bibliografia, na moi blogu świadomie i celowo umieszczam od wielu lat zalecają literaturę przy artykułach.
guest_9259 : https://it-consulting.pl/2026/07/09/dokument-a-forma-dokumentowa-i-podpis/ pierwszy raz widzimy u Pana, na modelu pojęciowym zastosowanie krotności oraz kompozycji. Dotychczas pisał Pan wielokrotnie, że model pojęciowy to wyłącznie pojęcia oraz związki asocjacji oraz generalizacji. Skąd więc na diagramie pojawiły się kompozycja oraz krotności? Zmienił Pan podejście?
Jaroslaw Zelinski : guest_9259 , bo to diagram klas UML a nie diagram faktów SBVR, ma nieco większe możliwości definicyjne. Standardowo krotności w SBVR do elementy reguł i definicji a nie diagramów, użycie diagramu klas UML pozwolił mi "legalnie" obejść to ograniczenie, ten diagram klas UML to nadal model pojęciowy w nomenklaturze UML 🙂
Jaroslaw Zelinski : guest_9259 c.d. diagram faktów SBR to okrojony diagram klas, służy wyłącznie do modelowania związków pojęciowych z użyciem predykatów (ontologie) i taksonomii, SBVR wymagało by napisania reguł: np. "jeden dokument ma jeden lub więcej egzemplarzy", w UML można to "narysować".
guest_9259 : Chociaż jak czytamy (dodatek C) dokuumentacji SBVR mamy wzmiankę o związku partitive connections, więc w sumie agregacja semantycznie pasuje 😉
Jaroslaw Zelinski : guest_9259, w każdej specyfikacji dodatki, które warto tez czytac 😉
Jaroslaw Zelinski : c.d. ale generalnie notacja to język, rzecz w tym, by dobrać język adekwatny do problemu i nie łamać jego zasad 🙂
guest_9259 : Czyli generalnie patrząc na dodatek C zarówno stosowanie związku agregacji jak i rozszerzenia diagramu pojęciowego o krotności nie łamie notacji.
Jaroslaw Zelinski : guest_9259 , o ile pamiętam jest w SBVR podrozdział, że diagram faktów to w sadzie "okrojony diagram klas". diagram kas w UML służy zresztą do tworzenia modeli i pojęciowych i struktury kodu. Visual Pradigm (i nie tylko) traktuje diagram faktów osobno by nie mieszać modeli pojęciowych i architektury kodu co w projektach bardzo pomaga utrzymać porządek w repozytirum.
guest_7539 : Czyli w zasadzie to, co mamy w dodatku C, traktujemy raczej jako "rozszerzenie" do diagramu faktów, które można stosować wykonując diagram modelu pojęciowego, tak długo jak to jest przydatne z punktu widzenia zrozumienia problemu.
Jaroslaw Zelinski : guest_7539 raczej jest tak, że diagram faktów to "okrojona" wersja diagramu klas na potrzeby ontologii, "liczność klas" to "zabieg" pozwalający pokazać reguły biznesowe takie jak np. "samochód może być prowadzony tylko przez jednego kierowcę" i nie należy tego mylić z "relacjami" ER.
guest_142 : Jeśli pracuję w projekcie, w którym jest pudełkowy CRM, to jak to udokumentować? Procesy biznesowe + UC i scenariusze + diagramy aktywności dla bardziej skomplikowanych algorytmów?
Jaroslaw Zelinski : guest_142 : BTW: procesy biznesowe nie dokumentują aplikacji tylko firmę, to nie to samo.
guest_142 : Dziękuję.
Jaroslaw Zelinski : 🙂
guest_111 : Czy możliwe jest aby model aplikacji był jeden, a różne GUI? Np. inny GUI dla klienta poczty, a inny dla tej przysłowiowej "pani z okienka"?
Jaroslaw Zelinski : guest_111, to zależy od projektu i projektanta, aplikacja to jej usługi a te to nic innego jak formularze ekranowe. Ale np. treść faktury, czyli jej widok, nie zależy od tego czy patrzy księgowa czy klient, który kupił trampki czyż nie? I nie ma czegoś takiego jak "ekran pani z okienka", jest konkretny dokument i to czy określony użytkownik jest jest twórca czy adresatem.
guest_2819 : dzień dobry
guest_2819 : czy będzie na blogu wpis na temat vp 18.1?
guest_6540 : Co Pan uważa o spec-driven development?
guest_9633 : guest_2819 v.18.1 nie wnosi niczego wielkiego poza integracja ze znanymi AI (rynek chce :))))) ... ale to co produkuje AI do niczego sie nie nadaje,
Jaroslaw Zelinski : to byłem ja 🙂
Jaroslaw Zelinski : guest_6540, tworzenie wykonywalnej specyfikacji nie ma żadnego sensu, bo: 1. co do zasady i nie przypadkiem etap projektowania to "platform independent model", 2. co do zasady projekt logiki działania system ma być zrozumiały dla "przeciętnego biznesu", to co nazywamy "jedno źródło prawdy to model działania a nie kod, który z zasady jest wtórny ...
Jaroslaw Zelinski : BTW: byłem na krótkim urlopie, stąd dopiero dziś odpowiedź
Jaroslaw Zelinski : guest_6540, Od lat widzę i rozumiem wstręt koderów do wszystkiego co nie jest kodem, ale to właśnie powody porażek, i dlatego na świecie coraz rzadziej oddaje sie projekty koderom ... sorry.
Jaroslaw Zelinski : Po czterech oderwania od IT i biznesu dniach wróciłem 🙂 .
Guestex : Dzień dobry, imponuje mi pańskie rozumowanie przy budowaniu systemów j aplikacji. Czy jest jakaś książka/książki/materiały, które najbardziej wpłynęły na to.podejście? Dziękuję za odpowiedź. Pozdrawiam
guest_9259 : Jakie inne źródła literaturowe poza Weilkensem poleca pan, gdzie piszą o tym, że nie należy "tłumaczyć" modelu pojęciowego na model architektury LLD?
Jaroslaw Zelinski : guest_9259, odtwarzanie taksonomii w kodzie to chyba najgorsza forma programowania z perspektywy komplikacji kodu
Jaroslaw Zelinski : Guestex : to były lata 90te, gdy odkryłem, że relacyjny model danych i SQL masakrycznie wszystko komplikuje. To było (i jest) dobre do tworzenia systemów księgowości, ale nie do zarządzania treścią, gdzie liczby stanowią ułamek treści. Literatury jest nie mało ale ona ginie w "głównym nurcie" jakim jest C++/JavaEE/.NET.
Jaroslaw Zelinski : guest_9259, dlatego od kilku lat staram sie w artykułach na blogu przywoływać wszelkie źródła