74 Znaleziono wyniki wyszukiwania

Szukałeś: "audyt organizacji"
Tablice decyzyjne

Tablice decyzyjne

Wiele firm ma problemy zarządcze nie dlatego, że są źle zarządzane, ale dlatego, że stopień złożoności tych firm jest zbyt duży by podejmować je na wyczucie. W obecnych czasach decyzje muszą być podejmowane w relatywnie krótkim czasie bo rynek nie czeka, jednak jakość tych decyzji nie powinna być zła. Dlaczego bywa zła? Bo decyzje są nie raz podejmowane z niepełnym zrozumieniem sytuacji. Podejmowana decyzja, by była możliwie najlepsza, wymaga pełnego zrozumienia, tego czego dotyczy (co chyba nie jest dziwne). Jeżeli dotyczy firmy, nie powinno się podejmować decyzji bez pełnego zrozumienia potencjalnego wpływu tej decyzji na firmę. W przeciwnym wypadku skutki są dość losowe, czyli nie zarządzamy a staramy się zarządzać.

[…] Analiza biznesowa organizacji poprzedzająca np. wdrożenie nowego oprogramowania, powinna polegać na wykonaniu audytu i uporządkowaniu reguł decyzyjnych oraz opracowaniu modeli procesów biznesowych by je zweryfikować. Drugi krok to ocena, jakiej wiedzy oczekujemy od ludzi (ich umiejętności i wiedza). Dokumentujemy ją z obawy przed “błędem ludzkim”. Tu zwracam uwagę na to, że wymaganiem na oprogramowanie może być tablica decyzyjna, jeżeli planujemy automatyzację jakiejś czynności. Proces biznesowy nie jest wymaganiem, to co najwyżej kontekst wykonywanych czynności.

Czytaj dalej Tablice decyzyjne
Modelowanie struktury organizacyjnej

Modelowanie struktury organizacyjnej

Dosyć często spotykam się z modelowaniem struktur organizacyjnych czy nawet ról w procesach, z pomocą diagramów przypadków użycia i hierarchii aktorów z użyciem dziedziczenia. Jest to moim zdaniem kompletne nieporozumienie i fałszywe.

Zawiłe diagramy struktur organizacyjnych w postaci aktorów dziedziczących po sobie (nie przytoczę tu żadnego, każdy taki jest w zasadzie zły), na których przełożony dziedziczy po podwładnym (lub podobne konstrukcje), są niemalże zawsze gruntu fałszywe. Studiowanie zakresów obowiązków pracowników firm jawnie pokazuje, że to nie prawda. Z zasady wielu menedżerów działów nie ma kompetencji swoich podwładnych, nie raz szef działu prawnego nie ma, i nie musi mieć, uprawnień radcowskich czy adwokackich, w wielu większych sekretariatach, upoważnienia do pewnych podpisów są przydzielane indywidualnie i szef (szefowa) nie ma tych wszystkich upoważnień. Szef kancelarii tajnej może mieć uprawnienia do informacji tajnej nadane przez ABW, których to uprawnień nie ma nie raz, jego przełożony. Przykładów na fałszywość dziedziczenia uprawnień w strukturze organizacyjnej można podać tak ogromną ilość, że dość częste stosowanie tej konstrukcji wydaje mi się niezrozumiałe. projektują oprogramowanie także, z reguły nieprawdą, jest dziedziczenie praw dostępu. Nie przypadkiem w praktyce stosuje metody macierzowe zarządzania prawami dostępu (niewydolne i nie prawdziwe w sensie biznesowym) lub kontekstowe (dużo lepsze).

Czytaj dalej Modelowanie struktury organizacyjnej
Projekt wykonany – co było robione

Projekt wykonany – co było robione

