Representatieve manier van SLA % berekenen

[MisterEagle]

Momenteel ben ik bezig om verouderde maandrapportages te actualiseren. Hierbij loop ik tegen een kwestie aan waar ik zelf geen sluitend antwoord op kan vinden maar waar ik ook niet lekker over kan sparren op het werk vanwege de tegenstrijdige belangen. Daarom probeer ik het hier. (Hoop trouwens dat het topic op de juiste plek staat)

Het gaat om de volgende concrete vraag, hoe bereken ik representatief hoeveel % van de incidenten we oplossen binnen afgesproken (SLA) doorlooptijd?

Als voorbeeld de volgende gegevensset

	nov	dec	jan
aangemeld	1000	1000	1000
afgemeld binnen SLA	900	900	900
afgemeld buiten SLA	0	0	0
werkvoorraad	100	200	300

Eenvoudig gezegd zou ik zeggen dat van alle afgeronde incidenten je kijkt naar hoeveel je daarvan binnen de doorlooptijd hebt afgesloten en hoeveel je hebt afgesloten buiten de doorlooptijd. Hiermee kan je een percentage berekenen. In het voorbeeld hierboven heb je dus per maand 100% van je doorlooptijd gehaald van je afgesloten incidenten. Hiermee zie je echter niets over het feit dat je werkvoorraad per maand met 100 stuks groeit. Terwijl dit wel incidenten zijn die je vaak niet meer kunt halen en dan vind ik 100% rapporteren niet erg representatief.
Is dit op te lossen middels te rekenen? Of is het netter om gewoon een tweede waarde te rapporteren waarin bijvoorbeeld het percentage wordt aangegeven van openstaande werkvoorraad welke niet meer haalbaar is?

[Thekk]

Kan je niet simpel een rij bovenaan opnemen met 'Open aan begin van periode'? En de werkvoorraad is 'Open aan einde periode'

Afhankelijk van je servicetermijnen kan het best zijn dat events die aan het einde van de maand zijn aangemeld, nog best binnen de termijnen in de volgende maand af te ronden zijn.

[ Voor 42% gewijzigd door Thekk op 27-02-2020 15:15 ]

[MisterEagle]

Thekk schreef op donderdag 27 februari 2020 @ 15:14:
Kan je niet simpel een rij bovenaan opnemen met 'Open aan begin van periode'? En de werkvoorraad is 'Open aan einde periode'

Afhankelijk van je servicetermijnen kan het best zijn dat events die aan het einde van de maand zijn aangemeld, nog best binnen de termijnen in de volgende maand af te ronden zijn.

Dat is op te nemen en inderdaad wat je aangeeft is ook een van de uitdagingen. Eerst werd het berekend over alle afgesloten incidenten in die periode maar dat geeft geen goed beeld want de langste doorlooptijd is twee weken en daarmee kan je dus eenvoudig over naar de volgende periode.

Maar met het alleen berekenen over de daadwerkelijk afgesloten incidenten voelt dus heel dubbel omdat je daarmee, in het voorbeeld, 100% zou halen, terwijl je maar 90% van de incidenten oppakt.

[ Voor 12% gewijzigd door MisterEagle op 27-02-2020 15:18 ]

[Homerius]

Ik zou de openstaande incidenten opsplitsen naar degenen die nog 'binnen de SLA' af te melden zijn, en degenen die al 'buiten SLA' termijn vallen. Volgens mij ben je dan transparant.

De incidenten die buiten de SLA termijn vallen kun je dan verder toelichten indien nodig.

[Onbekend]

Stel dat je een SLA hebt van 5 dagen, en er wordt iets aangemeldt op 29 november. Deze zou in november afgemeldt kunnen worden (binnen SLA), maar ook in december (binnen of buiten SLA).
Maar incidenten die niet worden afgemeldt, komen nooit in jouw lijstje terecht.

