analiza biznesowa – Page 21 – JZ IT Consulting Ltd

Czego moglibyśmy się nauczyć od naukowców?

Post author:Jaroslaw Zelinski
Post published:19 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

I tu zaczynają się schody. Bo jeżeli rozumiem programistów, że lubią się bawić, to nie rozumiem dlaczego od razu chcą latać na prototypach samolotów, gorzej, nie chcą czekać na projekt i te śmieszne rysunki techniczne. Dlaczego inżynier mechanik chce zajmować się projektowaniem tego jak ma wyglądać i latać samolot skoro jego rola i kompetencje to konstruowanie a nie np. badanie satysfakcji klienta z lotu na wygodnym fotelu... Jak mam sobie wyobrazić tworzenie samolotu w postaci podstawianych na lotnisko pasażerskie kolejnych prototypów? Czy każdy projekt IT to samoloty? Tak! Tam pracują ludzie, płacą za to i cierpi ich biznes jak oprogramowanie nie zadziała jak trzeba! Co mogę po tym powiedzieć? Państwo sami zdecydujcie co wolicie w swoich projektach: 200% narzutu na swobodne podejście dostawców oprogaramowania czy 20% na dobrego analityka projektanta...

Sprawna Inżynieria Oprogramowania – role w projekcie

Post author:Jaroslaw Zelinski
Post published:18 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

W projektach informatycznych najczęściej spotykamy: analityka wymagań (AW), analityka systemowego (AS), dewelopera w tym architekta systemu (D). W zasadzie trudno powiedzieć co jest produktem każdego z nich. Najczęściej AW dostarcza jakiś opis tego czego oczekuje klient, AS robi porządkuje to zrobił AW np. z pomocą przypadków użycia a D bierze to do ręki i musi zaprojektować i wykonać oprogramowanie. Jak widać, odpowiedzialność za to co powstanie jest rozmyta. Klient najpierw przekazuje swoje oczekiwania AW zaś otrzymuje produkt od D. Konia z rzędem temu, kto mi powie jak tego dokonać bez permanentnych iteracyjnych wyjaśnień i bombardowania Klienta pytania w rodzaju "co Państwo mieli na myśli pisząc...".

A na grzyba nam Pan Analityk?

Post author:Jaroslaw Zelinski
Post published:12 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Przecież analizę zrobimy sami, a jak nie - to zrobi to dostawca. Tak często rozpoczyna się tak zwana "Droga do klęski". Rzemieślnicy produkujący ?przed Kopernikiem? skomplikowane i kosztowne przyrządy do określania położenia planet i gwiazd z wiadomych powodów nie byli zainteresowani upraszczaniem modelu geocentrycznego i swoich skomplikowanych przyrządów. Dlatego zapewne nie raz jeszcze usłyszę, że dobra analiza to setki stron, tysiące wymagań, miesiące pracy. Jednak dobra analiza to tylko: dziesiątki stron i wymagań, tygodnie pracy ale nie dyktafon a zaawansowane metody, takie jak formalna analiza systemowa oparta na modelach i ich testowaniu.

Rentowność projektu czyli jego wizja i wykonywalność – należy planować

Post author:Jaroslaw Zelinski
Post published:28 April 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Dlaczego takich analiz wykonuje się mało? No cóż, nie są one w interesie dostawcy, który twierdzi, że jego system np. ERP jest "na pewno dobry". Po drugie wiele firm uznaje, że ich nie dotyczy ryzyko projektowe i pomijają analizy, a te są przecież niczym innym jak obniżeniem ryzyka niepowodzenia takich projektów. Pamiętajmy, że ponad 80% projektów wdrożeniowych w IT to projekty z silnie przekroczonymi budżetami i terminami, część z nich (szacuje się je na ok. 16%) to projekty zaniechane z tego powodu. Każdy z Państwa sam musi sobie odpowiedzieć na pytanie: czy 20% budżetu jest warte tego by chronić pozostałe 80%.

CRM – jaką pełni rolę

Post author:Jaroslaw Zelinski
Post published:18 April 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

nie wiem co to jest CRM ale mogę powiedzieć, że zarządzanie to określenie czego i od kogo oczekujemy, określenie swobód i ograniczeń każdemu pracującemu, określenie miar, których użyjemy do oceny spełnienia tych oczekiwań. Zarządzanie to ciągły proces, w którym menedżerowie, ustalając te swobody i ograniczenia kształtują środowisko pracy w organizacji tak, by możliwie najefektywniej spełniała ona swój cel: tworzyła wartościowy produkt dla klienta. Wspomniany przez czytelnika na początku kontakt menedżer to nic innego, jak współdzielone dane o kontrahentach i dokumentach z nimi powiązanych. To dlatego bardzo często repozytorium dokumentów z metadanymi (w tym także powiązania dokument - kontrahent) wystarczą. Jeżeli chcemy dodatkowo usprawnić pracę z pomocą takiego repozytorium, powinno ono mieć funkcjonalność generowania zdarzeń powiązanych z dokumentami: fakt ich pojawienia się oraz zdefiniowanych, powiązanych terminów. Każde takie zdarzenie ma (może mieć) swoich subskrybentów. Skoro dane są przechowywane, system raportowy poda nam każdą pożądaną statystykę, na ich zaś podstawie można wyciągać wnioski co do wprowadzenia ewentualnych zmian w ograniczeniach. I pętla zarządzania się zamyka! A gdzie te śmieszne "przypływy dokumentów"? One są albo skutkiem ograniczeń, albo wymuszone przez procedurę albo efektem reguł biznesowych i kompetencji. Bez analizy tych zjawisk nie da się jednoznacznie opisać tak zwanych "przepływów dokumentów" bo tylko mała cześć z nich to efekt sztywnej procedury, którą faktycznie można opisać diagramem.