TAOM TAOM.AI Digital Twin
DeutschEnglishFrançaisEspañol
Accueil / Pilotage des champs – qui a le droit de faire quoi

Pilotage des champs – qui a le droit de faire quoi

TAOM Process Studio · Pilotage des champs – qui a le droit de faire quoi

Gouvernance d’entreprise – droits, validations et contrôle des données jusqu’au niveau du champ

Qui a le droit de faire quoi – visible par tous.

Pour chaque client, une matrice définit quel champ de l’étape est obligatoire, qui peut le modifier et qui peut le valider – et ce qui se passe avec les informations manquantes lorsqu’une étape est publiée ou validée.

Le pilotage des champs s’applique à tous les utilisateurs inscrits – seule l’utilisation anonyme sans compte en est exclue. Chaque utilisateur du client voit les règles ; seul l’administrateur peut les modifier, et chaque modification est journalisée.

Vérification et testmatrice des fonctionnalitésProtection de l’information
119Champs du catalogue – les nouveaux apparaissent avec la valeur par défaut
Obligatoire · Facultatif · Désactivépar champ et par client
Rôles« Peut modifier » et « Peut valider » issus de l’organisation du projet
Tous les utilisateursinscrits – sauf anonymes
En un coup d’œil

Trois niveaux de contrôle

Qui peut modifier et valider quel champ, comment une étape passe du brouillon à la validation et ce qui part vers quel système cible selon le besoin de protection – à parcourir en cliquant.

Champ de l’étape Réglage Peut modifier Peut valider
Nom Obligatoire ✓
Description Facultatif ✓
Catégorie Obligatoire ✓
Risque (GAMP 5) Facultatif –
Obligation de contrôle Facultatif –
Cas de test Facultatif ✓
Statut de revue géré par TAOM TAOM –
Version du modèle géré par TAOM TAOM –
Champ de l’étape Réglage Peut modifier Peut valider
Nom Obligatoire ✓
Description Facultatif ✓
Catégorie Obligatoire ✓
Risque (GAMP 5) Facultatif ✓
Obligation de contrôle Facultatif ✓
Cas de test Facultatif ✓
Statut de revue géré par TAOM TAOM ✓
Version du modèle géré par TAOM TAOM ✓
Champ de l’étape Réglage Peut modifier Peut valider
Nom Obligatoire –
Description Facultatif –
Catégorie Obligatoire –
Risque (GAMP 5) Facultatif ✓
Obligation de contrôle Facultatif ✓
Cas de test Facultatif –
Statut de revue géré par TAOM TAOM ✓
Version du modèle géré par TAOM TAOM –
Champ de l’étape Réglage Peut modifier Peut valider
Nom Obligatoire –
Description Facultatif –
Catégorie Obligatoire –
Risque (GAMP 5) Facultatif –
Obligation de contrôle Facultatif ✓
Cas de test Facultatif ✓
Statut de revue géré par TAOM TAOM –
Version du modèle géré par TAOM TAOM –

Exemple de configuration. Chaque entreprise paramètre sa propre matrice – 119 champs, rôles issus de l’organisation du projet, chaque modification journalisée.

retravailler → retour au brouillonBrouillonVérification requiseVérifié sur le plan métierValidéRejetéQuatre yeuxRôle « Peut valider »
L’étape est en cours de description. Des champs obligatoires peuvent encore manquer – l’enregistrement fonctionne toujours.
Soumise à vérification. S’il manque des champs obligatoires, la règle « Valider » s’applique : non autorisé, avec confirmation ou autorisé.
Une deuxième personne confirme le contenu. Celui qui a modifié l’étape ne peut pas le faire – principe des quatre yeux (imposer ou seulement journaliser).
Uniquement les rôles disposant de « Peut valider ». Ensuite, l’étape peut partir vers le système cible (p. ex. Jira, Confluence) – selon la règle « Publier ».
Avec motif. Un ticket lié est rouvert, avec un retour visible.

S’y ajoute, pour des modèles entiers : des versions avec brouillon → à valider → validée ou rejetée, avec une règle propre « Quatre yeux pour les versions de modèle ».

Cible Ce qui sort – besoin de protection « Public »
Export HTML/PDF complet
Documentation (p. ex. Confluence) complet
Ticket (p. ex. Jira) complet
SAP Cloud ALM complet
Canaux Teams/Slack complet
Cible Ce qui sort – besoin de protection « Interne »
Export HTML/PDF complet
Documentation (p. ex. Confluence) complet
Ticket (p. ex. Jira) complet
SAP Cloud ALM complet
Canaux Teams/Slack complet
Cible Ce qui sort – besoin de protection « Confidentiel »
Export HTML/PDF complet
Documentation (p. ex. Confluence) complet
Ticket (p. ex. Jira) complet
SAP Cloud ALM complet
Canaux Teams/Slack sans contenu
Cible Ce qui sort – besoin de protection « Strictement confidentiel »
Export HTML/PDF sans contenu
Documentation (p. ex. Confluence) sans contenu
Ticket (p. ex. Jira) sans contenu
SAP Cloud ALM sans contenu
Canaux Teams/Slack sans contenu

