Click-not-code, czyli jak programować nie programując

Chyba każdy, kto ma do czynienia z informatyką słyszał o książce Niklausa Wirtha ,,Algorytmy + struktury danych = programy’’. Chociaż ukazała się w 1976 roku, do dziś nie straciła aktualności. W Polsce doczekała się sześciu wznowień, dzięki czemu kolejne pokolenia studentów mogą uczyć się z niej dobrych praktyk programowania. Tytuł przewrotnie nie wspomina o kodowaniu - a my skupimy się na tym, czy rzeczywiście możliwe jest stworzenie programu, w którym nie będzie ani jednej linijki kodu.

Studium przypadku: koncern mediowy

Z roku 1976 przenieśmy się w czasy bardziej nam współczesne, aby przyjrzeć się bliżej pewnej dużej firmie z branży mediowej. Dystrybucja filmów to jedna z wielu rodzajów jej działalności. Kupowane od producentów tytuły są rozprowadzane do różnych krajów, na różnych nośnikach: do kin, do sieci telewizji kablowych, na DVD, BlueRay, czy do serwisów VoD. Proces utrudnia fakt, że w niektórych krajach licencja może obejmować tylko wybrane metody dystrybucji, a podczas negocjowania warunków zakupu trzeba przewidzieć spodziewane przychody, aby ocenić opłacalność całego przedsięwzięcia. Dodajmy, że należy jeszcze zaprojektować plakaty i okładki, zlecić tłumaczenia, nagrać dubbing i wyprodukować nośniki. Zanim wybierzemy się do kina na kolejną część Minionków, czy obejrzymy nowe odcinki Star Trek wielu ludzi wykona dużo pracy, biorąc udział w długim, złożonym procesie.

Aby go usprawnić, z pomocą PwC przygotowano i wdrożono system wspierający cały cykl - od pierwszego zainteresowania przez negocjacje zakupu i przygotowanie treści, aż do zakończenia dystrybucji. W rozwiązaniu wykorzystana została dostosowana do potrzeb i wymagań firmy platforma Salesforce App Cloud, a w ciągu kilku miesięcy powstała aplikacja obsługująca ten specyficzny rodzaj działalności. Można śmiało ją nazwać programem, choć nie napisano przy niej kodu.

Poznajmy Salesforce

Aby lepiej zrozumieć, w jaki sposób powstała aplikacja, należy się kilka słów wyjaśnienia. Firma Salesforce.com zdobyła rynek swoim produktem wspomagającym procesy sprzedaży o zbliżonej nazwie: Salesforce. Dziś jej ofercie znajduje się cała rodzina produktów - ale wymienimy te podstawowe.

Najbardziej rozpoznawalny jest Salesforce Sales Cloud. Znajdziemy tu wszelkie funkcjonalności przydatne w procesie sprzedaży: zarządzanie kontami klientów, zespołem sprzedawców oraz ich strukturą, obsługę potencjalnych klientów i szans sprzedażowych, planowanie i śledzenie aktywności, tworzenie ofert cenowych, analizę prognoz sprzedaży. Wiele funkcji ma na celu zwiększenie produktywności handlowców przez automatyzację typowych, powtarzalnych czynności oraz poprawienie widoczności procesów sprzedaży na różnych etapach cyklu. Sztuczna inteligencja analizuje historyczne dane o wygranych i przegranych, aby wskazywać szanse sprzedażowe o większym prawdopodobieństwie wygranej i podpowiadać działania, które będą najbardziej skuteczne na danym etapie.  

Salesforce Service Cloud koncentruje się na wsparciu procesów obsługi klienta. Wspomaga pracę agentów call center z wykorzystaniem różnorodnych kanałów komunikacji. Monitoruje spełnienie założonych norm czasu reakcji (tzw. SLA - Service Level Agreement) i skraca obsługę zgłoszeń, podsuwając sugestie rozwiązań wyszukanych w bazie wiedzy - które można następnie wysłać klientowi jednym kliknięciem. Sztuczna inteligencja analizuje pytania klientów i udziela odpowiedzi na podstawie historii wcześniejszych odpowiedzi agentów.

Obydwa produkty mogą być wzbogacone o raporty, wykresy pogrupowane w dashboardy menedżerskie, szablony komunikacji, a także automatyzację procesów i obsługę własnych dowolnych danych. Wszystkie te elementy tworzą platformę Salesforce - część produktów Sales Cloud i Service Cloud umożliwiającą rozbudowę standardowych funkcji. Może też występować ona samodzielnie jako odrębny produkt o nazwie Salesforce App Cloud.

Specyfika działalności wspomnianego koncernu mediowego różni się od typowej sprzedaży i obsługi klienta, dlatego do budowy aplikacji posłużyła nam właśnie Salesforce App Cloud. Po przeprowadzeniu analizy przygotowaliśmy koncepcję rozwiązania. Jej podstawą był projekt modelu danych.

Struktury danych

Dane w Salesforce są przechowywane w formie obiektów (objects) posiadających atrybuty (pola - fields) i powiązanych relacjami. Platforma umożliwia pracę na logicznym modelu danych bardzo bliskim biznesowemu - co pozwala zapomnieć o szczegółach fizycznego sposobu składowania danych w bazie.

W strukturze danych Salesforce dostępnej dla użytkownika możemy wyróżnić dwa typy obiektów: standardowe i niestandardowe.

Obiekty standardowe są częścią pakietu Salesforce. Nie można ich usunąć, ani zmieniać definicji, tak jak i pól standardowych zdefiniowanych dla każdego obiektu. Można zmienić ich etykiety, albo sprawić, żeby w ogóle się nie wyświetlały. Możliwe jest dodanie własnego pola niestandardowego - w ten sposób mamy możliwość pewnego dostosowania standardowych obiektów do własnych potrzeb. Przykładami obiektów standardowych są: Klient (Account), Kontakt (Contact), Szansa Sprzedaży (Opportunity), Oferta (Quote), Sprawa (Case). W projekcie naszego systemu zastosowanie znalazły tylko dwa obiekty standardowe: Klient oraz Kontakt.

Resztę modelu danych zbudowaliśmy za pomocą obiektów niestandardowych. Tworzy się je w sposób deklaratywny przez wypełnianie formatek lub za pomocą graficznego narzędzia Schema Builder. Mogą mieć dowolne nazwy - z wyłączeniem nazw obiektów standardowych i niektórych słów kluczowych. Wykorzystywane są do przechowywania wszelkich danych niepasujących do obiektów standardowych, takich jak: projekt zakupowy, projekt dystrybucji, terytorium dystrybucji, informacje finansowe, informacje techniczne, itp.

Do każdego obiektu - zarówno standardowego, jak i niestandardowego - można dodawać własne pola. Twórca aplikacji ma do dyspozycji ich kilka rodzajów.

Zwykłe pola informacyjne służą do przechowywania prostych informacji. Dostępne typy danych to tekst, pole tekstowe, liczba dziesiętna (dla liczb całkowitych nie ma oddzielnego typu danych - definiuje się liczbę miejsc po przecinku równą zeru), data, data i czas, czas, oraz wartości logiczne.

Listy wyboru to odmiana pola tekstowego. Pozwala wybierać tylko spośród zdefiniowanych wcześniej wartości. Listy mogą być jednokrotnego lub wielokrotnego wyboru. Jeżeli ten sam zestaw wartości będzie stosowany w kilku różnych miejscach, można listę zdefiniować globalnie.

Pola definiujące relacje przez wskazanie klucza obiektu powiązanego - przy czym można określić dodatkowe kryteria zawężające możliwość wyboru do określonej grupy.  Dzięki temu w polu ,,Konkurencja” można wybrać tylko firmy oznaczone jako ,,Konkurent”.

Pola typu formuła są wyliczane automatycznie na podstawie wartości zapisanych w innych polach. W formułach można się odwoływać zarówno do pól zwykłych, jak i do innych pól typu formuła z tego samego obiektu lub z powiązanych obiektów nadrzędnych (parent). Można także stosować funkcje.

Długie pola tekstowe oraz pola typu rtf (rich text), w których można przechowywać długie, sformatowane teksty

