Document:Klachtenregistratie Overzicht

From WOSI
Revision as of 20:50, 17 April 2008 by Schim (talk | contribs)
Jump to navigation Jump to search
Klachtenregistratie - Legacy
Datum 6-11-2007
Fase [[Fase {{{fase}}}]]
Versie 1.0
Status Concept
Auteurs Arno Fiege
Goedgekeurd door
Aangepast door

Klachtenregistratie - Legacy

Beschrijving van bestaande documentatie

Project module

Inleiding

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.

Bijlage A - Documentanalyse

Fase 1 Documenten

wosi-deelproject-klachtenregistratie-fase1-pid_v1_0 (dd: 12-05-2006)

Dit document bevat een opsomming van producten die het eerste project team zou gaan opleveren. De resultaten die zouden worden opgeleverd zijn nergens terug te vinden. Daardoor is dit document waardeloos voor ons. Als er wel resultaten waren geweest hadden ze hoogstwaarschijnlijk wel gebruikt kunnen worden.

Fase 2 Documenten

wosi-deelproject-klachtenregistratie-fase2-pid_v1_0

Dit document bevat een verwijzing naar een document waarvan gezegd wordt dat het een functioneel ontwerp is (“de niet planmatige onderhoudsketen volgens KUBIS, een verkenning”). Op basis van dat document en wat andere informatie zijn uit dit document de beweegredenen en het verloop van het proces te halen.

wosi-deelproject-klachtenregistratie-globaal-faseplan_onderzoeksfase_v1_0

Dit document bevat de uitwerking van de onderzoeksfase van het projectteam. Deze informatie is voor ons doel niet van belang. Wel staan er een aantal dingen in die we wel belangrijk vinden. Dat zijn de ideeën ten opzichte van gebruiksvriendelijkheid en de ideeën over de functionaliteit van het prototype.

wosi-deelproject-klachtenregistratie-fase2-voortgang_********_v1_0

De voortgangsdocumenten gedateerd op 20061020, 20061030, 20061113, 20070108 bevatten geen bruikbare informatie. Ze geven alleen een beeld over de voortgang van het vorige team.

wosi-deelproject-klachtenregistratie-fase2-voortgang_20061127_v1_0

Dit voortgangsdocument bevat naast de voortgangsinformatie wel extra informatie te bruikbaar zou kunnen zijn. Er wordt in dit document melding gemaakt van het feit dat het “functioneel ontwerp” (KUBIS) geen goede basis is voor het ontwikkelen van een klachtenregistratie.

wosi-deelproject-klachtenregistratie-fase2-voortgang_20061211_v1_0

Ook in dit document staat enige extra informatie die voor ons van belang kan zijn. Het gaat hierbij om het feit dat het prototype geen bestaande ideeën van de woningcorporaties in zicht heeft. Het gaat hierbij dan om de informatie die de woningcorporaties al in hun huidige systemen op de website beschikbaar hadden.

wosi-deelproject-klachtenregistratie-globaal-analyse_v1_0

Dit document is een document dat de nodige informatie bevat voor het klachtensysteem. In dit document wordt duidelijk hoe de huidige processen bij de woningcorporaties ongeveer verlopen en worden enkele aanbieders van bestaande systemen genoemd. Verder bevat het nog een klein beetje informatie over mogelijke functionaliteit.

wosi-deelproject-klachtenregistratie-globaal-functioneel_ontwerp_v1_0

Dit document bevat de klachtenregistratie zoals die in Rotterdam is bedacht. Er worden in het document met een aantal geavanceerde termen gegooid waarvan de waarde niet geheel duidelijk is. Wel geeft dit document het beeld dat het systeem zo specifiek mogelijk moet zijn. Er moet een hoog detail niveau bereikt kunnen worden, Urgentie is belangrijk en Slimme suggesties door het systeem zijn interessant.

wosi-deelproject-klachtenregistratie-globaal-technisch_ontwerp_v1_0

Dit document bevat een concreet ontwerp voor een klachtenregistratie systeem. Het bevat een datamodel, een oo model en instructies over de oude ontwikkelstraat.

wosi-deelproject-klachtenregistratie-globaal-beschrijving_prototype_v1_0

Dit document bevat net zoals het zegt een beschrijving van het prototype in asp.net. Wellicht kan dit ter referentie dienen voor functionaliteit.

wosi-deelproject-klachtenregistratie-globaal-faseplan_ontwikkelfase_v1_0

Dit document is zo goed als identiek aan het faseplan onderzoeksfase. En bevat dus geen extra informatie.

Bijlage B – Klachtenregistratie Proces Rotterdam

