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.

Continue ReadingJak 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...

Continue ReadingCloud 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...

Continue ReadingPokazać 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"...

Continue ReadingKilka 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...

Continue ReadingCo jest wadą większości analiz biznesowych?