A jednak jak to mówią „nigdy nie mów nigdy”. Postanowiłem napisać o SaaS (Software as a Service, ang. Oprogramowanie jako Usługa) mimo wcześniejszych deklaracji, że nie będę tego tematu poruszał, ale tu w nieco innym kontekście. Dlaczego? Bo jednak nie potrafię słuchać tłumaczenia: „SaaS jest dobre dla firm bo jest dobre”. Ja oczywiście zawsze jestem uciążliwy i pytam „Dlaczego dla mnie jest dobre”? Tłumaczenie, że „Dzierżawione jest lepsze i tańsze” od razu nasuwa mi pytanie „To dlaczego dostawcy SaaS nie są jeszcze milionerami?” A jak chcę skopać leżącego to pytam jeszcze o rentowność (dla mnie, nie dla niego).

Nie wątpliwie dzierżawa zamiast zakupu może być korzystna gdyż ma dwie podstawowe zalety: wydatki na zasoby dzierżawione są zawsze mniej ryzykowne niż na własne bo wyjście z własnej inwestycji jest trudniejsze od rezygnacji z dzierżawy (zakładam, że umowa na dzierżawę nie zawiera niekorzystnych dla dzierżawiącego zapisów). Druga zaleta dzierżawy to mierzalna oczekiwana jakość zapewniona umową (nie zapominajmy, że jednak ze umowa to tylko obietnica). Dlaczego więc SaaS (a dawniej usługi ASP, Application Service Provider) nie zawojowały rynku?

Najpierw kilka wyjaśnień.  Osobiście nadal stoję na stanowisku, że obecne SaaS i niegdysiejsze ASP to TO SAMO tylko ubrane w inne słowa. Jedyne co sie zmieniło to technologia zdalnego udostępniania tych zasobów. Kiedyś były to głównie system zdalnego dostępu do platformy z aplikacją obecnie jest to głownie zdalny dostęp do aplikacji w całości zaprojektowanej jako system zdalny np. dostępny za pośrednictwem Internetu i przeglądarki internetowej.

Moim zdaniem ASP, SaaS i inne cokolwiek bądź zdalnie i cudze to tylko odpowiedni model biznesowy. Model ten musi być poparty architekturą systemu bezpieczną dla firmy. Sam fakt, że można wydzierżawić system dziedzinowy na kwartał, płacąc tylko za ten okres to za mało. Dlaczego? Powód jest moim zdaniem ten sam, który sprawia, że wiele wdrożeń się nie udaje: zaniedbuje się architekturę systemu, model danych i model przetwarzania w firmie. O czym mówię? Spójrzmy na diagram poniżej (kliknij na diagram by powiększyć).

Kliknij by powiększyć

Co tu mamy? Dwa systemy: System Pierwszy i System Drugi. System Pierwszy przetwarza dane operacyjne firmy, System Drugi nie. System Drugi lokalnie (u siebie) przetwarza dane potrzebne do tego by pokazać nam oczekiwane wyniki przetwarzania (dlatego te dane nie zostały jawnie pokazane). Danych pośrednich nie musimy znać ani posiadać, wymagane są wyniki przetwarzania. Widać więc, że System Drugi może być „cudzy” ale System Pierwszy praktycznie nie, chyba, że zdalnie wykorzystujemy kompletny pakiet wspomagający zarządzanie firmą co i tak nie zwolni nas z posiadania narzędzi biurowych i baz danych dlatego nawet taki przypadek wymaga analizy, ot choćby z uwagi na ocenę ryzyka.

Dodam także jeszcze, że zasoby (oznaczone niebiesko) są zarządzane, proces ten (dostarczenie tych zasobów, oprogramowania, i ich utrzymanie) jest związany nierozerwalnie z tymi zasobami więc w zasadzie mamy tu pokazany model BPO czyli outsourcing procesu, który zabezpiecza nam jakieś zasoby IT, usługę. Być może niektórzy z Państwa już widzą co my tu mamy.

