Pojawia się wiele nieporozumień na temat zakresów projektów analiz przed-wdrożeniowych, sam padłem ofiarą jednego z nich. W czym problem? Koszty i czas trwania takiej analizy. Do napisania tego artykułu natchnął mnie kolega (Jacek Mamot, prezes K2 Consulting) podczas swojej prezentacji na dzisiejszym CRM GigaCon.
Co analizować
Okazuje się, że nie należy zapominać zadawać dodatkowych pytań. Na pytanie „ile to kosztuje i trwa” odpowiedziałem enigmatycznie (w tym blogu pojawia się to nie raz), że koszt analizy wymagań to ok. 10-20% budżetu projektu, a czas jej trwania to ok, 50% czasu całego projektu.
O czym zapomniałem? O rozdzieleniu wymagań funkcjonalnych od ograniczeń (wymagań poza funkcjonalnych) i tak zwanego przejścia. Oprogramowanie ma dwa aspekty:
- funkcjonalności,
- skala (skutki ograniczeń).
Ile i co kosztuje
Koszt każdego projektu programistycznego to trzy etapy i zarazem składniki:
- analiza i opracowanie wymagań (projektowanie)
- wytworzenie, dostarczenie produktu
- wdrożenie (przejście)
Uwaga: logika biznesowa nie zależy od liczby użytkowników (zakładam milcząco, że dobry projekt to i tak liczba mnoga potencjalnych użytkowników, więc współdzielony dostęp do danych jest możliwy zawsze) i rygorów ich pracy. Tak więc warto pamiętać, że należy stworzyć dwa dokumenty:
- Specyfikację tego jakie oprogramowanie ma zostać dostarczone – Analityk Biznesowy,
- Plan i wycena projektu, w tym przejście – Dostawca, tu składniki: koszt i termin wytworzenia oprogramowania, koszt niezbędnej infrastruktury, koszt wdrożenia (tak zwane przejście)
Tak więc koszt etapu Analityka Biznesowego to ok. 20% budżetu i 50% harmonogramu ale wytworzenia i/lub dostarczenia oprogramowania. Nie obejmuje on etapu przejścia, który ma wymiar wyłącznie organizacyjny (szkolenia, zmiany kompetencji, etapy zmian zakresów obowiązków itp.) i zasobowy (nowi pracownicy, koszt licencji na oprogramowanie, platforma systemowa i jej wydajność i pojemność).
Jeżeli więc projekt obejmuje więcej niż kilkadziesiąt osób (pracowników) warto zacząć wyróżniać projekt „przejścia” jako odrębny etap. W jakim momencie ja się „pomyliłem”? Przemilczałem przejście. Ja nigdy go nie dotykam, bo to robi dostawca.
Dostawca oprogramowania zawsze musi przeprowadzić analizę przed-wdrożeniową, której celem nie jest analiza wymagań (te już są) a analiza kosztów wdrożenia a wcześniej tak zwana analiza gap/fit (analiza tego, które wymagania system spełnia, a których nie).
Tak więc na zakończenie zwrócę uwagę: analiza wymagań i projekt oprogramowania jest złożona, niezależnie od tego ilu użytkowników go będzie używało. Jednak koszt wdrożenia oprogramowania w firmie 10 osobowej będzie nieporównywalnie mniejszy niż w korporacji zatrudniającej 10000 osób. Tu jednak problemy leżą już gdzie indziej.
Ale ktoś powie: duży ERP wymaga przewidzenia wielu ról w systemie i w związku z tym obsługi wielu etapów jakie pokonują tam dokumenty. Owszem, dlatego uważam, że należy osobno wybrać system, który wchłonie te dokumenty (np. finanse itp.) i osobno system, które je tam doprowadzi czyli „jakiś workflow”. To dużo bezpieczniejsze i mniej ryzykowne. Na diagramie poniżej (dane z IBM) wdrożenie to etap instalacji i oddania do użytku.
Prawo autorskie do treści
Na zakończenie warto zwrócić uwagę na prawo do treści dokumentu raportu z analizy. Bardzo często zawiera on projekt rozwiązania, pomysł na rozwiązanie problemu. Proszę zwrócić uwagę, że projekt zawierający docelowy model procesów, procedury, scenariusze pracy, specyfikacje reguł biznesowych, wzory dokumentów i wiele innych elementów takiej dokumentacji to „prace o indywidualnym charakterze”.
Jeżeli w ramach analizy wymagań powstaje także projekt oprogramowania dedykowanego, w zasadzie cały on jest dziełem w rozumieniu prawa autorskiego.
Analiza biznesowa i i dokumentacja pomysłu (bo czym innym jest specyfikacja wymagań na oprogramowanie, to zapis naszego pomysłu na system) projektu, efekt naszej ciężkiej pracy, wypracowywania latami modelu biznesowego, własnych metoda zarządzania, tego co nie raz stanowi klucz przewagi konkurencyjnej.
Jeżeli prace te wykona dostawca oprogramowania z zasady staje się posiadaczem tego pomysłu. Nie raz pewnie słyszeli Państwo w ofertach i na konferencjach stwierdzenia w rodzaju: „zgromadziliśmy doświadczenie z branży …”, „oferujemy referencyjne modele biznesowe, najlepsze praktyki branżowe…”. Czym one są?
Dlatego dobrą praktyką jest raczej oddzielenie projektowania od wykonania. Zlecenie analizy i opracowania rozwiązania i przejęcie praw majątkowych do opracowania (projektu systemu) i na tej podstawie dopiero wskazanie wykonawcy daje gwarancje, że dostawca oprogramowania nie nabędzie żadnych praw do Państwa pomysłu. Daje gwarancję, że Wasz unikalny pomysł nie stanie się „modelem referencyjnym dla branży…” lub co gorsza „gotowym produktem z pudełka”… bardzo często są to powielone, nie raz nielegalnie lub co najmniej nieetycznie, cudze rozwiązania.