Je zou moeten kijken naar het aantal incidenten die in die betreffende maand uit de SLA zijn verlopen, en het aantal dat binnen de SLA zijn beantwoordt. (Dit geeft de oplospercentage van helpdesk zelf aan.)
Het aantal incidenten die gerapporteerd zijn heeft daar verder niets mee te maken. Dat is alleen bruikbaar om te kijken naar de werkdruk op de helpdesk (i.c.m. de geldende SLA's).

[Devian]

Misschien zie ik het verkeerd, maar de enige manier om dit te doen is om per ticket te kijken of dat ticket wel of niet binnen SLA afgehandeld is..

Dus elke maand een uitdraai maken van alle tickets, aanmaakdata ticket + afmelddata ticket, etc...en dan een SLA rapportage maken gebasseerd op die data.

[Tom-Z]

Niet genoeg gegevens om iets zinnigs te kunnen zeggen.

Het zou bij wijze van spreken kunnen dat die 100 werkvoorraad die van november naar december worden overgedragen allemaal incidenten zijn die op 30 november zijn aangemeld en op 1 december zijn afgemeld. En vervolgens die 200 van december naar januari zijn aangemeld op 31 december en afgemeld op 1 januari. Dan haal je 100% SLA. Maar het zou net zo goed kunnen dat al die incidenten op de 1e van de maand zijn aangemeld en pas over een jaar zullen worden afgemeld. Dan heb je 90% SLA over alle maanden. Maar met dezelfde gegevens zou je ook 100% 100% 70% kunnen hebben. Of 90% 100% 80%.

Van alle incidenten zou je al lang moeten kunnen weten of ze nog op tijd afgehandeld zijn, want Januari is inmiddels al meer dan 2 weken geleden afgelopen. Je zou in principe gewoon moeten kunnen rapporteren welk percentage van de in maand X ingediende incidenten binnen de SLA is afgehandeld.

Of geef, zoals @Onbekend zegt, het aantal meldingen waarvan in die maand de SLA is verlopen (dat zijn dus meldingen uit de laatste twee weken van de vorige maand en de eerste twee van de eerste maand; eventueel als percentage van de in die periode totaal ingediende incidenten).

[MisterEagle]

wow, ineens gaan de reacties snel, dank jullie wel allemaal!

Het is voor mij mogelijk om de werkvoorraad aan het begin van de periode, welke nog binnen de SLA te halen is, te rapporteren.

Volgens mij zeggen jullie nu het volgende: rapporteren over afgesloten incidenten, hoeveel daarvan binnen SLA zijn opgelost (en automatisch dan ook hoeveel erbuiten)
Daarnaast toevoegen extra dimensie met betrekking tot werkvoorraad en daar een percentage aan hangen qua wel/niet haalbaal binnen SLA.

(Dit is overigens hoe ik het nu heb, echter halen we dan 90% van de incidenten wel op tijd, terwijl de werkvoorraad 50% al niet meer haalbaar is. Als ik rapporteer van die 90% is het management erg gelukkig maar dat beeld vind ik te rooskleurig. Vandaar dat ik opzoek ben naar een manier om dat mee te nemen in de oorspronkelijke berekening maar wellicht is dat inderdaad niet mogelijk)

edit:

Devian schreef op donderdag 27 februari 2020 @ 15:31:
Misschien zie ik het verkeerd, maar de enige manier om dit te doen is om per ticket te kijken of dat ticket wel of niet binnen SLA afgehandeld is..

Dus elke maand een uitdraai maken van alle tickets, aanmaakdata ticket + afmelddata ticket, etc...en dan een SLA rapportage maken gebasseerd op die data.

Gelukkig kan ik dat met de tooling eenvoudiger doen en totalen eruit trekken, alleen omdat rapportage per periode (maand) gewenst is, loop je inderdaad tegen zaken aan zoals @Tom-Z bijvoorbeeld aangeeft.

[ Voor 26% gewijzigd door MisterEagle op 27-02-2020 15:40 ]

[Tom-Z]

(Dit is overigens hoe ik het nu heb, echter halen we dan 90% van de incidenten wel op tijd, terwijl de werkvoorraad 50% al niet meer haalbaar is. Als ik rapporteer van die 90% is het management erg gelukkig maar dat beeld vind ik te rooskleurig. Vandaar dat ik opzoek ben naar een manier om dat mee te nemen in de oorspronkelijke berekening maar wellicht is dat inderdaad niet mogelijk)

Wat je ook kan doen is boven- en ondergrenzen geven. Reken uit wat je percentage zou zijn als je hele werkvoorraad morgen opgelost zou worden, en wat het percentage zou zijn als de werkvoorraad tot het einde der tijden blijft liggen. Rapporteer beide.

[ Voor 6% gewijzigd door Tom-Z op 27-02-2020 15:49 ]

[MisterEagle]

Tom-Z schreef op donderdag 27 februari 2020 @ 15:49:
[...]

Wat je ook kan doen is boven- en ondergrenzen geven. Reken uit wat je percentage zou zijn als je hele werkvoorraad morgen opgelost zou worden, en wat het percentage zou zijn als de werkvoorraad tot het einde der tijden blijft liggen. Rapporteer beide.

Daar ga ik even mee aan de slag inderdaad.

Net nog een brainfart, als ik weet van de openstaande incidenten hoeveel er niet meer te halen zijn in de SLA, kan ik dan dat percentage omdraaien en dan weet ik wat we potentieel wel halen.
Dat vervolgens bij het percentage tellen van incidenten afgesloten in doorlooptijd en dit delen door 2 voor het gemiddelde.

Of is dat dan weer te dirty?

[The Eagle]

Wat jij VINDT heeft niks te doen met een SLA. Een SLA is een afspreek. Die A staat niet voor niks voor Agreement. Je spreekt met elkaar af wat je gaat presteren, en daar rapporteer je op. Haal je iets niet dan heeft dat ongetwijfeld consequenties, maar daar gaat het niet om. Als je een afspraak maakt moet je je er aan houden, einde discussie.
Als jij zegt dat er een grotere werkvoorraad is, dan moet je bij je management aangeven dat dat het geval is en dat je met de zelfde hoeveelheid personeel meer werk moet doen, waardoor de SLA afspraken in het gedrang komen. En dan gebruik je juist die cijfers om dat aan te tonen. Niet om jezelf achter te verschuilen naar je klant toe.
Sowieso, als ik jouw manager zou zijn, zou ik verwachten dat je sinds het begin van de SLA de omgeving hebt leren kennen en dus sneller kunt reageren op indicenten, waardoor de oplostijd per incident korter wordt en je er dus meer aan kunt in de zelfde tijd. Kun je dat niet dan moet je dat aantonen met - jawel - je eigen cijfers.
Ergo: Ik zou er ook de werkvoorraad aan openstaande indicenten op peildatum bij zetten. En daarnaast het percentage van die incidenten dat in de periode geopend is, plus het percentage van die incidenten wat voor je rapportageperiode (geopend vorige periode, geopend eerder) geopend is. Dan kun je de tendens goed zien en inzichtelijk maken.

[MisterEagle]

The Eagle schreef op donderdag 27 februari 2020 @ 17:00:
Wat jij VINDT heeft niks te doen met een SLA. Een SLA is een afspreek. Die A staat niet voor niks voor Agreement. Je spreekt met elkaar af wat je gaat presteren, en daar rapporteer je op. Haal je iets niet dan heeft dat ongetwijfeld consequenties, maar daar gaat het niet om. Als je een afspraak maakt moet je je er aan houden, einde discussie.
Als jij zegt dat er een grotere werkvoorraad is, dan moet je bij je management aangeven dat dat het geval is en dat je met de zelfde hoeveelheid personeel meer werk moet doen, waardoor de SLA afspraken in het gedrang komen. En dan gebruik je juist die cijfers om dat aan te tonen. Niet om jezelf achter te verschuilen naar je klant toe.
Sowieso, als ik jouw manager zou zijn, zou ik verwachten dat je sinds het begin van de SLA de omgeving hebt leren kennen en dus sneller kunt reageren op indicenten, waardoor de oplostijd per incident korter wordt en je er dus meer aan kunt in de zelfde tijd. Kun je dat niet dan moet je dat aantonen met - jawel - je eigen cijfers.
Ergo: Ik zou er ook de werkvoorraad aan openstaande indicenten op peildatum bij zetten. En daarnaast het percentage van die incidenten dat in de periode geopend is, plus het percentage van die incidenten wat voor je rapportageperiode (geopend vorige periode, geopend eerder) geopend is. Dan kun je de tendens goed zien en inzichtelijk maken.

O maar daar ben ik het helemaal mee eens hoor, t probleem is alleen dat die bewuste manager alleen maar ziet dat we, zoals in 't voorbeeld, 100% van de SLA halen want alle incidenten die we afsluiten zijn binnen de doorlooptijd. (Zolang we alles wat we niet halen maar niet afsluiten)
en dat is juist waar ik mij druk over maak, in het verleden kwam mijn voorganger daar mee weg. Terwijl we juist niet in control zijn want de werkvoorraad neemt alleen maar toe, maar dat beseft met niet want we halen toch 100% van de SLA?

edit:
Ben nu inderdaad bezig om in het nieuwe rapport ook de werkvoorraad, zowel totalen als % wel/niet haalbaar mee te nemen. Waarbij mijn benadering is; we hebben afgesproken dat we minimaal 80% binnen SLA tijd oppakkenafhandelen. Dus sluitingspercentage moet minimaal 80% zijn en werkvoorraad mag nooit meer dan 20% niet meer haalbaar zijn.
Het idee om dit te kunnen combineren in één cijfer heb ik, voor nu, maar opgegeven omdat ik daar simpelweg de formule nog niet bij kan bedenken.

[ Voor 10% gewijzigd door MisterEagle op 27-02-2020 17:37 ]

[Orion84]

MisterEagle schreef op donderdag 27 februari 2020 @ 17:32:
[...]
O maar daar ben ik het helemaal mee eens hoor, t probleem is alleen dat die bewuste manager alleen maar ziet dat we, zoals in 't voorbeeld, 100% van de SLA halen want alle incidenten die we afsluiten zijn binnen de doorlooptijd. (Zolang we alles wat we niet halen maar niet afsluiten)
en dat is juist waar ik mij druk over maak, in het verleden kwam mijn voorganger daar mee weg. Terwijl we juist niet in control zijn want de werkvoorraad neemt alleen maar toe, maar dat beseft met niet want we halen toch 100% van de SLA?

Daar is een mooie term voor: watermelon reporting.

edit:
Ben nu inderdaad bezig om in het nieuwe rapport ook de werkvoorraad, zowel totalen als % wel/niet haalbaar mee te nemen. Waarbij mijn benadering is; we hebben afgesproken dat we minimaal 80% binnen SLA tijd oppakkenafhandelen. Dus sluitingspercentage moet minimaal 80% zijn en werkvoorraad mag nooit meer dan 20% niet meer haalbaar zijn.
Het idee om dit te kunnen combineren in één cijfer heb ik, voor nu, maar opgegeven omdat ik daar simpelweg de formule nog niet bij kan bedenken.

Het blijft lastig om dit echt lekker in een KPI te gieten inderdaad, heb zelf ook wel eens een vergelijkbare kwestie aan de hand gehad.

Je kan kijken naar SLA gehaald vs. SLA gemist (met daarin zowel gesloten buiten SLA als open voorbij SLA). Dan moet je alleen even kijken wat je precies doet met tickets die dus inderdaad de volgende maand doorlopen. Tel je die dan weer mee? En zo niet: hoe ga je dan om met tickets die aan het eind van een periode geopend zijn, maar pas de maand daarna de SLA overschrijden?
Edit: en ik bedenk me net dat SLA gehaald vs SLA gemist ook weer scheef kan zijn door tickets die nog open staan maar nog wel binnen SLA afgerond zouden kunnen worden.

[ Voor 4% gewijzigd door Orion84 op 27-02-2020 17:58 ]

[Bobo221]

Vervang "werkvoorraad" voor "pending" of "openstaand" en neem deze niet telkens mee naar de volgende maand maar ververs de data op de achtergrond in de maand waarin de ticket aangemaakt is.

[MisterEagle]

@Orion84 Thanks, die term kende ik nog niet, interessant!

@Bobo221 Ik zie dit niet zo goed voor me of ik snap je niet. Als SDMer heb ik de opdracht per maand te rapporteren, ik geloof niet dat de directie gelukkig wordt als ik telkens met terugwerkende kracht opnieuw rapporteer..

Zat net in de auto nog te denken om misschien iets te doen met totaal van openstaand begin periode plus aangemeld in die periode, en dat dan af te zetten tegen afgesloten in die periode.

Maargoed, zit nu in een restaurant en daarna een afspraak. Maar even proberen het los te laten :-)

