Noworoczne wynurzenia

Analiza to dość pojemne pojęcie w potocznym języku, jednak analiza jako etap procesu rozwiązywania problemu, wymaga podejścia wręcz naukowego, bardzo ścisłego. To się wiąże w zasadzie z koniecznością stosowania wyrafinowanych narzędzi analitycznych a takimi są systemy pojęciowe (najczęściej spotykane w tej branży po postacią notacji).Należy je bardzo dobrze poznać i zrozumieć ?moc? narzędzi jakim jest ?system pojęciowy? i ?język?. To wymaga czasu, braku presji do naginania zasad (np. naciskający na zmianę treści pracodawca lub zamawiający) oraz przede wszystkim przekonania, że ?to działa?.Niestety wielu ?sponsorów? projektów uważa, że płaci za wynik analizy. Niestety na rynku jest wielu analityków uważających, że właśnie to jest ich rola: dać oczekiwany wynik analizy.

Czytaj dalejNoworoczne wynurzenia

Biznes wychodzi z objęć systemu … monolitycznego ERP

Rynek stale się rozwija i dojrzewa. Praktycznie każda większa firma doświadczyła w jakiejś formie wdrożenia gotowego, dostosowywanego do potrzeb, oprogramowania ERP. Warto jednak podkreślić, że idea jednego "super systemu" ERP II, odchodzi powoli do lamusa. Moim zdaniem to kwestia roku, dwóch. Pierwsze symptomy to zalecenia producentów dużych systemów: wdrażać gotowe oprogramowanie w postaci "gotowej" tylko tam gdzie pasuje, obszary specyficzne dla firmy opisać i zaprojektować dla nich dedykowane rozwiązanie i zintegrować. Dobry system ERP to środowisko programistyczne (tak zwany framework, szkielet). Systemy, nawę je "zapóźnione", nadal wymagają ingerencji w ich kod by cokolwiek osiągnąć. Kompromisem jest sytuacja, w której system ERP ma bogaty interfejs (tak zwane [[API, Application Programming Interface]]) pozwalający na integrację dedykowanych podsystemów lub właśnie zewnętrznych komponentów czyli korzystania z możliwości jakie daje Cloud Computing). Przyszłość to komponenty...

Czytaj dalejBiznes wychodzi z objęć systemu … monolitycznego ERP

Zarządzanie zmianą w projekcie analitycznym

No cóż, temat się w rozmowach powtarza, jest nie łatwy więc kilka słów. Pomijając narzędzie, którym się tu posłużę, chodzi o "pryncypia" :): bezpieczeństwo projektu oraz zarządzaniem wersjami, zmianą, w tym wymaganiami. Zarządzanie zmianą Po pierwsze wydaje mi się, że chyba najlepszym sposobem na zarządzanie wersjami, zmianami, śledzeniem projektu itp. są wypracowane mechanizmy znane każdemu kto korzysta(ł) z takich narzędzi do zarządzania projektami jak SVN ([[Subversion]]) czy [[CVS]]. Chodzi o coś co się nazywa: znaczniki, gałęzie, wersje. Projekt ma tak zwaną linie główną (baseline, trunk). Jednak w trakcie prac nad projektem warto czasem stworzyć "odnogę" projektu. Pozwala…

Czytaj dalejZarządzanie zmianą w projekcie analitycznym

Podwójny obieg dokumentów w urzędach

Uważam, że korzyści z elektronicznego obiegu w urzędach są ogromne mimo faktu, że dokumenty inicjujący i kończący są (i długo jeszcze będą) nadal papierowe (ilu ludzi tak na prawdę ma możliwość posługiwania się elektronicznym dokumentem?!). Ważne jest by system taki po pierwsze, został dobrze zaprojektowany gdyż jego celem nie jest zastąpienie papieru, a zmiana sposobu pracy urzędu, a to ogromna różnica.Co jest moim zdaniem największym błędem? To, że urzędy "zamawiając" taki system, z góry zaznaczają, że "wdrożenie systemu elektronicznego obiegu dokumentów nie powinno wymagać zmian instrukcji kancelaryjnej i wewnętrznych procedur" i to jest idiotyczne podejście bo faktycznie nic nie naprawiając dokładamy kosztów i pracy...Tak więc sugeruję, by może nowe Ministerstwo Cyfryzacji zajęło się jak najszybszym opracowaniem drugiej wersji instrukcji kancelaryjnej dla Gmin (ja chętnie pomogę), planujących "cyfryzację" bo bez tego ten cały interes jest na plaster... wewnętrzny obieg dokumentów w urzędzie to zapewne 99% całej pracy z dokumentami. Więc chyba warto pozostawić "papierowe" dokumenty u obywatela a skupić się na owych 99%-ach wewnątrz urzędu bo tu tkwi problem. A archiwa? OK, kategorię archiwalna A ma znikoma ich ilość, więc nie zarośniemy bo pozostałe dokumenty w urzędach są od lat niszczone i będą.

