analiza biznesowa – Page 9 – JZ IT Consulting Ltd

Nie dać się szantażować swojemu własnemu dostawcy oprogramowania

Post author:Jaroslaw Zelinski
Post published:10 September 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Gdzie tkwi podstęp: Logika Biznesowa Dedykowana MUSI być udokumentowana osobno w sposób jednoznaczny, nie dający programiście pola do własnej interpretacji, a to wymaga opisania tego metodami formalnymi. Logika biznesowa dedykowana musi być odrębnym TWOIM kodem (w umowie prawa majątkowe do niego oraz umowa o ochronie Twojego know-how). Ale to dużo kosztuje! Dostawca oprogramowania i tak na Twój koszt to w jakiejś formie zrobi! Otóż praktyka pokazuje, że zaprojektowanie i wykonanie odrębnej Logiki biznesowej dedykowanej, kosztuje zawsze mniej (nie raz znacznie mniej!) niż koszt dostosowywania ogromnej istniejącej już logiki dostarczonej. Większość kupujących systemy ERP z powodu braku tej wiedzy i pod naciskiem dostawcy oprogramowania, przyjmuje niekorzystną dla siebie metodę wdrożenia i podpisując wcześniej niekorzystną dla siebie umowę (kastomizacja oprogramowania).

Demo System Szachownica

Post author:Jaroslaw Zelinski
Post published:5 September 2013
Post category:Przykładowe projekty

Z uwagi na zainteresowanie moim projektem "demo" stworzyłem tę stronę. Tu będą się pojawiały informacje o kolejnych etapach tworzenia tego dokumentu. Powiadomienia o postępach będą wysyłane mailem do subskrybentów. Projekt…

Po co komu analityk a jeśli tak to jaki czyli bałagan w administracji

Post author:Jaroslaw Zelinski
Post published:19 August 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Być może więc za specyfikowanie wymagań na oprogramowanie powinny odpowiadać urzędy centralne od razu po tym, jak nałożą jakiś ustawowy obowiązek na podległe im urzędy? Wtedy mamy "osobę" analityka, który wykona analizę nowej ustawy i opracuje wymagania na oprogramowanie. Firma, która wygra przetarg, zapewne w ramach swojej analizy i opracowania koncepcji rozwiązania, popyta urzędników o jakieś szczegóły w rodzaju wewnętrzna organizacja pracy urzędu, struktury obowiązków i kompetencji itp. ale nie o to co urzędnik ma robić a czego nie! I dokładnie takie samo podejście polecam firmom: zanim wybierzecie produkt lub wykonawce oprogramowania, jako interesariusze własnych projektów, zlećcie analizę i opracowanie specyfikacji i dopiero potem pozwalajcie własnym Waszym pracownikom decydować o Waszych firmach, nie to będą przynajmniej wasze kadry kierownicze.

Krótka lista pięciu rzeczy, które nie są regułami biznesowymi

Post author:Jaroslaw Zelinski
Post published:31 July 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Od samego początku analizy i projektowania logiki systemu należy skupić się na tym "co i po co" a nie "jak". Zajmowanie się pytaniami "jak" (najgorsze pytanie analizy: jak Państwo to robią) na samym początku, prowadzi do zgromadzenia ogromnej ilości, nadmiarowych, szczegółów, które zamulają prace wszystkich członków zespołu projektowego. Szczegóły, te których znajomość faktycznie wnosi wartość, należy analizować na końcu, wtedy - mając szkielet całego projektu - wiemy które mają jakiekolwiek znaczenie.

Niski poziom analizy…

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

Niestety źle dobrany system informatyczny, mający wspierać/automatyzować czynności w procesie, może być powodem powstania całych podręczników procedur nieuzasadnionych biznesowo, dedykowanych użytkownikom tego systemu, stwarzając przy tym pozory, że to sam proces jest ich źródłem :( Niestety tak się często kończą projekty, w których pomięto analizę i projektowanie i od razu wybrano dostawcę i produkt (analiza wykonana przez dostawce to raczej "jak wdrożyć to co mamy" a nie "jak rozwiązać problem użytkownika"). Problemem większości projektów IT jest założenie, że tylko dostawca/wykonawca usługi ma wiedzę o tym jak to zrobić. Tezę tę forsują najczęściej własnie wykonawcy (developerzy), a problem polega na tym, że wykonawca dąży tu do sytuacji gdy sam sobie stawia wymagania a potem rozlicza ich realizację.