Pola sumujące (roll-up summary) służą do agregacji danych liczbowych z rekordów obiektów podrzędnych (typu child). Możliwe są tu następujące operacje: liczba rekordów, suma, średnia, wartość maksymalna i minimalna. Można agregować dane tylko z niektórych rekordów - na podstawie zdefiniowanego warunku.

Algorytmy

Jak wiadomo, same dane to nie wszystko. Jeden ze sposobów przetwarzania danych już znamy - pola typu formuła - jednak są one dalece niewystarczające. Do pełnego odwzorowania procesów Klienta w systemie musieliśmy zastosować rozgałęzienia decyzyjne oraz iteracyjne wykonywanie operacji w pętli. W tym celu wykorzystaliśmy oferowane przez Salesforce narzędzia do automatyzacji procesów: Workflow Rules, Process Builder, Visual Flow oraz Approval Process.

Workflow Rules to najprostsze mechanizmy. Ich działanie polega na wykonaniu pewnej akcji pod wpływem zmian wartości zapisanych w rekordzie.  Są wywoływane podczas tworzenia lub edycji rekordu. Następnie sprawdzany jest warunek (rule). Jeżeli jest spełniony - wykonywana jest pewna akcja: ustawianie zawartości pola (konkretnej wartości lub wyniku formuły), wysłanie emaila lub stworzenie zadania przypisanego do określonej osoby. Dobrze ilustruje to zapis:

Za każdym razem gdy <rekord obiektu jest tworzony lub edytowany> 
sprawdź warunek
     Jeżeli <spełniony jest warunek> to: {
          Wykonaj akcję 1
          Wykonaj akcję 2
                …
          Wykonaj akcję n
     }

Workflow Rules są bardzo proste. Sprawdzany jest tylko jeden warunek, a lista dostępnych akcji jest ograniczona. Ma to swoje zalety: bardzo prosta konfiguracja i szybkość wykonywania samej reguły - co ma znaczenie przy masowej aktualizacji wielu rekordów jednocześnie. Jeżeli chcemy wykonać różne akcje dla różnych warunków, należy utworzyć kilka reguł workflow. Trzeba wtedy jednak uważać na zależności między nimi, gdyż kolejność wykonywania reguł jest przypadkowa.

W przypadku złożonych warunków, bardziej odpowiednim narzędziem będzie Process Builder (kreator procesów). Zasada działania jest podobna do Workflow Rules, ale możliwości konfiguracyjne znacznie bogatsze. Można zdefiniować kilka warunków wywołania akcji, a lista dostępnych czynności jest dłuższa: oprócz zmian zawartości pól, wysyłania emaili i zakładania zadań, można tworzyć nowe rekordy, przesyłać rekord do zatwierdzenia lub wywoływać kolejne procesy. Ciekawą własnością jest możliwość jednoczesnej aktualizacji wszystkich lub wybranych powiązanych rekordów podrzędnych (typu child).

Działanie Process Buildera obrazuje poniższy schemat: 

Za każdym razem gdy <rekord obiektu jest tworzony lub edytowany> {

     Jeżeli <spełniony jest warunek 1> to: {
          Wykonaj akcję 11, akcję 12, …, akcję 1n
          Zakończ proces lub przejdź do sprawdzania następnego warunku 
     }

     Jeżeli <spełniony jest warunek 2> to: {
          Wykonaj akcję 21, akcję 22, …, akcję 2n
          Zakończ proces lub przejdź do sprawdzania następnego warunku 
     }
     ....
     Jeżeli <spełniony jest warunek m> to: {
          Wykonaj akcję m1, akcję m2, …, akcję mn
          Zakończ proces
     }

}

Zarówno Workflow Rules, jak i Process Builder pozwalają zdefiniować akcje wykonywane po pewnym czasie - na przykład wysłać przypominający email po dwóch tygodniach od złożenia oferty lub utworzyć zadanie na 30 dni przed upływem terminu ważności kontraktu.