Scenario

  1. Een eigenaar van een huurobject heeft een klacht of een probleem. De eigenaar gaat naar de website van zijn woningcorporatie. Hij meldt zich aan op de website. De authenticatie procedure is nog nader te bepalen. De eigenaar heeft zich aangemeld en het systeem weet welke huurobjecten de eigenaar heeft en wie de eigenaar is.
  2. De eigenaar geeft aan of hij een klacht heeft over zijn omgeving of een probleem met een huurobject.
  3. De eigenaar selecteert het huurobject waar hij een probleem of een klacht mee heeft. Als de eigenaar maar een huurobject heeft is de stap overbodig.
  4. De eigenaar geeft aan in welke ruimte van het huurobject hij de klacht ondervindt. Het systeem weet wat voor ruimtes een huurobject heeft en wat er mis mee kan zijn. De eigenaar vult in van welk object in een ruimte hij een probleem heeft. Een ruimte heeft een aantal objecten waar de eigenaar (al dan niet tegen betaling) service voor kan eisen. Het systeem weet welke objecten in een ruimte zitten.
  5. De eigenaar vult in wat in er mis met object wat hij geselecteerd heeft in de vorige stap. Het systeem weet wat er mis kan zijn met een bepaald object (eigenaar kan ook zijn eigen omschrijving invullen) Ook weet het systeem waar de klacht eventueel vandaan zou kunnen komen. (bijvoorbeeld het lekt in de huiskamer, zou kunnen zijn de er een lekkage in de badkamer is.) Het systeem geeft dus suggesties, die op basis van de interpretatie van de eigenaar kan worden ingevuld. De klant is geen expert, dus wat hij daar invult is zijn idee waar het zou vandaan kunnen komen.
  6. De eigenaar vult in wanneer hem het beste uitkomt dat er een monteur langs komt. De datum en de tijden. Hiermee is de klacht / probleem helemaal goed in het systeem ingevuld.
  7. De eigenaar krijgt een bevestiging via mail of telefoon. Urgente klachten en problemen worden telefonisch bevestigd.

A. Bij Sociale problemen (problemen die niet te maken hebben met de huurobjecten van de eigenaar) moet worden bepaald waar het vandaan komt. Eigenaar vult in of het probleem van mensen uit zijn omgeving vandaan komt (bijv. geluidsoverlast) of van een object uit zijn omgeving (open riool, vuilnis op straat). De woningcorporatie kan dan de nodige acties ondernemen. De woningcorporatie in Rotterdam wilt een co-producent zijn voor de stad, dat is de reden dat dit ook belangrijk is.

Uitzondering

Er zijn uitzonderingen op het bovenstaande scenario. De klacht kan namelijk ook natuurlijk telefonisch worden doorgeven (veel eigenaren hebben geen internet), maar het is dan wel de bedoeling dat de telefonist de klacht op dezelfde manier invoert als het bovenstaande scenario.

Bij heel urgente problemen zoals een gaslek wordt er direct gehandeld en wordt het bovenstaande scenario natuurlijk niet uitgevoerd.

Bijlage C

Dit is de beperkte beschrijving van het datamodel die we hebben kunnen terug vinden in oude documentatie.

Klacht (complaint):

Aan een klacht kan het volgende gekoppeld worden:

  • Customer: De klant die de klacht heeft aangemeld;
  • Employee: De werknemer die de klacht aan heeft genomen;
  • ComplainType: Denk hierbij aan defect/technisch mankement/schade/etc;
  • ComplaintStatus: Denk hierbij aan aangemeld/afgehandeld/etc;
  • ComplaintPriority: Denk hierbij aan hoog/middel/laag;
  • ComplaintHandler: Een klacht kan zowel intern als extern afgehandeld worden. Als een klacht intern wordt afgehandeld, dan wordt hij via ComplaintHandlerIntern gekoppeld aan een afdeling, en eventueel aan een medewerker. Als een klacht extern wordt afgehandeld, dan wordt hij via ComplaintHandlerExtern gekoppeld aan een extern bedrijf (ExternalCompany);
  • Facility: Een facility is een voorziening die in een ruimte kan staan. Bijvoorbeeld een wc. Een klacht over een wc wordt dus op deze manier gelinkt;
  • Space: Een space is een ruimte in een huis. Bijvoorbeeld een badkamer. Als er een klacht is over de badkamer, wordt hij dus op deze manier gelinkt;
  • Property: Een property is een woning. Bijvoorbeeld het appartement waar de familie Knots in woont. Als er een klacht over de woning is wordt deze dus op deze manier gelinkt.

Er is al het een en ander uitgelegd over Property, Space en Facility. Het is handig om te weten dat een Property binnen een complex kan vallen. Bijvoorbeeld het appartement van de familie Knots, dat valt binnen een bepaald complex, het flatgebouw. Binnen de Property vallen dus verschillende Spaces en daar binnen weer Facilities.

Dan verder met de zaken die aan Property gekoppeld kunnen worden:

  • Contract: Een klant is via een Contract verbonden aan een Property. Een Property kan meerdere contracten hebben, omdat ook oude contracten dan in het systeem kunnen blijven staan;
  • Sales: Als een woning verkocht wordt, wordt dat via deze koppeling geregeld.

Aan Space is verder gekoppeld:

  • SpaceType: Een ruimte is gekoppeld aan een bepaald type. Zo heb je bijvoorbeeld het type badkamer/woonkamer/etc;
  • StandardComplaint: Per Space kunnen een aantal standaardklachten bekend zijn. Deze staan in deze tabel. Het idee is dat wanneer een klacht veel voorkomt, er een standaardklacht voor wordt gemaakt. Dit om het invullen van een klacht makkelijker te maken voor de klant. Zie de documentatie van het klachtensysteem voor meer info.

Aan Facility is verder gekoppeld:

  • ProblemFacility: Een bekend probleem van een Facility. Bijvoorbeeld een CV ketel die niet goed verwarmt;
  • SolutionFacility: Een oplossing voor het bekende probleem. In het geval van de CV ketel bijvoorbeeld: druk op de ‘reset’ knop;
  • FacilityType: Een type faciliteit, bijvoorbeeld een CV ketel, of een WC.

Aan Sales is verder gekoppeld:

  • SalesStatus: Hierin staat de status van de verkoop, denk aan te koop/verkocht onder voorbehoud/verkocht/etc;
  • ExternalCompany: Dit is de makelaar die eventueel aan de verkoop gekoppeld kan zijn.