Czytaj dalejPodwójny obieg dokumentów w urzędach

Hurtownie danych czyli “Systemy od historii”

Hurtownia danych to model stworzony pod kątem przetwarzania faktów historycznych na prostym modelu danych (diagram powyżej, górny, to tak zwana kostka OLAP). Opracowanie takiego modelu wymaga specjalnej analizy i projektu, ale nie zapominajmy: analizę się robi raz a raporty stale...Tak więc szanowni Państwo. Jeśli tylko Wasza firma jest bliżej czołówki niż ogona rankingu rynku w Waszej branży, nie dajcie się namówić na jeden zintegrowany ERP i jakiś model referencyjny, bo nawet jak uda się go wdrożyć, to zmiana czegokolwiek będzie trudna a upgrade do nowszej wersji niemożliwy. Opracowanie projektu systemu składającego się z komponentów, pozwoli Wam dobrać najlepiej spełniające Wasze wymagania aplikacje. Jak z klocków LEGO złożycie "dedykowany system" pomagający utrzymać przewagę na rynku, a nie cofający Waszą firmą do poziomu "innych podmiotów w branży".

Czytaj dalejHurtownie danych czyli “Systemy od historii”
computer model real world
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512

Czynniki sukcesu w projektach programistycznych

Pojawia się próba diagnozy. Pełna tak zwana śladowalność wymagań (nazwana tu hipertracebility) jest podobno kosztowna i trudna do utrzymania. Zaraz potem: niedbałość w definiowaniu wymagań - no to w końcu dokładnie czy nie? Kolej na analityków: zrzucanie odpowiedzialności ? analitycy tworzą dokument wymagań i wypychają go do programistów. Oczywiście jest to problem, co z tym? Analityk powinien ponosić odpowiedzialność za swój produkt do końca projektu. Założenie, że można stworzyć skończony dokument wymagań. Otóż można ale o tym za chwilę. Poza ważnymi elementami zarządzania takim projektem, w tym zarządzaniem zespołem autorzy wskazali jedną z głównych moim zdaniem przyczyn: brak dokumentu HLD (projektu wysokopoziomego).Otóż nie da się czymś tak złożonym jak oprogramowanie (zakładam, że to nie trywialny system), zarządzać na poziomie detalicznych szczegółów.

Czytaj dalejCzynniki sukcesu w projektach programistycznych

Ujarzmić dane – ale po co ich aż tyle?

Moim zdaniem hurtownie danych i wszelkiego typu systemy BI mogą być skuteczne jako wykrywanie "czegoś" w historii, na pewno sprawdzają się jako złożone systemy raportowania, ale nie sądzę by jakakolwiek hurtownia danych plus system BI odkryła cokolwiek nowego lub skutecznie prognozowała. [...] Budowanie modeli na bazie małych partii danych jest po pierwsze wiarygodniejsze (paradoksalnie) niż proste wnioskowanie statystyczne, po drugie daje szanse odkrycia czegoś nowego. W czym problem? To drugie jest nie możliwe z pomocą deterministycznej maszyny jaką jest komputer. To wymaga człowieka, ten jednak nie daje się produkować masowo... ;), korporacja na nim nie zarobi.Hm... czy przypadkiem promowanie systemów hurtowni danych, BI, pracy z terabajtami danych itp.. to nie tworzenie sobie rynku przez dostawców tych technologii?Warto więc za każdym razem, zanim zainwestujemy w rozwiązania operujące na terabajtach danych, przemyśleć co chcemy osiągnąć. W zasadzie nie ma uzasadnienia dla trzymania wszystkich danych, ważne jest określenie jaki problem chcemy rozwiązać. Jeżeli są to problemy związane z analizą danych historycznych, badania statystyczne mogą być skuteczne, do tego poddają się automatyzacji. Jeżeli jednak problem tkwi w planowaniu zmian, prognozowaniu, odkrywaniu, polecam raczej człowieka i budowanie hipotez.

Czytaj dalejUjarzmić dane – ale po co ich aż tyle?

Analiza biznesowa

Stosowanie opisanych tu formalizmów to uznanie, że dobre i sprawdzone standardy pozwalają zminimalizować ryzyko projektów analitycznych.Analiza to nie zbieranie danych o firmie i ich sortowanie, bo czy to nie brzmi jak ekologiczne zbieranie śmieci? Analiza to porządkowanie zebranej wiedzy o organizacji, korzystając z wypracowanych systemów pojęciowych, czyli przyporządkowywanie wszystkiego co wiemy do skończonej liczby pojęć, oraz uzupełnianie lub naprawianie wszystkiego czego zabranie w tak opracowanym modelu. Kluczem dobrej analizy jest uogólnianie czyli wychwytywanie rzeczy istotnych oraz odsiewanie informacji zbędnych, nie mających wpływu na cel projektu a zaciemniających go. Analiza to odkrywanie i rozumienie reguł, panowanie nad złożonością organizacji.Większość projektów takich jak np. wdrażanie nowych metod kontrolingu, zrównoważonej karty wyników, nowych systemów IT itp. cierpi głównie z powodu posiadania nadmiaru informacji z jednej strony i kompletnego jej niezrozumienia z drugiej. Sławne już w badaniach "złe i niekompletne wymagania" czy "zmiany zakresu projektu w trakcie jego trwania" to klasyczne skutki złej (a często pomijania!) analizy biznesowej. Koszty tych porażek wielokrotnie przewyższają koszt takich analiz.

Czytaj dalejAnaliza biznesowa

Producent systemu ERP chce 20 mln USD zadośćuczynienia od długoletniego klienta – kliencie pilnuj się, pomogę

Nie raz od klientów słyszę, że walka z dostawcę nie ma sensu, ale nie jest to prawda. Na etapie zawierania umowy zależy dostawcy bardzo, i jest to czas (ostatni!) by negocjować. Tak więc po pierwsze warto zadbać o treść uwowy, po drugie zadbać o swój know-how, jak? Dedykowane dla siebie funkcjonalności należy implementować, ale nie metodą ingerencji w pierwotny kod źródłowy (polecana przez dostawców kastomizacja) a poza nim, w postaci odrębnego projektu. Nawet jeżeli implementacja będzie miała miejsce w środowisku kupionej aplikacji to jednak nasz jest fragment kodu wytworzony od zera dla nas (jeżeli nie został zaprojektowany przez dostawcę pierwotnego systemu!). Tak więc po pierwsze warto zadbać o treść uwowy, po drugie zadbać o swój know-how, jak? Dedykowane dla siebie funkcjonalności należy implementować, ale nie metodą ingerencji w pierwotny kod źródłowy (polecana przez dostawców kastomizacja) a poza nim, w postaci odrębnego projektu. Nawet jeżeli implementacja będzie miała miejsce w środowisku kupionej aplikacji to jednak nasz jest fragment kodu wytworzony od zera dla nas (jeżeli nie został zaprojektowany przez dostawcę pierwotnego systemu!).

Czytaj dalejProducent systemu ERP chce 20 mln USD zadośćuczynienia od długoletniego klienta – kliencie pilnuj się, pomogę

Czas nie jest aktorem dla Systemu c.d. czyli projekt

aktorem absolutnie nie jest Czas, aktorem jest inny system, tu źródło sygnału czasu. Diagram UC jest zgodny ze standardem a my "zrozumieliśmy istotę rzeczy". Stosowanie w analizie standardów prowadzi do rozumienia i ma taką właśnie zaletę: analiza i modelowanie prowadzi do zrozumienia problemu, łamanie zasad notacji ukrywa niezrozumienie problemu (o co chodzi z tym oczekiwanym przez klienta czasem).

