Koniec ery gotowców w systemach biznesowych?

Rozszerzając swoje zainteresowania o odpowiadającą im sferę zawodową, siłą rzeczy zaczynamy poznawać również te mniej atrakcyjne aspekty danego obszaru.

Ponieważ jest to serwis w znacznej mierze poświęcony designowi i rozwojowi aplikacji webowych, na tych zagadnieniach poprzestanę, nie zagłębiając się w specyfikę wykraczającą poza te ramy. Nie oznacza to oczywiście, że pozostałe obszary są mniej interesujące. Wręcz przeciwnie – również tam kryje się wiele ciekawych i zaskakujących zależności.

Choć swoją próbę wejścia do branży automotive, poznania rządzących nią mechanizmów i oceny jej kondycji rozpocząłem od marketingu, nie ukrywam, że od początku interesował mnie przede wszystkim szerszy obraz rynku. Szczególnie kwestie związane z automatyzacją procesów, organizacją pracy i zarządzaniem.

Archaiczne i problematyczne rozwiązania, ograniczona wymiana danych oraz metody pracy, które zdają się pamiętać zupełnie inną epokę, nie wywołały u mnie większego zaskoczenia. Co istotne, obserwacje te dotyczą zarówno rynku polskiego, jak i zagranicznego.

Z jednej strony taki stan rzeczy może być przygnębiający, z drugiej otwiera szerokie możliwości w zakresie rozwoju systemów informatycznych. W wielu przypadkach już pierwsze, stosunkowo proste wdrożenia mogą istotnie zmienić dotychczasowy sposób funkcjonowania przedsiębiorstwa. Oznacza to z jednej strony dużą chłonność rynku, z drugiej zaś konieczność przekonania potencjalnych odbiorców do zmian, które często oznaczają odejście od wieloletnich przyzwyczajeń.

Dotychczasowe doświadczenia nie wskazują przy tym, aby to polscy odbiorcy byli grupą szczególnie oporną na inwestycje w automatyzację. Mimo to pierwszym kierunkiem poszukiwań stał się rynek zamorski. I nie mam tu na myśli kierunku wschodniego.

Dotarcie do informacji dotyczących wewnętrznej organizacji przedsiębiorstw nie jest oczywiście łatwe. Dlatego w pierwszej kolejności skupiłem się na zagadnieniach, które można zidentyfikować lub przynajmniej wywnioskować na podstawie ogólnodostępnych serwisów internetowych firm działających w danej branży.

W przypadku automotive, a dokładniej rynku jednośladów, uwagę zwracają przede wszystkim kwestie związane z brakiem automatyzacji działań SEO i GEO, komunikacji z odbiorcami, organizacji jazd testowych oraz innych aktywności skierowanych do potencjalnych klientów.

Początkowo skupiłem się na uporządkowaniu sposobu zarządzania ofertą i przygotowaniu rozwiązania, które można byłoby zaprezentować wybranym podmiotom. Są to jednak zagadnienia, których omawianie mogłoby stosunkowo łatwo prowadzić do poruszania kwestii objętych tajemnicą przedsiębiorstwa.

Znacznie przystępniejszym obszarem do prezentacji wydają się więc kwestie związane z zarządzaniem kontaktami oraz innymi procesami skierowanymi do odbiorców końcowych, które nie wymagają wchodzenia w szczegóły wewnętrznej organizacji firmy ani sposobu zarządzania jej ofertą.

Obserwacją, która zapewne nie zaskoczy większości osób mających styczność z tym rynkiem, jest bardzo niski poziom integracji systemów i wymiany danych pomiędzy poszczególnymi narzędziami wykorzystywanymi przez poznane przeze mnie organizacje. W zdecydowanej większości przypadków trudno wręcz mówić o funkcjonowaniu jakiegokolwiek spójnego systemu informatycznego.

Automatyzacja jazd testowych

Jeżeli automatyzacja nawet stosunkowo prostych procesów praktycznie nie istnieje, stworzenie rozwiązania pozwalającego poprawić ten stan rzeczy nie musi być szczególnie skomplikowanym przedsięwzięciem.

Jedną z pierwszych aplikacji, z którymi postanowiłem zwrócić się do wybranych potencjalnych odbiorców, był prosty system do zarządzania jazdami testowymi. W branży motocyklowej proces ten wciąż w zdecydowanej większości przypadków sprowadza się do udostępnienia numeru telefonu do dealera lub formularza kontaktowego.

Mając świadomość, że nie będzie to szczególnie wymagające zadanie, decyzje dotyczące pracochłonności i doboru technologii, pozwalających ograniczyć czas realizacji, podejmowałem na bieżąco. PHP, Laravel i gotowy dashboard oparty na Tailwind CSS może nie były rozwiązaniami, które najlepiej odpowiadały moim preferencjom, ale znałem już ich możliwości i wiedziałem, jaki efekt będę w stanie osiągnąć, uwzględniając wcześniejsze doświadczenia oraz dostępny czas.

