GIS-Byggesag. MTM GeoInformatik Institut for Samfundsudvikling og Planlægning Fibigerstræde 11, 9220 Aalborg Øst, Tlf

Transkript

1 GIS-Byggesag MTM GeoInformatik Institut for Samfundsudvikling og Planlægning Fibigerstræde 11, 9220 Aalborg Øst, Tlf Titel: GIS-Byggesag (MTM GeoInformatik 2. års projekt) Projektperiode: 1. september maj 2003 Projektgruppe: 1 Gruppemedlemmer: Steen Muchitsch Søren Breddam Ole Dittmer Andersen Vejleder: Bent Hulegaard Jensen Oplagstal: 6 stk (trykte) Sider: 115 Appendiks: 2 stk Bilag: 6 stk, heraf 2 CD. Synopsis: Med udgangspunkt i formålet for MTM GeoInformatiks 2. studieår Udvikling af digitalt geografisk informationsteknologi har projektgruppen arbejdet ud fra problemformuleringen: Hvorfor anvendes GIS ikke i højere grad som et integreret værktøj i forbindelse med byggesagsbehandling? Derpå gennemføres en vidensproduktionsproces som involverer en introduktion til byggesagsbehandling, beskrivelse af det relevante datagrundlag, gennemgang af aktuelle tiltag fra Den Digitale Taskforce, Servicefællesskabet for Geodata, Kommunedata og Kommunernes Landsforening, samt interviews med byggesagsbehandlere. På dette grundlag opbygges en GIS-applikation kaldet GIS-Byggesag som håndterer såvel gennemgang af data for rådighedsindskrænkninger som styringen af byggesager. Ud fra vurdering og aftestning konkluderes det, at GIS-Byggesag, udviklet i nært samarbejde med kommunale byggesagsbehandlere, kan løse opgaven med at bringe GIS ind i en central rolle ved byggesagsbehandlingen. Afslutningsvis beskrives perspektiverne for den fremtidige byggesagsbehandling med udgangspunkt i den beskrevne løsning og andre aktuelle tiltag på området. Rapporten eller dele heraf må ikke gengives uden projektgruppens tilladelse

2 GIS-Byggesag English Summary On basis of the intention of the Master of Technology Management Geo Informatics second year Development of digital geographic information technology we wonder: Why is it that GIS is not used as an integrated tool in planning? To establish a working platform we perform a knowledge production process which involves an introduction to planning, description of relevant data, Danish Government initiatives such as projects from The Digital Taskforce, projects from The Danish Association of Municipalities and interviews with planning officers. Using an Interative Software Development process, a GIS-software application - GIS- Byggesag is built. GIS-Byggesag deals with data-analysis and planning administration. From evaluating and testing the software application we conclude that GIS-Byggesag, developed in close co-operation with planning officers solves the task of bringing GIS into a central role in planning. Finally we view the perspectives of future planning and planning administration on the basis of our software application and other projects dealing with the same subject

3 GIS-Byggesag Forord Denne rapport er udarbejdet som 2. års projekt på MTM GeoInformatik Studiet ved Aalborg Universitet, foråret Vi takker byggesagsbehandlerne i Stevns, Køge og Nykøbing Falster Kommuner for deres hjælp dels med at give os et grundlæggende kendskab til en byggesagsbehandlers dagligdag og dels med sparring i forbindelse med applikationsudviklingen. Endvidere takker vi Per Andersen (KMD), Winn Nielsen (Den Digitale Taskforce), Philip Parslov (Businessminds) og Sten Høxbroe (KMD) for deres bidrag. Kildehenvisninger er angivet som [1], hvor nummeret henviser til kildelisten bagerst i rapporten. Kort i denne rapport er gengivet med Copyright Kort- og Matrikelstyrelsens tilladelse nr. G Endvidere er gengivet data med tilladelse fra Storstrøms Amt samt Stevns og Nykøbing Falster Kommuner. Køge den 27. maj 2003 Steen Muchitsch Søren Breddam Ole Dittmer Andersen - 3 -

4 GIS-Byggesag Indholdsfortegnelse English Summary...2 Forord Indledning Læsevejledning Problemformulering Hovedproblem Delproblemer Valg og fravalg - projektafgrænsning Udvælgelse/Projektafgrænsning: Metodebeskrivelse Opdeling i delmetoder Vidensproduktionsprocessen Applikationsudviklingsmetoden Sien Samspillet vores metode Introduktion til byggesagsbehandling Lovgrundlag Anvendelsesområde Bygningsreglement for småhuse af Bygningsreglement af Dispensation, nabohøring m.v Tilsynspligt, lovliggørelse BGS Data i byggesagsbehandlingen - Rådighedsindskrænkninger Omfanget af data Plantemaer Naturbeskyttelsesloven Andre Samlet vurdering af datagrundlaget Aktuelle tiltag omkring Byggesagsbehandlingen Den Digitale Taskforce

5 GIS-Byggesag Indholdsfortegnelse 6.2 Servicefællesskabet for Geodata Kommunernes Landsforening / Kommunalteknisk Chefforening Kommunedata Regional E-dag i Nordjyllands Amt Strukturkommissionen Kommentarer til de aktuelle tiltag Barrierer for GIS i Byggesagsbehandlingen Barrierer Prioritering af Barrierer Sining af barrierer Resultater fordelt på kategorier Opsummering hvad kan vi løse? Systemudvikling Forslag Testimplementering i Nykøbing F. Kommune Testimplementering i Køge Kommune Endelig implementering Konklusion Vurdering af applikationen Vurdering af de imødegåede barrierer Vurdering af metodevalg Perspektivering Hvad med borgeren ansøgeren? Datagrundlaget Sagsdokumentation og -styring XML og WMS Fremtidig byggesagsbehandling i lyset af strukturkommissionens arbejde Kildeliste Kildekritik Opdeling Kilder i vidensproduktionsprocessen

6 GIS-Byggesag Indholdsfortegnelse 12.3 Kilder i metodeafsnittene Appendiks Bilag

