4 Gdy w usługach pojawia się AI. Ewolucja schematu usługi
Narzędzia sztucznej inteligencji wspierają coraz więcej interakcji między klientem a usługodawcą. Ułatwiają wyszukiwanie i porównywanie ofert, generują zapytania i odpowiedzi oraz automatyzują powtarzalne czynności. W wielu przypadkach stają się aktywnymi uczestnikami procesu i wykonują zadania w zastępstwie człowieka. Klasyczny schemat usługi (service blueprint)1 ma problem z pokazaniem ich roli oraz konsekwencji dla doświadczenia klienta i pracownika.
Wprowadzenie
Schemat usługi jest jednym z najbardziej rozpoznawalnych narzędzi osób projektujących usługi. Przedstawia usługę jako sekwencję działań w czasie oraz ujawnia powiązania między doświadczeniem klienta a procesami w organizacji, które to doświadczenie umożliwiają.
Szybki rozwój systemów generatywnej inteligencji zmienia charakter usług. Część doświadczenia klienta zaczyna tworzyć się w warstwie technologicznej poza kontrolą organizacji – i choć nie jest to nowość, bo pośrednicy, sieci partnerów czy agregatory są obecne w ekosystemach usługowych od dawna, to skala i głębokość zmian sprawiają, że tradycyjny service blueprint niewystarczająco dokładnie opisuje rzeczywistość.
Celem artykułu jest zaproponowanie rozszerzeń szablonu schematu usługi, które pozwolą mu lepiej wspierać współpracę między projektantami, właścicielami biznesowymi i przedstawicielami IT przy badaniu, tworzeniu, wdrażaniu i rozwoju usług. Zachowuję znaną logikę narzędzia, ale dodaję nowe warstwy opisu, które pozwalają wydobyć na powierzchnię nowych aktorów, nowe zależności i ryzyka.
Cztery dekady ze schematem usługi
Schemat usługi powstał w kontekście badań nad projektowaniem usług i zarządzaniem nimi prowadzonych w latach 70. i 80. XX wieku. Jednym z ważnych obszarów refleksji była specyfika usług jako procesów współtworzonych przez klienta i organizację.
Na tym tle G. Lynn Shostack zaproponowała w 1984 roku schemat usługi jako przedstawienia procesu świadczenia usługi w formie diagramu blokowego – sekwencję działań rozłożonych w czasie i podzielonych na te widoczne i niewidoczne dla klienta2. Część proponowanych przez Shostack oznaczeń, na przykład podział na elementy produktowe i usługowe, nie jest współcześnie powszechnie stosowana, natomiast pojawiły się dodatkowe warstwy opisu.
Nawet najbardziej popularne podręczniki, w których można znaleźć szablon schematu usługi, różnią się znacznie pod tym względem. Propozycja z Service Design: From Insights to Implementation3 wyraźnie rozdziela od siebie różne kanały obsługowe oraz funkcje w ramach organizacji, przez co zaczyna przypominać mapę podróży klienta, podczas gdy w Designing the Invisible: Introduction to Service Design4, This Is Service Design Thinking5 oraz Mapowaniu wrażeń6 tych podziałów jest znacznie mniej.
W swojej pracy za punkt wyjścia przyjąłem to drugie podejście, spopularyzowane przez publikacje internetowe, między innymi na stronach Nielsen Norman Group7 i Interaction Design Foundation8. W szablonach tych oddziela się:
- działania klienta (customer actions);
- działania pierwszej linii, czyli widoczne dla klienta (frontstage);
- działania zaplecza, czyli niewidoczne dla klienta (backstage);
- procesy wsparcia (support processes).
Pojawiają się również typowe czasy trwania poszczególnych etapów procesu, fizyczne elementy usługi lub punkty styku, a także bardziej szczegółowe opracowanie warstwy działań pierwszej linii i zaplecza – na przykład podział na technologię i pracowników albo na warstwy odpowiedzialności różnych funkcji biznesowych w organizacji.
Jedną z przyczyn trwałej popularności tego narzędzia jest jego zdolność do łączenia perspektyw, które w organizacjach często funkcjonują oddzielnie. Na schemacie usługi spotykają się doświadczenia klienta przedstawiane przez specjalistów CX (customer experience) na mapach podróży klienta oraz procesy wewnętrzne w organizacji, starannie opisywane przez analityków biznesowych i IT na mapach procesów biznesowych.
Schemat usługi bywa przedmiotem zasadnej krytyki9. Niezależnie od tego, czy jest wykorzystywany do mapowania i poprawiania istniejącej usługi, czy też prototypowania nowej, pomaga zauważyć powiązania oraz zidentyfikować miejsca, w których mogą pojawić się problemy.
Przyspieszona ewolucja usług z AI
Kiedy piszę o obecności systemów AI w usługach, mam na myśli więcej niż tylko generatywną sztuczną inteligencję i duże modele językowe. Lepszego odzwierciedlenia w procesach wymagają też choćby rozwiązania z kategorii rozpoznawania obrazu, rozpoznawania mowy, systemy rekomendacyjne czy narzędzia klasyfikacji dokumentów.
W przeciwieństwie do wielu wcześniejszych rozwiązań IT systemy te nie pełnią wyłącznie funkcji infrastruktury, która wspiera działania ludzi. Tradycyjny podział na 3 lub 4 P service designu – people (ludzie), props (rekwizyty), processes (procesy) i places (miejsca)10 – nie uwzględnia pojawienia się systemów na ich pograniczu, mniej lub bardziej samodzielnie analizujących, interpretujących, decydujących i wykonujących inne działania, które wcześniej należały do ludzi lub wymagały ich bezpośredniej interpretacji i reakcji.
Integracja rozwiązań AI może mieć różny charakter zależnie od poziomu niezależności od człowieka. Na potrzeby tego artykułu ujmuję to uproszczonym podziałem na asystentów i agentów, jednak możliwe są znacznie bardziej złożone typologie11.
Zarówno klient, jak i pracownik mogą korzystać z asysty AI, gdy na przykład wyszukują i syntetyzują informacje, porównują opcje, generują zapytania lub odpowiedzi czy automatycznie wypełniają pola w systemie customer relationship management (CRM, oprogramowanie wspierające procesy na styku klient – organizacja) na podstawie pliku PDF załączonego do maila. Ostateczna decyzja (i odpowiedzialność) pozostaje po stronie człowieka.
W drugim wypadku to człowiek inicjuje proces, a agent AI przechodzi przez proces aż do końca samodzielnie, albo realizując założony scenariusz, albo autonomicznie podejmując decyzje. W takiej sytuacji kroki procesu zaprojektowane z myślą o ludzkim użytkowniku tracą na znaczeniu, a o doświadczeniu klienta (lub pracownika) decydują wyłącznie rezultaty działania agenta. Podobnie jak w wypadku asystentów, agenci mogą działać na zlecenie klienta (na przykład wyszukać, wybrać i zamówić produkt na prośbę swojego użytkownika), jak i organizacji (na przykład przeanalizować reklamację, poprosić o dodatkowe informacje, zlecić zwrot opłaty albo eskalować zgłoszenie do konsultanta).
Nowi, cyfrowi aktorzy zwiększają nieprzewidywalność procesu świadczenia usługi. Nawet jeśli usługi – w przeciwieństwie do produktów – są z natury heterogeniczne, każda interakcja może wyglądać nieco inaczej, a w podróże klienta zawsze wpisana jest nieliniowość, to jednak zakłada się pewną powtarzalność.
Każdy klient, który sprawdzi ofertę na tradycyjnej stronie internetowej, zobaczy ten sam cennik. Jeśli w grę wchodzi bardziej zaawansowana personalizacja po stronie organizacji lub wykorzystanie narzędzi AI do wyszukiwania i porównywania ofert przez klienta, ten krok za każdym razem może wyglądać nieco inaczej i generować odmienne doświadczenie.
Duże modele językowe z natury działają niedeterministycznie, a najdrobniejsze różnice w sposobie zadania pytania, danych wejściowych czy dostępnym kontekście przekładają się na zauważalnie odmiennie odpowiedzi. Dochodzi też do paradoksalnej sytuacji, gdy klient nie widzi bądź nie rozumie aktywności, które zachodzą po jego stronie wymiany usługowej – ponieważ zostały oddelegowane do AI.
Czego nie dostrzega klasyczny schemat usługi?
Klasyczny schemat usługi również nie dostrzega tych aktywności, bo opisuje tylko część procesu przebiegającą po stronie organizacji. Działania klienta są w nim ograniczone do prostej ścieżki. Powszechnie stosowane warianty schematu usługi nie zostały zaprojektowane z myślą o reprezentowaniu nowego typu aktorów po obu stronach wymiany. W rezultacie istotne elementy współczesnych usług są w nich słabo widoczne, co ogranicza przydatność tego narzędzia.
W klasycznym schemacie usługi aktorami są klient oraz pracownik (pracownicy) lub zespół (zespoły) w organizacji. Rozwiązania technologiczne pojawiają się tylko po stronie organizacji – to interfejsy i aplikacje umożliwiające działania pierwszej linii, narzędzia wykorzystywane w działaniach zaplecza oraz systemy umożliwiające działanie usługi, tak zwane procesy wsparcia (support processes).
Takie ujęcie wystarcza w wypadku infrastruktury technicznej, jednak nie oddaje roli systemów, które interpretują dane, generują odpowiedzi, rekomendują lub podejmują decyzje – szczególnie po stronie klienta.
Bardzo ważny staje się przepływ i źródła danych, od których zależy nie tylko skuteczność systemów AI, lecz także ich bezpieczeństwo – jest to coś, co pojawia się w mapach procesów biznesowych, ale w typowych service blueprintach jest najczęściej tylko wzmiankowane w warstwie support processes.
Trudność sprawia również reprezentowanie ryzyk algorytmicznych. W service blueprincie czasami stosuje się specjalne oznaczenia na momenty szczególnie podatne na błędy (fail points), wąskie gardła procesu (bottlenecks) oraz formalne i nieformalne sposoby zapobiegania błędom (poka-yokes). Nowe ryzyka, takie jak błędne klasyfikacje, nieadekwatne rekomendacje, generowanie wiarygodnie wyglądających, lecz błędnych informacji, a w końcu uprzedzenia modelu wynikające z danych treningowych, również wpadałyby do tej kategorii obok błędów ludzkich, co utrudnia ich mitygację.
Próba dostosowania schematu usługi
W literaturze i praktyce projektowej zdarzają się zarówno próby wykorzystania standardowego schematu usługi do mapowania usług z udziałem AI12, sformułowania wytycznych do rozwoju tego narzędzia13, jak i deklaracje potrzeby całkowitego zastąpienia go nowym modelem14. Najciekawsza dotąd wydaje się propozycja Eriki Flowers oparta na jej wcześniejszej wspólnej pracy z Morganem Millerem nad praktycznym schematem usługi (practical service blueprint). Niestety, jej schemat systemów adaptacyjnych (adaptive systems blueprint), prezentowany na Service Design Global Conference w 2025 roku oraz różnych wydarzeniach online15, chyba nie doczekał się jeszcze wyczerpującego, publicznie dostępnego opisu.
Moim celem nie było zastąpienie schematu usługi nowym narzędziem, a jego ewolucyjna zmiana, która zachowa tę samą logikę, dzięki czemu będzie dało się je łatwiej włączyć do praktyki projektowej w nowych warunkach.
Punktem wyjścia pozostaje przedstawienie usługi jako sekwencji działań różnych aktorów w czasie. Schemat obejmuje działania klienta, działania pierwszej linii, działania zaplecza oraz procesy wsparcia.
Il. 1. Proponowane elementy rozszerzonego schematu usługi uwzględniającego interakcje zapośredniczone przez AI
Największą zmianą jest bardziej szczegółowa reprezentacja aktorów w procesie. Oprócz klienta i pracowników organizacji po obu stronach uwzględniam dwie formy udziału narzędzi czy systemów AI. Są to asystenci wspierający czynności człowieka lub przygotowujący półprodukty do zatwierdzenia oraz agenci reprezentujący klienta albo organizację i autonomicznie wykonujący czynności w ich imieniu.
W miejsce linii interakcji (line of interaction), rozdzielającej działania klienta i organizacji w klasycznym schemacie pojawia się miejsce interakcji, czyli interfejs, punkt styku, artefakt fizyczny lub application programming interface (API, zestaw reguł i protokołów, które pozwalają programom i systemom na wymianę danych), które pozwalają się komunikować aktorom po obu stronach.
Dodatkowym uzupełnieniem jest warstwa danych, od których zależne są działania aktorów na danym etapie, oraz regulacji, w której zawierają się przepisy prawa oraz wewnętrzne zasady określające na przykład ograniczenia przetwarzania danych czy wytyczne cyberbezpieczeństwa na poszczególnych etapach procesu.
Jako obowiązkowe pojawiają się trzy oznaczenia nawiązujące do omówionych elementów fakultatywnych schematu usługi. „Wąskie gardła” i „momenty krytyczne” oznaczają dokładnie to samo, co wcześniej. Ważne jest jednak uwzględnienie potencjalnych problemów wynikających z wdrożenia AI, na przykład tego, jak wyczerpujące się tokeny, zwiększonego obciążenia powodującego wolniejsze działanie systemu czy braku możliwości pobrania niezbędnych danych.
Nowym oznaczeniem są „momenty weryfikacji”, w których pomyłka AI może być szczególnie kosztowna bądź kłopotliwa, więc bezwzględnie konieczne jest dodatkowe sprawdzenie poprawności rezultatów prac. Miejsce ludzkiego osądu w procesie wynika też z samego diagramu i kierunków przepływów, a to oznaczenie powinno pojawiać się w momentach, gdy problem pojawia się wyjątkowo często i istnieje konieczność wprowadzenia jakiejś optymalizacji w przyszłości.
Il. 2. Przykładowy proces zamówienia materiałów specjalistycznych w relacji między przedsiębiorstwami. Na schemacie widać również strzałki oznaczające kierunek przepływów oraz oznaczenia potencjalnie problematycznych punktów procesu
Mapowanie usług w czasach AI w praktyce
Takie rozszerzenie schematu usługi zaproponowałem pierwotnie na potrzeby projektów poprawy lub rozbudowy już istniejących usług i procesów. W wielu przypadkach kluczowy cel projektu, czyli niezbędna modernizacja infrastruktury usługi lub odpowiedzenie na nowe potrzeby, problemy i oczekiwania klientów w trakcie warsztatów znikał pod presją oczekiwania, by wprowadzić dosłownie cokolwiek wykorzystującego AI.
Jest to zrozumiałe – zastosowanie AI może przyspieszyć i ułatwić pewne interakcje, a niektóre etapy procesu całkowicie zastąpić. Kusi, by działać jak najszybciej. Konieczne są jednak przygotowania, w tym mapowanie rzeczywiście funkcjonujących w organizacji procesów i zaplanowanie niezbędnych poprawek, aby nie zautomatyzować obecnych błędów.
Oczywiście większość organizacji ma już jakoś opracowane mapy procesów czy podróży klienta, które mogą być podstawą takiej pracy. Zmodyfikowany schemat usługi pozwala na bardziej szczegółową analizę i zidentyfikowanie miejsc:
- w których można wprowadzić nową technologię, aby ułatwić życie pracowników i klientów;
- w których nie przynosi to korzyści uzasadniających koszt wdrożenia;
- w których jest to na tyle ryzykowne, że wymaga znacznie głębszego przemyślenia lub oczekiwania na większą dojrzałość technologii.
Mam nadzieję, że jako narzędzie ochroni też organizacje przed wdrożeniem AI-chatbotów w losowych miejscach, byleby wsiąść do pociągu innowacji.
Rozszerzony schemat usługi pozwala też lepiej uchwycić zmiany po stronie klienta. Lou Downe w Good Services pisała, że „Google jest stroną główną twojej usługi”. Coraz częściej tym pierwszym punktem styku będzie okienko czatu, a klient otrzyma mocną opinię o naszej usłudze, zanim jeszcze pozna jej nazwę. Jeśli rozwój systemów agentycznych pójdzie w stronę przewidywaną przez Sarah Gibbons i Pabla Fernándeza Valleja16, przygotowanie organizacji pod działanie asystentów i agentów AI będzie równie oczywiste jak dzisiaj prace nad SEO.
W tym sensie schemat usługi przestaje być wyłącznie narzędziem opisu procesu wewnątrz organizacji, a zaczyna obejmować szerszy system działań, w którym uczestniczą również systemy zewnętrzne i dane.
Mam też świadomość, że nawet po modyfikacjach schemat usługi nadal ma ograniczenia. Wraz ze wzrostem liczby aktorów i zróżnicowaniem ich zadań blueprint szybko traci czytelność i konieczne staje się dzielenie usługi na mniejsze całostki. Nadal pozostaje też narzędziem silnie liniowym, co utrudnia przedstawienie rzeczywistych, nieliniowych przebiegów usług, które wraz z rozwojem AI stają się jeszcze bardziej nieliniowe. Trudne jest również uchwycenie pętli uczenia się systemów oraz zmian w czasie, które nie wynikają z pojedynczej interakcji, lecz z akumulacji danych i decyzji – ale przynajmniej da się je oznaczyć i zaplanować.
To oznacza, że przedstawiona propozycja nie jest rozwiązaniem ostatecznym, lecz raczej kolejnym krokiem w ewolucji narzędzia, które podobnie jak same usługi nieustannie się zmienia. Kolejnym krokiem będzie jego dalsze stosowanie w praktyce projektowej i rozwijanie na bazie zebranych doświadczeń.
