TAOM TAOM.AI Digital Twin
DeutschEnglishFrançaisEspañol
Home / Feldsteuerung – wer was darf

Feldsteuerung – wer was darf

TAOM Process Studio · Feldsteuerung – wer was darf

Enterprise Governance – Berechtigungen, Freigaben und Datenkontrolle bis auf Feldebene

Wer was darf – für alle sichtbar.

Je Kunde legt eine Matrix fest, welches Feld am Prozessschritt Pflicht ist, wer es ändern und wer freigeben darf – und was mit fehlenden Angaben passiert, wenn ein Schritt veröffentlicht oder freigegeben wird.

Die Feldsteuerung gilt für alle registrierten Benutzer – nur anonyme Nutzung ohne Konto bleibt aussen vor. Jeder Benutzer des Kunden sieht die Regeln; umstellen darf der Verwalter, und jede Änderung wird protokolliert.

Prüfung und TestLizenzstruktur
119Felder im Katalog – neue erscheinen mit Vorgabe
Muss · Kann · Ausje Feld und Kunde
Rollen„Darf ändern“ und „Darf freigeben“ aus der Projektorganisation
Alle registriertenBenutzer – nur anonym nicht
Auf einen Blick

Drei Ebenen der Kontrolle

Wer welches Feld ändern und freigeben darf, wie ein Schritt vom Entwurf zur Freigabe kommt und was je Schutzbedarf in welches Zielsystem geht – zum Durchklicken.

Feld am Prozessschritt Einstellung Darf ändern Darf freigeben
Name Muss ✓
Beschreibung Kann ✓
Kategorie Muss ✓
Risiko (GAMP 5) Kann –
Prüfpflicht Kann –
Testfälle Kann ✓
Review-Status führt TAOM TAOM –
Modellversion führt TAOM TAOM –
Feld am Prozessschritt Einstellung Darf ändern Darf freigeben
Name Muss ✓
Beschreibung Kann ✓
Kategorie Muss ✓
Risiko (GAMP 5) Kann ✓
Prüfpflicht Kann ✓
Testfälle Kann ✓
Review-Status führt TAOM TAOM ✓
Modellversion führt TAOM TAOM ✓
Feld am Prozessschritt Einstellung Darf ändern Darf freigeben
Name Muss –
Beschreibung Kann –
Kategorie Muss –
Risiko (GAMP 5) Kann ✓
Prüfpflicht Kann ✓
Testfälle Kann –
Review-Status führt TAOM TAOM ✓
Modellversion führt TAOM TAOM –
Feld am Prozessschritt Einstellung Darf ändern Darf freigeben
Name Muss –
Beschreibung Kann –
Kategorie Muss –
Risiko (GAMP 5) Kann –
Prüfpflicht Kann ✓
Testfälle Kann ✓
Review-Status führt TAOM TAOM –
Modellversion führt TAOM TAOM –

Beispielkonfiguration. Jede Firma stellt ihre Matrix selbst ein – 119 Felder, Rollen aus der Projektorganisation, jede Änderung protokolliert.

nacharbeiten → wieder EntwurfEntwurfPrüfung erforderlichFachlich geprüftFreigegebenAbgelehntVier AugenRolle „Darf freigeben“
Der Schritt wird beschrieben. Muss-Felder dürfen noch fehlen – Speichern geht immer.
Zur Prüfung gestellt. Fehlen Muss-Felder, greift die Regel „Freigeben“: nicht erlaubt, mit Rückfrage oder erlaubt.
Eine zweite Person bestätigt den Inhalt. Wer den Schritt selbst bearbeitet hat, darf das nicht – Vier-Augen-Prinzip (erzwingen oder nur protokollieren).
Nur Rollen mit „Darf freigeben“. Danach darf der Schritt ins Zielsystem (z. B. Jira, Confluence) – gemäss Regel „Veröffentlichen“.
Mit Begründung. Ein verknüpftes Ticket wird wieder geöffnet, mit sichtbarer Rückmeldung.

Dazu für ganze Modelle: Versionen mit Entwurf → zur Freigabe → freigegeben oder abgelehnt, eigene Regel „Vier-Augen bei Modellversionen“.

Ziel Was hinausgeht – Schutzbedarf „Öffentlich“
HTML/PDF-Export vollständig
Dokumentation (z. B. Confluence) vollständig
Ticket (z. B. Jira) vollständig
SAP Cloud ALM vollständig
Teams/Slack-Kanäle vollständig
Ziel Was hinausgeht – Schutzbedarf „Intern“
HTML/PDF-Export vollständig
Dokumentation (z. B. Confluence) vollständig
Ticket (z. B. Jira) vollständig
SAP Cloud ALM vollständig
Teams/Slack-Kanäle vollständig
Ziel Was hinausgeht – Schutzbedarf „Vertraulich“
HTML/PDF-Export vollständig
Dokumentation (z. B. Confluence) vollständig
Ticket (z. B. Jira) vollständig
SAP Cloud ALM vollständig
Teams/Slack-Kanäle ohne Inhalt
Ziel Was hinausgeht – Schutzbedarf „Streng vertraulich“
HTML/PDF-Export ohne Inhalt
Dokumentation (z. B. Confluence) ohne Inhalt
Ticket (z. B. Jira) ohne Inhalt
SAP Cloud ALM ohne Inhalt
Teams/Slack-Kanäle ohne Inhalt

