Bedarf
Abhängigkeiten · Data Nodes
- Bezüge zu: KI Agenten (über
REQUESTS_MEMBER), Kostenstellen (überORIGINATES_FROM), OKRs (überORIGINATES_FROM), Personen (überREQUESTS_MEMBER), Wertschöpfung (überORIGINATES_FROM), Projekte (überORIGINATES_FROM), Rollen (überORIGINATES_FROM,REQUIRES_ROLE)- Wird bezogen von: Kompetenzen (über
REQUIRES)
Ein Bedarf spricht aus, was gebraucht wird: wie viel Kapazität, in welchem Zeitraum, für welche Tätigkeiten und mit welchem Können. Er ist der Ausgangspunkt der Planung — siehe Bedarf & Ressourcenplanung.
Bedarfe machen sichtbar, was ein Ziel, ein Projekt oder ein laufender Wertstrom an Menschen (und KI-Agenten) tatsächlich verlangt. Ohne sie existiert nur eine Plan-Zahl gegen ein Bezugsobjekt — und niemand kann sagen, ob sie gedeckt ist.
Ein Bedarf ist bewusst homogen: eine Anforderung, eine Menge, ein Profil. Braucht ein Projekt Backend und UX, sind das zwei Bedarfe an derselben Quelle. Das hält das Modell einfach und macht Teil-Deckung ausdrückbar.
Standardansicht
Abschnitt betitelt „Standardansicht“Die Listenansicht zeigt die Bedarfe des Mandanten. Über die Detailseite kommst du an das Anforderungsprofil (Beziehungen) und an die Karte Deckung.
Einen Bedarf anlegen
Abschnitt betitelt „Einen Bedarf anlegen“Sidebar „Bedarfe” → Schaltfläche „Neuer Bedarf” oben rechts → Dialog „Neuen Bedarf erstellen”.
Im Dialog stehen oben die allgemeinen Felder (Mandant, Bezeichnung, Customer ID, Klassifizierung), darunter unter „Bedarfsdaten” das Formular aus dem Schema des Entitätstyps. Die Art entscheidet, was Pflicht ist:
| Art | Pflichtfelder | Enddatum |
|---|---|---|
| Vorhaben (Projekt, OKR) | Gesamtbedarf (h), Gültig ab, Gültig bis | Pflicht — ein Vorhaben endet |
| Laufender Betrieb (Wertstrom, Rolle) | Bedarf je Periode (h), Gültig ab | optional — Betrieb endet nicht |
Das jeweils andere Mengenfeld wird ausgeblendet und ist dann auch nicht Pflicht. Eine Bezeichnung ist nicht zwingend, hilft aber beim Wiederfinden im Arbeitsvorrat.
Gespeichert wird über „Als Entwurf speichern” oder „Speichern & Veröffentlichen” — wie jede Änderung läuft auch ein neuer Bedarf durch den [[drafts-overview|Entwurfs- und Freigabeweg]] des Mandanten.
Die Beziehungen (woraus der Bedarf entsteht, welche Rolle und welche Kompetenzen er
verlangt) setzt du nach dem Anlegen auf der Detailseite — nicht im Dialog. Ein Bedarf
ohne ORIGINATES_FROM ist gültig, aber ohne Quelle schwer einzuordnen.
Denk an den Zuschnitt: ein Bedarf = eine homogene Anforderung. Lieber zwei Bedarfe an derselben Quelle als einen, der zwei Profile vermischt.
Kein Menüpunkt „Bedarfe”? Dann führt der Mandant keinen Entitätstyp mit dem Modul
demand— siehe Entitätstypen. Auch der Cockpit-Eintrag „Ressourcenplanung” hängt daran.
Wichtige Beziehungen
Abschnitt betitelt „Wichtige Beziehungen“- ORIGINATES_FROM (Bedarf → Wertstrom/Rolle/OKR/Projekt/Kostenstelle) — woraus der Bedarf entsteht. Wertstrom und Rolle tragen den laufenden Betrieb, OKR und Projekt die Vorhaben.
- REQUIRES_ROLE (Bedarf → Rolle) — die Tätigkeitsachse: die Rolle bündelt, was zu tun ist.
- REQUIRES (Bedarf → Kompetenz, mit Stufe) — die Könnensachse.
- REQUESTS_MEMBER (Bedarf → Person/KI-Agent) — ein namentlicher Wunsch, keine Zuweisung.
Details: Beziehungstypen.
Beispiel-Schema zum Kopieren
Abschnitt betitelt „Beispiel-Schema zum Kopieren“{ "type": "object", "properties": { "demandKind": { "type": "string", "title": "Art", "enum": ["run", "change"], "default": "change" }, "demandedHours": { "type": "number", "title": "Gesamtbedarf (h)", "minimum": 0, "showWhen": { "field": "demandKind", "values": ["change"] } }, "hoursPerPeriod": { "type": "number", "title": "Bedarf je Periode (h)", "minimum": 0, "showWhen": { "field": "demandKind", "values": ["run"] } }, "activities": { "type": "array", "items": { "type": "string" }, "title": "Tätigkeiten" }, "startDate": { "type": "string", "title": "Gültig ab", "format": "date" }, "endDate": { "type": "string", "title": "Gültig bis", "format": "date" }, "granularity": { "type": "string", "title": "Periodenraster", "enum": ["month", "quarter"], "default": "month" }, "distribution": { "type": "string", "title": "Verteilung", "enum": ["even", "frontloaded", "backloaded"], "default": "even", "showWhen": { "field": "demandKind", "values": ["change"] } }, "memberKind": { "type": "string", "title": "Wer darf decken", "enum": ["any", "human", "agent"], "default": "any" }, "demandStatus": { "type": "string", "title": "Status", "enum": ["open", "planned", "closed", "cancelled"], "default": "open" }, "priority": { "type": "string", "title": "Priorität", "enum": ["low", "medium", "high", "critical"] }, "description": { "type": "string", "title": "Beschreibung" } }, "required": ["demandKind", "startDate"], "allOf": [ { "if": { "properties": { "demandKind": { "const": "change" } } }, "then": { "required": ["demandedHours", "endDate"] } }, { "if": { "properties": { "demandKind": { "const": "run" } } }, "then": { "required": ["hoursPerPeriod"] } } ]}Zwei Besonderheiten dieses Schemas:
allOfmitif/thenmacht die Pflicht abhängig von der Art: ein Vorhaben braucht Gesamtmenge und Enddatum, der laufende Betrieb die Menge je Periode. Siehe JSON-Schema für Entitätstypen.showWhenblendet das jeweils andere Mengenfeld aus. Ein ausgeblendetes Feld ist nie Pflicht — nur deshalb entsteht aus der Kombination keine Sackgasse.
Status ist nicht Deckung
Abschnitt betitelt „Status ist nicht Deckung“demandStatus beschreibt den Lebenszyklus (offen, geplant, abgeschlossen, verworfen).
Ob ein Bedarf gedeckt ist, wird gerechnet und steht nicht im Feld — sonst wäre es die
erste Zahl, die niemand nachzieht.
Detailansicht
Abschnitt betitelt „Detailansicht“Die Detailseite zeigt die Bedarfsdaten, das Anforderungsprofil in der Beziehungssektion und im Reports-Tab die Karte Deckung: je Periode Bedarf, Geplant und Offen.
Verwandt
Abschnitt betitelt „Verwandt“- Bedarf & Ressourcenplanung — Bedarf, Plan und Deckung im Überblick
- Laufender Betrieb und Vorhaben — Die zwei Arten und ihre Mengenformen
- Das Bedarfsprofil — drei Achsen — Die drei Achsen des Anforderungsprofils
- Rollen — Rollen als Bündel von Tätigkeiten
- JSON-Schema für Entitätstypen — Schema-Optionen,
showWhen, abhängige Pflicht