August 2013 – JZ IT Consulting Ltd

Optymalizacja procesów biznesowych

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

Co robić? Po pierwsze oddzielić "grubą kreską" procesy od zadań. Proces to jedno zadanie lub seria zadań (czynności). Model takiego procesu pokazuje kolejność tych zadań, ewentualne warianty tej kolejności. Jeżeli ma to być "mapa", proces musi być deterministyczny (przewidywalny w 100%). Jeżeli tylko okaże się, że liczba wariantów zaczyna nam w toku analiz rosnąć, jest to sygnał, że należy zrezygnować z pisania procedury i przejść na metodę "zespół z kierownikiem". Taki niepodzielny zespół jest reprezentowany na modelu procesów jako rola w osobie kierownika tego zespołu (lub nazwa zespołu). Dokumentacja "wnętrza" sprowadza się do listy reguł biznesowych oraz określenia liczebności zespołu.

Śmierć aplikacji dedykowanych to mit

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

Nikt tu nie namawia nikogo do pisania zintegrowanych systemów ERPII od zera, jednak dostosowywanie ich (kastomizacja) w zasadzie przeczy zdrowemu rozsądkowi, o czym nie raz już pisałem (wyjaśnienie w cytowanym powyżej artykule). Przypomnę, że mamy tu dwa problemy: pierwszy to koszty kastomizacji dużego systemu są niemalże zawsze większe (ja od 20 lat nie spotkałem się z tym by były niższe) niż zaprojektowane nowego dedykowanego modułu. Drugi: kastomizacja powoduje, że całe know-how firmy (związane z tym dostosowywanym oprogramowaniem) zostaje przejęte przez dostawce oprogramowania, który może handlować nim na rynku.

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.

Architekt korporacyjny jako pracownik outsourcowany. Czy to na pewno dobry pomysł?

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

Niedawno napisałem, ze Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją ((Jak rozmawiać z biznesem nt. Architektury Korporacyjnej | Jarosław Żeliński IT-Consulting). Cytowany w tym artykule…

Struktura organizacyjna jako system

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

Jeżeli jeszcze ktoś nie wyczuł podstępu to niniejszym informuję, że powyższy diagram to diagram klas notacji UML. Jego cechą jest to, że klasy zostały przedstawione z pomocą ikon, reprezentujących określone stereotypy. Zgodnie z UML, linie przerywane z grotem reprezentują związki użycia (grot wskazuje na użyty obiekt)), asocjacje z pełnym rombem to kompozycje (związek całość część). Czy taki diagram jest niezrozumiały dla biznesu? Mam także nadzieję, że tu widać wyraźnie, że modelowanie dziedziny systemu w postaci klas połączonych z pomocą prostych asocjacji itp., to nie model obiektowy a nieudolna atrapa bazy danych, która z paradygmatem obiektowym nie wiele ma wspólnego.