Tak więc dwa porównywalne pod kontem wydanych pieniędzy rozwiązania (podejście kasowe) będą potraktowane różnie (w podejściu memoriałowym), jeśli udział licencji i pracy ludzkiej będzie w obu projektach na różnym poziomie. W różnych firmach podejście może być nieco inne (zależne od preferencji dyrektora finansowego, zarządu bądź rady nadzorczej), ale ogólna idea będzie bardzo podobna. Klienci indywidualni nie czują takiego rozwarstwienia, to znaczy zapłacone pieniądze zawsze tak samo obciążają ich budżet (bez względu na źródło kosztów w postaci licencji bądź pracy innych osób). Zastanawiałem się, czy nie może to być źródłem jakiś większych anomalii na rynku efektywnym, ale doszedłem do wniosku, że produkty dla klientów indywidualnych i korporacyjnych to w większości przypadków rozdzielne produkty, więc myślę, że nie stanowi to większego problemu.

Nie tylko koszty

Innym przejawem efektywności związanej z oprogramowaniem jest optymalne wykorzystanie dostępnej funkcjonalności oprogramowania. Tu zapewne większość praktyków podniesie głosy sprzeciwu i każdy będzie miał przynajmniej kilka dobitnych przykładów, kiedy to użytkownicy mogli zrobić coś znacznie prościej, a z niewiadomych powodów robili to w sposób wolniejszy, bardziej skomplikowany i mocniej obciążający serwer. Zgadza się, sam mógłbym sypać takimi przykładami jak z rękawa. Jednak mimo mnogości takich przykładów uważam, że zjawisko to nie zaprzecza efektywności. Otóż uważam, że przyczynami stosowania rozwiązań nieoptymalnych, mimo że optymalne są dostępne, może być na przykład niewiedza (czyli np. brak szkolenia, przekonanie o braku czasu na nie czy zatrudnianie personelu o słabszych kwalifikacjach) bądź czynniki fizyczne powiązane ze zmianą sposobu postępowania (zamiast dwukrotnie możemy jednokrotnie wprowadzać numer paczki do systemu, ale wymaga to dwukrotnego obejścia stanowiska pracy, a wcześniej nie było to potrzebne). W praktyce często jako przyczynę nieoptymalności można wskazać niepoprawne wdrożenie lub nadzór nad pracą, co tak naprawdę przekłada się na próbę oszczędności na niewłaściwym etapie, co jest może anomalią, ale nie w zjawisku efektywności tylko kompetencji zarządzających.

Pojęcia efektywności rynku można też użyć w związku z funkcjonalnością poszczególnych produktów. Jeśli na rynku istnieją dwa różne produkty o podobnej cenie i jeden z nich jest bardziej popularny, wtedy do wyrównania popularności potrzeba obniżenia ceny mniej popularnego produktu bądź podwyższenia jego funkcjonalności. I kwestia ta dotyczy funkcjonalności postrzeganej oczami klienta, a nie producenta bądź analityków zatrudnianych przez niego. Tak więc może się okazać, że znacznie lepiej sprzedaje się produkt 20% tańszy, mimo że ten droższy ma 5 razy tyle możliwości. Przyczyną może być zarówno fakt, że te supermożliwości nie są przydatne przeciętnemu użytkownikowi, jak i to, iż koszt dotarcia do nich (np. szkolenie bądź komplikacja obsługi) jest tak wysoki, że nie rekompensuje różnic w funkcjonalności. Tak więc producenci analizując popyt na podobne produkty usiłują wydobyć od konsumentów wiedzę, które składniki danego produktu wpływają na konkretny wybór. I jak można to zaobserwować najciekawsze elementy podobnych pakietów informatycznych są dość szybko implementowane u konkurencji (zresztą dokładnie tak samo jest w urządzeniach elektronicznych domowego użytku, samochodach i innych produktach). I to też śmiało można nazwać efektywnością rynku. Nie istnieją bowiem znane rozwiązania, które pozwalałyby zarabiać przez dłuższy czas tylko wąskiej grupie producentów.

Jakkolwiek jestem przeciwnikiem patentowania algorytmów, to nawet ta kwestia broni się w obrazie efektywności (myślę o tej realnej efektywności z kosztami transakcyjnymi i kosztami zdobycia informacji). Otóż konieczność zakupów opatentowanych technologii do rozszerzenia funkcjonalności produktu nie oznacza nic innego jak zwiększenie kosztów powstawania danego produktu. I znów rachunek kosztów w porównaniu z rachunkiem potencjalnych zysków powoduje podjęcie decyzji, czy warto daną funkcjonalność implementować czy nie.

Z teorii do praktyki

Czy wiedza co to jest efektywność może się do czegoś przydać informatykom? Uważam, że tak, i to bardzo. Myślę, że jest to mechanizm, który pozwala dokładnie ocenić działanie zespołu konsultantów, projektantów, programistów i wdrożeniowców oraz oszacować, czy zaproponowane rozwiązanie jest dla odbiorcy globalnie tańsze. Jeśli przyjmiemy, że rynek jest efektywny, wtedy fakt wyparcia starego rozwiązania przez nowe oznacza, że to nowe okazało się tańsze. Oczywiście należy na tę kwestię patrzeć globalnie. To wzniesienie się ponad swoje otoczenie jest szczególnie przydatne na przykład w przypadku integracji dwóch firm o różnych systemach informatycznych. Jeśli przyjmiemy, że łączą się firmy, w których dopracowano się już optymalności, wtedy prawie zawsze w miejscu, gdzie wymienia się system (celem ujednolicenia go w całej grupie), można wskazać pewne braki optymalności.

Najczęściej przyczyną jest jeden z trzech aspektów, który nie podważa efektywności globalnej. Pierwszy to fakt, że posiadanie jednego wspólnego systemu informatycznego jest tańsze, niż straty wynikające z niedopasowania tego systemu do działań firmy, której się narzuca zmianę. Drugi wynika z różnic w zakresie działalności biznesowej między przejmującym i przejmowanym. Często zakresy działalności się nie pokrywają (bądź pokrywają tylko częściowo), więc nie można oczekiwać, żeby system jednej z firm całkowicie pokrył potrzeby drugiej. W miarę jak sygnały o konieczności zmian będą coraz silniejsze, można liczyć, że oprogramowanie zostanie właściwie zmodyfikowane. Kolejnym aspektem jest fakt, że oprogramowanie narzucone potencjalnie jest w stanie sprostać wymaganiom stawianym przez zdominowane środowisko, jednak tylko pod warunkiem, że nastąpią również zmiany w procesach (które zapewne zostały zaniechane - tu najczęściej winne są osoby planujące integrację ponad głowami osób odpowiedzialnych za informatykę bądź z udziałem takich osób, ale o niewłaściwych kompetencjach). Sądzę, że w przypadku integracji firm wszystkie przyczyny się na siebie nakładają, co powoduje oddolne przekonanie, iż sprawy, zgodnie z prawem Murphy'ego, przechodzą ze złych w gorsze i po przejściu proces jest gotów do powtórzenia się. Jednak uważam, że spojrzenie globalne pozwala powiedzieć, że działanie takie (przy zachowaniu odpowiednio długiej skali czasu) jest efektywne.

Oczywiście spojrzenie przez pryzmat efektywności nie musi dotyczyć tylko przejęć firm i łączenia ich systemów informatycznych. Dokładnie to samo zjawisko można odnieść do drobnych wdrożeń i małych poprawek w już pracujących programach. Jeśli użytkownicy sugerują jakieś zmiany w programie, a następnie nie korzystają z nich, można podejrzewać, że sugestie zostały źle zrozumiane. Oczywiście mnóstwo jest przypadków, kiedy użytkownikom wydaje się, że jakaś zmiana przyniesie poprawę jakości pracy, a po wdrożeniu okazuje się, że tylko im się wydawało. Osobną kategorią są żądania nieprzemyślanych zmian w działaniu (np. nikt się nie zastanowił, jak zmiana wpłynie na inny proces bądź nie zwrócono uwagi na to, że w przypadkach, w których dotychczas proces działał dobrze, teraz siłą rzeczy będzie działał źle). Trzeba jednak umieć rozróżnić przypadki, które sugerują nieefektywność rynku, od tych, które udowadniają głupotę zleceniodawców.