Mamy tu więc ogólną koncepcję SOA ([[Serwice Oriented Architecture]], ang. [[Architektura systemu Zorientowana na Usługi]]). Model, w którym proces biznesowy jest wspomagany usługą IT jest niczym innym jak właśnie SOA, problem w nazewnictwie tkwi tylko w tym, gdzie przebiega granica pomiędzy właścicielami zasobów i tym, że nie musi to być ta sama granica, która rozdziela dwie firmy w jej działalności rynkowej. Granice pomiędzy zasobami wyznaczają właściciele tych zasobów ale pozostałe granice wyznaczają modele biznesowe.

Dlaczego więc nie zawsze ASP, SaaS czy BPO (także outsourcing) ma sens? Właśnie powodem są dane a konkretnie interfejsy pomiędzy wykorzystywanymi systemami. Jeżeli jakieś dane są stale współużytkowane to rozdzielenie ich pomiędzy „nasz system” a „ich system” jest i ryzykowne i nie raz trudne technicznie co także pokazuje powyższy diagram. Przykłady:

Przykład 1

Biura rachunkowe, jeżeli chcą mieć więcej i większych klientów powinny oferować zdalny dostęp do systemu, którym przetwarzają dane o transakcjach finansowych i wzbogacić je o funkcje CRM. Wystawianie faktur wymaga bazy danych kontrahentów i firm, do których wysyłamy oferty bo procesy te (ofertowanie, fakturowanie i obsługa posprzedażna) współdzielą dane o klientach i produktach.

Przykład  2

System kadrowo-płacowy może być dzierżawiony gdyż dane o pracownikach i ich wynagrodzeniach są potrzebne okresowo i „tylko do odczytu” np. podczas księgowania wynagrodzeń oraz przy udostępnianiu pracownikom zasobów firmy (należy sprawdzić czy dana osoba ma prawo do tego co chcemy jej udostępnić i na jak długo). Procesy, które przetwarzają dane które powinny być nam znane ale nie musimy ich przetwarzać.

Przykład 3

System CAD do projektowania produktów może być wykorzystany w modelu dzierżawy gdyż po zakończeniu projektowania potrzebne są nam jedynie wykonane projekty ale można zlecić zewnętrznej firmie projektowej wykonanie projektu i nie nawet zatrudniać projektantów. Pojawia się tu jednak problem cyklu zarządzania produktem, który wymaga stałego zarządzania projektem i produktem. Dlatego nawet ten przypadek wymaga bardziej szczegółowej analizy na ile możemy ten proces pozostawić poza naszą firmą.

Wszystkie te przypadki wymagają analizy, nie ma dwóch jednakowych firm ani jednakowych przypadków. Po raz kolejny uważam, że nie istnieją na poziomie strategii żadne najlepsze praktyki czy referencyjne procesy biznesowe. Przewaga rynkowa to model biznesowy a ten wymusza takie a nie inne procesy biznesowe wewnątrz firmy. Jeżeli można mówić o najlepszej praktyce to chyba tylko o tej, że każda decyzja wymaga analizy podobnie jak ktoś powiedział, że jedyną stałą rzeczą w biznesie jest ciągła zmiana.

Zakończenie

Mam nadzieję, że dałem Państwu kilka wskazówek jak radzić sobie z ofertami dostawców usług SaaS i z własnymi pomysłami na outsourcing. Daleki jestem od stwierdzenia, że dzierżawa jest zła. Uważam tylko, że dzierżawa powinna być korzystna i bezpieczna. Jak już Państwo nie raz ode mnie słyszeli: „Albo to narysuję albo to nie istnieje”.  Podjąłem więc wyzwanie i … obawiam się, że SaaS to tyko BPO (Business Process Outsourcing, ang. Outsourcing Procesów Biznesowych) czyli po prostu znany już stary model biznesowy ubrany w nowe nośne hasło reklamowe …

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.