Rollout Usecases und Betriebsaufbau

1. Executive Overview (Top-Level)

Ihr baut keinen Tool-Zoo, sondern eine steuerbare Betriebsplattform. Deshalb bleibt die Reihenfolge immer gleich: Space-Struktur -> Kundenkontext -> Projekte -> Gates -> Betriebsrhythmus.

1.1 Wie nennt man das ueberhaupt?

Fuer euer Setup passen diese Begriffe. Intern koennt ihr einen Hauptbegriff waehlen und die anderen als Untertitel nutzen.

Wording-Standard: IT/CS-Fachbegriffe in der Kommunikation zuerst, IIO-Mapping als Zusatz. Business- und Teamsprache wird als Uebersetzungsstil daraus abgeleitet. Beispiel: "Tenant-Instanz (Node)", "Referenztemplate (Seed)", "Instanziierung (Projection)".

2. Standard-Zielstruktur fuer den Rollout

Die Struktur ist fuer alle Branchen gleich. Unterschiede kommen nur in Story, Boundary und Compliance-Regeln.

organisation//
  customers/
    private//
      profile/
      contracts/
      operations/
      projects/
    public//
      profile/
      publishing/
  projects/
    active//
      story/
      plan/
      work/
      artifacts/
      state/
      evidence/
    archive//
  shared/
    templates/
    relations/
    runbooks/

3. Anonymisierte Kunden-Usecases (Branchenbeispiele)

Die folgenden Beispiele sind absichtlich anonymisiert und als Schablonen fuer euren Aufbau gedacht.

4. Beispiel: Wie wir Kunden anlegen und verwalten

4.1 Anlegen (immer private default)

id: customer-industrial-dist-01
kind: customer
visibility: private
owner_actor: human-owner-01
delivery_actor: human-delivery-01
state: active
relations:
  - type: has_project
    target: project-industrial-onboarding

4.2 Verwalten im Betrieb

5. Beispiel: SW-Projekte anlegen (wie und wo)

Fuer jeden Kunden laufen operative und technische Projekte ueber denselben Story-to-State-Pfad. SW-Projekte liegen im Kundenkontext und zusaetzlich in der zentralen Projektablage.

5.1 Projektanlage im Kundenkontext

organisation//customers/private/customer-industrial-dist-01/projects/
  project-industrial-portal-v1/
    story/story-industrial-portal-v1.yaml
    plan/plan-industrial-portal-v1.yaml
    work/work-items/
    artifacts/
    state/state.yaml
    evidence/

5.2 Spiegel in zentrale Projektablage

organisation//projects/active/project-industrial-portal-v1/
  story/
  plan/
  work/
  artifacts/
  state/
  evidence/
  links/customer-ref.yaml

5.3 Minimales Projekt-Template

id: project-industrial-portal-v1
kind: software-project
customer_ref: customer-industrial-dist-01
story_ref: story-industrial-portal-v1
owner_role: delivery-lead
reviewer_role: reviewer
visibility: private
state: draft
release_mode: gated

6. Entwicklungsprozess fuer SW (Top-down)

7. Betriebsprozess fuer Rollout und Scale-up

7.1 Rollout-Stufen

7.2 Betriebsrhythmus (empfohlen)

8. Fail-Closed Situationen im Rollout

9. Betriebssektionen: Windows, Linux, Netzwerk

Diese Sektion verbindet klassische Systemadministration mit eurer Story/Gate/TX-Logik. Jede Aenderung bleibt rollback-faehig und auditierbar.

9.1 Windows Administration (Beispielpfad)

project-id: project-win-core-hardening
scope:
  os: windows
  components: [ad, file-services, endpoint-policies]
change-type: controlled
rollback-plan: required

9.2 Linux Administration (Beispielpfad)

project-id: project-linux-platform-stability
scope:
  os: linux
  components: [base-os, container-runtime, backup-agent]
rollout-mode: staged
incident-trigger: automatic-on-health-deviation

9.3 Netzwerk und Infrastruktur (Beispielpfad)

project-id: project-network-segmentation-wave1
scope:
  domain: network
  segments: [office, production, guest]
change-window: weekend
security-gate: required

10. Grosser Beispiel-Usecase: Systemhaus fuehrt Plattform aus

Szenario: Ein grosses Systemhaus mit heterogener Infrastruktur (Windows, Linux, macOS, Mobile, Netzwerk, Remote-Standorte, Team-Kollaboration) betreut viele B2B- und Privatkunden parallel und fuehrt die Plattform in kontrollierten Wellen ein.

10.1 Kundenportfolio im Beispiel

10.2 Rollout in vier Wellen

10.3 Beispiel fuer parallele Projektlandschaft

projects/active/
  project-industrial-portal-v1/          # SW-Projekt Kunde A
  project-care-ops-dashboard-v1/         # SW-Projekt Kunde B
  project-tooling-partner-workflow-v1/   # SW-Projekt Kunde C
  project-finance-approval-flow-v1/      # SW-Projekt Kunde D
  project-win-core-hardening/            # Windows Betrieb
  project-linux-platform-stability/      # Linux Betrieb
  project-macos-endpoint-governance/     # macOS Betrieb
  project-mobile-device-compliance/      # Mobile Betrieb
  project-network-segmentation-wave1/    # Netzwerk Betrieb
  project-remote-ops-site-connectivity/  # Remote Infrastruktur
  project-team-collaboration-standards/  # Teamplattformen (z. B. M365/Teams)

10.4 Steuerungsregeln im Beispielbetrieb

11. Skalierungsstufen: 20, 50, 100, 500 Mitarbeitende

Mit wachsender Teamgroesse aendert sich nicht das Prinzip, sondern die Betriebsdisziplin: mehr Standardisierung, mehr Delegation, staerkere Trennung von Rollen und Betriebszonen.

12. Abteilungsmodell (damit jeder arbeiten kann)

Das Abteilungsmodell uebersetzt eure Plattformlogik in alltagstaugliche Verantwortungsraeume. Jede Abteilung hat klare Inputs, Outputs und Gate-Bezuege.

13. Schulung, Einfuehrung, Betrieb: das Enablement-Programm

Damit alle mit dem System arbeiten koennen, braucht ihr ein wiederholbares Einfuehrungsprogramm mit klaren Lernstufen und Betriebspruefungen.

13.1 Lernstufen

13.2 Einfuehrungsfahrplan (90 Tage Beispiel)

13.3 Betriebskennzahlen fuer Einfuehrung

14. Verknuepfte Kapitel

• Training and Enablement Playbook
• Company Rollout Curriculum
• Role-based Training Curricula
• Taegliche Administration: Objekte, Kunden, Projekte
• Rollenpakete fuer Daily Ops
• Bedienung ohne GUI
• GUI Transition Backlog
• Betriebsmodi und Reifegrade