Guide til kravsspecificering af e-handelsløsning

Transkript

1 Udarbejdet af DI Handel i samarbejde med Netcompany Version: 1.0 Status: Endelig

2 FORORD Denne guide er udarbejdet i samarbejde med Netcompany med det formål at øge DI Handels medlemmers faglige kompetence i forbindelse med udvikling af webløsninger, der indvolverer flere parter. Guiden kan benyttes og være nyttig for alle direktøren, IT-direktøren, salgschefen og web/marketingafdelingen - og er især velegnet som bindeled mellem IT og den forretningsenhed, der ønsker løsningen. Det kræver tid og ressourcer at udarbejde en god kravspecifikation, men arbejdet betaler sig, da en velbeskrevet kravsspecifikation: - sikrer at I har afdækket og diskuteret behov og ønsker på tværs af organisationen inden projektet igangsættes - minimerer misforståelser mellem samarbejdspartnere og skaber konsensus om projektet - sikrer det bedste fundament for at udarbejde et realistisk budget på løsningen - er en forudsætning for at skabe en løsning, der fungerer fra dag 1. Vi anbefaler jer derfor at inddrage alle relevante interne parter og være så specifikke og deltaljerede som muligt, når I udarbejder kravsspecifikationen. Eventuelle områder i dokumentet, som I ikke føler jer gearede til at svare på, kan beskrives mundtligt over for potentielle leverandører, som generelt vil være behjælpelige med at guide jer igennem uklare punkter. Kravsspecifikationen kan tillige tjene det formål, at den tydeliggør, i hvilken grad en potentiel leverandør har viden om komplekse problemsstillinger og tager højde for disse i deres løsningsforslag. Har du spørgsmål til udarbejdelse af kravsspecifikationen er du velkommen til at kontakte Line Poulsen, Konsulent i DI Handel på lpou@di.dk / INDHOLDSFORTEGNELSE 1 KRAVSSPECIFIKATION TIL E-HANDELSLØSNING Målsætninger Målgrupper Konkurrenter Interessenter Økonomiske rammer Tidsmæssige rammer Funktionelle behov Visuelle behov Integrationsbehov Infrastruktur behov Operationelle behov Side 2 af 11

3 1 Kravsspecifikation til e-handelsløsning Formålet med dette dokument er at definere behovene for og kravene til en e-handelsløsning (en webshop,der giver jeres kunder og potentielle kunder mulighed for at få deltajeret viden om og købe forskellige produkter og services online 24/7) E-handelsløsningen skal indeholde forskellige elementer [Opsummer de elementer der umiddelbart skal indgå i løsningen,bl.a. produktkatalog, indkøbskurv, kortbetaling, udenlandsk valuta, min konto, tilbudsgivning, ordrebehandling, leveringstid, lagerstatus, leverandørsamarbejde, kampagnestyring, markedsføring, søgemaskineoptimering, osv. ] Den forretningsmæssige kontekst for e-handelsløsningen er [Beskriv de overordnede forretningsmæssige forhold, der omgiver e-handelsløsningen, bl.a. branche, selskabsform og struktur, markeder, geografiske forhold, relevante økonomiske nøgletal, osv. ] Dokumentet opstiller de informationer, der er nødvendige for at kunne starte udvikling af e-handelsløsningen. Dokumentet henvender sig til projektets forretningsmæssige styregruppe og sponsor, til IT-afdelingen samt til en eventuel leverandør/udviklingspartner. 1.1 Målsætninger Målsætningen er at udvikle en e-handelsløsning, som opfylder et eller flere forretningsbehov [Beskriv to til fem målsætninger for e-handelsløsningen, som forretningen ønsker at opnå. Dette vil være den rettesnor, som beslutninger omkring løsningen hægtes op på gennem projektet, og som sikrer, at projektet i sidste ende hjælper forretningen. Eksempler på typiske målsætninger: Skabe nye leads og kunder Forøge indtægter fra website Forøge antallet af kunder på website Forøge konverteringsraten på website Højne kendskabgrad /placering på søgemaskiner Reducere ordrebehandlingstider Reducere administrationsomkostninger Forbedre kundeservice Angiv specifikke målbare værdier (kombiner gerne med en tidshorisont) for hver målsætning, som kan bruges til at vurdere gevinsten ved at gennemføre projektet. ] Side 3 af 11

4 1.2 Målgrupper E-handelsløsningens primære målgrupper er [Beskriv de vigtigste målgrupper og kundesegmenter for e-handelsløsningen, dvs. hvem der allerede besøger websitet, og hvilke nye besøgende websitet skal tiltrække. I e-handel er det absolut største fokus besøgende kunder og genbesøgende kunder. Eksempler på typiske målgrupper/kundesegmenter (tilføj dine egne): Lokale kunder (eksempelvist kunder med tilknytning til en lokal butik) VIP kunder (eksempelvist kunder med en særlig prisaftale) Internationale kunder (eksempelvist kunder der ønsker eget sprog) Mobile kunder (kunder der ønsker at købe via smartphone eller tablet) Inspirationssøgere (typisk kunder der efterspørger storytelling og unika) Prissammenlignere (typisk kunder der efterspørger standardvarer) Hvad skal den enkelte målgruppe/segment have nem adgang til i løsningen? Målet for e-handel er typisk at opnå et salg, og derfor skal forsiden og den primære navigation næsten altid lede kunderne til relevante produkter, specielle tilbud eller services/rådgiving, der overbeviser kunden om, at I er den rette leverandør. ] 1.3 Konkurrenter E-handelsløsningens primære konkurrenter er [Beskriv de primære konkurrenter. Hvad er konkurrenternes fokus og planer? Hvem har den bedste konkurrerende e-handelsløsning og hvorfor? Hvem gør det mindre godt og hvorfor? Beskriv hvordan e-handelsløsningen skal hjælpe dig til at differentiere dig fra konkurrenterne, f.eks. igennem tilbud af bedre/mere synlige services, branding, markedsføring og/eller salgstrategi. ] 1.4 Interessenter E-handelsløsningens interessenter er [Det er et typisk problem i IT-projekter, at det ikke lykkes at involvere alle interessenter fra starten af projektet. Det gør det vanskeligt at udvikle en løsning, som stiller alle tilfreds, og som tager højde for alle faldgruber og behov. Prøv derfor at identificere og beskrive alle de vigtigste interessenter og stakeholders, og hvorfor/hvordan de kan bidrage. Eksempler på typiske interessenter: Markedsføringsafdelingen Indkøbsafdelingen Økonomiafdelingen Lagerpersonalet Side 4 af 11

5 Ordrebehandlingspersonalet Kundeserviceteams Website-teamet Ledelsen Husk, at når løsningen er søsat forekommer det ofte, at man taler om det som mangler, og ikke det som er opnået. Prøv at minimere denne risiko ved at tage alle interessenters behov i betragtning fra starten. Det er oftest ikke muligt at opfylde alle behov i den første version af løsningen, men der bør ligge en bevidst prioritering bag tilvalg og fravalg. ] 1.5 Økonomiske rammer De økonomiske rammer for etableringen af e-handelsløsningen er [Beskriv de økonomiske rammer for etablering af løsningen (projektbudgettet). Nogle organisationer ønsker ikke at dele deres interne projektbudgetter med leverandører, men dette er ofte uproduktivt. Kun hvis leverandøren kender både målsætningerne og budgettet er det muligt at udvikle et gennemarbejdet og realistisk tilbud på løsningen. Hvis budgettet er lavt, så informer leverandøren om det, så de kan vurdere, om det er realistisk at udvikle alle de identificerede behov, eller om det er nødvendigt med en forretningsmæssig prioritering. Vær realistisk, og hold for øje, at du med lave budgetter kan være nødsaget til at indgå kompromisser og lave skarpere prioriteringer af webløsningens funktioner. Overvej om en agil tilgang til udviklingen er mulig. I sådanne tilfælde udvikles løsningen under en fastlagt økonomisk ramme og et løsere defineret omfang, som hele tiden prioriteres i forhold til de forretningsmæssige behov og ideer, der opstår. Ofte giver dette et bedre slutresultet, da den læring, der opnås undervejs kan indbygges i løsningen. Når du vælger platform skal du have fokus på at vælge den platform, der er mest optimal for din virksomhed, dine kunder og det marked som I opererer i. Der findes mange gode it-platforme til at drive webshop fra og alle har fordele og ulemper. Prisrammen er også meget varieret, hvorfor der er vigtigt, at have specificeret og prioriteret sine behov inden i vælger platform, så I vælger den løsning der på kort og lang bane imødekommer jeres behov bedst. Der findes ikke en enkelt standardløsning, men en række forskellige løsninger, som kræver mere eller mindre programmering afhængigt at hviklen løsning du vælger og kompleksisten i din webshop. Som udgangspunkt vil opsætning af webshop dog kræve en vis mængde programmering (integration til dine IT- systemer og specifikke ønsker til funktioner, grafik mv). Derudover er der bl.a. udgifter til betalingsgateways, hosting samt eventuelt udvikling af kundespecifikke funktioner. Lidt om e-commerceplatforme: Open source er som udgangspunkt en gratis platform, der ikke betales licens for at anvende. Den er gratis at anvende fordi den udvikles af en række programmører rundt om i verden, der ikke tager sig betalt for det. Open source giver jeres programmører/itleverandør adgang til dele af den bagvedliggende kode, som gør ændringer meget fleksible. Udgiften går primært til programming af design, kundespecifikke funktioner, hosting og betalingsgateways. Ulempen er, at I med open source ikke har en virksomhed i ryggen som kan garantere, at platformen løbende vedligeholdes med nye funktioner og er kompatibel. Eksempler er bl.a. Magento og PrestaShop. En hosted webshop er en licensbaseret løsning med faste forudsigelige udgifter. Der står en e-commerceudbyder bag løsningen, som påtager sig ansvaret for at løsningen kører og løbende videreudvikles. Derved minimeres risikoen for kompatibilitetsproblemer. Såfremt der opstår problemer, kan man kontakte udbyderens supportafdeling. Omvendt har du ikke adgang til koderne bag ved din shop og har derfor ikke altid samme fleksibilitet i forhold til at få lavet ændringer og du kan være mere låst til din udbyder. Det er dog ofte muligt at få lavet ønskede ændringer, ligesom det ofte er muligt at tilkøbe ekstra moduler med flere funktioner enkelt og nemt. DanDomain, Hybris, Sitecore, EPiServer, Demandware, ucommerce, SUMOshop, inriver, m.fl. er eksempler på hosted platforme. Undersøg om der allerede findes licenser og/eller supportaftaler til én eller flere at disse standardplatforme, da det ville kunne være en budgetmæssig fordel at genbruge disse. Selvfølgelig under forudsætning af, at de kan opfylde forretningsbehovene. ] Side 5 af 11

6 1.6 Tidsmæssige rammer De tidsmæssige rammer for e-handelsløsningen er [Beskriv den forventede tidsmæssige ramme for etablering af løsningen (tidshorisont og deadlines). Dette er en nøgleafklaring i forhold til at strukturere projektet. Hvis en deadline er kort er det ofte muligt at etablere en mere simpel første version af e-handelsløsningen, som kan køre online, mens den fulde version bygges op. En typisk e-handelsløsning kan etableres på 3-6 måneder; selvfølgelig afhængig af de eksakte forretningsmæssige behov, integrationskompleksitet osv. ] Side 6 af 11

7 1.7 Funktionelle behov Dette afsnit beskriver, hvad der forventes af e-handelsløsningen. Følgende liste af funktioner og features beskriver hvad løsningen skal indeholde [Kortlæg de funktioner og features som løsningen skal indeholde. Følgende liste kan eventuelt bruges som inspiration (den er ikke udtømmende). Husk ligeledes at undersøge, hvordan jeres favoritwebshops er opbygget og hent inspiration i de funktioner, I oplever der: Indholdsredigering Redigering af produktvisning Redigering af kasseflow Oprettelse og redigering af menuer, sider, tekster og media Inspirationsblog/nyheder Behov for at tilrette og redigere information i produktoversigter og produktvisninger. Behov for at tilrette og redigere information og proces vedr. kasseflow. Behov for at oprette og tilrette menuer og sider, samt behov for at indholdsredigere statiske tekster, billeder og videomateriale. Behov for at kunne oprette artikler og nyheder til inspirationsblog eller nyhedsside. Produktkatalog Produkt Information Management (PIM) Behov for at styre og genbruge produktinformation, herunder markedsføringstekster, oversættelser, grafisk materiale, bl.a. ved at kunne trække disse fra eksisterende systemer Produktsortimenter Behov for at inddele produkterne i sortimenter til eksempelvist forskellige brands eller lande. Produktvarianter sortering/filtrering Behov for at understøtte produktvarianter, eksempelvist farvevarienter, eller materialevarianter og lade kunden sortere/filtrere via predefinerede parametre Relaterede produkter Lagerbeholdning Bestillingsvarer Udenlandske valutaer Flere sprog Flere butikker Behov for at vedligeholde information om relaterede produkter, eksempelvist produkter i en serie, så de vises automatisk Behov for at styre og vise lagerbeholdning. Behov for at udstille og sælge bestillingsvarer, der evt. kræver flere tilvalg/konfigurering Behov for at understøtte udenlandske valutaer. Behov for at understøtte sprogversionering og oversættes til flere sprog. Behov for at understøtte salg via flere butikker - både online butikker og fysiske butikker. Side 7 af 11

8 Styring af brands Uafhængige butikker og franchise Behov for individuel styring af flere brands i samme løsning - både virksomhedsbrands og produktbrands. Behov for at understøtte salg via uafhængige butikker og franchisetagere. Differentierede priser Behov for at understøtte differentierede priser, eksempelvist salg på specifikke prisaftaler med VIP-kunder og salg via rammeaftaler. Markedsføring Tidsstyrede kampagner Fri fragt Rabat: Stykpris Rabat: Ordresum Rabat: Køb 2 for 1 pris Rabat: Sætpris Rabat: Kampagnekode Rabat: Butiksspecifik Rabat: Kundespecifik Social: Kundeklub og Min Side Social: Produktanmeldelser Social: Produktbedømmelser SEO: Søgemaskinevenlighed Behov for at håndtere processer i relation til tidsstyrede kampagner, så de automatiseres Behov for at tilbyde fri fragt, eksempelvist på ordrer over et vist beløb. Behov for at tilbyde rabatter på stykpriser, dvs. enkeltstyksrabatter. Behov for at tilbyde rabatter på ordresum, eksempelvist ordrer over et vist beløb. Behov for at tilbyde Køb 2 for 1 s pris rabatter, dvs. rabatter på multiple køb inden for en produktkategori. Behov for at tilbyde sætpriser, dvs. rabatter på fastlagte sæt af produkter. Behov for at tilbyde rabatter på baggrund af kampagnekoder. Behov for at tilbyde butiksspecifikke rabatter, eksempelvist lokale kampagner Behov for at tilbyde kundespecifikke ad-hoc rabatter. Behov for at tilbyde kundeklub og klubindhold, herunder Min Side med indhold målrettet interesser. Behov for at tilbyde at kunder kan bidrage med egne produktanmeldelser. Behov for at tilbyde at kunder kan bidrage med egne produktbedømmelser, eksempelvist 1-5 stjerner. Behov for at arbejde med søgemaskineoptimering, eksempelvist søgemaskinevenlig URL er og nøgleord. Transaktioner Betaling med betalingskort Behov for at understøtte betaling med betalingskort. Side 8 af 11

9 Betaling med MobilePay o.lign. Abonnementsbetalinger Ordreflow Ordrehistorik Revision Behov for at understøtte betaling med MobilePay. Behov for at understøtte abonnementsbetalinger, eksempelvist løbende serviceabonnementer. Behov for at tilrette og styre ordreflow. Behov for at se og vise ordrehistorik. Behov for at se og vise revisionsspor. Sikkerhed Individuelle brugerrettigheder Rettighedsstyring: Butikker Rettighedsstyring: Sortimenter Rettighedsstyring: Priser Rettighedsstyring: Sprog Rettighedsstyring: Ordrer Behov for at styre brugeradgange og rettigheder til løsningen. Behov for at styre rettigheder i forhold til butikker. Behov for at styre rettigheder i forhold til sortimenter. Behov for at styre rettigheder i forhold til priser. Behov for at styre rettigheder i forhold til sprog og oversættelser. Behov for at styre rettigheder i forhold til ordrer og levering. Kundeservice Reklamationer Returvarer Behov for at understøtte arbejdsgange vedrørende reklamationer. Behov for at understøtte arbejdsgange vedrørende returvarer. Specielle indkøbsscenarier Skal shoppen håndtere særligt udfordrende indkøbsscenarier skal det beskrives i form af simple diagrammer eller user-stories. Det kan f.eks. være særlige bestillingsprocesser i forhold til underleverandører, eller særlige logistik-processer i forhold til fragt. 1.8 Visuelle behov Dette afsnit beskriver eventuelle visuelle behov til e-handelsløsningen [Udarbejd eventuelt grovskitser til strukturen på dit nye websitet, samt grovskitser eller simple wireframes, som viser hvordan løsningens vigtigste skærmbilleder kunne tage sig ud. Find gerne websites som stil- og udtryksmæssigt passer til din virksomhed og jeres brand, samt websites som du ikke kan lide. Dette er relevant input i forhold til designprocessen. Hvis der er særlige behov i forhold til look-and-feel kan dette med fordel beskrives. Dette kunne f.eks. være i forhold til look-andfeel på smartphones og tablets. ] Side 9 af 11

10 1.9 Integrationsbehov Dette afsnit beskriver e-handelsløsningens integrationsbehov i forhold til virksomhedens øvrige IT-systemer [En e-handelsløsning har typisk en række integrationer til systemer, der varetager lagerbeholdninger, ordrer, kunder, betalinger, og BI/analytics. Lav en liste over de eksisterende IT-systemer, som din webshop skal integreres med, og find desuden gerne links til snitfladerne (API erne) og integrationsvejledningerne for de samme systemer. Dette er helt centralt for at kunne lave et realistisk budget for realiseringen af e-handelsløsningen. Den bedste måde at sikre sig at I kommer hele vejen rundt er at beskrive de enkelte processer fra I modtager en ordre til den er helt færdigbehandlet i jeres økonomifunktion. Her er to eksempler på hvilke processer I skal overveje: Modtagelse og ekspedition af ordre Modtagels e af ordre Evt. ændringer til ordre Pakning af ordre Hæve penge Distributio n af ordre inkl. TT Afstemnin g med økonomi Kundeservice Returflow Returprocedurer for kunden Modtagels e af retur Check af varer Registrering til gensalg Tilbageførsel af beløb Afstemme med økonomi Info til kunden For hver proces bør I beskrive, hvem der skal udføre hvad, hvornår det skal udføres, og hvordan det skal udføres. Der findes standardmoduler, som stiller en integration til rådighed mellem e-handelsplatformene og eksempelvist ERP- eller CMSsystemer, så data kan flyttes mellem systemerne. Hvis du ønsker at anvende disse standardmoduler, bør du angive det, da det kan stille nogle krav til, hvordan information i både kilde- og modtagersystemet skal struktureres. Standardmodulerne er ofte licensbaserede, hvilket betyder, at de kan påvirke den økonomiske ramme for projektet. Hvis der ikke findes en snitflade (API) til et givent system, kan der som regel etableres en skræddersyet integration, evt. i form af delvist automatiske indlæsninger af filer. ] 1.10 Infrastruktur behov Dette afsnit beskriver de infrastrukturmæssige behov for e-handelsløsningen [Overvej og beskriv særlige behov i forhold til platforme, servere, netværk og drift. Tag gerne udgangspunkt i de tidligere beskrevede processer, men tilføj ligeledes processerne for marketing (produktbeskrivelse, billeder og pris), kundeservice, osv. Igen skal I for hver proces beskrive: hvem skal udføre opgaven, hvornår skal den udføres, og hvordan skal den udføres ] 1.11 Operationelle behov Dette afsnit beskriver de operationelle behov for e-handelsløsningen. De operationelle behov afdækkes ved at se på, hvilke arbejdsopgaver webshoppen har. Alt fra vareoprettelse, ordremodtagelse, pluk og pak af ordrerne til kundeservice skal beskrives. Arbejdsopgaverne skal konkretiseres og dette sker ved, at følgende fire spørgsmål besvares for hver arbejdsproces: 1. Hvad skal udføres? 2. Hvem skal udføre det? 3. Hvorledes skal det udføres? Side 10 af 11

11 4. Hvor ofte skal det udføres? Dette afsnit kan være overvældende, men kan strukteres ved at synliggøre de enkelte arbejdsprocesser. Herunder er et eksempel på arbejdsopgaver ved ordremodtagelse: Modtagelse og ekspedition af ordre Modtagels e af ordre Evt. ændringer til ordre Pakning af ordre Hæve penge Distributio n af ordre inkl. TT Afstemnin g med økonomi Kundeservice [Beskriv de interne behov relateret til brugervenlighed, compliance, sikkerhed og performance (dvs. indlæsningstider eller brugerbelastning). Beskriv også hvilke forretningsmæssige og tekniske KPI er i løsningen, der kunne være relevante at overvåge og måle på. ] Mere info eller spørgsmål kan rettes til konsulent Line Poulsen på lpou@di.dk eller Side 11 af 11