X.6.1.1.2 EHF Utvikle teknisk veileder

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

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

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
  • Ledelsen må forsikre seg om at de som utfører prosessen har den nødvendige kompetanse, følger prosessen og bidrar med forbedringsforslag. 

​​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

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

Prosess X5112

Prosessdiagram i Excel:

X611 Utvikle og forvalte EHF alle prosesser
xlsx 289.17 KB

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

IDAktiviteter i prosesskartAnsvarBeskrivelseKP (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 (ehf@dfo.no)
>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 (ehf@dfo.no)
>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

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

X5112 Gantdiagram1
Oppdatert: 13. januar 2023

Kontakt

  • ehf [at] dfo.no (ehf[at]dfo[dot]no)

Fant du det du lette etter?

Nei

Det beklager vi!

Tilbakemeldingen din er anonym og vil ikke bli besvart. Vi bruker den til å forbedre nettsidene. Hvis du vil ha svar fra oss, ta kontakt på telefon, e-post eller kundesenter på nett.