Modèle fourni par TAOM. Le client l’adapte par niveau et par cible (« rien » retient entièrement une étape) ; TAOM signale ce qui a été retenu après le transfert. Le niveau peut être imposé au minimum par une liste de conformité (p. ex. GxP, RGPD).

La matrice

Un champ, trois questions

La base est le catalogue de champs de TAOM. Seuls les écarts du client sont enregistrés – si TAOM livre un nouveau champ, il apparaît avec la valeur par défaut sans que personne n’ait à toucher la matrice.

01 · Réglage

Obligatoire, facultatif ou masqué

Un champ obligatoire vide ne bloque jamais l’enregistrement. Il ne compte qu’à la publication et à la validation – selon les règles ci-dessous.

02 · Peut modifier

Rôles par champ

Issus du catalogue de rôles de l’organisation du projet – par exemple GPO, process owner, gestion des tests, validation, assurance qualité ou protection des données.

03 · Peut valider

Qui fixe le statut

Seuls les rôles disposant de « Peut valider » passent une étape à « Validé ». Sans entrée, le modèle s’applique.

Les champs gérés par TAOM ou qui reviennent d’un système cible (p. ex. Jira, Confluence) peuvent seulement être affichés ou masqués. Dans l’éditeur, ils portent un cadenas avec le motif, par exemple « géré par le système cible ».
Statut et valeurs vont ensemble

Du brouillon à la validation – avec les informations nécessaires

Chaque étape de processus porte un statut. Quelles valeurs doivent être présentes pour quel statut et qui peut le fixer, c’est le pilotage des champs qui le règle.

BrouillonCréée, à la main ou comme proposition d’un agent.
Vérification requisePrête pour la vérification métier.
Vérifié sur le plan métierContenu confirmé, validation en attente.
✔ ValidéUniquement par les rôles disposant de « Peut valider ».
RejetéToujours avec un motif, visible sur la forme.
Règle

Publier avec des lacunes

non autorisé · avec confirmation (par défaut) · autorisé. Les informations obligatoires manquantes sont visibles dans le système cible.

Règle

Valider avec des lacunes

non autorisé (par défaut) · avec confirmation · autorisé. Celui qui valide malgré tout est journalisé.

Règle

Principe des quatre yeux

imposer (par défaut) · seulement journaliser. Avec « imposer », l’auteur ne valide pas lui-même.

Diffusion

Ce qui sort – par besoin de protection et par cible

Pour chaque besoin de protection d’une étape et chaque cible, la matrice définit si le contenu est transmis entièrement, sans contenu ou pas du tout.

Besoin de protection Par défaut
Public · Interne complet vers toutes les cibles
Confidentiel complet, sans contenu dans les canaux Teams/Slack
Strictement confidentiel sans contenu partout – seulement identifiant et nom

Cibles : export HTML/PDF, Confluence, Jira, SAP Cloud ALM, canaux Teams/Slack. S’y ajoute une liste de conformité (p. ex. RGPD) avec un besoin de protection minimal, extensible par client. La même règle s’applique au manuel utilisateur.

La transparence plutôt que la recherche

Les règles ne sont pas cachées dans un écran d’administration. Chaque utilisateur du client voit quel champ est obligatoire et qui peut le modifier ou le valider.

  • s’applique à tous les utilisateurs inscrits
  • visible par tous les utilisateurs du client
  • seul l’administrateur peut modifier
  • chaque modification journalisée : qui, quand, avant, après
  • Cadenas dans l’éditeur, contrôle sur le serveur
Dans le reporting

Qui a quel rôle – à quel statut, dans quel processus ?

Ce qui compte dans le rapport, c’est ce qui est réellement attribué – pas ce qui serait possible. Personne n’a besoin de passer par le compte client pour savoir qui peut faire quoi et où. La vue « Rôles et validations » du reporting le montre par modèle et, sur le modèle d’entreprise sur tous les modèles.