7 GIS-Byggesag Indledning 1. Indledning Dette er en afrapportering af det afsluttende 2.årsprojekt på MTM Geoinformatik på Aalborg Universitet. Det er samtidigt en fortsættelse af den forundersøgelse projektgruppen gennemførte på første år af MTM Geoinformatik Her var emnet mere bredt defineret som Barrierer for GIS udbredelse i danske kommuner. I projektet konstrueredes et redskab til systematisk kategorisering af barrierer. Formålet med dette redskab var at gøre det muligt at bearbejde samlinger af barrierer barrierekategorier i stedet for at bearbejde barriererne enkeltvis. Med dette projekt er vi gået skridtet videre og har bragt redskabet, som fik betegnelsen sien, i anvendelse på en helt konkret opgave. Hermed har vi rettet fokus mod formålet for MTM-projektet på 2. studieår, som skal omfatte Udvikling af digitalt geografisk informationsteknologi. [27] Dette projekt giver dermed et bud på, hvordan sien kan indgå i et udviklingsforløb for en GIS-applikation. Nærværende projektrapport dokumenterer det forløb, vi har gennemgået i udviklingsarbejdet med en GIS-applikation til byggesagsbehandling. Applikationen er benævnt GIS-Byggesag. Applikationen er vedlagt på cd [Bilag 5] i udgaven af rapporten, der afleveres til bedømmelse på Aalborg Universitet. Øvrige læsere kan hente applikation og data fra Læsevejledning I det næste afsnit følger dels en gennemgang af projektrapportens indhold og dels tre forslag til, hvordan rapporten kan læses alt efter hvilke oplysninger, der ønskes uddraget Gennemgang af rapportens afsnit. Projektrapporten indledes med en problemformulering (Kapitel 2), hvor vi udover at præsentere vores tese med tilhørende hovedproblem og endvidere beskriver en række tilgrænsende problemstillinger. På den måde skabes et fundament til forståelse af, hvad byggesagsbehandling er i 2003, og hvilke elementer der påvirker sagsgangen. Problemformuleringen munder ud i en afgrænsning af projektet. Derpå følger en metodebeskrivelse (Kapitel 3), hvori der redegøres for de metodikker, der er anvendt i projektet. De tre følgende hovedafsnit (Kapitel 4, 5 og 6) danner sammen med mødereferater [Bilag 2] et billede af byggesagsbehandlingen, som den foregår i dag, og de indeholder endvidere bud på den nærmeste fremtids udviklingstendenser. Vi ønsker på denne måde at redegøre for grundlaget for byggesagsbehandling og de umiddelbare behov, der kan knyttes til. Det sker ved at introducere rammerne for byggesagsbehandling i Kapitel 4 sammen med en præsentation af det mest anvendte sagsstyringssystem for byggesager. Herefter følger en gennemgang af de data, der indgår i den del af byggesagsbehandlingen (Kapitel 5), som omfatter rådighedsindskrænkningerne. Hvor findes data, på hvilken form og med hvilken kvalitet? - 7 -

8 GIS-Byggesag Indledning Fra interviews med byggesagsbehandlere i tre kommuner [Bilag 2] søger vi at skabe et indblik i en byggesagsbehandlers dagligdag, og med afsnittet om aktuelle tiltag omkring byggesagsbehandlingen (Kapitel 6) ser vi på, hvorfra der er forskellige bud på forandringer i arbejdsprocesserne. Det leder frem til en opstilling af barrierer for GIS i byggesagsbehandlingen med efterfølgende prioritering af barriererne (Kapitel 7). Herefter anvendes sien til systematisk kategorisering af barriererne. De opnåede kategorier vurderes i forhold til såvel målepunkternes indflydelse som barrierernes prioriteringer. Ud fra denne vurdering vælges en række barrierer/barrierekategorier, som vi vælger at fokusere på, og som danner input til udviklingen af en GIS-applikation til byggesagsbehandling. Den gennemførte systemudvikling i Stevns Kommune beskrives på baggrund af den udvalgte metode (Kapitel 8). Tilsvarende indsamles erfaringer fra implementering i Køge og Nykøbing F. Kommuner. Jævnfør metodevalget fører dette frem til den endelige kravspecifikation/systemdokumentation. Konklusionen (Kapitel 9) indeholder en række delpunkter. Vi vurderer den udviklede applikation på flere måder. Dels gennem indhøstede brugererfaringer og dels gennem egen aftestning af funktionalitet. Dernæst vurderes, hvorvidt de udvalgte barrierer/barrierekategorier rent faktisk imødegås af applikationen. Endvidere vurderes den anvendte arbejdsmetode dels som arbejdsproces og dels i forhold til de opnåede resultater. Afslutningsvis sætter vi de samlede erfaringer fra projektet ind i et perspektiv for fremtidig byggesagsbehandling (Kapitel 10). Projektrapporten indeholder kildekritik, (Kapitel 11) og kildeliste (Kapitel 12) samt appendiks (Kapitel 13) og bilagsliste (Kapitel 14). Appendiks A indeholder Brugermanual til GIS-Byggesag, samt en implementeringsvejledning. Appendiks B indeholder den endelige kravspecifikation/systemdokumentation for GIS- Byggesag Det samlede projekt, inklusive links til relevante kilder på Internettet, findes på hvorfra den fremtidige udvikling af GIS-Byggesag også kan følges Læsevejledning for en byggesagsbehandler. Hvis du som byggesagsbehandler ønsker en hurtig oversigt over, hvad den udviklede applikation (GIS-Byggesag) består af, og hvordan (og om) du kan anvende den i dit daglige arbejde, vil vi foreslå at læse følgende afsnit i den angivne rækkefølge. Start med Appendiks A Brugervejledning (undlad f.eks. at læse implementeringsafsnittet) for at se hvad GIS-Byggesag består af. Installér evt. GIS-Byggesag samt eksempeldata fra CD en for at afprøve funktionaliteten, samtidig med at manualen gennemgås. For at se hvilke krav der er stillet undervejs i udviklingsprocessen kan Appendiks B Kravspecifikation med fordel læses. Det kan passende suppleres med læsning af Afsnit 7 Barrierer for GIS i byggesagsbehandlingen

9 GIS-Byggesag Indledning Afslutningsvis findes i Afsnit 9 Konklusion et samlet overblik over de første erfaringer ved brugen af GIS-Byggesag, samt bud på de næste udviklingstrin. Figur 1.1 Læsevejledning for byggesagsbehandler Læsevejledning for en chef (for byggesagsafdelingen eller evt. teknisk forvaltning) Hvis du som chef for byggesagsbehandlere ønsker at få overblik over, hvad der rører sig på området, vil vi foreslå at læse følgende afsnit i den angivne rækkefølge. Start med Afsnit 6 Aktuelle tiltag omkring byggesagsbehandling for at få beskrevet de initiativer der er i gang i forskelligt regi. Gå derefter videre med Afsnit 7 Barrierer for GIS i byggesagsbehandlingen for at få indblik i, hvad der kan være årsagerne til at GIS ikke for længst er blevet en integreret del af byggesagsbehandlingen i Danmark. Slut af med at få vores bud på fremtidens byggesagsbehandling i Afsnit 10 Perspektivering og læs evt. også Afsnit 9 Konklusion for at få et samlet overblik over de første erfaringer ved brug af GIS-Byggesag. Figur 1.2. Læsevejledning for chef Læsevejledning for en GIS-koordinator Hvis du som kommunens GIS-koordinator gerne vil have klarhed over hvordan GIS- Byggesag implementeres, og hvilke data der kan indgå i løsningen, vil vi foreslå at læse følgende afsnit i den angivne rækkefølge Start med Appendiks A Brugervejledning (specielt implementeringsafsnittet) for at få et overblik over, hvad der skal til for at implementere applikationen. Installér evt. GIS- Byggesag samt eksempeldata fra CD en for at se datastrukturen i MapInfo-tabellerne sammen med vejledningen

