Business Model vs. System Model

Swego czasu pisałem o tym, że np. klasa przechowująca informacje o pracowniku raczej powinna nazywać się DaneOPracowniku a nie Pracownik. Dlaczego? Bo projekt systemu zawierający informacje o pracownikach i klientach, a także treść wielu dokumentów, powinien pozwalać zrozumieć co jest "w systemie" a co w "rzeczywistości" (pracownik jest żywym organizmem, oprogramowanie co najwyżej zarządza danymi opisującymi tego pracownika). Ku mojemu zaskoczeniu ale także radości, niemalże ten sam problem poruszył Ron Ross (bloger i autor książki BUILDING BUSINESS SOLUTIONS: Business Analysis with Business Rules): To make a long story short, business models talk directly about real-world things (as business people do);…

Czytaj dalejBusiness Model vs. System Model

RE: Duży monolityczny ERP czy integracja

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 dalejRE: Duży monolityczny ERP czy integracja

Duży monolityczny ERP czy integracja

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 dalejDuży monolityczny ERP czy integracja

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

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 dalejCzym jest jakość oprogramowania… a może od czego ona zależy?

Model jako symulacja – także w analizie i projektowaniu oprogramowania

Model dziedziny nie powinien więc być diagramem słownikowym (diagram klas z gęsto powiązanymi klasami nafaszerowany dziedziczeniem i asocjacjami). Taki diagram to model pojęciowy (pojęcia słownikowe) nie nadający się do implementacji. Wymaga jeszcze wiele pracy. Jeżeli skażemy na nią programistę, osobę która nie zna tej "dziedziny", to z dużym prawdopodobieństwem powstanie "coś co nie koniecznie jest tym czymś co powinno powstać", i nie jest to wina tego programisty tylko tego, który mu dał opis tego co ma powstać w takiej właśnie, niezdefiniowanej postaci. [...] Tak więc szanowni klienci: sprawdzajcie co Wam dają analitycy, jeżeli model dziedziny systemu jest dla Was totalnie nie zrozumiały (to co mówi lub referuje analityk), to prawdopodobnie jest to zły model...Tak więc model dziedziny opisujący sprzedaż, powinien zawierać obiekt biznesowy Faktura ale obiekt ten nie powinien mieć operacji "nowa faktura", model powinien zawierać odrębny obiekt np. NarzędzieFakturzysty, mający "w sobie" wiedzę o tym jak się wystawia faktury. Powody są dwa: techniczny opisał powyżej kolega programista, drugi powód jest bardzo prozaiczny: bo faktury same się nigdzie nie wystawiają...

Czytaj dalejModel jako symulacja – także w analizie i projektowaniu oprogramowania

Analiza oddziaływania i jakość modelowania

Model zawierający wyżej opisane śladowania (i tylko taki!) pozwala na analizę zalezności, np. chcemy dowiedzieć się na co ma wpływ Proces_2, wtedy powinien powstać np. taki diagram:Jak widać, śladowanie jest tu warunkiem koniecznym dlaczego? Taki model może powstać "automatycznie" (narzędzie do modelowania musi posiadać taka funkcjonalność). jednak to nie jedyny warunek: model musi zachowywać formalna poprawność, czyli nie używamy pojęcia Rola (pas na modelu procesów) do symulowania "systemu" który coś robi, bo oprogramowanie to narzędzie człowieka (rola w procesie), specyfika użycia danego narzędzia to umiejętności aktora (użytkownika) i jest to co najwyżej problem skojarzenia danej czynności (procesu) z dokumentem opisującym procedurę lub instrukcję użytkownika (to także narzędzie powinno umożliwiać).Wszelkie łamanie formalizmów notacji odnosi taki sam skutek jak np. wykorzystywanie pól w bazie danych do przechowywania innych danych niż te z nagłówka np. wpisywanie drugiego imienia do pola Nazwisko czy nazwy dzielnicy w pole Miasto. Z takiej bazy danych żaden sensowny raport już nie powstanie. Jeżeli na modelu procesów użyto symboli w innych znaczeniach niż to wynika z użytej notacji żadnej sensownej informacji też nie uzyskamy... to już nie modele tylko zwykłe obrazki.

Czytaj dalejAnaliza oddziaływania i jakość modelowania

Znajomość branży klienta szkodzi a nie pomaga…

Jakie doświadczenie i gdzie jest potrzebne I teraz pytanie jakie architekt budowlany musi mieć doświadczenie, jeżeli chce zaprojektować most? Wypadało by nie był to jego pierwszy most, ale czy musi znać miasto, w którym ten most powstanie? Czy musi mieć "doświadczenie kolejowe" dlatego, że to most kolejowy? Raczej nie, powinien mieć doświadczenie w projektowaniu mostów.Dlatego ktoś, kto ma rolę analityka i projektanta w projekcie, powinien mieć bardzo duże doświadczenie w analizie i projektowaniu, ale znajomość konkretnej branży nie wnosi tu żadnej wartości dodanej, a biorąc pod uwagę fakt, że rutyna zabija, potrafi być wręcz szkodliwe.Jeżeli to zamawiający oczekuje analityka z doświadczeniem w swojej branży, nie raz kieruje się on przypuszczeniem, że to ułatwi komunikację z nim. Jednak problem tkwi nie w znajomości branży a w komunikatywności ogólnie. Analityk powinien się cechować bardzo dobrymi zdolnościami komunikacyjnymi a nie znajomością konkretnej branży (wtedy raczej ryzykuje popadniecie w slang branżowy, co raczej przeszkadza niż pomaga).Z perspektywy dostawcy rozwiązań, popularyzującego tezę, że "on jest lepszy bo ma wiedzę z danej branży", jest to raczej próba stworzenia sztucznej bariery wejścia dla konkurentów, bo z wyżej opisanych powodów trudno o inne uzasadnienie... Zwróćmy uwagę, na to, że firmami, poza nielicznymi wyjątkami, zarządzają specjaliści od zarządzania. Branża ich doświadczeń ma tu drugorzędne znaczenie bo konkretny rynek musi znać dyr. marketingu a nie prezes firmy, ten drugi musi się umieć z tym pierwszym dogadywać. Inżynierowie dziedzinowi w roli prezesów, Ci częściej doprowadzają swoje firmy do upadku...

Czytaj dalejZnajomość branży klienta szkodzi a nie pomaga…

Sprzedam Ci prawa do kodu czyli wielka ściema

A może chcecie prawa do kodu źródłowego?A jasne, możemy chcieć. "No to zapłaćcie za to prawo". A przepraszam za co teraz? Kod, który powstał to utwór zależny, jest więc chroniony i już mamy na niego wyłączność, nie musimy ekstra za to płacić. Ale nie chcemy tego sami pisać (kodować) jeszcze raz. No dobrze, patrzymy na faktury, a tam jest kilkaset godzin programistów. Czyli co? Już zapłaciliśmy za ich pracę, za ten kod! Wystarczy!Kiedy pojawia się problem?W większości przypadków z jakimi się niestety spotykam to projekty, w których nie powstała opisana tu dokumentacja. Jaki mamy efekt? No jest kod, wszelkie prawa do niego i jego logiki ma wykonawca (jest autorem całości). Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych podlega wyłącznie ochronie jako dzieło literackie, jednak niestety to-co-program-ma-robić to tylko idea, a ta nie podlega ochronie (stwierdzenie faktu, że wystawiamy faktury, jako treść, nie stanowi żadnego zdatnego do ochrony tajemnicą firmy know-how). Tak więc wszelkie prawa do kodu ma w takim wypadku programista bo sam od zera to napisał (kod).Pada propozycja: za dodatkowe pieniądze sprzedamy prawa majątkowe do kodu, będziecie się Państwo czuli bezpiecznie. I teraz pytanie: jaką wartość ma nieudokumentowany kod oprogramowania? Tysiące linii kodu programu, nie raz kilka milionów, pisany bez projektu w wielu iteracjach. Mamy którąś tam jego wersję, w końcu powstawał w bólach, wielokrotnie modyfikowany, bez projektu. Nakład pracy znacznie przewyższający jego przepisanie. Kto i jakim kosztem będzie ten kod analizował by go zrozumieć i rozwijać? Ten kod, bez jego autora, jest BEZWARTOŚCIOWY a My, bez tej opłaty, nie mamy żadnych praw do tego za co zapłaciliśmy (poza licencją czyli prawem do korzystania).Tak więc niejednokrotnie oferta na sprzedaż praw do kodu to zwykła ściema!

Czytaj dalejSprzedam Ci prawa do kodu czyli wielka ściema

Krótki wpis o śladowaniu

Dobrze opracowany, kompletny model organizacji, łączy w sobie:model motywacji biznesowej, [[model struktury organizacyjnej]], model procesów biznesowych (wymieniony już powyżej), model reguł biznesowych. Elementy każdego z tych modeli są ze sobą powiązane: role w procesach są wywodzone ze stanowisk w modelu organizacyjnym, analizowane procesy są wywodzone z modelu motywacji, reguły biznesowe są kojarzone z czynnościami w procesach i wywodzone z aktów prawnych i wewnętrznych zarządzeń.Mając tak opracowany kompletny model organizacji, zawierający śladowanie, i odpowiednie oprogramowanie CASE można przeprowadzić analizę oddziaływania, np. sprawdzić na jakie osoby w organizacji przeniesie się zmiana wybranych reguł biznesowych. Mając model systemu informatycznego skojarzony z procesami, można sprawdzić wpływ awarii poszczególnych podsystemów na procesy biznesowe i ich skutki dla firmy. Takich analiz można wykonać wiele, nie było by to możliwe bez tak skonstruowanego modelu.Dlatego, podstawową wartością poprawnie wykonanych modeli organizacji i użycia właściwych narzędzi, jest nie tylko opracowanie wymagań np. na oprogramowanie. Możliwe jest testowanie reakcji elementów struktury organizacji na zdarzenia np. awarie. Możliwe jest opracowanie projektów integracji, wymiany oprogramowania. Możliwe jest sprawdzenie na co ma wpływ np. nieoczekiwana obecność pracownika. To tylko wybrane przykłady, jednak możliwe jest to wyłącznie pod warunkiem posiadanie poprawnie wykonanego modelu.

Czytaj dalejKrótki wpis o śladowaniu

Prawo a wymagania …

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 dalejPrawo a wymagania …

Wiedza po studiach… krótko

Niestety obecna "kadra analityczna" wielu firm, także ta "samodzielna freelancerska" to rzesza ludzi władająca pseudowiedzą. Na rynku księgarskim królują poradniki w rodzaju "analityk biznesowy w trzy tygodnie", po audytach dokumentów spotykam się z argumentami w rodzaju "ale ja mam certyfikat analityka po dwudniowym kursie i tam tak pokazywano". O testach egzaminacyjnych już nie będę pisał bo nie ja jeden uważam, że to odmóżdżanie a nie kontrola wiedzy."Drodzy Młodzi Przyjaciele. Czuję się w obowiązku zwierzyć się Wam z bardzo przykrej tajemnicy. Nie jesteście - większość z Was - dobrze wykształceni, a jedynie tak Wam się wydaje. Zostaliście oszukani najpierw przez nauczycieli, a potem przez wykładowców" - wyznaje Jan Stanek, profesor fizyki z Uniwersytetu Jagiellońskiego

Czytaj dalejWiedza po studiach… krótko

Procesy biznesowe lepiej z regułami biznesowymi i zasobami

W wielu firmach system zarządzania jest tak niespójny, że jedynym sposobem funkcjonowania tych firm, jest łamanie zasad przez jej pracowników. Niestety pierwsza wpadka często powoduje załamanie się całego systemu (a nie raz i firmy). Wiele Zarządów firm nie zdaje sobie nawet sprawy z tego, jak duże jest ryzyko ciągłości funkcjonowania ich firm.Tak więc model procesu to nie algorytm działania firmy, wykazano nie raz, że algorytmizacja pracy ludzi jest niecelowa (wtedy stosujemy roboty).Znaczna część tego co robią ludzie to efekt ich kompetencji, wiedzy i doświadczenia, a nie dyktowania im jak mają wykonywać swoja pracę.Jeżeli wybierzemy drogę modelowania tego wszystkiego diagramami, to ilość tych diagramów szybko przekroczy granicę sensy całego projektu: nie będą czytane. Ich wartość będzie żadna.W procesie dobrze przygotowanej analizy (jakiejkolwiek) modele tworzy się by je badać, a nie tylko po to by powstały za pieniądze sponsora projektu.Należy też nabrać pokory: większość organizacji sprawnie funkcjonuje nie mając żadnych modeli procesów, więc teza, że ich brak szkodzi jest nie do obrony. Po co więc te modele? Żeby zrozumieć dlaczego tak jest i co się stanie, gdy zechcemy wprowadzać zmiany.

Czytaj dalejProcesy biznesowe lepiej z regułami biznesowymi i zasobami

Koniec treści

Nie ma więcej stron do załadowania