W rezultacie, po około tygodniu pracy, można było zaprezentować potencjalnym odbiorcom gotowy system. Pomimo kilku ograniczeń – między innymi braku API, możliwości osadzenia na stronie dealera części przeznaczonej dla klientów końcowych oraz kilku innych niedociągnięć – rozwiązanie do dziś jest wykorzystywane przez kilka podmiotów zagranicznych.

Podejście drugie, nie do końca poprawione

Sytuacja sprzed ponad trzech lat ma się nijak do obecnych możliwości tworzenia aplikacji. W tamtym czasie moim podstawowym narzędziem wspomagającym programowanie był Copilot, początkowo w wersji bezpłatnej, a później płatnej. Tę drugą wykupiłem przede wszystkim po to, by sprawdzić, czy oferuje istotnie większe możliwości niż ogólnodostępna wersja. I, co tu dużo kryć, po dwóch dniach testów przestałem z niej korzystać, a o samej subskrypcji szybko zapomniałem.

Trudno jednak porównywać jego ówczesne możliwości z tym, co oferują dzisiejsi agenci AI.

Mając z tyłu głowy ograniczenia i niedociągnięcia wcześniej opracowanego systemu, a jednocześnie znając możliwości nawet mniej popularnych modeli, uznałem, że nadszedł czas na ponowną weryfikację koncepcji. Chciałem sprawdzić, ile czasu zajmie przygotowanie poprawionej alternatywy, pozbawionej zidentyfikowanych wcześniej niedogodności.

Dzięki doświadczeniu w projektowaniu systemów CMS, webdesignie i ogólnemu rozeznaniu w temacie, a także znajomości różnych modeli AI, byłem w stanie dość trafnie oszacować czas potrzebny na opracowanie zakładanej funkcjonalności. Ostatecznie moje przewidywania nie odbiegały znacząco od rzeczywistości.

Już na wstępie mogę jednak zaznaczyć, że nie jest to kwestia jednego czy trzech dni, nawet jeśli dysponujemy dość klarowną koncepcją systemu i określonym zakresem funkcjonalnym, w ramach którego agent może realizować powierzone mu zadania.

Nie da się ukryć, że znaczna część pracy technicznej może dziś zostać powierzona AI. Agenci potrafią nie tylko realizować założenia projektu, ale również pomagać w identyfikowaniu pominiętych wcześniej elementów i proponować rozwiązania problemów, które pojawiają się w trakcie pracy.

Zastanawia mnie jednak, jak wyglądałaby próba stworzenia podobnego systemu przez osobę, która nie ma wcześniejszego doświadczenia w projektowaniu i rozwijaniu aplikacji.

Czy obecne możliwości agentów AI byłyby w stanie zrekompensować braki w wiedzy technicznej i podejście projektowe? Czy ostatecznie udałoby się stworzyć produkt rzeczywiście nadający się do wdrożenia? I w jakim stopniu byłby on w stanie wyeliminować problemy, które zidentyfikowaliśmy na początku?

Prototyp koncepcyjny

Jak już wspominałem, omawiany we wpisie system ma przede wszystkim posłużyć do weryfikacji założeń dotyczących aktualnej pracochłonności tworzenia aplikacji oraz możliwości wybranych agentów AI.

Z drugiej strony nie ma to być wyłącznie demonstracja możliwości technologii czy makieta prezentująca sposób działania przyszłego rozwiązania. Celem jest stworzenie w pełni funkcjonalnego systemu, który będzie można wykorzystać również w środowisku produkcyjnym.

Poza zakresem projektu pozostają natomiast kwestie biznesowe. Aplikacja nie powstaje z myślą o komercjalizacji, choć jej bardziej rozwinięta wersja nie tylko mogłaby znaleźć odbiorców, ale wręcz miałaby szansę dobrze odnaleźć się na dość skostniałym rynku.

Ze względu na znaczną część czasu poświęcanego marce Royal Enfield wybór padł właśnie na ten podmiot. Co istotne, jest to również dość interesujący przypadek organizacyjny. Spółka importująca produkty tej marki posiada nie tylko wyłączne prawa do jej reprezentowania, ale – co wcale nie jest tak oczywiste – praktycznie cała sieć dealerska również znajduje się w jej rękach. Nie jest to zresztą żadną tajemnicą.

Taka struktura, poza możliwością uwzględnienia potrzeb samej sieci dealerskiej, pozwala spojrzeć na projekt znacznie szerzej niż w przypadku rozwiązania przygotowywanego wyłącznie z myślą o pojedynczych dealerach. Daje też możliwość uwzględnienia zależności i funkcjonalności, które w innym przypadku mogłyby pozostać poza zakresem projektu.

MVP

