Refleksje – IT w czasach nowych wyzwań rynkowych

Tu należy się uwaga, że znaczny udział usług to obecnie usługi związane z tworzeniem oprogramowania tak zwanego dedykowanego lub jego dostosowywania. Moim zdaniem można uznać prognozę IDC z 2003 roku za trafioną. Obserwując nie tylko przetargi proporcje te wydają się jak najbardziej trafne. Warto zwrócić uwagę, że obecna złożoność oprogramowania wspomagającego biznes, praktycznie uniemożliwia skuteczne wdrożenie bez wsparcia. Czasy gdy kupujący "sam sobie coś zrobił" raczej bezpowrotnie minęły. To co obserwuję, to migracja znacznej części usług z obszaru technologicznego (główny problem to instalacja i uruchomienie) do obszaru biznesowego (główny problem to zmiana organizacji jaką powoduje wdrożenie nowych narzędzi IT). Na tym etapie pojawia się potrzeba poprzedzenia instalacji oprogramowania (wybór, zakup i wdrożenie) analizą i prognozowaniem (predykcją, przewidywaniem) skutków tego wdrożenia. Bardzo istotne jest, nie to czy produkt "zadziała" a to do czego planujemy go użyć i czy się sprawdzi.

Czytaj dalejRefleksje – IT w czasach nowych wyzwań rynkowych

Emerytury… Idealizacja czyli mechanizm systemu solidarnościowego

