A po co nam ten SWOT

Wielu właścicieli firm, ich zarządy, pomija ten etap w projektach z uwagi na swoje przekonanie, że ich dotychczasowe działania i chęć ich kontynuacji, nie wymagają żadnej korekty, oczekują podania na tacy opisu narzędzia, którego - jak sądzą - potrzebują. Zachowują się jak pacjenci, którzy mimo, że ostatnie badania robili wiele lat temu, nie dopuszczają myśli, że lekarz może im przepisać na gorączkę coś innego niż kolejną aspiryną. Bywa, że zbyt późno odkrywają, że tym razem to nie było kolejne przeziębienie.

Czytaj dalejA po co nam ten SWOT

Modelowanie struktury organizacyjnej – widać światełko w tunelu

Na konferencjach i forach toczą się stale dyskusje na ten temat. Większość firm doradczych, informatycznych i ich analitycy bronią tezy, że celem analizy jest zebranie informacji w postaci dokumentów i zestawień. Niestety takie dokumenty są kompletnie nieprzydatne, mają wartość nagrania (patrz wyżej zdjęcie lotnicze), nie da się na ich postawie wyciągać żadnych pozwalających na dowodzenie ich słuszności, wniosków nie licząc może oceny estetyki edytorskiej. Niewątpliwą "zaletą takiej analizy" jest to, że nie wymaga ona absolutnie żadnych kompetencji poza umiejętnością komunikacji. Takim analitykiem może być niemalże każdy (łatwa rekrutacja, niski koszt), ale czy taki jest cel analiz poprzedzających projekty, warte setki tysięcy złotych a nie raz miliony? Na zakończenie dodam, że najgorszym sposobem jaki znam i jaki niestety często spotykam, na modelowanie struktury organizacyjnej, jest użycie diagramu klas lub diagramu przypadków użycia i modelowanie z zastosowaniem dziedziczenia (klas lub aktorów).

Czytaj dalejModelowanie struktury organizacyjnej – widać światełko w tunelu

Architektura korporacyjna z OMG.org

Mamy więc pomysł o wdzięcznej nazwie Architektura Korporacyjna. Po nam to? Po co nam taka dokumentacja? Przykłady korzyści z jej posiadania: mamy "na tacy" model systemy zależności (analizy wpływu) pozwalający natychmiast ocenić ryzyka związane z wzajemnym wpływem na siebie procesów, ludzi, zasobów (np. jakie skutki będzie miało wyłączenie konkretnego serwera czy spóźnienie do pracy konkretnego pracownika), mamy "na tacy" wymagania na oprogramowanie, bez niepotrzebnego "zwinnego" ich poszukiwania metodą prób i błędów, niezależnie od tego czy kupujemy nowe czy wymieniamy (niestety, tak zwane zwinne metody to nie raz bardzo duże koszty "zarzuconych bocznych ścieżek" odkrywanych burzą mózgów), od razu zauważymy, że idea posiadania monolitycznego systemu ERP II nie bardzo ma sens (to usztywnia organizacje oraz tworzy potężny [["single point of failure"]], złośliwi dodają "single point of big cost" :)), i najważniejsze: jak tylko przeprowadzimy analizę i wykonamy model AK szybko wychwycimy tak zwane osierocone wymagania na oprogramowanie, osierocone stanowiska pracy, osierocone procedury, ... (osierocone: niewykorzystywane), to nie raz źródło samo w sobie - eliminacja "sierot" - ogromnych oszczędności, i inne ... Jak tym zarządzać? Na pewno nie ręcznie, bez oprogramowania CASE w zasadzie nierealne. Czy to kosztowne? Hm... kłania się analiza ROI, więc każda organizacja ma swój próg rentowności. Jednak od siebie powiem tak: oszczędności pojawiają się natychmiast w postaci identyfikacji "sierot". Kolejny etap oszczędności to reorganizacja kosztów i ryzyk zarządzania organizacją, kosztów posiadania oprogramowania, kosztów jego rozwoju, kosztów zakupu i tworzenia. Dobra wiadomość: początek każdy już ma w postaci prowadzonej dokumentacji w dziale HR.

Czytaj dalejArchitektura korporacyjna z OMG.org

Analiza oddziaływania i jakość modelowania

Model zawierający wyżej opisane śladowania (i tylko taki!) pozwala na analizę zalezności, np. chcemy dowiedzieć się na co ma wpływ Proces_2, wtedy powinien powstać np. taki diagram: Jak widać, śladowanie jest tu warunkiem koniecznym dlaczego? Taki model może powstać "automatycznie" (narzędzie do modelowania musi posiadać taka funkcjonalność). jednak to nie jedyny warunek: model musi zachowywać formalna poprawność, czyli nie używamy pojęcia Rola (pas na modelu procesów) do symulowania "systemu" który coś robi, bo oprogramowanie to narzędzie człowieka (rola w procesie), specyfika użycia danego narzędzia to umiejętności aktora (użytkownika) i jest to co najwyżej problem skojarzenia danej czynności (procesu) z dokumentem opisującym procedurę lub instrukcję użytkownika (to także narzędzie powinno umożliwiać). Wszelkie łamanie formalizmów notacji odnosi taki sam skutek jak np. wykorzystywanie pól w bazie danych do przechowywania innych danych niż te z nagłówka np. wpisywanie drugiego imienia do pola Nazwisko czy nazwy dzielnicy w pole Miasto. Z takiej bazy danych żaden sensowny raport już nie powstanie. Jeżeli na modelu procesów użyto symboli w innych znaczeniach niż to wynika z użytej notacji żadnej sensownej informacji też nie uzyskamy... to już nie modele tylko zwykłe obrazki.

Czytaj dalejAnaliza oddziaływania i jakość modelowania

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

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 dalejNieudane wdrożenie wielkiego systemu informatycznego w USA – a co u nas?

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

Koniec treści

Nie ma więcej stron do załadowania