2011 – Strona 4 – Jarosław Żeliński IT-Consulting

Burza mózgów – homeopatia w analizie

Post author:Jarosław Żeliński
Post published:27 sierpnia 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:14 komentarzy
Post last modified:4 maja 2018

Jeśli coś jest skomplikowane, złożone, możliwym rozwiązaniem jest dodanie zasobów i właściwych procedur. Jednak jeśli coś jest trudne, potrzebny jest po protu ktoś, kto potrafi. Czemu o tym piszę? A bo właśnie mam przed sobą kolejny dokument o nazwie SIWZ, wykonany podobną techniką (w obszarze wymagania), jakimś kosztem (czas pracowników albo koszt konsultanta pracującego tą właśnie metoda) opracowano tę specyfikację wymagań a teraz zamawiający sam przyznaje (po rozstrzygnięciu przetargu), że analiza wymagań jest potrzebna bo ów SIWZ jest "niespójny, ma braki i wymaga korekty i uzupełnień". Z tego powodu także nie ma pewności, że w ogóle dobrze opisano Przedmiot Zamówienia".Niestety wiele projektów programistycznych to odkrywanie wymagań "w trakcie" dostarczania produktu. Po dostarczeniu jakiegoś fragmentu (lub nie raz prototypu całości) beneficjent stwierdza: "to jest dokładnie to czego chcieliśmy ale zupełnie nie to co jest nam potrzebne"...

Czytaj dalej

BPM 2.0 czyli nowe mity…

Post author:Jarosław Żeliński
Post published:23 sierpnia 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:4 komentarze
Post last modified:27 sierpnia 2011

Powyższego niestety nie zrozumiałem (co to znaczy "możliwości wykorzystania różnych metod do relatywnie łatwej integracji z innymi wykorzystywanymi systemami"), nie licząc tego, że faktycznie dobrze wdrożone systemy wspomagające zarządzanie przepływem pracy i dokumentów, jest swego rodzaju systemem pracy grupowej. Integracja, jej łatwość i koszt zaś nie zależy od systemu BPM a tych integrowanych systemów ERP czy CRM.Tak więc nie sądzę by możliwe było projektowanie i wdrożenie systemu bez "służ informatycznych". Jednak dobrze zaprojektowany i już wdrożony system BPM może pozwalać na komponowanie kolejnych nowych lub zmianę starych procesów, jednak tu możliwe jest jedynie używanie wstępnie zaprojektowanych i zaimplementowanych "procesów i obiektów danych" jak z klocków.

Czytaj dalej

Internet w Polsce ma 20 lat

Post author:Jarosław Żeliński
Post published:18 sierpnia 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:16 marca 2012

No cóż, komentarz zbędny. Jeżeli miał bym od siebie coś dodać :) to to, że moje przygody "na stałe" z Internetem mają 16 lat jak tylko Internet wyszedł "w rynek" z pomocą Maloka BBS. Potem dostęp za pośrednictwem TP SA i dalej jak wszyscy :) ...

Czytaj dalej

Polski rynek IT może wzrosnąć w tym roku o ponad 10%

Post author:Jarosław Żeliński
Post published:18 sierpnia 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:18 sierpnia 2011

Wzrost rynku IT w Polsce w 2011 r. może wynieść ok. 10,9%, wynika z sierpniowego raportu firmy badawczej PMR. Jego wartość może wynieść ok. 28,7 mld zł wobec 25,9 mld zł w 2010 r. "Po okresie kryzysu rynek IT w Polsce zanotował w ubiegłym roku wyraźną poprawę wyników. Wzrost liczby zamówień z sektora przedsiębiorstw pozwala realnie ocenić możliwości wzrostu rynku w tym roku na ponad 10%" - ocenił autor raportu Paweł Olszynka.

Czytaj dalej

Epistemologia ? jak pomaga w analizie

Post author:Jarosław Żeliński
Post published:16 sierpnia 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:28 lipca 2018

Nie raz pojawia się wątek "filozoficzny" w procesie analizy (a konkretnie w rozmowach o niej...;)). Jednym z kluczowych elementów, celem, każdej analizy jest jej efekt czyli poznanie czegoś i przekazanie tej wiedzy komuś (najczęściej zleceniodawcy tej analizy). Rzecz w tym, że liczy się to czy zleceniodawca nie tylko otrzymał wyniki analizy a także czy je sobie przyswoił...Przyjmując, że dany system pojęciowy jest kompletny (pozwala na zapisanie każdej informacji z danej dziedziny), analiza polega tu na rozłożeniu tekstu (danych) pozyskanych np. z wywiadów czy dokumentów, na skończoną liczbę pojęć i związków pomiędzy nimi. W efekcie uzyskujemy np. diagram procesu BPMN (jeżeli celem był model procesu biznesowego) lub diagram klas UML (jeżeli celem była np. analiza pojęciowa i zbudowanie taksonomii).Tu dotykamy procesu komunikacji, czyli przekazania pozyskanej wiedzy i wyników analizy innej osobie.

