Elektronisk Handelsformat - EHF - Veileder for systemleverandører

Kilde: DFØ

Elektronisk handelsformat (EHF) gjør det mulig med standardisert, elektronisk kommunikasjon mellom virksomheter, uten direkte integrasjoner mellom datasystemer.

Publisert: 17. aug 2018, Sist endret: 04. des 2020

Hva er EHF?

Elektronisk handelsformat (EHF) er en standard for elektronisk utveksling av informasjon mellom oppdragsgiver og leverandør, i hele anskaffelsesprosessen.

Følges standarden, vil dokumenter som sendes fra for eksempel en oppdragsgiver, kunne leses inn i leverandørens datasystem selv om systemene er ulike. Virksomhetene unngår dermed dyre én-til-én-integrasjoner mellom ulike datasystemer.

Det Europeiske formatet kalles PEPPOL BIS. EHF er kompatibelt med formatet  PEPPOL BIS fo de meldinger som dette formatet dekker. Ved å tilpasse dine systemer til EHF-standarden, vil du dermed kunne kommunisere med andre Europeiske land som følger BIS-standarden. Målet er å standardisere prosesser og meldingsinnhold på tvers av landegrenser.

EHF kan være både anbefalt, i henhold til Referansekatalogen eller obligatorisk i henhold til lov/forskrift. ved elektronisk fakturering i staten.

Hva er en EHF prosess?

En EHF prosess er i denne sammenheng den prosess som understøttes av én eller flere EHFer. Mens  EHF kunngjøring er navnet på EHFen, er EHF kunngjøring prosess navnet på prosessen. Legger prosess til EHF navn.

Hvorfor har vi EHF prosesser?

Anskaffelse er en prosess - en systematisk serie med aktiviteter rettet mot oppnåelse av ett eller flere mål for anskaffelsen. For å oppnå en god anskaffelse må man ha en god anskaffelsesprosess. Digitalisering er bruk av teknologi i forbedring av prosesser. Man kan ikke lykkes med digitalisering, for eksempel ved bruk av EHF, uten en prosessorientert tilnærming. For eksempel: 
Før vi skal utvikle en EHFer må vi vite hvilken prosess som EHF skal benyttes i. Når vi utvikler EHF  tegnes disse inn i prosessen slik at vi kan analysere og identiferes hvilke tekniske, prosessuelle og organisatoriske endringer og gevinster som kan oppnås. Etter utviklingen får brukerne en beskrivelse av prosessen og et prosessdiagram. Hensikten er å forenkle arbeidet med implementering og sikre at alle som deltar får den informasjon de trenger for å utføre og samarbeide på en effektiv måte.

Hvordan utvikles EHFer og EHF prosesser?

Prosessen for utvikling og forvaltning av EHF og prosessene de(n) benyttes i består av 5 faser:

Bilde av EHF-prosessen1
 
 

1. Analysere behov
I første fase identifisere vi interessentene – hvem som må inkluderes i utviklingen. Vi kartlegger prosessen slik den utføres og nåsituasjon for interessentene – hva de er fornøyd med, hva de har problemer med, og andre tanker om forbedring og fornying. Etter kartleggingen gjennomføres det analyser for å identifisere og velge den beste løsningen, mål og krav til EHF. Fasen oppsummeres i en rapport som danner grunnlag for planlegging og gjennføring av utviklingsarbeidet.  
2. Utvikle EHF 
Etter kartlegging og analyse utvikles EHFen(e). Første trinn er utvikling av en informasjonsmodell – beskrivelse av informasjonselementene i EHF. Informasjonsmodellen gjøres så om til en datamodell som knytter sammen alle elementene til en helhet med avhengigheter og regler. Datamodellen danner grunnlag for den tekniske beskrivelsen som systemleverandører trenger for å implementere EHFen.
3. Utbredelse og implementering
Når utviklingen er ferdig vil brukerne motta:  

  • En EHF/Implementeringsveileder for systemleverandører. 
  • Valideringsstøtte for systemleverandører. 
  • EHF prosessdefinisjon som gir nøkkelinformasjon om prosessen og hvordan den skal brukes og implementeres, samt et prosessdiagram. Denne kan og bør benyttes av alle faggrupper som skal delta i implementering- og gevinsterealiseringsarbeidet. 
  • Eventuelle veiledere tilpasset målgruppens behov. 
  • System for å gi tilbakemeldinger.  
  • Brukerstøtte.  

4. Gevinstrealisering
Målet er at systemleverandører, oppdragsgivere, leverandører og andre som skal benytte prosessen får den informasjon de trenger (se over) for å implementere, nyttiggjøre, gi tilbakemeldinger og komme med forslag til forbedringer og nyutvikling av EHF. 

5. Forvaltning
Samtidig som fase 4 er slutten på utviklingsfasen er den starten på en ny fase – forvaltning av EHF. Hensikten med denne fasen, som aldri tar slutt, er gjennom kontinuerlig forbedring å sikre at brukerne til enhver tid har de tjenestene som dekker deres behov.  
 

Hvem har nytte av prosessdefinisjonene? 
Prosessdiagrammene og definisjonen er i utgangspunktet generiske og kan derfor brukes av alle i alle typer prosessarbeid, ikke bare digitalisering. Vårt prosessrammeverk og definisjoner kan med stor fordel benyttes av alle.  
Dersom du er interessert i å vite mer om vårt prosessrammeverk, hvordan det kan benyttes og fordelene med. Ta kontakt med Jan Mærøe. 
 

Hva er EHF prosessrammeverk

EHF prosessrammeverk består av tre elementer: Prosessoversikt. Prosessdefinisjoner. Og metoder for prosessarbeid.
EHF prosessrammeverket har to formål:  

  • Det ene er å sikre at det arbeides med riktig prosess på riktig måte - sikre at EHF har riktig kvalitet.  

  • Det andre er å sikre at alle som skal delta i utviklingen, og bruke EHF prosessen - oppdragsgivere, leverandører, systemleverandører, osv., får den informasjonen de trenger for å forstå og bruke prosessen på en riktig måte.  

1. Prosessoversikt

Prosessoversikten er en tabell som viser alle typer/former for aktivitet som utføres i en anskaffelsesprosess uavhengig av type anskaffelser. Det er viktig å forstå at oversikten IKKE beskriver en prosess eller prosdyre – hvilke aktiviteter som skal utføres i hvilken rekkefølge på hvilken måte -  kun de ulike typer aktiviteter. Det samme som en liste med ingredienser du trenger for å lage en matrett, eller hvilke typer legoklosser du trenger for å lage en legofigur, osv.
I en anskaffelse er det mange forskjellige aktiviteter. For å forenkle arbeidet er alle aktiviteter gruppert og organisert i et hierarki etter følgende mønster.

NivåType/kategori prosess Eksempel 
1Kategori - hva slags kategori/type prosess det er.X= Anskaffelser. Dersom man ønsker å utvide rammeverket til å gjelde andre typer prosesser, for eksempel HR-prosesser vil denne kategorien tildeles en bokstav eller tall om man ønsker å bruke det.
2Hovedgrupper i kategori - prosesser som logisk hører sammen samles i en gruppe.X2=Avklare behov og forberede konkurranse – er en gruppe prosesser i X som logisk hører sammen i anskaffelser. Det som ofte kalles en fase.
3Prosess i hovedgruppeX21= Vurdere behov - er en prosess i hovedgruppen X2.
4Del-prosess og eller oppgave i prosessX211=Beskrive dagens utfordringer og dagens løsning - er en del-prosess i prosessen X21
5Dersom prosessen består av flere nivåer med del-prosesser kan det opprettes flere nivåer.X2111=Identfisere prosess, osv.  - er en oppgave i del-prosessen X211 osv.  
6,7..Nederste nivå er oppgavenivået 

Når man kartlegger og beskriver prosesser er det vanlig å begynne på et detaljert nivå. Ulempen med det er at det fort blir uoversiktlig og kanskje også unødvendig. Fordelen med hierarkisk modellering hvor du begynner på et overordnet nivå, er at du beholder oversikten og sammenhengen samtidig som du ikke detaljerer mer enn det du trenger – mer effektiv og bedre måte å kartlegge og beskrive prosesser på.
Oversikten er en tabell som består av disse 4 kolonnene:

IDAktivitetEHF prosessRolle
Hver aktivitet får tildelt en unik ID som ikke endres.Navn på aktiviteten som utføres i anskaffelsen. Disse navnene referer til beskrivelsen av aktivitetene i anskaffelsesprosessen på anskaffelser.noNår en prosess/aktivitet digitaliseres får den et eget navn og definisjon. Klikker du på navnet får du opp prosessdefinisjonen.Hvilken organisasjon som deltar i prosessen, for eksempel oppdragsgiver, leverandør, etc.

ID
Identifikatoren består som sagt av en bokstav som beskriver hvilken type/kategori prosess det er, samt et antall siffer som samlet sett angir hvilket nivå man er på. 
ID endres ikke. Fordelen med det er at vi kan spore aktiviteten over tid. Ulempen er at den ikke gir noen mening ut over å beskrive hva slags type prosess og hvilket nivå den er på.
Aktivitet
Navn på aktiviteten som utføres i en anskaffelse. Dette skal være de samme aktivitetene som står beskrevet på anskaffelser. no. Det er lagt inn lenker på overordnet nivå som tar deg til den siden på anskaffelser.no hvor denne aktiviteten står beskrevet.
EHF Prosess
Er navnet på den prosess som understøttes av EHFer. Aktivitetene som står beskrevet i kolonne 2 hentes fra anskaffelser.no og er beskriver kun hva som må gjøres av aktivtet uavhengig av om det er en person eller et system.
Når disse digitaliseres ved bruk av EHFer får vi en digital variant med et eget navn, for eksempel «EHF spørsmål og svar», som er den digitale varianten av aktiviteten «Spørsmål og svar av eventuelle avklaringer til oppfyllelse av kvalifikasjon» som du finner i beskrivelsen av prosessen på anskaffelser.no.
Dersom du ikke finner navn på EHF i denne kolonnen betyr det at den ikke er utviklet, eller er under utvikling.
Dersom du klikker på navnet til EHF prosessen får du opp en prosessdefinisjon, se nærmere forklaring under.
Rolle
Beskriver hvilke organisasjoner som deltar i prosessen, for eksempel oppdragsgiver, leverandør, publiseringstjeneste.  

Her finner du lenke til EHF Prosessoversikt


2. EHF prosessdefinisjon

Alle EHFer har en egen prosessdefinisjon, et dokument som inneholder både et prosessdiagram og all grunnleggende informasjon du må ha for å forstå prosessdiagrammet.
Hensikten med prosessdefinisjonen er å sikre at alle som skal bidra i utvikling, implementering og vedlikehold – oppdragsgivere, leverandører, systemleverandører, prosjekter, etc. Får den informasjon de trenger for å arbeide og samarbeide på en effektiv måte.

3. Metode for prosessarbeid

I utvikling av prosessrammeverket legger vi til grunn den tilnærming og de erfaringer man har med utvikling av verdens mest utbredte prosessrammeverk – APQC process classification framework.
I arbeidet med prosesser benytter vi de grunnleggende BPM – business process management – metodene og verktøy.
Prosessdiagram følger BPMN 2.0 notasjonen – den mest avendte notasjonen i verden.

Alle kan bruke prosessrammeverket

Arbeidet med kartlegging og beskrivelse av prosesser krever kompetanse, tid og ressurser som mange ikke har. Et mål for utvikling av prosessrammeverket er at det skal kunne brukes av alle som ønsker det. Fordelene er blant annet.

  • Virksomheten sparer tid og ressurser.  

  • Når alle bruker samme rammeverk utvikler man felles språk, forståelse og metoder som gjør det langt enklere å samarbeide og lære av hverandre.  

  • Det forenkler og forbedrer både opplæring og ledelse av medarbeidere. 

Vil du vite mer?

Dersom du vil vite mer om hvordan vi arbeider og hvordan du kan nyttiggjøre deg dette, ta kontakt med Jan Mærøe.

EHF forvaltning og endringshåndtering

Alle delprosesser som er dekket av EHF henger sammen da arbeidet med standarder tar hensyn til den totale anskaffelsesprosessen.

Det europeiske formatet PEPPOL BIS forvaltes og utvikles av Peppol. Formatene PEPPOL BIS og EHF er igjen basert på resultater fra arbeidet til CEN BII, UBL og andre enheter som har blitt gitt mandat til å virke som en koordinerende enhet. Et eksempel på dette er utlysningsskjemaene og nå ESPD som administreres av Publication Office.

Gjennom nasjonal standardisering av meldingsinnholdet i de forskjellige transaksjonene (EHF- Elektronisk Handelsformat) som igjen er koordinert med Europeisk standardisering (PEPPOL BIS formater og andre), vil man utvikle og vedlikeholde innhold og oppsett på en enhetlig måte som dermed reduserer kostnadene for de enkelte virksomhetene betraktelig ved implementering av systemstøtte.

For effektiv kommunikasjon med interessentene i anskaffelsesprosessen, ved endrede behov og regulereringer, forvaltes EHF og BIS etter gitte regler og med fastsatte tidsfrister for endringen. Dette for at alle parter skal høres og at systemleverandørene skal få tid til å implementere endringene. Regler for endringer relatert til endringens natur med forskjellig varslingstid for å gi tid til systemendringer finner du her.

Det er fullt mulig for alle å spille inn ønsker i denne prosessen nasjonalt og internasjonalt- ehf@dfo.no

EHF prosessen

Digitaliseringsdirektoratet benytter forskjellige kanaler for informasjonsspredning om endringer. Hovedkanalen er Anskaffelser.no samt LinkedIn gruppen "Elektronisk handelsformat- EHF. Offentlige anskaffelser har også en gruppe på Facebook. Den tekniske siden som bærer informasjonen og endringer finner du på Anskaffelser.dev.no.

Vi anbefaler systemleverandører å laste ned vår RSS-feed for å holde seg oppdatert:https://anskaffelser.dev/

Elektronisk Handelsformat (EHF) og prosess

EHF kunngjøre konkurranse prosess

 Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF kunngjøre konkurranse prosess
Prosess IDX311 Kunngjøre konkurranse
OrganisasjonDFØ-ANS
Prosess eierThor Møller
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.09.15Dokument etablertPetter Vinje
    
    
    

3. Om prosessen

Kunngjøringsprosessen er en prosess hvor oppdragsgiver kunngjør et skjema knyttet til offentlige anskaffelser på Doffin og eller TED.

4. Brukere og bruksområde 

  • Prosessen benyttes på alle typer kunngjøringer (se pkt. 13 kommentarer). 
  • Oppdragsgiver trenger prosessen for å informere om behov for varer og tjenster og resultat av en anskaffelse.
  • Leverandører trenger prosessen for å få informasjon og dermed kunne tilby sine varer og tjenster.

5. Formål

Best mulig utnyttelse av offentlige midler gjennom størst mulig konkurranse.   

6. Mål

At kunngjøringen blir publisert på Doffin og/eller TED til riktig tid med riktig informasjon.

7. Gevinster

For oppdragsgiver

  • Størst mulig tilfang av tilbydere
  • Informasjonsflyt som likebehandler leverandørmarkedet

For leverandør: 

  • Alle offentlige konkurranser samlet på ett sted.
  • Sikre likebehandling for innlevering av tilbud.

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

  • Doffin = Nasjonal kunngjøringsdatabase for offentlige anskaffelser, lovpålagt å bruke over terskel, frivillig under terskel
  • TED = Europeisk kunngjøringsdatabase, lovpålagt å bruke over terskel for norske oppdragsgivere
  • KGV = Konkurransegjennomføringsverktøy

9. Startkriterier/forutsetninger

TriggerBeslutning om å kunngjør konkurranse på Doffin/TED
Andre forutsetninger

Oppdragsgiver er lovpålagt å benytte KGV verktøy.

KGV verktøy må være kompatibel med etablert Doffin prosess.

Må ha kompetanse i bruk av KGV system.

Lovpålagt å kunngjøre på Doffin og eller TED for noen konkurranser.

​​10. Input og leverandører

InputAvleverende prosess: Leverandør/avsender - organisasjonReferanse
Beslutning om kunngjøringX2 Avklare behov og forberede konkurranseOffentlig oppdragsgivere 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
OppdragsgiverPersonO-per 
OppdragsgiverSystemO-sys 
Systemleverandør SlKGV
Publiseringstjeneste PubDoffin + TED
    

12. Prosessdiagram

EHF kunngjøre konkurranse prosess
 
 

EHF kunngjøre konkurranse prosess (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
 1. Forbered  kunngjøringO-perDel-prosess 

Inkluderer alle kunngjøringstyper: 

  • Veiledende kunngjøring.
  • Intensjonskunngjøring.
  • Kunngjøring av konkurranse.
  • Endringskunngjøring.
  • Kunngjøring av kontraktsinngåelse
  • Kunngjøring av kjøperprofil
 2. Send kunngjøringO-sys   
 3. ValideringPub  Både teknisk og manuell prosess
 4. Send avviksmeldingPub   
 5. Korriger kunngjøringO-per   
 6. Sjekk publikasjonstypePub   
 7. Oversett tekst til engelskPub   
 8. Publiser kunngjøringPub  Ted
 9. Generer kunngjøringsbekreftelsePub  Ted
 10. Send kunngjørings-bekreftelsePub  Doffin
 11. Lagre kunngjøringsbekreftelseO-sys   
 12. Publisere kunngjøringPub  Doffin
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
Nei   

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Kunngjøring publisertX 314 Søke på kunngjøringerLeverandør 
    

16. Sluttkriterier

Nei

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Ikke fyller ut kunngjøringsskjemaet riktig.Lav-middelsLiten-høyDersom verktøystøtte benyttes kan man få varsel og redusere risiko for feil.Opplæring i bruk av system. Redusere bruk av egenproduserte maler. 
Ikke korrekt oversettelse eller manglende godkjennelse av oversettelseLav-middelsLiten-høySikre god rutiner og sporingEtablere en god kvalitetssikringprosess
Feil utfylling gir dårlig statistikkunderlag for nye konkurranserLav-middelsLiten-høyGod systemstøtteEtablere en god kvalitetssikringprosess
     

19: Behov for støtte

StøtteForklaring/Lenker
Behov for skjemaopplæring via systemet. 
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Når EHF foreligger vil du finne spesifikasjoner her:  

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF søk kunngjøring

​EHF Søk kunngjøring gjør det mulig for leverandører å sette opp en varslingstjeneste om konkurranser som er av interesse. Det forutsettes at leverandøren har et eget system koblet til PEPPOL eDelivery for å kunne ta en slik funsjonalitet i bruk. De fleste konkurransesystemer har en slik tjeneste i dag men utfordringen er at leverandører må tilknytte seg de ulike tjenestene til de ulike konkurransesystemene.  Målet er at leverandøren kan operere en slik tjeneste fra det systemet som velges uavhengig de ulike konkurransesystemene.

Status for formatet

Under planlegging.

Formål og virkemåte: Automatisk søk i kunngjøringsdatabaser

EHF Søk kunngjøring beskriver en prosess som gir leverandører mulighet til å automatisere søk i kunngjøringsdatabaser, for eksempel Doffin, gjennom sitt eget system.

En leverandør kan bruke formatet til å gjøre et elektronisk søk mot databasen basert på utvalgte søkekriteria, og få returnert oversikt over relevante konkurranser. Leverandøren kan utforme søket så det er i henhold til eget vare- og tjenestesortiment.

Formatet gjør det mulig å strukturere meldingene som kommer i retur slik at leverandørens system kan organisere og presentere informasjonen likt hver gang.

Fordeler med å ta i bruk formatet

For oppdragsgivere

  • Kunngjøringer som legges ut på publiseringsløsninger vil automatisk bli oppdaget av aktuelle leverandører.
  • Innholdet gir leverandør informasjon om hvor ytterligere informasjon om konkurransen finnes. Dermed øker potensialet for at flere leverandører besvarer konkurransen.

For leverandører

  • Systemet sikrer at alle kunngjøringer som er relevante blir presentert for leverandør i eget system.
  • Informasjon som blir presentert inneholder relevante detaljer om konkurransens innhold.
  • Informasjonen kan gjenbrukes i neste prosess der leverandør viser sin interesse overfor oppdragsgiver.

EHF søk kunngjøring prosess

​Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF søk kunngjøring prosess 
Prosess IDX314 Søk på kunngjøringer
OrganisasjonDFØ-ANS
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.08.17Dokument etablertPetter Vinje
    
    
    

3. Om prosessen

I denne prosessen søker leverandør sitt system etter interessant kunngjøringer. Dersom søk får treff i publiseringsdatabasen returneres aktuell kunngjøringer til leverandør.

4. Brukere og bruksområde 

Leverandør trenger prosesser når han skal søke i publiseringsdatabaser.  

5. Formål

Sikre at leverandøren til enhver tid kan få oversikt over kunngjøringer som er interessante.

6. Mål

Automatisert innhenting av kunngjøringer.

7. Gevinster

Oppdragsgiver: Flest mulig leverandører får se kunngjøringen når den publiseres vil kunne bidra til økt antall tilbydere i hver konkurranse.

Leverandør: 

  • Effektiv måte å få oversikt over alle offentlige anskaffelser – sparer tid og ressurser.
  • Leverandør kan gjenbruke informasjon fra kunngjøringen i neste prosess – sikrer riktig informasjonsflyt og økt effektivitet i mottakende prosess.

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

TriggerKunngjøringen 
Andre forutsetninger

Leverandør har satt opp riktig søkekriterier i sitt system.

​​10. Input og leverandører

InputAvleverende prosess: Leverandør/avsender - organisasjonReferanse
KunngjøringenEHF kunngjøring  prosess Publiseringsdatabaser som Doffin og TED  
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
LeverandørSystemL-sys  
Publiseringstjeneste SystemPub 
    

12. Prosessdiagram

EHF Søk kunngjøring
 
 

EHF Søk kunngjøring (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
 1. Systemsøk i publiseringsdatabasebasert på CPV-koder L-sys   
 2. Send forespørsel om kunngjøringerL-sys   
 3. Søk i databasen og samle alle kunngjøringer relatert til CPV Pub   
 4. Organiser kunngjøringer og pakk de sammen i forsendelsekontainer Pub   
 5. Motta alle kunngjøringer som tilhører CPV gruppe L-sys   
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
Nei   

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Kunngjøring vist i leverandør systemEnten EHF vis interesse proses eller EHF utsendelse av anskaffelsedokumet prosessLeverandør 
    

16. Sluttkriterier

Nei

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Nei    

19: Behov for støtte

StøtteForklaring/Lenker
Behov for prosessopplæring. 
Behov for systemopplæring 

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Når EHF foreligger vil du finne spesifikasjoner her:  https://anskaffelser.dev

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF vise interesse

EHF vise interesse lar leverandører standardisere førespurnader til oppdragsgjevar om å få tilsendt konkurransedokument.

Status for formatet

EHF Under planlegging. PEPPOL BIS i produksjon

Føremål og verkemåte: Standardisering av førespurnader om konkurransedokument

Forskrift om offentlege innkjøp sikrar at alle leverandørar skal ha gratis, direkte og uavgrensa tilgang til konkurransegrunnlagsdokumenta (§14-3-1).

Meininga med EHF Vise interesse er at leverandørar via sitt eige datasystem, skal kunne varsle oppdragsgjevar om at dei ønskjer å få tilsendt konkurransedokument.

Oppdragsgjevarar får dermed ei standardisert og strukturert melding inn i sitt konkurranseinnleveringsverktøy. Neste steg i prosessen for oppdragsgjevar blir då å sende ut konkurransedokumenta på ein mest mogleg strukturert måte, så leverandørane opplever oppdragsgjevarane mest mogleg like i sin måte å kommunisere på, samt kunne nyttiggjere seg av den strukturerte konkurranseinformasjonen i sine eigne system.

Fordelar

For oppdragsgjevarar

  • Ta i mot alle førespurnader inn i sitt system på ein strukturert og standardisert måte, mellom anna informasjon om kvar ein skal sende innkjøpsdokumenta.
  • Sikre at alle leverandørar som har vist interesse får tilsendt dei same dokumenta.

For leverandørar

  • Kunne informere oppdragsgjevarar på ein standardisert og strukturert måte, via sitt eige datasystem, om at dei ønskjer å delta i konkurransen.
  • Innsparingar som følgje av redusert tidsbruk når formatet blir brukt ved kommunikasjonen mellom ulike system. 

Teknisk informasjon om bruk av formatet

EHF vise interesse for anskaffelse prosess

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF Vise interesse for anskaffelse 
Prosess IDX315
OrganisasjonDFØ-ANS
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.08.14Dokument etablertPetter Vinje
    
    
    

3. Om prosessenI

Vise interesse er en prosess hvor leverandør sender melding til oppdragsgiver for å vise interesse for en anskaffelse.  

4. Brukere og bruksområde 

Brukere

Leverandør: Trenger prosessen for å bli registrert i oppdragsgivers system for derigjennom å bli oppdatert på anskaffelsen.  

Oppdragsgiver: Trenger prosessen for å få oversikt over leverandører som er interessert i anskaffelsen.    

5. Formål

Gjøre det enkelt for leverandør å vise interesse for anskaffelsen. Og tilrettelegge for en elektronisk samhandling mellom oppdragsgiver og leverandør i anskaffelsen. 

6. Mål

Effektivisere informasjonsflyt mellom oppdragsgiver og leverandør for den enkelte anskaffelse.  

7. Gevinster

Oppdragsgiver: Maskinelt kan behandle interessenter og derigjennom effektivisere utførelsen av prosessen. 

Leverandør: Får rask og riktig informasjon som basis for beslutning om deltagelse i anskaffelsen. 

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

Trigger

  Kunngjøring av anskaffelse 

Andre forutsetninger

Oppdragsgiver og leverandører har systemer som støtter den digitale prosessen.   

​​10. Input og leverandører

InputAvleverende prosess: Leverandør/avsender - organisasjonReferanse
Informasjon i kunngjøringen EHF kunngjøringprosessOppdragsgiver 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
Oppdragsgiver SystemO-sys  
LeverandørPersonL-per  
LeverandørSystemL-sys  
    

12. Prosessdiagram

EHF vise interesse for anskaffelse
 
 

EHF vise interesse for anskaffelse (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
 1. Lag underlag om melding for å vise interesse L-per    
 2. Send vis interesse for konkurranse L-sys    
 3. Lagre leverandør som har vist interesse i database O-sys    
 4. Motta bekreftelsen L-sys    
      
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
Nei   

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Oversikt for oppdragsgiver over leverandører som har vist interesse.  Utsendelse av anskaffelsesdokumenter dersom leverandør ønsker det.Oppdragsgiver 
Kvittering for melding om vist interresse En ev. Innsendelse av forespørsel om anskaffelsesdokumenter Leverandør 

16. Sluttkriterier

Nei

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Nei    

19: Behov for støtte

StøtteForklaring/Lenker
Behov for prosessopplæring. 
Behov for systemopplæring 

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://docs.peppol.eu/pracc/  

Når EHF foreligger vil du finne spesifikasjoner her:  https://anskaffelser.dev/.

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF anskaffelsesdokument

EHF anskaffelsesdokument lar oppdragsgiver lage strukturerte, maskinlesbare konkurransedokumenter.

Status for formatet

I produksjon

Formål og virkemåte: Digitalisere konkurransedokumentene fra oppdragsgiver

Formatet er en start på å kunne gjøre mer og mer av innholdet i konkurranser maskinlesbart. Basert på europeisk standardisering og pilotering vil formatet kunne inneholde viktig informasjon som gjenbrukes av leverandører i deres systemer for innlevering.

Formatet vil gjøre det mulig for leverandører å få informasjon fra konkurransedokumentene inn i sine egne systemer. De kan dermed besvare krav og behov som oppdragsgiver har definert, ved hjelp av strukturerte data.

Formatet tilrettelegger for inkludering av forskjellige meldinger basert på det behov oppdragsgiver har. Veilederen gir informasjon om hvordan sending av overordnet konkurranseinformasjon og hvordan vedlegge standardformater som det europeiske egenerklæringsskjema (ESPD Request) og for ytelsesbeskrivelser via EHF forespørselskatalog (pre-award catalogue request), beskrives og inkluderes. Andre dokumenter som tilhører anskaffelsesdokumentene vil etterhver bli maskinlesbare ved at de blir etablert som EHF.

Fordeler med å ta i bruk formatet

For oppdragsgivere

  • Dersom prosessene som går forut for utarbeidelse av konkurransedokumentene er elektroniske, vil oppdragsgiver kunne sende ut konkurransegrunnlag på et maskinlesbart format til alle leverandører som har vist interesse, via sitt konkurransesystem.
  • Oppdragsgivers system trenger ikke å vedlikeholde manuelle e-postlister, fordi alle mottakere ligger i felles adresseregister (SML/SMP/ELMA).
  • Hvis oppdragsgiver har vurdert at konkurranseinnsendingen skal være kryptert, inkluderes den offentlige nøkkelen leverandørene trenger til å kryptere innsendingen i EHF anskaffelsesdokument.  
  • Ved at formatet kan inkludere EUs egenerklæringsskjema (ESPD request) i et maskinlesbart format, kan leverandørens system importere skjemaet.  
  • Det samme gjelder EHF forespørselskatalog, der leverandørens system kan importere og lagre generisk vare- og tjenesteinformasjon fra oppdragsgiver, og inkludere det i sin informasjon ved innlevering av tilbud.

For leverandører

  • Ved at leverandør benytter et innleveringssystem har man muligheter til å importere strukturert informasjon og la sitt system pre-fylle informasjon fra oppdragsgivers konkurransedokumenter.
  • På en enkelt måte kunne kryptere tilbudet ved at krypteringsnøkkelsen ligger i et strukturert format.

EHF utsendelse av anskaffelsedokument prosess 

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF utsendelse av anskaffelsedokument prosess 
Prosess IDX316 Tilgjengeliggjøre/sende anskaffelsesdokumenter 
OrganisasjonDFØ-ANS
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.08.19Dokument etablertPetter Vinje
    
    
    

3. Om prosessen

EHF utsendelse av anskaffelsedokumenter prosess, er en prosess hvor leverandør sender en forespørsel om oppdragsgiver kan sende anskaffelsesdokumentene til sitt system. Oppdragsgivers system sender anskaffelsedokumenten til leverandøren. Leverandør system bekrefter mottak av anskaffelsedokumentene.   

4. Brukere og bruksområde 

Leverandør har behov for å få informasjon som er maskinlesbart.  

Oppdragsgiver trenger prosessen for å effektiv sende ut anskaffelsedokumenter i maskinlesbart format til riktig leverandør(er).  

5. Formål

Høyne kvalitet på informasjonsinnhold. Samt tilrettelegge for at leverandør kan effektivisere sine prosesser.

6. Mål

Få en mest mulig optimal prosess som kan stimulere til økt deltakelse.  

7. Gevinster

Leverandør:

  • Enklere å besvare en anskaffelse. 

  • Mer effektive prosesser – spare tid og ressurser.  

  • Sannsynligheten for å vinne anskaffelser øker.  

Oppdragsgiver

  • Sikre at leverandør mottar og gir riktig informasjon.  

  • Mer effektive prosesser – spare tid og ressurser.  

  • Sikrer økt kvalitet og effektivitet i mottakende prosess(innleveringsprosessen). 

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

Trigger

  Har lest kunngjøringen som de finner interessant.

Andre forutsetninger

Må ha system som kan motta standard format.

​​10. Input og leverandører

InputAvgivende prosess: Leverandør av inputReferanse
Kunngjøringen Doffin/TED  
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer

Oppdragsgiver 

System 

o-sys 

 

Leverandør 

Person 

l-per 

 

Leverandør 

System 

l-sys 

 
    

12. Prosessdiagram

EHF utsendelse av anskaffelsesdokumenter
 
 

EHF utsendelse av anskaffelsesdokumenter (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
 1. Legg inn kunngjøringsreferanse i system for å kunne be om riktige dokumenter for anskaffelsen L-per   
 2. Forespørsel om anskaffelsedokumenter sent L-sys    
 3. Sjekk kunngjøringsreferanse og klargjør de aktuelle dokumenter for sendingO-sys   
 4. Motta anskaffelsedokumenterL-sys    
 5. Klargjør bekreftelse på mottatt forsendelseL-sys   
 6. Bekreftelse sent L-sys   
 7. Lagre mottaksbekreftelseO-sys   
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
Nei   

15. Output og mottaker/bruker

OutputMottakende prosess:Mottaker/brukerReferanse
Mottatt anskaffelsesdokumenter  Leverandør 
    

16. Sluttkriterier

Nei

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Nei    

19: Behov for støtte

StøtteForklaring/Lenker
Behov for prosessopplæring og systemopplæring.   
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Når EHF er utviklet vil du finne de her https://anskaffelser.dev/

Lenke: https://docs.peppol.eu/pracc/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF spørsmål og svar

EHF spørsmål og svar lar oppdragsgiver og leverandør sende spørsmål og svar som strukturerte EHF-data, heller enn å bruke e-post.

Status for formatet

Under planlegging.

Formål og virkemåte: Kommunisér via strukturerte EHF-data, ikke på e-post

Det er klare regler for kommunikasjonen i selve konkurransegjennomføringsprosessen. Leverandører som ønsker å få belyst detaljer i anskaffelsesdokumentene skal få svar av oppdragsgiver. Det er et krav om at alle leverandører som deltar i konkurransen får tilsendt spørsmålet og svaret fra oppdragsgiver. Oppdragsgiver må vurdere om spørsmålet fra leverandør er konkurransesensitivt og dermed må redigeres.  

Målet med EHF spørsmål og svar er å få denne kommunikasjonen flyttet fra e-post, over til bruk av strukturerte EHF-data, slik at oppdragsgiver og leverandør kan benytte sine egne systemer for mottak av og svar på meldinger via PEPPOL eDelivery og adresseregisteret ELMA.

EHF Spørsmål og svar vil kunne benyttes i konkurransegjennomføringsprosessen og i kontraktsoppfølgingsprosessen

Målet er sikre at kommunikasjonen skjer i henhold til regelverk, lagre kommunikasjonen så den eventuelt kan gjenbrukes i andre konkurranser via eks. chat-roboter og slippe kostbart vedlikehold av e-postlister.

Fordeler med å ta i bruk formatet

For oppdragsgivere

  • Unngå at du ikke mottar e-poster fordi du oppgav feil e-post adresse i anbudet.
  • Unngå å glemme å informere alle deltakerne om spørsmål og svar underveis i anbudsprosessen.  
  • La konkurranseverktøyet styre utsendingen av og dokumentere spørsmål og svar.

For leverandører

  • Gir mulighet til å benytte sitt eget system for spørsmål og svar relatert til det enkelte anbud og lagre disse for læring.
  • Gir trygghet for mottakers adresse ved at de ligger i ett adresseregister (ELMA-SMP)

EHF spørsmål og svar prosess

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF spørsmål og svar prosess
Prosess ID 
OrganisasjonDFØ-ANS
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.07.02Dokument etablertPetter Vinje
    
    
    

3. Om prosessen

I denne sammenheng har valgt å ta utgangspunkt i den generiske prosessen og beskrive spesielt spørsmål og svar i konkurransegjennomføring.  

Spørsmål og svar i konkurransegjennomføring:  

Prosessen begynner med at leverandører leser gjenom innholdet i kunngjøringsdokumentene eller anskaffelsesdokumentene og får behov for avklaringer. Leverandør sender spørsmål til oppdragsgiver. Oppdragsgiver mottar spørsmålene, formulerer svar, anonymiserer navn på spørsmålsstiller og innholdet i spørsmålet før dette lagres og sendes alle interessenter til konkurransen.  

I alle andre prosesser mottas spørsmål og sendes svar til spørsmålstiller.  

4. Brukere og bruksområde 

Brukere

Leverandør og oppdragsgiver har behov for denne prosessen når det er behov for avklaringer.

Bruksområde

I alle prosesser der det er behov for avklaringer

5. Formål

Sikrer felles forståelse – unngå misforståelser, feil, etc.

6. Mål

Få til effektiv kommunikasjon basert på strukturert informasjon. Gjøre det enklere å dokumentere kommunikasjon. Gjenbruke spørsmål og svar i andre prosesser slik som spørsmål og svar på nettsider. Forenkle og effektivisere Statistikk, Analyse og forbedringsarbeid.

7. Gevinster

Oppdragsgiver: Slipper å vedlikeholde mail-lister – sparer tid og ressurser. Får automatisk en liste over leverandører som deltar i konkurransen slik at du kan sikre at alle får svar, og for ettertiden kan dokumentere det i systemet.  Dette reduserer tidsbruk og reduserer/eliminerer risiko for feil. Dokumentasjonen kan benyttes som grunnlag for utarbeidelse av statistikk og i forbedringsarbeid. Fordi informasjonen ligger i systemet tilgjengelig for alle i virksomhetens anskaffelsesavdeling, unngås problemet som oppstår når informasjon lagres lokalt. – for eksempel ved sykdom, ferier, etc 

Leverandør: Gi mulighet til å benyttes sitt eget system til spørsmål og svar og lagre dette for egen dokumentasjon og læring. All informasjon om anskaffelsen blir dokumentert og lagret sentralt – enklere for alle å få tilgang til informasjonen og gjenbruke den i nye anskaffelser, ved utarbeidelse av statistikk, forbedringsarbeid, etc.   

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

Trigger

   Anskaffelsesdokumenter er mottatt eller kunngjøring funnet på Doffin eller andre avklaringer må bli gjort 

Andre forutsetninger

Begge – leverandør og oppdragsgiver må ha et system som det er gitt opplæring i

​​10. Input og leverandører

InputAvgivende prosess:Leverandør av inputReferanse
KunngjøringKunngjøringDoffin-TED 
AnskaffelsesdokumenterUtsendelse av anskaffelsesdokumenter Oppdragsgivers KGV  
Andre avklaringerAlle prosesser i AnskaffelsesprosessenOppdragsgiver eller leverandørs systemer som dekker andre deler av prosessen 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer

Oppdragsgiver 

Person 

o-per 

 

Oppdragsgiver 

System 

o-sys 

 

Leverandør 

Person 

l-per 

 

Leverandør 

System 

l-sys 

 
    

12. Prosessdiagram

EHF spørsmål og svar
 
 

EHF spørsmål og svar (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
 1. Forbered spørsmål L-per eller O-per   I konkurransegjennomføring er det som regel leverandør. Mens det i kontraktsoppfølgningen kan være både oppdragsgiver og leverandør som stiller spørsmål.
 2. Sende spørsmåL-sys eller O-sys Systemspesifikk  
 3. Besvare spørsmål L-per eller O-per  Dette er en del-prosess som utføres av en person som benytter et system. Omfanget av prosessen vil variere.x

NB! I Konkurransegjennomføringsprosessen er det pålagt oppdragsgiver å inkludere leverandørens spørsmål i svaret og at svaret gis alle interessenter i anskaffelsen.  

Oppdragsgiver må vurdere om spørsmål fra leverandør skal anonymiseres av hensyn til konfidensialitet

 4. Motta svar O-sys eller L-sys Systemspesifikk  
 5. Lagre spørsmål og svar O-sys eller L-sys Systemspesifikk  
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
3Dersom du må anonymisere må du kontrollere at dette er gjort riktig.Gjøres manueltDersom informasjon som skulle vært anonymisert blir publisert kan det få store konsekvenser for både leverandør og oppdragsgiver.
    

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Dokumentasjon – spørsmål og svar. Dette er en generisk prosess som kan benyttes av andre prosesser.Oppdragsgiver og/eller leverandør.  
    

16. Sluttkriterier

Nei

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
I konkurransegjennomføringsprosessen er det lovpålagt å sende ev. anonymiserte spørsmål og svar til alle interessenter. 

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
I aktivitet 3 er det risiko for at informasjon ikke blir anonymisert.  Lav/medium HøyVed bruk av system vil risiko reduseres.System må bygge inn støtte for å minne oppdragsgiver på å anonymisere.

19: Behov for støtte

StøtteForklaring/Lenker
Behov for opplæring i system og offentlige anskaffelser 
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Foreløig ikke utviklet EHF. EHF spørsmål og svar vil bli lagt på følgende adresse: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF kvalifisering

Status for formatet

Under utvikling.

Formål og virkemåte: Leverandører kan sende inn kvalifiseringsdokumenter via eget system

I toleddet prosedyre må leverandører kvalifisere seg for å være med i konkurransen. Dette gjelder også i en Dynamisk innkjøpsordning (DPS).

EHF kvalifisering legger til rette for at leverandøren skal kunne gjøre dette via sitt eget system, ved å sende kvalifiseringsdokumenter til oppdragsgiver via PEPPOL eDelivery.

Formatet er tilrettelagt for å inneholde EUs egenerklæringsskjema (ESPD Response) som en egen strukturert fil. Ved utlysning av anbud med begrenset prosedyre, kan dermed en leverandør sende inn både strukturerte og ikke-strukturerte kvalifikasjonsdokumenter. Prosessen ekskluderer ikke andre strukturerte dokumenter hvis dette støtter oppunder oppdragsgivers behov for dokumentasjon.

Prosessen kan også tas i bruk for dynamisk innkjøpsordning (DPS) der ESPD request og response er sentrale elementer i en kvalifisering.

Fordeler med å ta i bruk formatet

For oppdragsgivere

  • Dersom du bruker formatene EHF kunngjøring og EHF anskaffelsesdokument, har du standardisert og maskinlesbar informasjon som du kan sende til leverandørene.
  • Data du mottar i retur fra leverandører på samme format, kan i sin tur brukes til automatisert evaluering av kvalifikasjonskravene i ditt eget konkurranseverktøy. 

For leverandører

  • Formatet gjør det mulig å automatisere utfylling av maskinlesbar informasjon sendt fra oppdragsgiver. Eksempel på dette er EUs egenerklæringsskjema (ESPD Request og Response) som kan importere kravene og sende et tilsvar automatisert. Dette vil øke effektiviteten hos tilbyder og dermed senke besvarelseskostnadene.

EHF kvalifisering prosess

 Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF kvalifiseringsprosess  
Prosess IDX32 kvalifisere leverandører
OrganisasjonDFØ-ANS
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.08.21Dokument etablertPetter Vinje
    
    
    

3. Om prosessen

Dette er en prosess hvor leverandør sender inn svar på kravene til oppdragsgiver for å kunne kvalifisere seg for anskaffelsen. Dersom han er kvalifisert mottar han en bekreftelse på dette. Hvis ikke kan du rette opp feil og kvalifisere på nytt dersom det er en DPS prosess

4. Brukere og bruksområde 

Oppdragsgivere trenger prosessen når de skal redusere antall tilbydere. I DPS benyttes prosessen for å få oversikt over de leverandører man skal sende forespørsler til.  

For leverandør er dette en måte å gjøre seg tilgjengelig for oppdragsgiver for å få tilsendt forespørsler i DPS.  

5. Formål

Ha mulighet til å redusere antall tilbydere i en anskaffelse. Kvalitetsikre om krav for å kunne delta i en konkurranse er innfridd før selve besvarelse og innsendelse av konkurransedokumenter har funnet sted. Og kunne ha en leverandørdatabase for å kunne sende forespørsler i henhold til DPS. Kunne sjekke krav som er stilt.  

6. Mål

  • Få en digital, effektiv kvalifiseringsprosess.  

  • Likebehandling av alle leverandører.  

  • Sikre tilstrekkelig informasjon for å kunne sjekke bevis i henhold til krav.

7. Gevinster

Oppdragsgiver: Mye mer effektiv prosess – sparer tid og ressurser. Riktig dokumentasjon fra leverandør. Informasjon innhentes kun én gang – «Once only principle». Ved bruk av maskinlesbare formater (EHF) i transaksjonene kan systemet foreta en automatisk evaluering av oppfyllelse av krav stilt i kvalifiseringen.  Legger til rette også for en automatisert bevisinnhenting (eBevis prosess) fra offentlige databaser. 

Leverandør: Mer effektiv prosess – redusert bruk av tid og ressurser når system automatisk fyller ut de krav som oppdragsgiver stiller. Synliggjøre sin interesse overfor oppdragsgiver. Spesielt ved DPS.

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

DPS (Dynamic Purchasing System) = Dynamisk innkjøpsordning

9. Startkriterier/forutsetninger

Trigger Beslutning om å benytte to-ledded prosedyre eller DPS
Andre forutsetninger

Kompetanse på prosdyrevalg og bruk av digitale verktøy

​​10. Input og leverandører

InputAvleverende prosess: Leverandør/avsender - organisasjonReferanse
Anskaffelsesdokumenter X316Tilgjengligjøre/sende anskaffelsesdokumenter  Oppdragsgiver 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolleForkortelserKommentarer
Oppdragsgiver PersonO-per  
Oppdragsgiver SystemO-sys 
LeverandørPersonL-per  
LeverandørSystemL-sys 
    

12. Prosessdiagram

EHF kvalifisering prosess
 
 

EHF kvalifiseringsprosess (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
 1. Fyll inn tilsendt EHF ESPD request og andre dokumenter som kreves i kvalifiseringen L-per   
 2. Kvalifiseringsdokumenter sent L-sys   
 3. Generer en bekreftelsesmelding O-sys   
 4. Sjekk bevis i offentlige eller private databaser O-sys/O-per   
 5. Kvalifisering mottaksbekreftelse er mottatt L-sys   
 6. Motta respons L-sys   
 

7. Kvalifisere på nytt i DPS 

L-per   
 8. Besvar anskaffelsesdokumenterL-per   
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
4. Sjekk bevis i offentlige eller private databaser Krav oppdragsgiver har stilt for å kunne kvalifisere seg inn. Benytte eBevis tjenesten som automatisk sjekker bevis i offentlige databaser. Unngå blant annet arbeidslivskriminalitet. Og sikre god soliditet i leverandørmassen.
    

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Leverandører innlag i kvalifiseringsdatabase.  X348 Send inn tilbud. Oppdragsgiver 
Leverandører innlag i kvalifiseringsdatabase.  X316Tilgjengligjøre/sende anskaffelsesdokumenter (DPS).Leverandør 
    

16. Sluttkriterier

Nei

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Nei    

19: Behov for støtte

StøtteForklaring/Lenker
Behov for prosessopplæring. 
Behov for systemopplæring 

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Format EHF ikke ferdig utviklet. Når den er klar vil den bli publisert her: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF eBevis

EHF Dokumentasjonsbevis lar oppdragsgjevar automatisere innhenting og kontroll av bevis for at kvalifikasjonskrava er oppfylte.

Status for formatet

I produksjon

Føremål og verkemåte: Automatisering av innhenting av bevis

EHF Dokumentasjonsbevis skildrar prosessen der oppdragsgjevar skal sjekke opplysningane leverandør har gjeve opp i konkurransen. Det er oppdragsgjevar sitt ansvar å hente inn bevis for at opplysningane er riktige.

Kjelder for bevis vil typisk vere offentlege databasar, men det kan i tillegg vere leverandørspesifikke bevis som oppdragsgjevar må få direkte frå leverandør. Ved elektronisk førespurnad bør ein bruke same format for førespurnad og retur av bevis. 

Fordelar med å ta i bruk formatet 

For oppdragsgjevarar

  • Oppdragsgjevarar vil kunne få tilgang til kvalifikasjonsdokumentasjon frå offentlege register i sanntid, noko som kan gje store innsparingar.
  • Oppdragsgjevarar vil kunne kontrollere dokumentasjonsbevis på ein enklare måte.
  • Formatet gjer det mogleg at dokumentasjonsbevisa blir leverte inn på eit standardisert format (EHF), slik at «bevispakka» kan lesast direkte inn i oppdragsgjevar sitt IT-system.

 For leverandørar

  • Leverandørar vil oppnå store innsparingar knytte til tid, sidan dei berre treng å gje samtykke til at bevis blir kontrollerte ved innlevering av skjemaet "ESPD response", i staden for sjølv å hente inn oppdaterte bevis og sende dei inn saman med tilbodet sitt.

  • Leverandøren vil også få betre oversikt over kva slags bevis som er henta inn av kven, ved at han får gjenpart av dokumentasjonen oppdragsgjevarane har henta inn i Altinn.

Totalt sett vil dette forenkle dagens manuelle og papirbaserte arbeidsflyt monaleg, både for leverandørar og oppdragsgjevarar.

 

EHF eBevis prosess

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF eBevis prosess 
Prosess ID 
OrganisasjonDFØ-ANS
Prosess eierHilde Kjølset
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.06.03Dokument opprettetJan Mærøe
    
    
    

3. Om prosessen

eBevis eller «Hente bevis» er en prosess der oppdragsgiver digitalt og i sanntid kan innhente bevis/dokumentasjon fra leverandører relatert til den spesifikke anskaffelsen. Bevisene/dokumentasjonen kan gjelde avvisningsgrunner eller kvalifikasjonskrav enten i kvalifikasjons- eller i kontraktsoppfølgningsfasen. Mange av bevisene/dokumentasjonen er basert på det europeiske egenerklæringsskjemaet (ESPD). Beviskilden kan både være offentlige databaser, sertifiseringsdatabaser eller leverandørspesifikke baser. 

4. Brukere og bruksområde 

Brukere

Kan brukes av offentlige oppdragsgivere ved alle former for anskaffelsesprosedyre.

Bruksområde

Kan brukes over og under terskelverdi.  

Kan brukes både ved konkurransegjennomføring/kvalifisering og ved kontraktsoppfølging

5. Formål

Hovedformålet er at du skal kontrollere dokumentasjon på at leverandører er kvalifisert jfr. LOA/FOA.

6. Mål

At oppdragsgiver henter inn informasjonen som det offentlige har ansvar for kun én gang – “once-only- principle” 

7. Gevinster

Oppdragsgiver: Forenkle og effektivisere innhenting av bevis i anskaffelsesprosessen. Sikre at oppdragsgivers bevisinnhentingsprosess er i henhold til LOA/FOA. Redusert mulighet for at leverandører kan forfalske dokumenter – hentes direkte fra kilden. Enklere dokumentasjonsprosess. Enklere å gjenbruke maskinlesbar informasjon. Enklere kontraktsoppfølging.

Leverandør:Redusere arbeidsbelastning for leverandør ved at oppdragsgiver henter inn dokumentasjon selv fra offentlige eller andre databaser. Enklere for leverandør å formidle leverandørspesifikke beviser.  

Systemleverandør: Tilby markedet nye tjenester.  

Samfunn: Forebygge arbeidslivskriminalitet. Betydelig effektiviseringsgevinst. Stimulere til seriøsitet i markedet. Enklere kontraktsoppfølging. 

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

Trigger

>Melding eller manuell start. eBevis er en del av kvalifiseringsprosessen og kontraktsoppfølgingsprosessen. For DPS vil prosessen trigges automatisk. For andre anskaffelsesprosedyrer vil det være en person eller system som setter i gang eBevis-prosessen.   

>Systemteknisk/tidsintervall. eBevis kan også trigges basert på tidsintervall som en del av kontraktsoppfølgingsprosessen. Triggeren vil mest sannsynlig være definert i KGV basert på en risikovurdering per anskaffelse.   

Andre forutsetninger

>EHF ESPD/EHF egenerklæringsskjema skal være fylt ut 

  

​​10. Input og leverandører

InputAvleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tomLeverandør/avsender - organisasjonReferanse
EHF ESPD; EHF egenerklæring Innlevering av tilbud og kontraktsoppfølgingsprosessenLeverandør 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer

Oppdragsgiver 

Person 

o-per 

 

Oppdragsgiver 

System 

o-sys 

 

Leverandør 

Person 

l-per 

 

Leverandør 

System 

l-sys 

 
Leverandør lNår aktiviteten kan utføres av person eller system brukes kun l 
eBevis tjenesten SystemeBT-sys  
Offentlige beviskilderSystemOff-sysOmfatter offentlige og leverandørdatabaser
    

12. Prosessdiagram

eBevis prosessen
 
 

EHF eBevis prosess (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarBeskrivelse

KP (x)

Kommentar
 1. Tolke ESPD, egenerklæringsskjema eller andre kravo-sys >Systemet ser på ESPD, egenerklæringsskjema eller andre input til krav og identifiserer hvilke bevis som skal hentes/sjekkes.  
 2. Forberede eBevis/Get evidenceo-sys

>Lage og sende eBevis melding basert på ESPD, egenerklæringsskjema eller andre input til krav.  

>Validere i henhold til EHF eBevis

  
 3. Vurdere meldingsinnholdeBT-sys 

>Lese eBevis melding. 

>Kontrollere at avsender har lov til å innhente bevis.  

>Definere hvilke bevis som krever samtykke.  

>For bevis som krever samtykke sende forespørsel om samtykke via Altinn.  

>For bevis som ikke krever samtykke, sende forespørsel til beviskilde. 

x 
 4. Beslutte samtykkel-per

>Leverandør tar beslutning om samtykke via Altinn.  

>Leverandør beslutter Ja til samtykke om at bevis kan hentes via eBevis. 

>Leverandør beslutter Nei til samtykke forutsetter manuell innlevering av bevis eller at leverandør vurderes avvist . 

>Svarer ikke

  
 5. Forespørre bevis fra avgivende kildeeBT-sys>Sende forespørsel.  
 6. Henter ut relevante bevisoFF-sys>Systemet henter informasjonselementer fra avgivende kilde.   
 7. Populere EHF eBevis responseBT-sys>Systemet sammenstiller informasjonselementer fra avgivende database og lager EHF eBevis respons.  
 8. Motta bevisoFF-sys 

>Mottar EHF eBevis respons og presenterer resultatet for bruker, for eksempel et ok-signal.  

>Arkivere eBevis respons

  
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
3>Kontrollere at avsender har lov til å innhente bevis. Systemet sjekker om leverandør har gitt samtykkeSkal ivareta leverandørs rettigheter.
    

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Dokumentasjon for kvalifikasjonskrav og avvisningsgrunner>Vurdering/evaluering av kvalifikasjon i henhold til krav (ikke definert prosess)>Oppdragsgiver 
  >Kontraktsoppfølgingssystem 
    

16. Sluttkriterier

>Alle definerte bevis må være innhentet og tilgjengeliggjort for neste prosess.

>De som ikke har gitt samtykke har fått purring slik at de formelt sett kan vurderes om de skal avvises.  

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
I offentlige eller andre databaser kan bevis innhentes manuelt

>Hvor det ikke finnes bevis i offentlige databaser.  

>KGV har ikke implementert eBevis tjeneste (støtte for) 

>Oppdragsgiver har ikke kjøpet modul for eBevis. 

  

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Risiko for at leverandør leverer bevis manuelt i stedet for samtykke til utleveringlavlav >Regelverksendring for å muliggjøre uthenting av informasjon uten forhåndssamtykke fra leverandør.
Nedetid ut over definerte SLA krav.lavmiddels >Prosess for avviksmelding hos Brønnøysund registrene.
Valideringsfeillavlav 

>Kontakt systemleverandør. 

>Krev at systemleverandør følger forvaltning av format VEFA.

     

19: Behov for støtte

StøtteForklaring/Lenker
Behov for prosessopplæring.   
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://vefa.difi.no/ehf-egov/specs/ehf-get-evidence-1.0.0/

21. Tilleggsinformasjon

Nei

22. Vedlegg

ReferanseTekst og/eller lenke 
Lov og forskrift 

Forskrift om offentlige anskaffelser  

https://lovdata.no/dokument/SF/forskrift/2016-08-12-974/KAPITTEL_3-6#%C2%A717-1 

https://lovdata.no/dokument/SF/forskrift/2016-08-12-974/KAPITTEL_3-13-2#%C2%A724-7

eBevis, anskaffelsesfaglig veiledning:https://www.anskaffelser.no/anskaffelsesprosessen/anskaffelsesprosessen-steg-steg/konkurransegjennomforing/velge-tilbud-og-innga-avtale/vurdere-kvalifikasjoner/ebevis-0
Beskrivelse av eBevis-tjenesten som datadelingstjeneste hos Brønnøysundregistrene:https://www.brreg.no/offentlig-sektor/enklere-offentlige-innkjop-med-ebevis/
Teknisk beskrivelse av eBevis (data.altinn.no) hos Digitaliseringsdirektoratet:  https://ebevis.no/
Teknisk beskrivelse av samtykke hos Digitaliseringsdirektoratet:https://altinn.github.io/docs/utviklingsguider/samtykke/
Lenke til EHF Get evidence:https://vefa.difi.no/ehf-egov/specs/ehf-get-evidence-1.0.0/ 
Lenke til referansekatalogen:https://www.digdir.no/digitale-felleslosninger/digitale-anskaffelser/1486 

 

EHF i innleveringsprosessen

Elektronisk innlevering lar leverandør automatisere utfyllingen av anskaffelsesdokumenter basert på utsendelse fra oppdragsgiver.  Oppdragsgiver kan automatisk evaluere de strukturerte dokumentene som sendes fra leverandør

Status for formatet

I produksjon

Formål og virkemåte: Automatisering av innlevering av anskaffelsesdokumenter

En innlevering av et tilbud består av en rekke dokumenter.  Prosessteget innlevering finnes i alle prosedyrer. Det er oppdragsgiver som generer anskaffelsesdokumentene som danner grunnlaget for leverandørs tilbud.  Derfor opererer EHF med recuest (forespørsel) og response (svar) for å skille mellom meldingene som kommer fra oppdragsgiver og leverandør.  Innleveringsmeldingen består av en hovedtransaksjon samt andre transaksjoner som beskriver deler av forespørselen. Noen formater er i produksjon og noen er under planlegging.  Målet er å redusere antall PDF dokumenter og erstatte de med strukturerte formater.  Følgende meldinger kan være representert i en innlevering:

  • Hovedtransaksjon (EHF/PEPPOL BIS T005 Tender) med kvitteringsmelding ( EHF/PEPPOL BIS T005 Tender Receipt Notification)
  • EHF ESPD response
  • EHF Tilbudskatalog
  • Kontrakt
  • Andre anskaffelsesdokumenter

Fordeler med å ta i bruk formatet 

For oppdragsgjevarar

  • Oppdragsgiver vil kunne sammenligne tilbud på strukturert dokumentnivå.
  • Oppdragsgiver vil kunne automatisk evaluere de dokumenter som er maskinlesbare
  • Oppdragsgiver vil kunne lagre og gjenbruke strukturerte dokumenter i andre konkurranser og for dokumentforvalning
  • Oppdragsgiver vil kunne sende kvitteringsmeldinger til leverandørs systemer.

 For leverandører

  • Leverandør vil kunne fylle ut besvarelser basert på lagret informasjon i sitt system og fra anskaffelsesdokumentene som for eksempel EHF forespørselskatalog som inneholder standard klassifiseringskoder på vare og tjenester.
  • Leverandøren vil få en bedre oversikt over innleverte tilbud ved at de benytter eget system.
  • Leverandøren får kvitteringsmeldinger direkte inn i sitt system som reduserer usikkerhet om innleveringen har gått bra.

Totalt sett vil dette forenkle dagens manuelle og papirbaserte arbeidsflyt, både for leverandører og oppdragsgivere.

EHF tilbudsinnlevering prosess

 Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navn EHF tilbudsinnlevering prosess 
Prosess IDX351 Ta imot tilbud 
OrganisasjonDFØ-ANS
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.08.26Dokument etablertPetter Vinje
    
    
    

3. Om prosessen

Leverandør har fylt ut alle anskaffelsesdokumentert og levert inn tilbud før fastsatt tidsfrist.

4. Brukere og bruksområde 

Leverandør trenger prosessen for å tilby sine varer og tjenester i henhold til de krav oppdragsgiver har satt.  

Oppdragsgiver trenger prosessen for å ta imot anskaffelsesdokumenter i et maskinlesbart format.   

5. Formål

Hovedhensikten er å forbedre eksisterende innleveringsprosess

6. Mål

  • Få flere tilbydere.  

  • Øke kvalitet på informasjon.  

  • Økt grad av automatisk evaluering – mindre bruk av tid og ressurser.  

7. Gevinster

Oppdragsgiver: Riktig informasjon fra leverandør. Ved bruk av EHF i denne prosessen har du mulighet til å foreta automatisk evaluering som igjen sparer tid og ressurser. Og sikrer riktig informasjonskvalitet. Redusert risiko for klager.

Leverandør: Automatisert prosess sikrer kvalitet og effektivitet – sparer tid og ressurser.  

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

TriggerMottak av anskaffelsesdokumenter 
Andre forutsetningerLeverandør har eget system der han kan motta og behandle digitale anskaffelsesdokumenter.  

​​10. Input og leverandører

InputAvleverende prosess: Leverandør/avsender - organisasjonReferanse
Anskaffelsesdokumenter X348 Send inn tilbudOppdragsgiver 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolleForkortelserKommentarer
Oppdragsgiver PersonO-per  
Oppdragsgiver SystemO-sys 
LeverandørPersonL-per  
LeverandørSystemL-sys 
    

12. Prosessdiagram

EHF tilbudsinnlevering
 
 

EHF tilbudsinnlevering prosess (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
 1. Besvar de krav og kriterier oppdragsgiver har i anskaffelsesdokumentene L-per   
 2. Tilbud fra leverandør på anskaffelsen er sendtL-sys   
 3. Generer kvitteringsmeldig på mottatt tilbudO-sys   
 4. Motta bekreftelsesmelding og lagre denneL-sys   
 5. Registrere  mottaks-tidspunktO-sys   
 6. Evaluer innsendte tilbudO-per, O-sys   
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
 NeiKontroll innebygget i system 

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Evaluert tilbudX359 Meddele tildeling av kontraktLeverandør 
    

16. Sluttkriterier

Nei

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
For leverandører er det en risiko at de ikke overholder innleveringsfristen.  LavHøySystemstøtte, varsler.Leverandør anskaffer systemstøtte med varsling.  

19: Behov for støtte

StøtteForklaring/Lenker
Behov for prosessopplæring. 
Behov for systemopplæring 
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke EHF: https://anskaffelser.dev/

Lenke PEPPOL BIS: https://docs.peppol.eu/pracc/ 

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF kontrakt

EHF kontrakt lar oppdragsgjevar og leverandør signere kontrakt elektronisk, på ein sikker og bindande måte.

Status for formatet

Under planlegging.

Føremål og verkemåte: Elektronisk signering av kontrakt

Oppdragsgjevar sender eit utkast til leverandør som les igjennom, signerer med sin elektroniske signatur, og sender ferdig signert kontrakt tilbake til oppdragsgjevar.

Oppdragsgjevar signerer så, og sender signert kontrakt tilbake til leverandør, slik at begge partar har kvart sitt signerte eksemplar lagra.

Fordelar med å ta i bruk formatet

For oppdragsgjevarar

  • Elektronisk signert kontrakt gjer prosessen sporbar, og kontraktsinnhaldet kan lagrast og vere sporbart heilt ned på feltnivå i systemet.    
  • Du kan setje opp systemet til å gje ulike oppfølgingar eller avgrensingsoppgåver, til dømes kor lenge kontrakten varar (setje på varsling god tid i forvegen før avtalen går ut).  
  • Verdien på kontrakten kan vere kopla opp mot formatet EHF bestilling via kontraktsadministrasjonssystemet. Systemet kan så varsle når maksgrensa for verdien av kontrakten byrjar å nærme seg.

For leverandørar

  • Fordelane for leverandør er mykje av det same som for oppdragsgjevar når det gjeld prosessinnsparingar, sporbarheit og lagring.
  • Om leverandør tek i bruk eit system som er i høve til dei retningslinjene som er gjevne, og er kopla opp mot infrastrukturen i PEPPOL-nettverket (aksesspunkt, adresseregister ELMA), vil leverandør signere ein avtale på same måte med alle offentlege verksemder, sjølv om verksemdene brukar ulike plattformer.
  • Ein treng ikkje vere fysisk til stades eller sende papirbaserte dokument i posten.

EHF katalog

EHF katalog lar oppdragsgiver motta og endre avtalesortiment på en standardisert måte. Det gir også mulighet for bedre oppfølging av avtalen og økt avtalelojalitet.

Status for formatet

I produksjon.

Formål og virkemåte: Sikre at alt kjøp er i henhold til kontrakt

EHF katalog skal gjøre det enklere for både oppdragsgiver og leverandør å inngå avtaler, endre avtalesortiment og avvikle avtaler.

Formatet kan brukes til å motta informasjon om varer og tjenester fra en leverandør det er inngått kontrakt med, på en standardisert måte.

Katalogfamilien består av forespørselskatalog, tilbudskatalog og katalog. Alle tre katalogtyper dekker hver sin del av anskaffelsesprosessen og er harmonisert slik at de henger sammen og man kan overføre data fra en katalogprosess til den neste.

En katalog kan brukes til å

  • gjøre avrop på en rammeavtale via et bestillingssystem
  • oppdatere avtalesortiment hvis avtale tillater det
  • implementere nye avtale på en effektiv måte
  • avvikle en avtale på en effektiv måte

Rollene må være definert i organisasjonen

For at prosessene skal fungere, er det viktig at de roller som er definert inn i prosessen er etablert både i oppdragsgivers og leverandørs organisasjon.

Fordeler med å ta i bruk formatet

For oppdragsgivere

  • En god katalog som kommer rett inn i bestillingssystemet, vil gjøre det enklere å søke vare eller tjeneste for bestiller.  
  • Reduserte kostnader i form av mindre tidsbruk og riktigere bestillinger (riktig vare eller tjeneste til riktig pris).  
  • Oppdateringer vil være sporbare fordi EHF katalog sendes og lagres elektronisk. Man har dermed mulighet å gi innkjøpsavdelingen gode data som grunnlag for nye konkurranser.  
  • Krav til miljø, sosialt ansvar, produsent og opprinnelsesland, vil sette oppdragsgiver i stand til å følge opp krav fra konkurransen. Den merkeordningen varen eller tjenesten tilhører kan legges ved på linjenivå i katalogen, se siden "Koder for bruk i EHF katalog for merkeordninger - miljø og samfunnsansvar".
  • Vare- og tjenesteinformasjon som følger med i katalogen fra leverandøren vil gi god kvalitet i bestillingen. Denne informasjonen kan igjen danne grunnlag for automatisering av matching av faktura.

For leverandører

  • Kan presentere sitt sortiment av varer og tjenester på en god måte for bestillere, i bestillerens egen innkjøpsløsning. Det er viktig både med tanke på å forhindre feilbestillinger, en mest mulig effektiv implementering av ny avtale, og en effektiv måte for å holde sortimentet oppdatert hvis avtalen tillater dette.
  • Det er også kritisk for leverandør at avtalelojaliteten er maksimal. Det sikres ved at bestiller får god informasjon om varen og tjenesten via bestillingssystemet. Oppdragsgiver på sin side sikrer avtalelojalitet ved å ha klare definisjoner av roller og en god prosessforståelse i egen virksomhet.

EHF katalogprosess

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF katalog prosess 
Prosess ID 
OrganisasjonDFØ-ANS
Prosess eierJan Mærøe
Henvendelser 

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.05.20Dokument opprettetJan Mærøe
    
    
    

3. Om prosessen

Dette er en prosess hvor en avtaleansvarlig mottar en katalog som viser avtalt sortiment på varer og tjenester på en maskinlesbar måte. Avtaleansvarlige sjekker om varen og tjenester som er beskrevet i katalog er i henhold til avtale. Avtaleansvarlige godkjenner katalog og sprer denne til virksomhetens bestillere. Neste gang det avtaleansvarlig mottar en katalog sjekker systemet den nye katalogen opp mot den gamle og gir en avviksrapport.  

4. Brukere og bruksområde 

Brukere: Leverandør, avtaleansvarlig - i virksomhet eller hos innkjøpssentral, og bestiller.  

Bruksområde: Den kan benyttes ved alle bestillinger av varer og tjenster som kan beskrves på en maskinell måte i form av en katalog. Benyttes når avtalen er inngått og avrop på avtale skal starte.  

5. Formål

EHF katalog skal gjøre det enklere for oppdragsgiver og leverandør å: Inngå avtaler. Endre avtalesortiment underveis i kontraktasperioden. Og avvikle avtaler.  

6. Mål

At bestilling gjøres i henhold til avtalt sortiment.

7. Gevinster

Oppdragsgiver: Sparer tid. Økt avtalelojalitet som gir økt besparelse på avtalen, økt troverdighet i leverandørmarkedet for neste konkurranse. Sikrer en god implementering av avtalen hos alle bestillere som medfører redusert bruk av tid og økt kvalitet. Økt medarbeidertilfredshet.  

Innkjøpssentral: Enklere å sende ut kontrollert katalog til alle medlemmer av innkjøpssamarbeidet og deres bestillingssystemer. 

Leverandør: Sparer tid på implementering av avtale. Sikrer at riktig sortiment blir presentert, og slipper å bruke tid på å kontakte bestillere for å presentere ny avtale. for bestillere. . Økt avtalelojalitet – sikrer at man kjøper på avtalt sortiment. Leverandør er sikret at gamle avtaler (fra andre leverandører) fjernes fra system.

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei.

9. Startkriterier/forutsetninger

TriggerKatalogverktøy varsler om ny katalog 
Andre forutsetninger

Organisasjonen må ha definert bestiller med kompetanse på bestillingssystem og avtaleansvarlig med riktig kompetanse på katalogverktøy.   

Må stille krav om EHF katalog i konkurransegrunnlag og kontrakt (samhandlingsavtale).  

Leverandør må ha kompetanse til å lage en katalog. Enten via sitt eget system eller en tjenesteleverandør.  

Må kunne ta imot EHF katalog via PEPPOL eDelivery.  

10. Input og leverandører

InputAvleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tomLeverandør/avsender - organisasjonReferanse
Innsendt katalog Leverandør 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer

Oppdragsgiver 

Person 

o-per 

 

Oppdragsgiver 

System 

o-sys 

 

Leverandør 

Person 

l-per 

 

Leverandør 

System 

l-sys 

 
    

12. Prosessdiagram

katalogprosess_bilde.png
 
 

EHF katalog prosess (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarBeskrivelse  

KP (x)

Kommentar
 

1. Oppdater eget vare/tjeneste system med beskrivelser og priser i henhold til kontrakt 

l-per 

>Legg inn avtale priser i vare- og prissystemet. >Trykk på knappen for eksport av EHF katalog.  

 
 

2. Send Katalog 

l-sys 

>Katalogen sendes som en EHF XML via PEPPOL eDelivery 

 

 
 

3. Last opp katalogen i katalogverktøy. Sjekk avviksrapport for endringer i henhold til kontrakt 

o-per 

Første gang: 

>Sjekk liste over mottatte kataloger 

>Gå inn på katalog og sjekk kataloglinjer for varer eller tjenester om de er i henhold til avtale 

>Når katalog er godkjent huk av for hvilke bestillere som skal motta katalog og tilgjengeliggjør dem for bestillere som skal ha denne type katalog.  

 

Andre gang: 

>Ved mottatt katalog skjekker systemet om det er avvik mellom den første katalogen og innsendt katalog.  

>Generer avviksrapport fra system.  

>Og sjekk om eventuelle avvik er i henholdt til ev. bestemmelser i kontrakt.  

>Godkjenn katalog  

>Tilgjengeliggjør for bestillere.  

>Ev. fjern gammel versjon om ikke systemet har den type funksjonalitet.  

 

 

 
 

4. Motta Katalog Respons 

l-sys 

>Hvis godkjent er det ok. 

>Hvis ikke godkjent gå til 5.  

 

 
 

5. Klargjør katalog for utsendelse til kunder av innkjøpssentralen 

o-per 

>Send til oppdragsgiver på nytt.  

 

 
 

6. Klargjør katalog og last den opp i bestillingssystemet 

o-per 

>Tilgjengeliggjør for bestillere 

 
 

7. Klargjør ny katalog med endret innhold 

l-per 

 

 

 
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig

Systemet kontrollerer om det riktige formatet er brukt 

Validatorfunksjon i system 

Unngå feil.  

Sjekk via system at katalog er tilgjengelig for bestiller 

Via søkemotor 

Unngå forsinkelser og gjøre bruk av bedre avtale med en gang.  

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse

Varer og tjenester er tilgjengelig 

Ordreprosessen 

Bestiller 

 

    

16. Sluttkriterier

Gammel katalog må være fjernet for å unngå utgått sortiment.  

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 
  

18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Nei    
     

19: Behov for støtte

StøtteForklaring/Lenker
Ved spesielle varer/tjenester må kanskje avtaleansvarlige ha støtte fra spesialkompetanse for å kunne godkjenne katalog  
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://anskaffelser.dev/

21. Tilleggsinformasjon

Lenke til klassifisering av varer og tjenester https://www.gs1.no/support/standardbibliotek/dele/unspsc  

22. Vedlegg

Nei

EHF ordre og ordrebekreftelse

EHF ordre og ordrebekreftelse gjør det mulig å standardisere ordreprosessen mellom oppdragsgiver og leverandør.

Status for formatet

I produksjon.

Formål: Standardisere ordreprosessen mellom oppdragsgiver og leverandør

I oppdragsgivers bestillingssystem hentes innholdet til en EHF ordre fra kataloginformasjon, lagrede historiske bestillinger eller via punchout funksjonalitet hvis systemet tilbyr denne tjenesten mot leverandøren.

EHF ordre stiller imidlertid visse krav til informasjonsinnholdet for at orden/bestillingen skal kunne prosesseres. Det er viktig at vare og tjeneste data i ordre/bestillingen er korrekt for at leverandøren som mottar ordren skal kunne importere dataene inn i sitt ordrehåndteringssystem automatisk.

Etter å ha mottatt en ordre, skal leverandøren sende en ordrebekreftelse i retur til oppdragsgiver på samme format, slik at han får kunnskap om hvilke varer og tjenester som blir levert og når de blir levert. 

Fordeler med å ta i bruk formatet

For oppdragsgivere

  • Foreta en sikker og standardisert bestilling av kontraktsfestede varer og tjenester.
  • Økt avtalelojalitet, sporbarhet og kontroll for oppdragsgiveres bestillere.  
  • Motta en standardisert ordrebekreftelse som er dokumenterbar med de forpliktelser leverandør gir for leveransen.
  • Gi mulighet til et elktronisk varemottak for å redusere risiko for svinn og gi ordre oppdatert informasjon for å kunne automatisk matche faktura 
  • Kunne fange data som kan gjenbrukes i nye anskaffelser.  
  • Kunne måle innkjøpsmønster når det gjelder miljø og sosialt ansvar, basert på krav i konkurranse og informasjon lagt til i formatet EHF katalog.

For leverandører

  • Stalig sektor benytter en enhetlig måte å bestille varer og tjenester på, der leverandør kan importere ordrer automatisk inn i sitt system. Dette vil øke kvaliteten i bestillingene med redusert risiko for returer/feilbestillinger.  
  • Data fra ordre og ordrebekreftelse kan benyttes for å produsere EHF faktura.

EHF ordreprosess

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF ordre prosess
Prosess ID 
OrganisasjonDigitaliseringsdirektoratet
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.06.16Dokument etablertJan Mærøe
    
    
    

3. Om prosessen

Prosessen starter med at en person/enhet har et behov for varer og/eller tjenster. Behovet beskrives og sendes til en bestiller(kan være samme person som behovshaver). Så søker bestiller opp varer og tjenster i bestillingssystemet basert på katalog og/eller puch-out. Så lagres dette i handlekurven til bestiller. Som påfører den handlekurven konteringsinformasjon(prosjekt, kostnadssted, etc.). Dersom organisasjon har en beløpsgrense der bestilling skal godkjennes, sendes bestillingen til den som har autorisajonsfullmakt. Dersom godkjenner ser at bestillingen må endres sendes den tilbake til bestiller som gjør endringer. Hvis alt er ok sender godkjenner bestilling til leverandør. Er bestillingen under vedtatt beløpsgrense sender bestiller direkte til leverandør.

Leverandør mottar bestillingen og sjekker tilgjengelighet på varen/tjenesten. Leverandør sender ordrebekreftelse med eller uten endringer. Dersom endringer må bestiller ta stilling til de endringer som er kommet – enten ta kontakt med leverandør for å endre bestilling eller kansellere bestilling.

Forskjellen på denne prosessen og avansert ordre er at endring og kansellering kan gjøres via system.

4. Brukere og bruksområde (hvem og når)

Oppdragsgiver med følgende roller: Behovshaver, bestiller og godkjenner.

Leverandør v/den som tar i mot bestillingen/ordre og sender bestillings-/ordrebekreftelsen, eller leverandørsystem som elektronisk importerer bestiling og automatisk genererer ordrebekreftelse basert på tilgjengelighet til varen/tjenesten. 

5. Formål

Effektivisering i betydningen redusert bruk av tid, ressurser og økt kvalitet

6. Mål

At oppdragsgiver automatiserer bestilingsprosessen basert på inngåtte avtaler i form av katalog/punch-out.

At leverandør automatiserer prosess for mottak av bestilling/ordre og automatisk kan sende en ordrebekreftelse.

At man automatisk kan matche faktura og ordre/bestilling.

7. Gevinster

For oppdragsgiver: Spart tid og/ev ressurser/kostnader. Økt kvalitet i betydningen ingen feil i utførelsen.  Fange data for analyse som kan benyttes i planlegging og oppfølgning av leverandør i avtaleperioden. Som gir mulighet for å bedre kontroll og forbedring av prosesser.  Bedre planlegging kan redusere transportbehov som vil gi miljøgevinster.

For leverandør: Få inn bestillingen elektronisk i system og slippe manuelle punching på for eksempel kundesenter og redusere/eliminere feil som krever tid, ressurser. Slippe å sjekke varer/tjenester og sende ordrebekreftelse manuelt – kan krave mye tid og ressurser samt risiko for feil som kan gå ut over kundetilfredshet. Kan dokumentere bestilling fra oppdragsgiver slik at man slipper tvister i ettertid. Oppdragsgiver oppgir presise leveransetider og steder – reduserer transportkostnader og transportbehov som gir miljøgevinster. 

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver 

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

TriggerOrganisasjonens behov for varer/tjenster
Andre forutsetninger

Inngått avtale med leverandører av varer/tjenester. 

Må ha definert hvem som skal ha bestillerroller i organisasjonen.

Må ha definert hvem som skal ha godkjennerrollen i organisasjonen opp mot bestillere.

Må ha anskaffet et bestillingssystem og ha en organisasjon som kan benytte det. 

Må eventuelt ha definert grenser for godkjenning av bestilling.

Må ha leverandører som kan sende katalog eller ha satt opp et punch-out system.

Leverandørene må ha et system for å motta elektroniske ordre/bestillinger og sende elektroniske ordre/bestillings bekreftelser.

Leverandør må kunne påføre faktura bestillingsnummer/ordrenummer.

10. Input og leverandører

InputAvleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tomLeverandør/avsender - organisasjonReferanse
Behov Organisasjon 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
OppdragsgiverBehovshaverO-beh 
OppdragsgiverBestillerO-bes 
OppdragsgiverGodkjennerO-god 
OppdragsgiverSystemO-sys 
OppdragsgiverPersonO-per 
LeverandørPersonL-per 
LeverandørSystemL-sys 
    

12. Prosessdiagram

EHF ordre prosess
 
 

EHF ordre prosess (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarBeskrivelse

KP (x)

Kommentar
 1. Klargjør handelkurv, påfør konteringsinformasjon og send til godkjenning eller direkte til leverandørO-bes   
 2. Godkjenn ordreO-god   
 3. Send ordreO-sys   
 4. Behandle ordreL-sys / L-per   
 5. Generer en bekreftelse med status avslåttL-sys   
 6. Generer en bekreftelse med status delvis bekreftetL-sys   
 7. Generer en bekreftelse med status bekreftetL-sys   
 8. Motta og kontrollere bekreftelse mot ordreO-sys   
 9. Slett ordre i bestillingssystemO-sys   
 10. Oppdater ordre i bestillingssystemO-sys   
 11. Vurder om endringer av ordre kan aksepteresO-bes   
 12. Ta kontakt med leverandørO-bes   
 13. Motta tilbakemelding fra oppdragsgiver. Enten slett ordre eller endre ordrebekreftelse og send på nyttL-per   
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
8Kontrollere at det ikke er avvik fra ordre/bestillingSystem gir ved avvik en oversikt over hva avviket består i.Uten tidlig varsel om varen kan leveres eller ikke, vil/kan organisasjonen få problemer som i verste fall kan være livstruende.  
    

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Ordre oppdagert i systemFakturaprosessOppdragsgiver 
Varer og tjenesterVaremottaksprosessen hos oppdragsgiverOppdragsgiver 
Grunnlag for å allokere varer eller tjenester.Transport/leveranseprosessLeverandør 
    

16. Sluttkriterier

Nei

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Aktivitet 1 oppdager at det ikke finnes varer/tjenester i bestillingssystemMå kontakte leverandør manuelt.
  

18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Ikke korrekt definert leveransested for varen/tjenestenLavLavLegge inn og vedlikeholde korrekte leveranseadresser i bestillingssystem.Rette feil i system.
     

19: Behov for støtte

StøtteForklaring/Lenker
Behov for prosessopplæring 
Hvis behovshaver har et behov som er spesielt må bestiller klarlegge hva behovet egentlig erKan være behov for opplæring og dialog med faginnstanser i virksomheten
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF avansert ordre

EHF avansert ordre gjør det mulig å standardisere ordreprosessen mellom oppdragsgiver og leverandør.

Status for formatet

I produksjon.

Formål: Standardisere ordreprosessen mellom oppdragsgiver og leverandør

I oppdragsgivers bestillingssystem hentes innholdet til en EHF ordre fra kataloginformasjon, lagrede historiske bestillinger eller via punchout funksjonalitet hvis systemet tilbyr denne tjenesten mot leverandøren.

EHF avansertordre stiller imidlertid visse krav til informasjonsinnholdet for at orden/bestillingen skal kunne prosesseres. Det er viktig at vare og tjeneste data i ordre/bestillingen er korrekt for at leverandøren som mottar ordren skal kunne importere dataene inn i sitt ordrehåndteringssystem automatisk.

Etter å ha mottatt en ordre, skal leverandøren sende en ordrebekreftelse i retur til oppdragsgiver på samme format, slik at han får kunnskap om hvilke varer og tjenester som blir levert og når de blir levert. Oppdragsgiver har mulighet for å kunne sende et forslag på en endret ordre (order change) eller en kanselering av ordren (order cancellation) hvis ikke leverandørens forslag til endring av ordren er akseptabel for oppdragsgiver.

Teknisk informasjon om bruk av formatet

Se gjeldende standarder for EHF avansert ordre (EHF Advanced order)

Fordeler med å ta i bruk formatet

For oppdragsgivere

  • Foreta en sikker og standardisert bestilling av kontraktsfestede varer og tjenester.
  • Økt avtalelojalitet, sporbarhet og kontroll for oppdragsgiveres bestillere.  
  • Motta en standardisert ordrebekreftelse som er dokumenterbar med de forpliktelser leverandør gir for leveransen.
  • Sende en endring eller kanselering av ordren
  • Gi mulighet til et elktronisk varemottak for å redusere risiko for svinn og gi ordre oppdatert informasjon for å kunne automatisk matche faktura 
  • Kunne fange data som kan gjenbrukes i nye anskaffelser.  
  • Kunne måle innkjøpsmønster når det gjelder miljø og sosialt ansvar, basert på krav i konkurranse og informasjon lagt til i formatet EHF katalog.

For leverandører

  • Stalig sektor benytter en enhetlig måte å bestille varer og tjenester på, der leverandør kan importere ordrer automatisk inn i sitt system. Dette vil øke kvaliteten i bestillingene med redusert risiko for returer/feilbestillinger.  
  • Data fra ordre og ordrebekreftelse kan benyttes for å produsere EHF faktura.

Dette formatet er basert på det europeiske standardisering OASIS-UBL

EHF avansert ordre prosess

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnAdvanced ordering process/avansert ordre prosess
Prosess ID 
OrganisasjonDigitaliseringsdirektoratet
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.04.28 Jan Mærøe
    
    
    

3. Om prosessen

En oppdragsgiver har et behov og sender en ordre til sin leverandør. Leverandøren gir et ordresvar som enten bekrefter hele ordren eller har avvik. Da kan oppdragsgiver ente akseptere avviket, foreta en endring av ordren, eller kansellere ordren.

4. Brukere og bruksområde

Brukere: Oppdragsgiver og leverandør av varer og tjenester. Transportør. (pakkseddel basert på ordre)

Bruksområde: Kan brukes ved vare og tjenestekjøp basert på katalog eller punch-out.

5. Formål

Prosessen hjelper oppdragsgiver og leverandør i å finne riktig varer og tjenester – optimalisere bestillingsprosessen. Sikre dokumentasjon av det oppdragsiver og leverandør gjør. Effektivserer komplekse bestillingsprosesser ved at systemet støtter deg både når det gjelder bestilling, endring, kansellering og bekreftelse. Danner grunnlag for senere prosesser – varemottak, automatisert mottak av faktura. Danner grunnlag for planleggingsfasen.

6. Mål

Gjøre all manuell kommunikasjon overflødig ved at man kommuniserer via systemet.

7. Gevinster

For oppdragsgiver: Ved å bruke et system reduseres tidsbruken. Kan dokumentere alle prosesstrinn som er utført - viktig ved revisjon, kontroll. Du sikrer at bestillingen har den rette kvalitetene – slipper returer. Man kan lage statistikker som kan gjøre planlegging av enklere. Forsyner faktura med bestillingsnummer som gjør fakturamatch mulig.

For leverandører: Sikrer kvalitet i bestillingsprosessen og unngår dermed feil som medfører returer og andre komplikasjon som igjen fører til økt tidsbruk og kostnader.

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei.

9. Startkriterier/forutsetninger

TriggerProsessen starter når et behov oppstår (trigger). Bestiller får beskjed fra en i organisasjonen om at de trenger noe
Andre forutsetninger
  • I denne prosessen må katalog være lagt inn i søkemotoren i bestillingsystmet, eller lagt opp en lenke til en punch-out løsning hos leverandør.  
  • Virksomheten bør ha en godkjenningsløsning tilknyttet prosessen. Virksomheten kan ha definerte grenser for bestillinger som godkjennes.   
  • Må velge ut personer til rollene som bestiller, varemottaker og godkjenner.
  • Virksomheten må ha gjort konteringsinformasjon tilgjengelig i systemet for bestiller.
  • Fordi innføring kan være krevende bør det gjennomføres en grundig kartlegging av endringsbehov. Det bør etableres KPIer og rapportering av KPI til ledelsen for at løsningn skal utbres i hele virksomheten.

10. Input og leverandører

InputAvleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tomLeverandør/avsender - organisasjonReferanse

Funnet varer og tjenester fra katlog eller punch-out via sin søkemotor

Katalogprosessen, puch-out prosessen.

Internt

 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
OppdragsgiverBehovshavero-beh 
OppdragsgiverBestillero-bes 
OppdragsgiverGoskjennero-god 
OppdragsgiverAvtaleforvaltero-avf 
Leverandør l 
LeverandørPersonl-per 
LeverandørSysteml-sys 
    

12. Prosessdiagram

EHF avansert ordreprosess
 
 

Prosesstegning for avansert ordre (pdf) 

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarBeskrivelse

KP (x)

Kommentar
 

1 Kontere og godkjenneConnect accounting information

o-bes

>Påfør konteringsinformasjon
>Godkjenne

X

 
 

2. Send en ny ordre med varer og/eller tjenester eller endre en eksisterende ordre

o-bes

 

 

 
 

3 Importer ordre i ordrebehandlingssystem og hent informasjon om varen og/eller tjenster er tilgjengelig

l-sys

Systemspesifikk

 

 
 

4. Lag en ordrerespons basert på tilgjengelighet

l-sys

Systemspesifikk

 

 
 

5.Send en negativ ordrerespons

l-sys

Systemspesifikk

 

 
 

6. Send en ordrerespons uten endringer

l-sys

Systemspesifikk

 

 
 

7. Send en ordrerespons med endringer

l-sys

Systemspesifikk

 

 
 

8. Motta ordrerespons

o-bes

 

X

 
 

9. Prosseser ordrerespons og sammelign med ordre sendt

o-sys

Systemspesifikk

X

 
 

10. Lagre ordrerespons

o-sys

Systemspesifikk

 

 
 

11. Oppdater ordre sendt med endringer fra ordrerespons

o-sys

Systemspesifikk

 

 
 

12. Lagre ordrerespons

o-sys

Systemspesifikk

 

 
 

13. Evaluer endringer

o-bes

 

 

 
 

14. Forbered kanselering av ordre

o-sys

Systemspesifikk

 

 
 

15. Send ordre kanselering

o-sys

Systemspesifikk

 

 
 

16. Fjern ordre fra bestillingssystemet

l-sys

Systemspesifikk

 

 
 

17. Forbered endringsordre

o-sys

Systemspesifikk

 

 
 

18. Send endringsordre

o-sys

Systemspesifikk

 

 
 

19. Evaluer oppdragsgivers endringsforslag sendt i endringsordre

l-per

 

 

 
 

20. Send en postiv respons

l-sys

Systemspesifikk

 

 
 

21. Send en negativ respons

l-sys

Systemspesifikk

 

 
 

22. Slett ordre fra systemet

o-sys

Systemspesifikk

 

 
 

23. Lagre ordre respons

o-sys

Systemspesifikk

 

 
 

24. Oppdater ordre med endringer

o-sys

Systemspesifikk

 

 

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig

1

Sjekke verdi i henhold til godkjenningsprosess..

I henhold til regler i bestillingssystem

Attestering/budsjettfullmakt vedtatt skal følges.

8

Sjekk at leverandør har respondert på ordre sendt eller endringsordre sendt.

Sjekk status i ordreoversikt.

For å sikre at prosessen ikke forsinkes unødvendig.

9

Kontroller om endring på opprinnelige ordre er akseptabel.

Sjekk om forslag på ny vare og tjeneste er akseptabel.

Sikre at behov blir dekket. (riktig kvalitet, pris)

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse

Oppdatert ordre klar for mottak

Vare/tjenestemottak

o 

Grunnlag for mottak av faktura

Fakturaprosess

o 
    

16. Sluttkriterier

Leverandør og oppdragsgiver er enig om leveranse av varer/tjeneste.

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring

Aktivitet 1 Hvis bestiller ikke finner varen eller tjenesten i søkemotoren.

Da må man på manuell behandling.

18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak

Får ikke svar fra leverandør

Lav

Kan være kritisk

Manuell kontroll

Ringer, sender mail, etc.

19: Behov for støtte

StøtteForklaring/Lenker

Kun behov for ordinær opplæring i bruk av system.

 

Aktivtet 1: Kan være behov for faglig bistand ved bestilling av spesielle varer og tjenester.

 
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei.

EHF ordreforslag

EHF ordreforslag (EHF Order Agreement) lar oppdragsgjevar dokumentere kjøp av tenester utført i leverandøren sine system eller tenester utført basert på rammeavtalar.

Status for formatet

I produksjon.

Føremål: Dokumentere kjøp av varer eller tenester utan ei forutgåande bestilling

EHF ordreforslag kan brukast i bestillingsprosesser der

  • prisar på tenester fastsetjast på bestillartidspunktet
  • tenester utførast basert på ein vedlikehalds- eller utviklingsavtale, utan ei forutgåande direkte bestilling

Døme på dette er

  • bestilling av billettar i bestillingssystemet til eit flyselskap
  • ein røyrleggjar som utbetrar ein lekkasje på ein skole og sender kostnader på materiale og brukt tid i etterkant til oppdragsgjevar
  • ein konsulent som rapporterer inn timar brukt for ein avgrensa periode på eit stort prosjekt

Formatet lar leverandør og oppdragsgjevar nytte sine eigne system til å utveksle og lagre strukturerte data i slike tilfelle, og dermed også bruke dataa vidare i kjøpsprosessen tildømes å matche faktura.

Teknisk informasjon EHF Ordreforslag

EHF Order Agreement teknisk spesifikasjon

Fordelar med å ta i bruk formatet

For oppdragsgjevarar

  • Får maskinlesbar dokumentasjon på varer og tenester som er kjøpt utan forutgåande bestilling.    
  • Bruke lagra informasjon til å matche pakksedel og faktura.

For leverandørar

  • Kunne bruke sitt eige system mot systemet til ulike oppdragsgjevarar, for stadfesting og innrapportering av utført arbeid og kostnader som må dekkast.    
  • Kunne gjenbruke informasjonen til å fakturere oppdragsgjevar.

EHF ordreforslag prosess

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF ordreforslag prosess  
Prosess ID 
OrganisasjonDigitaliseringsdirektoratet
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.05.11Dokument etablertJan Mærøe
    
    
    

3. Om prosessen

I denne prosessen registrerer leverandør informasjon om utført tjeneste eller utført bestilling for oppdragsgiver. Systemet sender et ordreforslag til oppdragsgiver. Oppdragsgiver mottar ordreforslag og lagrer det i sitt system.  

4. Brukere og bruksområde (hvem og når)

Prosessen kan benyttes av leverandør og oppdragsgivere.  

Oppdragsgiver skal normalt sende en ordre til leverandør før varer og tjenester leveres. Dette kan i mange tilfeller være lite hensiktsmessig – forsinke prosessen med å utføre tjenesten. For eksempel: Det har oppstått en vannlekkasje på en skole hvor det ikke er tid til å vente på en ordre. Det er inngått avtale om vedlikehold hvor det er uhensiktsmessig å be om og vente på en ordre for hver oppgave som skal utføres. Det er tatt en policy beslutning i virksomheten om å bruke reiseselskapets web-side for å reserve plass. Uten en slik løsning ville du kunne tapt reservasjonen før bestillingen når leverandør (sanntids-bestilling).    

5. Formål

Når leverandør sender faktura for et hasteoppdrag, må den behandles manuelt. Hensikten med denne prosessen er å sikre at innkomne faktura kan behandles maskinelt og effektivt.  

6. Mål

Flest mulig maskinelt behandlede fakturaer, automatch.  

7. Gevinster

For leverandør: Dokumentasjon som kan brukes som input til faktura. Gjenbruk av informasjon sparer tid, reduserer feil og som følge av det reduserer kostnader. Ved statusmøter mellom oppdragsgiver og leverandør kan leverandør enkelt dokumentere sine prosesser/arbeid. Noe som sparer partene for tid samt øker tilliten til leverandøren.   

For oppdragsgiver: Kunne dokumentere utført oppdrag ved ettersyn/revisjon – sparer tid og skaper tillit. Ved statusmøter blir det enklere å sammenligne informasjon som leverandør fremlegger med egen. Noe som sparer tid og reduserer kostnader. Fakturamatch sparer tid og reduserer risiko for feil. Enkel gjenbruk av strukturert informasjon forenkler planlegging – sparer tid ved nye konkurranser.  

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei.

9. Startkriterier/forutsetninger

TriggerEt behov som må løses, for eksempel behov for flyreise, rask reparasjon av vannlekkasje.   
Andre forutsetninger 

10. Input og leverandører

InputAvleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tomLeverandør/avsender - organisasjonReferanse

En ansatt eller bestiller reserverer for eksempel en reise.  

Oppdragsgiver logger seg på reisesystemet 

Oppdragsgiver 

 

En vannlekkasje oppstår.  

Varslingssystem eller rutinekontroll fra leverandør 

Oppdragsgiver 

 

Andre eksempler.  

 

 

 

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
OppdragsgiverBehovshavero-beh 
OppdragsgiverBestillero-bes 
OppdragsgiverGoskjennero-god 
OppdragsgiverAvtaleforvaltero-avf 
OppdraggiverSystemo-sys 
Leverandør l 
LeverandørPersonl-per 
LeverandørSysteml-sys 

12. Prosessdiagram

2020_05_15_bilde_ordreforslag.png
 
 

EHF ordreforslag prosess

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarBeskrivelse

KP (x)

Kommentar
 

1. Utfør arbeid i henhold til kontrakt og registrer tid og varekostnad 

l-per 

Situasjonsbestemt. 

  
 

2. Oppdragsgiver har registrerer informasjon i system eks reise. 

l-per 

Situasjonsbestemt. 

  
 

3. Lagre informasjon i system og klargjør forsendelse.  

l-sys 

Systemspesifikk 

  
 

4. Send et ordreforslag basert på utført oppgave. 

l-sys 

 

Systemspesifikk 

 

  
 

5. Lagre ordreforslag i system 

o-sys 

Systemspesifikk 

  
 

6. Sjekk om ordreforslag er i henhold til kontrakt 

o-bes/avf 

 

x 
 

7. Kontakt leverandør 

o-bes/avf 

 

  
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig

6

Sjekk om leveranse er i henhold til kontrakt 

Enten kan system brukes opp mot kontrakts arkiv eller manuelt.  

Sikre at man får avtalte priser.  

    

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse

Strukturert informasjon (EHF ordreforslag) lagret i system i påvente av faktura.  

Fakturaprosessen (er definert) 

Oppdragsgiver/Bestiller 

 

    

16. Sluttkriterier

Leverandør må inkluderer ordreforslagsnummer i faktura slik at det er mulig for oppdragsgiver å koble ordreforslag mot faktura når den mottas. 

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 

18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Nei.    

19: Behov for støtte

StøtteForklaring/Lenker
Nei. 

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei.

22. Vedlegg

Nei.

EHF punch-out

EHF Punch Out gjev kontroll på komplekse bestillingar ved hjelp av leverandøren sitt system.

Status for formatet

I produksjon.

Formål og virkemåte: Kontrollere at riktig vare eller tjeneste leveres via leverandørs system

EHF punch out skildrar prosessen og meldingsinnhaldet der oppdragsgjevar

  1. får automatisk tilgang til avtalt sortiment i leverandøren sin nettbutikk, ved å klikke på ei lenkje i sitt eige bestillingssystem
  2. vel varer og tenester og legg dei i ei handlekorg inne i systemet til leverandøren
  3. overfører handlekorga tilbake til sitt eige bestillingssystem

Fordeler ved å ta i bruk formatet

For oppdragsgivere

  • Høve til å setje saman komplekse varer eller tenester, til dømes ein PC.
  • Lagre strukturert informasjon om varer og tenester i bestillingssystemet sitt som dannar grunnlaget for ein ordre/bestilling, til dømes ved utsending av EHF ordre og matching med EHF faktura.

For leverandør

  • Informasjon om komplekse varer og tenester kan sendast til oppdragsgjevar sitt bestillingssystem på ein strukturert måte.
  • Bestillar sender ordre med leverandøren sin vare- og tenesteinformasjon. Det lar leverandøren importere strukturert ordreinformasjon (EHF ordre) direkte inn i sitt eige system. Informasjonen kan så gjenbrukast ved utsending av ordrestadfesting og faktura.

EHF punch-out prosessen

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF punchout prosess 
Prosess ID 
OrganisasjonDigitaliseringsdirektoratet
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.06.02Dokument opprettetJan Mærøe
    
    
    

3. Om prosessen

I punch out prosessen logger oppdragsgiver seg inn i sitt bestillingssystem, søker ønsket vare og klikker på lenken til leverandørens nettbutikk (punch out system). Oppdragsgiver søker etter varer og/eller tjenester i leverandørens nettbutikk og legger disse i handlkurv. Når oppdragsgiver har funnet alle varer eller tjenester klikker han på knappen som skal sende handlekurven over til sitt bestillingssystem.  Handlekurven lagres i oppdragsgivers system. Neste prosess er ordreprosess.  

4. Brukere og bruksområde (hvem og når)

Oppdragsgiver kan benyttes ved kjøp av komplekse varer og/eller tjenester som må skreddersys i leverandørens system, for eksempel konfigurering av PC.

5. Formål

Sikre god maskinlesbar informasjon fra leverandørenes system inn i eget bestillingssystem ved bruk av standard format.  

6. Mål

  • Tilstrekklig informasjon for å kunne sende en EHF ordre 

  • Tilstrekkelig informasjon for å matche EHF faktura med EHF ordre.   

  • Muliggjøre innsamling og bruk av data i analyser.  

  • Synlighet, transparens i bestillingsprosessen.  

7. Gevinster

Oppdragsgiver: Økt kvaliltet i informasjonen vil redusere bruk av tid, ressurser og risiko for feil. Ledelsen får mulighet til bedre planlegging og kontroll.   

Leverandører: Sparer tid ved at oppdragsgiver benytter leverandørens informasjon i etterfølgende prosesser.  

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Punch out er det samme som round trip.  

9. Startkriterier/forutsetninger

TriggerBehov for varer og/eller tjenester.  
Andre forutsetninger

Leverandørens bestillingsystem må ha innført punch-out funksjonalitet. Vær oppmerksom på at ved å stille krav om denne prosessen i konkurranser kan ha en konkurransevridende effekt da ikke alle leverandører har ressurser til å utvikle en slik løsning.  

Bestillere hos oppdragsgivere må være kjent med leverandørens nettbutikk

10. Input og leverandører

InputAvleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tomLeverandør/avsender - organisasjonReferanse
Behov Oppdragsgiver 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
OppdragsgiverBehovshavero-beh 
OppdragsgiverBestillero-bes 
OppdragsgiverSystemo-sys 
LeverandørSysteml-sys 
    

12. Prosessdiagram

EHF Punch out
 
 

EHF punch-out prosess

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarBeskrivelse

KP (x)

Kommentar
 1. Logg inn i bestillingsystem og klikk punch out o-bes   
 2. Punch out sesjon åpnes baser på innloggingsurl og avtalevarer vises i søkemotor.l-sys   
 3. Fyll handlekurv basert på søkemotorresultat og avslutt handleprosesso-bes   
 4. Forbered forsendelse av varer til oppdragsgivers bestillingssystem.  Lagre bestilling i systemel-sys   
 5. Returner oppdragsgiver til sitt eget bestillingssystem og lukk sesjonen i systemet l-sys  Her må en såkalt hook-url benyttes
 6. Handlekurv mottas i bestillingssystemet til oppdragsgivero-sys   
 7. Lagre varer i bestillingssystemet og klargjør for forsendelse av EHF ordre o-sys   
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
 Nei  
    

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Varer lagret i oppdragsgivers bestillingssystem Ordreprosess (er definert) Oppdragsgiver/system  
    

16. Sluttkriterier

Varer og tjenester må være i henhold til avtale.  

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 
  

18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Nei    
     

19: Behov for støtte

StøtteForklaring/Lenker
Opplæring i bruk av leverandørers systemer.   
  
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF pakkseddel

EHF pakkseddel gjør det mulig for oppdragsgiver å kontrollere at rett vare eller tjeneste er mottatt, og at det betales for riktig vare eller tjeneste.

Status for formatet

I produksjon.

Formål og virkemåte: Kontrollere at riktig vare eller tjeneste leveres

Kontroll med leveranser er viktig for både oppdragsgivere og leverandører. Begge parter må være trygge på at leveransen stemmer med bestillingen, og at det betales for riktig vare eller tjeneste. Formatet EHF pakkseddel kan hjelpe begge parter med kontrollen, ved at leveransen blir dokumentert elektronisk.

For leveranse av fysiske varer er det viktig at varemottakerrollen er definert hos oppdragsgiver. Varen kan bli levert et annet sted enn der den ble bestilt fra, og mottaker av varen kan være en annen enn bestiller.

Et eksempel er en skole: Bestiller sitter på kontoret og en vaktmester tar i mot varene. Dermed bør vaktmesteren være definert som varemottaker og må registrere varene inn i systemet.

Vareinformasjon fra EHF pakkseddel kan benyttes som underlag for denne kontrollen. Varemottaket vil også fungere som en referanse for ordre og benyttes ved match av EHF faktura.

EHF pakkseddel kan også benyttes som en bekreftelse på utført tjenesteoppdrag, der bestiller vil sjekke om for eksempel en konsulent eller vikar har vært tilstede og utført oppgaven i henhold til tilsendt pakkseddel.

Fordeler ved å ta i bruk formatet

For oppdragsgivere

  • Få kontroll på leveransene.
  • Klargjøre eget system for automatisert matching av EHF faktura.
  • Ved elektronisk mottak (registrere restlevering, ukurans og brekkasje): Bedre grunnlag for å følge opp leverandør på levereransekvalitet i henhold til kontrakt på jevnlige statusmøter.  
  • Få definert rollebeskrivelsen varemottaker og tildele oppgaven til personer i organisasjonen.
  • Redusere avvik på faktura ved at den reelle leveransen registreres, så feilfakturering ikke forekommer.

For leverandør

  • Pakkseddel er som regel den siste oversikten over leveransen av varer som leverandør tar ut. Det vil si at restinger og andre ting som avviker fra bestilling er luket ut, slik at man har en reell oversikt over de varer som faktisk sendes til oppdragsgiver. Elektronisk pakkseddel sendes som regel over til transportør. Dersom EHF pakkseddel sendes til oppdragsgiver samtidig, vil begge parter være koordinert.  
  • For leverandør er det en fordel at oppdragsgiver sjekker varene i henhold til EHF pakkseddel for å unngå tvister der bestiller ikke har mottatt varene, eller at man påstår ukuranse og brekkasje som kan ha skjedd internt hos oppdragsgiver.
  • For tjenesteleveranser er det en fordel for konsulent eller innleid personell, som vikarer, å kunne sende inn en bekreftelse på utført arbeid, slik at faktura er klarert før den sendes og sjekkes. Dermed flyttes kontrollen tidligere i prosessen slik at man unngår kreditering.

EHF mottaksprosessen

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF vare og tjenestemottak prosess 
Prosess ID 
OrganisasjonDigitaliseringsdirektoratet
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.05.28Dokument etablertJan Mærøe
    
    
    

3. Om prosessen

Dette er en prosess hvor oppdragsgiver mottar og registrerer inn et korrekt mottak av varer og/eller tjenester. Systemet oppdatere opprinnelig bestilling med hva som er levert for derigjennom å kunne automatisk matche en faktura.  

4. Formål

Pakkseddel gjør det mulig for oppdragsgiver å kontrollere at riktig vare og/eller tjenester er mottatt. For derigjennom sikre korrekt utbetaling i henhold til bestilling.  

Fange statistikk på leveransepresisjon fra leverandør.    

5. Mål

Målet er å helautomatisere behandlingen av faktura.  

Ikke betale for noe som ikke er levert

6. Gevinster

For oppdragsgivere vil gevinst være å unngå utbetalinger for manglende leveranser – redusere kostnader. Reduserer risiko for at varer ikke blir levert som kan være virksomhetskritisk, eks helsesektoren. Reduserer tidsbruk i prosesser knyttet til dokumentasjon og arkivering. Bestilling oppdateres for automatisk match av faktura – sikrer en effektiv fakturaprosess. Ved elektronisk mottak, der pakkseddel gir en elektronisk dokumentasjon på leveranse, kan oppdragsgiver følge opp leverandørens leveransekvalitet (restlevering, ukurans og brekkasje) for problemløsning/forbedring.  

Leverandør får dokumentert at leveranse er gjennomført på riktig sted, til riktig tid – kan redusere risiko for tvister om varen er levert på riktig sted, med riktig kvalitet, antall osv.  

Totalt sett bidrar koordineringen til en mer effektiv verdikjede – samhandling mellom oppdragsgiver, leverandør og transportør.   

For tjenesteleveranser er det en fordel for den som yter tjenesten å kunne sende inn en bekreftelse på utført arbeid slik at faktura er klart av oppdragsgiver før den sendes. Dermed flyttes kontrollen tidligere i prosessen slik at man reduserer risiko for kreditering – reduser bruk av tid og kostnader.  

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

7. Brukere og bruksområde (hvem og når)

Oppdragsgiver v/vare- og tjenestmottak. Brukes der bestilling er sendt via et bestillingssystem. 

8. Definisjoner/forkortelser

Ingen

9. Startkriterier/forutsetninger

TriggerBestilling mottatt fra oppdragsgiver.  
Andre forutsetninger

Etablere et elektronisk varemottak i sitt bestillingssystem. 

Oppdragsgiver må definere en varemottakerrolle og tildele denne til personer som får opplæring i hvordan man foretar elektronisk varemottak.  

10. Input og leverandører

InputAvleverende prosess: Navn på prosess + ID Leverandør/avsender - organisasjonReferanse
Bestilling Oppdragsgiver 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
OppdragsgiverBestillero-bes 
OppdragsgiverVaremottakero-var 
Leverandør   
    

12. Prosessdiagram

EHF Pakkseddel3
 
 

EHF mottaksprosess (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarBeskrivelse  

KP (x)

Kommentar
 

1. Plukke varer og allokerer ressurser.   

 

 

 

 
 

2. Genererer EHF pakkseddel 

 

 

 

 
 

3. Utføre oppdrag 

 

 

 

 
 

4. EHF pakkseddel sent 

 

 

 

 
 

5. Lagre EHF pakkseddel i system 

 

 

 

 
 

6. Motta varer eller sjkk utført oppdrag 

 

>Motta varer eller sjekk utført oppdrag 

>Registrer i system.  

 
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig

Bestiller sjekker om leveranser fra bestillingen er registrert i systemet.  

Sjekk pakkseddel status.   

Sikre at ordre er i henhold til den faktura som kommer – automatch kan gjennomføres.  

    

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse

Mottatte varer og tjenester registert i system.   

System 

Oppdragsgiver 

 
    

16. Sluttkriterier

Korrekt leveranser er registrert i systemet.  

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Ingen 

18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Hvis varemottaker ikke vet om det er farlig gods i leveransen kan det være fare for liv og helse.  LitenHøyFølge anvisninger som EHFpakkseddel gir for risikoprodukter.  Leverandør må merke risikoprodukter.  
     

19: Behov for støtte

StøtteForklaring/Lenker

Ingen ut over systemstøtte 

 

Opplæring i utførelse av prosess.  

 
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF fakturering

EHF fakturering 3.0 sikrer automatisk, rask og sikker utbetaling. Formatet er obligatorisk ved fakturering i staten.

Status for formatet

I produksjon.

Formål og virkemåte: Standardisering av utbetaling og matching mot ordre

Faktura og en eventuell kreditnotatransaksjon er den siste transaksjonen i bestillingsprosessen og danner informasjonsgrunnlaget for utbetaling til leverandør av varer og tjenester.

Bruker din virksomhet allerede EHF katalog og EHF ordre, har du strukturert informasjon som kan gjenbrukes når du skal sende elektronisk faktura på formatet EHF fakturering 3.0 til opdragsgiver. Dermed gir leverandøren oppdragsgiver mulighet til automatisk å matche faktura mot ordre, og reduserer dermed sjansene for at utbetalinger blir forsinket, utbetaling skjer til feil leverandør. Samtidig effektiviserer virksomheten sin prosess og øker kvaliteten. 

EHF faktura er obligatorisk ved fakturering i staten:

Fordeler ved å ta i bruk formatet

For oppdragsgivere

  • En EHF Fakturering 3.0 gir oppdragsgiver mulighet til å kunne prosessere meldingen elektronisk intern, og kunne validere og arkivere den.  
  • En elektronisk faktura gir en enklere prosess for internflyt og godkjennelse, som igjen reduserer mulige forsinkelsesrenter for virksomheten.  
  • Har oppdragsgiver tatt i bruk et bestillingssystem med formatet EHF ordre, har oppdragsgiver mulighet for å godkjenne de økonomiske forpliktelsene før bestilling er gjort, og sende leverandør bestillingsnummer. Faktura kan dermed matches mot ordren og godkjennes maskinelt.
  • Samlet fører dette til vesentlig reduksjon av prosesskostnader, reduserer feil og øker sporbarheten. 

For leverandører

  • Den store gevinsten for en leverandør er at man kan sende faktura til alle offentlige oppdragsgivere på ett format, via samme infrastruktur.  
  • Da oppdragsgiver kan automatisere prosesseringen av faktura, vil utbetalingen kunne komme raskere enn ved manuell fakturabehandling.
  • Ved mottak av EHF ordre gjennbruke informasjon fra ordre i å lage EHF fakturering.

EHF faktura og kreditnota prosess

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF faktura og kreditnota prosess 
Prosess ID 
OrganisasjonDigitaliseringsdirektoratet
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.06.02Dokument opprettetJan Mærøe
    
    
    

3. Om prosessen

I denne prosessen lager leverandør en faktura for varer han har sendt eller tjenester han har utført, som sendes til oppdragsgiver. 
Oppdragsgiver sjekker faktura mot bestilling. Hvis faktura er lik bestilling/orderen som er sendt kan faktura betales automatisk – uten manuell behandling. 
Hvis faktura ikke er i samsvar med bestilling må oppdragsgiver kontrollere og eventuelt kreve at leverandør retter opp feil og eventuelt sender en kreditering. 

4. Brukere og bruksområde (hvem og når)

Offentlige oppdragsgiver må benytte EHF faktura se Referansekatalogen for IT-standarder: https://www.digdir.no/digitale-felleslosninger/digitale-anskaffelser/1486

5. Formål

Effektivisere fakturabehandling – spare tid. Samt kunne dokumentere utbetaling fra offentlige virksomheter.  

6. Mål

Korrekt faktura opp mot bestilling og i henhold til avtale.

7. Gevinster

Oppdragsgiver: 

  • Ved å eliminere den manuelle faktureringsprosessen kan virksomhetene spare mye tid og ressurser. 
  • Fordi faktura finnes imaskinlesbart format er det enklere å gjennomføre bokettersyn/revisjon. 
  • Fordi faktura er grunnlag for utbetaling til leverandør kan utbetalingsprosessen også effektiviseres.
  • Hvis det er feil på faktura kan den også effektivisere kreditteringsprosessen. 
  • En elektronisk faktura reduserer også risiko for morarenter ved for sen utbetaling.  

Leverandører: 

  • Reduserer risiko for sen betaling av varer og tjenester fra oppdragsgiver.
  • Faktura danner grunnlag for purreprosessen som kan settes opp automatisk i leverandørens systemer ved overskridelse av innbetalingsdato.
  • Fakturaen danner også grunnlag for en effektiv krediteringsprosess ved feil. 

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

TriggerEHF ordre, abonnement eller annen form for bestilling (for utenlandske leverandører PEPPOL BIS) 
Andre forutsetningerNei

10. Input og leverandører

InputAvleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tomLeverandør/avsender - organisasjonReferanse
OrdreOrdreprosessen (definert) Oppdragsgiver/bestiller  
Abonnement Fakturaprosess til leverandør Leverandør  

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
OppdragsgiverSysteml-sys 
OppdragsgiverBestillero-bes 
LeverandørSysteml-sys 
LeverandørPersonl-per 

12. Prosessdiagram

EHF faktura og kreditnota prosess 3
 
 

EHF faktura og kreditnota prosesstegning (pdf)

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarBeskrivelse 

KP (x)

Kommentar
 1. Generere faktura basert på bestilling fra oppdragsgiver for leveranse av varer/tjenesterl-sys    
 2 Send faktural-sys    
 3 Motta fakturao-sys    
 4. Sjekk faktura mot bestillingo-sys  
 5.  Sjekk avvik. Sjekk om utbetaling har funnet stedo-bes x 
 6. Kontakt leverandør å be om kreditering av  hele fakturaen og be de sende en ny faktura med korrekt beløpo-bes   
 7. Kontakt leverandør: be om kreditnota på hele fakturaen og be de sende en korrekt faktura og betale tilbake hele utbetalingen. 
Be om kreditnota på deler av fakturaen. Be leverandør betale tilbake delbeløpet.
o-bes   
 8. Behandle forespørselen og klargjør for kreditnota og/eller utbetaling av beløpl-per x  
 9. Generer kreditnota med referanse til utsendt faktural-sys   
 10. Send kreditnotal-sys   
 11. Motta kreditnotao-sys   
 12. Oppdater eller utligne faktura mot kreditnota i regnskapssystemeto-sys   
 13. Klargjør utbetaling til leverandøro-sys   
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
4Maskinell kontroll av informasjon i faktura opp mot ordre SystemFor å redusere risiko for feilutbetaling
5Sjekk avvik. Sjekk om utbetaling har funnet stedManueltFor å redusere risiko for feilutbetaling
8Behandle forespørselen og klargjør for kreditnota og/eller utbetaling av beløpManuelt/SystemFor å redusere risiko for feilutbetaling
 Ved oppsett av abonnements mottak sjekke at referansenummer er korrekt opp mot gjeldende beløpsgrense  SystemFor å effektivisere fakturaprosessen
    

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Grunnlag for utbetaling Payment prosess/utbetalingsprosess Regnskapssystem hos oppdragsgiver 
    
    
    

16. Sluttkriterier

Kvitteringsmelding fra paymentsystem

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 
  

18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Feilutbetaling LavHøyElektronisk match av ordre eller abonnements ordning  Sikre at alle fakturaer har et bestillings/abonnements nummer.
     

19: Behov for støtte

StøtteForklaring/Lenker
Systemopplæring for oppdragsgivere og leverandør. 
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF gjennomfakturering prosess

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navn 
Prosess ID 
OrganisasjonDigitaliseringsdirektoratet
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
0,5   
    
    
    

3. Om prosessen

ss

4. Brukere og bruksområde (hvem og når)

ss

5. Formål

ss

6. Mål

ss

7. Gevinster

ss

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

ss

9. Startkriterier/forutsetninger

Trigger 
Andre forutsetninger 

10. Input og leverandører

InputAvleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tomLeverandør/avsender - organisasjonReferanse
    
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
OppdragsgiverBehovshavero-beh 
OppdragsgiverBestillero-bes 
OppdragsgiverGoskjennero-god 
OppdragsgiverAvtaleforvaltero-avf 
    
Leverandør   
    
    
    
    

12. Prosessdiagram

ss

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarBeskrivelse 

KP (x)

Kommentar
 1.    
 2.    
 3.    
 4.    
 5.    
 6.    
 7.    
 8.    
 9.    

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
    
    

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
    
    
    
    

16. Sluttkriterier

ss

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
  
  

18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
     
     

19: Behov for støtte

StøtteForklaring/Lenker
  
  
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://anskaffelser.dev/

21. Tilleggsinformasjon

ss

22. Vedlegg

ss

EHF purring

EHF purring lar leverandøren automatisere purring av oppdragsgiver ved manglende betaling. Formatet gir også mulighet for å matche purring mot faktura.

Status for formatet

I produksjon.

Formål og virkemåte: Automatisere purring ved manglende betaling

Dersom en leverandør ikke har mottatt betaling i tide, kan han bruke formatet EHF purring til å purre oppdragsgiver.

Lov om inkassovirksomhet og annen inndriving av forfalte pengekrav (inkassoloven), § 3 a. Elektronisk kommunikasjon, legges det til rette for elektronisk kommunikasjon:
"Krav i eller i medhold av denne loven om at meddelelser til skyldneren skal gis skriftlig, er ikke til hinder for bruk av elektronisk kommunikasjon dersom meddelelsen er sendt på en betryggende måte".

Formatet et anbefalt i henhold til Referansekatalogen

Fordeler ved å ta i bruk formatet

For oppdragsgivere

  • Når du mottar purring elektronisk på formatet EHF purring, får du maskinlesbare referanser til EHF faktura som er innsendt av leverandør tidligere. Dermed kan oppdragsgiver spore opp den aktuelle fakturaen i eget datasystem, og spore prosessen for utbetaling til leverandør. Har utbetalingen stoppet, kan du sende melding om utbetaling på nytt.

For leverandører

  • Mulighet for å automatisere prosessen med å purre oppdragsgivere, ved at EHF purring utløses automatisk ved manglende betaling.

EHF purring prosess

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF purring prosess
Prosess ID 
OrganisasjonDigitaliseringsdirektoratet
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.05.29Opprette dokumentJan Mærøe
    
    
    

3. Om prosessen

Før purreprosessen begynner har leverandør sendt en faktura til oppdragsgiver og lagret forfallsdato for betaling i sitt øknomisystem/kundeoppfølgingssystem. Purreprosessen begynner når forfallsdato passeres uten at systemet har regitrert innbetaling for den aktuelle faktura. Leverandørs system oppretter en EHF purring og sender denne til oppdragsgivers system. EHF purring inneholder referanse til den aktuell faktura slik at oppdragsgiver lett kan finne denne. Basert på mottatt purring starter oppdragsgiver en ny utbetalingsprosess..

Hvis EHF purring inneholder purregebyr må oppdragsgiver også sikre utbetaling av dette.  

4. Brukere og bruksområde (hvem og når)

Brukere: Leverandør og oppdragsgiver.

Når: Ved for sen betaling av innsendt faktura.

5. Formål

Unngå manuelle purrerutiner som kan være tid- og kostnadskrevende

6. Mål

At purring kan utføres elektronisk mellom leverandør og oppdragsgiver

7. Gevinster

Leverandør: Sparer tid ved at systemet genererer en purremelding ved manglende betaling fra oppdragsgiver (etter forfallsdato på den opprinnelige fakturaen). Spart tid skjer ved at system tar utgangspunkt i utsendt orginalfaktura når purring lages. Dettesikrer riktig informasjon(kvalitet) i purringen.

Oppdragsgiver: Sparer tid ved at purring referer til innsendt/mottatt orginalfaktura. Sikrer at orginalfakturainformasjon er riktig. Muliggjør automatisert sjekk om orginalfaktura er godkjent og utbetalt eller at purringen skal godkjennes og utbetales.

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Forfallsdato: Den datoen oppdragsgiver må ha betalt fakturaen på.

9. Startkriterier/forutsetninger

TriggerIkke mottatt betaling før fallsdatoen på en faktura i leverandørs system trigger purreprosessen (forfallsdato + 14 dager).
Andre forutsetningerLeverandør må ha et system som sjekker forfallsdato + 14 dager, på en faktura mot mottatt betaling. Gjøres ofte i et økonomisystem

10. Input og leverandører

InputAvleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tomLeverandør/avsender - organisasjonReferanse
Melding om ikke innebetalt fakturaSystemspesifikk (ID er normalt det opprinnelige faktuanummert + forfallsdatoen)Leverandør 
    

11. Deltakere
Beskrivelse av roller finner du her:

OrganisasjonRolle (ved behov)ForkortelserKommentarer
OppdragsgiverSystemo-sys 
OppdragsgiverPersono-per 
LeverandørSysteml-sys 
    

12. Prosessdiagram

EHF purre prosess
 
 

EHF purring prosess

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarBeskrivelse

KP (x)

Kommentar
 1. Fakturasystem generer en EHF purringl-sysSystemspesifikk  
 2. Send purring på utsendt faktural-sysSystemspesifikk  
 3. Undersøk årsak til at utbetaling ikke har funnet stedo-perDelprosessen består av to aktiviterer. Den ene er å finne årsaken til at utbetaling ikke har funnet sted og og iverksette riktig tiltak  
 4. Generer utbetaling og send til betalingsmottakero-sysSystemspesifikk  
      

14. Kontrollpunkter og målinger

Akt. nr.Hva som skal kontrolleres, målesHvordan det skal gjøresHvorfor det er nødvendig
 Nei  
    

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Utbetaling til leverandørPayment prosessLeverandør 
Leverandør varslet om manglende faktura Leverandør 
Leverandør varslet om at utbetaling er underveis Leverandør 
    

16. Sluttkriterier

Leverandør: At innbetaling for utsendt orginalfaktura og purring er registrert og bokført i leverandørs system.

Oppdragsgiver: Undersøker hva som var årsaken til at utbetaling ikke fant sted og utbredrer eventuelle feil

17. Unntak/spesielle hensyn

HvorUnntak - betingelser og endring
Nei 
  

18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Nei    
     

19: Behov for støtte

StøtteForklaring/Lenker
Nei 
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke: https://anskaffelser.dev/ 

21. Tilleggsinformasjon

https://lovdata.no/dokument/SF/forskrift/1989-07-14-562

Alle regninger skal ha en forfallsdato, det vil si at kunden må betale fakturaen innen denne fristen. På grunn av at man bruker purring for å minne kunden på en manglende innbetaling, kan purring også kalles betalingspåminnelse.

Regler for purring og purregebyr:

  • Man kan sende ut en purring 14 dager etter den opprinnelige betalingsfristen, for å minne kunden på at regningen ikke er betalt.
  • Når man først må sende ut en purring, kan man legge til et gebyr for å måtte sende ut denne. Da kalles det purregebyr. Hvor stort gebyr man kan kreve, og andre regler for utsendelse av purringer, reguleres av Inkassoforskriften.

I Norge kan man kun kreve gebyr på utsendelse av to purringer. Det kan kreves renter fra betalingsfristen på den opprinnelige regningen, til forfall på purringen. Det gebyret som kan kreves inn, kan være lik en tidel av den gjeldende inkassosatsen når det sendes ut en purring. Per 01.01.2014 er maksimumsgebyret for purrenota kr 64,- (10% av Inkassogebyr). Purringen må ha en betalingsfrist på minst 14 dager.

Fra purring til inkasso

Dersom en regning ikke betales innen forfallsdatoen, kan man velge å sende et inkassovarsel direkte i stedet for purring. Man kan også sende ut inkassovarsel etter at purringen er sendt. Hvis inkassovarselet ikke betales innen 14 dager, kan saken sendes til inkasso. Inkasso vil si å inndrive gjeld, som ofte gjøres av et inkassobyrå.

22. Vedlegg

Nei

Støtteprosesser 

Digitale støtteprosesser

EHF Utvikle og forvalte standardformat

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF utvikle og forvalte standard format
Prosess IDX511 Utvikle og forvalte standard format
OrganisasjonDFØ-ANS
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.11.26Dokument etablertPetter Vinje
    
    
    

3. Om prosessen

Prosessen beskriver hvilke aktiviteter, som må og kan utføres i hvilken rekkefølge, av hvilke personer/organisajsoner/systemer, hver gang det skal utvikles og forvaltes et standard format.

4. Brukere og bruksområde 

  • Prosjektleder:

- Alle som leder denne type utviklingsprosjekter skal/kan benytte prosessen i 
-- Planlegging: Identifiser og avklare hvilke aktiviteter det er behov for. 
-- Organisering: Tilrettelette og organisere arbeidet.  
-- Ledelse: Veilede, coach, motivere deltakerne. 
-- Kontroll: Følge opp milepælene, iverksette tiltak ved avvik.
-- Læring og utvikling:  Fordi utvikling og forvaltning er en prosess må de som skal forbedre prosessen ha oversikt over prosessen.

  •  Prosjektdeltakere:

- Alle som deltar i prosjektet skal være kjent med og benytte prosessen og de metoder, verktøy som er beskrevet der. Gjør det enklere å forstå hvilke aktiviteteter man har ansvar for, hvordan disse         skal utføres, hvem man skal samarbeide med.  

  • Prosjekteier/programeier:

- Avhengig av prosessen for å sikre at alle prosjekter gjennomføres på en like god måte.

  • Offentlig virksomhet

- Er avhengig av prosessen for å dokumentere sin praksis i interne prosessverktøy og sikre at prosjekter utføres på en riktig og effektiv måte. 
- Er avhengig av prosessen for å kunne forbedre og utvikle seg. Uten prosessfokus er det ikke mulig å utvikle organisasjon eller virksomhet.

  • Systemleverandører, oppdragsgivere, leverandører:

- Det er mange elementer i prosessen som systemleverandører, oppdragsgiver og andre kan benytte i eget arbeid. 

  • HR-funksjoner/endringsledelse:

- HR er avhengig av prosessen i sitt arbeid med rekruttering og utvikling av medarbeidere og organisasjon. Endringsledelse er avhengig av prosessen for å avdekke behov for endringer i en så tidlig fase som mulig – øke mulighetene for vellykket endring og gevinstrealisering.

  • Markedsfunksjonen:

- Er avhengig av prosessen for å identifisere behov/muligheter for å iverksette markedstiltak i en tidlig fase. 

5. Formål

Sikre at utvikling og forvaltning av standard formater forbedres og gjennomføres på en mest mulig effektiv måte. 

6. Mål

  • Til enhver tid ha en oppdatert prosessdefinisjon.
  • Benytte prosessdefinisjonen i  planlegging, organisering, ledelse og kontroll av alle prosjekter. 
  • Benytte prosessdefinisjonen i rekruttering, opplæring og utvikling av prosjektledere og deltakere.
  • Benytte prosessdefinisjonen i forbedring og utvikling av organisasjonen. 
  • Sikre at kompetanse dokumenteres slik at risiko for problemer ved sykdom og fravære reduseres.

7. Gevinster

Bruk av prosessdefinisjoner er en ubetinget fordel for alle som bidrar til og skal bruke standardiserte formater.

  • Enklere: Bruk av prosessen som sjekkliste gjør det enklere å planlegge og gjennomføre prosjekter.
  • Raskere: Ved å følge prosessen reduseres unødvendig bruk av tid. Prosjekter kan gjennomføres raskere – økt produktivitet. 
  • Bedre: Ved å følge prosessen vil kvaliteten på leveranser bli jevnt sett høyere – reduserer uønskede variasjoner. Enklere, raskere og bedre arbeid gir økt bruker og medarbeidertilfredshet. 
  • Rimeligere: Bedre kvalitet og mer effektive prosesser reduserer ressursbruk.
  • Mer attraktiv: Enklere, raskere, bedre og rimeligere prosesser gjør oss mer attraktive som organisasjon for brukere og ansatte.
  • Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

  • Prosess: En systematisk serie med aktiviteter rettet mot oppnåelse av ett eller flere mål. 
  • Effektivitet: Prosessen benytter ikke mer ressurser enn det som er nødvendig for å produsere format med ønsket kvalitet. 
  • Produktivitet: Antall formater som utvikles i en bestemt tidsperiode.
  • Kvalitet: Er her det samme som kvalitet på informasjonen – at den er komplett og nøyaktig – oppfyller brukerens behov – ikke måtte bruke ekstra tid, ressurser på å finne, rette, legge til informasjon som mangler. 

9. Startkriterier/forutsetninger

Trigger

  Prosessdefinisjonen tas i bruk når prosjekt er besluttet igangsatt.

Andre forutsetninger

Ledelsen må tilrettelegge og sikre at alle prosjekter følger prosessen. Kultur for å arbeide prosessorientert.

​​10. Input og leverandører

InputAvgivende prosess:Leverandør av inputReferanse
Beslutning m/prosjektgrunnlagLedelseProsjekteier 
    
    
    

11. Deltakere
Beskrivelse av roller finner du: https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar

OrganisasjonRolle (ved behov)ForkortelserKommentarer
DFØ ANSProsjekteierPE 
DFØ ANSProsjektlederPL 
DFØ ANSProsjektdeltakerePD 
Oppdragsgiver OO benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver.
Leverandør LAngir at aktivitet utføres av en leverandørorganisasjon.
Systemleverandør SLSL benyttes når det er behov for å angi at aktiviteten utføres av en systemleverandør. Som regel er det ikke behov for å angi hvilke rolle som utfører aktiviteten hos systemleverandør.
Ev andre Ev. andreMan kan også legge til roller dersom det er hensiktsmessig.
    

12. Prosessdiagram

Prosess 511
 
 

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
X5111Analysere behov og mulighetPLLenke til delprosess  
X5112Utvikle teknisk veilederPLLenke til delprosess  
X5113Forvalte standard formaterPLLenke til delprosess  
      

14. Kontrollpunkter og målinger

Aktivitet nr.Hva som skal kontrolleres, måles Hvordan det skal gjøresHvorfor det er nødvendig
IngenProsessen kontrolleres ved bruk av sjekklister og oppfølgningsmøter.   
     

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Et format som blir utviklet og vedlikehold og publisert på anskaffelser.dev.no Systemleverandører 
Et format som blir utviklet og vedlikehold og publisert på anskaffelser.dev.no Oppdragsgivere 
Et format som blir utviklet og vedlikehold og publisert på anskaffelser.dev.no Leverandører 
Et format som blir utviklet og vedlikehold og publisert på anskaffelser.dev.no Alle andre som har behov/ønske om å informasjon om prosessen og format. 

16. Sluttkriterier

Utviklingsfasen avsluttes når høring er avsluttet. Forvaltningsfasen avsluttes når formatet publiseres i ny versjon og gammel format fjernes.  

17. Unntak/spesielle hensyn

Del-prosess, aktivitetUnntak/hensyn  
X5111 Analysere behov og mulighet

I tilfeller hvor prosessen er mer omfattende og praksis varierer vil erfaringsmessig hele WS1 medgå til å kartlegg og diskutere hvordan prosessen ser ut. Et arbeid som kan være krevende både for de som skal ha workshop og delta.

Et alternativ til dette er å be deltakerne fylle ut et excelark hvor de beskriver sine oppgaver og svarer på noen spørsmål med et oppfølgningsintervju i etterkant. Fordelen med det er at de som skal arrangere workshopen får oversikt over situasjonen og kan være bedre forberedt til WS1. Fordelen for deltakerne er at de allerede har reflektert over egen situasjon. Fordelen for alle er at man kan gjennomføre en bedre WS i betydningen at man kan bruke mer tid på gode diskusjoner og avklaringer og redusere behov for ytterligere WS.
X5112 Utvikle teknisk veilederAktivitet 7 og 8 er avhengig av prosjekt. Noen ganger er syntaks definert. Andre ganger må den lages.

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Deltakerne benytter ikke/avviker fra prosessen.HøyLav-høyKontrollere at prosessen benyttes.Eskalere, varsle, informere om konsekvensene.

19: Behov for støtte

StøtteForklaring/Lenker
Prosjektleder vil ha behov for opplæring og støtte i prosessen og hvordan den skal/kan brukes.    
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Resultatet av prosessen vil publiseres her: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Her finner du et Gantdiagram som omhandler analyse og teknisk utvikling

EHF Analysere behov og mulighet

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF Analysere behov og mulighet
Prosess IDX5111 Analysere behov og mulighet
OrganisasjonDFØ-ANS
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.11.26Dokument etablertPetter Vinje
    
    
    

3. Om prosessen

Prosessen X5111 Analysere behov og mulighet er den første av de tre del-prosessene i X511 Utvikle og forvalte standard format. Prosessen begynner når beslutning om prosjekt er tatt. Og beskriver alle aktiviteter knyttet til planlegging og analyse av behov/mulighet for format – grunnlaget for de som skal utvikle teknisk veileder.    

4. Brukere og bruksområde 

Programeier, prosjektleder, deltakere har behov for prosessen når:

  • Prosjektet skal planlegges.
  • Behov og mulighet for bruk av standard format skal identifiseres og avklares. 
  • Besluttning om utvikling og eventuelt videre arbeid skal tas.

5. Formål

Sikre kvalitet og effektivitet i utvikling av teknisk veileder.

6. Mål

  • Sikre at alle som deltar i prosjektet blir involvert og informert så godt og tidlig som mulig. 
  • Sikre at brukernes behov blir ivaretatt og riktig format utviklet.
  • Sikre at alternative løsninger blir vurdert og mest hensiktsmessig løsning valgt.
  • Sikre at de som utvikler teknisk veileder får den informasjonen de må ha for å kunne utvikle formatet på en effektiv måte.
  • Sikre at behov for markedsføringstøtte og endringsledelse er forstått og planlagt i god tid. 

7. Gevinster

Alle som eier, ledere, deltar i prosjektet vil ha følgende fordeler.

  • Enklere, raskere og bedre planlegging – grunnlag for effektiv utvikling og bruk av utviklingsressurser. 
  • Tidlig involvering og informasjon bidrar til økt tilfredshet og motivasjon hos deltakerne. 
  • Tidlig involvering av HR, markedsfunksjon reduserer risiko for at viktige tiltak knyttet til endring og markedsføring ikke iverksettes tidlig nok.
  • De som skal utvikle tekniske veiledere får den informasjon de må ha for effektiv utvikling.
  • Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

  • Prosess: En systematisk serie med aktiviteter rettet mot oppnåelse av ett eller flere mål. 
  • Effektivitet: Prosessen benytter ikke mer ressurser enn det som er nødvendig for å produsere format med ønsket kvalitet.
  • Produktivitet: Antall formater som utvikles i en bestemt tidsperiode. 

9. Startkriterier/forutsetninger

Analyseprosessen starter når beslutning om prosjekt er tatt.

Trigger

  Beslutning om prosjekt.

Andre forutsetninger

Ledelsen må tilrettelegge og sikre at alle prosjekter følger prosessen. Kultur for å arbeide prosessorientert

​​10. Input og leverandører

InputAvgivende prosess:Leverandør av inputReferanse
Beslutning m/prosjektgrunnlagLedelseProsjekteier 
    

11. Deltakere
Beskrivelse av roller finner du her: https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar

OrganisasjonRolle (ved behov)ForkortelserKommentarer
DFØ ANSProsjekteierPE 
DFØ ANSProsjektlederPL 
DFØ ANSProsjektdeltakerePD 
DFØ ANSProsessansvarligPRA 
DFØ ANSFormatansvarligFA 
Oppdragsgiver OO benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. 
Leverandør LAngir at aktivitet utføres av en leverandørorganisasjon.
Systemleverandør SLSL benyttes når det er behov for å angi at aktiviteten utføres av en systemleverandør. Som regel er det ikke behov for å angi hvilke rolle som utfører aktiviteten hos systemleverandør.
    
Ev andre Ev andreMan kan også legge til roller dersom det er hensiktsmessig.

12. Prosessdiagram

Prosess X5111
 
 

Lenke til prosessdiagram i Excel

Dersom du har visio og ønsker å bruke/redigere diagrammet.

  • Høyre-klikke på diagrammet
  • Klikk "Visio-objekt"
  • Klikk "Redigier" eller Åpne" diagram i visio.

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
 Starte prosjekt 

 

  
 1. Lage prosjektgrunnlag:PESjekkliste
>Målbilde:
>Hvordan skal aktørene benytte produktet?
>Hvordan passer produktet inn i anskaffelsesprosessen?
>Hvilke kontrollmekanismer skal etableres?
>Krav til statistikkinnsamling?
>Krav til metode?
>Krav til gjennomsiktighet?
>Hva er utenfor scope (avgrensninger)?
>Resultat:
>>Hvilke del-produkter skal produseres?
>>Hvilke bi-produkter skal produseres?
>>Hvilke brukere har de ulike del-/bi-produktene?
>>Hvilke krav stilles til implementerere?
>>Hvilken funksjonalitet stilles det krav om?
>>Annet?
 Mal
 2. Lage forslag til mandatPL  Mal
 3. Godkjenne mandatPE   
 4. Lage forslag til prosjektplanPL  Mal
 5. Godkjenne prosjektplanPL   
 6. Planlegge  og gjennomføre Kick-offPL  >Excel oppgavearke
 7. Planlegge WS1 og fortsette arbeidet med utvikling av informasjonsmodell og fylle ut malerPL  >Excel oppgaveark
>Undersøke om muligheter for pilotering av standard format.
 8. Ev. Gjennomføre kartlegging og intervjuPRA>Lage AS-IS prosessmodell >Excel oppgaveark mal
>Presentasjons eksempel med spørsmål
 9. Beskrive nåsituasjon: AS-ISPRA>Kartlegge forventninger
>Kartlegge AS-IS situasjon 
 >Prosessrammeverk 
>BPMN 2.0 notasjon
>Sjekkliste
 10. Gjennomføre WS1 AS-ISPL  >Sjekkliste
>Eksempler
 11. Beskrive fremtidig  situasjon for brukere og interessenterPRA>Forventning og krav til format og prosess. 
>Endringsbehov
>Gevinstmuligheter
 >Sjekkliste
 12. Planlegge WS2 og videreføre arbeid med utvikling av informasjonsmodell og maler, TO-BE prosessmodell, Use casePL>Informasjonsmodell
>Prosessmodell
>Use Case
>Fylle ut maler
 >Maler
>Eksempler
 13. Gjennomføre WS2 Fremtidig situasjonPLDersom det ikke er behov for en WS2 bør det likevel holdes et avsluttnings-/informasjonsmøte.  
 14. Lage analyserapportPLI tilfellet det kun blir WS1 kan arbeidet med å sluttføre rapporten påbegynnes etter aktivitet 10. med eventuell gjennomgang i et avsluttningsmøte.  
 15. Godkjenne analyserapportPE   
      

14. Kontrollpunkter og målinger

I denne prosessen vil bruk av sjekklister og oppfølgningsmøte være tilstrekkelig som kontroll og oppfølgning.  

Aktivitet nr.Hva som skal kontrolleres, måles Hvordan det skal gjøresHvorfor det er nødvendig
   Kontroll sikres ved bruk av sjekklister og oppfølgningsmøter. 
     

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
AnalyserapportX5112 Utvikle teknisk veilederDFØ ANS 
    

16. Sluttkriterier

Rapport fra analysefasen må være godkjent før neste prosess kan påbegynnes

17. Unntak/spesielle hensyn

Del-prosess, aktivitetUnntak/hensyn  
Aktivitet 8.Dersom det er behov/fordel at deltakerne forbereder seg til noe før WS1 anbefales det at de gis en oppgave med eventuelle oppfølgningsmøter. Dersom det er behov for å lage prosesskart anbefaler vi at dette forberedes, gjøres her, ikke i WS1 fordi det kan ta mye tid fra viktige diskusjoner.  

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Avviker fra prosessenHøyLav-høyProsjektleder må kontrollere at prosessen følges.

Prosessen tillater avvik i de tilfeller det er hensiktsmessig.
Dersom det oppstår ikke hensiktsmessige avvik, må Prosjektleder kartlegge årsaken og iverksette tiltak.
Dersom avviket representerer en forbedring, bør prosessdefinisjonen oppdateres og endring kommuniseres.  

     

19: Behov for støtte

StøtteForklaring/Lenker
Behov for opplæring i utførelse av prosess. 
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Sluttresultatet, en EHF, publiseres her: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

EHF Utvikle teknisk veileder

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF Utvikle teknisk veileder
Prosess IDX5112 Utvikle teknisk veileder
OrganisasjonDFØ-ANS
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.12.02Dokument etablertPetter Vinje
    
    
    

3. Om prosessen

Prosessen beskriver alle aktiviteter som må/kan utføres i utvikling av teknisk veileder/standard format.

4. Brukere og bruksområde 

  • DFØ ANS trenger prosessen for å dokumentere hvordan de arbeider med utvikling av veileder/standard format.
  • Programleder/eier trenger prosessen for å sikre at alle prosjekter utvikler veiledere/standard formater med samme effektivitet og kvalitet. Samt forbedrer disse.
  • Prosjektleder trenger prosessen for å forsikre seg om at de som utvikler teknisk veileder/standard format har den nødvendig kompetansen, og arbeider på den riktige måten.
  • De som utvikler teknisk veileder/standard format trenger prosessen for å forstå hvordan disse skal utvikles.

5. Formål

Sikre en mest mulig effektiv utvikling av teknisk veileder/standard format.    

6. Mål

  • Til enhver tid ha oppdatert prosessdefinisjon som speiler beste praksis og ivaretar utviklernes behov for informasjon om prosess, leveranser, etc.
  • Redusere utviklingstid for de som skal utvikle systemer/tjenester.
  • Skape interoperabilitet mellom ulike systemer.
  • Bruke prosessdefinisjonen som grunnlag forbedrings- og utviklingsarbeid. 

7. Gevinster

  • Enklere. For de som skal utvikle standard formater blir det enklere å lære og utføre sine oppgaver.  
  • Raskere. Når de som skal utvikle forstår og følger prosessen vil utviklingen gå raskere. 
  • Bedre. Når de som skal utvikle veilederen kan arbeider raskt og riktig får vi også en jevnere, bedre kvalitet. 
  • Rimeligere. Når de som utvikler kan gjennomføre raskere og bedre utviklingsprosesser vil vi redusere ressursbruk og kostnader – øke produktivitet.
  • Mer attraktive: enklere, mer effektiv arbeid med høyere kvalitet på leveranser gjør oss mer attraktive for ansatte og brukere. 
  • Risiko: Standardiserte prosesser reduserer risiko for problemer ved sykdom, jobbskifte, fravær.

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

  • Prosess: En systematisk serie med aktiviteter rettet mot oppnåelse av ett eller flere mål. 
  • Effektivitet: Prosessen benytter ikke mer ressurser enn det som er nødvendig for å produsere format med ønsket kvalitet.
  • Produktivitet: Antall formater som utvikles i en bestemt tidsperiode.
  • Kvalitet: Er her det samme som kvalitet på informasjonen – at den er komplett og nøyaktig – oppfyller brukerens behov – ikke måtte bruke ekstra tid, ressurser på å finne, rette, legge til informasjon som mangler. 

9. Startkriterier/forutsetninger

Trigger

  Når analyserapport er godkjent.  

Andre forutsetninger
  • Ledelsen må forsikre seg om at de som utfører prosessen har den nødvendige komptanse, følger prosessen og bidrar med forbedringsforslag. 

​​10. Input og leverandører

InputAvgivende prosess:Leverandør av inputReferanse
Beslutning m/prosjektgrunnlagLedelseProsjekteier 
AnalyserapportX5111 EHF Analyse av behov og mulighetProsjektleder 
Use caseX5111 EHF Analyse av behov og mulighetProsjektleder 
Rolle og prosessdiagramX5111 EHF Analyse av behov og mulighetProsjektleder 
SpesifikasjonerX5111 EHF Analyse av behov og mulighetProsjektleder 
ForretningsreglerX5111 EHF Analyse av behov og mulighetProsjektleder 
    

11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar

OrganisasjonRolle (ved behov)ForkortelserKommentarer
DFØ ANSProsjekteierPE 
DFØ ANSProsjektlederPL 
DFØ ANSProsjektdeltakerePD 
DFØ ANSProsessansvarligPRA 
DFØ ANSFormatansvarligFA 
Oppdragsgiver OO benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. 
Leverandør LAngir at aktivitet utføres av en leverandørorganisasjon.
Systemleverandør SLSL benyttes når det er behov for å angi at aktiviteten utføres av en systemleverandør. Som regel er det ikke behov for å angi hvilke rolle som utfører aktiviteten hos systemleverandør.
    

12. Prosessdiagram

Prosess X5112
 
 

Lenke til prosessdiagram i Excel

Dersom du har Visio og ønsker å bruke/redigere diagrammet:

  • Høyre-klikke på diagrammet i Excel
  • Klikk "Visio-objekt"
  • Klikk "Redigier" eller Åpne" diagram i Visio.

13. Aktiviteter

IDFørAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
 A1. Gjennomgå eksisterende standarder >CEN
>PEPPOL
  
 A2. Definere forretningsregler >Bruk kravmalen som er fylt ut i analysefasen  
 23. Definere datamodell >Bruk meldingsdokumentet og kravsdokumentet fylt ut i analysefasen  
 A4. Velge eller opprette repo på Github >GitHub  
 15.Benytte eksisterende kodelister eller lage nye kodelister >ISO stanadarder
>Se Post-Award kodeliser
>Se Pre-Award kodelister
  
 1,56. Undersøke syntaks muligheter >Bruke meldingsmalen, blir fylt ut i analysefasen
>Bruke AnsBL til å forme syntaksen, hvis ikke UBL eller annen syntaks kan brukes
  
 1,2,3,5,67. Lage syntaksbinding mot eksisterende syntaks >UBL
>XML
>Riktig namespace
>Elementer og attributter
>Kodeliste
>Regler
  
 1,2,3,4,5,68. Lage syntaks og syntaksbinding for ikke eksisterende syntaks >AnsBL 
>XML
>Riktig namespace
>Elementer og attributter
>Kodeliste
>Regler
  
 2,7,89.  Lage og teste regler Schematron >Forretningsregler
>Bruke kravmalen, blir fylt ut i analysefasen.
>Teksteditor
  
 5,7,8,910. Lage eksempelfil >Syntaksbindingen
>Teksteditor (Atom, …)
  
 5,7,8,9,1011. Lage snippets >Asciidoc - som referanse
>Syntaksbindingen - som tagger
  
 A12. Lage spesifikasjon    
 1213. Skrive introduksjon og bakgrunn for formatet >Asciidoc
>Bruke prosjektbeskrivelsesmalen, blir fylt ut i analysefasen
  
 5,7,8,9,10,11,1314. Beskrive de viktige aspektene ved formatet (ferdig spesifikasjon) >Asciidoc
>Syntaksbindingen/meldingsmalen fra analysefasen
  
 A15. Lage usecase >Asciidoc
>Bruk use case malen, blir fylt ut i analysefasen
  
 A16. Lage rolle og prosessdiagram >BPMN 2.0
>UML
  
 5,7,8,9,1017. Lage change log og releasenote >Asciidoc: Skriv endringer som har blitt gjort  
 5,7,8,918. Etablere validatorstøtte >Schematron filer  
 1819. Etablere 0.9 versjon Sjekkliste: 
- Eksempelfilene validerer,
- Syntaks,
- Visningen av snippetsene,
- Eksempler i syntaksen uten bugs,
- Schematron regler,
- Tittel,
- Versjonsnummer,
- Visningen av lenkene,
- Rekkefølgen av innholdet i guiden,
- Visning av bildene,
- Rollediagram, 
- Prosessdiagram
  
 1920. Sende ut på review >anskaffelser.dev  
 2021. Gjennomgang av høringssvar >SuperOffice (ehf@dfo.no)
>GitHub (Issue)
  
 2122. Implementering av høringssvar >Oppdatere formatet
>Teste endringene
  
 2223. Sende format ut på offisielt review >anskaffelser.dev  
 2324. Gjennomgang av høringssvar >SuperOffice (ehf@dfo.no)
>GitHub (Issue)
  
 2425. Implementering av høringssvar >Oppdatere formatet
>Teste endringene
  
 2526. Lage erfaringsnotat >Dokumentere prosess  
 8,927. Lage identifikatorer >Etter retningslinjer fra Peppol  
 2728. Søke Peppol om godkjenning av identifikatorer >Peppol eDelivery  
       

14. Kontrollpunkter og målinger

Aktivitet nr.Hva som skal kontrolleres, måles Hvordan det skal gjøresHvorfor det er nødvendig

Ingen

  Prosessen kontrolleres ved hjelp av sjekklister, oppfølgingsmøter, validator. 
     

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Teknisk veileder (EHF)Brukernes prosesserOppdragsgiver 
Leverdører
Systemleverandører
 
Gyldig Syntaks (dokumentinstans)Brukernes prosesserOppdragsgiver 
Leverdører
Systemleverandører
 

16. Sluttkriterier

Prosessen er ferdig når høringen er gjennomført og høringssvarene implementert.

17. Unntak/spesielle hensyn

Del-prosess, aktivitetUnntak/hensyn  
Aktivitet 7 og 8Avhengig av prosjektet. Noen ganger definert syntaks, andre ganger må vi lage.

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Avviker fra prosessenLavLav-høyProsjektleder må kontrollere at prosessen følges

Prosessen tillater avvik i de tilfeller det er hensiktsmessig.

Dersom det oppstår ikke hensiktsmessige avvik, må Prosjektleder kartlegge årsaken og iverksette tiltak.

Dersom avviket representerer en forbedring, bør prosessdefinisjonen oppdateres og endring kommuniseres.  

19: Behov for støtte

StøtteForklaring/Lenker
De som skal gjennomføre prosessen må få opplæring, veiledning og støtte i arbeidet.   
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Resultatet av prosessen (EHF) publiseres her: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

22.1 Gant diagram

Diagrammet beskriver hovedaktivitetene og rekkefølgen i utvklingsfasen.  Lys grønn indikerer når de kan påbegynnes.

5112 Gantdiagram

X5112 Gantdiagram1
 
 

 

EHF Forvalte standard format

Prosess Definisjon Dokument (PDD) DIFI ANS ATS

1. Informasjon

Prosess navnEHF Forvalte standard format
Prosess IDX5113 Forvalte standard format
OrganisasjonDFØ-ANS
Prosess eierJan Mærøe
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.02020.12.03Dokument etablertPetter Vinje
    
    
    

3. Om prosessen

 Prosessen beskriver alle aktiviteter som må eller kan utføres i forvaltning av standard format.  Etter teknisk utvikling overtar forvaltningsorganisasjonen ansvaret for formatet.

4. Brukere og bruksområde 

  • DFØ ANS trenger prosessen for å dokumentere forvaltningsprosessen.
  • DFØ trenger prosessen for å sikre at ønsker fra brukerne blir ivaretatt på en god måte.
  • DFØ ANS trenger prosessen for sikre at kompetanse i forvaltning av standard format utvikles/blir i virksomhet og kan overføres til andre – unngå problemer som oppstår ved skifte, fravær. 
  • DFØ ANS trenger prosessen for å kunne forbedre, utvikle forvaltningen av standard format.
  • Deltakerne i forvaltning av standard format trenger prosessen for å forstå, planlegge og gjennomføre sine oppgaver på en koordinert måte. 

5. Formål

Sikre at standardformat forvaltes på en rask, effektiv og riktig måte.

6. Mål

  • Implementere endringsønsker og tilrettelegge for en kvalitetsmessig og effektiv implementering av endringer i de ulike systemene.

7. Gevinster

Alle som eier, ledere, deltar og skal bruke resultatet av bedre prosesser vil ha en fordel, gevinst av denne prosessen.

  • Brukerne: Endringsønsker blir ivaretatt. Ny funksjonalitet/tjenester utvikles i systemer. 
  • DFØ ANS: Relevant og attraktiv for markedet.
  • Oppdragsgivere: Effektiv kvalitetsmessig implementering i deres systemer. 
  • Leverandører: Effektiv kvalitetsmessig implementering i deres systemer.
  • Systemeleverandører: Effektiv kvalitetsmessig implementering i deres systemer. 
  • Samfunnet: Enklere å operasjonalisere politiske beslutninger. 

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

  • Prosess: En systematisk serie med aktiviteter rettet mot oppnåelse av ett eller flere mål. 
  • Effektivitet: Prosessen benytter ikke mer ressurser enn det som er nødvendig for å produsere format med ønsket kvalitet.
  • Produktivitet: Antall formater som utvikles i en bestemt tidsperiode. 
  • Informasjonskvalitet: Kvaliteten på informasjonen som mottas. 100% informasjonskvalitet vil si at informasjonen er komplett og riktig slik at de som mottar den kan utføre sine oppgaver/aktiviteter på en riktig og effektiv måte – ikke måtte bruke ekstra tid, ressurser på å finne, rette, legge til informasjon som mangler. 

9. Startkriterier/forutsetninger

Trigger

  Innkommende endringsønsker

Andre forutsetninger
  • Ledelsen må legge til rette for at de som skal utføre prosessen har mulighet til å det. For eksempel at prosessen er definert, oppdatert med lenker til verktøy, metoder og at det er gitt opplæring.
  • Ledelsen må sikre at prosessen følges.

​​10. Input og leverandører

InputAvgivende prosess:Leverandør av inputReferanse
Endringsønske Peppol BIS, formel kanal 
Endringsønske GitHub 
Endringsønske EHF@DFO.no 
    

11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar

OrganisasjonRolle (ved behov)ForkortelserKommentarer
DFØ ANS ATSEHF teamEHF-T 
Oppdragsgiver OO benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver
Leverandør LAngir at aktivitet utføres av en leverandørorganisasjon.
Systemleverandør SLSL benyttes når det er behov for å angi at aktiviteten utføres av en systemleverandør. Som regel er det ikke behov for å angi hvilke rolle som utfører aktiviteten hos systemleverandør.
    

12. Prosessdiagram

Prosess X5113
 
 

Lenke til prosessdiagram i Excel

Dersom du har Visio og ønsker å bruke/redigere diagrammet:

  • Høyre-klikke på diagrammet i Excel
  • Klikk "Visio-objekt"
  • Klikk "Redigier" eller Åpne" diagram i Visio.

13. Aktiviteter

IDFørAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
  1. Sjekke endringsønsker >Via release not Peppol BIS
>GitHub
>EHF@DFO.no
 Forskjellen på minor og major er tidsforløpet i varsling og implementering av ny versjon
 12. Vurder endringsomfanget Om det er bug,minor eller major  
 23. BUG: Analyser hva som må gjøres. Iverksette tiltak    
 34. BUG:Dokumenter endring For bruk i release note og dokumenter endring i change log  
 45. BUG: QA 
(Kvalitetssikring)
    
 56. BUG: Oppdater i eksisterende EHF veileder(e)    
 67. BUG: Sette i produksjon Etter denne aktiviteten er retting utført i veileder og endring publisert  
 28. M/M:Analyser og planlegg det som må utvikles    
 89. Utvikling av endring (Syntaks, kodelister, schematronregler)  
 910. Oppdatere EHF veileder(e)    
 1011. QA 
(Kvalitetssikring)
    
 1112. Etablere release note og change log    
 1213. Send ut melding til alle brukere. Om den forestående endringen med informasjon om høringens startdato og sluttdato. Varsler hvilken dato ny versjon trer i kraft  
 1314. Korriger endring hvis det er feil. Hvis ikke send melding om at vi er uenig i kommentaren Hvis det kommer kommentarer på endring.  
 1415. Publiser ny versjon    
 1516. Varsle markedet om fjerning av gammelt format    
 1617.Gi melding til Digitalisereringsdiretoratet Om å slette mulighet for nyregistrering av gammelt format i ELMA og slettingsdato av gammel versjon  
 1718. Fjerne mulighet for nyregistrering av gammel versjon  i ELMA    
 1819. Fjerne gammel versjon fjernet fra ELMA    
       

14. Kontrollpunkter og målinger

Aktivitet nr.Hva som skal kontrolleres, måles Hvordan det skal gjøresHvorfor det er nødvendig
Ingen  Prosess kontrolleres ved bruk av sjekklister. 
     

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
Pilot candidateMottaker/brukers egne prosesserSystemleverandørBenyttes når markedet/prosessen er umodent, fordel med pilot.
Release candidate (RC) 1,2,..Mottaker/brukers egne prosesserSystemleverandørBenyttes når markedet/prosessen er umodent. 
Oppdatert versjonMottaker/brukers egne prosesserSystemleverandør 
    

16. Sluttkriterier

  1. Når høringen er gjennomført og høringssvarene implementert. Publisere ny versjon.
  2. Når mulighet for registrering av gammel versjon er fjernet i ELMA (SMP).
  3. Gammel versjon er fjernet fra ELMA (SMP). 

17. Unntak/spesielle hensyn

Del-prosess, aktivitetUnntak/hensyn  
Dersom markedet ikke har implementert ny versjonMå gammel versjon leve inntil antall transaksjoner av ny versjon har nådd kritisk masse. Fastsettes av leder.

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
Avviker fra prosessenLavMedium-HøyMarkedet gir tilbakemelding om ev. avvikGå tilbake til relevant prosessteg.
Endring medfører så høy kostnader at systemleverandører ikke implementerer.LavHøyMarkedet gir tilbakemelding 
     

19: Behov for støtte

StøtteForklaring/Lenker
Behov for prosessopplæring. 
Behov for teknisk opplæring 
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

Lenke til informasjonsside: https://anskaffelser.dev/postaward/g3/announcement/ 

Release management: https://anskaffelser.dev/postaward/g2/policy/release-management/

Lenke til tekniske spesifikasjoner: https://anskaffelser.dev/

21. Tilleggsinformasjon

Nei

22. Vedlegg

Nei

HR-støtte

Endringsledelse

EHF implementeringsprosess av digitale løsninger i virksomheten

Prosess Definisjon Dokument (PDD) DFØ ANS ATS

1. Informasjon

Prosess navnEHF implementeringsprosess av digitale løsninger i virksomheten
Prosess IDX5211 EHF implementeringsprosess av digitale løsninger i virksomheten
OrganisasjonDFØ-ANS
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.0 Dokument etablert 
    
    
    

3. Om prosessen

  

4. Brukere og bruksområde 

 

5. Formål

 

6. Mål

 

7. Gevinster

Oppdragsgiver

Leverandør:   

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

Trigger

  

Andre forutsetninger

 

​​10. Input og leverandører

InputAvgivende prosess:Leverandør av inputReferanse
    
    
    
    

11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar

OrganisasjonRolle (ved behov)ForkortelserKommentarer
    
    
    
    
    

12. Prosessdiagram

 

 

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
      
      
      
      
      
      

14. Kontrollpunkter og målinger

Aktivitet nr.Hva som skal kontrolleres, måles Hvordan det skal gjøresHvorfor det er nødvendig
     
     

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
    
    

16. Sluttkriterier

 

17. Unntak/spesielle hensyn

Del-prosess, aktivitetUnntak/hensyn  
  

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
     

19: Behov for støtte

StøtteForklaring/Lenker
  
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

 

21. Tilleggsinformasjon

 

22. Vedlegg

 

EHF implementeringsprosess av digitale løsninger i virksomheten-analyse

Prosess Definisjon Dokument (PDD) DIFI ANS ATS

1. Informasjon

Prosess navnEHF implementeringsprosess av digitale løsninger i virksomheten- analyse
Prosess IDX EHF implementeringsprosess av digitale løsninger i virksomheten- analyse
OrganisasjonDFØ-ANS
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.0 Dokument etablert 
    
    
    

3. Om prosessen

  

4. Brukere og bruksområde 

 

5. Formål

 

6. Mål

 

7. Gevinster

Oppdragsgiver

Leverandør:   

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

Trigger

  

Andre forutsetninger

 

​​10. Input og leverandører

InputAvgivende prosess:Leverandør av inputReferanse
    
    
    
    

11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar

OrganisasjonRolle (ved behov)ForkortelserKommentarer
    
    
    
    
    

12. Prosessdiagram

 

 

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
      
      
      
      
      
      

14. Kontrollpunkter og målinger

Aktivitet nr.Hva som skal kontrolleres, måles Hvordan det skal gjøresHvorfor det er nødvendig
     
     

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
    
    

16. Sluttkriterier

 

17. Unntak/spesielle hensyn

Del-prosess, aktivitetUnntak/hensyn  
  

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
     

19: Behov for støtte

StøtteForklaring/Lenker
  
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

 

21. Tilleggsinformasjon

 

22. Vedlegg

 

EHF implementeringsprosess av digitale løsninger i virksomheten- implementering

Prosess Definisjon Dokument (PDD) DIFI ANS ATS

1. Informasjon

Prosess navnEHF implementeringsprosess av digitale løsninger i virksomheten- implementering
Prosess IDX EHF implementeringsprosess av digitale løsninger i virksomheten- implementering
OrganisasjonDFØ-ANS
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.0 Dokument etablert 
    
    
    

3. Om prosessen

  

4. Brukere og bruksområde 

 

5. Formål

 

6. Mål

 

7. Gevinster

Oppdragsgiver

Leverandør:   

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

Trigger

  

Andre forutsetninger

 

​​10. Input og leverandører

InputAvgivende prosess:Leverandør av inputReferanse
    
    
    
    

11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar

OrganisasjonRolle (ved behov)ForkortelserKommentarer
    
    
    
    
    

12. Prosessdiagram

 

 

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
      
      
      
      
      
      

14. Kontrollpunkter og målinger

Aktivitet nr.Hva som skal kontrolleres, måles Hvordan det skal gjøresHvorfor det er nødvendig
     
     

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
    
    

16. Sluttkriterier

 

17. Unntak/spesielle hensyn

Del-prosess, aktivitetUnntak/hensyn  
  

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
     

19: Behov for støtte

StøtteForklaring/Lenker
  
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

 

21. Tilleggsinformasjon

 

22. Vedlegg

 

EHF implementeringsprosess av digitale løsninger i virksomheten- forvaltning

Prosess Definisjon Dokument (PDD) DIFI ANS ATS

1. Informasjon

Prosess navnEHF implementeringsprosess av digitale løsninger i virksomheten- forvaltning
Prosess IDX5211 EHF implementeringsprosess av digitale løsninger i virksomheten- forvaltning
OrganisasjonDFØ-ANS
Prosess eier 
HenvendelserJan Mærøe

2. Historikk

VersjonDatoEndringForfatter/Rolle
1.0 Dokument etablert 
    
    
    

3. Om prosessen

  

4. Brukere og bruksområde 

 

5. Formål

 

6. Mål

 

7. Gevinster

Oppdragsgiver

Leverandør:   

Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver

8. Definisjoner/forkortelser

Nei

9. Startkriterier/forutsetninger

Trigger

  

Andre forutsetninger

 

​​10. Input og leverandører

InputAvgivende prosess:Leverandør av inputReferanse
    
    
    
    

11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar

OrganisasjonRolle (ved behov)ForkortelserKommentarer
    
    
    
    
    

12. Prosessdiagram

 

 

13. Aktiviteter

IDAktiviteter i prosesskartAnsvarAktivitetsbeskrivelse

KP (x)

Kommentar
      
      
      
      
      
      

14. Kontrollpunkter og målinger

Aktivitet nr.Hva som skal kontrolleres, måles Hvordan det skal gjøresHvorfor det er nødvendig
     
     

15. Output og mottaker/bruker

OutputMottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette.Mottaker/brukerReferanse
    
    

16. Sluttkriterier

 

17. Unntak/spesielle hensyn

Del-prosess, aktivitetUnntak/hensyn  
  

​​​​​​18. Risiko

RisikoSannsynlighetAlvorlighetMetodeTiltak
     

19: Behov for støtte

StøtteForklaring/Lenker
  
  

20. Lenke til EHF/PEPPOL BIS Spesifikasjon.

 

21. Tilleggsinformasjon

 

22. Vedlegg