Utvikling av dagligvarenettsted med opsjon på forvaltningsavtale

Bilag 1: Kundens kravspesifikasjon – Utvikling av dagligvarenettsted med opsjon på forvaltningsavtale

Bilag 1: Kundens kravspesifikasjon

Utvikling av dagligvarenettsted med opsjon på forvaltningsavtale

Bilag 1: Kundens kravspesifikasjon – Utvikling av dagligvarenettsted med opsjon på forvaltningsavtale

Innhold

1 Innledning 4

1.1 Oppdragene 4

1.2 Bakgrunn 5

1.3 Visjon 5

1.4 Oppdragsgivers formål med avtalen 6

1.5 Hensikten med dokumentet 6

1.6 Oppbygging av dokumentet 6

1.7 Forkortelser og begreper 6

1.8 Beskrivelse av nåsituasjon 9

1.9 Overordnet behov 9

2 Utvikling av nettsted for dagligvaresammenlikning 9

2.1 Sammendrag 9

2.1.1 Universell utforming 10

2.1.2 Tilrettelegging for flere språkversjoner 10

2.1.3 Mobil og skrivebord 10

2.2 Databaser, oppdatering, applikasjoner 11

2.2.1 Varelisten 12

2.2.2 Pristabellen 13

2.2.3 Utsolgtprognose basert på uttrekk av bongdata 14

2.2.4 Merkeordningstabellen 14

2.2.5 Butikktabell 15

2.2.6 Oppskrifttabellen 15

2.2.7 Brukertabeller 16

2.2.8 «Big data»-tabeller 17

2.3 Applikasjoner 18

2.3.1 Applikasjon for angivelse av innholdspreferanser 18

2.3.2 Handlelappbyggeren 22

2.3.3 Preferansesnifferen 32

2.3.4 Oppskriftsvelgeren 33

2.3.5 Kartvelgeren 34

2.3.6 Forum 34

2.3.7 Brukerens «MinSide» 34

2.3.8 Lagring av data og produksjon av statistikk 35

Bilag 1: Kundens kravspesifikasjon – Utvikling av dagligvarenettsted med opsjon på forvaltningsavtale

2.4 Øvrige sider på dagligvarenettsted 35

2.4.1 Administrasjonssider 35

2.4.2 Ingen «portabel» versjon 36

2.5 Parallelle versjoner av hele nettstedet, eller av Preferansesnifferen 36

2.5.1 Layoutparametere for spisset versjon 36

2.6 Testmiljø 37

2.7 Utviklingsmiljø 37

3 Kapasitet 37

4 Prosjektmetodikk 38

5 Utviklingsperiode 38

6 Garantitid og forvaltning 38

7 Opsjon på forvaltning og videreutvikling 38

7.1 Forvaltning 39

7.1.1 Forvaltningsoppgaver 39

7.1.2 Forvaltningsrutiner 39

7.2 Videreutvikling 41

8 Konkurransekriterier – leverandørens besvarelse 41

8.1 Utdannelse 41

8.2 Erfaring 42

8.3 Pris 44

8.3.1 Fastpris for utviklingsoppdraget 44

8.3.2 Timepris for forvaltningsoppdraget (opsjon) 44

1 Innledning

Forbrukerrådet inviterer med dette til en konkurranse om å utvikle en ny sammenlikningstjeneste for dagligvarer.

Dagligvarebutikkene omsatte for over 160 milliarder kroner i 2014 1). Dagligvaremarkedet er vår viktigste forbruksarena. Våre valg i dagligvaremarkedet påvirker vår helse, vår mattilfredshet og vår økonomi. På leverandørsiden styrer valgene våre oppgang og nedgang for butikker og produsenter, dyreholdspraksis og miljøadferd.

På dette som på andre områder ønsker Forbrukerrådet å lage en tjeneste som bedrer Forbrukernes innsikt og forhandlingsposisjon. Vi ønsker at valgene skal påvirkes og endres som følge av tjenesten.

De fleste og viktigste valgene skjer i butikken, der forbrukeren vanligvis ankommer med en ufullstendig handleliste på en lapp eller i hodet. Vi ønsker å gripe inn i og gjøre prosessen mellom dette uklare behovet og valget av den konkrete vare mer rasjonelt.

Vi ønsker også å hjelpe dem som ønsker en dypere og mer omfattende planlegging av sitt dagligvareforbruk. Vi vil gjøre det enkelt å lage handlelister og dagligvarebudsjetter i henhold til den enkeltes preferanser.

Antakelig kan vårt mål for den nye tjenesten sees på som en reise hvor forbrukeren innledningsvis benytter noen nokså enkle og spontant benyttbare finesser, for derigjennom å kunne bli lokket videre mot en mer stringent og langvarig planlegging av innkjøpene.

1.1 Oppdragene

Dette dokumentet omhandler den rene utviklingen, samt etterfølgende forvaltning. Databasearkitektur/tegning av back-end vil være gjenstand for en separat konkurranse. Det samme vil design av brukergrensesnitt. Resultatet av disse to mindre konkurransene vil danne viktige rammer for utviklingsprosjektet.

Noen føringer ligger imidlertid fast allerede: Løsningen skal baseres på utbredte og velkjente Fri Programvare-løsninger (stikkordsmessig Linux – PostgreSQL – Java – WordPress). Fysisk vil den etableres i skyen (Forbrukerrådet vil selv være kontaktpunktet mot skyleverandør). Forbrukerrådet vil eie alle rettigheter til de utviklede løsninger og selv kunne lisensiere dem som Fri Programvare.

Løsningen vil skille seg fra dagens internettjenester i Forbrukerrådet bl.a. i kraft av sine store datamengder. Alle innholdsdata om alle dagligvarer skal ligge i Forbrukerrådets egne databaser. Alle priser og helst lagerprognose for alle varer i alle butikker skal også samles inn og vedlikeholdes mange ganger i døgnet (i hvert fall fra de større kjedene, som kan rapportere i sanntid).

Løsningen vil også kunne ta vare på data på vegne av brukeren, som vil kunne logge seg inn og få tilgang til dem.

Det vil være relativt enkelt å lokalisere varer i databasene. Det er mer krevende å lokalisere alternative varer. Det er også en utfordring å håndtere kampanjer av typen «tre for to».

Mest krevende er det imidlertid å lage morsomme, effektive og enkle grensesnitt mot forbrukerne.

Utviklingen skal starte i desember 2015. Tjenesten skal i henhold til den foreløpige tidsplanen lanseres

15. oktober 2016.

1.2 Bakgrunn

Forbrukerrådet etablerte i 2008 Xxxxxxxxxxxxxx.xx, med oversikt over prisene på lån og innskudd i alle norske banker. I 2010 ble tjenesten utvidet til også å omfatte pengeoverføringer til utlandet og i 2011 prisene for skadeforsikring. I 2013 lanserte Forbrukerrådet en sammenlikningstjeneste for tannlegetjenester, xxxxxxxxxxxxxxxxxx.xx. I 2015 lansertes xxxxxxxxx.xx, som sammenlikner strømprisavtaler fra alle norske tilbydere.

Matkjedeutvalget (NOU 2011:4) gikk inn for at det bør utvikles verktøy for å gjøre forbrukerne bedre i stand til å sjekke vareutvalg og kvalitet, og sammenlikne priser på dagligvarer. Barne-, likestillings- og inkluderingsdepartementet (BLD) ga Forbrukerrådet i oppdrag å utrede om og hvordan en slik tjeneste kunne etableres. Forbrukerrådets konklusjon var at matkjedeutvalgets ønske best lar seg realisere gjennom en internettbasert dagligvaresammenlikning. En slik tjeneste bør gi tilgang til alle relevante opplysninger om matvarene som tilbys i norske dagligvarebutikker i sanntid, herunder pris og innhold.

Stortinget ga i 2015 regjeringen i oppdrag å lage en slik internettjeneste og oppdraget er gitt videre til Forbrukerrådet.

1.3 Visjon

Etter lansering av vår nye sammenlikningstjeneste for dagligvarer, vil forbrukerne kunne sammenlikne innhold og pris for langt de fleste dagligvareprodukter i det norske markedet i sanntid. Brukeren vil kunne få oversikt over alternative varer eller alternative leverandører og kunne lage handlelister for daglig, ukentlig og månedlig handel. Xxxxxxxx skal kunne sette opp et dagligvarebudsjett og sjekke dette av mot de innkjøp han faktisk foretar.

Handlelistene skal kunne skrives ut eller tas frem på mobil, og man tenker seg også at de kan videreformidles til nettbutikker når brukeren ønsker dette.

Tjenesten skal være tilgjengelig på alle utbrede publiseringsflater, som desktop, nettbrett og mobil.

Tjenesten skal mer enn oppfylle statens krav til universell utforming, og skal kunne brukes av hele befolkningen.

De store matvarekjedene skal automatisk oppdatere tjenesten med priser og betingelser i sanntid. Mindre aktører skal kunne benytte en forenklet innrapporteringsmetode.

Tredjepart skal kunne bidra med menyer med ingredienslister i et format som gjør at tjenestens brukere skal kunne benytte dem.

Tjenesten vil drives sammen med Forbrukerrådets øvrige open source-løsninger som består av mest mulig standardiserte og velkjente komponenter et bredt it-miljø i Norge og utlandet har erfaring med.

Det skal være enkelt for brede utviklermiljøer å sette seg inn i våre løsninger og utvikle for vår plattform. Dette vil skape enda bedre konkurranse både om utvikling av våre tjenester og forvaltning av dem.

1.4 Oppdragsgivers formål med avtalen

Formålet er å få tegnet separate, fleksible og gunstige kontrakter med en leverandør om både utvikling og senere forvaltning. Det vil finnes mange alternativer til de komponenter, programmer og driftsmiljøer Forbrukerrådet har valgt, men innenfor rammen av dette anbudet ønsker vi ingen alternative tilbud der vi allerede har foretatt teknologivalg.

1.5 Hensikten med dokumentet

Hensikten med dette dokumentet er å beskrive de krav kunden stiller til løsningen, samt gi retningslinjer til leverandøren for hvordan disse kravene skal oppfylles. Dette dokumentet vil ved kontraktsinngåelse utgjøre Bilag 1 til kjøpsavtalen.

1.6 Oppbygging av dokumentet

Dokumentet er bygget opp slik:

Del 1: Innledning

Del 2: Utviklingsoppdraget

Del 7: Forvaltnings- og videreutviklingsavtalen

Del Feil! Fant ikke referansekilden.: Konkurransekritierier – leverandørens besvarelse

1.7 Forkortelser og begreper

Forkortelse/begrep	Forklaring
Aktører	Eksempelvis norske dagligvarekjeder, produsenter, grossister og distributører.
Amazon Web Services (AWS)	Forbrukerrådets applikasjoner, databaser, maler etc. skal lagres i «skyen». Leverandør er for tiden Amazon Web Services. Xxxxxxxxxxxxxx.xx, xxxxxxxxx.xx og xxxxxxxxxxxxxxxxxx.xx er allerede hos AWS. Forbrukerrådet holder selv i kontakten med skyleverandør.
Apache Tomcat	Web-server (fri programvare).
App	Dataprogram, her brukt om applikasjon for mobiltelefon, vanligvis skrevet i separate utgaver for begge de to vanligste plattformene Android og Apple OS.
CMS	Content Management System - se «Publiseringssystem».

Forkortelse/begrep	Forklaring
Dagligvarer	Alle varer som vanligvis selges i dagligvareforretninger, herunder mat, drikke, hygieneartikler og husholdningsartikler
Bootstrap	Design-rammeverk for nettsider. Mange nettsteder som endrer utseende avhengig av skjermstørrelsen bruker Bootstrap (fri programvare).
Database	En samling datatabeller
Datatabell	For eksempel en samling homogent definerte dataobjekter der hvert objekt beskriver en dagligvare
Ember.js	Javascriptbibliotek (fri programvare).
ENVA-varegrupper	Hvert produkt i EPD-basen er tilordnet en varekategori i form av et ENVA-nummer. ENVA-numrene korresponderer med UNSPSC-kodene, som er en FN-standard.
EPD-basen	Et register der produsenter og leverandører av varer, hovedsakelig til dagligvarehandelen, registrerer alle sine produkter.
EPD-nummer	Et unikt nummer for hvert produkt. Dette gjenfinnes i strekkoden på produktet.
Det Europeiske Økonomiske Samarbeidsområdet (EØS)	Norge omfattes av de fleste EU-regler gjennom EØS-samarbeidet. EØS består av den europeiske union, Island, Liechtenstein og Norge. En leverandør i et EØS-land har anledning til å delta i offentlige anbud i alle andre EØS-land på lik linje med oppdragslandets leverandører. Større anbud – som dette – må kunngjøres i den europeiske anbudsoversikten TED.
Forbrukerrådet	Kunden.
Fri programvare	Fri programvare er programvare der brukeren har lisensfestet rett til å endre og redistribuere programvaren. Tilsvarer i stor utstrekning det engelske begrepet «Open source», selv om de to ikke er fullstendig kongruente. Forbrukerrådets ikt-strategi innebærer at nettstedene i sin helhet skal bygge på Fri programvare.
Google Analytics	Google Analytics (forkortet GA) er en gratistjeneste fra søkemotorfirmaet Google som generer detaljert statistikk om besøkende til en nettside. Tjenesten er hovedsakelig rettet mot markedsførere, i motsetning til webmastere og teknologer som nettanalyse-industrien i utgangspunktet var rettet mot.
Innholdsfortegnelse	Informasjon på varen eller varens etikett. For dagligvarer reguleres utformingen og innholdet av innholdsfortegnelsene av lov.
Java	Programmeringsspråk.
Java Server Faces (JSF)	Egenutviklet løsning for datafanger.
Javascript	JavaScript er et programmeringsspråk som er mye brukt for å tilføre dynamiske elementer til nettsider. I slike tilfeller kjører Javascript lokalt i nettleseren og kan endre sidens utseende, gi hjelpemeldinger etc. uten løpende kommunikasjon med serveren.
jQuery	Et stort bibliotek av javascript-programmer. Brukes i nettsteders brukergrensesnitt, blant annet for å tilpasse utseendet og tilpasse dette til forskjellige skjermstørrelser (fri programvare).
Linux	Unix-liknende operativsystem-kjerne (fri programvare).
MySql	SQL-databasetjener (fri programvare). Publiseringssystemet WordPress, som benyttes av Forbrukerrådet, lagrer data i MySql.
Open Source	Et dataprogram der kildekoden er tilgjengelig og vanligvis kan endres og manipuleres uhindret av opphavsrett. På norsk brukes begrepet «Fri programvare», selv om de to begrepene ikke er helt sammenfallende.

Forkortelse/begrep	Forklaring
	Forbrukerrådets ikt-strategi innebærer at nettstedene i sin helhet skal bygge på Fri programvare.
PostgreSql	SQL-databasetjener (fri programvare).
Publiseringssystem	Program der journalister skriver artikler og der redaktører setter opp sider. Publiseringssystemet er et vindu mot bakenforliggende databaser for bl.a. artikler, bilder, videoer, tabeller. Publiseringsmaler, publiseringsrutiner, designmaler o.s.v vil også være en del av publiseringssystemet. Forbrukerrådet benytter publiseringssystemet WordPress.
«Skyen»	Nettskyen (eng: cloud computing) er en betegnelse for alt fra dataprosessering og datalagring til programvare på servere som står i eksterne serverparker tilknyttet internett. Serverparkene i nettskyen kjennetegnes ved at de er laget for dynamisk skalering ved kapasitetsbehov, og ved at det som regel betales for faktisk bruk. Amazon, Google og Microsoft tilbyr for eksempel serverkapasitet i nettskyen på timesbasis. Forbrukerrådet kjøper ren maskinkapasitet i skyen. Vår forvalter må ha kompetanse til å laste programmer opp til vårt område i skyen og vedlikeholde dem der, men forbrukerrådet ønsker å gjøre avtaler med skyleverandører direkte.
SOAP	SOAP er et rammeverk for meldingsutveksling mellom maskiner, utarbeidet under World Wide Web Consortium. Finansportalens forsikringsløsninger samtaler i sanntid med forsikringsselskapene ved SOAP-konforme meldinger: xxxx://xxx.x0.xxx/XX/xxxx/
Strekkode	Kode på dagligvare som korresponderer med en innholdsfortegnelse og en pris
Spring framework	I stedet for å programmere alt fra bunnen av, kan man benytte biblioteker av ferdige funksjoner, der det måtte passe. Spring er et av mange java-biblioteker. Fri programvare.
Tomcat	Tomcat, tidligere under The Apache Jakarta Project, er en vev container utviklet av Apache Software Foundation. Tomcat implementerer Java Servlet- og Java Server Pages-teknologiene fra Sun Microsystems, som da gir et miljø for å kjøre Java kode i samarbeid med en vevtjener. Den har også verktøy for konfigurasjon og administrasjon, men kan også bli konfigurert ved å editere konfigurasjonsfiler som normalt er skrevet i XML. Siden Tomcat har en HHTP tjener integrert, blir den også betraktet som en enestående vevtjener.
Tradesolution	Et norsk selskap som registrerer vareinnhold og butikker og tildeler varer unike varenumre (som korresponderer med strekkoden på varen og/eller forpakningen).
UNSPSC-koder	«The United Nations Standard Products and Service Codes» er en nomenklatur for produkter og tjenester for bruk I e-handel. Det utgjør et fireetasjes hierarki med mulighet for å legge til en femte ved å bruke to ekstra tall. ENVA-numrene, som tilordnes norske dagligvarer, korresponderer med UNSPSC-kategoriene.
WAI	Web Accessibility Initiative, en av undergruppene til W3C. Denne standarden for universell utforming, som skal gjøre nettstedene tilgjengelige også for folk med nedsatt funksjonsevne, omtales ofte som ”WAI-kravene”.
WCAG	WCAG (Web Content Accessibility Guidelines) er en standard utviklet av WAI (Web Accessibility Initiative) en av undergruppene til W3C. Standarden, som skal gjøre nettstedene tilgjengelige også for folk med nedsatt funksjonsevne, omtales ofte som ”WAI-kravene”. Forbrukerrådet skal minst oppfylle kravene til WCAG 2.
Web Services	Web services er meldingsutveksling mellom maskiner ved et på forhånd avtalt meldingsformat. Finansportalens forsikringskalkuatorer benytter Web Services, der brukerdata sendes til selskapene for premieberegning i sanntid. Finansportalens web services bygger på standarden SOAP.
WordPress	Verdens mest utbredte publiseringssystem for nettsteder, lisensiert som Fri programvare.

Forkortelse/begrep	Forklaring
Youtrack	Xxxxxxxxxxxxxx.xx, xxxxxxxxx.xx og xxxxxxxxxxxxxxxxxx.xx kommuniserer med forvaltningsselskapet gjennom feilmeldingssystemet Youtrack. Youtrack brukes også til utviklingsoppgaver og til driftsoppgaver som starter med en henvendelse fra en dataleverandør. Youtrack har mange fellestrekk med Jira og Bugzilla.

1.8 Beskrivelse av nåsituasjon

Det er knapt 4.000 dagligvarebutikker i Norge. Til sammen fører de til enhver tid rundt 30.000 forskjellige varer. De tre store dagligvarekjedene Coop, Rema og Norgesgruppen står for praktisk talt hele omsetningen på rundt 160 milliarder kroner.

Hver dag er det tusenvis av prisendringer, og til tross for reklame som fremhever tilbud på enkeltvarer, vil ikke kundene vite hvilke priser som gjelder for det store flertall av varene før de kommer i butikken.

Det finnes i dag bare begrensede sammenlikningstjenester for dagligvarer på internett i Norge. Det finnes enkelte nettbutikker, men disse opererer med én pris – sin egen – for hver vare. Noen dagsaviser gjennomfører fra tid til annen prissammenlikninger, men ingen permanent over tid.

I andre land finnes det tjenester som har fellestrekk med den Forbrukerrådet skal etablere. Xxxxxxxxxxxxx.xx.xx inneholder varer og priser fra de største kjedene i Storbritannia. Men Xxxxxxxxxxxxx.xx.xx er innrettet mot netthandel av dagligvarer, som blir en sekundær funksjon i den nye norske tjenesten. Xxxxxxxxxxxxx.xx.xx holder heller ikke oversikt over sortimentet i den enkelte butikk.

1.9 Overordnet behov

En sammenlikningstjeneste for dagligvarer skal gjøre det mulig for forbrukere å velge de varer som best samsvarer med vedkommendes behov.

Et sentralt behov er behovet for å spare penger. Men via tjenesten vil man også kunne orientere seg om innholdet i varene. Forbrukeren vil kunne sortere ut varer som har innholdsemner han vil unngå. Han vil for eksempel kunne velge varer med lavere saltinnhold eller lavere energiinnhold. Forbrukeren vil kunne velge varer han mener bedre setter ham i stand til å nå helsemål. Han vil kunne velge varer som er tilknyttet visse merkeordninger, som også angir kvalitetsparametere som miljøbelastning, produksjonsforhold og produksjonsmåte. Forbrukeren vil kunne få idéer til et mer variert kosthold.

2 Utvikling av nettsted for dagligvaresammenlikning

2.1 Sammendrag

Forbrukerrådet avholder en anbudskonkurranse om et utviklingsoppdrag med en tilhørende opsjon på å tegne en avtale om forvaltning og videreutvikling.

Utviklingsoppdraget går ut på å utvikle et nytt nettsted for sammenlikning av dagligvarer. Dette nettstedet skal etableres på Forbrukerrådets valgte infrastruktur (i stikkordsform Linux – Postgresql – Apache – WordPress – Amazon Web Services).

Et antall relativt store datatabeller skal opprettes. Rutiner for automatisk oppdatering av disse mot dataleverandørene skal etableres.

Internettapplikasjoner for lesing av strekkode i butikk (fra mobiltelefon), presentasjon av innhold, presentasjon av alternative varer og bygging av handlelister skal lages. Brukeren skal kunne angi generelle preferanser, som vil benyttes ved presentasjon av alternative varer. Brukeren skal kunne lage et dagligvarebudsjett og et dagligvareregnskap og lagre disse i en egen konto. Xxxxxxxx skal kunne bygge handlelister med utgangspunkt i oppskrifter.

I utgangspunktet vil ingen preferanser være satt, men det skal være mulig for redaksjonen å sette slike ved parametere. Det samme gjelder til en viss grad utseendet (grafikk, bakgrunnsfarger, fonter og fontstørrelser), slik at det i praksis kan publiseres «spissede» versjoner, for eksempel til brukergrupper som måtte være særlig opptatte av økologisk mat.

Alle innsamlede data vil tas vare på i minst ett år, og kunne danne grunnlag for statistikk. Noe statistikk vil automatiseres og presenteres på nettstedet.

Tjenesten vil også – med brukernes samtykke – ta vare på brukerdata med sikte på metadataanalyser som også planlegges publisert på nettstedet.

2.1.1 Universell utforming

Forbrukerrådet følger gjeldende standarder (WCAG) for utvikling av websider og betydelig arbeid er lagt ned i å gjøre sidene tilgjengelige for alle typer brukere. Dagligvaresammenlikningen skal oppfylle mer enn minstekravene i WCAG 2.0.:

xxxx://xx.xxxx.xx/xxxxxxxxxx/xxxxxxxxx/xxxx-xxx-xxxxxxxxxxxxx/xxxx-xxxx

Dette vil i stor grad styres av designet som Forbrukerrådet for dagligvaretjenestens vedkommende utvikler parallelt og vil levere ved begynnelsen av prosjektet.

2.1.2 Tilrettelegging for flere språkversjoner

Ved lanseringen vil den nye dagligvaretjenesten foreligge på bokmål, engelsk og nynorsk. Det skal være mulig for redaksjonen å legge til nye språkversjoner med minimal involvering av teknisk personale.

2.1.3 Mobil og skrivebord

Alle sider ved tjenesten bortsett fra de som krever skanner skal være tilgjengelig fra både mobiltelefon, nettbrett og vanlig datamaskin. Design leveres parallelt med at anbudet løper, men

antakelig vil utseendet avvike mer enn vanlig mellom de forskjellige plattformene, da mobilversjonen i stor grad er beregnet på å bli brukt inne i en butikk og vil ha en skannefunksjon.

2.2 Databaser, oppdatering, applikasjoner

Under gis en foreløpig gjennomgang av tjenestens «backend». Den kan betraktes som en huskeliste, da arkitekturen ikke er detaljplanlagt ennå. En mer detaljert arkitektur vil foreligge ved utviklingsstart, da dette er et separat eksternt oppdrag som vil være ferdigstilt da.

Den mest sentrale datatabellen vil være den som inneholder beskrivelser av alle varer som finnes i norske dagligvarebutikker. Denne tabellen vil være bygd opp på samme måte som dagens tilsvarende liste utarbeidet av selskapet Tradesolution. En liknende liste vedlikeholdes også av selskapet Millum.

En varedatabase med innhold, beskrivelse og bilde av de 30.000 – 50.000 varer som finnes i dagligvarehandelen vil sannsynligvis bli etablert ved import av data fra disse eksisterende varedatabasene.

Det skjer daglige endringer i varedatabasen, både i form av rettelser, ved at det kommer til nye produkter og ved at produkter tas ut av handelen. Det må derfor opprettes automatiske oppdateringsrutiner.

(Det aller meste av vareinformasjonen, finnes hos noen få datakilder. Men det skal kunne knyttes til også andre datastrømmer, som vil kunne assistere forbrukere som ønsker vurdering av enkeltvarer også fra tredjepart).

I neste omgang vil det bli importert priser fra kjedene. Det må først etableres et «startbilde», som viser sortimentet og utgangsprisene for alle varer i alle butikker. Mens hver kjede i sine forskjellige butikker vanligvis opererer med 3-5 ulike priser for hver vare, er ikke dette noen robust begrensning og løsningen må kunne takle at samme vare har ulik pris i alle de knapt 4.000 butikkene.

Det tas sikte på å oppdatere prisdatatabellen samtidig som prisendringene skjer i butikkene. Dette vil antakelig skje ved en «push-tjeneste» hvor vi via web services mottar en kopi av meldingene som går til butikksystemene og der fører til endring av hyllekantprisene og prisene i kassaapparatene.

Forbrukerrådets tjeneste vil løpende beregne sannsynligheten for at en vare er utsolgt, på bakgrunn av utdrag av bongdata (priser og varer som registreres i kassaapparatene) som mottas fra kjedene.

Ved hjelp av applikasjoner skal brukerne kunne sette opp handlelister. Handlelistene kan skrives ut eller hentes opp på mobiltelefon i butikken. Handlelistene vil også kunne sendes til nettbutikker.

Det vil også være mulig å lage handlelister med utgangspunkt i menyer/oppskrifter. Forbrukerrådet vil ikke lage menyer. Slike skal kunne importeres fra tredjepart.

Handlelistene skal kunne danne utgangspunktet for et dagligvarebudsjett. Budsjettene skal kunne utgjøre et dagligvareregnskap, i den grad brukeren merker av hvilke varer han faktisk kjøper.

Brukerne skal via Forbrukerrådets tjeneste kunne abonnere på bongdata. Bongdata er ganske enkelt kassalappen i elektronisk form. Medlemmer av Trumf-fordelsklubben og Coop kan i dag se sluttsummen på hvert av sine kjøp på tjenestenes «MinSide». Bunnpriskunder kan se også enkeltvarene på kassalappen om de importerer den til sin Digipost-postkasse.

Forbrukerrådets tjeneste vil i utgangspunktet ønske den fulle kassalappen, som kan importeres til vår

«MinSide» i den utstrekning brukeren ønsker det og kjedene gir tilgang.

2.2.1 Varelisten

Tabellen skal minst inneholde den lovbestemte informasjonen. For matvarer er dette

• Ingredienslisten (Ett tekstfelt)

• Allergénlisten (14 boolske felt)

• Næringsdeklarasjonen (7 flyttallfelt)

• Merketilknytning («Nyt Norge», «Debio» etc, rundt 100 boolske felt)

• Bilder av varen

• Strekkodenummer (varens id i systemet)

• Kategorinummer

• Dato for innføring i databasen

Forbrukerrådet ønsker en fleksibel relasjonsdatabase som støtter opprettelse av nye tjenester siden. Hvorvidt det vil måtte opprettes gjensidige «pekere» til butikker i butikktabellen som har varen i sitt sortiment, eller om det holder med pekere motsatt vei, er et designspørsmål det vil bli tatt stilling til underveis.

Det er rundt 30.000 forskjellige varer til salgs i de store dagligvarekjedene. Men varetabellen vil kunne måtte inneholde langt flere varer, da vi ikke ønsker noen «overraskelser» i form av at det dukker opp prisendringer tilknyttet strekkoder vi ikke har.

Det kommer hvert år et høyt antall nye varer og et tilsvarende høyt antall forsvinner ut av sortimentene, uten at varen nødvendigvis rapporteres som uaktuell. Antakelig må vi utvikle rutiner som automatisk anslår sannsynligheten for at varen er ute av sortimentet når det har gått en viss tid uten at det blir rapportert ny pris.

I utgangspunktet skal hele varetabellen ligge på Forbrukerrådets servere (eller mer presist: den serverkapasiteten vi leier i «skyen»). Importen av initielle data vil kunne skje fra databaser som ikke er umiddelbart kompatible med postgreSQL, som foretrekkes i dette prosjektet.

2.2.1.1 Automatisk oppdatering av varetabellen

Leverandører og produsenter oppdaterer listene til Tradesolution og Millum. Det gjøres daglig mindre endringer. Større endringer finner sted fire ganger i året, da det er tradisjon for at mange nye varer «slippes» på samme dato.

Det må oppdateres rutiner for automatisk oppdatering. I dette arbeidet vil vi antakelig tilpasse oss dataleverandørenes standarder og formater, men vi ser for oss web services med xml-meldinger.

2.2.1.2 Manuell innføring i varetabellen

Det skal være mulig å registrere varer manuelt. Her tenker man særlig på gårdsutsalg og hjemmeprodusenter hvis varer ikke finne i Tradesolution eller hos Millum.

For dette formål må produsenten ha en brukerkonto som «butikk» der han kan legge inn varene. Det må også her være felter for lovbestemt vareinformasjon.

Det må være manuell kontroll av varene: For hver manuelt innrapportert vare går en mail til

«moderator» med et sammendrag av opplysningene. I mailen vil det være en «Godkjenn»-lenke og en «Be om flere opplysninger»-lenke.

I Tradesolution leveres den fysiske varen inn til måling og fotografering. Det vil ikke Forbrukerrådet ha kapasitet til.

2.2.2 Pristabellen

Antakelig behøves ingen egen pristabell. Prisene vil enten være en relasjon i butikktabellen eller en del av varetabellen.

Det er vanligvis 4-5 priser per vare per kjede. Men det kan være forskjellig pris for én og samme vare i de nesten 4.000 dagligvarebutikkene, og dette må løsningen ta høyde for.

Det kan også være flere priser for samme vare i samme butikk, om den inngår f.eks. i en «3 for 2»- kampanje eller selges med en annen pris til medlemmer av fordelsklubber e.l.

2.2.2.1 Automatisk oppdatering av priser

Det forventes flere tusen prisendringer hver dag. Disse skal speiles i vår tjeneste samtidig som prisene endres i butikkene. Det vil hovedsakelig være de tre store kjedene som rapporterer prisendringer. Vi vil tilpasse oss deres formater og teknologi, som vil være en form for web services – maskin til maskin-kommunikasjon via internett.

De fleste prisendringer bestemmes sentralt. I de fleste kjeder går det ingen datastrøm tilbake til kjedene fra butikkene, med unntak av det man kan slutte seg til ved kassadata/bongdata.

Forbrukerrådet kan bare benytte data som finnes. Det vil si meldingene sentralt fra kjedene ned til butikkene.

Prisendringsmeldingene er ikke ferdig definert, men de vil antakelig minst inneholde:

• Varenummer

• Starttid

• Sluttid (aktuelt for kampanjer)

• Hvilken kategori butikker eller hvilke enkeltbutikker endringen gjelder for

• Medlemsrabatter

• Kampanje (3 for 2 e.l.)

Prisendringsmeldingen vil også kunne ha et felt som viser tilgjengelighet, der kjeden kunne melde at varen gikk ut av sortimentet. (Dette er strengt tatt ingen prisendring, men det kunne være praktisk å bruke samme melding).

2.2.2.2 Oppdatering av priser for andre enn de store kjedene.

I tillegg til å tilpasse oss de store kjedenes meldingsformater, vil vi også publisere et eget format (antakelig basert på kjedenes) for at mindre aktører skal kunne rapportere til oss om de ønsker det eller blir pålagt det.

Dette vil være samme type maskin-til-maskin kommunikasjon som med kjedene, og den skal kunne gå som en «push»-tjeneste fra prisleverandøren, slik det skjer for de store aktørene.

2.2.2.3 Manuell oppdatering av priser

De aller minste aktørene vil få tilbud om manuell oppdatering av prisene. Dette vil være et enkelt, men omfattende skjema der alle varer i databasen er tilgjengelige på en linje, og aktøren kan endre prisen for sin egen butikk manuelt.

Muligvis bør det være en identifiseringsfunksjon her også, som ligner den brukerne står overfor når de skal lage handlelapp, hvor den lille, manuelle aktøren kan fylle en handlekurv med de varene han fører og deretter manuelt gi dem pris (heller enn å gjøre dette direkte i det svært store skjemaet som omfatter alle varer).

2.2.3 Utsolgtprognose basert på uttrekk av bongdata

Kjedene har generelt ikke oversikt over lagerstatus i sine butikker. De vet ikke hvorvidt en vare står i hyllen, eller om den er utsolgt. Dette kan imidlertid anslås om vi vet hvor lenge siden varen ble slått inn i kassen. Om en vanligvis hyppig solgt vare ikke er registrert på 20-30 minutter, er det et tegn på at den kan være utsolgt.

Vi har bedt kjedene om hyppig (kanskje hvert 10. minutt) å oversende en oversikt over når et varenummer sist ble registrert i kassen i hver av kjedens butikker.

Vi vil spare på disse rapportene et par dager – lenge nok til å kunne beregne vanlig omsetningsfrekvens for hver vare, og dermed hvor lenge det bør gå uten at den er omsatt før vi mistenker at det er tomt.

I datamengde vil dette utgjøre kanskje den største tabellen i løsningen. Data vil imidlertid være relativt «flate» og operasjonene som skal gjøres på dem enkle.

2.2.4 Merkeordningstabellen

Det er en rekke merkeordninger («Nyt Norge», «Debio») for dagligvarer. Merketabellen vil til en viss grad bestå i et utdrag fra varetabellen, der de fleste merkeordninger er avmerket som en egenskap ved hver vare.

