CDG000747_Bijlage 2 : Functionele en niet-functionele vereisten. Bestek CDFout! Verwijzingsbron niet gevonden. Fout! Verwijzingsbron niet gevonden

Bestek CDFout! Verwijzingsbron niet gevonden. – Fout! Verwijzingsbron niet gevonden. Bijlage 2

Bestek nummer CDG000747

Voor het toewijzen van een overheidsopdracht voor de aanneming van diensten met betrekking tot Lijstenbeheer stad Gent

CDG000747_Bijlage 2 : Functionele en niet-functionele vereisten

1


Inhoudsopgave 1

Algemene toelichting ............................................................................................... 3 1.1 Doel en scope ....................................................................................................... 3 1.2 De toestand zoals ze nu is (AS IS) ....................................................................... 3 1.3 Gewenste toestand (To Be) .................................................................................. 4 1.4 Niet-functionele vereisten .................................................................................... 5

2

Beschrijving vereisten ............................................................................................. 6 2.1 Gebruikers............................................................................................................ 6 2.2 Contacten ............................................................................................................. 8 2.3 Adressen ............................................................................................................ 10 2.4 Lijsten ................................................................................................................ 11 2.5 Gebruikersinterface ............................................................................................ 12 2.6 Bronnen ............................................................................................................. 13 2.7 Data kwaliteit ..................................................................................................... 14 2.8 Output & koppelingen ........................................................................................ 16 2.9 Privacy ............................................................................................................... 17

3

Bestaande implementaties in MS CRM ................................................................... 18

2


1 Algemene toelichting 1.1 Doel en scope De stad Gent maakt op grote schaal gebruik van adres- en contactbestanden. Deze bestanden dienen vaak een verschillend doel, gaande van eenvoudige mailinglijsten, interne of externe communicatie, facturatie tot meer complexe vormen van interactie, zoals bijvoorbeeld CRM-toepassingen (reservaties, planning, klachtenbeheer,…). De toepassing zal de ruim 200 bestaande bestanden met contactgegevens vervangen, die momenteel nog in MS Access, MS Excel, MS Word, Filemaker, of andere toepassingen worden bijgehouden. De contactgegevens zullen centraal bijgehouden worden, gedeeld worden door de verschillende gebruikers, en gekoppeld aan authentieke bronnen. Voor het beheer en gebruik van de gegevens wordt rekening gehouden met alle beperkingen op het vlak van privacy. Het systeem dient een zeer flexibele en gebruiksvriendelijke front-end te hebben, en een krachtige en flexibele databank-gebaseerde back-end. De gebruikers moeten op een eenvoudige manier de lijsten kunnen beheren en gebruiken voor o.a. het uitsturen van mailings en andere communicaties. Daarnaast zal het systeem ook gekoppeld worden aan andere toepassingen die gebruik maken van contactgegevens. Het doel van de lijstentoepassing is dus 2-ledig: - enerzijds willen we een toepassing die een platform biedt om alle lijsten, die nu in allerlei formaten in de stadsadministratie terug te vinden zijn, te beheren en gebruiken; - anderzijds willen we een centrale databank die toelaat contactgegevens te beheren en te ontsluiten naar zowel individuele gebruikers (o.a. via lijsten) als naar andere toepassingen.

1.2 De toestand zoals ze nu is (AS IS) Momenteel worden allerlei lijsten van contacten in aparte documenten (Word, Excel,…) of toepassingen (MS Access, Filemaker,…) opgeslagen en beheerd. Het resultaat is dat die lijsten een eigen bestaan leiden, niet automatisch geactualiseerd worden (b.v. overleden personen worden niet automatisch uit de lijsten gehaald, personen of bedrijven die verhuizen worden niet gelinkt met hun nieuwe adres,…) en ook weinig of niet met anderen gedeeld worden. Elke dienst maakt daarnaast ook gebruik van eigen methodes om hun lijsten te gebruiken voor het uitsturen van mailings en andere campagnes. Er is een duidelijke vraag vanuit de gebruikers om efficiënter te kunnen werken, een hogere kwaliteit van gegevens te kunnen gebruiken, op een eenvoudige manier campagnes te kunnen doen, en tegelijk een goede ondersteuning te krijgen voor de gebruikte toepassing en tools.

3


1.3 Gewenste toestand (To Be) Toepassing

Alle contactgegevens van zowel personen als bedrijven die binnen de stad Gent gebruikt worden, zullen opgeslagen worden in één centrale databank. De gegevens zullen vanuit één toepassing kunnen beheerd en gebruikt worden, en dit zowel voor het beheer van alle lijsten die momenteel in de stad gebruikt worden, als voor alle andere toepassingen die contactgegevens gebruiken. De toepassing zal geïnstalleerd worden op de infrastructuur van Digipolis Gent, en bij voorkeur gebaseerd zijn op MS Dynamics CRM. Voor het meer complexe beheer van de lijsten zal de gebruikersinterface van de toepassing zelf gebruikt worden, maar voor eenvoudig gebruik (basisfunctionaliteiten zoals het consulteren van lijsten of basis-ingaves) zal gebruik gemaakt worden van eenvoudige web-pagina’s of van b.v. een Sharepoint gebaseerde interface.

Informatiebronnen

Het systeem dient gekoppeld te worden met een aantal (voor een deel authentieke) bronnen (zie sectie 2.2 ‘Bronnen’) voor het verzekeren van een hoge data kwaliteit van de gebruikte gegevens.

Output en koppelingen

Er zijn verschillende outputmogelijkheden van de gegevens voorzien: • via file-extractie voor verdere verwerking (b.v. in Excel), • via een campagnemodule/tool voor het uitvoeren van b.v. marketingen communicatie-acties, • publicatie op het Intranet/Internet, • … Daarnaast dienen er koppelingen voorzien te worden met infofiches en andere toepassingen die de contactgegevens gebruiken, dit laatste bij voorkeur via webservices.

Data kwaliteit

Aangezien de toepassing ook als centrale database voor contactgegevens zal fungeren moet er bijzondere aandacht besteed worden aan data kwaliteit (zie sectie 2.7 ‘Data kwaliteit’).

Privacy

Privacy is cruciaal gezien het beheer en gebruik van persoonsgegevens. Er moeten dan ook speciale maatregelen genomen worden om de privacy te bewaken (zie sectie 2.9, ‘Privacy’).

4


1.4 Niet-functionele vereisten De toepassing zal op een grote schaal binnen de stad Gent gebruikt worden, en dit door verschillende types gebruikers en toepassingen. Het is dan ook van cruciaal belang dat de toepassing zowel zeer performant als zeer gebruiksvriendelijk.

Performantie

Snelheids- en wachttijdvereisten: de wachttijden voor het ophalen, beheren, wijzigen,… van gegevens moeten voor de gebruiker aanvaardbaar zijn.

Betrouwbaarheids- en beschikbaarheidsvereisten: de toepassing moet zeer stabiel en altijd beschikbaar zijn. Capaciteitsvereisten: het systeem moet een groot aantal gegevens kunnen bevatten (minimaal 1 mio records), verwerken (o.a. bij de dagelijkse synchronisatie buiten de diensturen met de authentieke bronnen, bij het uitvoeren van campagnes,…), en beheren. Daarnaast moeten er een groot aantal (+/-100 van de 800 totaal aantal) gebruikers tegelijk in het systeem kunnen werken.

Gebruiksvriendelijkheid

De eindgebruiker van de applicatie moet in de mogelijkheid zijn om op natuurlijke wijze, zonder nood aan een doorgedreven opleiding, de applicatie te gebruiken (ook voor niet-frequente gebruikers). De te nemen acties moeten intuïtief in het programma kunnen uitgevoerd worden. De toepassing ondersteunt functionaliteiten die de gebruiker helpt bij het invullen van gegevens (b.v. via autocompletion), zoeken van informatie (b.v. via fuzzy zoeken),… De schermen moeten zo eeenvoudig mogelijk zijn, zonder overhead.

5


2 Beschrijving vereisten 2.1 Gebruikers Klant

De klant en de afnemer van het systeem is de stad Gent. De gebruikers van de lijstentoepassing, zijn alle werknemers van stad Gent die nu al met heterogene adresbestanden werken.

Categorieën

Er zijn verschillende categorieën gebruikers: •

•

•

•

Rollen

Systeembeheerder/Toepassingsbeheerder a. Verantwoordelijk voor het beheer van het systeem op niveau van de hele stad, evenals van eventuele externe koppelingen met andere systemen en gegevensbronnen of import/migratie van bestaande bestanden b. Heeft lees- en schrijfrechten. c. Kan andere gebruikers aanmaken en beheren d. Kan basistabellen beheren e. Kan extra velden beheren Lijstbeheerder a. Aanmaak en beheer eigen lijst(en) b. Rechten op de lijst(en) toekennen aan andere gebruikers c. Exportmogelijkheden ifv mailings Gewone gebruiker a. Werken met/aanpassen van contactgegevens van toegekende lijsten b. Exportmogelijkheden ifv mailings Alleen lezen gebruiker a. Enkel raadplegen van de toegekende lijsten b. Met of zonder exportmogelijkheden ifv mailings

Los van het type gebruiker moeten er ook extra rollen aan een gebruiker toegekend kunnen worden : 1. VIP-gebruikers: gebruiker die specifiek toegang krijgt tot privacygevoelige gegeven vb privé GSMnummer 2. Bevolkingsgebruiker: deze personen hebben een speciale toelating van de dienst bevolking voor het consulteren van persoonsgegevens uit het Rijksregister (bvb Rijksregisternummer) 3. Personeelsgebruiker: deze personen mogen uit hoofde van hun functie een aantal privé gegevens van personeelsleden opvragen, gegevens die door een « gewone » ambtenaar niet zichtbaar mogen zijn. Deze rol zal geïmplementeerd moeten worden als beslist wordt om met de lijstentoepassing op eenzelfde omgeving te werken als het Infopunt Personeel (zie lager).

6


De lijstentoepassing moet deze gebruikersgroepen en –rollen kunnen beheren en hen rechten kunnen toekennen. Eventuele andere gebruikersprofielen of rollen moeten ook in een latere fase op een eenvoudige wijze kunnen worden geïmplementeerd.

Single Sign-on

De toepassing ondersteunt single sign-on voor de gebruikers en maakt dus gebruik van de bestaande Active Directory mogelijkheden.

7


2.2 Contacten Wat?

Onder contacten verstaan we volgende entiteiten: personen, organisaties en relaties.

Personen

Dit zijn natuurlijke personen met alle basisgegevens die nodig zijn ter identificatie (naam, geboortedatum, adres,…) en contactgegevens (mailadres, bijkomende adresgegevens, telefoonnummer en gsm,…). Tussen 2 personen moeten relaties beschreven kunnen worden in de zin van “ is echtgenoot van” , “is kind van”,…)

Organisaties

Organisaties kunnen zowel bedrijven (onderneming of vestiging) als verenigingen allerlei zijn. De basisgegevens zijn ondernemingsnummer en BTW-nummer (indien van toepassing) naam, commerciële naam,… Er kunnen ruime contactgegevens worden bewaard voor een organisatie (mailadres, websites, telefoonnummers,…) Tussen 2 organisaties kan een al dan niet hiërarchische relatie beschreven worden, maar die vormt geen aparte entiteit (moeder-, dochteronderneming, opvolger,…).

Relaties

Een relatie beschrijft het verband tussen een persoon en een organisatie. Een relatie moet gezien worden als een hoedanigheid van een natuurlijke persoon (bvb voorzitter van de voetbalclub of CEO van een bedrijf). Elke persoon of organisatie kan gekoppeld zijn aan meerdere relaties hebben. De relatie wordt telkens beschreven met begin- en einddatum, functietitel, specifieke contactgegevens,… Een relatie kan verwijzen naar adresgegevens van de persoon of van de organisatie. Bij voorkeur kunnen de onderlinge relaties visueel overzichtelijk weergegeven worden.

Velden per type contact

Per entiteit worden verschillende velden bijgehouden: zie mindmap hieronder en in bijlage 3 (CDG000747_Bijlage 3_Contacten) bij dit bestek. Deze lijst is vatbaar voor aanpassingen.

8


9


2.3 Adressen CRAB adrespunten en Rijksregister adressen In gemeentebesturen zijn er 2 officiële formaten voor adresaanduiding: de belangrijkste is AGIV (Agentschap Geografische Informatie Vlaanderen) met het CRAB-formaat, de andere is het Rijksregister (Federale bevoegdheid) met de codes die daar gehanteerd worden. Om diverse historische redenen zijn er grote verschillen in de adressen van die 2 bronnen en is een één op één match niet volledig mogelijk. Er is voorlopig op federaal of Vlaams niveau geen initiatief om die 2 bronnen éénduidig te koppelen aan mekaar. Met de lijstentoepassing hebben we de ambitie om dat voor het lokale niveau, dus voor grondgebied Gent wel te doen. Hiertoe moeten 2 bestanden “gematcht” worden: 1. GRAB (=gemeentelijk referentie adressen bestand) is de centrale Geodatabank van de stad waarin alle adres-gegevens van grondgebied Gent in CRAB-formaat worden bijgehouden. Er is een webservice ter beschikking om die gegevens op te halen 2. Voor de rijksregister-adressen zijn er 2 bestanden die hiervoor geïmporteerd moeten worden. Voor de adressen buiten Gent hebben we Multinet gegevens ter beschikking (met jaarlijkse updates). In -

concreto betekent dit: 2 types adressen matchen (automatisch en manueel) interface om de niet gematchte adressen te kunnen beheren en aanpassen metadata toevoegen updates voorzien alles ter beschikking kunnen stellen van andere toepassingen invoer van niet-gevalideerde adressen moet kunnen, maar mogelijkheid voorzien om nadien via beheerderstaken te laten valideren.

De manier waarop dit technisch uitgewerkt wordt, kan in onderling overleg bepaald worden. ( er is indien nodig een service ter beschikking om de juiste adresbepaling te kunnen doen)

10


2.4 Lijsten Wat?

Lijsten zijn verzamelingen van contacten. Deze kunnen manueel samengesteld worden door contact per contact toe te voegen, maar kunnen ook dynamisch, op basis van een aantal selectiecriteria gevormd worden. Enkel de beheerder(s) van een lijst kunnen die criteria aanpassen. De contacten worden in de centrale database opgeslagen, een lijst is een manier om een subset van die centrale gegevens te visualiseren en beheren. Wijzigingen aan een record in een lijst zijn steeds algemene en dus centrale wijzigingen. Dit betekent ook dat het verwijderen van een record uit een lijst, niet betekent dat het record uit de centrale database is verwijderd. Een hiërarchische groepering van lijsten is wenselijk. Bvb Hoofdlijst met alle scholen, onderverdeeld in stadsonderwijs, vrij onderwijs, gemeenschapsonderwijs… Zakenpartners is hiervan een zeer goed voorbeeld: er zijn verschillende types zakenpartners die evt door verschillende personen beheerd kunnen worden. De essentiële functies voor het beheer van een lijst moeten aanwezig zijn: uitgebreid zoeken, filteren, sorteren, raadplegen, wijzigen, printen, exporteren,…

Extra velden

Per record moeten er op niveau van de lijst (niet centraal en dus niet zichtbaar voor andere gebruikers die geen toegang tot de lijst hebben), extra velden kunnen toegevoegd worden aan persoon/organisatie/relatie. Deze velden maken deel uit van de lijst en moeten dus over dezelfde beheersmogelijkheden (zoek, print, filter,…) beschikken zoals hierboven beschreven.

Deelbaarheid

De beheerder van een lijst moet zelf kunnen beslissen om een lijst te delen met een andere gebruiker en kunnen bepalen welke rechten hij die gebruiker hierbij toekent.

Pilootlijsten & resultatenlijsten

Volgende lijsten moeten opgeleverd worden als resultaat van de opdracht. Voor nagenoeg elk van die lijsten zal een bulk-import of migratie traject noodzakelijk zijn. 1/ zakenpartners - totaal van 3500 zakenpartners - export beschikbaar in .cvs-bestand 2/ protocollijst (openbare gegevens) - access bestand 3/ Bestand vrijwilligers - xls-bestand - 1700 lijnen 4/ lijst contactpersonen gebiedsgerichte werking - verschillende xls -bestanden 5/ nog 6 andere bestanden die in samenspraak bepaald zullen worden

11


2.5 Gebruikersinterface UI voor kern gebruikers

UI voor kerngebruikers die alle functionaliteiten moeten kunnen aanwenden.

UI voor basis gebruikers

UI met basisfunctionaliteiten die toelaat om: • Met minimum aan opleiding grote groep gebruikers te kunnen laten werken in de applicatie • Webinterface • Evt sharepoint

12


2.6 Bronnen

13


WinLBV

WinLbv is het lokaal bevolkingsbestand van de stad Gent en dient als bron voor de bevolkingsgegevens van de eigen inwoners. Leverancier: Cevi NV Database: SQL server Frequentie koppeling: éénmalige import en nadien dagelijkse updates Technologie koppeling: te bekijken Opmerkingen: ‐ Er moeten enkele rules toegepast worden om de overleden, verhuisde,… inwoners te kunnen identificeren en filteren. ‐ Velden afkomstig uit WinLbv zijn alleen-lezen binnen CRM aangezien ze de hoogste betrouwbaarheid genieten.

VKBO

Er moet een koppeling met VKBO gelegd worden. Koppeling via: CORVE (bij voorkeur webservice: zie www.corve.be) Frequentie: dagelijks Inhoud: • Gentse ondernemingen en vestigingen • Indien mogelijk op vraag ook instant ophalen van niet-Gentse ondernemingen/vestigingen • Basis identificatiegegevens • Contactgegevens • Indien mogelijk ook extra gegevens uit de jaarrekening: omzet , aantal werknemers,… Opmerkingen: ook hier moeten een aantal interpretaties gebeuren en rules toegepast worden.

GRAB

GRAB = gemeentelijk referentie adressen bestand; zie hoger bij Adressen.

Cevips

Cevips is de toepassing voor personeelsbeheer van de stad Gent. Er is momenteel al een koppeling tussen Cevips en MS Dynamics CRM in het kader van het Infopunt Personeel dat de afhandeling van cases in deze tool doet. De koppeling bestaat uit een .csv-bestand dat elke nacht klaargezet wordt vanuit Cevips en opgeladen wordt in CRM. Het is mogelijk dat de bestaande koppeling deels of volledig kan (her)gebruikt worden. Leverancier: Cevi NV Frequentie koppeling: dagelijks

AD

Om het gebruikersbeheer te vereenvoudigen moet een koppeling met de Active Directory gerealiseerd worden. Er is al een koppeling gerealiseerd met AD om de mailadressen van personeelsleden op te halen (project Infopunt Personeel).

File import module

Er moet een bulk importmodule zijn, waarmee via een user interface een lijst gegevens snel kan worden opgeladen. De mapping van de importvelden naar velden in de lijstentoepassing moet kunnen worden geconfigureerd en de nodige controles op datakwaliteit en dubbels moet voorzien zijn (zie onder). Indien nodig moeten rules toegepast kunnen worden om de data correct op te nemen.

2.7 Data kwaliteit

14


Aangezien de lijstentoepassing ook als centrale database voor contactgegevens zal fungeren is data kwaliteit een bijzonder belangrijk issue, en dit zowel bij het (bulk) importeren van bestaande lijsten, als bij manuele invoer van gegevens.

Duplicatendetectie en afhandeling

Intelligente en doorgedreven duplicatendetectie- en afhandeling is hierbij cruciaal: ‐ Detectie potentiële dubbels ‐ Visualisatie dubbels ifv vergelijking ‐ Voorstelling verschillende merge-opties De nodige tools/schermen voor gerichte controles door de databeheerders moeten voorzien zijn.

Kwaliteitsniveaus

Het hanteren van verschillende kwaliteitsniveaus is ook een belangrijk punt. Hiermee bedoelen we dat voor elke persoon, relatie of organisatie een kwaliteitsniveau moet kunnen toegekend worden aan de gegevens. Dit kwaliteitsniveau kan bepalend zijn voor het gebruik/visualisatie van de gegevens binnen de toepassing (dit moet nog in concreto worden uitgewerkt). ‐ Een record met onvolledige of onbetrouwbare gegevens moet het laagste kwaliteitsniveau krijgen. ‐ Een record met niet gevalideerde gegevens (check met bron niet mogelijk of niet gelukt), kan ter validatie aan een beheerder voorgelegd worden. ‐ Een record afkomstig uit een authentieke bron draagt het hoogste kwaliteitsniveau. De velden die overgenomen werden uit de authentieke bron worden gelockt zodat ze niet overschreven kunnen worden.

Normalisatie

Normalisatie van gegevens Waar mogelijk moet er steeds met normalisatie van gegevens gewerkt worden. Dit kan bvb voor Rijksregisternummer, telefoonnummers, GSM nummers, datums, ondernemingsnummers,… Dankzij de koppeltabel voor adressen zullen ook de Gentse adressen genormaliseerd zijn. Voor adressen buiten Gent bestaan er alternatieve mogelijkheden voor normalisate van adresgegevens (CRAB, multinet,…).

Signaalfunctie

Bij data kwaliteit denken we ook aan duidelijke signaalfuncties binnen de toepassing voor gegevens die correct moeten geïnterpreteerd worden of die van gevoelige aard zijn, bijvoorbeeld: ‐ Duidelijk aangeven als een persoon overleden is, niet alleen op niveau van de persoon, maar ook op niveau van diens relaties. ‐ Mailadressen, telefoonnummers,… die een status “ongeldig” hebben gekregen mogen in mail- of SMS-acties niet meer meegenomen worden. ‐ Signaal naar de beheerder(s) van een lijst kunnen sturen als een van de lijstleden of een van zijn gegevens, verwijderd of niet relevant/bruikbaar meer is. Dit signaal kan ook gegeven worden in de vorm van toegewezen taken binnen een workplace. ‐ ….

15


Controlefunctie

Bij het publiceren van gegevens op naar een website- omgeving (afhankelijk van het informatieniveau van de records) moet het mogelijk zijn een controlefunctie in te bouwen. Dit wil zeggen dat er een workflow kan opgestart worden die de informatie eerst laten nakijken door een verantwoordelijke alvorens ze daadwerkelijk gepubliceerd wordt.

16


2.8 Output & koppelingen

17


Er moeten verschillende output mogelijkheden en koppelingen met andere systemen voorzien zijn:

Ad hoc

File export

Gebruikers moeten op elk moment gegevens kunnen exporteren in .xls, .csv en eventueel andere formaten die eenvoudig en andere toepassingen (typisch MS Excel) kunnen opgeladen worden.

Campagnes

De lijsten zullen zeer frequent gebruikt worden om (marketing/informatie/…) campagnes (email, samenvoegen in Word-templates, SMS,…) te doen. Dit moet op een eenvoudige en gebruiksvriendelijke manier kunnen gebeuren.

Structureel

Internet en/of intranet

Koppeling met Infofiches

Sommige lijsten moeten gepubliceerd worden op intranet en/of internet op dagelijkse basis. Afhankelijk van het informatieniveau van de records (zie hoger bij punt 2.2 Contacten) worden de gegevens doorgegeven voor website en/of intranet. De lijst zakenpartners is hiervan een goed voorbeeld. De specifiek hiertoe aangeduide zakenpartners moeten geëxporteerd worden om op de websites www.gent.be en m.gent.be gepubliceerd te worden. Een iets grotere set aan gegevens wordt dan weer op intranet gepubliceerd ter ondersteuning van de stadsdiensten. Een infofiche bevat alle relevante uitleg over een bepaald product, evenement, locatie of dienstverlening. De infofiches vormen samen het kennisbeheersysteem voor de stad. Ze worden decentraal beheerd en worden via intranet (en in de toekomst via internet) verder verspreid. Momenteel zitten de infofiches in SAP CRM 3 maar er loopt een opdracht om deze te migreren naar een nieuwe tool tegen januari 2012. Het staat nog niet volledig vast welke de nieuwe tool wordt (zou Sharepoint kunnen zijn). Wel staat vast dat er een nauwe koppeling moet zijn tussen de infofches en de zakenpartners: • In elke infofiche worden de verwante zakenpartners gekoppeld en moeten gevisualiseerd kunnen worden. • Andersom moet aan elke zakenpartner ook een infofiche kunnen gekoppeld worden. • Die koppelingen moeten automatisch wederzijds zijn ( tenzij de beheerder hier anders over beslist). • De zoekfunctie van de infofiches moet ook kunnen zoeken in de zakenpartners.

Webservices /database views

