Idee
Przykład analizy interesariuszy przedsięwzięcia informatycznego
Abstrakt
Kontynuacja upowszechnienia idei homologacji i przykład analizy interesariuszy. Materiał został opublikowany w: Informatyka i administracja, Polskie Towarzystwo Informatyczne, red. Józef Oleński, Grzegorz Bliźniuk, Jerzy S. Nowak, Katowice 2005, ISBN 83-922624-4-1.
Czy koszt pozyskania oprogramowania dedykowanego oraz związane z tym ryzyko dla strony zamawiającej mogą być niższe? Na to pytanie, w odniesieniu do systemów na potrzeby administracji publicznej, udzielałem odpowiedzi twierdzącej już dwukrotnie, wskazując na potencjał drzemiący w idei homologacji systemów informatycznych [Ganowski2004a], [Ganowski2005].
Tylko raz, jak dotychczas, zetknąłem się z publikacją polemiczną [Rutkowski2005], która notabene ukazała się w tym samym wydaniu tygodnika COMPUTERWORLD, w którym obwieściłem „koniec dyktatury producentów oprogramowania”. Publikacja ta nie mogła więc odnieść się do mojej wypowiedzi, z którą sąsiadowała, a treść tego materiału nie wskazywała również na to, aby jej autor był zaznajomiony z moim pierwszym artykułem, w którym sporo uwagi poświęciłem analizie porównawczej różnych metod pozyskiwania oprogramowania oraz analizie SWOT samej homologacji SI.
Jedną z tez, mających zniechęcić zamawiających do stosowania homologacji systemów informatycznych, ma być rzekoma niezgodność tej idei z aktualnym prawodawstwem Unii Europejskiej, czyniąc z niej proceder wręcz nielegalny. Nie mogę się zgodzić z tą wypowiedzią podwójnie. Po pierwsze dlatego, że wg mnie, autor mówił o zupełnie innym zagadnieniu, niż to które ja poruszam — być może mając na celu jedynie przyczepienie etykietki ostrzegawczej, jaka niejednokrotnie może być wystarczającym środkiem odstraszającym dla tych, którzy nie mają czasu na zgłębianie podstaw nieznanych im dotychczas koncepcji lub tych którzy mają wątpliwości[1]. Powód drugi, dla którego zmuszony jestem wyrazić swój sprzeciw, związany jest z hipotezą owej niezgodności. Nawet, gdyby tak było, że homologacja systemów informatycznych jest wbrew jakimś wytycznym UE, to uważam, że należałoby się jeszcze raz dokładnie tym wytycznym przyjrzeć, badając również motywy jakimi kierowali się ich wnioskodawcy. Złe, a nawet głupie prawo powinno być znoszone, a nie za wszelką cenę przestrzegane.
„Homologacja systemów informatycznych jest sposobem nabywania oprogramowania dedykowanego na zasadach rynkowych” [Ganowski2004a] (s. 130) i trudno jest mi sobie wyobrazić, żeby Unia Europejska, jako taka, a nie poszczególne, reprezentowane w niej frakcje, otwarcie występowała przeciwko wolnemu rynkowi. Główną zaletą homologacji SI jest zezwolenie adresatom aplikacji na wybór spośród wielu konkurujących ze sobą, gotowych już produktów, zbliżając proces nabywania oprogramowania do tego, jaki jest realizowany w przypadku pozyskiwania programów „z półki”. Systemy „z półki” są jednak programami ogólnego zastosowania i nie spełniają wymagań specyficznych, jakie przywykło się wypełniać realizując projekty własnymi siłami, outsourceując przedsięwzięcia lub ewentualnie wchodząc w układy partnerstwa publiczno-prywatnego. Konieczność rywalizowania o względy klientów zmusza producentów do stałego dbania o jakość produktu i usługi (w tym czas reakcji) oraz nie pozostaje bez wpływu na cenę. To nie jest „duch przeszłości”, chyba, że za symbol przyszłości przyjmiemy strach przed polskim hydraulikiem we Francji, A.D. 2005.
W moim drugim artykule zachęcającym do stosowania mechanizmów homologacji systemów informatycznych [Ganowski2005] podkreśliłem szczególnie ważny wg mnie aspekt tego zagadnienia, tj. szansę na ucieczkę zamawiających przed masochistycznym oddawaniem się w ręce monopoli, jakimi oferenci stają się w chwili namaszczenia ich do roli jedynych słusznych producentów. Tak jest i być musi, nawet mimo szczerej woli uczciwego świadczenia usługi proponowanej w treści oferty. W sytuacjach kryzysowych, jakich wcale nie mało, gdy mamy do czynienia z projektami, z definicji związanymi z niepewnością[2], trudno nie skorzystać z siły przetargowej, jaką się dysponuje. A w przedsięwzięciach outsourceowanych taką siłą zamawiający po prostu obdarowują swoich usługodawców.
W przypadku homologacji SI oczywiście też możemy mieć do czynienia z monopolem, tak jak ze zjawiskiem tym stykamy się w przypadku programów „z półki”. Nie tak znowu dawno temu, ten kto zastanawiał się nad wykorzystaniem arkusza kalkulacyjnego, w zasadzie był skazany na program Excel, gdyż o konkurencji, takiej jak Lotus 123, Quattro Pro, czy tym bardziej VisiCalc pamiętali już tylko historycy branży IT. Dziś twórcy Excel’a zaczynają się obawiać programu OpenOffice.org Calc i dzieje się to dzięki istnieniu wolnego rynku dla produktów. Oczywiście, dla dobra klientów, ale również, w dłuższym okresie, dla dobra producenta, który zdominował rynek, ponieważ „[i]stnieje również górna granica pozycji rynkowej, którą nierozsądnie jest przekraczać – nawet jeśli nie zabrania tego prawo antymonopolowe. …” [Drucker2002] (s. 59).
Niniejszy artykuł ma dwa cele. Pierwszym z nich, jest kontynuacja upowszechnienia idei homologacji systemów informatycznych, jako najlepszej metody pozyskania oprogramowania dedykowanego, w przypadkach gdy istnieje odpowiednio duży rynek nabywców[3]. Cel drugi, to przedstawienie przykładu analizy interesariuszy przedsięwzięcia informatycznego, a to znaczy czegoś, co powinno towarzyszyć każdemu projektowi informatycznemu i co powinno być na bieżąco aktualizowane, ponieważ ma ogromny wpływ na zwiększenie szans powodzenia przedsięwzięcia.
„Interesariusz” to termin w naszym języku nowy, którego nie znalazłem jeszcze w żadnym słowniku języka polskiego, ale który, jako tłumaczenie terminu stakeholder, wkradł się już do słownika angielsko-polskiego. I w tym charakterze jest on coraz częściej stosowany przez autorów, na łamach prasy fachowej. Cóż więc, czy mi się to podoba, czy nie, nabieram przekonania, że się przyjmie i być może również ten artykuł będzie miał w tym swój udział[4]. Interesariuszami nazywam wszystkich tych, którym może zależeć na sukcesie projektu, lub wręcz przeciwnie, którzy woleliby, aby projekt legł w gruzach, skoro w ogóle musiał zaistnieć. A zatem, są to wszyscy ci, którzy mogą coś zyskać bądź stracić, zarówno w trakcie trwania przedsięwzięcia, jak i w wyniku wdrożenia jego efektów.
Rzecz jasna, interesariuszami są przyszli użytkownicy nowych aplikacji. Tyle, że jakkolwiek bardzo istotni, to nawet nie w czołówce tych najważniejszych. Jeżeli dziś są oni uczestnikami procesów swojej organizacji, to jutro, po wdrożeniu nowego systemu mogą być zmuszeni do wypełniania swoich obowiązków w sposób odmienny od dotychczasowego, a może się okazać, że w nowych procesach zabraknie już dla nich miejsca, w ogóle. Czy komuś mogłoby na takim obrocie sprawy zależeć? Pewnie najmniej, właśnie tym, pracownikom na pierwszej linii frontu. Oczywiście wcale tak być nie musi, że od razu mają być oni postawieni na straconej pozycji, a co więcej, najczęściej wiele zyskują dzięki nowej organizacji pracy. Niemniej jednak, to naturalne, że powinni (chcieć) mieć wpływ na swoją przyszłość i brać aktywny udział w formułowaniu wymagań na nowy system informatyczny, ale dokument projektowy, często określany nazwą „Wymagania Użytkownika”, w tzw. projekcie informatycznym, nie powinien w ogóle powstawać. UWAGA! Nie chciałbym być tutaj źle zrozumiany, bo wymagania na system to bez wątpienia niezmiernie istotna rzecz[5]. Chodzi mi jednak o to, że pytanie przyszłych użytkowników – jedynie, lub przede wszystkim – o to jak sobie wyobrażają swoją nową pracę, z wykorzystaniem nowego programu komputerowego, bardzo rzadko prowadzi do całościowej optymalizacji procesów biznesowych. Znacznie częściej uzyskujemy w ten sposób zbiór pomysłów na optymalizacje lokalne, skutkujące minimalną korzyścią całościową, która najczęściej nie uzasadnia ponoszenia kosztów. A może się okazać i tak, że optymalizacje lokalne dadzą w wyniku globalne pogorszenie [Ganowski2004b].
W gruncie rzeczy, nawet nie powinniśmy myśleć o czymś takim jak projekty informatyczne i właśnie dlatego w poprzednim akapicie pozwoliłem sobie na użycie określenia „tzw. projekt informatyczny”. Nie o informatyzację powinno przecież organizacjom chodzić, a o podnoszenie efektywności funkcjonowania, a to z kolei oznacza, że o optymalizację dostarczania wartości klientom. Tak się składa, że do środków, które umożliwiają dziś istnienie procesów w wersjach najdoskonalszych należą też narzędzia IT, ale nie zmienia to faktu, że informatyka nie powinna stawać się celem samym w sobie. A zatem, z punktu widzenia organizacji, która chce lepiej działać, projekty powinny być nie informatyczne a biznesowe[6].
Gdyby przyjąć, że wszystkie organizacje uwierzyły już, iż najważniejszą rzeczą w ich życiu jest orientacja na klienta, to właśnie klient powinien być najbardziej zadowolonym interesariuszem przedsięwzięcia wprowadzającego ulepszenia procesów, w tym nowe rozwiązania informatyczne. Z drugiej jednak strony, nikt przecież nie będzie starał się zadowolić klienta za wszelką cenę, ponieważ zadowolenie takie musi się przekładać na akceptowalny zwrot z inwestycji, tym którzy wykładają swoje środki. W przypadku administracji publicznej tańsza obsługa jej klientów, to możliwość pomocy większej grupie osób lub lepsze zaadresowanie funduszy, pochodzących nie skądinąd jak tylko z podatków.
Zatem, przystępując do analizy potrzeb organizacji, w ramach projektu, który ma w efekcie przynieść usprawnienie jej funkcjonowania, pochylamy się nad wszystkimi, których nasze prace mogą w jakikolwiek sposób dotyczyć, bo jest to niezmiernie istotne zadanie, którego pominięcie może skierować przedsięwzięcie na złe tory, niemal każde i niemal od razu. I jest kilka powodów, dla których tak się dzieje. Po pierwsze, dlatego, że bez tej chwili refleksji, przychodzi nam najczęściej ochota na wprowadzanie ulepszeń służących nie tym, którzy mają największe znaczenie, a tym, którzy potrafią najgłośniej krzyczeć i mają najłatwiejszy dostęp do kanałów umożliwiających głoszenie swoich poglądów. Po drugie, dobrze jest wiedzieć, kto może być naszym potencjalnym sojusznikiem, a kto najprawdopodobniej ustawi się w opozycji. Co ciekawe, choć wcale nie takie dziwne, jedna osoba może wcielać się w danej chwili w wiele ról. A zatem może być jednocześnie i przeciwnikiem i zwolennikiem, i sojusznikiem i wrogiem. Warto jednak pamiętać: jeżeli projekty nie udają się, to głównie z przyczyn leżących po stronie ludzi, a dokładniej ich nastawienia do tego co i jak ma być wykonane, a nierzadko również przez kogo.
W przypadku homologacji systemów informatycznych w administracji publicznej mamy do czynienia z kilkoma interesariuszami i są to:
Klienci jednostek organizacyjnych, których procesy są wspierane przez homologowane oprogramowanie,
Adresaci systemów, tj. ci którzy korzystają z nich w sposób bezpośredni oraz ci, którzy są odpowiedzialni za sprawne dostarczanie wartości klientom,
Zamawiający, którzy są zobowiązani do wprowadzania i rozwijania systemów informatycznych w jednostkach organizacyjnych, do których aplikacje są adresowane,
Przedsiębiorcy – dostawcy oprogramowania, którzy produkują aplikacje komputerowe, aby utrzymać się przy życiu i rozwijać,
Podatnicy, czyli ci, których pieniądze są wykorzystywane na finansowanie produktów.
Dalszą część artykułu poświęcę dokładniejszemu omówieniu tych grup.
Osoba, która stawia się w urzędzie aby załatwić swoją sprawę, gdyby ją zapytać o zdanie, który ze sposobów nabywania oprogramowania przez administrację publiczną jest lepszy, pewnie odpowiedziałaby coś w takim rodzaju: „Panie, a czy ja nie mam lepszych rzeczy do robienia niż zastanawianie się nad takimi głupotami. Mam gdzieś to u kogo kupują swoje programy i w ogóle mam gdzieś te ich komputery. Ja chce stąd jak najszybciej wyjść, i to z tym po co przyszedłem. Dla mnie mogą i na papierze robić, o ile tylko załatwią to, o co mi chodzi. A czy ja to dla przyjemności tu przychodzę?”. I chyba nie byłoby się czemu dziwić. Być może osoba ta wspomniałaby jeszcze coś o tym, że „tylko marnują nasze pieniądze, które lepiej byłoby przeznaczyć na to czy owo”, ale w tej wypowiedzi występowała by już w roli finansującego, więc tutaj tę kwestię pominę.
Klient chce być szybko i miło obsłużony. Jak mu się już coś takiego przytrafi, to nawet tego nie zauważy, ale to, że musi czekać w kolejkach, a później urzędnik jeszcze się nad nim pastwi, pamięta długo i wszystkim opowiada.
Szybkość i profesjonalność obsługi zależy dziś również od tego jakich urzędnicy używają systemów informatycznych. Jeżeli urzędnik wie, że program został wybrany, co więcej przy jego współudziale, spośród puli dostępnych na rynku programów oferujących te same funkcje, będzie do tego programu zupełnie inaczej podchodził niż do systemu, który został narzucony z góry. Jeżeli coś w jego programie będzie działało nie tak jak powinno, łatwo będzie mu uzyskać poprawkę. A wszystko to dzięki konkurencyjnemu rynkowi gotowych produktów. Jeśli producent nie będzie nadążał za wymaganiami rynku, zostanie po prostu wyeliminowany z gry. Nawet jeśli będzie posiadał certyfikat homologacji. Wymagania homologacyjne zawsze będą określały tylko minimum pożądanych cech aplikacji i w żaden sposób nie da się w nich określić jednoznacznie „przyjemności w użytkowaniu” i „przyjazności w kontaktach międzyludzkich użytkownika z reprezentantem producenta”.
Użytkownika irytuje to, że nie może wydusić z programu rzeczy, jakie zostały mu przyrzeczone, ale bardziej bezsilny czuje się, gdy nie jest w stanie uzyskać poprawki, która ulepszyłaby jego pracę. Urzędnik-użytkownik wszystkie swoje frustracje przynosi później na klientów, traktując ich dokładnie tak samo jak producent systemu, monopolista wyłoniony w plebiscycie na najlepsze obiecanki, traktuje zamawiającego. To bardzo trudne, nie przenosić problemów związanych z jednym zagadnieniem na inne aspekty życia. Ja tego nie potrafię i nie znam nikogo, kto by się tego całkowicie wystrzegał.
Klient urzędu w odniesieniu do zagadnienia homologacji będzie więc nieświadomym sojusznikiem.
Adresaci oprogramowania, to oczywiście jego użytkownicy końcowi, ci którzy niszczą sobie wzrok przy komputerach wpatrując się w to co zostało dla nich zamówione przez zamawiającego i wykonane przez producenta. Są wśród nich zarówno tacy, którzy stykają się z klientami urzędu jak i ci, którzy dla klientów pozostaną na zawsze anonimowi, realizując swoje zadania gdzieś w tle. Wszyscy oni są bardzo ważni, a wydajność ich pracy, a zatem ich zadowolenie, przekładające się na zadowolenie klientów, zależy od jakości wykorzystywanych programów (oczywiście między innymi). Oni powinni cieszyć się z możliwości wyboru, a zatem z homologacji.
Adresatami oprogramowania są jednak również te osoby, które nie korzystają z nich w sposób bezpośredni, wypełniając funkcje kierownicze - właścicieli procesów, w wyniku których dostarczane są wartości klientom organizacji. To oni będą obarczeni odpowiedzialnością za dokonanie wyboru, jeśli taki wybór zostanie im umożliwiony. Nawet jeśli załatwią tę sprawę delegując ją swoim podwładnym.
Stosunek decydentów do zagadnienia homologacji będzie zależał od ich charakteru. Ci spośród nich, którzy wierzą w idee samorządności, zapewne też pochwalą idee homologacji. Pewnie sprawdzą czy to im się będzie opłacało, ale z pewnością nie będą negować, że tam gdzie jest wybór, tam gdzie jest konkurencyjny rynek produktów, tam generalnie jest lepiej. Do tej grupy zaliczą się też tacy, którzy już wcześniej dokonali swoich wyborów, zanim powstała inicjatywa spójnego systemu obsługi klientów. Jeśli są zadowoleni z tego co mają, nie będą chcieli godzić się na nowe rozwiązania narzucone z góry. Jeśli nie będą zadowoleni, zapewne woleliby zostać przy swoim (a więc wybrać), przynajmniej do czasu aż rzeczywiście okaże się, że rozwiązania alternatywne są godniejsze uwagi. W końcu lepszy wróbel w garści niż gołąb na dachu.
Jeżeli któryś z lokalnych decydentów znalazł się na swoim miejscu jedynie przez przypadek, to homologacja może byś dla niej / niego nie byle jakim problemem. Homologacja to możliwość wyboru, a wybór to konieczność podejmowania decyzji. Czasem lepiej jest, gdy decyzję musi podjąć ktoś za mnie. Wtedy mogę protestować, że nie zostałem dopuszczony do głosu. Wtedy mogę też wylewać swoje żale, że coś tam nie jest tak, tylko dlatego, że ktoś poza moimi plecami tak to zaprogramował.
Zamawiający to ten, który z jakichś powodów jest zobowiązany do „wprowadzania i rozwijania systemów (tele)informatycznych zapewniających spójny system obsługi” klientów jednostek organizacyjnych, do których oprogramowanie jest adresowane. Fragment ujęty w poprzednim zdaniu w cudzysłowy jest tekstem wyjętym wprost z ustawy o promocji zatrudnienia i instytucjach rynku pracy, w formie pierwotnej i z przedrostkiem „tele-”, w formie zmienionej, proponowanej przez ustawę o informatyzacji działalności podmiotów realizujących zadania publiczne. Ustawa jest pewnie głównym powodem, dla którego zamawiający staje się zamawiającym, aczkolwiek można by sobie wyobrazić również i inne przyczyny.
Z zamawiającym też, sprawa bycia za lub przeciw nie jest taka oczywista. W sytuacji z jaką mamy do czynienia w przypadkach ministerstw Gospodarki i Pracy oraz Polityki Społecznej głównym zamawiającym jest sam minister. Działa on w imieniu finansujących (podatników), na rzecz klientów urzędów i adresatów oprogramowania. Nie może działać wbrew nim, choć oczywiście może się nie zgadzać z tym co mówią i może próbować przekonywać do swoich racji. Notabene właśnie minister powinien być głównym odbiorcą analizy grup (ścierających się) interesów. Póki co, nie widzę powodów, dla których ten szczebel decyzyjności mógłby uważać, że tradycyjny przetarg jest lepszy od homologacji (oczywiście tam gdzie homologację da się zastosować). Trudno też o bardziej symboliczną wymowę popierania homologacji, niż ma to miejsce w przypadku Ministerstwa Gospodarki i Pracy. Homologacja, o czym będzie mowa dalej, daje szanse małym i średnim przedsiębiorstwom.
Minister jednak sam nie będzie homologował żadnego programu. Zobaczmy zatem, co mogą myśleć o tym zagadnieniu osoby, które będą zaangażowane w cykl życia oprogramowania homologowanego, po stronie zamawiającego?
Homologacja systemów informatycznych będzie od nich niewątpliwie wymagać więcej wysiłku. Przed moimi oczami ukazały się teraz liczne smutne twarze. Cóż, niestety nie ma nic za darmo. Czym większa liczba graczy ujawni się na rynku, tym większej liczbie graczy trzeba będzie tłumaczyć co się miało na myśli zapisując wymagania i tym więcej będzie produktów do przetestowania. Łatwo więc będzie w takiej sytuacji powiedzieć: „w naszym przypadku, to się na pewno nie uda, przede wszystkim dlatego, że mamy zbyt mało etatów, a poza tym prawo leżące u podstaw naszych systemów tak szybko się zmienia”. Można by długo udowadniać, że tego typu argumenty nie zawsze mają rację bytu a i tak tych, którzy nie chcą być przekonani przekonać się nie da. Tym bardziej, że nie istnieje żadna metoda formalna, która pozwalałaby wyliczyć, kiedy homologacja jest możliwa do zastosowania, a kiedy można o niej zapomnieć[7]. Warto zwrócić jednak uwagę na fakt, że homologacja niektórym już się udaje, a więc istnieją namacalne dowody. W przypadku SI wspierającego proces realizacji świadczeń rodzinnych do walki stanęło 11 firm i każda z nich, ma już swój gotowy produkt.
Rzeczą, która może zachęcić sceptycznie nastawionych do homologacji, poza tym, że homologacja jest lepsza dla klientów urzędów, adresatów oprogramowania, głównego zamawiającego, finansujących i części producentów, jest to, że z procesem homologacji związanych jest mniej przepychanek wymagających wysiłku psychicznego. Żaden z producentów nie może już stawiać zamawiającego pod ścianą, teraz liczą się już tylko produkty i ich percepcja.
Producent oprogramowania to ten, który jak sama nazwa wskazuje musi pożądane aplikacje komputerowe wyprodukować, ale w przypadku systemów dedykowanych, wytwarzanych na zamówienie, również wdrożyć. Celem producenta jest możliwie najwyższy zwrot z inwestycji. Oto więc, na co producent musi łożyć:
zakup czasu specjalistów, których rękoma ma zadanie zrealizować,
koszt ich ewentualnego doszkolenia,
koszt niezbędnych narzędzi (komputery, programy wspomagające proces wytwórczy oprogramowania),
utrzymanie biura (przestrzeń do pracy, meble i inne elementy wyposażenia, prąd, papier i inne materiały eksploatacyjne)
oraz, co często stanowi niebagatelną składową:
koszt sprzedaży lub też pozyskania projektu (jak również koszty poniesione na sprzedaż, która okazała się chybiona).
W dwóch przypadkach: 1) realizacji kontaktów, w ramach których powstają systemy i 2) sprzedaży gotowych produktów, poszczególne nakłady mogą się znacznie różnić. Jest to związane z poziomem pewności (wiary w to), że zainwestowane środki się zwrócą. W przypadku pierwszym mamy do czynienia raczej z pewnością, w przypadku drugim bliżej jest do wiary. Tak się jednak składa, że szanse na pozyskanie przedsięwzięcia mają tylko niektórzy, a spośród nich wygranymi okazują się zazwyczaj ci, którzy są w stanie więcej naobiecywać i lepiej uzasadnić swoje obiecanki[8]. Właśnie ten punkt odniesienia pozwoli mi dokonać rozróżnienia między dużymi i małymi, którzy wydaje się, powinni mieć różne spojrzenia na homologację SI w administracji publicznej. Podział taki jest tworzony przez zamawiającego w chwili publikacji dokumentu SIWZ i nie ma charakteru stałego zaszufladkowania. Jeden SIWZ może zawierać takie sformułowania, które wykluczają daną firmę, klasyfikując ją do małych, inny, w tym samym czasie, dając szansę tej firmie, zaliczy ją do dużych.
Duzi nie mają powodów do tego aby lubić homologację. Jeśli jest szansa na to aby zostać monopolistą, trzeba tę szansę wykorzystać. A wygrana w przetargu daje gwarancje monopolu. Homologacja oferując wszystkim producentom te same szanse, zmusza do wykonania na prawdę dobrego oprogramowania i stałego dbania o jego konkurencyjność. Być wyrzuconym, nawet przez bardzo niezadowolonego klienta, dla którego realizuje się projekt nie jest tak łatwo. Być wyrzuconym przez rynek odbiorców, którzy czują się zawiedzeni i którzy mają alternatywę szybkiego przejścia na rozwiązanie przynajmniej ekwiwalentne, to już zupełnie inna sprawa.
Duzi nie mają monopolu na mądrość, bo nikt takiego monopolu nie posiada. Często jednak są o wiele mniej sprawni od swoich małych konkurentów. Właśnie dlatego chcą mieć pewność, już na starcie, że programy które stworzą zostaną od nich kupione. Pamiętam, parę lat temu redaktor Marek Ostrowski, w programie „7 dni świat” wypowiadał się na temat różnic pomiędzy monarchią a demokracją. Nie odtworzę tej wypowiedzi słowo w słowo, ale sens jej utkwił mi dobrze w pamięci i wydaje się, że oddaje też ona doskonale różnice pomiędzy funkcjonowaniem dużych i małych producentów oprogramowania. Oto ta wypowiedź, po przystosowaniu do moich potrzeb: Duży producent jest jak okręt liniowy, który potrzebuje kilku mil morskich na to aby zawrócić z obranego kierunku, a jak zostanie trafiony torpedą, tonie pociągając za sobą setki ofiar. Mały producent jest jak tratwa, na której płynie się, być może i z tyłkiem zanurzonym w wodzie, ale za to ciągle w dobrym kierunku, bo zwrot można wykonać niemalże w miejscu. A i trafić w niego trudniej. Oczywiście, jestem też w stanie wyobrazić sobie sytuację, w której okręt liniowy uderza w tratwę…
Dla małych homologacja jest szansą na stanie się dużymi. Kto by nie chciał wyeliminować swoich konkurentów na drodze administracyjnego odebrania im szansy konkurowania. Ale jak mały ma udowodnić że jest dobry, skoro jemu szansy nikt nie chce dać? Dla małego jest więc szansą wykonanie świetnego produktu i właśnie w ten sposób udowodnienie światu, że i on coś potrafi. Mały wie, że jest w stanie wykonać swoją pracę szybciej i taniej od dużego, bo to cechą małych jest otwartość na innowacje i to mali nie pakują pieniędzy w biurokratyczne nadbudówki[9].
Tak naprawdę homologacja może być korzystna i dla dużych, jeśli zostaną już w nią wepchnięci. Nastawiając się na wygrane w przetargach, a więc pozyskiwanie kontraktów na przedsięwzięcia, inwestują głównie w handlowców. Homologacja jest dla nich doskonałą okazją do faktycznego sprawdzenia się w produkcji i podjęcia ewentualnych kroków usprawniających. Po cóż producentowi ISO czy kolejny poziom CMM, oczywiście poza marketingiem, jeśli nie jest w stanie stwierdzić doświadczanie, że rzeczywiście może dostarczać lepsze oprogramowanie, taniej i szybciej.
To ja, ale nie jestem sam. Jest nas parę milionów, nie wiem dokładnie ile, ale precyzja nie ma tutaj żadnego znaczenia. Wszyscy, którzy płacimy podatki finansujemy działania administracji publicznej i pewnie większość z nas wolałaby środki przekazywane do urzędów skarbowych zachować przy sobie. A może tu jestem jakiś inny?
Oprogramowanie homologowane jest dla administracji publicznej tańsze. Wykonawcy liczą na zysk, ale minimum jakie zakładają że osiągną, to zwrot kosztów zainwestowanych w wytworzenie i sprzedaż swoich produktów. W związku z tym, że inwestycja leży właśnie po ich stronie, zapewne będą oglądać każdą złotówkę – a tak z pewnością nie czynią, kiedy stroną finansującą przedsięwzięcie jest zamawiający. Oczywiście kiedy zamawiający finansuje powstanie potrzebnego produktu, to on ogląda każdy grosz, jednak zazwyczaj nie ma żadnych racjonalnych podstaw do uważania, że coś powinno być tańsze. Pozostaje mu wróżenie z fusów, albo nadstawianie ucha na podszepty tych, którzy nie wygrali tradycyjnego przetargu na outsourcing projektu. I ponoszenie wydatków na wielostopniową weryfikację. Ceną steruje rynek[10].
Homologacja systemów informatycznych z pewnością nie jest doskonałą metodą pozyskiwania oprogramowania dedykowanego, ale w przypadku istnienia „odpowiednio dużego”[11] rynku odbiorców, nikt jeszcze nie wymyślił nic lepszego – tak mógłbym jeszcze raz nawiązać do idei demokracji, parafrazując stare na jej temat powiedzenie.
Każde działanie o charakterze projektowym powinno rozpoczynać się od analizy interesów interesariuszy[12] (często nawet przez nich głęboko skrywanych), ponieważ sukces przedsięwzięcia zależy od woli ludzi, którą implikuje ich percepcja zagrożenia, bądź szansy na poprawę warunków życia.
Idea homologacji systemów informatycznych w administracji publicznej ma swoich przeciwników, ale może mieć również swoich zwolenników i właśnie to starałem się pokazać w niniejszym artykule. Ci drudzy, jak się wydaje, mają w swych rękach silniejsze argumenty (taniej, szybciej, lepiej), ale to ci pierwsi mają lepsze możliwości wypowiadania się. Analiza interesariuszy pokazuje, że homologacja systemów informatycznych powinna być brana pod uwagę każdorazowo, gdy zamawiający ma zapewnić oprogramowanie dużej grupie adresatów. Z analizy interesariuszy wynika też to, czyich kłód rzucanych pod nogi może się spodziewać ten, kto na homologację zechce postawić. Ale nie jest to jedynie wskazanie na ludzi, których należy się bać. Mówi bowiem i o tym, z kim warto, a nawet powinno się, rozmawiać i komu należy prezentować uzasadnienia swoich tez. Jeżeli interesariusz zrozumie tłumaczenie strony, którą uważa za adwersarza, może zapomnieć o pewnych swoich interesach, a nawet może całkowicie opuścić grono interesariuszy.
[Ganowski2004a] Homologacja Systemów Informatycznych w administracji publicznej w: Informatyka w Polityce Społecznej, red. Zbigniew Olejniczak i Jerzy S. Nowak. Polskie Towarzystwo Informatyczne. Warszawa, 2004.
[Ganowski2004b] Procesy biznesowe a informatyzacja administracji publicznej w: Systemy informatyczne w administracji, red. Zbigniew Olejniczak, Jerzy S. Nowak i Janusz K. Grabara. Wydawnictwa Naukowo Techniczne. Warszawa, 2004.
[Ganowski2005] Koniec dyktatury producentów oprogramowania, w: COMPUTERWORLD nr 7/658. 15 lutego 2005 r..
[1] Na niezgodność z prawem europejskim powoływali się również redaktorzy tygodnika COMPUTERWORLD, z którymi miałem przyjemność wymieniać opinie na temat idei homologacji systemów informatycznych. Za każdym razem podkreślali jednak, że podobno homologacja SI jest niezgodna z prawem UE.
[2] Definicje pojęcia projekt mówią o ograniczonej czasem produkcji czegoś nowego, bądź czegoś, co już istniało w nowy sposób. Produkcja może oznaczać też świadczenie usługi.
[3] Termin „odpowiednio duży” nie jest precyzyjny, jednak używam go tutaj z pełną świadomością. To jedna z wad homologacji SI, że odpowiedzenie na pytanie co to znaczy „odpowiednio duży” nie jest takie łatwe — szerzej [Ganowski2004a] (s. 135). Powiatowych Urzędów Pracy jest ponad 350, Ośrodków Pomocy Społecznej ponad 2500, użytkowników ZUS'owskiej aplikacji PŁATNIK zapewne parędziesiąt tysięcy. To są dobre rynki dla zastosowania tej metody pozyskiwania oprogramowania.
[4] Nie podoba mi się, mogę się do tego przyznać, ale nie jestem do niego już aż tak wrogo nastawiony, jak to miało miejsce chociażby jeszcze miesiąc temu. Niewątpliwie dobrze jest mieć jeden, zwięzły sposób nazywania istotnych pojęć.
[5] Pewnie nie trzeba już tego nikomu udowadniać, jednak dla potwierdzenia: trzecia i czwarta pozycja w rankingu najważniejszych dziesięciu wyznaczników sukcesu projektów, wg The Standish Group, to odpowiednio „Clear Business Objectives” i „Optimizing Scope and Requirements” [Johnson2005].
[6] Dokładnie takiego określenia: „nie ma projektów informatycznych, są projekty biznesowe” użył p. Grzegorz Kuliszewski z BISE, podczas jednego ze swoich wystąpień na konferencjach organizowanych przez COMPUTERWORLD, w 2005 r. Do tego sprowadzają się moje myśli, jednak dotychczas nie udało mi się tego ująć w tak skrótowej formie. Teraz pozostaje mi tylko się pod tym podpisać (obiema rękami).
[8] Szerzej na ten temat pisałem w [Ganowski2005].
[9] Mały jest zwinny (ang. agile) więc chętnie odwołuje się do metodyk zwinnych (Agile Software Methodologies). Duży najczęściej próbuje wszystko maksymalnie sformalizować (zbiurokratyzować), a następnie potwierdzić stopień zgodności zbiurokratyzowania poprzez uzyskanie odpowiedniego certyfikatu. Koszt tej biurokratyzacji oraz koszt uzyskania certyfikatów też muszą być przecież jakoś pokryte.
[10] Piąta silna strona homologacji w analizie SWOT, w [Ganowski2004a].
[12] Takie to właśnie z tymi interesariuszami masło maślane, jednak faktycznie analizować należy właśnie interesy, a nie samych interesariuszy. A czyje interesy? A no właśnie tych, których nazywamy interesariuszami. To jedyne miejsce, w którym użyłem takiego sformułowania, ale wszędzie indziej, gdzie pisałem o analizie interesariuszy, miałem na myśli właśnie to, o czym tutaj wzmiankuję.