Oba mechanizmy pozwalają zautomatyzować niektóre - choć nie wszystkie - czynności. Widać, że struktura algorytmu jest liniowa - czynności wykonywane są jedna po drugiej i mogą dotyczyć tylko rekordu, który wywołał proces lub któregoś z rekordów powiązanych. Nie można wyszukiwać rekordów, ani ich usuwać. Nie można też uruchomić procesu na życzenie użytkownika - procesy Workflow Rules oraz Process Builder są wywoływane tylko podczas tworzenia lub edycji rekordów. Czasem może być to wygodne, ale czasami bywa ograniczeniem.

Tych niedogodności pozbawiony jest kolejny mechanizm automatyzacji procesów: Visual Flow. Twórca aplikacji ma tu do dyspozycji wszystkie brakujące funkcjonalności: ekrany do komunikacji z użytkownikiem (wyświetlanie komunikatów i wprowadzanie danych), zmienne, podstawienia, instrukcje w pętli oraz cztery podstawowe operacje na danych: tworzenie, wyszukiwanie, aktualizację i usuwanie. Za pomocą Visual Flow można zapisać praktycznie dowolny algorytm i niepotrzebna jest przy tym znajomość żadnego języka programowania. Praca w tym narzędziu odbywa się metodą ,,przeciągnij i upuść” i przypomina rysowanie diagramów procesów. Nie sposób opisać tu wszystkich możliwości Visual Flow, dlatego poświęcimy mu oddzielny artykuł.

Kluczowe elementy projektu zakupowego to analiza warunków kontraktu oraz decyzja o jego przyjęciu i skierowaniu filmu do dalszej dystrybucji. U naszego Klienta w proces ten zaangażowanych jest kilka działów analizujących warunki kontraktu pod względem finansowym, technicznym i prawnym, oraz kierownictwo firmy podejmujące decyzje na podstawie otrzymanych rekomendacji. Zależnie od wielkości kontraktu, końcowa decyzja jest podejmowana przez dwie do sześciu osób.

Aby zrealizować to wymaganie wykorzystaliśmy specjalizowany mechanizm kreatora procesów akceptacji - Approval Process. Za jego pomocą mogliśmy zdefiniować ścieżki akceptacji, pozwalające automatycznie kierować rekordy do właściwych decydentów na podstawie spełnienia określonych warunków, jak również zdefiniować odpowiednie reguły akceptacji wieloosobowej: jedna osoby z grupy, wszystkie osoby z grupy, lub akceptacja po kolei. Każdy akceptujący, kiedy przychodzi jego kolej, otrzymuje powiadomienie z najważniejszymi informacjami potrzebnymi do podjęcia decyzji. W razie potrzeby może zapoznać się ze wszystkimi szczegółami kontraktu oraz rekomendacjami poprzednich akceptujących, a następnie zatwierdzić bądź odrzucić kontrakt. Akceptacja może być wykonana z urządzenia mobilnego - a ze względu na dużą ilość danych używane są iPady.

Click or Code?

Mimo bogactwa opisanych narzędzi konfiguracyjnych, czasami zachodzi konieczność napisania fragmentu kodu - Salesforce dopuszcza i taką możliwość. Służy do tego dedykowany język programowania Apex, przypominający składnią Javę. Za jego pomocą oprogramowuje się funkcje, które trudno zrealizować w inny sposób - na przykład integrację z innymi systemami, szczególne wymagania dotyczące interfejsu użytkownika lub masowe operacje na dużej ilości danych. We wdrożeniu biorą udział dwie grupy konsultantów: eksperci od konfiguracji oraz programiści. W środowisku nazywa się ich czasem clickers oraz coders.

W wielu przypadkach większość wdrożenia można zrealizować tylko za pomocą konfiguracji, bez konieczności kodowania.  W naszym projekcie niemal całość rozwiązania została wykonana przez ,,klikersów” opisanymi metodami konfiguracyjnymi. Tylko jedna funkcja wymagała napisania kodu: pobieranie zawartości z pliku Excel w celu zapisania jej do rekordu Salesforce. Można więc stwierdzić, że tytułowe określenie click-not-code jest tu jak najbardziej na miejscu, a postawiona na wstępie teza znajduje potwierdzenie - choć pewnie niektórzy ,,kodersi” mogliby polemizować...