Infrastruktur for elektronisk handel

Transkript

1 Infrastruktur for elektronisk handel Prosjekt i regi av Norsk EDIPRO Oppsummering av intervjuene i kartleggingsfasen Versjon september 2000 Norsk EDIPRO Tel Postboks 2526 Solli Fax Oslo Internett:

2 Innholdsfortegnelse 1 BAKRUNN JENNOMFØRIN AV INTERVJUUNDERSØKELSEN FORM PÅ INTERVJUENE UTVAL AV INTERVJUOBJEKTER I HVILKEN RAD ER SVARENE REPRESENTATIVE? HOVEDKONKLUSJONER OPPSUMMERIN AV DE ENKELTE SPØRSMÅLENE DAENS LØSNINER, PLANER O PÅÅENDE PROSJEKTER FOR E-HANDEL Har bedriften operative løsninger for e-handel i dag, eller har man pågående prosjekter/planer om å etablere slike løsninger (1)? Hva legger man i begrepene Portal og Markedsplass (2)? I den grad man har EDI-løsninger, benytter bedriften egen EDI-tjeneste eller bruker man en Formidlingssentral (3)? KRAV TIL FELLES INFRASTRUKTUR FOR E-HANDEL Hvordan vil du beskrive/karakterisere en felles infrastruktur for e-handel (5)? Hvilke elementer bør inngå i beskrivelsen av en felles infrastruktur (hva er viktigst), og vil noe av dette være bransjeavhengige (6)? FORRETNINSPROSESSER Er det mulig eller ønskelig å standardisere måten en forretningsprosess utføres på (eventuelt avhengig av bransje) og hvilke forretningsprosesser bør i så fall inngå i beskrivelsen av en felles infrastruktur (hva er viktigst) (7)? Hvordan kan forretningsprosessene beskrives (8)? Bør det stilles spesielle krav til bruk av identifikasjonsbegreper (f.eks. at bruk av gitte identifikasjonsbegreper er påkrevet i enkelte forretningsprosesser) (9)? DATAFORMATER O SEMANTISKE PROBLEMSTILLINER Bør man i en felles infrastruktur for e-handel sette begrensninger med hensyn til hvilke dataformater (syntaks) som skal støttes, i tilfelle hvilke (10)? Er det mulig å spesifisere et begrenset sett av syntaksnøytrale semantiske beskrivelser av datainnhold i meldinger som (nesten) alle kan tilpasse seg (11)? KOMMUNIKASJONSTEKNOLOIER Bør man i en felles infrastruktur for e-handel sette begrensninger med hensyn til hvilke aksess/nettverksløsninger eller meldingstransporttjenester som skal tillates (12)? SIKKERHET Hvilke funksjonelle sikkerhetstjenester bør inngå i en felles infrastruktur for e-handel (13)? Bør man i en felles infrastruktur for e-handel sette begrensninger med hensyn til hvilke kryptografiske algoritmer, sertifikatformater eller tekniske sikkerhetselementer som skal tillates (14)? TREDJEPARTSTJENESTER (FORMIDLINS- O TRANSLATØRTJENESTER) Hvilke tjenester bør være tilgjengelig fra en tredjepart, og hvilke av disse er aktuelle for egen bedrift (15)? Hvilket ansvar skal tillegges en eventuell 3-part (f.eks. verifikasjon av sertifikater) (16)? PROBLEMSTILLINER SOM MÅ UTREDES/LØSES Er det spesielle problemstillinger som må utredes/løses før en felles infrastruktur for e-handel kan realiseres (17)? BRUK AV INFRASTRUKTUREN Hva skal til for at din bedrift skal gjøre bruk av en felles infrastruktur (18)? Hva skal til for at din bedrift skal kunne ha tiltro til at en annen virksomhet faktisk holder seg til beskrivelsen av infrastrukturen (19)? INTERNASJONALE INITIATIV O STANDARDISERINSAKTIVITETER Hvilke internasjonale initiativ og standardiseringsaktiviteter bør legges til grunn ved spesifikasjon av en felles infrastruktur for e-handel (20)?

3 1 Bakgrunn Denne rapporten er en delrapport fra kartleggingsfasen i prosjektet infrastruktur for elektronisk handel. Hensikten med rapporten er å gi en oppsummering av den intervjuundersøkelsen som er gjennomført for å få frem prosjektdeltakernes syn på hva en infrastruktur for elektronisk handel skal omfatte. Hovedkonklusjonene fra kartleggingen ble presentert og debattert i en workshop for alle prosjektets deltakere. Oppsummeringen fra denne workshoppen er gitt i en egen delrapport. Denne delrapporten er utarbeidet av Bjørn Aasheim, Norsk EDIPRO, og Jostein Frømyr, EdiSys AS. 2