Vorlage von TAOM. Der Kunde stellt je Stufe und Ziel um („nichts“ hält einen Schritt ganz zurück); was zurückgehalten wird, meldet TAOM nach dem Übertragen. Die Stufe kann aus einer Compliance-Liste (z. B. GxP, DSGVO) mindestens vorgegeben werden.

Die Matrix

Ein Feld, drei Fragen

Grundlage ist der Feldkatalog von TAOM. Gespeichert werden nur die Abweichungen des Kunden – liefert TAOM ein neues Feld aus, erscheint es mit der Vorgabe, ohne dass jemand die Matrix anfassen muss.

01 · Einstellung

Muss, Kann oder Ausblenden

Ein leeres Muss-Feld sperrt das Speichern nie. Es zählt erst beim Veröffentlichen und Freigeben – nach den Regeln unten.

02 · Darf ändern

Rollen je Feld

Aus dem Rollenkatalog der Projektorganisation – etwa GPO, Process Owner, Testmanagement, Validierung, Qualitätssicherung oder Datenschutz.

03 · Darf freigeben

Wer den Status setzt

Nur Rollen mit „Darf freigeben“ setzen einen Schritt auf „Freigegeben“. Ohne Eintrag gilt die Vorlage.

Felder, die TAOM selbst führt oder die aus einem Zielsystem (z. B. Jira, Confluence) zurückkommen, lassen sich nur ein- oder ausblenden. Im Editor tragen sie ein Schloss mit der Begründung, etwa „geführt vom Zielsystem“.
Status und Werte gehören zusammen

Vom Entwurf zur Freigabe – mit den Angaben, die dafür nötig sind

Jeder Prozessschritt trägt einen Status. Welche Werte für welchen Status vorhanden sein müssen und wer ihn setzen darf, regelt die Feldsteuerung.

🧪 EntwurfAngelegt, von Hand oder als Vorschlag eines Agenten.
🟡 Prüfung erforderlichBereit für die fachliche Prüfung.
🟢 Fachlich geprüftInhalt bestätigt, Freigabe steht aus.
✔ FreigegebenNur durch Rollen mit „Darf freigeben“.
🔴 AbgelehntImmer mit Begründung, sichtbar am Shape.
Regel

Veröffentlichen mit Lücken

nicht erlaubt · mit Rückfrage (Vorgabe) · erlaubt. Fehlende Pflichtangaben stehen sichtbar im Zielsystem.

Regel

Freigeben mit Lücken

nicht erlaubt (Vorgabe) · mit Rückfrage · erlaubt. Wer trotzdem freigibt, wird protokolliert.

Regel

Vier-Augen-Prinzip

erzwingen (Vorgabe) · nur protokollieren. Wer erstellt hat, gibt bei „erzwingen“ nicht selbst frei.

Weitergabe

Was nach aussen geht – je Schutzbedarf und Ziel

Je Schutzbedarf eines Schritts und je Ziel legt die Matrix fest, ob der Inhalt vollständig, ohne Inhalt oder gar nicht weitergegeben wird.

Schutzbedarf Vorgabe
Öffentlich · Intern vollständig an alle Ziele
Vertraulich vollständig, in Teams/Slack-Kanäle ohne Inhalt
Streng vertraulich überall ohne Inhalt – nur Kennung und Name

Ziele: HTML/PDF-Export, Confluence, Jira, SAP Cloud ALM, Teams/Slack-Kanäle. Dazu eine Compliance-Liste (z. B. DSGVO) mit Mindest-Schutzbedarf, je Kunde ergänzbar. Dieselbe Regel gilt für das Benutzerhandbuch.

Transparenz statt Suchen

Die Regeln liegen nicht versteckt in einer Verwaltungsmaske. Jeder Benutzer des Kunden sieht, welches Feld Pflicht ist und wer es ändern oder freigeben darf.

  • gilt für alle registrierten Benutzer
  • sichtbar für alle Benutzer des Kunden
  • umstellen nur der Verwalter
  • jede Änderung protokolliert: wer, wann, was vorher, was nachher
  • Schloss im Editor, Prüfung auf dem Server
Im Reporting

Wer hat welche Rolle – an welchem Status, in welchem Prozess?

Im Report zählt, was tatsächlich vergeben ist – nicht, was möglich wäre. Niemand muss ins Kundenkonto wechseln, um herauszufinden, wer wo was darf. Die Sicht „Rollen & Freigaben“ im Reporting zeigt es je Modell und am Unternehmensmodell über alle Modelle.

