Rozważania

Moje wszelkie blogowe dywagacje ;)

Refleksje – IT w czasach nowych wyzwań rynkowych

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 »

Emerytury… no to i ja coś napisze…

Cykl zycia

Daleko mi do konkurowania z ekspertami od finansów publicznych czy makroekonomii (zainteresowanych makroekonomią zapraszam tu). Nie planuję tu też żadnej analizy obecnej reformy emerytalnej. Co innego mnie zastanawia gdy słucham doniesień i relacji w prasie i TV na ten temat. Słyszę o negocjacjach ze związkami zawodowymi czy protestami opozycji. Przepychanki, a raczej niskie etycznie targi, między klubami i politykami w rodzaju „jak Ty mi poprzesz to ja Tobie poprę”. Moim zdaniem powyższe jest jakimś populistycznym ukrywaniem prawdy albo totalnym niezrozumieniem realiów. Obydwa te powody w moich oczach dyskwalifikuję wielu polityków i nie tylko polityków. Ale do rzeczy. Problem emerytur jest „prosty”. Określona część obywateli, pracująca, utrzymuje pozostałą część: niepracującą (i wymagająca pomocy). Utrzymywanie swoich dzieci nie budzi wątpliwości. Zaczynają się problemy z postrzeganiem bytu o wdzięcznej nazwie „niepracujący i mający ograniczone możliwości pracy”. Nie rozwodząc się, nazwijmy ich „biorcami świadczeń społecznych”. Dla uproszczenia tego tekstu jednak zawężę zakres „rozważań” tylko do emerytów. Moim zdaniem system emerytur jako jakiekolwiek „odkładanie” na przyszłość to fikcja. Widać to po tym jak zmieniane są (dopasowywane do realiów) przepisy emerytalne i funkcjonowanie ZUS. Zresztą nie jest to tylko problem naszego kraju. Uznając więc (chyba) realia, należy pogodzić się z tym, że obecnie pracujący utrzymują obecnych emerytów. Taka redystrybucja...

Czytaj »

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

appEngProgramer

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 »

Scenariusze biznesowe w architekturze korporacyjnej

Diagram ArchiMate Sprzedaż

Kluczowym narzędziem budowania scenariuszy są modele, te jednak muszą być sformalizowane (]), 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. ] nie ma "monopolu" ani na metody scenariuszowe ani na (] 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 »

Jak przygotować zapytanie ofertowe?

do zrobienia

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 stronie. Niestandardowe funkcje powinny zostać dokładnie opisane. Opis może przybrać formę zarówno słowną, jak i graficzną (schemat działania, diagramy UML). Jak widać podzielił wymagania na funkcje (funkcjonalności) standardowe i niestandardowe. Dlaczego? Uważam, że słusznie, standardowe (opisane już gdzieś lub ogólnie uznane)  funkcjonalności należy wydzielić i przytoczyć ich znane i typowe opisy lub nazwy (np. okno logowania) dzięki czemu unikamy nazbyt szczegółowych (czytaj kosztownych bo pracochłonnych) opisów zachowując już jednak pewną jednoznaczność. Po drugie, zapewne będą one realizowane przez predefiniowane w wielu narzędziach, moduły (czytaj wykonane taniej). Niestandardowe funkcjonalności wymagają dokładniejszego opisu – bo są niestandardowe . I dalej: Poza danymi czysto technicznymi warto opowiedzieć także o swoim...

Czytaj »

Wymagania na coś dużego – w czym problem?

KosztAnalizy

Producenci różnych rzeczy zdają sobie sprawę, że koszty podjęcia właściwej decyzji przy skomplikowanych produktach są spore i ludzie będą podejmować decyzje błędne, to pozwala działać na rynku firmom, które w przeciwnym wypadku by upadły. I jak teraz wyglądają w Państwa oczach zakupy i wdrożenia dużych gotowych systemów? Jak to robić lepiej? Po pierwsze nie kupować "dużych i drogich zintegrowanych systemów" bo to duże ryzyko, kupować mniejsze, łatwiejsze do opisania, projektować te, które są zbyt dużym ryzykiem w przypadku złego wyboru. Jeżeli już z powodu ryzyka mamy poświęcić duży budżet na kosztowne specyfikowanie oprogramowania to sygnał, że należy je za te pieniądze po prostu zaprojektować i wykonać. Niestety nie ma prostej odpowiedzi jak to robić "dobrze". Chyba, że będzie to propozycja następującego procesu: analiza biznesowa zdefiniowanie celu zaprojektowanie architektury systemu (to jako system należy rozumieć organizację wraz z wspierająca ją informatyką), zmierzamy w kierunku tak zwanej ] zidentyfikować oczekiwane od oprogramowania usługi (wymagania), podzielić je na odrębne obszary dziedzinowe, dla każdego obszaru dziedzinowego poprowadzić odrębny projekt wyboru rozwiązania. wybrać rozwiązania. Zwracam uwagę drobny szczegół: wybory produktu dokonujemy na końcu, nigdy na początku!

Czytaj »

Wymiećmy spod kołdry brudy informatyzacji

Wymiećmy spod kołdry brudy informatyzacji

