Idee

a przynajmniej nie na tyle, na ile wiedzą to ci, dla których wiedza ta jest podstawą źródła utrzymania. I to jest jak najbardziej normalne. Ktoś, kto nie zna możliwości informatyki nie jest w stanie ocenić w czym faktycznie informatyka może mu pomóc.

Niestety Ci, którzy wiedzą — dostawcy usług informatycznych, wcale nie pomagają swoim klientom w doborze najwłaściwszych rozwiązań. Pytają zamawiającego, jak on sobie wyobraża swój nowy system, zapisują to co usłyszą i następnie opracowują modele, które mają na celu ułatwienie im zrozumienia dziedziny problemu oraz zweryfikowanie wymagań na okoliczność ewentualnych sprzeczności. Inni, można by powiedzieć bardziej doświadczeni, rozpoczynają od pytania o tzw. „rzeczywisty problem” swojego klienta, jaki chce on rozwiązać przy pomocy nowego systemu. Przedstawiciele zamawiającego nie potrafią jednak odpowiedzieć na wszystkie pytania informatyków, a ci ubolewają, że nie są pewni, czy aby o wszystko już zapytali. Byliby niezmiernie szczęśliwi, gdyby 100% wymagań mieli już na starcie.

Wiele firm IT, aby minimalizować ryzyko projektu, proponuje swoim klientom realizację usługi w sposób ewolucyjny, lub też – jak wolą to nazywać – iteracyjny. Jednak to na zamawiającym ciąży odpowiedzialność za dokładne wskazanie, które z wymagań są dla niego ważniejsze, a które mniej istotne. Nie jest to zadanie łatwe, mimo, że

a przecież tego nie wiedzą specjaliści z firmy informatycznej, która ma wyprodukować oprogramowanie — a przynajmniej nie na tyle, na ile wie to On sam.

Ktoś kto potrzebuje nowego systemu informatycznego ma swój katalog produktów lub usług oraz swój rynek zbytu i wie jak docierać do swoich klientów. Sprzedaje im swoje produkty lub usługi, zapewnia obsługę posprzedażną i coraz częściej patrzy na sukces w kategoriach ich zadowolenia.

Poszukując nowego systemu informatycznego wierzy, że dzięki zastosowaniu nowoczesnych środków IT będzie swoją pracę wykonywać lepiej, a to oznacza, że:

• szybciej [CZAS],

• taniej [BUDŻET],

• dokładniej [ZAKRES], oraz

• tak aby klienci byli jeszcze bardziej zadowoleni z otrzymywanych wartości.

Czasy, w których to, co zachodziło w przedsiębiorstwach „po prostu jakoś się działo” powoli odchodzą do historii. Coraz więcej firm myśli w kategoriach procesów i ma świadomość kosztów konkretnych, całościowych przedsięwzięć, a nie tylko wydatków ponoszonych przez poszczególne jednostki organizacyjne, bez względu na to, z czym te wydatki są związane. Dzięki normom ISO 9000:2000 takie podejście niebawem może okazać się powszechnie obowiązującym.

System informatyczny musi być elementem procesów biznesowych zamawiającego, jednak wewnętrzna organizacja tych procesów powinna być inna od tej sprzed wdrożenia SI.

Jeżeli zinformatyzujemy kroki aktualnego procesu, uzyskamy jedynie niewielkie korzyści wynikające z ich automatyzacji, a koszty inwestycji mogą nie mieć szansy na zwrot. Dzięki zastosowaniu nowoczesnych technologii informatycznych pewne dotychczas wykonywane akcje mogą być całkowicie wyeliminowane, lub zastąpione mniejszą liczbą ekwiwalentnych. Wiedząc co może zaoferować informatyka (to wiedzą informatycy) oraz mając w pamięci wartości jakie firma zamawiająca usługę IT chce dostarczać swoim klientom (to wie sam zamawiający) możemy stworzyć zupełnie nowy proces.

Ale zadania tego, nie zrealizuje żadna ze stron kontraktu samodzielnie.

Na początku dobrze jest mieć opis tego co już jest, tj. tego w jaki sposób zamawiający oprogramowanie dostarcza wartości (produkty i/lub usługi) swoim klientom obecnie. Dobrze jest też dysponować w miarę dokładną oceną kosztów związanych z dostarczaniem tych wartości.

Jeżeli zamawiający nie posiada tych opisów, należy poświęcić trochę czasu na ich przygotowanie, mimo, że może nie wydawać się to pracą bardzo ambitną.

Uzyskanie charakterystyki stanu obecnego rzeczywiście nie jest zadaniem bardzo skomplikowanym i twórczym, aczkolwiek wymaga pewnych zdolności analitycznych oraz umiejętności współpracy. Często bowiem bywa tak, że ludzie potrafią coś doskonale robić, ale nie są w stanie o tym opowiedzieć, lub też mylą to „co jest” z tym co „chcieli by aby było”.

Znajomość aktualnego procesu i jego faktycznych kosztów:

• unaoczni rzeczywiste wąskie gardła, ponieważ wyniki wyliczeń wcale nie muszą pokrywać się z odczuciami tych, którzy na co dzień odpowiadają za realizuję poszczególnych kroków procesu^[1], oraz

• pozwoli, po opracowaniu nowej wersji procesu, na dokładne wyliczenie korzyści, uzasadniających konieczność poniesienia wydatków związanych z wdrożeniem SI.

Sposobów opisu procesów biznesowych jest już wiele, jednak za najgodniejsze polecenia, z punku widzenia projektu IT, uważamy zastosowanie przypadków użycia^[2], metody, którą w następnych krokach polecalibyśmy, w formie niemal identycznej, dla specyfikowania wymagań funkcjonalnych na system.

Ocena kosztów procesu to nic innego jak coraz bardziej rozpowszechniona metoda ABC.

