Difference between revisions of "Notule 2007-12-13 Bezoek Enschede Maastricht"

From WOSI
Jump to navigation Jump to search
m
m
Line 125: Line 125:
 
(stukje ruwere notulen dan voorgaande Veel gaat in kernwoorden)  
 
(stukje ruwere notulen dan voorgaande Veel gaat in kernwoorden)  
  
*Keten modellering (integratie)  
+
* Keten modellering (integratie)  
*rapportages  
+
* rapportages  
*proces  
+
* proces  
*dashboard
+
* dashboard
  
 
(uitleg op basis van documenten die we overhandigd kregen)  
 
(uitleg op basis van documenten die we overhandigd kregen)  

Revision as of 22:10, 26 May 2008

De inhoud van deze pagina kom uit dit document
Onderwerp Bezoek Enschede & Maastricht
Datum 13 & 14 december 2007
Aanvang 13 december 2007 09:30
Einde 14 december 2007 19:30
Locatie 13 december 2007 09:30
Notulist Arno
Aanwezigen databaseteam, frameworkteam, moduleteam
Afwezigen


WOSI Bedrijf bezoeken

Dit document bevat een ruwe uitwerking van de aantekeningen die gemaakt zijn tijdens de bedrijfsbezoeken van 13 en 14 December 2008 aan de woningcorporaties in Enschede en Maastricht. Dit document bevat niet alle besproken elementen maar geeft alleen een beeld van de besprekingen van het module en framework team met de corporaties.

Enschede

Tijdens de bijeenkomst zijn we begonnen met het bespreken van een aantal algemene zaken.

Na het formele gedeelte zijn we verder gegaan met het bespreken van de verkoopmodule en de klachtenmodule waarbij opgemerkt moet worden dat door een aantal strategische ontwikkelingen binnen de corporatie de aandacht voor de verkoopapplicatie groter was.

Verkoop

Om te beginnen hebben we de term “Bandbreedte” voorgelegd. Deze term kennen ze in Enschede niet maar op basis van de beschrijving zou dit het beste te omschrijven zijn als “Prijs Indicatie”.

De rol van taxateur wordt binnen Enschede ingevuld door een extern makelaar die ook de waarde schatting voor zijn rekening neemt.

Enschede verkoopt alleen als grens voor mankementen te hoog is om onderhoud op uit te voeren. (Bijvoorbeeld onderhoud kost meer dan 3000,- waarbij het bedrag kan veranderen in de toekomst)

Geïnteresseerden registreren is niet iets wat je alleen op individuele woningen wil doen. Dit moet wel mogelijk zijn in het uiterste geval maar meer op basis van een complex, omgeving of regio.

Bij het selecteren van een koper moet er ook op basis van een groep geselecteerd kunnen worden. Dit heeft onder andere te maken met de sociale samenhang van een wijk. Men wil controle houden over wie in welke hoeveelheid in een wijk gaat wonen om probleemwijken voor te zijn of te voorkomen.

Woningen worden gewoon getaxeerd en in principe word er geen prijs indicatie gegeven.

Er zijn eisen om bijvoorbeeld alleen woningen te verkopen die 10 jaar of ouder zijn.

Alle woningen zijn in principe verkoopbaar. Tijdens een evaluatie word in de database een markering toegeveogd aan woningen die verkocht mogen worden.

Verkoop kan aan de huidige huurder van de woning plaats vinden.
Verkoop proces voor de applicatie start in principe op het moment dat een huurder van een woning die gemarkeerd is voor verkoop zijn huurcontract opzegt.

Als we het over onderhoudsafspraken hebben vinden deze plaats op basis van blokken van twee uur waar de klant uit kan kiezen wat het beste uitkomt. Hiervoor krijgt hij 10 opties.

Bij contract zou taxatiewaarde ook gepubliceerd moeten worden om de koppeling van verkoop prijs te vereenvoudigen.

Voor het verkoopproces is het dus belangrijk dat:

  • Externe inlog duidelijk geregeld is
  • Groepen mogelijk zijn
  • Workflow duidelijk is in de applicatie en dynamische is zodat het makkelijk aangepast kan worden.

Wanneer waarschuw je wie in het proces en waarvoor. Ook de manier is hierbij van belang. Gaan we een e-mail sturen, bij inloggen op het scherm publiceren...

Binnen het proces kunnen er ook verschillende statussen zijn voor de verschillende onderdelen dit moet dus duidelijk zijn beschreven. Denk hierbij aan taxaties die in behandeling zijn en onderhoud die tegelijkertijd bezig is. Ze lopen allebei zijn afhankelijk van elkaar maar toch onafhankelijk.

Binnen verkoop moet onderhoud gezien worden als twee verschillende onderdelen. Namelijk:

  • Het beoordelen van de kwaliteit (moet er verbouwd worden, herstellen of fixen)
  • Het oplossen van problemen.

Dus verkort weergeven

  • Kijken
  • Onderhoud
  • Akkoord
  • Fixen
  • Taxatie
  • Verkopen

