Dobrze Ci radze SellPander SaaS

Kiedy chcemy wprowadzać do swojej firmy powiew świeżości w postaci automatyzacji jakiegoś konkretnego procesu, potrzebujemy najpierw zapoznać się z dostępnymi na rynku opcjami. W tym artykule przybliżę temat jednej klasy produktów – rozwiązań w modelu SaaS, starając się jednocześnie odpowiedzieć na pytanie – czy warto z nich korzystać? 

Rozwiązania SaaS vs On-Premise 

Aby móc w ogóle zabrać się za rozważania na temat tego, kiedy warto zdecydować się na rozwiązania w modelu SaaS, musimy w pierwszej kolejności dowiedzieć się, jakie inne alternatywy są dostępne na rynku. 

Przede wszystkim pragnę zaznaczyć, iż nie planuje tutaj wprowadzać rozległych dywagacji na temat technicznych szczegółów działania tego typu systemów – w końcu, gdybyśmy chcieli być w pełni poprawni od strony technologicznej, musielibyśmy poza modelem SaaS wyróżnić również rozwiązania PaaS czy IaaS, a w przypadku rozwiązań On-Premise – omawiać różnice między programem „pudełkowym” a tym pisanym na zamówienie. 

System SMS dla firm i urzędów: powiadomienia i marketing

Na potrzeby tego artykułu uznajmy więc, iż rozwiązania SaaS to takie, które po pierwsze dostępne są w chmurze – a więc praktycznie z każdego, dowolnego miejsca na ziemi z dostępem do Internetu – z wyłączeniem niektórych bardziej “zamkniętych” krajów, po drugie – których infrastruktura utrzymywana jest po stronie dostawcy – program znajduje się na serwerach firmy będącej właścicielem oprogramowania i to ona dba o jego dostępność i prawidłowe działanie, oraz po trzecie – rozwiązanie opłacane jest w modelu abonamentowym – zazwyczaj albo w formie zużycia (koszt zależy od ilości wykonanych operacji w programie) albo wygodnych, miesięcznych pakietów. 

Po drugiej stronie barykady znaleźć możemy wspomniane rozwiązania On-Premise. Te z kolei, cechują się jednorazową zapłatą za program (bądź też całkowitym brakiem tego kosztu, w przypadku tak zwanych rozwiązań Open Source – przykładem niech będzie sklep internetowy na platformie Presta Shop), instalacją na własnej infrastrukturze – może to być po prostu komputer, bądź dedykowany, zakupiony serwer, oraz koniecznością samodzielnego dbania o dostarczone rozwiązanie.  

Posiadając już odpowiednią nomenklaturę, możemy przejść do podjęcia wyzwania postawionego w temacie i przeanalizować, jakie są wady oraz zalety rozwiązań w modelu SaaS oraz kiedy warto korzystać z tej formy programu. 

Niskie bariery wejścia 

Niewątpliwą zaletą rozwiązań w modelu SaaS jest niski koszt wejścia, a więc początkowa kwota, którą należy wydać, aby móc korzystać z danego systemu. 

W znaczącej wielkości przypadków jest to po prostu kwota pierwszego miesiąca abonamentu bądź też – w przypadku opłaty za wykorzystanie – ilość zużytych w danym miesiącu zasobów. W tej formie sytuacja prezentuje się nawet lepiej – płatność następuje dopiero po zakończeniu danego okresu rozliczeniowego, a więc zwyczajowo po 30 dniach. 

Jeżeli zestawimy ze sobą koszty rozwiązania pudełkowego, z rozwiązaniem w modelu SaaS możemy zdać sobie sprawę, iż praktycznie nieopłacalnym jest inwestycja w gotowy program. Jeżeli natomiast zamiast programu gotowego “pod lupę” weźmiemy koszty rozwiązania indywidualnego, szytego na miarę – są spore szanse, że różnica będzie nawet ponad kilkudziesięciokrotna. Oczywiście, warto w tym miejscu zauważyć, że mówimy tylko i wyłącznie o opłacie miesięcznej – ideą modelu biznesowego, jakim jest SaaS, jest oczywiście abonament i konieczność ciągłego jego opłacania. W perspektywie długoterminowej program gotowy może okazać się bardziej opłacalny – ten krok warto jednak rozważyć dopiero wtedy, gdy jesteśmy już pewni co do naszych potrzeb. 

