Kommuner drukner i Word-skabeloner

Inden Aabenraa Kommune besluttede sig for at skabe orden i sit skabelon-kaos, havde man i kommunen 8.000 skabeloner, der skulle opdateres jævnligt. Én ad gangen.

Mens nogle kommuner for flere år siden begyndte at skære ned på antallet af skabeloner, som anvendes til at svare borgerne med, bakser flere kommuner stadig med at nedbringe antallet af skabeloner. I Aabenraa Kommune er man gået fra 8.000 unikke skabeloner til 6, mens man i Aalborg Kommune har bragt det totale antal skabeloner og blanketter ned til godt 850 fordelt over de forskellige forvaltninger.

Skabeloner - som ofte er i Word-format - anvendes til intern kommunikation i kommunen og kommunikation mellem institutioner, kommune og borgere. For eksempel ved afgørelse af ansøgning om byggetilladelse, tildeling af institutionspladser og så fremdeles.

Især de kommuner, der er resultatet af sammenlægningerne tilbage i 2007, har oplevet problemet med mange skabeloner:

»Vi er lidt som en sammenbragt familie, hvor vi hver især havde hver vores skrammel med,« siger it- og digitaliseringschef i Aabenraa Kommune Eva Minke Andersen.

Hun fortæller, hvordan kommunens medarbejdere førhen måtte rette Word-dokument efter Word-dokument, hver gang der kom en ny bekendtgørelse, eller der skete en navneændring, der krævede en ændring af en eller flere af de i alt 8.000 skabeloner.

Kender du noget til skabelon-rod i kommunerne? Du kan tippe os her.

Opdateres manuelt en ad gangen

Selvom man i Aalborg Kommune er begyndt at skære ned på antallet af skabeloner og blanketter, kommer det bag på it-chef i Familie- og Beskæftigelsesforvaltningen Johnny Vad, at kommunen stadig har 850 skabeloner og blanketter. Skabeloner skal opdateres en ad gangen, når der sker ændringer på det område, skabelonen drejer sig om.

Johnny Vad fortæller, at det i Aalborg Kommune er forskelligt, hvem der opdaterer skabelonerne. I hans forvaltning er det en enkelt person, der har ansvaret, og han fortæller, at Kommunernes Landsforening har en skabelonbank, man kan abonnere på. På den måde får man en notifikation, hver gang der bør ske en ændring i en skabelon.

I Aabenraa var det et stort arbejde at opdatere skabelonerne.

»Hver gang en institution eller forvaltning skiftede navn eller logo, eller hvis der kom en ny bekendtgørelse, skulle vi ind manuelt og rette i den pågældende skabelon,« siger Eva Minke Andersen, der er glad for, at man i Aabenraa ikke længere har 8.000 unikke skabeloner.

Fra 8.000 til 6 skabeloner over tre år

I Aabenraa Kommune begyndte man allerede oprydningen for tre år siden. Dengang blev kommunen præsenteret for en løsning, der kunne reducere antallet af skabeloner til en god håndfuld.

»Det var en øjenåbner, og jeg vil klart anbefale andre kommuner at få kigget på antallet af skabeloner med henblik på at reducere det,« siger ESDH-koordinator i Aabenraa Kommune Gertrud Fink. Løsningen, kommunen blev præsenteret for, leveres af Dania Software og koster kommunen omkring 50.000 kroner om året.

I stedet for 8.000 individuelle skabeloner har Aabenraa Kommune nu 6 basisskabeloner, som automatisk importerer information om borgeren. Herefter indsættes de standardfraser, brevet skal indeholde.

»Det har været en lang implementeringsproces, som stadig er i gang, men systemet fungerer godt, og det er blevet nemmere at følge de retningslinjer, der er sat op for, hvordan kommuners skabeloner skal se ud,« siger Eva Minke Andersen, der også fortæller, at der sker færre fejl efter implementeringen af Dynamic Template, som løsningen hedder.

Redaktionen er efterfølgende blevet bekendt med, at 850 er antallet af skabeloner og blanketter i Aalborg tilsammen

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Jensen

Ja, Word er nemt at bruge for den almindelige bruger, det er WYSIWYG, hvad du ser på skærm kommer ud på papir.
Ulempen med Word er dog at det er svært at sikre ensartet layout i en lang række dokumenter da alt gemmes i Word dokumentet, og det er en stor opgave at opdatere når der sker ændring af logo eller navn.

Et nemt og ganske gratis alternativ kan være brug af typesetting,. HTML formularer eller LaTeX.
Du indskriver noget tekst, og mediet der præsenterer tekst har til opgave at sikre layout, layout kan så styres ved links til fælles elementer der styrer format.
Men sådan et alternativ passer sikkert ikke ind i det offentlige hvor Windows sikkert er standard, og penge ikke er noget problem.

  • 11
  • 0
Esben Nielsen

Man kan faktisk også autogenere ooxml ud fra data...

Pointen er netop at afkoble layout fra data, så data (rå tekst) kan tilgås fra andre kilder.

Brugen "dokumenter" som enhed for data er rigtig dårligt, da det gør det rigtigt svært senere at strukturere data.

Et godt eksempel er brugen af Doors til kravsstyring frem for word-dokumenter: Ved at tage tekstfelterne over i en DB, kan man pludselig automatisere en masse ting - og autogenere dokumenter til sidst.

  • 5
  • 0
Frithiof Andreas Jensen

Men sådan et alternativ passer sikkert ikke ind i det offentlige hvor Windows sikkert er standard, og penge ikke er noget problem.


Jaja, Kom tilbage efter at du har lärt en sekretär - eller din gamle mor - at bruge LaTeX!

De fleste Office-anvendere kan knapt finde ud af at bruge Word "Style-sheets" og nu skal de läre at debugge, compile, lede efter manglende tegnsätning mange, mange, linier (eller filer) väk fra den obskure fejlmeddelelse ....

Jeg har engang fået det til at fungere at brugerne placerer ting i en database, hvorefter et program genererer en fint formateret rapport via LaTeX.

Men. Det er egentligt det samme problem: Nogen skal programmere hvordan dokumentet skal se ud og nogen skal löbende opdatere formaterne og koden.

  • 4
  • 0
Lars Lundin

Jaja, Kom tilbage efter at du har lärt en sekretär - eller din gamle mor - at bruge LaTeX!

Da jeg studerede på DTH for mange år siden anvendte sekretærerne LaTeX. Rent teknisk er der ikke noget i vejen for at de anvender de samme skabeloner idag.

Forresten så finder jeg den implicitte sammenligning af en sekretær med en gammel mor (hvad det så end præcis måtte være) upassende.

  • 1
  • 0
Mads Lorenzen Journalist

Efter henvendelse fra Dania Software er tallet i artiklen ændret til omkring 50.000, idet Aabenraa ifølge Dania Software ikke skulle have talt alle ydelserne med. Dania Software påpeger ligeledes, at selvom der er tale om en fordobling, er det et yderst beskedent beløb for en virksomhed på størrelse med en kommune.

  • 1
  • 0
Morten Winther

De fleste sagsbehandlere i en kommune burde slet ikke bruge Word og kommuner kunne spare mange penge på licenser ved at tænke automatisk dokumentgenerering ind i deres fagsystemer.

Flere og flere systemer bliver webbaseret og da sagsbehandleren ofte blot retter til i en skabelon, kunne det med fordel erstattes af form felter eller web-editors som ckeditor. Fagsystemer kan derefter generere en PDF som smides til Digital Post og ESDH.

  • 8
  • 0
Henrik Mikael Kristensen

Det tror jeg ikke er noget større problem, hvis man har én LaTeX ekspert pr. kommune til at debugge style sheets, og så burde det jo være enkelt nok at kværne dokumenter ud med tiden uden at brugeren skal tænke alt for meget over det. Det tager måske et års tid at få det på plads.

Desuden er der jo meget visuelle LaTeX editorer idag, så brugeren ikke føler sig helt hensat til en gammeldags tekstkonsol.

Men måske er det "styrken" i Word, at man får et sandt WYSIWYG miljø, hvor man nærmest impromptu kan skrive et pænt formateret dokument til en klient, og umiddelbart se resultatet. Det er meget sjovt, men det skalerer ad helvede til, når du skal skrive breve til 100 klienter om dagen, og det er meget kostbart at gøre til et søgbart arkiv, for Word formatet er fuldstændig udueligt til den slags.

Det er i så fald et af de IT abstraktioner der går helt hen over hovedet på almindelige brugere, politikere og whatnot: At den tekst du indskriver ikke nødvendigvis behøver at ligne det du får ud, og at der er administrativ værdi i at optimere dit tekstredigeringsprogram til meget effektiv indskrivning og efterfølgende kompilering og arkivering i stedet for at se pænt ud.

Kunne folk forstå det, slap vi nok for at død og pine hænge fast i Word, og kunne spare nogle gode millioner indenfor offentlig IT.

  • 4
  • 0
Torben Jensen

Nu kender jeg ikke typen af alle disse dokumenter der skrives i kommunen.
Men generelt set må der været tale om et fælles layout og en række templates med standard tekst i en form hvor modtager adresse og lidt andre data skal sættes ind efter behov.

