2011 – JZ IT Consulting Ltd

Biznes wychodzi z objęć systemu … monolitycznego ERP

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

Rynek stale się rozwija i dojrzewa. Praktycznie każda większa firma doświadczyła w jakiejś formie wdrożenia gotowego, dostosowywanego do potrzeb, oprogramowania ERP. Warto jednak podkreślić, że idea jednego "super systemu" ERP II, odchodzi powoli do lamusa. Moim zdaniem to kwestia roku, dwóch. Pierwsze symptomy to zalecenia producentów dużych systemów: wdrażać gotowe oprogramowanie w postaci "gotowej" tylko tam gdzie pasuje, obszary specyficzne dla firmy opisać i zaprojektować dla nich dedykowane rozwiązanie i zintegrować. Dobry system ERP to środowisko programistyczne (tak zwany framework, szkielet). Systemy, nawę je "zapóźnione", nadal wymagają ingerencji w ich kod by cokolwiek osiągnąć. Kompromisem jest sytuacja, w której system ERP ma bogaty interfejs (tak zwane [[API, Application Programming Interface]]) pozwalający na integrację dedykowanych podsystemów lub właśnie zewnętrznych komponentów czyli korzystania z możliwości jakie daje Cloud Computing). Przyszłość to komponenty...

Zarządzanie zmianą w projekcie analitycznym

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

No cóż, temat się w rozmowach powtarza, jest nie łatwy więc kilka słów. Pomijając narzędzie, którym się tu posłużę, chodzi o "pryncypia" :): bezpieczeństwo projektu oraz zarządzaniem wersjami, zmianą, w tym wymaganiami. Zarządzanie zmianą Po…

Podwójny obieg dokumentów w urzędach

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

Uważam, że korzyści z elektronicznego obiegu w urzędach są ogromne mimo faktu, że dokumenty inicjujący i kończący są (i długo jeszcze będą) nadal papierowe (ilu ludzi tak na prawdę ma możliwość posługiwania się elektronicznym dokumentem?!). Ważne jest by system taki po pierwsze, został dobrze zaprojektowany gdyż jego celem nie jest zastąpienie papieru, a zmiana sposobu pracy urzędu, a to ogromna różnica. Co jest moim zdaniem największym błędem? To, że urzędy "zamawiając" taki system, z góry zaznaczają, że "wdrożenie systemu elektronicznego obiegu dokumentów nie powinno wymagać zmian instrukcji kancelaryjnej i wewnętrznych procedur" i to jest idiotyczne podejście bo faktycznie nic nie naprawiając dokładamy kosztów i pracy... Tak więc sugeruję, by może nowe Ministerstwo Cyfryzacji zajęło się jak najszybszym opracowaniem drugiej wersji instrukcji kancelaryjnej dla Gmin (ja chętnie pomogę), planujących "cyfryzację" bo bez tego ten cały interes jest na plaster... wewnętrzny obieg dokumentów w urzędzie to zapewne 99% całej pracy z dokumentami. Więc chyba warto pozostawić "papierowe" dokumenty u obywatela a skupić się na owych 99%-ach wewnątrz urzędu bo tu tkwi problem. A archiwa? OK, kategorię archiwalna A ma znikoma ich ilość, więc nie zarośniemy bo pozostałe dokumenty w urzędach są od lat niszczone i będą.

Hurtownie danych czyli “Systemy od historii”

Post author:Jaroslaw Zelinski
Post published:7 December 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Hurtownia danych to model stworzony pod kątem przetwarzania faktów historycznych na prostym modelu danych (diagram powyżej, górny, to tak zwana kostka OLAP). Opracowanie takiego modelu wymaga specjalnej analizy i projektu, ale nie zapominajmy: analizę się robi raz a raporty stale... Tak więc szanowni Państwo. Jeśli tylko Wasza firma jest bliżej czołówki niż ogona rankingu rynku w Waszej branży, nie dajcie się namówić na jeden zintegrowany ERP i jakiś model referencyjny, bo nawet jak uda się go wdrożyć, to zmiana czegokolwiek będzie trudna a upgrade do nowszej wersji niemożliwy. Opracowanie projektu systemu składającego się z komponentów, pozwoli Wam dobrać najlepiej spełniające Wasze wymagania aplikacje. Jak z klocków LEGO złożycie "dedykowany system" pomagający utrzymać przewagę na rynku, a nie cofający Waszą firmą do poziomu "innych podmiotów w branży".

Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512

Czynniki sukcesu w projektach programistycznych

Post author:Jaroslaw Zelinski
Post published:6 December 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Pojawia się próba diagnozy. Pełna tak zwana śladowalność wymagań (nazwana tu hipertracebility) jest podobno kosztowna i trudna do utrzymania. Zaraz potem: niedbałość w definiowaniu wymagań - no to w końcu dokładnie czy nie? Kolej na analityków: zrzucanie odpowiedzialności ? analitycy tworzą dokument wymagań i wypychają go do programistów. Oczywiście jest to problem, co z tym? Analityk powinien ponosić odpowiedzialność za swój produkt do końca projektu. Założenie, że można stworzyć skończony dokument wymagań. Otóż można ale o tym za chwilę. Poza ważnymi elementami zarządzania takim projektem, w tym zarządzaniem zespołem autorzy wskazali jedną z głównych moim zdaniem przyczyn: brak dokumentu HLD (projektu wysokopoziomego). Otóż nie da się czymś tak złożonym jak oprogramowanie (zakładam, że to nie trywialny system), zarządzać na poziomie detalicznych szczegółów.