Konfigurator pozwala skonfigurować produkt, którego nie da się wyprodukować - jak ustawić reguły

Konfigurator pozwala zamówić produkt niemożliwy do wykonania, gdy nie ma w nim reguł produkcji: zakresów wymiarów, opcji, które się wykluczają, i opcji, które wymagają innych. Naprawa polega na spisaniu tych reguł razem z produkcją w jednej tabeli danych, z której konfigurator blokuje niedozwolone wybory i wyjaśnia klientowi, dlaczego.

Jak wygląda konfiguracja, której nie da się wyprodukować?

Na ekranie zwykle wygląda poprawnie, bo model 3D narysuje wszystko, co mu się poda. Problem wychodzi dopiero u handlowca albo technologa, który czyta zapytanie.

• garaż z bramą uchylną tak szeroką jak cała ściana, bez miejsca na słupki i obróbki,
• brama segmentowa w garażu, który ma za mało miejsca nad otworem na prowadnice,
• hala z bramą, która wypada na słupie ramy,
• ogrodzenie z bramą przesuwną przy samym narożniku działki, bez miejsca na odjazd skrzydła,
• dwa dodatki, które się wykluczają, np. dwa różne rodzaje napędu do tej samej bramy.

Każda taka konfiguracja kończy się dodatkową korespondencją z korektą, a klient ma poczucie, że cena i wygląd z konfiguratora były nieprawdziwe. Część klientów nie czeka na wyjaśnienia i pyta innego producenta.

Dlaczego konfigurator nie blokuje niemożliwych wyborów?

Bo reguły produkcji nie zostały spisane albo zostały wpisane w kod w kilku miejscach naraz. Konfigurator wie, jak narysować bramę, ale nie wie, gdzie wolno ją postawić.

Reguły istnieją tylko w głowach

Technolog wie, że dany dach robi się dopiero od określonej szerokości, a handlowiec, że furtka nie może mieć dowolnej szerokości. Ta wiedza nie trafiła do wymagań na konfigurator, więc wykonawca dostał tylko listę opcji i cennik.

Reguły zapisane w kodzie

Nawet spisane reguły bywają wpisane bezpośrednio w kod jako warunki. Każda zmiana w produkcji wymaga wtedy programisty, a reguły z czasem rozjeżdżają się z cennikiem i katalogiem. Bywa też, że ta sama reguła jest zapisana dwa razy, raz przy modelu 3D, a raz przy formularzu, i po zmianie poprawiono tylko jedno miejsce.

Brak testów na granicach

Konfigurator sprawdzono na kilku typowych zestawach, a nie na wartościach skrajnych: minimalnej szerokości, maksymalnej długości, największej bramie w najmniejszej ścianie. Właśnie tam najczęściej wychodzą niemożliwe połączenia.

Jakie reguły powinien mieć konfigurator produktu?

Większość ograniczeń produkcji da się opisać czterema typami reguł. Każdą zapisuj jako wiersz w tabeli, a nie jako warunek w kodzie.

Najwięcej reguł zależnych mają garaże i wiaty: szerokość i typ bramy zależą od ściany, rodzaj dachu od szerokości, a okna i drzwi od tego, ile miejsca zostaje obok bramy. Tak projektujemy konfigurator 3D garaży. W halach dochodzą reguły konstrukcji: bramy i drzwi muszą wypadać między ramami albo wymagają zmiany konstrukcji, którą zatwierdza konstruktor, dlatego w konfiguratorze 3D hal stalowych rozstaw ram jest jednym z parametrów reguł. Przy ogrodzeniach reguły dotyczą przede wszystkim rozstawu słupków, wysokości przęseł i miejsca na bramy i furtki, i to od nich zaczynamy, budując konfigurator 3D ogrodzeń.

Gdzie zapisać reguły, żeby zmieniać je bez programisty?

W tabeli danych, np. arkuszu lub panelu administracyjnym, z której konfigurator czyta reguły przy starcie. Kod zna tylko typy reguł, a konkretne wartości i komunikaty są danymi.

Każdy wiersz tabeli powinien mieć identyfikator reguły, warunek, skutek, komunikat dla klienta, osobę, która regułę zatwierdziła, i datę. Ta sama tabela służy wtedy produkcji jako dokumentacja, a handlowcom jako odpowiedź na pytanie „czy da się to zrobić?”. Reguły sprawdzaj dwa razy: w przeglądarce, żeby klient od razu widział ograniczenia, i na serwerze przy wysyłce zapytania, bo dane wysłane z przeglądarki można zmienić.

Jak informować klienta o ograniczeniach?

Wyjaśniaj przy opcji, a nie komunikatem o błędzie na końcu. Klient powinien widzieć, dlaczego coś jest niedostępne i co może wybrać zamiast tego. Komunikat pisz językiem klienta, a nie produkcji: zamiast kodu reguły lepiej „brama nie zmieści się w tej ścianie”.

• niedostępne opcje wyszarzaj z krótkim powodem, np. „Ten dach jest dostępny od większej szerokości. Zwiększ szerokość albo wybierz dach jednospadowy.”, zamiast je ukrywać,
• gdy zmiana wymiaru unieważnia wcześniejszy wybór, pokaż, co się zmieniło, zamiast poprawiać to po cichu,
• proponuj najbliższą wykonalną wersję, np. węższą bramę albo przesunięcie okna,
• dla nietypowych potrzeb zostaw ścieżkę „zapytaj o wykonanie indywidualne” z dołączoną konfiguracją.

Jak zbudować macierz testów reguł?

Macierz testów to lista konkretnych konfiguracji z oczekiwanym wynikiem: dozwolona, zablokowana albo zmieniona z komunikatem. Nie obejmuje wszystkich kombinacji, tylko przypadki, w których reguły naprawdę pracują.

Dla reguły zakresu testuje się wartość minimalną, maksymalną i tuż poza zakresem. Dla wykluczeń sprawdza się obie kolejności wyboru, czyli najpierw opcję A, a potem B, i odwrotnie. Dla wartości zależnych zmienia się wymiar już po wybraniu elementu, bo częstym źródłem błędów jest właśnie kolejność: klient wybiera szeroką bramę, a potem zmniejsza szerokość garażu albo przesuwa bramę bliżej narożnika. Macierz trzymaj obok tabeli reguł, uruchamiaj ją jako testy automatyczne po każdej zmianie, a wynik pokazuj zespołowi produktu przed publikacją nowej wersji.

Co sprawdzić przed uruchomieniem reguł? Lista kontrolna

• każda opcja ma przypisane zakresy i zależności albo świadomą decyzję, że ich nie ma,
• reguły są w tabeli danych, a nie w kodzie,
• każda reguła ma komunikat zrozumiały dla klienta,
• reguły są sprawdzane także na serwerze przy wysyłce zapytania,
• macierz testów obejmuje wartości minimalne, maksymalne i tuż poza zakresem,
• zespół produktu zatwierdził reguły, z datą i nazwiskiem osoby zatwierdzającej.

Ten problem jest jednym z naszej listy 50 problemów z konfiguratorem 3D produktu, w której opisujemy też cennik, zaokrąglenia i rozmieszczanie bram i okien na modelu.