Protokoll 3

L, A och I presenterar sig och I godkänner att inspelningen påbörjas. I befinner sig i desktopapplikationen.

L: Vi vill att du visar hur du arbetar i Enrich och sen kommer vi kanske ha några följdfrågor på det. Men mest för att se hur man använder det ute på företagen. I: Absolut. Jag tänker att jag visar först de redaktionella arbetsmoment som vi använder oss av i desktopklienten. Och sen kör jag lite på vad vi gör i webbversionen. L: Aa.

I: Dels så har jag arbetsmappar där jag har sparat ner olika urval, alltså querys från webbklienten som man kan använda sig av i desktopklienten. Dels för att kunna få en tydligare överblick av alla entiteter.

L: Mm.

I: Och det vi arbetar mycket med här är texter och bilder. Så i vår delade mapp så använder vi oss av säsongbetonade mappar.

L: Okej.

I: Vi har olika querys här på olika översättningjobb tex. Och sen de vanligaste, de som behöver text. Och det är egentligen produkter vi har. Så vi kan gå in på för nästa säsong här, ”fall winter 20/21”. I den här miniatyröverblicken så har vi complete- statusen. Den är inte jag så mycket inblandad i, men många av de högre uppsatta här använder sig av den för att se vilken status ett visst urval har med en snabb överblick. Men jag arbetar med i tabellvyn och med fields. Och då för att se dels vilka kategorier en produkt ligger i dels kort beskrivning och lång beskrivning som våra textredaktörer håller på med när de skriver texterna. Och sen har vi statusen för att se var en produkt ska hamna. Och i den här så har vi bara de som behöver text. Och den här statusen sätts av våra inköpsassistenter och våra inköpare när de registrerar varje produkt i programmet.

L: Mm.

I: Och är det en återkommande produkt som redan har text så har de redan en status som är ”klar SV”, som är klar på svenska. Men är det en ny eller är det en uppdaterad produkt så brukar de sätta att den behöver text. Och här inne tror jag att de mesta var helt nytt. Det är några som har en kort och en lång beskrivning, men som behöver uppdateras.

L: Okej.

I: Sen har vi aktivitet, som ligger bredvid status här. Vi har använt oss av den entiteten mer förr i tiden genom att sätta regler för vilka sidor som produkten ska visas på. Men nu är det mer som ett filterval för slutanvändaren, alltså kunden. L: Okej.

I: De använder sig av den för att kunna filtrera ner till exempel [produktkategori] på [underkategori] och [underkategori] eller på [underkategori].

L: Ja.

I: Sen har vi lite för våra momskategorier och tariffkoder och liknande som är för vår lagerhantering. Sen har vi säsongen här som är den sista viktiga delen. Den använder vi oftast för att sortera om säg en [produkt] som ser likadan ut i själva utföranden, men som har en ny färg för varje säsong så hanterar vi den på en lägre nivå. För den nivån vi ser här nu är produktnivån.

77

I: Om man går in på den översta här (produkten i listan), så har den underliggande artiklar. Det här är produktnivån och sen så har vi artikelnivån som är entiteter som är kopplade till produkter. Och sen under det har vi SKU-nivå, storleken kan man säga. Och det ser vi här ute på type (i tabellvyn) att allt här är produkter.

L: Mm.

I: Så de är de tre nivåerna som vi använder oss av för varje produkt vi säljer. L: Mm.

I: Säsongen som vi ser på produktnivå, ni ser här att den har två säsonger. Och det är då precis det jag sa, att det fanns då en färg eller en artikel på artikelnivån som var för säsongen ”sommarsäsongen 2019” och sen är det en artikel som är för ”fall winter 20/21”.

L: Just det.

I: Så den här kolumnen (Säsong), de här entiteterna är egentligen bara kopierade. Tagna från de artiklarna som ligger under respektive produkt.

L: Mm.

I: Vi kan gå in på [kategori] och [underkategori]. Och här kan vi se mer vad vi använder oss av för statusar i det här fältet (Status). Vi har ”klar” och vi har ”klar SV” som är klara produkter för web-shopen. Sedan har vi även fysiska butiker här uppe. Säg att en butik vill ha en specifik sak bara till deras butik så har de en egen status som heter butik då. Och det är för att vi ska kunna särskilja på om de ska ha en bild och om de ska ha en text. För om det bara är köpt till en butik så lägger vi inte ner den arbetskraften det krävs för att få hem texter och bilder till dem.

