Zum Inhalt springen

Bedarf

Abhängigkeiten · Data Nodes

  • Bezüge zu: KI Agenten (über REQUESTS_MEMBER), Kostenstellen (über ORIGINATES_FROM), OKRs (über ORIGINATES_FROM), Personen (über REQUESTS_MEMBER), Wertschöpfung (über ORIGINATES_FROM), Projekte (über ORIGINATES_FROM), Rollen (über ORIGINATES_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.

Die Listenansicht zeigt die Bedarfe des Mandanten. Über die Detailseite kommst du an das Anforderungsprofil (Beziehungen) und an die Karte Deckung.

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:

ArtPflichtfelderEnddatum
Vorhaben (Projekt, OKR)Gesamtbedarf (h), Gültig ab, Gültig bisPflicht — ein Vorhaben endet
Laufender Betrieb (Wertstrom, Rolle)Bedarf je Periode (h), Gültig aboptional — 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.

  • 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.

{
"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:

  • allOf mit if/then macht 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.
  • showWhen blendet das jeweils andere Mengenfeld aus. Ein ausgeblendetes Feld ist nie Pflicht — nur deshalb entsteht aus der Kombination keine Sackgasse.

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.

Die Detailseite zeigt die Bedarfsdaten, das Anforderungsprofil in der Beziehungssektion und im Reports-Tab die Karte Deckung: je Periode Bedarf, Geplant und Offen.