Krav og ønsker til e-handelssystemer – set fra en indkøber-synsvinkel

1. Krav og ønsker til e-handelssystemer – set fra en indkøber-synsvinkel Marit Lund Ikast-Brande Kommune Oplæg på møde i IKA’s brancheopmærksomhedsgruppe vedr. e-handel d. 30. november 2010 Baseret på erfaringer fra KMD WebBestilling, samt en smule viden om andre systemer 2010

2. E-kataloger • Skal være enkelt for leverandørerne at uploade til systemet • Leverandøren skal kunne se hvordan e-kat. kommer til at se ud for brugerne • Skal automatisere og servere så meget som muligt for katalog-administratoren, f.eks.: • Antal nye, slettede og ændrede varer, både samlet indenfor hver af de 3 kategorier og opdelt på varegrupper indenfor hver af de 3 • Hvor mange har tilknyttet billeder • Hvor mange og hvilke varer mangler billeder (TrueLinks måde ikke fordel for brugere af andre systemer) • Ændrede ting fremhæves med gul markering • Prisændringer skal fremgå i procent og fremhæves med rødt for stigning og grønt for fald + kunne søges og sorteres • Skal vise gennemsnitlig prisændring, dels på ændrede varer, dels på alle varer i e-kataloget og på alle tilbudslistevarer 2010

3. E-kataloger – fortsat • Skal være muligt at søge, sortere og lægge katalogdata over i regneark, før der godkendes • Skal være muligt at afvise enkelt-varelinier, så kataloget kan godkendes pta. enkelte fejl • Skal kunne skrive kommentarer til leverandøren både overordnet og på varelinieniveau og både ved godkendelse og afvisning af katalog • Skal være muligt at have 2 mail-adresser lagt ind pr. katalog: 1 til bestillinger, 1 til mails vedr. kataloget • Skal være mellem-godkendelse, hvor administrator kan se e-kat. uden at der sendes godkendelsesmail til leverandøren, og uden at e-kat. kan ses af indkøberne • Billeder skal tilknyttes via link (ikke besværlig cd-rom-fremsendelse med følgende forsinkelse) • Link til datablade 2010

4. E-kataloger – fortsat • Tydelig angivelse af mindste bestillingsenhed og nettoindhold skal være obligatorisk • Pris pr. stk. skal regnes automatisk ud • Emneord / søgeord skal kunne ses af brugerne i det godkendte katalog • Skal være muligt at indlæse regneark m. hhv. tilbudsliste og øvrige varer, så systemet selv kan kontrollere om varenumre og priser passer i e-kataloget • Skal være god plads i alle felter, så leverandører kan lægge meget ind i f.eks. varenavn, emneord, varebeskrivelse • Skal være mulighed for flere forskellige e-kataloger (m. hver sit indhold og ”regler”) fra samme lev. uden at systemet opfatter det som forskellige lev. (f.eks. CVR-tjek) • Skal være nemt at vise hvilke varer der stammer fra udbuds-tilbudslisten 2010

5. E-kataloger – fortsat • Mulighed for gebyr (tillæg) ved ordrer under bestemt beløb og for fradrag hvis man køber over et bestemt antal • Pop-up med beløbsgrænse ved gebyrer • Samme lev.: 1 e-kat. m. gebyr, 1 e-kat u. gebyr: Skal kunne addere varelinier fra de 2 kataloger, før gebyr pålægges • Tydelig og gennemskuelig måde at angive at varer kan bestilles i anbrud • Skal være muligt at eksportere et godkendt e-katalog til en anden kommune med det samme e-handelssystem • MEN skal også være muligt at køre HELT uafhængigt af andre kommuner med samme system 2010

6. Søgning • Systemets hastighed er MEGET vigtig. Søgning og visning skal ske hurtigt • Skal være mulighed for flere forskellige slags søgning: Enkel søgning og avanceret søgning • Skal starte op i enkel søgning, men blive i avanceret søgning indtil logoff, hvis denne er valgt 1 gang, og ikke fravalgt igen • Èt søgefelt er IKKE nok • Èn bred søgning med søgning i alle felter er IKKE nok • Skal være mulighed for at vælge at søge: • Kun hos bestemt(e) leverandør(er) • Kun i varenumre • Kun i varenavne • Kun i emneord/søgeord • I alle felter på én gang 2010