L: Nä. Vad har ni då för information på de som ligger i butik?

I: Då är det mer teknisk information som pris, storlekar, momskategorier och så för att lagerhanteringen ska fungera. Och namn och underkategorier.

L: Mm.

I: Men vi kan gå in på någon som har status ”butik”. Så se vi här att det finns text på några. Då är det ofta texter som vi har fått direkt från leverantör som har blivit inmatade automatiskt när inköpsassistenterna registrerar ordrar till exempel. Så då får i stort sett vår leverantör ett Excel-utdrag som har alla de här kolumnerna och så får de fylla i varje kolumn med de produkterna som vi har lagt order på.

L: Okej.

I: För att det ska gå snabbt att registrera och att det blir rätt med streckkoder och liknande.

L: Mm.

I: Så de här färdiga beskrivningarna som vi får, de kan vara både av hyffsad kvalité och väldigt, väldigt dålig kvalité.

L: Okej.

I: Beroende på om det är svenska eller utländska leverantörer. Vi har fått i stort sett Google Translate-texter.

L: De kan ju vara lite som de är.

I: Ja, precis. Men det här (tabellvyn för produkterna) använder vi oss ofta av och särskilt de här förgjorda querysen. Det här (befinner sig i en ny mapp) är för årets säsong inför sommaren. När vi ska skriva texter så drar vi ofta ut allting på ett Excel- ark för att det ska gå snabbt och det ska vara enkelt att fylla i flera produkter samtidigt istället för att sitta och klicka in på varje produkt och fylla i Details-vyn.

78 L: Jag förstår.

I: Och sen när vi har gjort det så är det oftast en helt vanlig import som vi gör. Och det är stort sett texterna. Sen har vi vår fotograf och bildansvarig som använder sig av en annan query som är på artikelnivån. Och då har vi en helt annan vy på det hela (tabellvyn innehåller andra kolumner). Om vi går in här (på en artikel) så är det ofta att man lägger till bilderna under resurserna.

L: Mm.

I: Det här är väl lite det som är kruxet med desktopklienten, att man inte kan gå in på en nivå och se flera överliggande nivåers entiteter. Att man inte kan se produktnamnen i den här rutan (i tabellvyn) utan då får man göra en export från webbklienten istället.

L: Ja, okej. Så du kan inte utifrån det där se vilken produkt den artikeln tillhör? I: Precis. Utan då får man gå in på varje produkt för sig och då kan man se att det här tillhör [produktnamn]. Men utifrån den här vyn så ser man inte. Och man kan inte heller sortera på märke eller namn eller så, utan då får man göra det via webbklienten som jag tänkte visa sen.

L: Okej.

I: Sen kommer jag till det som jag brukar göra mest och det är kampanjer och sätta ihop olika urval av produkter som ska visas på olika sidor. Vi kan gå in här till exempel på [produktkategori]. Här har jag gjort ett urval i webbklienten för alla artiklar som har märket [märkesnamn], men som inte innehåller några färger som heter ”khaki”, ”deep sea blue” eller ”blackout” och som inte heller har säsong ”SS 20”. Så det är en rätt krånglig query som jag har gjort här för att få ett urval med artiklar som vi ska sätta ner priset på eller liknande.

L: Mm.

I: Och de här använder jag sen i en annan entitet som heter kampanjer. Då har vi en kampanjentitet som vi tar de här artiklarna (resultatet av sökfrågan) och lägger dem i respektive kampanj för att vi ska kunna sätta ner priset på endast de här artiklarna till exempel.

L: Mm.

I: Och här har vi lite olika. För i den här kampanjen så ligger det produkter och inte artiklar. Om man sätter ner priset på dem då så kommer det blir på alla produkter som ligger här (i kampanjen) samt alla artiklar ligger eller kommer att bli inlagda på dem produkterna. Så vanligtvis om det är småkampanjer, till exempel bara för den här dagen eller bara för veckan, så använder vi oss av produkter. Men är det större kampanjer som utförsäljning eller nu när vi har lagerrensning så lägger vi det på artikelnivå för att nya säsonger av samma produkt inte ska komma in på nedsatt pris. Om det kommer in en likadan fast en annan färg nästa år till exempel.

