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 komptanse, 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

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

ID 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 stanadarder
>Se Post-Award kodeliser
>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

Oppdatert: 13. januar 2023

Kontakt

e-post: 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.