Men det vil kunne være rasjonelt å ha en egen tabell, i tilfelle brukere ønsker en oversikt over varer som er omfattet av merkeordningen.

Det forefinnes også vanligvis en bredere informasjon om merkeordningen som ikke er trykket på varene. Den bør også være tilgjengelig.

2.2.4.1 Oppdatering av merkeordningstabellen

Merketabellen vil oppdateres mot varetabellen for eksempel én gang i døgnet.

Merkeordninger som ikke inngår i standard vareopplysning, skal kunne publisere en xml-feed vi definerer formatet for og skal kunne importere. Xxxxxxxx skal så kunne se merket på de respektive varene om han ønsker det.

2.2.5 Butikktabell

Det er knapt 4.000 dagligvarebutikker i Norge, de aller fleste av dem medlemmer i en av de tre dagligvarekjedene Norgesgruppen, Rema og Coop. Alle butikker skal ligge i en egen tabell som inneholder navn, adresse, geografiske koordinater, kjedetilknytning og – om eierne ønsker å legge det inn – en kort tekstbeskrivelse.

Forbrukerrådet antar at man i utgangspunktet kan importere en ferdig tabell med disse dataene, men butikker må også kunne legges inn manuelt.

Det skal også finnes en kobling mellom denne tabellen og varetabellen for så vidt gjelder butikkens sortiment. Når det kommer en endringsmelding for en pris i en butikk, vet vi at varen finnes i sortimentet. Men vi behøver også et startbilde, vi må i utgangspunktet kjenne sortimentet.

Data om butikkene kan antakelig lastes ned fra én sentral base.

Vi regner med å kunne importere sortimentet elektronisk fra kjedene.

Generelt finnes det ikke tilgjengelig lagerstatus, men vi vil opprette en algoritme for sannsynligheten for at varen finnes i butikken.

2.2.5.1 Automatisk oppdatering av butikktabellen

Det må oppdateres rutiner for automatisk oppdatering. I dette arbeidet vil vi antakelig tilpasse oss dataleverandørene. Det kan også være uavhengige butikker som kan måtte innrapporteres manuelt av eierne via innlogging og et grensesnitt for rapportering.

2.2.6 Oppskrifttabellen

Dagligvaretjenesten vil publisere en standard (sannsynligvis et xml-format) for hvordan man kan melde inn oppskrifter til tjenesten.

Disse oppskriftene skal (minst) inneholde en ingrediensliste for 1, 2 og 4 personer. De bør også inneholde minst ett bilde.

Ingredienslisten vil i utgangspunktet ikke være knyttet til konkrete varer. Det må lages en automatisk tilknytning, der en applikasjon hver natt går gjennom oppskriftene og varetabellen og søker i ingredienslisten etter passende varer som kan matches med oppskriftene.

2.2.7 Brukertabeller

Det skal være mulig å bruke tjenesten uten å være logget inn, men vil man ta vare på data til neste gang, må man vanligvis være innlogget.

Det vil være et sett brukertabeller for hver registrert bruker. Det er uvisst hvor mange brukere man vil kunne få, men til å begynne med bør vi ta høyde for 50.000 registrerte brukere.

2.2.7.1 Handlelistetabellen

Hver bruker vil ha hver sin handlelistetabell. Fra handlelistetabellen vil brukeren kunne hente frem tidligere handlelister. I utgangspunktet bør dette være en relasjonstabell, der alle tidligere handlelister ligger i én tabell. Kjøpte man 2 liter melk mandag og 3 liter torsdag, kan tid, pris og butikk være en relasjon til varen, identifisert ved varenummeret.

2.2.7.2 Preferansetabellen

Ved en dertil egnet, enkel applikasjon kan forbrukeren angi sine preferanser overfor ingredienser, allergéner og næringsinnhold. Preferansene lagres i en preferansetabell for hver bruker.

2.2.7.3 Favorittabellen

Brukeren skal kunne merke av favoritter i varelisten. Hvilke dette er, må løsningen huske, slik at disse kan foreslås som alternativvarer neste gang brukeren skal lage en handleliste.

2.2.7.4 Byttetabellen

På bakgrunn av brukerens angitte preferanser, vil det kunne presenteres alternativer til varen brukeren initielt valgte. Hver gang han bytter, skal dette registreres. Det skal registreres tid, pris, varenummer han byttet fra og varenummer han byttet til.

Denne byttetabellen kan benyttes til siden å presentere brukeren for relevante alternativer. Man kan også tenke seg at den også kan brukes til å presentere relevante alternativer for andre brukere, ved en «de som har et liknende handlemønster som deg, velger ofte også..»-analyse.

2.2.7.5 Kassabongtabellen

Det skal være mulig for brukere å importere kvitteringer/kassabonger direkte fra tilknyttede butikker. Disse vil bli en kortversjon av varetabellen, med dato, pris og butikk for hver vare du har kjøpt. Denne tabellen vil både kunne danne utgangspunkt for et dagligvareregnskap og kanskje påminnelser om at husholdningen kanskje er i ferd med å gå tom for artikler som ikke har dukket opp på handlelisten på en stund.

Kassabongdata skal også kunne ajourføres mot handlelister, slik at brukeren skal kunne se om det gjenstår varer han hadde planlagt å handle, men ikke kjøpte (fordi han glemte det, butikken var utsolgt e.l.)

Det er ingen gitt å vite hvor mange brukere som vil legge sine dagligvareregnskap til Forbrukerrådets internettløsning. Men det er to millioner trumf-medlemmer. Det er 1,4 millioner Coop-medlemmer. En halv million har Digipost-postkasse.

Forbrukerrådet tror tjenesten bør skaleres for 50.000 aktive MinSide-brukere det første året, men om tjenesten skulle ta av, kan den fort bli langt større.

2.2.7.5.1 Oppdatering av kassabongtabellen

Det finnes i dag «MinSide»-funksjoner i både rabattsystemet Trumf og i Coop. I disse systemene gjenfinner man alle sine kjøp i medlemsbutikkene i en «MinSide»-funksjon. Men bare sluttsummen ved hver betaling vises. I Bunnpris-kjeden kan man i stedet motta kassalappen elektronisk i sin «Digipost»-postkasse. Her vises hele kassalappen, alle varer med pris for hver.

En «MinSide»-funksjon bør ha en kassalappfunksjon lik den Bunnpriskunder har i Digipost. Kassalapper må mottas elektronisk og dataleserbare og ajourføres mot dagligvarebudsjett og dagligvareregnskap for hver bruker.

2.2.8 «Big data»-tabeller

Både butikker og den alminnelige offentlighet vil være interessert i aggregerte adferdsdata fra løsningen. (Det vil likevel være i tråd med Forbrukerrådets personvernpolicy at den enkelte bruker uttrykkelig gir tillatelse til slik bruk).

Hvor mye billigere må handlekurven bli for at gjennomsnittsbrukeren bytter butikk? Hvor går smertegrensen for prisen for hjemkjøring av varer?

Hvilke varer anser den jevne konsument som alternativer til hverandre? Hva gjør brukeren når varen er utsolgt?

Xxxxxxx forbrukeren faktisk det han planlegger å handle? Hvilke innholdskomponenter er forbrukerne mest skeptiske til?

Dette kan være spørsmål man vil kunne få svar på ved å analysere metadata fra tjenesten.

Disse relasjonene må beregnes av dertil egnede applikasjoner og løpende lagres i tabeller.

2.3 Applikasjoner

Med det dataomfang og den datakvalitet som planlegges, kan det bygges en lang rekke applikasjoner. De vil henvende seg til forskjellige brukssituasjoner og kanskje forskjellige kunder. Forbrukerrådet vil prioritere tjenester som er enkle, raske og intuitive å bruke. Det er et mål å hjelpe mange litt heller enn å hjelpe få mye (men helst begge deler).

2.3.1 Applikasjon for angivelse av innholdspreferanser

Den obligatoriske merkingen av matvarer gjør det mulig for brukerne å filtrere ut visse innholdskomponenter. Andre kan man angi at man ønsker mindre av.

Databasen vil inneholde alle matvarenes ingredienser, men ikke hvor mye av hver av dem som er brukt. Alle matvarer har også en deklarasjon av næringsinnhold, hvor en del emner og egenskaper angis ved vekt. Opprinnelsesland er kjent. Det samme er hvorvidt varen inneholder en eller flere av 13/14 allergener. Det vil også være mulig å hente opp informasjon om hvilke merker («Godt Norsk»,

«Økologisk», «Svanemerket» etc. varen måtte være tildelt).

I et særskilt grensesnitt vil brukeren kunne angi sine preferanser for alle disse innholdselementene og egenskapene.

Innholdsfortegnelsen for en pizza kan f.eks. se slik ut:

EPD	2932267
GTIN	7039010019965
Produsents varenummer
Produktnavn	GRANDIOSA HELMAX SALAMI
Varemerke	GRANDIOSA
Produsent	Orkla Foods AS
Informasjonseier	Orkla Foods AS
Ingrediensliste	Hvetemel, vann, ost, 23% (Jarlsberg, mozzarella, Norvegia), skinke 8% (svinekjøtt, vann, salt, sukker, stabilisator (E451, E450), rosmarinekstrakt, antioksidant (E301), konserveringsmiddel (E250)), salami 7% (storfekjøtt, svinekjøtt, storfefett, salt, krydder, antioksidant (E300, E301), konserveringsmiddel (E250)), tomatpurè, mild søt chili, rapsolje, gjær, salt, sukker, krydder.
Inneholder følgende allergener	Gluten,Melk
Gluten	JA
Skalldyr	NEI
Egg	NEI
Fisk	NEI
Peanøtter	NEI
Soya	NEI
Melk	JA
Nøtter	NEI

Selleri	NEI
Sennep	NEI
Sesam	NEI
Svoveldioksid eller sulfitter	NEI
Lupin	NEI

2.3.1.1 Innhold som finnes i ingredienslisten

Alle ingredienser skal oppgis, men med noen unntak behøver ikke produsenten angi prosentandelen eller vekten av hvert enkelt element. Om ingredienslisten viser at to produkter begge inneholder natriumtitrit (E250), kan vi derfor ikke si hvilket som inneholder mest. Følgelig kan vi ikke fortelle en forbruker som måtte ønske så lite natriumnitrit som mulig hvilket av de to han bør velge.

Ingredienslisten er ikke kategorisert og ordnet. Den er bare en tekststreng der innholdselementene er listet opp. Betegnelsene bygger heller ikke på en felles terminologi. Det kan følgelig brukes flere forskjellige betegnelser på samme ingrediens. E250, natrimnitrit og sodiumnitrit er det samme.

Vi behøver antakelig en «metaingrediensliste», et største felles multiplum for samtlige av de rundt

30.000 varene som til enhver tid er i handelen. På grunn av den ikke-standardiserte terminologien blir nytten av denne likevel begrenset.

Brukeren vil derfor ikke på ett sted, i én tabell, få presentert en oversikt over samtlige ingredienser i samtlige varer (som antakelig summerer seg til flere ti tusener). Derimot vil han, når han tar frem en vare, få opp ingredienslisten og kunne krysse av for ingredienser han liker/ikke liker.

Ingredienspreferansene må altså bygges over tid og deretter automatisk tas hensyn til.

2.3.1.2 Innhold som finnes i næringsdeklarasjonen

I tillegg til ingredienslisten, må produsenten publisere næringsinnholdet, fordelt på syv komponenter. Dette er næringsinnholdet til pizzaen Helmax Salami:

NÆRINGSINNHOLD PR 100 GRAM
Energi	1053 kJ / 252 kcal
Fett	11 g
- hvorav mettede fettsyrer	3,3 g
Karbohydrater	25 g
- hvorav sukkerarter	2,5 g
Protein	13 g
Salt	0,90 g