Czytaj dalej

Analiza danych i podejmowanie decyzji: pięta achillesowa współczesnych organizacji

Post author:Jarosław Żeliński
Post published:15 sierpnia 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:28 lipca 2018

Warto tworzyć dobrze przemyślane systemy metadanych dla systemów archiwizacji gdyż pozwala to z jednej strony "spiąć" archiwum dokumentów z hurtownią danych z drugiej "pozbyć się" śmieci. Tempo przyrostu danych stale rośnie gdyż biznesowe oprogramowanie, automatyzując wiele naszych czynności, wytwarza je w tempie w jakim człowiek nigdy nie był by w stanie. Po drugie narasta zjawisko powielania, co nazywam to syndromem "copy&paste". Wiele dokumentów (o zgrozo także tych podobno "autorskich") i powstaje coraz częściej metodą powielania tego co znajdzie się w firmowych archiwach (wiedza korporacyjna czyli po prostu jej zanik, bo wiedza to umiejętność napisania czegoś a nie skopiowania) czy w sieci. Moja praktyka (to co dostaje do audytu u klientów) pokazuje, że dokumenty wytworzone "od zera" praktycznie zawsze mają większą wartość merytoryczną. Do tego dochodzi ryzyko przeniesienia, podczas kopiowania, treści niechcianych. Kopiując dziesiątki stron "starej oferty" lub poprzedniego "opracowania doradczego", tworząc kolejne "indywidualne autorskie opracowanie" narazić się można nie tylko na ujawnienie tajemnicy ale także na zwykłe ośmieszenie. Dlatego system zarządzania dokumentami i wiedzą należy dobrze zaprojektować. W przeciwnym wypadku narażamy się na budowę wielkiego śmietnika.

Czytaj dalej

Co piszczy w internecie – Megapanel maj 2011

Post author:Jarosław Żeliński
Post published:22 lipca 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:22 lipca 2011

Wyniki Megapanel PBI/Gemius za maj 2011 Polskie Badania Internetu Sp. z o.o. (PBI) i firma badawcza Gemius SA, współpracujące w zakresie realizacji badania ?Megapanel PBI/Gemius? ? standardu pomiaru oglądalności witryn i aplikacji internetowych w Polsce, opublikowały wyniki za maj 2011. (Wyniki_Megapanel_PBI_Gemius_maj_2011).Pierwsze trzy pozycje oglądalności stron to kolejno od najlepszej: grupa Google, grupa Onet, grupa Wirtualna Polska - Orange. W tym grupa NK.pl na pozycji 7., Facebook na pozycji 9., grupa Wikipedia na pozycji 11., Microsoft na pozycji 14. więc jak widać nasza rodzima NK dobrze się trzyma, szkoda, że nie ma charakterystyki odwiedzających... Prawdę mówiąc zaskakuje mnie pozycja Microsoftu, czy jest to wyniki klikana w Pomoc w środowisku Windows czy też realne zainteresowanie produktami.

Czytaj dalej

Łańcuch wartości M.E.Porter (Competitive Advantage, 1985)

Wymagania na system ERP – co ma do tego M.E.Porter i rok 1985?

Post author:Jarosław Żeliński
Post published:18 lipca 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:3 komentarze
Post last modified:21 września 2022

Podejście takie jest stosowane. Badania pokazują, że liderzy rynku, bez względu na branżę, to firmy dobrze zarządzane a nie te, które najwięcej wydały na IT. Podejście to wymaga dużej odwagi i samodzielności, ignorowania tak zwanych modeli referencyjnych (bo te są dobrymi praktykami a nie czymś co należy skopiować), owocuje jednak sukcesami. Niestety często zdarza się, że wdrożenie systemu ERP niszczy przewagę firmy, gdyż nowa technologia zamiast ją umocnić niszczy kompromisami i kopiowaniem modeli innych firm (nie raz konkurentów) wszystko to co odróżniało ją od innych.Za zakończenie polecam gorąco drugą ksiązkę Portera: [[Porter o konkurencji, Michael E. Porter, PWE, Warszawa 2001]]. W tej znajdziemy zbiór dziewięciu artykułów na temat budowania konkurencji i jej utrzymaniu. W szczególności warto poznać artykuł "[[W jaki sposób informacja wpływa na przewagę konkurencyjną]]". Pięć zasad, które mogą pomóc w budowaniu przewagi na bazie informacji, odsyłam do książki , warto. To przyczynek to napisania kilku słów o systemach wspomagania decyzji ale to inny temat, nie ERP...

Czytaj dalej

Od czego zacząć wdrożenie

Post author:Jarosław Żeliński
Post published:15 lipca 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:16 lipca 2011

