Business Case dla Open Source – część pierwsza, filozoficzna

Data: 2013-05-06
Autor: Sebastian Konkol

Dwa lata minęły, odkąd mój dobry znajomy postawił przede mną wyzwanie: przygotować model wyceny uzasadnienia biznesowego dla wykorzystania oprogramowania Open Source w projektach informatycznych administracji publicznej. Trochę wstyd, że tyle to trwało, ale – na moją „obronę” – kontekst wyzwania niestety wygasł, zanim na dobre się rozpalił. Myślałem o tym długo, bo i wymagany research jest spory, i tematyka obłożona klątwami często nacechowanymi emocjonalnie. Tym niemniej, zebrałem się w sobie i oto, do czego doszedłem w ramach poszukiwań – w podziale na dwie części: filozoficzną (poniżej) i twardą (nastąpi wkrótce) lub, jak kto woli, jakościową i ilościową.

Muszę przyznać, że dodatkowym bodźcem do powrotu do tego tematu były niedawne wieści ze świata Ubuntu – rozszerzenie dostępności dystrybucji systemu operacyjnego Linux nie tylko na serwery i desktopy, ale także na smartfony, tablety i to, co dzisiaj jeszcze kojarzy się nam z telewizorem. Dotąd, w historii informatyki stosowanej, taki wyczyn udał się tylko jednej firmie (rzecz jasna, Microsoft) – straszliwie komercyjnej w każdym możliwym wymiarze tego określenia. A tu znienacka, ruch społeczny – nieopłacany w tradycyjnym tego terminu znaczeniu – opracował coś poważniejszego i to nie tylko lepiej, ale w trybie Open Source. Dla informatyki użytkowej znaczy to wiele, a mnie zastanowiło, co to znaczy dla sposobu, w jaki wyceniane są dzisiaj przedsięwzięcia informatyczne – krótko mówiąc, czy uzasadnienie biznesowe bierze pod uwagę to, co brać powinno…