[Arjan90]

Je kan best veel benaderingen hierop loslaten en uiteindelijk gaat het erom wat "Management" (en dat is dus niet alleen de manager, maar mogelijk ook directie) wil zien. "Window dressing" heeft niemand iets aan. Dit is ook altijd het nadeel van KPI's, zeker als het lopende zaken zijn met een langere SLA.

Een aantal varianten die mij in het hoofd springen:

• KPI benaderen als een maximaal te behalen resultaat: op de eerste van de daaropvolgende maand heb je x verzoeken in de werkvoorraad die of wel, of niet binnen SLA vallen. Daar kun je je maximaal te behalen resultaat op berekenen. Als alternatief zou je het rapport dan mogelijk ook een paar dagen later kunnen publiceren, dan weet je precies hoe de KPI is. Dit kan in de praktijk vaak alleen als het rapport dan binnen afzienbare tijd definitief gemaakt kan worden en dat IS uiteindelijk afhankelijk van duur van de SLA
• KPI benaderen als behaald in die maand: dus hoeveel verzoeken heb je in maand x verwerkt en hoeveel daarvan waren buiten SLA, dan neem je dus ook verzoeken uit voorgaande maanden mee die dan worden afgesloten.

Links- of rechtsom: des te actueler de data, des te beter je kan bijsturen als organisatie. Maandelijkse rapportages kun je dus ook maar maandelijks op bijsturen en resultaten van mogelijke verbeteringen zie je vaak pas twee maanden later (immers, de eerstvolgende maandrapportage gaat deels over een periode toen je de verbetering nog niet had doorgevoerd).

Zeker gezien je zorg zou ik inderdaad ook als getal opnemen wat de actuele werkvoorraad aan het einde van de periode is, mogelijk gesplitst in verzoeken van de gerapporteerde maand en in verzoeken van voorgaande maanden (verzameld). E.e.a. natuurlijk afhankelijk van hoelang de SLA loopt. Zo kun je zien welke achterstand er in de betreffende maand is ontstaan en of oude achterstand wel wordt ingelopen.

Staar je ook niet blind op alleen SLA en KPI's, het risico is dat managers naar hun stukje van het proces gaat kijken en daaruit concluderen dat ze het top doen. SLA en KPI zijn vooral handig als je ze over een geheel proces (end-2-end) meet en daartussen een aantal "thermometers" hebt staan over de performance van dat subproces. Zo kun je veel beter beoordelen hoe afdelingen en teams presteren over een geheel proces. En dat is vaak veel relevanter, want dan kun je kijken waar de flessenhals zit.

[Widow]

Met dit soort vragen moet je soms even uitzoomen en kijken wat de situatie is, en wat de vraag achter de vraag is. Ik hoor dat je een rapportage wilt aanpassen om beter te rapporteren over de toenemende werkvoorraad, en dat je de oplossing zoekt in het aantal incidenten dat binnen de SLA wordt opgelost. Maar zou het een idee zijn om iets over de werkvoorraad te rapporteren? En wat wil je dat het management gaat doen met die informatie, meer resources beschikbaar stellen in het team? Processen optimaliseren?

