CHECKLIST SOFTWARE GEMEENTELIJK MELDPUNT

Transcriptie

1 CHECKLIST SOFTWARE GEMEENTELIJK MELDPUNT OVER DIT DOCUMENT Bedoeling van dit document is een checklist te bieden die kan gebruikt worden bij het bepalen van welk type meldingssysteem voor uw organisatie het meest geschikt is. Het meldingssysteem voor de gemeente bestaat niet. Aan de hand van onderstaande beschrijving van mogelijke functies van een meldsysteem kunt u uitmaken welke functies van een meldsysteem voor uw bestuur het belangrijkst zijn en uw keuze zullen bepalen. bij het opstellen van bestekken voor software ter ondersteuning van een gemeentelijk meldpunt. Het document gaat daarbij enkel in op de vragen die typisch zijn voor meldsystemen. Vragen die voor elk type applicatie gelden (bijvoorbeeld :wat zijn de hardware vereisten?) zijn niet in dit document opgenomen. Dit is een eerste versie, aangemaakt naar aanleiding van het seminarie Gemeentelijk meldpunt op 22 november Aanvullingen, verbeteringen en opmerkingen zijn ten zeerste gewenst en kunnen meegedeeld worden aan: Peter Hautekiet V-ICT-OR Kenniscentrum Paviljoenstraat 9 B-1030 Brussel Tel. +32 (0) Fax +32 (0) Peter.Hautekiet@v-ict-or.be

2 WAT? DE INHOUD VAN HET MELDSYSTEEM Wat moet in eerste plaats kunnen behandeld worden door de software die het gemeentelijk meldpunt ondersteunt? EEN GEWONE MELDING Een melding betreft het signaleren van een gebrekkig functioneren van de overheid. Het gaat hier om de klassieke voorbeelden als de defecte straatlamp, de losliggende tegel,... Het kan echter ook gaan om inbreuken tegen de wet en overtredingen waartegen de overheid nog niet in actie is gekomen, zoals geurhinder, bouwovertredingen,... EEN KLACHT Een klacht is een melding over een slecht opgevolgde melding of over een vraag tot dienstverlening die niet (goed) werd opgevolgd. Wanneer een burger reeds eerder melding deed van een losliggende tegel en deze melding werd niet opgevolgd, spreekt men bij een hernieuwde melding van een klacht. Wanneer een burger melding doet van een gebrekkige dienstverlening bij een bepaald loket of een bepaalde dienst, spreekt men eveneens van een klacht. In grotere besturen worden klachten vaak apart behandeld door een ombudsman. Voor kleinere besturen lijkt dit moeilijk haalbaar. Belangrijk is wel dat binnen de registratie klachten als zodanig herkenbaar zijn. EEN SUGGESTIE Positief geformuleerde voorstellen tot verbetering, aanpassing van de dienstverlening enzoverder... WEGWIJS INFORMATIE Veel meldpunten behandelen ook vragen om informatie in verband met dienstverlening. Het betreft hier vragen van het type: waar kan ik terecht voor..., wat moet ik doen als..., en zo verder. Een productencatalogus vormt hier vaak een belangrijke ondersteuning. WIE? MOGELIJKE GEBRUIKERS VAN HET MELDSYSTEEM DE CENTRALE GEBRUIKERS. De hoofdgebruikers zijn de gebruikers van het centrale meldingspunt binnen een gemeente, die meldingen naar de diensten kunnen sturen. Het centrale meldpunt treedt op als beheerder van het systeem, binnen één bepaalde gemeente.

3 DE DECENTRALE GEBRUIKERS. Bijvoorbeeld : een secretariaatsgebruiker van een dienst heeft de volledige bevoegdheid over de meldingen die voor zijn/haar afdeling zijn bestemd. De secretariaatsgebruiker is vaak ook in staat om een melding te registreren die niet voor zijn afdeling bestemd is maar (vaak via het centrale meldpunt) aan de juiste afdeling wordt gericht. DE ONRECHTSTREEKSE OF OCCASIONELE GEBRUIKERS Meldingen kunnen naar gelijk welke medewerker gestuurd worden voor reactie. Het is de bedoeling dat het antwoord minimaal automatisch in het systeem bij de betreffende melding kan gevoegd worden. Op welke manier kan het systeem de antwoorden per van de onrechtstreekse gebruikers opvangen?. DE TECHNISCHE BEHEERDERS De technische beheerders ondersteunen het systeem maar gebruiken het niet. Database beheer (bijvoorbeeld maken van complexere rapporten, technische eerstelijnsondersteuning,...) KANALEN De software moet in basis gericht zijn op de verwerking van meldingen door een operator. Deze meldingen komen via verschillende kanalen, zowel telefonisch, mondeling, per brief of per binnen. Aandachtspunten per kanaal zijn: Telefonische meldingen: vlotte, proportionele invoer (geen overbodige informatie opvragen, aandacht voor schrem layout, tabbladen beperken, ) Meldingen per laat de software een eenvoudige verwerking via een mailsysteem (MS Outlook) toe, met een automatische minimale verwerking van het antwoord van de aangesprokene? Meldingen via de website: een bijzondere vorm van kunnen zijn de meldingen die via de website binnenkomen. De software moet ook meldingen kunnen verwerken die van een formulier van internet komen enz... In welke mate kan het systeem dergelijke (half)gestructureerde informatie zo vlot mogelijk integreren? Meldingen per brief of fax: inscannen van binnenkomende documenten, link met postregistratie DE LEVENCYCLUS VAN EEN MELDING De functionele vereisten van het systeem worden behandeld aan de hand van de levenscyclus van een melding. MELDING KOMT BINNEN Een melding komt binnen langs verschillende kanalen. Minimaal moet het mogelijk zijn aan te duiden via welk kanaal de melding is binnengekomen. Daarbij kunnen gebruikers van het systeem beroep doen op een