W przypadku rozwiązań SaaS możemy wyróżnić jeszcze dwie istotne kwestie dotyczące ceny. Pierwszy z nich to tak zwana “opłata aktywacyjna” – niektóre systemy wymagają, aby poza abonamentem miesięcznym przy pierwszej płatności uiścić również koszt udostępnienia dla nas rozwiązania. Opłaty te nie są zwykle zbytnio wysokie, zwłaszcza w porównaniu do pełnej ceny programów pudełkowych. 

Na drugim końcu spektrum – które notabene, z moich obserwacji występuje częściej – możemy znaleźć okresy testowe. Wiele firm oferujących rozwiązania w modelu SaaS, aby zachęcić klientów, pozwala na korzystanie z pełnej funkcjonalności systemu przez wybrany okres (zwykle 14 bądź 30 dni) całkowicie za darmo. W wielu sytuacjach możemy spotkać się również z darmowymi kontami, bezpłatnymi przez cały okres użytkowania systemu – które to dają możliwość korzystania z jego mocno ograniczonej funkcjonalności bądź posiadają wysoce restrykcyjne limity co do ilości wykonywanych operacji. 

Utrzymanie Infrastruktury 

Model abonamentowy występujący w rozwiązaniach SaaS możemy w pewnym stopniu przyrównać do miecza obosiecznego. Z jednej strony, decydując się na korzystanie z danej platformy, musimy ciągle opłacać abonament, co jak wspomnieliśmy wyżej – nie jest korzystne w perspektywie długoterminowej. Z drugiej jednak strony z abonamentu możemy zrezygnować w każdym momencie – co dla firmy tworzącej oprogramowanie jest oczywiście niekorzystne. 

Ideą biznesów w modelu SaaS jest więc nie tylko dostarczenie odpowiednich funkcjonalności aplikacji, ale również długoterminowe utrzymanie klienta. Co najczęściej w tym przeszkadza? Niedziałające funkcje i brak zrozumienia działania systemu przez kupującego. 

W języku informatyki możemy spotkać się z pojęciem SLA – które to z angielskiego oznacza “Service Level Agreement”. W prostym tłumaczeniu SLA, czyli umowa gwarancji poziomu świadczonych usług odnosi się do zapewnienia przez dostarczającego system gwarancji poprawności jego działania. W przypadku platform SaaS SLA najczęściej jest rozumiane jako czas, w którym dostawca zapewnia poprawne działanie systemu. 

Zobaczmy to na przykładzie: Załóżmy, że dostawca danego oprogramowania oferuje SLA na poziomie 99% w skali miesiąca. W jaki sposób mamy to rozumieć? Otóż ten wskaźnik nie oznacza nic innego jak to, że przez 99% czasu w miesiącu system będzie w pełni funkcjonalny i dostępny dla jego użytkowników.  Dostawca gwarantuje nam więc, że przez ~737 godzin (dla miesiąca posiadającego 31 dni kalendarzowych) nie będziemy mieli problemów z logowaniem czy używaniem wybranych przez nas funkcji. Jednocześnie, zastrzega on sobie, że ewentualne problemy techniczne mogą występować przez ~6 godzin – czyli 1% czasu w skali miesiąca. 

Niezależnie od tego, czy dany podmiot wykazuje publicznie SLA (a więc posiada w regulaminie zapisy odnośnie gwarantowanego czasu dostępności usługi – oczywiście w przypadku “remisu” zawsze warto wybierać ten system, który takie zapisy posiada), czy też nie, biznesy oparte o model SaaS muszą w zadanym stopniu dbać o stabilność infrastruktury. W przeciwnym wypadku – po prostu stracą klientów. 

Przypomina mi się w tym miejscu awaria, która nastąpiła w marcu 2021 roku u dostawcy serwerów internetowych, spowodowana pożarem we Francuskim Centrum Danych. Pewien popularny na rynku program wspierający sprzedawców e-commerce posiadał swoje serwery właśnie w tym miejscu. Po wybuchu pożaru usługa całkowicie przestała działać. Czy to oznacza, że firma będąca właścicielem programu nie była w żaden sposób przygotowana na taką ewentualność? 

Odpowiedź nie jest niestety czarno biała. Otóż program ten posiadał swoje kopie zapasowe w innym centrum danych. Problem w tym, że centrum to było… dokładnie obok budynku, w którym wybuchł pożar. Awaria “zahaczyła” więc o oba budynki – tym samym powodując braki w działaniu zarówno serwerów głównych, jak i zapasowych. 

Ostatecznie po kilku dniach usługodawca był w stanie uruchomić ponownie system. Pomimo licznych gróźb odnośnie pozwów z tytułu utraconych korzyści, firma przetrwała, a użytkownicy jeszcze bardziej docenili oferowane przez program funkcje – w końcu, gdy go zabrakło, część z nich znalazła się z przysłowiową ręką w nocniku. 

Analizując tą sytuacje, możemy dojść do kilku wniosków – nie skupiając się zupełnie na ocenie poprawności działań w kontekście zabezpieczeń tejże firmy przed katastrofą, faktem jest, że były wprowadzone jakiekolwiek zabezpieczenia. Usługodawca posiadał serwery główne, serwery lustrzane, a oprócz tego dodatkowe kopie danych przesyłane do serwerów lokalnych. W zależności od tego, jaką skalę osiąga Twoja firma, być może posiadasz podobnej klasy rozwiązania – w większości jednak ciężko się z tym spotkać. 

Kluczowe programy uruchomione na zwykłych komputerach biurowych, na których na co dzień pracują ludzie to niestety standard w większości Polskich firm. Brak wykonywania kopii zapasowych ważnych danych czy dokumentów również nie jest czymś rzadko spotykanym. Analogiczna sytuacja, jak opisywany pożar, mogła przecież wystąpić również w Twoim miejscu pracy. Czy wtedy byłbyś w stanie odtworzyć utracone informacje? 

Niewątpliwą więc przewagą systemów SaaS jest brak konieczności dbania o infrastrukturę – samodzielnej konfiguracji serwerów, zatrudniania specjalistów i tworzenia kopii zapasowych. W tym przypadku całość tych usług świadczy firma zewnętrzna – a biznes, który z nich korzysta, może skupić się na tym, na czym zna się najlepiej. 

Wsparcie techniczne 

Kwestie związane ze wsparciem technicznym, a więc sytuacjami, gdy albo nie wiemy, jak użytkować dany program – potrzebujemy swoistego rodzaju instrukcji, poprowadzenia, bądź też takimi, gdy program nie działa, tak jak powinien – to jeden z głównych tematów na który warto zwrócić uwagę przy decydowaniu się na wybrany przez nas produkt. 

Niestety, “czarną owcą” w rodzinie produktów SaaS bardzo często jest wsparcie techniczne – świadczone na bardzo niskim poziomie. Od strony biznesowej nie jest to nieuzasadnione – w końcu w swoich założeniach SaaS ma być tani i masowy. Wysoki poziom wsparcia pojedynczego klienta nie jest po prostu opłacalny. 

W wielu przypadkach w branży pojawia się pojęcie “pierwszej linii supportu” – i kwestii tak zwanego “przebicia się przez nią” – mówimy tutaj o sytuacjach, w których coś nie działa, tak jak powinno, a wsparcie danego programu, jest jakby to powiedzieć… niezbyt pomocne. 

