Bilag 1: Kundens kravspesifikasjon

Transkript

1 Bilag 1: Kundens kravspesifikasjon Side 1 av 68

2 Dokumenthistorikk Versjon Dato Beskrivelse av endring Forfatter(e) Utkast for innspill per Sopra Steria Utkast til workshop Sopra Steria Foreløpig versjon til innspillsrunde Sopra Steria Noen mindre skrivefeil rettet og to feilplasserte tekstavsnitt flyttet fra kapittel til Sopra Steria Side 2 av 68

3 Innholdsfortegnelse 1 Innledning Dokumentets oppbygging Krav til Leverandørens besvarelse Formål og omfang Overordnede prinsipper og føringer Omgivelser Målgrupper for løsningen Begrepsliste Det langsiktige målbildet for Byggesøknadsløsningen Brukeren i sentrum Søke om byggetillatelse Innhenting av samtykke Nabovarsling Supplering av søknad Felles krav til Byggesøknadsløsningen Grensesnitt mot øvrige systemer Kompletteres etter at avklaringer rundt teknologi og arkitektur er landet Kravtabeller Krav til brukerflaten Krav til løsningen Brukerutfordringer i dag Informasjonsinnhenting Felles krav til informasjonsinnhenting Se eiendom Under utarbeidelse Veiledning Kladd Forhåndskonferanse Krav til søknad Felles for alle søknader Varsling av gjennomført byggetiltak under 50kvm Ikke utarbeidet Søknad om byggetillatelse (tillatelse til tiltak) Igangsettingstillatelse Midlertidig brukstillatelse og ferdigattest Søknad om endringstillatelse Refusjon Krav til elementer i søknad Side 3 av 68

4 8.1 Utforme og beskrive tiltak ikke utarbeidet Nabovarsling Gjennomføringsplan Avfallsplan Samtykke fra øvrige myndigheter Dispensasjon Delesøknad Krav til oppfølging av søknad Supplering av søknad Revidering av søknad Mottak av vedtak Klage på vedtak Se status på søknad Krav til tjenester for naboer og øvrige aktører Motta og gi merknad til nabovarsel Gi samtykke Innsyn i byggesak Ikke utarbeidet Erklæring om ansvarsrett Krav til støttetjenester Gebyrberegning Digital signering Ikke utarbeidet Betalingsløsning Ikke utarbeidet Sende og motta generelle henvendelser Administrasjon av løsningen Ikke utarbeidet Krav til teknologi og arkitektur - Under utarbeidelse Felles integrasjonsplattform for kommunal sektor Systemlandskap for byggesøknad Overordnet dataflyt mellom komponenter Informasjonsmodell for byggesøknad under utarbeidelse Krav til oppsett Ikke utarbeidet Vedlegg - Under utarbeidelse Side 4 av 68

5 Figurliste Figur 1: Oppbyggingen av behov og krav-kapitlene i dokumentet... 7 Figur 2: Eksempelskisse fra prototype på Byggesøknadsløsningen Figur 3: Grunndataregistre og fellesløsninger Byggesøknadsløsningen Figur 4: Systemlandskap Byggesøknadsløsningen Figur 5: Brukergruppenes behov i sentrum Figur 6 Dokumentets oppbygning Figur 7: Selvhjulpne brukere Figur 8 Oversikt over tjenester som løses i byggesøknadsløsningen Figur 9: Eksempel på mulighetsrom og plassering av tiltak i kart Figur 10: Signeringsprosess Tabelliste Tabell 1: Beskrivelse av kravkoder... 8 Tabell 2: Beskrivelse av svarkoder... 9 Tabell 3 :Beskrivelse av målgrupper for bruk av løsningen Tabell 4: Oversikt over sentrale begreper Side 5 av 68

6 1 Innledning I dette bilaget beskrives Kundens krav til ny Byggesøknadsløsning rettet mot kommunens innbyggere og næringsliv. Kravspesifikasjonen er utviklet av et felles prosjekt i regi av KS KommIT og tilgjengeliggjort for norske kommuner til bruk i separate anskaffelser. Formål og omfang av løsningen som skal anskaffes er nærmere beskrevet i kapittel Dokumentets oppbygging Dokumentet beskriver innledningsvis strukturen i dette bilaget og hvordan Kunden ønsker at Leverandøren besvarer de kravene som er stilt i dette bilaget med vedlegg. Dette skal hjelpe Leverandøren med å forstå oppbyggingen av dokumentet og å forstå hvordan kunden ønsker at kravspesifikasjonen besvares. I andre kapittel beskrives formålet med anskaffelsen og hva innføring av ny løsning skal gi av effekter hos Kunden. Samtidig beskrives de rammer og omgivelser som vil påvirke løsningen og som Leverandøren må forholde seg til i den videre utviklingen av løsningen. Eksempler på dette er aktører som er involvert, overordnede prinsipper og føringer og en oversikt over hvilke systemer som det kreves en integrasjon mot. I tredje kapittel beskrives det langsiktige målbildet. Dette kapittelet beskriver hvordan Kunden ønsker at løsningen utvikles på sikt. Målbildet strekker seg på mange områder utover det som stilles som krav til leveranse av løsningen i denne kravspesifikasjonen. Realisering av det langsiktige målbildet avhenger på flere områder av at det utvikles nye standarder og tjenester. Innholdet i kapittelet er derfor tatt med som informasjon til Leverandøren for at Leverandøren kan forstå hva Kunden har ambisjon om å oppnå på sikt og på denne måten kunne hensynta fremtidige tjenester som vil påvirke utviklingen av byggesøknadsløsningen. Det langsiktige målbildet blir også utdypet med brukerhistorier som ligger vedlagt denne kravspesifikasjonen. I de påfølgende kapitlene beskrives behovene som den nye løsningen skal dekke og de spesifikke kravene som stilles til bl.a. funksjonalitet, kvalitet, bruk av standarder og integrasjoner. Kravene som er beskrevet i denne delen av dokumentet, er krav til leverandørens leveranse som enten må eller bør innfris igjennom de to hovedleveransene som Leverandøren forplikter seg til. Siden Kundens behov og krav til brukervennlig standardløsning ikke dekkes fullt av løsninger som er tilgjengelig i dagens marked, åpner Kunden for at Leverandøren kan splitte opp leveranse av løsningen i to hovedleveranser. Det fremkommer av kravkodene i de vedlagte kravtabellene hvilken funksjonalitet som må inngå i første hovedleveranse og hvilken funksjonalitet som kan inngå i andre hovedleveranse om Leverandøren ønsker det. De to hovedleveransene er nærmere beskrevet i Bilag 4. Kapittelinndelingen av behov og kravkapitlene i kombinasjon med hvilke tjenester løsningen skal tilby søker er vist i figuren på neste side. Side 6 av 68

7 Figur 1: Oppbyggingen av behov og krav-kapitlene i dokumentet I behov og krav-kapitlene beskrives formål med området og det overordnede funksjonelle behovet, samt at det beskrives krav til integrasjoner, bruk av standarder m.m. i teknologi og arkitektur-kapitlet og krav til oppsettet av løsningen i eget kapittel. De overordnede behovene og kravene utdypes av kravtabeller som er et vedlegg til dette bilaget. Identifiserte utfordringer som brukerne opplever med dagens situasjon er også listet opp her. Side 7 av 68

8 1.2 Krav til Leverandørens besvarelse Utfylling av kravtabell Til dette bilaget er det vedlagt en kravtabell som angir spesifikke krav som Leverandørens tilbudte løsning skal eller bør tilfredsstille. Leverandøren har ansvar for at løsningen dekker det overordnede behovet, selv om det overordnede behovet ikke er kravstilt uttømmende i de konkrete krav i vedlagte kravtabell. Krav i kravtabellen, er sådan bare å vurdere som et supplement til de overordnede behovsbeskrivelsene i de oppgitte kravkapitlene i dette dokumentet. Enhver mangel på oppfyllelse av det overordnede behovet må tas som et klart og tydelig forbehold i henhold til krav stilt i konkurransegrunnlaget. Videre gjøres det oppmerksom på at i hvilken grad Leverandørens tilbud dokumenterer at det oppfyller overordnede føringer og prinsipper, som er nærmere beskrevet i kapittel xxx i dette bilaget, vil bli tillagt vesentlig vekt i evalueringen av leverandørens tilbud Kravkoder For hvert krav i kravtabellen er det angitt en kravkode som angir hvilken type krav som stilles. Det er fire ulike kravkoder; A-1, A-2, B og C som er benyttet i alle kravtabellene. Disse kravkodene er beskrevet nærmere i tabellen nedenfor: Kravkode: A-1 «Må-krav som må leveres i Leveranse 1» A-2 «Må-krav» B «Bør-krav» C Beskrivelse: «Ønskelig funksjonalitet» Tabell 1: Beskrivelse av kravkoder Dette er krav som leverandørens tilbudte løsning må tilfredsstille og som leverandøren må levere som del av Leveranse 1 iht. plan for leveranse i Bilag 4. Dette er krav som leverandørens tilbudte løsning må tilfredsstille og som leverandøren senest må levere innen fristen for Leveranse 2 iht. plan for leveranse i Bilag 4. Leverandøren kan fritt velge å levere denne funksjonaliteten som del av Leveranse 1. Dette er krav som dekker et behov som leverandørens tilbudte løsning bør tilfredsstille, men det er ikke et absolutt krav. Leverandøren kan selv velge hvilken leveranse denne funksjonaliteten skal leveres som del av. Dette er krav som dekker funksjoner som kunden anser som ønskelig og som kan gi kunden merverdi. Side 8 av 68

9 Svarkoder Hvert krav skal besvares av leverandør med en av de fire svarkodene 1, 2, 3 eller 4. Betydningen av de ulike svarkodene er beskrevet i tabellen nedenfor: Svarkoder: 1 «Ja, leveres i leveranse 1» 2 «Ja, leveres i leveranse 2» 3 «Nei» 4 «Alternativ løsning» Beskrivelse: Tabell 2: Beskrivelse av svarkoder Dette er funksjonalitet som inngår som del av den tilbudte løsningen og som Leverandøren forplikter seg til å levere innen fristen for Leveranse 1 iht. plan for leveranse i Bilag 4. Dette er funksjonalitet som inngår som del av den tilbudte løsningen, som Leverandør forplikter seg på å levere innen fristen for Leveranse 2 iht. plan for leveranse i Bilag 4. Dette er krav til funksjonaliteten som ikke inngår som del av den tilbudte løsningen. Leverandøren trenger ikke å fylle ut kommentarfeltet. Dette er funksjonalitet som ikke inngår som del av den tilbudte løsningen, men Leverandøren mener at alternativ funksjonalitet i den tilbudte løsningen vil dekke Kundens antatte behov som ligger til grunn for kravet. Leverandøren skal beskrive sin forståelse av Kundens behov. Leverandøren skal beskrive sin foreslåtte løsning av behovet. I tillegg skal det beskrives hvilken Leveranse, 1 eller 2, som den alternative funksjonaliteten vil bli levert i. Leverandøren skal besvare alle kravene i kravtabellen med en svarkode. Alle krav som tilbudt system oppfyller, skal kommenteres som beskrevet i tabellen ovenfor (gjelder svarkode 1, 2 og 4). Eventuelle krav som ikke er besvart med svarkode og/eller mangler kommentar, vil i evalueringen av Leverandørs tilbud bli tolket som et nei (svarkode 3). Kun svarkode 1 vil være akseptabel oppfyllelse av A-1-krav, mens både svarkode 1 og 2 vil være akseptabel oppfyllelse av A-2-krav (blir vurdert binært). Svarkode 4 vil være gjenstand for en vurdering av om Leverandørens beskrevne alternative løsning reelt dekker Kundens behov. Kun beskrivelser som kan forsvare at den dekker Kundens behov innenfor kravstilte leveranse, vil være akseptabel oppfyllelse av A-1 og A-2 krav. Det gjøres oppmerksom på at Kunden som del av evaluering av Leverandørens tilbud, vil evaluere hvor mye funksjonalitet som tilbys som del av Leveranse 1 utover det som er obligatorisk å levere i leveranse 1. Dette vil gjøres ved å evaluere andel A-2-krav og B-krav som er besvart med svarkode 1. Side 9 av 68

10 2 Formål og omfang Som ledd i arbeidet med å legge til rette for en forenklet og elektronisk byggesaksprosess, er det et mål å anskaffe en brukervennlig byggesøknadsløsning rettet mot innbygger og næringsliv. Løsningen skal være en felles inngangsport til byggesak i XXX kommune for søker og tiltakshaver, hvor både innbyggere og næringsliv kan orientere seg om byggesak, utforme og sende inn byggesøknader, samt følge og supplere søknadene. Kommunens Byggesøknadsløsning skal også være en felles inngangsport for naboer som skal se og evt. gi merknader til et nabovarsel, samt ansvarlige foretak som f.eks. skal signere for ansvarsrett i en byggesøknad eller andre parter som skal bidra inn i byggesøknaden. Byggesøknadsløsningen skal tilby en helhetlig brukergrensesnitt som gir brukeren støtte og veiledning i hele prosessen fra valg av søknadstype, nødvendig forhåndsarbeid, forhåndskonferanse, utfylling av byggesøknaden, varsling av berørte parter og informasjon og oppfølging av den videre søknadsprosessen. Leverandøren av løsningen som skal anskaffes må ta et helhetlig ansvar for at løsningen videreutvikles og forvaltes slik at den tilfredsstiller til enhver tid gjeldende regelverk og det offentliges krav til hva søknaden skal inneholde. Figur 2: Eksempelskisse fra prototype på Byggesøknadsløsningen For å understøtte anskaffelse av standardiserte løsninger i kommunene, har et felles prosjekt i regi av KS KommIT med støtte fra Direktoratet for Byggkvalitet og Kommunal og moderniseringsdepartementet utarbeidet en felles kravspesifikasjon som ligger til grunn for denne anskaffelsen. Prosjektet har involvert representanter for innbyggere og næringsliv i arbeidsmøter hvor dagens byggesøknadsprosess har blitt kartlagt og hvor ønsket fremtidig byggesøknadsprosess er grunnlaget for kravspesifikasjon som er blitt utformet. Kravspesifikasjonen er basert på funksjonelle krav, krav til brukervennlighet og integrasjoner mot relevante kildesystemer. En felles kravspesifikasjon for ny byggesøknadsløsning som alle norske kommuner kan benytte seg av legger til rette for at: Side 10 av 68

