Podkreślmy: sumując koszty operacyjne (w tym pracę programisty) oraz marżę, powinniśmy otrzymać cenę produktu. Czy na pewno? Niestety, nie. Nagle okazuje się, że do ceny doliczane są koszty, które wykraczają poza zdefiniowane przez nas obszary. Koszty, które doprowadzają do sytuacji, kiedy oprogramowanie kosztuje tak dużo, że aż trudno w to uwierzyć.

Za co naprawdę płaci państwo

Na cenę oprogramowania składają się dziesiątki i setki czynników, z których każdy może podnieść jego końcową cenę. Szczególnie w sytuacji oprogramowania zamawianego przez administrację publiczną. Czy składniki wymienione powyżej są jedynymi wyznacznikami wysokiej ceny oprogramowania wytwarzanego na zlecenie państwa polskiego? Oczywiście nie.

Wśród powodów, dla których oprogramowanie jest drogie, można wymienić:

• Skomplikowaną i czasochłonną procedura zamówień publicznych - po stronie wykonawcy oprogramowania wiąże się to z przypisaniem praktycznie całego zespołu do czytania, analizowania i przygotowywania oferty. Wielokrotnie w działania ofertowe muszą by zaangażowane "kosztowne" osoby, takie jak prawnicy czy konsultanci wszelkiego rodzaju. Koszty te oczywiście pokryje zlecający.
• Ludzie - aby wygrywać przetargi, firmy muszą spełniać, czasami niezrozumiałe, wymagania, np. zatrudnianie osób z danym poziomem uprawnień dostępu do informacji niejawnej albo z certyfikatami zarządzania projektami. Choć te osoby mogą być rzadko wykorzystywane operacyjnie w samym projekcie, to koszty ich pozyskania również kształtują końcową cenę.
• Wcześniejsze doświadczenia - aby startować w przetargu i mieć realne szanse na zamówienie, podmiot wykonujący oprogramowanie musi mieć doświadczenie z podobnymi systemami w przeszłości. Jeśli takich firm nie jest dużo, a jak wiemy, duże zamówienia publiczne w Polsce to domena 4-5 firm, to mogą one dowolnie kształtować ceny. Szczególnie jeśli na rynku znajduje się jedynie jeden podmiot, który spełnia określone wytyczne. Wtedy cena monopolisty jest ceną ostateczną.
• Specyfikacja istotnych warunków zamówienia, zwana SIWZ-em - to specyfikacja wymagań dla systemu, który ma powstać. Jeśli jej założenia są zbyt mało precyzyjne, zmuszają wykonawców do przerzucenia na zlecającego części ryzyka. Oznacza to, że podmiot startujący w przetargu spodziewa się kłopotów z odbiorem (np. procedura przeprowadzenia testów akceptacyjnych nie jest dobrze opisana) i dodaje do końcowej ceny ekstrastawkę wynikającą z szacowanego ryzyka na wypadek takiego zdarzenia.
• Cena - wpływ na cenę ma budżet zlecającego. Rozpoczynając przetarg, dana instytucja przygotowuje swoją własną wycenę kosztów powstania systemu. Jeśli wstępna wycena zlecającego jest precyzyjna, czyli podmiot jest świadomy, ile chce zapłacić za oprogramowanie, łatwo udaje się znaleźć wykonawcę. Czasami zdarza się jednak, że cena jest wyssana z palca. W przypadku niedoszacowania powoduje to, że wykonawcy proponują ceny znacznie wyższe, czego następstwem jest unieważnienie przetargu. Gdy zaś cena jest za wysoka, dostawcy chętnie zgadzają się na wytworzenie systemu po zawyżonych kosztach.

W rzeczywistości istnieje jeszcze więcej czynników wpływających na końcową cenę oprogramowania. Część z nich jest jawna, jak chociażby te wymienione powyżej, część niejawna, a części lepiej, żeby w ogóle nie było (np. nielegalny lobbing).

Czy oprogramowanie może być tańsze?

Oczywiście, że oprogramowanie może być tańsze. Co więcej, może być naprawdę tanie w stosunku do tego, co płaci bezpośrednio państwo, a pośrednio każdy z nas.

Czynniki obniżające cenę oprogramowania to:

1. Świadomość wytworzonego produktu po stronie zlecającego. Co chcemy zrobić, jak chcemy to zrobić i dlaczego chcemy to zrobić? Odpowiedzi na te proste pytania powinny ułatwić komunikację z wytwórcą i samą definicję wymagań.

2. Lepsza specyfikacja wymagań. Bardziej staranny i precyzyjny SIWZ pomoże wykonawcy trafniej wycenić produkt i nie dodawać zawyżonych składników ceny zorientowanych na pokrycie ewentualnego ryzyka poprawek w wymaganiach lub zmiany wymagań.

3. Uproszczone procedury zamówień oraz czytelne i jasne zasady. Większa kontrola w wydatkowaniu państwowych pieniędzy jest dobra, ale czy naprawdę musimy doprowadzać to do granic absurdu? Trudne procedury przetargowe czy rozciągnięte w nieskończoność procedury odwoławcze hamują ważne społecznie projekty informatyczne. Po co funkcjonują organizacje takie jak Najwyższa Izba Kontroli czy Centralne Biuro Antykorupcyjne? Zostały powołane do patrzenia na ręce władzy i pilnowania uczciwości przetargów. Procedury plus działania instytucji kontrolnych powinny wspomagać procesy zakupowe, a nie je opóźniać.

4. Dopuszczenie mniejszych podmiotów do zleceń. Aktualne procedury faworyzują duże firmy. Czy naprawdę musimy (i powinniśmy) stawiać na rozwój największych, skoro w kolejce czeka wiele firm gotowych zrobić ten sam produkt taniej i lepiej?

5. Korzystanie z gotowych i tanich rozwiązań. Na najniższym poziomie możemy powiedzieć o wyposażeniu stacji roboczych. Oprogramowanie Windows jest popularne, ale i drogie. Czy naprawdę do obsługi prostych aplikacji potrzebujemy pełnego Windows 7 zamiast rozwiązań tańszych, takich jak Linux? Czy pakiet biurowy MS Office musi być wymagany, skoro do utworzenia dokumentu wystarczy darmowy Open Office? Dla aplikacji internetowych i intranetowych też istnieją dziesiątki rozwiązań otwartych i darmowych. Nie musimy za każdym razem tworzyć CMS-a (Content Managament System) od nowa. Podobnie jest z systemami do zarządzania dokumentacją (w tym jej obiegiem), księgowością, zasobami ludzkimi i każdym innym typem aplikacji zamawianych przez administrację państwową.

6. Korzystanie z wiedzy i doświadczenia z poprzednich projektów. Jeśli dostawca ma, lub miał, kłopoty z dostarczeniem produktu na czas w przeszłości, to możemy się spodziewać, że może mieć podobne problemy aktualnie. Stworzenie ogólnokrajowej bazy wymiany informacji o wykonawcach i dostawcach może wskazać nam tych najbardziej godnych polecenia.

Powyższe propozycje nie są niczym nowym. Są one od lat podnoszone na różnych forach i przy okazji kolejnych zamówień. Niestety, do tej pory ten głos jest wołaniem na puszczy. Warto więc wciąż jeszcze te postulaty powtarzać.