Resources en capaciteitsplanning
Wat zijn resources?
In proces simulaties stellen resources alles voor met beperkte capaciteit waar activiteiten om concurreren. Resources zorgen voor realistische bottlenecks, wachtrijen en wachttijden in je simulatie.
Veelvoorkomende resource types
| Categorie | Voorbeelden |
|---|---|
| People | Customer service agents, loan officers, managers, specialisten |
| Equipment | Machines, werkplekken, testapparatuur |
| Systems | Softwarelicenties, servercapaciteit, API rate limits |
| Facilities | Vergaderruimtes, productielijnen, inspectiestations |
Waarom resources modelleren?
Zonder resourcebeperkingen gaat simulatie uit van onbeperkte capacity, elke case wordt direct verwerkt zonder wachttijd. Dat is niet realistisch.
Resourcemodellering maakt het mogelijk:
- Bottlenecks realistisch te vinden
- Wachttijden goed te voorspellen
- Capacity planning en what-if analyses uit te voeren
- Resource utilization patronen te begrijpen
Resource pools
Resources in ProcessMind zijn georganiseerd in pools van uitwisselbare units.
Pool eigenschappen
| Eigenschap | Beschrijving |
|---|---|
| Name | Naam van de resource (bv. “Approval Staff”, “Loan Processor”) |
| Capacity | Aantal beschikbare units in de pool |
Inzicht in Capacity
Capacity bepaalt hoeveel activities een resource tegelijk kan gebruiken:
- Capacity = 1: Eén case tegelijk mogelijk
- Capacity = 5: Tot 5 cases gelijktijdig mogelijk
Voorbeeld: Als je approval afdeling 3 medewerkers heeft die elk één approval tegelijk doen, stel capacity dan op 3.
Resources toewijzen aan activiteiten
Elke activiteit in je proces kan aangeven welke resources nodig zijn:
Toewijzingseigenschappen
| Instelling | Beschrijving |
|---|---|
| Resource Pool | Uit welke resource pool wordt geput |
| Quantity | Hoeveel units van die resource nodig |
Simpele toewijzing
De meeste activiteiten hebben één unit van één resource nodig:
- Activiteit: “Review Application”
- Resource: “Loan Officers” (aantal: 1)
Multi-unit toewijzing
Sommige activiteiten vragen meerdere units:
- Activiteit: “Major Decision Committee”
- Resource: “Senior Managers” (aantal: 3)
Resource allocatie: Hoe cases resources krijgen
Wanneer een case een activiteit bereikt die resources vereist, volgt de simulatie dit proces:
Het Allocation Flow
- Controleer beschikbaarheid: Zijn de benodigde resources beschikbaar?
- In de wachtrij als nodig: Niet beschikbaar? Dan komt de case in de wachtrij
- Wachten: De case wacht tot resources vrijkomen
- Toewijzen: Zodra resources beschikbaar zijn, worden ze gereserveerd voor deze case
- Uitvoeren: De activity wordt uitgevoerd voor de sampleduur
- Vrijgeven: Na afronden komen de resources weer beschikbaar in de pool
Wachtgedrag en wachtrijstrategie
ProcessMind ondersteunt meerdere queue strategies om te bepalen hoe cases prioriteit krijgen als resources vrijkomen:
| Strategie | Beschrijving |
|---|---|
| FIFO | First In, First Out, cases volgen volgorde van aankomst (standaard) |
| LIFO | Last In, First Out, nieuwste cases eerst |
| Random | Cases willekeurig uit de wachtrij gekozen |
Je stelt de wachtrijstrategie per activiteit in bij de elementinstellingen.
Kiezen van een wachtrijstrategie
FIFO is het meest gebruikelijk en eerlijk. Gebruik LIFO voor urgente escalaties. Random is handig om onvoorspelbare diensten te simuleren.
Wat gebeurt er als resources niet beschikbaar zijn?
Als resources bezet zijn:
- De case gaat in de wachtrij van die resource
- De case wacht (simulatietijd verstrijkt)
- Zodra een resource vrijkomt, wordt een wachtende case gekozen met de queue strategy
- De activity start daarna
Deze wachtrij zorgt voor realistische wachttijden in je simulatie.
Resource beschikbaarheid met periodiciteit
Resources zijn niet altijd in gelijke capaciteit beschikbaar. Gebruik periodiciteit om variabele beschikbaarheid te modelleren.
Voorbeeld: Openingstijden
| Periodiciteit | Capaciteit |
|---|---|
| Elke werkdag 09:00-17:00 | 5 agents |
| Elke werkdag 17:00-21:00 | 2 agents |
| Elk weekend 10:00-16:00 | 1 agent |
| Standaard | 0 agents |
Voorbeeld: Shiftrooster
| Periodiciteit | Capaciteit |
|---|---|
| Elke dag 06:00-14:00 (ochtend) | 5 operators |
| Elke dag 14:00-22:00 (avond) | 3 operators |
| Elke dag 22:00-06:00 (nacht) | 1 operator |
Voorbeeld: Seizoensvariatie
| Periodiciteit | Capaciteit |
|---|---|
| Elk jaar 15 nov - 31 dec (piek) | 20 medewerkers |
| Standaard | 12 medewerkers |
Resource utilization begrijpen
Utilization meet hoe druk jouw resources zijn:
Utilization = (Tijd bezig ÷ Totaal beschikbaar) × 100%
Utilization interpreteren
| Utilization niveau | Betekenis |
|---|---|
| Onder 50% | Onderbenut, waarschijnlijk teveel capaciteit |
| 50-70% | Gezonde balans, voldoende ruimte voor variatie |
| 70-85% | Druk, beperkte slack bij pieken |
| 85-95% | Hoge utilization, waarschijnlijk vertragingen |
| Boven 95% | Bottleneck, wachtrijen ontstaan |
De Utilization Trap
Don't Target 100% Utilization
Hoge utilization lijkt efficiënt, maar zorgt voor problemen. Zelfs kleine schommelingen in de vraag zorgen bij 100% utilization voor snel groeiende wachtrijen. Streef naar 70-80% voor stabiele, flexibele processen.
Waarom hoge utilization leidt tot lange wachtrijen
Een simpel voorbeeld:
- Resource capaciteit: 1
- Gemiddelde verwerkingstijd: 10 minuten
- 5,5 cases per uur (55% utilization): wachtrijen zijn te overzien
- 5,9 cases per uur (98% utilization): wachttijden lopen snel op
Bij bijna 100% utilization zorgen kleine schommelingen gelijk voor snel groeiende wachtrijen.
Gedeelde resources
Eén resource pool kan meerdere activiteiten bedienen. Dit is gebruikelijk en realistisch:
Gedeelde resources instellen
- Maak een resource pool aan (bv. “Customer Service Team”)
- Koppel dezelfde pool aan meerdere activiteiten
- Activiteiten concurreren om de gedeelde capaciteit
Voorbeeld: Gedeeld personeel
Het “Customer Service Team” (capaciteit: 5) behandelt:
- “Answer Phone Inquiry”
- “Process Email Request”
- “Handle Chat Support”
Alle drie activiteiten gebruiken dezelfde pool. Zijn er 4 telefoongesprekken? Dan is er nog 1 agent voor mail of chat.
Voordelen van gedeelde resources
- Modelleert cross-getrainde, flexibele teams
- Laat competitie zien tussen verschillende soorten werk
- Toont welke activiteit het meeste resourcegebruik heeft
Multi-resource activiteiten
Sommige activiteiten vereisen tegelijk verschillende resources:
Voorbeeld: Design review meeting
| Resource Pool | Benodigd aantal |
|---|---|
| Senior Designer | 2 |
| Meeting Room | 1 |
| Design Lead | 1 |
Let op: De activiteit kan pas starten als alle benodigde resources tegelijk beschikbaar zijn. Zijn er wel designers maar geen meeting room? Dan wacht je case.
Overwegingen bij multi-resource
- Kan complexe wachtpatronen opleveren
- Let op activiteiten die meerdere resource types blokkeren
- Kijk of alle resources echt tegelijk nodig zijn
Capaciteitsplanning met simulatie
Eén van de belangrijkste toepassingen van resource simulatie is capaciteitsplanning.
Belangrijke vragen beantwoord door simulatie
Hoeveel resources heb ik nodig?
Simuleer met verschillende capaciteit:
| Capaciteit | Gemiddelde wachttijd | Utilization | Throughput |
|---|---|---|---|
| 2 medewerkers | 45 min | 95% | 150/week |
| 3 medewerkers | 12 min | 78% | 150/week |
| 4 medewerkers | 3 min | 58% | 150/week |
Inzicht: De derde medewerker verkort wachttijden sterk. De vierde geeft weinig extra voordeel.
Waar zitten mijn bottlenecks?
Vergelijk utilization over alle resources:
| Resource | Utilization |
|---|---|
| Front Desk | 65% |
| Underwriters | 92% |
| Legal Review | 48% |
| Closing Team | 71% |
Inzicht: Underwriters zijn de bottleneck. Meer baliepersoneel helpt niet; het werk stapelt zich sneller bij onderwriting op.
Wat als de vraag stijgt?
Simuleer hogere instroom:
| Vraag | Huidig team | Groei wachtrij |
|---|---|---|
| Huidig | 5 | Stabiel |
| +20% | 5 | Groeit langzaam |
| +50% | 5 | Niet houdbaar |
Inzicht: Huidige capaciteit kan circa 20% groei aan. Daarna zijn extra resources nodig.
Best practices voor resource modelling
Begin simpel
Gebruik eerst enkele resources die echt knelpunten zijn:
- Modelleer niet iedereen apart
- Groepeer uitwisselbaren in pools
- Voeg detail toe waar het iets oplevert
Gebruik real data
Bepaal capacity op basis van de werkelijke bezetting:
- Actueel aantal FTE
- Werkuren en roosters
- Historische beschikbaarheid (inclusief vakantie, ziekte)
Slack inbouwen
Resources zijn niet 100% beschikbaar:
- Medewerkers nemen pauzes
- Machines hebben onderhoud nodig
- Onverwachte afwezigheid komt voor
Modelleer realistische beschikbare tijd, niet het theoretisch maximum.
Valideren met de praktijk
Vergelijk de gesimuleerde utilization met de werkelijke situatie:
- Komen de wachtrijen overeen met de echte wachttijden?
- Ligt de simulatie-throughput dicht bij de werkelijke throughput?
- Komt resource utilization realistisch over?
Pas zo nodig je resource model aan.
Houd rekening met het menselijke aspect
Onthoud dat mensen geen machines zijn:
- Productiviteit verschilt per dagdeel
- Langdurige hoge bezetting kan burn-out of fouten geven
- Cross-training kent grenzen