7. Søgning – fortsat • Skal kunne ”trunkere” – enten (og helst) med automatisk højre- og venstre-trunkering eller med mulighed for at gøre det ved at sætte et tegn – f.eks. ? – så ”?cyk?” (eller ”cyk”) giver alt med de 3 bogstaver i på den måde, f.eks. ”legetøjscykelhjelm” • Skal i avanceret søgning være muligt at kombinere søgninger (med ”og”, ”eller”, ”ikke”) og at genbruge søgninger • F.eks. ved at alle søgninger i avanceret søgning får et nummer og en kort gengivelse af søgestrengen + bliver oplistet, hvorefter det er muligt at søge: ”s3 ikke jul”, når s3 var en søgning efter servietter, hvor resultatet blev alt for stort, og bl.a. indeholdt juleservietter, som man ikke var interesseret i 2010

8. Søgning – fortsat • Eller uden at kombinere søgninger, men f.eks. ved at man vælger at skrive i ”Alle felter” og skriver ”servietter og 3-lags ikke jul” – (”og”, ”eller” og ”ikke” er altid søgeværktøjer, ikke ord, man søger på, medmindre de skrives med stort (Og, Ikke, Eller)) • Hvis man skriver flere ord i et søgefelt, uden at skrive ”og”,”eller”,”ikke” i mellem ordene, skal det være underforstået at der står ”og” imellem dem. Ellers kommer der kun et resultat, hvis ordene står lige ved siden af hinanden i samme rækkefølge, og det duer IKKE • Mulighed for ”gennemse”-funktion, hvor man kan bladre ned igennem leverandørens varegrupper og undervaregrupper, hvis man ikke kan søge en vare frem vha. de ord man selv kan forestille sig • Skal være muligt at søge på miljømærker o.lign. mærker 2010

9. Visning • Gerne første-visning i 1-liniet format, så mange varer kan ses på én gang • Mulighed for at vælge mellem andre visningsformater, når man vil se flere oplysninger (administrator skal kunne definere visningsformater) • Mulighed for at markere de varelinier, man vil se i andet format • Lille thumbnail-billede i det 1-liniede format • Det lille thumbnail-billede skal være nemt at gøre stort, f.eks. ved at holde markøren på billedet • Hvis al tekst i et felt ikke er synligt, skal det kunne ses ved at holde markøren på feltet • Varer skal automatisk vises med den billigste først, medmindre andet vælges • De viste varelinier skal kunne sorteres efter alle mulige parametre: F.eks. varenr., varenavn, pris, stykpris 2010

10. Bestilling • Skal være nemt at sætte forskellige kontonumre på forskellige varelinier i samme ordre • Må ikke være nødvendigt selv at taste kontonr. hver gang • Skal være nemt at tilføje posteringstekst • Skal være nemt at skrive besked til leverandør (også selv om lev. får ordren som XML-fil direkte ind i sit system) • Skal være nemt at ændre til anden forud defineret leveringsadresse (leveringsadressen skal IKKE skrives manuelt af den enkelte indkøber) – gerne mulighed for at bruge institutions tlf.nr. til identifikation af leveringsadresse • Skal være nemt at navngive ordre • Varer i indkøbskurv skal blive liggende til de bliver sendt, også selvom der logges af • Skal være mulighed for ordrekladder 2010

11. Bestilling – fortsat • Skal være tydelig og gennemskuelig måde at bestille i anbrud på, hvis anbrud er aftalt med lev. • Skal være muligt for 1 indkøber at være tilnyttet til og købe ind for flere forskellige inst./afd. • Skal være muligt at bestille på CPR-nr., så faktuaen bliver automatisk bogført på CPR-nr. • Skal være muligt at dele betalingen af den enkelte varelinie op på flere kontonumre med en af indkøberen indtastet procent-fordeling 2010