Her finnes det mengdeangivelser, så her kan ett produkt veies mot et annet. Foretrekker man mat med lavt karbohydratinnhold, kan man f.eks. presentere pizzaer med under 25g/100g. Likeledes kan tjenesten hente opp pizzaer med mindre saltinnhold.

Med et så godt datagrunnlag, blir dette en relativt enkel liste der brukeren kan angi preferanser.

(Illustrasjonen er hentet fra en tidlig idéskisse).

2.3.1.3 Innhold som finnes i allergénlisten

I tillegg til ingredienslisten og næringsdeklarasjonen, må produsenten angi om varen inneholder ett eller flere av 14 allergéner. Her angis ikke mengden, det står enten JA eller NEI i listen.

Også dette gir et enkelt utgangspunkt for å la brukeren krysse av for allergener han vil unngå. Her er allergénlisten fra den nevnte pizzaen:

Inneholder følgende allergener	Gluten,Melk
Gluten	JA
Skalldyr	NEI
Egg	NEI
Fisk	NEI
Peanøtter	NEI
Soya	NEI
Melk	JA
Nøtter	NEI
Selleri	NEI
Sennep	NEI
Sesam	NEI
Svoveldioksid eller sulfitter	NEI
Lupin	NEI
Bløtdyr	NEI

2.3.1.4 Angivelse av kvalitetspreferanser

Ingredienslisten, allergénlisten og næringsdeklarasjonen omhandler rent tekniske egenskaper ved selve varene. Vi kan ikke ut fra disse opplysningene bedømme om varen smaker godt, om den ser appetittlig ut, om den har riktig konsistens og lukt o.s.v.

Vi kan heller ikke vite om det er brukt unødig mye sprøytemidler ved fremstillingen, om dyr er behandlet bra, om landbruksarbeidere er behandlet bra, om det er brukt mye energi ved fremstillingen eller om varene er kort- eller langreiste.

Men en rekke organisasjoner følger med på disse aspektene og tildeler varene diverse kvalitetsmerker. Brukere av dagligvaretjenesten vil kunne angi sine preferanser også for merkeordningene.

2.3.1.4.1 Smak er ikke lett

Det kvalitetsaspektet vi nok oftest tenker på er smak. Forbrukerrådet har imidlertid ikke tilgang til objektive vurderinger av smak. Vi vil kunne viderebringe brukernes vurderinger, men disse må jo brukes med de forbehold som følger av at folk har forskjellig smak og at produsenter kunne bli fristet til å gi karakterer til egne varer.

Man kunne også tenkt seg smakspaneler som blindtestet mat og drikke, eller anmeldelser fra fagfolk. Men dette har ikke Forbrukerrådet apparat til.

Brukeranmeldelser ønsker vi imidlertid å legge til rette for (se mer om det nedenfor).

2.3.1.4.2 Merkeordninger er lett og vanskelig

For en rekke merkeordningers vedkommende, vil varedatabasen inneholde opplysninger om hvorvidt en vare er tildelt merket. Disse kan enkelt presenteres for brukeren i en liste og han kan krysse av om han ønsker at disse tas hensyn til.

For andre merkeordningers vedkommende vil Forbrukerrådet publisere en innrapporteringsstandard som gjør at brukere selv kan importere disse til sin side i dagligvareløsningen (se mer om dette nedenfor).

I motsetning til allergener, som helt bør unngås, vil merkeordningene være et sorteringskriterium. Om brukeren har angitt det, vil varer alt annet like (eller omtrent like) nevnes tidligere som alternativ når de har det prefererte merket.

2.3.1.5 Preferanser angitt «i forbifarten»

Xxxxxxxxx preferanser kan også utledes av hans tidligere valg, både angitt på tidligere handlelister og – særlig interessant – når han har byttet en vare mot en annen i handlekurven/handlelappen sin.

Arkitekturmessig kan det diskuteres om dette hører hjemme i preferansetabellen eller om det hører hjemme i hans sammenslåtte, historiske handleliste.

Skal preferansene gjenspeiles og brukes som «Big Data», må de nesten lagres i en tabell som reflekterer varetabellen.

2.3.2 Handlelappbyggeren

Handlelappbyggeren er en applikasjon der brukeren kan finne varer ved søk, eller plukke dem fra et varehierarki. Varene er merket med ENVA-varegruppene de tilhører, et «fireetasjes» hierarki som korresponderer med FN-standarden UNSPCS. Kategoriseringen er ikke tilpasset inndelingen man i dag finner i norske butikker (og i norske forbrukeres hoder), men er det beste som i skrivende stund er tilgjengelig.

xxxx://xxx.xx0.xx/xxx-xxxx-xx0/xx0-xxxxxxxx/

Handlelappbyggeren bør derfor ikke bare baseres på et endimensjonalt hierarki, men det må også opprettes annet slektskap mellom varene.

2.3.2.1 Initielt butikkvalg

Før brukeren starter utfyllingen av handlelisten, blir han bedt om å oppgi hvilke butikker det kan være aktuelt å handle i. Dette kan skje både ved å velge fra et kart, ved søk og (kanskje) ved å oppgi hvor han er og hvor han skal.

Man skal kunne fortsette å fylle ut handlelisten også om man ikke velger butikk(er) det kan være aktuelt å handle i.

Bilag 1: Kundens kravspesifikasjon – Utvikling av dagligvarenettsted med opsjon på forvaltningsavtale

2.3.2.2 Finne varer

Å lage en handlelapp starter naturligvis med at du finner en vare og setter den på handlelisten din ved «dra og slipp».

2.3.2.2.1 Finne varer ved søk

Den enkleste måten å finne varer på, er å søke etter dem. Søker du på «ost», får du opp alle produkter i de relevante kategoriene (men helst ikke POSTERS, KOSTER eller POSTEIER).

Du skal så få de kategoriene og produktegenskapene fra varene eller varetypen opp som filtre.

(Fra en tidlig idéskisse).

2.3.2.2.2 Finne varer fra et kategoritre

Alternativt kan du velge varer direkte fra kategoritreet. En høyst foreløpig varekategorisering vises i skissen over. Hver av disse kategoriene vil ha underkategorier og datamodellen må ta høyde for et «uendelig» antall underkategorier.

Bygging av kategoritreet er ikke trivielt. Forbrukerrådet er kjent med AC Xxxxxxx og flere nettbutikker tilordner hver enkelt vare en varekategori manuelt. Forbrukerrådet har ikke kapasitet til å gjøre dette og er i skrivende stund på utkikk etter en koblingstabell mellom ENVA-kategorien (som er tilordnet varen av leverandøren) og et mer moderne hierarki. Om dette ikke finnes, må vi bruke ENVA-kategoriene direkte.

2.3.2.2.3 Finne varer med utgangspunkt i oppskrifter

Xxxxxxxx skal også kunne fylle handlekurven med utgangspunkt i oppskrifter. Xxxxxxxx skal kunne «klikke og dra» middagsretter til sin «Min månedsmeny» (på «MinSide) som skal inneholde inntil 30 middagsoppskrifter. De tilhørende ingredienser legges enkelt i handlelisten.

2.3.2.2.4 Finne varer med utgangspunkt i en butikk

Både i det alminnelige søkefeltet og ved kart, skal brukeren kunne finne en enkel butikk. Velger man en butikk, vil vareutvalget i den «nettbutikken» som utgjøres av Forbrukerrådets dagligvaretjeneste innskrenkes til å omfatte bare utvalget i den valgte butikken.

2.3.2.3 Alternativer til varene du fant

Nytten av en sammenlikningstjeneste for dagligvarer består i at den må hjelpe deg til å finne varer bedre tilpasset ditt behov. Det vil derfor være viktig at tjenesten kan presentere deg for alternative varer.

Funksjonaliteten kan sees på som en egen applikasjon, her kalt «Alternativvelgeren», som automatisk trer i funksjon når brukeren velger en vare eller skanner en hyllekant. Det må være et mål at den ikke viser en lang liste med alternativer, i hvert fall ikke på mobil, men mer målrettet plukker ut de alternativer som kan være aktuelle for akkurat denne brukeren.

Dette er ikke trivielt, og i skrivende stund ikke ferdigutforsket. Men nedenfor presenteres noen innfallsvinkler.

2.3.2.3.1 Alternative varer basert på egne preferanser

I avsnittet om preferanser (Feil! Fant ikke referansekilden.) spesifiseres det at det skal bygges en slags valgside der brukeren kan angi sine preferanser langs en hel rekke akser.

(Fra en tidlig idéskisse).

Pris skal uansett være en preferanse (og kanskje ikke et eksplisitt brukervalg: Alt annet like skal løsningen foreslå den billigste varen).

2.3.2.3.2 Alternative varer basert på kategorier

Først og fremst skal alternativene baseres på brukernes preferanser. ENVA-varegruppene er for få/har for liten oppløsning. Alternativer basert bare på ENVA-kategorier vil antakelig frembringe mange irrelevante varer.

Alternativvelgeren vil søke gjennom alle varer fra samme kategori som den brukeren har valgt og se om noen bedre tilfredsstiller hans preferanser.

(Skjermdump fra nettbutikken xxxxxxxx.xx)

La oss si at vår bruker har valgt en pakke med ferdig oppskåret («skivet») Jarlsberg ost fra Tine. Løsningen kan med EPD-nummeret som nøkkel uten videre hente opp det identiske produktet fra andre butikker, men vil ikke lett kunne identifisere alle reelle alternativer. Det vil kunne finnes alternativer som ikke er ferdig oppskåret. Det vil kunne finnes større pakninger.

Varene er påført ENVA-kategorinumre. Her er kategoriene for ost:

2658 BRUNOST INDUSTRIPK. OST NORSK

2659 2661	HVITOST BUTIKKPK./LØSVEKT OST KUVERTPAKKET NORSK	OST NORSK IMPORTERT OST NORSK	OG
2662	PRIM INDUSTRIPK.	OST NORSK

2663	MATLAGINGSOST BUTIKKPK./LØSVEKT	OST NORSK OG IMPORTERT
2664	SMELTEOST BUTIKKPK./LØSVEKT	OST NORSK OG IMPORTERT
2667	HVITOST INDUSTRIPK.	OST NORSK OG IMPORTERT
2669	OST KUVERTPAKKET IMPORTERT	OST NORSK OG IMPORTERT
2671	MATLAGINGSOST INDUSTRIPK.	OST NORSK OG IMPORTERT
2672	SMELTEOST INDUSTRIPK.	OST NORSK OG IMPORTERT
3878	KREMOST BUTIKKPK./LØSVEKT	OST NORSK OG IMPORTERT
3879	BLÅMUGGOST BUTIKKPK./LØSVEKT	OST NORSK OG IMPORTERT
3880	HVITMUGGOST BUTIKKPK./LØSVEKT	OST NORSK OG IMPORTERT
3881	PULTOST INDUSTRIPK.	OST NORSK
3882	OST KITTMODNET BUTIKKPK./LØSVEKT	OST NORSK OG IMPORTERT
3883	KREMOST INDUSTRIPK.	OST NORSK OG IMPORTERT
3884	HVITMUGGOST INDUSTRIPK.	OST NORSK OG IMPORTERT
3885	BLÅMUGGOST INDUSTRIPK.	OST NORSK OG IMPORTERT
3886	OST KITTMODNET INDUSTRIPK.	OST NORSK OG IMPORTERT
4418	BRUNOST BUTIKKPK./LØSVEKT	OST NORSK
4419	PRIM BUTIKKPK./LØSVEKT	OST NORSK
4420	PULTOST BUTIKKPK./LØSVEKT	OST NORSK
4421	OST DIVERSE ØVRIG	OST NORSK
4727	HVITMUGG	DESSERTOST
4728	BLÅMUGG	DESSERTOST
4729	FAST	HVITOST BIT
4730	HALVFAST	HVITOST BIT
4731	KITTMODNET	HVITOST BIT
4732	LETT	HVITOST BIT
4733	ØKOLOGISK	HVITOST BIT
4734	REVET	MATLAGINGSOST
4735	PARMESAN	MATLAGINGSOST
4736	FETA	MATLAGINGSOST
4737	MOZZARELLA	MATLAGINGSOST
4738	ØKOLOGISK	KREMOST
4739	LETT	KREMOST
4740	STANDARD	KREMOST
4741	TUBE	SMELTEOST