Freigabestand je SchrittFreigegeben, fachlich geprüft, Prüfung erforderlich, Entwurf, abgelehnt mit Begründung – jede Zahl öffnet die Schritte dahinter.
Rollen und PersonenJe Rolle, wer ausführt (R), entscheidet (A), gehört (C) oder informiert wird (I) – als Tabelle und als Heatmap Person × Zuständigkeit.
Lücken sichtbarSchritte ohne Zuständigkeit, ohne A, freigegeben ohne A, offene Stellen.
ProjektorganisationWer welche Funktion in welchem Bereich hat – bestätigt, unbestätigt, abgelaufen oder unbesetzt.
Wer darf wasWer laut Feldsteuerung den Review-Status und die Modellversion freigeben darf, beide Vier-Augen-Regeln, Felder mit Rollenbeschränkung und die gültige Version.
Direkt zum SchrittAus jedem Fenster „Rollen bearbeiten“ – der Schritt öffnet sich im Reiter Organisation.
Roles & approvals in reporting – Who decides, who performs, what is approved – and where responsibility is missing. Plus who may approve according to field control and which version is valid. Every number opens the steps behind it.
Roles & approvals in reporting Who decides, who performs, what is approved – and where responsibility is missing. Plus who may approve according to field control and which version is valid. Every number opens the steps behind it.
Heatmaps: role × approval status, person × responsibility – At a glance: in which role approvals are missing and who is R, A, C or I at how many steps. Click a cell to see the steps.
Heatmaps: role × approval status, person × responsibility At a glance: in which role approvals are missing and who is R, A, C or I at how many steps. Click a cell to see the steps.
Project organisation in the report – Who holds which function in which area – confirmed, unconfirmed, expired or vacant. Without switching to the customer account.
Project organisation in the report Who holds which function in which area – confirmed, unconfirmed, expired or vacant. Without switching to the customer account.

Screenshots from TAOM Process Studio with sample data. Click an image to enlarge it.

Meine Aufgaben – je Person oder Rolle

Im Reiter „Aufgaben“ des Reportings gibt man einen Namen, eine Rolle oder eine Funktion ein – oder einfach „Ich“. TAOM zeigt, was ansteht: offene Freigaben, abgelehnte Schritte zum Nacharbeiten, offene Tests und Modellversionen zur Freigabe. Jede Zeile führt direkt zum Schritt oder Testfall.

Wie viel liegt an?Anzahl je Art und die Zeit dafür – aus den Projektzeiten (Plan − Ist) oder, wo keine gepflegt sind, aus der Bearbeitungszeit im Process Mining.
Arbeitslast im BetriebStunden pro Monat für die Schritte, die eine Person oder Rolle ausführt.
Zur KenntnisWo jemand nur gehört (C) oder informiert (I) wird – getrennt von den eigenen Aufgaben.
Auch über alle ModelleAm Unternehmensmodell sucht dieselbe Ansicht über alle Modelle unter dem Knoten.
Tasks across all models – on the enterprise model – One role selected, all models under the node searched: open tests with test case ID, steps in progress and the time needed – plus the role’s operational workload from process mining.
Tasks across all models – on the enterprise model One role selected, all models under the node searched: open tests with test case ID, steps in progress and the time needed – plus the role’s operational workload from process mining.
Tasks per person or role – Enter a name or role – or “Me”: pending approvals, rejected steps to rework, open tests and model versions, with time from project times or process mining. Every row leads straight to the step or test case.
Tasks per person or role Enter a name or role – or “Me”: pending approvals, rejected steps to rework, open tests and model versions, with time from project times or process mining. Every row leads straight to the step or test case.

Screenshots from TAOM Process Studio with sample data. Click an image to enlarge it.

Als Nächstes: Berechtigungen im Process Mining – wer welche Rolle hatte, als ein Schritt bearbeitet, geprüft oder freigegeben wurde.

Häufige Fragen

Kurz beantwortet

Kann ein Kunde die Vorgabe von TAOM übernehmen, ohne etwas einzustellen?

Ja. Die Matrix liegt für jeden Kunden beim Lizenzkauf bereit. Wer nichts ändert, arbeitet mit der Vorlage.

Was passiert, wenn ein Pflichtfeld leer ist?

Speichern geht immer. Beim Veröffentlichen fragt TAOM nach (Vorgabe), beim Freigeben ist es nicht erlaubt (Vorgabe). Beides kann der Verwalter umstellen.

Hängt das mit GxP zusammen?

Ja. Vier-Augen-Prinzip, protokollierte Freigaben und unveränderliche Kennungen sind die Grundlage für Nachweise in regulierten Umgebungen – siehe Prüfung und Test.

FeldsteuerungVier-Augen-PrinzipValidierungGAMP 5IQ / OQ / PQZielsystemRückwegProjektorganisation

Regeln, die jeder sehen kann.

Die Feldsteuerung gilt für alle registrierten Benutzer von Process Studio.

LizenzstrukturReporting