Znaczenie ma nie wielkość projektu, a cykl jego życia…

Powyższe nasuwa od razu kolejny wniosek: zamawiający najczęściej formułują zapytania w sposób pozwalający dostawcom składać oferty na pierwszy etap, polegający tylko na dostarczeniu i wdrożeniu. Jak widać z zasady wygrywają tu projekty "na żywioł". Żądanie od dostawców ujęcia kosztów utrzymania (tak zwany "maintenance") niczego nie zmienia bo to tylko stała oplata administracyjna. Jedynym sposobem na rzetelne porównanie ofert jest operowanie kosztem cyklu życia dostarczonego produktu.

Czytaj dalejZnaczenie ma nie wielkość projektu, a cykl jego życia…

UML MDA czyli od biznesu do projektu logiki systemu

To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania "na papierze". Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich...). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: "czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da". W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: "ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów". W zasadzie taki proces analizy i projektowania jest znany od lat jako [[Model Driven Architecture]] (MDA). [...] Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman'a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD (Joint Application Development) to jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt.To jest właśnie problem nazywany "użytkownik nie wie czego chce". Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman'a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.

Czytaj dalejUML MDA czyli od biznesu do projektu logiki systemu

Jak bronić się przed zalewem danych? Ignorować je… troszkę

Technologia IT pozwala zapisywać ogromne ilości danych. W cytowanym na początku artykule namawia się nas na inwestycje w technologie, które dają szanse na "przerobienie" tego. A czy aby na pewno musimy gromadzić to wszystko? Mózg ludzki ma doskonała obronę przed nadmiarem informacji, jak wiemy radzimy sobie całkiem nieźle mimo tego, że wiele rzeczy zapominamy. To miliony lat ewolucji stworzyły ten mechanizm! Wystarczy go naśladować.Zmierzam do tego, że projektowanie systemów informatycznych to także projektowanie tego jakimi danymi zarządzać i które zachowywać np. w hurtowni danych. Gdyby nasza firma zawierała nieskończoną ilość transakcji sprzedaży rocznie (:)) czy musimy analizować wszystkie by ocenić udziały w rynku, podział na regiony, najlepszych i najgorszych sprzedawców, nadużycia w transporcie? Nie! wystarczy mieć dane reprezentatywne, rejestrować do analiz tylko ustalona część ([retencja danych]]). Niestety nie jest łatwo podjąć decyzje, która to część i to jest (powinno być) tak na prawdę część analizy wymagań. A koszt takiej analizy nijak się nie ma, jest znacznie mniej kosztowna, niż systemy do przetwarzania wszystkich tych danych. Nie dajmy się zwariować z wydatkami na rosnące pojemności systemów składowania i przetwarzania danych.

Czytaj dalejJak bronić się przed zalewem danych? Ignorować je… troszkę

Cloud Computing we Wrocławiu

Podstawową różnica pomiędzy CC a SaaS jest to, że oprogramowanie SaaS to po portu zdalny dostęp do aplikacji: użytkownik otrzymuje adres w sieci ([[URL]]), login i hasło dostępu. W przypadku CC, użytkownik nie widzi nic, poza ewentualnie nową opcją w aplikacji, której używa (np. pojawi się polecenie Renderuj w programie do tworzenia grafiki wektorowej). Gdyby chodziło o zewnętrzne składowanie plików, zapewne tego nie zobaczy. Po prostu administratora "przełączy" nasze oprogramowanie (naszą stację roboczą) do innego, zdalnego, systemu składowania plików.Na koniec ciekawostka, o której wspominam od kilku lat: monolityczne system ERP odchodzą (powoli, bronią się strasznie ;)) do lamusa. Bo...

Czytaj dalejCloud Computing we Wrocławiu

Pokazać więcej z sensem… ArchiMate