12. Standardordrer • Skal være nemt at oprette og benytte standardordrer • Skal være nemt at redigere i standardordrer, både tilføje, slette, ændre varelinierækkefølge og standardordrenavn • Mulighed for at tilføje egne bemærkninger på varelinieniveau • Standardordrer skal kunne gives til andre, ekskl. kontonr. – både kopieres ml. 2 indkøbere, og skubbes ud til få/ mange/alle fra administrators side • Skal være mulighed for fælles standardordrer i afdelingen • Priser i standardordrer skal opdateres automatisk ved nyt e-katalog • Lev. skal kunne angive erstatningsvarenumre, som skal godkendes først af administrator ved katalogupload, derefter af enkelt standardordreindehaver – dog kun godkendes af administrator på std.ordre-niveau på administrator-udskubbede standardordrer • Slettede varenumre og erstatningsvarenumre skal være nemme at opdatere i standardordrer, men IKKE automatisk 2010

13. Standardordrer – fortsat • Slettet varenr. og erstatningsvarenr. skal sættes op over for hinanden, så de kan sammenlignes, før accept af udskiftning. Slettede varenr. uden accepteret erstatningsvarenr. skal kunne udskrives, så indkøber selv kan finde og tilføje erstatninger – eller det skal laves, så manglende accept af eller manglende forslag til leverandør-erstatningsvarenr. medfører mulighed for umiddelbart selv at søge efter erstatning til standardordren • Skal kunne tilføje fra flere standardordrer til indkøbskurv – uden at der overskrives • Skal være mulighed for at overskrive eksisterende indhold i indkøbskurven, hvis det ønskes • Standardordre-indhold skal kunne sorteres på alle mulige termer: f.eks. varenr., varenavn, varegruppe, pris • Skal kunne have mange forskellige standardordrer, og kunne gruppere dem som ønsket 2010

14. Ordresøgning • Skal indeholde både default-søgning og mulighed for forskellige søgeparametre • Default-søgning kan f.eks. være på alle afdelingens ordrer inden for den sidste måned • De valgbare søgeparametre kan f.eks. være: Bestillerens navn, oprettelsesdato, leverandørnavn, ordrestatus (sendt, delvis varemodtaget, varemodtaget, faktura modtaget, automatisk bogført, til manuel bogføring, manuelt bogført, osv.), ordrenavn, ordrenummer, bestillende afdeling, alle leverandører og alle institutioner/afdelinger (den sidste kun for superbrugere og administrator) • Det skal være nemt at søge ordrer frem, som ikke er varemodtaget • Det skal være nemt at søge ordrer frem, hvor der ikke er modtaget nogen faktura 2010

15. Ordresøgning – fortsat • Det skal være nemt at søge ordrer frem, hvor der er modtaget faktura, men ikke varemodtaget • Det skal være nemt at søge ordrer frem, hvor der ikke har kunnet automatisk bogføres, selvom alt er varemodtaget • Det skal være nemt at søge ordrer frem, hvor der er sket automatisk bogføring • Kunne ønske oversigt med symboler for om der er modtaget faktura, hvor længe der er til fakturaen skal betales + rød markering, hvis betalingsfristen er overskredet 2010

16. Varemodtagelse • Skal være mulighed for både ”Delvis varemodtagelse” og ”Varemodtag alt” • Skal være mulighed for automatisk bogføring, hvis delvist varemodtaget og modtaget tilsvarende ”delvis” faktura • Delvis varemodtagelse skal være nem, også hvis kun 1 ud af 20 varelinier mangler at blive leveret • God ide med mulighed for at vinge af i ”sidste levering”, hvis leverandøren oplyser at en varelinie eller et antal af varer på varelinien aldrig kommer til at kunne leveres • Vigtigt at man kan varemodtage ting, som andre i afdelingen har bestilt 2010