4 2 jennomføring av intervjuundersøkelsen Som grunnlag for de enkelte intervjuene ble det utarbeidet et omfattende intervjuskjema. Dette ble distribuert til intervju objektene før intervjuene ble gjennomført. Intervjuobjektene hadde dermed muligheten til å forberede seg på de spørsmålene som ble reist. Hvert intervju ble gjennomført innenfor en tidsramme på ca. 2 timer. Intervjuundersøkelsen ble gjennomført i to puljer: Pulje 1 omfattet et mindre antall intervjuer som ble gjennomført i perioden 9 12 mai. Hensikten med disse intervjuene var bl.a å høste erfaring med de spørsmålsstillinger som var utarbeidet. Intervjuene i denne puljen ble gjennomført av minimum to personer. Følgende virksomheter ble intervjuet i denne puljen: EDB Fundator AS Viken Energinett Borregård Bankenes BetalingsSentral På grunnlag av erfaringene fra disse intervjuene ble intervjuskjemaet revidert og forenklet. Pulje 2 omfattet hovedtyngden av intervjuene og ble gjennomført i tiden 19 mai 15 juni. I denne puljen ble intervjuene gjennomført av en enkelt intervjuer. 2.1 Form på intervjuene I utarbeidelsen av intervjuskjemaet ble det ikke lagt opp til ja/nei-spørsmål, men i stedet et sett med åpne spørsmål som kunne være utgangspunkt for en dialog mellom intervjuer og intervjuobjektet. Spørsmålene ble forsøkt utformet slik at de skulle få frem en helhetlig tankerekke hos intervjuobjektet. Også i gjennomføringen av intervjuene har det vært lagt vekt på å skape en åpenhet slik at intervjuobjektene kunne får frem flest mulig av sine synspunkter, også der hvor dette har gått ut over de forhåndsdefinerte spørsmålene. Den teknikken som er valgt både i utforming av intervjuskjemaet og i selve gjennomføring av intervjuene medfører en klar fare for at: 1. Det er ulik tolkning av spørsmålene og at det derved kan være forskjeller med hensyn til hva som kommer frem under de enkelte intervjuene 2. Intervjuer i for stor grad styrer intervjuet (diskusjonen) i en gitt retning Punkt 1 over er forsøkt motvirket ved at det ble brukt relativt mye tid på å bearbeide spørsmålene og skape felles oppfatning mellom intervjuerne før pulje 2 av intervjuene ble gjennomført. Det skal imidlertid ikke underslås at den intervjuformen som er valgt gir stort rom for tolkning og påvirkning. 2.2 Utvalg av intervjuobjekter I kartleggingsfasen er det gjennomført i alt 20 intervjuer med et bredt utvalg av bedrifter. Med et så begrenset utvalg intervjuobjekter vil det alltid kunne reises spørsmål om utvalget er representativt og følgelig om konklusjonene gir et representativt blide av markedet. Det er vår oppfatning at med de begrensede resurser prosjektet har hatt til rådighet ville det vært umulig å gjennomføre et vesentlig større antall intervjuer. Det er også prosjektets oppfatning at de utvalgte virksomhetene gir et akseptabelt tverrsnitt av 3

5 Tabell 1: Antall intervjuobjekter per bransje og bedriftsstørrelse. Størrelse Antall Bransje Stor SMB* virksomheter Bank/finans/forsikring Transport Elektro Møbel Bygg Varehandel (eks dagligvare) Dagligvare El-kraft Olje Offentlig (eks helse) Helse Leverandører av IT tjenester Totalt * SMB = virksomheter med mindre enn 50 ansatte markedet og sådan gir grunnlag for å trekke generelle konklusjoner på de problemstillinger som er reist. Med hensyn til hvilke bransjer som er representert er det, som det fremgår av tabell 1, relativt stor spredning blant intervjuobjektene. I forhold til bedriftsstørrelse er det en kraftig underrepresentasjon av SMB (bedrifter med mindre enn 50 ansatte) i forhold til det norske markedet generelt. Når det gjelder offentlig virksomhet og helse er det verdt å peke på at intervjuene ikke er gjennomført med konkrete offentlige virksomheter, men er representert gjennom program for elektronisk handel i det offentlige i regi av Arbeids- og administrasjonsdepartementet og prosjektet elektronisk handel i helsesektoren. De virksomhetene som er intervjuet har i ca halvpartene av intervjuene vært representert av kun en person. Kun i et fåtall intervjuer har det vært mer enn to personer tilstede fra intervjuobjektene. De personer som er intervjuet har i utgangspunktet kommet frem gjennom Norsk EDIPRO s kontakter og henvisninger fra bransjeorganisasjonene, samt interne henvisninger i den enkelte virksomhet. Det har vært en relativ god spredning mellom IT-folk og brukere blant intervjuobjektene, ca 50/50. I hvilken grad de personene som er intervjuet har gitt uttrykk for oppfatninger som er representative for de virksomhet de representerer får stå for intervjuobjektenes egen regning. 2.3 I hvilken grad er svarene representative? Det synes å være en klar tendens i intervjuene at intervjuobjektenes svar er preget av dagens situasjon og løsninger samt av strategi i egen virksomhet. Det synest også å være en klar tendens blant intervjuobjektene at man fremhever svakhetene i dagens løsninger og søker alternativer som kan kompensere for disse svakhetene, samtidig som man i stor grad er lojal mot virksomhetens strategi fremover. Den måten kartleggingen er gjennomført på sammen med et relativt begrenset utvalg intervjuobjekter gjør at man ikke har en vitenskapelig dekning for å trekke bastante konklusjoner som man kan hevde er statistisk representative for markedet generelt. jennom kartleggingen har man likevel fått frem en del klare signaler om hva som oppfattes som de vesentlige elementene i en åpen infrastruktur for elektronisk handel. 5

