Większość projektów wdrożeniowych zaczyna się od jednego pytania: „Czego nam brakuje?”. Jako analitycy zbieramy wymagania, dodajemy nowe pola, budujemy kolejne Flow i wdrażamy nowe obiekty. System rośnie, lista funkcji się zgadza, a kolejne iteracje dowożą to, co zostało zaplanowane. Z perspektywy projektu wszystko wygląda poprawnie.
A potem pojawia się dobrze znany moment. Użytkownicy zaczynają omijać CRM, dane są niekompletne, a lejek sprzedaży przestaje być wiarygodny. W takich sytuacjach naturalną reakcją jest szukanie brakującej funkcjonalności. W praktyce jednak problem rzadko leży w tym, czego system nie ma. Znacznie częściej chodzi o to, jak trudno się z niego korzysta. Innymi słowy: o tarcie.
Czym jest „tarcie” w Salesforce?
Tarcie można rozumieć jako każdy opór poznawczy lub operacyjny, który napotyka użytkownik podczas wykonywania zadania. W przeciwieństwie do klasycznych błędów systemowych nie objawia się ono w sposób oczywisty. Nie blokuje pracy wprost. Jest raczej sumą drobnych, powtarzalnych niedogodności, które z czasem wpływają na zachowanie użytkowników.
To właśnie dlatego jest tak trudne do uchwycenia. System formalnie działa poprawnie, ale użytkownicy zaczynają go omijać, upraszczać sobie pracę poza nim lub odkładać działania „na później”. W efekcie spada jakość danych, a organizacja traci zaufanie do narzędzia, które miało być jej fundamentem. W większości przypadków nie wynika to z braku funkcji, lecz z nadmiernej złożoności w miejscach, które nie powinny jej mieć.
Gdzie ukrywa się tarcie?
W praktyce tarcie najczęściej przyjmuje trzy powtarzalne formy, które można zaobserwować w niemal każdym dojrzałym orgu.
Pierwszą z nich jest tarcie poznawcze, widoczne przede wszystkim w przeładowanym interfejsie. Użytkownik, zamiast skupić się na zadaniu, musi najpierw odfiltrować większość informacji widocznych na ekranie. Klasycznym przykładem jest rekord Opportunity zawierający kilkadziesiąt pól, z których w danym kontekście używanych jest zaledwie kilka. W takiej sytuacji użytkownik przestaje czytać, a zaczyna skanować, ignoruje część informacji i podejmuje decyzje na podstawie niepełnego obrazu. To nie jest efekt „bogatego systemu”, lecz konsekwencja braku priorytetyzacji informacji. Pokazywanie wszystkiego „na wszelki wypadek” bardzo często okazuje się błędem projektowym.
Drugim obszarem jest tarcie procesowe, które najczęściej ujawnia się jako nadmiar kroków koniecznych do wykonania prostej operacji. Zjawisko to bywa określane jako „dług kliknięć” i bardzo często jest tylko powierzchownym objawem głębszego problemu, jakim jest narastający dług techniczny w automatyzacjach. W praktyce objawia się to koniecznością ręcznego przepisywania danych, przechodzeniem przez kilka ekranów w celu wprowadzenia jednej zmiany czy trudną do przewidzenia logiką wynikającą z nakładających się Flow, Apexu i zapytań SOQL. Z czasem prowadzi to do sytuacji, w której użytkownicy zaczynają prowadzić równoległe notatki w Excelu lub komunikatorach, a Salesforce przestaje być narzędziem operacyjnym, a staje się wyłącznie systemem raportowym.
Dobrym przykładem może być proces aktualizacji statusu Opportunity w jednej z firm. W pierwotnej wersji wymagał on przejścia przez kilka ekranów i ręcznego uzupełnienia wielu pól. Po uproszczeniu go do jednej dedykowanej akcji dostępnej bezpośrednio z widoku rekordu liczba kroków została znacząco ograniczona. Efekt był zauważalny nie w samym procesie, lecz w danych: kompletność kluczowych informacji w lejku wzrosła, ponieważ użytkownicy przestali odkładać aktualizację na później.
Trzecią formą jest tarcie informacyjne, które najczęściej ujawnia się w raportach i dashboardach. Rozbudowane zestawienia wskaźników mogą sprawiać wrażenie kompleksowych, ale jeśli nie prowadzą do konkretnej decyzji, nie redukują niepewności. W takich sytuacjach użytkownik otrzymuje dane, ale bez kontekstu działania. W efekcie spada zaufanie do raportów, a wraz z nim motywacja do dbania o jakość danych wejściowych. Problem nie polega na braku informacji, lecz na braku ich interpretacji w kontekście realnych decyzji biznesowych.
Jak mierzyć tarcie?
Jednym z powodów, dla których tarcie bywa ignorowane, jest brak oczywistych metryk. Standardowe wskaźniki adopcji, takie jak liczba logowań, nie oddają jakości doświadczenia użytkownika. Warto więc sięgnąć po bardziej pośrednie sygnały, które pozwalają zrozumieć, jak system jest faktycznie używany.
Przykładem może być kompletność pól opcjonalnych. Jeśli użytkownicy konsekwentnie wypełniają wyłącznie pola wymagane, może to oznaczać, że interfejs jest zbyt złożony lub nieintuicyjny. Podobnie działa analiza czasu spędzanego na poszczególnych etapach procesu (Time-in-Stage), gdzie długie przestoje często nie wynikają z realnych opóźnień biznesowych, lecz z kosztu operacyjnego samej zmiany statusu. Warto również obserwować wykorzystanie prywatnych notatek i nieustrukturyzowanych zadań. Ich rosnąca liczba przy jednoczesnym braku danych w polach strukturalnych jest wyraźnym sygnałem, że użytkownicy omijają system, zamiast z nim współpracować.
Rola analityka: od budowniczego do inżyniera wydajności
W wielu organizacjach rola analityka nadal jest postrzegana przez pryzmat liczby dostarczonych funkcji. Tymczasem w dojrzałych systemach coraz większą wartością staje się umiejętność upraszczania.
Zamiast dążyć do kompletności interfejsu, lepiej skupić się na budowaniu kontekstu. Rozwiązania takie jak Dynamic Forms czy Dynamic Actions pozwalają dostosować widok do aktualnego etapu procesu i roli użytkownika, ograniczając liczbę elementów widocznych jednocześnie. Równolegle rośnie znaczenie rozwiązań wspierających użytkownika w czasie rzeczywistym, takich jak In-App Guidance, które przenoszą wiedzę z dokumentacji bezpośrednio do momentu działania.
Istotną rolę zaczynają odgrywać również mechanizmy automatyzacji oparte na AI, które przejmują część zadań operacyjnych, takich jak podsumowywanie komunikacji czy uzupełnianie danych. W tym kontekście dobrze zaprojektowany system nie jest tym, który wymaga od użytkownika więcej pracy, lecz tym, który tę pracę redukuje.
Podsumowanie
W systemach klasy enterprise problemem rzadko jest brak funkcjonalności. Znacznie częściej jest nim opór, który system stawia użytkownikowi w codziennej pracy. Analiza tarcia pozwala ten opór zidentyfikować i świadomie redukować.
Nie jest to jedynie kwestia doświadczenia użytkownika w sensie UX. To bezpośredni efekt biznesowy: lepsza adopcja, wyższa jakość danych i większa wiarygodność procesów, które na tych danych się opierają. W tym sensie upraszczanie systemu nie jest rezygnacją z jego możliwości, lecz warunkiem ich realnego wykorzystania.
