Elektronisk handelsformat (EHF) gjør det mulig med standardisert, elektronisk kommunikasjon mellom virksomheter, uten direkte integrasjoner mellom datasystemer. Dette er en veileder for systemleverandører og brukere av prosessene. Oversikten forutsetter at man har prosesskompetanse.
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.
EHF kan være både anbefalt eller obligatorisk i henhold til lov/forskrift se Referansekatalogen.
EHF støtter oppunder regjeringens tiltak i henhold
til Meld. St. 22 Smartere innkjøp-effektive og profesjonelle
offentlige anskaffelser:
16.7 Regjeringens tiltak: det
finnes standardformater og fellesløsninger som muliggjør sømløs
flyt av informasjon mellom ulike verktøy i hele
anskaffelsesprosessen og på tvers av landegrenser
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.
Hva er en EHF prosess?
En EHF prosess er i denne sammenheng den prosess som understøttes av én eller flere EHFer. Mens EHF ordre er navnet på EHFen, er EHF ordre prosess navnet på prosessen. Legger prosess til EHF navn. Dersom prosessen har digital støtte som ikke inkluderer EHF kalles den Digital prosess. For eksempel støttes kunngjøringsprosessen digitalt, men ikke av EHF. Som følge av det kalles den Digital kunngjørings prosess.
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 identifiseres 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:

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 prosedyre – 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 |
---|---|---|
1 | Kategori - 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. |
2 | Hovedgrupper 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. |
3 | Prosess i hovedgruppe | X21= Vurdere behov - er en prosess i hovedgruppen X2. |
4 | Del-prosess og eller oppgave i prosess | X211=Beskrive dagens utfordringer og dagens løsning - er en del-prosess i prosessen X21 |
5 | Dersom 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:
ID | Aktivitet | EHF prosess | Rolle |
---|---|---|---|
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.no | Nå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.
EHF prosessoversikt er en utvidet delprosess/aktivitetsliste basert på anskaffelsesprosessen på Anskaffelser.no.
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 og anbefales av
Rammeverk for digital samhandling.
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

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.no.
Vi anbefaler systemleverandører å laste ned vår RSS-feed for å holde seg oppdatert: https://anskaffelser.no/
Digital - Elektronisk Handelsformat (EHF) og prosess
Digital kunngjøringsprosess
Digital søk kunngjøring prosess
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | Digital søk kunngjøring prosess |
---|---|
Prosess ID | X.3.1.4 Søk på kunngjøringer |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
---|---|---|---|
1.0 | 2020.08.17 | Dokument etablert | Petter 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/forutsetningeri
10. Input og leverandører
Input | Avleverende prosess | Leverandør/avsender - organisasjon | Referanse |
---|---|---|---|
Kunngjøringen | EHF kunngjøring prosess | Publiseringsdatabaser som Doffin og TED | |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
---|---|---|---|
Leverandør | System | L-sys | |
Publiseringstjeneste | System | Pub | |
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
---|---|---|---|---|---|
1. Systemsøk i publiseringsdatabasebasert på CPV-koder | L-sys | ||||
2. Send forespørsel om kunngjøringer | L-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åles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
---|---|---|---|
Nei |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Kunngjøring vist i leverandør system | Enten EHF vis interesse proses eller EHF utsendelse av anskaffelsedokumet prosess | Leverandør | |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
---|---|
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
---|---|---|---|---|
Nei |
19: Behov for støtte
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
---|---|---|---|---|
Nei |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon
Peppol BIS: https://docs.peppol.eu/pracc/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
Digital vise interesse for anskaffelse prosess
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | Digital vise interesse for anskaffelse |
---|---|
Prosess ID | X.3.1.5 |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.08.14 | Dokument etablert | Petter 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
Trigger |
Kunngjøring av anskaffelse |
---|---|
Andre forutsetninger |
Oppdragsgiver og leverandører har systemer som støtter den digitale prosessen. |
11. Deltakere
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
---|---|---|---|
Oppdragsgiver | System | O-sys | |
Leverandør | Person | L-per | |
Leverandør | System | L-sys | |
12. Prosessdiagram
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
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åles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
---|---|---|---|
Nei |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
---|---|---|---|
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
Hvor | Unntak - betingelser og endring |
---|---|
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
---|---|---|---|---|
Nei |
19: Behov for støtte
Støtte | Forklaring/Lenker |
---|---|
Behov for prosessopplæring. | |
Behov for systemopplæring |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://docs.peppol.eu/pracc/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
Digital utsendelse av anskaffelsesdokument prosess
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | Digital utsendelse av anskaffelsesdokument prosess |
---|---|
Prosess ID | X.3.1.6 Tilgjengeliggjøre/sende anskaffelsesdokumenter |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
---|---|---|---|
1.0 | 2020.08.19 | Dokument etablert | Petter 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
Input | Avgivende prosess | Leverandør av input | Referanse |
---|---|---|---|
Kunngjøringen | Doffin/TED | ||
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver |
System |
o-sys |
|
Leverandør |
Person |
l-per |
|
Leverandør |
System |
l-sys |
|
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
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 sending | O-sys | ||||
4. Motta anskaffelsedokumenter | L-sys | ||||
5. Klargjør bekreftelse på mottatt forsendelse | L-sys | ||||
6. Bekreftelse sent | L-sys | ||||
7. Lagre mottaksbekreftelse | O-sys | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
---|---|---|---|
Nei |
15. Output og mottaker/bruker
Output | Mottakende prosess: | Mottaker/bruker | Referanse |
Mottatt anskaffelsesdokumenter | Leverandør | ||
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
---|---|
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
---|---|---|---|---|
Nei |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring og systemopplæring. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://docs.peppol.eu/pracc/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
Digital spørsmål og svar prosess
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | Digital spørsmål og svar prosess |
Prosess ID | X.3.1.2 Svare på spørsmål fra leverandører X.3.1.8 Svare på spørsmål fra leverandører vedrørende anskaffelsesdokumenter X.3.2.5 Spørsmål og svar av eventuelle avklaringer til oppfyllelse av kvalifikasjon X.3.4.1 Spørsmål og svar på negativ respons til oppfyllelse av kvalifikasjon (DPS- kvalifisere seg igjen) |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.07.02 | Dokument etablert | Petter 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
Input | Avgivende prosess: | Leverandør av input | Referanse |
Kunngjøring | Kunngjøring | Doffin-TED | |
Anskaffelsesdokumenter | Utsendelse av anskaffelsesdokumenter | Oppdragsgivers KGV | |
Andre avklaringer | Alle prosesser i Anskaffelsesprosessen | Oppdragsgiver eller leverandørs systemer som dekker andre deler av prosessen | |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver |
Person |
o-per |
|
Oppdragsgiver |
System |
o-sys |
|
Leverandør |
Person |
l-per |
|
Leverandør |
System |
l-sys |
|
12. Prosessdiagram
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
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åles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
3 | Dersom du må anonymisere må du kontrollere at dette er gjort riktig. | Gjøres manuelt | Dersom 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
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
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
Hvor | Unntak - betingelser og endring |
I konkurransegjennomføringsprosessen er det lovpålagt å sende ev. anonymiserte spørsmål og svar til alle interessenter. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
I aktivitet 3 er det risiko for at informasjon ikke blir anonymisert. | Lav/medium | Høy | Ved bruk av system vil risiko reduseres. | System må bygge inn støtte for å minne oppdragsgiver på å anonymisere. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for opplæring i system og offentlige anskaffelser | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Peppol BIS Call for Tenders Question and Answeres: https://docs.peppol.eu/pracc/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
Digital kvalifisering prosess
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | Digital kvalifiseringsprosess |
Prosess ID | X.3.2 kvalifisere leverandører |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.08.21 | Dokument etablert | Petter 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
Input | Avleverende prosess: | Leverandør/avsender - organisasjon | Referanse |
Anskaffelsesdokumenter | X.3.1.6 Tilgjengligjøre/sende anskaffelsesdokumenter | Oppdragsgiver | |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle | Forkortelser | Kommentarer |
Oppdragsgiver | Person | O-per | |
Oppdragsgiver | System | O-sys | |
Leverandør | Person | L-per | |
Leverandør | System | L-sys | |
12. Prosessdiagram
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
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 anskaffelsesdokumenter | L-per | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor 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
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Leverandører innlag i kvalifiseringsdatabase. | X.3.4.8 Send inn tilbud. | Oppdragsgiver | |
Leverandører innlag i kvalifiseringsdatabase. | X.3.1.6Tilgjengligjøre/sende anskaffelsesdokumenter (DPS). | Leverandør | |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
---|---|
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
---|---|---|---|---|
Nei |
19: Behov for støtte
Støtte | Forklaring/Lenker |
---|---|
Behov for prosessopplæring. | |
Behov for systemopplæring |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
EHF ESPD: https://anskaffelser.dev/preaward/g2/spec/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
Digital CV prosess
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
ID og navn |
Denne prosessen støtter følgende prosesser: X.2.6.2 Definere krav til erfaring og kompetanse. X.3.5.6 Evaluere tilbud. https://www.anskaffelser.no/verktoy/veiledere/ehf-prosessoversikt |
EHF Prosess | Digital CV prosess |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2021.02.23 | Dokument etablert | Petter Vinje |
3. Definisjoner/forkortelser
- EHF = Elektronisk Handelsformat
- CV = Curriculume Vitae
4. Om prosessen
Prosessen begynner med at oppdragsgiver stiller krav og kriterier til kandidatens kompetanse. Kandidaten dokumenterer sin kompetanse. Oppdragsgiver gjennomfører en elektronisk bevisinnhenting og evaluering av kandidatens kompetanse. Til slutt velges beste kandidat.
5. Brukere og bruksområde
- Oppdragsgiver kan i alle tifeller benytte prosessen når behov for ekstern kompetanse oppstår.
6. Formål
Oppfylle krav til dokumentasjon og effektivisere oppdragsgiver og leverandørens prosess.
7. Mål
- 100% samsvar mellom kandiatens kompetanse/erfaring og krav og kriterier.
- Alle kandidater skal oppfylle virksomhetens sikkerhetskrav.
8. Måltall/KPIer
KPI | Kommentar |
9. Gevinster
For oppdragsgiver:
- Økt presisjonsnivå på kravstillingen sikrer bedre kvalitet på leveransen.
- Bruk og gjenbruk av standardformater samt automatisk bevisinnhenting og evaluering reduserer tids- og ressursbruk.
- Forenkling av prosess for leverandør kan føre til økt antall tilbydere i anskaffelsen.
For leverandør:
- Standardisering av krav og automatisering av prosess forenkler og effektiviserer leverandørens arbeid. For eksempel vil tydeligere krav redusere behov for å tolke, stille spørsmål, osv.
- Ved bruk av EHF CV etableres det et likt oppsett som hele offentlig sektor kan benytte, og som legger til rette for automatisert hel- eller delvis utfylling av besvarelsen.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
10. Startkriterier/forutsetninger
Trigger |
Behov for å utføre en tjeneste har oppstått |
Andre forutsetninger |
Teknologiske: Oppdragsgiver og leverandør må ha systemstøtte. |
11. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Beslutning/dokumentasjon av behov | For eksempel fra planleggingsprosess | Intern prosess | |
12. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Person | O-per | O-per benyttes når man ønsker å angi at denne aktiviteten utføres av en person hos oppdragsgiver, uten behov for å angi rolle. |
Oppdragsgiver | System | O-sys | O-sys benyttes når man ønsker å angi at aktiviteten utføres av oppdragsgivers system. |
Leverandør | Person | L-per | Angir at aktivitet utføres av en person i leverandørorganiasjon. |
Leverandør | System | L-sys | Angir at aktivitet utføres av et system i leverandørs organisasjon. |
Publiseringstjeneste | Pub | Pub benyttes når det er behov for å angi at aktiviteten utføres av en publiseringstjeneste, for eksempel Doffin. Her kan man også bytte ut Publiseringstjeneste med organisajsonens navn, for eksempel Doffin. | |
13. Prosessdiagram
Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
14. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
1. Vurdere tjenestens innhold, kategorisere, stille krav og kriterier – D. | O | ||||
2. Etablere anskaffelsesdokumenter. Forbered utlysning av konkurranse. Opprette CV og velge krav og kriterier – D. |
O | ||||
3. Send kunngjøring til Doffin og/eller TED | O-sys |
Systemspesifikk X.3.1.1 Kunngjøre konkurranse |
|||
4. Lage en EHF CV request og sammenstille denne med andre anskaffelsesdokumenter | O-sys | Systemspesifikk | |||
5. Søk i utlysningene og finn en anskaffelse som er av interesse | L-per | X.3.1.4 Søk på kunngjøringer | |||
6. Vurder hvilke anskaffelser som er interessante | L-per | ||||
7. Velg i system hvilke anskaffelsesdokumenter du ønsker å få tilsendt. | L-per | ||||
8. Lag en melding for å hente anskaffelsesdokumentene maskinelt | L-sys | Systemspesifikk | |||
9. Pakke dokumentene i en container og sende ut til de leverandører som har vist interesse | O-sys. | X.3.1.6. Tilgjengeliggjøre/sende anskaffelsesdokumenter | |||
10. Se gjennom EHF CV Request og tilpass CV basert på krav og kriterier – O. | L-per | Leverandør CV tjeneste | |||
11. Koble på elektronisk adresse til bevisdatabase hvis dette finnes | L-sys | Systemspesifikk | |||
12. Fyll ut andre anskaffelsesdokumenter til kvalifisering eller til annen prosedyrer | L-per | ||||
13. Sammenstill alle strukturerte og ustrukturerte dokumenter og pakke de i container. | L-sys | Systemspesifikk | |||
14. Evaluer og ranger EHF CV opp mot EHF CV request. | O-sys | Systemspesifikk | |||
15. Vurder kandidatene basert på rangert liste og velg den/de beste. | O-per | ||||
16. Sjekk bevis. | O-sys | Systemspesifikk | |||
17. Klarere sikkerhet. | O-per | ||||
18. Sammenstill alle resultater og velg den/de beste kandidatene. | O-per | ||||
15. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Aktivitet nr. 17 | Sjekke at korrekt klarering er motatt dersom dette stilles som krav. | Kan være manuell eller automatisk avhengig av system. | Sikre at personen tilfredstiller de riktige klareringskravene. |
Aktivitet nr. 18 | Kontrollere at priselement er knyttet til riktig person/kompetanse. | Systemstøtte for kobling av maskinlesbare elementer basert på unike identifikatorer. | For å oppnå automatisk evaluering. Mer effektiv prosess. |
16. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Bakgrunnsjekk utført. | X.3.5.5 Avvise tilbud som ikke oppfyller krav | Oppdragsgiver | |
Innstilling av beste kandidat. | X.3.5.6 Evaluere tilbud | Oppdragsgiver | |
17. Sluttkriterier
Nei
18. Unntak/spesielle hensyn
Hvor | Unntak/hensyn |
Nei |
19. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
---|---|---|---|---|
Nei |
20: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring | |
21. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke EHF ESPD: https://anskaffelser.dev/preaward/g2/spec/
22. Tilleggsinformasjon
Nei
23. Vedlegg
Nei
Digital eBevis prosess
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | Digital eBevis prosess |
Prosess ID | X.3.2.4 Vurder kvalifikasjoner basert på leverandørens utfyllelse av ESPD/egenerklæring og andre anskaffelsesdokumenter |
Organisasjon | DFØ-ANS |
Prosess eier | Hilde Kjølset |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.06.03 | Dokument opprettet | Jan 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
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
EHF ESPD; EHF egenerklæring | Innlevering av tilbud og kontraktsoppfølgingsprosessen | Leverandør | |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver |
Person |
o-per |
|
Oppdragsgiver |
System |
o-sys |
|
Leverandør |
Person |
l-per |
|
Leverandør |
System |
l-sys |
|
Leverandør | l | Når aktiviteten kan utføres av person eller system brukes kun l | |
eBevis tjenesten | System | eBT-sys | |
Offentlige beviskilder | System | Off-sys | Omfatter offentlige og leverandørdatabaser |
12. Prosessdiagram
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse |
KP (x) |
Kommentar |
1. Tolke ESPD, egenerklæringsskjema eller andre krav | o-sys | >Systemet ser på ESPD, egenerklæringsskjema eller andre input til krav og identifiserer hvilke bevis som skal hentes/sjekkes. | |||
2. Forberede eBevis/Get evidence | o-sys |
>Lage og sende eBevis melding basert på ESPD, egenerklæringsskjema eller andre input til krav. >Validere i henhold til EHF eBevis |
|||
3. Vurdere meldingsinnhold | eBT-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 samtykke | l-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 kilde | eBT-sys | >Sende forespørsel. | |||
6. Henter ut relevante bevis | oFF-sys | >Systemet henter informasjonselementer fra avgivende kilde. | |||
7. Populere EHF eBevis respons | eBT-sys | >Systemet sammenstiller informasjonselementer fra avgivende database og lager EHF eBevis respons. | |||
8. Motta bevis | oFF-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åles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
3 | >Kontrollere at avsender har lov til å innhente bevis. | Systemet sjekker om leverandør har gitt samtykke | Skal ivareta leverandørs rettigheter. |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
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
Hvor | Unntak - 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
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Risiko for at leverandør leverer bevis manuelt i stedet for samtykke til utlevering | lav | lav | >Regelverksendring for å muliggjøre uthenting av informasjon uten forhåndssamtykke fra leverandør. | |
Nedetid ut over definerte SLA krav. | lav | middels | >Prosess for avviksmelding hos Brønnøysund registrene. | |
Valideringsfeil | lav | lav |
>Kontakt systemleverandør. >Krev at systemleverandør følger forvaltning av format VEFA. |
|
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Nei
21. Tilleggsinformasjon
Nei
22. Vedlegg
Referanse | Tekst 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: | /anskaffelsesprosessen/anskaffelsesprosessen-steg-steg/konkurransegjennomforing/velge-tilbud-og-innga-avtale/vurdere-kvalifikasjoner/ebevis |
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 |
Digital tilbudsinnlevering prosess
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | Digital tilbudsinnlevering prosess |
Prosess ID | X.3.5.1 Ta imot tilbud |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.08.26 | Dokument etablert | Petter 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
Trigger | Mottak av anskaffelsesdokumenter |
Andre forutsetninger | Leverandør har eget system der han kan motta og behandle digitale anskaffelsesdokumenter. |
10. Input og leverandører
Input | Avleverende prosess: | Leverandør/avsender - organisasjon | Referanse |
Anskaffelsesdokumenter | X.3.4.8 Send inn tilbud | Oppdragsgiver | |
11. Deltakere
Beskrivelse av roller finner du
her:
Organisasjon | Rolle | Forkortelser | Kommentarer |
Oppdragsgiver | Person | O-per | |
Oppdragsgiver | System | O-sys | |
Leverandør | Person | L-per | |
Leverandør | System | L-sys | |
12. Prosessdiagram
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
1. Besvar de krav og kriterier oppdragsgiver har i anskaffelsesdokumentene | L-per | ||||
2. Tilbud fra leverandør på anskaffelsen er sendt | L-sys | ||||
3. Generer kvitteringsmeldig på mottatt tilbud | O-sys | ||||
4. Motta bekreftelsesmelding og lagre denne | L-sys | ||||
5. Registrere mottaks-tidspunkt | O-sys | ||||
6. Evaluer innsendte tilbud | O-per, O-sys | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei | Kontroll innebygget i system |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Evaluert tilbud | X.3.5.9 Meddele tildeling av kontrakt | Leverandør | |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
---|---|
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
For leverandører er det en risiko at de ikke overholder innleveringsfristen. | Lav | Høy | Systemstøtte, varsler. | Leverandør anskaffer systemstøtte med varsling. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring. | |
Behov for systemopplæring | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke EHF: https://anskaffelser.dev/preaward/g2/spec/
Lenke PEPPOL BIS: https://docs.peppol.eu/pracc/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
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
1. Informasjon
Prosess navn | EHF katalog prosess |
Prosess ID | X.4.1.2 Informere brukere om avtalen |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.05.20 | Dokument opprettet | Jan 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
Trigger | Katalogverktø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
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Innsendt tilbudskatalog | X.3.5.1 Ta imot tilbud | Leverandør | |
Innsendt katalog | X.4.1.1 Gjennomføre oppstartsmøte med leverandør | Leverandør | |
11. Deltakere
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver |
Person |
o-per |
|
Oppdragsgiver |
System |
o-sys |
|
Leverandør |
Person |
l-per |
|
Leverandør |
System |
l-sys |
|
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse |
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. |
x |
||
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 |
x |
||
7. Klargjør ny katalog med endret innhold |
l-per |
|
|
||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
1 |
Systemet kontrollerer om det riktige formatet er brukt |
Validatorfunksjon i system |
Unngå feil. |
6 |
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
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Varer og tjenester er tilgjengelig |
Ordreprosessen |
Bestiller |
|
16. Sluttkriterier
Gammel katalog må være fjernet for å unngå utgått sortiment.
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei | |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei | ||||
19: Behov for støtte
Støtte | Forklaring/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/postaward/g3/spec/
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 elektronisk 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
1. Informasjon
Prosess navn | EHF ordre prosess |
Prosess ID | X.4.2.2 Bestille varer og tjenester |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.06.16 | Dokument etablert | Jan 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
Trigger | Organisasjonens 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
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Behov | Organisasjon | ||
11. Deltakere
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Behovshaver | O-beh | |
Oppdragsgiver | Bestiller | O-bes | |
Oppdragsgiver | Godkjenner | O-god | |
Oppdragsgiver | System | O-sys | |
Oppdragsgiver | Person | O-per | |
Leverandør | Person | L-per | |
Leverandør | System | L-sys | |
12. Prosessdiagram

Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
Har du koblet din pc til ekstern skjerm og ikke hele diagrammet i Excel vises, kan problemet løses hvis du kobler fra den eksterne skjermen.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse |
KP (x) |
Kommentar |
1. Klargjør handelkurv, påfør konteringsinformasjon og send til godkjenning eller direkte til leverandør | O-bes | ||||
2. Godkjenn ordre | O-god | ||||
3. Send ordre | O-sys | ||||
4. Behandle ordre | L-sys / L-per | ||||
5. Generer en bekreftelse med status avslått | L-sys | ||||
6. Generer en bekreftelse med status delvis bekreftet | L-sys | ||||
7. Generer en bekreftelse med status bekreftet | L-sys | ||||
8. Motta og kontrollere bekreftelse mot ordre | O-sys | ||||
9. Slett ordre i bestillingssystem | O-sys | ||||
10. Oppdater ordre i bestillingssystem | O-sys | ||||
11. Vurder om endringer av ordre kan aksepteres | O-bes | ||||
12. Ta kontakt med leverandør | O-bes | ||||
13. Motta tilbakemelding fra oppdragsgiver. Enten slett ordre eller endre ordrebekreftelse og send på nytt | L-per | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
8 | Kontrollere at det ikke er avvik fra ordre/bestilling | System 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
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Ordre oppdagert i system | Fakturaprosess | Oppdragsgiver | |
Varer og tjenester | Varemottaksprosessen hos oppdragsgiver | Oppdragsgiver | |
Grunnlag for å allokere varer eller tjenester. | Transport/leveranseprosess | Leverandør | |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Aktivitet 1 oppdager at det ikke finnes varer/tjenester i bestillingssystem | Må kontakte leverandør manuelt. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Ikke korrekt definert leveransested for varen/tjenesten | Lav | Lav | Legge inn og vedlikeholde korrekte leveranseadresser i bestillingssystem. | Rette feil i system. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring | |
Hvis behovshaver har et behov som er spesielt må bestiller klarlegge hva behovet egentlig er | Kan være behov for opplæring og dialog med faginnstanser i virksomheten |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/postaward/g3/spec/
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
1. Informasjon
Prosess navn | EHF avansert ordre prosess |
Prosess ID | X.4.2.2 Bestille varer og tjenester |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.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
Trigger | Prosessen starter når et behov oppstår (trigger). Bestiller får beskjed fra en i organisasjonen om at de trenger noe |
Andre forutsetninger |
|
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Funnet varer og tjenester fra katlog eller punch-out via sin søkemotor |
Katalogprosessen, puch-out prosessen. |
Internt |
|
11. Deltakere
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Behovshaver | o-beh | |
Oppdragsgiver | Bestiller | o-bes | |
Oppdragsgiver | Goskjenner | o-god | |
Oppdragsgiver | Avtaleforvalter | o-avf | |
Leverandør | l | ||
Leverandør | Person | l-per | |
Leverandør | System | l-sys | |
12. Prosessdiagram

Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse |
KP (x) |
Kommentar |
1. Kontere og godkjenne bestilling. |
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. Behandle innkommende ordre og sjekk tilgjengelighet og tilrettelegg for en bekreftelse |
l-sys |
Systemspesifikk |
|
||
4. Lag en ordrebekreftelse basert på tilgjengelige varer og tjenester. |
l-sys |
Systemspesifikk |
|
||
5.Send negativ bekreftelse |
l-sys |
Systemspesifikk |
|
||
6. Send en bekreftelse uten endring. |
l-sys |
Systemspesifikk |
|
||
7. Send ordrebekreftelse med endring. |
l-sys |
Systemspesifikk |
|
||
8. Motta ordrebekreftelse |
o-bes |
|
X |
||
9. Prosesser ordrebekreftelse og sammenlign med sendt ordre. |
o-sys |
Systemspesifikk |
X |
||
10. Lagre ordrebekreftelse |
o-sys |
Systemspesifikk |
|
||
11. Oppdatere ordre med endring |
o-sys |
Systemspesifikk |
|
||
12. Lagre ordrebekreftelse |
o-sys |
Systemspesifikk |
|
||
13. Evaluer endring mot opprinnelig ordre |
o-bes |
|
|
||
14. Forbered kanselering av ordre |
o-sys |
Systemspesifikk |
|
||
15. Send ordreavslag |
o-sys |
Systemspesifikk |
|
||
16. Fjerne ordre fra system. |
l-sys |
Systemspesifikk |
|
||
17. Forbered endringsordre |
o-sys |
Systemspesifikk |
|
||
18. Send endringsordre |
o-sys |
Systemspesifikk |
|
||
19. Evaluer oppdragsgivers forslag for endring av ordre |
l-per |
|
|
||
20. Send en positiv ordrebekreftelse |
l-sys |
Systemspesifikk |
|
||
21. Send en negativ ordrebekreftelse |
l-sys |
Systemspesifikk |
|
||
22. Slett ordre i system. |
o-sys |
Systemspesifikk |
|
||
23. Lagre ordrebekreftelse |
o-sys |
Systemspesifikk |
|
||
24. Oppdater ordre med endringene |
o-sys |
Systemspesifikk |
|
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor 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
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
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
Hvor | Unntak - betingelser og endring |
Aktivitet 1 Hvis bestiller ikke finner varen eller tjenesten i søkemotoren. |
Da må man på manuell behandling. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Får ikke svar fra leverandør |
Lav |
Kan være kritisk |
Manuell kontroll |
Ringer, sender mail, etc. |
19: Behov for støtte
Støtte | Forklaring/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/postaward/g3/spec/
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
1. Informasjon
Prosess navn | EHF ordreforslag prosess |
Prosess ID | X.4.2.2 Bestille varer og tjenester |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.05.11 | Dokument etablert | Jan 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
Trigger | Et behov som må løses, for eksempel behov for flyreise, rask reparasjon av vannlekkasje. |
Andre forutsetninger |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
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
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Behovshaver | o-beh | |
Oppdragsgiver | Bestiller | o-bes | |
Oppdragsgiver | Goskjenner | o-god | |
Oppdragsgiver | Avtaleforvalter | o-avf | |
Oppdraggiver | System | o-sys | |
Leverandør | l | ||
Leverandør | Person | l-per | |
Leverandør | System | l-sys |
12. Prosessdiagram

Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse |
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åles | Hvordan det skal gjøres | Hvorfor 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
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
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
Hvor | Unntak - betingelser og endring |
---|---|
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Nei. |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/postaward/g3/spec/
21. Tilleggsinformasjon
Nei.
22. Vedlegg
Nei.
EHF punch-out prosessen
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | EHF punchout prosess |
Prosess ID | X.4.2.2 Bestille varer og tjenester |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.06.02 | Dokument opprettet | Jan 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
Trigger | Behov 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
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Behov | Oppdragsgiver | ||
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Behovshaver | o-beh | |
Oppdragsgiver | Bestiller | o-bes | |
Oppdragsgiver | System | o-sys | |
Leverandør | System | l-sys | |
12. Prosessdiagram

Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse |
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 handleprosess | o-bes | ||||
4. Forbered forsendelse av varer til oppdragsgivers bestillingssystem. Lagre bestilling i systeme | l-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 oppdragsgiver | o-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åles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei | |||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
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
Hvor | Unntak - betingelser og endring |
Nei | |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei | ||||
19: Behov for støtte
Støtte | Forklaring/Lenker |
Opplæring i bruk av leverandørers systemer. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/postaward/g3/spec/
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
1. Informasjon
Prosess navn | EHF vare og tjenestemottak prosess |
Prosess ID | X.4.2.3 Levere vare og tjenester X.4.2.4 Motta varer og tjenster |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.05.28 | Dokument etablert | Jan 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
Trigger | Bestilling 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
Input | Avleverende prosess: Navn på prosess + ID | Leverandør/avsender - organisasjon | Referanse |
Bestilling | Oppdragsgiver | ||
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Bestiller | o-bes | |
Oppdragsgiver | Varemottaker | o-var | |
Leverandør | |||
12. Prosessdiagram

Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse |
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 sjekk utført oppdrag |
|
>Motta varer eller sjekk utført oppdrag >Registrer i system. |
x |
||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
6 |
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
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Mottatte varer og tjenester registert i system. |
System |
Oppdragsgiver |
|
16. Sluttkriterier
Korrekt leveranser er registrert i systemet.
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Ingen |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Hvis varemottaker ikke vet om det er farlig gods i leveransen kan det være fare for liv og helse. | Liten | Høy | Følge anvisninger som EHFpakkseddel gir for risikoprodukter. | Leverandør må merke risikoprodukter. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Ingen ut over systemstøtte |
|
Opplæring i utførelse av prosess. |
|
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/postaward/g3/spec/
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:
- Se Referansekatalogen for hvilke lovkrav som gjelder
Fordeler ved å ta i bruk formatet
For oppdragsgivere
- En EHF Faktura 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
1. Informasjon
Prosess navn | EHF faktura og kreditnota prosess |
Prosess ID | X.4.2.6 Sende og motta betalingskrav |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.06.02 | Dokument opprettet | Jan 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
Trigger | EHF ordre, abonnement eller annen form for bestilling (for utenlandske leverandører PEPPOL BIS) |
Andre forutsetninger | Nei |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Ordre | Ordreprosessen (definert) | Oppdragsgiver/bestiller | |
Abonnement | Fakturaprosess til leverandør | Leverandør |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | System | l-sys | |
Oppdragsgiver | Bestiller | o-bes | |
Leverandør | System | l-sys | |
Leverandør | Person | l-per |
12. Prosessdiagram

Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse |
KP (x) |
Kommentar |
1. Generere faktura basert på bestilling fra oppdragsgiver for leveranse av varer/tjenester | l-sys | ||||
2 Send faktura | l-sys | ||||
3 Motta faktura | o-sys | ||||
4. Sjekk faktura mot bestilling | o-sys | x | |||
5. Sjekk avvik. Sjekk om utbetaling har funnet sted | o-bes | x | |||
6. Kontakt leverandør å be om kreditering av hele fakturaen og be de sende en ny faktura med korrekt beløp | o-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øp | l-per | x | |||
9. Generer kreditnota med referanse til utsendt faktura | l-sys | ||||
10. Send kreditnota | l-sys | ||||
11. Motta kreditnota | o-sys | ||||
12. Oppdater eller utligne faktura mot kreditnota i regnskapssystemet | o-sys | ||||
13. Klargjør utbetaling til leverandør | o-sys | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
4 | Maskinell kontroll av informasjon i faktura opp mot ordre | System | For å redusere risiko for feilutbetaling |
5 | Sjekk avvik. Sjekk om utbetaling har funnet sted | Manuelt | For å redusere risiko for feilutbetaling |
8 | Behandle forespørselen og klargjør for kreditnota og/eller utbetaling av beløp | Manuelt/System | For å redusere risiko for feilutbetaling |
Ved oppsett av abonnements mottak sjekke at referansenummer er korrekt opp mot gjeldende beløpsgrense | System | For å effektivisere fakturaprosessen | |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Grunnlag for utbetaling | Payment prosess/utbetalingsprosess | Regnskapssystem hos oppdragsgiver | |
16. Sluttkriterier
Kvitteringsmelding fra paymentsystem
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei | |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Feilutbetaling | Lav | Høy | Elektronisk match av ordre eller abonnements ordning | Sikre at alle fakturaer har et bestillings/abonnements nummer. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Systemopplæring for oppdragsgivere og leverandør. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/postaward/g3/spec/
21. Tilleggsinformasjon
Referansekatalogen for IT-standarder
Forskrift om elektronisk faktura i offentlige anskaffelser
22. Vedlegg
Nei
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.
I 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
1. Informasjon
Prosess navn | EHF purring prosess |
Prosess ID | X.4.2.8 Sende og motta purring |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.05.29 | Opprette dokument | Jan 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
Trigger | Ikke mottatt betaling før fallsdatoen på en faktura i leverandørs system trigger purreprosessen (forfallsdato + 14 dager). |
Andre forutsetninger | Leverandø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
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Melding om ikke innebetalt faktura | Systemspesifikk (ID er normalt det opprinnelige faktuanummert + forfallsdatoen) | Leverandør | |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | System | o-sys | |
Oppdragsgiver | Person | o-per | |
Leverandør | System | l-sys | |
12. Prosessdiagram

Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse |
KP (x) |
Kommentar |
1. Fakturasystem generer en EHF purring | l-sys | Systemspesifikk | |||
2. Send purring på utsendt faktura | l-sys | Systemspesifikk | |||
3. Undersøk årsak til at utbetaling ikke har funnet sted | o-per | Delprosessen 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 betalingsmottaker | o-sys | Systemspesifikk | |||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei | |||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Utbetaling til leverandør | Payment prosess | Leverandø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
Hvor | Unntak - betingelser og endring |
Nei | |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei | ||||
19: Behov for støtte
Støtte | Forklaring/Lenker |
Nei | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/postaward/g3/spec/
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
X.5 Prosedyrer / teknikker
X.5.1 Dynamisk innkjøpsordning ved bruk av 4-hjørners modell (DPS)
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | Dynamisk innkjøpsordning (DPS) |
Prosess ID |
X.5.1 Dynamisk innkjøpsordning (DPS) https://www.anskaffelser.no/verktoy/veiledere/ehf-prosessoversikt |
Organisasjon | DFØ-ANS |
Prosess eier | Wenche Ludviksen |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
0.99 | 2021.01.05 | Dokument etablert | Petter Vinje |
1.0 | 2021.02.11 | Publisert | Jan Mærøe |
3. Definisjoner/forkortelser
DPS = Dynamic Purchasing System/Dynamisk innkjøpsordning.
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.
FOA= Forskrift om offentlige anskaffelser (anskaffelsesforskriften).
X.2.2.7= Prosessene ID nummer. Her finner du mer informasjon om vår tilnærming til prosessarbeid og bruk av ID nummer.
4. Om prosessen
DPS er en fullt ut elektronisk anskaffelsesprosess med to trinn: Trinn 1 er etablering av ordningen ved kvalifisering av leverandører. Trinn 2 er anskaffelsene i ordningen.
Prosessdigrammet beskriver en «to-be» prosess hvor oppdragsgiver og leverandør kommuniserer med hverandre via hvert sitt system, basert på full ut maskinlesbare dokumenter. Eksisterende 3-hjørners model er beskrevet som et unntak på vei mot en «fullt ut elektronisk prosess» (jfr. FOA § 26-4 (3)).
5. Brukere og bruksområde
Oppdragsgivere: Kan benytte denne ved repetitive kjøp av standardiserte varer og/eller tjenester hvor det ikke er behov for dialog med tilbyder før kjøp. Eksempel på varer og tjenester: Møbler. IT/AV utstyr. Enkle konsulent- vaktmester- og/eller renholdstjenester, etc.
6. Formål
Oppnå en bedre og mer effektiv prosess ved å ta i bruk teknologi som i større grad gjør det mulig å rette anskaffelsen mot det konkrete behovet, enn ved for eksempel rammeavtaler. Samt gjennomføre prosessen på kortere tid med mindre bruk av ressurser.
7. Mål
- Tilpasse hver konkurranse til behovet på en bedre måte enn rammeavtaler hvor man bindes når avtalen inngås.
- Utnytte konkurransemekanismen i markedet både ved at flere SMB får mulighet til å gi tilbud, og at oppdragsgiver får flere tilbud.
- Frigjøre ressursbruk til andre og viktigere oppgaver/ev. redusere bruk av ressurser gjennom automatisering.
- Økt fleksibilitet. Ordningens varighet kan endres ved behov, eller avsluttes dersom det ikke er behov for dem lenger (Ved inngåelse av rammeavtaler er du forpliktet i en avtalt periode, maks 4 år, som ikke kan endres).
8. Måltall/KPIer
KPI | Kommentar |
9. Gevinster
For oppdragsgiver: Bedre behovsdekning fordi hver konkurranse kan tilpasses behovet. Større antall tilbud – bedre utnyttelse av konkurransekraft i markedet. Tar ikke like lang tid å gjennomføre som en rammeavtale. Får tilgang til markedsutvikling og innovasjon, noe du ikke gjør i en rammeavtale. Mer effektive prosesser.
- Bruk av digitale verktøy for standardiserte og maskinlesbare maler for krav og kriterier, som muliggjør automatiserte evalueringer, sparer tid og ressurser.
- Standard kontraktsmaler sparer tid og ressurser.
For leverandør: Få tilgang til det offentlige markedet – økt omsetning, spesielt SMB. Kunne digitalisere sine egne interne prosesser i tilbudsinnlevering – enklere, raskere, bedre og mer motiverende å levere tilbud til det offentlige.
Mer effektive prosesser.
- Bruk av digitale verktøy for standardiserte og maskinlesbare tilbudsforespørsler som muliggjør automatiserte evalueringer, gjør at leverandør på forhånd kan se om og i hvilken grad krav og kriterier er oppfylt. Unngå å bruke tid og ressurser på å levere tilbud som ikke når opp i konkurransen. Dette gir mulighet til å forbedre tilbudet før det sendes inn.
- Standard kontrakter sparer tid og ressurser for leverandør. Slipper å sette seg inn i ny kontrakter, formuleringer, etc. hver gang.
10. Startkriterier/forutsetninger
Trigger |
Beslutning om DPS (Som regel innkjøpsgruppen som tar beslutning. Beslutning som regel dokumentert i møtereferat.) |
Andre forutsetninger |
Ledelse: Forutsetter at prosess X227 velge prosedyre, og/eller X228 beslutte kontraktsstrategi, er gjennomført med beslutning om å gjennomføre en DPS hvor det minimum er tatt stilling til:
At det er nok aktører i markedet, potensielle tilbydere, til at DPS skal fungere formålstjenlig. |
Andre forutsetninger | Organisatoriske: Krever endring i måten man tenker anskaffelser: Fra bruk av rammeavtaler, til bruk av DPS og en ny forståelse for hva, hvorfor, hvordan, hvem, etc. Kan i noen tifeller kreve ny strategi og ev. omorganisering. Det er helt nødvendig å kartlegge behov for organisatoriske endringer. |
Andre forutsetninger | Prosessuelle: Rekkefølge på aktiviteter – hva som gjøres når avviker fra tradisjonell rammeavtraleinngåelse. DPS forutsetter at man setter seg inn i og implementerer ny prosess. Gjør man ikke det, er det risiko for at man ikke oppnår gevinster. |
Andre forutsetninger | Personlige: De som skal utføre DPS må få den opplæring og støtte som kreves for at de skal forstå, kunne, ville og ha mulighet til å utføre prosessen slik det forventes. |
Andre forutsetninger | Teknologiske: Forutsetter at både oppdragsgiver og leverandør må ha systemer/verktøy som støtter prosessen. |
Andre forutsetninger |
Juridiske: Den forenklede heldigitale kontraktssigneringsprosessen beskrevet i prosess nr. 3 Gjennomføre konkurranse, aktivitet nr. 12,15 og 17 forutsetter at følgende tekst inkluderes i anskaffelsesdokumentene: Leverandøren er bundet av sitt tilbud frem til vedståelsesfristen. Signering av kontrakt anses å ha skjedd når oppdragsgiver har meddelt den vinnende leverandøren om at dennes tilbud er valgt, og partene har signert kontrakten elektronisk. Elektronisk signering av kontrakt vil foregå på følgende måte:
|
11. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
All dokumentasjon som er utbarbeidet i forbindelse med kontraktstrategien. | X.2.2.7 Velge prosedyre og/eller X.2.2.8 Beslutte kontraktsstrategi. | Oppdragsgiver | |
12. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Oppdragsgiver | Person | O-per | O-per benyttes når man ønsker å angi at denne aktiviteten utføres av en person hos oppdragsgiver, uten behov for å angi rolle |
Oppdragsgiver | Behovshaver | O-beh | O-beh benyttes når man ønsker å angei at denne aktiviteten utføres av en behovshaver. |
Oppdragsgiver | System | O-sys | O-sys benyttes når man ønsker å angi at aktiviteten utføres av oppdragsgivers system. |
Oppdragsgiver | Budsjetteier/avtaleier. | O-bud | Den som har budsjettmyndighet. O-bud benyttes når det er behov for å angi at denne aktivitetene utføres av budsjett/avtaleier hos oppdragsgiver. |
Oppdragsgiver | Innkjøper | O-inn | Person som leder innkjøpsprosessen. |
Oppdragsgiver | Kontraktsforvalter | O-kon | Den som følger opp kontrakten mot leverandør og brukere etter kontraktsinngåelse. I dette tilfellet den som administrerer det enkelte kjøpet. |
Oppdragsgiver | Fagansvarlig | O-fag | Fagperson som har spisskompetanse sitt fagområde. |
Oppdragsgiver | Bestiller | O-bes | Den som gjennomfører bestillinger på løpende avtaler med en eller flere leverandører. |
Oppdragsgiver | Mottaker | O-mot | Mottaker av varen eller tjenesten |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Leverandør | Person | L-per | Angir at aktivitet utføres av en person i leverandørorganisasjon |
Leverandør | System | L-sys | Angir at aktivitet utføres av et system i leverandørs organisasjon. |
Innkjøpssentral kunde | IK | Virksomheter tilsluttet en innkjøpssentral for én spesifikk DPS. | |
Innkjøpssentral kunde | Person | IK-per | Angir at aktivitet utføres av en person. |
Innkjøpssentral kunde | System | IK-sys | Angir at aktivitet utføres av et system. |
Systemleverandør | SL | SL 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 som utfører aktiviteten hos systemleverandør. | |
Publiseringstjeneste | Pub | Pub benyttes når det er behov for å angi at aktiviteten utføres av en publiseringstjeneste, for eksempel Doffin. Her kan man også bytte ut Publiseringstjeneste med organisasjonens navn, for eksempel Doffin. | |
Ev andre | Ev. andre | Man kan også legge til roller dersom det er hensiktsmessig. |
13. Prosessdiagram

Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
Har du koblet din pc til ekstern skjerm og ikke hele diagrammet i
Excel vises, kan problemet løses hvis du kobler fra den eksterne
skjermen.
14. Aktiviteter
D=del-prosess, O=oppgave. Betegnelser som for eksempel X251 referer til prosess ID og beskrivelse av prosessen som du finner i prosessoversikten på https://www.anskaffelser.no/verktoy/veiledere/ehf-prosessoversikt
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
Etablere DPS prosess | https://lovdata.no/forskrift/2016-08-12-974/§26-5 | ||||
1. Planlegg DPS – delprosess – D. | O-per |
>Utarbeide konkurransegrunnlag - D >Vurder kategorisering (lots) - D >Estimer verdi på anskaffelser i hele ordningens varighet - D >X251 Velge kvalifikasjonskrav og -nivå basert på risiko - D >X252 Velge tildelingskriterier som kan benyttes i tilbudsinvitasjoner under ordningen - D >X253 Velge kontrakt/kontraktskrav som kan benyttes under ordningen - D >Fyll ut kunngjøringsskjema i KGV - O >Fyll ut ESPD-skjema i KGV - O >Publiser kunngjøring i KGV – som sender til Doffin/TED - O |
|||
2. Forbered og sende kunngjøring – delprosess – D | Lenke til kunngjøringsprosessen | ||||
3. Finn kunngjøring på Doffin. Er den av interesse klikk på lenken i utlysningen - O. | L-per | Oppgave | |||
4. Les igjennom informasjon i anskaffelses-dokumentene og vurder og beslutter deltakelse - O. | L-per | Oppgave | |||
5. Prosesser mottaksbekreftelse og anskaffelses-dokumenter – D. | O-Per |
>Ta i mot forespørsel om å bli registrert som interessent i konkurransen og lagre bland annet elektronisk adresseidentifikator (ELMA adresse) – O-sys >Forberede sending av anskaffelsesdokumentene, både maskinlesbare (EHF) og ustrukturerte filer som PDF, Word, Excel osv.- O-sys >Send alle anskaffelsesdokumenter. O-sys |
|||
6. Analyser anskaffelsesdokumentene – O. | L-per | ||||
7. Forbered spørsmål til oppdragsgiver – O. | L-per | Lenke til spørsmål og svar prosess | |||
8. Vurder spørsmål. Lag svar og send alle tilbydere – D. | O |
>Oppdragsgiver legger ved spørsmål og ev. anonymiserer disse. >Sender spørsmål med svar til alle. |
Lenke til spørsmål og svar prosess | ||
9. Eventuelt korriger besvarelse – O. | L-per | ||||
10. Prosesser ESPD respons eventuelt andre dokumenter. | L-sys | Systemspesifikk | Søknad om opptak i DPS ordningen. https://lovdata.no/forskrift/2016-08-12-974/§26-6 | ||
11. Basert på ESPD forbered bevisinnhenting. Prosesser kvitteringsmelding. |
O-sys | Systemspesifikk | |||
12. Lag bevisinnhentings-melding og hent bevis. | O-sys | Systemspesifikk | Lenke til eBevis prosessen | ||
13. Evaluer bevis. | O-sys | Systemspesifikk | Oppdragsgiver kan på et hvilket som helst tidspunkt i ordningens varighet innhente bevis, eller be leverandører levere oppdaterte bevis. For å sikre at de fremdeles oppfyller kvalifikasjonskravene. Det anbefales at oppdragsgiver etablerer rutine for periodisk kontroll av bevis. | ||
14. Opprett leverandør i database. | O-sys | Systemspesifikk | |||
15. Forbered og send positiv respons. | O-sys | Systemspesifikk | |||
16. Forbered spørsmål til oppdragsgiver hvis uklarheter – O. | L-per | Forutsetter at du ikke forstår grunnen til at du ble avvist på kvalifikasjonskravene. Lenke til spørsmål og svar prosess |
|||
17. (hvis 15) Vurder spørsmål. Svar leverandør – O. | O-per | Svar går kun til den leverandør som har spurt. Lenke til spørsmål og svar prosess |
|||
18. Oppdater bevis i database basert på svar fra oppdragsgiver – O. | L-per | Hvis avvist på kvalifikasjonssvar. | |||
Oppdragsgiver/Innkjøpssentral informerer | |||||
1. Lage/tilpass maler/veiledning for bruk i DPS. (EHF forespørselskatalog, EHF kontrakt, Regler for konkurranse..) Oppdatert liste over deltakere i DPS generert |
O | ||||
2. Motta maler og klargjør kvittering. | IK-sys | Systemspesifikk | |||
3. Forbered og send spørsmål til innkjøpssentral/adm. av DPS– O. | IK-per | ||||
4. Vurder spørsmål. Lag svar og send til virksomhet -O. | O-per | Ev. anonymisere og sende til alle hvis informasjonen er relevant for alle kunder. Lenke til spørsmål og svar prosess |
|||
Gjennomføre konkurranse | Lenke til spørsmål og svar prosess | ||||
1. Definer behovet – D. | O | Kravbank: Sjekk om det finnes en mal. Hvis ikke lag en ny mal med krav og evaluering. Last ned PDF | |||
2. Gjennomgå mottatt tilbudsinvitasjon – D. | L | Hvis mottatt kravbank PDF sjekk krav i kravbank og eventuelt evaluer mot krav. | |||
3. Vurder spørsmål. Lag svar til leverandør – D. | O | Lenke til spørsmål og svar prosess | |||
4. Juster tilbud i henhold til svar på spørsmål – O. | L-per | ||||
5. Generer EHF Tilbudskatalog basert på generisk informasjon fra EHF Forespørselskatalog eventuelt andre dokumenter – D. | L-sys /L-per | Systemspesifikk |
Hvis alle dokumenter er i maskinlesbart format. Er dette en systemspesifikk oppgave. Hvis ikke, må en person utføre hele eller deler av prosessen. Kravbank: Leverandør laster opp filen og legger inn sitt tilbud. Laster ned en kravbank PDF og inkluderer denne i tilbudet som sendes oppdragsgiver. |
||
6. Kontroll av tilbud før innsending – O. | L-per | ||||
7. Signere og kryptere tilbudet. | L-sys | Systemspesifikk | |||
8. Send kvittering. | Systemspesifikk | ||||
9. Evaluer de forskjellige tilbudte varer/tjenester. Velg beste tilbud – D. | O-sys /O-per |
>Evaluering kan foretas av systemet, |
Kan ved behov bruke «EHF spørsmål og svar» for avklaring og supplerende informasjon. Kravbank: Evaluer tilbyders svar |
||
10. Generer anskaffelsesprotokoll. | O-sys | Systemspesifikk | |||
11. Forbered informasjon til leverandører om hvilket tilbud som er valgt – O. | O-per | ||||
12. Kort begrunnelse for tildeling basert på evalueringskriterier - O | O-per | Ref. 9 Startkriterier/forutsetniger | |||
13. Kort begrunnelse for ikke tildeling basert på evalueringskriterier – D. | O-per | ||||
14. Klargjør kvittering. | L-sys | Systemspesifikk | |||
15. Generer et svar ved at leverandør åpner tildelingsmeldingen-O. | L-per |
>Ref. 9 Startkriterier/forutsetniger. |
|||
16. Ferdigstill og signer protokoll - D | O-sys | Systemspesifikk | |||
17. Prosesser kunngjøring av kontraktsinngåelse. | O-sys | Systemspesifikk |
>Ref. 9 Startkriterier/forutsetniger. |
||
18. Publiser kunngjøring | Pub(D) | Systemspesifikk | |||
19. Klargjør EHF Tilbudskatalog. | O-sys | Systemspesifikk | Mrk. Her avsluttes DPS, tilbudskatalog er input til bestillingsprosess. | ||
20. Klargjør tilbudte varer/tjenester for manuell innleggelse i bestillingsløsning – O. |
O-per | ||||
Kunde melder seg inn/ut | |||||
1. Foreta en vurdering av forespørsel – O. | O-per | ||||
2. Fjern kunde fra DPS – O. | O-per | ||||
3. Legg til kunde i DPS – O. | O-per | Inkludere også å legge til kunde som mottaker av leverandørliste. | |||
4. Send leverandørliste og maler – O. | O-per | Systemspesifikk | |||
5. Klargjør og generer endringskunngjøring. | O-sys | Systemspesifikk |
Endringskunngjøring anbefales (ikke lovpålagt) for å varsle leverandørmarkedet om endringen. |
||
6. Publiser endring. | Pub | Systemspesifikk | |||
Leverandør melder seg ut | |||||
1. Klargjør utmelding – O. | L-per | ||||
2. Send mottaksbekreftelse. | O-sys | Systemspesifikk | |||
3. Fjern leverandør fra DPS database-O. | O-per | ||||
4. Klargjør for utsendelse av ny oppdatert leverandørliste til kunder – O. | O-per | ||||
Leverandør meldes ut | |||||
1. Fjern leverandør fra DPS database - O. | O-per | ||||
2. Send melding om tvungen utmelding med begrunnelse – O. | O-per | ||||
3. Klargjør for utsendelse av ny oppdatert leverandørliste til kunder – O. | O-per | ||||
4. Forbered kvitteringsmelding. | L-sys | Systemspesifikk | |||
Avslutte Ordning | https://lovdata.no/forskrift/2016-08-12-974/§26-5 | ||||
1. Fyll inn kunngjøringsskjema – O. | O-per | Lenke til kunngjøringsprosessen | |||
2. Send ut kunngjøringsskjema. | O-sys | Systemspesifikk | |||
3. Klargjør leverandørliste for utsendelse til kunder med 0 forekomst av leverandører – O. | O-per | ||||
4. Informer kunder og leverandører om avslutning av DPS ordningen – O. | O-per |
15. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Sikre at alle kvitteringsmeldinger mottatt | Gjøres i system | For å sikre melding er mottatt av mottaker. | |
16. Output og mottaker/bruker
Output | Mottakende prosess: | Mottaker/bruker | Referanse |
1. Etablere DPS: |
2 Oppdragsgiver/Innkjøpssentral informerer. NB! En leverandør kan søke om opptak i hele ordningens varighet, også etter at den er etablert. |
Bruker av DPS. | |
2. Oppdragsgiver/Innkjøpssentral
informerer: |
>3 Gjennomføre konkurranse | ||
3. Gjennomføre konkurranse: |
>X.4.2.2 Bestille varer og tjenester. |
||
4. Kunde melder seg inn i og ut av
ordningen: |
>3. Gjennomføre konkurranse |
>Leverandørmarkedet |
|
5. Leverandør melder seg ut: |
>3. Gjennomføre konkurranse |
>Oppdragsgiver |
|
6. Leverandør meldes ut av ordningen: |
>3. Gjennomføre konkurranse |
>Oppdragsgiver |
|
7 Avslutte DPS: |
>Når DPS avsluttes må behov vurderes på nytt. >Ref. prosess «X.2 avklare behov og forberede konkurranse». |
>Doffin/TED for informasjon til leverandører om avslutning av
DPS. |
17. Sluttkriterier
- Sluttkriterier ved gjennomføring av konkurranser er: Kontrakt klar til arkivering og avtalen klar til bruk (settes i bestilling eller oppfylle det som er avtalt).
- Sluttkriterier for selve ordningen er at den enten opphør når dato for ordningens varighet oppnås, eller at den ikke lenger dekker oppdragsgivers behov og avsluttes.
18. Unntak/spesielle hensyn
Hvor | Unntak/hensyn |
I hele DPS prosessen: |
Dagens situasjon er at man operer i en 3-hjørners modell. Det vil si at oppdragsgiver og leverandør samhandler i oppdragsgivers system. Prosessdiagrammet beskriver en digital prosess (4-hjørneres modell) hvor oppdragsgiver og leverandør sitter i hvert sitt system og utveksler maskinlesbare meldinger. I begge disse tilfellene er prosessen den sammen. Forskjellen er utveksling av standard maskinlesbare meldinger. |
19. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Risiko for at du ikke får tilbud | Lav | Middels-Høy | Sikre at man ikke stiller krav og kriterier som utelukker deler av markedet. | Hvis du ikke får tilbud kan du endre krav og kriterier og sende ny tilbudsinvitasjon. |
Risiko for at markedsaktører ikke ønsker eller kan melde seg inn i ordningen. | Lav-middels | Høy | Sikre at kvalifikasjonskravene ikke utelukker deler av markedet for å delta. | Avslutte ordningen, endre kvalifikasjonskrav og kunngjøre ny DPS. |
Dersom man ikke har en heldigital prosess er det en risiko for at man kan få så mange tilbud på hver forespørsel at arbeidsmengden også blir for stor. | Høy | Høy |
Ta i bruk heldigital prosessflyt mellom oppdragsgiver og leverandør basert på standardiserte maskinlesbare meldinger som gir mulighet en mest muilg automatisert evaluering. Ta i bruk standardiserte maler for tilbudsforespørsel og tilbudsinnlevering som sikrer at det er enkelt å sammenligne informasjon. |
Dersom dette inntreffer må man øke ressursbruk. Og hvis det er gjentagende vurdere å gjøre noe med malene eller om DPS er hensiktsmessig. |
20: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring. | For eksempel ta utgangspunkt i denne beskrivelsen. |
Få oversikt/opplæring i hva slags funksjonalitet som finnes i systemet og hvordan denne benyttes. | Overgang fra dokumenthåndtering (PDF,Word, Excel) til systembruk gjør det mulig å automatisere hele/deler av prosessen forutsatt at man forstår og kan bruke systemet. |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Nei
21. Tilleggsinformasjon
Spørsmål sendes til: ehf@dfo.no
22. Vedlegg
Ingen foreløpig.
X.6 Støtteprosesser
X.6.1 Digitale støtteprosesser
X.6.1.1 EHF Utvikle og forvalte standardformat
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | EHF utvikle og forvalte standard format |
Prosess ID | X.6.1.1 Utvikle og forvalte standard format |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.11.26 | Dokument etablert | Petter 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
Input | Avgivende prosess: | Leverandør av input | Referanse |
Beslutning m/prosjektgrunnlag | Ledelse | Prosjekteier | |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
DFØ ANS | Prosjekteier | PE | |
DFØ ANS | Prosjektleder | PL | |
DFØ ANS | Prosjektdeltakere | PD | |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL 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. andre | Man kan også legge til roller dersom det er hensiktsmessig. | |
12. Prosessdiagram
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
X.6.1.1.1 | Analysere behov og mulighet | PL | Lenke til delprosess | ||
X.6.1.1.2 | Utvikle teknisk veileder | PL | Lenke til delprosess | ||
X.6.1.1.3 | Forvalte standard formater | PL | Lenke til delprosess | ||
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
Ingen | Prosessen kontrolleres ved bruk av sjekklister og oppfølgningsmøter. | |||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
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, aktivitet | Unntak/hensyn |
X.6.1.1.1 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. |
X.6.1.1.2 Utvikle teknisk veileder | Aktivitet 7 og 8 er avhengig av prosjekt. Noen ganger er syntaks definert. Andre ganger må den lages. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Deltakerne benytter ikke/avviker fra prosessen. | Høy | Lav-høy | Kontrollere at prosessen benyttes. | Eskalere, varsle, informere om konsekvensene. |
19: Behov for støtte
Støtte | Forklaring/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 på anskaffelser.no.
21. Tilleggsinformasjon
Nei
22. Vedlegg
X.6.1.1.1 EHF Analysere behov og mulighet
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | EHF Analysere behov og mulighet |
Prosess ID | X.6.1.1.1 Analysere behov og mulighet |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.11.26 | Dokument etablert | Petter Vinje |
3. Om prosessen
Prosessen X.6.1.1.1 Analysere behov og mulighet er den første av de tre del-prosessene i X.6.1.1 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
Input | Avgivende prosess: | Leverandør av input | Referanse |
Beslutning m/prosjektgrunnlag | Ledelse | Prosjekteier | |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
DFØ ANS | Prosjekteier | PE | |
DFØ ANS | Prosjektleder | PL | |
DFØ ANS | Prosjektdeltakere | PD | |
DFØ ANS | Prosessansvarlig | PRA | |
DFØ ANS | Formatansvarlig | FA | |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL 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 andre | Man kan også legge til roller dersom det er hensiktsmessig. |
12. Prosessdiagram
Prosessdiagram i Excel:
Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
Starte prosjekt |
|
||||
1. Lage prosjektgrunnlag: | PE | Sjekkliste >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 mandat | PL | Mal | |||
3. Godkjenne mandat | PE | ||||
4. Lage forslag til prosjektplan | PL | Mal | |||
5. Godkjenne prosjektplan | PL | ||||
6. Planlegge og gjennomføre Kick-off | PL | >Excel oppgavearke | |||
7. Planlegge WS1 og fortsette arbeidet med utvikling av informasjonsmodell og fylle ut maler | PL | >Excel oppgaveark >Undersøke om muligheter for pilotering av standard format. |
|||
8. Ev. Gjennomføre kartlegging og intervju | PRA | >Lage AS-IS prosessmodell | >Excel oppgaveark mal >Presentasjons eksempel med spørsmål |
||
9. Beskrive nåsituasjon: AS-IS | PRA | >Kartlegge forventninger >Kartlegge AS-IS situasjon |
>Prosessrammeverk >BPMN 2.0 notasjon >Sjekkliste |
||
10. Gjennomføre WS1 AS-IS | PL | >Sjekkliste >Eksempler |
|||
11. Beskrive fremtidig situasjon for brukere og interessenter | PRA | >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 case | PL | >Informasjonsmodell >Prosessmodell >Use Case >Fylle ut maler |
>Maler >Eksempler |
||
13. Gjennomføre WS2 Fremtidig situasjon | PL | Dersom det ikke er behov for en WS2 bør det likevel holdes et avsluttnings-/informasjonsmøte. | |||
14. Lage analyserapport | PL | I 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 analyserapport | PE | ||||
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øres | Hvorfor det er nødvendig | |
Kontroll sikres ved bruk av sjekklister og oppfølgningsmøter. | ||||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Analyserapport | X5112 Utvikle teknisk veileder | DFØ ANS | |
16. Sluttkriterier
Rapport fra analysefasen må være godkjent før neste prosess kan påbegynnes
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/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
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Avviker fra prosessen | Høy | Lav-høy | Prosjektleder må kontrollere at prosessen følges. |
Prosessen tillater avvik i de tilfeller det er
hensiktsmessig. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for opplæring i utførelse av prosess. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Sluttresultatet, en EHF, publiseres her: https://anskaffelser.no/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
Spørsmål send til EHF@DFO.NO
X6.1.1.2 EHF Utvikle teknisk veileder
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | EHF Utvikle teknisk veileder |
Prosess ID | X.6.1.1.2 Utvikle teknisk veileder |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.12.02 | Dokument etablert | Petter 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 |
|
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Beslutning m/prosjektgrunnlag | Ledelse | Prosjekteier | |
Analyserapport | X5111 EHF Analyse av behov og mulighet | Prosjektleder | |
Use case | X5111 EHF Analyse av behov og mulighet | Prosjektleder | |
Rolle og prosessdiagram | X5111 EHF Analyse av behov og mulighet | Prosjektleder | |
Spesifikasjoner | X5111 EHF Analyse av behov og mulighet | Prosjektleder | |
Forretningsregler | X5111 EHF Analyse av behov og mulighet | Prosjektleder | |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
DFØ ANS | Prosjekteier | PE | |
DFØ ANS | Prosjektleder | PL | |
DFØ ANS | Prosjektdeltakere | PD | |
DFØ ANS | Prosessansvarlig | PRA | |
DFØ ANS | Formatansvarlig | FA | |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL 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
Prosessdiagram i Excel:
Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Før | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
A | 1. Gjennomgå eksisterende standarder | >CEN >PEPPOL |
||||
A | 2. Definere forretningsregler | >Bruk kravmalen som er fylt ut i analysefasen | ||||
2 | 3. Definere datamodell | >Bruk meldingsdokumentet og kravsdokumentet fylt ut i analysefasen | ||||
A | 4. Velge eller opprette repo på Github | >GitHub | ||||
1 | 5.Benytte eksisterende kodelister eller lage nye kodelister | >ISO stanadarder >Se Post-Award kodeliser >Se Pre-Award kodelister |
||||
1,5 | 6. 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,6 | 7. Lage syntaksbinding mot eksisterende syntaks | >UBL >XML >Riktig namespace >Elementer og attributter >Kodeliste >Regler |
||||
1,2,3,4,5,6 | 8. Lage syntaks og syntaksbinding for ikke eksisterende syntaks | >AnsBL >XML >Riktig namespace >Elementer og attributter >Kodeliste >Regler |
||||
2,7,8 | 9. Lage og teste regler Schematron | >Forretningsregler >Bruke kravmalen, blir fylt ut i analysefasen. >Teksteditor |
||||
5,7,8,9 | 10. Lage eksempelfil | >Syntaksbindingen >Teksteditor (Atom, …) |
||||
5,7,8,9,10 | 11. Lage snippets | >Asciidoc - som referanse >Syntaksbindingen - som tagger |
||||
A | 12. Lage spesifikasjon | |||||
12 | 13. Skrive introduksjon og bakgrunn for formatet | >Asciidoc >Bruke prosjektbeskrivelsesmalen, blir fylt ut i analysefasen |
||||
5,7,8,9,10,11,13 | 14. Beskrive de viktige aspektene ved formatet (ferdig spesifikasjon) | >Asciidoc >Syntaksbindingen/meldingsmalen fra analysefasen |
||||
A | 15. Lage usecase | >Asciidoc >Bruk use case malen, blir fylt ut i analysefasen |
||||
A | 16. Lage rolle og prosessdiagram | >BPMN 2.0 >UML |
||||
5,7,8,9,10 | 17. Lage change log og releasenote | >Asciidoc: Skriv endringer som har blitt gjort | ||||
5,7,8,9 | 18. Etablere validatorstøtte | >Schematron filer | ||||
18 | 19. 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 |
||||
19 | 20. Sende ut på review | >anskaffelser.dev | ||||
20 | 21. Gjennomgang av høringssvar | >SuperOffice (ehf@dfo.no) >GitHub (Issue) |
||||
21 | 22. Implementering av høringssvar | >Oppdatere formatet >Teste endringene |
||||
22 | 23. Sende format ut på offisielt review | >anskaffelser.dev | ||||
23 | 24. Gjennomgang av høringssvar | >SuperOffice (ehf@dfo.no) >GitHub (Issue) |
||||
24 | 25. Implementering av høringssvar | >Oppdatere formatet >Teste endringene |
||||
25 | 26. Lage erfaringsnotat | >Dokumentere prosess | ||||
8,9 | 27. Lage identifikatorer | >Etter retningslinjer fra Peppol | ||||
27 | 28. 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øres | Hvorfor det er nødvendig | |
Ingen |
Prosessen kontrolleres ved hjelp av sjekklister, oppfølgingsmøter, validator. | |||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Teknisk veileder (EHF) | Brukernes prosesser | Oppdragsgiver Leverdører Systemleverandører |
|
Gyldig Syntaks (dokumentinstans) | Brukernes prosesser | Oppdragsgiver 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, aktivitet | Unntak/hensyn |
Aktivitet 7 og 8 | Avhengig av prosjektet. Noen ganger definert syntaks, andre ganger må vi lage. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Avviker fra prosessen | Lav | Lav-høy | Prosjektleder 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øtte | Forklaring/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.no/
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
X.6.1.1.3 EHF Forvalte standard format
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
Prosess navn | EHF Forvalte standard format |
Prosess ID | X5113 Forvalte standard format |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.12.03 | Dokument etablert | Petter Vinje |
1.1 | 2021.03.22 | Lagt til to bekreftelser på aktivitet 13 og 16 | Petter 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.
- Samfunne 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 |
|
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Endringsønske | Peppol BIS, formel kanal | ||
Endringsønske | GitHub | ||
Endringsønske | EHF@DFO.no | ||
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
DFØ ANS ATS | EHF team | EHF-T | |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver | |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL 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
EHF forvalte standard formater prosessdiagram:
Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Før | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
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 se "Release management" | ||||
1 | 2. Vurder endringsomfanget | Om det er bug,minor eller major | ||||
2 | 3. BUG: Analyser hva som må gjøres. Iverksette tiltak | |||||
3 | 4. BUG:Dokumenter endring | For bruk i release note og dokumenter endring i change log | ||||
4 | 5. BUG: QA (Kvalitetssikring) |
|||||
5 | 6. BUG: Oppdater i eksisterende EHF veileder(e) | |||||
6 | 7. BUG: Sette i produksjon | Etter denne aktiviteten er retting utført i veileder og endring publisert | ||||
2 | 8. M/M:Analyser og planlegg det som må utvikles | |||||
8 | 9. Utvikling av endring | (Syntaks, kodelister, schematronregler) | ||||
9 | 10. Oppdatere EHF veileder(e) | |||||
10 | 11. QA (Kvalitetssikring) |
|||||
11 | 12. Etablere release note og change log | |||||
12 | 13. Send ut melding til alle systemleverandører og brukere. | Om den forestående endringen med informasjon om høringens startdato og sluttdato. Varsler hvilken dato ny versjon trer i kraft |
Varsling kontraktsoppfølgingsfasen |
|||
13 | 14. Korriger endring hvis det er feil. Hvis ikke send melding om at vi er uenig i kommentaren | Hvis det kommer kommentarer på endring. | ||||
14 | 15. Publiser ny versjon | |||||
15 | 16. Varsle alle systemleverandører og deres brukere. | |||||
16 | 17.Gi melding til Digitalisereringsdiretoratet | Om å slette mulighet for nyregistrering av gammelt format i ELMA og slettingsdato av gammel versjon | Tidsfrister se release management. https://anskaffelser.no/postaward/g3/docs/release-management/ | |||
17 | 18. Fjerne mulighet for nyregistrering av gammel versjon i ELMA | Tidsfrister se release management. https://anskaffelser.no/postaward/g3/docs/release-management/ | ||||
18 | 19. Fjerne gammel versjon fjernet fra ELMA | |||||
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
Ingen | Prosess kontrolleres ved bruk av sjekklister. | |||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Pilot candidate | Mottaker/brukers egne prosesser | Systemleverandør | Benyttes når markedet/prosessen er umodent, fordel med pilot. |
Release candidate (RC) 1,2,.. | Mottaker/brukers egne prosesser | Systemleverandør | Benyttes når markedet/prosessen er umodent. |
Oppdatert versjon | Mottaker/brukers egne prosesser | Systemleverandør | |
16. Sluttkriterier
- Når høringen er gjennomført og høringssvarene implementert. Publisere ny versjon.
- Når mulighet for registrering av gammel versjon er fjernet i ELMA (SMP).
- Gammel versjon er fjernet fra ELMA (SMP).
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
Dersom markedet ikke har implementert ny versjon | Må gammel versjon leve inntil antall transaksjoner av ny versjon har nådd kritisk masse. Fastsettes av leder. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Avviker fra prosessen | Lav | Medium-Høy | Markedet gir tilbakemelding om ev. avvik | Gå tilbake til relevant prosessteg. |
Endring medfører så høy kostnader at systemleverandører ikke implementerer. | Lav | Høy | Markedet gir tilbakemelding | |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring. | |
Behov for teknisk opplæring | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke til informasjonsside: https://anskaffelser.no/postaward/g3/announcement/
Release management: https://anskaffelser.no/postaward/g3/docs/release-management/
Lenke til tekniske spesifikasjoner: https://anskaffelser.no/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
X.6.1.2 Implementering og forvaltning av bestillingsløsning i kontraktsoppfølging
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
ID og navn | X.6.1.2 Implementering og forvaltning av bestillingsløsning i kontraktsoppfølging |
EHF prosess | |
Organisasjon | DFØ-ANS |
Prosess eier | Wenche Ludviksen |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2021.02.22 | Dokument etablert | Petter Vinje |
3. Definisjoner/forkortelser
System: Er i denne sammenheng samspillet mellom alle de ressurser som kreves for å realisere gevinstene ved innføring av ny bestillingsløsning: Mennesker, bestillingsløsning, prosesser og rutiner, målesystemer, arbeidsmiljø, informasjon, etc. - helheten.
4. Om prosessen
Prosessen beskriver alle de grunnleggende aktivitetene som må utføres ved analyse, implementering og forvaltning av bestillingsløsning i kontraktsoppfølgningsfasen. Prosessen tar utgangspunkt i at bestillingsløsningen er anskaffet og er avgrenset til aktiviteter for tilrettelegging, implementering og forvaltning av valgte løsning. I de tilfeller hvor det er behov for å gjennomføre prosjekter som går fra kartlegging av behov til valg av løsning, anbefaler vi at man i tillegg benytter Prosjektveiviseren.no som i større grad dekker de innledende fasene før implementering.
- I analyseprosessen kartlegges og analyseres dagens prosess og nåstiuasjon for kontraktsoppfølgning. Med det som utgangspunkt defineres fremtidig situasjon (målbildet) og endringsbehov kartlegges. Prosessen avsluttes med en rapport som beskriver funn og anbefalinger til implementering og forvaltning av bestillingsløsning. Analysefasen kan også gjennomføres som en selvstendig prosess, for eksempel i forbindelse med forbedringsarbeid (merverdi).
- I implementeringsprosessen videreføres og styrkes prosjektets forankring i linjeorganisasjon. Bestillingsløsningen tilrettelegges for bruk, piloteres og eventuelle feil og mangler rettes opp før løsningen rulles ut til alle brukerne. Bruken følges opp med målinger og rapporter til ledelsen.
- I forvaltningsprosessen beskriver alle de grunnleggende aktivitetene som må/bør utføres for å sikre en god og effektiv forvaltning av systemet – den digitale løsningen samt organisasjonen som forvalter og benytter den. Foreløpig har vi kun identifisert aktivitetene. Definisjoner for de ulike aktivitetene vil bli utarbeidet etter hvert.
5. Brukere og bruksområde
Oppdragsgiver: Har behov for prosessen når de skal velge og implementere ny bestillingsløsning. Aktiviteter i analyseprosessen som utføres i forbindelse med kartlegging av prosess, nåsituasjon, identifisere endringsbehov kan også benyttes som et ledd i internevaluering og forbedringsarbeid.
Leverandører: Når oppdragsgiver benytter en bestillingsløsning må leverandør også benytte et digital system for å kunne sende og motta meldinger – samhandle med oppdragsgiver. I den sammenheng vil leverandøren også kunne benytte prosessdefinisjonen (PDD) i forbedring av egne prosesser.
6. Formål
Sikre at virksomhetens bestillingsløsning blir implementert, benyttet og vedlikeholdt på en formålstjenlig og effektiv måte.
7. Mål
- Effektiv opplæringsprosess i bruk av bestillingsløsning.
- Hele virksomheten skal ta i bruk bestillingsløsning.
- Økt avtalelojalitet. Velge riktig varer/tjenster i henhold til avtale.
- Redusere risiko for å gjøre feil - øke kvalitet.
- Effektivisere virksomhetens prosess.
- Samle inn data for analyseformål. For eksempel ved utarbeidelse av strategi for anskaffelser.
- Redusere behov for leverandørprodusert statistikk.
8. Gevinster
Oppdragsgiver:
- Ved å benytte denne prosessen vil det bli enklere for prosjektleder å planlegge og gjennomføre prosjektet på en god og effektiv måte.
- Enklere for de som skal delta i prosjektet å forstå og gjøre det som kreves.
- Brukerne av bestillingsløsningen vil oppleve god tilrettelegging og støtte ved innføring og bruk av løsning.
- Ledelsen vil oppleve at alle de viktige prosessen blir etablert og fulgt.
- At det etableres en god rapporteringsrutine for prosjekt og forvaltning av bestillingssystem og organisasjon som skal benytte det.
- At målene nås og gevinster realiseres.
Leverandør:
- God tilgang til informasjon om hva oppdragsgiver forventer av leverandør når ny prosess og bestillingsløsning er implementert hos oppdragsgiver.
- Enklere å tilrettelegge egne prosesser for god digital samhandling.
- Kan benyttes i alle typer prosessforbedringsarbeid.
Samfunn:
- Fordi prosessen er generisk og kan benyttes av alle, vil den kunne bidra til bedre og mer effektiv implementering og forvaltning av bestillingsløsninger i den enkelte virksomhet - spredning av ønsket praksis, som igjen vil bidra til forbedring av kontraktsgjennomføringsprosessen.
- Dersom mange tar i bruk prosessen vil det kunne gi en betydelig samfunnsøkonomisk gevinst i forhold til dagens praksis.
9. Startkriterier/forutsetninger
Trigger |
Prosessen begynner med beslutning om bruk av bestillingsløsning. |
Andre forutsetninger |
Teknologiske: Må ha anskaffet et system. Organisatoriske: Bør være forankret i virksomhetens mål og strategi for digitalisering og/eller anskaffelser og nødvendig ressursallokering. |
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Beslutning om bruk av bestillingsløsning | Ledergruppen | ||
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle | Forkortelser | Kommentarer |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Oppdragsgiver | Ledergruppe | O-LG | |
Oppdragsgiver | Prosjektleder | O-PL | |
Oppdragsgiver | Prosjektdeltakere | O-PD | IT-avdeling, linjeleder, økonomi, HR, o.l. |
Oppdragsgiver | Prosesseier | O-PE | |
Oppdragsgiver | Innkjøper | O-IN | Person som leder innkjøpsprosessen. |
Oppdragsgiver | E-handelsansvarlig | O-EH | Ansvarlig for forvaltningsprosessen. Kontroll og tilgjengeliggjøring av avtale avropsmetode, herunder kontroll og godkjenning og distribusjon av katalog, punch-out, mm. |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL 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
Diagrammet viser de tre hovedaktivitetene/delprosessene.
Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
X6.1.2.1 | Analysere implementering av bestillingsløsning. | Lenke til prosessdefinisjon | Lenke til veileder og sjekkliste til prosess for implementering og forvaltning av bestillingsløsning | ||
X.6.1.2.2 | Implementere bestillingsløsning. | Lenke til prosessdefinisjon | Lenke til veileder og sjekkliste til prosess for implementering og forvaltning av bestillingsløsning | ||
X.6.1.2.3 | Forvalte bestillingsløsning. | Lenke til prosessdefinisjon | Lenke til veileder og sjekkliste til prosess for implementering og forvaltning av bestillingsløsning | ||
14. Kontrollpunkter og målinger
Se del-prosesser i punkt 13.
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
15. Output og mottaker/bruker
Se del-prosesser i punkt 13.
Output | Mottakende prosess | Mottaker/bruker | Referanse |
16. Sluttkriterier
Nei, når bestillingsløsningen er tatt i bruk må det etableres et forvaltningsregime som sikrer at systemet fungerer og blir løpende vedlikeholdt, oppdatert og forbedret.
17. Unntak/spesielle hensyn
Vi anbefaler alle å ta utgangspunkt i prosessdefinisjonen når prosjekter skal planlegges: Gå gjennom hver enkelt aktivitet. Diskutere om det er behov for utføre aktivitet eller ikke, hvem som er ansvarlig, hvordan den skal gjennomføres, hvor lang tid det vil ta, etc. En slik gjennomgang vil sikre at alle utvikler en felles forståelse for prosjektet/forvaltning: Hvem som skal gjøre hva, hvordan og hvorfor det skal gjennomføres. Samt bidrar til enklere planlegging og implementering.
Del-prosess, aktivitet | Unntak/hensyn |
---|---|
Se del-prosesser i punkt 13. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
---|---|---|---|---|
Systemleverandører blir forsinket eller ikke oppfyller kontraktskrav/funksjonalitet | Medium/Stor | Stor |
>Godt og tett samarbeid i analyse/planleggingsfasen. >Sanksjoner i kontrakt. |
>Dokumentere problemet. |
Systemleverandør blir kjøpt opp, går konkurs eller på annet vis ikke lenger kan/vil støtte versjonen eller løsningen lenger. | Liten | Stor | >Markedsovervåkning. |
>Dersom man har gjennomført en god anskaffelsesprosess kan denne gjenbrukes. >Har du en god forvaltningsprosess har du all informasjon du trenger, kun behov for å overføre til nytt system. |
Følger ikke prosessen, eller tilsvarende prosesser, spesielt analysefasen | Medium | Stor | Følge denne eller tilsvarende prosesser | >Gå igjennom alle delprosesser for å finne avvik og utfør det som ev. mangler. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Sikre lederforankring på alle nivåer. | Erfaring viser at du må ha forankring i hele linjen, og spesielt viktig på nederste nivå – de medarbeiderne rapporterer og forholder seg til. |
Sikre forankring og involvering, samarbeid, med IT, økonomi, regnskap, faktura | Innføring av ny bestillingsløsning forutsetter et tverrfaglig samarbeid med så tidlig involvering som mulig for å sikre forankring, motivasjon og gi deltakerne tid til planlegging. |
20. Tilleggsinformasjon
Nei
21. Vedlegg
Nei
X.6.1.2.1 Analysere implementering av bestillingsløsning
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
ID og navn | X.6.1.2.1 Analysere implementering av bestillingsløsning |
EHF prosess | |
Organisasjon | DFØ-ANS |
Prosess eier | Wenche Ludviksen |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2021.02.25 | Dokument etablert | Petter Vinje |
3. Definisjoner/forkortelser
System: Er i denne sammenheng det helhetlige samspillet mellom alle ressurser som kreves for å bruke og nyttiggjøre seg av den digitale løsningen: Mennesker, teknologi (it-systemer), metoder (prosesser, prosdyrer), målesystemer (KPI, rapporter, bruk av rapporter), arbeidsmiljø (fysisk, psykisk), informasjon, etc.
Endringsledelse: Planlegging, organisering, ledelse og kontroll med de aktiviteter som må utføres for å få til endringene som kreves for å realisere de planlagte gevinstene.
4. Om prosessen
I analyseprosessen kartlegges og analyseres dagens prosesser og nåsituasjon for kontraktsoppfølgning. Med det som utgangspunkt defineres fremtidig/ønsket situasjon (målbildet) og endringsbehov kartlegges. Prosessen avsluttes med en rapport som beskriver funn og anbefalinger til implementering og forvaltning av bestillingsløsning. Analysefasen kan også benyttes i generelt forbedringsarbeid.
5. Brukere og bruksområde
Oppdragsgiver: Har behov for prosessen når de skal velge og implementere ny bestillingsløsning. Aktiviteter i analyseprosessen som utføres i forbindelse med kartlegging av prosess, nåsituasjon, identifisere endringsbehov kan også benyttes som et ledd i internevaluering og forbedringsarbeid.
Leverandører: Når oppdragsgiver benytter et digitalt system må leverandør også benytte et digital system for å kunne sende og motta meldinger – samhandle med oppdragsgiver. I den sammenheng vil leverandøren også kunne benytte prosessdefinisjonen (PDD) i forbedring av egne prosesser.
6. Formål
Implementering, gevinstrealisering og forvaltning av bestillingsløsning forutsetter at virksomheten har de nødvendig kunnskaper for å lykkes med det. Hensikten med denne prosessen er å gi virksomheten en metode for å samle inn og bruke de kunnskaper som kreves for lykkes med prosjektet.
7. Mål
- Sikre at alle som deltar blir informert og involvert så tidlig som mulig. Tidlig involvering er motiverende i tillegg til at det gjør det enklere for deltakerne å forstå og planlegge hvordan de skal bidra.
- Sikre felles forståelse. Analyse, implementering og forvaltning forutsetter et effektiv samarbeid som igjen forutsetter at alle har samme forståelse for hva, hvorfor, hvordan, når, hvem, etc. Tidlig informasjon og involvering sikrer dette.
- Fremskaffe et best mulig fakta/kunnskapsgrunnlag for planlegging og implementering av bestillingsløsning. Mangelfull kunnskap/forståelse i planleggingen er en av de vanligste årsakene til at prosjekter ikke lykkes.
8. Gevinster
Oppdragsgiver: Ved å benytte denne prosessen vill det bli enklere for prosjektleder å planlegge og gjennomføre prosjektet på en god og effektiv måte. Enklere for de som skal delta i prosjektet å forstå og gjøre det som kreves. Brukerne av bestillingsløsning vil oppleve god tilrettelegging og støtte ved innføring og bruk av løsning. Ledelsen vil oppleve at alle de viktige prosessen blir etablert og fulgt. At målene nås og gevinster realiseres.
Leverandør: God tilgang til informasjon om hva oppdragsgiver forventer av leverandør når ny prosess og system er implementert hos oppdragsgiver. Enklere å tilrettelegge egne prosesser for god digital samhandling. Kan benyttes i eget forbedringsarbeid.
Systemleverandører: Vil oppleve at samarbeidet i alle faser av prosjektet blir enklere. Enklere å synliggjøre løsningens fordeler/gevinster. Styrker kunderelasjonen.
Samfunn: Bidrar til spredning av ønsket praksis for implementering og forvaltning av bestillingsløsning i kontraktsoppfølgning. Som igjen vil bidra til forbedring av kontraktsgjennomføringsprosessen. Med tanke på hvor viktig kontraktsoppfølgingsprosessen er. Hvor avhengig den er av bestillingsløsning. Og hvor mange som er avhengig av prosessen. Vil en riktig og effektiv digitalisering av kontraktsoppfølgingsprosessen gi en stor samfunnsøkonomisk gevinst.
9. Startkriterier/forutsetninger
Trigger |
Prosessen begynner med at bestillingsløsning er anskaffet. |
Andre forutsetninger |
>Prosjektet bør være forankret i virksomhetens mål og strategi for digitalisering og/eller anskaffelser. >Må ha gjennomført et grundig forarbeid – kartlegging av nåsituasjon, ønsket situasjon, etc. Dersom dette ikke er gjort, må dette gjøres i prosessen, se aktivitetene 9-12 i prosessdiagram, og pkt. 13 beskrivelse av aktiviteter. |
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Løsning er anskaffet | Ledergruppen | ||
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle | Forkortelser | Kommentarer |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Oppdragsgiver | Ledergruppe | O-LG | |
Oppdragsgiver | Prosjektleder | O-PL | |
Oppdragsgiver | Prosjektdeltakere | O-PD | IT-avdeling, linjeleder, økonomi, HR, o.l. |
Oppdragsgiver | Prosesseier | O-PE | Den som har ansvaret for prosessen. Alle virksomheter har ikke prosesseiere. Bør vurderes. |
Oppdragsgiver | Innkjøper | O-IN | Person som leder innkjøpsprosessen. |
Oppdragsgiver | E-handelsansvarlig | O-EH | Ansvarlig for forvaltningsprosessen. Kontroll og tilgjengeliggjøring av avtale avropsmetode, herunder kontroll og godkjenning og distribusjon av katalog, punch-out, mm. |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL 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
Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
1. Avklare om det er tilstrekkelig informasjon og forankring for å utarbeide plan – O. | O-PL | Dersom du har tilstrekkelig informasjon, forankring og mandat kan du gå til aktivitet nr. 5. Hvis ikke må du utføre aktivitet 2, 3 og 4. | |||
2. Skaffe informasjon og/eller utforme forslag til mandat – O. | O-PL | ||||
3. Forberede og gjennomføre presentasjon av mandat for ledelsen i virksomheten – O. | O-PL | ||||
4. Godkjenne mandat – O. | O-LG | ||||
5. Lage prosjektplan – D. | O-PL | Se aktivitet nr. 1 | |||
6. Godkjenne prosjektplan – O. | O-LG | ||||
7. Forberede kick-off – O. | O-PL | ||||
8. Gjennomføre Kick/off – O. | O-PL | ||||
9. Lage og (foredle) AS-IS prosessmodell – D. | O-PE eller O-PD | >Kartlegging av prosesser og bruk av BPMN 2.0. | Dersom man ikke har prosesseier, er det naturlig at en av prosjektdeltakerne med kompetanse i prosesskartlegging gjør det. Alternativ får ekstern bistand. | ||
10. Kartlegge og analysere nåsituasjon for AS-IS prosessmodell – D. | O-PL | >Se veileder over. | I aktivitet nr. 9 kartlegges aktivitetene. Mens i denne aktivitetene kartlegges og analyseres situasjonen når vi utfører disse aktivitetene. For eksempel: Hva er bra som bør videreføres? Hva er problematisk – som må løses i en ny løsning? Hva kan forbedres med bruk av ny løsning? Etc. | ||
11. Definere fremtidig situasjon – målbildet – D. | O-PL | Prøve å beskrive situasjonen når løsning er implementert. For hvem er dette en fordel? For hvem er dette en ulempe? Hvordan må/ønsker vi at situasjonen skal være med ny løsning? | |||
12. Beskrive TO-BE prosessmodell og roller. Benytte eksisterende rollebeskrivelser eller lage nye – D. | O-PE O-PD | Basert på beskrivelse av fremtidig situasjon, må prosessen defineres som grunnlag for utarbeidelse av rollebeskrivelser og opplæring. | |||
13. Kartlegge virksomhetens avdelinger/divisjoner som skal ta systemer/verktøy i bruk og hvilke roller som skal dekkes med hvilke personer – O. | O-PD | Benytt rollebeskrivelsene utarbeidet i aktivitet nr. 12. | |||
14. Kartlegge virksomhetens leveransepunkter og identifiser disse med en maskinlesbar unik identifikator (eks. GLN) – O. | O-PD |
>Sjekk i GS1 systemet om dine leveringspunkter er opprettet av en leverandør allerede. Sørg i tilfelle for å ta over eierskapet av disse. Priser GLN tjenester | GS1 Norway |
Må kartlegge hvilke leveransepunkter dere har og sjekke ut at de stemmer. Dersom det er besluttet at virksomheten skal lage sin egne unike identifikatorer må disse knyttes mot leveransestedene. Det er viktig at denne listen holdes oppdatert og ved endring at det kommuniseres ut til leverandører. Dersom det er besluttet å kjøpe en GLN nummerserie fra GS1 Norge. Bestill nye GLN nummer og knytt disse mot leveringspunktene. Dette viderformidles til leverandørene slik at de får lagt det inn i sine systemer, knyttet til riktig kundenummer. er Leverandør informeres om endringer av GS1 systemet. |
||
15. Kartlegge og analysere gap – forskjellen på as-is og to-be. Kartlegger endringsbehov og behov for use case – D. | O-PL | >Veileder kommer. | Det er veldig viktig å kartlegge alle endringsbehov, ikke bare det tekniske. | ||
16. Definere områder for måling (KPI) for alle avdelinger. Etablere måltall per avdeling og informere om rapporteringsrutiner – O. | O-PD | Mulige kilder for informasjon: HR-system, organisasjonskart og økonomisystem for å finne fullmaktsstruktur. | |||
17. Skrive analyserapport – O. | O-PL | Lenke til veileder kommer. Se aktivitet nr. 9. | Rapporten er viktig fordi den sikrer et felles forståelse, målbilde og godt grunnlag for planlegging av implementering og forvaltning. | ||
18. Kvalitetssikre analyserapport – O. | O-PL | ||||
19. Presentere analyserapport for ledelsen – O. | O-PL | ||||
20. Godkjenne analyserapport – O. | O-LG | ||||
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei | |||
15. Output og mottaker/bruker
Output | Mottakende prosess | Mottaker/bruker | Referanse |
Analyserapporten |
>Ledelsesprosess >X5122 Implementere digital løsning i kontraktsoppfølging |
>Lederrguppen >Deltakere i implementeringsprosess |
|
Rollebeskrivelser |
>Rekrutteringsprosessen >Opplæringsprosessen >Ledelse (veiledning og coaching) |
>HR >Ledergruppen og linjeledere |
Lenke til veileder og sjekkliste til prosess for implementering og forvaltning av bestillingsløsning |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Vi anbefaler alle å ta utgangspunkt i prosessdefinisjonen når prosjekter skal planlegges: Gå gjennom hver enkelt aktivitet for å diskutere og avklare om det er behov for aktiviteten eller ikke, hvem som er ansvarlig, hvordan den skal gjennomføres, hvor lang tid man antar det vil ta. Etc. En slik gjennomgang vil sikre at alle utvikler en felles forståelse for prosjektet og ens egen rolle og bidrag i det.
Del-prosess, aktivitet | Unntak/hensyn |
Dersom ledergruppen har besluttet implementering | Kan man hoppe over aktivitet 1-4, starte planleggingen i aktivitet 5. Lage prosjektplan |
Aktivitet 18-21 | Må vurdere omfang og behov. I noen tilfeller kan det være tilstrekkelig med informasjon om status, videre arbeid. I andre tilfeller kan det være nødvendig å avsette ekstra tid på informasjon, forankring, avklaringer og beslutninger. Det er viktig at alle spørsmål besvares og alle avklaringer tas før man begynner implementering. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Ikke fulgt definert analysefase. | Medium | Stor | Sikre at prosjektet følger analysefasen som er definert. | Benytte denne prosessbeskrivelse for å avdekke hvor det er feil, mangler og rette opp. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Nei | |
20. Tilleggsinformasjon
Nei
21. Vedlegg
Nei
X.6.1.2.2 Implementere bestillingsløsning
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
ID og navn | X.6.1.2.2 Implementere bestillingsløsning |
EHF Prosess | |
Organisasjon | DFØ-ANS |
Prosess eier | Wenche Ludviksen |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2021.02.25 | Dokument etablert | Petter Vinje |
3. Definisjoner/forkortelser
System: Er i denne sammenheng samspillet mellom alle de ressurser som kreves for å nå målet: Mennesker, teknologi(it-systemer), metoder, målesystemer, arbeidsmiljø, informasjon, etc. - helheten.
4. Om prosessen
I implementeringsprosessen beskrives hvilke aktiviteter som må/bør utføres i forbindelse med implementering av bestillingsløsning: Forankring av prosjekt i hele organisasjonen linje fra toppleder og ut til medarbeidere og linjeledere. Tilrettelegging av system for bruk. Pilotering og retting av feil og mangler. Utrulling til alle brukere med oppfølgning, måling og rapportering til ledelsen.
5. Brukere og bruksområde
Oppdragsgiver: Har behov for prosessen når de skal implementere den nye bestillingsløsning.
6. Formål
Sikre at virksomhetens digitale løsninger blir implementert i henhold til plan.
7. Mål
Alt implementeringsprosessen tilrettelegges slik at alle som deltar forstår, kan, vil og har mulighet til å utføre sine oppgaver på den måten som forventes.
8. Gevinster
Oppdragsgiver: Ved å benytte denne prosessen vill det bli enklere for prosjektleder å planlegge og gjennomføre prosjektet på en god og effektiv måte. Enklere for de som skal delta i prosjektet å forstå og gjøre det som kreves. Brukerne av digitale løsninger vil oppleve god tilrettelegging og støtte ved innføring og bruk av løsning. Ledelsen vil oppleve at alle de viktige prosessen blir etablert og fulgt. At målene nås og gevinster realiseres.
Leverandør: God tilgang til informasjon om hva oppdragsgiver forventer av leverandør når ny prosess og system er implementert hos oppdragsgiver. Enklere å tilrettelegge egne prosesser for god digital samhandling. Kan benyttes i eget forbedringsarbeid.
Systemleverandører: Vil oppleve at samarbeidet i alle faser av prosjektet blir enklere. Enklere å synliggjøre løsningens fordeler/gevinster. Styrker kunderelasjonen.
Samfunn: Bidrar til spredning av ønsket praksis for implementering og forvaltning av digitale løsninger – utvikling av gode og effektive støtteprosesser. Som igjen vil bidra til forbedring av kontraktsgjennomføringsprosessen. Med tanke på hvor mange som kan benytter denne prosessen vil gi en betydelig samfunnsøkonomisk gevinst.
9. Startkriterier/forutsetninger
Trigger |
Output fra X.6.1.2.1 Analysere implementering av bestillingsløsning. |
Andre forutsetninger |
|
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Dokumenter | X.6.1.2.1 Analysere implementering av bestillingsløsning. | Prosjektgruppe | |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Oppdragsgiver | Ledergruppe | O-LG | |
Oppdragsgiver | Prosjektleder | O-PL | |
Oppdragsgiver | Prosjektdeltakere | O-PD | IT-avdeling, linjeleder, økonomi, HR, o.l. |
Oppdragsgiver | Prosesseier | O-PE | |
Oppdragsgiver | Innkjøper | O-IN | Person som leder innkjøpsprosessen. |
Oppdragsgiver | E-handelsansvarlig | O-EH | Ansvarlig for forvaltningsprosessen. Kontroll og tilgjengeliggjøring av avtale avropsmetode, herunder kontroll og godkjenning og distribusjon av katalog, punch-out, mm. |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL 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
Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
1. Forankre og ansvarliggjøring ledere på alle nivåer, spesielt linjeledere som har hovedansvar for tilrettelegging og bruk av løsninger inntil ønsket praksis er etablert som kultur – D. | O-PL |
Spesielt linjeledere som har hovedansvar for tilrettelegging og bruk av løsninger inntil ønsket praksis er etablert som kultur. Lenke til veileder og sjekkliste til prosess for implementering og forvaltning av bestillingsløsning |
|||
2. Utforme opplæringsmateriell og lag en opplæringsplan som omfatter de ulike rollers bruk av systemet. Legg ut informasjon på intranett/e.lignende – D. |
O-PL |
Systemleverandører har en viktig rolle. | |||
3. Sette opp tilgangsstyring i system for pilotbrukere i henhold til definerte roller – O. | O-PL | Prosjektleder må involvere berørte enheter for å utføre aktiviteten. | |||
4. Lage og/eller importere og kvalitetssikre katalog for oppstart – O. | O-PL | I denne prosessen utføres denne ofte av en prosjektleder. For å videreføre kompetansen er det en fordel om prosjektleder får rollen som ehandelsansvarlig i forvaltningsprosessen. | |||
5. Knytte UNSPSC koder mot konteringsstrengen i økonomisystem (for å muliggjøre automatisk match mellom ordre og faktura) – O. | O-PL | Prosjektleder må involvere berørte enheter for å utføre aktiviteten. | |||
6. Gjennomføre systemopplæring for pilotbrukere tilpassert ulike roller – O. | O-PL | Forutsetter at systemleverandør har materiell. Eller man benytter egenprodusert materiale. Dette inkluderer også pilotering av opplæringsmateriell som skal benyttes i utrullingen. | |||
7. Gjennomføre pilot med pilotgruppe – D. | O-PL | Foretar reelle bestillinger mot definerte leverandører basert på innsendt katalog. | |||
8. Evaluere tilbakemelding fra brukere relatert til pilot – O. | O-PL | ||||
9. Melde avvik – O. | O-PL | ||||
10. Foreta eventuelle korrigeringer/utbedringer på bakgrunn av tilbakemeldinger -D. | SL | ||||
11. Teste korrigeringer/utbedringer – O. | O-PL | Hvis korrigeringer ikke fungerer, må man melde tilbake til systemleverandører, akt. 9. | |||
12. Gjennomføre systemopplæring tilpasset ulike roller for alle avdelinger i henhold til utrullingsplan – D. | O-PL | Forutsetter at man har testet dette, aktivitet nr. 6. | |||
13. Rapportere om status til ledergruppen underveis – D. | O-PL | Kan inneholde aktiviteter som: Hente, sammenstille, analysere, presentere. Viktig å knytte rapporten til virksomhetens vedtatte måleparametere i analysefasen. | |||
14. Kontrollpunkter og målinger
Se del-prosesser i punkt 13.
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei | |||
15. Output og mottaker/bruker
Output | Mottakende prosess | Mottaker/bruker | Referanse |
System tilgjengelig for bruk i hele organisasjonen. |
>X.4.2 Bruke avtalen >X.4.3 Forvalte avtalen >X.6.1.2.3 Forvalte bestillingsløsning i kontraktsoppfølging |
Alle som har behov som må dekkes. | |
Kompetanse opparbeidet i implementeringsprosjekt. | >X.6.1.2.3 Forvalte bestillingsløsning i kontraktsoppfølging | Linjeorganisasjonen må få tilført kompetanse. Det beste er om deltakere i analyse og implementeringsprosjektet får tilsvarende roller i forvaltningsprosessen. |
16. Sluttkriterier
- Analyse- og implementeringsprosessen, med erfaringer, må være dokumentert og tilgjengelig for forvaltningsprosessen (for eksempel sluttrapport).
- Forvaltningsansvarlig må være utpekt og kompetanse overført fra prosjektleder dersom dette ikke er samme person.
17. Unntak/spesielle hensyn
Vi anbefaler alle å ta utgangspunkt i prosessdefinisjonen når prosjekter skal planlegges: Gå gjennom hver enkelt aktivitet. Diskutere om det er behov for utføre aktivitet eller ikke, hvem som er ansvarlig, hvordan den skal gjennomføres, hvor lang tid man antar det vil ta. Etc. En slik gjennomgang vil sikre at alle utvikler en felles forståelse for prosjektet – hvem som skal gjøre hva, og hvordan det skal gjennomføres, samt enklere planlegging.
Del-prosess, aktivitet | Unntak/hensyn |
Nei | |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Ledere som ikke sikrer at deres organisasjon tar i bruk løsningen. | Middels | Stor |
>Kan redusere ved rapportering og oppfølgning av den enkelte leders ansvar og bidrag. >Det er viktig med hyppig oppfølgning og rapportering til toppleder. >Viktig at toppleder iverksetter tiltak ved avvik. |
Avvik må rapporteres til virksomhetens øverste leder. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Prosjektleder må få opplæring i hvordan prosjektet skal | |
Prosjektleder må myndiggjøres og ha støtte fra toppleder. | |
Prosjektleder må ha tilgang til andre relevante fagområder som for eksempel IT, innkjøp, økonomi, faktura, HR. | |
Prosjektleder må ha mandat til å styre leverandører av varer og tjenester som skal knyttes til løsningen. |
20. Tilleggsinformasjon
Nei
21. Vedlegg
Nei
X.6.1.2.3 Forvalte bestillingsløsning
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
ID og navn | X.6.1.2.3 Forvalte bestillingsløsning |
EHF Prosess | |
Organisasjon | DFØ-ANS |
Prosess eier | Wenche Ludviksen |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2021.02.25 | Dokument etablert | Petter Vinje |
3. Definisjoner/forkortelser
System: Er i denne sammenheng samspillet mellom alle de ressurser som kreves for å nå målet: Mennesker, teknologi(it-systemer), metoder, målesystemer, arbeidsmiljø, informasjon, etc. - helheten. Bestillingssystem: Er alle de ressurser som kreves for å gjennomføre bestillinger. Mens bestillingsløsningen er det tekniske verktøyet som benyttes i systemet.
4. Om prosessen
Prosessen beskriver alle de viktigste aktivitetene som må utføres for å sikre en god og effektiv forvaltning av virksomhetens bestillingssystem.
Hver enkelt del-prosess vil bli beskrevet i nærmere deltalj, utarbeides egen PDD.
5. Brukere og bruksområde
Oppdragsgiver: Har behov for prosessen for å sikre at virksomheten til enhvertid har et oppdater og velfungerende bestillingssystem. Sikre kontinuitet – at kvalitet og effektivitet ikke reduseres ved sykdom, fravær, endring av ansatte. Sikre at forbedringstiltak ikke får uønskede konsekvenser – at ytelser ikke påvirkes negativt.
Systemleverandører: Trenger prosessen for å fange opp feil og eventuelt ønske om endring fra oppdragsgiver. Endringer i bestillingsløsningen, verktøyet.
6. Formål
Sikre at virksomheten:
- Til enhver tid har en bestillingsløsning som ivaretar brukernes behov for å få levert riktige varer og tjenester til rett tid, med rett kvalitet.
- Benytter ressursene effektivt.
- Oppfyller dokumentasjonskrav.
- Sikrer at lovpålagte krav følges.
Samfunn:
- Mer effektiv forvaltning
7. Mål
- Alle skal benytte løsningen.
- At den er tilpasset de standarder som er definert.
- At den bidrar til bedre internkontroll
- Bedre statistikk.
- Økt avtalelojalitet.
- Tilrettelegge for bedre prosesser for leverandører.
7. Gevinster/fordeler
Oppdragsgiver:
- Enklere å overta og videreføre oppgaver for den som får ansvar for forvaltningen.
- Sikrer at man har en optimal (best og mest mulig effektiv) «bestilling til betalingsprosess»/Kontraktsoppfølgningsprosess. Ledelsen får raskere tilgang til data,informasjon - bedre beslutningsgrunnlag. Redusert risiko for uønskede forpliktelser. Reduserer risiko for at prosesser ikke utføres, ev. utføres ved ved sykdom, fravær, etc.
Leverandører:
- God tilgang til informasjon om hva oppdragsgiver forventer av leverandør når ny prosess og system er implementert hos oppdragsgiver.
- Får bestillingen gjennom én, ikke flere kanaler. Sikrer god kvalitet, unngår feil, misforståelser. Reduserer risiko for feillevering og gjennom det kostbar retur av varer.
- En maskinlesbar bestilling tilrettelegger for enklere generering av påfølgende dokumenter som for eksempel ordrebekreftelse, pakkseddel og faktura. Enklere å tilrettelegge egne prosesser for god digital samhandling. Kan benyttes i eget forbedringsarbeid.
- Mulighet for raskere betaling fra oppdragsgiver.
- Rapportering og statistikkkrav til leverandør kan borfalle – ivaretas av oppdragsgiver.
Systemleverandører:
- Forutsigbart endringsarbeid.
- Mindre behov for opplæring og support.
- Enklere å avdekke nye behov og muligheter for tjenesteutvikling.
Samfunn:
- Økt avtalelojalitet antas å ha en stor økonomisk gevinst.
- Maskinlesbart gir bedre grunnlag for å nasjonal statistikk.
- Bidrar til spredning av ønsket praksis for implementering og forvaltning av bestillingsløsninger – utvikling av gode og effektive støtteprosesser.
- Digital samhandling via standardformat kan redusere risiko for arbeidslivskriminalitet, samt stimulere til reduksjon av miljøbelastning.
9. Startkriterier/forutsetninger
Trigger |
X.6.1.2.2 Implementere bestillingsløsning |
Andre forutsetninger |
Ansvaret for forvaltning av bestillingsløsning er overført og forstått av linjen. |
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
System er implementert og all nødvendig dokumentasjon og kompetanse er overført til linjen. |
X.6.1.2.2 Implementere bestillingsløsning X.4.2 Bruke avtalen X.4.3 Forvalte avtalen |
11. Deltakere
Beskrivelse av roller
Organisasjon | Rolle | Forkortelser | Kommentarer |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Oppdragsgiver | Ledergruppe | O-LG | |
Oppdragsgiver | Prosjektleder | O-PL | |
Oppdragsgiver | Prosjektdeltakere | O-PD | IT-avdeling, linjeleder, økonomi, HR, o.l. |
Oppdragsgiver | Prosesseier | O-PE | |
Oppdragsgiver | Innkjøper | O-IN | Person som leder innkjøpsprosessen. |
Oppdragsgiver | E-handelsansvarlig | O-EH | Ansvarlig for forvaltningsprosessen. Kontroll og tilgjengeliggjøring av avtale avropsmetode, herunder kontroll og godkjenning og distribusjon av katalog, punch-out, mm. |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL 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
Lenke til: Implementering og forvaltning av bestillingslosning i kontraktsoppfølging.excel
Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
13. Aktiviteter
Disse aktivitetene beskriver del-prosesser som vil bli definert på et senere tidspunkt. I tillegg til disse kan det også være behov for andre typer aktiviteter i forvaltningen.
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse |
KP (x) |
Kommentar |
1. Justere og kontinuerlig forbedre prosesser - D. | O-LG | Beskriver de aktiviteter som oppdragsgiver må utføres for å praktisere kontinuerlig forbedring. | Kontinuerlig forbedring av prosessen er ledelsens ansvar. | ||
2. Vedlikeholde roller og tilgangsstyring, samt opplæring av brukere – D. | O-EH | Beskriver aktiviteter som ivaretar virksomhetens sikkerhetsbehov knyttet til bestilling av varer og tjenester. Samt sikre at de som har roller har den nødvendige kompetansen. | X | Lenke til veileder og sjekkliste til prosess for implementering og forvaltning av bestillingsløsning | |
3. Opprette(nye) og vedlikeholde unike interne maskinlesbare koder for identifikasjon av fysiske leveransepunkter – D. | O-EH | Beskriver aktiviteter som sikrer at varer og tjenester blir levert til riktig mottakssted/lokasjon. | X | Lenke til GS1/GLN https://www.gs1.no/gln | |
4. Legge inn, vedlikeholde og knytte leveranseadresser mot riktige brukere – D. | O-EH | Beskriver aktiviteter som sikrer sikrer at bestiller og fysisk leveransested knyttes sammen. Redusere mulighet for avvik. Og sikre at bestiller har myndighet til å forplikte virksomheten økonomisk. | |||
5. Kontere UNSPSC grupper for automatisk konteringer-D. | O-EH | Beskriver aktiviteter som sikrer at riktig informasjon er lagt i system for automatisering av senere prosesser. | |||
6. Leverandøraktivering og avslutning – D | O-EH | Beskriver aktiviteter som sikrer at man aktiverer og avslutter en kontrakt på en mest mulig effektiv måte. | X | ||
7. Sikre at krav til digitale prosesser finnes i de konkurranser der det er relevant – D. | O-EH | Beskriver aktiviteter som sikrer at leverandører oppfyller de forpliktelser oppdragsgiver ønsker å gi for å stimulere til en digital prosess. | X |
Inngår i planleggingsprosessen. Lenke til samhandlingsavtale blant annet. |
|
8. Lage relevant statistikk for bruk i planlegging og kontraktsoppfølging – D. | O-EH | Beskriver aktiviteter som sikrer god informasjon til virksomheten angående måloppnåelse/KPIer. | Inngår i planleggingsprosessen. | ||
9. Informere internt/eksternt om digitale prosesser – D. | O-EH | Beskriver aktiviteter som sikrer en god og oppdatert informasjon til interne og eksterne brukere. | |||
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Aktivitet nr. 2 | At alle som har fått tildelt rolle også har gjennomført opplæring. | Loggføre opplæring. | Sikre at system har brukere som kan utføre prosessen. |
Aktivitet nr. 3 | Sjekk at maskinlesbare koder er mottatt og lagt inn i system. Og at de er unike pr. lokasjon. | Virksomheten må utpeke en ansvarlig for administrasjon og innleggelse av de unike kodene i sitt system. | Sikre at leverandør kan mappe ordre mot sitt kundenummer med riktig leveransepunkt/lokasjon. Unngå at varer og tjenester blir levert til feil sted. |
Aktivitet nr. 6 | At katalog fjernes fra system når avtalen går ut/opphører. | Ansvarlig for katalogverktøy fjerner tilgang til bestilling på katalogen ved å gjøre den usynlig, inaktiv, fjernes helt. | Stimulere til økt avtalelojalitet på ny katalog. Sikre at man bestiller riktig produkt av riktig leverandør til riktig pris. |
Aktivitet nr. 7 | At status quo og erfaringer inkluderes i nye anskaffelser som planlegges. | Anskaffelsesavdeling må etablere en rutine for å inkludere de som er ansvarlig for bestillingsløsning. | Sikre at riktig og oppdaterte krav implementeres i nye avtaler. Risiko for at du får en leverandør som ikke kan levere katalog i riktig format. Som betyr at du ikke kan bruke bestillingsløsningen for den aktuelle avtalen. |
15. Output og mottaker/bruker
Output | Mottakende prosess: | Mottaker/bruker | Referanse |
1. Justere og kontinuerlig forbedre prosesser: Økt kvalitet. Økt effektivitet. Økt produktivitet. Etc. | Samme prosess. | Hele organiasjonen. | |
2. Vedlikeholde roller og tilgangsstyring, samt opplæring av brukere: Oppdatert roller, tilganger og kompetanse til å fylle rollen man har fått tildelt. |
Bestillingsprosessen. |
De som har en eller flere roller. | |
3. Opprette(nye) og vedlikeholde unike interne maskinlesbare koder for identifikasjon av fysiske leveransepunkter. | Ordre- og varemottaksprosessen. | Leverandør og organiasjon. | |
4. Legge inn, vedlikeholde og knytte leveranseadresser mot riktige brukere. | Bestillingsprosessen. | Bestillere. | |
5. Kontere UNSPSC grupper for automatisk konteringer. | Fakturaprosessen (ordre/fakturamatch) | Bestiller, attestant og regnskap. | |
6. Leverandøraktivering og avslutning. | Katalog- og bestillingsprosessen. | Leverandør, katalog- og avtaleansvarlig. | |
7. Sikre at krav til digitale prosesser finnes i de konkurranser der det er relevant. | Planleggingsprosessen. | Innkjøpsansvarlig. Leverandørmarkedet. | |
8. Lage relevant statistikk for bruk i planlegging og kontraktsoppfølging. | Planleggingsprosessen. Løpende avtaleforvaltning. Økonomi- og regnskap. | Alle. | |
9. Informere internt/eksternt om digitale prosesser. | Alle. |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
Se prosessdefinisjon for hver del-prosess i forvaltningsprosessen. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Se prosessdefinisjon for hver del-prosess i forvaltningsprosessen |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Se prosessdefinisjon for hver del-prosess i forvaltningsprosessen. | |
20. Tilleggsinformasjon
Se prosessdefinisjon for hver del-prosess i forvaltningsprosessen.
21. Vedlegg
Se prosessdefinisjon for hver del-prosess i forvaltningsprosessen.
X. 6.2 HR-støtte
X. 6.2.1 Endringsledelse
X.6.3 Aktivere og deaktivere leverndører
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
ID og navn | X.6.3 Aktivere og deaktivere leverandører i bestillingsløsning, knyttet til X.4.3.3. Avslutte kontrakt. |
EHF Prosess | |
Organisasjon | DFØ-ANS |
Prosess eier | Wenche Ludviksen |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2021.05.28 | Dokument etablert | Petter Vinje |
3. Definisjoner/forkortelser
Ingen
4. Om prosessen
Prosessen beskriver aktiviteter virksomheten må gjøre for å sjekke om varen/tjenesten er egnet for katalog eller punch-out, og om leverandørene kan delta i en elektronisk bestillings- til betalingsprosess. Hvordan de aktiveres i den digitale samhandlingen. Og hvordan samhandlingen avsluttes ved kontraktens opphører.
5. Brukere og bruksområde
Virksomheten v/kontraktsansvarlig: Har ansvar for å forberede leverandørmarkedet på den digitale samhandlingen, tilrettelegge for mottak av varer/tjenestekatalog eller innleggelse av punch-out lenke og sjekk av punch-out løsningens kvalitet. Fjerne katalog og/eller punch-out lenke ved kontraktens avslutning.
6. Formål
Sikrer at leverandører leverer varer og tjenester ihht avtalt kvalitet, tid og pris.
7. Mål
Tids- og ressursbruk: Leverandøraktiveringen skjer med minst mulig bruk av tid og ressurser.
Kvalitet: Kvalitetssikre at brukerne/bestillerne får et riktig vare-/tjenestesortiment i henhold til kontrakt.
Avtalelojalitet: Legge til rette for 100% avtalelojalitet.
8. Måltall/KPIer
Dersom det er definert måltall eller KPI kan de beskrives her. Dersom det er en direkte sammenheng mellom prosessen og et mål/måltall bør det beskrives. For eksempel «Prosess X er nødvendig for å oppnå mål……».
Måltall/KPI | Kommentarer |
Avtalelojalitet. | Avtalelojalitet vil si at man bestiller hos riktig leverandør, bestiller de varer/tjenester man har avtalepriser på. Samt at man sikrer at man kun betaler for de varer/tjenester man mottar. Med elektronisk bestillingsløsning bør avtalelojalitet være 100% som måles og følges opp. |
Lojalitet til bruk av bestillingsløsning. |
For eksempel obligatorisk bruk av bestillingsløsning i virksomheten. Organisasjonen bør ha mål om 100% bruk av bestillingsløsning, måle, følge opp og iverksette tiltak om nødvendig. |
9. Gevinster:
Oppdragsgivers gevinster: Oppfylle kravene i LOA/FOA vedrørende etterlevelse av avtale. Effektivisere virksomhetens prosesser gjennom automatisering av oppgaver. Forenkler arbeidsprosessen for avtaleforvalter og bestillere. Sikrer at man kan realisere de økonomiske gevinstene man kan oppnå gjennom avtalen. Sikrer at kjøpsbeslutningen tas på grunnlag av riktig informasjon – unngå feilbestillinger, reklamasjoner, feilleveranser. Virksomheten har til enhver tid tilgang til egne data – ikke avhengig av leverandøren – raskere og bedre beslutningsgrunnlag. Bestillingssystemet sikrer at bestillinger blir anvist og godkjent, noe som igjen sikrer at man ikke forplikter virksomheten på feil grunnlag.
Leverandørers gevinster: Økt antall avrop på sin avtale. Mulighet for elektronisk prosessering av bestilling fra oppdragsgiver – mulighet til å effektivisere egne interne prosesser. Dersom man lager en god beskrivelse av varen/tjenesten i katalogen reduseres risiko for feil bestillinger som medfører kostbare returer. Implementering av ny avtale er effektiv ved at leverandør slipper å bruke ressurser på å selge inn sitt sortiment til hver enkelt bestiller. Når oppdragsgiver bruker GLN eller andre maskinlesbare identifikatorer blir leveransepresisjonen høyere og enklere – mer effektive leveranseprosesser.
Samfunnets gevinster: Virksomheter som får riktig varer/tjenester til riktig pris, kvalitet og leveransepresisjon vil få reduserte kostnader, frigjøre ressurser til viktigere oppgaver. Miljøgevinst gjennom færre og mer effektiv leveranser – reduksjon av unødvendig transport.
10. Startkriterier/forutsetninger
Trigger |
Ny avtale med leverandør av varer og tjenester er inngått. |
Andre forutsetninger |
Teknologiske:
|
Andre forutsetninger |
Organisatoriske:
|
11. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Signert avtale fra leverandør | Leverandør | ||
Og/eller behov for å bestille varer og tjenester |
X.4.2.2 Bestille varer og tjenester Begge lenken viser til en oversikt over EHF prosesser. |
Oppdragsgiver | Mange har leverandører som må legges inn i bestillingsløsningen selv om de ikke har en formell kontrakt. |
12. Deltakere
Beskrivelse av roller
Organisasjon | Rolle | Forkortelser | Kommentarer |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Oppdragsgiver | Person | O-per | O-per benyttes når man ønsker å angi at denne aktiviteten utføres av en person hos oppdragsgiver, uten behov for å angi rolle. |
Oppdragsgiver | Behovshaver | O-beh | O-beh benyttes når man ønsker å angei at denne aktiviteten utføres av en behovshaver. |
Oppdragsgiver | System | O-sys | O-sys benyttes når man ønsker å angi at aktiviteten utføres av oppdragsgivers system. |
Oppdragsgiver | Budsjetteier/avtaleier. | O-bud | Den som har budsjettmyndighet. O-bud benyttes når det er behov for å angi at denne aktivitetene utføres av budsjett/avtaleier hos oppdragsgiver. |
Oppdragsgiver | Innkjøper | O-inn | Person som leder innkjøpsprosessen. |
Oppdragsgiver | Kontraktsforvalter | O-kon | Den som følger opp kontrakten mot leverandør og brukere etter kontraktsinngåelse. |
Oppdragsgiver | Fagansvarlig | O-fag | Fagperson som har spisskompetanse sitt fagområde. |
Oppdragsgiver | Bestiller | O-bes | Den som gjennomfører bestillinger på løpende avtaler med en eller flere leverandører |
Oppdragsgiver | Mottaker | O-mot | Mottaker av varen eller tjenesten |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon | |
Leverandør | Person | L-per | Angir at aktivitet utføres av en person i leverandørorganiasjon |
Leverandør | System | L-sys | Angir at aktivitet utføres av et system i leverandørs organisasjon. |
Systemleverandør | SL | SL 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. | |
Publiseringstjeneste | Pub | Pub benyttes når det er behov for å angi at aktiviteten utføres av en publiseringstjeneste, for eksempel Doffin. Her kan man også bytte ut Publiseringstjeneste med organisajsonens navn, for eksempel Doffin. | |
Ev andre | Ev. andre | Man kan også legge til roller dersom det er hensiktsmessig. |
13. Prosessdiagram
Last med Prosessdiagram:
Dersom du har Visio og ønsker å bruke/redigere diagrammet.
Høyre-klikke på diagrammet
Klikk "Visio-objekt"
Klikk "Rediger" eller Åpne" diagram i Visio.
14. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse |
KP (x) |
Kommentar |
Forberede aktivering av avtale og/eller leverandør | |||||
1. Internanalyse av egnethet av vare og/eller tjeneste for avrop via egne systemer (bestilling til betaling) Egner seg for katalog eller punch-out? | O-inn | I anskaffelsesprosessen X.2.1 Vurdere behov, se lenke | |||
2. Undersøke i markedet – D. | O-inn | ||||
3. Analysere funn – O. | O-inn | ||||
4. Utfylling av krav i anskaffelsesdokumentene (samhandlingsavtalen) -O. | O-inn | Tekst kravspesifikasjon og kontrakt | |||
5. Informere – D. | O-inn | ||||
6. Melde seg på leverandørkonferanse – O. | L-per |
|
|||
7. X.3.1.1 Kunngjøre konkurranse – P. | O-inn | ||||
Aktivere avtale og eller leverandør | |||||
1. Planlegg leverandøraktivering – D. | O-per | ||||
2. Vurder behov for å sende en påminnelse til leverandørene om de krav som er stilt i anskaffelsen som skal understøtte bestilling til betalingsprosessen. F.eks. EHF og andre krav til digital samhandling – O. | O-per | ||||
3. Planlegg oppstartsmøte med leverandør basert på de krav som er stilt i anskaffelsen – O. | O-per | ||||
4. Forbered oppstartsmøte ved å sjekke status i egen organisasjon angående digital samhandling – O. | O-per | ||||
5. Oppstartsmøte Gjennomgå kravene som er beskrevet i avtalen - D. |
O-per | ||||
6. Klargjør for katalogmottak – D. | O-per | Bruk brukerveiledning fra din systemleverandør | |||
7. Legg inn puch-out lenke i systemet – O. | O-per | Bruk brukerveiledning fra din systemleverandør | |||
8. Gjør leverandør tilgjengelig for fritekst ordre og test om ordre kommer frem - O. | O-per | Bruk brukerveiledning fra din systemleverandør | |||
9. X.4.2.1 Leverandør og kundeaktivering(EHF katalog prosess) – P. | EHF katalogprosess | ||||
10. X.4.2.1. Leverandør og kundeaktivering (EHF katalog prosess) – P. | EHF katalogprosess | ||||
11. Kontroll på at innhold er i henhold til avtale – O. | O-inn | Sjekk om varer og tjenester i katalog/punch-out er i henhold til avtale | |||
Avslutte avtale | |||||
1. Deaktiver gjeldende katalog, fjern punch-out lenke eller mulighet til å benytte fritekst – O. | O-per | Bruk brukerveiledning fra din systemleverandør og/«Veileder og sjekkliste» | |||
2. Sende melding til leverandør om å sende en katalog med 0 forekomster – O. | O-per | ||||
3. X.4.1.2 EHF katalogprosess - P | EHF katalogprosess | ||||
4. Importere mottatt katalog – O. | O-sys | ||||
5. Kontroller at mottatt katalog har 0 forekomster/varelinjer og slett fra systemet slik at bestiller ikke har tilgang lenger. Og/eller informere om avslutning av ny avtale – D. | O-inn | ||||
15. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei | |||
16. Output og mottaker/bruker
Output | Mottakende prosess: | Mottaker/bruker | Referanse |
Leverandør tilgjengelig i bestillingsløsning | X.4.2.2 Bestille varer og tjenester. | Oppdragsgiver og leverandør. | |
Leverandørs varer og tjenester og/eller leverandør er fjernet fra bestillingsløsningen | X.4.3.3 Avslutte kontrakt | Oppdragsgiver og leverandør. | |
17. Sluttkriterier
Nei
18. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
Nei |
19. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Aktiverer ikke alle leverandører i bestillingsløsning | Høy | Lav |
>Sikre at systemet er tilrettelagt for 100% bruk. |
>Gå gjennom leverandør-reskontro for å identifisere leverandører som ikke er aktivert i bestillingsløsning. |
Dersom katalog ikke blir fjernet er det risiko for at man bestiller på feil avtale. | Lav | Høy | >Følge prosessen. | >Følge prosessen. |
20: Behov for støtte
Prosess navn | Dynamisk innkjøpsordning (DPS) |
Prosess ID |
X.5.1 Dynamisk innkjøpsordning (DPS) https://www.anskaffelser.no/verktoy/veiledere/ehf-prosessoversikt |
Organisasjon | DFØ-ANS |
Prosess eier | Wenche Ludviksen |
Henvendelser | Jan Mærøe |
20. Tilleggsinformasjon
Lenke: https://anskaffelser.no
Lenke: www.anskaffelser.no
21. Vedlegg
Last ned veileder utarbeidet på grunnlag av erfaringer fra slike prosjekter: