· Av Erik Svedin
Vad ett PIM-system är, hur det skiljer sig från kassa, webbshop och affärssystem, och när en cykelbutik med flera leverantörer faktiskt behöver ett.
Ett PIM-system, Product Information Management, är ett system som håller butikens produktinformation på ett ställe: artikelnummer, EAN-kod, benämning, varumärke, kategori, tekniska specifikationer, bilder och produkttexter. Därifrån skickas informationen vidare till kassan, webbshoppen, Google Shopping, Blocket och de förmånscykelportaler som kräver strukturerad data. En cykelbutik med en leverantör och en kanal klarar sig utan. En butik med tio leverantörer, en kassa, en webbshop och ett par portaler behöver antingen ett PIM eller en person som gör PIM-systemets jobb för hand, och det är den personens timmar som avgör om det lönar sig. Vi driver själva en cykelbutik och skriver det här utifrån hur det ser ut vid vår egen disk.
Ett PIM är en databas med en regel: varje produkt finns exakt en gång, och allt som ska sägas om den sägs där. Skillnaden mot ett kalkylark är att PIM-systemet också vet vart informationen ska, i vilket format, och håller reda på vad som ändrats sedan sist. Skillnaden mot webbshoppen är att PIM-systemet inte säljer något; det beskriver. Ett PIM tar emot data från leverantörerna, låter butiken komplettera och rätta, och publicerar sedan samma data till varje kanal utan att någon skriver av den. Priset och lagersaldot bor oftast inte i PIM-systemet utan i kassan eller affärssystemet, och PIM-systemet hämtar dem därifrån när det behövs.
De fyra systemen svarar på olika frågor, och problemen uppstår när ett av dem tvingas svara på en fråga det inte är byggt för.
| System | Frågan det svarar på | Äger normalt | Exempel i cykelhandeln |
|---|---|---|---|
| Kassa (POS) | Vad såldes, till vilket pris, och hur många finns kvar? | Pris, lagersaldo, försäljning | Nutid (numera Vendolink), Specter, Crona, Lightspeed |
| Webbshop | Hur ser produkten ut för kunden på nätet? | Presentation, kundvagn, betalning | Abicart, WooCommerce, Shopify, Starweb |
| Affärssystem (ERP) | Vad har vi köpt, fakturerat och bokfört? | Inköp, fakturor, ekonomi | Specter, Fortnox med lagermodul |
| PIM | Vad är produkten, och vad ska sägas om den överallt? | Artikeldata, EAN, specifikationer, bilder, texter | Ett branschspecifikt PIM eller ett generellt som Akeneo eller Plytix |
En kassa kan lagra en bild och en text per artikel, men den kan inte ta emot en leverantörs prislista med 20 000 rader och matcha dem mot sortimentet. En webbshop kan hantera varianter, men den vet inte vad som såldes i butiken i eftermiddags. Det är i gapen mellan systemen som PIM-systemet gör nytta.
En cykel som ska säljas online, i butik och via en förmånsportal behöver ungefär tjugo fält för att vara komplett, och det är fler än de flesta kassor har plats för. Modell, årsmodell, ramstorlek, färg, EAN per variant, tillverkarens artikelnummer, vikt, ramtyp, växelsystem, bromsar, motor och batterikapacitet på elcyklar, rekommenderat pris, kategori, minst två bilder och en produkttext. Delar och tillbehör klarar sig med färre fält men har i gengäld ett annat problem: kompatibilitet. Ett växelöra, en kedja eller ett bromsbelägg är bara rätt för vissa cyklar, och den informationen finns sällan i leverantörens fil utan måste läggas till av butiken. Det är typiskt PIM-data: den finns ingen annanstans och den ska synas i alla kanaler.
Tumregeln är att behovet uppstår när butiken har fler än tre leverantörer som skickar prislistor och fler än en kanal att publicera i. Under den gränsen är kassan som huvudkälla och webbshoppen som spegel fullt tillräckligt. Över gränsen kommer signalerna en och en: cykeln har stått i butiken i tre veckor men ligger inte ute på webben, samma artikel finns två gånger i kassan med olika benämning, säsongens prislista ligger i ett kalkylark som ingen vågar läsa in, och förmånsportalen skickar tillbaka filen för att EAN saknas på hälften av raderna. Förmånscykeln är i sig ett skäl: portalerna kräver strukturerad produktdata per variant, och en butik som inte kan leverera den syns inte där en stor del av cykelköpen numera görs.
Delvis, och det är så de flesta butiker faktiskt gör. Kassan som huvudkälla fungerar så länge artikelregistret är städat, varje artikel har EAN och antalet leverantörer är litet. Webbshoppen som huvudkälla fungerar för butiker som säljer mest online och har få varianter. Båda lösningarna brister på samma tre ställen: de kan inte läsa in leverantörernas filer utan manuellt arbete, de har begränsat stöd för varianter och bilder, och de saknar plats för kompatibilitetsdata. En butik som väljer kassan som huvudkälla bör åtminstone se till att registret städas en gång ordentligt och att nya artiklar alltid läggs upp med EAN från start; det är det billigaste sättet att skjuta upp behovet av ett PIM.
Från leverantörerna, i det format varje leverantör råkar använda. Vissa cykelleverantörer erbjuder ett API där data hämtas automatiskt, andra lägger filer på en FTP-server, och många skickar fortfarande Excel- eller CSV-filer per mejl inför säsongen. PIM-systemets första jobb är att läsa alla formaten och matcha raderna mot butikens sortiment, i första hand på EAN-kod och i andra hand på tillverkarens artikelnummer. Det som inte matchar redovisas i stället för att tyst falla bort, och det är där butiken hittar nyheter, utgångna artiklar och sådant som bytt benämning sedan förra listan. Först därefter kompletterar butiken med det leverantören inte levererar: kategori i butikens eget träd, kompatibilitet, egna texter.
Tre saker, och ingen av dem är teknisk. Ett artikelregister som går att lita på, vilket i praktiken betyder en genomgång av dubbletter, benämningar och saknade EAN-koder innan något system kopplas in. En person som äger produktdatan, alltså någon som bestämmer hur en artikel ska heta och i vilken kategori den ska ligga när leverantören och webbshoppen säger olika saker. Och tid vid säsongsskiftet, när nya prislistor kommer och gamla modeller ska ut; PIM-systemet gör arbetet mindre, inte noll. Butiker som hoppar över den första punkten får ett PIM fullt av samma dubbletter som kassan hade, fast nu i fler kanaler.
Ett generellt PIM är byggt för vilken bransch som helst och kräver att butiken själv bygger kopplingarna till leverantörerna, definierar fälten för en cykel och sätter upp kanalerna. Ett PIM byggt för cykelhandeln har leverantörernas format, cykelns fält och kanalerna som Blocket och förmånsportaler färdiga från början, och kan innehålla sådant som ett generellt PIM aldrig får: vilket växelöra som passar vilken ram, vilka bromsbelägg som passar vilken broms. För en butik med fem till femton anställda är skillnaden i praktiken om uppsättningen tar veckor eller månader. Central PIM i BikeOffice är ett sådant branschspecifikt system; den som vill jämföra bör fråga varje leverantör hur många cykelleverantörers format som redan finns inlästa.