4 standaardlijst van kanalen. Deze lijst is door technische beheerders aanpasbaar en uitbreidbaar zonder tussenkomst van de leverancier. De aanbieder zal tevens duidelijk maken of er een specifieke interface is per kanaal. Voor een registratie via de telefoon is een snelle registratie met maximaal beroep op hulpbronnen (zie verder: openheid), voor een via de website binnengekomen melding is een maximaal hergebruik van de door de klant ingegeven informatie noodzakelijk. MELDING WORDT GEREGISTREERD WIE MELDT Bronbestanden met contactgegevens maken geen deel uit van meldsysteem op zich. Het systeem moet echter wel gebruik kunnen maken van dergelijke bronbestanden, zoals daar zijn: lokaal bevolkingsbestand, Kruispuntbank Ondernemingen, lijsten binnen besturen met verenigingen,... Daarnaast moet steeds de mogelijkheid bestaan om een melder in te voeren die niet in een bronbestand voorkomt. WIE REGISTREERT Bronbestanden met personeelsgegevens maken geen deel uit het meldsysteem. Het systeem moet echter wel gebruik kunnen maken van een bronbestanden met personeelsgegevens. Daarnaast moet steeds de mogelijkheid bestaan om een registrator in te voeren die niet in een bronbestand voorkomt. Het moet vooraf duidelijk zijn welke velden minimaal moeten beschikbaar zijn om een registrator succesvol te kunnen registreren, op welke manier deze gegevens in het systeem zullen worden binnengebracht en welke voorwaarden daarvoor vervuld moeten zijn. RUIMTELIJKE COMPONENT Vele meldingen hebben een ruimtelijke component. Is het binnen het system mogelijk om de plaats waarop de melding betrekking heeft te registreren? Ook hier is het gebruik van bronbestanden belangrijk (bijvoorbeeld CRAB Stratenlijst). WAAROVER WORDT GEMELD De inhoud van de melding moet kunnen worden beschreven/opgevangen in een commentaarveld. De mogelijkheid om hierbij ook attachments te kunnen invoegen is belangrijk. Idealiter kan ook de link gelegd worden met een productenlijst of productencatalogus, ter ondersteuning van informatievragen en in functie van rapportering van klachten. WANNEER WORDT GEMELD Tijdstip van de melding: het tijdstip is standaard de tijd van invoeren van de melding, maar kan gewijzigd worden door de gebruiker. Indien de melding via een webformulier werd aangemaakt, wordt het tijdstip dat wordt meegestuurd met dat formulier overgenomen. SOORT MELDING Is het systeem in staat diverse soorten meldingen te behandelen?

