Etap 2: dane produktów, reguły konfiguracji i model cenowy

Faza 2 przekształca zatwierdzone wymagania w model, który konfigurator produktu może wykonać. To tutaj katalogi, wymiary, kody produktów, zależności, wyjątki, formuły, cenniki i uprawnienia stają się danymi strukturalnymi, a nie wiedzą rozproszoną w arkuszach kalkulacyjnych i doświadczonych pracownikach.

To nie jest zwykłe ćwiczenie z bazą danych. Model produktu określa, co konfigurator może sprzedawać, w jaki sposób wyjaśnia wybory i jaki ustrukturyzowany wynik ma zastosowanie do wyceny, CRM, handlu elektronicznego, zamówień lub produkcji.

Seria wdrożeń: Faza 1 — odkrycie i wymagania · Faza 2 — dane produktów, zasady i ceny · Faza 3 — zasoby 3D i UX · Faza 4 — integracje i testowanie · Faza 5 — uruchomienie i optymalizacja

Co zawiera model danych konfiguratora produktu

Model danych konfiguratora reprezentuje tożsamości, atrybuty, relacje, ograniczenia i kontekst komercyjny wymagane do utworzenia prawidłowej konfiguracji produktu.

Zwykle potrzebuje co najmniej:

• rodziny i modele produktów;
• stabilne identyfikatory produktów, opcji i komponentów;
• wymiary, jednostki, zakresy i przyrosty;
• grupy opcji i liczność wyboru;
• wymagane, kompatybilne i wykluczone kombinacje;
• wartości pochodne i ilości obliczone;
• kontekst rynku, kanału, konta i roli;
• źródła cen, wzory, macierze i korekty;
• stany wizualne i odniesienia materialne;
• wycena, zamówienie, BOM i mapowanie integracji;
• identyfikatory konfiguracji i wersji.

Widoczny interfejs może wyświetlać komunikat „Antracyt” lub „Ekran boczny”. Dalsze systemy mogą wymagać kodu wykończenia, rodziny ekranów, szerokości, wysokości, silnika, tkaniny i ilości. Model łączy decyzję przyjazną klientowi z przyjętym znaczeniem operacyjnym.

Szczegółową architekturę można znaleźć w pliku przewodnik po modelu danych konfiguratora produktu.

Najpierw ustal stabilną tożsamość

Każda jednostka wielokrotnego użytku potrzebuje identyfikatora, który pozostaje stabilny w przypadku zmiany wyświetlanych nazw, tłumaczeń lub pozycji na ekranie. Przykłady obejmują:

• identyfikator rodziny produktów;
• identyfikator modelu lub systemu;
• opcja i identyfikator wartości opcji;
• identyfikator materiału i wykończenia;
• komponent lub identyfikator SKU;
• identyfikator cennika i zestawu reguł;
• identyfikator rynku, dealera i konta klienta;
• zapisana konfiguracja i identyfikator wersji.

Nazwy są treścią. Dowód tożsamości to umowa. Jeśli „biały drogowy” zmieni się na „biały RAL 9016”, zapisany projekt nie powinien po cichu stać się innym wykończeniem.

Tam, gdzie istnieją standardowe identyfikatory produktów, takie jak numery GTIN, należy ich używać zgodnie z polityką organizacji dotyczącą głównych produktów, a nie wymyślać dla wygody konfiguratora. Wytyczne Google dotyczące danych produktów również ostrzegają wydawców, aby nie wymyślali ani nie używali ponownie numerów GTIN, oraz zalecają dokładną identyfikację produktu, jeśli istnieją identyfikatory (Centrum wyszukiwarki Google).

Normalizuj katalog bez jego spłaszczania

Normalizacja nie oznacza narzucania każdemu produktowi tej samej struktury. Oznacza to oddzielenie koncepcji nadających się do ponownego wykorzystania, aby można było nimi spójnie zarządzać.

Produkt szyty na miarę może być reprezentowany jako:

• rodzina: pergola bioklimatyczna;
• systemu: model wolnostojący jednostrefowy; Parametry
• : szerokość, projekcja i wysokość;
• moduły: słupy, belki, strefy dachowe i drenaż;
• zamknięcia: ekrany, ściany przeszklone lub listwowe;
• opcje komfortu: oświetlenie i ogrzewanie;
• wykończenie: akceptowane kolory ram i elementów;
• kontekst komercyjny: rynek, sprzedawca, cennik, strefa podatkowa i instalacyjna.

