Gång på gång har jag sett hur e-handlare går in i ett projekt att byta plattform helt oförberedda på de mest grundläggande frågeställningarna, vilket leder till problem i uppstarten, genomförandet och slutresultatet i form av tid, kvalitet och kostnad. Jag tänkte här dela med mig av några tips (listan kan ju såklart göras oändlig…) efter många års erfarenhet av att genomföra plattformsbyten inom e-handel.

Jag tänkte försöka förklara vilka vanliga problem som uppstår och vad man bör tänka på för att undvika dem, eller åtminstone minimera de negativa effekterna.

Klichén är ju att ett projekt är lyckat om den som beställt projektet anser det är lyckat. Så tänker oftast både e-handlaren och leverantören av plattformen. Men de bästa projekten är de där båda kommer ut nöjda, och den riktiga stakeholdern - kunden - visar sin uppskattning genom köp och transaktioner.

1. Tillsätt en projektledare på beställarsidan

Ett problem som jag ofta ser, är att man som e-handlare inte är en särskilt van beställare. Hur ofta upphandlar man och implementerar man en ny plattform för e-handel egentligen? I genomsnitt var fjärde år kanske? Inte sällan sätter man den operativa e-handelschefen som projektledare från beställarsidan och ofta är denna personen vass på e-handel, men ganska sällan på att driva projekt. Dessutom har e-handelschefen ofta sitt vanliga jobb att utföra, lagerproblem ska hanteras, kampanjer ska lanseras, rapporter ska levereras, content ska produceras till produkttexter osv, osv.

Genom att tillsätta en erfaren projektledare med domänkunskap som har tid att jobba med projektet på beställarsidan kommer man spara tid och pengar. Men framförallt kan man bli tryggare i att slutresultatet faktiskt levererar på de mål man satt upp i form av omsättning och marginal i e-handeln. Hen kan koordinera interna medarbetare och externa leverantörer samt säkerställa att allt som bör ske faktiskt också sker. Det är en stor fördel om projektledaren dessutom faktiskt har erfarenhet av både e-handel och e-handelsprojekt sedan tidigare.

2. Ha din produktdata i gott skick

En sak jag ägnat mycket tid åt är att analysera förutsättningarna för att genomföra ett e-handelsprojekt på bästa sätt: Vad behöver finnas på plats? I vilken ordning ska man utföra olika aktiviteter för att jobba på ett optimalt sätt? Vad är orsakerna till att projekt får problem?

Ett sak jag noterat som är ett ständigt återkommande problem är att det är oordning i produktdata. Det kan vara att man inte har produktkategorierna rätt strukturerade, att man egentligen skulle behöva göra om produktmodellen, att man kanske inte ens har berikat sina produkter med bilder, texter och attribut som är nödvändiga för kundens konvertering. Om man inte har detta när man startar den tekniska implementationen av en ny e-handelsplattform så kan inte utvecklarna jobba effektivt och slutresultatet av projektet är höljt i dunkel fram till lansering.

Det är svårt att bygga en produktsida om man inte vet vad som ska visas på den, hur bilder ser ut, hur många bilder det är, hur långa är beskrivningarna osv osv. Det är som att koda i blindo. Och det blir sällan bra och leder till att allt tar längre tid samt många akuta hack i slutet när man väl får riktiga data. En lätt löjlig jämförelse: Att starta ett e-handelsprojekt utan bra produktdata är som att spela in en film med ett halvfärdigt manus. Det blir sällan bra.

3. Testa, testa, testa

Det låter ju som att slå in en öppen dörr att säga man ska testa sin e-handel under utvecklingen men det är ett enormt problem att man som beställare under projektets gång inte testar. Jag upplever att man ofta inte har tid (se punkt 1 ovan) och att man som beställare inte tycker att det är lönt att testa något som ännu inte är helt färdigt och produktionsfähigt (se punkt 2). Någon gång har jag också varit med om att man som beställare inte ens känner att man har ett ansvar för test - "vi betalar ju dyra pengar till leverantören för att de ska göra sitt jobb utan fel". Men att köpa och implementera en komplex e-handel är inte samma sak som att köpa ett färdig mjukvara från hyllan.

Det är mer regel än undantag att beställaren först två-tre veckor innan go live i ett stort plattformsprojekt börjar testa på riktigt. Det är en riktigt dålig tidpunkt att upptäcka grundläggande problem i t.ex. orderintegrationer, produktvisning, affärslogik, prisstruktur etc. Om man befinner sig ett par veckor före lansering måst fokus vara vara formell slutverifiering - utan några stora överraskningar.

Att testa är svårt. Men det blir lättare och enklare om man börjar tidigt. Eller sagt på ett annat sätt: Ju mer man ignorerar det desto dyrare och sämre kommer det bli i slutändan.

4. Red ut med leverantören hur go-live ska gå till

Leverantören vill sälja ett projekt och kan i de tidiga sälj- och projektfaserna vara lite rädd för att komplicera saker genom att prata om go-live och vad som händer efter go live. Många gånger har jag suttit och insett att samarbetet och avtalet tar slut i samma sekund som man går live på tisdag 08:00. Men vad händer på onsdagen sen då? Hur ska buggar hanteras? Och om man bestämmer att go-live ska vara en fasad utrullning över en månad på olika marknader, hur ska den kostnaden hanteras? Har vi garantitid i avtalet? Vad kan jag kräva av leverantören efter go-live om jag inte som beställare har testat och kvalitetssäkrat under projektets gång?

Man undviker mycket huvudvärk (och oändliga förhandlingsmöten med fingerpekande) om man har rett ut vad som gäller för detta innan man ens påbörjar projektet. Om båda parter dessutom har en pragmatisk och lösningsorienterad inställning om att lösa problem i partnerskap kommer resan bli så mycket enklare.

Last final words: Fastprisprojekt är en riktigt bra grund för riktigt mycket problem och irritation på båda sidor, hur smart det än låter på pappret.

5. Tänk igenom vad som faktiskt behöver migreras

Allt ska med! Eller? Nej, verkligen inte. Datamigrering är ofta mycket tidskrävande och komplext, dvs dyrt. Är det verkligen nödvändigt att ha med fem år gamla ordrar från en kund som sedan dess aldrig köpt något igen? Behöver vi få med den där kunden som loggade in en gång 2017 där det enda ni har är en hotmailadress, samtidigt som ni saknar ett GDPR-godkännande? Otaliga timmar har slösats bort på att föra över gammal meningslös data från gamla system.

Ställ er frågan: "Vad behöver migreras?" Ställ er inte frågan "Vad behöver inte migreras?" Data som man önskar migrera men inte behöver kunna uppdatera kan till exempel läggas i en read-only databas istället. Data och content är grunden i en effektiv e-handel, men skräpdata är meningslös och ofta direkt skadlig.

Summering

Ordning och reda är, och har alltid varit, grunden till ett lyckat projekt. Som beställare behöver du någon som hjälper er att strukturera projektet, som dessutom har tid och vet vad som behövs för en lyckad e-handel. Någon som säkerställer att allt som behövs finns i avtal med leverantörer, och som vet vad som är onödigt, alltför tidskrävande eller vad man kan strunta i den där MVP-lanseringen. Någon som säkerställer att ni verkligen utför de aktiviteter som verkligen behövs och som kan styra och guida er leverantör av teknikprojektet.

Dom kallar oss projektledare.