État de validation par étapeValidé, vérifié sur le plan métier, vérification requise, brouillon, rejeté avec motif – chaque chiffre ouvre les étapes correspondantes.
Rôles et personnesPour chaque rôle, qui réalise (R), décide (A), est consulté (C) ou informé (I) – sous forme de tableau et de heatmap personne × responsabilité.
Lacunes visiblesÉtapes sans responsable, sans A, validées sans A, postes ouverts.
Organisation du projetQui occupe quelle fonction dans quel domaine – confirmée, non confirmée, expirée ou vacante.
Qui peut faire quoiQui peut valider le statut de revue et la version du modèle selon le pilotage des champs, les deux règles des quatre yeux, les champs avec restriction de rôle et la version en vigueur.
Directement à l’étape« Modifier les rôles » depuis chaque fenêtre – l’étape s’ouvre dans l’onglet Organisation.
Rôles et validations dans le reporting – Qui décide, qui exécute, ce qui est validé – et où la responsabilité manque. Avec, selon le pilotage des champs, qui peut valider et quelle version est en vigueur. Chaque chiffre ouvre les étapes concernées.
Rôles et validations dans le reporting Qui décide, qui exécute, ce qui est validé – et où la responsabilité manque. Avec, selon le pilotage des champs, qui peut valider et quelle version est en vigueur. Chaque chiffre ouvre les étapes concernées.
Cartes thermiques : rôle × statut de validation, personne × responsabilité – D’un coup d’œil : dans quel rôle des validations manquent et qui est R, A, C ou I sur combien d’étapes. Un clic sur une cellule affiche les étapes.
Cartes thermiques : rôle × statut de validation, personne × responsabilité D’un coup d’œil : dans quel rôle des validations manquent et qui est R, A, C ou I sur combien d’étapes. Un clic sur une cellule affiche les étapes.
Organisation de projet dans le rapport – Qui occupe quelle fonction dans quel domaine – confirmée, non confirmée, expirée ou vacante. Sans passer par le compte client.
Organisation de projet dans le rapport Qui occupe quelle fonction dans quel domaine – confirmée, non confirmée, expirée ou vacante. Sans passer par le compte client.

Captures d’écran de TAOM Process Studio avec des données d’exemple. Cliquez sur une image pour l’agrandir.

Mes tâches – par personne ou par rôle

Dans l’onglet « Tâches » du reporting, on saisit un nom, un rôle ou une fonction – ou simplement « Moi ». TAOM montre ce qui est en attente : validations ouvertes, étapes rejetées à retravailler, tests ouverts et versions de modèle à valider. Chaque ligne mène directement à l’étape ou au cas de test.

Combien y a-t-il à faire ?Nombre par type et temps nécessaire – à partir des temps de projet (prévu − réel) ou, à défaut, du temps de traitement dans le Process Mining.
Charge de travail en exploitationHeures par mois pour les étapes qu’une personne ou un rôle réalise.
Pour informationLà où quelqu’un est seulement consulté (C) ou informé (I) – séparé de ses propres tâches.
Aussi sur tous les modèlesSur le a href= »/modele-d-entreprise/ »>modèle d’entreprise recherche la même vue sur tous les modèles sous le nœud.
Tâches sur tous les modèles – au modèle d’entreprise – Un rôle choisi, tous les modèles sous le nœud parcourus : tests ouverts avec identifiant du cas de test, étapes en cours et le temps nécessaire – plus la charge du rôle en exploitation issue du process mining.
Tâches sur tous les modèles – au modèle d’entreprise Un rôle choisi, tous les modèles sous le nœud parcourus : tests ouverts avec identifiant du cas de test, étapes en cours et le temps nécessaire – plus la charge du rôle en exploitation issue du process mining.
Tâches par personne ou rôle – Saisissez un nom ou un rôle – ou « Moi » : validations en attente, étapes refusées à reprendre, tests et versions de modèle ouverts, avec le temps issu des temps de projet ou du process mining. Chaque ligne mène directement à l’étape ou au cas de test.
Tâches par personne ou rôle Saisissez un nom ou un rôle – ou « Moi » : validations en attente, étapes refusées à reprendre, tests et versions de modèle ouverts, avec le temps issu des temps de projet ou du process mining. Chaque ligne mène directement à l’étape ou au cas de test.

Captures d’écran de TAOM Process Studio avec des données d’exemple. Cliquez sur une image pour l’agrandir.

Prochaine étape : les droits dans le Process Mining – qui avait quel rôle lorsqu’une étape a été modifiée, vérifiée ou validée.

Questions fréquentes

Réponses brèves

Un client peut-il reprendre la configuration par défaut de TAOM sans rien paramétrer ?

Oui. La matrice est prête pour chaque client dès l’achat de la licence. Qui ne change rien travaille avec le modèle.

Que se passe-t-il si un champ obligatoire est vide ?

L’enregistrement fonctionne toujours. À la publication, TAOM demande confirmation (par défaut) ; à la validation, ce n’est pas autorisé (par défaut). L’administrateur peut modifier les deux.

Est-ce lié aux BPx (GxP) ?

Oui. Le principe des quatre yeux, les validations journalisées et les identifiants immuables sont la base des preuves en environnement réglementé – voir Vérification et test.

Protection de l’information & classificationChange Impact ManagementPilotage des champsPrincipe des quatre yeuxValidationGAMP 5IQ / OQ / PQSystème cibleVoie de retourOrganisation du projet

Des règles que chacun peut voir.

Le pilotage des champs s’applique à tous les utilisateurs inscrits de Process Studio.

matrice des fonctionnalitésreporting