Konfigurator drzwi będzie wykorzystywał różne koncepcje: ościeżnicę, panel, kierunek otwierania, przeszklenie, naświetla boczne, okucia, próg i pakiet zabezpieczeń. Konfigurator pompy może wykorzystywać opcje punktu pracy, medium, materiału, uszczelnienia, silnika i sterowania. Model musi być zgodny z rzeczywistą strukturą decyzyjną produktu.

Wymiary modelu jako regulowane parametry

Wymiary to więcej niż pola wejściowe. Każdy parametr wymaga:

• jednostka i precyzja;
• minimum i maksimum;
• dozwolone przyrosty;
• wartość domyślna;
• zależność od modelu lub rynku;
• wyświetlanie i znaczenie operacyjne;
• wpływ na geometrię, cenę, ilość i wydajność;
• testy graniczne.

Nie zakładaj, że numer pokazany klientowi jest tym samym numerem wymaganym na produkcji. Rozmiar otworu, rozmiar ramy zewnętrznej i rozmiar produkcyjny mogą się różnić. Jeśli wymagane są transformacje, nazwij je i przetestuj.

Konfiguracja parametryczna jest przydatna, gdy geometria i wyniki pochodzą ze zmiennych, a nie ze skończonej listy wariantów statycznych. podręcznik konfiguratora produktów parametrycznych wyjaśnia to rozróżnienie bardziej szczegółowo.

Przekształć wiedzę ekspercką w zasady

Reguły produktu definiują przestrzeń rozwiązań. Typowe typy reguł obejmują:

Reguły dołączania

Wybranie jednej opcji wymaga innej. Zmotoryzowany ekran może wymagać kompatybilnej jednostki sterującej.

Reguły wykluczeń

Dwie opcje nie mogą współistnieć. Dla określonego panelu drzwiowego może nie być akceptowany określony układ przeszkleń.

Reguły zakresu

System lub komponent jest ważny tylko w określonych granicach wymiarowych.

Reguły kardynalności

Użytkownik musi wybrać dokładnie jeden rodzaj dachu, może wybrać kilka akcesoriów lub musi wybrać przynajmniej jeden moduł.

Reguły pochodne

Ilości, słupki, moduły, silniki lub mocowania są obliczane na podstawie wymiarów i układu.

Reguły kontekstowe

Katalog, opcje lub uprawnienia zmieniają się w zależności od kraju, sprzedawcy, klienta, roli lub daty.

Reguła powinna mieć identyfikator, cel, właściciela, priorytet, dane wejściowe, dane wyjściowe i przykłady testów. Notatka prozaiczna, taka jak „sprawdź duże rozmiary”, nie jest logiką produktu wykonywalną.

przewodnik po silniku reguł konfiguratora obejmuje zależności, wykluczenia, ograniczenia, wyjaśnienia i zarządzanie regułami.

Zasady projektowania służące wyjaśnieniu, a nie tylko egzekwowaniu

Użytkownicy powinni zrozumieć, dlaczego dana opcja jest niedostępna. Ukrycie każdego nieprawidłowego wyboru może sprawić, że interfejs będzie przejrzysty, ale może również sprawić, że katalog będzie wydawał się niekompletny. Blokowanie wyboru bez wyjaśnienia powoduje frustrację.

Właściwe zachowanie zależy od kontekstu:

• ukryj nieistotne opcje, zanim nabiorą znaczenia;
• wyłącz rozpoznawalne opcje, gdy wyjaśnienie przyczyny pomaga;
• zasugeruj zmianę, która udostępniłaby opcję;
• zachowanie wcześniejszych wyborów, gdy nowy wybór powoduje konflikt, a następnie poproś użytkownika o rozwiązanie go;
• rozróżnij nieważność techniczną od niedostępności handlowej.

Wyjaśnienia reguł stanowią część doświadczenia z produktem i należy je przeglądać zgodnie z logiką.

Zbuduj jeden organ ustalający ceny

Ceny na żywo są dokładne tylko wtedy, gdy ich źródło i zasady są jasne. Suma może zależeć od:

• model podstawowy lub system;
• wymiary, powierzchnia, obwód, objętość lub ilość;
• grupy materiałów i wykończeń;
• ceny komponentów i akcesoriów;
• macierze cen i punkty przerwania;
• strefy pracy, przeglądów, dostaw i instalacji;
• cenniki dealerów, klientów i kont;
• marże, rabaty i limity zatwierdzające;
• waluta, podatek i zaokrąglanie;
• daty wejścia w życie i poprawki.

Zdecyduj, który system jest właścicielem każdej części. Konfigurator może wykonywać przyjęte formuły, wywoływać usługę wyceny lub otrzymywać ceny z ERP lub innego kontrolowanego źródła. Ważne jest, aby wynik był identyfikowalny i przetestowany.

Oddziel kalkulację ceny od prezentacji ceny

Obliczony wynik komercyjny i kwota pokazana użytkownikowi mogą się różnić w zależności od roli lub kanału.

Publiczna witryna internetowa może wyświetlać:

• dokładna cena konsumencka;
• zakres budżetu;
• cena „od” z jasnymi warunkami;
• brak ceny, wciąż obliczamy wewnętrzne oszacowanie.

Portal dealerów może pokazywać cenę konta, zalecaną cenę detaliczną i marżę. Wewnętrzny sprzedawca może zastosować dozwolony rabat. Model powinien opierać się na przyjętej polityce, a prezentacja jest zgodna z autoryzacją i strategią komercyjną.

Configurix może obsługiwać aktualne ceny, cenniki, formuły, podatki, opłaty instalacyjne i przepływy handlowe specyficzne dla roli, jeśli są one uwzględnione w zakresie. Dokładne kontrole administracyjne i zatwierdzające są definiowane podczas wdrażania.

Przeczytaj przewodnik po wyszukiwarce cenowej konfiguratora produktów dla wzorów, macierzy, cenników i metod testowania.

Skorzystaj z sprawdzonych przykładów, aby zbudować i zweryfikować ceny

Zbierz reprezentatywne przypadki cenowe przed wdrożeniem:

Każdy przykład wymaga oczekiwanego wyniku zatwierdzonego przez właściciela komercyjnego. „Wygląda blisko” nie jest kryterium akceptacji.

Połącz mapowania produktów, wizualne i operacyjne

Model produktu musi łączyć trzy widoki, nie mieszając ich:

1. widok klienta — zrozumiałe nazwy, obrazy i kierowane wybory;
2. widok komercyjny — linie cenowe, rabaty, język wyceny i status projektu;
3. widok operacyjny — identyfikatory, ilości, wymiary, jednostki i dalsze mapowania.

Jeden wybór może mieć wpływ na wszystkie trzy. Wybór ramki w kolorze antracytowym powoduje zmianę materiału w 3D, opisu linii w wycenie oraz identyfikatora wykończenia w zamówieniu lub BOM-ie. Mapowanie powinno być wyraźne, a nie wywnioskowane z tekstu ekranowego.

Jak Configurix podchodzi do fazy 2

Program Configurix buduje środowisko konfiguracyjne w oparciu o katalog zaakceptowany przez klienta, zamiast narzucać produktowi stałą bibliotekę demonstracyjną. W zależności od implementacji zarządzany model może łączyć:

• rodziny produktów, wymiary i grupy opcji;
• reguły zgodności, zależności i wykluczania;
• parametryczne lub modułowe stany 3D;
• kalkulacje cen na żywo i kontekst komercyjny;
• opisy i zdjęcia markowych ofert;
• uporządkowane dane dotyczące potencjalnego klienta i projektu;
• opcjonalne mapowania CRM, ERP, PIM, e-commerce, zamówień lub BOM.

Configurix obsługuje ciągłe dostosowywanie. Produkty, opcje, ceny, języki, dokumenty i przepływy pracy można rozszerzać po uruchomieniu, w zależności od uzgodnionego modelu administracji, uprawnień, zakresu wsparcia i testów regresyjnych. Zmiana powinna zachować stabilną tożsamość i zachowanie zapisanego projektu, a nie być traktowana wyłącznie jako edycja wizualna.

Zarządzanie zmianami produktów i cen

Zdefiniuj przepływ zmian przed pierwszą wersją:

1. żądanie identyfikuje produkt, regułę, cenę lub produkt, którego dotyczy problem;
2. właściciel akceptuje zamierzone znaczenie komercyjne;
3. przegląd wpływu identyfikuje konsekwencje wizualne, cenowe, ofertowe, BOM i integrację;
4. implementacja odbywa się w środowisku nieprodukcyjnym; Uruchomiono
5. przykłady regresji;
6. recenzent zatwierdza zaakceptowane zachowanie; Wydanie
7. zostało opublikowane z wersją i planem wycofania.

Zapisane konfiguracje wymagają jawnej polityki. Niektóre projekty powinny pozostać przy historycznej rewizji produktu i ceny; inne mogą zostać migrowane. Decyzja ta zależy od ważności oferty, statusu umowy i reguł biznesowych.

Typowe błędy fazy 2

Używanie etykiet wyświetlanych jako identyfikatorów

Zmiana tłumaczeń i nazw marketingowych. Stabilne identyfikatory nie powinny.

Reguły kodowania tylko w interfejsie

Wyłączenie przycisku nie jest niezawodną zasadą, jeśli interfejsy API, zapisane projekty lub inne kanały mogą go ominąć. Zatwierdź zaakceptowany stan w odpowiednim urzędzie.

Łączenie zasad technicznych i handlowych bez własności

Maksymalny zakres i rabat dealera to różne zasady stosowane przez różnych właścicieli, nawet jeśli oba wpływają na ostateczną ofertę.

Traktowanie arkusza kalkulacyjnego jako oczywistego

Formuły wymagają jednostek, zaokrągleń, pierwszeństwa, dat wejścia w życie i przepracowanych przykładów.

Generowanie BOM-u na podstawie nazw wizualnych

Wynik produkcji lub zamówienia wymaga zaakceptowanych tożsamości komponentów, ilości, jednostek, wersji i mapowań. Nie jest on tworzony automatycznie, ponieważ komponent jest widoczny w 3D.

Lista kontrolna zakończenia fazy 2

Faza 2 jest zakończona, gdy:

• rodziny produktów i wartości opcji mają stabilne identyfikatory; Wymiary
• zawierają jednostki, zakresy, przyrosty i testy;
• zależności, wykluczenia i reguły pochodne są udokumentowane i wykonywalne;
• konfiguracje normalne, graniczne i nieprawidłowe zachowują się zgodnie z oczekiwaniami;
• akceptowane są uprawnienia cenowe i ślad kalkulacji;
• zdefiniowano rynek, konto, rolę, walutę i zachowanie podatkowe;
• mapowania klientów, handlowe i operacyjne są wyraźne;
• uzgodniono zapisaną konfigurację i politykę zmian;
• zmiany produktów i cen mają właścicieli i przepływ pracy dotyczący wydania.

Następnym krokiem jest uczynienie modelu widocznym i użytecznym bez utraty jego znaczenia. Kontynuuj z Faza 3: Potok zasobów 3D i konfigurator UX dla Internetu.

Często zadawane pytania

Czy program Configurix może obliczać aktualne i dokładne ceny?

Tak, gdy przyjęta logika cenowa i dane źródłowe zostaną wdrożone i przetestowane. Configurix może obliczać na podstawie wymiarów, opcji, formuł, matryc, cenników, podatków, opłat instalacyjnych i kontekstu komercyjnego. Dokładność należy potwierdzić na podstawie zatwierdzonych przykładów i zachować w przypadku zmiany zasad.

Czy nasz zespół może później dodać lub zmienić opcje?

Tak. Configurix można dostosować po uruchomieniu. Dokładna metoda — narzędzia administracyjne, wsparcie zarządzane lub kombinacja — zależy od wdrożenia. Każdą zmianę należy ocenić pod kątem zasad, 3D, ceny, dokumentów i dalszych map.

Czy Configurix zastępuje nasz system ERP lub PIM?

Nie automatycznie. Configurix może posiadać lub wykonywać konfigurację skierowaną do klienta i warstwę CPQ podczas łączenia się z akceptowanymi produktami, cenami i uprawnieniami operacyjnymi. Granica systemu rekordów jest zdefiniowana dla każdej implementacji.

Czy w każdym projekcie znajduje się automatyczny BOM?

Nie. Generowanie BOM jest opcjonalne i wymaga identyfikacji komponentów, mapowań, ilości, wymiarów, rewizji i testów akceptacyjnych. Podsumowanie opcji sprzedaży, skonfigurowane zamówienie i BOM produkcyjny to różne wyniki i należy je dokładnie określić.