6 3 Hovedkonklusjoner Den måten intervjuene er gjennomført på sammen med et relativt begrenset utvalg intervjuobjekter gjør at man ikke har en vitenskapelig dekning for å trekke bastante konklusjoner som man kan hevde er statistisk representative for markedet generelt. jennom intervjuene har man likevel fått frem den del klare signaler om hva som oppfattes som de vesentlige elementene i en infrastruktur for elektronisk handel. Det er ingen klar og entydig oppfatning i markedet for av hva en åpen infrastruktur for elektronisk handel skal være. Det er likevell en generell enighet om at den må inneholde elementer av Teknologi; i form av maskinvare, fremføringsnett (dvs Internett), kommunikasjonsprotokoller og løsninger, sikkerhetsløsninger og dataformater Datainnhold; i form av meldingsdefinisjoner (fortrinnsvis en syntaksnøytral beskrivelse av datainnholdet en melding) Tjenestetilbydere; i form av markedsplasser, portaler, formidlingssentraler, TTPer, ol Funksjonalitet; i form av definerte forretningsprosesser På et helt overordnet nivå er det en relativt entydig konklusjon om at en fremtidig åpen infrastruktur for elektronisk handel må fokusere på datainnhold og funksjonalitet, ikke teknologi. Valg av teknologi må i større grad overlates til markedet. Dette gir nok like mye uttrykk for hva man opplever som problemene i dagens løsninger og er ikke nødvendigvis en undervurdering av problemene forbundet med bruk og etablering av tekniske løsninger. Når det gjelder datainnhold og funksjonalitet er det også klart at en eventuell standardisering må drives fram av den enkelte bransje og at vi i alle fall på kort sikt må akseptere et mangfold, det vil si variasjoner i måten forretningsprosessene utføres på. På grunnlag av intervjuundersøkelsen kan man trekke ut følgende overordnede krav til en fremtidig åpen infrastruktur for elektronisk handel: Infrastrukturen må tilrettelegge for et mangfold i tekniske løsninger type løsning: EDI, elektronisk skjema, markedsplasser, etc fremføringsnett og kommunikasjonsprotokoller syntaks og dataformater sikkerhetsløsninger Åpen og tilgjengelig for alle aktører med et minimum av forhåndsavtaler. Tilrettelegge for aktiv bruk av tjenesteytere (tredjeparter). Sikre en entydig og presis definisjon av de data som utveksles. Skape trygghet for de underliggende forretningstransaksjonene. Utfordringen med å etablere en fremtidig åpen infrastruktur for elektronisk handel blir da å skape system og struktur blant de løsninger som etableres i markedet og å gjøre informasjonene om de ulike løsningene åpent tilgjengelig, samt at det må defineres et minimumssett av felles kjøreregler. 6

7 4 Oppsummering av de enkelte spørsmålene 4.1 Dagens løsninger, planer og pågående prosjekter for e-handel Har bedriften operative løsninger for e-handel i dag, eller har man pågående prosjekter/planer om å etablere slike løsninger (1)? Flesteparten av bedriftene i intervjuundersøkelsen har en eller annen form for e- handelsløsning, eller planer om å innføre en slik løsning i overskuelig framtid. Det er derfor grunn til å anta at de alle har erfaring og kompetanse innenfor elektronisk handel Eksisterende løsninger Dagens løsninger dreier seg hovedsakelig om tradisjonelle EDI-løsninger basert på EDIFACT, med vekt på ordrebehandling (bestilling/ordrebekreftelse) og betaling, og i mindre grad fakturering. Det synest å være en økende interesse for bruk av elektronisk varekatalog, fortrinnsvis via en Internett- portal (driftet av tredjepart). Flere bedrifter har tatt i bruk web-skjema eller har planer om dette, evt. i kombinasjon med EDIFACT. Nettbank oftest nevnt i forbindelse med web-skjema. Tredjepartsløsninger ut over vanlig formidlingssentral (f.eks. portaler/ markedsplasser) er i dag lite utbredt, men vurderes seriøst av flere bedrifter. Innenfor transportbransjen benyttes EDI i hovedsak i forbindelse med fortolling (TVINN) samt tradisjonelle EDIFACT-meldinger i forbindelse med fraktoppdrag (manifest, booking, bestilling/bekreftelse, status, fraktfaktura, etc.). Tradisjonelle handelsmeldinger på andre områder enn frakt synes å være fraværende innenfor transportbransjen. En transportbedrift tilbyr EDI mot varelager (inngang/uttak, rapportering av beholdning). Konklusjoner: Hovedtyngden av dagens løsninger for elektronisk handel dreier seg om tradisjonelle EDI-løsninger basert på EDIFACT eller web-skjema (med vekt på førstnevnte) De fleste løsningene er knyttet til områdene ordre, fakturering, betaling, transport, fortolling Pågående planer/prosjekter Enkelte bedrifter har planer om å innføre XML, men ingen har operative løsninger for dette i dag. Internett tillegges stor betydning, men de fleste er lite konkrete på innhold/tjenester ut over bruk av Internett som en kommunikasjonskanal. Enkelte ser for seg å foreta innkjøp over Internett, men uten å konkretisere hvordan dette skal foregå i praksis, ut over at det må skje en integrasjon mot ERP-systemer og eventuelt gjøre disse tilgjengelig via web. Innen forsikring ser man for seg ulike typer innrapporteringer av f.eks. premieutbetalinger mot ligningsvesenet, etc. på proprietært format. Tredjepartsløsninger (portaler/markedsplasser) nevnes også i forbindelse med Internett. 7

8 Innen transportsektoren nevnes særlig track-and-trace -løsninger og strekkodemerking av gods som et viktig satsningsområde. Også drifting av lagerhotell (tredjepartslogistikk) ses på som et viktig satsingsområde. Konklusjoner: Relativt stort fokus på videreutvikling av eksisterende EDIFACT-løsninger for å nå flere handelspartnere. Relativt stort fokus på utvikling av Internett og web-baserte løsninger (proprietære formater) integrert med egne ERP-systemer og ofte i kombinasjon med etablere EDIFACT-løsninger innefor definerte funksjonsområder. Funksjonsområder som trekkes frem er: Innrapporteringer ordreinngang betalingsløsninger (telebank/nettbank) utvikling av standard blanketter/skjema på web Etablering av portaler/markedsplasser er et tema i tiden Track-and-trace, basert på strekkodemerking av gods, er et klart satsningsområde innenfor transportsektoren Hva legger man i begrepene Portal og Markedsplass (2)? Det var ikke mulig å komme fram til en klar definisjon av begrepene portal og markedsplass eller forskjellen på dem blant de intervjuede bedriftene. Noen svarer vet ikke, mens andre benytter begrepene mer eller mindre om hverandre. Det hersker også uklarhet om hvem som egentlig står bak de ulike stedene som portaler og markedsplasser representerer, hva slags forhold (ansvar, etc.) de har i forhold til brukerne og hvilke tjenester de tilbyr. En nærmere gjennomgang av svarene tyder likevel på at en markedsplass oppfattes til å tilby mer funksjonalitet enn en portal. I det ligger også at markedsplasser anses som mer dynamiske enn portaler. Nedenfor følger en oppsummering av synspunkter/uttalelser innenfor de to kategoriene: Portal Brukes i B2B-markedet om løsninger som driftes av en tredjepart i forbindelse med gjennomføring av handelstransaksjoner i faste kundeforhold mellom bedrifter (ISAL har f.eks. Internettportal som ivaretar kjøp innenfor byggebransjen) Samme som markedsplass. Distribusjons- og markedsføringskanal. Internett-vinkling til markedsplassen (startside på Internett) Inngangsport (samling URLer) til andre tjenester. Et samlingssted, et naturlig sted å finne info. Tjenestetilbyder på Internett (f.eks. SOL). Hjemmeside på Internett. Statisk 8

9 Markedsplass Kan også være B2B, men hovedsakelig i forbindelse med engangskjøp (jf. børs, trading center ) samt utlegging av informasjon om bedriften, også mot forbrukere. Ikke faste kundeforhold. Samarbeid om f.eks. innkjøp, hvor leverandørene legger ut åpen informasjon eller informasjon til en begrenset interessegruppe. Må inneholde distribuerte varekataloger og en sentral meta varekatalog. Sted der kjøper og selger møtes, inklusive tekniske løsninger. Noe snevrere enn en portal: en bedrift med partnere for kjøp/salg, varekataloger, etc. Produktorientert (mer enn en portal). Benyttes også for å legge ut informasjon om bedriften på Internett. Dynamisk Konklusjoner: Det er uklare og til dels sprikende oppfatninger av hva som ligger i begrepene. Noen funksjoner peker seg ut, f.eks.: Sted hvor likeverdige partnere møtes for å utveksle informasjon, gjennomføre transaksjoner eller trade (børsfunksjon). Løsningstilbyder i faste forretningsforhold Tjenestetilbyder på Internett (f.eks. SOL) Sted hvor bedriften kan legge ut informasjon (tjenestetilbud, nyheter, etc.) om seg selv Markedsplasser oppfattes generelt som mer dynamiske og tilbyr større grad av funksjonalitet enn portaler. Markedet for portaler og markedsplasser synest å ære et umodent marked hvor aktørenes roller og ansvar er uklart definert I den grad man har EDI-løsninger, benytter bedriften egen EDI- tjeneste eller bruker man en Formidlingssentral (3)? Bruk av formidlingssentral (FMS) er relativt utbredt, særlig blant mindre bedrifter som har etablert EDI-løsninger. Blant større bedrifter er bildet mer variert. Her benyttes dels egen EDI-konverter eller FMS avhengig av partner. Markedet for FMS-tjenester er jevnt økende. Økende utbredelse av FMS, også blant større bedrifter. 9

10 4.2 Krav til felles infrastruktur for e-handel Hvordan vil du beskrive/karakterisere en felles infrastruktur for e- handel (5)? Hovedpunkter som trekkes frem i beskrivelsen av en felles infrastruktur for elektronisk handel er: Bidra til problemfri gjennomføring (teknisk og funksjonelt) av forretningsprosessene. Må inneholde både tekniske og organisatoriske elementer. Kun datatekniske løsninger er ikke tilstrekkelig. Semantisk beskrivelse og prosessering av data. Dette griper inn i forretningsprosessene, dvs. at deler av forretningsprosessene også må defineres. Fokus på meldingsinnhold samt hvilke meldinger som skal brukes. Definere funksjonalitet i grensesnittene. Standardiserte maler og formater for informasjonsutveksling Må gi muligheter for å kommunisere elektronisk for å redusere transaksjonskostnader og tid samt feil, enten via portaler/markedsplasser eller direkte med handelspartner. Sikre kontinuitet i informasjonen langs hele verdikjeden samt gjøre denne informasjonen tilgjengelig for kunden (f.eks. forsendelsesmåte, leveringsbekreftelser, avviksmeldinger, etc.) Internett vil spille en sentral rolle i infrastrukturen. Muliggjøre track-and-trace -løsninger ved synkronisering av informasjonsflyt og fysisk vareflyt (strekkoder kritisk og nødvendig for å få til e-handel). Tilby alle typer tjenester som ikke er forretningskritiske (dvs. som ikke er en del av kjernevirksomheten). Regelsett som beskriver hvordan meldinger skal håndteres og som inneholder felles elementer som kan brukes for alle typer utvekslinger. Må være enkelt og fleksibelt. Må være enkelt, fleksibelt og føre til laverer kostnader, mindre tidsforbruk og færre feil. De viktigste elementer som trekkes frem er: Internett Forretningsprosesser Datainnhold (må bl.a. inneholde semantiske beskrivelse for å sikre felles tolkning av data) Sikkerhet Formidling, tolking, overvåking Samtrafikk De som hadde jobbet med EDI og integrasjon i lengre tid framhevet særlig forretningsprosessene og tilpasningen av disse til handelspartnerne som viktig i en felles infrastruktur. I det offentlige anser man infrastrukturen å være identisk med offentlig markedsplass slik den er definert i forbindelse med Program for elektronisk handel i det offentlige, dvs. et sett med tjenester, avtaler, bistand som kobler sammen aktørenes internsystemer mot et felles grensesnitt. Markedsplassen er beskrevet i form av et rollekart som omfatter kjøpere, selgere og tredjeparter tilknyttet markedsplassen. Alle transaksjoner skjer internt på markedsplassen, med tilgang via et web-grensesnitt. 10

11 Det er ingen klar og entydig oppfatning i markedet for av hva en infrastruktur for elektronisk handel skal være, men den må inneholde elementer av teknologi (maskinvare, protokoller, etc.) meldingsdefinisjoner kataloger (produkt-/varekatalog, etc.) funksjonalitet (forretningsprosesser, etc.) tjenestetilbydere (TTPer, markedsplasser, etc.) Internett (er infrastrukturen?) Hvilke elementer bør inngå i beskrivelsen av en felles infrastruktur (hva er viktigst), og vil noe av dette være bransjeavhengige (6)? Følgende elementer var listet opp i tilknytning til dette spørsmålet: Forretningsprosesser Syntaksnøytal beskrivelse av datainnhold i meldinger Dataformater/syntaks Kommunikasjonsteknologi Sikkerhet, inkl. TTP-tjenester Tredjepartstjenester (Formidling- og translatørtjenester) Alle elementene som var listet opp i forbindelse med spørsmålet ble trukket fram som viktige, med særlig vekt på: Forretningsprosesser Datainnhold (syntaksnøytral beskrivelse av datainnhold i meldinger). Kommunikasjon Sikkerhet enerell enighet om at minimum ovennevnte elementer må inngå i en felles infrastruktur. 11

12 4.3 Forretningsprosesser Er det mulig eller ønskelig å standardisere måten en forretningsprosess utføres på (eventuelt avhengig av bransje) og hvilke forretningsprosesser bør i så fall inngå i beskrivelsen av en felles infrastruktur (hva er viktigst) (7)? Det synest å være generell enighet om at det er mulig og ønskelig å standardisere måten en forretningsprosess gjennomføres på tvers av bransjer, men det reises tvil om det også er praktisk gjennomførbart (markedet vil etablere egne, proprietære løsninger). Variasjoner vil forekomme både innen bransjer og fra bedrift til bedrift, men avhenger av hvilken type prosess det er snakk om. Variasjoner må man leve med, men deler av prosessen vil uansett kunne standardiseres. Det skal bemerkes at en bedrift påpekte at en av grunnene til den relativt store utbredelsen av betalingsløsninger er at betalingsprosessen i stor grad er standardisert på tvers av bransjer og sektorer, og at dette har vært en forutsetning for å få opp volumet. Volum betinger at forretningsprosessene kan utføres på en ensartet måte. Visse forretningsprosesser, særlig fakturering/betaling, ordrebehandling, bestilling av transport anses som viktigere enn andre med hensyn til om de bør inngå i infrastrukturen eller ikke, men det ble påpekt at flere forretningsprosesser øker kompleksiteten. Mange av de intervjuede bedriftene unnlot å svare direkte på dette spørsmålet, noe som tyder på at det hersker stor usikkerhet på dette området. De fleste syntes likevel å være enige om at det er viktig å få til en standardisering. Standardiseringen må imidlertid drives av den enkelte bransje og det må vurderes hvilket nivå man skal legge seg på nivå. Det er både mulig og ønskelig å standardisere måten forretningsprosessene gjennomføres på, men kan være vanskelig å gjennomføre på kort sikt. På lang sikt vil en standardisering tvinge seg fram. Forretningsprosessene er (trolig) til en viss grad bransjeavhengige, men deler av prosessene vil uansett kunne standardiseres. Standardiseringen må drives fram av den enkelte bransje Hvordan kan forretningsprosessene beskrives (8)? Hovedpunktene som trekkes frem for å beskrive forretningsprosessene er: Det må utvikles et sett av regler og standarder som beskriver hvordan forretningsprosessene skal gjennomføres, herunder avgrensning mot interne og eksterne prosesser. I forbindelse med tredjeparter er det viktig å ha kontroll med hva som skjer: det må dokumenteres nøye hvordan tredjeparten skal utføre de forretningsprosesser som legges ut ( outscources ), herunder gis en detaljert beskrivelse av hvilket ansvar tredjeparten har. I denne sammenheng kan det bemerkes at i forbindelse med betalingsløsningen mellom Hydro Finans og BBS har Hydro utarbeidet en 250- siders manual som beskriver BSS sitt ansvar i ulike situasjoner. 12

13 For å sikre størst mulig tilfang av bedrifter må ikke forretningsprosessene spesifiseres for restriktivt. Det bør etableres et sentralt repository for publisering og vedlikehold av spesifikasjonene. Om mulig bør man her kunne laste ned eksekverbare spesifikasjoner som kan integreres inn i brukernes løsninger. Objektmodellen er viktig å få frem, samt en scenario-beskrivelse som dokumenteres i en åpen repository (jf. ebxml). rensesnitt (dvs. en nøyaktig beskrivelse av når ansvaret går over fra en aktør til en annen) er viktig. Viktig med avgrensning mot interne og eksterne prosesser. Det synest å være generell enighet om viktigheten av å dokumentere forretningsprosessene, særlig i tilfeller hvor tredjeparter er involvert Bør det stilles spesielle krav til bruk av identifikasjonsbegreper (f.eks. at bruk av gitte identifikasjonsbegreper er påkrevet i enkelte forretningsprosesser) (9)? Alle de intervjuede bedriftene anså identifikasjonsbegreper som en selvfølgelig og viktig del av infrastrukturen, men det er uenighet om man skal satse på kun en ID eller om flere bør tillates. I sistnevnte tilfelle var det også uenighet om konverteringen mellom dem bør håndteres av bedriftene selv eller overlates til tredjeparter. Mange mente at identifikasjonsbegreper er en så viktig del av bedriftenes kjernesystemer at dette bør håndteres av bedriftene selv. Det var ingen klar konklusjon med hensyn til hvilket identifikasjonsbegrep man skal velge i tilfelle man satser på kun ett begrep. En selvfølgelig del av infrastrukturen; ønskelig med kun ett identifikasjonsbegrep (men vanskelig å realisere i praksis?) Id-begreper er en så viktig del av kjernesystemene at bedriftene bør håndtere dette selv 13