Man kunne forestille sig en web baseret løsning, hvor brugeren kan vælge mellem en række formularer, indtaste de variable værdier, trykke på en knap, og bagved er der så noget LaTeX eller PDF kode der danner et nydeligt PDF dokument som output.
Dermed skjules generering for bruger, og layout kan styres centralt.

Hvad angår LaTeX findes der web baserede cross platform løsninger, f.eks. https://www.sharelatex.com/

  • 0
  • 0
Henrik Mikael Kristensen

Hvilke(n) Windows eller cross platform editor vil du/folk anbefale?

Der er f.eks LyX og BaKoMa.

Men egentligt vil jeg ikke anbefale en specifik løsning, for fidusen er også, at du kan i meget større omfang tilbyde en custom brugerflade eller editor til udfyldning af tekster, der så kan generere et LaTeX dokument vha. noget scripting. Så kan man også bygge det visuelle op, så det giver mere mening i forbindelse med indtastningen fremfor at binde sig til layoutet i det færdige dokument, som man gør i de håbløse Adobe PDF formularer, som kommunerne en overgang brugte (eller gør de stadig?).

  • 1
  • 0
Jesper Lund Stocholm

Brugen "dokumenter" som enhed for data er rigtig dårligt, da det gør det rigtigt svært senere at strukturere data.


Word (OOXML) giver mulighed for ren adskillelse imellem layout og data. Jeg har igennem den seneste tid lavet præcist sådan et system, der danner dokumenter til bla. rapporteringsformål. Konkret danner det Word-filer og PowerPoint-præsentationer af data fra en ekstern kilde (beliggende i skyen, btw). Alle data fra LOB-systemer gemmes i en xml-klump inde i Word-dokumentet, og Word sørger så for at flette disse ind i dokumentet, når det åbnes.

Der er masser af situationer, hvor brugen af Word kunne erstattes af PDF eller lignende, men det er noget vrøvl at sige, at "hvis man bruger Word, så kan man ikke adskille data fra layout".

  • 2
  • 0
Peter Stricker

det er noget vrøvl at sige, at "hvis man bruger Word, så kan man ikke adskille data fra layout".


Jeg synes ikke rigtig, at dit eksempel modsiger den citerede påstand. Det lyder som om, du har lavet et system, der genererer Word filer ud fra data, der stammer fra en ekstern kilde. Hvis det er korrekt forstået, så bruges Word blot som præsentationsapplikation, og ikke som dokumentgenereringsværktøj. Og det er tydeligvis brugen af Word som generator, der er ment i det citerede.

  • 1
  • 0
Jesper Lund Stocholm

Jeg synes ikke rigtig, at dit eksempel modsiger den citerede påstand. Det lyder som om, du har lavet et system, der genererer Word filer ud fra data, der stammer fra en ekstern kilde. Hvis det er korrekt forstået, så bruges Word blot som præsentationsapplikation, og ikke som dokumentgenereringsværktøj.


Mjaeh - systemet danner ikke Word-filer. Det kunne det sådan set godt gøre, men det er ret komplekst.

Systemet anvender en række DOCX-templates, hvori der ligger en klump xml. I selve Word-dokumentet er defineret en række "placeholders" (content controls), der hver især er mappet til data i xml klumpen.

Når dokumentet indlæses, så vil Word løbe disse "placeholders" igennem, identificere data i xml-strukturen og vise disse data på de angivne steder.