Standardem w branży IT i świadczeniu usług w formie SaaS jest rozdzielenie pracowników tworzących rozwiązanie (programistów) od tych, którzy odpowiadają na pytania (dział wsparcia). W związku z tym, wysyłając dane zapytanie, dobrze jest mieć w głowie, że prawdopodobnie przynajmniej na początku zainteresuje się nim osoba mająca ogólny obraz sytuacji i orientująca się po oferowanych funkcjach – ale nie będąca zaangażowana w złożone szczegóły techniczne. 

Niejednokrotnie spotykałem się z sytuacjami, gdzie to klient musiał najpierw udowodnić danej firmie, iż błąd faktycznie występuje – a nie iż wynika on z nieprawidłowej konfiguracji. Ta “walka”, próba udowodnienia swojej racji jest właśnie tym, co nazywamy “przebiciem się przez pierwszą linię supportu” – czyli sytuacją, gdy zgłoszenie zostanie faktycznie przekazane do osoby posiadającej odpowiednią wiedzę i kompetencje, mogącej zrobić coś z problemem. 

Temat wsparcia technicznego, mówiąc kolokwialnie, jest niczym rzeka – jeżeli w poprzednim punkcie porównaliśmy go do “czarnej owcy”, zobaczmy również przykład “wilka w owczej skórze”. 

Nie tak dawno temu współpracowaliśmy z jedną firmą, przygotowując dla niej rozwiązania indywidualne. Firma ta, na spotkaniu zarządu, zdecydowała się skorzystać z pewnego zagranicznego rozwiązania SaaS. Warto w tym miejscu zaznaczyć, iż rozwiązanie to było swojego rodzaju integratorem – pobierało i przesyłało dane z i do kilku innych platform. Korzystając z formularza internetowego, firma wysłała zapytanie, opisując swoje potrzeby. 

Na odpowiedź nie trzeba było długo czekać – Account Manager (osoba zajmująca się klientami) od razu zaproponował spotkanie z dokładnym rozeznaniem się odnośnie płaszczyzny współpracy. Spotkanie przebiegło znakomicie – nasz klient dowiedział się, że nie tylko będzie mógł zrobić to, na co liczył, ale również wiele więcej. 

Przed rozpoczęciem współpracy kontrahenci odbyli jeszcze kilka spotkań, ustalając, jak będzie przebiegał cały proces. Po tym czasie skontaktowali się z nami – potrzebowali wykonawcy, który połączy ich obecną infrastrukturę z nowo nabytym rozwiązaniem SaaS. 

Rozpoczęliśmy proces integracji – z początku przebiegający gładko i bezproblemowo. Przygotowaliśmy wszystkie niezbędne komponenty systemu połączeniowego, przesłaliśmy dane do systemu SaaS i poinformowaliśmy klienta o statusie. 

To, co wydarzyło się później, ciężko było przewidzieć. 

Chwilę po zakończeniu prac otrzymaliśmy informację zwrotną od klienta – na platformie zewnętrznej (na którą przesyłane są informacje za pomocą rozwiązania SaaS) produkty nie wyświetlają się poprawnie. Sprawdziliśmy konfigurację – z naszej strony wszystko wygląda w porządku. Skontaktowaliśmy się więc w tej sprawie ze wsparciem technicznym omawianego programu. 

W między czasie na platformie SaaS uruchamialiśmy kolejne systemy zewnętrzne. W przypadku praktycznie każdego z nich schemat wyglądał podobnie – za każdym razem, coś było nie tak jak powinno. Wysyłaliśmy więc kolejne zapytania do działu wsparcia technicznego, cierpliwie oczekując na odpowiedź. 

Po kilkunastu dniach dostaliśmy pierwszą z nich – połączenie z platformą zewnętrzną nie leży w gestii wsparcia programu (który to z tą platformą się łączy) i proszą o kontakt z firmą zewnętrzną, która “być może” będzie w stanie pomóc. Dla większości platform dostaliśmy analogiczne komunikaty. Kilkoma zgłoszeniami platforma postanowiła się jednak zająć. 