14 4.4 Dataformater og semantiske problemstillinger Bør man i en felles infrastruktur for e-handel sette begrensninger med hensyn til hvilke dataformater (syntaks) som skal støttes, i tilfelle hvilke (10)? De fleste bedriftene var enige om at de vanligste dataformatene (EDIFACT, XML og HTML) bør støttes. Man var noe mer avventende til WML/WAP. Det var også uenighet med hensyn til om det bør settes begrensninger på antall og type formater. Hovedinntrykket er at dette er noe som bør overlates til markedet. Utfordringen er ikke syntaks, men å få infrastrukturen til å fungere på meldingsinnhold, forretningsprosser, regelverk, etc. Hvilke formater som støttes vil i siste instans være et spørsmål om pris. Infrastrukturen bør ikke sette begrensninger med hensyn til hvilke formater (EDIFACT, XML, HTML, ANSI X.12, etc.) som skal tillates. Dette bør reguleres av markedet Er det mulig å spesifisere et begrenset sett av syntaksnøytrale semantiske beskrivelser av datainnhold i meldinger som (nesten) alle kan tilpasse seg (11)? Det var uenighet på dette punkt. Noen mente at en faktura kan beskrives entydig for alle bransjer (trenger bare visse nøkkeldata, som bestillingsnummer, kontaktperson, etc.), mens andre mente dette ikke er mulig og at man alltid vil måte leve med funksjonelle ulikheter. Andre igjen mente det er mulig, men kanskje ikke praktisk gjennomførbart. Det ble påpekt at noe av formålet med en felles infrastruktur er å håndtere slike ulikheter, slik at bedriftene kan konsentrere seg om sin kjernevirksomhet. Mulig å standardisere, men neppe praktisk gjennomførbart. Ulike datadefinisjoner etc. bør overlates til infrastrukturen å håndtere. 14

15 4.5 Kommunikasjonsteknologier Bør man i en felles infrastruktur for e-handel sette begrensninger med hensyn til hvilke aksess/nettverksløsninger eller meldingstransporttjenester som skal tillates (12)? De fleste av intervjuobjektene var av den oppfatning at valg av kommunikasjonsbærere er relativt uvesentlig, og at det følgelig er liten eller ingen grunn til å legge begrensninger. Hovedargumentet for et slikt synspunkt er forventningen om at utviklingen av nye løsninger skjer så raskt at en standardisering ikke er praktisk mulig, samt at raskere, smartere og billigere løsninger vil få utbredelse av seg selv. Tilsvarende var det stor enighet om at det er naturlig å benytte Internett som kommunikasjonsbærer i en fremtidig åpen infrastruktur. Følgende argumenter ble trukket frem blant de som mente at man i en infrastruktur for elektronisk handel bør sette begrensninger med hensyn på mulige kommunikasjonsløsninger: 95% av trafikken uansett går over Internett (IP), så hvorfor ikke begrense infrastrukturen til dette. mer aktuelt/lettere å sette begrensninger her, fordi det er lettere (billigere) enn å tilpasse seg ulike teknologier jør det enkelt. Minimum må defineres. Infrastrukturen i seg selv bør ikke sette begrensninger, men kan godt peke i en gitt retning basert på internasjonale forhold (markedsdrevet) Infrastrukturen må stille krav til funksjonalitet, for eksempel krav til to veis kommunikasjon Det er naturlig å basere en fremtidig åpen infrastruktur for elektronisk handel på bruk av Internett 15

16 4.6 Sikkerhet Hvilke funksjonelle sikkerhetstjenester bør inngå i en felles infrastruktur for e-handel (13)? I spørsmålsstillingen ble følgende funksjonelle sikkerhetsløsninger listet opp: Ikkebenekting av opphav Ikkebenekting av mottak Integritet Konfidensialitet Autentisering Blant disse var autentisering den som ble trukket frem som viktig av de fleste, tett fulgt av integritet og Ikkebenektning av opphav. Konfidensialitet er den funksjonen som er minst aktuell. Det skal dog bemerkes at alle anerkjenner behovet for konfidensialitet i overføring av person data. Konklusjoner: Sikkerhet er viktig! I utgangspunktet alle, men bruken av sikkerhets-tjenestene vil være avhengig av anvendelse, også innen bransje. PKI kan fort komme inn som et nødvendig element og må være en opsjon Bør man i en felles infrastruktur for e-handel sette begrensninger med hensyn til hvilke kryptografiske algoritmer, sertifikatformater eller tekniske sikkerhetselementer som skal tillates (14)? Det er stor enighet blant intervjuobjektene om at sikkerhet er et viktig tema. De færreste er imidlertid villig til å gå inn på en diskusjon om hva dette innebærer i forhold til konkrete tekniske løsninger. Blant de ti som besvarte dette spørsmålet var det en marginal overvekt av de som mente at infrastrukturen i seg selv ikke skal sette begrensninger med hensyn på tekniske sikkerhetsløsninger. Det er imidlertid verdt å peke på at de som har praktisk erfaring med å implementere komplekse sikkerhetsløsninger mot flere partnere er blant de som ønsker at infrastrukturen skal sette begrensninger på dette punkt. Argumentene for dette er at: Sikkerhet vesentlig tyngre enn kommunikasjon. Ikke lurt å åpne for alle typer teknologier her. Det er billigst, da sikkerhet er fryktelig dyrt. Må sette begrensninger (velge ut noen elementer). Sikkerhet viktig, men kostbart. 16

