Produktinformation kan liknas med ett företags kroppspulsåder där livsviktigt information flödar genom hela företaget. Oavsett användare och roll har man troligtvis något form av informationsbehov kopplat till företagets produkter eller tjänster för att kunna utföra sitt dagliga arbete. Frågan som vi här ställer oss är - hur kan produktinformation flöda genom ett företags olika system för att tillgodose informationsbehovet, från både interna och externa intressenter? Med produktinformation menas alla typer av produktrelaterade egenskaper och attribut som är nödvändiga för att kunna hantera processer för finansiell- och sortimentsplanering, prognostisering och inköp, lagerhantering och påfyllnad samt slutligen sälj- och marknadsmässig berikning och spridning via tillgängliga säljkanaler.

Numera finns en förväntan hos konsumenten att interaktionen med ett företags produkter skall vara enhetligt oavsett säljkanal. Detta ställer ett antal krav på de bakomliggande systemen som vi kommer att visa prov på nedan. Detta inlägg avser att ge exempel på ett vedertaget produktmönster baserat på Dynamics 365 for Finance and Operations (D365 F&O) tillsammans med ett antal vanligt förekommande ”best-of-breed” system hos en fashion retailer. Innan vi dyker ner i detaljerna kanske ni frågar er varför alla dessa sidosystem verkligen skall behövas? Kan man inte bara lyfta in samtliga förmågor i D365 F&O? Även om D365 F&O tillsammans med lämplig partnerlösning för fashion retail är väl positionerat för att kunna tillgodose samtliga av ovanstående nämnda processer får man inte glömma att kunden i många fall har investerat stora mängder tid och pengar i ”best-of-breed” system (exempelvis PLM-, PIM- och DAM- system) som man inte är beredd att ersätta bara för att affärssystemet skall bytas ut. Istället behöver man hitta ett sätt där man drar fördel av styrkorna med respektive system på ett optimalt sätt. Därav behovet av ett produktmönster som beskriver flödet av information mellan de olika systemet samt vad respektive system har för ansvar och huruvida det agerar ”master” eller ”slave”.

Produktmönster för en fashion retailer

Produktmönstret nedan är speciellt utformat för en fashion retailer och har som syfte att ge en vy över produktinformation som flödar mellan ett företags olika system. Viktigt att tänka på är att detta endast är en produktvy vilket innebär att det finns annan information som behöver flöda mellan dessa system som inte tas upp i inlägget, exempelvis kundinformation, lagersaldo, säljorder, kvitto osv.

Product pattern

Alla produkter, både egenutvecklade och externa (inköpta från leverantör), skapas upp i PLM (Product Lifecycle Management)- systemet. Här kan man annars tänka sig att egenutvecklade produkter hanteras av PLM systemet medan inköpta produkter hanteras av PIM- systemet. Argument som talar för föreslaget angreppssätt är en enhetlig process oavsett typ av produkt. PLM- systemet äger produktutvecklingsprocessen samt ”sampling”- hanteringen fram tills dessa att produkten är redo att köpas in. Statuskoder på produkten styr sedan när information om produkten skall göras tillgänglig för kringliggande system. Vissa produktegenskaper ”föds” kontinuerligt tillbaka till PLM systemet så som uppdateringar kring produktlivcykelstatus.

Skapade produkter konsumeras av PIM (Product Information Management)- systemet där berikning sker utifrån ett sälj- och marknadsperspektiv, inkl. bilder och annan relevant media. Hantering av upphovsrättsskyddat material kopplat till bilder och annan media säkerställs av DAM (Digital Asset Management)- förmågan som i detta exempel är en del av PIM- systemet. Produktvarianter så som färg- och storlekskombinationer, så kallat SKU:er (Stock Keepint Units), skapas upp och hanteras av PIM- systemet. PIM- systemet tillhandahåller även ett ”kontrolltornsperspektiv” av tillgängliga sortiment över samtliga kanaler. Detta är typiskt något som står högt upp på en kunds önskelista och något som ett PIM system är betydligt bättre lämpat att hantera än ett ERP system. Framförallt om man är en internationell aktör som agerar på många marknader och via både fysiska och digitala kanaler och antalet säljkanaler därmed är omfattande.

Produkter- och produktvarianter konsumeras av Dynamics 365 F&O (ERP) där berikning sker utifrån ett inköp/lager- och pris-/kampanjhanteringsperspektiv. Utifrån fördefinierad logik kan Dynamics 365 F&O sedan publicera ”tillgänglighetsmeddelanden” baserat på om en produkt har köpts in eller finns i lager som sedan kan konsumeras av PIM- systemet samt tillgängliga säljkanaler så som Ecom och POS (Point of Sale). Sker försäljning i både digitala- och fysiska kanaler är rekommendationen att all pris- och rabatthantering hanteras av Dynamics 365 F&O. Har man endast en närvaro i digitala kanaler räcker det oftast med pris- och promotion motorn som tillhandahålls av Ecom plattformen.

Förutom generell produktinformation är Ecom (E-handelsplattformen) i behov av navigeringshierarki, bilder, säljande texter och översättningar som här tillhandahålls av PIM- systemet. Att denna förmåga placeras i PIM systemet och inte i Ecom grundar sig i att man vill ha en enhetlig hantering oavsett säljkanal. Många av de större PIM- lösningarna erbjuder standard connectorer mot ett antal Ecom- lösningar vilket minskar utvecklingsbehovet avsevärt.

Produktinformation så som priser och säljande attribut distribueras av D365 F&O och dess Retail Server via standard API:er som kan konsumeras både av den interna Dynamics POS samt av externa POS (Point of Sales)- system. Förslagsvis distribueras samtliga produkter till POS- systemet, även de som ej finns för försäljning i butik. Detta för att kunna stödja ett ”Unified Commerce”- scenario där konsumenten handlar on-line men vill kunna returnera varan i butik.

Basdata för produkt föds från PIM till Marketing Automation (MA)- systemet. Detta för att MA- systemet skall kunna skapa och hantera personaliserade erbjudanden och andra typer av externa utskick där produktinformation ingår.

En produktfeed tillämpas för att fånga upp ”dagsfärsk” produktinformation i samband med E-mail kvitton och olika typer av kampanjändamål.

Lärdomar att ta hänsyn till

  • Försök att mappa system mot användarroller i syfte att undvika att användaren skall behöva hoppa mellan olika system för att utföra sina arbetsuppgifter. Detta har även en kostnadsaspekt kopplat till sig då det hjälper att hålla nere licenskostnaderna. Exempelvis kan man tänka att produktutvecklingsavdelningen primärt jobbar i PLM systemet, merchandisers i PIM/DAM och inköpare i D365 F&O osv
  • ”Keep it simple”. Det vill säga försöka att definiera enhetliga processer, undvika avvikelser i den mån det är möjligt samt försök att dra fördel av respektive systems styrkor.
  • Investera i en framtidssäkrad plattform. Detta är ett område där utvecklingen går otroligt fort och det är därför av största vikt att systemen kan utvecklas i takt med verksamheten. Detta ställer både krav på en arkitektur som kan skala ut i takt med ökade transaktionsvolymer men även som kan hantera förändringar baserat på nya affärsmöjligheter och krav.

Har ni frågor kring ett lämpligt produktmönster för just er organisation eller om er nuvarande plattform kan anses framtidssäkrad så tveka inte att höra av er till oss. Har ni synpunkter på ovan så tas även det tacksamt emot.

Add new comment

Comment editor

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
Blog moderation guidelines and term of use