Czytaj dalejCzas nie jest aktorem dla Systemu c.d. czyli projekt

Czas nie jest aktorem Systemu

Tak więc radzę ostrożnie z Wikipedią. Wprowadzanie pojęć ukrywających istotę rzeczy to moim zdaniem, ukrywanie niewiedzy na etapie analizy i projektowania. To jedna z przyczyn złej jakości procesu tworzenia oprogramowania. Niezależnie od tego jak ładnie umotywujemy istnienie aktora Czas, programista i tak musi ten problem rozwiązać i nie będzie to na pewno interfejs "interakcji Systemu z Czasem"... A co z czasem? No cóż, albo człowiek klika co godzinę w coś, albo wewnątrz systemu jest moduł, który generuje zdarzenie wywołujące te samo operację co klikający użytkownik... Moduł wewnętrzny systemu nie jest jego aktorem.Jak w takim razie w ogólności modelować cykliczność? Np. "prenumerata czasopisma na okres 12 m-cy", "codzienne generowanie raportu", "zbieranie wskazań licznika co N jednostek czasu" ? Po pierwsze usługa systemu to odpowiednio: zarządzanie prenumeratami, generowanie raportów, przetwarzanie pomiarów. Prenumerata to zapis mówiący, że mam otrzymać np. każde wydanie jakiegoś periodyka w ciągu danego roku. Generowanie raportów to czynność człowieka (raport na życzenie) albo automatu reagującego na zdarzenie "konkretny czas", zdarzenia takie generuje np. zegar systemowy. Zbieranie wskazań licznika to cykliczne zdarzenie inicjowane przez System. Implementacja tych wymagań to element projektowania logiki biznesowej i nie jest to już diagram przypadków użycia a model dziedziny systemu bo to tu jest logika biznesowa.

Czytaj dalejCzas nie jest aktorem Systemu

Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

Mapa (model) procesów oraz struktura organizacyjna, by były jednoznaczne, muszą być także zestawem zdefiniowanych pojęć. Musimy wiedzieć co znaczy słowo: przełożony, podwładny, komórka organizacyjna czy jej kierownik. Jeszcze większym wyzwaniem zdefiniowanie systemu pojęć dla mapy procesów (proces, czynność, zdarzenie, dokument...). Budowanie systemów pojęciowych spełniających powyższe warunki jest bardzo trudne dlatego dla modeli procesów biznesowych najlepiej wykorzystać gotowy model pojęciowy: jest nim notacja. Najlepiej obecnie opracowanym takim modelem pojęciowym jest gotowa notacja [[BPMN]]. Tworzenie własnych jest kosztowne (czas i wiedza osoby opracowującej) i bardzo ryzykowne (może się nie udać). Dlatego używanie dzisiaj własnych lub innych (np. dostosowywane profilami diagramy UML) jest w moich oczach nieracjonalnym podejściem.Model pojęć specyficzny dla danej organizacji niestety musi powstać "od zera", podobnie jak powiązana z nim specyfiakcja reguł biznesowych. Jest to trudne bo tworzenie przestrzeni nazw wymaga utrzymania niezależności poszczególnych definicji i spójności i zupełności całego ich systemu. Niedochowanie tych wymagań prowadzi do niepełności a nawet sprzeczności reguł biznesowych, które w końcu są budowane (odkrywane i dokumentowane) z pomocą tych pojęć. Zanim wiec zaangażujesz kogoś do modelowania własnej firmy, upewnij się, komu zlecasz tę pracę...W bardzo dużym więc skrócie:procesy biznesowe to faktyczny, widoczny sposób pracy firm (ludzi w nich zatrudnionych), procesy to efekt funkcjonowania ludzi w środowisku ograniczeń, należy poznać tych ludzi, ograniczenia to: procedury, prawo, zarządzenia wewnętrzne oraz specyficzne dla firmy wewnętrzne normy zwane regułami biznesowymi, opracowanie biznesowego modelu firmy wymaga zrozumienia i opisania tego co powyżej opisałem, nie istnieje droga na skróty. ...

Czytaj dalejReguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

Koniec treści

Nie ma więcej stron do załadowania