"Modelowanie przedsiębiorstwa stwarza dobrą możliwość analizy oraz kształtowania procesów działania. Dzięki temu można uniknąć problemów przy wprowadzaniu zmian." (Hubert H. Zimmermann)
Ale nie chodzi w analizie i modelwoaniu organizacji o tworzenie mnóstwa diagramów, a o to, by zrozumieć jak organizacja funkcjonuje opisując to, oraz stworzyć model, który pozwoli na prognozowanie zachowania organizacji w odpowiedzi na bodźce, nawet te które jeszcze nie zaistniały. Prognoza? A jak Państwo chcecie ocenić ryzyko i skutki utraty członka zarządu (np. złamał nogę na nartach…;)) lub jednego z kluczowych dyrektorów? Jak chcecie ocenić skutki i ryzyko wdrożenia nowego systemu systemu ERP?
Model organizacji to nie trawnik boiska z wydeptanymi ścieżkami, bo trwa rośnie a kolejne rozgrywki to nowe ścieżki, nie narysujemy wszystkich możliwych! Model to reguły gry w piłkę nożną, umiejętności poszczególnych piłkarzy, granice boiska, obie połowy, pola karne i bramki. To decyduje o tym ja wygląda gra. Co jest ważne w analizie? Odkryć i jednoznacznie udokumentować obowiązujące zasady.
Moja metodyka to efekt doświadczeń zbieranych od 1989 roku, stale prowadzonych prac badawczych oraz studiowania światowej literatury na temat analiz systemowych, modelowania i projektowania systemów. Jest zgodna z zaleceniami międzynarodowych instytutów i organizacji zajmujących się dobrymyu praktykami i formalizowaniem metod analitycznych. Jest także zgodna z zaleceniami dostawców narzędzi programistycznych jak i gotowego oprogramowania wspomagającego zarządzanie, w szczególności systemów klasy ERP. Firmy te zalecają poprzedzanie projektów pełnymi analizami i projektowaniem, a w zakresie wdrażania gotowego oprogramowania zalecają analizę luki (rozbieżności cech gotowego produktu z udokumentowanymi wymaganiami) po czym wypracowanie kompromisu, zaprojektowanie i wytworzenie brakujących funcjonalności. Wbrew wielu ofertom firm wdrażających, producenci systemów ERP odradzają wszelkie ingerencje w kod ich systemów, tak zwane kastomizacje. Opisana tu metodyka dotyczy produktu analizy a nie zarządzania projektem analitycznym.
Powszechnie uważa się, że analiza wymagań na oprogramowanie to prosty, ale pracochłonny proces prowadzenia wywiadów i skrzętnego zapisywania tego, czego oczekuje przyszły użytkownik. Nic bardziej błędnego – jest to najgorszy sposób. Metody polegające na zbieraniu życzeń przyszłych użytkowników z pomocą ankiet, sesji warsztatowych, pisania tak zwanych user story, to metody nie poddające się żadnej weryfikacji ani ocenie kompletności. Możemy jedynie wierzyć, że nikt o niczym nie zapomniał, i że tak powstały opis jest spójny, co przy obecnej złożoności funcjonowania nawet małych firm, graniczy z cudem.
Najlepszym sposobem na minimalizację ryzyka w projekcie informatycznym (a ponad 75% to projekty z problemami) jest wybór dostawcy oprogramowania dopiero po opracowaniu analizy potrzeb i zaprojektowaniu architektury rozwiązania. To pozwala wybrać wśród wielu dostępnych na rynku możliwości, najlepsze dla zamawiającego.
Prawa do opracowanego systemu posiada jego autor. Jedynym sposobem na zabezpiecznie sobie wyłącznych praw do opisu metod pracy swojej organizacji i zamawianego oprogramowania, jest samodzielne opracowanie projektu lub zlecenie go niezależnemu projektantowi, a potem dopiero zlecenie jego wykonania i dostarczenia. Opis taki, projekt, musi jednak spełniać wymagania ustawy o prawie autorskim, które nie chroni opisu funkcjonalności ale chroni opis jej realizacji.
Audyt struktur i zasobów organizacji
Struktura organizacyjna, przetwarzane dokumenty, ludzie którzy sie tym zajmują, zasadność każdej czynności i ryzyka ich pominięć, ryzyka zaniedbań, reguły biznesowe, ograniczenia prawne. To tylko kluczowe elementy składające się na całość funkcjonowania organizacji. Większość firm posiada udokumentowaną strukturę organizacyjną, zakresy obowiązków pracowników. Jednak jak sprawdzić logikę i spójność powiązań tego w jedną całość? To, czy nie ma "bezpańskich" obowiązków, zbiorowej odpowiedzialności, przerośniętych kompetencji, niezdefiniowanych reguł biznesowych?
Analiza i specyfikowanie wymagań na oprogramowanie
W projektach IT mamy do czynienia z następującymi kluczowymi ryzykami, powodującymi znaczny wzrost kosztów projektu:
- Ryzyko wyboru złego oprogramowania,
- Ryzyko błędów w specyfikacji wymagań (brakujące wymagania, niespójność, zły model danych, wymagania "pod wykonawcę"),
- Ryzyko utraty metorycznej kontroli nad dostawcą oprogramowania,
- Ryzyko przejęcia "wiedzy i pomysłu" (know-how) zamawiającego przez dostawcę oprogramowania i sprzedawania ich kolejnym klientom.
Opracowanie wymagań na oprogramowanie wymaga wykonania audytu organiazacji. Na tym etapie zaleca sie ewentualne optymalziacje i zmiany organziacyjne. Jako wynik otrzymujemy model biznesowy działania (procesy, reguły, procedury, role, zasoby). Na podstawie celu biznesowego projektujemy wymagania na zasoby IT, konfrontujemy je już istniejącymi i opracowujemy wymagania na konkretne (nowe) oprogramowanie.
Jeżeli w roku analizy okaże się, że pewne wymagania wymagają opracowania dedykowanego oprogramowania (modułu), konieczne jest opracowanie takiego projektu a potem dopiero zlecenie jego realizacji wybierając optymalną technologię i wykonawcę. Projekt ten powinien bazować na modely biznesowym.
Narzędzia pracy
Do prowadzenia projektów wykorzystuję wyłącznie komercyjne, licencjonowane, wspierane przez dostwców oprogramowanie i serwer plików projektowych. Wszystko to z zachowaniem bezpieczeństwa danych i wysokiej niezawodności u renomowanych dostawców usług Data Center. Wszystkie pliki są chronione, kopie zapasowe (tak zwany backup) są wykonywane w trybie dobowym.
Nie wykorzystuję do pracy żadnych darmowych ani społecznościowych zasobów internetu, gdyż dostawcy tych usług ograniczają, a nie raz przejmują, prawa do przetrzymywanych tam zasobów, nie ponoszą też odpowiedzialnosći za ich utratę.
|
Analiza i projektowanie
