Eine Governance-Modell-Frage im RFP beantworten

Modelldesign

Beginnen Sie mit Entscheidungen statt einem Stapel Committees

Lesen Sie über die Governance-Frage hinaus. Der Draft Contract kann Change Approval dem Buyer vorbehalten, Dispute Steps definieren, Service Reviews vorschreiben oder Security- und Data-Protection-Rollen zuweisen. Pricing Assumptions können von Buyer Attendance oder Decision Time abhängen. Extrahieren Sie diese Anforderungen vor dem Design. Ein schönes Diagramm, das dem Vertrag widerspricht, zeigt ein nicht abgestimmtes Operating Model.

Erstellen Sie ein Decision Inventory. Typische Domains sind Daily Service Control, Incident Command, Performance Exceptions, Risk Treatment, Release Approval, Contract Change, Financial Variation, Security Acceptance, Continuous Improvement, Strategic Roadmap und Exit. Ergänzen Sie Routine und Exceptions. Formulieren Sie je Item die zu entscheidende Frage und die Folge einer Verzögerung. So wird Governance vom People Arrangement zum Contract Control System.

Weisen Sie jeder Decision eine accountable Role zu. Andere Roles empfehlen, liefern Evidence, genehmigen Reserved Rights, führen aus oder erhalten Notice. Definieren Sie Delegated Limits als Value, Service Impact, Security Severity, Schedule Effect oder Contract Deviation. „Jointly owned“ reicht selten. Wo Buyer Approval nötig ist, trennen Sie Supplier Recommendation Authority und Buyer Reserved Decision.

Forums

Geben Sie jedem Forum einen Decision Contract

Gruppieren Sie Decisions mit gleicher Authority, Evidence und Timescale. Ein Operational Service Review kann Corrective Actions entscheiden und Changes innerhalb Delegated Boundary genehmigen. Ein Commercial Board entscheidet Variations und Contract Interpretation. Ein Executive Forum behandelt Outcomes, Material Risk und Deadlock. Wiederholen Sie nicht denselben Risk Register auf drei Ebenen. Lower Forums handeln und eskalieren nur bei überschrittenem Threshold.

Spezifizieren Sie je Forum Purpose, Chair, Decision Authority, Required Members, Quorum, Inputs, Standing Decisions, Outputs, Cadence und Secretariat. Trennen Sie Deciders von Informed Participants. Nutzen Sie Roles statt Namen, sofern nicht Key Personnel verlangt werden. Beschreiben Sie Urgent Decisions zwischen Meetings. Ein Monthly Calendar kann keinen Critical Incident führen, der in Minuten eine Entscheidung braucht.

Halten Sie das Modell proportional. Das UK Sourcing Playbook behandelt Contract Management und Governance Structure als strategische Designentscheidung und verlangt klare Escalation Routes. Die Contract Management Principles betonen Accountability, Roles und Governance Mechanisms. Das stützt diszipliniertes Design, aber kein universelles Three-tier Template. Complexity, Risk, Contract Value und Buyer Capacity bestimmen den Aufwand.

• Purpose: Contract Outcome oder Control, den das Forum schützt.
• Authority: erlaubte Decisions und nicht überschreitbare Limits.
• Inputs: Evidence vor einer gültigen Decision.
• Outputs: Decisions, Conditions, Actions, Owners und Due Dates.
• Cadence: regulärer Rhythmus plus Urgent Path.
• Interface: Eingang oder Escalation zu anderem Forum.

Escalation

Definieren Sie Trigger, Clock und Safe State

Ein Escalation Path ist keine Leiter von Senior Titles. Definieren Sie beobachtbare Trigger wie Breach Severity, Unresolved Time, Financial Value, Risk Exposure, Customer Impact, Regulatory Concern oder Authority Disagreement. Nennen Sie Invoker, Recipient, Evidence Package und Response Clock. „Escalate as appropriate“ lässt genau die strittigste Decision ohne Operating Rule.

Erklären Sie den Zustand während der Entscheidung. Der Incident Lead kann Command behalten, ein Change bleibt frozen, ein Temporary Control wird aktiviert oder Work läuft nur innerhalb Approved Safe Boundary. Trennen Sie Operational Urgency von Contractual Dispute. Service Restoration braucht sofortige Aktion, auch wenn Commercial Responsibility offen ist. Governance schützt Outcomes, ohne Rights still aufzugeben.

Geben Sie dem Deadlock Path ein End State. Er kann von Operational Owners zu Contract Authorities und anschließend zum Contractual Dispute Mechanism führen, soweit Tender Terms dies erlauben. Zeigen Sie Record und Rückmeldung an Delivery Teams. Escalation endet erst, wenn Plan, Risk, Change, Financial Position und Owner aktualisiert sind, nicht wenn Senior People einen Call hatten.

Operating Proof

Zeigen Sie Records und Phasenwechsel, die Governance real machen

Nennen Sie Controlled Records: Decision Log, Action Log, Risk and Issue Register, Change Record, Performance Report, Approval, Exception, Incident Review und Meeting Record. Ein Minimum Decision Record enthält Frage, Authority, berücksichtigte Evidence, Decision, Conditions, Dissent, Owner, Datum und Communication. Minutes mit „discussed“ ohne Outcome beweisen keine Direction oder Accountability.

Passen Sie Governance je Phase an. Mobilization braucht schnellere Readiness-, Dependency- und Acceptance-Decisions. Transformation ergänzt Architecture, Release und Benefit Controls. Steady State kann Cadence bei stabiler Performance senken. Exit verlangt Decisions über Data Transfer, Continuity, Assets, Knowledge und Acceptance. Nennen Sie Phase Trigger und beendete Temporary Forums, damit Governance nicht nach jeder Ausnahme wächst.

Schließen Sie mit Buyer Dependencies und Feasibility Proof. Nennen Sie Buyer Roles, Preparation Time, Approval Turnaround und Data Inputs als Annahmen, falls nicht vorgegeben. Verbinden Sie Supplier Roles mit verfügbaren Personen und Contract Responsibilities. Eine kompakte Decision-rights Table, Forum Specification, Escalation Example und Record Set zeigt mehr Kontrolle als eine große Hierarchy. Der Evaluator soll eine schwierige Decision bis Closure simulieren können.

• Dokumentieren Sie Authority, Evidence, Outcome, Conditions, Owner und Datum.
• Ändern Sie Cadence und Membership mit der Delivery Phase.
• Beenden Sie Temporary Controls statt Committees anzusammeln.
• Kennzeichnen Sie Buyer Participation als Dependency.
• Testen Sie das Modell mit Incident, Change und Deadlock.