Wypełniam lukę między biznesem a dostawcami systemów Jarosław Żeliński Identyfikuję potrzeby, specyfikuję wymagania na systemy informatyczne. Projektuję oprogramowanie i nadzoruję jego wdrożenie. Utrzymuję spójność dokumentacji procesów biznesowych i powiązanych z…
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.
Krótki wpis po pewnej nie długiej dyskusji na pewnym forum. Jeden z dyskutantów przytoczył definicję zakresu projektu publikowaną w WIKI:
Zakres projektu jest to możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu.
Zakres nigdy nie określa konkretnych zadań mających na celu realizację projektu. Odpowiada na pytanie, co powinno być zrobione w projekcie. Wyznacza ramy do oszacowania kosztu projektu i czasu realizacji projektu. Zakres, koszt i czas tworzą parametry projektu, tzw. ?magiczny trójkąt?. (Zakres projektu ? Wikipedia, wolna encyklopedia).
Tak więc mamy pytanie: „co powinno być zrobione w projekcie”? Pytanie jakie ja postawiłem: „czyim projekcie”? Zakres projektu dla kogo? […] W moich oczach nie ma nic bardziej ryzykownego niż przekazanie Opisu Księgowej od razu programistom do wykonania. Bo mamy tak na prawdę trzy zakresy projektu, każdy inny, każdy ma innego adresata i każdy należy udokumentować inaczej, ale zawsze jednoznacznie postawić zadanie.
Praca bez tego typu dokumentów, bez jasnego wydzielenia poszczególnych etapów analizy, tak często praktykowana przez wiele firm IT, to atak na twierdzę bez mapy terenu i strategii…
Tu należy się uwaga, że znaczny udział usług to obecnie usługi związane z tworzeniem oprogramowania tak zwanego dedykowanego lub jego dostosowywania. Moim zdaniem można uznać prognozę IDC z 2003 roku za trafioną. Obserwując nie tylko przetargi proporcje te wydają się jak najbardziej trafne.
Warto zwrócić uwagę, że obecna złożoność oprogramowania wspomagającego biznes, praktycznie uniemożliwia skuteczne wdrożenie bez wsparcia. Czasy gdy kupujący „sam sobie coś zrobił” raczej bezpowrotnie minęły. To co obserwuję, to migracja znacznej części usług z obszaru technologicznego (główny problem to instalacja i uruchomienie) do obszaru biznesowego (główny problem to zmiana organizacji jaką powoduje wdrożenie nowych narzędzi IT).
Na tym etapie pojawia się potrzeba poprzedzenia instalacji oprogramowania (wybór, zakup i wdrożenie) analizą i prognozowaniem (predykcją, przewidywaniem) skutków tego wdrożenia. Bardzo istotne jest, nie to czy produkt „zadziała” a to do czego planujemy go użyć i czy się sprawdzi.
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…
Swego czasu przewalała się w środowisku IT fala głosów za „certyfikacją zawodu informatyka”. Po pierwsze pojawił się kłopot z definicją kim jest ów „informatyk”, po drugie pojawił się kłopot z wykazaniem korzyści dla ogółu klientów, bo korzyść dla środowiska „informatyków” (co by to słowo nie miało tu oznaczać) jest prosta: ograniczenie dostępu do zawodu czyli jego monopolizacja. Zalety w rodzaju „podniesie się jakość usług” do mnie, i nie tylko do mnie, nie przemawiają. Nie wierzy w to nikt, kto ma w praktyce do czynienia z „certyfikowanymi” specjalnościami. Certyfikat (czyli po portu zdany test) to nic innego jak „wiem jak to robić” co nie ma nic wspólnego z „umiem to zrobić”. Każdy (prawie) wie jak się biega, jak się robi zdjęcia, jak się śpiewa, wie (w końcu uczą tego w szkole podstawowej i średniej) jak się pisze książki i wiersze, wie .… większość z nas wie jak siw robi większość tego co mamy wokół siebie, czy jednak potrafimy?
Certyfikaty itp. to w większości przypadków żadna gwarancja a nie raz wręcz odwrotnie.
Wdrożenie nowego oprogramowania, jeżeli ma mieć sens, powinno więc wspierać tworzenie dodatkowego zysku lub przychodu, w przeciwnym wypadku w zasadzie nie ma sensu. Innym powodem może być ratowanie posiadanego już przychodu czyli utrzymania się na rynku.
Dodatkowy zysk, to efekt obniżania kosztów. Ratowanie posiadanego rynku, to efekt reakcji na siły rynku: siły dostawcy (np. jego system EDI wymusza inwestycje u nas), siły odbiorcy (oczekuje obsługi podobnej do tej, jaką oferuje konkurencja), siły konkurencji (ich produkty i usługi są wyższej jakości, musimy też zainwestować).
Powyższy model obrazuje to co ma wpływ na to Dlaczego zarabiamy. Zbudowanie takiego modelu dla konkretnej firmy, zrozumienie Dlaczego zarabia, pozwala szukać sposobu i miejsc mogących przyczynić się do realizacji celu projektu, jednak cel ten należy wcześniej Nazwać. Drugi krok to ocena możliwości realizacji i prognozowanie skutków, by określić cel: miarę i wielkość tego co chcemy osiągnąć by wiedzieć czy się udało.
Podsumowanie
Model biznesowy moim zdanie nie odnosi się do procesów biznesowych, to procesy biznesowe są konsekwencją modelu biznesowego. Dlaczego? Bo jeśli przyjmiemy, że model biznesowy obrazuje (dokumentuje) źródła zysku firmy w łańcuchu wartości na rynku, to procesy biznesowe są opisem tego, w jaki sposób ta wartość wewnątrz firmy powstaje. To pozwala dopiero wskazać jakie działania (procesy) wesprzeć i jak, by „ulepszyć” firmę. Dlatego brak modelu biznesowego jest poważnym utrudnieniem analizy wymagań… bo czego wymagać od oprogramowania skoro nie wiemy co i jak pomoże w zarządzaniu firmą?
Wydaje mi się, że rynek na systemy ERP/CRM rośnie, jednak z mody na taki system (tu chyba faktycznie można mówić o nasyceniu) przechodzi w ocenę realnych potrzeb i biznesowej opłacalności (nadal mniej niż 80% ma taki system). Co maja pozostałe skoro wiemy, że „coś mają?”. Z moich doświadczeń wynika, ze mają „jakiś system FK/magazyny/sprzedaż” oraz bazy ad-hoc (np. Excel) lub po protu dużo ręcznej pracy. Czemu nie inwestują w ERP? Nie widzą powodu by wydać tak duże pieniądze choć czują, że dalej tak nie pociągną.
Jeżeli wierzyć innym badaniem, mówiącym, że w firmach dużych jest nasycenie, należy się skupić na firmach średnich i małych. Patrząc na wyniki oceny tworzonej wartości dodanej w każdej grupie (na pierwszym miejscu są firmy duże w udziałem 44%. Na drugim są firmy mikro ? 28%) oraz moim niedawnym wyliczeniem, że rozbudowany system tego typu na własność to inwestycja rzędu minimum 75 tys. zł, moim zdaniem można raczej mówić, że inwestycje poczynią firmy średnie. A mikro? Tworzą dużą wartość dodaną więc maja dochody, nie mają jednak możliwości zainwestowania aż 75 tys. zł. Co pozostało? Dzierżawa czyli SaaS. Prawdopodobnie jest to duży rynek (mikro firmy) dla usług dzierżawy oprogramowania o typowej wielości kontraktu 5 użytkowników/10GB danych. Te wielkości to coraz popularniejsze w USA oferty hostingowe/SaaS o wdzięcznej nazwie Lite.