4742	BEGER	SMELTEOST
4743	BIT	SMELTEOST
4744	BIT	BRUNOST
4745	LETT	BRUNOST
4746	PRIM	BRUNOST
4747	SMELTOST	SKIVET OST
4748	BRUNOST	SKIVET OST
4749	KITTMODNET	SKIVET OST
4750	LETT	SKIVET OST
4751	FAST	SKIVET OST
4752	HALVFAST	SKIVET OST
4753	GAMMELOST	DIVERSE OSTER
4754	PULTOST	DIVERSE OSTER
4755	SØST	DIVERSE OSTER

(Kilde: GS1 Norway)

Skivet Jarlsbergost er antakelig påført ENVA-varekategorien 4751 – «Fast skivet ost».

Kanskje finnes passende alternativer i de andre gulmerkede ostekategoriene over. Men vi har ingen regel/algoritme for hvordan vi kan assosiere dem automatisk.

Vi kan presentere andre varer i samme kategori. Men å presentere alle varer her som alternativer vil kunne være bom. Mange oster som er nokså annerledes enn Xxxxxxxxx vil kunne finnes her.

2.3.2.3.3 Alternative varer basert på produsent

Jarlsberg skivet ost av en viss pakningsstørrelse lar seg identifisere ved sitt varenummer. Om vi også ser på produsenten, vil vi kunne avgrense alternativene til andre Tine-oster.

2.3.2.3.4 Alternative varer basert på ingredienser

For mange varere vil lignende ingrediensliste bety lignende varer. I Jarlsberg-eksemplet vil man kunne sjalte ut oster som ikke er laget av kumelk, og også oster tilsatt f.eks. skinkebiter eller reker.

2.3.2.3.5 Alternative varer basert på produktnavn

Noen ganger vil dette kunne hjelpe, men i osteeksemplet blir det antakelig for snevert bare å presentere Xxxxxxxxx-oster som alternativer til Jarlsberg. Men det vil i det minste kunne frembringe andre pakningsstørrelser og også den magrere varianten av osten. Oster med

«skivet» i produktnavnet vil avgrense utvalget av alternativer.

2.3.2.3.6 Alternative varer basert på at varen er ny

En AC Nielsen-undersøkelse («Nordmenn er vanedyr i butikken» 23-06-2015) viser at nordmenn i stor grad holder seg til varer vi har kjøpt før. Når vi bytter, er det viktigste motivet at varen er ny.

I vår dagligvaretjeneste vil vi merke oss når det kommer nye varer i varelisten. En visst tid etter at de er introdusert, er de særlig aktuelle som alternativer.

2.3.2.3.7 Alternative varer basert på egne tidligere valg

Til å begynne med vil brukerne kunne få opp for mange alternativer, mange av dem irrelevante. Men over tid vil løsningen kunne merke seg hvilke varer du anser som alternativer til hverandre og foreslå disse først.

2.3.2.3.8 Alternative varer basert på andres valg

På samme måte som tjenesten husker dine egne valg av alternativer, vil den kunne aggregere alle brukers valg for det formål å fremstille alternativlister. Dette ligner litt på måten f.eks.

Spotify lager spillelister på, basert på andre som hører på det samme som deg.

2.3.2.4 Oppdeling av handlelister

Om du skal stikke innom butikken på vei hjem fra bussen, ønsker du kanskje ikke å besøke flere dagligvarebutikker. Men tjenesten skal kunne dele handlelisten om du ønsker det. Du skal kunne dele den både i to og tre, med én handleliste for hver butikk.

2.3.2.5 «Send til nettbutikk»

Etter all sannsynlighet vil også nettbutikker vise sitt vareutvalg og sine priser i vår nye løsning. Om brukeren velger nettbutikk, må tjenesten kunne sende ham videre til denne med en liste som bare inneholder produkter vedkommende butikk har signalisert at den har. Når han klikker seg til nettbutikken, vil han få med sin handleliste i form at et json-array.

(Illustrasjonene er hentet fra en tidlig idéskisse).

Oppdelingen av handlelister må følge visse regler. Antakelig må brukeren merke av de fysiske butikker det er aktuelt for ham å handle i. På et mer avansert nivå kan tjenesten beregne en alternativkostnad for tid (slike tidskostnader publiseres bl.a. av Transportøkonomisk Institutt) og kostnadene ved en lengre reise, om handling i den alternative butikken er en omvei.

2.3.2.5.1 Omsortering ved «utsjekking»

Brukeren skal kunne fylle kurven med hvilke varer hun vil, selv om innholdet i kurven etter hvert kan måtte kreve besøk i en rekke forskjellige butikker. Ved «utsjekking» vil brukeren kunne velge å få én handleliste, eller to eller flere. I mange tilfeller blir det uansett varer som må ut av kurven igjen.

Bytte av varer i kurven, for å lage en praktisk håndterlig liste, må te seg på samme måte som det initielle valget av varer. Men nå blir bare varer i de valgte butikkene tilgjengelige.

Brukseksempel for handlelappbyggeren

Brukeren går inn på dagligvarenettstedet og søker på «fisk» i søkefeltet. Han får så opp all fisk som finnes i alle butikker.

Et sprettoppvindu som spør ham om han vil innskrenke utvalget til butikker i nærheten. Han kan enten skrive inn navnet på stedet han befinner seg, eller velge fra kart. Han kan videre plukke ut det antall enkeltbutikker han ønsker.

Han klikker på noen fiskeprodukter til han har funnet et som passer, og klikker «Sett på handleliste». Dagligvarenettstedet vil da også vise frem tre – fem alternativer, antakelig i form av mindre bilder rundt kanten av rammen som inneholder den valgte varen. Brukeren velger eller velger ikke et av alternativene.

Den neste varen vil han velge fra kategoritreet på siden. Han velger frysevarer og går gjennom hierarkiet ned til Pizza. Han finner en pizza han legger til handlelappen.

Om han gjenkjennes, ved cookie eller innlogging, kan han klikke på «Tidligere handlelapper». Disse vil komme frem i form av en liste der han kan klikke ved de varene han også ønsker å handle nå.

Han klikker «Skriv ut handlelapp» eller «Lagre handlelapp». Han kan nå få beskjeden:

«Varene på handlelisten finnes i fem forskjellige butikker. Klikk på den/de du vil handle i». I samme dialog er det en oversikt over butikkene og han kan klikke på den han vil gå i.

Nå følger vanligvis en ny dialog som følge av at han må bytte ut varer som ikke finnes i butikken han har valgt. Én og én vare kommer frem og alternativer presenteres.

Nå kan handlelisten lagres. Han får spørsmålet «Vil du sende handlelappen til deg selv?». Han kan så sende den pr. sms eller e-post, slik at den kan hentes frem på telefonen i butikken.

Om butikken han har valgt er en nettbutikk, får han frem valget «Send handlelisten til nettbutikken x».

2.3.3 Preferansesnifferen

Preferansesnifferen er beregnet på bruk fra mobiltelefon. Ved hjelp av denne skal brukeren skanne strekkoden til varen. Applikasjonen vil vise den informasjonen om varen som ligger i varedatabasen. Varer som bedre passer med preferansene skal komme frem, om det er noen.

En indikator vil så vise i hvilken grad varen passer til brukerens preferanser.

Preferansene er de brukeren har angitt på forhånd, eller de som (med hans tillatelse) kan utledes av tidligere adferd på nettstedet. Om slik informasjon ikke foreligger, vil indikatoren vise om varen er relativt dyr eller relativt billig sammenliknet med alternative, liknende varer.

Preferansesnifferen er hovedsakelig ment som en frittstående applikasjon. Men brukeren bør kunne angi om han virkelig kjøper angjeldende vare. Denne vil da legge seg i hans kjøpshistorikk/dagligvareregnskap.

I skrivende stund er ikke Forbrukerrådet sikre på om man kan bygge preferansesnifferen som en nettside tilpasset mobil eller om man er nødt til å bruke en «app». En html-applikasjon som kjører i

nettleseren foretrekkes (da slike er lettere å vedlikeholde), men om nødvendig må det lages «apper» for Android og iPhone.

Preferansesnifferen skal også ha en funksjon der brukeren kan skanne strekkoden på hyllekoden og trykke på knappen «Utsolgt», om varen ikke finnes i hylla.

Endelig kan vår pris være feil. Også dette skal brukeren kunne melde fra om.

2.3.3.1 «Tomt for varen»-knappen

Preferansesnifferen skal også inneholde en knapp der brukeren kan angi at varen ikke finnes i hylla. Siden det stadig er butikker som har lager, kan man ikke konkludere med at den er utsolgt. Men om dagligvaretjenesten mottar mange uavhengige «Tomt for varen»-meldinger, kan man kanskje vise en advarsel til andre brukere: «Antakelig tomt», eller liknende.

Brukseksempel for preferansesnifferen

Xxxxxxxx åpner dagligvaretjenesten på en smarttelefon inne i butikken. Han skanner strekkoden på en vare og får frem ingrediensliste, næringsinnhold og allergener. Han har tidligere angitt at han ikke tåler gluten. Siden varen inneholder gluten, peker indikatoren på rødt. Samtidig foreslår applikasjonen to alternative varer som finnes i samme butikk og som ikke inneholder gluten.

Xxxxxxxx velger en av disse, og krysser av i applikasjonen for at han har kjøpt den.

Xxxxxxxx ser at en vare er utsolgt. Han skanner strekkoden på hyllekanten og klikker på «Tomt for varen»-knappen i applikasjonen.

2.3.4 Oppskriftsvelgeren

Det skal være en egen side hvorfra man kan velge oppskrifter. Oppskriftene skal være tilknyttet konkrete enkeltvarer og kunne legges direkte i handlekurven.

De vil også kunne legges til «Min Månedsmeny», hvor det vil være plass til inntil 30 middagsoppskrifter samt en kurv andre dagligvarer (brødmat, pålegg, brus, godteri, vaskemidler, papir etc.).

Tjenesten vil løpende beregne og vise frem prisen for månedsmenyen. Den vil også summere opp næringsinnholdet for alle varene og kanskje allergenene og ingrediensene.

Oppskriftene vil ha tre kilder:

1. En redaksjonelt styrt grunnbase med oppskrifter

2. Mulighet til å importere oppskrifter fra eksterne kilder

3. Mulighet til å importere andre brukeres oppskrifter

4. Mulighet til å legge inn egne oppskrifter

2.3.4.1 Innlegging av egne oppskrifter

Det skal være mulig for brukeren å lage egne oppskrifter. Tjenesten vil inneholde en

«metaingrediensliste» som er største felles multiplum for alle varene i tjenesten. Oppskriften må benytte ingredienser som gjenfinnes her.

Oppskriften skal kunne deles med andre brukere. Det kan hende at bare oppskrifter der det lastes opp bilde(r) skal kunne deles.

2.3.5 Kartvelgeren

Løsningen skal tilknyttes et kart, fortrinnsvis et som ikke fordrer at Forbrukerrådet må betale lisensavgift. Her skal alle butikkene i butikktabellen finnes. Hver butikk kan vises med en kjedelogo. Når man klikker på butikken, vår man opp overordnede data, som adresse, eierforhold, parkeringsforhold og åpningstider (om disse er tilgjengelig). Når man har valgt en butikk, blir de tilgjengelige varene i menyer og fra søk begrenset til det som finnes i denne butikken. Men man kan velge flere butikker (se Handlelappbyggeren, avsnitt 2.3.2).

