XaaS Marketer

XaaS, czyli Anything as a Service w kontekście badań marketingowych oznacza dostarczenie czegoś więcej niż tylko wyników badania w formie Powerpoint.

To dostarczenie całego narzędzia jako usługi czy platformy. Jest to rozwiązanie, dzięki któremu badacz może przyspieszyć i zautomatyzować swoją pracę, a Klient może zacząć sam analizować swoje dane.

Czasem warto wyjść poza schemat i zadać sobie pytania: „Czy moja usługa może być sprzedawana w kiosku?” albo „Czy mój produkt może stać się usługą?”.

Łatwo dać się złapać w pułapkę i odpowiedzieć sobie „nie”. Chwile potem konkurent właśnie to robi. Takie pytania musiała swego czasu zadać sobie branża telekomunikacyjna. Czasy telefonów stacjonarnych (jeszcze z analogowymi pokrętłami) już minęły, bo pojawiły się telefony komórkowe. Natomiast na początku nadal były to bardzo podobnie skrojone usługi różniące się urządzeniem. I w którymś momencie pojawiły się usługi typu prepaid. Teraz, by mieć swój numer telefonu, nie trzeba zapisywać się do komitetu kolejkowego, tylko kupić starter w kiosku za parę złotych.

O ile ten przykład może jest już dla nas dość oczywisty, to może zastanówmy się nad innymi usługami? Na przykład ubezpieczenie samochodu. Czasem pojawiają się absurdy, że wysokość ubezpieczenia zależy od koloru samochodu (czerwone okazywały się być bardziej niebezpieczne), ale taryfikacja jest nadana z góry. Kalkulacja składki oparta jest o statystyki dotyczące właściciela pojazdu, rodzaju pojazdu, historii szkód i wielu innych. Statystyki, a nie dane. To już kwestia czasu, kiedy w Polsce spowszechnieją usługi Pay As You Drive czy Pay How You Drive (przykładem może być firma metromile). Ubezpieczenia oparte o zbieranie i analizowanie dużych zbiorów danych oceniających charakter jazdy.

Dlaczego kampanie przepalają budżet? 7 najczęstszych błędów w media mixie

Podobną linię myślenia musieli kiedyś przejść właściciele infrastruktur IT (upraszczając – właściciele serwerów), którzy postanowili udostępnić swoje zasoby, tworząc usługi IaaS (Infrastructure As A Service).

Programiści też chcieli skoncentrować się na samym programowaniu i nie martwić się o platformę, na której tworzyli swoje aplikacje (i w ten sposób powstało PaaS – Platform As A Service).

Oczywiście same aplikacje, które kojarzone były z programem instalowanymi na komputerze przeszły podobną ewolucję i dzisiaj mówimy o Software As A Service.

Połączenie tych wydarzeń zaowocowało chmurą – idealnym miejscem na dostarczenie usług SaaS. Powstanie usług SaaS to typowe win-win. Twórca programu nie musi martwić się o kwestie utrzymania systemu z punktu widzenia IT i może skoncentrować się samym rozwiązaniu. Dostawca platformy ma ogromne korzyści skali.

A co ma użytkownik?

Użytkownik otrzymuje:

• Aplikację dostępną online
• Działająca bardzo szybko
• Bezpieczną

Myślę, że można założyć, że większość dzisiejszych startupów próbuje wejść w rynek SaaS wykorzystując technologie Amazona (AWS), Googlea czy Microsoft (Azure).

Z powyższych technologii korzystać też mogą badacze marketingowi. Praca badacza w wybranych miejscach jest czynnością powtarzalną.  Dlatego powstają różnego rodzaju makra czy programy, które tą pracę mają przyspieszyć. No bo jeśli czynność jest powtarzalna, to znaczy, że można ją zaprogramować. Jak maszynę.

Wynikiem pracy badawczej jest raport. Plik z rozszereniem pptx przesyłany drogą pocztową. W obliczu dostępnej technologii brzmi to trochę jak przesyłanie deklaracji PIT pocztą analogową: można, ale po co?

Prześledźmy proces badania ankieterskiego oceniającego efektywność kampanii mediowej.

1. Klient chce poznać wpływ komunikacji na wybrane parametry marki takie jak świadomość, wizerunek, intencje.
2. Tworzona jest ankieta – bardzo podobna do wszystkich innych ankiet.
3. Ankieta jest kodowana w odpowiednim systemie (własnym dostawcy fieldworku).
4. Emitowane są zaproszenia do ankiet (w formie display w przypadku RTS lub jako zaproszenie do udziału w badaniu w przypadku badań panelowych).
5. Respondenci udzielają odpowiedzi.
6. Dane są przekazywane do działu badawczego.
7. Dział analizuje dane wyliczając odpowiednie statystyki.
8. Powstaje… raport.

Każdy z tych etapów można próbować zautomatyzować:

1. Klient zaznacza w panelu, że ta konkretna kampania ma być zbadana.
2. Ankieta tworzona jest automatycznie, gdyż składa się z powtarzalnych części.
3. Punkt trzeci jest już niepotrzebny, bo zadział się wcześniej.
4. To również odbywa się automatycznie w momencie stworzenia ankiety – łącząc się z systemem programmatic albo z agregatorem paneli internetowych.
5. Tego nie chcemy automatyzować!
6. Dane są po prostu dostępne w bazie danych.
7. Analizy z uwagi na powtarzalność ankiety są również powtarzalne.
8. Wyniki dostępne są w postaci dostępnych online raportów. 