Przede wszystkim jednak – zakładają, że rzeczywiście potrzebne jest wytworzenie systemu informatycznego, a nie skorzystanie z rozwiązań udostępnianych w formie SaaS (Software as a Service, jak na przykład salesforce.com) – umówmy się, jak w dzisiejszych warunkach wyglądają alternatywy dla realizacji projektów systemów informatycznych. Jakimi opcjami dysponujemy, a w konsekwencji jakie powinniśmy porównywać.

  1. Z punktu widzenia kryteriów oceny najmniej skomplikowaną możliwością jest skorzystanie z oferty firmy tworzącej systemy informatyczne na zamówienie. Pomijając blaski i cienie procesów wytwórczych oprogramowania, system robi to, co chcemy i robi to dokładnie tak, jak chcemy. Mamy nad nim także kompletną kontrolę, zapewnioną elastyczność, a także wygodny, pojedynczy punkt odpowiedzialności za jakość działania systemu – wytwórcę oprogramowania. Taka możliwość jest w zasadzie jedyną dostępną, jeśli dla oczekiwanego systemu nie ma „w przyrodzie” istniejącego produktu, który dawałby się dostosować (system nie należący do żadnej z istniejących klas rozwiązań informatycznych, jak np. CRM, ERP, BI, ESB czy wiele innych). Za komfort elastyczności „płaci się” zwykle dłuższymi czasami dostarczenia (szczególnie, jeśli nie pominiemy cieni procesów wytwórczych oprogramowania), a od dostawcy wymagamy zwykle stabilności kompetencji wymaganych do rozwoju systemu i trwałości biznesu dostawcy.
  2. Częściej chyba wykorzystywanym wariantem dojścia do posiadania oczekiwanego systemu informatycznego jest skorzystanie z oferty integratora, który – bazując na dostępnych komponentach systemów informatycznych – dostarczy rozwiązanie nie tworząc go od podstaw. Rolą dostawcy jest wtedy dobór właściwych komponentów i dokonanie ich modyfikacji lub rozwoju w sposób zapewniający skuteczną i trwałą ich współpracę. Jest więc relatywnie taniej (koszt gotowych komponentów jest zwykle ponoszony nie przez nasz projekt, ale jest współdzielony przez wiele przedsięwzięć korzystających z komponentu), a system jest od początku stabilniejszy (komponenty są zwykle już przetestowane i zweryfikowane „bojem”). Taka opcja wprowadza jednak ograniczenia elastyczności (komponenty są gotowe, więc robią coś tak, jak robią) i zwiększa liczbę zależności (nie tylko integrator, ale także producenci gotowych komponentów), więc liczba podmiotów do zweryfikowania rośnie – nawet, jeśli formalnie zagwarantujemy sobie pełną odpowiedzialność integratora za całość rozwiązania, włączając w to gotowe komponenty (Oracle, SAP czy Microsoft po prostu ogłasza koniec okresu wsparcia dla określonego rozwiązania i tyle).
  3. W stosunkowo rzadkich przypadkach, kiedy istnieje rozwiązanie gotowe spełniające wszystkie oczekiwania (np. dla rozwiązań finansowo-księgowych), korzysta się zwykle z firmy wdrożeniowej. Jej zadaniem jest po prostu zainstalowanie i skonfigurowanie systemu informatycznego w takim zakresie, w jakim jest to możliwe przy wykorzystaniu dostępnych mechanizmów tego systemu. Czas realizacji takiego przedsięwzięcia jest zwykle zaskakująco krótki, a i cena niższa. Jesteśmy jednak ograniczeni dostępnymi możliwościami systemu i w pełni uzależnieni od kierunków rozwoju systemu wyznaczanych przez jego producenta (nie firmy wdrożeniowej). Mamy jednak znów pojedynczą zależność – od producenta.
  4. Możliwością – co ciekawe – bardzo często wykorzystywaną przez informatyków-praktyków (np. dla rozwiązań na potrzeby wewnętrznych działów IT lub dostawców oprogramowania) jest oparcie rozwiązania o oprogramowanie Open Source. Sam system inicjalnie nie kosztuje nic (o ile nie ruszy nas sumienie i przekażemy kilku groszy w formie darowizny), ale wymaga większego zaangażowania w przystosowanie i wdrożenie, gdyż zwykle trzeba samemu zrozumieć lub się nauczyć. Podobnie jak w przypadku wyboru systemów komercyjnych, dobór oprogramowania Open Source opiera się na kilku praktycznych wskazówkach. Stabilnie realizowane takie projekty zapewniają wyższą jakość systemu nawet niż w przypadku gotowych systemów komercyjnych, ale nie warto się łudzić, że będziemy mieli jakikolwiek wpływ na kierunek rozwoju takiego systemu.
  5. Ruch Open Source wiele zmienił w biznesie produkcji oprogramowania, integracji i wdrażania systemów informatycznych. Pośród innych zagadnień, sprawy oprogramowania otwartego i zamkniętego zaczęły się bardzo mieszać – coraz częstszym modelem jest bezpłatne udostępnienie ograniczonej funkcjonalności wersji systemu komercyjnego do rozwoju w ramach Community Edition – inaczej mówiąc, fundowania projektu Open Source na bazie kodu posiadanego systemu informatycznego. Takie rozwiązanie przedstawia użytkownikowi systemu możliwość przejścia z wersji Open Source na wersję komercyjną w sytuacji, w której będzie to zasadne. Możliwe jest także udostępnienie innym firmom mechanizmów tworzenia dodatków (open source lub komercyjnych), „punktowo” uzupełniających możliwości wersji Community Edition o wymagane funkcje. To taki rozsądny kompromis pomiędzy ponoszeniem inicjalnych kosztów oprogramowania komercyjnego a wysiłkiem wymaganym dla pracy w całości na bazie systemu Open Source.

Prawdopodobnie dałoby się wskazać jeszcze więcej wariantów działania, szczególnie jeśli uwzględnić hybrydy powyższych możliwości. Taki przegląd pokazuje jednak, jak różne kryteria decyzyjne kierują wyborem rozwiązania systemu informatycznego – a dokładniej, jak wiele decyzji subiektywnych (a często nawet emocjonalnych) poprzedza proces decyzyjny wyboru „właściwego” rozwiązania.

Przedstawione powyżej opcje dowodzą, z jak różnych kryteriów decyzyjnych korzystamy oceniając poszczególne z nich – i jak nieporównywalne one są. Jeśli mamy obiektywnie porównywać uzasadnienie biznesowe każdego z wariantów i móc decydować obiektywnie nie tylko o wyborze dostawcy lecz także o formule realizacji przedsięwzięcia informatycznego w szerszym rozumieniu, musimy sprowadzić kryteria oceny do wspólnego mianownika. Nie o to wszak chodzi, by porównywać słonie i ciężarówki…

Kryteria oceny, jakie uważam za słuszne i kompletne, grupowane są w dwóch kategoriach: kosztów (finansowe) oraz ryzyka i przyszłego potencjału (niefinansowe). W większych szczegółach przedstawia się to następująco.

Kryteria finansowe:

  • Koszty bezpośrednie, czyli najłatwiej dostrzegalne:
    • sprzęt – zakup sprzętu, jego rozszerzeń już w trakcie realizacji projektu i aktualizacji w trakcie produkcyjnego użytkowania;
    • oprogramowanie – zakup licencji i własności intelektualnej oraz uaktualnień i uzupełnień realizowanych w trakcie jego produkcyjnego użytkowania;
    • usługi projektowe – instalacja, konfiguracja, dopasowanie do specyficznych potrzeb (w przypadku systemu tworzonego w całości na zamówienie często największy składnik kosztów);
    • utrzymanie własne – nadzór poprawności działania systemu, rozwiązywanie bieżących problemów i koordynacja rozwiązywania zgłoszeń przekazanych na zewnątrz, narzędzia związane z takimi działaniami (np. bug tracker);
    • utrzymanie zewnętrzne – opłaty utrzymaniowe związane z gotowością do rozwiązywania problemów identyfikowanych w ramach utrzymania własnego;
    • osobowe – zarządzanie projektem i procesem wytwórczym, inżynieria systemowa (architekci, analitycy, programiści, testerzy, …);
    • administracja systemem – strojenie, zmiany konfiguracji, zapewnienie możliwości naturalnego rozrastania się zasobów dla systemu;
    • gromadzenie wiedzy – materiały, szkolenia formalne, zdobywanie doświadczenia;
    • wyłączenie, deinstalacja i usunięcie systemu.
  • Koszty pośrednie, czyli często pomijane:
    • utrzymanie – obniżenie produktywności w związku z koniecznością uzyskania pomocy od stron trzecich czy mediowania w sporach między stronami;
    • gromadzenie wiedzy – nauka w trakcie pracy, obniżenie skuteczności działań wynikające z konieczności doszkolenia się w trakcie rozwiązywania problemu;
    • rozwój narzędzi – wysiłek wkładany w wytworzenie narzędzi i aplikacji ułatwiających utrzymanie systemu w ruchu;
    • futz factor – straty produktywności wynikające z możliwości wykorzystania dostępnych zasobów obliczeniowych do działalności niezwiązanej z wykonywaną pracą;
    • straty – realne straty finansowe lub utracone korzyści wynikające z niedostępności systemu, obniżenia wydajności lub awarii.

Kryteria niefinansowe:

  • Potencjał:
    • gotowość do modyfikacji – potencjał wpływania na sposób działania systemu;
    • interoperacyjność – potencjał łączenia systemu do współpracy z innymi systemami i aplikacjami;
    • skalowalność – potencjał rozbudowy zasobów technicznych systemu bez zmiany logiki działania oprogramowania;
    • elastyczność techniczna – potencjał rekonfiguracji systemu do działania w środowisku innym, niż pierwotnie określone;
    • dostępność aplikacji – potencjał rozwoju systemu o nowe funkcje.
  • Ryzyko:
    • dostępność i stabilność – ryzyko obniżenia dostępności systemu lub destabilizacji jego pracy;
    • cykl życia – ryzyko wyłączenia systemu z zakresu wsparcia zewnętrznego;
    • wydajność – ryzyko obniżenia dostępności systemu;
    • jakość wsparcia (wewnętrznego i zewnętrznego) – ryzyko obniżonej wiarygodności i skuteczności działań utrzymania dla systemu;
    • bezpieczeństwo – ryzyko złamania zabezpieczeń systemu (np. wyciek lub utrata danych);
    • poziom trudności zarządzania systemem – ryzyko utraty zdolności utrzymania systemu w przypadku utraty obsady administratorów systemu.

Listę kryteriów niefinansowych można bez wątpienia snuć dalej, ale nie o to chodzi. Ważne jest to, że tak sformułowane kryteria pozwalają na ocenę każdej z przedstawionych opcji wytworzenia systemu informatycznego. O ile kryteria finansowe dają się określić zwykle z wykorzystaniem podstawowego aparatu matematycznego (nie wykraczając zbytnio poza dodawanie i mnożenie), o tyle oszacowanie przyszłego potencjału lub ryzyka wymagać może stosowania bardziej wyuzdanych metod wyliczania wartości, np. szacowania ryzyka operacyjnego czy ROV.

Aby nie pozostawić sprawy w sferze czysto jakościowej, w drugiej części (która nastąpi wkrótce) porównam dwa „skrajne” warianty wytworzenia systemu informatycznego – oprogramowanie zamknięte (COTS) i otwarte (Open Source). Stay tuned!

Pozostaw komentarz