Fra EZD PUW til et system i EZD-klassen: hva sekretæren bør avklare før kommunen velger vei

Innlegget er for sekretærer i kommuner og fylkeskommuner som i dag bruker EZD PUW, samt for skattmestere (skarbnik), fylkesordførere (starosta) og ordførere (wójt): migrering av dokumentflyt er først en organisatorisk og budsjettmessig beslutning, og deretter en teknisk.

Hvilke frister gjelder egentlig

I samtalene om EZD blandes tre forhold av svært ulik vekt.

Planlagt krav fra 1. januar 2028. Digitaliseringsdepartementet skriver om dette «i samsvar med de foreslåtte bestemmelsene»: statlige og kommunale enheter skal arbeide basert på elektroniske dokumentbehandlingssystemer. NASK oppgir samme dato i presentasjonen «Policy for innføring av EZD i Polen» (Polityki wdrażania EZD w RP) av 18. mars 2026, og presiserer uttrykkelig at det gjelder kravet om EZD, «ikke EZD RP». Dette er en varsling, ikke en vedtatt bestemmelse. Det er likevel lurt å legge datoen til grunn i planleggingen og følge med på om den endres.

Endring av arkivloven. Regjeringen (Rada Ministrów) vedtok lovforslaget 28. juli 2026, det kom til Sejmen 30. juli (dokument nr. 3000), og 15. september la komiteene fram sin innstilling. Forslaget gir skannede papirdokumenter samme verdi som originalene, fastsetter krav til systemene og rydder opp i reglene for kassasjon av dokumentasjon. Det skal tre i kraft 12 måneder etter kunngjøring. Forslaget inneholder ikke datoen 1. januar 2028 og innfører i seg selv ikke noe krav om å innføre et system.

Tidsplan for EZD PUW. Ifølge samme NASK-presentasjon: støtte til migrering fra EZD PUW til EZD RP fra 1. kvartal 2028, stans i videreutvikling av EZD PUW i 2. kvartal 2029, avslutning av migreringsstøtten 31. desember 2030, og slutt på servicestøtte for EZD PUW 31. mars 2031. Dette er en tidsplan fra en presentasjon, ikke fra en rettsakt, og kan derfor endres.

Konklusjonen for en kommune som allerede bruker EZD PUW: presset skyldes ikke selve datoen 2028, men at dagens system vil slutte å bli videreutviklet og deretter miste servicestøtte. Det er tid til å forberede seg skikkelig, men ikke tid nok til å utsette kartleggingen.

Hvilke beslutninger ligger hos kommunen

Valg av system. EZD RP stilles til rådighet av NASK vederlagsfritt, enten i skyen eller på kommunens egen infrastruktur. Det planlagte kravet gjelder imidlertid systemklassen, så kommunen kan også velge en annen løsning som oppfyller kravene. Det er lurt å sammenligne minst to alternativer, der man regner total eierkostnad (TCO) og ikke bare lisensprisen.
Omfang av migreringen. Skal alle saker overføres, bare pågående saker, eller starter man med et «rent» system fra nyttår mens det gamle beholdes for innsyn.
Integrasjoner med fagsystemer. Økonomi og regnskap, skatt, registre, e-Doręczenia (polsk e-Delivery), KSeF (det polske e-fakturasystemet) og BIP (offentlig informasjonsportal). Enhver kobling som i dag fungerer med EZD PUW, må gjenskapes, erstattes eller bevisst avvikles.
Arkivdata. Hva skjer med avsluttede saker, hvordan de skal gjøres tilgjengelige, og når og i hvilken form de overføres til virksomhetsarkivet og statsarkivet. Dette er en beslutning der arkivaren må ha en stemme.
Driftsmodell. NASK-sky, en annen skyleverandør eller eget serverrom. Dette avgjør hvem som har ansvar for sikkerhetskopiering, oppdateringer og driftskontinuitet.

For økonomisk oppfølging

«Vederlagsfritt system» betyr ikke vederlagsfri migrering. Budsjettet må ta høyde for integrasjoner med fagsystemer, dataoverføring, opplæring, de ansattes arbeidstid og perioden hvor to systemer kjører parallelt. Disse postene bør vises separat for kommunestyret (rada), med en beskrivelse av hva som skjer dersom de ikke finansieres.

Hva som bør kartlegges før beslutningen fattes

Denne kartleggingen kan kommunen gjøre selv. Den krever tid og tilgang til folk, ikke programmeringskompetanse.

Versjon og driftsmåte for EZD PUW: hvor det er installert, hvem som administrerer det, hvilke tillegg og tilpasninger det har.
Omfang: antall brukere, pågående og avsluttede saker, mengden lagrede filer.
Integrasjoner: hva EZD PUW utveksler data med, hvem som etablerte koblingen, om det finnes dokumentasjon og avtale for den.
Faktisk arbeidsflyt: hvordan skriv og fakturaer faktisk beveger seg gjennom avdelingene, inkludert steder der papir fortsatt sirkulerer ved siden av systemet.
Arkivdokumenter: arkivinstruks (instrukcja kancelaryjna), ensartet saksarkivplan (jednolity rzeczowy wykaz akt), unntak fra elektronisk saksbehandling.
Avtaler og lisenser: frister, oppsigelsestider, rettigheter til data og eksport av disse.
Mennesker: hvem som skal være koordinator, hvem som kjenner dagens system, hvor mye tid avdelingene realistisk kan avsette til opplæring.

Hvordan en slik kartlegging skiller seg fra en vanlig liste over applikasjoner, har jeg beskrevet i innlegget Kartlegging versus applikasjonsliste.

Typiske feil

Dette er situasjoner som går igjen i lignende prosjekter, ikke en beskrivelse av en bestemt kommune.

Overføring av den gamle arbeidsflyten uendret. Migrering er en anledning til å forenkle godkjenningsveiene. Å gjenskape dem uten endringer tar med de gamle problemene inn i det nye systemet.
Integrasjoner utenfor avtalen. Koblinger til fagsystemer dukker opp etter at avtalen er signert, og kommer tilbake som tilleggsavtaler.
Manglende beslutning om arkivdata. Uten en slik beslutning må det gamle systemet driftes på ubestemt tid, fordi ingen vet om det kan slås av.
Et prosjekt som kun er IT-drevet. Arbeidsmåten endres i hver eneste avdeling, men avdelingene får vite om fristene først på opplæringen.
Beslutning under tidspress. En kommune som starter noen måneder før servicestøtten opphører, sammenligner ikke alternativer, men tar det som er tilgjengelig.

Analogi for styret

Migrering av dokumentflytsystemet ligner på å flytte kommunens kontorer til en annen bygning. Man kan frakte alt med seg, inkludert skap som ingen har åpnet på årevis. Eller man kan først ta en opptelling, bestemme hva som skal flyttes og hva som skal til arkivet, og først deretter bestille transport.

Om hvordan man forbereder organisasjonen på innføring, skriver jeg mer utfyllende i innlegget Forberedelse til systeminnføring.

Spørsmål til leverandørene

Disse bør stilles til enhver som tilbyr system, migrering eller innføringsstøtte, også ved EZD RP.

Hvilke data fra EZD PUW blir overført, i hvilken form, og hva blir utelatt?
Hvordan verifiserer vi at ingenting mangler etter migreringen? Hvem signerer protokollen for denne verifiseringen?
Hvilke integrasjoner med våre fagsystemer er inkludert i prisen, og hvilke krever egen kalkyle?
Hvor lenge varer perioden med parallell drift av to systemer, og hvem har ansvar for hva i denne perioden?
I hvilket format og på hvilke vilkår får vi tilbake våre data dersom samarbeidet avsluttes?
Hvem har ansvar for sikkerhetskopiering, oppdateringer og tilpasning til regelverksendringer?
Hvor mange arbeidstimer for våre ansatte forutsetter tidsplanen, fordelt på avdelinger?
Hvor kan vi se en gjennomført innføring hos en enhet av tilsvarende størrelse?

Kilder

Rettstilstand per 4. oktober 2026.