W sumie udało nam się uzbierać kilkanaście kwestii nie działających zgodnie z obietnicą – zebraliśmy je wszystkie w jeden mail i poprosiliśmy o reakcje. Czekając prawie miesiąc na jakiekolwiek informacje, nasz klient postanowił skontaktować się z Account Managerem. Ten obiecał oznaczyć zgłoszenie jako “P1” – czyli najwyższy priorytet – i skierować sprawę od razu do osób decyzyjnych. Wszyscy mieliśmy nadzieję, że przyniesie to rezultaty. 

Po kilkunastu mailach z pytaniami, jak wygląda status naprawy błędów i kolejnym miesiącu oczekiwania nadal nie mieliśmy żadnych wskazówek – oprócz kilku kolejnych zapewnień, że sprawa została oznaczona jako jeszcze większy priorytet i niedługo ktoś się z nami skontaktuje. Pomimo ponownych prób kontaktu z Account Managerm, ten przestał całkowicie odpowiadać na wiadomości. 

W końcu otrzymaliśmy inną wiadomość – nie związaną ze zmianą priorytetu bądź dodatkowymi pytaniami. Otóż nasze zgłoszenie, po ponad 2 miesiącach zostało zamknięte – system prosi nas o wypełnienie ankiety satysfakcji. 

Z racji braku jakichkolwiek perspektyw, finalnie klient zdecydował się na rezygnację z rozwiązania SaaS i poprosił nas o przygotowanie analogicznej aplikacji indywidualnie dla niego – takiej, którą można by było określić jako działającą. 

Ta sytuacja może wydawać się dosyć ekstremalna – i faktycznie taką jest. W większości przypadków, nawet jeżeli pojawią się określone problemy ze wsparciem klienta – nie powinny one przyjąć aż takiej formy. Zostawiam ją tutaj bardziej jako przestrogę – warto dokładnie sprawdzać, jak funkcjonuje dany system przed podjęciem ostatecznej decyzji. 

Oczywiście, wspomnijmy również o kwestii wsparcia technicznego rozwiązań własnych. Tutaj sytuacja jest trochę bardziej skomplikowana – w zależności od tego, jak funkcjonuje dana firma i program, wsparcie może przyjąć różne formy. Kluczowe są jednak następujące czynniki. 

Po pierwsze, przy decydowaniu się na rozwiązanie własne warto zwrócić uwagę czy w ogóle występuje jakiekolwiek wsparcie. Jeżeli tak – ile ono kosztuje. Wyjątkowo rzadko zdarza się, iż dana firma oferuje wsparcie po przetestowaniu programu – w jego cenie. Ilość możliwych zgłoszeń, poprawek jest nie do ocenienia i wiele biznesów nie byłoby w stanie przetrwać, oferując nielimitowany czas wsparcia. Z reguły, jeżeli już wsparcie takie jest oferowane – pojawia się w formie zadanego okresu czasu po uruchomieniu rozwiązania.  

Zdarzają się również sytuacje, w których brak jest jakiegokolwiek wsparcia czy szkolenia w pakiecie, po dostarczeniu rozwiązania. Rzadziej występują one przy zakupie rozwiązań klasy Enterprise – a więc przy większych, bardziej rozbudowanych programach. O wiele częściej z tego typu sytuacją możemy się spotkać przy mniejszych projektach. 

Weźmy sobie jako przykład sklep internetowy – jeżeli takowy posiadasz, to czy po jego wykonaniu otrzymałeś jakąś instrukcję, w jaki sposób się po nim poruszać? Jak dodawać nowe produkty czy edytować treści? Czy też zostałeś zostawiony samemu sobie z ewentualną możliwością zapytania twórców?  

Jeżeli nie posiadasz sklepu internetowego, a planujesz taki mieć – zwróć uwagę na ten aspekt. 

