analiza przedwdrożeniowa – Page 8

Dokumentowanie wymagań na systemy nie tylko ERP – droga do porażki

Post author:Jaroslaw Zelinski
Post published:24 May 2008
Post category:Analizy biznesowa i projektowanie oprogramowania

Istotą opisu wymagań na system jest kontekst całego projektu i tej inwestycji a kontekstem tym jest model biznesowy i zakres projektu. Model biznesowy można wykonać nawet metodami formalnymi za pomocą pseudokodu czy języka relacji logicznych jednak model taki jest bezwartościowy, jeżeli nie stanowi sobą zrozumiałego przekazu dla każdego zaangażowanego w projekt czytaj "szczególnie klienta biznesowego". Kluczem do sukcesu jest tu modelowanie czyli zobrazowanie w sposób zrozumiały dla każdej strony w projekcie IT istoty biznesu i jego kontekstu w projekcie tworzenia i wdrażania oprogramowania. Model biznesowy i wewnętrzna struktura zarządzania organizacji to nie obiektowe modele a procesowe mapy łańcuchów tworzenia wartości w firmie. Model obiektowy ma zastosowanie dopiero podczas tworzenia modeli informacyjnych czyli struktury danych przechowywanych i przetwarzanych w firmie a dane to nic innego jak reprezentacja tych informacji, które firma chce przetwarzać oraz sposób w jaki chce to robić o czym wielu analityków zdaje się zapominać. Jak więc prowadzić analizy wymagań?

System informacyjny to nie informatyka, kto o tym zapomina – przegrywa

Post author:Jaroslaw Zelinski
Post published:6 March 2008
Post category:Analizy biznesowa i projektowanie oprogramowania

Dużo się mówi od pewnego czasu o architekturze systemów informatycznych zorientowanej na usługi (SOA, ang. Service Oriented Architecture) . Jest to trend zmierzający w stronę budowy tych systemów pod kątem specjalizowanych potrzeb biznesowych. Opisane wcześniej procesy biznesowe to nasze potrzeby zaś system to świadcząca nam pewne usługi infrastruktura. Jeżeli jednym z procesów biznesowych jest w firmie fakturowanie to nasz system informatyczny powinien świadczyć usługę wspierającą ten proces w postaci np. programu lub jego modułu dedykowanego do procesu fakturowania. Program taki lub jego moduł powinien operować takimi danymi jakie my w firmie wykorzystujemy. To jest ten moment, w którym to my określamy wymagania na program a nie dostawca narzuca nam możliwości swojego systemu. Zawsze możliwe jest to, że dany produkt nie spełnia naszych wymagań i nie powinno się z niego po prostu zrezygnować.

Gotowy czy dedykowany system ERP czyli Krawców ciąg dalszy

Post author:Jaroslaw Zelinski
Post published:9 February 2008
Post category:Analizy biznesowa i projektowanie oprogramowania

Inaczej rzecz ujmując, zbudowanie systemu dedykowanego (co by to nie miało tu znaczyć) daje dużą szansę, że konkurencja będzie miała duży problem z szybkim jego "zmałpowaniem" czyli użyciem standardowego, dostępnego na rynku systemu i co jeszcze gorsze, referencyjnych rozwiązań. Zakup takiego "gotowca" to nic innego jak podkładanie się, bo konkurent poczeka na efekty i kupi to samo na rynku bez większego wysiłku. Powiem więcej, dostawca takiego gotowca, jak tylko skończy go wdrażać sam pobiegnie do naszych konkurentów oferując im "branżowe, prekonfigurowane rozwiązania do szybkiego wdrożenia".

Schyłek epoki krawców

Post author:Jaroslaw Zelinski
Post published:6 January 2008
Post category:Analizy biznesowa i projektowanie oprogramowania

System IT powinien się zwrócić w okresie rzędu trzech do pięciu lat. Przyjmuje się taki mniej więcej okres zachodzenia istotnych zmian w otoczeniu rynkowym, niektóre firmy uznają nawet, że w ich branży okres ten nie przekracza jednego roku. Uśredniając podane wartości można uznać, że system IT powinien się zwrócić w trzy lata a minimalna inwestycja to 50tys.złotych. Oznacza to, że (dla uproszczenia nie licząc kosztu pieniądza) średniomiesięczny koszt to 50 tys./36 miesięcy=1388zł. Załóżmy, że na IT firmy wydają 2% przychodów (co moim zdaniem jest optymistycznym założeniem) to na inwestycję taką będzie stać firmę o minimalnych miesięcznych przychodach rzędu prawie 70 tys. zł.

Obieg danych, dokumentów, informacji a proces biznesowy

Post author:Jaroslaw Zelinski
Post published:8 November 2007
Post category:Analizy biznesowa i projektowanie oprogramowania

Kolejna ślepa uliczka jaką dostrzegam w reklamach systemów klasy workflow to wskazywanie jako głównej korzyści ich wdrożenia narzucenie ścisłej kontroli poczynaniom pracowników. Nie znam przypadku wdrożenia systemu zakończonego sukcesem, którego głównym celem było kontrolowanie pracowników wbrew ich woli. Typowym przykładem są różnego typu restrykcyjne systemy kontroli czasu pracy czy kontroli pracy przy komputerze, nadzór urzędnika tą metodą także się nie sprawdza. Lepszy jest moim zdaniem system informatyczny zaprojektowany tak by pomagał pracownikom osiągać ich cele. On niejako wdraża się sam. Systemy kontroli i restrykcji, nawet jeżeli udaje się je wdrożyć, są bardzo kosztowne i często bojkotowane przez ludzi.