17 4.7 Tredjepartstjenester (Formidlings- og translatørtjenester) Hvilke tjenester bør være tilgjengelig fra en tredjepart, og hvilke av disse er aktuelle for egen bedrift (15)? I spørsmålsstillingen var det identifisert en rekke tjenester som i større eller mindre grad er tilgjengelig i markedet i dag. Enkelte andre tjenester kom frem i løpet av intervjuene. Følgende liste gir et bilde av de typer tjenester man forventer at en tredjepart kan tilby: Sikkerhet, dvs. TTP-tjenester inklusive Sertifisering og nøkkeladministrasjon og Kryssertifisering Konvertering og sammenkobling mellom ulike teknologisk løsninger (bl.a. tegnkonvertering) Konvertering mellom interne dataformater og standard formater i infrastrukturen Oversetting mellom ulike semantiske datadefinisjoner Overvåking/kontroll av at de omforente forretningsprosessene blir fulgt Konvertering av identifikasjonsbegreper Drift og overvåkning av trafikk/meldingsflyt Arkivering Duplisering/massedistribusjon Splitting data til ulike mottakere Bransjevise Portaler/Markedsplasser Funksjonsorienterte Portaler/Markedsplasser Det er imidlertid ingen enighet med hensyn på hvilke av disse tjenestene som bør inngå som en selvfølgelig del av infrastrukturen og hvilke som oppfattes som betalbare tilleggstjenester. (I dette ligger det ingen forventning om at infrastrukturen i seg selv skal være kostnadsfri.) Det var spesielt to av de ovenstående tjenestene hvor det var stor uenighet bland intervjuobjektene: 1. Overvåking/kontroll av at de omforente forretningsprosessene blir fulgt En slik tjeneste handler i stor grad om å gi tredjepartsleverandørene en form for poiliti-rolle, hvor tjenesteleverandøren kontrollerer den enkelte bruker på vegne av samfunnet for å sikre at de avtalte forretningsprosessene blir overholdt. Blant de ni som spesifikt kommenterte dette forholdet var det en marginal overvekt av de som mente at tjenesteleverandørene skal ha en slik rolle. Det motsatte synet er at den enkelte bruker selv har ansvar for å sikre at han overholder de avtale forretningsprosessene, og at dette uansett ikke er noe som kan eller bør overlates til en tredjepart. 2. Konvertering av identifikasjonsbegreper Se diskusjon under punkt Konklusjoner: Tredjepartsleverandører er en selvfølgelig del av en åpen infrastruktur for elektronisk handel og er spesielt viktig for SMB for å kunne implementere praktiske løsninger. Tredjepartsleverandørene representerer et naturlig utgangspunkt for implementering av standardiseringsinitiativ. 17

18 4.7.2 Hvilket ansvar skal tillegges en eventuell 3-part (f.eks. verifikasjon av sertifikater) (16)? Momenter som ble trukket frem var: Skal ha ansvaret for det han tar betalt for å gjøre. Viktig at han gir tilbakemelding. Portaler må blant annet være ansvarlig for å slusing til markedsplasser Tjenesteleverandørens eventuelle ansvar er sterkt knyttet opp til kostnader. Jo ber ansvar, jo høyere kostnad Ansvaret som tillegges en tjenesteleverandør må reflektere det avtalesettet som eksisterer mellom handelspartene Må definere standardiserte tjenesteavtaler som en del av infrastrukturen De har ansvar for fremføring av meldinger og de tjenestene de tar betalt for (f eks konvertering). Viktig at de kan bevise at de har oppfylt avtalen. Dette krever oppfølging og logging på en sikker måte. Det konkrete ansvar en ASP har vil være kontraktsavhengig Ansvarlig for å sørge for rask, sikker og rimelig kommunikasjon samt varsling. Må i etterkant kunne fortelle ha som er skjedd Juridisk logging. Aktører i infrastrukturen (dvs markedsplassene) må kunne håndtere en fulle kjede fra behov til kontering. runnfunksjonalitet vil da være Distribuere katalog/produkt Ordre/bestilling Bekreftelse Resten er opsjoner og tillegg Juridisk ansvar for transaksjoner. Må defineres når ansvar går over til tredjeparten. Sørge for åpenhet, oppetid, stabilitet, etc. og kommunikasjon i elektroniske nettverk. Det må stilles juridiske og formelle krav (dvs. tredjeparten må garantere at tjenesten blir utført). ASPer må sørge for at infrastrukturen lar seg implementere. Det synest å være relativt stort sprik med hensyn til hvilket ansvar man forventer at en tjenesteleverandør skal ha ut over det grunnleggende ansvaret for en sikker fremføring av data. Dette har klare koblinger både mot bedriftens generelle strategi med hensyn til outsourcing og mot de kostnadene som er involvert. 18

19 4.8 Problemstillinger som må utredes/løses Er det spesielle problemstillinger som må utredes/løses før en felles infrastruktur for e-handel kan realiseres (17)? Følgende konkrete problemstillinger kom frem: Koordinering av alle PKI-prosjektene Hva kan en tredjepart tillate seg å fakturere av tilrettelegging? Kan de ta betalt for det samme av flere kunder? å i tur med justisdept for å modernisere lovverket, f. eks. Forsikringsavtaleloven Viktig å utrede gråsoner som ikke fanges opp av en avtale. Foreløpig mangler klare føringer og svar på hvordan ting egentlig skal fungere over Internett, f.eks. identifisering, sporbarhet av transaksjoner, båndbredde. Rammebetingelser fra det offentlige (gebyrer, lovverket) må utredes nærmere Myndighetskrav til funksjoner og dokumenter Datatilsynets begrensninger Juridiske og formelle krav samt når går ansvaret over fra a til b, hvordan er ansvaret definert, regresskrav, etc. 19

