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

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

Post author:Jarosław Żeliński
Post published:24 maja 2008
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:18 września 2022

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ń?

Czytaj dalej

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

Post author:Jarosław Żeliński
Post published:6 marca 2008
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:16 stycznia 2024

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ć.

Czytaj dalej

IV Kongres Bezpieczeństwa Sieci już za nami! Tegoroczna edycja zgromadziła ponad 700 uczestników.

Post author:Jarosław Żeliński
Post published:22 lutego 2008
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:10 marca 2012

Trwający dwa dni Kongres składał się z trzech równoległych konferencji - Network Security GigaCon, Firewall&VPN GigaCon, Secure Mail GigaCon, w ramach których firmy tworzące rozwiązania dla bezpieczeństwa prezentowały swoje produkty, a eksperci wygłosili wykłady merytoryczne. Sponsorami konferencji były firmy: HP, IMNS Polska, Sonicwall, Qualys, Axence, Mediarecovery, MKS oraz firmom uczestniczącym Sun Capital, dotCOM, Kaspersky Lab, Ascomp, Entrasys, Trend Micro, Ed&r, Wheel, CryptoTech, CTS, EtherWerX.

Czytaj dalej

Outsourcing IT w latach 2006-2012 podwoi się

Post author:Jarosław Żeliński
Post published:21 lutego 2008
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:10 marca 2012

Osobiście nie definiował bym outsourcingu jako obligatoryjnie długoterminowej umowy. Prosty przykład: firmy nie stać na utrzymywanie etatowego specjalisty jednak jego kompetencje są okresowo potrzebne. Jednym ze sposobów jest każdorazowe angażowanie specjalisty na okres gdy jego kompetencje są wymagane. Odróżnił bym outsourcing procesu biznesowego (tu długoterminowa umowa) od outsourcingu w ogóle.bał bym sie powiedzieć, ze outsourcing jest obligatoryjnie tańszy. Możemy mieć sytuację, że usługa outsourcingu jest droższa od dotychczasowego procesu jednak z outsourcingiem (droższym) możemy zyskać dodatkowa korzyści np. podniesienie jakości, niezawodności, obniżenie ryzyka, inne.

Czytaj dalej

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

Post author:Jarosław Żeliński
Post published:9 lutego 2008
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:10 marca 2012

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".

Czytaj dalej

Schyłek epoki krawców

Post author:Jarosław Żeliński
Post published:6 stycznia 2008
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:10 marca 2012

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ł.

Czytaj dalej

Rynek oprogramowania dla MŚP zaczyna przyśpieszać

Post author:Jarosław Żeliński
Post published:29 grudnia 2007
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:10 marca 2012

W 2006 r. rynek oprogramowania dla małych i średnich przedsiębiorstw (MŚP) ponownie wzrósł. Jego wartość wynikająca z funkcjonowania ponad 210 firm producentów oprogramowania zwiększyła się zarówno w sektorze małych, jak i średnich przedsiębiorstw. Wzrosty te dla sektora MŚP ogółem oznaczały w 2006 r. dynamikę złotówkową równą 14,6%.

Czytaj dalej

Ja jako ekspert Foresight Polska 2020

Post author:Jarosław Żeliński
Post published:11 grudnia 2007
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:7 listopada 2010

Właśnie otzrymałem mail: Szanowni Państwo, w imieniu Konsorcjum Koordynującego Narodowy Program Foresight Polska 2020 pragnę serdecznie podziękować za zainteresowanie Programem i wypełnienie ankiety rekrutacyjnej do Zespołu Ekspertów Zewnętrznych Narodowego Programu Foresight 2020. Mam również przyjemność poinformować, iż proces rekrutacji został w Państwa przypadku zakończony pozytywnie. Serdecznie witamy w gronie Ekspertów Zewnętrznych Narodowego Programu Foresight Polska 2020. Jacek Szut Research Executive Pentor Research International Koordynator ds. Promocji Narodowego Programu Foresight Polska 2020 Co to jest Foresight Polska 2020 Program realizowany jest przez Konsorcjum Koordynujące, wybrane w drodze konkursu, w składzie: Instytut…

Czytaj dalej

Chaos deterministyczny

Post author:Jarosław Żeliński
Post published:10 grudnia 2007
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:10 marca 2012

Jeden z pracowników moich klientów, duży developer powiedział, że firma i to co się w niej dzieje jest tak skomplikowana, że nie wyobraża sobie bo można to było opisać lub narysować. Powiedziałem, że można, należy jednak po pierwsze przyjąć pewien poziom szczegółowości opisu sensowny z perspektywy człowieka (model to uproszczenie) oraz podzielić problem na kawałki... dyskusja nie miała końca. Mój projekt dobiegł końca i okazało się, że udało się opisać nie małą firmę w ciągu miesiąca, modelem na kilkudziesięciu stronach. Jak?

Czytaj dalej

SaaS czy to jest BPO? Czyli swoje w końcu czy cudze…

Post author:Jarosław Żeliński
Post published:1 grudnia 2007
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:21 marca 2012

A jednak jak to mówią "nigdy nie mów nigdy". Postanowiłem napisać o SaaS (Software as a Service, ang. Oprogramowanie jako Usługa) mimo wcześniejszych deklaracji, że nie będę tego tematu poruszał, ale tu w nieco innym kontekście. Dlaczego? Bo jednak nie potrafię słuchać tłumaczenia: "SaaS jest dobre dla firm bo jest dobre". Ja oczywiście zawsze jestem uciążliwy i pytam "Dlaczego dla mnie jest dobre"? Tłumaczenie, że "Dzierżawione jest lepsze i tańsze" od razu nasuwa mi pytanie "To dlaczego dostawcy SaaS nie są jeszcze milionerami?" A jak chcę skopać leżącego to pytam jeszcze o rentowność (dla mnie, nie dla niego).

Czytaj dalej

Software Development Journal 11/2007

Post author:Jarosław Żeliński
Post published:20 listopada 2007
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:24 sierpnia 2022

Artykuł opisuje drugi, po przypadkach użycia i modelu dziedziny systemu, aspekt opisu wymagań: zachowania systemu. Nie jest to proste biorąc pod uwagę różnorodność problemów: obiekty stanowe (np. dokumenty, ludzie), współbieżność i transakcyjność i wiele innych. Opisanie tekstem w sposób jednoznaczny tych elementów wymagań jest praktycznie nie możliwe. Za pomocą diagramów: sekwencji, komunikacji, aktywności, maszyny stanów, czy przebiegów czasowych możliwe jest przekazanie opisu budowy systemu np. programistom będąc niemalże pewnym, że napiszą kod taki jaki chciał projektant mimo, tego, że nie będzie go w tym procesie kodowania.

Czytaj dalej

Obieg danych, dokumentów, informacji a proces biznesowy

Post author:Jarosław Żeliński
Post published:8 listopada 2007
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:8 października 2023

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.

Czytaj dalej

Koniec treści

Nie ma więcej stron do załadowania

Nowsze wpisy

Starsze wpisy