Réponse succincte
Dans le cadre d'un appel d'offres, les logiciels de gestion des droits d'accès à l'information (IRM) ne doivent pas être évalués uniquement sur la base de listes de fonctionnalités générales. Ce qui importe avant tout, c'est de savoir si la solution en question est capable de cartographier les processus de gouvernance de manière traçable, durable et évolutive dans le cadre de l'exploitation courante.
Il convient notamment de prendre en compte les rôles et les autorisations, les validations, les escalades, les justificatifs, les données structurées, les possibilités d'exportation, les intégrations ainsi que le modèle opérationnel sous-jacent. Une logique d'évaluation solide doit donc associer chaque fonctionnalité requise à une preuve concrète, au risque opérationnel qui y est lié et à l'avantage identifiable pour la gestion de l'entreprise.
Valeur informative limitée des listes générales de caractéristiques
Appels d'offres concernant la protection des données, Conformité- et les logiciels de gestion intégrée des risques proposent souvent un large éventail de fonctionnalités. On demande par exemple s'ils intègrent des workflows, des fonctions de reporting, des tableaux de bord, des modèles de rôles, des options d'exportation, des API, le multilinguisme ou Audit Il y a des sentiers.
Dans la pratique, cette approche a souvent pour conséquence que la quasi-totalité des fournisseurs satisfont formellement à une grande partie des exigences. Les résultats sont très proches les uns des autres, même si les solutions peuvent présenter des différences considérables lors de leur mise en service ultérieure.
Cela tient moins au nombre de fonctionnalités répertoriées qu'au caractère abstrait des termes utilisés. En effet, une simple case à cocher indiquant la présence d'une fonctionnalité ne permet généralement pas de se faire une idée fiable du degré d'exhaustivité, de configurabilité et d'aptitude à l'exploitation de cette fonctionnalité.
Cela apparaît clairement, par exemple, avec le terme „ workflow “. Ce terme peut désigner aussi bien une simple notification par e-mail qu’un processus configurable comportant des rôles, des conditions, des délais, des escalades, des rappels, des points de décision et Audit Trail. Si ces deux aspects sont simplement répertoriés dans une matrice d'évaluation sous la mention „ workflow existant “, il en résulte une comparabilité qui ne reflète pas suffisamment l'étendue réelle des prestations.
Les décisions de recrutement des grandes entreprises
Les grandes entreprises n'achètent généralement pas de logiciels de gouvernance pour un seul utilisateur ou un processus isolé. La solution doit au contraire s'intégrer dans un modèle opérationnel organisationnel et technique existant.
Il convient notamment de prendre en compte plusieurs domaines d'activité, régions, sociétés, rôles, langues et exigences réglementaires. À cela s’ajoutent des responsabilités changeantes, des exigences en matière d’auditabilité, des possibilités d’importation et d’exportation, des modèles d’autorisation, ainsi que la nécessité de continuer à développer les processus même en cas d’évolution du cadre juridique ou organisationnel.
Dans ce contexte, la question de savoir si un logiciel offre en principe une fonctionnalité donnée ne suffit pas pour procéder à une évaluation. Il convient plutôt de vérifier si l'organisation est en mesure de piloter le processus sous-jacent à l'aide de cette solution de manière durable, traçable et évolutive.
Le critère d'évaluation ne porte donc plus uniquement sur l'aspect fonctionnel, mais s'étend désormais aux risques et aux exigences liés à l'exploitation ultérieure.
Contrôlabilité dans les solutions de gouvernance
La maîtrise signifie qu'une organisation ne se contente pas de documenter les informations, mais qu'elle est capable de traiter les processus de manière fiable, en s'appuyant sur des responsabilités, des contrôles et des décisions clairement définis.
Cette différence peut être illustrée à l'aide d'un registre des activités de traitement. Une évaluation purement fonctionnelle s'attacherait notamment à déterminer si,
- si les activités de traitement peuvent être prises en compte,
- s'il y a des champs obligatoires et
- s'il est possible d'exporter des rapports.
Une évaluation davantage axée sur l'entreprise tient en outre compte de,
- qui est autorisé à créer une activité de traitement,
- quelles informations doivent être disponibles dans leur intégralité avant un examen,
- à quel moment il convient d'impliquer le délégué à la protection des données,
- qui en assume la responsabilité technique,
- quelles modifications entraînent un nouvel examen,
- comment assurer le suivi des mesures en cours,
- comment les validations sont documentées,
- quelle version faisait foi à quel moment,
- quelles entreprises ou régions sont autorisées à accéder à quelles informations,
- comme preuve d'un Audit est produite et
- comment le système réagit si le responsable concerné ne prend pas les mesures nécessaires dans le délai imparti.
Dans le premier cas, l'évaluation porte essentiellement sur la saisie d'un enregistrement. Dans le second cas, la question centrale est de savoir si le processus de gouvernance sous-jacent peut être mis en œuvre de manière fiable dans le cadre de l'exploitation courante.
Importance des critères d'élimination
De nombreuses évaluations d'appels d'offres traitent les exigences de manière largement similaire. Une fonctionnalité de confort peut ainsi se voir attribuer une pondération similaire à celle d'un problème majeur lié aux autorisations, à l'intégration ou à l'exportation. Cela peut conduire à ce qu'une faiblesse majeure soit compensée, d'un point de vue mathématique, par plusieurs fonctionnalités moins importantes.
Pour certaines exigences, une telle compensation n'est toutefois généralement pas appropriée.
Si, par exemple, une solution ne permet pas de séparer suffisamment les mandants, les sociétés ou les données sensibles, un tableau de bord supplémentaire ne devrait pas suffire à pallier cette lacune. Il en va de même pour les Audit Les lacunes, les possibilités d'exportation insuffisantes ou l'absence de portabilité des données. La question de savoir si les processus centraux ne peuvent être adaptés que par le biais de développements sur mesure concerne également de manière directe les coûts ultérieurs, la rapidité de réaction et la dépendance vis-à-vis du fournisseur.
Les appels d'offres devraient donc commencer par définir les exigences dont le non-respect entraîne l'exclusion.
Les critères d'exclusion suivants sont notamment pris en compte :
- Exigences en matière de sécurité de l'information et d'hébergement,
- Emplacement des données,
- Modèle des rôles et des autorisations,
- Séparation des clients ou des sociétés,
- Audit Trail,
- Exportabilité et portabilité des données,
- capacité d'intégration,
- justificatifs requis par la réglementation,
- Évolutivité,
- Disponibilité et l'assistance,
- les exigences contractuelles minimales ainsi que
- possibilités de sortie définies.
Ce n'est qu'une fois ces exigences minimales satisfaites qu'il convient de procéder à une évaluation plus approfondie et plus nuancée, basée sur un système de points.
Distinction entre les éléments indispensables et les éléments de différenciation
Les fonctionnalités standard ne doivent pas être surévaluées dans une matrice d'évaluation. Le fait qu'une solution de gestion de la confidentialité soit une Registre des activités de traitement La capacité à générer des graphiques constitue généralement une condition préalable fondamentale. Il en va de même pour la création de comptes utilisateurs ou la génération de rapports PDF simples.
Attribuer des notes élevées à ces éléments incontournables augmente le risque d'égalité mathématique, sans refléter suffisamment les différences réelles entre les solutions.
Les éléments de différenciation apparaissent plutôt dans des questions telles que :
- Dans quelle mesure le modèle de données peut-il être adapté ?
- Est-il possible de limiter l'accès des services aux informations dont ils ont besoin pour accomplir leurs missions ?
- Est-il possible de modifier des processus sans recourir au développement logiciel ?
- Plusieurs domaines de gouvernance peuvent-ils utiliser des objets communs ?
- Comment les relations entre les activités de traitement, les risques, les prestataires de services, les systèmes et les mesures sont-elles représentées ?
- Est-il possible de définir des autorisations assorties de conditions et de prévoires de suivi ?
- Les escalades peuvent-elles être déclenchées par des délais ou des risques ?
- Le processus décisionnel est-il entièrement transparent ?
- En combien de temps peut-on mettre en œuvre les nouvelles exigences réglementaires ?
- Les équipes internes pourront-elles ensuite faire évoluer elles-mêmes la solution ?
Ces questions portent moins sur la présence de fonctionnalités spécifiques que sur la compatibilité avec la plateforme et la capacité de fonctionnement de la solution.
Les pièces justificatives en tant qu'élément de l'évaluation
Le simple fait d'indiquer qu'une fonctionnalité existe ne devrait pas suffire lorsque les exigences sont strictes. Il convient au contraire d'exiger systématiquement une preuve concrète.
Si un prestataire indique, par exemple, qu’il dispose d’un modèle de rôles flexible, cela doit être vérifié à l’aide d’un scénario d’application réaliste. Un tel scénario pourrait prévoir qu’un service ne soit autorisé à traiter que ses propres activités de traitement, tandis que le délégué à la protection des données puisse contrôler toutes les opérations concernées. Un interlocuteur régional n’a accès qu’à la société qui lui est attribuée. Le service juridique peut consulter les analyses contractuelles sans avoir automatiquement accès à l’ensemble des Données sur l'emploi . La direction a accès aux informations sur l'état d'avancement et aux risques, mais pas nécessairement à tous les détails opérationnels.
Dans le cadre de cette évaluation, il convient ensuite de vérifier si,
- si le fournisseur est effectivement en mesure de configurer ce scénario,
- comment les droits se transmettent,
- comment les modifications sont consignées et
- si le client pourra effectuer lui-même ces ajustements ultérieurement.
Ce n'est qu'à travers une telle preuve qu'une affirmation générale concernant le fonctionnement devient une base d'évaluation solide.
| Question générale sur les fonctionnalités | Question RFP plus rigoureuse | Justificatif attendu |
|---|---|---|
| Existe-t-il des workflows ? | Est-il possible de configurer des processus avec des rôles, des délais, des conditions, des validations, des relances et des remontées hiérarchiques ? | Démonstration en direct d'un processus de validation complet. |
| Existe-t-il un modèle à suivre ? | Est-il possible de contrôler les accès en fonction des objets, des rôles, des entités et des processus ? | Configuration d'un scénario d'autorisation réaliste. |
| Existe-t-il un système de reporting ? | Compétences en gestion, Audit et les différents services peuvent-ils obtenir des rapports différents à partir des mêmes données structurées ? | Trois rapports adaptés à des publics cibles spécifiques issus d'une même opération. |
| Y en a-t-il un ? Audit Du trail ? | Les modifications, les décisions, les rôles, les dates et les valeurs antérieures sont-ils documentés de manière à permettre leur traçabilité ? | Affichage de l'historique complet des modifications. |
| Y a-t-il des exportations ? | Les clients peuvent-ils exporter leurs données de manière exhaustive, structurée et sans dépendance évitable vis-à-vis du fabricant ? | Exemple d'exportation complète des données. |
| Existe-t-il des API ? | Quels objets, actions et événements sont disponibles via les interfaces documentées ? | API-Documentation et un cas concret d'intégration. |
| Le système est-il configurable ? | Quelles modifications le client peut-il effectuer lui-même sans faire appel au service de développement du fabricant ? | Adaptation en temps réel d'un objet et d'un workflow. |
| Cette solution prend-elle en charge RoPA ? | Comment les activités de traitement, les systèmes, les prestataires de services, les risques, les TOM, Bases juridiques et les partages sont-ils reliés entre eux ? | Présentation d'un modèle de gouvernance cohérent. |
| Y a-t-il des devoirs ? | Les tâches peuvent-elles être déclenchées, attribuées, transmises à un niveau hiérarchique supérieur et suivies automatiquement ? | Processus avec dépassement de délai et escalade. |
| La solution prend-elle en charge le multilinguisme ? | L'interface, les contenus, les champs de données et les rapports sont-ils disponibles en plusieurs langues ? | Présentation d'un même processus en plusieurs langues. |
Répondre à ce genre de questions demande plus d'efforts aux prestataires. Cela permet toutefois d'évaluer la solution en question de manière plus fiable.
Scripts standardisés pour les démonstrations de produits
Une démonstration gratuite du produit ne constitue qu'un critère de sélection partiellement pertinent. Les fournisseurs ont tendance à mettre en avant les fonctionnalités dans lesquelles leur solution excelle. Il peut s'agir d'un tableau de bord, d'une interface utilisateur ou d'un système de reporting spécifique.
Cela n'apporte donc qu'un gain limité en termes de comparabilité, car tous les prestataires ne traitent pas le même cas d'utilisation.
Une démonstration dans le cadre d'un appel d'offres devrait donc s'appuyer sur un scénario standardisé. Un tel scénario peut, par exemple, comporter les étapes suivantes :
- Un département déclare une nouvelle activité de traitement.
- Certaines informations obligatoires manquent.
- La demande est renvoyée au responsable concerné.
- Certaines réponses déclenchent un contrôle de protection des données.
- Un prestataire est désigné.
- Un risque est évalué.
- Une mesure est créée.
- L'autorisation est accordée sous certaines conditions.
- Au bout de six mois, un rappel est déclenché.
- Un auditeur demande le parcours décisionnel complet.
Chaque soumissionnaire doit présenter le cas dans son intégralité. Il ne suffit pas d'évaluer uniquement le résultat. Il convient notamment de prendre en compte les questions suivantes :
- Combien d'étapes manuelles faut-il effectuer ?
- À quels endroits se produisent les ruptures de support ?
- Quelles sont les informations qui doivent être mises à jour à plusieurs reprises ?
- Dans quelle mesure le statut de traitement correspondant est-il compréhensible ?
- Comment configurer les écarts ?
- Quelles modifications nécessitent l'intervention du fabricant ?
- Quels justificatifs sont générés automatiquement ?
Grâce à cette approche, la démonstration du produit fait partie intégrante de l'examen technique et professionnel.
La dépendance à l'adaptation en tant que facteur de coût
Le prix de la licence indiqué dans un appel d'offres ne reflète généralement que partiellement les coûts réels d'une solution de gouvernance.
D'autres coûts peuvent notamment résulter :
- développement sur mesure,
- adaptations techniques,
- Conseil,
- Migration des données,
- Intégrations,
- Rapports,
- Formations,
- Adaptations de la version,
- Tests,
- Assistance et
- un changement ultérieur de fournisseur.
La question de savoir dans quelle mesure l'organisation peut adapter elle-même la solution revêt donc une importance particulière.
Les processus réglementaires et organisationnels ne restent pas inchangés. Les entreprises réorganisent les responsabilités, créent de nouvelles sociétés ou modifient les circuits internes de contrôle et de validation. À cela s'ajoutent de nouveaux champs, de nouveaux rapports et de nouvelles exigences techniques.
Si chaque adaptation doit faire l'objet d'un projet de développement, cela a généralement des répercussions sur les coûts, la durée et la dépendance vis-à-vis des fabricants. La configurabilité ne doit donc pas être considérée uniquement comme une fonctionnalité de confort, mais comme une caractéristique économique importante du modèle d'exploitation.
Évaluation de la compatibilité avec la plateforme
Une application RoPA spécialisée peut être un Registre des activités de traitement de manière exhaustive sur le plan technique. Les grandes entreprises ont toutefois souvent d'autres exigences en matière de gouvernance.
Cela peut notamment inclure :
- Analyses d'impact relatives à la protection des données,
- Contrôles des prestataires de services,
- Évaluations des transferts,
- Risques et mesures,
- Demandes des personnes concernées,
- Gestion des incidents,
- Gouvernance de l'IA,
- Gestion de la sécurité de l'information,
- Directives,
- Partages et
- Audit La gestion.
Si ces processus sont gérés dans des applications distinctes, cela peut entraîner l'apparition de nouveaux silos de données et la duplication des tâches de gestion. Systèmes, prestataires de services, risques et Responsable doivent alors, le cas échéant, être saisies dans plusieurs solutions indépendamment les unes des autres.
La compatibilité avec les plateformes se mesure donc notamment à la capacité à utiliser des objets de gouvernance communs de manière transversale. Un prestataire de services ne devrait pas nécessairement être tenu de Protection des données, la gouvernance de l'IA et la sécurité de l'information doivent être enregistrées à plusieurs reprises. Les risques devraient pouvoir être associés aux processus, mesures et contrôles concernés. Un cas d'utilisation de l'IA peut être associé à une activité de traitement, à un fournisseur, à un modèle, à un contrôle de protection des données, à un examen de sécurité et à une autorisation.
C'est dans ce lien que réside la différence entre une application métier isolée et une plateforme de gouvernance.
Mise en place d'une matrice d'évaluation
Une matrice d'évaluation fiable devrait relier entre eux quatre niveaux :
Fonction – Justification – Risque opérationnel – Avantages pour la direction
1. Fonction
Il convient tout d'abord de déterminer quelles sont les compétences techniques ou spécialisées requises.
Exemple : workflows de validation configurables.
2. Justificatif
Il convient ensuite de déterminer comment le prestataire doit prouver qu'il dispose effectivement de cette capacité.
Exemple : configuration en temps réel d'un processus de validation comprenant deux rôles de réviseur, des conditions et une procédure d'escalade.
3. Risque d'exploitation
Il convient également d'évaluer le risque qui en découle lorsque cette capacité fait défaut ou n'est disponible que de manière limitée.
Exemple : les décisions restent consignées dans des e-mails, les délais sont ignorés et les validations ne sont plus entièrement traçables par la suite.
4. Avantages pour la direction
Enfin, il convient de prendre en compte l'intérêt opérationnel ou stratégique que cette capacité présente pour l'organisation.
Exemple : des délais d'exécution plus courts, une réduction des tâches manuelles de coordination, une meilleure aptitude à l'audit et une moindre dépendance vis-à-vis du fabricant.
Ce n'est qu'en combinant ces quatre niveaux qu'il est possible de procéder à une évaluation qui va au-delà de la simple prise en compte de fonctions isolées.
| Critère d'évaluation | Justificatif | Risque opérationnel en cas de faiblesse | Avantages pour la direction | Pondération |
|---|---|---|---|---|
| Rôles et autorisations | Scénario réaliste en matière d'autorisations | Accès non autorisés, absence de séparation, charge administrative importante | Délégation sécurisée et exploitation évolutive | 10 % |
| Configuration du flux de travail | Processus en temps réel avec conditions et escalade | Processus liés aux e-mails, dépassement des délais, suivi manuel | Des délais d'exécution plus courts et des responsabilités clairement définies | 12 % |
| Modèle de données et relations | Lien entre l'activité de traitement, le système, le prestataire de services et le risque | Double prise en charge et absence de contexte professionnel | Une vision uniforme de la gouvernance | 10 % |
| Audit Trail | Historique complet des modifications | Les décisions ne sont pas suffisamment justifiées | Auditabilité et obligation de rendre compte | 8 % |
| Rapports et exportations | Gestion, Audit- et rapport d'exploitation | Création manuelle de rapports | Un pilotage plus rapide et des justifications solides | 8 % |
| configurabilité | Adaptation par l'équipe chargée de la relation client | Dépendance vis-à-vis des fabricants et coûts d'exploitation élevés | Une adaptation plus rapide et des coûts d'exploitation réduits | 12 % |
| Intégration et API | Cas concret d'intégration | Changements de support et double saisie des données | Automatisation et amélioration de la qualité des données | 8 % |
| Migration des données | Concept de cartographie, de test et de validation | Perte de données, retards et faible adhésion | Lancement structuré du projet | 8 % |
| Sécurité de l'information | Justificatifs techniques et organisationnels | Sécurité et Conformité-Risques | Une entreprise digne de confiance | KO / 10 % |
| Modèle d'exploitation et assistance | SLA, structure de support et processus de validation | Résolution tardive des problèmes et dépendance vis-à-vis du projet | Prévisibilité et sécurité d'exploitation | 7 % |
| Compatibilité avec les plateformes | Utilisation d'objets communs dans plusieurs solutions | Apparition de nouveaux silos de gouvernance | Évolutivité et protection de l'investissement | 7 % |
La pondération concrète doit être adaptée aux exigences de chaque entreprise. L'essentiel est qu'elle reflète la pertinence réelle des critères pour l'entreprise.
La maîtrise en tant que composante de l'avantage économique
Le retour sur investissement des logiciels de gouvernance est souvent réduit au gain de temps réalisé sur certaines tâches de documentation. On se demande par exemple combien d'heures de travail peuvent être économisées lors de l'élaboration d'un rapport RoPA.
Cette analyse est pertinente, mais elle ne rend pas pleinement compte des avantages économiques. Une part importante de ces avantages peut résider dans la meilleure maîtrise des processus sous-jacents.
Cela concerne notamment les aspects suivants :
- Les départements savent quelles informations et quelles tâches on attend d'eux.
- Les responsabilités restent clairement définies.
- Les contrôles sont lancés aux dates prévues.
- Il est possible d'assurer le suivi des délais et des mesures.
- Les décisions sont consignées.
- La direction dispose ainsi d'une vue d'ensemble fiable.
- Les preuves d'audit sont générées dès le déroulement du processus.
- Les nouvelles exigences réglementaires peuvent être mises en œuvre plus rapidement.
- Les connaissances restent dans le système et ne se trouvent pas uniquement dans les boîtes mail de chaque individu.
Cet avantage est souvent plus difficile à exprimer par un indicateur unique que le simple gain de temps. Il peut néanmoins revêtir une importance économique plus grande pour l'organisation.
Une solution qui se contente de générer plus rapidement des rapports ne fait, dans un premier temps, qu'améliorer une tâche administrative. Une solution qui relie entre eux les rôles, les risques, les décisions et les justificatifs peut, en outre, renforcer la capacité de gouvernance de l'organisation.
Points à vérifier en matière d'approvisionnement
Le service des achats prend régulièrement en compte le prix, le contrat, le cahier des charges et les performances du fournisseur. En ce qui concerne les plateformes de gouvernance, il convient en outre d'examiner certaines questions opérationnelles :
- Quels sont les services inclus dans l'offre standard ?
- Quelles sont les fonctionnalités qui nécessitent des modules complémentaires ?
- Quelles modifications relèvent de la configuration et lesquelles relèvent du développement ?
- Qui est habilité à effectuer des configurations ?
- Quels sont les coûts liés à l'assistance aux fabricants ?
- Comment sont organisés les processus de mise en production et de mise à jour ?
- Les configurations personnalisées sont-elles conservées lors des mises à jour ?
- Quelles sont les possibilités d'exportation ?
- Quelles sont les modalités d'une sortie ultérieure ?
- Quels sont les coûts liés à un volume de données supplémentaire, à des utilisateurs, des sociétés ou des modules supplémentaires ?
- Quels sont les services qui dépendent d'un partenaire de mise en œuvre ?
- Quels engagements figurant dans la feuille de route sont contractuellement contraignants et lesquels ne constituent que des déclarations d'intention ?
Le prix de licence le plus bas ne correspond pas nécessairement à l'offre la plus rentable. Les coûts à long terme dépendent dans une large mesure du modèle d'exploitation et de la flexibilité de la solution.
Points à vérifier en matière de conformité juridique et de protection des données
Les aspects juridiques et la protection des données ne doivent pas se limiter à l'évaluation des contrats ou du contenu technique des différents modules. Il convient également de vérifier si la plateforme permet d'assurer la traçabilité requise.
Il s'agit notamment :
- des responsabilités clairement définies,
- autorisations documentées,
- l'implication en temps utile des acteurs concernés,
- Gestion des versions,
- champs d'application définis,
- des modifications compréhensibles,
- Prise en compte des recommandations techniques,
- acceptations de risques documentées,
- mesures en cours,
- Les dossiers en attente et
- Portabilité des données.
Une solution de gouvernance ne doit pas se contenter d'enregistrer des déclarations ou des résultats isolés. Elle doit également permettre de retracer de manière transparente le processus qui a conduit à une décision.
Points à vérifier pour les DSI et les services informatiques
Pour les DSI et les services informatiques, les exigences techniques et opérationnelles occupent généralement le devant de la scène. Il convient notamment de vérifier les points suivants :
- Cette architecture s'intègre-t-elle dans l'environnement informatique existant de l'entreprise ?
- Dans quelle mesure ce modèle d'intégration est-il flexible ?
- Comment les identités et les rôles sont-ils associés ?
- Quelles sont les API et les événements disponibles ?
- Comment les configurations sont-elles transférées et testées ?
- Comment s'organise la séparation entre les clients et les sociétés ?
- Comment les versions sont-elles gérées ?
- Quelles sont les bases de données et les technologies concernées ?
- Comment s'effectuent la surveillance, la journalisation et Disponibilité Est-ce garanti ?
- Dans quelle mesure existe-t-il une dépendance vis-à-vis du fabricant ou du partenaire de mise en œuvre ?
Une plateforme peut offrir un large éventail de fonctionnalités tout en nécessitant des coûts d'exploitation considérables. L'évaluation technique ne doit donc pas se limiter au nombre de fonctionnalités.
Classification d'Ailance
Dans le cadre d'un appel d'offres, Ailance ne doit pas être évaluée en fonction du nombre de cases pouvant être cochées dans une liste de fonctionnalités générales. Ce qui importe avant tout, c'est de savoir si la plateforme est capable de refléter la logique de gouvernance et le modèle opérationnel du client concerné.
Ailance met en relation selon l'approche de plateforme décrite ici :
- objets de gouvernance configurables,
- Relations entre les données,
- Rôles et autorisations,
- Flux de travail,
- Contrôles et validations,
- Risques et mesures,
- Rapports et tableaux de bord,
- Audit les sentiers ainsi que
- API et intégrations.
Cette approche peut s'avérer particulièrement pertinente pour les entreprises qui souhaitent mettre en place plusieurs domaines de gouvernance sur une base commune.
Ailance RoPA ne se limite pas à la Documentation des opérations de traitement. Les opérations de traitement peuvent concerner des systèmes, des prestataires de services, des risques, des mesures techniques et organisationnelles, Bases juridiques, aux autorisations, aux mesures en cours et aux avis du délégué à la protection des données.
Pour l'évaluation, il convient donc de vérifier si ces liens donnent lieu à un processus de gouvernance soumis à l'impôt et si celui-ci répond aux exigences organisationnelles de l'entreprise concernée.
Vérification de sa propre matrice d'appel d'offres
Les entreprises devraient revoir leurs matrices d'évaluation existantes, en particulier lorsque les exigences sont formulées en termes généraux.
Pour une ligne telle que „ Workflow disponible “, il convient par exemple de préciser quelle prestation concrète un prestataire doit fournir pour obtenir la note maximale. Il convient de préciser si une confirmation générale du fonctionnement suffit ou si le prestataire doit démontrer comment les rôles, les délais, les conditions, les escalades, les validations et les justificatifs s'articulent entre eux.
Si cela ne ressort pas clairement de la matrice d'évaluation, il se peut que ce soient davantage des termes que des compétences réellement démontrées qui soient évalués.
Conclusion
Lors du choix d'un logiciel de gouvernance, une évaluation basée uniquement sur des listes générales de fonctionnalités ne suffit généralement pas.
Une logique solide d'appel d'offres doit tout d'abord définir des critères d'élimination, puis faire la distinction entre les conditions de base et les critères de différenciation réels. Les exigences critiques doivent être étayées par des preuves concrètes. Il convient en outre de prendre en compte les risques opérationnels, les coûts induits, les dépendances en matière d'adaptation et le modèle opérationnel sous-jacent.
La question déterminante n'est donc pas seulement de savoir si un logiciel met à disposition un workflow. Il convient plutôt de vérifier si ce workflow permet à l'organisation de gérer de manière durable et traçable les rôles, les décisions, les risques, les escalades et les justificatifs.
Dans un premier temps, une coche de fonctionnalité indique simplement qu'un prestataire a formellement confirmé une exigence. Il convient de procéder à un examen plus approfondi pour déterminer si la tâche organisationnelle sous-jacente pourra ainsi être remplie lors de l'exploitation ultérieure.
Questions et réponses
Comment évaluer un logiciel IRM de protection de la vie privée dans un appel d'offres ?
L'évaluation doit prendre en compte à la fois les critères d'élimination, les compétences professionnelles, les prérequis techniques, les justificatifs concrets, les risques opérationnels et l'utilité pour la gestion de l'entreprise. Les simples cases à cocher correspondant à des caractéristiques générales ne suffisent généralement pas à cet effet.
Quels sont les critères d'élimination à prendre en compte pour les logiciels Privacy-IRM ?
Les critères d'exclusion comprennent notamment la sécurité de l'information, la localisation des données, le modèle des rôles et des autorisations, Audit Trail, la portabilité des données, la capacité d'intégration, l'évolutivité, l'assistance et les exigences contractuelles minimales.
Pourquoi les listes de fonctionnalités ne suffisent-elles pas ?
Les fournisseurs utilisent parfois les mêmes termes pour désigner des fonctionnalités très différentes. Un « workflow », par exemple, peut désigner une simple notification ou un processus de gouvernance entièrement configurable.
Comment les démonstrations de produits doivent-elles être menées dans le cadre d'une procédure d'appel d'offres ?
Tous les prestataires devraient traiter un scénario défini de manière uniforme. Cela permet de mieux comparer la qualité des processus, la facilité d'utilisation, la configurabilité, les ruptures de support et la traçabilité.
Quelle est la différence entre un « incontournable » et un « argument de différenciation » ?
Une fonctionnalité indispensable est une condition préalable fondamentale, comme par exemple l'enregistrement des activités de traitement. Un critère de différenciation permet de déterminer dans quelle mesure la solution peut être déployée de manière flexible, évolutive et contrôlable en conditions réelles d'exploitation.
Pourquoi la configurabilité est-elle importante ?
Les processus de gouvernance évoluent régulièrement. Si chaque adaptation nécessite un développement spécifique au fabricant, cela peut entraîner une augmentation des coûts, des délais et des dépendances. La configurabilité permet de réduire ces risques.
Que signifie « compatibilité avec les plateformes » dans le domaine des logiciels de gouvernance ?
La compatibilité avec les plateformes signifie que plusieurs processus de gouvernance peuvent utiliser des objets, des rôles et des données communs. Cela permet d'éviter la création de nouveaux silos de données et la duplication des tâches de gestion des données.
Quels justificatifs un soumissionnaire doit-il fournir dans le cadre d'une procédure d'appel d'offres ?
Les exigences critiques doivent être illustrées à l'aide de scénarios concrets. Cela concerne, par exemple, les modèles de rôles, les workflows de validation, les escalades, Audit Trails, exportations de données, intégrations et modifications de configuration.
Comment évaluer le retour sur investissement d'une plateforme de gouvernance ?
Outre le gain de temps, il convient de prendre en compte la réduction des efforts de coordination, l'accélération des prises de décision, une meilleure auditabilité, une moindre dépendance vis-à-vis des fournisseurs, une meilleure qualité des données et un pilotage de gestion amélioré.
Quelle est l'importance du modèle d'exploitation ?
Le modèle d'exploitation détermine la manière dont une solution est gérée, personnalisée, intégrée, prise en charge et développée. Il peut avoir une incidence plus importante sur les coûts à long terme que le simple prix de la licence.
Comment Ailance RoPA peut-il contribuer à la gouvernance ?
Ailance RoPA associe les activités de traitement aux systèmes, aux prestataires de services, aux risques, ainsi qu'aux mesures techniques et organisationnelles, Bases juridiques, les mesures en cours, les responsables, les validations et les justificatifs. La solution peut ainsi aller au-delà d'une simple fonction de répertoire électronique.
Quelle question faut-il particulièrement prendre en compte dans un appel d'offres ?
Une question revêt une importance particulière : quelles modifications l'entreprise pourra-t-elle apporter elle-même ultérieurement, sans avoir à commander un projet de développement ou de conseil supplémentaire à cette fin ?.
German 
English 
Italian 
French