20 4.9 Bruk av infrastrukturen Hva skal til for at din bedrift skal gjøre bruk av en felles infrastruktur (18)? Følgende momenter kom frem: od integrasjon mellom forskjellige plattformer. Juridiske avklaringer må være gjort. - Handelsprosesser, og personvernet! Viktig med profilering av merkevarer od definisjon på hvor verdiene og kontrollen er i en forretningsprosess. Må være synlig hvilken gevinst det ligger for en bedrift å benytte en infrastruktur. od definisjon av dataelementer, og at den semantiske beskrivelsen passer med bedriftens datasystemer Vil være avhengig av funksjonsområde. For innkjøp bør bla følgende elementer være mulig: Enkel tilgang til varekataloger for å se hvem som kan levere Mulighet for å sammenligne pris/tilbud fra forskjellige leverandører Ikke for dyrt (investering og drift) At tjenester tilbys til forsvarlige kostnader samt at driftsstabilitet kan garanteres Må vise at det ikke er noen grunn til å etablere bedrifts eller bransjespesifikke løsninger Lavere kostnad enn i dag Relativt små endringer Troverdighet for at dette blir en standard. Må ha internasjonal/europeisk forankring. Deltakere fra forskning, brukere og leverandører. Forankring hos myndighetene. Må spesifisere koblinger til f eks merkelapper og strekkoder for å dokumentere en helhetlig prosess Fokuserer på strukturert informasjon (underforstått EDIFACT) ikke på web Større offentlig trykk offentlige penger At markedet eller forholdet til konkurrentene krever det eller at den er til nytte At infrastrukturen er sikker samt at standarder finnes. Partene må være trygge på at transaksjoner håndteres på en sikker måte. Det viktigste argumentet for brukerne til å ta i bruk en ny infrastruktur for elektronisk handel er synliggjøring av de konkrete gevinster den enkelte virksomhet kan oppnå. Det er et viktig argument for brukerne at tjenestene i infrastrukturen kan tilbys til en forsvarlig kostnad samt at driftsstabilitet kan garanteres. De konkrete kravene til kost og driftsstabilitet kan variere avhengig av funksjon. Det er videre viktig å skape troverdighet for at dette blir en standard som har internasjonal/europeisk forankring. 20

21 4.9.2 Hva skal til for at din bedrift skal kunne ha tiltro til at en annen virksomhet faktisk holder seg til beskrivelsen av infrastrukturen (19)? Følgende momenter kom frem: Må foreligge en avtale om bruk pluss at det må finnes mekanismer som gjør at man kan oppdage avtalebrudd lobal forankring Testing/sertifiseringsordninger kan bidra. For eksempel Netsafe sertifisering eller bransjegodkjenning? Dette vil bli håndtert ved selvjustis i markedet At det foreligger en avtale som beskriver hvordan infrastrukturen skal fungere. Vil være fornuftig med demonstrator-prosjekter. Må få opp mange-til-mange prosjekter. Tredjeparter må kunne bidra med noe som gjør at nykommere kan komme opp å stå. Det er ingen entydighet med hensyn til hvordan man kan sikre størst mulig tilslutning til infrastrukturen. Noen hevder at dette ikke noe problem da det vil bli håndtert ved selvjustis i markedet. Andre ser behov for konkrete tiltak. De tiltakene som først og fremst trekkes frem er Testing og sertifiseringsordninger a la Netsafe som er etablert for Internettbutikker. Bransjegodkjenning av forretningsprosessene som inngår i infrastrukturen. Et etablert avtaleverket, som beskriver hvordan ting skal gjøres og hvem som tar ansvar for hva. 21

22 4.10 Internasjonale initiativ og standardiseringsaktiviteter Hvilke internasjonale initiativ og standardiseringsaktiviteter bør legges til grunn ved spesifikasjon av en felles infrastruktur for e- handel (20)? I spørsmålsstillingen ble følgende internasjonale initiativ og standardiseringsaktiviteter listet opp: Open-EDI reference model (ISO 14662) UN/EDIFACT EbXML Internet Open Trading Protocol (IOTP) Open Buying on the Internet (OBI) Open Trading Protocol (OTP) Secure Electronic Market Place for Europe (SEMPER) Secure Electronic Transaction (SET) RosettaNet Biztalk framework CEN/ISSS Building Blocks EC-DTF reference model eco framework specification IMPRIMATUR business model STEP Industrial Data Framework Java EC framework I løpet av intervjuene ble også W3C og Watch (EURO avregning) i regi av NATCHA Cross boarder Council trukket frem som interessante aktiviteter Konklusjoner: De færreste brukere har noe bevist forhold til internasjonale initiativ og standardiseringsaktiviteter. Det er likevell stor enighet om at det er viktig å følge internasjonale standarder. Selv blant de som har et bevist og aktivt forhold til det som skjer internasjonalt er det usikkerhet med hensyn på hva som blir toneangivende fremover. Følgende utsagn kan stå som eksempel på den usikkerhet man føler: Usikker på hvor viktige de opplistede initiativene er. De fleste er i en tidlig fase (dvs. vanskelig å si hvor betydningsfulle de vil bli). Noen initiativer som var hippe for noen år siden er ikke på listen. Det er likevel stor enighet om at vi må forsøke å plukke ut vinnerne og legge disse til grunn ved for en fremtidig infrastruktur for elektronisk handel 22