Tu pokażę przykład jak notacja ArchiMate radzi sobie z problemem łączenia biznesu, oprogramowania i technologii. A gdzie BPMN i UML? Ano każdy proces (przyjęcie zamówienia, kompletacja, fakturowanie) w kontekście szczegółów przepływu pracy, modelowany byłby w notacji BPMN (konkretne role, dokumenty, czynności). Pozostałe warstwy operują pojęciami, których szczegóły można (należy) modelować już w notacji UML. Usługi mapują się na przypadki użycia, pozostałe to architektura: komponenty oprogramowania, dane, architektura techniczna.Jak widać, ArchiMate pozwala na tym poziomie abstrakcji na więcej niż same BPMN czy UML, ale też nie zastępuje ich. Wzbogaca także system pojęciowy na potrzeby analizy biznesowej co pozwala wiernie odtworzyć rzeczywistość biznesową w sposób zrozumiały dla "biznesu". Jako podsumowanie przytoczę jeszcze raz znany już tu diagram...

Czytaj dalejPokazać więcej z sensem… ArchiMate

Kilka uwag na temat systemów ERP II, ich historii i metod ich wyboru

Analiza biznesowa obejmuje wyłącznie obszar strategii i procesów biznesowych. Wdrożenie poprzedzane jest analizą całej organizacji, wydzielenie w niej niezależnych obszarów dziedzinowych (np. rachunkowość, zarządzanie procesami pracy, zarządzanie wiedzą, portal klienta, zarządzanie i sterowanie produkcją, zarządzanie procesem sprzedaży, inne).Każdy obszar cechuje się tymi trzema poziomami: strategia, procesy, realizacja. Na etapie analizy potrzeb prowadzimy audyt i modelowanie procesów. Zakładamy, że szczegóły tego ?jak pracujemy? i tak ulegną zmianie po wdrożeniu nowego narzędzia pracy, więc pomijamy je na tym etapie (zostaną określone podczas wdrożenia). Jeżeli analiza wykaże, że istnieje obszar niestandardowy w organizacji, tylko dla tego obszaru prowadzi się szczegółową analizę, gdyż w tym obszarze będzie (najprawdopodobniej) wdrażane rozwiązanie dedykowane.Tak więc zintegrowany system ERP II nie musi oznaczać "jedno rozwiązanie od jednego dostawcy". Po pierwsze trudno jest szczegółowo wyspecyfikować taki system, po drugie nie raz okazuje się, ze "systemy od wszystkiego są do niczego"...

Czytaj dalejKilka uwag na temat systemów ERP II, ich historii i metod ich wyboru

Co jest wadą większości analiz biznesowych?

To, że są one tak na prawdę tylko uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji i jej potrzeb (bo nie koniecznie jej pracowników!) i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane, swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE!Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek? ( czytaj cały artykuł: Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!).Dlaczego tak jest? Bo oprogramowanie jest tworzone z pomocą języków programowania a te SĄ sformalizowane. Nie da się skompilować do postaci systemu ERP "luźnej prozy". Napisałem to w Listopadzie 2011, dzisiaj ciąg dalszy. Na początek dodam jeszcze moją konkluzję z pewnej konferencji:Tak więc język formalny, użyta notacja, czyni projekt wartościowym [jednoznacznym]. Bez tego raczej nie znaczy on po protu nic. (Modelowanie procesów biznesowych - dlaczego mają sens tylko metody formalne i uznane notacje).Jak to mówią: mocne słowa, ale nie zapominajmy, że mało który projekt biznesowy IT kończy się w terminie i zamyka w założonym budżecie. Zastanówcie jak były dokumentowane Wasze "nieudane" projekty...

Czytaj dalejCo jest wadą większości analiz biznesowych?
Read more about the article Modelowanie biznesowe c.d. – know-how, gdzie ono jest?
źr. Busnes Process Trends http://www.bptrendsassociates.com/

Modelowanie biznesowe c.d. – know-how, gdzie ono jest?