Powyższe jest zgodne z zaleceniami OMG.org (https://www.omg.org/mda), audyt to etap CIM a projektowanie przypadków użyci i modelu dziedziny to etap PIM.

Wykonanie takiej analizy jest pracochłonne i wymaga dużego doświadczenia, umiejętności analiz procesów biznesowych, projektowania obiektowego i dobrego narzędzia CASE, jednak modele te pozwalają także przeprowadzić analizy wpływu (zależności pomiędzy procesami, skutki i podatność na awarie oprogramowania itp.) oraz zredukować do minimum prawdopodobieństwo przekroczenia terminu i kosztów (statystyki wskazują na średnie przekroczenie kosztów o 60% i terminów o 200% projektów z niskiej jakości specyfikacji wymagań). Praktyka autora wskazuje, że warto taką analizę przeprowadzić dla projektów, których budżet przekracza 50-70 tys, zł i większych.

Czytaj dalej Projekt wykonany – co było robione
Proces zbierania i analizy wymagań u developera

Proces zbierania i analizy wymagań u developera

Analiza Biznesowa i specyfikacja wymagań opracowana metodą opisywaną tu i na stronach OMG, jest od tej ostatniej (grupa konsultantów i sesje warsztatowe) znacznie tańsza. W czasie trwa podobnie, jednak robi to z reguły jedna osoba (tak! ale przy założeniu ma stosuje zaawansowane narzędzia CASE nie tylko do tworzenia diagramów ale także do ich weryfikacji śladowania zarządzania spójnością modeli itp.), a efektem jest projekt logiczny a nie dopiero lista wymaganych cech. Korzyść jest więc podwójna. Jeżeli zrobi to Analityk wynajęty przez Klienta a nie Dostawcy, to wszelkie prawa (know-how) do projektu pozostają po stronie nabywcy.

Można powiedzieć, że to trudne i kosztowne. Trudne owszem, wymaga doświadczenia i wiedzy zarówno z zakresu zarządzania jak i inżynierii oprogramowania. Per saldo, wliczając w to koszty modyfikacji na etapie wdrażania i odkrywania wymagań (wady specyfikacji nie poddającej się weryfikacji) jest to proces zawsze tańszy (badania kierowników projektów wskazują, że zła jakość wymagań generuje dodatkowe koszty rzędu 60% wartości projektu, koszt takiej analizy nie przekracza zaś 20%). Do tego pojawiają się potencjalne koszty nieujawnione klientowi: prawa autorskie do projektu i aplikacji. Jeżeli firma będąca wykonawca oprogramowania robi analizę swojego klienta i potem mu sprzedaje prawa do jej wyników wraz z dostarczanym oprogramowaniem, to jest to klasyczny przypadek anegdoty o konsultantach, którzy zapytani o to która jest godzina, proszą Cie o Twój zegarek, odpowiadają na pytanie która godzina i wystawiają fakturę za usługę i także za zwracany Ci Twój zegarek.

Czytaj dalej Proces zbierania i analizy wymagań u developera
Ach ten opluty wodospad… czyli lessons learned ERP

Ach ten opluty wodospad… czyli lessons learned ERP

Opisane tu podejście często nazywane jest “kaskadowym” (waterfall – wodospad). Jest ono dość często wskazywane jako powód porażek projektów, ale moim zdaniem jest to pewna demagogia, gdyż tak na prawdę przyczyną większości problemów jest nie tyle “wodospadowe” podejście, ono jak widać z powyżej opisanego procesu, ma głęboki sens, co wzięcie sobie na barki projektu (zawarcie umowy z dostawca na trzy lata to przyjęcie w dniu jej zawarcia harmonogramu łamiącego opisana powyżej zasadę) na lata zaniedbując zupełnie fakt, że otoczenie rynkowe obecnie zmienia się nawet co kwartał.

Mamy więc kuriozalne zestawienie: podjęcie projektu od razu od ostatniego etapu (wybór dostawy, produktu i realizacja) i zaplanowanie go od razu na np. trzy lata. To projekt w rodzaju “nie wiem co tu jest grane ale kupujemy [ten system] i wdrażamy go”. To nie ma prawa się udać…

A nasze “lessons learned”? No właśnie, znane mi projekty zakończone kłopotami, to właśnie projekty na skróty. Projektu prowadzone w myśl powyższych zasad (krótkie i dobrze zaplanowane etapy) są znacznie bardziej odporne na kłopoty.

Czytaj dalej Ach ten opluty wodospad… czyli lessons learned ERP
Znajomość branży klienta szkodzi a nie pomaga…

Znajomość branży klienta szkodzi a nie pomaga…

Jakie doświadczenie i gdzie jest potrzebne
I teraz pytanie jakie architekt budowlany musi mieć doświadczenie, jeżeli chce zaprojektować most? Wypadało by nie był to jego pierwszy most, ale czy musi znać miasto, w którym ten most powstanie? Czy musi mieć “doświadczenie kolejowe” dlatego, że to most kolejowy? Raczej nie, powinien mieć doświadczenie w projektowaniu mostów.

Dlatego ktoś, kto ma rolę analityka i projektanta w projekcie, powinien mieć bardzo duże doświadczenie w analizie i projektowaniu, ale znajomość konkretnej branży nie wnosi tu żadnej wartości dodanej, a biorąc pod uwagę fakt, że rutyna zabija, potrafi być wręcz szkodliwe.

Jeżeli to zamawiający oczekuje analityka z doświadczeniem w swojej branży, nie raz kieruje się on przypuszczeniem, że to ułatwi komunikację z nim. Jednak problem tkwi nie w znajomości branży a w komunikatywności ogólnie. Analityk powinien się cechować bardzo dobrymi zdolnościami komunikacyjnymi a nie znajomością konkretnej branży (wtedy raczej ryzykuje popadniecie w slang branżowy, co raczej przeszkadza niż pomaga).

Z perspektywy dostawcy rozwiązań, popularyzującego tezę, że “on jest lepszy bo ma wiedzę z danej branży”, jest to raczej próba stworzenia sztucznej bariery wejścia dla konkurentów, bo z wyżej opisanych powodów trudno o inne uzasadnienie… Zwróćmy uwagę, na to, że firmami, poza nielicznymi wyjątkami, zarządzają specjaliści od zarządzania. Branża ich doświadczeń ma tu drugorzędne znaczenie bo konkretny rynek musi znać dyr. marketingu a nie prezes firmy, ten drugi musi się umieć z tym pierwszym dogadywać. Inżynierowie dziedzinowi w roli prezesów, Ci częściej doprowadzają swoje firmy do upadku…

Czytaj dalej Znajomość branży klienta szkodzi a nie pomaga…