M arcin LEDWOROWSKI
Na wstępie postawmy do dyskusji na pół serio następujące w załączniku prawa dotyczące zakresu biznesowego systemu informatycznego, zapisane formalnie. Nazwijmy te prawa logiczną przestrzenią dom yślną systemów informatycznych, w skrócie led w o r. W dalszej części referatu będę ściśle opierał się na poniższych definicjach.
Siłą rzeczy, z racji aktualnego zajęcia Autora, niniejszy referat jest pisany z punktu widzenia Odbiorcy Systemu, „jednakże z zachowaniem praw Dostawcy należnych na podstawie odpowiednich UMÓW ”.
W praktyce oznacza to po prostu, że kreowanie aplikacji biznesowej to nieustanna sztuka kompromisów, zarówno po stronie zamawiającego jak i wykonawcy.
W popularnej historyjce obrazującej proces realizacji zamówienia najczęściej na końcu otrzymujemy system zupełnie inny od założonego. Jak więc zminimalizować szansę pomyłki ? Czy zamiast złożonego systemu Odbiorca będzie zadowolony z otrzymania fragmentarycznego obrazu systemu ? To zależy od podstawy na jakiej zbudowaliśmy system.
Zastanówmy się, co więc stanowi podstawę dla rozwiązania informatycznego ? Analiza strategiczna biznesu - czyli czy je s t coś co je s t „O K ” ?
Czy wizja firmy może być zapisana w postaci funkcji oprogramowania ? Zdecydowanie NIE.
No chyba, że mamy na myśli dużą ogólnoświatową firmę software-ową, której jedynym celem jest opanowanie produkcji wszelkiego oprogramowania.
Podobnie odpowiemy na pytania o strategię, cele strategiczne, których raczej nie zapiszemy wprost jako kolejnej opcji ... (Dla sceptyków: wyobraźmy sobie dużą salę, podczas prezentacji pierwszej wersji nowego systemu informatycznego prezes dużej firmy usługowo-produkcyjnej mówi :”A ten klawisz realizuje naszą strategię...”).
Zgodzimy się wszakże, że używając sformalizowanych metod budowania i
„pomiaru” stopnia realizacji strategii np. BSC (Balanced Scorecard - Strategiczna Karta Wyników) możemy za pom ocą odpowiednio skonstruowanego oprogramowania obiektywizować ocenę realizacji strategii firmy.
Wszystkie działania służące „zważeniu” wartości firmy, czy też „zmierzeniu”
osiągania celów strategicznych służą próbie obiektywizacji wartości firmy. Celem biznesu powinno być zwiększanie wartości firmy (co można podobno mierzyć - np. za pom ocą wskaźników EVA®). Rozwiązania informatyczne w firmie muszą służyć realizacji strategii i odpowiadać celom firmy. W praktyce wartość firmy może być określana przez księgowych, podczas transakcji sprzedaży firmy (np. na giełdzie) albo też przez rzeczoznawców. A dopiero transakcja sprzedaży części, bądź całości firmy ujaw nia jej realną wartość, aczkolwiek tzw. działania ukryte
(zaniżenie wartości przez zarządzających), bądź różnego rodzaje strategie fuzji lub przejęć mogą wartość firmy zniekształcić.
Firmę możemy także wyceniać wg wartości jej aktualnych przychodów oraz wg planów działalności w przyszłości. Biznes plan firmy jest zapisem planowanych operacji i uzyskiwanych z nich przychodów, a oprogramowanie tworzymy na bazie tego planu.
Biznes plan - łuski na oczach inwestorów...
Podstawą rozwiązani# informatycznego jest biznes plan firmy. Nie będzie dobrego biznes planu bez sprecyzowanej strategii firmy, bez określonej wizji i misji. Jeśli fundamenty się chwieją, trudno jest wybudować solidny dom. Konflikty dotyczące sensowności realizacji założonych operacji w firmie dotyczą niezrozumienia strategii albo niezrozumiałości strategii firmy. Trudno jest także zbudować kompletne rozwiązanie informatyczne dla nieznanych produktów. Jest to częsta bolączka polskich firm - działanie po omacku, z husarskim animuszem.
Biznes plany, które powstają w dłuższym okresie czasu podczas prowadzenia normalnej działalności firmy dezaktualizują się w okresie 2-3 miesięcy od chwili ich powstania.
Bardzo klarowna sytuacja występuje podczas tworzenia biznes planu od podstaw, dla zupełnie nowych przedsięwzięć. Nie trzeba zajmować się bowiem diagnozą organizacji, ani też ujmować jej aktualnego sposobu działania, prowadzić analiz bieżącej rentowności. W prawdzie sytuacja rynkowa również zmienia się dość szybko, jednakże nie będzie to wpływać na zaplanowane wielkości.
Najlepszym sposobem na weryfikację biznes planu jest jego zrealizowanie. Z zachowaniem zarówno zaplanowanych wydatków, uruchomienie w terminie i osiągnięcie sukcesu rynkowego w postaci przychodów i klientów zaplanowanych w szczegółach w części finansowej. Drugim równie skutecznym jest weryfikacja dokonywana przez inwestora. Jeśli uzna biznes plan za sensowny - pozwoli też na jego realizację.
Zasadniczo biznes plany opierają się o statyczne dane, z uwzględnieniem co najwyżej dwóch lub trzech scenariuszy (optymistyczne, realne, pesymistyczne).
Budowanie elastycznego planu, z dużą ilością parametrów jest bardzo mozolne i przeciąga moment skutecznego dotarcia do etapu analizy finansowej. Decyzja o zakończeniu symulacji jest zawsze trudna i powinna leżeć w rękach zarządzających. Wielu z nich zada natychmiast pytania z serii „ a co się stanie gdy?”. Dzięki elastycznej symulacji w biznes planie od razu odpowiemy na pytania o zmianę wyniku po redukcji zatrudnienia o 30%, o wprowadzenie upustu za płatność gotówką itd.
Tutaj pojawia się pytanie czy Dostawca powinien otrzymać biznes plan do wglądu ? Moim zdaniem - tak. Im lepsza wiedza Dostawcy o celach biznesowych tym i jego zrozumienie dla wymagań Odbiorcy będzie większe.
Na podstawie biznes planu z rozwiniętą częścią produktow ą z pomocą analityka powinniśmy napisać pierwszą specyfikację wymagań - czyli przejść do analizy wdrożeniowej.
Od tej chwili m ogą się rozpocząć znaczące różnice pomiędzy „kupowaniem”
systemów z półki a „dopasowywaniem” - lub „strojeniem” aplikacji do potrzeb użytkownika.
Jeszcze na studiach na pisemnym egzaminie z Techniki Komputerowej u dr inż. M ariana M olskiego w bydgoskiej ATR popełniłem gafę twierdząc, że
„strojenie” aplikacji jest terminem nieistniejącym, przynajmniej w znanej mi literaturze informatycznej. Pech chciał, że dr Molski był autorem tej nieznanej książki, w której „strojenie” zostało właśnie opisane... Minę miałem nieszczególną kiedy na korytarzu dowiedziałem się od kolegów w czyjej książce było to opisane.
Dr Molski okazał się jednak łaskawy i egzamin w sumie zdałem na czwórkę.
Analiza wdrożeniowa - czy dowiemy się wszystkiego ?
Idealną sytuacją dla Odbiorcy projektu jest zlecanie Dostawcy do wykonania zamkniętej specyfikacji aplikacji przy znanej i określonej specyfikacji technicznej. Dostawca ma wówczas największe szanse na dobre zaplanowanie projektu, terminy wykonania zadania i jego zasoby będą najlepiej określone, a sukces projektu jest prawie pewny. W praktyce takie sytuacje występują niezbyt często, zwykle dopiero podczas budowania kolejnych wersji systemów.
W większości przypadków Odbiorca posiada cele - określone w biznes planie, które zamierza zrealizować. Cele biznesowe, rzadko kiedy są także sprecyzowane ostatecznie.
Formułowanie celów biznesowych
Zupełnie inaczej właściciel czy zarządzający firm ą odbierze zadanie pod nazwą „uruchomienie sieci W AN” w porównaniu do „zapewnienie stałego dostępu do danych o sprzedaży w każdym punkcie obsługi klienta” albo „automatyzacja zamówień i zminimalizowanie stanu magazynowego we wszystkich sklepach do poziomu zapewniającego utrzymanie obrotów”. Informatycy, po krótkiej analizie odkryją niew ielką różnicę pomiędzy tak sformułowanymi zadaniami.
Często biznes plany zawierają całą stertę ogólników, pod płaszczykiem których następuje „sprzedawanie” tematów mocno technicznych, niezbędnych do realizacji spójnej wizji przedsięwzięcia.
Cel biznesowy pojedynczego „produktu” jest zawarty w jednym zdaniu.
Do tego może być dołączony krótki opis działania produktu z punktu widzenia klienta. Przykładowo właściwie sformułowane cele biznesowe do osiągnięcia w różnych firmach to np. :
„ możliwość comiesięcznego generowania telefonicznego billingu (szczegółowego zestawienia połączeń) dla klienta”,
»poprawa jakości obsługi klienta poprzez m.in. zwiększenie liczby obsłużonych połączeń do centrum telefonicznego” (instalacja cali centre),
»uruchomienie zdalnego dostępu do rachunku bankowego klientów instytucjonalnych” (home banking),
»uruchomienie dostępu do rachunku bankowego klientów indywidualnych przez Internet” ,
»oferowanie klientom o najwyższych dochodach indywidualnych warunków sprzedaży produktów przez osobistych account managerów” (CRM),
„bieżąca obsługa 0,5 min. klientów indywidualnych” (wielka baza danych),
„zwiększenie sprzedaży produktów poprzez pakietowanie elementarnych produktów i różnicowanie cenowe dla definiowalnych grup klientów”.
Każdy z podanych wyżej celów biznesowych wynika z chęci zwiększenia wartości firmy, polepszenia oferty produktowej firmy, poprawy jakości istniejących produktów.
Nie stawiajmy sobie celów biznesowych, które są wyłącznie projektami technicznymi - Zarząd i akcjonariusze „kupią” tematy wyłącznie biznesowo (politycznie) poprawne.
Specyfikacja wymagań
Specyfikacja wymagań powinna precyzować drogi i narzędzia do osiągnięcia celów biznesowych. Każdy produkt, który będzie realizowany czy obsługiwany przez system informatyczny powinien być opisany. W wielu przypadkach podczas tworzenia specyfikacji wymagań następuje samoograniczanie się Odbiorcy, ze względu na brak precyzyjnych definicji produktów biznesowych w firmie. Z uwagi na upływający czas Odbiorca godzi się także na „ograniczanie zakresu projektu” . Nie powinien jednak tego czynić wtedy, gdy godzi to w realizację pierwotnego celu biznesowego.
Z drugiej strony jeśli realizacja celu biznesowego jest zagrożona właśnie ze względu na upływający czas - to należy ograniczyć swoje życzenia.
Jak się okazuje często w wymaganiach Odbiorca pom ija niektóre bardzo ważne aspekty swoich potrzeb. Analitycy podczas swojej pracy docierają do większości potrzeb Odbiorcy, ale pewne obszary zostają podświadomie pominięte. Pominięcia wynikają z fałszywych przekonań Odbiorcy co do charakteru współpracy z Dostawcą, z przyzwyczajeń z dotychczas stosowanych systemów oraz z elementów nieznanych w chwili definiowania wymagań.
Przejście ze specyfikacji wymagań do specyfikacji aplikacji jest zadaniem dla projektantów i programistów. Dla Odbiorcy istotnym elem entem staje się wówczas możliwość jak najszybszego zweryfikowania swoich potrzeb na działającej aplikacji. Szybka ścieżka w tworzeniu aplikacji pozwala Odbiorcy zorientować się w koniecznej przebudowie procedur pracy. Zawęża to potrzeby Odbiorcy i klaruje ich wizję. Inwestowanie przez Dostawcę w narzędzia szybkiej budowy aplikacji sprzyja Odbiorcy. Oddala też widmo klęski... Chyba, że klęskę zaplanowaliśmy dużo wcześniej.
Plan projektu
Plan projektu przede wszystkim tworzymy w narzędziach pozwalających go szybko i sprawnie zmieniać. N a pewno będzie w nim dokonywanych dziesiątki poprawek, a podczas podpisywania aneksów z D ostaw cą jest to naprawdę niezbędne narzędzie. Dlaczego aneksy ? Na pewno będą..., bo nie słychać o dużych projektach w których nie było aneksów. Zadajmy sobie także w tym miejscu pytanie kiedy powinniśmy wykonać plan projektu ? Przed czy po podpisaniu Umowy ? Podobnie jak w przypadku specyfikacji - ideałem jest przygotowanie szczegółowego planu projektu i wdrożenia jako załącznika do Umowy. Upraszcza to zdecydowanie późniejsze postępowanie z Dostawcą, jednak może spowodować
znaczące usztywnianie się Dostawcy na zakres projektu. „Com napisał - napisałem powie Dostawca przy każdej próbie rozszerzenia zakresu projektu przez Odbiorcę. I z punktu widzenia Dostawcy — jest to zrozumiałe. Nikt nie będzie przecież w nieskończoność poprawiać baz danych, poprawiać kolejnych funkcji oprogramowania i inwestować raz zarobione pieniądze w „kolejną wersję”
systemu informatycznego.
Umowy
Analizując projekty znane z pierwszych stron polskich gazet dochodzimy do wniosku, że wielkie projekty cierpią na „manię wielkości”. Odbiorca chce zbudować „kompleksowy system”, całościowe rozwiązanie, Dostawca sprzedaje system „zintegrowany”. Przepisy dotyczące zamówień publicznych, jak i sposoby konstruowania zapytań ofertowych preferują jednokrotne określenie warunków przetargu (konkursu), jak i jednokrotne budżetowanie. Skuteczne budowanie systemów zintegrowanych powinno przebiegać wieloetapowo. Wydaje się, że skuteczniejsze jest podejście heurystyczne do aplikacji, z metodami kolejnych przybliżeń, gdyż otrzymujemy szybciej działające aplikacje i rozpoczynamy ich użytkowanie pomimo braków.
Powiększanie zakresu projektu wynika najczęściej z chęci określenia budżetu na całość zadania. Odbiorcy mają obawy, że ustalenie zadań dla Dostawcy tylko na I etap spowoduje zwiększenie wymagań finansowych Dostawcy w późniejszym okresie. Jak to mówią moi koledzy - Dostawca złapie za gardło i będzie ściskać (a im większy Dostawca tym ucisk silniejszy).
Negocjacje z Dostawcą przebiegają w duchu znanych z książek rozmów sprzedażowych. Negocjatorzy Dostawcy obiecują w rozmowie to i tamto, jednak jeśli ich obietnice nie znajdą się zapisane w Umowie (w załącznikach) to nie będzie to zrealizowane. Jednakże u Odbiorcy wrażenie „spełnienia życzeń”
pozostaje długo. W arto jest protokołować spotkania, gdyż pomoże to w późniejszym rozliczeniu z rzeczywistych i z pustych obietnic w porównaniu do zrealizowanych wymagań.
Wnioski
Duży projekt to duży problem. Kierownik dużego projektu systemu informatycznego musi posiadać wyjątkową odporność psychiczną oraz bezwzględne oparcie w swoich mocodawcach. Zmiany w założeniach i aneksy do umów z Dostawcą są nieuniknione. Skupiajmy się na dobrej realizacji każdego zadania, starając się je dokładnie od siebie oddzielać i minimalizować ich zakresy.
Dobrze przygotowana analiza skaże projekt na sukces. Bo czy stać nas na klęskę ?
ZAŁĄCZNIK - definicje przestrzeni ledwor®
Aksjomaty przestrzeni: wymagania, system inform atyczny, Dostawca, Odbiorca, funkcje systemu
Prawo „pierwszej wersji system u”
(i) Suma wymagań w dla systemu informatycznego jest zawsze większa od sumy wymagań zrealizowanych wz w systemie.
Prawo kompromisu Dostawcy i Odbiorcy
( w —> 0 0 ) A ( W Z — >
O )
^ W— =const ^
(2)Vwz j
Pomimo deklarowanego przez Dostawcę wzrostu liczby wymagań Odbiorcy w do nieskończoności oraz zauważanego przez Odbiorcę spadku zrealizowanych wymagań wz przez Dostawcę do zera rzeczywisty, końcowy stosunek w do wz będzie stały po zakończeniu projektu.
Prawo nadmiarowości aplikacji