Proces biznesowy, nie procedura i nie opis przepływu pracy, to prosty ciąg czynności, których celem jest konkretny rezultat: produkt procesu (jego wyjście).Proces ma cel, stanowi prosty łańcuch pracy wykonawcy (Rola), radzi sobie z wydarzeniami "utrudniającymi". Główny ciąg (oczekiwany) zaznaczono szarą strzałką. Pozostałe "atrakcje" to czynności wymuszone pewnymi nie oczekiwanymi (a raczej nie chcianymi), ale przewidzianymi zdarzeniami. Tu nie ma "rombów", bramek decyzyjnych bo one są cechą "procesów decyzyjnych", procedur, a te to reguły biznesowe i "wiedza o biznesie" a nie proces biznesowy. Pewne czynności mogą być ograniczone Procedurą, która mówi, że "tylko tak wolno tę pracę wykonać".Reguły biznesowe to wewnętrzne (np. zarządzenia) lub zewnętrzne (prawo) ograniczenia. Pojawia się rola czyli wykonawca (tu rola działu HR - opis kompetencji pracowników), on posiada niezbędną wiedzą i umiejętności, potrafi obsługiwać "maszyny" (także oprogramowanie). Tak więc definicja mówiąca, że proces wykonuje się w w środowisku ograniczeń i wymaga zasobów tak właśnie wygląda: zasoby to ludzie (role), ich wiedza i narzędzia pracy, ograniczenia to reguły biznesowe i procedury.

Czytaj dalejModelowanie biznesowe c.d. – know-how, gdzie ono jest?

Metryki dokumentów w urzędach

Od 7 marca urzędnicy będą mieli obowiązek prowadzenia metryki każdej sprawy administracyjnej. MAiC określiło właśnie wzór i sposób ich prowadzenia. Zgodnie z projektem rozporządzenia metryka sprawy, wraz z dokumentami, do których odsyła ma stanowić obowiązkową część akt sprawy administracyjnej i ma być na bieżąco aktualizowana. W treści metryki uwidaczniane będą wszystkie osoby, które uczestniczyły w postępowaniu administracyjnym wraz z określeniem podejmowanych przez te osoby czynności. (za Serwis Samorządowy PAP) (o liście wyłączeń) Treść ustawy można pobrać tu Wzór metryki

Czytaj dalejMetryki dokumentów w urzędach

Prawo autorskie i wartości niematerialne – analiza systemowa

Problem w tym, że generalnie szwankuje etyka. Mało kto niestety postępuje etycznie, dowodem jest liczba użytkowników pirackich kopii. Z drugiej strony środowiska autorów raczej nie wychodzą na ulice protestować przeciwko prawu autorskiemu...Ostatnie protesty moim zdaniem pokazały, że problem tkwi w rozumieniu twórców, rozumieniu praw autorskich i tego, że jednak istnieją wartości niematerialne. Jeżeli jedynym powodem, dla którego obecnie nie ma nielegalnych rzeźb Nike z Samotraki jest to, że stworzenie takiej nielegalnej kopii wymagało by talentu rzeźbiarza, to kim są kopiujący nielegalnie muzykę, książki czy filmy?Osobiście odcinam się w tym artykule od relacji rząd a społeczeństwo, bo to dyskusja polityczna a nie systemowa. Nie znaczy to, że uchylam się od udziału w niej, po protu nie robię tego na ulicy. Martwi mnie to, że w rządzie chyba nikt nie myśli systemowo, w każdym razie nie widać tam produktów systemowego myślenia. Obym się mylił...Kończąc, piratów należy ścigać, warto jednak to robić w imieniu autorów dzieł. Nie podoba mi się ściganie piratów z urzędu - pakowania tego do prawa karnego. Prawo autorskie to sprawy cywilne i powinien być poszkodowany i pozew a nie ściganie 'bo tak", to zmusi twórców do samodzielnego dbania o własny interes, bez przerzucania kosztów prowadzonej działalności (egzekwowanie swoich praw autorskich) na Państwo czyli na nas wszystkich. Po drugie nie da się uniknąć mecenasów, jednak warto zastanowić się nad czasem ochrony i patentowej i praw autorskich. Wydaje mi się, że ochrona z tytułu praw autorskich powinna wygasać wraz ze śmiercią autora. A ochrona patentowa powinna wygasać po upływie okresu zwrotu z inwestycji, który to okres łatwo sprawdzić w biznesplanie.Twórca i jego dzieła musza być chronione ale posiadacze praw majątkowych nie powinni być dyktatorami... a posiadacze praw cudzych utworów: nie powinni być pasożytami... i to pasożytnictwo powinno być tępione a nie prawo autorskie i prawa autorów.

Czytaj dalejPrawo autorskie i wartości niematerialne – analiza systemowa