Użycie modelu jako narzędzia wyboru systemu ERP jest bardzo skuteczne - wystarczy go opisać dodatkowo zakresem projektu i rozesłać do dostawców i zapytać czy ich system pasuje do modelu oraz ile ten produkt kosztuje rok po roku. Jednocześnie dobrze wykonany model organizacji nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt jego wykonania, a często stanowią zbędne ograniczenia. Dobry model powstaje z użyciem standardów i dobrych praktyk. Do typowych standardów należą: notacja BPMN (Business Process Modeling Notation), UML (Uniefied Modeling Langualge), AchiMate/TOGAF, Siatka Zachmanna, Business Motivation Model. Do dobrych praktyk np. wzorce projektowe czy zalecenia Business Rules Group. Zachęcam do zakupu całego wydania COMPUTERWORLD Aplikacje Kompendium ERP Czerwiec 2011.

Czytaj dalej

Dostosowanie oprogramowania: kiedy?

Post author:Jarosław Żeliński
Post published:6 lipca 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:13 lipca 2011

Fowler pyta o to, o co wielu wielu informatyków: czy dostarczenie firmie kolejnych nowych możliwości, powinno się realizować poprzez napisanie (tworząc dedykowane) potrzebne nowe oprogramowanie, czy poprzez zakup gotowego oprogramowania. Ogólnie opinia, zalecane podejście przez Fowlera to: jeżeli proces wymagający wsparcia nowym oprogramowaniem, to proces kluczowy dla utrzymania konkurencyjności lepiej stworzyć oprogramowanie dedykowane do tego procesu. Jeżeli to jeden z procesów pomocniczych, efektywniej będzie kupić gotowe oprogramowanie i dostosowanie do niego procesu w firmie. Co ciekawe, podobnie jak ja, zaleca w przypadku gotowego oprogramowania dostosowanie się do niego a nie dostosowywanie oprogramowania do siebie.

Czytaj dalej

A jeżeli klient nie ma kompetencji do wykonania analizy

Post author:Jarosław Żeliński
Post published:5 lipca 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:4 komentarze
Post last modified:22 czerwca 2023

Opisywane tu nie raz metody bazujące na modelowaniu przyszłego systemu (jego logiki biznesowej) i testowaniu czy model pozwala na spełnienie celu biznesowego dają oszczędności nawet 50%, a bywa, że znacznie większe, jeśli okaże się, że uniknięto zakupu jakiegoś zbędnego oprogramowania lub modułu. Koszt dobrze opracowanej analizy z dużym zapasem pokrywają oszczędności wynikające z braku wielu prototypów.Podsumowując: analityka zawsze warto zatrudnić, poprzedzając to kontrolą tego co wytworzy. Dobry analityk zawsze wyceni projekt jako umowę o dzieło o konkretnym terminie i koszcie. Projekty w rodzaju czas i materiał to projekty w rodzaju " na początku nikt nic nie wie". Warto je robić tylko w przypadkach, gdy tej wiedzy faktycznie nie ma, spodziewamy się systemu o wartości setek tysięcy złotych lub kosztowniejszych i zainwestowanie nawet kilkudziesięciu tysięcy w analizę, która pozwoli oszacować ryzyko wydania tych kilkuset, może mieć sens. W takich przypadkach i tak ustalamy próg kosztów, przy których uznamy, że dalsze prace już niczego nowego nie wniosą.A na koniec, analiza trwająca kilka czy kilkanaście dni roboczych, zakończona kilkudziesięcioma stronami tekstu i tabelą na setki pozycji wymagań w niczym nam nie pomoże.

Czytaj dalej

Budżet na projekt IT

Post author:Jarosław Żeliński
Post published:4 lipca 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:5 komentarzy
Post last modified:31 maja 2013

Tak więc moim zdaniem budżet zamawiającego to wiedza zamawiającego, której nie musi ujawniać. Skoro już jej nie ujawnia to powinien mieć kompetencje (własne lub wynajęte) pozwalające po pierwsze opisać projekt, po drugie zdefiniować (opisać) "to coś informatycznego" co pomorze mu ten projekt zrealizować.Wyjawienie przez klienta planów i budżetu takiemu dostawcy to postawienie się pod ścianę w negocjacjach z nim. Dlatego nie ma sensu sytuacja gdy dostawca pyta klienta o jego budżet czy oferowanie mu czegokolwiek. I nie ma tu znaczenia uczciwość tego dostawcy bo z perspektywy klienta sprzedawca na prowizji stanowi duże ryzyko dla rzetelności takiej oferty.I na koniec: napisanie tylko: "system ma wystawiać faktury VAT" jako opis tego co chcemy kupić nie ma żadnego sensu bo to stanowczo za mało by cokolwiek wycenić i ocenić.... ale też napisanie, że "kontrahenta można dodać do faktury z rozwijanej listy uruchamianej prawym klawiszem myszy", jest jeszcze większym błędem, bo po pierwsze nie raz narzuca wspomnianą kastomizacje (a to podnosi koszt), a po drugie bywają lepsze sposoby rozwiązania tego problemu. Dla gotowego systemu nie ma sensu pisanie aż takich szczegółów, a dla dedykowanego robi się to zupełnie inaczej.

Czytaj dalej

Koniec treści

Nie ma więcej stron do załadowania

Nowsze wpisy

Starsze wpisy