Po spisaniu dość obszernego zakresu wymagań funkcjonalnych dla MVP i wyborze stacku technologicznego, który powinien umożliwić szybkie wdrażanie kolejnych wersji w środowisku testowym, a w razie potrzeby również migrację do łatwo dostępnego środowiska produkcyjnego, można przejść do IDE – na sterydach.

W przypadku omawianego systemu zarządzania jazdami testowymi ciekawsze wydaje mi się przedstawienie jego koncepcji i złożoności samego rozwiązania niż szczegółowe omawianie tego, które modele zostały wykorzystane, w jakim środowisku pracowały, gdzie pojawiły się problemy i ile tokenów pochłonęła ich praca.

A wbrew pozorom przygotowanie aplikacji, która ma usprawnić organizację pracy co najmniej 11 salonów dealerskich i zautomatyzować wykorzystywane w nich procesy, nie jest tak trywialnym zadaniem, jak mogłoby się wydawać.

Pierwsza wersja produktu spełniająca minimalne założenia funkcjonalne była gotowa już po kilku godzinach pracy i mogła zostać uruchomiona. Nie oznacza to jednak, że na tym kończy się projekt. Istotą przedsięwzięcia jest odwzorowanie całego spektrum obecnie wykorzystywanych procesów, a także uwzględnienie nowych możliwości i zależności, które warto w takim systemie przewidzieć. A tych, jak się okazuje, jest naprawdę sporo.

Dealer Portal

Dalsza część wpisu nie będzie więc opisem procesu odtworzenia niewielkiego wycinka rzeczywistości, ale próbą przedstawienia możliwości i uzasadnienia, dlaczego wybrane zagadnienie warto potraktować znacznie szerzej.

Kontakty pozyskiwane w związku z organizacją jazd testowych trafiają do firm różnymi kanałami, z różnych źródeł i przy różnych okazjach. Pierwszym z nich jest standardowy formularz zapisów dostępny na stronie głównej. Kolejne to wydarzenia jednorazowe oraz ich serie, obejmujące określone grupy eventów.

Zgłoszenia napływają nie tylko z głównej podstrony poświęconej jazdom testowym w serwisie royalenfield.pl, ale również ze stron poszczególnych wydarzeń, landing page’y, wpisów blogowych czy zewnętrznych serwisów.

Do tego dochodzą platformy wykorzystywane w działaniach marketingowych i pozyskiwaniu kontaktów, takie jak sieć reklamowa Google, Profile Firmy w Google czy usługi Meta.

Tak duże rozdrobnienie źródeł, konieczność obsługi poszczególnych salonów oraz dystrybucji zgłoszeń pochodzących zarówno z głównego kanału, jak i licznych wydarzeń własnych czy imprez organizowanych przez podmioty spoza sieci, sprawiają, że podejście ograniczające się wyłącznie do agregacji leadów byłoby niewystarczające.

Potrzebne jest rozwiązanie, które uwzględni nie tylko samo pozyskiwanie kontaktów, ale również ich dalszą obsługę, przypisywanie do odpowiednich placówek i powiązanie z pozostałymi elementami procesu.

Park maszynowy

Różnorodność kanałów, którymi napływają zgłoszenia, oraz konieczność ich prawidłowego rozdzielania pomiędzy dealerów to tylko jedna z wielu zależności. Naturalnie trzeba uwzględnić również dostępność motocykli przeznaczonych do jazd testowych, ich lokalizację, stan techniczny oraz aktualny status.

System musi zatem uwzględniać możliwość wykluczenia pojazdów uszkodzonych, sprzedanych, znajdujących się w serwisie, relokowanych lub czasowo niedostępnych z powodu innych potrzeb przedsiębiorstwa.

Automatyzacja zarządzania wszystkimi tymi kwestiami nie będzie niestety możliwa w obecnych warunkach. Większość związanych z nimi działań trzeba więc pozostawić po stronie poszczególnych dealerstw. Dotyczy to między innymi aktualizacji przebiegu, zmiany statusu oraz aktywacji i dezaktywacji pojazdów w systemie. Wszystko po to, aby nieaktualne lub błędne informacje nie wpływały negatywnie na doświadczenia klientów korzystających z formularza rezerwacji.

Skoro za stan parku maszynowego odpowiadać powinny osoby, które mają z nim bezpośredni kontakt i dysponują najbardziej aktualnymi informacjami, cały proces należy maksymalnie uprościć.

Jednocześnie zarządzanie katalogiem modeli i ich kategoryzacją powinno pozostać w gestii administratora centralnego. Dzięki temu pracownicy poszczególnych salonów nie będą musieli samodzielnie wprowadzać tych danych, a co ważniejsze – nie będą mieli możliwości wprowadzania błędnych lub niespójnych informacji. Ich zadaniem pozostanie wybór motocykli z przygotowanego wcześniej, jednolitego zbioru.