11 Leverandøren kan levere samme produkt og tjeneste til flere kunder Leverandøren kan utarbeide en standardisert besvarelse som kan benyttes som grunnlag for besvarelse på senere forespørsler Innføring av en ny byggesøknadsløsning i XXX kommune skal bidra til følgende effekter: Klar økning i antallet byggesøknader som leveres heldigitalt Reduksjon i antall byggesøknader hvor søkeren tar kontakt for å få veiledning til fremgangsmåte og utfylling av byggesøknad Høy tilfredshet blant innbyggere og næringsliv som benytter den digitale byggesøknadsløsningen. Innbyggere og næringsliv opplever at de får god digital støtte og veiledning i prosessen med utfylling av byggesøknaden 90 % av alle digitale byggesøknader er komplette fra søker ved leveranse av søknaden. Et godt datagrunnlag fra søknaden for effektiv elektronisk saksbehandling av søknaden. 2.1 Overordnede prinsipper og føringer Kunden ønsker at Leverandøren vektlegger å imøtekomme følgende overordnede prinsipper og føringer i løsningen Leverandøren tilbyr: Løsningen skal både veilede søkeren igjennom søknadsprosessen og det regelverket som gjelder Løsningen skal gjøre mest mulig relevant informasjon vedr. eiendom, byggesaker m.m. tilgjengelig for søker, slik at søker får et samlet sted å hente inn relevant informasjon til bruk i planlegging og utfylling av byggesøknaden. Løsningen skal hente inn strukturerte data som er tilgjengelig via etablerte tjenestegrensesnitt og gjenbruke data som er registrert i byggesøknaden til påfølgende søknader. Dobbeltregistrering av informasjon skal unngås så langt det er mulig. Løsningen skal produsere strukturerte søknader som danner grunnlag for en rask og effektiv saksbehandling Løsningen skal være brukervennlig og intuitiv i bruk ved bl.a. å: o Baserer seg på kjente konvensjoner for godt webdesign/interaksjon, slik at brukeren kan kjenne seg igjen fra lignende løsninger som brukeren har benyttet tidligere. o Har en logisk struktur på innhold slik at det til enhver tid er enkelt å navigere til ønskelig sted i løsningen o Viser tydelig hvor i løsningen man er til enhver tid o Har et lettfattelig språk og forklarer eventuelle fremmedord/fagutrykk for brukerne som har behov for dette o Er selvforklarende for brukere i de forskjellige målgruppene o Har et behagelig visuelt design Løsningen skal kunne benyttes på de mest brukte plattformene i markedet (de mest brukte nettleserne på mobil, nettbrett, pc m.m.) Løsningen skal være fremtidsrettet og støtte opp under kundens målbilde Hvordan tilbudt løsning ivaretar prinsippene og føringene nevnt ovenfor, bes besvart i bilag 2 Leverandørens løsningsspesifikasjon. Side 11 av 68

12 2.2 Omgivelser Det foreligger i dag en rekke digitale tjenester som leverandøren må eller kan benytte seg av i realiseringen av Byggesøknadsløsningen. Figuren under viser en oversikt over aktuelle grunndata og fellesløsninger for Byggesøknadsløsningen, samt andre fagsystem som Kunden regner med det på sikt vil bli mulig å kunne levere byggesøknaden direkte til kommunen i fra. Figur 3: Grunndataregistre og fellesløsninger Byggesøknadsløsningen Samtidig foregår det en rekke ulike prosjekter og er planlagt en rekke digitale tjenester som vil eller kan ha betydning for Byggesøknadsløsningen. Blant annet har Direktoratet for byggkvalitet initiert flere prosjekter med det formål å standardisere og effektivisere byggesaksprosessen og legge til rette for overgang til heldigitale søknadsprosesser. Dette gjøres bl.a. gjennom forenkling og digital tilgjengeliggjøring av forskrifter. I tillegg har KS KommIT flere pågående strategiske prosjekter innen Plan, bygg og geodata og jobber med utvikling av nasjonale tjenester rettet mot kommunene. I de påfølge underkapitlene gis det en enkel oversikt over pågående og planlagte prosjekter, samt eksisterende og tiltenkte digitale tjenester som vil eller kan ha innvirkning på Byggesøknadsløsningen. Side 12 av 68

13 application ebyggesøknad systemlandskap Priv ate komponenter og løsninger mot innbygger og næringsliv Garasje søknad fra Leverandør Y Prosjektsystemer BIM/CAD Systemer Byggesøknadsportalen Portal fra leverandør X Nasjonale komponenter ID-porten Enhetsregisteret Byggsøk Det offentlige kartgrunnlag - DOK Folkeregisteret (DSF) Sentral godkjenning Matrikkel Kontakt og reservasjonsregisteret Felles Integrasjonsplattform Kommunal Sektor (FIKS) Gebyrkalkulator Regelmotor Betalingstjeneste Innsendingstjeneste Valideringstjeneste Mottakstjeneste KS SvarUt - Forsendelsetjeneste Kommunale fag- og støtte-systemer KS SvarInn Offentlig Journal Fagsystem for digital byggesaksbehandling Kart/GIS løsning Postmottak Arkiv NOARK5 kjerne Planregister Kontorstøtte Økonomisystem E-Post Generell saksbehandling Figur 4: Systemlandskap Byggesøknadsløsningen Eksisterende tjenester og pågående prosjekter Følgende tjenester og prosjekter er klare eller vil være klare til leverandørens bruk i fase 1 av leveransen av ny byggesøknadsløsning: Prosjekt eller tjeneste Beskrivelse Aktuell fase Veileder for avklaring av søknadsplikt Kantega AS utvikler på oppdrag for DiBK en enkel veileder på nett som skal hjelpe innbyggere (og næringsliv) med å avklare om et tiltak er søknadspliktig iht. revidert plan og bygningslov gjeldende fra 1. juli Veilederen vil fungere som et nettbasert spørreskjema, hvor brukeren svarer på et sett med spørsmål og kommer frem til en konklusjon om det må leveres søknad om byggetillatelse eller om tiltaket er unntatt Fase 1 Side 13 av 68

14 Informasjonsmodell for byggesak Felles Integrasjonsplattform kommunal sektor (FIKS) Altinn Det offentlige kartgrunnlaget søknadsplikt. Veilederen skal være klar innen ny lov trer i kraft fra 1. juli Det må linkes til veilederen i fra byggesaksportalen, slik at brukeren sendes inn til den utarbeidede veilederen om brukeren er usikker på om tiltaket er søknadspliktig. Informasjonsmodell for byggesak beskriver data som samles inn i byggesaksprosessen og data behovet til omkringliggende systemer. Informasjonsmodellen utarbeides i en egen arbeidsgruppe. FIKS inneholder i dag KS SvarUT forsendelsestjeneste og mottakstjeneste. KS SvarUt forsendelsestjeneste Tjenesten mottar forsendelse og besørger videre ekspedering til elektroniske meldingstjenester (Altinn, eboks eller DigiPost) eller vanlig post. Mottakstjeneste Innsendingstjeneste Under evaluering Valideringstjeneste Under evaluering KS SvarInn Det er også tilgjengelig en lokal KS SvarInn komponent for å overføre fra Mottakstjeneste til Arkivet via GeoIntegrasjon Arkiv webservice. Kandidat til å inngå i FIKS. Under evaluering i Skjenkebevilgningsprosjekt og det jobbes med en pilot på Nabovarsel. Offentlige datasett fra Kartverket. Tilgjengelig på Kun tilgjengelig i wmsformat i dag, men det planlegges også å tilgjengeliggjøre datasett i WFS-format, som gjør det lettere å gjøre strukturerte oppslag i datasettene og sjekke hvilke datasett som har relevant informasjon for en gitt eiendom eller område. Fase 1 Fase 1 Fase 1 Fase 1 Side 14 av 68

15 2.2.2 Tiltenkte tjenester Følgende tjenester eller prosjekter er tiltenkt og vil kunne ha påvirkning på Byggesøknadsløsningen i en senere fase. Prosjekt eller tjeneste Beskrivelse Aktuell fase Regelverkssjekk Tiltenkt nasjonal tjeneste for tilgjengeliggjøring av til Fase 2 enhver tid gjeldende lov- og regelverk på byggesaksområdet for digital bruk. Kan benyttes til å kontrollere om strukturerte deler av en søknad er innenfor gjeldende lov og regelverk. Digitale plandata Kartverket har gjennom Norge Digitalt-samarbeidet Fase 2 mål om at alle analoge planer skal digitaliseres fra papir og rasterform til vektorformat frem til Videre jobbes det med planer om rommelige data (3D). BIM Det er etablert en faggruppe på BIM som jobber Fase 2 med å definere Information Delivery Manual(IDM) for byggesak som vil gi en godkjent BIM-leveranse (IFC-fil) til dokumentasjon i en byggesak. I en fremtidig versjon av Byggesøknadsløsningen vil opplasting av en godkjent BIM-fil kunne pre-utfylle store deler av en søknad og plasser tiltak i kart. Felles Integrasjonsplattform kommunal sektor (FIKS) Valideringstjeneste En tjeneste som validerer kompletthet/korrekthet på innsendte søknader. Vil i første fase evaluere godkjent XML-struktur og signaturer, men kan tenkes utvidet med sjekk mot regelverk m.m. når nasjonale tjenester for tilgjengeliggjøring av regelverk er klare. Regelmotor Inngår sannsynligvis i valideringstjenesten for å sjekke regler. Kan være lovkrav eller forretningsregler og integrasjoner til eksterne tjenester for kontroll av innsendte data. Gebyrkalkulator En felles tjeneste for å beregne byggesaksgebyr fra gitte parametere og metoder. Betalingstjeneste En tjeneste for å kunne betale byggesøknaden ved innsending. Side 15 av 68

16 2.3 Målgrupper for løsningen I tabellen nedenfor er viktigste målgruppene for brukere av løsningen beskrevet. Målgruppene er delt inn ulike kategorier basert på bruksmønster og behov. Søkere, inndelt i kategorier: Profesjonell søker Mindre erfaren søker Tiltakshaver Nabo Ansvarlige foretak Eksempel: Utbyggere Entreprenører Arkitektkontor Privatperson Mindre byggefirma Privatperson Profesjonell byggeier Firma eller privatperson Utførende Prosjekterende Kontrollerende Tabell 3 :Beskrivelse av målgrupper for bruk av løsningen Bruksmønster og behov: Søker som er godkjent for ansvarsrett. Har ofte flere aktive søknader Både store og små saker. Lite behov for informasjon Stort behov for versjons-håndtering og oversikt over mange søknader som er inne samtidig. Stort behov av informasjon og veiledning både mht. regelverk og søknadsprosess Kan være tiltakshaver/selvbygger eller søker godkjent for ansvarsrett med får byggesøknader Søker sjelden Interessert i informasjon om eiendom og hvilke bestemmelser som gjelder Anmode om forhåndskonferanse Skal signere på søknad og kan bidra med utfylling av delelementer i en søknad Interessert i å følge status på byggesøknad Kan også være søker Logge seg på for å se mottatt nabovarsel Gi merknad til foreslått tiltak Orientering om byggesøknadsprosess og klageadgang Innsyn i byggesak Erklære ansvarsrett i byggesøknaden for sitt ansvarsområde Levere samsvarserklæring for utført arbeid Side 16 av 68

17 2.4 Begrepsliste Oversikt over sentrale begreper benyttet i dette dokumentet: Begrep: BIM Brukerflaten Byggesøknadsløsningen Kladd Selvbygger Søker Forhåndskonferanse Samtykke øvrige myndigheter Tiltak Tillatelse til tiltak Ett-trinns-søknad To-trinns-søknad Beskrivelse: Building Information Modelling. Brukerflaten i den nye Byggesøknadsløsningen, som utgjør det grafiske grensesnittet som er rettet mot innbygger og næringsliv. Digital tjeneste rettet mot innbyggere og næringsliv for å utforme, levere og supplere byggesøknader digitalt. Det er benevnelsen i dette dokumentet på løsningen som leverandøren skal levere under denne kontrakten. En påbegynt søknad, der søker har mulighet til å prøve ut funksjonalitet i byggesøknadsløsningen for bruk i egen planlegging. Søker er den personen som har igangsetter en byggesøknad, og som står som ansvarlig kontaktperson i byggesaksprosessen. En forhåndskonferanse er et møte mellom søker og kommunen, initiert av søker, for å få hjelp og svar på ting han lurer på tidlig i søknadsprosessen. Søker vil få belyst aktuelle problemstillinger og gjøres kjent med atuelle krav og forutsetninger for videre saksprosess.kommunen står ansvarlig for å skrive et referat fra dette møtet, som deretter skal signeres av begge parter, og arkiveres i saksdokumentene. Samtykke fra øvrige myndigheter kan for eksempel være når en byggesøknad gjelder en bygning som skal benyttes til arbeidslokaler, kreves det særskilt samtykke fra Arbeidstilsynet. Dersom lokalet i tillegg skal ha en kantine, vil dette kreve samtykke fra Mattilsynet. Saksbehandlingsforskriften lister opp 14 sektormyndigheter, men det er kun et fåtall som normalt blir aktuelle i en byggesøknadsprosess. De fleste forhold som berører sektormyndigheter er avklart gjennom reguleringsplanen. Dersom det er søknad på en uregulert tomt, vil flere sektormyndigheter sannsynligvis bli involvert. Med tiltak etter Lov om planlegging og byggesaksbehandling (planog bygningsloven) 1-6, menes oppføring, riving, endring, herunder fasadeendringer, endret bruk og andre tiltak knyttet til bygninger, konstruksjoner og anlegg, samt terrenginngrep og opprettelse og endring av eiendom. Som tiltak regnes også annen virksomhet og endring av arealbruk som vil være i strid med arealformål, planbestemmelser og hensynssoner. Vedtak om tillatelse til å gjennomføre oppsøkt tiltak (oppføing, riving, endring m.m). Gjerne omtalt som byggetillatelse eller rivingstillatelse. Søknad om tillatelse til tiltak og igangsetting i ett trinn. Alle ansvarsretter må være belagt på tidspunkt for søknad om tillatelse til tiltak. Dersom en ønsker å sende byggesøknad før utførende foretak er bestemt, kan søknaden sendes i to trinn. Da sendes først søknad om Side 17 av 68

18 rammetillatelse. Når rammetillatelse foreligger og utførende foretak er bestemt, sendes søknad om igangsettingstillatelse. Søknad om rammetillatelse angir de ytre rammene for byggeprosjektet. Etter forskriftsbestemmelsen er dette forhold som for eksempel hva slags tiltak det gjelder, størrelsen, fasader, forholdet til kommunal plan og avklaring i forhold til naboene. Rammesøknad (RS) Gjennomføringsplan Samsvarserklæring Avfallsplan Dispensasjon Refusjon Rammetillatelse kan gis for forhold som ikke kreves avklart før i igangsettingstillatelsen. I forbindelse med rammetillatelsen foretas det i hovedsak en avklaring av om tiltaket i det hele tatt kan realiseres på det aktuelle sted med hensyn til gjeldende arealplaner eller fremtidig ønsket arealdisponering samt de ytre og innvendige rammer for tiltaket. En samlet plan for gjennomføring av tiltaket, med synliggjøring av ansvarsområder, tiltaksklasser, ansvarlige foretak, gjennomføring av kontroll og ferdigstillelse av tiltaket 1. For prosjektering: Skriftlig bekreftelse på at ansvarlig prosjekterende har utført prosjekteringen innenfor sitt ansvarsområde i overensstemmelse med krav og tillatelser gitt i eller med hjemmel i plan- og bygningsloven 2. For utførelse: Skriftlig bekreftelse på at ansvarlig utførende har utført tiltaket innenfor sitt ansvarsområde i overensstemmelse med produksjonsunderlaget, krav til utførelse og tillatelser gitt i eller med hjemmel i plan- og bygningsloven. En avfallsplan er en beskrivelse og redegjørelse for håndtering av avfall fordelt på ulike avfallstyper og mengder. Dispensasjon innebærer at bestemmelser gitt i eller i medhold av Plan- og bygningsloven (herunder reguleringsplan og bebyggelsesplan) fravikes i en konkret sak. Eksempler på dispensasjoner fra bestemmelser i plan- og bygningsloven: bygge nærmere enn 4 meter fra nabogrense bygge høyere enn 8- og 9-metersregelen i avvike kravene i teknisk forskrift Eksempler på dispensasjoner fra reguleringsplan/kommuneplan; overskridelse av tillatt grad av utnytting i kommuneplan/reguleringsplan (f.eks., høyere utnyttelse enn %-BYA=20%) avvike regulert bygningsutforming i regulerings- eller bebyggelsesplan bygge utenfor regulerte byggelinjer eller byggegrenser Søknad om dispensasjon skal: utformes i eget brev, nabovarsles og sendes inn sammen med søknaden om tillatelse / meldingen. Med refusjon, menes her å søke om å få dekket utgifter i forbindelse med utviding, fornying, omlegging av offentlig godkjent vei eller hovedledning for vann og avløp. For å få refusjon må tiltakshaver ha Side 18 av 68

19 utarbeidet et kostnadsoverslag som må godkjennes av kommunen på forhånd. Pbl slår fast at kommunen har ansvar og plikt til å føre tilsyn med at plan- og bygningslovgivningen overholdes i kommunen. Tilsyn Målet er å påse at aktørene i byggesaken gjennomfører sine oppgaver i henhold til ansvarsretten slik at tiltaket blir i samsvar med bestemmelsene gitt i eller i medhold av pbl. og tillatelsen. Det følger av pbl femte ledd, at igangsettingstillatelsen kan Igangsettingssøknad (IG) deles opp i henholdsvis søknad om rammetillatelse og igangsettingstillatelse (såkalt trinnvis søknadsbehandling). Endringstillatelse Midlertidig brukstillatelse (MB) Ferdigattest (FA) Tabell 4: Oversikt over sentrale begreper Side 19 av 68

20 3 Det langsiktige målbildet for Byggesøknadsløsningen Det langsiktige målbildet blir beskrevet for å gi Leverandøren en forståelse av hvilken retning Kunden ønsker at løsningen skal utvikles over tid. Målbildet går på mange områder utover de krav som kunden stiller til leveranse i fase 1 og 2 som leverandøren er forpliktet til å levere iht. denne avtalen. Det langsiktige målbildet beskrives i de påfølgende delkapitlene samt utdypes av tre vedlagte brukerhistorier som forklarer behovene til ulike roller i en byggesøknad. Brukerhistoriene beskriver tre ulike roller: 1. Garasjebyggeren Sjur: Privatperson som skal søke om å få bygget en garasje (Vedlegg XXX) 2. Petter Innbygger og Janne Saksbehandler: En noe mer erfaren søker som skal søke om tillatelse til tiltak i ny løsning (Vedlegg XXX) 3. Profesjonelle søkere: Hvordan profesjonelle søkere ønsker at søknadsprosessen skal fungere (Vedlegg XXX) 3.1 Brukeren i sentrum Målet med den nye Byggesøknadsløsningen, er å gi stor gevinst for alle involverte i en byggesak. Løsningen skal hele veien ha fokus på god brukeropplevelse både for den uerfarne og den profesjonelle søkeren i gjennomføringen av søknaden. Løsningen skal støtte brukerens ulike behov, og snakke til de ulike målgruppene på en god og effektiv måte. Den uerfarne søker ledes inn til en god, trinnvis veiledning med visuell støtte, mens den profesjonelle søkeren opplever at søknadsløsningen er effektiv å benytte til å levere byggesøknaden. Byggesøknadsløsningen skal også ivareta en god brukeropplevelse for andre involverte i byggesøknadsprosessen, som bare skal inn i løsningen i enkeltfaser (for eksempel naboer, ansvarlige foretak og sektormyndigheter som skal inn for å lese, avgi merknad eller signere). Figur 5: Brukergruppenes behov i sentrum Hele søknadsprosessen fra informasjonsinnhenting og søknad om tillatelse til tiltak og frem til anmodning om ferdigattest, gjøres gjennom søknadsportalen. Et viktig prinsipp i den nye løsningen er gjenbruk av informasjon. Informasjon som kommunen besitter eller som er registrert i offentlige registre lastes automatisk inn i de ulike søknadene og informasjon som søker har lagt inn på et tidligere tidspunkt gjenbrukes i påfølgende søknader. Side 20 av 68

21 3.2 Søke om byggetillatelse Når søkeren velger en eiendom i løsningen får han opp all relevant informasjon knyttet til den aktuelle eiendommen og tidligere byggesaker knyttet til den via portalen. Samtidig får søker tilgang til alle relevante kart og reguleringsbestemmelser for eiendommen. Byggesøknadsløsningen vil sørge for forenkling av søknadsprosessen gjennom sporvalg, som sørger for at søkeren vil bli skjermet for irrelevante felter. Disse sporvalgene blir tilpasset alle de ulike henvendelsestypene og søknader til kommunen. Søkere uten erfaring vil dermed få muligheten til å bli veiledet gjennom utfyllingen av henvendelser og skjemaer. F.eks. kan løsningen skal automatisk kunne velge tiltakstype basert på registrert informasjon om tiltaket (areal og evt. plassering ift. eksisterende bebyggelse). På den måten slipper søker å ta stilling til hva som er forskjell på påbygg og tilbygg, men trenger bare å konsentrere seg om å fylle ut nødvendig informasjon og evt. svare på nødvendige avklarende spørsmål som trengs for at løsningen kan sette rett søknadstype og tiltakstype. Erfarne søkere vil imidlertid kunne slippe å forholde seg til veiledende informasjon, og dermed kunne gjennomføre prosesstegene raskere og mer effektivt. Søkeren kan i Byggesøknadsløsningen tegne og plassere tiltaket som et polygon i kartet. Dette vil hjelpe søkeren med å plassere tiltaket i kartet og gir søkeren direkte oversikt over avstand til andre bygninger på tomten, nabogrense, vei, kommunalt vann og avløp m.m. Løsningen kan visualisere hvordan tiltaket vil se ut med ulike plasseringer på eiendommen, samt hvordan tiltaket vil passe inn i terrenget. Byggesøknadsløsningen automatiserer mest mulig av søkeprosessen, samtidig som den legger til rette for at aktivitetene som må utføres manuelt kan gjøres effektivt. F.eks. vil løsningen automatisk beregne hvilken utnyttelsesgrad det nye tiltaket vil gi på tomten og synliggjør for søkeren evt. avvik fra gjeldende regelverk og reguleringsbestemmelser Som et alternativ til å fylle ut store deler av søknaden manuelt i løsningen, kan søkeren velge å laste opp en BIM-modell på Byggesøknadsløsningen. BIM-modellen kan f.eks. være en garasjemodell eller husmodell utarbeidet av en garasje- eller ferdighusleverandør eller den kan være utarbeidet av arkitekten for akkurat det tiltaket som skal gjennomføres. Ved å legge inn BIM-modeller, fanger løsningen opp relevante data og legger dette inn automatisk i søknaden og søkeren må kun supplere søknaden med informasjon som ikke finnes i BIM-modellen. Dersom løsningen avdekker at tiltaket er utenfor gjeldende lover og bestemmelser vil søkerflaten gi et varsel om hvilke forhold dette gjelder. Forklaringer og referanser blir vist i søkerflaten, slik at søker kan finne ut hva som er problemet og hvordan det er mulig å løse det. Alternativt må søker velge å søke om dispensasjon for det aktuelle forholdet. For at søkeren til enhver tid skal få en oversikt over hvor mye tiltaket vil koste, er det implementert en gebyrkalkulator i brukerflaten som fortløpende angir gebyret. En vesentlig del av søkerflaten er også innsynet den gir søkeren i saksgangen. For søker og tiltakshaver er det viktig å ha oversikt over status i saksbehandlingen, og løsningen gjør det mulig å følge med på framdriften. Side 21 av 68

22 3.3 Innhenting av samtykke Før en søknad kan ferdigstilles og godkjennes kreves det for eksempel ved næringsbygg et samtykke fra myndigheter og løsningen skal automatisk avdekke dette behovet. Et eksempel er bygg som skal brukes som arbeidsplasser, der søker må innhente et samtykke fra Arbeidstilsynet. Videre skal den vise hva slags involvering det er behov for og den må åpne for at søkeren kan gjennomføre innhenting av nødvendig samtykke med tilhørende kommunikasjon fra de aktuelle myndighetene direkte via løsningen. Søkeren vil også kunne kommunisere med øvrige myndigheter og tredjepart, som de enten er avhengig av å få uttalelse fra, eller som kan bistå dem i utarbeidelsen av søknaden. En tredjepart vil i denne sammenheng kunne være naboer, arbeidstilsyn, miljømyndigheter, fylkesmann m.fl., men også aktører med delansvar i forbindelse med tiltaket (utførende, kontrollerende osv.). Løsningen har i denne forbindelse en funksjon som gjør det mulig for tredjepart å signere elektronisk på dokumenter, slik at søkeren kan oppfylle dokumentasjonskravene papirløst. 3.4 Nabovarsling Løsningen avdekker automatisk behov for å gjennomføre nabovarsling basert på informasjon registrert i søknaden og håndtere hele nabovarslingsprosessen i løsningen. Relevante elementer fra søknaden inngår automatisk i nabovarslingen. Aktuelle naboer som er lovpålagt å varsle vises i kartet og søkeren kan legge til evt. ekstra parter som skal motta nabovarsel. Naboer som mottar et nabovarsel kan logge seg inn i brukerflaten, der de kan se igjennom det utsendte nabovarslet med nødvendig dokumentasjon på tiltaket. Naboer kan signere for at de ikke har noen merknader til tiltaket eller de kan registrere eventuelle merknader til det foreslåtte tiltaket direkte i løsningen. Naboen får også informasjon om muligheter til å komme med merknader til byggesaken, hvilke rettigheter man har som part i en byggesak, hvem man kan kontakte og hva som vil skje videre i saksbehandlingen. Hvis berørte parter registrerer at de ikke har noen merknader, kan søknad om tiltak leveres før fristen for nabovarselet er utløpt. Når nabovarslingen er utført og eventuelle nabomerknader er mottatt, gjør løsningen det mulig for søker å redegjøre for hvordan disse blir ivaretatt. 3.5 Supplering av søknad Etter at søknaden er sendt inn, kan det være behov for flere oppfølginger og avklaringsrunder mellom søkeren, kommunen og eventuelle andre parter. Det kan for eksempel være behov for supplerende informasjon i en mangelfull søknad, eller at søknaden må revideres Løsningen skal gjøre det lett å holde oversikt og å se hva som er siste versjon av dokumenter. Det er også mulig for søker å skrive notater i søknaden om hva som er supplert og hvorfor. Suppleringen kan utføres på alle deler av søknaden, det kan tilføyes informasjon til BIM-modellen, det kan legges ved filer og det er mulig å supplere med annen metadata. Søkeren sine endringer blir markert både i tegninger og modeller, og dato for endringer blir registrert. Dersom noe informasjon legges til en søknad, vil det bli sendt beskjed om hva som er endret til saksbehandler, som kan gjøre en vurdering og raskt fatte et vedtak. Søker vil få oversikt over hvilke konsekvenser en supplering eller revidering vil ha på saksbehandlingen, eller om det vil medføre økt gebyromkostning eller involvering av andre myndigheter. Side 22 av 68

23 4 Felles krav til Byggesøknadsløsningen De følgende kapitlene beskrives behovene og kravene til løsningen. Dokumentene følger kategoriene i figur 6, og denne vil følge med som en veileder. Kravene og behovene i de ulike underkapitlene er utdypet igjennom brukerhistoriene i vedlegg 2 til dette bilaget. Figur 6 Dokumentets oppbygning Videre må løsningen enkelt kunne oppdateres og tilpasses endringer som for eksempel endringer i lovverk, nye nasjonale tjenester og revisjon av standarder. En oversikt over systemer som løsningen skal kunne kommunisere med finnes i kapittelet «Grensesnitt mot øvrige systemer». Det vises også til kapittel 2.2 hvor de ter gitt en beskrivelse av omgivelsene til løsningen, med oversikt over både eksisterende og tiltenkte tjenester. Det legges vekt på at Byggesøknadsløsningen skal gjøre bruk av nasjonale og kommunale fellesløsninger, utnytter informasjon fra grunndataregistre, støtter samhandling med kommunens fagsystemer og kan settes opp med en visuell profil som gjør at byggesøknadsløsningen kan fremstå som en integrert del av kommunens nettsider. Side 23 av 68

24 4.1 Grensesnitt mot øvrige systemer Kompletteres etter at avklaringer rundt teknologi og arkitektur er landet Nedenfor listes kort opp hvilke systemer dette prosessområder skal hente, avlevere og tilby data til. Krav til grensesnitt og hvilke type data er nærmere beskrevet i kapittel XXX. Løsningen skal hente data fra følgende systemer: Folkeregisteret Enhetsregisteret Matrikkel Sentral godkjenning Det offentlige kartgrunnlag (DOK) Kontakt og reservasjonsregisteret ID-porten Kommunens planregister og plankart Kommunens kartbaser Kommunens Fagsystem for digital byggesaksbehandling Kommunens Arkiv Løsningen skal levere data til følgende systemer: FIKS Innsendingstjeneste Løsningen skal tilby data til følgende systemer: Oversikt over byggesøknader til kommunenes innbyggerportal eller tilsvarende Løsningen skal kunne motta data fra følgende systemer: Kommunens Fagsystem for digital byggesaksbehandling 4.2 Kravtabeller Kundens spesifikke krav til byggesøknadsløsningen fremgår av Vedlegg 1 til dette bilaget (SSA-T Bilag 1 Vedlegg 1 Kravtabell). I kravtabellene er kravene gruppert etter kapittelnummerne i dette bilaget. Leverandørens bes å besvare hvorvidt leverandørens tilbudte løsning dekker de angitte kravene direkte i de vedlagte kravtabell i henhold til krav til utfylling i kapittel 1.2. Side 24 av 68

25 5 Krav til brukerflaten Å ivareta god brukervennlighet er et av de viktigste målene i brukerflaten. Man skal legge til rette for en effektiv søknadsprosess både for erfarne og uerfarne søkere. Brukerflaten må derfor tilpasses ulike roller og brukerens behov. Brukeren vil få veiledet dialog som er tilpasset det steget hvor man befinner seg i søknadsprosessen. Behovene og kravene i dette kapittelet, beskriver hvilke funksjoner løsningen må ha for at brukerflaten skal være et godt og effektiv arbeidsredskap. Figur 7: Selvhjulpne brukere Side 25 av 68

26 5.1 Krav til løsningen Skissen under viser hvilke tjenester som løsningen skal tilby til brukere av løsningen. Hvilke av tjenestene som er relevante for en gitt søker, vil avhenge av tiltaket man skal utforme. Figur 8 Oversikt over tjenester som løses i byggesøknadsløsningen Brukerflaten skal være inngangsporten til alle søknadsoppgaver for søker, fra informasjonsinnhenting og forarbeid til avslutning av søknadsprosessen. Det skal være lett å orientere seg for søker, og det vil være oversikt over fremdriftsinformasjon og stegene man må igjennom. Alle stegene skal være synlig fra begynnelsen, og stegoversikten skal kunne brukes til å navigere mellom de ulike stegene, og eventuelt mellom ulike søknader dersom det er aktuelt. Det vil være hensiktsmessig å tilpasse brukerflaten for de ulike søkergruppene, siden de stiller med ulik kompetanse, erfaringer og forutsetninger for å kunne levere en komplett søknad. Søkere uten erfaring vil få muligheten til å bli veiledet gjennom utfyllingen av henvendelser og skjemaer. Erfarne søkere vil imidlertid kunne slippe å forholde seg til veiledende informasjon, og dermed kunne gjennomføre prosesstegene raskere og mer effektivt. Løsningen vil sørge for forenkling gjennom sporvalg, slik at søkeren vil bli skjermet for irrelevante felter. Ved hjelp av funksjonen kladd, kan brukeren prøve seg frem, og planlegge hvordan tiltaket vil se ut på sin eiendom. Man vil få varsler underveis dersom man går utenfor mulighetsrommet. Se eksemplet på bildet under: ( Side 26 av 68

27 Figur 9: Eksempel på mulighetsrom og plassering av tiltak i kart Videre i søknadsprosessen, kan søker også legge inn BIM-modeller i løsningen, og kunne spare seg for mye arbeid med utregning av areal og utnyttingsgrad. Ved å legge inn BIM-modeller, fanger løsningen opp relevante data og legger dette inn automatisk i søknaden. Søker vil imidlertid ha mulighet for å korrigere data, ved behov for justeringer. Dette vil spesielt være aktuelt, dersom søkeren legger inn informasjon som ikke stemmer overens med planer og reguleringer. Det gjøres oppmerksom på at det er et pågående arbeid med å definere et BIM-format som kan inngå som godkjent dokumentasjon i byggesøknaden, men det oppfordres til at leverandøren av byggesøknadsløsningen inngår samarbeid med leverandører av BIM/prosjekteringsløsninger mtp. å kunne integrere direkte med eksisterende løsninger i markedet. I brukerflaten skal søkeren slippe å åpne ulike vinduer i nettleseren, ettersom alt arbeid skal foregå i brukerflaten. Forhåndsvisning gjør det mulig å se på dokumenter uten å måtte åpne dem i eksterne programmer. Søker må også kunne utføre ulike fritekstsøk i brukerflaten. Det er ønskelig med en brukerflate som automatiserer mest mulig av søkeprosessen, mens den samtidig legger til rette for at aktivitetene som må utføres manuelt kan gjøres effektivt. All kommunikasjon med saksbehandler, naboer, kommune, øvrige myndigheter osv., skal det være mulig å gjennomføre i brukerflaten. Alle aktører og myndigheter skal også dele informasjon i brukerflaten, slik at avklaringer kan bli foretatt raskt. De viktigste målgruppene for løsningen finnes det en oversikt over i kapittel 0. I brukerflaten skal det være mulig for søker å følge med på status på saken og søknaden sin, slik at de slipper å kontakte kommunen dersom de lurer på noe. Brukerflaten gir søker oversikt over når kommunens behandlingsfrist går ut, og får også mulighet til å legge inn egne tidsfrister. Brukerflaten må kunne settes opp for å vises med layout/design og informasjonselementer tilpasset den enkelte kommune, slik at løsningen kan oppfattes av bruker som en integrert del av kommunens nettsider. Side 27 av 68

28 5.2 Brukerutfordringer i dag Følgende er identifisert som utfordringer knyttet til dagens søknadsløsninger: Søkere og andre interessenter har ikke mulighet til å finne ut hvor langt søknaden har kommet i saksbehandlingen, og må kontakte kommunen for å finne ut av det. Det er uoversiktlig for søker med mange søknader inne å holde oversikt på status for den enkelte søknaden. Det er vanskelig å få en forståelse av hvilken informasjon som kommunen krever, og hvilket format det skal leveres i. Det er for mye faguttrykk/ stammespråk i forklaringene og beskrivelsene av hvordan man skal utfylle søknader. Tilbakemeldinger fra Byggsøk er at teksten som forklarer framgangsmåten er for lang og omstendig til at den er forståelig. Side 28 av 68

29 6 Informasjonsinnhenting En ny byggesøknadsløsning, må enkelt og raskt kunne gi ulike typer søkere en god oversikt over hvor de kan finne relevant informasjon både om sin eiendom, aktuelt regelverk, og om selve søknadsprosessen. Før man går i gang med selve søknadsprosessen, vil det være hensiktsmessig for søker å få sjekket ut forhold som kan være avgjørende for prosjektet (gebyrkostnader, regelverk, saksgang og avklaringer av tredjeparts interesser). I denne fasen vil søker kunne foreta en realitetsorientering og kvalitetssjekk av prosjektplanene. Mulige utfall av prosessen kan være en bekreftelse av at man er på rett vei, at man må gjøre justeringer i prosjektet eller at man velger å kutte ut. 6.1 Felles krav til informasjonsinnhenting Løsningen må kunne selvbetjenes av søkeren, uavhengig av erfaring. Søker vil få nødvendig veiledning via brukerflaten ved behov. For eksempel vil man kunne se på ulike eksempler som kan hjelpe brukerne til å finne ut hvilken kategori et tiltak vil falle inn under. Eksemplene må også støtte brukeren i å finne ut hvilken dokumentasjon som kreves i søknaden, og hvordan denne dokumentasjonen skal fremskaffes. Faguttrykk og begreper forklares ved at søkeren kan klikke på ordet, og deretter få opp en boble med ordforklaring. I løsningen kan søkeren ta kontakt med sin kommune om man har spørsmål som man ikke finner hjelp til å løse i Byggesøknadsløsningen. Siden de fleste i dag benytter søkemotorer på Internett til å finne frem til relevant informasjon, er det viktig at byggesøknadsløsningen legger til rette for at søkemotorer gir gode treff på relevante søkeord, og at treffene leder brukeren rett inn på sider med relevant informasjon. Videre vil kommunenes egne nettsider kunne være viktige inngangsporter for brukerne. Derfor er det et mål at standardisert informasjon fra Byggesøknadsløsningen kan gjøres tilgjengelig via kommunens egne nettsider, slik at ikke hver kommune må vedlikeholde denne informasjonen separat og at brukerne finner konsistent informasjon om byggesøknadsprosessen på tvers av kommunene. Informasjonen som er tilgjengelig i byggesøknadsløsningen, må til enhver tid være korrekt og oppdatert i henhold til siste gjeldende lover og regler. En del av informasjonen vil kunne være standardisert, mens andre deler av informasjonen vil kunne tilpasses kommunens spesifikke behov. Det må være en tydelig avgrensning på hvem som forvalter hvilken informasjon. Oppdatering av informasjon, omstrukturering og forandring må kunne skje på en enkel og intuitiv måte for kommunen. Det må gis en klar oversikt over gebyrer, slik at søker kan få et estimat på totalsummen på søknaden tidlig i søknadsprosessen. Det må også gis en oversikt over tiden dette vil ta, og hvilke frister søker må forholde seg til. Søker kan enkelt foreta utregningen via for eksempel en gebyr-app, med link fra informasjonssidene. I mange tilfeller er det kjent at kart og annen informasjon kan gi motstridende opplysninger, for eksempel i en kommuneplan og reguleringsplan. I de tilfellene det er kjent, skal det informeres og forklares av hvem og i hvilket trinn det må gjøres avklaringer og vedtak på hva som er det sist gjeldende. Side 29 av 68

30 All informasjon som er tilgjengelig på kommunens hjemmesider i forbindelse med byggesøknadsprosessen skal være tilgjengelig i løsningen, enten via linker eller ligge direkte i informasjonsportalen. Informasjon som ikke er tilgjengelig digitalt, men som brukeren trenger, skal beskrives nærmere. Det må også opplyses om hvordan søker kan få tilgang til denne informasjonen. Søker kan få informasjon både som: Tekst Video «Ofte stilte spørsmål» Kart og illustrasjoner Prosesskart for ulike type søknader Brukerutfordringer i dag Følgende er identifisert som utfordringer knyttet til informasjonsinnhenting og forarbeid i dag: Manglende digitale plandata På kommunenes hjemmesider møter søkere for mye (i volum) informasjon, og den er fremstilt på en uoversiktlig måte Det er vanskelig å forstå hva som er relevant av tilgjengelig informasjon Informasjonen er fremstilt på et lite brukervennlig språk, og ikke alle søkere skjønner at å søke om tillatelse til tiltak er det samme som å søke om å bygge garasje eller veranda Det er vanskelig å vite hva som er søknadspliktig og ikke søknadspliktig Det brukes mange faguttrykk og fremmedord for søkere Det er vanskelig å få oversikt over prosessen i seg selv, da det ikke finnes/vises noe prosesskart Det er lite informasjon om eiendom og byggesaker tilgjengelig digitalt Mangler oversikt over ansvar og roller i søknadsprosessen, hva skal man gjøre selv, hva skal andre gjøre Det er vanskelig å komme i gang fordi man ikke har oversikt over hva som er gjort på en eiendom tidligere Brukerne savner en beskrivelse på hva planbestemmelser er, hvordan man finner frem til de og hvordan de skal tolkes (både tolkning av hva bestemmelsene betyr og hvordan de gjelder ift. f.eks. kommunedelplan). Kartsystemet har et krevende brukergrensesnitt som er vanskelig å bruke uten veiledning Savner veiledere som kan komme med gode eksempler på lignende situasjoner Informasjonskanalene som finnes i dag er for tungvinte, og det å åpne den tar for lang tid Søkeprosessen virker for komplisert for søker Det er stor usikkerhet blant søkere om når en søknad er komplett Det er vanskelig å vite hvilke skjema som skal benyttes, og hvilke lover og regler som gjelder i hvert tilfelle Kartsystemet er for vanskelig i dag, søkere trenger hjelp til å tegne skisser Søkere lurer på hva en dispensasjon er og når det vil være aktuelt å måtte søke om dispensasjon 6.2 Se eiendom Under utarbeidelse Dette kapittelet er foreløpig dekt av brukerhistorier i vedlegg 2, samt delvis i øvrige kapittel, men vil bli omskrevet til å være et eget kapittel Krav til løsningen Side 30 av 68

31 6.3 Veiledning Både erfarne og uerfarne søkere har behov for veiledning i byggesøknadsprosessen. Det er derfor viktig at byggesøknadsløsningen tilgjengeliggjør og referer til relevant veiledningsmateriell som søker kan ha behov for Krav til løsningen Løsningen må tilgjengeliggjøre relevante veiledninger for brukerne. Det er avdekt følgende behov for veiledere: - Veileder for å avklare om et planlagt tiltak er søknadspliktig - Veileder for å avklare om et tiltak er kan søkes om uten ansvarsrett - Veileder til søknadsprosessen Løsningen bør så langt det er mulig benytte tilgjengelig materiell fra DiBK eller andre nasjonale kilder, slik at minst mulig informasjon iht. lov og regelverk må vedlikeholdes internt i løsningen. 6.4 Kladd Tiltakshavere og mindre rutinerte søkere vil ha behov for å kunne prøve ut byggesøknadsløsningen, uten at det nødvendigvis resulterer i søknad og formell saksgang. Jo mer detaljert informasjon man legger inn i en kladdesøknad, jo mer relevant innsikt vil man kunne tilegne seg Krav til løsningen Krav og behov til Kladd vil i hovedsak være de samme som til selve søknaden, med følgende presiseringer: Det skal gå an å fylle ut en kladd uten å være autentisert/logget inn, men man vil da gå glipp av funksjonalitet som forutsetter innlogging (pre-utfylling, lagringsmulighet og evt. innsynstilgang). Det skal gå an å eksportere informasjon fra en kladd til pdf-format. For å lagre en kladd, for senere bruk, må man logge seg inn. Når man er innlogget, har man tilgang til all funksjonalitet i Byggesøknadsløsningen. En lagret kladd skal kunne redigeres og slettes. Informasjon fra en kladd skal kunne gjenbrukes (pre-utfylles) i en anmodning om forhåndskonferanse. Det skal være mulig å overføre en kladd til en annen bruker av Byggesøknadsløsningen (for eksempel når tiltakshaver har opprettet kladden, og en ansvarlig søker skal overta). 6.5 Forhåndskonferanse Forhåndskonferanse avholdes før innsending av søknad. Forhåndskonferansen består av trinnene: 1. Anmodning om forhåndskonferanse 2. Gjennomføring og signering av referat Krav til løsningen Behovet for forhåndskonferanse oppstår før en søknad blir sendt inn. Målet er at det ikke skal være behov for forhåndskonferanser, men at informasjonen som ligger tilgjengelig for søker er tilstrekkelig. I en ny løsningen skal det være mulig å gjennomføre forhåndskonferansen digitalt, slik at personlig oppmøte ikke lenger er nødvendig. Side 31 av 68

32 Anmodning om forhåndskonferanse Hovedmotivasjonene for å bruke forhåndskonferanse, er å få avklart ulike forhold knyttet til tiltaket. Tiltakshaver legger frem byggeplanene for kommunen, og kommunen orienterer om innholdet i kommunale planer og andre bestemmelser og krav som er relevante for byggeplanene. Dette bidrar til at tiltakshaver får belyst aktuelle problemstillinger ved tiltaket og gjøres kjent med relevante krav og forutsetninger for den videre saksbehandling. Kommunen skal også opplyse antatt saksbehandlingstid. I en forhåndskonferanse skal søker kunne få informasjon om: Rammeforutsetninger og krav knyttet til arealplaner Infrastruktur, aktuelle lover Forskrifter og retningslinjer Dokumentasjonskrav Krav til plassering av tiltaket Behov for koordinering med aktuelle myndigheter, jf. PBL 21-5 Kommunens praksis Saksbehandlingsrutiner Mulighet for delt saksbehandling Uavhengig kontroll, tilsyn Ansvarsregler Krav til ansvarlige foretak I forhåndskonferansen står kommunen ansvarlig for å skrive referat, og dette skal bli signert av tiltakshaver og kommunens representant. Referatet skal følge med som saksdokument i den videre saksbehandlingen Gjennomføring og signering av referat Forhåndskonferansen kan brukes i alle typer tiltak etter plan- og bygningsloven, uavhengig av størrelse og vanskelighetsgrad. I de tilfellene der søker eller tiltakshaver ønsker å gjennomføre en forhåndskonferanse, understøtter løsningen visning av relevant dokumentasjon via brukerens brukergrensesnitt og referatet kan signeres elektronisk i møtet. Signert referat sendes automatisk ut til partene og arkiveres, og skal følge med som saksdokument i den videre saksbehandlingen. All dokumentasjon, relevant kommunikasjon og referat arkiveres for å kunne gjenbrukes ved en eventuell senere søknad. Det opprettes en kobling mellom forhåndskonferansen og aktuell sak i saksbehandlingssystemet slik at det er enkelt å finne det senere Brukerutfordringer i dag Følgende er identifisert som utfordringer knyttet til forhåndskonferanse i dag: Det er vanskelig for søker å avgjøre hva som er nødvendig og aktuell informasjon å sende inn til kommunen ifbm. anmodning om forhåndskonferanse. Det tar ofte 2 uker før det blir kalt inn til en forhåndskonferanse, noen søkere velger derfor å møte fysisk og stille spørsmål til saksbehandlere direkte for å spare tid. Det er vanskelig å forstå hva en forhåndskonferanse innebærer og hvem som skal delta, og hva som eventuelt må være klart på forhånd. Side 32 av 68

33 7 Krav til søknad Figuren nedenfor viser hvor «Søknad og dokumentasjon» er plassert i dokumentet, og hvilke elementer kapittelet består av. «Søknad og dokumentasjon» omfatter alle søknader som blir sendt inn til kommunene, i tillegg til krav til dokumentasjon dersom en søknad for eksempel krever varsling av naboer, uttalelse fra sektormyndighet, m.m. Søknadene og dokumentasjoner er samlet i et kapittel fordi disse aktivitetene stiller en del felles krav til løsningen. Disse felleskravene blir beskrevet innledningsvis, før det kommer en mer detaljert beskrivelse av behovet knyttet til de ulike søknadene. 7.1 Felles for alle søknader For at søknadsprosessen skal bli mest mulig brukervennlig for søker, skal det i løsningen være lagt inn sporvalg for de ulike søknadene og henvendelsene. Løsningen vil automatisk veilede søker inn på henvendelsestype ut i fra det søker har registret av informasjon, eller som løsningen allerede har hentet inn fra et tidligere steg i søknadsprosessen. Tidligere søknader kan kopieres og gjenbrukes som mal for en ny søknad og informasjonen som en søker har lagt inn på et tidligere tidspunkt i saken kan alltid bli gjenbrukt. Ved behov kan søker endre metadata som er lagt inn, og informasjonen som gjøres tilgjengelig for søker endres som en følge av dette. Løsningen viser de grove trekkene i saksbehandlingsprosessen som søker må forholde seg til, og tilhørende frister som er gjeldende for søknaden. Dersom søknaden er av en art som krever en ansvarlig søker gir løsningen tydelig informasjon om dette og veiledning i hvordan søknaden skal opprettes. Løsningen forhindrer at søknaden kan bli sendt inn dersom søker ikke er registrert som godkjent ansvarlig søker for den gjeldende tiltaksklassen. Søknader som det er registrert at inneholder en feil kan ikke sendes inn uten at søker bekrefter at det blir sendt inn en ikke-komplett søknad. Søker får informasjon om at søknaden kan stå i fare for å bli avvist grunnet mangler ved søknaden og må kunne beskrive i søknaden hvorfor manglene ikke Side 33 av 68

34 kunne rettes opp før innsending. Denne samme oversikten over mangler vil følge med søknaden når den sendes inn til kommunen. I det søknaden er sendt inn får søkeren beskjed om at søknaden er mottatt, hvem som er tildelt saken og forventet behandlingstid. Løsningen gjør det mulig å se status på kommunens behandling av søknaden direkte i brukerflaten. Søknaden blir lagret slik at søkeren til enhver tid har tilgang til informasjonen som er registrert. Det er mulighet for å lagre all kommunikasjon i forbindelse med søknaden, for eksempel notater, og andre tilbakemeldinger. I flere av blankettene blir det henvist til nye blanketter, forskrifter eller føringer. All informasjon som kreves i blanketter som det er henvist til, skal det være mulig å registrere i løsningen. Et eksempel er i blankett 5174 «Søknad om tillatelse til tiltak». Her henvises det blant annet til skjema 5175 «Opplysninger om tiltakets ytre rammer og bygningsspesifikasjon». Søkeren blir her bedt om å oppgi bebyggelsens størrelse og grad av utnytting, og det henvises til TEK10 og NS Løsningen skal ha implementert de aktuelle veilederne og forskriftene, og henter fram den informasjonen som er aktuell og som gjøre det lett for søker å fylle inn korrekt informasjon. Løsningen må også kunne gjøre det mulig å registrere: At alle ansvarsforhold er dekket At all nødvendig dokumentasjon er vedlagt Utsjekking mot det offentlige kartgrunnlag med temakart; ras, flom, radon, kulturminner osv. Etterlevelse av plan- og bygningsloven og saksbehandlingsforskriften Etterlevelse av gjeldende planer, herunder reguleringsplaner og kommuneplan At samtykke fra øvrige myndigheter foreligger At det er lagt ved søknad om nødvendige dispensasjoner At privatrettslige forhold er avklart Forskrift om saksbehandling åpner for at eier selv kan ta ansvar for hele eller deler av arbeidet i stedet for å engasjere ansvarlige foretak. Forutsetningene for dette er: Tiltaket skal være i tiltaksklasse 1 Bygningen skal være til eget bruk I dette tilfellet må det kunne registreres i løsningen at søker står ansvarlig for å bygge tiltaket og at søker garanterer og sikrer at regelverket følges. Dersom eier skal ha alt ansvar selv, er det ikke krav til gjennomføringsplan. Sammen med innsending av søknad om ferdigattest må selvbygger kunne sende inn en erklæring på at arbeidene er utført i samsvar med regelverket Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Mange uerfarne søkere har for lite søkerkompetanse, for dårlig innsikt i søknadsprosess og i kravene til innhold. I alle tiltak hvor det skal være ansvarlige foretak er det krav til å utarbeide gjennomføringsplan. Planen kan fort bli en komplisert matrise, og det kan være vanskelig å holde orden på hvor langt de ulike ansvarsområdene har kommet; hva er det avgitt samsvarserklæring på og når er denne avgitt? Er området avsluttet? Osv. Mye dokumentasjon fra tiden før 2000 foreligger ikke digitalt, og søkere må møte opp i arkivet og lete. Man kan også bestille dette digitalt, men leveringstiden fra arkiv er ofte syv til ti dager. Mange av de gamle tegningene foreligger kun i A1-format, dersom endringer blir gjort her må ny løsning ta stilling til dette. Side 34 av 68

35 I forbindelse med ferdigattest er det trangt med tid, og ansvarlig søker velger i enkelte tilfeller å sende inn attesten for tidlig når ikke alt er ferdig enda. Dette er fordi folk er klare til å flytte inn og søkere er engstelige for kommunenes saksbehandlingstid. Lite er automatisert Det er lite gjenbruk av informasjon og data som søker registrerer i blanketter Det er vanskelig å få en forståelse av hvilken informasjon som kommunen krever siden kommunene ber om forskjellig dokumentasjon, og det vanskelig å forstå hvilket format alt skal leveres i. Ansvarlig søker opplever det som utfordrende å holde orden på ansvarsområder, foretak og samsvarserklæringer. Et søknadssystem bør kunne kobles mot søkers fagsystem for automatisk overføring av data til gjennomføringsplanen. 7.2 Varsling av gjennomført byggetiltak under 50kvm Ikke utarbeidet Hensikten med dette steget, er at søker skal kunne registrere og sende inn varsel til kommunen om tiltak under 50 kvm som fra 1. juli 2015 er unntatt søknadsplikt er gjennomført. Krav til hvordan dette funksjonelt skal løses er under utarbeidelse Beskrivelse Brukerutfordringer i dag 7.3 Søknad om byggetillatelse (tillatelse til tiltak) Hensikten med dette steget er at søker skal kunne utforme og sende inn en søknad om byggetillatelse til kommunen med nødvendig underlagsdokumentasjon. En komplet søknad skal dekke kommunens og øvrige aktører informasjonsbehov i forbindelse med behandling av byggesøknaden. Byggesøknaden kan være av typen ett-trinnssøknad, søknad om rammetillatelse eller søknad uten ansvarsrett. For at det skal være mulig å velge eller bytte søknadsform underveis i prosessen med utarbeidelsen av en søknad, er alle de tre søknadstypene samlet under en felles paraply som heter søknad om byggetillatelse (tillatelse til tiltak) Beskrivelse av krav Søker eller tiltakshaver skal enkelt kunne starte på en ny søknad om byggetillatelse eller hente opp tidligere eller påbegynte søknader om byggetillatelse. En søknad om byggetillatelse vil fungere som «toppdokumentet» i byggesøknaden, som syr sammen de ulike elementene som den aktuelle byggesaken består av sammen til en komplett søknad som kan signeres og sendes inn til kommunen. Alle felter der informasjonen som skal registreres i blankettene «Søknad om tiltalelse til tiltak» (nr og 5175) og «Søknad om tillatelse til tiltak uten ansvarsrett» (nr. 5153) og som er aktuelle for tiltaket det søkes om, skal i søknadsprosessen bli tilgjengeliggjort for søker. Mens søknad om tillatelse uten ansvarsrett kun er aktuell når det er tiltakshaver selv som står som søker og tiltaket er av en slik art at det faller inn under bestemmelsene in PBL 20-2, vil søknad om tillatelse til tiltak som rammetillatelse eller søknadsbehandling i ett-trinn være kunne være aktuelle både for profesjonelle søkere med ansvarsrett og saker hvor tiltakshaver enten planlegger å erklære selvbyggeransvar eller starter med å fylle ut en søknad som del av sin informasjonsinnhenting, for senere å evt. overføre en delvis utfylt søknad til en profesjonell aktør som kan erklære ansvarsrett som ansvarlig søker. Side 35 av 68

36 En søknad kan både være det første en søker oppretter, for deretter å utfylle aktuelle delelementer i søknaden (slik som beskrivelse av tiltak, nabovarsling m.m.) eller det kan være at det er gjennomført en forhåndskonferanse eller nabovarsling tidligere og at informasjonselementer fra disse prosessene nå ønskes knyttet inn i en ny søknad. Nå søker starter utfylling av søknaden må han veiledes igjennom valg av hvilke delelementer som må fylles ut ifm. søknaden (gjennomføringsplan for søknader med ansvarsrett, nabovarsel, evt. dispensasjoner m.m.) Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Det er vanskelig å ha oversikt over hvilken informasjon kommunen har behov for og i hvilket format det skal sendes inn Det er utfordrende å forstå hvilket ansvar man har som søker Søker må oppgi samme informasjon flere ganger, noe som tidkrevende 7.4 Igangsettingstillatelse Hensikten med dette steget er at søker skal kunne registrere og sende inn nødvendig data som dekker informasjonsbehovet til kommunen og øvrige aktører i forbindelse med igangsettingssøknader. Søknad om igangsetting er kun aktuelt i byggesaker hvor det foreligger en rammetillatelse Beskrivelse av krav Løsningen skal gjøre det mulig for søker å registrere all informasjon som krever i skjemaet « Søknad om igangsettingstillatelse». Hvis det er gitt en rammetillatelse må det søkes om igangsetting av byggearbeid i en eller flere egne søknader. Søker må kunne angi om det søkes om igangsettingstillatelse for hele eller deler av tiltaket. Ved delt igangsetting må det være tydelig når de ulike tillatelsene er gitt, hvilken prosjektering som er avsluttet og hva som står igjen. Søker får også mulighet til å velge hvilken byggesak det skal søkes om igangsettingstillatelse på. Hvis rammesøknaden er levert via brukerflaten kan søkeren få opp en ny søknad om igangsettingstillatelse hvor all tidligere og aktuell informasjon er fylt ut. Dersom det på et tidligere tidspunkt er sendt inn delsøknader i den samme saken, vil løsningen gjøre det mulig å gjenbruke en tidligere utfylt søknad om igangsettingstillatelse, slik at informasjon som ansvarsretter m.m. som er felles, ikke må legges inn på nytt. Informasjonen fra forrige søknad som ikke lenger er relevant kan enkelt slettes. Videre gjør løsningen det mulig å legge ved vedlegg som søknaden, dette er erklæringer om ansvarsretter, oppdatert gjennomføringsplan og oppfyllelse av vilkår i rammetillatelse. En søknad om igangsettingstillatelse er basert på en allerede sendt inn søknad som har fått et positivt vedtak. At det foreligger et vedtak som godkjenner tiltaket kontrollerer søknaden automatisk Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Side 36 av 68

37 For søker er det vanskelig å holde oversikt over historikken av del-igangsettingssøknadene som er gitt. 7.5 Midlertidig brukstillatelse og ferdigattest Hensikten med dette steget er at søker skal kunne registrere og sende inn nødvendig data som dekker kommunens og øvrige aktører informasjonsbehov i forbindelse med søknader om midlertidigbrukstillatelse og ferdigattest Beskrivelse av krav Løsningen skal kunne registrere all informasjonen som skal inn i blankettene som foreligger i dag når det skal søkes om midlertidig brukstillatelse og ferdigattest. I forbindelse med en søknad om midlertidig brukstillatelse og ferdigattest må løsningen gjøre det mulig å angi gjenstående arbeider av mindre vesentlige betydning, innenfor den delen av tiltaket det søkes midlertidig brukstillatelse for. Videre må det være mulig for søker å angi resterende deler av tiltaket hvor det ikke søkes om midlertidig brukstillatelse. Disse områdene kan tegnes inn i tiltaket tegneløsningen og søker kan markere de gjeldende delene i brukerflaten. Søker må også kunne registrere og vise til bekreftelse på at tiltaket har tilstrekkelig sikkerhetsnivå til å bli tatt i bruk. I tillegg må søker kunne beskrive hvilke type arbeid det gjenstår å få klarert sikkerhetsnivå på og angi når arbeidene vil være utført og være tilgjengelige for kommunen. Dersom det er foretatt søknadspliktige endringer eller justeringer i forhold til opprinnelig tillatelse, må det være mulig å registrere og sende inn oppdatert informasjon som viser hva som er utført. Ofte haster det med å få midlertidig brukstillatelse på plass, og i løsningen gis det fleksibilitet på hvilke muligheter kommunen tilbyr. For eksempel kan man sende inn anmodning om brukstillatelse/ferdigattest før arbeidet er ferdigstilt og samtidig informere om at siste samsvarserklæringer og oppdatert gjennomføringsplan vil ettersendes ved en gitt dato. Det gir Side 37 av 68

38 kommunen mulighet til å være fleksibel ved å foreta gransking av saken før den er komplett og gi tilbakemelding om evt. mangler og f.eks. kladde ferdig vedtak på forhånd. Hvis det var stilt vilkår i tidligere vedtak kommer det opp i brukerflaten, slik at søker kan svare og dokumentere at de er imøtekommet. Løsningen skal gjøre det mulig for søke å sende inn ukomplett søknad slik at saksbehandler har mulighet å starte behandlingen. Det skal være mulighet for søker å supplere med resterende dokumentasjon innen den dato som er angitt som «ferdigdato». Avfallsplanen skal sendes inn i forbindelse med en ferdigattest. Kravene til denne rapporten står beskrevet i kapittel Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Søker har på dette tidspunktet ofte hastverk, da det er folk som ønsker å flytte inn. Det er derfor viktig å kunne følge med på status på søknaden. Dette er ikke lett å få til i dag med mindre søker har en god dialog med saksbehandler. Det er vanskelig for søker å forstå hvilken informasjon kommunen har behov for i de ulike søknadene. 7.6 Søknad om endringstillatelse I en søknad om endringstillatelse søkes det om en endring i en gitt tillatelse, altså i en sak som det allerede er fattet vedtak i. Hvis det ikke er fattet vedtak kan søknaden i stedet for følges opp med en supplering eller revidering Beskrivelse av krav Størrelsen i endring i et fattet vedtak kan variere fra en liten justering som ikke har signifikant betydning for involverte parter eller større endringer som krever en helt ny behandling av tiltaket. Det er utfordrende å standardisere søknad på endringstillatelse på grunn av spennet av typer endringer et tiltak kan få, samt at vurderingene om behovet er skjønnsmessig basert, og særdeles kommunespesifikt. Søkerflaten skal allikevel tilby generelle retningslinjer om endringer som utløser behov for en endringssøknad, f.eks. «Dersom en endring i tiltaket endrer de ytre rammene og naboer kan bli påvirket, må du sende inn en søknad for endringstillatelse». Fra og med 1. januar 2016 skal ikke endring av ansvarsrett utløse behov for å sende inn en søknad om endringstillatelse. Ved endring av ansvarsrett skal det kun sendes inn en erklæring om endrede ansvarsforhold og en justert gjennomføringsplan. Ny løsning skal gjøre det mulig for søker å registrere all informasjon som krevet i blankett « Søknad om endring av tillatelse» i søkerflaten. Samtidig skal irrelevante felter i en søknad automatisk filtreres bort basert på informasjon (input) til søknaden som søkeren etter hvert registrerer. Søkeren skal enkelt kunne hente inn en godkjent byggesøknad for å foreta endringer, og sende inn endringene som en søknad om endringstillatelse. Løsningen må muliggjøre automatisk endringslogg ved endringer i f.eks. BIM-modell slik at saksbehandler kan oppdage hvor endringen finner sted raskest mulig. Samtidig må løsningen tilgjengeliggjøre en manuell beskrivelse (fritekst og standardvalg) hvor søkeren kan beskrive hvilke endringer det er søkt om. Små endringer bør innarbeides i as-built ved ferdigattest. Side 38 av 68

39 7.6.2 Brukerutfordringer i dag Søknad om endringstillatelse gjøres i dag gjennom byggesøknadsløsning, Byggsøk, og gjennom blanketter. Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Søker synes det er utfordrende å forstå når det er behov for en endringstillatelse standardisert og generell veiledning om behov for endringssøknad skal tilbys i søkerflaten. Søkere har kommentert at det er vanskelig å forstå hva slags informasjon som skal sendes inn søkerflaten må derfor filtrere bort felter som ikke er relevant for omfanget av endringen som det søkes på. Søker har ikke kunnskap om endringssøknaden vil påvirke tidsfristene for søknaden En søker som ønsker å endre på flere ting av ulik omfang skal sende én søknad, og ikke flere søknader. 7.7 Refusjon Der det er krav om at noe må opparbeides før man kan få bygge; for eksempel adkomstvei, gangvei, VA eller liknende, kan man kreve refusjon fra naboer som skal ha del i fellesanlegget. For å få rett til refusjon, kreves det en særskilt framgangsmåte som er beskrevet i PBL. Det må søkes kommunen om rett til refusjon. En godkjenning av dette, med en fordelingsnøkkel for utgiftene, må foreligge før arbeidet igangsettes. Ettersom dette ikke er en funksjon søker vil ha behov for så ofte i brukerflaten, anses det som tilstrekkelig krav at søker får veiledning til å fylle ut en søknad, samt mulighet til å be om et møte med kommunen for nærmere gjennomgang av refusjonsgrunnlaget Beskrivelse av krav Løsningen skal gjøre det mulig for søker å beskrive tiltaket, og se hvem som berøres. Partene i saken skal ha mulighet til å kunne se søknaden, konsekvens- og kostnadsberegning, samt at de skal kunne avgi merknad. Løsningen skal også bidra til å oppnå mer standardiserte refusjonsprosesser. Det er enkelt å finne, utarbeide og/eller legge ved i søknaden (der det er aktuelt): Kart og dokumentasjon på hele refusjonstiltaket Grunnlag for beregninger Høringsuttalelser Kostnadsoverslag Tekniske planer Forslag til fordeling av utgiftene Uttalelse og varsel til berørte grunneiere og festere Kommunens godkjenning av planer og kostnadsoverslag Kommunens vedtak om foreløpig beregning av refusjon Anledning til uttalelse til gitt pristilbud Tilleggsutligning Renter ved betaling i årlige terminer Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Mangler en oversikt over prosessen og hvordan dette skal gjøres Side 39 av 68

40 Side 40 av 68

41 8 Krav til elementer i søknad Dette kapittelet gir en oversikt over elementer som kan eller skal inngå i en eller flere av de søknadskategoriene som er beskrevet i forrige kapittel. 8.1 Utforme og beskrive tiltak ikke utarbeidet Dette kapittelet er foreløpig dekt av brukerhistorier i vedlegg 2, samt delvis i øvrige kapittel, men vil bli omskrevet til å være et eget kapittel Beskrivelse av krav Brukerutfordringer i dag 8.2 Nabovarsling Hensikten med dette steget, er å sørge for at det å lage og sende ut nabovarsel kan gjøres effektivt og enkelt digitalt. Dette gjøres direkte i brukerflaten hvor all nødvendig informasjon om tiltaket allerede er lagt inn Beskrivelse av krav Løsningen legger til rette for at søkeren skal slippe å vurdere selv om det skal foretas nabovarsling. Hvorvidt nabovarsling skal foretas eller ikke, baseres på informasjon som søkeren legger inn i søknaden. Søker om igangsettingstillatelse vil imidlertid nabovarslingsfeltene være unntatt fra brukerflaten, og man slipper å forholde seg til det. Side 41 av 68

42 Basert på informasjon som søker legger inn (tiltak med målsatt situasjonsplan, snitt- og fasadetegningene), genererer løsningen et ferdig utfylt nabovarsel. Dette inkluderer en automatisk generert oversikt over naboer, siden tiltakets eiendomsinformasjon allerede ligger inne. Søkeren kan legge til flere parter som man mener blir berørt, om man ønsker det. Søkeren kan også velge å laste opp bekreftelse på at naboer er varslet direkte, i stedet for å sende ut nabovarselet elektronisk for en eller flere av sine naboer. Saksbehandlingsforskriften stiller krav om at det skal foreligge kvittering fra nabo for at de har mottatt varsel. Dette kravet skal løsningen sørge for at løsningen håndterer automatisk med digital utsendelse av nabovarselet til naboenes digitale postkasse. Når nabovarslingen er utført og eventuelle nabomerknader er mottatt, gjør løsningen det mulig for søker å redegjøre for hvordan disse blir ivaretatt Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Nabovarslingen er for omfattende i dag, det tar for mye tid å fylle ut skjemaer ved utarbeidelse av nabovarselet Blant søkerne er det usikkerhet om når nabovarsling må utføres. Ved hvilke typer/omfang av tiltak er det påkrevd med nabovarsling, og om alle eller kun berørte naboer må varsles. Saksbehandler opplever at det kommer for mange uberettigede klager og merknader fra naboene i dag. 8.3 Gjennomføringsplan I alle byggesaker hvor det skal benyttes ansvarlige foretak, er det krav til gjennomføringsplan. Hensikten med gjennomføringsplanen er å kunne ha en løpende oppdatert oversikt over alle ansvarsområder i tiltaket, hvilken tiltaksklasse de har og hvilket foretak som har ansvaret for de ulike områdene. Gjennomføringsplanen skal også vise ved hvilke søknadspunkt samsvarserklæring eller kontrollerlæring skal foreligge, samt hvilke samsvarserklæringer og kontrollerklæringer som allerede foreligger. Gjennomføringsplanen må kunne oppdateres gjennom hele prosessen fra søknad om byggetillatelse til søknad om ferdigattest. Side 42 av 68

43 8.3.1 Beskrivelse av krav For alle tiltak som krever ansvarsrett, skal følgende funksjoner dekkes av ansvarlige foretak: - Ansvarlig søker (kun ett foretak skal ha denne funksjonen) - Ansvarlig prosjekterende (ansvaret kan være delt mellom flere foretak) - Ansvarlig utførende (ansvaret kan være delt mellom flere foretak - Ansvarlig kontrollerende (kun i saker hvor det er krav om uavhengig kontroll det kan være flere kontrollerende foretak i en byggesak) I gjennomføringsplanen legger ansvarlig søker inn foretak med ansvarsrett for hvert av de aktuelle funksjonsområdene. For de funksjonene hvor det skal være flere ansvarlige foretak, deler ansvarlig søker opp funksjonsområdet i flere ansvarsområder i gjennomføringsplanen og legger inn en beskrivelse av hvilket ansvar det ansvarlige foretaket skal påta seg i byggesaken. Søknadssystemet må kunne hente informasjon om foretakene som legges inn fra registeret over foretak med sentralt godkjenning. For kommunene er det viktig informasjon hvorvidt foretakene har sentral godkjenning eller ikke, og hvilke funksjoner og ansvarsområder de er godkjent for. Dersom foretaket ikke har sentral godkjenning, må systemet kunne hente informasjon fra Foretaksregisteret. For foretak som utenfor EØS, må det være mulig å dokumentere at det er registrert i tilsvarende foretaksregister eller bransjeregister i EØS-stat. For foretak fra land omfattet av WTO-avtalen må det være mulig å dokumentere at det oppfyller krav gitt i eller med hjemmel i plan- og bygningsloven. Denne dokumentasjonen skal ikke sendes kommunen med mindre kommunen åpner et tilsyn i saken. Alle foretak som registreres i gjennomføringsplanen må motta et varsel om at de er lagt til som ansvarlig foretak i den aktuelle byggesøknaden og at de må gå inn og erklære at de påtar seg dette ansvaret. Gjennomføringsplanen skal til enhver tid vise kommunen hvordan ansvarsfordelingen i byggesaken er og hvor langt prosessen har kommet. Hver gang det sendes en delsøknad eller det skjer endringer i ansvarsretter, skal gjennomføringsplanen oppdateres og sendes kommunen. Gjennomføringsplanen skal vise hvilke erklæringer som foreligger. Verken samsvarserklæringer eller kontrollerklæringer skal sendes kommunen med mindre kommunen åpner et tilsyn, men søker skal ha mulighet til å holde denne informasjonen samlet i tilknytning til gjennomføringsplanen til den aktuelle byggesaken. Gjennomføringsplanen skal inneholde følgende elementer: Fagområder (ikke definert i lovverket kun en hjelp til å gruppere ansvarsområdene) Ansvarsområder (fritekst som beskriver hvilket ansvar foretaket tar på seg) Tiltaksklasser (1, 2 eller 3) Ansvarlig foretak Status for samsvarserklæringer og kontrollerklæringer (planlagt eller avgitt) Hvorvidt ansvarsområdet er avsluttet Versjon Signatur fra ansvarlig søker Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Vanskelig å holde gjennomføringsplanen oppdatert til enhver tid da det er mange ting som forandrer seg underveis i prosessen. Utfordringene blir enda større etter hvor erklæring om ansvarsrett kan sendes inn når som helst i byggesaken. Vanskelig å enkelt se hva som er forandret fra forrige versjon av søknaden Side 43 av 68

44 Dersom det avgis samsvarserklæring for ett ansvarsområde flere ganger, blir bare datoen for den siste erklæringen markert i gjennomføringsplanen. Gjennomføringsplanens versjonsnummer må skrives inn manuelt. 8.4 Avfallsplan Avfallsplan er et steg i søknadsprosessen hvor søkeren skal registrere og sende inn nødvendig data som dekker SSB og kommunens informasjonsbehov i forbindelse med avfallsplan og avfallsrapport. Avfallsplanen skal utfylles i forbindelse med ferdigattesten Beskrivelse av krav I avfallsplanen skal det være enkelt å kunne utarbeide en plan over alle avfallsfraksjoner i tiltaket, samt å stipulere mengde for hver av fraksjonene. Dersom tiltaket er så omfattende at det er krav om en avfallsplan, må søker og en uavhengig konsulent ha tilgang til å utarbeide en avfallsplan i løsningen. Det må da være god tilgang til alle nødvendige avfallsfraksjoner. I planen skal det anslåes en mengde av alle sannsynlige fraksjoner som er aktuelle, og disse må være tilgjengelig i en ny løsning. Det må også være mulig å varsle tydelig dersom det legges opp til en sorteringsgrad som er mindre enn det som er forskriftsfestet. Det er krav om avfallsplan for følgende saker: Nybygg over 300m2 BRA Rivning av bygg over 100m2 BRA Byggesaker som genererer mer enn 10 tonn avfall De ulike sakene har forskjellige blanketter, og løsningen må gjøre det mulig for søker å fylle inn nødvendig informasjon. Ved byggeprosessens slutt skal det med grunnlag i avfallsplanen, utarbeides en avfallsrapport hvor de faktiske mengdene av hver fraksjon blir fylt inn. Både avfallsplan og avfallsrapport skal angi hvor mye avfall som genereres per kvm BRA (bruksareal), samt sorteringsfaktor (hvor mye avfall som er levert til gjenvinning i forhold til leveranse av usortert avfall). Det er bare avfallsrapporten som skal sendes kommunen, og dette gjøres ved innsending av søknad om ferdigattest. Ansvarlige utførende foretak skal kunne legge inn hvor mye avfall de har levert av de ulike fraksjonene og dokumentasjon for dette må kunne lastes opp i løsningen i forbindelse med en ferdigattest. All data fra avfallsrapportene skal kunne rapporteres direkte til SSB (Statistisk Sentralbyrå) Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Avfallsplan utarbeides som regel av uavhengige konsulenter som vanligvis ikke har andre ansvarsområder i byggesaken. Disse må ha enkel tilgang til utfylling. Utfylling av mengde for faktisk levert avfall av hver fraksjon gjøres av alle utførende foretak disse bør også ha tilgang til utfylling. Det er ikke krav om at avfallsplanen skal sendes kommunen, dette medfører at planen ofte ikke blir fylt ut før søknaden blir sendt men forskriftene krever at planen fylles ut før arbeidene igangsettes. Side 44 av 68

45 8.5 Samtykke fra øvrige myndigheter Bygningsmyndigheten har plikt til å innhente eventuelle tillatelser, samtykker og uttalelser fra de myndighetene som berøres av det aktuelle tiltaket, men tiltakshaver kan selv også legge frem saken sin for de aktuelle myndighetene, og således redusere saksbehandlingstiden. Dette må løsningen legge til rette for. Kommunens samordningsplikt etter plan- og bygningslover 21-5 omfatter følgende myndigheter: Helsemyndighet Brannvernmyndighet Arbeidsmiljømyndighet Vegmyndighet Havnemyndighet Forurensningsmyndighet Sivilforsvaret Jordlovmyndighet Friluftsmyndighet Kulturminnemyndighet Reindriftmyndighet Kirkelig myndighet Luftfartsmyndighet Bergverksmyndighet (Jernbaneverket) DiBK har startet opp et prosjekt som skal kartlegge og gi en juridisk utredning av andre myndigheter sin rolle i byggesaksprosessen. Prosjektet skal gjøre rede for hvilke andre myndigheter den kommunale bygningsmyndighet er pliktig å rapportere til løpet i byggesaksprosessen, hva som da skal rapporteres og når i saksgangen informasjonen skal gis. Løsningen må ta kunne implementere resultatet fra dette prosjektet. På sikt er målet at øvrige myndigheter skal kunne avgi merknader og å sende ut vedtak, samt å hente ut nødvendig informasjon direkte fra Byggesøknadsløsningen. DiBK har startet opp arbeidet med dette i samarbeid med Arbeidstilsynet, der de evaluerer muligheter for en full integrert løsning mellom Byggesøknadsløsningen og systemet som Arbeidstilsynet bruker i dag. Arbeidstilsynets utfordring er at det er tiltakshaver som skal sende inn søknad til dem, og ikke ansvarlig søker. Ofte er det ansvarlig søker som utarbeider søknaden, og informasjon om planlagt virksomhet blir da mangelfull. Løsningen må sørge for at all relevant informasjon fra søknaden, supplert med egen redegjørelse og dokumentasjon for ivaretakelse av arbeidsmiljøregelverkets krav, blir formidlet til Arbeidstilsynet, og at dette kan signeres av tiltakshaver Kommunens samordningsplikt omfatter alle søknadspliktige tiltak. Dersom forholdet til en aktuell myndighet ikke er avklart, kan kommunen velge å avvente med en endelig tillatelse eller gi rammetillatelse med forbehold om at igangsettingstillatelse ikke vil bli gitt før nødvendig avgjørelse eller uttalelse foreligger Beskrivelse av krav Løsningen bør ha funksjonalitet for å avdekke krav til involvering av øvrige myndigheter i de tilfellene hvor det er tydelige kriterier for hvilken myndighet som skal involveres. Noen eksempler på dette er: Tiltaket berører arbeidsplasser arbeidsmiljømyndighet skal involveres Side 45 av 68

46 Tiltaket har byggehøyde på mer enn 18 meter luftfartsmyndighet skal involveres Tiltaket er et næringsbygg på mer enn 1000 kvadratmeter sivilforsvarsmyndighet skal involveres ift krav om tilfluktsrom eller evt. dispensasjon fra kravet Tiltaket omfatter deponi forurensningsmyndighet må involveres Søker må få veiledning om hvorvidt de relevante myndighetene kun skal informeres, om de skal uttale seg eller om de skal fatte et vedtak, slik at søker selv kan velge å innhente samtykke la kommunen utføre oppgaven ifm. behandlingen av søkanden Dersom det er tiltakshaver som står ansvarlig for å innhente samtykke fra (for eksempel i søknader som berører arbeidsplasser), så må løsningen ivareta mulighet for at tiltakshaver kan legge inn eventuell relevant dokumentasjon og redegjørelser som viser hvordan de kravene regelverket sektormyndigheten forvalter er ivaretatt og undertegne dette elektronisk før oversendelse til sektormyndigheten. Prosessen må også kunne støttes og koordineres av ansvarlig søker gjennom funksjonalitet for opplasting av vedlegg til søknaden Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Det er vanskelig å ha oversikt over hvilke øvrige myndigheter som må involveres Søker mangler oversikt over når dette må utføres, og hvem man skal ta kontakt med I noen tilfeller er tiltakshaver ansvarlig for innhenting av samtykke fra sektormyndighet, og ikke ansvarlig søker Man må oppgi samme informasjon flere ganger til ulike myndigheter 8.6 Dispensasjon Hensikten med ny løsning er at søker skal få hjelp til å avdekke dispensasjonsplikt, og at informasjon som kommunen og øvrige myndigheter krever i forbindelse med en søknad om dispensasjon kan dokumenteres effektivt og intuitivt som en integrert del av byggesøknaden Beskrivelse av krav Løsningen skal hjelpe søker med å avdekke dispensasjonsplikt, gjennom validering, etter hvert som søker legger inn informasjon om tiltaket i sin søknad om tiltak. For eksempel, dersom søker har angitt at tiltaket er nærmere enn tillatt grense for bygging mot offentlig veg. Søker skal videre få veiledning om hvilket regelverk tiltaket er i strid med, og hvilke myndigheter som skal involveres i dispensasjonssøknaden. I og med at løsningen i første fase ikke vil ha funksjonalitet for å avdekke dispensasjonsplikt for alle typer regelverk, må søker selv også kunne oppgi at tiltaket er dispensasjonspliktig. Løsningen skal legge til rette for at søknad om dispensasjon gjenbruker informasjon som søker har beskrevet fra før. Løsningen skal også gjøre det enkelt å videreformidle søknaden, dersom dispensasjonen krever behandling av en annen myndighet enn kommunen Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Side 46 av 68

47 Ikke alle søkere har satt seg godt nok inn i hva som krever en dispensasjonssøknad. 8.7 Delesøknad En delesøknad benyttes når det er behov for å dele opp et areal av en eksisterende eiendom. En søker som har en stor eiendomstomt har solgt deler av tomten sin for ny bebyggelse av bolig. Søkeren må derfor søke om å skille ut den delen av tomten som er solgt slik at denne tomten får et eget bruksnummer. Delesøknader har ikke krav om ansvarlig søker slik som for søknad om tillatelse til tiltak iht. PBL Beskrivelse av krav En delesøknad er i utgangspunktet bygget opp på samme måte som en søknad om tillatelse til tiltak (byggesøknad). Delesøknaden består av to deler; den delen av søknaden som ber om deling av en eiendomstomt, og den andre delen som ber om rekvisisjon av oppmålingsforretning (vedlegg til byggesøknaden) som vurderes av Statens Kartverk. Disse to delene følger ulike regler, hhv. Plan- og bygningsloven (pbl) og Matrikkelloven (ml). Enkelte kommuner har i dag slått disse to delene sammen til én søknad, men utformingen av denne søknaden er ulik mellom kommunene. For søker er det viktig at søknadsprosessen for en delingssøknad fremstår som én og samme søknad, og at det fremkommer tydelig hvilken type informasjon som kreves for at søknaden kan anses som komplett ved innsendelse. Det er derfor ønskelig med én felles løsning hvor søkeren tas gjennom hele søknadsprosessen digitalt og i én søknad. Rekvisisjon av oppmålingsforretning inngår dermed i delesøknaden, og ikke som et vedlegg til delesøknaden Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: En søker opplever at søknadsprosessen er oppstykket av ulike skjemaer og til ulike mottakere en søker skiller ikke mellom elementene i søknaden som skal til kommunen og Statens Kartverk Kommunene som har slått sammen begge delene i delesøknadene i én søknad har ulik praksis det finnes ingen klare retningslinjer om hvordan den sammenslåtte versjonen skal være Det er uklart hvilken informasjon som kreves i en delesøknad Side 47 av 68

48 9 Krav til oppfølging av søknad Det kan være behov for oppfølging og avklaring mellom søker, kommunen og eventuelle andre parter etter at en søknad er innsendt. Figuren nedenfor viser hvor Oppfølging av søknad er plassert i byggesøknadsprosessen. Mer detaljer ses i kapitel XXX. Innledning, Dokumentets oppbygging. Behovene til de ulike søkergruppene vil være ulike. For en mindre erfaren søker er behov for en beskrivelse av fremgangsmåte; hva søkeren foreta seg ved eventuelle suppleringer/revideringer, og hvordan dette gjøres. Med beskrivelsen skal det også ligge ved eksempler, slik at søker enkelt og intuitivt vet hva som skal gjøres for at søknadsbehandlingen skal kunne fortsette. En profesjonell søker har mindre behov for veiledning underveis oppfølging av en søknad. Med veiledning tenker vi på beskrivelse av terminologi/begreper, forutsetninger og saksgangen generelt. En profesjonell forutsetter at løsningen håndterer en oversiktlig fremstilling av alle pågående søknader og tiltak i systemet, og at man til enhver tid er informert om hvilken søknad eller hvilket tiltak som krever oppfølging. Alle aktivitetene som beskrives her må utføres digitalt for å sikre en effektiv prosess. Behovene for oppfølging beskrives her sammen med de tilhørende kravene dette vil stille til en løsning: Supplering av søknad: Søkeren må sende inn tilleggsdokumentasjon til innsendt søknad Revidering av søknad: Søkeren må endre innholdet i innsendt søknad Mottak av vedtak: Søker mottar vedtak kort tid etter at søknaden er ferdigbehandlet Klage på søknad: Alle parter i en sak har muligheten til å klage et fattet vedtak 9.1 Supplering av søknad En søker må supplere til en søknad hvis kommunen har behov for tilleggsdokumentasjon utover den opprinnelige søknaden som søkeren har sendt inn. Søker må dermed sende inn suppleringer til den innsendte søknaden slik at søknaden anses som komplett og videre behandling kan starte. Noen kommuner sender tilbake hele søknaden ved mangler, mens andre velger å be om supplerende informasjon. Løsningen må kunne støtte begge alternativene Beskrivelse av krav Når en søknad er sendt inn, kan det være behov for å supplere innsendt søknad med tilleggsdokumentasjon. Tilleggsdokumentasjon kan være nye versjoner av dokumenter, flere og nye dokumenter med tilleggsinformasjon. Det må være enkelt for søker å kunne holde orden på hva som er supplert, hva som er siste versjon med versjonshåndtering, og til hvilke tiltak søknaden gjelder. For søker må supplering av søknad være enkelt og intuitivt. Dette innebærer at den informasjonen som er nødvendig må være lett tilgjengelig. Med nødvendig informasjon tenker vi både på den informasjonen som søkeren trenger for å supplere en søknad, og informasjon om hvorfor søkeren må supplere en søknad. Dersom oppdatert informasjon er av en slik karakter at det vil innebære endring Side 48 av 68

49 av søknaden må det vurderes om det skal gjennomføres ny nabovarsling. Løsning må derfor stille spørsmål til søker om det gjort endringer av en slik karakter at det kreves nytt nabovarsel Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Det er vanskelig for søkeren å identifisere hvilken tilleggsdokumentasjon som etterspørres da dette ikke kommer tydelig nok frem i mangelbrevet. Da er det behov for å ta en telefon for å oppklare uklare momenter. Det er vanskelig å holde orden på hva som er siste versjon av søknadsdokumentet Brukeren forstår ikke bestandig om saksbehandlingstiden har stoppet opp, i påvente av supplering av informasjon, eller om tiden fortsetter å løpe. Bruker har heller oversikt om dette vil få konsekvenser med hensyn til merkostnader eller lignende. Søker vet lite om hvilke frister kommunen har for å gi et svar. 9.2 Revidering av søknad En søker som reviderer sin søknad foretar en endring i innholdet (søknadsdokumenter) som allerede er innsendt til behandling, men hvor vedtak enda ikke er fattet. Omfanget av behov for revidering kan variere. Revidering av søknad kan være etterspurt av kommunen, eller at søker finner det nødvendig å endre innholdet i innsendt dokumentasjon Beskrivelse av krav Etter at en søknad er sendt inn, kan det i flere tilfeller være behov for revidering av innsendt dokumentasjon. Vanlige årsaker kan være: 1. Søker får tilbakemelding fra saksbehandler i kommunen at innsendt dokumentasjon må revideres, f.eks. dersom søknaden er i konflikt med gjeldende krav og regler 2. Søker ønsker å forandre sitt byggeprosjekt og må derfor oppdatere innsendt dokumentasjon, f.eks. søker ønsker å bygge et skråtak istedenfor et flatt tak Ved revidering av dokumentasjon er det derfor behov for at innsendt søknadsdokumentasjon ligger tilgjengelig i søknadsflaten til søker og at nødvendige dokumenter kan oppdateres med nye versjoner som kan legges ved den reviderte søknaden. Det er ulik praksis blant norske kommuner på hva som gjøres når en søknad må oppdateres; enkelte kommuner returnerer søknaden i sin helhet når søknaden sannsynligvis ikke vil bli vedtatt, mens andre kommuner anbefaler søkere om å revidere søknaden. Det er derfor ønskelig at løsningen understøtter begge alternativene med full revidering (hele søknaden sendes inn igjen på nytt) eller kun revidering av aktuelle deler av søknaden som er endret (kun endret dokumentasjon sendes inn til kommunen). Det skal være enkelt for søker å ha oversikt over hvilke dokumenter som er revidert med versjonshistorikk, samt tilhørighet til søknad/tiltak. Dersom revideringen er av en slik karakter at det vil innebære endring av søknaden må det vurderes om det skal gjennomføres ny nabovarsling. Løsning må derfor stille spørsmål til søker om det gjort endringer av en slik karakter at det kreves nytt nabovarsel. Det må være enkelt og intuitivt for søker å revidere en søknad. Side 49 av 68

50 9.2.2 Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Løsningen for versjonshåndtering er ikke tilfredsstillende. Når en søker har revidert søknaden sin, vil ikke saksbehandler være opplyst om ny oppdatering. Samtidig vet ikke søker om den endringen som er gjort er av så stort omfang at endringen utløser krav om ny saksbehandling og nytt vedtak. 9.3 Mottak av vedtak Søker vil i sin digitale postkasse motta et skriftlig vedtak så snart søknaden er ferdigbehandlet. Det er da ønskelig at søkeren kan oppsøke byggesøknadsløsningen og finne vedtaket der koblet til riktig søknad ved at byggesøknadsløsningen henter inn vedtaket fra søkerens digitale postkasse Beskrivelse av krav Det er ønskelig at byggesøknadsløsningen har funksjonalitet for å hente inn vedtak som søkeren mottar og lagre dette sammen med den aktuelle søknaden. Løsningen bør automatisk spørre søkeren om det skal logges på søkerens digitale postkasse når en søknad endrer status til «Vedtak fattet». Løsningen sørger for at søkeren enkelt kan lagre vedtaket sammen med søknaden Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Vedtak kommer pr brev eller til søkerens digitale postkasse og knyttes ikke automatisk til søknaden 9.4 Klage på vedtak En søker eller alle parter i en sak har mulighet til å klage på et fattet vedtak. Dette er en lovfestet rett og skal være gratis. Det er likevel et mål at klagegrunnlaget er gyldig, slik at det ikke brukes mye tid på å behandle uberettigede klager Beskrivelse av krav Når et vedtak er mottatt, har alle parter i saken rett til å klage på dette vedtaket, med mindre forholdet det skal klages på tidligere er ferdigbehandlet i en detaljregulering som er mindre enn fem år gammel. Vedtaket skal orientere om klagefrist og videre klageprosess. Løsningen beskriver prosessen for klagebehandling, hvilke instanser som det er mulig å klage til, samt på hvilke grunnlag klage kan sendes inn. Den som klager får veiledning til å skrive klagen i brukerflaten til den aktuelle søknad, samt opplyst hvilken type dokumentasjon og referanser som skal legges ved. Klagebehandlingsprosessen fremkommer tydelig i løsningen, og det til enhver tid mulighet til å følge med på hvor i prosessen man står. Tidsfrister vises på en oversiktlig måte Brukerutfordringer i dag Ny løsningen må ha funksjoner for å løse følgende utfordringer: Involverte parter i en sak, mangler kunnskap om klageadgang og klageprosess En søker opplever unødig lang saksbehandlingstid der det er fremsatt ugyldige klager Side 50 av 68

51 9.5 Se status på søknad Etter at en søknad er sent inn må søkeren kunne følge status på søknaden via byggesøknadsløsningen Beskrivelse av krav Løsningen skal hver gang brukeren logger seg inn sjekke status på alle aktive byggesøknader via det tilgjengelige tjenestegrensesnittet mot byggesaksarkivet til kommunen. Status på alle søknadene vises i en oversikt over alle de aktuelle byggesøknadene til brukeren og i skjermbildet når søkeren er inne på den aktuelle søknaden Brukerutfordringer i dag Ny løsningen må ha funksjoner for å løse følgende utfordringer: Søker mottar ingen statusoppstering på saken uten selv å ta kontakt med kommunen, eller når han mottar de formelle brevene. Søker har derfor ingen automatisk oversikt over fremdriften i behandlingen av byggesøknaden. Side 51 av 68

52 10 Krav til tjenester for naboer og øvrige aktører Under dette kapitlet er tjenester som ikke i hovedsak er rettet mot søkere og tiltakshavere samlet. Målgruppen for disse tjenestene vil i hovedsak være parter i byggesaken Motta og gi merknad til nabovarsel I alle byggesaker med krav til varsling av naboer, skal nabo motta et digitalt nabovarsel hvor de blir bedt om å logge seg inn i byggesøknadsløsningen for å se på tiltaket som naboen planlegger og hvor de kan levere merknader digitalt direkte i løsningen eller bekrefte at de ikke har noen merknader til det planlagte tiltaket Beskrivelse av krav For nabo som mottar et nabovarsel i sin digitale postkasse, mottar de en link hvor de kan logge seg inn i byggesøknadsløsningen og komme direkte inn på nabovarselet med presentasjon av det planlagte tiltaket. Her får naboene oversikt over tiltaket som det planlegges å søke om, og man kan velge kvittere for mottatt varsel uten å avgi merknad eller å registrere eventuelle merknader til det foreslåtte tiltaket. Naboen får også tilgang til informasjon om klageadgang og hvilke rettigheter man har som part i en byggesak, hvem man kan kontakte ved spørsmål i saken og hva som vil skje videre i saksbehandlingen. Naboen har en frist på to uker til å registrere en merknad, om han ikke aktivt registrere at han ikke har noen merknader til tiltaket. Hvis alle naboer registrerer at de ikke har noen merknad kan søknad om tiltak leveres før to ukers frist for nabovarselet er utløpt Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: - Nabo må ofte ens ærend til nærmeste postkontor for å hente nabovarsel ifm. av rekommandert postsending. - Nabo må oppsøke kommunen eller ansvarlig søkers adresse for å få innsyn i byggesøknaden det er varslet om. - Både besøk på postkontor og hos kommune/ansvarlig søker tar mye tid og fristen på to uker til å gi merknad kan raskt bli knapp. - Naboer sender ofte kopi av merknad direkte til kommunen for å være sikker på at søker oppgir at det er gitt nabomerknad - Naboer har i liten grad orientert seg om sine klagerettigheter og hva slags forhold som gir grunnlag å vinne frem med en evt. klage. Det brukes derfor mye tid og energi på å gi merknader og klage på saker som kommunen normalt ikke vil ta hensyn til i behandling av byggesøknaden. Side 52 av 68

53 10.2 Gi samtykke Det åpnes for at leverandøren kan utvikle en tjeneste hvor samtykke fra øvrige myndigheter kan legges rett inn på byggesøknaden som en digital tjeneste som leverandøren avklare direkte med den/de aktuelle myndigheter. Dette som en enkel og ustandardisert tjeneste som langt tidligere kan realisere deler av det langsiktige målbildet for de myndighetene som søker/tiltakshaver hyppigst henter inn samtykke fra Beskrivelse av krav Det kan med fordel etableres en tjeneste som gjør det mulig for relevante myndigheter å sende sitt vedtak direkte til byggesøknadsløsningen, slik at godkjenning fra forespurt myndighet legger seg direkte inn som dokumentasjon i søknaden. Det foreligger ingen valgt standard for en slik tjeneste, slik at en evt. løsning må avklares direkte med relevante myndigheter. Det påpekes at en enkel kartlegging har vist at det er Arbeidstilsyn som er den myndigheten det hyppigst innhentes samtykke fra før byggesøknaden sendes inn til behandling i kommunene Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: - Mye manuell postgang mellom myndighet og søker/tiltakshaver og myndighet og kommune 10.3 Innsyn i byggesak Ikke utarbeidet Det er ønskelig at byggesøknadsløsning tilrettelegger for digitalt innsyn i byggesaker. Hvordan kommunenes arkiv kan tilgjengeliggjøres på en standardisert måte for en slik funksjon er oppe til vurdering Beskrivelse av krav Brukerutfordringer i dag 10.4 Erklæring om ansvarsrett Ansvarlige foretak skal på en enkel måte motta et digitalt varsel om at de er satt opp som ansvarlig foretak i en byggesøknad og at de må gå inn å erklære at de påtar seg denne ansvarsretten. De skal da enkelt kunne logge seg inn i byggesøknadsløsningen, få oversikt over saken og signere digitalt for at de påtar seg den aktuelle ansvarsretten Beskrivelse av krav Et foretak som er lagt inn som ansvarlig for ett eller flere ansvarsområder i en byggesøknad mottar et varsel fra når de blir lagt til i gjennomføringsplanen av ansvarlig søker. Ved å klikke på linken i dette varselet kommer brukeren rett inn til beskrivelsen av ansvarsområdet som ansvarlig søker har oppgitt at foretaket skal påta seg ansvaret for. Det er også mulig for brukeren å se på det øvrige innholdet i byggesøknaden, men brukeren kan ikke endre på innholdet. Brukeren kan da velge mellom å fraskrive seg ansvarsretten med melding tilbake til ansvarlig søker om årsak eller å erklære at foretaket påtar seg ansvarsretten for det beskrevne ansvarsområdet. Løsningen må gjøre det Side 53 av 68

54 mulig å registrere all informasjon som er påkrevd i blankettene i «Erklæring om ansvarsrett», «Søknad om ansvarsrett som selvbygger». Figur 10: Signeringsprosess Figur 10 viser gangen i en signeringsprosess. Løsningen må gjøre det enkelt for alle parter i en sak å signere underveis i søknadsprosessen. De ulike rollene skal få varsel om når, hva og hvor de skal signere, samt hva signaturen innebærer. Ansvarlig søker skal også få en oversikt over hvem som har signert og når. Det vil være aktuelt med flere ulike signeringer: Kvittere og signere for å ha lest noe Signere for å erklære ansvarsrett Signere for å erklære at arbeid er fullført (samsvarserklæring) Samtidig må løsningen holde en oversikt over de byggesakene som et ansvarlig foretak har erklært ansvarsrett i, slik at de enkelt kan finne frem igjen til de aktuelle byggesakene for å legge inn samsvarserklæring eller bare få oversikt Selvbygger For tiltak i tiltaksklasse 1, kan eier, dersom han skal bruke tiltaket selv, søke om ansvarsrett som selvbygger for hele eller deler av ansvaret. Selvbygger kan søke selvbyggeransvar for alle funksjoner bortsett fra som ansvarlig kontrollerende. I søknaden skal selvbygger sannsynliggjøre at arbeidet godkjenningen gjelder vil bli utført i samsvar med bestemmelser gitt i eller med hjemmel i plan- og bygningsloven. Dersom selvbygger påtar seg alt arbeid i byggesaken, kreves det ingen gjennomføringsplan. Dette fordrer at det ikke er krav til uavhengig kontroll i byggesaken. I en søknad om personlig ansvarsrett som selvbygger av egen bolig eller fritidsbolig må søker angi omfanget av selvbyggeransvaret, dette må løsningen legge til rette for. Løsningen må også gjøre det mulig for søker å spesifisere hvilke deler av tiltaket de søker om selvbyggeransvaret for. Gjennomføringsplanen bør kunne gjenbrukes fra tidligere søknader for å overføre og gjenbruke informasjon Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Dagens prosess er papirbasert og tidkrevende. Det må signeres flere ganger i prosessen, både ifm. erklæring om ansvarsrett og ifm. samsvarserklæring og det er mye informasjon som må fylles ut på nytt i de ulike skjemaene Side 54 av 68

55 Ett foretak kan ha mange forskjellige ansvarsområder i en sak, men med forskjellige kontaktpersoner. Når organisasjonsnummeret er det samme, kan dette være vanskelig å holde styr på de ulike områdene. De ulike foretakene har veldig ulik praksis hvordan de håndterer rettighetene til signering av de ulike ansvarsområdene. Side 55 av 68

56 11 Krav til støttetjenester Støttetjenester er funksjonalitet som felles for de øvrige tjenestene som tilbys i byggesøknadsløsningen Gebyrberegning Gebyrberegning skal på en transparent og intuitiv måte hjelpe en søker å estimere gebyrstørrelse til en påstartet søknad. Gebyrberegningen kalkulerer automatisk et stipulert gebyr for levering og behandling av søknad Beskrivelse av krav I brukerflaten skal det være en funksjonalitet for å beregne og vise et stipulert gebyr for levering og behandling av søknad. Gebyret oppdateres for hvert valg som gjøres i utfyllingen av søknaden som har betydning for gebyrets størrelse, slik som areal på tiltaket, dispensasjoner m.m. Gebyrkalkulatoren reflekterer kun de gebyrene som er relevante i den aktuelle kommunen som søknaden er knyttet til en eiendom i. I tillegg skal brukeren ved et enkelt klikk komme rett inn på en oversikt over alle gebyrer som gjelder i forhold til byggesøknader i den aktuelle kommunen. Løsningen må være fleksibel ift. variasjon mellom gebyrregulativene for de enkelte kommunene, så fremt det er mulig å registrere gebyrberegningsgrunnlaget strukturert via informasjon utfylt i søknaden Brukerutfordringer i dag Ny løsning bør ha funksjoner for å løse eller imøtekomme følgende utfordringer: Det er mangel på oversikt over sammenhengen mellom type gebyrer i forhold til type saker, noe som vanskeliggjør beregning av den totale gebyrkostnaden. Det finnes ikke én standard på gebyrberegning da størrelsen på gebyrene er kommunespesifikke. Automatisk utregning og spesifisering av gebyromfang tilpasset type søknad som er påstartet Digital signering Ikke utarbeidet Det er ikke avklart hvordan digital signering skal foregå. Det skal bli tatt en vurdering av om det skal velges en standard for signatur som må benyttes Beskrivelse av krav Brukerutfordringer i dag 11.3 Betalingsløsning Ikke utarbeidet Det er ikke avklart hvordan betalingsløsningen vil se ut. Det skal bli tatt en vurdering av om dette skal være en nasjonal tjeneste eller del av denne løsningen. Side 56 av 68

57 Beskrivelse av krav Brukerutfordringer i dag 11.4 Sende og motta generelle henvendelser Henvendelser til kommunen som ikke inngår som del av en søknad kan utformes som en generelle henvendelser i dette kapitlet. En bruker kan ha behov for å gjøre henvendelser til kommunen både før en byggesak er opprettet og i forbindelse med en pågående byggesak. Kommunen kan ha behov for å kontakte en søker for å varsle, informere eller besvare en henvendelse, og dette skal søker kunne motta direkte i byggesøknadsløsningen med varsling til oppgitt e-postadresse/telefon Beskrivelse av krav Løsningen skal tilby et grensesnitt hvor brukere kan utforme og sende inn henvendelser til kommunen. I brukergrensesnittet skal det være kobling mot ofte stilte spørsmål som brukeren kan søke i for å se om hans spørsmål er besvart tidligere. Hvis brukeren ser behovet for å ta kontakt med kommunen skal han enkelt kunne utforme en henvendelse, legge ved nødvendig dokumentasjon som vedlegg og sende henvendelsen direkte til kommunens postmottak for byggesakshenvendelser. Brukeren skal også motta varsel, svar, og informasjon fra kommunen via portalen, f.eks. ved varsel om tilsyn, samt motta tilsynsrapporten i etterkant av tilsynet. Det må være mulig å se henvendelseshistorikk via løsningen. Det er behov for at løsning gir tydelig informasjon om hvordan kommunen kan kontaktes via evt. andre tilgjengelige kanaler, slik som: Telefon Oppmøte hos kundesenter/infotorg Kontakt-oss-skjema Brukerutfordringer i dag Det eksisterer ingen systemstøtte for generelle henvendelser til kommunen i dagens søknadsløsninger. Henvendelser går som tradisjonell e-post til kommunens postmottak eller brukerne tar kontakt med kommunen pr telefon eller ved fysisk oppmøte. Brukeren har derfor ingen samlet oversikt over sine henvendelser til kommunen med tilhørende svar fra kommunen koblet til den aktuelle byggesaken. Mange brukere opplever også at det kan gå lang tid før en henvendelse kommer frem til rett saksbehandler for behandling og det derfor kan ta uforholdsmessig mye tid å få svar på relativt enkle spørsmål pr e-post Administrasjon av løsningen Ikke utarbeidet Beskrivelse av krav Side 57 av 68

58 12 Krav til teknologi og arkitektur - Under utarbeidelse Tabellen nedenfor viser hvilken informasjon som er tilgjengelig digitalt, og hvilken som ikke er tilgjengelig (må oppdateres av kommunene) Tilgjengelig digitalt: Kommuneplan Reguleringsplan? Arkiv fra og med år 19XX Kart Infoland Forurensingskart Lover og regler Fylles ut Ikke tilgjengelig digitalt: Arkiv frem til år 19XX Grunnboka Fylles ut 12.1 Felles integrasjonsplattform for kommunal sektor Visjonen for den felles kommunale ikt-arkitektur er at kommunene gjennom et felles rammeverk for digitalisering og IKT-arkitektur samordner kommunal sektoren til å levere digitale tjenester som gir innbyggere og næringsliv et reelt digitalt førstevalg. De digitale tjenestene understøttes av nasjonale og kommunale registre med grunndata, nasjonale og kommunale fellesløsninger, kommunenes fagsystemer og infrastruktur. Standarder og grensesnitt sørger for at informasjonen mellom disse flyter godt. Komponentene hver for seg, hvordan de fungerer sammen, og hvordan de kan settes sammen på nye måter, utgjør vårt målbilde for det felles kommunale rammeverk for digitalisering: Side 58 av 68

59 For å kunne realisere dette målbilde vil det utover rammeverk for digitalisering også være behov for teknisk infrastruktur som kobler disse ulike komponentene sammen. Meldingsformidleren SvarUt er en del av en slik infrastruktur. I forbindelse med pågående arbeid med skjenkebevilling vil også funksjonalitet for arbeidsflyt (edialog) bli en del av dette. Sammen med funksjonalitet i Altinn og eventuelt andre teknologileverandører vil en sum av løst koblede løsninger danne den felles integrasjonsplattformen for kommunal sektor (FIKS). Denne integrasjonsplattformen kobler kommunens lokale IKT-løsninger sammen med andre felles IKT-løsninger, og støtter opp under kommunenes digitale tjenester basert på behov hos innbygger og næringsliv. Om arbeid med det nasjonale veikartet resulterer i nye nasjonale plattformer, vil kommunene kunne beslutte å ta i bruk disse uten å måtte gjøre omfattende endringer på kommunenes etablerte tjenester. Målbilde for felles integrasjonsplattform for kommunal sektor kan illustreres slik: Side 59 av 68

60 Integrasjonsplattformen vil være kommunenes inngangsport til felles funksjonalitet og data. Den skal bidra til samhandling på tvers av kommuner og mellom kommuner og stat, og vil sette kommunene i stand til å møte brukerbehov på en effektiv og samordnet måte. Integrasjonsplattformen utvides med funksjonalitet basert på behov som følge av KS KommIT sine prosjekt. Side 60 av 68

61 12.2 Systemlandskap for byggesøknad Systemlandskapet for byggesøknad er inndelt i private, nasjonale, felles kommunale og kommunale fag og støttesystem komponenter. Inndelingen viser komponenter og systemer på generell basis. Hver kommune vil ha sin implementering av lokale fag- og støttesystemer. Side 61 av 68