Hvor stort er dette it-projekt i forhold til tidligere projekter hos henholdsvis Erhvervs- og Byggestyrelsen og andre offentlige myndigheder?
Vi har ikke tidligere håndteret it-projekter, som skulle indrettes på at håndtere over 100.000 mere eller mindre samtidige ansøgere. Rent økonomisk og teknisk er projektet imidlertid ikke større eller mere kompliceret end flere andre projekter, som vi har og har haft ansvaret for.
Størrelsen af projekter kan opgøres på mange måder, men på grund af den korte tid vi har haft til rådighed og de store mængder sager, som skal håndteres, har vi haft cirka 60 ansatte (dog ikke på fuld tid) hos EBST og forskellige tekniske underleverandører koblet på.
Dertil kommer selvfølgelig de cirka 50 nye sagsbehandlere, der er blevet trænet til sagsbehandling og det call center på cirka 40 mand, der blev etableret til at lave borgersupport pr. 14.04.09. Så mandskabsmæssigt kan man nok betegne projektet som værende stort for EBST, middelstort i forhold til Statens øvrige projekter.
Til gengæld er tiden for gennemførsel og det økonomiske budget ikke stort set i forhold til EBST og slet ikke i forhold til Statens generelle IT projekter.
Hvad er I blevet mest overraskede over efter lanceringen?
Fra starten var vi klar over, at vi med den tid, der var til rådighed for at bygge løsningen og afteste denne, ikke ville kunne gardere os 100 procent mod tekniske problemer. Ligeledes vidste vi også fra starten, at vi med denne løsning introducerede et nyt koncept overfor borgerne, som ville kunne byde på både teknologiske og brugermæssige udfordringer.
Teknologisk var der få, men selvfølgelig ærgerlige overraskelser, som vi og andre kan bruge næste gang, man vil benytte en elektronisk ansøgning og kommunikation i det omfang, vi har gjort her:
1. Vi fandt ret hurtig ud af, at selvom EBST havde tilstrækkelig kapacitet på vores mailservere, der skulle udsende mails med login information, blev vi som afsender identificeret som potentiel spam hos en række store ISP'er og derved kunne vi konstatere, at vores mails til borgerne blev nedprioriteret hos borgernes egne mail providers og derved opstod der lange ventetider.
Dette kunne muligvis være undgået, hvis vi havde gjort opmærksom på eventuelle ventetider overfor brugerne og dermed bedre afstemt forventningerne til disse på forhånd. Alternativt skulle vi have forsøgt at blive whitelistet hos ISP'erene.
2. Vi havde desværre et nedbrud hos TDC på det nummer, der var til vores call center, og det bevirkede, at mange borgere ikke kunne komme i kontakt med vore tekniske helpdesk i de første hektiske timer den 14.04.09. Det var selvfølgelig meget ærgerligt, men også uden for vores kontrol.
3. Mange borgere oplevede desværre meget store problemer med at tilknytte diverse håndværkertilbud og andre relevante dokumenter. I et par timer var vi overbevist om, at vi havde et kapacitetsproblem ift. linier, switche, servere eller databaser, men efter en grundig gennemgang af diverse systemlogs blev det klart, at vi havde et æ, ø, å problem på en af de servere, der indgik i løsningen.
Det blev løst senere samme dag og efterfølgende har vi kontaktet de ansøgere, der havde problemet og givet dem muligheden for at ansøge.
Side 2 - Svar fra Erhvervs- og Byggestyrelsen
Hvordan er det tekniske setup bag Boligforbedringer.dk ?
Her henviser vi til dokumentet "EBST IT Tekniske løsning"
Hvilken teknik benytter i til at styre besøgspresset?
www.Boligforbedringer.dk er opbygget i EBST's CMS system W2L.
CMS systemet kører i et driftsmiljø, hvor det driver ca. 25 hjemmesider samt et antal værktøjer. Driftsmiljøet er dimensioneret til at klare mange hjemmesider med mange brugere. Da projektet omkring boligforbedringer.dk blev skudt i gang, vurderede vi om det eksisterende miljø ville kunne klare belastningen fra boligforbedringer.dk.
Vi valgte at etablere et isoleret hardware-miljø til boligforbedringer.dk. Vi forudså, at EBST's eksisterende hjemmesider ebst.dk og boligejer.dk også ville opleve en øget trafik - dette vurderede vi, at det eksisterende drift-setup kunne håndtere.
Den umiddelbare løsning ville være at kopiere hele CMS-platformen til ny stærk hardware og opbygge/vedligeholde og drive hjemmesiden derfra. Problemet med denne løsning var, at hjemmesiden skulle i luften så vidt muligt samtidigt med fremsættelsen af lovforslaget den 18. marts. Den nye hardware var ikke-eksisterende, og selve installationen og konfiguration af webservere og databaser ville tage for lang tid og indebære for store risici angående konfigurationsfejl. Desuden var der et udestående omkring licenser, hvis systemet skulle køre på flere servere.
I stedet valgte vi en anden strategi. Boligforbedringer.dk blev opbygget og vedligeholdt på normal vis i EBST's eksisterende driftssystem. Parallelt med dette arbejde, blev der skaffet den fornødne hardware, som skulle drive hjemmesiden. Den nye hardware blev sat op til at hente/cache siderne til boligforbedringer.dk fra EBST's eksisterende driftssystem med et fast interval (vi valgte 15 min.). Dette skaber kun en ubetydelig belastning på det eksisterende driftssystem. Domænet boligforbedringer.dk peger på det nye hardware-setup, som derved tager alt trafikken fra de mange brugere.
Den hardware som blev anskaffet til at servicere boligforbedringer.dk var 4 fysiske servere med en kraftig Cisco router/load balancer foran, som fordeler trafikken imellem de 4 servere. På de 4 servere blev Open Source produktet Varnish anvendt til at styre caching. Der blev etableret en dedikeret 2 Gigabit forbindelse fra Internettet til hardwaren.
Som en ekstra sikkerhed lavede vi "nødforsider" til de forskellige miljøer. I tilfælde af nedbrud på ebst.dk, ville der blive vist en simpel statisk side, som bl.a. havde link til de andre miljøer: boligforbedringer.dk og ansøgningsskemaet. Tilsvarende nødforside blev lavet til boligforbedringer.dk. Det blev dog ikke nødvendigt at anvende disse nødforsider.
Da hjemmesiden blev åbnet den 20. marts viste det sig, at denne løsning kunne stå for et endog meget stort pres.
På det bagvedliggende elektroniske blanket system - Digiform blev følgende platform opsat:
• Der blev lavet en dedikeret 2 gigabit forbindelse til vedhæftning af bilag, samt en 2 gigabit dedikeret forbindelse til trafik mellem borgeren og blanket systemet
• Der blev lavet et kraftigt dedikeret netværk til løsningen baseret på Cisco udstyr, der tog sig af alt fra load balancing, routing til internettet, switching mellem servere m.v. Eksempelvis havde hver server minimum 2 gigabit forbindelse til switchen.
• Der blev opsat 8 web/-applikationsservere til blanket systemet hvor trafikken fra borgerne blev fordelt på
• Der blev opsat en kraftig database (i et failover cluster) med et kraftigt dedikeret disk-system
• Der blev opsat 2 servere til at generere PDF og kvitterings-mail til borgeren, samt mail servere der afleverer mailen til borgeren. De samme servere bliver om natten brugt til at lave overførslen af sager fra blanket systemet til sagsbehandlings system.
• Der blev opsat en upload server (til vedhæftning af bilag) med sit eget disk system
• Fra blanket systemet til sagsbehandlings system er der etableret en dedikeret fiber linie hvor der hver nat mellem 24-6 overføres sager og bilag. Disse indlæses i sagsbehandlings systemet og hver dag er der en ny portion sager klar til sagsbehandlerne. Hvis linien skulle gå ned, er der også forberedt at der manuelt kan flyttes sager systemet til sagsbehandlings systemet, så der hver dag er sager nok til sagsbehandlerne.
• Sagsbehandlings systemet er brugt i forvejen hos Erhvervs & Byggestyrelsen, og her har vi taget det eksisterende system og placeret på en kraftigt skaleret platform, der har kapaciteten til at oprette minimum 10.000 sager per nat, samt klare de mange online sagsbehandlere der bruger systemet i dagtimerne.
Vores testplan blev opbygget efter metoden at sikre at vi kunne klare nedbrud i løsningen uden at det ville påvirke borgeren, samt performance test af "worst case". Vores tests er ikke kun lavet lokalt, men ude fra internettet.
Ligeledes har vi også sørget for at løsningen på alle måder er redundant og kan klare nedbrud i enkelte komponenter - lige fra fysiske ting som nødstrøm, dobbelte netkort, raid disk-systemer m.v. - til logisk redundans hvor databasen kan bringes i drift på en anden server, at PDF generering kan startes på andre maskiner m.v. - og alt sammen uden at systemet ville utilgængeligt for borgeren. Og vi tager selvfølgelig også backup af alle data.
Vi henviser til dokumentet "EBST IT Tekniske løsning" for en detaljeret beskrivelse af løsningen.
Side 3 - Svar fra Erhvervs- og Byggestyrelsen
Hvad har systemet kostet?
Som oplyst i bemærkningerne til loven har vi et budget til IT på cirka 10 millioner kroner. Systemerne er ikke færdigudviklet, men vi styrer udviklingen indenfor denne ramme.
Hvordan skalerer det, når I nu i de kommende dage ikke får nær så mange besøgende som i går?
Rent teknisk skalerer systemet automatisk ift. det load, der er på www.boligforbedringer.dk og det bagvedliggende blanketsystem.
Se i øvrigt vedlagte dokument "EBST IT Tekniske løsning"
Kan systemet genbruges - eller skal det bare arkiveres lodret nu?
Det var fra starten afgørende for os, at vi skulle holde os under et givet budget samt opbygge systemet, således at vi ikke efter "rush-hour" stod med systemmæssig overkapacitet, som EBST ikke kunne bruge til ret meget, med mindre der kom en anden "først til mølle" ordning.
På den infrastrukturmæssige side er derfor meget af infrastrukturen lejet eller leaset og vil derfor uden meromkostning for EBST kunne tilbageleveres nu, hvor det værste load er overstået.
Vi har også i vid udstrækning flyttet interne EBST systemer ud i drift centeret for derved at sikre optimal kapacitet, redundans og beredskab. Disse databaser og applikationer vil ligeledes blive flyttet tilbage på deres gamle produktionsplatforme.
På applikationssiden vil det elektroniske blanketsystem (Digiform) gå tilbage til sin oprindelige funktion, som ansøgningsmulighed i Strukturfonden.
Hvad var de værste fejl ved systemet?
Det var uden tvivl det æ, ø, å problem vi havde på én af vore servere den 14. april 2009.
Hvorfor havde I ikke testet ordentligt for fejl?
Spørgsmålet er i sit udgangspunkt relevant, da alle fejl er én fejl for meget, men man kunne også vende spørgsmålet om og spørge; Hvorledes lykkedes det at gennemteste en løsning med formentlig større kompleksitet og kapacitet end Billetnet på 1½ uge og så ende med at have så få fejl, som vi havde?
Tidsfaktoren har været afgørende. Folketing og regering har lagt meget vægt på at få ordningen i gang snarest muligt efter at Folketinget var færdig med sin behandling af lovforslaget den 2. april. Som bekendt er ordningen udformet for at få gang i en kriseramt byggesektor, hvor meldingen har været at alt var gået i stå i afventning af igangsætning af ordningen.
Vi har derfor truffet den principbeslutning, at vi ville gå i luften med ordningen straks efter påske, medmindre der var risiko for alvorlige nedbrud og tab af data.
Systemet er udviklet og aftestet sideløbende med, at kravspecifikationen blev udarbejdet i takt med den politiske proces der i sidste ende var afgørende for systemets funktioner. Kravspecifikationen blev som følge heraf først låst den 26. marts.
Vi har bemærket, at der i Computerworld og andre medier har været kommentarer om, at man kunne have sikret sig mod de fejl vi oplevede ved at teste mere eller anderledes.
De kommentarer vi har set er i teorien rigtige nok, men afspejler ikke at tidsfaktoren var så afgørende som nævnt.
Vi har beskrevet, hvorledes vi angreb opgaven med test i nedenstående.
Side 4 - Svar fra Erhvervs- og Byggestyrelsen
Hvilken serverplatform, database, hvilke fysiske maskiner kører systemet på?
Her henviser vi til dokumentet "EBST IT Tekniske løsning"
Hvad ligger der bagved webinterfacet, som brugeren møder?
www.boligforbedringer.dk: EBST egetudviklede CMS system W2L
Den elektroniske blanket: Det af EBST og 2M Business Application udviklede Digiform: Adobe Flex og Java
Hvem drifter systemet?
NetGroup A/S, LBE Informatik, 2M Business Application A/S drifter www.boligforbedringer.dk og det elektroniske formular system Digiform.
NetGroup A/S og TDC A/S er ansvarlig for linier ind og ud af EBST.
TMI (Tvær Ministeriel IT) drifter sagsbehandlingssystemet TAS 4.0
Søfartsstyrelsen drifter EBST's Navision Stat
Basecare A/S har defineret driftskriterier, SLA'er og beredskabsplaner for ovenstående samt lavet kvalitetskontrollen af dette
Hvem har udviklet systemet?
- EBST har leveret kravstillere og kontakten til de politiske kravstillere, testere og delprojektledere + øverste ledelse i programmet
- TMI har leveret linier og opsætning/hosting af infrastruktur til TAS og mailservices + EBST bruger hotline
- Advice og LBE Informatik har leveret www.boligforbedringer.dk + CMS
- NetGroup har leveret infrastruktur og liniekapacitet samt hosting af hele web og ansøgningsdelen (Digiform)
- 2M Business Application har leveret Digiform + integration til TAS + teknisk hotline
- Basecare har leveret kapacitetsberegninger, driftskriterier, infrastrukttest og kvalitetssikring af Digiform og mailservices
- Ementor har leveret TAS 4.0 + tilretninger + brugeruddannelse
- Økonomistyrelsen skal sammen Ementor leverer integrationen til Navision Stat
- Schultz har leveret call center via ISS + udsendelse af papirblanket
- Data Scanning har leveret indscanning af papirblanketter samt integration til TAS 4.0
- ProjectHouse har leveret øverste program- og projektledelse, underleverandørstyring samt test management.
Side 5 - Svar fra Erhvervs- og Byggestyrelsen
Hvor lang tid har udviklingsfasen varet?
4 ½ uge fsva frontend. Sagssystemet er fortsat under udvikling
Hvor længe har testfasen varet?
1½ uge. Der er dog blevet testet løbende i takt, med at HW, linier, SW er blevet leveret og opstillet. Det var således end-to-end testen der var 1½ uge til
Hvordan har i testet systemet?
Da It projektet blev igangsat den 09.03.09 stod det klart for alle, at testperioden ville blive meget kort grundet det faktum, at der på det tidspunkt ikke lå en egentlig kravspecifikation eller beskrivelse af Renoveringspuljen og at den politiske proces kunne ændre afgørende ved kravspecifikationen helt frem til idriftsættelsen.
Det var en kondition som leverandørerne måtte acceptere fra starten.
Desuden var der meget kort tid til at bygge systemet. Disse to konditioner tvinger os til at tage en, for typiske offentlige IT projekter, lidt utraditionel byggeteknik i brug, hvor man basalt set bygger systemet via en lang række parallelle projekter, hvor man dog ikke kan fastlåse bruger og systemgrænseflader før til sidst. Dette kunne kun gøres hvis man bruger systemer der har meget fleksible grænseflader og i sin grundform allerede er gennemtestet, samtidig med at man bygger efter nogle kvalificerede antagelser.
Vi tog derfor udgangspunkt i eksisterende systemer i EBST hvorved omfanget af unittest og end-to-end test på de enkelte elementer i løsningen kunne begrænses.
Dernæst havde vi udfordringen med, at skalere disse
systemer til nogle ekstremt høje transaktionsmængder og få en sammenhængende infrastruktur opstillet til understøttelse af disse.
Udover, at forlange dokumentation og fysisk inspektion på
alle unittest af den opstillede infrastruktur benyttede vi os af samme parallel byggeteknik som på applikationssiden kombineret med en testteknik som ofte bliver kaldt "worst case scenario test". For dem der har set filmen "Apollo 13" vil de kunne nikke genkendende til, hvorledes det foregår.
Basalt set får man de bedste eksperter ind på alle de elementer der indgår i løsningen og, så laver man ud fra system blueprint og eksperternes viden en prioriteret liste over de scenarier eller elementer i løsningen som vil give de værste problemer ift. de succeskriterier man skal nå.
Ud fra dette får man så en prioriteret liste over testscenarier, som skal gennemføres inden en go/no go beslutning og en liste over test scenarier som kan gennemføres, hvis tiden tillader det inden go live. Alt efter, hvor langt man når ned af listen inden man løber tør for tid er basalt set med til at give os en indikation af, hvor stor en risiko man går i luften med.
Selve end-to-end løsningen kunne med baggrund i dette, således skubbes makismalt og det betød at vi kunne fortage en end-to-end test baseret på traditionelle use-cases henover påsken.
Side 6 - Svar fra Erhvervs- og Byggestyrelsen
Hvorhenne i landet bor systemet bag Boligforbedringer.dk?
Hos NetGroup bor www.boligforbedringer.dk og Digiform. Hos TMI bor sagsbehandlingssystemet TAS 4.0.
Er systemet færdigudviklet eller er der tale om en løbende process eller en betaversion?
Grundet tidspresset lagde vi allerede den 9. marts den strategi, at dele systemet op i 3 dele:
1. Frontend bestående af www.boligforbedringer.dk og den elektronisk blanket på Digiform samt XML integrationen imellem Digiform og TAS 4.0.
2. Sagsbehandlingsdelen med TAS 4.0
3. Integrationen mellem TAS 4.0 og tilskudsudbetalingen i Navision Stat.
Første del var selvfølgelig den mest afgørende den 14.04.09, da vi både skulle sikre at borgerne kunne aflevere over 100.000 elektroniske ansøgninger og at disse kunne ligge klar til de ca. 50 nye sagsbehandlere den 15.04.09 kl. 08.00.
Som supplement til den digitale ansøgning skulle endvidere udvikles en løsning hvor alle indkomne papiransøgninger skulle scannes af Data Scanning og leveres som en samlet XML fil ind i TAS 4.0.
Disse løsninger løsning er færdigudviklede og virkede fra dag 1.
Anden del er et spørgsmål om, at effektivisere sagsgangene i TAS 4.0 og via udvidet funktionalitet og automatisering nedbringe sagsbehandlingstiden for de 50 sagsbehandlere.
Denne del blev sat i drift (release 1.0) den 14. april og release 2.0 forventes leveret den 01.05.09. En release 3.0 vil herefter blive aftalt imellem parterne ift. de erfaringer der har været med release 1.0 og 2.0.
Tredje del af systemet er sammenhængen mellem TAS 4.0 og udbetalingsdelen i Navision Stat.
Denne del forventes sat i drift (release 1.0) den 01.05.09. En dato for relase 2.0 er endnu ikke aftalt.
Alle applikationer som indgår i løsningen er standardsystemer som blot til lejligheden er modificeret og skaleret op til Renoveringspuljeprojektet.
Hvordan synes i selv, det er gået den første dag?
Bortset fra æ, ø, å som var en ærgerlig fejl i en ellers god løsning vil jeg mene at vi har klaret det godt. Her er lidt fakta fra det første døgn:
- Den 14.04.09 kl. 09.00 Åbnede vi for elektronisk ansøgninger
- Den 14.04.09 kl. 09.07 Havde ca. 60.000 oprettet sig som brugere i Digiform
- Den 14.04.09 kl. 10.00. - 14.00 udsendte vi i gennemsnit ca. 20.000 mails i timen med login information
- Den 14.04.09 kl. 16.00 Havde vores call center håndteret 4.430 opkald fra borgerne og udsendt 3.318 papirblanketter
- Den 14.04.09 kl. 24.00 Lå der ca. 85.000 ansøgninger i Digiform som borgerne havde modtaget kvittering på
.
- Den 14.04.09 kl. 16.00 Var der 30 nyuddannede sagsbehandlere klar til sagsbehandling i TAS 4.0
- Den 15.04.09 kl. 06.00 Lå der ca. 85.000 ansøgninger klar i TAS 4.0 til sagsbehandling
- Den 15.04.09 kl. 08.50 Startede der 30 sagsbehandlere på behandling af ovennævnte sager
- Den 15.04.09 kl. 09.00 Var de første 2 tilsagn til borgerne røget af sted
Side 7 - Svar fra Erhvervs- og Byggestyrelsen
Systemet var i stand til at håndtere mange brugere. Alligevel er der stor forskel på hastigheden af eksempelvis email-bekræftelser. Hvad skyldes denne forskel?
Der var to forhold vi blev ramt af:
1. problem: Mail og pdf servere var designet til at kunne håndtere 30.000 mails og pdf dokumenter i timen. De første 7 minutter skulle vi genere ca. 60.000 nye brugere og tilhørende pdf dokumenter.
Nogle borgere måtte vente op til 2 - 3 timer med at modtage EBST mailen med deres user-id og password, for at kunne logge ind på selve ansøgningsskemaet.
I den første time fra kl. 09.00 - 11.00 havde vores mailservere svært ved at følge med, da der var ca. 90.000 nye brugere der skulle bruge et login. Systemet var designmæssigt bygget til en belastning der hed ca. 25.000 - 40.000 mails i timen og den kapacitet holdt. Det betød at vi kl. 10.00 havde ca. 50.000 mails i kø og at denne kø var afviklet kl. 12.00 - 13.00.
Det var selvfølgelig muligt at designe mailsystemet til en langt højere kapacitet, men her spiller tid/økonomi og vores forventninger til hvad der ville ske ved en overbelastning ind. Worst case var jo det, der skete -. at der var en del ventetid.
2. problem: EBST blev identificeret som potentiel mailspammer grundet de meget store mailmængder på meget kort tid.
Borgerne oplevede ekstreme forskelle på, hvor hurtigt de modtog deres mails. Langt de fleste fik den inden for 5 minutter og nogen måtte vente op til 5 - 6 timer.
Udover den kø der opstod på vores egne mailservere, blev EBST login- og kvitteringsmails identificeret som potentiel spam af en række store mail providers, grundet de ekstremt store mailmængder på meget kort tid. Dette er en del af sikkerhedsberedskabet hos nogen af disse store mail providers og det bevirker at de kan nedsætte hastigheden for videresendelsen af alle mails der kommer fra EBST.
Dette betyder i sidste ende, at nogle borgere får en yderligere forsinkelse på modtagelsen af sin mail og der var ekstremt store forskelle på hvor hurtigt en borgers mail blev ekspederet efter afsendelse fra EBST's mailserver alt efter hvilken mail provider borgerens opgivne mailadresse bliver sendt fra.
En anden gang vil vi nok afstå fra at inddrage almindelig e-mail i en "først til mølle" løsning.
Side 8 - Svar fra Erhvervs- og Byggestyrelsen
Der var problemer med de danske bogstaver Æ. Ø og Å. Hvad skyldes det, og hvordan har i løst det?
En kommunikationsfejl på vedhæftninger mellem ansøgningsskema og upload server. Fejlen blev meget hurtigt rettet da vi fik den lokaliseret.
Grunden til, at vi ikke fandt fejlen med det samme var simpelthen fordi vi ikke kunne finde det korrekte mønster i den ret enorme logfil der blev genereret i de allerførste timer efter puljens opstart og at næsten alle var overbevist om at vi skulle kigge efter et andet mønster i logfilen end det der rent faktisk viste sig at være fejlen.
Der var problemer med Flash. Hvad skyldes det?
Vi har ikke registreret store problemer med Flash. Der var et par opkald vedr. flash til supportlinjen og de vedrørte ansøgere som endnu ikke havde Flash installeret på deres computer. Ansøgningsskemaet fungerer med Flash 9 (red. + 10), hvor den seneste version er 10. Det betyder at langt størsteparten af landets computere faktisk var klar til ansøgningen uden at skulle installere eller opdatere Flash.
Hvordan understøtter systemet Linux og Mac?
Som sagt virker systemet med Flash Player 9 og fremad. Det betyder, at Linux og Macs også er understøttet
Hvordan understøtter systemet alternative browsere som eksempelvis Firefox og Safari?
Det virker også i Firefox og Safari
Der har været kritik blandt brugerne af det grafiske udtryk. Blandt andet kan man først logge af, når man er næsten helt igennem ansøgningsformularerne. Hvad siger du til kritikken af brugervenligheden?
Hvor mange besøgende har der været det første døgn?
Kigger man på diverse blogs og medier er det ligeligt fordelt med brugere, som syntes det var en dårlig brugervenlighed, og dem som syntes, at den var god. Med "Først til Mølle" princippet gjaldt det for folk at udfylde alt så hurtigt som muligt. Det har vi eksempelvis set i de indsendte ansøgninger.
Her kan vi se hvor stærkt, det er gået. Flere har udfyldt feltet Navn med fornavn og feltet Adresse med efternavn. De havde formodentlig forventet at skulle udfylde først fornavn og dernæst efternavn. Men de har ikke givet sig selv tid at læse, hvad de skulle udfylde.
Rigtig mange har også afsendt ansøgningen indenfor et par minutter, incl. bruger oprettelse, hentning af Flash fil, udfyldelse og afsendelse. Det har de kunnet klare på 2-3 minutter, så brugerfladen har vel for disse været intuitiv nok. Vi bestræber os dog altid for at gøre tingene bedre, så der vil helt sikkert blive en efter evaluering på denne del også.
Hvor mange ansøgninger er indleveret?
P.t. ca. 100.000 (97.000 elektroniske og 3.000 papiransøgninger)
Hvor mange ansøgninger er kikset?
Hvad menes med kikset?
Vi har ikke mistet nogen af de ansøgninger der har fået en kvittering for modtagelsen og det er ca. 100.000 på nuværende tidspunkt.
Der var 4.415 borgere der oplevede problemer med upload som resulterede i, at de blev forhindret i at ansøge. Mange af disse har efterfølgende prøvet igen og haft succes med ansøgningen.
Alle 4.415 borgere har fået en personlig henvendelse via mail fra EBST, hvori de bliver opfordret til at ansøge igen, såfremt de endnu ikke har fundet andre veje til at lave en succesfuld ansøgning.
Så er der selvfølgelig også eksempler i pressen på folk, der slet ikke fik oprettet sig som brugere og dermed kunne benytte den elektroniske ansøgning. Disse har vi både på hjemmesiden www.boligforbedringer.dk og via pressen opfordret til at prøve igen eller rekvirere en papiransøgning.
