Document:Klachtenregistratie Overzicht

From WOSI
Jump to navigation Jump to search
Klachtenregistratie Beschrijving[1]
Datum 6-11-2007
Fase Fase 4
Versie 1.0
Status Concept
Auteurs Arno Fiege
Goedgekeurd door
Aangepast door

Inleiding

Dit document bevat een korte omschrijving van de documentatie die aan het begin van fase 4 voor de deelnemers beschikbaar waren met betrekking tot de klachtenregistratie.

Situatie beschrijving

Binnen het project is er in de eerste en tweede fase aan de klachtenregistratie gewerkt. Voor zover wij nu hebben kunnen achterhalen is er geen documentatie uit de eerste fase meer beschikbaar. Uit de tweede fase is echter een heleboel documentatie beschikbaar. Deze informatie is echter niet gestructureerd en centraal beheerd.

Uit de derde fase is er ook nog een beperkte hoeveelheid informatie beschikbaar maar omdat in die fase besloten is niet verder te gaan met klachtenregistratie is die informatie beperkt.

Opbouw rapport

In dit document beschrijven we de nuttige informatie uit de vorige fases. Het is een bundeling van informatie die dus elders al beschikbaar was. Naast de informatie uit de oude documentatie bevat dit document ook extra informatie die in deze fase verzameld is op basis van onderzoek en beschikbare documentatie die niet of minimaal verwerkt is in de oude documentatie.

De opbouw binnen dit document is zo dat de informatie uit de oude documentatie van vorige team en informatie uit andere voor ons beschikbare documentatie duidelijk van elkaar gescheiden zijn.

In het derde hoofdstuk bespreken we de documentatie die de vorige teams hebben geschreven. Het daarop volgende vierde hoofdstuk bevat informatie over de andere documentatie die nog aanwezig was. En als laatste sluiten we af met de conclusies over de inhoud van de documentatie. Het document bevat ook nog enkele bijlagen om zo veel mogelijk de informatie de bundelen.

Oude Team Documentatie

De team documenten op een rijtje

Om te beginnen geven we eerste even een overzicht van de documentatie die in de vorige fases gemaakt is. (alle documenten beginnen met “wosi-deelproject-klachteregistratie” voor de leesbaarheid hebben we dat gedeelte weggelaten)

  • Fase 1
    • fase1-pid_v1_0Fase 1 - PID
  • Fase 2
    • fase2-pid_v1_0Fase 2 - PID
    • globaal-faseplan_onderzoeksfase_v1_0Faseplan - Onderzoeksfase
    • fase2-voortgang_20061020_v1_0Voortgang 20-10-2006
    • fase2-voortgang_20061030_v1_0Voortgang 30-10-2006
    • fase2-voortgang_20061113_v1_0Voortgang 13-11-2006
    • fase2-voortgang_20061127_v1_0Voortgang 27-11-2006
    • fase2-voortgang_20061211_v1_0Voortgang 11-12-2006
    • fase2-voortgang_20070108_v1_0Voortgang 08-01-2007
    • globaal-analyse_v1_0Analyse
    • globaal-functioneel_ontwerp_v1_0Functioneel Ontwerp
    • globaal-technisch_ontwerp_v1_0Technisch Ontwerp
    • globaal-beschrijving_prototype_v1_0Prototype Beschrijving
    • globaal-faseplan_ontwikkelfase_v1_0Faseplan - Ontwikkelfase

De inhoud

De inhoud en kwaliteit van deze documenten is zeer divers. Sommige documenten bevatten een goede basis op mee verder te kunnen en andere zijn totaal waardeloos.

In de bijlage a hebben we een korte weergave van de bevindingen van onderzoek gebundeld.

Wat weten we nu?

De buikbare inhoud van de documenten geeft ons al een uitgangspositie van waaruit we de klachtenregistratie kunnen opzetten. We weten al het volgende:

  • “De niet planmatige onderhoudsketen volgens KUBIS, een verkenning” beschreven als zijnde een functioneel ontwerp. De bruikbaarheid van dit document staat ter discussie op basis van bevindingen van de vorige fases.
  • De projectachtergrond volgens fase2:

Onder de woningcorporaties vallen een aantal onderhoudsbedrijven, die woningen (van deze corporaties) onderhouden. Deze onderhoudsbedrijven voeren zowel planmatig als niet-planmatig onderhoud uit. Het planmatig onderhoud wordt in een strategie bepaald en vervolgens uitgevoerd. Het niet-planmatig onderhoud (het onvoorspelbare onderhoud) wordt nu nog veelal per telefoon door de huurder gemeld en door medewerkers geregistreerd en verwerkt, dit kost tijd en geld. De corporaties zoeken daardoor naar een systeem die de klachten via het Internet aanneemt en verwerkt, zodat pas waar en wanneer nodig mensen worden ingeschakeld en zodoende kosten bespaard worden. Bovendien leidt registratie via het Internet ook tot correcte registratie van NAW gegevens van de klant en het optimaal kunnen volgen van de afhandeling van de klacht.

  • Volgens onderzoek van de vorige fase komen uit het KUBIS document de volgende stappen naar voren voor het klachtenregistratie proces.
    • onderkennen onderhoudsbehoefte;
    • ontvangen onderhoudsverzoek;
    • beoordelen onderhoudsverzoek;
    • inplannen en maken afspraak;
    • opstellen werkopdrachten;
    • voorbereiden werkzaamheden;
    • verstrekken werkopdracht;
    • uitvoering & coaching werkzaamheden;
    • technisch gereed melden;
    • toezicht & controle;
    • registratie gemaakte kosten;
    • facturering aan…;
    • sturing & managementinformatie.
  • In eerste instantie was het idee om een webapplicatie te ontwikkelen waarin huurders klachten konden aanmelden.
  • De websites van de woningcorporaties zouden meer inzicht kunnen geven op hun klachtenproces en mogelijkheden. Deze inzichten zouden in de applicatie verwerkt moeten worden.
  • De huidige processen van de woningcorporaties verlopen voornamelijk via telefoon en de balie. Internet wordt nauwelijks gebruikt. Er is een verdeling gemaakt op basis van bevindingen (tijdens contacten met de woningcorporaties ) die ongeveer als volgt is:
    • Invoer ( telefoon, web, balie ).
    • Workflow (Hoe past het in het bedrijf, hoe wordt klacht aangepakt, aannemer? ).
    • Afhandeling (Fysiek, acceptatie van de klant, archivering)
  • De verschillende woningcorporaties doen het allemaal anders. Zo heeft de een een aparte afdeling “Service & Onderhoud” en maakt de ander gebruik van de diensten van HomeTeam B.V.
  • Het klachtenregistratie model van Rotterdam is gedocumenteerd en opgenomen in dit document als bijlage B.
  • Het bestaande prototype is specifiek voor Rotterdam ontwikkeld.
  • Voor het prototype zijn een OO-model en de Datamodel beschikbaar. Voor het datamodel is nog een beperkte uitleg beschikbaar. (In dit document opgenomen als bijlage C)
  • De functionaliteit van het prototype is beperkt maar wel duidelijk beschreven in de Prototype Beschrijving.

Andere Documentatie

Naast de oude team documentatie hebben we ook nog een aantal andere documenten gevonden die voor het klachtenregistratiesysteem van belang kunnen zijn.

De overige documenten op een rijtje

De relevantie van de documenten is nog niet helemaal helder. Daarom nemen we ze toch op in dit document om in ieder geval een beeld te hebben van de inhoud. Zo kunnen we in een later stadium eenvoudiger bepalen of ze relevanter of minder relevant zijn geworden. De documenten zijn:

  • “ICT optimaal georganiseerd bij woningcorporaties” (Onderzoeksrapport)
  • “Casus onderhoud, intake en magazijn”
  • “De niet planmatige onderhoudsketen volgens KUBIS, een verkenning”
  • “Datamodel van het asp prototype”