Kolejne posunięcie, to już sedno sprawy, konstruowanie nowego procesu. Niewątpliwie najlepszym podejściem, jakie można polecić, jest burza mózgów. Im bardziej zespół, złożony z informatyków oraz przedstawicieli tego, któremu wydaje się, że potrzebuje nowego SI, okaże się twórczy, tym lepsze rozwiązanie zostanie wypracowane. Razem z powstawaniem nowego procesu rodzić będzie się sukces przedsięwzięcia informatycznego. Informatycy uzyskają pełne zrozumienie problemu, a nie jedynie wiedzę o jego istocie. Zamawiający przestanie myśleć o informatykach, jak o przybyszach z innej planety.

Aby zestawienie procesów nowego i starego było łatwe, do opisu i szacunku kosztów proponowanego procesu należy zastosować te same metody, jakie zastosowano w przypadku analizy stanu obecnego.

Nowy proces wskazuje teraz, w których miejscach będzie potrzebny system informatyczny. W szczególności oznacza to, że określa zarazem przyszłych użytkowników tego SI, jak również ich cele – wartości jakich będą od niego oczekiwać.

Uzyskujemy zatem z ten sposób kompletny zbiór wymagań funkcjonalnych i to w dodatku od razu w postaci nadającej się na przypadki użycia systemu, bez konieczności powtarzania pytania: „co jeszcze system mógłby robić?”.

Następny krok należy do specjalistów IT zajmujących się tworzeniem oprogramowania, ponieważ to oni muszą określić przybliżone koszty implementacji i następnie użytkowania systemu. Zestawienie korzyści związanych z wdrożeniem danego wymagania (wynikających z porównania starego i nowego procesu), oraz kosztów implementacji tego wymagania (wynikających z szacunków przygotowanych przez informatyków) pozwoli na proste uporządkowanie wszystkich wymagań funkcjonalnych wg kryteriów ekonomicznych.

Taka lista stanowi podstawę planowania przedsięwzięcia. Faktyczna kolejność realizacji wymagań może być inna, niż ta wynikająca z rachunku ekonomicznego, ponieważ:

• z pewnymi wymaganiami mogą być związane trudne do wyrażenia w pieniądzu korzyści społeczne czy też prestiżowe,

• niektóre wymagania muszą być zrealizowane wcześniej niż inne (najpierw trzeba coś wpisać aby można było to później odczytać).

Niemniej jednak, i tak wydaje się być to dużo lepszym podejściem niż pytanie zamawiającego: „co jest najważniejsze?”.

Dalszą część przedsięwzięcia proponujemy prowadzić zgodnie z koncepcją, znaną wśród informatyków jako podejście „Use Case Driven”^[3], tj. tak, że zdefiniowane dla systemu przypadki użycia, stanowią podstawę dla każdego elementu procesu wytwórczego.

• Analiza i modelowanie procesów biznesowych powinny być elementami przedsięwzięcia, w wyniku którego ma powstać system informatyczny wspierający biznes.

• Zadanie to winno być realizowane wspólnym wysiłkiem specjalistów związanych z dziedziną problemu oraz specjalistów IT

Podejście takie gwarantuje:

• Stworzenie oprogramowania naprawdę przydatnego, a nie tylko takiego, które jedynie wydaje się, że może być potrzebne.

• Stworzenie systemu zawierającego mniej błędów. Systemy, które wspierają pracę komórek organizacyjnych, a nie procesów implementują masę funkcji, które w rzeczywistości nie mają dla nikogo znaczenia (powstały ponieważ komuś się wydawało, że się przydadzą). System wspierający proces będzie zawierał tylko to co jest konieczne, a zatem będzie mniejszy. Mniejszy system, to mniej błędów.

• Stworzenie systemu, w którym niczego nie zabraknie. Wymagania wynikają wprost z opisu procesu biznesowego, a nie z przypuszczeń, o których łatwo zapomnieć.

• Odpowiada informatykom na pytania skąd się biorą przypadki użycia systemu oraz w jakiej kolejności należy implementować wymagania.

Wydaje się, że nie dość wystarczająco. Firmy produkujące oprogramowanie na zamówienie chcą przede wszystkim programować i niechętnie zapatrują się na branie odpowiedzialności za przydatność ich produktów zamawiającemu. Zależy im na jak największych zamówieniach, zatem korzystają z tego, że zamawiający chcą mieć „coś”, ale nie przeprowadzają dogłębnych analiz przydatności i opłacalności „tego czegoś”. Często nawet starają się wmówić swoim zamawiającym, że warto by zaimplementować jeszcze więcej funkcji, bo zrobienie tego teraz będzie kosztować mniej niż dorobienie w przyszłości. Cóż z tego, że zamawiającemu te funkcje nigdy nie będą do niczego potrzebne.

Skupienie uwagi na procesach biznesowych, może spowodować, że zapotrzebowanie będzie opiewać jedynie na fragment pełnej funkcjonalności systemu, jaka mogłaby zostać zamówiona, gdyby wymagania na system były gromadzone w tradycyjny sposób. W skrajnych przypadkach może się okazać, że system informatyczny nie będzie w ogóle potrzebny – a przecież producenci oprogramowania zarabiają właśnie na produkowaniu systemów informatycznych.

Firmy IT przejawiają jeszcze jedną istotną ułomność — przeważnie lansują własne rozwiązania, nawet jeśli wiedzą, że oprogramowanie, które zamawia ich klient jest już produkowane przez inną firmę IT. Cieszą się, że klient tego nie odkrył. Niejednokrotnie dużo szybciej i taniej można stworzyć to, co jest potrzebne zamawiającemu, poprzez złożenie i powiązanie kilku już gotowych i dostępnych na rynku produktów.