Kadra

Na możliwość zarezerwowania motocykla do jazdy testowej wpływa oczywiście jego dostępność i stan techniczny. Nie będzie to może najbardziej finezyjne określenie, ale równie istotnym zasobem są tutaj ludzie. Motocykl musi przecież ktoś przygotować, wydać klientowi i odebrać po zakończeniu jazdy.

Konieczne jest zatem uwzględnienie również dostępności pracowników poszczególnych dealerstw. Nie chodzi przy tym wyłącznie o urlopy, całodniowe nieobecności czy wyjazdy związane z udziałem w wydarzeniach. Równie istotne są krótsze wyjścia i inne absencje, które należy rozpatrywać nie w skali całych dni, ale konkretnych godzin.

Krótko mówiąc, nie obejdzie się bez modułu umożliwiającego pracownikom samodzielne zarządzanie swoją dostępnością i zgłaszanie nieobecności.

A skoro mowa o pracownikach, którzy będą jednocześnie użytkownikami zaplecza administracyjnego, trzeba zapewnić im odpowiednie miejsce do wykonywania tych czynności. W systemie nie może więc zabraknąć również modułu zarządzania użytkownikami, ich danymi i przypisaniem do poszczególnych placówek.

Należy oczywiście uwzględnić również sytuację, w której za obsługę jazd testowych w danej placówce odpowiada więcej niż jeden pracownik. W takim przypadku nieobecność jednej osoby nie powinna automatycznie skutkować wyłączeniem danego przedziału czasowego z możliwości rezerwacji. Ograniczenie dostępności powinno następować dopiero wtedy, gdy w tym samym czasie niedostępni będą wszyscy pracownicy uprawnieni do obsługi jazd testowych w danej placówce.

Czas pracy

Rozwijając kwestię zarządzania czasem pracy, naturalnym rozwiązaniem wydaje się stworzenie podsystemu umożliwiającego każdemu pracownikowi samodzielne definiowanie nieobecności, a także zapewniającego wgląd w listę osób uprawnionych do zarządzania tymi ustawieniami.

Wprowadzone w ten sposób dane będą automatycznie uwzględniane przez aplikację i przekładane na informacje wyświetlane osobom zainteresowanym umówieniem jazdy testowej. Pozwoli to również ograniczyć ryzyko rozbieżności między faktyczną dostępnością pracowników a danymi prezentowanymi w systemie.

Salony

Lista placówek oraz ich parametry, ze względu na niską rotację danych w tym obszarze i fakt, że zarządzanie nimi pozostaje w gestii zarządu, powinny być konfigurowane przez administratora.

Konfiguracja salonu musi uwzględniać przede wszystkim jego nazwę, dane adresowe i kontaktowe, status oraz indywidualny kod identyfikacyjny, wykorzystywany jako element numeru rejestracyjnego.

Kolejnym istotnym parametrem jest ogólna dostępność salonu, określana przez regularne godziny pracy, które wyznaczają ramy czasowe możliwych rezerwacji. Ze względu na potencjalne zmiany organizacyjne warto przewidzieć również możliwość ustawienia standardowego czasu trwania jazdy testowej, bufora pomiędzy kolejnymi rezerwacjami, pozwalającego przygotować motocykl dla następnego klienta, oraz maksymalnego horyzontu rezerwacji. Ten ostatni parametr powinien zabezpieczać zarówno przed zapisami dokonywanymi na ostatnią chwilę, jak i rezerwacjami z bardzo dużym wyprzedzeniem. W tym drugim przypadku, na przykład półrocznym, zmiany w parku maszynowym lub aktualnej ofercie mogłyby bowiem prowadzić do poważnych problemów organizacyjnych.

Warto również umożliwić definiowanie dni wyłączonych z rezerwacji — zarówno na poziomie pojedynczego salonu, jak i globalnie, dla całej sieci. Pozwoliłoby to uwzględnić święta, dni wolne od pracy oraz inne terminy, w których jazdy testowe nie powinny być dostępne.

Uzupełnieniem konfiguracji mogą być odnośniki do zewnętrznych serwisów związanych z daną placówką, na przykład profili społecznościowych czy wizytówki Google. Mogłyby one służyć między innymi do przekierowania klienta do zewnętrznego formularza umożliwiającego wystawienie opinii o salonie.

Zarządzanie uprawnieniami

Jeżeli w systemie będzie funkcjonować większa liczba użytkowników, trzeba liczyć się również z błędami wynikającymi z codziennej pracy, a także z naturalnymi różnicami w zakresie obowiązków i odpowiedzialności poszczególnych osób. Niezbędny staje się więc odpowiednio zaprojektowany system zarządzania uprawnieniami.