Najlepiej o efektywności mówić w przypadkach, gdy rynek jest bardzo duży. I tu narzucają się dwa porównania, które pokazują, że nie zawsze nominalna cena produktu może świadczyć o całkowitych kosztach ponoszonych przez jego użytkowników. Pierwsze, to porównanie zestawu IIS, dotNET i technologii Active Server Pages z zestawem JAVA, Apache, Tomcat i technologią serwletów. Oba zestawy są nominalnie bezpłatne, jednak to zestaw na bazie JAVY uzyskuje zdecydowaną i niekwestionowaną przewagę według większości raportów. Można z tego wyciągnąć wniosek, że zwycięzca oferuje tańsze rozwiązanie. Na tę taniość składają się zapewne stabilność i bezpieczeństwo środowiska oraz tańszy sprzęt (jak twierdzą niektórzy) wystarczający do zbudowania porównywalnych projektów. Na przeciwległym końcu porównania znajduje się para Linux i Windows w zastosowaniu desktopowym. Tu też nikt nie ma wątpliwości, że na razie Windows bije Linuxa na głowę liczbą wdrożeń. Oczywiście ściągnę sobie na głowę niezadowolenie zwolenników rozwiązań open source, ale uważam, że jest to przejawem tego, że bezpłatny Linux jest wciąż zbyt kosztowną alternatywą płatnych Windowsów. Mam nadzieję, że z czasem się to zmieni, choć jak na razie cały czas występuje bardzo duża rozbieżność między wysokimi możliwościami oferowanymi przez Linuxa, które zupełnie nie wpasowują się w duże zapotrzebowanie potencjalnych użytkowników.

Zapewne błędem jest próba zmuszenia użytkowników do zmiany swojego sposobu zachowania (co jest z ich punktu widzenia bardzo kosztowne) zamiast dopasowywania się do tego zachowania. Efekt, w którym nominalnie bezpłatny produkt przegrywa z płatnym oznacza, że na etapie konsultacji i projektu popełniono błędy, które skutkują wyższymi (z punktu widzenia użytkownika końcowego) łącznymi kosztami tego produktu (szkolenie, wdrożenie, używanie). Jak ktoś słusznie zauważył, oprogramowanie otwarte i bezpłatne często pisane jest przez pasjonatów dla siebie (dla grupy o cechach zbliżonych do twórców tego oprogramowania). Tak więc Apache uzyskuje przewagę nad IIS, gdyż używają go programiści, natomiast Linux nie ma szans na taką przewagę, gdyż używają go (a raczej próbują używać) tak zwani zwykli ludzie.

Podsumowanie

Mam nadzieję, że moja wizja efektywności przybliżyła tę kwestię czytelnikom, którzy wcześniej nie mieli z nią styczności. Myślę też, że osoby, które miały już jakieś swoje przemyślenia na ten temat, mogą je skonfrontować ze swoimi tezami. Najważniejsze co chciałbym, aby pozostało po przeczytaniu tego artykułu, to przekonanie, że indywidualne racjonalne zachowania ludzkie prowadzą globalnie do efektywności rynku. Zarówno tego wielkiego, na poziomie światowych trendów, jak i tego małego, na poziomie zachowań małych grup użytkowników. I z zachowań tych da się wywnioskować co jest zbyt drogie (zbyt trudne, zbyt ryzykowne, zbyt wolne) w naszym projekcie i się w nim nie sprawdza. Warto przy tym pamiętać, że jeśli z szacunków wynika, że uwzględniliśmy już wszystkie koszty używania pewnej funkcjonalności, a użytkownicy i tak z niej nie korzystają, niemal zawsze nie jest to świadectwem anomalii czy nieefektywności, tylko pominięciem w analizach jakiegoś ważnego czynnika, który podnosi koszty w sposób dla nas nieoczywisty lub trudny do zauważenia.