L: Just det.

I: Och här har vi då externa program som vi använder oss av för prisnedsättningar. Det är därför ni inte ser att det finns någon rabattsats här i.

A: Vad är det för program?

I: Vi har ett som heter ShopAdmin som är företagsspecifikt för hela vårt övriga företag som vi egentligen är tvingade att använda och som fungerar väldigt bra med övrig programvara som vi har på plats här.

79

I: Ja. Det krävs ju rätt mycket utveckling och problemlösning när man ska försöka få två program att fungera tillsammans som inte är gjorda för det från början. Men när jag kom in i det hela så har det fungerat rätt bra. Sen så vet jag att ny programvara som vi har implementerat efteråt så har det krävts väldigt mycket felsökning på.

L: Okej.

I: Då är det ShopAdmin och sen har vi ett som heter Diver också som är mer för de som utvärderar hur försäljningen går. Det har jag ingenting med att göra så där kan jag bara namnet på programmet i stort sett.

L: Mm. Men du föredrar att jobba i desktopapplikationen med det här då?

I: Ja, med att sätta urvalen till specifika kampanjer så föredrar jag absolut desktopklienten för att jag har egentligen inte hittat ett enkelt och simpelt sätt att arbeta med det i webbklienten.

L: Okej. Vad är det som är skillnaden?

I: Det är enkelheten at flytta över ett urval härifrån (arbetsmapp) till en specifik kampanj här (relationskopplingarna i kampanjentiteten) och få det på ett överblickbart sätt.

L: Okej.

I: Om jag flyttar över alla här så kan jag se det med en gång, att de verkligen har kommit in på rätt ställe och att alla är med.

L: Då är jag med.

I: Sen har också det sina begränsningar för skulle jag nu vilja ta... Det här är ett problem som jag har rätt ofta när man ska göra om gamla kampanjer eller man inser att den här kampanjen har vi haft, den ligger fortfarande live, men den är lagd på produktnivå och vi har nya artiklar som kommer in på den. Så om jag skulle vilja ta det urvalet som ligger på en aktiv kampanj redan och byta ut alla produkterna mot motsvarande artiklar. Så jag vill ta varje produkt och byta ut den och istället lägga till artiklarna som ligger under den här produkten så kan jag inte göra det här. För jag kan skapa ett nytt arbetsområde, jag kan markera alla produkter, jag kan dra över de till... Trodde jag att jag skulle kunna göra i alla fall. Markera alla produkter. Här har vi ett litet problem som ibland inträffar och det är att klickfunktionen är en senare.

L: Ja, just det.

I: Ni ser att det markeras där jag klicka förra gången. L: Men vad konstigt.

I: Och detta brukar innebära att man får starta om hela klienten, så vi testar att göra det. Och jag har ingen aning om det beror på våra datorer eller om det beror på inRiver-programmet eller om det beror på uppkoppling via VPN eller liknande. Men den här fråga är ställd till inRiver för rätt längesen, men de har inte kommit på någon smart lösning ännu.

L: Okej.

I: Då gör vi om. Då är vi inne på en ny kampanj här. Då testar vi att skapa ett nytt arbetsområde och drar över. Sådär, här fick jag över alla produkter som ligger här (under kampanjen) till arbetsområdet. Men sen om jag skulle vilja lägga in alla artiklar under varje produkt under det här fältet här uppe istället (artikel-kopplingar i kampanjen) för att man då ska undvika att få nya artiklar på samma produkt som inte ska ingå i kampanjen helt enkelt. Då får jag oftast gå in på varje produkt och ta

80

alla artiklar och dra över allt till ett nytt arbetsområde och sedan då dra över alla de artiklarna till kampanjen.

L: Mm.

I: Här hade vi bara en kampanj med 40 produkter, men vi har kampanjer där det är 10 000 produkter och då tar det rätt lång tid om man vill göra på det här sättet. Då är det oftast lättare att ta bort den kampanjen och skapa en ny kampanj och göra en query på artikelnivå i webbklienten.

