CORA: De referentiearchitectuur voor Nederlandse woningcorporaties. Versie 3.0 Verkenningen en voorbeelden

Transcriptie

1 CORA: De referentiearchitectuur voor Nederlandse woningcorporaties Versie 3.0 Verkenningen en voorbeelden

2 CORA is tot stand gekomen met medewerking van de volgende woningcorporaties: De Alliantie, Eigen Haard, Havensteder, Lefier, Mitros, Portaal, Rochdale, RWS Goes, Stadgenoot, Vestia, Wonen Breburg, Woonbedrijf Eindhoven, Woonbron, De Woonplaats, Woonstad Rotterdam, Woonzorg Nederland en Ymere. Verder hebben verschillende marktpartijen en overheidsinstellingen een bijdrage geleverd aan CORA. Het traject om tot deze versie van CORA te komen werd begeleid door PMtD Consultancy CORA werd mede mogelijk gemaakt door NetwIT, het Netwerk woningcorporaties en Informatie Technologie FLOW, de Stichting Fonds Leren en Ontwikkelen Wooncorporaties Vereniging van woningcorporaties Aedes. Er is ook een tabletversie van dit document beschikbaar. CORA is als PDF bestand op te vragen bij NetwIT ( en Aedes ( Contactinformatie: onder vermelding van: CORA Aedes NetwIT, december 2012 CORA 3.0 2

3 Inhoudsopgave 1 Inleiding Voorbeeld uitwerking onderhouden eenheden Voorbeeld uitwerking proces vastgoedsturing Voorbeelden applicatiearchitectuur Identificering en typering relaties Woonruimteverdeling (Vastgoed-Relaties) Praktijkvoorbeelden BAG Arubastraat te Delft Catharinastraat te Breda Groepswoning te IJburg Javaplein te Amsterdam Oppert te Rotterdam Schorsmolenstraat en omgeving te Breda Van Baerleplantsoen te Dordrecht Sjablonen voor beschrijving van dienstverlening CORA 3.0 3

4 1 Inleiding Dit document is CORA Verkenningen en voorbeelden. Het bevat voorbeelden en praktijkcases van de focusgebieden uit CORA 3.0. Niet alle voorbeelden en praktijkcases sluiten aan op de modellering en conventies van CORA 3.0, sommige voorbeelden zijn nog gebaseerd op CORA 1.0 of CORA 2.0. CORA 3.0 4

5 2 Voorbeeld uitwerking onderhouden eenheden Om tot een uitwerking te komen van de onderhoudprocessen, en daarbij het in ogenschouw nemen van de gevolgen voor (mutaties aan) het vastgoed, wordt eerst de levenslijn van het vastgoed bij een corporatie gepresenteerd. Levenslijn Het vastgoed komt in beeld bij de woningcorporatie bij de ontwikkeling, de nieuwbouw van eenheden of de aankoop van nieuwe eenheden. Na het akkoord op de oplevering c.q. de acceptatie van een vastgoedeenheid begint het leven van deze eenheid in het kader van het beheer en onderhoud (het beginpunt in de levenslijn). SVB = Strategisch voorraadbeheer, ZAV = Zelf aangebrachte voorziening Figuur 2.1 levenslijn onderhouden eenheden De voorgaande processen met betrekking tot ontwikkeling of aankoop worden hier niet verder uitgewerkt (buiten beschouwing). Bij dit beginpunt zijn de vastgoedgegevens van een eenheid vastgelegd als de beginsituatie van het beheer (exploitatie) en voor de gewenste vorm van dienstverlening. Dit kan betekenen dat alleen dienstverlening wordt gedaan in het kader van (planmatig) onderhoud (verkochte eenheid) of dat zowel verhuur, onderhoud en andere vormen van dienstverlening worden toegepast (verhuurde eenheid). Meer of minder dienstverlening impliceert ook dat er meer of minder gebeurtenissen zijn in de levenslijn voor het uitvoeren van werkprocessen die invloed hebben op de situatie van de (vastgoed)eenheid. De levenslijn eindigt als de eenheid definitief uit beheer (exploitatie) wordt genomen voor de corporatie. Dit impliceert dat de eenheid wordt gesloopt, verkocht zonder terugkoopplichten of zodanig wordt aangepast, dat de eenheid niet meer bestaat. De processen voor de afhandeling van het uit beheer nemen, sloop, verkoop of herstructurering worden hier niet verder uitgewerkt (buiten beschouwing). Gebeurtenissen In de levenslijn van het vastgoed zijn gebeurtenissen onderkend, die werkprocessen initiëren (triggeren) en daarmee invloed hebben op het vastgoed. Deze gebeurtenissen bepalen de verschillen in de processen, zoals met name aan de voorkant (initiëren onderhoud) en de achterkant (verwerken resultaten). Deze aspecten zijn: Initiatief gepland of niet gepland; Kosten voor klant; deels of geheel, direct of indirect; Tijdelijke of definitieve herhuisvesting noodzakelijk ; Functie c.q. doelgroepverandering tot gevolg. CORA 3.0 5

6 Dit levert de onderstaande matrix: Gebeurtenis Gepland Kosten Herhuisvestinverandering Functie- Proces klant ZAV- afhandeling* Nee Ja Nee Nee Verwerken verzoek tot ZAV Reparatie Nee Nee, mits Nee Nee Verwerken verzoek tot Reparatie Huuropzegging Nee Nee, mits Nee, maar Nee Verwerken verzoek huuropzegging Aanpassing op medische Nee Ja Nee Nee, maar Verwerken verzoek medische indicatie (gemeente) aanpassing Individuele verbetering Nee Ja Nee Nee, maar Verwerken verzoek individuele verbetering Calamiteit - afhandeling Nee Nee, mits Nee, mits Nee, mits Verwerken calamiteit Periodiek onderhoud Ja Nee Nee Nee Onderhouden periodiek SVB Ja Ja, maar Nee, maar Ja, maar Verbeteren complex (renoveren) SVB Ja Ja, maar Ja, definitief Ja Herstructureren * ZAV = Zelf Aangebrachte Voorziening Figuur 2.2 matrix aspecten per onderhoudsproces Uit de matrix komt naar voren dat er 9 verschillende processen zijn te benoemen. Deze processen hebben wel allemaal het gemeenschappelijke kernproces voor de uitvoering van de onderhoudswerkzaamheden. De renovatieprocessen en herstructureringsprocessen die voortkomen uit SVB (strategisch voorraadbeheer) zijn hier niet verder gemodelleerd. Wel worden ze geraakt in het proces Periodiek Onderhoud. Buiten Renoveren en Herstructureren zijn de processen hierna in detail uitgewerkt, waarbij eenmalig het gemeenschappelijke kernproces (het daadwerkelijke onderhoud) is beschreven. De processen zijn generiek en inrichtingsonafhankelijk beschreven, dus zonder verwijzing naar afdelingen of ondersteunende systemen. Hoofdschema Onderhouden Vastgoed Niet planmatig onderhoud Dit processchema laat op hoog abstractieniveau zien welke soort gebeurtenis tot onderhoud en daarmee wijzigingen in het vastgoed kan leiden: Verzoek tot ZAV (zelf aangebracht voorziening), deze wordt alleen in het hoofdschema beschreven Verzoek tot reparatie (reparatieonderhoud) Verzoek tot huuropzegging (mutatieonderhoud) Individueel verzoek tot verbetering Melding calamiteit (onderhoud t.g.v. een calamiteit) Verzoek op medische indicatie (aanpassingen vanwege medische oorzaak) Het beoordelen van een verzoek of melding en de uitvoering ervan zijn gesplitst. De uitwerking van de onderhoudsprocessen verschilt per gebeurtenis. Het subproces Verzoek tot ZAV is alleen in het hoofdschema uitgewerkt in plaats van in een aparte tekening. Daarom is de ZAV stroom in onderstaande afbeelding ook oranje weergegeven. Het uitvoeren van het onderhoud zelf, gaat veelal op dezelfde manier. Daarom is dit in één proces weergegeven. De verwerking van de resultaten nadat het onderhoud is uitgevoerd kan ook weer verschillen per gebeurtenis, dit is niet tot in detail uitgewerkt, alleen in het hoofdschema. CORA 3.0 6

7 De tekening laat dus de samenhang zien tussen de gebeurtenissen en het uitvoeren van het onderhoud en geeft aan dat dit kan leiden tot diverse gevolgen voor de cartotheek, huurprijzen, crediteuren en/of debiteurenadministratie. Het planmatig onderhoud is niet in dit schema opgenomen (zie volgende paragraaf). CORA 3.0 7

8 zelf aan te brengen verbetering Verzoek tot ZAV Verzoek tot reparatie Verzoek tot huuropzegging Individueel verzoek tot verbetering Melding calamiteit Verzoek op medische indicatie Vaststellen actie op melding Vaststellen actie op melding Uitgewerkt in subprocessen XOR Afgewezen melding XOR Goedgekeurd ZAV verzoek Goedgekeurd onderhoudsverzoek Vastleggen afspraken met huurder Uitvoeren onderhoud Vastgelegde afspraken met huurder Uitgevoerd onderhoud Uitgewerkt in subproces Uitvoeren niet planmatig onderhoud V Uitvoeren ZAV Aanpassen carthoteek Aanpassen huurprijzen Afwikkelen crediteuren Afwikkelen debiteuren V Afgeronde ZAV Afgeronde reparatie Afgeronde huuropzegging Afgerond individuele verbetering Afgeronde calamiteit Figuur 2.3 Hoofdschema Onderhouden Vastgoed Niet planmatig onderhoud Afgeronde medische aanpassing Toelichting symbolen: = OF (en/of); elke binnenkomende tak, of een combinatie daarvan, zet de uitgaande tak in werking. Een of meer uitgaande takken wordt geactiveerd als een inkomende tak is afgerond. = XOR = excluded OR; alleen één binnenkomende tak zet de uitgaande tak in werking. Alleen één uitgaande tak wordt in werking gezet als de inkomende tak is afgerond. = EN; de uitgaande tak wordt alleen in werking gezet nadat alle binnenkomende takken zijn afgerond. Twee of meer uitgaande takken worden in werking gezet nadat de binnenkomende tak is afgerond. Toelichting gebruik informatiebronnnen (blauwe symbolen): Worden niet in het hoofdschema gebruikt Worden niet gebruikt voor standaard procedures, werkinstructies, beleidregels etc. CORA 3.0 8

9 Subproces Verwerken verzoek tot reparatie Dit proces beschrijft het aannemen en beoordelen van een verzoek tot reparatie. Dit proces gaat vooraf aan het proces Uitvoeren van Niet Planmatig Onderhoud en verwerken resultaat. 1. Een verzoek tot reparatie wordt ontvangen van de huurder. 2. De aanvraag wordt geregistreerd en beoordeeld op volledigheid, juistheid, of behandeling past in het beleid en of actueel of gepland onderhoud bekend is. 3. Als de melding niet in behandeling wordt genomen volgt afwijzing en terugkoppeling naar de aanvrager. 4. Als het nodig is wordt het pand geïnspecteerd en bepaald of reparatie nodig is. Als reparatie niet nodig blijkt, volgt afwijzing en terugkoppeling naar de aanvrager. 5. Er wordt bepaald hoe de kosten gedekt worden, bijvoorbeeld garantie die van toepassing is of dat de huurder aansprakelijk is voor schade aan de woning. 6. Als de dekking van de kosten akkoord is, wordt opdracht tot uitvoering gegeven. Verzoek tot reparatie Ontvangen melding Ontvangst melding Vastleggen en beoordelen reparatiemelding XOR Afwijzing melding Reparatieverzoek XOR Inspecteren woning Inspectieverslag Geaccepteerd reparatieverzoek Geïnspecteerde woning Bepalen noodzaak reparatie XOR Afwijzing reparatieverzoek Bepalen dekking kosten Kostendekking reparatie Goedkeuring reparatieverzoek Kostendekking reparatie Beoordelen dekking kosten Ingetrokken reparatieverzoek Factuurgegevens XOR Goedgekeurd onderhoudsverzoek Figuur 2.4 subproces Verwerken verzoek tot reparatie CORA 3.0 9

10 Subproces Verwerken verzoek tot huuropzegging Dit proces beschrijft het opzeggen van een huurovereenkomst, waaruit mutatieonderhoud kan volgen. Dit proces gaat vooraf aan Uitvoeren Niet Planmatig Onderhoud en verwerken resultaat. 1. Het verzoek tot huuropzegging wordt ontvangen van de huurder of vertegenwoordigende partij. 2. Het verzoek wordt geregistreerd en beoordeeld op volledigheid en juistheid. 3. Als het verzoek niet in behandeling wordt genomen volgt een afwijzing. 4. De woning wordt geïnspecteerd. Tijdens de inspectie wordt geregistreerd: a. eventuele gebreken met bijkomende kosten b. eventuele ZAV afspraken c. huurprijsaanpassingen d. benodigd planmatig onderhoud (voor rekening van corporatie). e. Benodigd mutatieonderhoud (voor rekening van de corporatie) f. opleverdatum van de woning. 5. Als werkzaamheden voor rekening van de huurder zijn, wordt met de huurder besproken of die de gebreken zelf herstelt. Zo ja, voert deze het werk zelf uit. Dit wordt bij de eindcontrole gecontroleerd. 6. Als de huurder het werk niet zelf uitvoert wordt een opdracht tot mutatieonderhoud gegeven. 7. Als er planmatig onderhoud uitgevoerd moet worden, wordt hiervoor opdracht gegeven (vindt plaats na einde contractdatum). 8. O.b.v. het inspectieverslag wordt de huuropzegging verwerkt (einddatum contract). 9. Bij de eindcontrole wordt gecontroleerd of de huurder de woning goed heeft opgeleverd, worden meterstanden opgenomen enz. Uit te voeren werk huurder Afspraken ZAV Inspecteren woning Geaccepteerd Vz tot huuropzegging Geïnspecteerde woning V Verzoek tot Huuropzegging Ontvangen melding Ontvangst melding Vastleggen en beoordelen vz tot huuropzegging XOR Inspectieverslag Afwijzing melding Goedkeuren huuropzegging Goedgekeurde huuropzegging Uitvoeren werk huurder Verzoeken tot versneld planmatig onderhoud Opstellen aanbod mutatieonderhoud Aanbod mutatieonderhoud Uitgevoerd werk huurder Verzoek tot planmatig onderhoud Aanbod mutatieonderhoud Uitvoeren eindcontrole Inspectieverslag Beoordelen aanbod mutatieonderhoud Afgeronde huuropzegging Reactie huurder op aanbod mutatieonderhoud V Afgekeurde huuropzegging Goedgekeurd onderhoudsverzoek Figuur 2.5 subproces Verwerken verzoek tot huuropzegging CORA

11 Subproces Verwerken Individueel verzoek tot verbetering. Dit proces beschrijft het aannemen en beoordelen van een individueel verzoek tot verbetering (geriefverbetering). Dit proces gaat vooraf aan het proces Uitvoeren van Niet Planmatig Onderhoud en verwerken resultaat. 1. Een individueel verzoek tot verbetering wordt ontvangen van de huurder. 2. De aanvraag wordt geregistreerd en beoordeeld op volledigheid, juistheid, of behandeling past in het beleid en of actueel of gepland onderhoud bekend is. 3. Als de melding niet in behandeling wordt genomen volgt afwijzing. 4. Het pand wordt geïnspecteerd, als voorbereiding op het vaststellen van de werkzaamheden en het maken van de offerte aan de huurder. 5. De uit te voeren werkzaamheden worden vastgesteld, op basis daarvan wordt een offerte gemaakt voor de huurder. Dit kan door de corporatie worden gedaan, maar ook uitbesteed worden aan een externe partij. Bij uitbesteding wordt de offerte eerst beoordeeld door de corporatie, voor deze naar de huurder gaat. 6. De huurder beoordeelt de offerte. 7. De huurder kan het verzoek intrekken na beoordeling van de offerte. 8. Na goedkeuring van de offerte volgt opdracht tot uitvoering. Lijst met standaard toegestane individuele verbeteringen Individueel Verzoek tot verbetering Ontvangen melding Ontvangst melding Vastleggen en beoordelen vz tot individuele verbetering XOR Geaccepteerd Indiv Vz tot Verbetering XOR Inspecteren woning Geïnspecteerde woning Opstellen offerte Offerte Individuele verbetering Beoordelen offerte individuele verbetering Afwijzing melding Afwijzing verzoek op basis van lijst standaard toegestane verbeteringen Inspectieverslag Offerte Individuele verbetering Reactie huurder op offerte individuele verbetering XOR Ingetrokken verzoek tot individuele verbetering Goedgekeurd onderhoudsverzoek Figuur 2.6 subproces Verwerken Individueel verzoek tot verbetering CORA

12 Subproces Verwerken calamiteitenmelding Dit proces beschrijft het aannemen van een calamiteitenmelding. Dit proces gaat vooraf aan het proces Uitvoeren Niet Planmatig Onderhoud en verwerken resultaat. 1. Een calamiteit wordt ontvangen van de huurder, een medewerker of een externe partij. 2. De melding wordt beoordeeld op volledigheid en juistheid. 3. Als de melding niet in behandeling wordt genomen volgt afwijzing. 4. De calamiteit wordt geïnspecteerd. Tevens wordt 5. bekeken of de verzekeraar dient te worden ingeschakeld. 6. Direct uit te voeren activiteiten regelen. 7. Van activiteiten die later uitgevoerd kunnen worden, wordt de dekking van de kosten bepaald en gecontroleerd welk onderhoud gepland staat. 8. Als de bewoners niet in de woning kunnen (ver)blijven, wordt herhuisvesting in gang gezet. 9. Als het pand niet meer kan worden hersteld, gaat het uit exploitatie. Dit is buiten de scope van het onderhoudsproces. 10. De uit te voeren werkzaamheden worden vastgesteld en besproken met de huurder of aanvrager. Incidenteel kan dit leiden tot een (extra) verzoek tot verbetering. 11. De opdracht tot uitvoering wordt gegeven. Figuur 2.7 subproces Verwerken calamiteitenmelding CORA

13 Subproces Verwerken verzoek aanpassing op medische indicatie Dit proces beschrijft het aannemen en beoordelen van een verzoek tot aanpassing op medische indicatie. Dit proces gaat vooraf aan het proces Uitvoeren van Niet Planmatig Onderhoud en verwerken resultaat. 1. Een verzoek op medische indicatie wordt ontvangen van de huurder. 2. De aanvraag wordt geregistreerd en beoordeeld op volledigheid, juistheid en of behandeling past in het beleid. 3. Als de melding niet in behandeling wordt genomen volgt afwijzing en terugkoppeling naar de aanvrager. 4. Als het geen standaardaanpassing is, wordt de woning 5. geïnspecteerd en beschreven hoe de aanpassing plaats 6. kan vinden. Er wordt dan een offerte gemaakt van de kosten van de aanpassing. 7. In de praktijk zijn er aanpassingen die zo standaard zijn dat er geen offerte voor de gemeente nodig is, alleen prijsafspraken. Bijvoorbeeld: een verhoogde toiletpot, handgrepen 8. In andere gevallen bepaalt de gemeente of de aanpassing doorgang kan vinden en of de huurder een eigen bijdrage moet leveren. 9. Als de aanpassing niet doorgaat, volgt intrekking van het verzoek. 10. Als de aanpassing akkoord is gegeven door gemeente en huurder wordt opdracht tot uitvoering gegeven. Lijst met standaard voorzieningen Verzoek op medische indicatie Ontvangen melding Ontvangst melding Vastleggen en beoordelen Vz op medische indicatie XOR Geaccepteerd Vz tot Aanpassing Afwijzing melding Afwijzing verzoek op basis beleid en mogelijkheden XOR Prijsafspraken gemeente medische aanpassing Goedkeuren standaard aanpassing Inspecteren woning Inspectieverslag XOR Geïnspecteerde woning Toestemming gemeente nodig Opstellen offerte Offerte benodigde aanpassing Offerte benodigde aanpassing React. gemeente offerte aanpassing Beoordelen Offerte benodigde aanpassing V optioneel Ingetrokken verzoek op medische indicatie Reactie huurder eigen bijdrage Goedgekeurd onderhoudsverzoek Figuur 2.8 subproces Verwerken verzoek aanpassing op medische indicatie CORA

14 Subproces Uitvoeren Niet Planmatig Onderhoud Dit proces beschrijft het generieke deel van het uitvoeren van Niet Planmatig Onderhoud. Vanuit de subprocessen verzoek tot ZAV, reparatie, huuropzegging, verbetering, op medische indicatie of melding calamiteit is een goedgekeurd onderhoudsverzoek ingediend. De aanvrager kan een medewerker zijn of een huurder. 1. Onderhoud maakt een (werk)opdracht aan. 2. De uitvoerder wordt bepaald, dit kan of intern of extern worden uitgevoerd. Als het werk wordt uitbesteed wordt de prijs bepaald waarvoor dit wordt uitgevoerd. Meestal wordt gewerkt met standaardprijzen (bijvoorbeeld 3. vanuit een raamovereenkomst of andere afspraak), 4. anders wordt een prijs afgesproken via een 5. offertetraject (het deel over prijsbepaling is niet 6. in het schema gemodelleerd). Ook afspraken die de planning beïnvloeden worden hier bepaald. 7. De opdracht wordt gepland met de aanvrager. 8. Het onderhoud wordt uitgevoerd. De uitvoerder registreert hierbij de verbruikte materialen, de bestede uren en de status. 9. De aanvrager inspecteert het resultaat. Als de uitvoering niet akkoord is, wordt een aanvullende werkopdracht gepland. Of, als blijkt dat de opdracht niet volledig was, een nieuwe opdracht gepland. Goedgekeurd onderhoudsverzoek Aanmaken Opdracht Aangemaakte opdracht Bepalen uitvoerder XOR Interne uitvoerder Externe uitvoerder Bepalen planning uit te voeren werk Afspraken met huurder Vastgelegde planning Uitvoeren werk Registratie uitgevoerd werk Uitgevoerd werk Registratie verbruikte resources Beoordelen uitgevoerd werk Onvolledige uitvoering XOR Afgekeurde uitvoering Aanvullende opdracht nodig Uitgevoerd onderhoud Figuur 2.9 Subproces Uitvoeren Niet Planmatig Onderhoud CORA

15 Processchema Uitvoeren planmatig onderhoud Het planmatig onderhoud gaat over de gebeurtenissen aan de onderkant van de levenslijn: Figuur 2.10 Levenslijn onderhouden eenheden Planmatig onderhoud is gepland onderhoud (vaak wordt ook de term projectmatig onderhoud gebruikt) en omvat zowel het periodiek onderhoud als het onderhoud dat voortkomt uit strategische overwegingen (SVB = Strategisch Voorraad Beheer). 1. Vanuit het beheerplan voor het bezit wordt het periodiek onderhoud vastgesteld (schilderwerk, cv s vervangen enz.). 2. Vanuit strategische beleidskeuzes worden plannen gemaakt om het bezit te verbeteren of anderszins te wijzigen (isolatie, renovatie, liften plaatsen enz.). Er zijn 3 fasen te onderscheiden: Meerjarenonderhoudsplan-MJOP (vaak ook aangeduid als meerjarenonderhoudsraming MJOR) Onderhoudsjaarbegroting (1 jaar) Uitvoeren onderhoudsjaarbegroting 3. De plannen voor periodiek- en verbeteronderhoud worden opgenomen in het Meerjaren onderhoudsplan (MJOP of MJOR). 4. Elk jaar wordt bepaald welke plannen uitgevoerd gaan worden. Plannen uit het meerjaren onderhoudsplan kunnen opgeschoven worden. 5. De onderhoudsjaarbegroting wordt opgesteld. Voor de goedgekeurde plannen wordt de werkvoorbereiding gedaan (specificaties en planning opstellen, offertes aanvragen en bestellingen plaatsen). Het kan ook worden uitgevoerd op contractbasis, bijvoorbeeld onderhoud van liften, vervanging van cv s. 6. De bewoners worden op de hoogte gesteld. 7. Bij verbeterprojecten kunnen de bewoners inspraak hebben of ze de verbeteringen afnemen. 8. Bij inspraak kan een deel van het project (een reeks verbeteringen in een reeks woningen) worden afgezegd. Voor het periodiek onderhoud en de niet afgekeurde verbeteringen wordt opdracht tot uitvoering gegeven. Op basis hiervan vindt realisatie plaats en worden kosten geboekt (als gevolg van urenschrijven, facturen van aannemers, e.d.). Deze kosten worden bewaakt door ze te vergelijken met de budgetten van de (goedgekeurde) onderhoudsjaarbegroting. CORA

16 Figuur 2.11 Processchema planmatig onderhoud CORA

17 3 Voorbeeld uitwerking proces vastgoedsturing In hoofdstuk 5 van CORA 3.0 is een uitwerking gemaakt van de processen rond vastgoedsturing. Dit geeft inzicht in de positionering en samenhang van sturende processen op strategisch en tactisch niveau en de wijze waarop de portefeuillestrategie vertaald wordt naar tactische kaders voor de operationele uitwerking. Conventies Het voorbeeld gaat uit van een indeling in processen op strategisch, tactisch en operationeel niveau. Deze wijze van modelleren is afwijkend van het procesmodel in CORA 3.0 en is gedaan om de samenhang van sturingsprocessen op strategisch en tactisch niveau duidelijk te illustreren. De processen van vastgoedsturing op strategisch en tactisch niveau zijn uitgewerkt conform onderstaande tekenconventie. Figuur 3.1 tekenconventie proces Naamconventies voor het aanduiden van de processen zijn conform CORA 3.0 (werkwoord + zelfstandig naamwoord, bijv. Opstellen vastgoedstrategie). Verder zijn er een aantal specifieke conventies gehanteerd: Beheren Bij processen met de aanduiding Beheren wordt beheren in brede zin bedoeld, als aanduiding voor een proces waarin een regelkring zit ( Deming circle Plan- Do-Check-Act). Dergelijke processen hebben dus geen betrekking op operationeel beheren. Evalueren Bij processtappen met de aanduiding Evalueren wordt informatie gebruikt over beleid, plannen en bereikte resultaten. Deze informatie is afkomstig uit andere processen maar deze relaties zijn omwille van de leesbaarheid niet expliciet opgenomen. Achtereenvolgens worden behandeld: Procesmodel waarin alle processen van de corporatie gepositioneerd zijn op strategische, tactisch en operationeel niveau. De sturingscyclus van vastgoedsturing (8 baan model). Uitwerking van de processen m.b.t. vastgoedsturing op strategisch en tactisch niveau. CORA

18 Procesmodel - Positionering corporatieprocessen In onderstaand procesmodel zijn de corporatieprocessen gepositioneerd op strategisch, tactisch en operationeel niveau. Figuur 3.2 procesmodel Opmerkingen De sturende processen m.b.t. vastgoedsturing op strategisch en tactisch niveau zijn licht blauw gemarkeerd. Deze worden onderstaand verder uitgewerkt. Alle (primaire) processen op operationeel niveau zijn voor de sturingscyclus van vastgoedsturing gegroepeerd en aangeduid met Exploiteren en Investeren (zie grijs gemarkeerd blok). De processen binnen dit blok zijn nog gebaseerd op CORA 1.0. Vastgoedsturingscyclus Op de volgende pagina is de sturingscyclus van de vastgoedportefeuille weergegeven (RIGO 8 baan model, gebaseerd op Deming circle Plan-Do-Check-Act). Hierin wordt de samenhang duidelijk tussen de processen op strategisch, tactische en operationeel niveau. CORA

19 Figuur 3.3 baan model vastgoedsturing De besturingscyclus van de vastgoedgerelateerde dienstenportefeuille is op de volgende pagina samengevat. Figuur 3.4 baan model sturing diensten CORA

20 De processen van vastgoedsturing op strategisch en tactisch niveau zijn onderstaand weergegeven. Strategische processen Figuur 3.5 strategische processen vastgoed Ontwikkelen gebiedsstrategie Figuur 3.6 proces ontwikkelen gebiedsstrategie Ontwikkelen gebiedsstrategie Analyse leefomgeving en gebiedsontwikkeling Het analyseren van: de huidige markt, de politieke omgeving, nationale en internationale wetgeving en andere omgevingsfactoren. Vaststellen doelgroepen gebied en wijkbehoeften Het vaststellen van een doelgroep voor een gebied rekening houdend met de analyse van de leefomgeving en de gebiedsontwikkeling. Tevens wordt de wijkbehoeften gedefinieerd. Bepalen gebiedsvisie en beleidsuitgangspunten Het bepalen van de gebiedsvisie rekening houdend met de analyse van de leefomgeving en de gebiedsontwikkeling. Tevens worden op basis hiervan de strategische beleidsuitgangspunten vastgesteld m.b.t. de vraag vanuit de gebieden die bediend worden. CORA

21 Ontwikkelen vastgoedstrategie Figuur 3.7 proces ontwikkelen vastgoedstrategie Ontwikkelen vastgoedstrategie Opstellen vastgoedportefeuillestrategie Het bepalen van strategische kaders voor de gehele vastgoedportefeuille (aanbod) rekening houdend met de bepaalde gebiedsvisie en beleidsuitgangspunten (vraag). Opstellen portefeuille- en beleidsplannen Het opstellen van een nieuwe/herijkte portefeuillebeleidsplannen op het gebied van duurzaamheid, verkopen, investeren, onderhouden, slopen en verhuren rekening houdend met de bredere context en omgeving. Opstellen complexvisie en uitgangspunten Het bepalen van de complexvisie (alle complexen / clusters) rekening houdend met gemaakte analyses (intern en extern) en de opgestelde portefeuillestrategie en -plannen. Tevens worden op basis hiervan de strategische beleidsuitgangspunten vastgesteld voor alle complexen / clusters die het vastgoedaanbod vormen. Evalueren portefeuillebeleidsplan Het bepalen of de vastgoedportefeuillestrategie en het vastgoedbeleid aangepast moet worden op basis van de evaluatie van de bereikte resultaten ten opzichte van de opgestelde complexvisie en uitgangspunten. CORA

22 Ontwikkelen dienstenstrategie Figuur 3.8 proces ontwikkelen dienstenstrategie Ontwikkelen diensten(portefeuille)strategie Opstellen dienstenportefeuille strategie Het bepalen van strategische kaders voor de gehele dienstenportefeuille (aanbod) rekening houdend met de bepaalde gebiedsvisie en beleidsuitgangspunten (vraag). Vaststellen dienstenbeleid Het opstellen van een nieuwe/herijkte dienstenbeleid rekening houdend met de bredere context en omgeving. Vaststellen dienstontwikkelings-/verbeterplan Het bepalen van de toekomstige strategie van de dienst rekening houdend met de analyse markt en beleidsomgeving. Het plannen van ontwikkeling en vertering van het dienstenaanbod (alle diensten) rekening houdend met gemaakte analyses (intern en extern) en de opgestelde portefeuillestrategie en -plannen. Evalueren dienstenportefeuille strategie Het bepalen of de dienstenportefeuille strategie aangepast moet worden op basis van de evaluatie van de bereikte resultaten ten opzichte van het vastgestelde plannen voor ontwikkeling en verbetering van het dienstenaanbod. CORA

23 Tactische processen Figuur 3.9 tactische processen vastgoed Beheren vastgoedplannen Figuur 3.10 processchema beheren vastgoedplannen Opstellen vastgoedplannen Op basis van de strategie visie, uitgangspunten en plannen worden plannen uitgewerkt voor het vastgoedbeheer. Dit t.a.v. aankoop, verkoop, sloop, onderhoud en verhuur van vastgoed. Vaststellen vastgoedplannen De opgestelde vastgoedbeheerplannen worden vastgesteld. Deze plannen zijn kaderstellen voor het te voeren beleid m.b.t. (individuele) complexen / clusters. Evalueren vastgoedplannen Evaluatie van de realisatie van de vastgoedbeheerplannen. CORA

24 Beheren complexbeleid Figuur 3.11 processchema beheren complexbeleid Uitvoeren Omgevingsanalyse op complexniveau Op basis van de vastgoedplannen en informatie over de wijk wordt een omgevingsanalyse uitgevoerd voor het toekomstige complexbeheer. Opstellen complex beheerplannen Het opstellen van de complex beheerplannen op basis van de uitgevoerde omgevingsanalyse. Vaststellen complex beheerplannen Het vaststellen van de complex beheerplannen. Deze plannen zijn kaderstellen voor het exploiteren van en investeren in complexen / clusters. Tevens wordt hiermee de onderhouds- en investeringsplanning gevoed. Evalueren complex beheerplannen Het evalueren realisatie van de complex beheerplannen. CORA

25 Beheren Onderhouds en investeringsplanning Figuur 3.12 processchema beheren onderhouds en investeringsplanning Beheren meerjaren onderhouds- en investeringsplanning Op basis van de complex beheerplannen wordt de definitieve keus bepaald voor het toekomstige complexbeheer over meerdere jaren.(m.o.p./m.i.p.). Hierbij wordt ook de externe informatie over de wijksituatie betrokken. De vastgestelde meerjaren onderhoudsen investeringsplanning is kaderstellend voor (onderhouds)jaarplannen. Periodiek vindt evaluatie plaats van de meerjarenplanning. Beheren onderhoud jaarplan Op basis van de complex beheerplannen en de meerjarenplanning (M.O.P./M.I.P.) worden definitieve keuzes gemaakt voor het onderhoud aan complexen / clusters voor de komende jaren. Deze planning is kaderstellend voor de projectvoorbereiding. Periodiek vindt evaluatie plaats van de jaarplanning. Uitvoeren projectvoorbereiding Uit te voeren projecten uit het jaarplan worden voorbereid (nieuwbouw, renovatie, herontwikkeling en overige projecten). Hiermee samenhangende investeringsbeslissingen worden genomen. Dit is kaderstellend voor het uitvoeren en realiseren van de projecten op operationeel niveau (exploiteren en investeren). Evalueren onderhoud en investering Evaluatie van de realisatie van de jaarplannen. 4 Voorbeelden applicatiearchitectuur In dit hoofdstuk zijn enkele voorbeeldscenario s op basis van het informatiefunctie model geschetst. Het informatiefunctie model zelf is beschreven in paragraaf 9.2 van CORA 3.0. De voorbeeldscenario s zijn sterk vereenvoudigd en als voorbeelden bedoeld om een indruk te krijgen van de manier waarop een referentiearchitectuur vertaald kan worden naar de wensen en eisen van specifieke organisaties. De voorbeelden hoeven elkaar niet uit te sluiten, het is niet óf óf. Applicatiearchitectuur volgens een ERP-scenario Een voorbeeld gebaseerd op één grote applicatie die alle functionaliteiten afdekt is weergegeven in figuur 4.1. Er zijn op dit moment geen leveranciers die zo n brede applicatie CORA

26 kunnen leveren, geschikt voor woningcorporaties. Over het algemeen biedt een ERParchitectuur de mogelijkheid om basale administraties te voeren waarmee een eenduidige gegevensadministratie ontstaat. Naast de ERP-applicaties zullen andere applicaties ook van deze gegevens gebruik gaan maken. Figuur 4.1: Applicatiearchitectuur volgens een ERP-scenario CORA

27 In CORA 3.0 (paragraaf 9.1) applicatie-strategieën zijn in figuur 9.3 de belangrijkste applicatie-strategieën opgenomen. Dit voorbeeld is in dit figuur als volgt te plaatsen: Specialistisch pakket Specialistisch pakket Functionele aansluiting Pakket Pakket Pakket Pakket Pakket Pakket Specialistisch pakket Onderscheidend pakket Onderscheidend pakket Specialistisch pakket Pakket minimalisatie Figuur 4.2 Informatiefunctiemodel volgens een ERP-scenario Het voorbeeld laat zien dat de ERP-applicatie hier ook in staat moet zijn (de koppelvlakken moet bieden) om de kanaalfuncties te kunnen ondersteunen. Mogelijk kan dat via webservices, en kunnen communicatiekanalen zoals de website en het callcenter ingericht worden met die webservices. Wanneer een klant bijvoorbeeld een melding wil doen via de website, wordt de desbetreffende webservice aangeroepen, die de melding in de ERPapplicatie opneemt en klaar zet voor verwerking door een backoffice medewerker. CORA

28 Applicatiearchitectuur volgens een best-of-breed scenario Alle informatiefuncties vervullen met één applicatie is een utopie en nergens de praktijk: woningcorporaties hebben over het algemeen met meer dan één applicatie te maken. Het combineren van applicaties op verschillende informatiefuncties als strategische keuze wordt best-of-breed genoemd. Daarbij wordt het geheel van benodigde functionaliteiten gerealiseerd door verschillende applicaties met elkaar te laten samenwerken. Figuur 4.3 geeft een hypothetische situatie weer waarbij er verschillende backoffice en frontoffice applicaties zijn die allemaal informatie uitwisselen. Figuur 4.3: Applicatiearchitectuur volgens een best-of-breed scenario CORA

29 Dit voorbeeld past als volgt in figuur 9.3 van CORA paragraaf 9.1 applicatie-strategieën: Specialistisch pakket Specialistisch pakket Functionele aansluiting Pakket Pakket Pakket Pakket Pakket Pakket Specialistisch pakket Onderscheidend pakket Onderscheidend pakket Specialistisch pakket Pakket minimalisatie Figuur 4.4 Informatiefunctiemodel volgens een best-of-breed scenario Een wezenlijk aspect dat in een best-of-breed benadering geadresseerd moet worden is het benoemen van bronapplicaties en afgeleide applicaties. De afzonderlijke applicaties hebben meestal interne referentiebestanden nodig om goed te kunnen werken. Daarvoor kan het nodig zijn bijvoorbeeld relatie-, vastgoed- en overeenkomstgegevens onderling uit te wisselen. Bronapplicaties worden benoemd voor het eenduidig beheer van de gegevens. Tegelijkertijd wordt daarmee bepaald wie eigenaar is van de gegevens. Het schakelstation in het midden zou idealiter voor de informatie-uitwisseling moeten zorgen. In de praktijk is een best-of-breed scenario eerder onbedoeld in de loop der jaren ontstaan zonder dat de nodige koppelingen gelegd zijn. Noodzakelijke informatieuitwisseling wordt in de praktijk vaak handmatig uitgevoerd door overtikken van het ene systeem in het andere. Het kan ook voorkomen dat gebruikers verschillende applicaties tegelijkertijd moeten gebruiken. Een front- mid- backoffice concept zou hierbij passen, echter dat neemt het probleem niet weg dat de diverse applicaties de juiste koppelvlakken moeten hebben. Juist wil in dit verband zeggen dat er inhoudelijke consistentie moet zijn bij de informatie-uitwisseling tussen applicaties onderling. Best-of-breed wordt veelal benaderd via een service gerichte aanpak, zie de voorbeelduitwerking hierna. CORA

30 Applicatiearchitectuur volgens service oriëntatie Service (of diensten-) oriëntatie (SOA, Service Oriented Architecture) is een ontwerpbenadering waarbij de componenten elkaar onderling diensten aanbieden. Er zijn gegevensdiensten die de gegevens ontsluiten en beheren, functionele diensten die de functionaliteit bieden en presentatie diensten die ervoor zorgen dat de functionaliteit in de juiste interface en context wordt aangeboden aan gebruikers. Een enterprise service bus zorgt voor de berichtenuitwisseling en orkestratie van de processen. Op dit moment zijn de diensten die corporaties nodig hebben, zoals in figuur 4.5 hieronder, beperkt op de markt. Figuur 4.5: Applicatiearchitectuur volgens service oriëntatie CORA

31 Dit voorbeeld past als volgt in figuur 9.3 van de CORA paragraaf 9.1 applicatie-strategieën: Figuur 4.6 Informatiefunctiemodel volgens service oriëntatie Applicatiearchitectuur gebaseerd op workflow zaakbehandeling Figuur 4.7: Applicatiearchitectuur gebaseerd op workflow zaakbehandeling CORA

32 Om dit voorbeeld in een groter geheel te plaatsen wordt verwezen naar CORA 3.0 (Focusgebied: Zaaktypen en Zaakgericht werken). Vooral in de overheidswereld komt de laatste tijd het zaakgericht werken in zwang. Dat concept sluit goed aan bij het dienstverleningsproces: alle aanvragen van klanten worden beheerd in een zaakdossier waarin op elk moment de status van de aanvraag wordt bijgehouden. De verwerking wordt uitgevoerd met de backoffice applicaties. Dit principe lijkt erg op workflow, maar meestal met minder stappen in het behandelproces. In de bijbehorende applicatiearchitectuur is aan te raden om het zaaksysteem optimaal te integreren met de overige systemen (zoals, bijvoorbeeld, een ERP-systeem), waar het zaakdossier een hechte relatie mee heeft. Een separaat zaaksysteem blijkt in vergelijkbare sectoren vaak een complicerende factor. Nut en noodzaak worden mede bepaald door de mate waarin het bestaande applicatielandschap is versnipperd. CORA

33 5 Identificering en typering relaties Inleiding Dit hoofdstuk bevat een uitwerking van het gegevensdomein Relaties voor het uniek identificeren en typeren van relaties. De beschreven gegevens sluiten aan op de gegevensdefinities van CORA 1.0. Identificering en typering Natuurlijk persoon Rechtspersoon Type adres Type overeenkomst Relaties Adres Contactgegeven Overeenkomst Financieel Contactpersoon Type contactpersoon Contactmoment Legenda: Object 1-op-veel relatie veel-op-veel relatie 1-op-1 relatie Specialisatie van object Figuur 5.1 Variant op gegevensmodel relaties Bovenstaand model is een variant op het objectenmodel Relaties zoals dit in CORA 3.0 (paragraaf 10.1 Gegevensmodel) is opgenomen. CORA

34 In dit hoofdstuk wordt de nadruk gelegd op de identificering van relaties en de typering zoals die bij tkype contactpersoon en type overeenkomst is opgenomen. Daarnaast wordt een aantal gegevens beschreven die nader worden vastgelegd binnen de relatie objecten. BSN-nummer Niet iedereen mag zomaar het BSN-nummer gebruiken. Welke instanties of organisaties het mogen gebruiken is wettelijk geregeld. Woningcorporaties mogen het BSN-nummer uitwisselen met de Belastingdienst/Toeslagen. Tweelingzussen J(oke) Jansen en J(antine) Jansen wonen samen op 1 adres. Indien er geen BSN-nummer opgenomen is, zijn alle relatiegegevens hetzelfde terwijl het verschillende personen betreft. Voorkomende situaties Vanuit verschillende situaties kunnen contacten ontstaan met personen en niet natuurlijke personen. Vanuit enkele voorbeelden is dit verder vormgegeven: Man A woont samen met vrouw B. Vrouw B is huurder (contractant). Ze gaan uit elkaar. Man A schrijft zich in als woningzoekende met een nieuwe partner C. De man A belt met klacht over lekkage bij de buren. (Man A is Klant) Man A was contactpersoon voor leverancier X. Man A werkt nu voor leverancier Y en wil een afspraak met de inkoper van de corporatie (Man A is leverancier) Hoedanigheid en type overeenkomst Een relatie kan in de loop der tijd in verschillende hoedanigheden met een corporatie te maken hebben. Het type overeenkomst bepaalt dit. Extra relatiegegevens hangen samen met de overeenkomst en worden dan ook bij de overeenkomst opgenomen: Een interne medewerker heeft een loonovereenkomst. Een klant heeft een huurovereenkomst. Een VVE heeft een VVE beheerovereenkomst. Een leverancier heeft een leverantieovereenkomst. Een uitvoerder (intern of extern) heeft een uitvoerderovereenkomst waarop o.a. zijn vakgroep staat. Een makelaar heeft een makelaarsovereenkomst waarop o.a. zijn courtage staat vermeld. Een notaris heeft een notarisovereenkomst. Een huismeester heeft een huismeesterovereenkomst. Een woonconsulent heeft een woonconsulentovereenkomst. Een budgethouder heeft een mandaatovereenkomst waarop o.a. zijn mandaatgrens vastgelegd is. Een aantal overeenkomsten zal alleen voor interne medewerkers gebruikt worden. CORA

35 Overeenkomst en contactpersonen Een overeenkomst wordt afgesloten met 1 of meer relaties. Bij deze relaties moeten contactgegevens aanwezig zijn, anders is het opnemen van deze relaties bij de overeenkomst nutteloos. Bij een overeenkomst met een niet natuurlijk persoon (bijvoorbeeld een VVE), kunnen de contactpersonen in de loop der tijd wijzigen, maar de overeenkomst blijft bestaan met dezelfde relatie. Ook als er geen contactpersoon bekend is, moet contact met deze relatie opgenomen kunnen worden. De overeenkomst bepaalt dus ook de contactpersonen. Een relatie kan bij de ene overeenkomst zelf contactpersoon zijn, bij een ander contract een andere relatie. Bij relaties zijn er 0 of meer contactpersonen mogelijk. Prospects worden bepaald door het type contactpersoon Een woningzoekende (via inschrijving of woonbon) neemt al een dienst van de corporatie af en is dus een klant en geen prospect (bij sommige corporaties moet daar ook voor betaald worden). De extra woningzoekende gegevens passen daarmee ook beter in het schema zoals opgenomen in figuur 5.1 Variant op gegevensmodel relaties. Bij relatie kunnen extra contactgegevens opgenomen zijn (via het contract), bij een prospect niet. Contactsoorten Een relatie kan verschillende typen contactpersoon hebben voor verschillende contactsoorten: Advocaat; Gemeentelijke Sociale Dienst; Afwijkende betaler; Erfgenaam; Inkoper; Directeur. Afhankelijk van het contact en vaak ook contract, wordt de contactpersoon bepaald, of afgeleid waarvoor een contactpersoon contact opneemt. Relaties, overeenkomst en contactgegevens De woningcorporatie en zijn interne medewerkers zijn bijzondere relaties. Van interne medewerkers zijn veel meer gegevens vastgelegd dan van andere relaties: Er is een organisatiestructuur (directeur, managers, etc.); Via de loonovereenkomst moeten andere loonovereenkomsten (manager/leidinggevende) gekoppeld kunnen worden. Een VVE is een Relatie met een VVE-beheerovereenkomst. Bij een VVE zijn de eigenaren relevant. Sommige eigenaren vormen een bestuur met een voorzitter en penningmeester. Doorgaans is er ook een (externe) administrateur betrokken. In veel voorkomende gevallen is de corporatie ook lid van de VVE. Via contactgegevens zijn deze relaties vast te leggen. Soms moet immers met de individuele leden gecommuniceerd worden, soms met voorzitter, etc. Dit geldt ook voor andere niet natuurlijke relaties zoals huurcommissie, bedrijven, huishoudens, etc. CORA

36 6 Woonruimteverdeling (Vastgoed-Relaties) In dit hoofdstuk wordt ingegaan op woonruimteverdeling. De beschreven gegevens sluiten aan op de gegevensdefinities van CORA 1.0. Een woningcorporatie legt in essentie de gegevens voor woonruimteverdeling vast zoals weergegeven in figuur 6.1. Woonruimteverdeling is een stelsel van wetgeving en afspraken om huurwoningen te verdelen. Administratief Fysieke wereld Verhuurreactie Rechtspersoon Natuurlijk persoon Verhuurreactielijst Prospect Verhuurtoewijzing Verhuuraanvrager Verhuureditie Voorrangsaanduiding Gebouw Verhuuradvertentie Pand Verhuurmodel Huurovereenkomst Bouwdeel Bouwkundig Element Complex / Cluster Gebruikersfunctie Te onderhouden eenheid (TOE) Eenheid Benoemd terrein Overig gebouwd object Verblijfsobject Verhuurbare eenheid (VHE) Bedden in een verzorgingstehuis Opvangplaatsen tbv maatschappelijke opvang Tuin Standplaats Grond Ligplaats Parkeerplaats Bevestigingsplaats Vrijstaande berging Garagebox Parkeergarage Woning Bedrijfsruimte Garagebox Parkeergarage Verkoopbare eenheid (VKBE) Verkochte eenheid (VKE) Parkeerplaats Onzelfstandige eenheid Figuur 6.1: Gegevensmodel voor Woonruimteverdeling CORA

37 In dit aanbodmodel 1 zijn de onderstaande verbanden tussen de verschillende objecten 2 gemodelleerd: Een prospect (=VHE-zoekende) bestaat uit één of meer verhuuraanvragers. Een prospect kan reageren op een verhuuradvertentie. Een VHE wordt verhuurd aan een klant, dit wordt vastgelegd in een huurovereenkomst. Een prospect krijgt een VHE 3 aangeboden / toegewezen. Een verhuuraanvrager kan nul, één of meer voorrangsaanduidingen hebben. Een verhuuraanvrager bestaat uit een natuurlijk persoon of rechtspersoon. Een verhuuradvertentie betreft één VHE of complex / cluster. Een verhuuradvertentie heeft één of meer verhuurreacties. Een verhuureditie bestaat uit één of meer verhuuradvertenties. Een verhuurreactie maakt onderdeel uit van een verhuurreactielijst. Een verhuurreactielijst bestaat uit één of meer reacties. Een verhuurtoewijzing betreft één of meer VHE s. Een verhuurtoewijzing heeft één of meer VHE-zoekenden (prospects). Een verhuurtoewijzing heeft één verhuurmodel. Toelichting op het gegevensmodel Een uitgangspunt binnen het gegevensdomein woonruimteverdeling is dat dit alleen over het verhuren van VHE s gaat. Objecten die alleen een rol spelen in de context van woonruimteverdeling hebben een prefix Verhuur gekregen. Een voorrangsaanduiding is verhuuraanvrager gebonden. Elk complex / cluster of VHE van een verhuureditie heeft een eigen verhuurreactielijst. Een verhuurreactie wordt vastgelegd bij een verhuuradvertentie. Een verhuurreactielijst bestaat uit één of meer reacties. Gegevensdefinities woonruimteverdeling Deze paragraaf bevat de definities van de objecten in het gegevensdomein Woonruimteverdeling en dan specifiek die objecten die alleen een rol spelen in de context van woonruimteverdeling. De keuze of een object is opgenomen in deze uitwerking is gemaakt op basis van de 80/20 regel. Als in 80% van de geanalyseerde gevallen het object een rol speelt in het Woonruimteverdelingsproces is het object opgenomen in de uitwerking. 1 In het objectmodel voor woonruimteverdeling wordt uitgegaan van het aanbodmodel voor de verhuur van woningen. Andere vormen van modellen zijn: optiemodel en distributiemodel. Dan wordt namelijk niet d.m.v. een advertentie het aanbod kenbaar gemaakt. 2 Objecten die alleen een rol spelen in de context van woonruimteverdeling hebben een prefix Verhuur gekregen. 3 VHE waarvan bekend is, dat deze voor verhuur beschikbaar komt. CORA

38 Dit zijn de objecten 4 : Type voorrangsaanduiding Verhuuraanvrager Verhuuradvertentie Verhuureditie Verhuurmodel Verhuurreactie Verhuurreactielijst Verhuurtoewijzing Voorrangsaanduiding Naam Type voorrangsaanduiding Soort Subtype Definitie Eenduidig vastgelegde type voorrangsaanduiding Relaties Een voorrangsaanduiding heeft altijd een type voorrangsaanduiding. Contexten Het type voorrangsaanduiding concretiseert waarom een verhuuraanvrager voorrang kan krijgen in het woonruimteverdelingsproces. Bijvoorbeeld: urgentie, herstructurering en zorgindicatie. Type voorrangsaanduiding is een enumeratie. Een enumeratie is een reeks velden met een vaste, duidelijke, onveranderbare betekenis. Hierdoor is altijd bekend wat er met een bepaald gegeven uit een enumeratie bedoeld wordt. Variabelen van een enumeratietype kunnen een vaststaand aantal waarden aannemen, die met een identifier kunnen worden aangeduid. Over het algemeen worden de waarden van een enumeratietype intern weergegeven door een (kleine) integer. Synoniemen Reden wijziging Naam Verhuuraanvrager Soort Subtype Definitie Een verhuuraanvrager is een natuurlijk- of rechtspersoon die aangegeven heeft dat hij een verhuurbare eenheid wil huren. Relaties Maakt onderdeel uit van de aggregatie VHE-zoekende. Een verhuuraanvrager kan nul, één of meer voorrangsaanduidingen hebben. Een verhuuraanvrager bestaat uit een natuurlijk persoon of rechtspersoon. Contexten Verhuuraanvrager is gekozen, omdat het hier gaat over het domein Verhuur. Dit moet worden gelezen als de aanvrager of de aanvragers die wil/willen huren. Synoniemen Reden wijziging 4 De rol prospect (onderdeel objectenmodel Relaties) wordt beschouwd als VHE-zoekende en is dus niet apart gemodelleerd binnen dit objectenmodel. CORA

39 Naam Verhuuradvertentie Soort Basisobject Definitie Een verhuuradvertentie is het bekend maken van een te (weder)verhuren VHE of complex / cluster Relaties Een verhuuradvertentie betreft één VHE of complex / cluster. Een verhuuradvertentie heeft nul, één of meer verhuurreacties. Contexten Een verhuuradvertentie kan ook via het Te Woon principe worden geadverteerd. De VHE-zoekende (prospect) heeft dan de keuze tussen huren of kopen. Indien een prospect besluit om te kopen, dan kan een verhuuradvertentie leiden tot een koopovereenkomst. Een verhuuradvertentie kan gekoppeld zijn aan een verhuurmodel. Synoniemen Reden wijziging Naam Verhuureditie Soort Aggregatie Definitie Een verhuureditie is een groep van één of meer verhuuradvertenties, die op een tijdstip worden gepubliceerd. Relaties Een verhuureditie bestaat uit één of meer verhuuradvertenties. Elke verhuuradvertentie van een verhuureditie heeft een eigen verhuurreactielijst. Contexten Een verhuureditie is bijvoorbeeld een advertentie of een groep van advertenties met een gelijke start- en einddatum. Een verhuureditie kan ook een set van advertenties met een gemeenschappelijke eigenschap zijn bijvoorbeeld alle Vhe s die direct te huren zijn. Niet alle VHE s worden in een verhuureditie gepubliceerd. Dit zijn bijvoorbeeld de VHE s die direct worden toegewezen. Synoniemen Reden wijziging CORA

40 Naam Verhuurmodel Soort Subtype Definitie Een verhuurmodel bepaalt volgens welk proces een VHE wordt verhuurd. Relaties Contexten Voorbeelden van verhuurmodellen zijn Aanbodmodel, Direct te huur, Inschrijfmodel, Optiemodel, Lotingmodel, Bemiddeling Verhuurmodel is een enumeratie. Een enumeratie is een reeks velden met een vaste, duidelijke, onveranderbare betekenis. Hierdoor is altijd bekend wat er met een bepaald gegeven uit een enumeratie bedoeld wordt. Variabelen van een enumeratietype kunnen een vaststaand aantal waarden aannemen, die met een identifier kunnen worden aangeduid. Over het algemeen worden de waarden van een enumeratietype intern weergegeven door een (kleine) integer. Synoniemen Reden wijziging Naam Verhuurreactie Soort Basisobject Definitie In een verhuurreactie geeft een VHE-zoekende (prospect) aan dat hij in aanmerking wenst te komen voor een beschikbare VHE. Relaties Een verhuurreactie is gekoppeld aan één VHE-zoekende. Een verhuurrreactie wordt vastgelegd bij een verhuuradvertentie. Een verhuurreactie maakt onderdeel uit van een verhuurreactielijst. Contexten Een VHE-zoekende geeft aan dat hij in aanmerking wil komen voor een vrij gekomen VHE. Een VHE-zoekende kan meer dan één verhuurreacties plaatsen. Een VHE-zoekende geeft aan dat hij in aanmerking wil komen voor een nog vrij te komen VHE in een bepaald complex / cluster. Synoniemen Optie Reden wijziging Naam Verhuurreactielijst Soort Aggregatie Definitie Een verhuurreactielijst is een verzameling van één of meer verhuurreacties waarvan de volgorde volgens bepaalde spelregels kan worden bepaald. Relaties Een verhuurreactielijst bestaat uit nul, één of meer reacties. Contexten Synoniemen Reden wijziging CORA