Klachten

Specifieker dan nu – op basis van specialisatie en niet meerdere dingen tegelijk. Duidelijke keuzes in het eerste menu.

Authenticatie op basis van postcode, huisnummer en banknummer

Beslisboom zo specifiek mogelijk maken.

Algemene problemen

Geen huurders kunnen ook problemen melden
Problemen kunnen ook buiten reparaties vallen en gaan over sociale problemen of andere omgevingselementen als de hal van het gebouw waar de woning in zit.


Maastricht

Bij de woningcorporatie in Maastricht hebben we alleen de verkoopmodule besproken. De klachtenmodule hebben we achterwegen gelaten omdat de status daarvan nog te onduidelijk is en verkoop een veel grotere prioriteit heeft voor deze corporatie.

Verkoopmodule

In eerste instantie na het demonstreren van de applicatie hebben we een discussie gehad over de richting van de middag. Zouden we in de breedte of in de diepte gaan met de applicatie. Maastricht vond het belangrijk om de nadruk te leggen op de breedte om een goede fundering te leggen in het geheel.

Een punt wat bij die discussie meteen opvalt is het feit dat het registreren van interesse veel breder gezien kan worden dan de huidige implementatie. Behalve het feit dat het op basis van individuele woningen is (wat ook op bijvoorbeeld complex handig zou zijn) kan het zelfde systeem ook gebruikt worden voor bijvoorbeeld het verhuurproces.

Het is nu niet mogelijk om te controleren of een woning geschikt is voor verkoop en ook echt verkocht mag worden. (Systeem voor controleren van woning voor verkoop ontbreekt )

Het interesse systeem zou verder uitgewerkt kunnen worden op basis van bijvoorbeeld google maps waarbij op een kaart een selectie gedaan kan worden naar beschikbare woningen. (Google maps met criteria waar iemand wil wonen en wat de voorzieningen zijn. ) Het gaat hierbij dus eigenlijk om het kunnen selecteren van een regio, straat, complex en op basis daarvan interesse vast leggen. Dus bijvoorbeeld “Ik heb interesse in alle woningen in die regio binnen die prijsklasse”

Zoals eerder ook al omschreven moet de interesse selectie verder uitgewerkt worden. (Heel specifiek moet ook mogelijk zijn. Maar moet niet de standaard optie zijn. )

Sturen op basis van doorlooptijden.

  • Bij verkoop of verhuur vraag kant mee nemen.
  • Bijsturen en registratie
  • Rekening houden met wat je wil weten. Alles moet in het systeem opgenomen worden.
  • Dingen als mixen van wijken zijn belangrijke dingen daar een activatie reden voor kunnen zijn.

(stukje ruwere notulen dan voorgaande Veel gaat in kernwoorden)

  • Keten modellering (integratie)
  • rapportages
  • proces
  • dashboard

(uitleg op basis van documenten die we overhandigd kregen)

Nr 1 is hoe schrijven we iemand in
nr 2 en 3 zijn specifiek het proces.

Bij inloggen validatie om foute en rotzooi gegevens te voorkomen. Geen inloggen is geen optie omdat er dan foute gegevens en niet bestaande mensen in het systeem kunnen komen en de betrouwbaarheid weg is.

huuropzegging geeft overzicht van huizen die beschikbaar zijn voor eventuele verkoop.

Woning echt verkopen moet vastgesteld worden aan het begin van het proces. Het is een keuze die met ja of nee beantwoord kan worden (status, indicator)

op basis van percentages kan gezien worden wat de woningen

Of woning verkocht mag worden moet mogelijkheid zijn om een woning te accepteren voor verkoop of niet te accepteren voor verkoop.

Verkoop team bepaalt verkoop geschiktheid als laatste.

een team mag altijd hetzelfde. individuele personen mogen wat een het team waar ze deel van uitmaken mag.

Definitie van bandbreedte volgens Maastricht (richtinggevend)
“Bandbreedte = verkoop waarde mag niet meer dan +5% of -5% van de taxatie waarde zijn”

Woning kan verkoopsysteem niet in als er onderhoud bezig is. Bij voltooien van onderhoud wel in het systeem met beslissing voor verkoop of verhuur.

DOEL: zo goed mogelijke prijs zo snel mogelijk EN zo goed mogelijk huurder matchen.

Modules zo klein mogelijk omdat de flexibiliteit dan groter is voor de organisatie.
Keywords: Efficiëntie, Snelheid

Tijdens het gesprek blijkt dat er verschillende definities worden gehanteerd voor de verschillende termen.

  • Module = ondersteunt 1 proces.
  • Applicatie = 1 of meerdere modules

Rapportages

Hoeveel inschrijvingen, gemiddelde inschrijftijd, hoeveel huurders willen kopen
huur of koopbedragen,
rapportages per module omdat dat meer meerwaarde heeft.
Hebben een document gekregen waar meer informatie over de rapporatages in staat. (doris rapportages document)