2.3.6 Forum

Brukerne skal kunne skrive anmeldelser av enkeltvarer. Anmeldelsene skal være under fullt navn. Brukene skal likeledes, som beskrevet her, kunne legge inn oppskrifter.

Begge deler skal være synlig for andre brukere, som vil kunne knytte til kommentarer.

Vi ser ikke for oss at det skal være noe meldingssystem i tjenesten der brukere kan sende meldinger til bare én annen bruker.

2.3.6.1 Administrasjonsside for forum

Forumet vil være manuelt moderert. Ingen innlegg kommer inn uten godkjenning av moderator. Det må derfor være en administrasjon for dette. Selv godkjente innlegg kan inneholde tvilsom informasjon, og brukere skal kunne «flagge» slike.

Administrasjonsløsningen må gi administrator mulighet til å gi debattanten en direkte begrunnelse om innlegget er avvist.

2.3.7 Brukerens «MinSide»

Applikasjonene som er beskrevet vil alle kunne lagre brukerdata til senere. Brukeren vil kunne få adgang til disse ved en cookie på mobiltelefonen. På andre plattformer må han logge inn.

Det er i skrivende stund uklart hvor «sterk» innlogging som vil benyttes. Om det skal lages brukerfora med diskusjoner rundt bl.a. enkeltvarer, bør disse kanskje finne sted under fullt navn. Da bør innloggingen være med MinId, BankId eller tilsvarende.

«MinSide» vil kanskje bare kreve én egen side – for angivelse av innloggingsdata og kanskje innlegging av bilde. Den viktigste funksjonaliteten vil være at en innlogget bruker vil finne applikasjonene i løsningen slik han forlot dem ved forrige besøk, med alle tidligere valg synlige.

2.3.8 Lagring av data og produksjon av statistikk

Dagligvarenettstedet vil ta vare på alle prisdata i minst ett år. På bakgrunn av disse, vil vi kunne publisere prisutviklingen for varene sett under ett og varegrupper. Det kan også være aktuelt å transportere disse data til andre offentlige myndigheter i form av feeder.

2.3.8.1 Intern statistikkside

Vi ønsker at databasen kobles til et standard statistikkverktøy med fri programvare-lisens, slik at vi skal kunne gjøre standard uttrekk og analyser av databasen selv. I utgangspunktet er dette verktøyet bare for redaksjonen.

2.3.8.2 Ekstern statistikkside

Noen uttrekk av statistikken skal produseres henholdsvis hvert døgn, hver uke og hver måned og publiseres på en offentlig tilgjengelig statistikkside.

2.3.8.3 Statistikkfeeder

Noen uttrekk av statistikken skal kunne gjøres tilgjengelig som ukentlige og månedlige feeder.

2.4 Øvrige sider på dagligvarenettsted

Nettstedet vil, som det fremgår over, operere langs en rekke akser hva gjelder helse, smak, merkevarer, allergener o.s.v. Hvert eneste alleregén vil f.eks. naturlig fordre en artikkel. Det må kunne publiseres artikler om kosthold og matlaging, bl.a.

Artiklene vil nok spille annenfiolin – det meste av nettstedet vil minne om en nettbutikk, og denne funksjonaliteten vil stå i fokus og oppta det meste av oppmerksomheten. Artiklene vil finnes i en sekundær meny, antakelig. De må kunne opprettes og publiseres i WordPress.

2.4.1 Administrasjonssider

Det vil måtte være sider der vi setter opp import av nye prisdata fra eventuelle nye aktører som vil være med.

Det må likeledes kunne settes opp import av merkedata og av oppskrifter fra et administrasjonsgrensesnitt.

I administrasjonsgrensesnittet bør det ligge en oversikt over antallet registrerte brukere.

2.4.1.1 Administrasjon av forhåndsinnstillinger

Hvilken utgangsposisjon skal filtrene ha? Hvordan skal menystrukturen være? Hva skal ordlyden i menyordene være? Hvilke oppskrifter skal i utgangspunktet ligge i 30-dagersmenyen?

Disse og en rekke andre innstillinger skal være tilgjengelige via en administrasjonsside.

Som nevn i avsnittet om spesialversjoner, kan det være flere parallelle versjoner av nettstedet, eller av Preferansesnifferen. De vil skilles fra hverandre ved hvordan filtre er forhåndsvalgt. Slik skal det kunne være flere parallelle administrasjonssider.

2.4.2 Ingen «portabel» versjon

Finansportalens forsikringskalkulatorer kan i dag publiseres på tredjeparts nettsteder, med skreddersydde, farger, fonter og størrelse i en iframe. En liknende funksjon kommer for strømkalkulatoren på xxxxxxxxx.xx.

Den nye dagligvaretjenesten vil kun ligge på sitt eget nettsted.

2.5 Parallelle versjoner av hele nettstedet, eller av Preferansesnifferen

Det skal være mulig å publisere «spissede» versjoner av nettstedet og/eller av preferansesnifferen. Den spissede versjonen vil ikke kreve egne datatabeller, med unntak av administrasjonssiden der

«spissingen» foretas.

«Spissingen» består i at et eller flere av preferansefiltrene er forhåndsinnstilt.

Man skal kunne publisere den ferdig «spissede» versjonen fra en egen url, eller laste ned «spissingen» til sin eksisterende installasjon.

En mulig «spisset» versjon av Preferansesnifferen ville kunne være en som prefererer økologisk mat. Den vil kunne ha en litt avvikende design og annen farge.

2.5.1 Layoutparametere for spisset versjon

De viktigste grafiske elementene i Preferansesnifferen og på nettstedet skal kunne byttes ut med andre i de «spissede» versjonene. Også fonter og farger skal til en viss grad kunne endres, antakelig ved parametere i adressestrengen når versjonen anropes.

2.6 Testmiljø

Forbrukerrådet ønsker to parallelle installasjoner. Den ene skal være testmiljø, den andre utgjør produksjonsmiljøet.

Testmiljøet krever naturligvis mindre kapasitet mot internett.

Det vil være separate innlogginger og fullmakter for test og produksjon.

Forbrukerrådet praktiserer ikke noen automatisk oppdatering av produksjonsmiljøet med testdata. Det er et forholdsvis strengt skille mellom de to miljøene. Data må legges inn separat begge steder.

Forbrukerrådets dataleverandører har tilgang til testmiljøet, der de kan legge inn eksperimentelle priser og vilkår og se hvordan dette tar seg ut i sammenlikningene.

Ved utvikling av nye tjenester og finesser, vil disse som oftest først installeres i testmiljøet, hvor bl.a. dataleverandørene kan prøve dem og kommentere dem før de lanseres i produksjon.

Dette nødvendiggjør to parallelle installasjoner.

Testmiljøet og produksjonsmiljøet skal ligge «i skyen», som for tiden er Amazon Web Services.

2.7 Utviklingsmiljø

Vanligvis finnes det også en tredje installasjon, for utviklingsformål. Forbrukerrådet har erfaring for at utviklingsselskapet selv ønsker å være vertskap for utviklingsmiljøet, på egne maskiner, og har derfor lagt dette til grunn også i dette anbudet. Oppbyggingen av et utviklingsmiljø, en tredje parallellinstallasjon, er derfor ikke omfattet av utviklingsanbudet.

3 Kapasitet

Trafikken til Forbrukerrådets nettsteder varierer sterkt. Våre tjenester nevnes av og til i media, og særlig etter fjernsynsomtale kan en tjeneste som xxxxxxxxxxxxxx.xx eller xxxxxxxxx.xx ha 20.000 - 30.000 besøk på under én time.

For Finansportalens kalkulatorer kreves det at hver av dem kan håndtere opp til 1.600 henvendelser pr. minutt.

Også de øvrige tjenestene har tilsvarende krav.

Dagligvarer utgjør 10-15 ganger mer penger for husholdningene enn forsikring. Interessen forventes derfor også å bli høyere enn for våre nåværende tjenester. Gjennomsnittlig forventer vi 20.000 brukere om dagen, mens trafikktopper kan gjøre det nødvendig å avvikle 100.000 besøk på én time.

Vi regner med at svaret på trafikkutfordringene til en viss grad ligger i å leie tilstrekkelig kapasitet på hardware-siden i skyen. Forbrukerrådet vil sørge for dette, etter leverandørens anbefaling. Men tjenesten må selvfølgelig også ha en innebygget skaleringsmulighet.

4 Prosjektmetodikk

Forbrukerrådet etterspør ikke noen spesiell prosjektmetodikk. Alt arbeidet som er beskrevet i dette dokumentet skal i løpet av prosjektperioden fullføres til høy faglig standard innenfor den faste anbudssummen. En oppdeling i «sprinter» og Forbrukerrådets eventuelle godkjenning av disse avlaster ikke leverandøren for noen sider av dette totalansvaret.

Forbrukerrådet ønsker å avholde hyppige videokonferanser med utviklingsselskapet i utviklingsperioden, kanskje i form av et kort, daglig morgenmøte.

5 Utviklingsperiode

Utviklingen starter medio desember 2015. Tentativ lansering skal skje 1518. oktober 2016.

6 Garantitid og forvaltning

Innenfor rammen av anbudet, skal leverandøren foreta feilretting og optimalisering av de utviklede løsninger til og med 30/06/20162017. Også teknisk kommunikasjon med dataleverandører hører inn under garantiarbeidet.

Leverandøren må selv anslå forvaltningsbehovet de første driftsmånedene og bake dette inn i anbudet. Forbrukerrådet antar leverandøren minst må benytte én full stilling til finpuss og feilretting.

7 Opsjon på forvaltning og videreutvikling

Når tjenesten er etablert på AWS, og de første driftsmånedene er overstått, må den forvaltes og videreutvikles. Vi ønsker en opsjon på en forvaltnings- og videreutviklingsavtale, gjeldende fire år fra 1. juli 2017.

Leverandøren skal når som helst kunne si opp avtalen med seks måneders forvarsel. Kundens oppsigelsestid er tre måneder.

Med maskinparken plassert i «skyen», er det ikke naturlig å ha en separat driftsavtale. I stedet inngår de driftsoppgaver skyoperatøren ikke utfører i forvaltningen.

Den største delen av forvaltningsjobben er retting av feil, støtte til dataleverandører og små utbedringer.

Forbrukerrådet ønsker en meget fleksibel avtale, som foruten drift og forvaltning også omfatter mindre utviklingsoppgaver.

Forbrukerrådet forplikter seg ikke til noe uttak etter avtalen.

Bilag 1: Kundens kravspesifikasjon – Utvikling av dagligvarenettsted med opsjon på forvaltningsavtale

7.1 Forvaltning

Forvaltningsoppgavene estimerer Forbrukerrådet til 140 timer i måneden.

7.1.1 Forvaltningsoppgaver

Forvaltningsoppgavene

• Registrering av brukere og innloggingshjelp til produksjons- og testmiljøer

• Installasjon og vedlikehold av sikkerhetsprogramvare.

• Installasjon og vedlikehold av andre standardkomponenter og nye versjoner

• Retting av feil i spesialutviklet programvare

• Utbedre feil og brudd i kommunikasjonen med dataleverandører

• Utrede og forebygge sikkerhetsbrudd

• Bistå dataleverandører med å løse tekniske problemer i kommunikasjonen med Forbrukerrådet

• Produsere driftsrapporter

• Ha den daglige forvaltning av «skyen», i den utstrekning skyleverandøren (for tiden AWS) ikke utfører oppgavene.

Forvaltningsoppgavene omfatter ikke generell brukerstøtte for publiseringssystemet WordPress