10 GIS-Byggesag Indledning Læs derpå Afsnit 5 Data i Byggesagsbehandlingen for at få listet alle de data der indgår i behandling af rådighedsindskrænkningerne. Sammenholdt med datastrukturen bør det kunne give en god forståelse for opbygningen på datasiden. For at høste lidt erfaringer fra dataklargøring/testimplementering i et par kommuner kan man med fordel læse Afsnit 8 Systemudvikling/udviklingsdialog (Specielt afsnittene om testimplementeringer i Nykøbing F. og Køge Kommuner). Figur 1.3. Læsevejledning for GIS-Koordinator Læsevejledning for den metodeinteresserede Hvis dine interesser primært går i retningen af, hvilke metoder der er anvendt i projektet vil vi foreslå at læse følgende afsnit i den angivne rækkefølge Start med Afsnit 2 Problemformulering for at få overblik over tese, problem og projektafgrænsning. Læs derpå Afsnit 3 Metodebeskrivelse for beskrivelse af, hvilke metoder der tages i anvendelse for løsning af problemet. Hvis du har interesse i en af de beskrevne metoder, findes der i afsnittet en henvisning til, i hvilke dele af projektrapportens kapitler, hvor metoden anvendes. Afslutningsvis vurderer vi i Afsnit 9 Konklusion (specielt afsnit 9.4 Vurdering af metodevalg ), hvor godt metodevalget var i forhold til problemformuleringen. Figur 1.4. Læsevejledning for den metodeinteresserede

11 GIS-Byggesag Problemformulering 2. Problemformulering Problemformuleringen omfatter udover en præcisering af projektets hovedproblem også en præsentation af en række delproblemer samt en projektafgrænsning. 2.1 Hovedproblem Projektet tager sit udgangspunkt i følgende spørgsmål: Hvorfor anvendes GIS ikke i højere grad som et integreret værktøj i forbindelse med byggesagsbehandling? Hovedproblemets spørgsmål er relevant at stille i forhold til en lang række sagsområder. Vi stiller spørgsmålet i dette projekt til behandling af byggesager i den kommunale administration. Årsagen er, at vi opfatter denne sagsbehandling eller væsentlige dele af denne som et sagsområde, hvor GIS kan benyttes som et værktøj med mulighed for at opnå positive resultater. Denne vurdering støttes af, at byggesager altid knytter sig til en ejendom, som derfor knytter sig til en fysisk beliggenhed. Denne beliggenhed kan kombineres i vores GIS med alle data, som er struktureret tilgængelige på digital form, og som kan have betydning for sagens afgørelse. Det var meget tidligt i projektforløbet klart, at en vigtig årsag til den relativt ringe benyttelse af GIS i byggesagsbehandlingen var, at der ikke er applikationer på markedet, der understøtter både indsamling af rådighedsindskrænkninger og hændelser i en byggesag. Målet med dette projekt er derfor at udvikle en GIS-applikation, som retter sig mod den kommunale byggesagsbehandling. Formålet med denne udvikling er at skabe en forøgelse af effektivitet og kvalitet gennem styring af dataindsamling og sagsgange samt dokumentation af processer. Gennem arbejdet med projektets hovedproblem og delproblemer er følgende tese således formuleret: Det er muligt at udvikle en GIS-applikation, der henvender sig til byggesagsbehandlere med GIS-kunnen på brugerniveau, og som både indsamler alle de i GIS tilgængelige rådighedsindskrænkninger og samtidig tilbyder såvel styring af tidsfrister som integration og videregivelse af stamdata til MS Word-skabeloner til gavn for effektivitet og overblik i byggesagsbehandlingsprocessen. Projektets arbejde med at udvikle GIS-applikationen var dels begrundet af en række barrierer for udbredelse af GIS i den kommunale byggesagsbehandling, og dels førte selve applikationsudviklingen andre barrierer med sig. En vigtig del af projektet er registrering, strukturering og bearbejdning af disse barrierer. 2.2 Delproblemer Selvom GIS er indført i kommunens tekniske forvaltning, viser det sig ofte at anvendelsen er begrænset til et beskedent antal sagsområder. Der kan peges på en række problemstillinger, som har indflydelse på udbredelsen af GIS: interesse blandt medarbejderne personaleressourcer (tid)

12 GIS-Byggesag Problemformulering [28]. økonomi kendskab til GIS muligheder fagspecifikke GIS-applikationer (eller mangel på samme) uddannelse (herunder GIS-specifikke kurser / efteruddannelse) datagrundlag organisation Oftest vil det ikke være en enkelt faktor, der alene hindrer udbredelsen, men en række kombinationer af ovennævnte. Ressourcemæssigt er byggesagsbehandlerne trængt i dag, og udviklingen rummer ingen løfter om forbedringer. Der er en generel forventning om, at kommunerne vil få færre medarbejdere indenfor de næste 5-10 år, når mange medarbejdere går på pension. Landets arbejdsstyrke vil ikke kunne udfylde de mange huller, blandt andet fordi lønniveauet ikke er en mulig konkurrenceparameter, hvilket kan medføre, at rekrutteringsgrundlaget ikke vil være stort nok. Kravet må derfor være at få koncentreret sagsbehandlingen om det fagligt vigtige. Dataindsamlingen til byggesagsbehandlingen er meget ukoordineret. Det gælder for såvel digitale såvel som analoge kilder. Nogle digitale oplysninger skaffes fra KMD s registre, nogle på Amtets GIS-hjemmeside og nogle eventuelt fra et lokalt, kommunalt GIS. Specielt for registrene hos KMD har adgangen været via rene alfanumeriske skærmbilleder (såkaldte 3270-billeder), og først i de seneste par år har vi set muligheder for decentrale løsninger gennem Ejendoms- og Miljødatabasen og Web-adgang via BBR Web og ESR Web. Web-adgangen har dog stadig begrænsninger ved opslag og få muligheder for kobling til f.eks. et GIS. Analoge data omfatter såvel papirdokumenter (kort, lokalplaner, byggesagsarkiv, egne lister) som det byggesagsbehandleren bare kan huske og derfor ikke nødvendigvis kontrollerer. Specielt de analoge kilder betyder, at der opstår en meget individuel tilgang til sagsbehandlingen, ikke blot fra kommune til kommune men også fra sagsbehandler til sagsbehandler alt efter erfaringer og egne notater. Dataindsamlingen er dermed ikke en struktureret proces, som altid følges, men en proces, der indenfor den enkelte kommune og givetvis kommunerne imellem kan afvige fra sagsbehandler til sagsbehandler. Det kan konstateres, at byggesagsbehandlingen ikke er effektiviseret i forhold til de teknologiske muligheder. Ganske vist eksisterer der en række hjælpemidler for byggesagsbehandlingen, herunder de ovennævnte KMD-adgange og GIS, men der savnes én samlet adgang til data. I dag skal der søges mange steder for at skabe et samlet billede af rådighedsindskrænkninger for en ejendom. Det skyldes blandt andet den ukoordinerede dataindsamling og -opbevaring og det forhold, at der mangler en teknisk opsætning, der klart beskriver de data, der er behov for

13 GIS-Byggesag Problemformulering Samtidig er der pres udefra for at få en mere effektiv, smidig og ensartet sagsbehandling. Det gælder fra statsside, som det er formuleret af Den digitale Taskforce, fra erhvervslivets side, bl.a. gennem Byggematerielindustrien, og fra ansøgerne borgere og virksomheder. Alle ovennævnte problemstillinger leder også frem til et behov for at dokumentere de processer, der fører frem til afgørelser af byggesagerne. Dette ville være en uvurderlig hjælp for sagsbehandlerne, deres eventuelle afløsere, ansøgerne samt for troværdigheden i hele byggesagsbehandlingssystemet. På mange fronter ses krav om, at kvaliteten af arbejdet proces og resultat - skal deklareres. Det sker blandt andet i forbindelse med arbejdsgangsanalyser ved indførelse af ESDH og ved organisationsændringer. Ovenstående delproblemer er en række barrierer eller måske mere præcist barrierekomplekser. I dette afsnit dog formuleret i meget generelle vendinger. Senere i projektrapporten (Kapitel 7) konkretiseres de oplevede barrierer fra byggesagsbehandlerne. Det samme gælder de aktuelle initiativer, der er taget for at skabe fremtidens byggesagsbehandling. 2.3 Valg og fravalg - projektafgrænsning For at kunne afgrænse projektet er det vigtigt at se nærmere på, hvad byggesagsbehandling helt konkret er. Skematisk set består byggesagsbehandlingen af 5 dele: A: Borgerens ansøgning (skema, vejledning mv.) B: Sagsregistrering og efterfølgende sagsadministration C: Vurdering af rådighedsindskrænkninger D: Byggeteknisk vurdering E: Afgørelse (ud fra C og D) ad A Borgerens ansøgning: Traditionelt foregår borgerens ansøgning gennem udfyldelse af et eller flere skemaer alt efter sagstype, forskellige tegninger og kort samt eventuel personlig vejledning i forvaltningen eller pr. telefon. Som så meget andet arbejdes der for tiden med en elektronisk ansøgningsmulighed. KMD s Byggesagsguide er en browserbaseret indgang, hvor ansøgeren udfylder ansøgningsskemaet online og kan vedhæfte tegninger, kort og andre elektroniske bilag. Der er ikke tale om en løsning der indeholder GIS. Den største gevinst ved Byggesagsguiden er, at byggesagsbehandleren ikke skal indtaste de oplysninger ansøgeren allerede har udfyldt, da der sker en direkte opdatering af BBR/CR, når

14 GIS-Byggesag Problemformulering oplysningerne godkendes af byggesagsbehandleren. Selve sagsbehandlingen afhænger af hvilken sagstype, der er tale om, hvilket også afspejles i den videre proces. Løsningen er udviklet i forlængelse af KMD s deltagelse i et projekt, som er formuleret i regi af Den digitale Taskforce. [6] Byggesagsguiden er en løsning, som KMD kræver penge af kommunerne for. Dette sammenholdt med, at der er tale om en helt ny løsning, og at den kun dækker anmeldelsessager, gør, at der endnu ikke er særligt mange kommuner som anvender løsningen. Vores projekt omfatter ikke forhold omkring ansøgning af byggetilladelse, hvorfor der ikke findes en konflikt mellem de beskrevne initiativer vedrørende ansøgningen og nærværende projekt. Større byggesager har deres helt egen organisation omkring ansøgning, og disse er foreløbig ikke understøttet af Byggesagsguiden. Her er sagsbehandlingsmetoden meget forskellig fra kommune til kommune, men som oftest inviteres bygherre, bygherrerådgiver, entreprenør, ledningsejere og byggesagsbehandlere til et samlet møde, hvor projektet gennemgås. Ved alle sagstyper er de fire resterende skematiske procesdele aktuelle ad B - Sagsregistrering og sagsadministration: Den digitale Taskforce peger i sit beslutningsoplæg [5] på, at der er et behov for at udvikle systemer til sagsstyring og registrering, da hovedparten af de systemer, der er på markedet, vurderes til at være forældede. Desuden vurderes det, at der kun findes et sparsomt udbud af systemer, der tilbyder ledelsesinformation til brug for benchmarking samt dokumentation af servicedeklarationer etc. Desuden vurderer Den digitale Taskforce, at der er behov for at udvikle systemer, der kan skabe overblik over en byggesags behov for eksterne høringer. Her peges der på, at man vil kunne opnå en gevinst, såfremt man kan overgå fra den hidtidige tendens til at foretage sekventielle høringer til at anvende stjernehøringsprincippet. Fra KMD udbydes BGS og indtil for nylig BGS+ til kommuner med Ejendoms & Miljødatabasen (E&M) hvor der udover styringsredskaber også findes forskellige standardskrivelser. Data for udfyldelse af standardskrivelser hentes fra BBR og oplysninger indtastet i BGS/BGS+. Der er meget begrænset fleksibilitet i standardskrivelserne, hvorfor mange kommuner har fravalgt denne funktionalitet. Til gengæld er automatikken i overførsel af data fra BGS/BGS+ til BBR/CR og senere i processen til BBR/CS meget værdsat, idet den sparer en række dobbeltindtastninger. Nogle kommuner har valgt at styre sagerne uafhængigt af KMD ved egenudviklede databaser (Sydthy Kommune) eller med løsninger købt hos konsulenter. Udbudet af GIS-løsninger er meget begrænset. Kun en enkelt GIS-leverandør (Geograf) reklamerer med applikation til området. Applikationen har en vis GIS-funktionalitet og håndterer udover sagsadministration med styring af en række tidsfrister og skriftlig kommunikation med ansøgeren også eventuelle henvendelser til andre myndigheder samt svar herfra

15 GIS-Byggesag Problemformulering Årsagen til den manglende GIS-udvikling på området er bl.a. den manglende mulighed for at overføre data til BBR og andre KMD-registre. Derved kan GIS ikke træde i stedet for eksisterende løsninger men må fungere som supplement, hvilket begrænser incitamentet til at anskaffe dem. GIS kunne spille en vigtig rolle på det administrative plan, idet der via kortdelen kan skabes geografisk overblik over igangværende sager, identificeres naboejendomme for en eventuel nabohøring samt gives et billede af, om der er tilstrækkeligt med kortmateriale ved en sagsvisitering, når aflevering af ansøgning foretages ad C - Rådighedsindskrænkninger: Den digitale Taskforce vurderer i sit beslutningsoplæg [5] at der er et stort behov for at udvikle et system til digital indsamling af rådighedsindskrænkninger. Man peger på, at man vil kunne opnå en besparelse på op til 40% af sagsbehandlingstiden, hvis man endvidere kobler til bagvedliggende registre. Behandlingen af rådighedsindskrænkninger omfatter en meget stor dataindsamling og efterfølgende vurdering af, hvorvidt de fundne bindinger har betydning for byggesagen. En del af disse oplysninger findes i dag som tidligere nævnt blandt andet i KMD-registre og en lang række andre kilder, såvel digitale som analoge. Her er GIS en oplagt mulighed for at søge og sammenstille de digitale kilder, men det udnyttes ikke målrettet i de løsninger vi har set. Måske fordi kilderne er så spredte og fordi deres GIS-egnethed er varierende. Data kan groft opdeles i tre typer; eksisterende GIS-data, digitale registerdata og analoge data. De eksisterende GIS-data fra Kommunens eget GIS har de fleste byggesagsbehandlere til rådighed. Men en del af temaerne fremgår af amternes WebGIS, og for byggesagsbehandlerne betyder det, at den samme søgning skal udføres i flere systemer (amtets WebGIS og kommunens eget GIS) frem for i et samlet system. Registerdata uden tilhørende digital kortdel er naturligvis digitale data, men altså ikke umiddelbart tilgængelige i GIS. Data er typisk alle KMD-registrene (BBR, ESR, PlanRegister) og Tingbogen. Den geokodning der skal ske af disse data afhænger helt af om Kommunen har E&M-databasen med tilhørende applikationer eller eventuelt henter udtræk via Videregivelsessystemet for Ejendomsdata og efterfølgende indlægger i GIS. Digitale data omfattes endvidere af en problemstilling vedrørende datakvaliteten. Behovet for vurdering af kvaliteten indtræder, når datasættet anskaffes og klargøres. En helt speciel datagruppe er de analoge. Der er ofte en helt konkret årsag til at disse endnu ikke er konverteret til digital form. Hovedårsagen er i mange tilfælde økonomien i konverteringen af meget store datamængder, men også f.eks. juridisk praksis kan være en hindring. Det sidste gælder f.eks. for Tingbogens akter

16 GIS-Byggesag Problemformulering ad D - Byggeteknisk vurdering: Den byggefaglige vurdering omfatter bl.a. materialevalg, konstruktion, isolering, brandforhold mm. Selve vurderingen SKAL foretages af en bygningssagkyndig, men der kan være et reelt behov for et værktøj til at sikre de korrekte tegninger og eventuelle beregninger indgår i ansøgningsmaterialet. Denne del hører dog hjemme under sagsadministrationen (pkt. B) ad E Afgørelse Den samlede afgørelse af pkt. A, ansøgningen, træffes på baggrund af dataindsamling og vurdering af pkt. C og D. Her er det byggesagsbehandlerens faglige kompetence, der er den absolut vigtigste parameter. Når afgørelsen er truffet, vendes så at sige tilbage til pkt. B for udfærdigelse af tilladelse eller afslag. 2.4 Udvælgelse/Projektafgrænsning: Eftersom Den digitale Taskforce anviser, at der mangler en samlet indgang til rådighedsindskrænkninger, og KMD i dag er langt fremme med udviklingen af et system til at strømline ansøgningsprocessen vil vi rette blikket mod punkterne B og C. Det er projektgruppens forventning, at KMDs Byggesagsguiden i løbet af få år vil blive kommunernes foretrukne løsning, især når flere sagstyper kan håndteres af løsningen. Der hersker næppe tvivl om, at det rette medie for borgerselvbetjening også på byggesagsområdet hedder Internettet på grund af dettes store udbredelse. Det medfører ikke nødvendigvis at den efterfølgende sagsbehandling hos kommunen også skal ske i en browser-baseret løsning. Det er udelukkende et spørgsmål om det interface data afleveres i fra ansøgerens side. Dette projekt beskæftiger sig ikke med, hvordan en ansøgning når frem til byggesagsbehandleren. Hvor fokus i Byggesagsguiden ligger på borgeren og dennes ansøgning, vil vores fokus rette sig mod sagsstyring og datafremfinding samt analyse af rådighedsindskrænkninger og dermed også være rettet mod byggesagsbehandleren. Vores prioritering er, at byggesagsbehandleren i højere grad skal kunne bruge sin tid på den faglige del af byggesagsbehandlingen frem for at bruge den på administration og datafremfinding. Denne prioritering er i øvrigt blevet bekræftet gennem vores kontakt til byggesagsbehandlerne, som for nogens vedkommende har et håb om at bruge mindre tid på administrativt bøvl frem for at bruge tiden på det, som det virkelig drejer sig om: At vurdere det bygningstekniske og -arkitektoniske. For tiden tales der både i GIS-kredse såvel som i øvrige IT-orienterede kredse meget om XML som fremtidens udvekslingsformat. (Se fx. [11]). Når XML bliver mere udbredt i den offentlige og private infrastruktur for data, og der bliver udarbejdet XML-schemas til de offentlige datasæt, er der ingen tvivl om at der vil komme XML-oversættere til alle gængse GIS-platforme. På GIS-platformen MapInfo, som dette projekt har benyttet sig af, findes der allerede applikationer, der håndterer oversættelse af tabulære data til XML

17 GIS-Byggesag Problemformulering Vi har valgt at implementere vores løsningsbud ved hjælp af MapInfo og til dels MS Office produkter. MapInfo understøtter åben dataudveksling ved hjælp af XML og MS Office er i nogen grad de-facto-standard. Der er imidlertid ingen krav til tekstbehandleren, hvorimod der ikke er udviklet integration til andet kalendersystem end MS Outlook. Valget bunder i at det er værktøjer der i forvejen anvendes i de tre kommuner projektgruppens deltagere kommer fra. Vi har altså rettet fokus ind på at skabe løsninger der enkelt lader sig implementere i vore egne GIS-miljøer uden dog at give afkald på mulighederne for fremtidige udvidelser baseret på ny teknologi som f.eks. XML. Dermed vender vi tilbage til tesen og dermed målet med projektet: Det er muligt at udvikle en GIS-applikation, der henvender sig til byggesagsbehandlere med GIS-kunnen på brugerniveau, og som både indsamler alle de i GIS tilgængelige rådighedsindskrænkninger og samtidig tilbyder såvel styring af tidsfrister som integration og videregivelse af stamdata til MS Word-skabeloner til gavn for effektivitet og overblik i byggesagsbehandlingsprocessen. Målet er endvidere at understøtte frem for at ændre nuværende strukturer. Selvom organisationsændringer kan være teknologidrevne, kan accepten af et nyt værktøj hæmmes, hvis det udløser for store forandringer. Da der, som beskrevet ovenfor, også er stor forskel fra kommune til kommune, hvilke data der findes digitalt og på hvilken form, er der behov for en samlet løsning, der er så fleksibel at ét sæt manglende data (f.eks. manglende digitalisering af lokalplangrænser) ikke betyder, at applikationen som sådan ikke fungerer. Applikationen skal dog understøtte buffersøgninger, fordi det skal være muligt for den enkelte kommune at tage forbehold for kvaliteten af de benyttede data. Dette forbehold kan dog kun gælde nøjagtigheden i registreringen af det benyttede datasæt ikke fuldstændigheden. Her kan det så passende anføres, at implementering af den udviklede applikation forhåbentligt kan være en spore til at afsætte ressourcer til digitalisering af relevante analoge data

18 GIS-Byggesag Metodebeskrivelse 3. Metodebeskrivelse I dette afsnit gennemgås de metoder, vi har anvendt i projektet. Den teoretiske baggrund opstilles og begrundes med fokus på, hvad vi har gjort, hvordan vi har gjort det og ikke mindst hvorfor vi har gjort det. 3.1 Opdeling i delmetoder Et væsentligt element i det at arbejde problemorienteret er metodefriheden i projektarbejdet. Det er meget vigtigt, at det er problemet, der styrer metoden og ikke omvendt. Af samme årsag er redegørelsen for det gjorte metodevalg centralt. Videnskabsteoretisk beskæftiger vi os med det teknisk/naturvidenskabelige område, hvor vi arbejder med udviklingen af organisationens informationsteknologi og samtidig med det samfundsvidenskabelige område, hvor vi arbejder med organisationen og dens samspil med omverden. Projektet ligger, som det fremgår af problemformuleringen, i et spændingsfelt, som indeholder såvel en samfundsvidenskabelig tilgang bedst mulig byggesagsbehandling for ansøger og samfund som en teknisk løsning ifølge vores tese GIS - der tilgodeser dette. Vi har ikke entydigt kunne finde en metode, som dækker såvel de samfundsvidenskabelige som de teknisk-naturvidenskabelige aspekter af en sådan proces. Derfor er vores metodevalg blevet en kombination af en samfundsvidenskabelig vidensproduktionsproces og en softwareudviklingsmetode. Vidensproduktionsprocessen skaber grundlaget for at kunne komme i gang med den praktisk orienterede applikationsudvikling. 3.2 Vidensproduktionsprocessen Vi har valgt at benytte den beslutningsproces, som er beskrevet i Den skinbarlige virkelighed [17], og som har et væsentligt udgangspunkt i Enderuds model for vidensproduktionsprocessen. Årsagen hertil er den vægt, vi tillægger opbygningen af ny viden i projektet. Vi ønsker at få indkredset den del af byggesagsbehandlingen, der ud fra projektafgrænsningen er projektets emne, fra alle vinkler. Samtidig forudsætter vi, at denne vidensproduktion nødvendigvis må foregå gennem hele projektperioden. Netop den situation passer efter vores mening godt til vores temperament og måde at arbejde på. Der indsamles en række oplysninger, studeres teori, diskuteres muligheder og dannes på den måde ny viden. Denne viden indgår så som parameter for næste runde i vidensproduktionen. Projektarbejdet er foregået ved jævnlige møder i gruppen, men også længere forløb hvor vi hver især har indsamlet data om byggesagsprocessen, GIS og GIS-temaer og andre tiltag på området. Vidensproduktionsprocessen har tilladet os i meget høj grad at arbejde systematisk på denne måde. Samtidig var processen i sin natur iterativ ligesom vores applikationsudviklingsmetode, hvilket beskrives senere i dette afsnit. Processen fremgår figur 3.1. De angivne pile illustrerer blot, at der sker interaktion mellem de forskellige elementer i processen og skal ikke nødvendigvis tages som udtryk for, at elementerne kun påvirker

19 GIS-Byggesag Metodebeskrivelse hinanden en eller to ad gangen. Alle kombinationer er tænkelige, og der arbejdes iterativt, så ny viden anvendes i næste vidensproduktionsproces. Figur 3.1 Beslutningsproces. [17, side 51] For dette projekt gælder nedenstående om elementerne i figur Rammestyringsfaktorer Rammestyringsfaktorerne er forhold, der angiver de overordnede rammer for projektet. I denne forbindelse vil rammestyringsfaktorerne derfor se anderledes ud, end hvis det drejede sig om at bestille en applikationsudvikling hos et konsulentfirma. Love og regler: Det drejer sig specifikt om Byggeloven, de to bygningsreglementer og de mange lovkomplekser, der har indvirkning på byggesagsbehandlingen. Interessenter: Interessenterne er i denne forbindelse Stevns, Køge og Nykøbing F. Kommuner, repræsenteret ved deres byggesagsbehandlere, samt projektgruppens tre medlemmer. Byggesagsbehandlerne ønsker et bedre værktøj til byggesagsbehandling og administration, mens vi som GIS-folk ønsker anvendelserne udbredt, så tilgængelige ressourcer nyttiggøres. Formål: Den producerede viden skal anvendes i forbindelse med udviklingen af en GIS-applikation til byggesagsbehandling. Ressourcer: Projektets ressourcer ligger udelukkende i den tid projektgruppens medlemmer og øvrige

20 GIS-Byggesag Metodebeskrivelse deltagere i udviklingen har til rådighed ved siden af det daglige arbejde. Der er ikke involveret økonomi til indkøb af udviklingsplatform, data eller supplerende GISapplikationer Processtyringsfaktorer Processtyringsfaktorerne er forhold, som er bestemmende for projektets forløb. De ses undervejs i projektforløbet og influerer dermed løbende på vidensproduktionsprocessen Vidensproduktionsprocessen Problemformulering: Problemformuleringen indeholder de spørgsmål projektet skal besvare, samt den afgrænsning der arbejdes indenfor. Teori: En del af projektets teori kommer fra gennemgang af byggelovgivningen samt den lovgivning, som regulerer rådighedsindskrænkninger i forbindelse med byggesagsbehandling. Heraf fremgår nøjagtigt, hvilke forhold der skal tages hensyn til i en vilkårlig byggesagsbehandling. Undervejs ønsker vi at undersøge, hvor godt denne teoretiske tilgang stemmer overens med den byggesagsbehandling, der udføres i praksis. En anden del af projektets teori stammer fra kravene til kodning i det valgte udviklingssprog Mapbasic og til en vis grad Visual Basic. Empiri/data: Empirien har flere roller i et problemorienteret projekt. I forhold til problemformuleringen handler det dels om at finde og opstille problemer dels for kontrol af, hvorvidt de opstillede problemer er reelle. I forhold til Problemløsningen (konklusionerne) handler det dels om at skaffe idéer til hvilken retning problemløsningerne skal gå dels for at sandsynliggøre at de fundne løsninger er rigtige. [20] Vores indsamling af empiri spreder sig over et bredt felt; interviews med byggesagsbehandlere og andre aktører (KMD), gennemgang af datagrundlaget i forhold til lovgivning, undersøgelse af hvilke andre initiativer, der er taget på området, samt hvad der i dag er af applikationer til rådighed for byggesagsbehandlerne. Konklusioner: Resultatet af vidensproduktionsprocessen konklusionerne skal skabes på såvel et generelt niveau i form af baggrundsviden som et specifikt niveau i form af barrierer. Disse konklusioner anvendes i applikationsudviklingen og indgår samtidig i den videre vidensproduktionsproces. 3.3 Applikationsudviklingsmetoden Grundlaget for udviklingen af vores GIS-applikation er en evolutionær udviklingsmodel. En evolutionær model er bygget på en filosofi om interaktion og forandring. Den er karakteriseret ved hyppige tilbagemeldinger og brugerdeltagelse

21 GIS-Byggesag Metodebeskrivelse Basalt set kendetegner nedenstående tre punkter et projekt, hvor metoden er velegnet: Kunden kan ikke forklare præcist, hvad der ønskes Kravene ændres undervejs Aftestning sker løbende for kontrol og tilbagemelding Kendetegnende for at få succes med projekt på baggrund af en evolutionær model er: hyppig og hurtig tilbagemelding fra brugere projektets mål er flydende fokus er hele tiden på den vigtigste funktionalitet hyppige nye versioner Populært sagt passer den evolutionære model perfekt i situationer, hvor kunden/brugeren siger: Jeg kan ikke fortælle, hvad det er jeg vil have, men jeg ved det, når jeg ser det! De stadier der gennemløbes i en evolutionær model ses af nedenstående figur 3.2. Figur 3.2. Stadier i en evolutionær model [9, side 15] En evolutionær udvikling startes med et proposal (et forslag), som fører til den første systemdefinition. På baggrund af denne starter den iterative proces. Ny funktionalitet

22 GIS-Byggesag Metodebeskrivelse opbygges og testes af brugerne. Det medfører ønsker til forbedringer, som så igen fører til opbygning af ny funktionalitet. Når processen har medført en komponent, som er klar til implementering tages denne ud af udviklingen og evalueres. Fra evalueringen kan der dels komme input til forandret systemdefinition men også input direkte til den iterative proces. Og på tidspunkter, hvor de udviklede komponenter eller delapplikationer kan bære det, kommer der således en ny version af applikationen til verden. Evolutionære modeller er særdeles anvendelige i situationer, hvor der er tæt og direkte kontakt mellem kunde/bruger og udvikler, og hvor kravspecifikationer udspringer af brugerens anvendelse af de allerede udviklede programdele. Begrænsningen for denne type udvikling ligger i salg til mange kunder, hvor hyppige nye programversioner giver anledning til problemer med opgraderinger, forståelse for eventuelle følgefejl af ny funktionalitet og den uoverskuelighed, det medfører. En anden og oftere anvendt - betegnelse for evolutionære modeller er iterative modeller og udviklingsmetoden kaldes så Iterative Software Development (ISD). ISD er ikke én metode men en lang række metoder med det fællestræk at der arbejdes i et tæt samspil med kunden/brugeren. Vores version af ISD har som udgangspunkt at de inkrementelle dele hver især udspringer af følgende tre spørgsmål: hvilken information? hvilke funktioner? hvilke hændelser? Figur 3.3 Spørgsmål i ISD-processen. På baggrund af de beskrevne forudsætninger for ISD faldt det meget naturligt at anvende metoden i dette projekt. Vi har det tætte samspil mellem udvikler og kunde/bruger. Kunden/brugeren ved ikke, hvad de kan forvente sig af et Byggesags-GIS og vi kender som udviklere dermed heller ikke deres krav. Kravene opstår efterhånden som funktionaliteten af de første programdele kendes og anvendes

23 GIS-Byggesag Metodebeskrivelse Vi kan teste applikationen undervejs hos brugeren. Vi var på forhånd klar over, at det i regi af dette MTM projekt ikke er muligt at skabe et komplet Byggesags-GIS og netop denne udviklingsmetode giver alligevel mulighed for hele tiden at have funktionelle programdele med mulighed for at vurdere disse. 3.4 Sien Vi sammenføjer de to ovenfor beskrevne metoder/processer med den metode, som vi udviklede i vores 1. års MTM Projekt Sien. [14] Metoden tager sit udgangspunkt i, at der er en række barrierer for at opnå det ønskede resultat. En ustruktureret samling af barrierer kan virke næsten uoverkommelige og måske betyde at processen helt opgives. Med ønsket om at skaffe strukturering på den mangfoldighed af barrierer, der opleves i forbindelse med udbredelse af GIS, skabte vi et redskab. Målet var blandt andet, at de mange enkeltbarrierer samles og overskues i barrierekategorier. På den baggrund blev en række kriterier opstillet for redskabet: Redskabet skal kunne fungere på et meget bredt spektrum af barrierer. Målet er, at alle typer barrierer kan bearbejdes, så brugeren ikke først skal vurdere, hvorvidt en barriere er egnet til behandling med redskabet. Redskabet skal være forståeligt for andre end GIS-eksperter. Redskabet skal opfattes som funktionelt set fra brugerside. Redskabet skal kunne medvirke til at skabe overblik over det samlede barrierebillede. Resultaterne skal være operationelle. Det betyder, at de resultater der kommer fra behandling af barrierer skal være forståelige og til at arbejde videre med. Vi ønsker, at barriererne efter behandling peger på hvilke løsningsmodeller, der kunne tænkes anvendt. På det grundlag faldt det naturligt at forstå redskabet som en si, hvormed barriererne sorteres efter kornstørrelse. Billedlig talt afhænger kornstørrelsen af, med hvilken vinkel barrieren anskues. Disse vinkler valgte vi at kalde Målepunkter Målepunkter Ud fra en række kriterier kom vi frem til en definition på syv målepunkter som beskrives i det følgende: Intern ekstern: Er barrieren relateret til interne forhold i kommunen eller til eksterne forhold? Det vil sige forhold i det øvrige samfund, som kommunen ikke umiddelbart kan ændre eller påvirke. De Interne barrierer er relateret til forhold som kommunen - i teorien selv kan bearbejde og overvinde. Enhver barriere, der er karakteriseret som intern, skal efterfølgende vurderes i forhold til de seks resterende målepunkter. For at en barriere kan karakteriseres som intern eller primært intern skal der kunne etableres en løsning uafhængig af

24 GIS-Byggesag Metodebeskrivelse eksterne faktorer såsom lovgivning, datastrukturer for landsdækkende registre og kortstandarder. De Eksterne barrierer er relateret til forhold, som kommunen ikke selv eller ikke alene kan ændre. Bearbejdning af eksterne barrierer kan f.eks. ske gennem eller sammen med en organisation der specificerer standarder (KTC, GeoForum), et software-hus (MapInfo, Bentley, Intergraph, ESRI eller danske applikationsudviklere), et offentlig instans med ansvar for et landsdækkende register (KMD, KMS) o.s.v. Teknologi: Skyldes barrieren manglende, utilfredsstillende eller utilstrækkelige værktøjer eller hjælpemidler? Til hjælp ved tildeling af værdi til målepunktet kan det være relevant at der stilles spørgsmål af følgende karakter: Har vi den GIS-software der er behov for? Er problemet GIS-platformen som helhed eller en enkelt applikation? Er problemet hardware (for lidt RAM, diskplads osv.)? Er problemet at vi har for få GIS-arbejdspladser? Er GIS-applikationerne for svære at anvende for fagpersonerne? Er der forståelsesproblemer med engelske applikationer og manualer? Organisation: Skyldes barrieren forhold i den kommunale organisation, der virker begrænsende, hindrende eller obstruerende for GIS-indførelse? Ved organisation forstås den proces, der kobler teknik, kompetencer, holdninger og data sammen til et ønsket resultat. Organisation rummer således også arbejdsprocedurer, funktioner og ansvar. Der skelnes mellem personrelaterede og organisationsrelaterede forhold. Til hjælp ved tildeling af værdi til målepunktet kan det være relevant at der stilles spørgsmål af følgende karakter: Hvordan er workflow et for den opgave, hvor barrieren registreres? Er workflow et afhængigt af organisationen? Kan barrieren fjernes ved at ændre workflow og/eller organisation? Er der overensstemmelse mellem på den ene side mål og strategier for GIS og på den anden side ansvarsfelter og prioriteringer for den eller de funktioner, der har beslutningskompetence? Kompetence: Skyldes barrieren manglende viden, færdigheder, kompetencer, uddannelse etc. blandt personalet?

25 GIS-Byggesag Metodebeskrivelse Til hjælp ved tildeling af værdi til målepunktet kan det være relevant at der stilles spørgsmål af følgende karakter: Har barrieren sit udspring i manglende kompetence hos den/de medarbejdere der løser opgaven? Er det de rigtige fagpersoner der løser opgaven? Er der tale om et GIS/IT kompetenceproblem? Er der tale om et fagligt kompetenceproblem? Handler det om kurser i fag-applikationerne eller IT-generelt? Holdninger: Skyldes barrieren holdninger, traditioner, kultur etc. hos de involverede personer? Til hjælp ved tildeling af værdi til målepunktet kan det være relevant, at der stilles spørgsmål af følgende karakter: Er det en holdning hos den enkelte fagperson, der er barrieren? Er det hele medarbejderkulturen i afdelingen? Vil barrieren forsvinde, hvis personen forsvinder eller opgaven overføres til en anden person? Er det udsagn som nedenstående, der præger medarbejderen? o Det har vi prøvet! o Den slags dur i hvert fald ikke her! o Alle de der nye programmer skal vi ikke have her! o Jeg ved, hvordan den slags sager skal behandles, det har jeg gjort i 25 år, og mine egne metoder er bedre end det der GIS! Ressourcer: Er barrieren relateret til manglende ressourcer? Ved ressourcer forstå økonomiske ressourcer, tid, personer etc. Alt sammen forhold der i sidste ende kan løses, ved tilførsel af midler. Til hjælp ved tildeling af værdi til målepunktet kan det være relevant at der stilles spørgsmål af følgende karakter: Er der sammenhæng mellem GIS-ambitioner og GIS-budget? Er der sammenhæng mellem GIS-ambitioner og GIS-personale? (Her menes ikke kun de specifikke GIS-medarbejdere men også alle de sagsbehandlere og andre, der benytter GIS. Er ambitionsniveauet, hvad angår de fagområder GIS skal anvendes indenfor foreneligt med det antal medarbejdere, der er til rådighed.) Er tids-ambitionerne for, hvornår og for hvem der skal benytte GIS realistiske set i forhold til organisation, uddannelse, data osv.? Data: Skyldes barrieren manglende, mangelfulde eller usammenhængende data

26 GIS-Byggesag Metodebeskrivelse Til hjælp ved tildeling af værdi til målepunktet kan det være relevant, at der stilles spørgsmål af følgende karakter: Findes de data vi ønsker at beskæftige os med (på digital form)? Er der en standard for disse data? I bekræftende fald, benytter/overholder vi da denne standard? I benægtende fald, hvorfor ikke? Hænger data som opfylder forskellige standarder sammen? Er der uklarhed om nøglefelter/-data mellem data fra forskellige kilder (standarder)? Beskrivelse af siens virkemåde Med figur 3.4 illustreres forløbet i en arbejdsproces med Sien. Figur 3.4. Siens virkemåde. A Barriereliste Som udgangspunkt for anvendelse af sien har man en ustruktureret beskrivelse eller liste over de barrierer, der ønskes skabt et struktureret overblik over. Derved kan man efterfølgende få mulighed for at koncentrere indsatsen målrettet med at reducere antallet af barrierer, der forhindrer yderligere udbredelse og udvikling af GIS. I denne fase gennemgås de enkelte barrierebeskrivelser med henblik på at få opsplittet sammensatte barrierer i selvstændige og enkeltstående barrierebeskrivelser