5 Het soort melding aan te duiden (bijvoorbeeld melding, klacht,...)? Binnen deze ruwe indeling bovendien verdere onderverdelingen te gebruiken (bijvoorbeeld defecte straatverlichting, zwerfvuil,...)? Op basis van deze soortaanduiding en onderverdelingen een andere opvolging kunnen voorstellen (zie verder routering)? ENKELVOUDIGE OF MEERVOUDIGE MELDING Is het systeem in staat om zowel enkelvoudige als meervoudige meldingen op te slaan en op te volgen? GERELATEERDE MELDINGEN Is het systeem in staat om meldingen aan elkaar te linken? Een melding kan bijvoorbeeld ten onrechte worden afgesloten. Een nieuwe melding over hetzelfde probleem kan naar deze eerdere melding verwijzen. Een ander voorbeeld is wanneer eenzelfde problematiek wordt gemeld door verschillende melders. Bestaat de mogelijkheid om deze meldingen aan eenzelfde dossier te koppelen? MELDING WORDT GEROUTEERD PROCES Gebeurt een voorstel van routering op basis van een procesbeschrijving die bij de verschillende soorten en onderverdelingen van meldingen hoort? Kan de registrator per melding beslissen om van dit voorstel af te wijken? Op welke manier kan een dergelijke procesbeschrijving binnen het systeem vastgelegd worden? PARALLEL/SERIEEL Is het mogelijk meldingen serieel of parallel te routeren? KANALEN Via welke kanalen kan de melding worden gerouteerd: , werkbon, intranet, telefoon,... Op welke manier wordt dit in het systeem geregistreerd: in welke gevallen wordt de routering vanuit het systeem zelf gegeneerd (bijvoorbeeld een die automatisch wordt verzonden) en in welke gevallen kan het systeem de routering wel registreren maar niet genereren (bijvoorbeeld een die niet automatisch wordt verzonden, maar die wel wordt toegevoegd als attachment bij de melding en die op die manier zichtbaar is binnen het systeem) BESTEMMELINGEN VAN DE MELDING Interne bestemmelingen: heeft het bestuur de mogelijkheid om een lijst van interne bestemmelingen op te maken, gebaseerd op bronbestanden? Externe bestemmelingen: heeft het bestuur de mogelijkheid om een lijst van externe bestemmelingen op te maken, bijvoorbeeld nutsmaatschappijen?

6 REACTIES Kunnen de reacties van een bestemmeling opgeslagen worden in een commentaarveld? Met of zonder attachments? ROUTERINGSGESCHIEDENIS Het is belangrijk ten allen tijde snel een duidelijk overzicht te hebben van de routeringsgeschiedenis van een melding, met inbegrip van registrator, bestemmelingen, reacties, tijdstippen,... DE MELDING WORDT GECOMMUNICEERD Doorheen de routering verandert de status van een melding. Hierbij moet onderscheid gemaakt worden tussen de interne status van een melding en de externe status van een melding die kan worden meegedeeld aan de melder. Op welke manier kan de status van de meldingen gecommuniceerd worden aan de melder: via standaardbrieven, via de gemeentelijke website, via ,...? MELDING WORDT GERAPPORTEERD STANDAARDRAPPORTEN Maken standaardrapporten deel uit van het systeem? Deze standaardrapporten ondersteunen de werking van het centrale meldpunt en laten toe aanslepende meldingen op te sporen, dubbele meldingen te detecteren,... AD HOC OPVRAGINGEN: QUERIES EN VIEWS Daarnaast moet het voor de technische beheerders (en/of voor centrale gebruikers met voldoende technische bagage) mogelijk zijn om de database te bevragen met ad hoc queries en views, zonder dat daarvoor een tussenkomst van de leverancier vereist is. NIET-FUNCTIONELE VEREISTEN OPENHEID GEBRUIK KUNNEN MAKEN VAN EXTERNE BRONBESTANDEN Kan het system gebruik maken van binnen het bestuur aanwezige bronbestanden: Lokaal bevolkingsbestand Personeelsbestand Bedrijvendatabank (VKBO) Lijsten van verenigingen en andere contactgegevens binnen lokale besturen

7 Productenlijst Productencatalogus Veel meldingen hebben een ruimtelijke component. Het is daarom belangrijk gebruik te kunnen maken van belangrijke GIS bronbestanden (bijvoorbeeld stratenlijst). OPENHEID NAAR MAIL Binnenhalen van mails voor meldingen. Doorsturen van meldingen via mail. OPENHEID VAN DE DATABANKEN. Er moet een duidelijk onderscheid zijn tussen de meldingssoftware en de manier waarop de gegevens in het meldsysteem worden opgeslagen. Het is af te raden dat de meldingssoftware de enige toegang zou zijn tot de gegevens. GEBRUIKSVRIENDELIJKHEID INTERFACE EN GRAFISCHE VOORSTELLING. De gebruikersinterface is uiterst belangrijk. Hij moet intuïtief zijn en uiterst overzichtelijk. Het moet op een vlotte manier mogelijk zijn om snel gegevens te corrigeren te wijzigen enz Zeker wanneer wordt ingezet op een telefonisch meldpunt, is een goed afgewogen invoersscherm, zonder overdaad van velden en tabbladen aangewezen. Het moet vooraf duidelijk zijn welke velden minimaal moeten beschikbaar zijn om een melding succesvol te kunnen registreren, op welke manier deze gegevens in het systeem zullen worden binnengebracht (intikken, overnemen uit bronbestand, batchimport) en welke voorwaarden daarvoor vervuld moeten zijn. VERMIJDEN VAN DUBBELE INVOER Wanneer door verschillende personen, diensten meldingen geregistreerd worden is het van belang om de invoer van dubbele meldingen te vermijden of te linken aan mekaar. Een melding over een bepaald item kan bijvoorbeeld door drie verschillende personen gesignaleerd worden maar die allemaal een iets andere omschrijving geven van probleem of situering. Gespecialiseerde zoekmogelijkheden of vergelijkingstools zouden hier een aanzet van oplossing kunnen betekenen. PROPORTIONALITEIT De aangeboden schermen en in te vullen velden moeten proportioneel zijn in functie van de context. Wanneer een operator slechts vijf gegevens dient te lezen of in te vullen, zullen idealiter ook slechts deze gegevens worden aangeboden of gevraagd. Proportionaliteit betekent ook dat er een goed evenwicht tussen de eisen langs de rapportagekant en de eisen van de invoerzijde: wanneer een bepaald invoerveld een zware last legt op de registrator, is het de moeite waard na te gaan of deze extra inspanning voldoende meerwaarde bij de rapportering oplevert.

