Budgets, Allowance & Common Pool
Allowance gibt jeder Person eine periodische Gutschrift (täglich/wöchentlich/monatlich). Unverbrauchte Teile fließen in den Common Pool, aus dem Vielnutzer weiterarbeiten, sobald ihre Allowance aufgebraucht ist. So entsteht Fairness bei strengen Kostenobergrenzen.
Konzepte im Überblick
1. Persönliche Credits
Individuelle Credits, die einem Nutzer direkt zugeordnet sind:
- Werden manuell vom Admin vergeben
- Sind dauerhaft (verfallen nicht)
- Können negativ werden (Überziehung)
- Haben niedrigste Priorität beim Verbrauch
2. Allowance
Periodische Gutschrift, die automatisch erneuert wird:
- Automatisch: Wird zu festgelegten Zeiten gutgeschrieben
- Zeitgebunden: Verfällt am Ende der Periode (zurück zum Common Pool)
- Gleich für alle: Jeder im Projekt bekommt denselben Betrag
- Höchste Priorität: Wird zuerst verbraucht
3. Common Pool
Geteiltes Credit-Reservoir für das gesamte Projekt:
- Gemeinsam genutzt: Alle Projekt-Mitglieder haben Zugriff
- Nach Allowance: Wird genutzt, wenn Allowance aufgebraucht
- Vor persönlichen Credits: Schützt individuelle Reserven
- Dynamisch: Wächst durch Rückfluss ungenutzter Allowance
Verbrauchsreihenfolge
Anfrage von Nutzer Marie
│
├─→ Hat Marie Allowance?
│ ├─ Ja → Verbrauche von Allowance
│ └─ Nein/Aufgebraucht → Weiter zu ②
│
├─→ ② Hat Projekt Common Pool?
│ ├─ Ja & aktiviert → Verbrauche vom Common Pool
│ └─ Nein/Aufgebraucht → Weiter zu ③
│
└─→ ③ Hat Marie persönliche Credits?
├─ Ja → Verbrauche persönliche Credits
└─ Nein → ❌ Anfrage abgelehnt (keine Credits)Warum diese Reihenfolge?
- Allowance zuerst: Fördert regelmäßige, gleichmäßige Nutzung
- Common Pool danach: Bietet Flexibilität für Vielnutzer
- Persönliche Credits zuletzt: Schützt individuelle Reserven
Beispiel-Szenarien
Szenario 1: Standard-Nutzung
Setup:
Projekt: Schüler
Allowance: 100 Credits/Monat
Common Pool: 5.000 CreditsNutzer Marie:
Persönliche Credits: 50
Allowance (Monat): 100
Common Pool (geteilt): 5.000
Effektive Credits: 100 (Allowance) + 5.000 (Pool) + 50 (persönlich) = 5.150Nutzung im Monat:
Woche 1: 25 Credits → von Allowance (75 übrig)
Woche 2: 30 Credits → von Allowance (45 übrig)
Woche 3: 40 Credits → von Allowance (5 übrig)
Woche 4: 10 Credits → 5 von Allowance + 5 vom Common Pool
Monatsende:
- Allowance verbraucht: 100
- Common Pool verbraucht: 5
- Persönliche Credits: 50 (unberührt)Szenario 2: Vielnutzer
Nutzer Paul (nutzt intensiv):
Persönliche Credits: 20
Allowance (Monat): 100
Common Pool (geteilt): 5.000Nutzung im Monat:
Woche 1: 50 Credits → von Allowance (50 übrig)
Woche 2: 50 Credits → von Allowance (0 übrig)
Woche 3: 100 Credits → vom Common Pool (4.900 übrig im Pool)
Woche 4: 150 Credits → vom Common Pool (4.750 übrig im Pool)
Monatsende:
- Allowance verbraucht: 100
- Common Pool verbraucht: 250
- Persönliche Credits: 20 (unberührt)Szenario 3: Wenignutzer
Nutzer Lisa (nutzt wenig):
Persönliche Credits: 100
Allowance (Monat): 100
Common Pool (geteilt): 5.000Nutzung im Monat:
Woche 1: 10 Credits → von Allowance (90 übrig)
Woche 2: 15 Credits → von Allowance (75 übrig)
Woche 3: 5 Credits → von Allowance (70 übrig)
Woche 4: 0 Credits → nichts (70 übrig)
Monatsende (bei Settlement):
- Allowance verbraucht: 30
- Ungenutzt: 70 → fließt zurück zum Common Pool
- Common Pool neu: 5.070 Credits
- Persönliche Credits: 100 (unberührt)Settlement-Prozess
Settlement ist der Prozess am Ende einer Allowance-Periode:
Phase 1: Einsammeln
Ungenutzte Allowance wird von allen Nutzern eingesammelt:
Projekt: Schüler (200 Nutzer)
Allowance: 100 Credits/Monat
Settlement am 1. November:
───────────────────────────────────────
Nutzer A: 100 - 70 = 30 zurück
Nutzer B: 100 - 100 = 0 zurück
Nutzer C: 100 - 45 = 55 zurück
... (197 weitere Nutzer)
───────────────────────────────────────
Gesamt eingesammelt: 8.500 CreditsPhase 2: Zum Common Pool hinzufügen
Eingesammelte Credits fließen in den Common Pool:
Common Pool vorher: 5.000 Credits
Rückfluss: 8.500 Credits
Common Pool nachher: 13.500 CreditsPhase 3: Neue Allowance verteilen
Alle Nutzer erhalten frische Allowance:
Alle 200 Nutzer erhalten wieder: 100 Credits Allowance
Gesamt verteilt: 20.000 CreditsPhase 4: Budget-Abzug
Vom Projekt-Budget wird die neue Allowance abgezogen:
Projekt-Budget vorher: 50.000 Credits
Allowance-Kosten: 20.000 Credits
Projekt-Budget nachher: 30.000 CreditsMathematische Modelle
Modell 1: Basis-Kalkulation
Gegeben:
- Nutzer: N
- Allowance: A
- Nutzungsfaktor: f (0.0 - 1.0)
Berechnung:
Bedarf pro Periode = N × A × f
Common Pool (empfohlen) = Bedarf × 0.25
Beispiel:
N = 200, A = 100, f = 0.7
Bedarf = 200 × 100 × 0.7 = 14.000 Credits
Common Pool = 14.000 × 0.25 = 3.500 CreditsModell 2: Budget-Laufzeit
Gegeben:
- Budget: B
- Periodenbedarf: P
- Common Pool: C
Berechnung:
Laufzeit (Perioden) = (B + C) / P
Beispiel:
B = 50.000, P = 14.000, C = 3.500
Laufzeit = (50.000 + 3.500) / 14.000 = 3.82 PeriodenModell 3: Rückfluss-Prognose
Gegeben:
- Nutzer: N
- Allowance: A
- Durchschnittliche Nutzung: u
Berechnung:
Rückfluss = N × (A - u)
Beispiel:
N = 200, A = 100, u = 65
Rückfluss = 200 × (100 - 65) = 7.000 CreditsOptimierungs-Strategien
Strategie 1: Progressive Allowance
Unterschiedliche Allowance je nach Nutzergruppe:
Projekt: Schüler 5-7 (Unterstufe)
Allowance: 50 Credits/Monat
Begründung: Geringere Nutzung, einfachere Aufgaben
Projekt: Schüler 8-10 (Mittelstufe)
Allowance: 75 Credits/Monat
Begründung: Moderate Nutzung
Projekt: Schüler 11-13 (Oberstufe)
Allowance: 100 Credits/Monat
Begründung: Intensive Nutzung, komplexe AufgabenStrategie 2: Dynamischer Common Pool
Common Pool wächst mit der Zeit:
Monat 1:
Start: 5.000 Credits
Rückfluss: 7.000 Credits
Ende: 12.000 Credits
Monat 2:
Start: 12.000 Credits
Rückfluss: 6.500 Credits
Ende: 18.500 Credits
→ Pool wird immer größer (sofern nicht vollständig verbraucht)Strategie 3: Saisonale Anpassungen
Allowance an Schuljahr/Geschäftsjahr anpassen:
September - Dezember: 100 Credits/Monat (Hochsaison)
Januar - März: 80 Credits/Monat (Klausurphase)
April - Juli: 60 Credits/Monat (Auslaufen)
August: 30 Credits/Monat (Ferien)Fairness vs. Flexibilität
Hohe Fairness (Strikt)
Konfiguration:
Allowance: Niedrig (50)
Common Pool: Klein (2.000)
Persönliche Credits: Niedrig (20)Eigenschaften:
- ✅ Gleichmäßige Verteilung
- ✅ Strenge Kosten-Kontrolle
- ❌ Wenig Flexibilität für Vielnutzer
- ❌ Frustration bei intensiver Nutzung
Hohe Flexibilität (Großzügig)
Konfiguration:
Allowance: Hoch (200)
Common Pool: Groß (10.000)
Persönliche Credits: Hoch (100)Eigenschaften:
- ✅ Viel Spielraum für alle
- ✅ Keine "Out of Credits"-Probleme
- ❌ Höhere Kosten
- ❌ Ungleiche Verteilung (Vielnutzer konsumieren mehr)
Ausgewogen (Empfohlen)
Konfiguration:
Allowance: Moderat (100)
Common Pool: Mittel (5.000, ~25% Bedarf)
Persönliche Credits: Reserve (50)Eigenschaften:
- ✅ Balance zwischen Fairness und Flexibilität
- ✅ Kosten-Kontrolle mit Puffer
- ✅ Wenignutzer unterstützen Vielnutzer (via Pool-Rückfluss)
- ✅ Persönliche Credits als Sicherheitsnetz
Monitoring & Reporting
Wichtige Metriken
Projekt-Ebene:
- Budget-Verbrauch gesamt
- Common Pool Stand
- Durchschnittliche Allowance-Nutzung
- Rückfluss-Rate (Settlement)
- Anzahl Nutzer mit 0 CreditsNutzer-Ebene:
- Allowance-Nutzung (%)
- Common Pool Nutzung (Credits)
- Persönliche Credits Stand
- Häufigkeit "Out of Credits"Alarme einrichten
⚠️ Warnung: Common Pool < 20%
→ Nachfüllen erwägen
⚠️ Warnung: 10+ Nutzer mit 0 Credits
→ Allowance erhöhen?
🚨 Kritisch: Budget < 1 Periode
→ Dringend nachfüllen!
🚨 Kritisch: Common Pool leer
→ Viele Nutzer blockiert!Best Practices Zusammenfassung
Allowance = Regelmäßige Basis-Nutzung
- 70-80% der durchschnittlichen Nutzung
Common Pool = 20-30% des Periodenbedarfs
- Puffer für Spitzen und Vielnutzer
Persönliche Credits = Reserve
- Für außergewöhnliche Fälle
Settlement beobachten
- Rückfluss-Rate zeigt Optimierungspotenzial
Regelmäßig anpassen
- Mindestens quartalsweise überprüfen
Nächste Schritte
Mehr Details zu spezifischen Themen:
- Projekte - Projekt-Setup und -Verwaltung
- Nutzer - Nutzer-Credits verwalten
- Usage - Verbrauch analysieren
- Maintenance - Regelmäßige Wartungsaufgaben