Podstawowym założeniem powinno być odseparowanie poszczególnych dealerstw. Każdy pracownik wykonujący swoje obowiązki w ramach konkretnej placówki powinien mieć dostęp wyłącznie do dotyczących jej danych i funkcjonalności. Nie powinien przy tym widzieć informacji ani mieć możliwości wykonywania operacji związanych z działalnością pozostałych salonów.

Takie podejście pozwala nie tylko ograniczyć ryzyko przypadkowych błędów, ale również zachować porządek w strukturze systemu i jasno określić zakres odpowiedzialności poszczególnych użytkowników

Kwestie bezpieczeństwa logowania, w tym m.in. autoryzacja dwuskładnikowa (2FA), również wymagają uwzględnienia, jednak w ramach projektu ich obsługa będzie w głównej mierze opierać się na rozwiązaniach dostarczanych przez zewnętrznych usługodawców.

Podstawowym sposobem dostępu do systemu będzie logowanie za pośrednictwem wskazanego konta Google. Powiązanie konta z użytkownikiem oraz jego parametry będą odnotowywane po stronie aplikacji, natomiast samo uwierzytelnianie, w tym obowiązkowa weryfikacja dwuetapowa, pozostanie po stronie usług Google.

Wydarzenia

Wspomniane wcześniej wydarzenia, zarówno organizowane pojedynczo, jak i w ramach całych serii, mają w branży motocyklowej istotne znaczenie. Szczególnie wtedy, gdy ich program obejmuje udostępnianie motocykli do jazd testowych.

Uwzględnienie tego rodzaju aktywności wpływa na kilka niezależnych obszarów funkcjonowania systemu.

Po pierwsze, wydarzenia angażują pracowników sieci dealerskiej, co może uniemożliwiać poszczególnym placówkom realizację rezerwacji w standardowych godzinach pracy. Z tego względu zarówno termin wydarzenia, jak i związane z nim nieobecności pracowników muszą być uwzględniane w systemie oraz odpowiednio odzwierciedlane w interfejsie użytkownika końcowego.

Po drugie, wydarzenia tego typu wiążą się z częstymi zmianami w zakresie dostępności floty. Motocykle pochodzące z magazynu centralnego oraz poszczególnych salonów są transportowane na miejsce wydarzenia, a następnie wracają do swoich macierzystych lokalizacji. System powinien zatem uwzględniać nie tylko sam termin imprezy, ale również czas potrzebny na transport motocykla w obie strony, czas trwania wydarzenia oraz ewentualny bufor niezbędny do ponownego udostępnienia go w pierwotnej placówce.

Nie mniej istotna jest różnorodność samych wydarzeń, która powinna znaleźć odzwierciedlenie w sposobie działania interfejsu użytkownika. Frontend musi reagować na parametry wynikające z charakteru konkretnej imprezy oraz umożliwiać obsługę zarówno pojedynczych wydarzeń, jak i całych ich serii.

W przypadku serii użytkownik powinien mieć możliwość wyboru konkretnego wydarzenia wchodzącego w jej skład. Przy pojedynczym evencie interfejs może natomiast działać w uproszczonym trybie, bez konieczności prezentowania dodatkowych opcji wyboru.

Niezależnie od przyjętego wariantu wszystkie widżety powinny być przygotowane do osadzania (embedowania) w różnych środowiskach: na stronach wydarzeń w serwisie dystrybutora royalenfield.pl, na stronie głównej, we wpisach blogowych, a także w serwisach zewnętrznych. Dzięki temu mechanizm rezerwacji pozostanie spójny funkcjonalnie, niezależnie od miejsca, z którego użytkownik rozpocznie proces umawiania jazdy testowej.

Rezerwacje i obieg informacji

Do części frontendowej systemu, przeznaczonej dla odbiorcy końcowego, przejdę w dalszej części wpisu. W tym miejscu warto natomiast omówić proces, który powinien następować po zakończeniu przez zainteresowanego procesu rezerwacji i pomyślnym przekazaniu danych do backendu.

W pierwszej kolejności każde zgłoszenie powinno otrzymać indywidualny numer identyfikacyjny. Dla zachowania czytelności warto zastosować schemat uwzględniający datę rezerwacji, indywidualne oznaczenie placówki, oznaczenie sieci (z myślą o ewentualnym rozwoju systemu w przyszłości 😉) oraz unikalny hash zapewniający niepowtarzalność identyfikatora.

W systemie powinny być zapisywane również:

• data i godzina przyjęcia zgłoszenia,

• parametry wybranej usługi, w tym model motocykla,

• dane osoby dokonującej rezerwacji,

• termin realizacji usługi, obejmujący datę i godzinę.

Istotnym elementem zapewniającym poprawność działania systemu i eliminującym ryzyko wielokrotnego zarezerwowania tej samej maszyny jest przypisanie do każdego zgłoszenia konkretnego numeru rejestracyjnego pojazdu. Numery te powinny być wcześniej zdefiniowane w systemie, a następnie przypisywane automatycznie na etapie rezerwacji. Jeżeli motocykl o danym numerze rejestracyjnym został już zarezerwowany na określony termin, powinien zostać automatycznie wyłączony z puli dostępnych maszyn dla kolejnych użytkowników zainteresowanych tym samym modelem.

Dodatkowym mechanizmem kontrolnym, ograniczającym możliwość tworzenia fikcyjnych rejestracji przez pracowników sieci, powinien być obowiązek uzupełnienia rzeczywistego przebiegu motocykla w przypadku zgłoszeń oznaczonych jako zrealizowane. Chodzi o dwa niezależne odczyty: stan licznika przed wydaniem motocykla oraz po jego zwrocie. Pozwoli to nie tylko zweryfikować faktyczne wykorzystanie maszyny, ale również zachować historię jej eksploatacji. Kontrola najwyższą formą zaufania 😉

Panel obsługi zgłoszeń powinien oczywiście umożliwiać modyfikację statusu każdej rezerwacji oraz oferować rozbudowane mechanizmy filtrowania. Oprócz samego numeru rezerwacji istotna będzie możliwość wyszukiwania i sortowania danych według placówki, terminu realizacji, modelu motocykla, statusu oraz pozostałych parametrów zgłoszenia.

Zakres widocznych danych i dostępnych operacji powinien być przy tym uzależniony od uprawnień konkretnego użytkownika, przypisanej mu roli oraz placówki, z którą jest powiązany. Dzięki temu pracownik salonu będzie miał dostęp do informacji niezbędnych do bieżącej obsługi własnych rezerwacji, natomiast administratorzy sieci otrzymają odpowiednio szerszy zakres kontroli i możliwości zarządzania danymi.

Komunikaty

O pomyślnym przyjęciu rezerwacji warto oczywiście poinformować zarówno osobę przesyłającą zgłoszenie, jak i pracowników odpowiedzialnych za realizację jazdy testowej.

Można to zrealizować na kilka sposobów. Naturalnym i podstawowym rozwiązaniem jest wysłanie wiadomości e-mail z potwierdzeniem przyjęcia rezerwacji. Kanał ten może również służyć do późniejszego informowania o zmianach statusu zgłoszenia.

Osobiście uważam jednak, że wymaganie od użytkownika dodatkowego potwierdzenia rezerwacji za pośrednictwem otrzymanej wiadomości jest rozwiązaniem nie tyle pozbawionym funkcjonalności, ile po prostu archaicznym.

Po pierwsze, wiadomość może nie dotrzeć pod wskazany adres. Wystarczy zwykła literówka w adresie e-mail lub zakwalifikowanie korespondencji jako spamu. Z kolei wymuszanie logowania do systemu, choć stanowi pewną próbę rozwiązania problemów związanych z pocztą elektroniczną, w przypadku tak prostej czynności może sprawiać wrażenie niepotrzebnego pozyskiwania dodatkowych danych i komplikowania całego procesu.

Nie oznacza to oczywiście, że z wiadomości e-mail należy rezygnować. Wręcz przeciwnie – warto automatycznie wysyłać zarówno potwierdzenie przyjęcia rezerwacji, jak i podziękowanie za skorzystanie z usługi. Szczególnie istotna jest ta druga wiadomość, ponieważ stwarza okazję do pozyskania opinii użytkownika oraz zachęcenia go do wystawienia oceny w zewnętrznych serwisach, w tym na profilach firmowych Google widocznych w wynikach wyszukiwania i Google Maps. To nie tylko sposób na zbieranie wartościowego feedbacku, ale również budowanie pozytywnego wizerunku usługi i profesjonalizmu całej organizacji.

Automatyzacja procesu otwiera przy tym znacznie szersze możliwości komunikacji, wykraczające poza tradycyjną pocztę elektroniczną. Powiadomienia push oraz wiadomości dostarczane za pośrednictwem popularnych komunikatorów pozostają istotnymi kanałami informacyjnymi, które warto uwzględnić w docelowej architekturze systemu. Pozwoli to nie tylko zwiększyć skuteczność dostarczania informacji, ale również dostosować sposób komunikacji do przyzwyczajeń odbiorców.

Opinie

Opinie dotyczące przebiegu i jakości realizacji usługi, poziomu obsługi, przyjazności całego procesu, ewentualnych problemów, a także sugestie wskazujące obszary wymagające poprawy, powinny być gromadzone i prezentowane w ramach dedykowanego zestawienia.

Oznacza to konieczność przygotowania odrębnego modułu umożliwiającego nie tylko przegląd zgromadzonych opinii i ocen, ale również ich filtrowanie, podgląd szczegółowych informacji oraz analizę według wybranych parametrów. Dzięki temu zebrane informacje będą mogły służyć nie tylko do bieżącej oceny jakości obsługi, ale również do identyfikowania powtarzających się problemów i wskazywania obszarów wymagających dalszych usprawnień.

RE.View

Osoby śledzące działalność marki Royal Enfield na polskim rynku zapewne zauważyły już uruchomienie programu RE.View, umożliwiającego wydłużenie standardowej jazdy testowej do dwóch lub trzech godzin.

Program skierowany jest przede wszystkim do twórców internetowych i osób przygotowujących materiały poświęcone motocyklom, dla których standardowy czas udostępnienia maszyny może okazać się niewystarczający do rzetelnego zaprezentowania jej możliwości. Nie oznacza to jednak, że z tej możliwości nie mogą skorzystać również osoby, które po prostu chciałyby spędzić z wybranym motocyklem nieco więcej czasu na drodze.

Aby zwiększyć zasięg informacji o programie, dotrzeć do potencjalnie zainteresowanych osób i ułatwić im skorzystanie z tej możliwości, warto uwzględnić jego obsługę bezpośrednio w aplikacji.

W tym celu frontend przeznaczony dla użytkowników końcowych powinien udostępniać opcję zaznaczenia zainteresowania udziałem w programie RE.View, a następnie wyboru jednego z dostępnych wariantów czasowych. Dodatkowo warto przewidzieć dedykowaną sekcję wyjaśniającą założenia programu, wraz z odnośnikiem do jego landing page, gdzie zainteresowani będą mogli znaleźć więcej informacji i zapoznać się ze szczegółami.

Oczywiście wybór wariantu RE.View, oznaczający wydłużenie jazdy testowej o dodatkową godzinę lub dwie, musi być odpowiednio uwzględniany w mechanizmie zarządzania dostępnością motocykli. Rezerwacja powinna blokować możliwość udostępnienia danej maszyny na cały okres jej wykorzystania, z uwzględnieniem ewentualnego czasu potrzebnego na przygotowanie i ponowne udostępnienie pojazdu. Pozwoli to uniknąć nakładania się rezerwacji i związanych z tym problemów organizacyjnych.

One-Page Checkout

Design backandu, a dokładniej dashboardu choć oczywiście powinien uwzględniać standardy UI oraz UX, pozwalając na naturalne przemieszczanie się między stronami i niebyrząc wyuczonej na rpzestrzeni lat obsługi podstawowuch modułów webowych, nie musi być dopracowany do granic możliwosci. Niespójne marginesy, kolorystyka nieodpowiadajaca Brand Guidelinesom jest do przełkniecia jeśli tylko system jest funkcjonalny.

W przypadku frontendu prezentowanego odbiorcy końcowemu można jednak nieco poszaleć. Oczywiście design powinien zgrywać się z UI serwisu macierzystego marki, ale jeśli niechcemy dostosowywać go do każdego innego serwisu w którym potencjalnie bedzie wyświetlany warto by uwzględniał też sporą dozę uniwersalności.

O podejścou mobile first nie ma co specjalnie wspominać bo to dziś oczywistość. Dla potwierdzenia tego trendu warto wspomnieć że użytkownicy wyświetlajacy stronę royalenfield.pl na urządzeniach mobilnych stanowią pond 80% wszystkich odwiedzajacych i wartość ta utrzymuje się od conajmniej 2 lat.

Rozmyślając nad wyglądem i układem interfejsu dla odbiorcy, wygrała niechęć do poświęcania temu zagadnieniu życia oraz przyzwyczajenia. A że na przestrzeni ostatnich lat gros usług komercyjnych, obejmowała branza e-commerce to i z tego typu aplikacjami miałem najwięcej doczynienia.

I tak oto pomysł na końcowy element systemu wyrwany został żywcem z działaności wszelkiej maści sklepów internetowych i wykorzystywanych przez nie systemów zarządzania treścia.

Układ One-Page Checkout nie jest może najlepszym i ostatecznym rozwiażaniem, ale trochę jak z demokracją. One-Page Checkout to najgorsza forma checkoutu, ale lepszej jeszcze nie wymyślono.

Choć trafniejszym ujęciem będzie stwierdzenie, ze jeszcze lepsze się nie upowszechniło.

Tak jak wspominane bylo w poszczególnych sekcjach “checkout” oraz jego moduły zależne są od całego spektrum czynników. Jeśli formularz wyświetlany jest na stronie danego salony lub akcji związanej z daną placówką, select Wybierz salon lub punkt nie jest widoczny, a dane automatycznie są parowane z ustalonym w parametrze data dealerstwem.

Jeśli checkout ma realizaować zadania zwiążane z wydarzenem jednodniowym, niewidoczne jest natomiast pole wybierz datę.

Zależnie od preferencji sekcja dotycząca RE.View również moze być pokazywana lub ukrywana.

I tak wygląda sytuacja praktycznie z każdym elementem. Praktycznie wszystkie konfigurowalne sa na poziomie parametrów ustalanych w embedowanym kodzie, co wyklucza konieczność wprowadzania każdorazowo wymaganych ustawień w panelu zarządzania.