Alle documenten zijn gevonden in de kast van het WOSI lokaal. De eerste twee bevonden zich in de hangmap genaamd klachtenregistratie en het laatste document lag op een stapeltje in de kast. (Van de laatste twee documenten zijn verschillende versies aanwezig)

De inhoud

“ICT optimaal georganiseerd bij woningcorporaties”

Dit is een rapport over een onderzoek onder woningcorporaties over de ICT organisaties. Het merendeel van de inhoud van dit document geeft achtergrond informatie voor het algemene WOSI project. Zo bevat het onder andere informatie over de ICT organisatie en de inrichting.

De onderdelen uit het rapport die voor klachtenregistratie gedeeltelijke of grotere relevantie hebben zijn:

  • Hoofdstuk 5 sectie 5.6 Relevante ontwikkelingen.
  • Bevat informatie over software in gebruik, Operating Systems, Databases, positie van internet, intranet en extranet.

“Casus onderhoud, intake en magazijn”

Document afkomstig van de woningcorporatie in Rotterdam. Bevat een aantal casussen en concrete vragen naar aanleiding van de casussen over het systeem. Het lijkt erop dat dit document is gebruikt om input te krijgen van verschillende leveranciers om zo de beste te kunnen selecteren.

Er staan een aantal duidelijke eisen in de vragen waaraan een geschikte applicatie voor deze casussen zou moeten voldoen. De eisen zijn erg concreet en veeleisend voor het klachtenregistratie systeem.

“De niet planmatige onderhoudsketen volgens KUBIS, een verkenning”

Dit document heb ik momenteel niet in mijn bezit waardoor ik er niet zo veel concreets over kan zeggen. Wat ik wel weet is dat er informatie uit te halen is over het proces. Er staan een hoop diagrammen en beschrijvingen in. Concreet moet er echter nog wel beoordeeld worden in hoeverre dit waardevol is (dit omdat in de team documentatie niet al te positief over het document wordt geoordeeld).

“Datamodel van het ASP prototype”

Het datamodel dat gebruikt is voor het prototype uit een van de vorige fases bevat een aantal interessante elementen. Er staat een aardige hoeveelheid informatie in waar functionaliteit uit afgeleid kan worden.

Zo zijn tot op een redelijk uitgebreid detail niveau de verschillende informatie die nodig is voor klachtenregistratie uitgewerkt.

Conclusies

Op basis van de gelezen en beoordeelde documentatie kunnen we de volgende voorlopige conclusies trekken.

De informatie die relevant is, is grotendeels in dit document opgenomen. Voor de andere documentatie is dat niet het geval dit is omdat die informatie of te uitgebreid of te beperkt is om op te nemen in dit document.

Voor het datamodel dat voor het prototype is gebruikt is het wel belangrijk om het database team daar beschikking over te geven om te beoordelen in hoeverre deze informatie nog bruikbaar is en in hoeverre het opgenomen kan worden in het nieuwe datamodel.

We moeten zelf uitzoeken welke informatie we nou specifiek nodig hebben voor de klachtenregistratie en tot op welk detail niveau we zullen gaan met de implementatie in deze fase.

Daarbij is het wel handig om de informatie die we hebben gevonden op te nemen in het nieuwe ontwerp en hoog in te zetten zodat we bij het ontwikkelen een helder beeld hebben van de functionaliteit die de applicatie uiteindelijk moet gaan bezitten. Dit ook ten opzichte van overdracht naar andere teams (fases).

Vervolg Stappen

Voor het verdere proces zullen we ons nu richten op de websites van de woningcorporaties. Aan de hand van de informatie die we daar nog op vinden en de visie die we zelf los van het geheel ontwikkelen zal het ontwerpdocument vormgegeven worden.

Bijlagen

Referenties

  1. Bron Document terug te vinden op de oude wiki en in de webdav directory