[uzupełnienie grudzień 2021] Nie planuję tu analizy obecnej reformy emerytalnej. Tu (źródło poniższego cytatu) można zapoznać się z jedną z wielu opinią o ZUS. Polecam cały tekst a tu wstęp, który posłużył mi za inspirację do tego tekstu: Kluczowym elementem logiki ekonomicznej jest ujmowanie zagadnień w kategoriach strumieni i zasobów łącznie. Domański słusznie zwraca uwagę, że analizowanie miejsca systemu emerytalnego w gospodarce tylko w kategoriach podziału PKB, a więc strumieniowo, jest błędne. Powinno się bowiem uwzględniać konsekwencje kapitałowe współudziału w tworzeniu przez pracujących majątku gospodarczego, rozumianego całościowo (np. łącznie z…

Czytaj dalejEmerytury… Idealizacja czyli mechanizm systemu solidarnościowego

W strefie parkowania mandat się opłaca – czyli analiza systemowa … nie wykonana

Jak było by "lepiej"? Kara powinna niszczyć "wygraną" parkującego tak więc powinna wynosić co najmniej 31,20zł zamiast ustalonej 25zł (minimalna opłata plus kara powinna być równa co najmniej opłaci należnej). Z uwagi na to, że rolą kary jest nie tylko niszczyć korzyść za łamania zasad ale także odwodzić od ich łamania, powinna być odczuwalnie (co by to tu nie miało znaczyć) wyższa. Nie będę się tu rozwodził się nad tym, jaka powinna być, inny jest cel artykułu (zainteresowanym teorią gier polecam na początek np. książkę [[Konkurencja i kooperacja. Teoria gier w ekonomii i naukach społecznych. Malawski, Wieczorek, Sosnowska]]). Chce pokazać, że projektowanie systemu opłat i kar powinno być przeprowadzone "profesjonalnie" a nie po amatorsku. System powinien być tak zaprojektowany by nie demoralizował i by był skuteczny. Radni będą, jak zadeklarowali, zmieniali system kar. Ale niestety ośmieszyli się w oczach obywateli i stracili znaczne środki (6,20 za każde źle opłacone parkowanie). Teza mówiąca "brzydko jest być nieuczciwym" raczej rozśmiesza, bo to prawda, że brzydko, ale nie zmienia to faktu, że ekonomia jest bezlitosna i na pewno ludzie (wielu) znajdą "wygrywającą" strategię, jeżeli tylko taka istnieje. Innymi słowy skoro miasto pobiera dwie różne opłaty za tę sama usługę (z karą i bez), wybrana zostaje wersja o niższej opłacie. Powyższe to namiastka zjawiska "psucia" prawa i niestety demonstrowania niekompetencji urzędników. Sam fakt, że tego nie przewidzieli wystawia im słabe świadectwo. A co dopiero w przypadkach bardziej złożonych? Urzędnicy, skoro już nie mają tych kompetencji, powinni uczyć się korzystać z pomocy specjalistów. I nie tylko oni...

Czytaj dalejW strefie parkowania mandat się opłaca – czyli analiza systemowa … nie wykonana

No to była mała porażka… piszę ku przestrodze

Nie będę tu opisywał szczegółów tego projektu, ważne są wnioski a nie ta czy inna firma: pominięcie któregokolwiek etapu projektu analitycznego, w szczególności pierwszego, powoduje, że całość staje się nieweryfikowalna, ryzyko rośnie, ukrycie prawdziwego celu projektu przed analitykiem (jest to możliwe, jeżeli dojdzie to tego co powyżej) powoduje, że większość jego czasu pracy nie służy projektowi, po zanegowaniu efektów pracy analityka, obrona takiego projektu jest niemożliwa bo brak kluczowego narzędzia: śladowanie (przypomnę, że usunięto pierwszy etap - zdefiniowanie celu). Co było prawdziwym celem projektu? Okazało się, że "nie chcemy by przetarg wygrała firma XXX i jej produkt". W trakcie pierwszych problemów z "uznaniem" specyfikacji wymagań dostałem listę wad posiadanego oprogramowania. Ku mojemu zaskoczeniu były tam nawet błędy rachunkowe (inne tu pominę, choćby niezgodność programu z prawem). Pytam: jakim cudem to zostało odebrane i zapłacone? Cóż...

Czytaj dalejNo to była mała porażka… piszę ku przestrodze

Sami wymyślą, sami zrobią i sami ocenią

Rozmowa z Jarosławem Żelińskim: Sami wymyślą, sami zrobią i sami ocenią Naukowcy z Instytutu Informatyki Politechniki Wrocławskiej przyjrzeli się bliżej 80 inwestycjom, które uruchomiono w połowie 2010 roku. I porównali ze sobą ich wyniki. Okazało się, że są ogromne dysproporcje między urzędami a firmami. Dysproporcje niestety na niekorzyść projektów publicznych, które kończą się sukcesem dwukrotnie rzadziej niż analogiczne z sektora prywatnego. A do tego niestety ponad połowa z nich kończy się klapą. Skąd tak duże różnice między efektami informatyzacji prywatnych firm a informatyzacją urzędów? (Informatyzacja administracji, czyli najlepszy sposób na…

Czytaj dalejSami wymyślą, sami zrobią i sami ocenią

Jedno wymaganie – kilka perspektyw

Tak więc każde wymaganie: kojarzymy z realizującym go przypadkiem użycia, testujemy (z pomocą dobranego scenariusza testowego), dokumentujemy modelem opisującym jego realizację (np. Obiekt biznesowy w modelu dziedziny). Takie podejście powoduje, że zanim jeszcze dotkniemy gotowego produktu (tu niestety już po jego wyborze) możemy po pierwsze: przetestować samą specyfikację a po drugie przekazać potencjalnemu dostawcy (na etapie zapytania) pełna informację o tym, czego oczekujemy od produktu. Powyższe podejście w postaci 'full wypas" może być pracochłonne, dlatego możliwe są warianty pośrednie czyli tylko dla wymagań oznaczonych jako ryzykowne budujemy testy lub elementy modelu dziedziny, jednak mamy narzędzie do panowania nad tym ryzykiem. Po drugie zyskujemy narzędzie do weryfikacji, odbiór oprogramowania nie będzie sprawdzaniem listy dziesiątek cech, będzie "jazdą próbną na sucho" a więc relatywnie tania metodą testów: dostawca deklaruje (oferta na nasze zapytanie) zgodność z naszymi wymaganiami a te są weryfikowalne.

Czytaj dalejJedno wymaganie – kilka perspektyw

Scenariusze biznesowe w architekturze korporacyjnej

Kluczowym narzędziem budowania scenariuszy są modele, te jednak muszą być sformalizowane ([[użycie notacji formalnych]]), w przeciwnym wypadku są "niestetowalne" (w projektach bazujących na AK stosowana jest z reguły notacja ArchiMate). TOGAF to nie jedyna metodologia, w której można spotkać idee użycia scenariuszy. [[The Open Group]] nie ma "monopolu" ani na metody scenariuszowe ani na ([[notację ArchiMate]] stosowaną w projektach AK, która także nie jest objęta żadnym patentem ani inną ochroną prawną. Tak więc zachęcam to brania tej metody pod uwagę, szczególnie w ryzykownych i dużych projektach.

Czytaj dalejScenariusze biznesowe w architekturze korporacyjnej

Jak przygotować zapytanie ofertowe?

Ten artykuł jest pewną kontynuacją poprzedniego. Potraktujmy go jako "prostszą wersję" :) popartą oczekiwaniami przyszłego wykonawcy, który w swoim artykule niejako "składa zamówienie na dokument wymagań". Wpadła mi swego czasu przed oczy strona pewnego developera stron WWW. Dlaczego mnie zainteresowała? Bo po pierwsze słusznie oczekuje od swojego klienta konkretów, po drugie potrafi krótko i zwięźle opisać czego potrzebuje, by mógł wytworzyć oprogramowanie (opisał to w kontekście tworzenia stron WWW, które obecnie bardzo często także są wynikiem działania oprogramowania): Podstawowym dokumentem, który należy przygotować jest specyfikacja techniczna. Powinna ona wyszczególnić funkcjonalności, które mają znaleźć się na…

Czytaj dalejJak przygotować zapytanie ofertowe?

ISA – Interoperability Solution for European Public Administrations

Od czasu do czasu "nawołuję" do formalizowania projektów. Jak nie raz wspominałem, jest to podstawowa metoda uczynienia projektu (jego dokumentacji) przejrzystym. Drugą ważną korzyścią z formalizacji jest tak zwana [[interoperacyjność]], która oznacza możliwość współdziałania technologii różnych dostawców (producentów). Jak nie trudno się domyśleć, problem dotyczy w szczególności każdej większej organizacji, niejako skazanej na posiadanie rozwiązań z różnych źródeł. Klasycznym przykładem jest administracja publiczna (z interoperacyjnością, a raczej jej brakiem, w Polsce walczymy). Tak więc polecam osobom związanym z administracja publiczną i instytucjami publicznymi, zapoznanie się z tą inicjatywą. Moim zdaniem bardzo ważna, dobrze że podjęto ten temat gdyż kwestie integracyjne stanowią nie raz istotny koszt projektów IT a bywa, że brak interoperacyjności powoduje wręcz niemożność ich realizacji (np. w Polsce integracja rejestrów Państwowych).

Czytaj dalejISA – Interoperability Solution for European Public Administrations

Koniec treści

Nie ma więcej stron do załadowania