Produktdata afgør, hvornår en 3D-konfigurator kan gå live

En lanceringsdato for en konfigurator bliver som regel sat ud fra den synlige del af projektet: 3D-assets, interaktionsregler, integration i frontend. Den dato, der holder, bliver sat et mere stille sted, i de produktposter, konfiguratoren læser hver time.

En potentiel kunde beskrev forventningen ligeud: "Som jeg ser det, bør et produkt, der er aktivt på websitet, kunne bygges i konfiguratoren, og leveringsoplysningerne bør hentes på samme måde, som vi alligevel gør, når det lægges i kurven." Det er en rimelig beskrivelse af, hvordan en konfigurator opfører sig, når data er i orden. Det er arbejdet med at få kataloget i den orden, der flytter lanceringsdatoer.

Hvad klar produktdata betyder

En konfigurator læser dit produktkatalog. Den henter de samme poster som din webshop og lægger dine regler ovenpå: hvilke moduler der kan kombineres, hvilke stoffer der hører til hvilket stel, hvad en konfiguration koster, og hvad køberen får at vide om levering. Produktdata er klar, når hver post, konfiguratoren rører, har de felter, den har brug for, med de navne, dine egne teams allerede bruger.

Tre ting adskiller det fra en almindelig oprydning i kataloget. Konfiguratoren læser hver variant, så et felt, der er valgfrit til merchandising, bliver påkrævet. Den læser dem løbende, så én ufuldstændig post påvirker hele importen. Og den læser dem op mod et regelsæt, der allerede findes i virksomheden, som regel i hovedet på en enkelt medarbejder og i et par mailtråde.

Hvad konfiguratoren læser fra hver produktpost

På Shopify er kravene konkrete og dokumenterede. Før et produkt får PLANNER-tagget, skal hver variant have et unikt SKU, en pris, et unikt Planner ID-metafelt og et konfigureret Planner Features-metafelt, og produktets status skal være Active. De fem betingelser er adgangsbilletten til konfiguratoren.

Samme type krav gælder på andre platforme. Vi integrerer med Shopify Plus, SAP Commerce, Salesforce Commerce og skræddersyede backends, og hver integration har brug for en stabil identifikator pr. variant, en pris, den kan læse, og en struktureret beskrivelse af, hvad varianten er. Hvor de tre findes, kører læg-i-kurv, lagertjek og prisberegning i din eksisterende checkout. De samme poster føder den vareoversigt, de samlede mål og den leveringstid, køberen ser under konfigurationen, og det er et af de steder, hvor en 3D-konfigurator overlapper med CPQ-software.

Ved siden af handelsposten ligger geometrien. De fleste brands har en del af den på plads fra start: "Vi har 3D-filer til vores produkter, nogle også i Revit" er et almindeligt svar i begyndelsen af et projekt. Kvaliteten af dine assets bestemmer det visuelle resultat. Produktposten bestemmer, om konfiguratoren overhovedet kan nå dem.

Hvor ugerne reelt går

Forsinkelsesmønstret er dokumenteret på tværs af vores egne onboardinger. En udvikler tjekker shoppen, finder varianter med et tomt felt og melder det til projektlederen, projektlederen giver det videre til kunden, kunden retter en del af listen, og en ny runde begynder. På én Shopify-onboarding løb den sløjfe op i 26 kommentarer over tre måneder alene for borde og stole. Ti onboardinger viser samme forløb.

Arbejdet i en runde er lille: tilføj et SKU, sæt en pris, udfyld et metafelt. Hver runde koster alligevel en uge eller mere, fordi den går gennem tre personer og to systemer, før næste tjek kører.

Derfor har en lanceringsplan, der kun bygger på 3D-leverancen, en tendens til at skride. 3D-arbejdet er planlagt fra dag ét og følges op mod en dato. Datarunderne bliver opdaget én ad gangen, og hver opdagelse starter sløjfen forfra. At planlægge begge spor samlet er den praktiske forskel på en tidsplan på 13 uger for en konfigurator og en tidsplan med åben slutdato.

Hvad ufuldstændige data gør ved en live konfigurator

Efter lanceringen gælder de samme krav fortsat. Når et produkt får PLANNER-tagget, mens et SKU, en pris eller et identifikator-metafelt stadig er tomt, fejler importen i næste kørsel og bliver ved med at fejle hver time, indtil tagget fjernes. Fejlen omfatter hele kataloget, så ét nyt produkt kan bringe konfiguratorens data ud af trit med shoppen for alle købere, der bruger den.

Navngivning giver en mere stille udgave af samme effekt. "Polished Aluminium" i konfiguratoren og "Chrome" i ERP-systemet beskriver én finish, og en køber, der møder begge, vil spørge, hvilken af dem der kommer. En farvekode skrevet 0114 i ét system og 114 i et andet rejser samme spørgsmål. Britisk og amerikansk stavning og forskelle i store og små bogstaver når os på samme måde, som kundefeedback efter lanceringen. Hver rettelse tager 15 til 30 minutter pr. batch, når nogen først har fundet ud af, hvilket system der har det oprindelige navn.

Begge tilfælde viser produktposten som grænsefladen mellem dine systemer og konfiguratoren, og den rolle har den i hele integrationens levetid.

Sådan gør du data klar, før udviklingen starter

Fire trin dækker det meste, og alle fire kan køre, før det første asset er leveret.

• Kør felttjekket selv. Eksportér kataloget, og bekræft, at hver variant, der skal i konfiguratoren, har et unikt SKU, en pris og en unik identifikator. Dublerede identifikatorer er det hyppigste enkeltfund, og de dukker hurtigst op i et regneark.
• Send det officielle navneark. En ERP-eksport af produkt-, farve- og materialenavne, i præcis den form, jeres organisation bruger, bliver konfiguratorens facitliste. Den afgør navnespørgsmålene, før de når en køber.
• Skriv reglerne ned. Kombinationslogikken findes allerede. En potentiel kunde beskrev et modulsystem i en enkelt sætning: start med et basismodul med gavl i begge sider, og tilføj derefter ét modul ad gangen til venstre eller højre. Når det kommer på papir tidligt, kan udviklingen starte på jeres egen logik.
• Afgræns dine assets for sig. Tilgængelighed og format for dine assets styrer tidsplan og omkostninger på et spor for sig. Fortæl tidligt, hvad der findes og i hvilket format, så de to spor kan køre side om side.

Klar produktdata er den del af et konfiguratorprojekt, der har den længste gennemløbstid og er mindst synlig. Brands, der kører felttjekket og sender navnearket, før udviklingen starter, går direkte fra levering af assets til integration. Timerne bliver brugt under alle omstændigheder. Forskellen er, om de kommer som én samlet arbejdsopgave eller som en runde hver uge.