
Viktigste punkter
Zdjęcia ilustracyjne
Dette innlegget er for distriktssekretærer og distriktshoder (starosta), samt for kemnere, som budsjettet avtales med. Et distriktskontor har sin egenart: mange avdelinger med egne fagsystemer og nasjonale registre, underliggende distriktsenheter, og i loven om det nasjonale cybersikkerhetssystemet (KSC) status som en nøkkelenhet (podmiot kluczowy). Derfor er orden i IT her ikke bare et spørsmål om bekvemmelighet, men også om lovpålagte plikter.
Hvorfor det er vanskeligere i et distriktskontor
Distriktskontoret håndterer saker som bygger på systemer og registre driftet av ulike leverandører og institusjoner: kjøretøyregistrering, geodetiske data, byggesaker, økonomi, personal og arkiv/post. Hver avdeling kjenner sitt eget system, men sjelden er det noen som ser helheten: hvilke systemer utveksler data med hverandre, hvem som eier avtalen, når leverandørens support utløper, og hva som skjer når leverandøren setter opp prisen.
Fra samtaler med distriktskontorer ser jeg flere gjentagende årsaker:
- Kunnskapen er spredt. IT-medarbeideren kjenner infrastrukturen, avdelingene kjenner sine applikasjoner, leverandørene kjenner sine avtaler. Ingen har det fulle bildet.
- De lovpålagte kravene kommer hver for seg, men rammer de samme menneskene. KSC, KSeF, e-Doręczenia, det sentrale avtaleregisteret (CRU) og det varslede kravet om et system i EZD-klassen er i praksis endringer i den samme dokumentflyten.
- IT-avdelingen er liten. To, tre personer driver utstyr, nettverk og den daglige driften av kontoret. De har ikke tid til å lede valget av et stort system.
- Beslutninger tas under tidspress. Da er det ikke lenger tid til å sammenligne tilbud, og distriktskontoret forhandler fra en svakere posisjon.
Steg 1. Kartlegging av systemer og avtaler
Det første steget er ikke å velge et system, men å kartlegge det distriktskontoret allerede har. En god kartlegging svarer på enkle spørsmål: hvilke systemer er i bruk i hver avdeling, hvem eier dem, hvem er avtalen inngått med og hvor lenge gjelder den, hva koster driften, hvilke systemer utveksler data med hverandre, og hvor finnes enkeltpunkter som kan forårsake svikt – altså steder der feil på én komponent eller at én person slutter, stopper arbeidet.
Kartleggingen tar 2–6 uker, ligger under terskelverdien for offentlige anskaffelser og krever ikke tilgang til innbyggernes data. Den munner ut i en ettsides oppsummering til distriktshodet (starosta) og distriktsstyret (Zarząd Powiatu), samt et komplett sett dokumenter som brukes i hvert etterfølgende steg. Detaljer: kartlegging av IT-systemer.
Steg 2. Ettsides plan for lovpålagte krav
På grunnlag av kartleggingen utarbeides én side med krav og frister. For hvert krav angis: hvem som er ansvarlig, hva neste steg er, og innen når.
- System i EZD-klassen. Et varslet krav; ifølge det polske digitaliseringsdepartementets avklaringer fra oktober 2026 er fristen utsatt til tidligst 2029, og regelverket er fortsatt på utkaststadiet. Det er verdt å følge med, siden tidsplanen oppdateres fra tid til annen.
- KSC. Distriktskontoret er en nøkkelenhet (podmiot kluczowy) i henhold til loven om det nasjonale cybersikkerhetssystemet (KSC); enkelte krav har egne frister. Hvor man bør starte, beskriver jeg i innlegget KSC-loven i distriktskontoret.
- KSeF og e-Doręczenia. Endrer flyten av fakturaer og korrespondanse, og berører dermed de samme prosessene som systemet i EZD-klassen.
- Det sentrale avtaleregisteret (CRU). Krever kunnskap om avtaler, som uansett samles inn gjennom kartleggingen; jeg beskriver fremgangsmåten steg for steg i innlegget Det sentrale avtaleregisteret.
Planen for lovpålagte krav fungerer som en rehabiliteringsplan for en bygning som er i daglig bruk. Det er ikke mulig å skifte ut installasjonene i hvert rom hver for seg og uavhengig av hverandre. Man må vite hva som går gjennom hvilke vegger, og legge opp arbeidet slik at kontoret fungerer hele tiden.
Steg 3. Budsjettet som holder mål overfor distriktsrådet
Et IT-budsjett som én enkelt post er vanskelig å forsvare. Det er lettere når det deles inn i lovpålagt krav (det som må gjøres i henhold til regelverket) og investering (det distriktskontoret gjør for å arbeide mer effektivt), med kostnaden ved å la være ved siden av: hva som skjer dersom man ikke gjør noe. Budsjettforslaget utarbeides om høsten, så det er det beste tidspunktet å forberede en slik inndeling på. Mer i innlegget IT-budsjettet foran distriktsrådet.
Steg 4. Digitaliseringsansvarlig uten ny stilling
Ethvert stort prosjekt trenger en ansvarlig: en person som følger med på helheten, fristene og beslutningene. I et distriktskontor uten IT-direktør er det vanligvis sekretæren, selv om vedkommende sjelden har tid og erfaring med å velge store systemer. I stedet for å opprette en stilling, kan dette støttes med en ekstern rådgiver i redusert stilling: noen som hver uke eller hver måned setter seg sammen med sekretæren og IT-lederen, fører register over prosjekter og risikoer, bistår i samtaler med leverandører og vurderer forslagene deres uavhengig. Beslutningene forblir hos distriktskontoret.
IT-lederen er i denne sammenhengen en alliert, ikke et tilsynsobjekt. Registeret over systemer og budsjettfordelingen er de beste argumentene for ressursene som IT-medarbeideren vanligvis har bedt om lenge.
Eksempel fra praksis
Jeg har sett den samme mekanismen i en stor JST (den polske fellesbetegnelsen for kommunale og fylkeskommunale enheter), der partneren på etatens side var lederen for IT-avdelingen. Etaten vokste stadig med nye, usammenhengende applikasjoner som skulle støtte arbeidet i ulike enheter. Vi startet med en grunnleggende kartlegging av behov og eksisterende systemer. På dette grunnlaget ble det utarbeidet et kart over tiltak som skulle optimalisere kostnadene i kommende prosjekter, og deretter et grunnlag for en applikasjonsstrategi, omsatt i teknologiske krav: optimal total eierkostnad (TCO), redusert risiko for vendor lock-in, og en plan for å overføre kunnskap fra leverandørene til det interne IT-teamet.
Etaten innførte standarder for prosessmodellering, kunnskapsoverføring mellom leverandører og dokumentasjon av krav og systemarkitektur, og la en applikasjonsstrategi for de neste ti årene. Det mest overraskende var følgende: organisatoriske enheter som hadde egne budsjetter og fullmakter, drev parallelt sine egne IT-initiativer. De bygde ut siloer og økte driftskostnadene, selv om alt fra starten av kunne vært gjennomført innenfor én samlet strategi. Uten kartleggingen ville ingen ha sett dette.