Po drugie, w przypadku rozwiązań indywidualnych warto od razu zadać sobie pytanie – co, jeżeli nie będziemy “dogadywać się” z daną firmą? Czy ktoś będzie w stanie przejąć projekt? Zapewnić nam wsparcie techniczne w razie problemów? 

W tym punkcie wskazane jest, abyś zorientował się, czy dana firma pracuje w znanych technologiach i czy dostarcza rozwiązanie w formie możliwej do edycji.  

Pamiętam, jak pewnego razu mój znajomy zakupił opcję profesjonalnego sklepu internetowego w wyjątkowo korzystnej cenie – kilkukrotnie niższej niż wartość rynkowa. Gdy pewnego razu poprosił mnie o małą przysługę, skontaktowaliśmy się z twórcą, ponieważ potrzebowaliśmy dostępu do kodu sklepu. Wtedy dowiedzieliśmy się, że nie ma takiej możliwości, bo w rzeczywistości znajomy nie zakupił sklepu… a jedynie abonament, w formie sklepu jako usługi. 

Kiedy więc warto zdecydować się na rozwiązania SaaS? 

Podsumowując – nie istnieje jedna, poprawna odpowiedź czy należy korzystać z rozwiązań SaaS, czy też skupić się tylko na programach indywidualnych. Bazując jednak na tym, co zostało opisane wyżej, na rozwiązania w modelu SaaS polecam zdecydować się, gdy: 

  • Nie chcemy inwestować większych pieniędzy “na start”; 
  • Dziedzina, w której działa dany program wymaga częstych dostosowań, zmian; 
  • Nie posiadamy własnej rozbudowanej infrastruktury IT; 
  • Nie posiadamy specjalistów IT z wybranego zakresu do rozwiązywania określonych problemów z programem; 
  • Chcemy sprawdzić, jak funkcjonuje dana usługa; 
  • Zależy nam na funkcjonalnościach ogólnych, rozwiązujących większość naszych bolączek, niekoniecznie ich wszystkich. 

Przy wybieraniu rozwiązania SaaS powinniśmy zwrócić uwagę na: 

  • Funkcjonowanie wsparcia technicznego; 
  • Możliwości ewentualnej rozbudowy/dostosowania pod nas systemu; 
  • Wskaźnik zwrotu – po jakim czasie rozwiązanie SaaS wyszłoby drożej aniżeli stworzenie analogicznego indywidualnego rozwiązania; 
  • Zakres SLA. 

Dobrze Ci radził

Kacper Dyba – właściciela marki SellPander

Współwłaściciel kilku podmiotów specjalizujących się w zakresie automatyzacji w firmach. Prezes Zarządu KADOCODE SP. Z.O.O, właściciela marki SellPander, firmy oferującej rozwiązania dla sprzedawców e-commerce wspierających procesy przed i po sprzedażowe. Rozwiązania SellPander zdecydowało się się sprawdzić juiż ponad 2000 Polskich i nie tylko firm z segmentu e-commerce. Wśród nich można wyróżnić takie marki jak między innymi Kubota, Tefal, Max Elektro czy X-KOM”. Prezes Zarządu Project Future SP. Z O.O. która zajmuje się tworzeniem indywidualnych rozwiązań programistycznych dla średnich i większych przedsiębiorstw. Współwłaściciel Analitico, firmy specjalizującej się we wdrażaniu rozwiązań Bussines Inteligence pozwalających na kontrolowanie i monitorowanie wszelkich kluczowych danych w przedsiębiorstwie. Propagator ideii Hiperautomatyzacji, która nie tylko pozwala na ogromne oszczędności finansowe, ale również gwarantuje zyskanie olbrzymiej przewagi konkurencyjnej. Personalnie wierzy, że jeżeli coś jeszcze nie zostało zautomatyzowane, to tylko dlatego, że nikt jeszcze nie wymyślił w jaki sposób to zrobić.