8 APPENDIX : OVERZICHT VAN MOGELIJKE BEPALINGEN IN EEN BESTEK 1. De indiener zal in de offerte duidelijk maken welke soorten gebruikers gedefinieerd kunnen zijn en wat de daaraan verbonden rechten zijn. De indiener zal duidelijk maken wat de implicaties zijn op het licentiemodel. 2. De indiener zal in de offerte duidelijk maken welke velden minimaal moeten beschikbaar zijn om een melder succesvol te kunnen registreren. De indiener zal in de offerte tevens duidelijk maken op welke manier deze gegevens in het systeem zullen worden binnengebracht en welke voorwaarden daarvoor vervuld moeten zijn. 3. De indiener zal in de offerte duidelijk maken welke velden minimaal moeten beschikbaar zijn om de registrator van een melding succesvol te kunnen registreren. De indiener zal in de offerte tevens duidelijk maken op welke manier deze gegevens in het systeem zullen worden binnengebracht en welke voorwaarden daarvoor vervuld moeten zijn. 4. De indiener zal in de offerte duidelijk maken welke velden minimaal moeten beschikbaar zijn om een de ruimtelijke component van een melding succesvol te kunnen registreren. De indiener zal in de offerte tevens duidelijk maken op welke manier deze gegevens in het systeem zullen worden binnengebracht en welke voorwaarden daarvoor vervuld moeten zijn. 5. De indiener zal duidelijk maken of bij meldingen ook attachments kunnen ingevoegd worden. 6. De indiener zal aanduiden of het mogelijk is meldingen serieel of parallel te routeren. 7. De indiener zal duidelijk maken of het mogelijk is aan te duiden via welke kanalen de melding werd gerouteerd : , werkbon, intranet, telefoon, De indiener zal tevens aanduiden in welke gevallen de routering vanuit het systeem zelf wordt gegeneerd en in welke gevallen het systeem de routering wel kan registreren maar niet genereren. 9. Interne bestemmelingen : het bestuur heeft de mogelijkheid om een lijst van interne bestemmelingen op te maken, gebaseerd op bronbestanden. 10. Externe bestemmelingen : het bestuur heeft de mogelijkheid om een lijst van externe bestemmelingen op te maken, bijvoorbeeld nutsmaatschappijen. 11. De reacties van bestemmelingen kunnen opgeslagen worden. De indiener zal duidelijk maken of hierbij ook attachments kunnen ingevoegd worden. 12. Het is belangrijk ten allen tijde snel een duidelijk overzicht te hebben van de routeringsgeschiedenis van een melding, met inbegrip van registrator, bestemmelingen, reacties, tijdstippen, De indiener zal duidelijk maken op welke manier de status van de meldingen kunnen worden gecommuniceerd aan de melder : via standaardbrieven, via de gemeentelijke website, via , De indiener zal duidelijk maken welke standaardrapporten deel uitmaken van het systeem.

9 15. Daarnaast moet het voor de technische beheerders mogelijk zijn om de database te bevragen met ad hoc queries en views, zonder dat daarvoor een tussenkomst van de leverancier vereist is (zie verder : openheid). 16. De inschrijver zal daarom duidelijk maken op welke manier gebruik kan gemaakt worden van belangrijke bronbestanden en welke informatie daarvoor minimaal ter beschikking moet zijn a. Lokaal bevolkingsbestand b. VKBO c. Personeelslijst d. Lijsten met contactgegevens in diverse formaten e. CRAB-stratenlijst en adrespuntenbestand 17. De indiener zal duidelijk maken op welke manier binnenkomende s kunnen verwerkt worden als melding. 18. De indiener zal duidelijk maken op welke manier reacties van een bestemmeling via kunnen verwerkt worden binnen het meldpuntsysteem.