Forbrukerrådet binder seg innenfor forvaltningsavtalen ikke til å foreta noen bestillinger, men det er Forbrukerrådets intensjon vanligvis å benytte avtalen for et uttak på rundt 120 timer i måneden om vi erklærer forvaltningsopsjonen.

7.1.2 Forvaltningsrutiner

Forbrukerrådet vil sørge for at forvaltningsselskapet møter entydige bestillings- og prioriteringsrutiner.

7.1.2.1 Responsfrister

Leverandøren skal svare på e-posthenvendelser i løpet av 15 minutter i arbeidstiden (alle virkedager mellom 8-16 norsk tid).

Leverandøren skal også ha et vaktsystem med et sentralt telefonnummer hvor Xxxxxx i kritiske tilfeller kan nå Leverandøren også utenom arbeidstid.

7.1.2.2 Utbedringsfrister

Forbrukerrådet kategoriserer forvaltningsoppgaver som A-feil, B-feil og C-feil. Det er Kunden som bestemmer hvilken kategori en feil hører hjemme i (se også kontrakten).

Bilag 1: Kundens kravspesifikasjon – Utvikling av dagligvarenettsted med opsjon på forvaltningsavtale

A-feil er driftskritiske feil som fører til at hele eller vesentlige deler av løsningen er utilgjengelig eller ikke virker. Retting av slike feil må påbegynnes øyeblikkelig i arbeidstiden, og innen én time resten av døgnet og uken.

B-feil er også feil som gir driftsstans eller alvorlige feil, men i begrensede deler av løsningen. B-feil løses som en hovedregel innenfor normal arbeidstid. B-feil skal påbegynnes innen en virkedag etter at de er meldt.

C-feil er annen driftsassistanse. En del slike feil vil kunne være initiert av dataleverandører (varedataleverandør, dagligvarekjeder). Det kan også være oppdatering av programvare som benyttes og andre forefallende vedlikeholdsoppgaver. C-feil skal normalt påbegynnes innen fem virkedager (en uke).

Avtalen omfatter også mulighet for å utføre mindre utviklingsoppgaver, som bestilles fra gang til gang.

7.1.2.3 Oppetid

Alle deler av Forbrukerrådets internettsteder skal i gjennomsnitt være tilgjengelige for publikum i minst 99,5% av tiden.

7.1.2.4 Youtrack

Xxxxxxxxxxxxxx.xx benytter i dag oppgavesystemet «Youtrack in cloud» i sin kommunikasjon med forvaltningsselskapet. (Youtrack er nokså likt Jira og Bugzilla. Les mer her: xxxx://xxx.xxxxxxxxx.xxx/xxxxx).

Oppgaven blir beskrevet i meldingssystemet. Forbrukerrådet ber der om et estimat på timeforbruk for å løse den og vil deretter bestille den, legge den i en kø, be tredjepart om å løse den eller løse den selv.

Oppgavene diskuteres i meldingssystemet.

Estimatene, samt beskrivelse av hva som er gjort, føres inn i meldingssystemet.

Det finnes også en e-postadresse dataleverandører kan benytte for å be om assistanse. E-post adressert hit blir automatisk en oppgave i Youtrack (men den blir stadig bare løst etter ordre fra Forbrukerrådet).

7.1.2.5 Github

Løsningene til xxxxxxxxxxxxxx.xx og xxxxxxxxxxxxxxxxxx.xx er dokumentert i Github. Dette verktøyet skal brukes til å dokumentere utviklingsoppdraget og fremtidige endringer innenfor rammen av Forvaltnings- og videreutviklingsavtalen.

7.2 Videreutvikling

Nettstedet vil ha et løpende behov for videreutvikling. Innenfor forvaltnings- og videreutviklingsavtalen vil leverandøren ha rett til å gi pris (anslå et timeforbruk) på alle mindre oppgaver.

Forbrukerrådet vil vanligvis anskaffe slike hos leverandøren, men har rett til når som helst og uten noen begrunnelse å innhente alternative tilbud.

Oppgaver estimert til å koste mer enn 200.000 kroner vil uansett bli gjort til gjenstand for konkurranse fra alternative leverandører.

Omfanget av videreutvikling er altså avhengig både av Forbrukerrådets behov og av at man kommer til enighet om omfanget av den enkelte oppgave. Men Forbrukerrådet tror det er et videreutviklingsbehov på rundt 140 timer i måneden som kan komme til å bli dekket av videreutviklingsdelen av avtalen.

Forbrukerrådet binder seg imidlertid ikke til å kjøpe noe videreutvikling av leverandøren.

8 Konkurransekriterier – leverandørens besvarelse

Se eget dokument for de komplette konkurransereglene. Vurderingskriteriene i dette anbudet er kvalitet og pris.

Kvaliteten vil bli basert på en enkel vurdering av de personer tilbyder vil benytte til å utføre oppdraget. Deres formelle utdannelse vil telle halvparten og deres dokumenterte, relevante erfaring halvparten. Tilbudet vil bli veiet med hvor mye hver person skal arbeide i prosjektet.

For eksempel vil en mastergrad i informatikk gi full score på utdannelse – poengtall 3. Bachelorgrad vil gi poengtall 2. Om prosjektet skulle utføres av to personer med henholdsvis mastergrad og bachelorgrad i informatikk, hvor sistnevnte skulle utføre 70% av arbeidet, ville samlepoengsummen for «utdannelse» bli (70 x 2 + 30 x 3)/100 = 2,3

Besvarelsesskjemaene ligger i et eget bilag, som heter Leverandørens svar. Bruk disse og legg til kopier og nye rader etter behov.

8.1 Utdannelse

Utdannelsen til de personer som skal delta i prosjektet beskrives under. Tilbyder kan selv regne ut poengsummen etter følgende formel:

3 poeng: Mastergrad eller høyere i informatikk/computer sciences

2 poeng: Minst mastergrad i annet teknisk fag, Bachelorgrad i informatikk/computer sciences

1 poeng: Xxxxx høyere utdannelse

0 poeng: Ingen høyere utdannelse

Navn	Utdannelse	Universitet/høy- skole	Dokumentasjon	Poeng	Andel i utviklngs- prosjektet	Andel i forvaltning
Xxxx Xxxxxxxx	Mastergrad i informatikk	UiO	Vitnemål på forespørsel	3	40%	60%
Xxxxx Xxxxxxxx	Bachelorgrad i informatikk	Chalmers	Vitnemål på forespørsel	2	60%	40%

Utdannelse må kunne dokumenteres ved fremleggelse av eksamenspapirer, men vitnemål behøver ikke vedlegges anbudet.

(Dette skjemaet finnes også i vedlegget Leverandørens svar. Stryk og tilfør rader etter behov).

8.2 Erfaring

Det skal fylles ut erfaringsskjema. Erfaringen må dokumenteres.

Her vil imidlertid Forbrukerrådet gi poengene selv. Også her vil vi gi poeng etter en skala fra 0 til 3.

3 poeng: Sentral deltakelse i arkitektur og utvikling av vellykkede, økonomiske sammenlikningstjenester basert på automatisk datainnsamling, tilsvarende den nye dagligvaretjenesten.

2 poeng: Som over, men med en personlig mindre sentral rolle, eller en sterk rolle i andre relevante prosjekter på samme teknologiske plattform (linux, postgresql, java, nytt Fri Programvare- publiseringssystem, web services, microdata) og med like høy kompleksitet.

1 poeng: Mindre grad av personlig deltakelse i relevante prosjekter på samme eller i hovedsak samme teknologiske plattform (linux, postgresql, java, WordPress, web services, microdata) og med en mindre grad av kompleksitet.

0 poeng: Ingen erfaring med prosjekter og teknologier som beskrevet ovenfor

Vanligvis vil man ha utført oppgavene som del av et team. Den personlige andelen og rollen i oppdraget bør attesteres av teamleder eller av kunden.

Summen av vektene under er 1. For en person som scorer maksimalt på alle delområdene, vil poengsummen bli 3 poeng.

Det skal fylles ut ett skjema for hver person. Benytt versjonen i vedlegget «Leverandørens svar». Dokumentasjon kan gis i form av vedlegg eller referanser. Referanser må være kontaktet på forhånd.

Navn	Xxxx Xxxxxxxx	Xxxxx av arbeidet i utviklingsprosjektet	X %
Område	Dokumentasjonskrav	Dokumentasjon: Referanse/attest fra prosjektleder eller kunde. Url til tjenester.	Vekt
Web servicese	Dokumentert erfaring med maskin-til- maskin oppdatering av store datamengder via web services		12 %
Komplekse relasjons- datatabeller	Dokumentert erfaring med bygging og vedlikehold av komplekse og store samvirkende tabeller som hyppig aksesseres fra internett		12 %
«Big Data»	Dokumentert erfaring med utvikling av løsninger som bygger på analyse av store mengder brukerdata		8 %
Web-prosjekter	Oversikt over inntil 3 webprosjekter fra siste 3 år.		8 %
Open source	Dokumenter erfaring med bruk av Fri programvare.		8 %
Personali- sering	Dokumentert erfaring med personalisering av varer/musikk/filmer e.l. bygd på «Big data»		8 %
Java	Dokumenter erfaring med JavaEE utvikling.		8 %
Nettbutikker	Erfaring med bygging av nettbutikker		7 %
Linux	Dokumentert erfaring med Linux.		4 %
Universell utforming	Dokumenter kjennskap til universell utforming.		4 %
Postgresql	Dokumenter erfaring med postgresql, eller om slik mangler, andre sql-baserte databaser.		2 %
Skyerfaring	Dokumentert kjennskap til skybasert utvikling (som Amazon S3, Microsoft Azure, Google App Engine, Cloud Foundry etc).		2 %
Apache	Dokumenter erfaring med Apache.		2 %

Responsivt design	Dokumenter erfaring med “responsive design” og HTML5, CSS3.		2 %
LDAP	Dokumenter erfaring med LDAP.		2 %
Tomcat	Dokumenter erfaring med Tomcat.		2 %
jQuery	Dokumentert erfaring med jQuery.		2 %
Ember	Dokumentert erfaring med Ember.		2 %
Bootstrap	Dokumentert erfaring med Bootstrap.		2 %
Publiserings- system	Dokumenter erfaring med WordPress		1 %
JSON	Dokumenter erfaring med dataoverføring ved hjelp av JSON- standarden		1 %
AJAX	Dokumenter erfaring med AJAX.		1 %

8.3 Pris

8.3.1 Fastpris for utviklingsoppdraget

Alle de arbeider som er beskrevet i dette dokumentet skal foretas til fast pris. Prosjektet omfatter en lang rekke praktiske oppgaver som ikke er detaljert beskrevet. De er imidlertid tilstrekkelig godt opplyst til at en tilbyder med erfaring fra tilsvarende arbeid skal kunne gjøre seg opp en oppfatning av omfanget av oppdraget og tilby utførelsen av dette til fast pris.

Forbrukerrådet forbeholder seg retten til å forkaste tilbud som i for stor grad plasserer ansvaret for omfanget av arbeid som er ufullstendig beskrevet i dette dokumentet på Forbrukerrådet. Vi ønsker at tilbyder estimerer «gråsonene» basert på sin erfaring og inkluderer dette i et fastprisoppdrag.

I tilbudet skal det likevel oppgis en timepris for relevante grupper ansatte for det tilfellet at Forbrukerrådet ønsker å foreta tilleggsbestillinger.

8.3.2 Timepris for forvaltningsoppdraget (opsjon)

Også forvaltnings- og videreutviklingsoppdraget vil bli vurdert ut fra kompetanse og pris. Forbrukerrådet ønsker én felles timepris som skal speile den gjennomsnittlige prosentvise innsatsen fra ansatte med forskjellig kompetanse som leverandøren forplikter seg til i tilbudet.