L: Okej.

I: Jag kan bara gå igenom det jag arbetar med, men jag kan gå igenom lite kort att vi har tillvalsprodukter på vissa produkter. Till exempel [produktnamn]. När du går in och tittar på en [produktnamn] så ska du kunna se vilken [produkttillbehör] och [annan produkt] som passar till den. Sen har vi tre stycken kanaler och det är kanalerna som publicerar innehållet i PIMet i respektive databas som senare kopplas då till hemsidan.

L: Mm.

I: Och vi har då vårt kassasystem som heter VMS Pos. Vi har kampanjkanalen som är kopplad till de programmen som jag pratade om precis; ShopAdmin och till hemsidan. Sen har vi Web-kanalen. Så det är kanalen som publicerar alla bilder till vår databas så att de syns på hemsidan. Alla bilder som läggs då på artikelnivån. Och just nu har vi ett problem med vår synkning till hemsidan så den här kanalen är jag ofta inne och arbetar på och synkroniserar allt material manuellt varje dag. Och det är egentligen en lätt fix så det är bara att klicka på synchronize här, men det är ett av de dagliga arbetsmomenten just nu som vi förhoppningsvis ska kunna få bort.

L: Okej.

I: Och då har vi då istället för details-fönstret channel manager-fönstret som jag arbetar i.

L: Just det.

I: Men sen har vi här ett kategoriträd som går att arbeta med både härifrån och i webbklienten. Det är egentligen vår struktur på hemsidan så underkategorier och den underliggande strukturen på hemsidan kan man se här. Då har vi en dold kategori som heter [kategori] och sen har vi [kategori], [kategori] och barn samt [kategori]. Och där har vi då alla kanalnoder. Och det går att hantera härifrån. Man kan lägga till nya kategorier här och man kan se vilka produkter som ligger under varje kategori. Men i det här gränssnittet så är det rätt jobbigt att arbeta med det eftersom man bara har den här lilla rutan och det finns inget bra sätt att förstora den och sedan få tillbaka det ursprungliga.

L: Okej.

I: Så där tänkte jag att vi lämnar den här klienten lite och går in på webbklienten. Så här är det Enrich som jag använder mig mest av för att skapa querys. Och då kan vi gå in och titta på den som heter ”behöver text” till exempel. Så här är samma urval, men jag har inte alls samma möjlighet att lägga över de här i en kampanj på ett enkelt sätt och att hitta kampanjerna i det här anser jag vara väldigt omständligt. Jag har fortfarande inte hittat själva kampanjerna.

L: Okej.

I: Så jag använder mest det här för att skapa querys för att sedan då använda dem i desktopklienten.

81

I: Vi går in på en redan uppskapad här. Så här ser queryn ur här då. Vi vill ha ut entitetstypen artikel, men själva artikeln ska inte innehålla varken ”never out of stock säsongen fall winter 20/21” eller ”SS20”. Vi vill sätta de artiklarna som inte är nya på kampanjen. Och sen ska den relaterade produkten till de här artiklarna ha märket equals [märkesnamn] och statusen ska vara det som används. Så de som behöver text, används ej, gammal, de ska inte följa med ut på den här för vi ska reducera datamängden som ska ut till varje kampanj.

L: Just det.

I: Så det här är egentligen bara att göra urvalen som vi behöver. A: Tycker du att search queryn fungerar smidigt?

I: Ja, det får jag lov att säga att det tycker jag. En sak som jag tycker man skulle kunna förbättra på den är att man kan addera fler relationskopplingar. Nu är inte det här ett större problem som jag ser det, men att man lägger till en relation på artikel och en relation på... Säg att jag bara vill ha ut de som ingår i den här kampanjen till exempel. Så om vi har en vinterkampanj med 20 märken och 10 000 produkter så vill jag kunna göra en query på artiklar som har en produkt av märket det här, men ingår i den kampanjen.

L: Aa, just det.

I: Men nu ska man bara lägga till en enda relations-condition. Och completeness condition här använder jag nästan aldrig. Eller aldrig för att det är så pass osäkert vad som är vad.

L: Okej.

I: Vi har produkter som kan ha alltifrån 35% till 100% och allt däremellan som är klara bara att det finns en artikel i en produkt som ska vara i butiken till exempel. Som har status ”butik” och då anses den inte som klar. Och det är snarare hur mina föregångare här har satt upp att programmet ska arbeta.

L: Mm.

I: Så den är överflödig för just oss. Men både data-condition och relations-condition används ofta. Sen har vi ett urval som heter allt och det är egentligen för att vi ska kunna göra större landningssidor där vi har allt på hela hemsidan, men som jag ändå vill kunna ta bort vissa saker ifrån. Så det finns ett hårdkodat urval som en utvecklare har gjort som tar med allt som finns, men sen vill vi kunna använda urval. Som vi har till exempel här vi ska ha allting som har en huvudkategori som heter [kategorinamn]. Vi har tre huvudkategorier hos oss. Det är [kategori], det är [kategori] och [kategori]. Säg att vi har en kampanj som är 20% på alla [kategori] eller all [kategori] eller 20% på alla [kategori]. Så vi vill kunna skilja på dem i ett tidigt skede. L: Mm.

I: Enrich är det enda systemet i webbklienten som används av de andra redaktörerna.

L: Okej. Om ni delar upp vem som ska göra vad på en produkt, hur kommunicerar ni vem som ska göra vad?

I: Eftersom vi är rätt få här så använder vi oss nästan inte av Task, utan det är muntligt. Och sen har vi bara en person arbetar med bilder. Vi har haft tidigare en person som har arbetat med produkttexter och en person som har arbetat med content för övriga hemsidan.

L: Yes, då är jag med.

I: Enrich har vi enbart för produktregistrering så det används inte till content creation i den bemärkelsen.

82 L: Okej.

I: Jag arbetar mycket i Plan and Release också. Och det är för att se över strukturen som jag visade förut på hemsidan. Och då har vi samma kategoriträd här med huvudkategorier, underkategorier och produktkategorier helt enkelt. Och här sätter vi namn på dem. Vad de ska heta på hemsidan. Vi sätter vilka regler de ska använda sig av för att plocka in produkter från systemet.

L: Just det.

I: Så här ser vi att på den här nivån, [huvudkategori], så finns det inga och inte heller under på [underkategori]. Utan alla regler sätts på den understa nivån. Och detta är en kombination av externa utveckling och inRiver-användandet.

L: Mm.

I: Om vi går in på hemsidan. Här har vi alla kategorierna. Och då har vi samma struktur här. Vi kan gå in på [kategori] och här syns då alla produkter som alla de här underkategorierna (kategorierna i Plan and Release).

L: Just det.

I: Och sen har vi då de underkategorierna som filter här. Den laddar inte om sidan utan då sorterar den bara vilka produkter som visas. Men samtidigt har vi, säg på [kategori], så kan man gå in på länkar som leder en till just den sidan också. Så vi har filterkategorierna som bara sorterar på nuvarande sida samt länkar som går till respektive sida.

L: Okej. Så de där upp är länkar?

I: Precis. Vi använder oss nästan aldrig av querys i kategoriträdet här (i Plan and Release) och det är väl för att vi vill ha det så enkelt som möjligt. Sen har vi det problemet att vi inte får någon automatisk synkronisering just nu så jag är väldigt mycket inne på Publish för vi har tre stycken connectors och det är entity listener och det är för att vi ska få ett lagerföringsvärde på varje SKU-entitet. Så vi har produktentiteter, de har ett produkt-id, och vi har artikelentiteter som har ett artikel- id. Och så har vi SKU-entiteter som har ett SKU-id också. Men den här entity listener, den för över det här SKU-id så att samma nummer förs över till ett s-nummer. Så det id i PIM, det förs över fast med ett s framför för vårt lagerföringssystem.

L: Okej. Då är jag med.

I: Och vår translation connector är att vi ska kunna skicka iväg översättningsjobb från PIM direkt till vår översättningsfirma.

L: Okej, men de där två synkas inte automatiskt nu?

I: De här två synkas automatiskt. Sen är det att vi har problem med den sista här, web channel. Och nu har den faktiskt synkats här. Då är det någon som har satt