Så Word er ikke "kun" en præsentationsmekanisme. Man sige, at hvis man skulle tegne arkitekturen bag det, så ville det ligne MVC eller MVVM ret meget, hvor Word så ville være "View"-komponenten, der arbejder på et "View" eller en "ViewModel", der er genereret af en controller (den del af systemet, der henter LOB-data og skriver xml-filen inde i dokumentet.

Hvis jeg tager linien inden det jeg citerede med, så står der:

Pointen er netop at afkoble layout fra data, så data (rå tekst) kan tilgås fra andre kilder.

Brugen "dokumenter" som enhed for data er rigtig dårligt, da det gør det rigtigt svært senere at strukturere data.


Min pointe er stadig, at det er noget vrøvl at sige, at hvis man bruger Word, så kan man ikke adskille data fra layout. Bruger man DOCX som vi/jeg har gjort ovenfor, så er det endda også muligt at søge på tværs af dokumenter efter de strukturede data i xml.

(og så kan der jo være tusinde grunde til, at Word er et dårligt program at bruge i det hele taget - men adskillelsen imellem data og layout er ikke én af dem).

  • 1
  • 0
Peter Stricker

Min pointe er stadig, at det er noget vrøvl at sige, at hvis man bruger Word, så kan man ikke adskille data fra layout.


Men bruger du i det hele taget Word i den beskrevne løsning? Som jeg læser det, så bruger du netop ikke Word, når du genererer OOXML-dokumenterne. Slutbrugeren kan bruge Word til at læse dokumenterne, men der er vel ikke noget til hinder for at transformere dokumentet til pdf, og så bruge Adobe Reader til at læse dokumentet i? Med mindre en efterfølgende redigering af dokumentet i Word garanterer, at separationen mellem data og layout bevares.

Din beskrivelse har endnu ikke overbevist mig om, at Word sørger for adskillelsen af data og layout. Derimod lyder dit system til at være meget lig det Torben og Henrik foreslår - bortset fra, at outputtet er OOXML i stedet for LaTeX.

  • 0
  • 1
Jesper Lund Stocholm

Men bruger du i det hele taget Word i den beskrevne løsning? Som jeg læser det, så bruger du netop ikke Word, når du genererer OOXML-dokumenterne.


Det er korrekt.

Slutbrugeren kan bruge Word til at læse dokumenterne, men der er vel ikke noget til hinder for at transformere dokumentet til pdf, og så bruge Adobe Reader til at læse dokumentet i?


Der er ikke noget teknisk argument for ikke at gøre dette, men der er nogle forretningsmæssige krav til, at det ikke er en løsning. Dokumenterne vi danner (både DOCX-dokumenter og PPTX-præsentationer) indgår "med det samme" i en redigeringsproces i forretningen, og PDF er ikke voldsomt velvalgt til dette.

Med mindre en efterfølgende redigering af dokumentet i Word garanterer, at separationen mellem data og layout bevares.


Definér lige "garanterer" :-)

Men en umiddelbar redigering af dokumentet ændrer ikke på adskillelsen af data of layout (med det forbehold, at alt naturligvis kan smadres af de rigtige personer)

Derimod lyder dit system til at være meget lig det Torben og Henrik foreslår - bortset fra, at outputtet er OOXML i stedet for LaTeX.


Mjaeh - én af fordelene ved at bruge et program som forretningen kender er jo, at vi kan sætte ikke-teknikere i forretningen til at danne skabelonerne for os, og så kan vi teknikere blot flette data ind bagefter.

Henrik snakker om en custom brugerflade til indtastning af tekster, men det vil jeg ikke umiddelbart vurdere er muligt for os at lave. Det er ret komplekse skabeloner med tekst, billeder, tabeller, illustrationer dannet på baggrund af LOB-data etc flettet med data fra LOB-systemerne, så arbejdet med at danne denne UI synes ikke på nogen måde at være simpel - og jeg kan ikke se den umiddelbare værdiskabning ifht vores eksisterende løsning.

Jeg siger ikke på nogen måde, at man ikke kan lave vores system på en anden måde - jeg opponerede udelukkende på, at brug af OOXML skulle betyde, at adskillelsen imellem data og layout forsvandt.

  • 1
  • 0
Peter Stricker

Men en umiddelbar redigering af dokumentet ændrer ikke på adskillelsen af data of layout


Okay, nu er du for alvor ved at have mig overbevist. Det lyder som et rigtig godt system, hvis det stadig er muligt, at hive rå data ud at OOXML-dokumentet efter redigering.

Dokumenterne vi danner (både DOCX-dokumenter og PPTX-præsentationer) indgår "med det samme" i en redigeringsproces i forretningen


(Undskyld den ændrede rækkefølge i det citerede)

Såfremt separationen bevares under denne redigering, så lyder det også som en okay løsning. Indgår data fra de redigerede dokumenter efterfølgende i jeres datagrundlag?

PDF er ikke voldsomt velvalgt til dette.


Jeg kan kun være enig.

jeg opponerede udelukkende på, at brug af OOXML skulle betyde, at adskillelsen imellem data og layout forsvandt.


Nej, du opponerede mod kritikken af brugen af Word, ikke OOXML. Der er en meget stor forskel.

  • 1
  • 0
Jesper Lund Stocholm

Okay, nu er du for alvor ved at have mig overbevist. Det lyder som et rigtig godt system, hvis det stadig er muligt, at hive rå data ud at OOXML-dokumentet efter redigering.


Det er det.

Såfremt separationen bevares under denne redigering, så lyder det også som en okay løsning. Indgår data fra de redigerede dokumenter efterfølgende i jeres datagrundlag?


Ikke på nuværende tidspunkt. Men seperationen er intakt.

Nej, du opponerede mod kritikken af brugen af Word, ikke OOXML. Der er en meget stor forskel.


Korrekt. Men argumentet er det samme. Brugen af Word har ikke som uafværgelig konsekvens, at seperationen imellem data og layout fjernes. Hvis man bruger Word korrekt (og dermed OOXML), så kan denne uden de store sværdslag opretholdes.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize