analiza biznesowa – Page 15 – JZ IT Consulting Ltd

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

Post author:Jaroslaw Zelinski
Post published:18 June 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

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...

Sprzedam Ci prawa do kodu czyli wielka ściema

Post author:Jaroslaw Zelinski
Post published:15 June 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

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!

Krótki wpis o śladowaniu

Post author:Jaroslaw Zelinski
Post published:13 June 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

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.

Procesy biznesowe lepiej z regułami biznesowymi i zasobami

Post author:Jaroslaw Zelinski
Post published:15 May 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

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.

No to była mała porażka… piszę ku przestrodze

Post author:Jaroslaw Zelinski
Post published:16 April 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Nie będę tu opisywał szczegółów tego projektu, ważne są wnioski a nie ta czy inna firma: pominięcie któregokolwiek etapu projektu analitycznego, w szczególności pierwszego, powoduje, że całość staje się nieweryfikowalna, ryzyko rośnie, ukrycie prawdziwego celu projektu przed analitykiem (jest to możliwe, jeżeli dojdzie to tego co powyżej) powoduje, że większość jego czasu pracy nie służy projektowi, po zanegowaniu efektów pracy analityka, obrona takiego projektu jest niemożliwa bo brak kluczowego narzędzia: śladowanie (przypomnę, że usunięto pierwszy etap - zdefiniowanie celu). Co było prawdziwym celem projektu? Okazało się, że "nie chcemy by przetarg wygrała firma XXX i jej produkt". W trakcie pierwszych problemów z "uznaniem" specyfikacji wymagań dostałem listę wad posiadanego oprogramowania. Ku mojemu zaskoczeniu były tam nawet błędy rachunkowe (inne tu pominę, choćby niezgodność programu z prawem). Pytam: jakim cudem to zostało odebrane i zapłacone? Cóż...