W 2009 roku udzielając wywiadu Gazecie zwróciłem uwagę na fakt, że: - Patologiczne są przetargi, w których wykonawca systemu sam sobie robi analizę wymagań. Z całym szacunkiem, nie widziałem jeszcze wykonawcy, który by w takiej analizie napisał: „niniejszym stwierdzam, że moje rozwiązanie się tu nie nadaje”. Słyszałem za to: „ukręcimy łeb każdemu przetargowi, który ma oddzieloną specyfikację wymagań od wykonania na dwa przetargi” (na szczęście coraz rzadziej się to udaje). Powód był prosty – firmy się obawiały, że mniej zarobią. (Wymiećmy spod kołdry brudy informatyzacji). Świeży przykład. W pewnym przetargu wymagania opisane całkiem przyzwoicie w Załączniku nr 3 (znowu jednak nie znamy autora tej dokumentacji, Przetarg na utworzenie Systemu Konsultacji On-Line prowadzone w trybie przetargu nieograniczonego). Jednak znowu mamy przetarg, w którym dostawca oprogramowania ma w zakresie także: Wykonanie pełnej specyfikacji funkcjonalnej Systemu wraz z całościowym projektem graficznym oraz Harmonogramem realizacji projektu zawierającym przewidywane zaangażowanie osób. Zamawiający narzuca w przetargu rozwiązanie oparte o CMS Drupal, moja wątpliwość brzmi: a skąd wiadomo, że Drupal skoro nie ma jeszcze analizy wymagań? Te wątpliwość zgłosił także jeden z oferentów: „Pytanie 5 Pkt 2.2 – Z jakich względów rozwiązanie ma być oparte na...

Czytaj »

Troszkę o narzędziach… czyli jak pracuje firma analityka – moja

Cykl iteracyjny

Jednym z głównych problemów wielu projektów analitycznych (i nie tylko) jest komunikacja i dokumentowanie działań. Projekty analityczne mają to do siebie, że opisują organizację beneficjenta projektu. Tworzenie jej modeli wymaga „sprzężenia zwrotnego” beneficjent-analityk. Jednak nie chodzi o to, by się codziennie spotykać a o to, by na bieżąco konsultować. Od lat, jako analityk, stosuję z powodzeniem metodę pracy polegającą na studiowaniu i analizie dokumentów. Są to twarde dane o życiu firmy, niosą większość wiedzy o tym co i po co się dzieje. Praktyka pokazuje, że nie szczegóły powstawania tych dokumentów są istotne (nie licząc etapów powstawania) na etapie modelowania procesów (nie procedur, te trzeba bezwzględnie oddzielać od procesów!). Istotne jest zrozumienie co i dlaczego się dzieje (albo dlaczego się nie dzieje a powinno…). Przebieg takiego projektu analitycznego, jego szkielet, wygląda jak poniżej (wywiad to konsultacje a nie spowiedź): Tu i w każdym inaczej (inna metodą) prowadzonym projekcie, pojawia się problem, gdy do komunikacji używamy spotkań lub poczty elektronicznej. W przypadku spotkań, ich nadmiar paraliżuje organizację analizowaną. W przypadku spotkań i notatek po nich pojawia się problem „gdzie jest aktualna wersja”. Rozwiązaniem jest...

Czytaj »

Nieudane wdrożenie wielkiego systemu informatycznego w USA – a co u nas?

risk-mitigation-2007-04-30

Kolejnym problemem jest niestety jakość projektowania: Według firmy analitycznej Gartner około 60 proc. wdrożeń wielkich systemów informatycznych kończy się klęską. Przyczyną jest m.in. nieumiejętność przełożenia procesów działających w firmie na działanie systemu informatycznego, brak dostatecznego wsparcia ze strony pracowników i kierownictwa firmy (czasem nawet jawny opór), złe przygotowanie wdrożenia lub jego prowadzenie. (za Serwis Nauka w Polsce - PAP SA). Jak widać, jakość projektowania jest kluczem, zresztą nie tylko w przypadków dużych systemów ale w każdym przypadku. Różnica jest taka, że jeżeli niejedna firma świadomie ryzykuje kilkaset tysięcy rezygnując z etapu niezależnej analizy i projektowania wartej ok. 10-20% tej kwoty, to podobne podejście projekty warte milionów jest już raczej nieracjonalne...

Czytaj »

Bzdurne metryczki czy bzdurne podejście…

Bzdurne metryczki czy bzdurne podejście…

Sam pomysł na metryki bardzo dobry, bardzo mi się spodobał, jednak ma on sens pod warunkiem, że będzie ona (metryka czyli format metadanych) jednolita (pomijam ogłoszona w terminie zapowiadanym w ustawie). Efektem było by jedno, dobrze opracowane ] dla całego kraju oraz spójne informacje o przebiegu spraw. Jest nawet instytucja, która ma stosowne kompetencje by ją stworzyć: ]. I co? I nic! Jak widać mamy bałagan... :( i chyba znowu popis niekompetencji... Metryka dałaby podstawy budowy spójnego systemu zarządzania wiedzą w administarcji. Niestety jak widać nowe ministerstwo popełniło albo falstart albo ktoś nie wie co robi...

Czytaj »

Używam i polecam…

Business Process Designer
BPMN 2.0 Support
Conversation Diagram
Procedure Editor

Czytałem i polecam...

UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji. Wydanie III
kup teraz

Bestsellery Helion'a

Grafika wektorowa. Szkolenie podstawowe
kup teraz

Wersja mobilna

QR Code - scan to visit our mobile site

Bookshelf 2.0 developed by revood.com

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers:

  • RSS
  • Newsletter
  • GoldenLine
  • LinkedIn

Switch to our mobile site

Please don't print this Website

Unnecessary printing not only means unnecessary cost of paper and inks, but also avoidable environmental impact on producing and shipping these supplies. Reducing printing can make a small but a significant impact.

Instead use the PDF download option, provided on the page you tried to print.

Powered by "Unprintable Blog" for Wordpress - www.greencp.de