Automatyzacja procesów biznesowych to nawet nie jest zarządzanie zorientowane na procesy, to zaprzeczenie idei procesowego zarządzania, gdzie nadrzędnym celem jest ustanowienie jakości produktu procesu jako jego jedynego miernika, zaś właściciela procesu jako jedynej osoby odpowiedzialnej za tę jakość. Model (mapa) procesów to nie algorytm (co niektórzy usiłują forsować) ale scenariusze powstawania wartości dodanej z odzwierciedleniem odpowiedzialności za te wartości, wskazaniem jej twórców czyli wykonawców czynności w procesach. Czym więc jest ta ?mapa procesu biznesowego?? Jest to model tworzenia wartości przez organizacje a nie algorytm pracy ? algorytm zastępuje mózg, ma to sens w komputerze bo ten nie ma mózgu i tylko tam?
Kryzys zmusza do jeszcze bardziej wnikliwego myślenia i o strategiach rynkowych i o strategiach IT, bez których w sumie trudno sobie wyobrazić te pierwsze. Dwa lata temu pisałem o tym, że nadejdzie koniec systemów zintegrowanych w roli jednego uniwersalnego systemu w firmie: SOA: Czy to już nadchodzący koniec zintegrowanych ERP?
Wybór oprogramowania to trudne zajęcie i nie raz kosztowne. Pojawiają się narzędzia i metody, które pozwalają spróbować dokonać wyboru prościej, przekonać się na ile nasza firma jest “podobna” do innych. Możliwe, że standaryzacja pracy pozwoli wdrożyć rozwiązanie przygotowane “dla mas”. Uważam, że jeśli mamy przesłanki (np. benchmarking) do podejrzeń, że jesteśmy typową firma produkcyjną, funkcjonujemy w typowym łańcuchu dystrybucji oraz nie jesteśmy firmą obsługującą docelowych klientów (bo tu faktycznie trzeba się czymś wyróżnić) to możliwe, że standardowa instalacja ma szanse powodzenia… i warto zaryzykować skorzystanie z narzędzi opisanych poniżej …
(więcej…)
Obecna praktyka pokazuje, że jednak kierunek komponentowy jest słuszny. Komponenty to między innymi: łatwa do wdrożenia architektura SOA, łatwe dzielenie systemu na obszary o dedykowanych kompetencjach (np. osobno kadry i osobno finanse, osobno sprzedaż, inne). Taki podział to tak zwane dziedzinowe obszary a te to nie raz właśnie osobne specjalizowane podsystemy oraz interfejsy pozwalające na ich współpracę.Przy takim podejściu możliwe staje się używanie w modelu SaaS np. systemu CRM i lokalnie księgowości gdyż ilość wymienianych danych jest relatywnie mała i nie stoimy w obliczu utratry integralności danych.
Jednym z kluczowych elementów inwestycji w nowoczesne technologie jest tworzenie, utrzymanie a nawet powiększanie przewagi konkurencyjnej. Podstawą do projektowania tej przewagi jest stworzenie własnego modelu tej przewagi i zrozumienie przyczyn posiadanej przewagi oraz otoczenia rynkowego. Opisano tu model analityczny pozwalający na stworzenie opisu przewagi konkurencyjnej organizacji. Uważam, że wdrożenie jakiejkolwiek nowej technologii w celu poprawy konkurencyjności bez takiej analizy jest tylko losową próba poprawy sytuacji firmy, która przy nie trafionej inwestycji może nawet doprowadzić do bankructwa. Wszelkie prawa do treści opracowania są zastrzeżone.
[Czytelnik] Mam do Pana zupełnie prywatnie pytanie. Jak Pana zdaniem wypada oprogramowanie XXXX w porównaniu z innymi, podobnymi rozwiązaniami tego typu na rynku? Chodzi mi zarówno o poziom cenowy jak i funkcjonalność i możliwości tego systemu?
[J.Ż.] Nie wiem czy to Pana pocieszy czy zmartwi ale moja praktyka potwierdza jedno: najpierw cel potem narzędzie. Co ciekawe praktyka pokazuje, że nie licząc pewnych specyficznych dla środowiska cech niezmiennych systemu (są to jego ograniczenia), wdrożyć da się każde narzędzie.
Zaczęły się pojawiać kolejne ciekawostki uzupełniające dotychczasowe “trendy” w architekturze systemów informatycznych. Są to między innymi: CEP ? Complex Event processing EDA ? Event Driven Architecture SOA ? Service Oriented Architecture.
(więcej…)
Okres wakacyjny (kiedy to było …) zaowocował stosem zaległej literatury…. Dziś przyszła pora na zaległe numery Software Developer Journal. Czasopismo adresowane głównie do programistów i architektów ale jako analityk i ja także znajduje tam nie raz coś ciekawego.
(więcej…)
Model jawnie pokazuje, że bezpośredni związek z Bazą Danych mają Dane. Dalej już są wyłącznie niematerialne pojęcia czym więc jest Zarządzanie Wiedzą (milcząco zakładam, że zarządzać można czymś materialnym)? Jest to ?przechowywanie danych jednoznacznie zrozumiałych, opisujących określone i ograniczone liczbą fakty interpretowane jako pojmowalna przez adresata informacja?.
Paradoksalnie wykonanie takiego modelu jest tu największą trudnością. Dlaczego? Tworząc go należy bezwzględnie panować na jego złożonością, panować nad subiektywizmem osób z którymi prowadzimy wywiady, rozumieć strategię modelowanej firmy i jej model biznesowy, wiele innych. Identyfikacja procesów sama w sobie jest trudna, wymaga posiadania metod ich identyfikacji i weryfikacji poprawności samej analizy i modelu, to jednak temat na książkę a nie na taki artykuł.
Istotą opisu wymagań na system jest kontekst całego projektu i tej inwestycji a kontekstem tym jest model biznesowy i zakres projektu. Model biznesowy można wykonać nawet metodami formalnymi za pomocą pseudokodu czy języka relacji logicznych jednak model taki jest bezwartościowy, jeżeli nie stanowi sobą zrozumiałego przekazu dla każdego zaangażowanego w projekt czytaj "szczególnie klienta biznesowego". Kluczem do sukcesu jest tu modelowanie czyli zobrazowanie w sposób zrozumiały dla każdej strony w projekcie IT istoty biznesu i jego kontekstu w projekcie tworzenia i wdrażania oprogramowania. Model biznesowy i wewnętrzna struktura zarządzania organizacji to nie obiektowe modele a procesowe mapy łańcuchów tworzenia wartości w firmie. Model obiektowy ma zastosowanie dopiero podczas tworzenia modeli informacyjnych czyli struktury danych przechowywanych i przetwarzanych w firmie a dane to nic innego jak reprezentacja tych informacji, które firma chce przetwarzać oraz sposób w jaki chce to robić o czym wielu analityków zdaje się zapominać. Jak więc prowadzić analizy wymagań?
Dużo się mówi od pewnego czasu o architekturze systemów informatycznych zorientowanej na usługi (SOA, ang. Service Oriented Architecture) . Jest to trend zmierzający w stronę budowy tych systemów pod kątem specjalizowanych potrzeb biznesowych. Opisane wcześniej procesy biznesowe to nasze potrzeby zaś system to świadcząca nam pewne usługi infrastruktura. Jeżeli jednym z procesów biznesowych jest w firmie fakturowanie to nasz system informatyczny powinien świadczyć usługę wspierającą ten proces w postaci np. programu lub jego modułu dedykowanego do procesu fakturowania. Program taki lub jego moduł powinien operować takimi danymi jakie my w firmie wykorzystujemy. To jest ten moment, w którym to my określamy wymagania na program a nie dostawca narzuca nam możliwości swojego systemu. Zawsze możliwe jest to, że dany produkt nie spełnia naszych wymagań i nie powinno się z niego po prostu zrezygnować.
