Drei Zonen, die nicht stillschweigend vermischt werden sollten
- PVS/KIS/OEM: Fachanwendung, fachlicher Zweck, Nutzerführung und organisationsspezifische Prozesse.
- MEMM-Scope: vereinbarte Produkt-, Runtime-, API- und Releasegrenzen.
- Externe Betreiber/Governance: Infrastruktur, Provider, Identitäts- oder Trust-Dienste und regulatorisch zugeordnete Verantwortungen.
Warum diese Klärung vor der Demo sinnvoll ist
Eine Demo kann Funktionsideen zeigen, beantwortet aber nicht automatisch Fragen zu Betrieb, Updates, Fehlerfällen, externen Abhängigkeiten oder Abnahme. Ein begrenzter Integrationsscope macht deshalb schon vor einem Pilot sichtbar, welche Annahmen noch offen sind und welche Nachweise später benötigt werden.
Hersteller, Integrator und TI-M-Anbieter
Der Hersteller beschreibt das Modul und seine lokale API. Das integrierende System verantwortet seine Fachanwendung; der Anbieter TI-M Pro verantwortet den Headless-Betrieb, das Integrationshandbuch und die GTI-Abstimmung vor Integration sowie bei wesentlichen Änderungen (gemSpec_TI-M_Pro 1.2.0, A_28679, A_28681, A_28682, A_28849, A_28850).
Versionierte Primärquellen
Was hier ausdrücklich nicht behauptet wird: Das Modell ist keine universelle RACI. Die tatsächliche Verantwortung hängt von Vertrag, Deployment, regulatorischer Rolle, Zielumgebung und Release ab und muss projektbezogen festgelegt werden.