Achtergrond opdracht
We zijn op zoek naar iemand die in de samenwerkruimte op basis van de standaard in SharePoint 2019 aanwezige functionaliteiten een systeem kan bouwen/configureren voor het doen van piketmeldingen (Gemeenschappelijk Gebeurtenissen en Incidenten Beeld, afkorting GGIB). De gewenste functionaliteiten van het GGIB-systeem (eSWF) zijn bepaald aan de hand van het herijkte incidentenprotocol DGM:
– Toevoegen/ verwijderen collega’s vanuit de keten (met verschillende rechten: alleen lezen, meeschrijven, enz.). Lijst van deelnemers + autorisaties moet uitgedraaid kunnen worden. Toegang voor de volgende partijen: COA, DJI, DT&V, KMar, Ketenmariniers, IND, Inspectie JenV, Politie en DGM. En mogelijkheid tot uitbreiden. Eventueel dus gemeenten als we iets willen met meldingen vanuit OEK/ NOO. Zeer waarschijnlijk zullen dit uiteindelijk veel deelnemers zijn en mede daarom is het wenselijk dat dit onderdeel gebruikersvriendelijk is. Mijn ervaring vanuit de oude eSWF was dit zeer bewerkelijk. (Voorbeeld: Een persoon moest verwijderd worden en in een apart veld moesten daar ook de automatische mailmeldingen worden uitgezet. Als dit werd vergeten ontving deze persoon automatisch alle piketmeldingen. Risico dus op een datalek)
– In het herijkte protocol willen we eigenlijk dat er drie berichten worden verstuurd. Hier is het van belang dat er eerst een stap is voor de ketenpartners om een melding aan te vullen. Het is namelijk een ketenproces. Het zou bijvoorbeeld een oplossing kunnen zijn om met verschillende velden te werken. Echter zou er wel een tussenstap moeten zijn. Nu doet COA een melding en automatisch ontvangt iedereen deze melding. Dit is niet wenselijk. Bij het aanmaken van de melding selecteren wie de melding moet ontvangen en met welk doel (bijv. COA doet melding, maar er ontbreekt info vanuit IND. IND ontvangt melding met verzoek informatie aan te vullen).
1. Piketmelding naar dossierhouders uit de keten en piketfunctionaris met V-nummer, nationaliteit en de mogelijkheid voor de dossierhouders het bericht aan te vullen. (Voorbeeld: COA doet melding, IND vult verblijfsrechtelijke status aan en DT&V vult terugkeerinformatie aan. Dit complete bericht wordt een piketmelding. Tevens kan het zijn dat er bij een ernstig incident met veel impact wordt besloten om een incidenttafel in te richten).
2. Complete piketmelding (kan pas na punt 1) naar dDRM/DGM/ SJenV en dossierhouders DGM met nationaliteit en zonder V-nummer.
3. Complete piketmelding (kan pas na punt 1) naar de keten (managers, directeuren, enz.) zonder nationaliteit (nog even in overleg) en zonder V-nummer.
– Rapportages uitdraaien: maandelijks gaan we de incidenten openbaar maken en het is daarom wenselijk om maandelijkse rapportages te kunnen uitdraaien op een aantal onderdelen. Tevens is er ook de wens om lessen te kunnen trekken uit de incidenten die we ontvangen. Het zou daarom fijn zijn als er op verschillende onderdelen een selectie gemaakt kan worden voor een uitdraai. Rapportage voor extern gebruik (publicatie)/rapportage voor intern gebruik op categorie niveau/locatie niveau/organisatie niveau etc.
– Het systeem moet gebruikersvriendelijk zijn. Dit klinkt als een algemene opmerking maar dit is een prangende vraag geweest uit de werkgroep. Verschillende ketenpartners moeten werken in het systeem en het is tevens wenselijk dat dit met enige snelheid kan. Het verzoek dus om dit overzichtelijk te houden en eenduidige manier om een bericht op te maken. Door te werken met vaste velden en verschillende autorisatieniveau’s
– Kan het GGIB systeem op de Ipad/ telefoon worden gebruikt. Dit zou wel onze voorkeur hebben. De piketfunctionaris (als we akkoord zijn met bovenstaande) moet dan ook in het systeem een handeling uitvoeren. De piketdienst van DGM is 24/7 bereikbaar en moet kunnen werken in het systeem. Mocht dit niet het geval zijn dan moeten we hier goed opletten dit heeft namelijk effect op de bereikbaarheidsvergoeding van de piketfunctionaris. (wel/ niet plaatsgebonden beschikbaar zijn).
– Naar aanleiding van het protocol moeten er duidelijke omschrijving zijn van een melding, en mogelijkheid om controlevragen op te nemen zodat het bericht compleet is. (We willen bijvoorbeeld weten: soort incident op hoofdlijnen, locatie, betrokken organisaties, getroffen maatregels, nog aan te vullen informatie enz.). Op dit onderdeel zou het tevens fijn zijn als dit redelijk flexibel is aan te passen. We denken dat het protocol het komende jaar een aantal keer verscherpt zal worden. Triage (zie bijlage) moet op een bepaalde manier terugkomen in manier van registreren. + check: melding compleet ja/nee; dDRM geïnformeerd: ja/nee;
Werkzaamheden
Een verschil in afgehandelde meldingen en openstaande meldingen. Openstaande meldingen (zoals hongerstakingen) zijn meldingen die soms een half jaar kunnen openstaan maar is van belang dat daar aanvullende informatie op kan blijven komen. Denk hierbij aan de zaak Dolmatov (en tevens reden waarom dit een ketenproces is). Op dit moment is er 1 veld in eSWF met alle berichten. Niet geheel overzichtelijk. Bijvoorbeeld status melding: open/gesloten/open + direct actie vereist: ja/nee
– Het is wenselijk om met verschillende velden te werken die we kunnen aanpassen. Om type incidenten te categoriseren en later nog categorieën toe te voegen. Voorbeeld:
1. Meldingsinformatie
1a. Datum melding
1b. Datum incident
1c. Locatie incident
1d. COA locatie
1e. Soort incident
1f. Media aandacht?
1g. Gemeld aan bewindspersoon?
2. Persoonsgegevens
2a. Nationaliteit
2b. V-nummer
2c. Verblijfstatus
2d. Leeftijd
3. Berichten
3a. Bericht melding
3b. Bericht DL
3c. Openbaar maken?
3d. Bericht Stas
3e. Bericht Publicatie
‘nice to have’
– Eventueel dashboard functie toevoegen en/of verschillende weergave functies obv autorisatieniveaus. Aan het einde van de opdracht zal er ook documentatie opgeleverd moeten worden ten behoeve van het beheren van het systeem.
Functie eisen
- De kandidaat heeft een afgeronde opleiding van minimaal HBO niveau
- De kandidaat heeft minimaal 3 jaar ervaring als Sharepoint ontwikkelaar