Z punktu widzenia Klienta może to być jedna strona internetowa, gdzie po zaznaczeniu kampanii do zbadania pozostaje już tylko czekać na dostępne (w tym samym miejscu) wyniki.

Warto zwrócić uwagę na relację między firmą badawczą, a firmą wykonującą fieldwork. Tutaj również może być wykorzystany model SaaS na przykład za pomocą pośrednika, którego produktem jest zebranie paneli internetowych w jednym miejscu, dobór próby, wycena i przeprowadzenie badania.

Taki system niesie za sobą szybsze przekazanie wyników do Klienta z jednej strony, z drugiej poświęcenie większej uwagi na wyciąganie wniosków z racji zaoszczędzonego czasu.

W podobny sposób można podejść do każdego badania, czy oferowanego produktu. Proces taki polega na:

• Identyfikacji powtarzalnych czynności
• Opisania za pomocą algorytmów oraz automatyzacji tych czynności
• Połączenia elementów procesu
• Połączenia technologicznego pomiędzy wykorzystywanymi systemami za pomocą API (czyli języka wykorzystywanego do komunikacji między maszynami)
• Stworzenia aplikacji/rozwiązania w systemie SaaS. Najlepiej samoobsługowego i dostępnego przez Internet. 

Niesie to poważniejsze implikacje dla obecnych działów badawczych. To już nie są zespoły tylko badaczy. To zespoły, w których skład wchodzą:

• Badacze
• Analitycy danych
• Developerzy
• Administratorzy IT
• Architekci
• UXowcy
• Project Manager

Chociaż może badacz to już niekoniecznie ten wyraz. Może bardziej data scientist? Czyli osoba, która rozumie podstawy programowania, porusza się w świecie R i Python, nie boi się SQL, jednocześnie mając spojrzenie na szerszy problem.

Bardzo istotni w procesie badawczym stają się developerzy oraz architekci. Ponieważ w przypadku usług SaaS uwzględnić trzeba nie tylko komunikację między ludźmi, ale również między systemami. W powyższym przykładzie pojawia się warstwa komunikacji pomiędzy platformą dla Klienta, platformą firmy fieldworkowej oraz narzędziem ankieterskim. Nie ma tutaj ściągania plików z wynikami, przerzucania ich do innego systemu w celu analizy. Tutaj całą pracę wykonują komputery komunikując się miedzy sobą.

Konwersja obecnego produktu badawczego na usługę SaaS wiąże się z wyzwaniami i zagrożeniami.

1. Model biznesowy

Wycenianie usług SaaS różni się diametralnie od wycen produktów badawczych. Wycena nie powstaje na potrzeby konkretnego produktu. Należy traktować ją jako inwestycję, gdzie break even może być odsunięty w czasie o rok od momentu wdrożenia. Po stronie kosztowej powinna uwzględniać kwestie związane z architekturą (czas procesorów, przestrzenie dyskowe, oprogramowanie) oraz kwestie utrzymaniowe (wprowadzanie poprawek, nowych funkcjonalności). Po stronie przychodowej nie mówimy o produktach a na przykład o wycenie per zalogowana osoba. Oczywiście usługa może być zbudowana modułowo, gdzie za dodatkowe funkcjonalności pobierana jest dodatkowa opłata.

2. Prędkość wprowadzania zmian

Przy tworzeniu usług SaaS warto pamiętać o tym, że wprowadzenie zmiany może obejmować wszystkie elementy architektury. Innymi słowy ciężko to porównać do zmiany wykresu w powerpoincie, co można zrobić od razu. Wprowadzenie dodatkowych funkcjonalności musi być elementem pracy nad systemem. Tutaj dużym wyzwaniem jest zachowanie równowagi pomiędzy elastycznością systemu a jego prostotą. Łatwo zrobić narzędzie, które będzie miało nieskończone możliwości analizy, ale straci przy okazji intuicyjność.

3. Zespół

Ponieważ zupełnie zmieniamy paradygmat pracy pociąga to za sobą spore wyzwania od zespołu. Wymaga od wszystkich członków zrozumienia problemu jako całości. Od badaczy podstaw związanych z architekturą systemów, od developerów spojrzenia biznesowego na problem do rozwiązania. Pojawiają się narzędzia znane ze świata software housów: metodologia SCRUM, JIRA, github, Confluence, Bitbucket. Dzięki tym narzędziom łatwiej zrozumieć zależności pomiędzy elementami usługi. Jest to bardzo ważne, ponieważ zmiany w jednym miejscu pociągają za sobą zmiany w drugim. Dlatego badacz przestaje funkcjonować w świecie draftów i finali, a w świecie dev/test/prod. 

Myślę, że warto przyjrzeć się obecnym produktom i małymi krokami zacząć budować usługi. Rozpisać proces na zadania atomowe. Prześledzić wykorzystywane systemy i programy oraz ścieżkę danych i związanych z nimi analitykę. Zacząć budować klocki (mikrousługi albo gotowe frameworki), które potem można ze sobą połączyć. Klocki mogą dotyczyć wizualizacji danych (D3.js, Tableau, Qlik), budowania CMS (wordpress, Joomla, Umbraco), czy platformy (AWS, Heroku, Google).

Czekają nas ciekawe czasy, gdzie technologia stanowi serce dostarczania wyników z badań.