Drognym udogodnieniem dla odbiorców, a jednocześnie elementem wzmacniaja cym pozytywny odbiór usługi jest automatyczne wyświetlanie danych kontaktowych opiekuna rezerwacji, który wyswietla się zgodnie z przypisanym do wydarzenia lub salonu. Oczywioście moduł uwzględnia sytuację w której występuje wiecej niz jeden opiekun.

Zgodnie z paradygmatem, wszystkie wybrane przez zainteresowanego jazdami testowymi, parametry wyświetlane sa zbiorczo w odrębnej kolumnie, tak by przed kliknięciem CTA użytkownik miał możliwośc podejrzenia i zweryfikowania swoich wyborów.

Live demo

Choć zgodnie z pierwotnymi założeniami system i jego poszczególne komponenty nie były projektowane z myślą o funkcjonowaniu w środowisku w pełni produkcyjnym, rozwój i bieżące utrzymywanie serwisu royalenfield.pl skłoniły mnie do upublicznienia sprofilowanego pod potrzeby salonu Royal Enfield Kraków modułu rezerwacyjnego (checkoutu).

Zgodnie z opisaną wcześniej logiką, w tym przypadku pole umożliwiające wybór placówki lub konkretnego wydarzenia należącego do danej serii pozostaje ukryte. Nie ma bowiem potrzeby komplikowania interfejsu opcjami, które w tym scenariuszu nie znajdują zastosowania.

Testowanie rozwiązań bezpośrednio na środowisku produkcyjnym nie jest może szczególnie podręcznikowym podejściem. Trzeba jednak wziąć pod uwagę specyfikę całego przedsięwzięcia. Pełniąc od lat jednocześnie funkcję architekta, projektanta UI, developera, grafika, testera i project managera, a do tego dorobiłem się już całkiem pokaźnego grona własnych asystentów, choć wciąż niematerialnych. Trzymanie się sztywnych procedur, niekoniecznie przystających do realiów niewielkich, niszowych projektów, mogłoby się więc okazać zwyczajnie sztuką dla sztuki.

https://royalenfield.pl/salony/krakow/

Mogę zatem potwierdzić, że system działa zgodnie z opisanymi powyżej założeniami i jest dostępny do wykorzystania jako alternatywna forma rezerwacji jazd testowych w krakowskiej placówce Royal Enfield.

Nowa rzeczywistość

W dość skostniałej i anachronicznej branży automotive opisane rozwiązanie, nawet na etapie prototypu stworzonego w gruncie rzeczy dla zabawy i eksperymentu, może stanowić niemałą innowację.

Weryfikacja przyjętych założeń prowadzi jednak do znacznie ciekawszych pytań i wniosków. Czy jesteśmy już świadkami zmierzchu modelu SaaS, gotowych systemów CMS oraz zamkniętych, przeważnie horrendalnie drogich i nierzadko archaicznych rozwiązań biznesowych? Czy systemy rozproszone i rozwijane od lat frameworki czeka podobny los, czy wręcz przeciwnie – właśnie dzięki AI otwierają się przed nimi zupełnie nowe możliwości?

Przygotowanie w pełni sprofilowanego i dostosowanego do konkretnych potrzeb systemu zarządzania jest dziś szybsze i bardziej dostępne niż kiedykolwiek wcześniej. W kontekście mikro-, małych i średnich przedsiębiorstw zasadne staje się zatem pytanie o najbardziej racjonalną ścieżkę rozwoju: budowanie własnych, kompletnych ekosystemów ICT, korzystanie z dostępnych od lat rozwiązań, które być może nie są idealne, ale sprawdziły się już w praktyce, czy łączenie obu tych podejść?

A może warto poczekać na pojawienie się agencji oferujących kompleksową obsługę programistyczną w cenie zbliżonej do tej, którą przedsiębiorstwa ponoszą obecnie za utrzymanie i eksploatację gotowych systemów?

Nie chodzi przy tym wyłącznie o ograniczenie kosztów czy zastąpienie jednego narzędzia drugim. Równie istotna jest płynność przepływu danych, możliwość dalszego rozwoju działalności, automatyzacja czynności, które dotychczas wymagały znacznego nakładu pracy, a także dostęp do informacji, których gromadzenie, agregowanie i przetwarzanie było wcześniej nieopłacalne lub zwyczajnie niemożliwe.

I być może właśnie w tym ostatnim obszarze kryje się największa zmiana. Nie tyle w samym sposobie tworzenia oprogramowania, ile w możliwości budowania narzędzi, które rzeczywiście odpowiadają na potrzeby konkretnego przedsiębiorstwa, zamiast zmuszać je do dostosowywania własnych procesów do ograniczeń zakupionego rozwiązania.