Om de centrale contactegegevens ter beschikking te stellen van diverse andere toepassingen die zich buiten het MS CRM gebied bevinden, moet er een uitgebreide webservice bestaan voor opzoeking, raadpleging, creatie, wijziging, updates, … Een van de applicaties die zo’n koppeling vraagt is de Briefwisselingstoepassing die momenteel wordt uitgewerkt op een Alfresco-platform. In de toekomst zullen zeker nog andere applicaties volgen.

2.9 Privacy

18


Privacy is een bijzonder belangrijk punt binnen de stadsadministratie. Er wordt immers continu met persoonsgegevens gewerkt. Bij het afschermen van privacygevoelige gegevens wordt teruggevallen op 2 basisprincipes: proportionaliteit en finaliteit. Wat een gebruiker mag zien moet in verhouding staan tot wat hij nodig heeft voor zijn werk en mag enkel voor dat specifieke doel gebruikt worden. Met de lijstentoepassing moeten we het evenwicht bewaren tussen het centraal beheren en ter beschikking stellen van contactgegevens enerzijds en het afschermen van privacygevoelige data anderzijds. De centrale contactgegevens zijn voor iedereen raadpleegbaar met minimaal volgende beperkingen: ‐ De algemene zoekmogelijkheden over de gehele centrale database moeten ingeperkt worden: bvb zoek op minimaal 3 karakters, en/of minimaal 2 velden… ‐ Velden die enkel zichtbaar zijn voor bepaalde rollen van gebruikers (bvb Rijksregisternummer of privégegevens) moeten voor de “gewone” gebruiker afgeschermd worden De lijsten zijn volledig afgeschermd met volgende implicaties ‐ Alleen zichtbaar voor beheerders en gebruikers die de nodige rechten hebben gekregen ‐ Er mag in geen geval opgevraagd kunnen worden in welke lijsten een bepaalde persoon allemaal voorkomt (dit in tegenstelling tot een CRM systeem in een commerciële omgeving), tenzij van de lijsten waarvan je specifiek beheerder bent. Het feit dat iemand tot een bepaalde lijst behoort, kan namelijk al een privacygevoelig gegeven zijn (bvb lijst met methadongebruikers). Om die privacy maatregelen te realiseren moeten minimaal volgende middelen ter beschikking zijn: ‐ Rollen & rechten van de gebruikers (zie punt 2.1) ‐ Afscherming op veldniveau mogelijk (bvb privé GSM nummer) ‐ Hash op Rijksregisternummer toepassen ‐ Logging alle opvragingen en bijwerkingen worden nominatief in een log bijgehouden zodat permanente monitoring en audits achteraf steeds mogelijk zijn. ‐ Er zal aan de leverancier gevraagd worden om een charter te ondertekenen mbt respect op de privacy bij het gebruik van persoonsgegevens

19


3 Bestaande implementaties in MS CRM Er zijn al een aantal projecten gerealiseerd of geïnitieerd in MS Dynamics CRM (versie 2011): Ondernemers loket

OOG: Ondersteuningspunt Ondernemers Gent • sinds maart 2011 • case management en koppeling met Sharepoint 2010 voor kennisbeheer

InfoPunt Personeel – IPP

• • •

sinds juli 2011 case management en koppeling met Sharepoint 2010 voor kennisbeheer Sharepoint 2010 interface op CRM voor Back office gebruikers

Digidoss

• •

beheer van tewerkstellingsinitiatieven van het departement Economie opstart september 2011

Gentinfo

Centraal callcenter van de stad • case management en klachtenbeheer • Koppeling met Sharepoint (of andere tool) voor kennisbeheer • Sharepoint 2010 interface op CRM voor Back office gebruikers • geplande opstart januari 2012 Elk van deze projecten is momenteel een aparte implementatie, alleen het ondernemersloket en Digidoss zullen in eenzelfde omgeving uitgerold worden. Er moet bekeken worden hoe omgegaan wordt met deze implementaties en waar het raadzaam is om gezamelijke structuren te gebruiken.

20

CDG000747_Bijlage 2 : Functionele en niet-functionele vereisten. Bestek CDFout! Verwijzingsbron niet gevonden. Fout! Verwijzingsbron niet gevonden

Recommend Documents