Soms worden KPI's als heilige graal gezien terwijl het maar een deel van het totale plaatje is. Meestal gaat het ongeveer zo:
-Je hebt werkprocessen, activiteiten die worden uitgevoerd.
-In die processen vinden transformaties plaats. Een aangemeld ticket wordt een ticket in behandeling etc.
-Vervolgens ga je kijken welke transformaties echt van belang zijn om over te rapporteren. Dit is een moeilijke stap omdat je moet nadenken wat echt van belang is, en hoe je een totaal beeld schetst.
-Voor de transformaties die echt van belang zijn, ga je drie dingen opstellen: het onderwerp dat je wilt meten, een maatstaf wát je wilt weten over het onderwerp, en een norm die beschrijft wat je wilt halen. Dus stel dat je iets gaat doen met de werkvoorraad. Je kan kijken naar de gemiddelde doorlooptijd van alle tickets, of naar de hoeveelheid tickets die nog open staan. En daar bedenk je een norm bij, waar je op richt.
-Vervolgens komt meten en sturen nog, dat verhaal laat ik even buiten beschouwing. Deze methode komt uit het boek "De cockpit van de organisatie" - kan interessant zijn als je er meer over wilt weten.

Het is dus de kunst om een zo volledig mogelijk beeld te vormen van wat er gebeurd in je proces. Als je alleen gaat meten hoeveel incidenten er opgelost worden en niet kijkt naar wat er voor de rest in je proces gebeurt, schets je een onvolledig beeld met de rapportage. Het is hetzelfde als meten dat een auto 100kmpu rijdt. Maar als je doel is om van Amsterdam naar Utrecht te rijden, is het ook fijn als je weet in welke richting de auto rijdt. Want als je richting het noorden rijdt, geeft je rapportage mooi 100kmpu aan, maar ga je nooit in Utrecht aankomen. En het kost ontzettend veel tijd en denkwerk om te bepalen wat er allemaal relevant is om te rapporteren.

Daarnaast kan je een rapportage nooit los zien van het te besturen proces. Dus je kan niet alleen op KPI's sturen zonder dat je weet wat er onder de motorkap gebeurt. Als je dat wel doet, weet je niet welk effect de sturing op het proces heeft. Ik doe dit soort dingen voor werk en je wilt niet weten hoeveel middelmanagement ik tegenkom die gewoon ergens een tooltje hebben met wat prestatie indicatoren en geen idee hebben waarom die indicatoren van belang zijn, of hoe ze hiermee kunnen sturen en gewoon maar wat roepen naar de medewerkers als het dashboard rood is. Ik had een tijdje terug een klant die een vergelijkbaar iets wou, alleen dat waren geen incidenten maar een agile team, met een vergelijkbare vraag. Een van de indicatoren daar was het formaat van het backlog gedeeld door het aantal personen beschikbaar. Als die waarde te laag is, stagneert het werk omdat er niet voldoende aanvoer van nieuw werk is, en heb je eigenlijk teveel capaciteit binnen een team. Is die waarde te hoog, is de doorlooptijd te hoog voor klanten, en heb je te weinig capaciteit in het team. Misschien kan je daar iets mee

[LankHoar]

Zoals @Orion84 al aangaf, kun je dit het beste opbreken in verschillende KPIs die tezamen aangeven of de SLA voldoende gehaald word. Hier wat inspiratie: http://kpilibrary.com/

Ik zou kijken naar:
- Gesloten in periode X; SLA met vs missed
- Geopend in periode X; SLA met vs missed/cannot be met anymore vs not yet met/missed (still open)
- Average closure time (e.g. 80% word gesloten binnen 25 dagen, de overige 20% gemiddeld in 35 dagen)
- Uitschieters naar boven; dit geeft je inzicht in wat er mis gaat
- Uitschieters naar beneden; dit geeft je inzicht in wat er juist erg goed gaat, en wellicht geautomatiseerd kan worden
- FCR kan ook interessant zijn
- Average handling time ook
- Etc.

Tezamen kun je dit in een maandelijkse scorecard verwerken die een beter inzicht geeft of de boel goed gaat of niet.

[ Voor 7% gewijzigd door LankHoar op 28-02-2020 12:56 ]

[MeltedForest]

Openstaande incidenten kan je toch gewoon splitsen in het deel wat nog binnen de SLA is of niet? En als je één percentage als benchmark wil moet je die pending incidenten buiten de SLA meetellen in de maand waarin die nog (steeds) open staat.

deze maand nieuw aangemeld : 1000
deze maand closed binnen SLA: 900
deze maand closed buiten SLA: 0
performance: 900 / 900 + 0 = 100%
------
deze maand pending binnen SLA: 100
deze maand pending buiten SLA: 200
performance incl pending: 900 closed binnen SLA / 900 closed binnen SLA + 0 closed buiten SLA + 200 pending buiten SLA = 81.8%

edit: langdurige openstaande incidenten tellen ook gewoon elke maand mee, niet alleen in de maand van melden

[ Voor 11% gewijzigd door MeltedForest op 28-02-2020 13:10 ]

[Onbekend]

MeltedForest schreef op vrijdag 28 februari 2020 @ 13:09:
edit: langdurige openstaande incidenten tellen ook gewoon elke maand mee, niet alleen in de maand van melden

Een reactietijd voor een SLA is per incident bepaald, en kan dus maar 1x verlopen. De vraag van de TS is de SLA % bereken, en niet een overzicht van een backlog te geven.

Het is inderdaad belangrijk om de langdurige incidenten op een gegeven moment op te pakken, maar als men alleen op de SLA wordt afgerekend worden alle incidenten die uit de SLA zijn gelopen gewoon genegeerd..... Hier zijn dus andere overzichten voor nodig.