17. Automatisk bogføring • Automatisk bogføring er alfa og omega i et e-handelssystem • Kriterier for aut. bogf. skal være væsentlige, ikke overdrevne • Kriterier for aut. bogf. skal være fleksible, så administrator kan fravælge konkrete kriterier, samt justere præcisionen af dem – f.eks. om prisen skal passe helt præcist eller om den må afvige med f.eks. 5 øre, så afrunding er mulig. Administrator skal kunne indtaste hvilken præcision, der ønskes • Er vant til flere kriterier for aut. bogf. end i mange andre e-handelssystemer – det giver os problemer med at få aut. bogf. 2010

18. Rolleopsætning • Systemet skal indeholde flere mulige roller: • Administrator, som skal kunne alt – det skal være muligt at have mere end 1 administrator, så der er ”backup” • E-katalog-administrator – der skal også kunne være flere • Superbrugere, som skal kunne en del administrative ting, men hvor det er administrator, som skal kunne definere, hvad de skal kunne. Gerne med mulighed for at have superbrugere på 2 forskellige niveauer • Indkøbere, som skal kunne søge, bestille og varemodtage + slå op i aftalekatalog • Brugere med søgeadgang i e-kataloger og adgang til opslag i aftaler, men uden adgang til at bestille og varemodtage 2010

19. Fleksibilitet i hele opsætningen • Systemet skal være fleksibelt hele vejen igennem, så administrator kan vælge hvordan det hele skal sættes op, f.eks.: • Hvad de forskellige roller skal kunne - især hvad superbrugerne skal kunne • Automatisk bogførings-parametre og helt konkret afrunding mm. ned på hver enkelt lev. – dog skal det ikke være muligt at fravælge pris som parameter • Om der skal være 1 eller flere e-kat. fra samme lev. • Om det skal være tilladt at der er gebyr v. små ordrer i nogle e-kat., men ikke i andre e-kat. fra samme leverandør • Fritekstordre/tast-selv-ordre eller ej – SKAL kunne fjernes, så man kan styre hos hvilke lev. indkøberne køber hvilke varer • Mulighed for at definere forskellige visningsformater og definere hvilke felter der skal med i de forskellige formater + gerne hvor de skal stå på skærmbilledet, og hvor meget de må fylde • Den enkelte bruger skal have mulighed for at lave egen standardopsætning – vil man altid starte i enkel eller i avanceret søgning, vil man altid starte med at få vist et 1-liniet visningsformat eller et andet visningsformat • Mulighed for automatisk udsendelse af rykkere til indkøbere der ikke har varemodtaget X antal dage efter fakturamodtagelse 2010

20. Fleksibilitet – fortsat • Fleksibiliteten skal være på et niveau, hvor man dels kan køre med fælles regler for alle e-kataloger/leverandører, dels kan vælge specielle regler for enkelte e-kataloger eller leverandører (f.eks. mht. parametre for automatisk bogføring, forskellige regler for indlæsning af e-kat., osv.) • Fleksibiliteten SKAL være en mulighed, men systemet skal leveres med en ”grundopsætning”, så kommuner/administratorer, der ikke ønsker at sætte eget præg, har mulighed for at bruge det alligevel 2010

21. Statistik og rapporter • Skal være mulighed for at trække data ud på både leverandører, institutioner/afdelinger, ordrer og varenumre, både alene og i kombination og både generelt og for enkelte leverandører eller enkelte inst./afd. – for valgfri perioder, som vi kan taste som vi vil, f.eks: • Hvor mange og hvor store ordrer + gennemsnitsordrestr.+ samlet ordrebeløb til lev. (enkelte lev. og alle lev.) + muligt at koble inst./afd. på, så man kan se hvor mange og hvor store ordrer den enkelte inst. har sendt til lev. • Hvem har sendt/fået flest ordrer og hvem har slet ingen sendt/fået • Hvem sender/får de største/mindste gennemsnitsordrer • Hvilke inst./afd. har ikke e-handlet i en bestemt periode • Hvilke inst./afd. har ikke varemodtaget • Hvilke ordrer er ikke blevet varemodtaget X antal dage efter ordreafsendelse og/eller efter fakturamodtagelse 2010

22. Statistik og rapporter – fortsat • Hvilke ordrer er ikke koblet sammen med en faktura X antal dage efter ordreafsendelse • Hvor mange ordrer på under/over X kr. er blevet afgivet til enkelte lev. og leverandører i alt • Hvor mange ordrer til konkret lev. ligger i intervallet 0-100 kr, 101-200 kr., osv. – med mulighed for at koble på hvilke inst./afd. der har afgivet ordrerne • Hvor mange og hvilke ordrer er blevet automatisk bogført • Hvor mange og hvilke ordrer er sendt til manuel bogføring • Statistik over køb af enkelte varenr. skal være opsummeret – det samme varenr. skal ikke optræde i stat. hver gang det optræder i en ordre – listet i varenr.-orden med mulighed for forskellige sorteringer, f.eks. indenfor leverandørens varegrupper, efter pris, osv. • Alle statistikker skal kunne sorteres indenfor de enkelte parametre/overskrifter og skal kunne lægges over i regneark til videre behandling 2010

23. Statistik og rapporter – fortsat • Gerne mulighed for at vælge flere leverandører sammen til én statistik (dvs. ikke kun ”alle” eller 1 bestemt leverandør) • Skal være muligt at lave stat. både for enkelt e-katalog og for alle e-kataloger fra en bestemt leverandør • Statistik over hvor mange rykker-mails der er sendt pga. manglende varemodtagelse – opdelt på superbrugere, på afd./inst. og på indkøbere • Ønsker statistik med oprindeligt afsendte ordrer (ikke kun dem der stadig har status ”sendt”), hvor man kan se hvilke heraf, der er modtaget mindst 1 faktura til, der er varemodtaget, der er delvist varemodtaget, der er annulleret, der er automatisk bogført, der er sendt til manuel bogføring, osv. Alle skal være klikbare med mulighed for at se hvilke ordrer (og til og fra hvem) og klikke videre ind i de pågældende ordrer • Skal for hvert enkelt e-kat. kunne trække liste over varenr., der mangler billede 2010

24. Diverse • Der skal være genvejs-taster/-kommandoer – det må ikke være nødvendigt at klikke meget rundt med musen • Vigtigt at systemet altid skriver hvem der gør hvad • Vigtigt at man selv har mulighed for at skrive kommentarer på den enkelte ordre • Vigtigt at systemet skriver forklaringer på hvorfor, hvis der f.eks. ikke kan bogføres automatisk • Vigtigt at systemet skriver hvornår systemet selv gør hvilke ting (f.eks. hvornår fakturaen modtages, hvornår der bogføres automatisk, osv.) • Vigtigt ved systemskift at det nye system kan importere e-kataloger, brugere inkl. deres roller, afd./inst., osv. fra eksisterende e-handelssystem – må IKKE være nødvendigt at starte helt forfra 2010

25. Diverse – fortsat • Vigtigt at der er sammenhæng mellem e-handelssystemet og aftalestyring, aftaleopslag. Aftaleoversigt skal være en del af e-handelssystemet uanset om der er e-katalog fra leverandøren eller ej • Administrator skal automatisk kunne sende mail til alle oprettede indkøbere i hhv. en inst./afd., en hel forvaltning eller til alle indkøbere på 1 gang • Når administrator opretter de enkelte afd./inst. i systemet, skal det være muligt at kopiere opsætning mm. fra andre lignende afd./inst. • Når administrator skal rette i oplysninger/opsætning på afd./inst., roller mm., skal det være muligt at rette i alle på samme tid eller kun i enkelte, alt efter situationen • Der skal være et undervisnings-modul i systemet, hvor kursister kan lave bestillinger helt færdige uden at de reelt bliver sendt ud i verden, men som ellers fungerer helt normalt og gerne bruger de almindelige e-kataloger. Kan de alm. e-kataloger ikke bruges, skal der eksistere et bredt øvelseskatalog, som kan bruges til kurser 2010

26. Manualer • Vigtigt med grundig dokumentation og detaljeret manual til administrator • Gerne vejledning beregnet til indkøbere, men den skal være nem at tilpasse til kommunens måde at bruge systemet på 2010