Business Model Canvas

Modele biznesowe to temat rzeka aczkolwiek, te mające ambitniejsze uzasadnienie i opisane czymś więcej niż tylko prozą stanowią już raczej ułamek całości. Stale śledzę literaturę z tej dziedziny i ... mało się tu dzieje nowego. To w sumie dobry to znak, be jest symptomem dojrzałości dziedziny wiedzy. Tak, dojrzałości. W zasadzie trudno tu coś nowego wynaleźć, raczej okazuje się, że "wszystkie drogi prowadzą do Rzymu". [...]Podsumowując: wartością dodaną mającą, wartość rynkową dla odbiorcy (klienta) jest to co powoduje, że ONI przychodzą do nas :). Jest to nasz produkt ale MY (dostawca) jesteśmy częścią tego produktu! Dowodem na to jest pojęcie marki, kojarzymy ją z dostawca (producentem). Nie ma znaczenia sam brązowy napój z bąbelkami, one wszystkie smakują podobnie, znaczenie na także Nazwa i Logo reprezentujące Konkretnego Producenta.Czemu korzystam z mojego modelu? Otóż kluczową cechą modelu dla potrzeb analizy systemowej jest traktowanie go, pojęć z których się składa, jako pewnej przestrzeni nazw (conceptów) spełniających podstawową zasadę wzajemnego wykluczania się definicji pojęć. Dlatego nie łączę nigdy kosztów razem, rozdzielam koszty zasobów i koszty materiałów służących do wytworzenia produktów (pierwsze należą do nas, amortyzujemy je, drugie kupujemy w procesie zaopatrzenia by całkowicie je zużyć). Aktywności i zasoby zaś łączę pojęciem Proces Biznesowy, który modeluje ścisły związek pomiędzy zasobami (w tym role) a ich wytworami. To pozwala budować zstępującą hierarchie dekompozycji, uszczegóławiające każde z tych pojęć.

Czytaj dalejBusiness Model Canvas

Model biznesowy czyli po co mi te procesy przed wdrożeniem ERP czy CRM…

Wdrożenie nowego oprogramowania, jeżeli ma mieć sens, powinno więc wspierać tworzenie dodatkowego zysku lub przychodu, w przeciwnym wypadku w zasadzie nie ma sensu. Innym powodem może być ratowanie posiadanego już przychodu czyli utrzymania się na rynku.Dodatkowy zysk, to efekt obniżania kosztów. Ratowanie posiadanego rynku, to efekt reakcji na siły rynku: siły dostawcy (np. jego system EDI wymusza inwestycje u nas), siły odbiorcy (oczekuje obsługi podobnej do tej, jaką oferuje konkurencja), siły konkurencji (ich produkty i usługi są wyższej jakości, musimy też zainwestować).Powyższy model obrazuje to co ma wpływ na to Dlaczego zarabiamy. Zbudowanie takiego modelu dla konkretnej firmy, zrozumienie Dlaczego zarabia, pozwala szukać sposobu i miejsc mogących przyczynić się do realizacji celu projektu, jednak cel ten należy wcześniej Nazwać. Drugi krok to ocena możliwości realizacji i prognozowanie skutków, by określić cel: miarę i wielkość tego co chcemy osiągnąć by wiedzieć czy się udało.PodsumowanieModel biznesowy moim zdanie nie odnosi się do procesów biznesowych, to procesy biznesowe są konsekwencją modelu biznesowego. Dlaczego? Bo jeśli przyjmiemy, że model biznesowy obrazuje (dokumentuje) źródła zysku firmy w łańcuchu wartości na rynku, to procesy biznesowe są opisem tego, w jaki sposób ta wartość wewnątrz firmy powstaje. To pozwala dopiero wskazać jakie działania (procesy) wesprzeć i jak, by "ulepszyć" firmę. Dlatego brak modelu biznesowego jest poważnym utrudnieniem analizy wymagań... bo czego wymagać od oprogramowania skoro nie wiemy co i jak pomoże w zarządzaniu firmą?

Czytaj dalejModel biznesowy czyli po co mi te procesy przed wdrożeniem ERP czy CRM…

Koniec treści

Nie ma więcej stron do załadowania