Veileder
EHF Utvikle teknisk veileder
Prosessen beskriver alle aktiviteter som må/kan utføres i utvikling av teknisk veileder/standard format.
Kilde:
DFØ
Prosess Definisjon Dokument (PDD) DFØ ANS
1. Informasjon
| Prosessnavn | EHF Utvikle teknisk veileder |
|---|---|
| Prosess ID | X.6.1.1.2 Utvikle teknisk veileder |
| Organisasjon | DFØ-ANS |
| Prosesseier | Jan Mærøe |
| Henvendelser | Jan Mærøe |
2. Historikk
| 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 | |
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
| 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. | |
11. Deltakere
| 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
| Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
|---|---|---|---|---|
| 1. Gjennomgå eksisterende standarder | >CEN >PEPPOL | |||
| 2. Definere forretningsregler | >Bruk kravmalen som er fylt ut i analysefasen | |||
| 3. Definere datamodell | >Bruk meldingsdokumentet og kravsdokumentet fylt ut i analysefasen | |||
| 4. Velge eller opprette repo på Github | >GitHub | |||
| 5. Benytte eksisterende kodelister eller lage nye kodelister | >ISO standarder >Se Post-Award kodelister >Se Pre-Award kodelister | |||
| 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 | |||
| 7. Lage syntaksbinding mot eksisterende syntaks | >UBL >XML >Riktig namespace >Elementer og attributter >Kodeliste >Regler | |||
| 8. Lage syntaks og syntaksbinding for ikke eksisterende syntaks | >AnsBL >XML >Riktig namespace >Elementer og attributter >Kodeliste >Regler | |||
| 9. Lage og teste regler Schematron | >Forretningsregler >Bruke kravmalen, blir fylt ut i analysefasen. >Teksteditor | |||
| 10. Lage eksempelfil | >Syntaksbindingen >Teksteditor (Atom, …) | |||
| 11. Lage snippets | >Asciidoc - som referanse >Syntaksbindingen - som tagger | |||
| 12. Lage spesifikasjon | ||||
| 13. Skrive introduksjon og bakgrunn for formatet | >Asciidoc >Bruke prosjektbeskrivelsesmalen, blir fylt ut i analysefasen | |||
| 14. Beskrive de viktige aspektene ved formatet (ferdig spesifikasjon) | >Asciidoc >Syntaksbindingen/meldingsmalen fra analysefasen | |||
| 15. Lage usecase | >Asciidoc >Bruk use case malen, blir fylt ut i analysefasen | |||
| 16. Lage rolle og prosessdiagram | >BPMN 2.0 >UML | |||
| 17. Lage change log og releasenote | >Asciidoc: Skriv endringer som har blitt gjort | |||
| 18. Etablere validatorstøtte | >Schematron filer | |||
| 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 | |||
| 20. Sende ut på review | >anskaffelser.dev | |||
| 21. Gjennomgang av høringssvar | >SuperOffice ([email protected]) >GitHub (Issue) | |||
| 22. Implementering av høringssvar | >Oppdatere formatet >Teste endringene | |||
| 23. Sende format ut på offisielt review | >anskaffelser.dev | |||
| 24. Gjennomgang av høringssvar | >SuperOffice ([email protected]) >GitHub (Issue) | |||
| 25. Implementering av høringssvar | >Oppdatere formatet >Teste endringene | |||
| 26. Lage erfaringsnotat | >Dokumentere prosess | |||
| 27. Lage identifikatorer | >Etter retningslinjer fra Peppol | |||
| 28. Søke Peppol om godkjenning av identifikatorer | >Peppol eDelivery | |||
14. Kontrollpunkter og målinger
| Aktivitetsnummer | 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
Oppdatert:
30. april 2026