Le lieu de travail et ses outils de collaboration

C’est formidable de pouvoir travailler de n’importe où, avec n’importe quel appareil et de disposer de la technologie nécessaire quand on en a besoin. Plus qu’un luxe, c’est une nécessité dans la situation actuelle de travail à distance intensifié, ou pour les organisations internationales dont les utilisateurs sont très mobiles, répartis et fluides. Alors que tant de changements se produisent pendant la crise, votre lieu de travail devrait soutenir la reconfiguration de votre entreprise en permettant au personnel, aux partenaires, aux fournisseurs de travailler avec différentes applications, différentes équipes, etc.

Le mot « lieu de travail » utilisé dans ce contexte ne se limite pas aux postes de travail et aux outils de collaboration. Il s’étend à des domaines plus larges tels que l’architecture d’entreprise, la sécurité des applications et la gestion des identités et des accès. On peut dire que nous parlons de la base informatique plus large et des capacités numériques, pour soutenir et répondre aux besoins des entreprises – le lieu de travail n’est peut-être que la partie visible de l’iceberg.

L’héritage sur l’héritage ajoute de la complexité

Du côté de l’utilisateur, dès que vous passez par plusieurs cas d’utilisation, par exemple l’accès à un système existant sur place ou à une application Software as a Service, vous êtes susceptible d’avoir besoin de plusieurs comptes et donc d’une expérience utilisateur lourde.

Du côté de l’exploitation informatique, c’est également un fardeau de la faire fonctionner : les postes de travail sont encore la plupart du temps un dispositif physique lié à un domaine rigide de l’entreprise ; ils doivent être configurés, puis expédiés au personnel distant ou à des parties externes, et les comptes doivent encore être approvisionnés dans des environnements cibles, avec des droits d’accès définis de manière appropriée. Tous les éléments ci-dessus sont généralement des processus différents qui se répètent pour chaque fournisseur ou partenaire, ce qui entraîne autant de dispositifs et de configurations.

Plus important encore, dans quelle mesure cette situation désorganisée et chevauchante est-elle sûre ? Avoir une visibilité et un contrôle sur qui a accès à quoi, de bout en bout et pour tous les environnements, est un défi en raison des cas d’utilisation cloisonnés. Et à mesure que les utilisateurs rejoignent et quittent l’entreprise, que les applications évoluent, le niveau de sécurité diminue probablement en raison du manque de précision des comptes et des droits.

D’après notre expérience chez Wavestone, tous ces défis découlent de l’accumulation de nouveaux cas d’utilisation et de nouvelles technologies, mis en œuvre en silo, pour leur propre usage ou pour un groupe limité de cas d’utilisation. La plateforme, qui a d’abord été conçue pour une utilisation principale, s’est maintenant transformée en une plateforme à utilisations multiples avec un modèle et des processus mal adaptés. De nombreuses organisations peuvent aujourd’hui être fières de pouvoir compter sur une plate-forme fédérée et une expérience d’accès moderne pour les applications en nuage d’un côté – et sur une expérience différente, mais raisonnablement bonne, du côté des applications internes. Cependant, souvent, les deux ne sont pas intégrés et ne bénéficient donc pas des avantages que nous avons décrits dans l’introduction. Nous pensons que cela est dû à l’absence d’un modèle/architecture véritablement partagé pour soutenir une expérience moderne, dans tous les cas d’utilisation.

Figure 1 – Exemple de modèle d’entreprise dans lequel chaque entité gère séparément les identités et leur accès : duplication des processus

Un modèle pour une expérience de rationalisation

Pour cette raison et pour l’avenir de l’expérience utilisateur, chez Wavestone, nous croyons en un modèle basé sur la ou les Tours de Contrôle d’Identité.

Une tour de contrôle d’identité est une plate-forme permettant de faire respecter vos politiques d’accès. Son but est de vérifier les demandes d’accès provenant de sources d’identité fiables et de déterminer si cette identité est autorisée à accéder à une ressource numérique cible. Pour reprendre la métaphore, un pilote désireux d’obtenir une autorisation de décollage soumettra son plan de vol en utilisant un canal de confiance, et après son approbation et d’autres vérifications par les contrôleurs, le pilote pourra procéder au décollage. Si nous devions transposer cette métaphore en numérique, nous parlerions d’un utilisateur : pour que ledit utilisateur puisse accéder à la plate-forme X, il devrait utiliser un processus d’entreprise qui est lui-même fiable par une tour de contrôle d’identité. Cet utilisateur fournit son « plan d’accès » (par exemple, un jeton de session) à la tour de contrôle d’identité. Après que la tour de contrôle d’identité a vérifié l’authenticité du « plan d’accès » par rapport à ses politiques d’accès, elle effectuera d’autres vérifications de contexte, telles que : l’heure de la demande, le lieu d’origine de l’accès, le niveau de confiance du dispositif, etc. Si ces vérifications mettent en évidence quelque chose d’inhabituel ou d’incohérent dans l’authentification de l’utilisateur, des demandes supplémentaires peuvent être faites pour permettre à l’utilisateur d’entrer (ré-authentification ou renforcement).

La tour de contrôle d’identité est sous votre contrôle et détient les conditions d’accès, c’est-à-dire les politiques d’accès et accepte les utilisateurs de sources spécifiques grâce à une relation de confiance préétablie entre les organisations.

Par exemple, dans le schéma ci-dessous, imaginez une situation dans laquelle un fournisseur développe un nouveau service dans votre environnement en nuage. Les utilisateurs du fournisseur conserveraient leur dispositif et le processus d’authentification qu’ils utilisent dans leur environnement d’entreprise, tandis que la tour de contrôle d’identité (TIC) imposerait un contrôle d’accès à l’environnement en nuage – sans avoir à utiliser et à gérer un compte différent et à se ré-authentifier. Pour les environnements avec des privilèges très granulaires comme AWS, construire une TIC découplée n’est peut-être pas une approche réaliste et la TIC est alors probablement la plateforme d’identité d’Amazon qui est gérée par votre organisation et liée au fournisseur d’identité du fournisseur. Le modèle de la tour de contrôle d’identité est essentiellement une extension de la fédération, mise en œuvre pour couvrir tous les cas d’utilisation.

Figure 2 – Accès d’un utilisateur partenaire à une ressource du fournisseur de services dans le nuage via une tour de contrôle d’identité

Dans un autre scénario, comme le montre ce schéma, considérons un candidat qui postule à un emploi dans votre organisation, grâce à un portail de recrutement que vous proposez. Il déposerait une candidature sur votre portail en utilisant son identité numérique soutenue par le gouvernement, et une fois qu’il aurait donné son accord pour accéder à son profil LinkedIn, vous pourriez obtenir un CV numérique. Pour le candidat, il suffit de montrer sa pièce d’identité et de donner une copie de son CV, plutôt que de remplir le(s) formulaire(s) d’inscription en demandant une nouvelle fois les mêmes informations d’identité standard et en risquant de faire une faute de frappe dans ses coordonnées – ou même de devoir envoyer des copies de documents sensibles comme son passeport.

Figure 3 – Un scénario alternatif présentant la relation de confiance entre une plateforme d’identification gouvernementale et l’entreprise

Un modèle, trois piliers clés

Forts de nos connaissances et de notre expérience, nous pensons que ce modèle devrait reposer sur trois piliers clés : une identité unique dans tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360°.

Une Architecture d’Identité Unique : elle est réalisée en suivant une règle simple : ne pas dupliquer les données d’identité. Moins vous créez de fiches d’identité pour une même personne physique, plus l’expérience numérique sera simplifiée – car des étapes lourdes commencent à apparaître lorsqu’un compte, un dispositif ou une action d’authentification supplémentaire est nécessaire pour que l’utilisateur accède à la ressource cible. La clé d’une donnée d’identité unique est d’essayer de réutiliser les données de sa source (qui fait autorité) au lieu de les dupliquer/copier dans vos propres systèmes. Par exemple, les fournisseurs ou partenaires travaillant avec votre organisation ont probablement déjà des identités numériques professionnelles pour leur propre usage informatique – quelles seraient les conditions pour les exploiter au lieu de les recréer ?  Les deux piliers suivants contribuent à répondre à cette question.

Un modèle commun et flexible : Le deuxième pilier consiste à utiliser un modèle commun et flexible pour permettre/restreindre l’accès à l’information. Pour assurer la flexibilité, un modèle de contrôle d’accès basé sur les attributs (ABAC) permet des règles granulaires et est bien adapté à une approche adaptative et basée sur les risques. Pour que cela fonctionne, il est toutefois essentiel de définir la « grammaire » du modèle d’autorisation : quels sont les attributs réels utilisés pour fournir des accès qui ont un sens au niveau de l’entreprise ? Comment se traduisent-ils en « privilèges » ? Quels sont leurs formats/valeurs ? Lorsque la tour de contrôle d’identité est fournie par un fournisseur de cloud (par exemple, par un fournisseur de cloud comme Azure ou AWS), la grammaire est souvent déterminée par ledit service. En outre, pour que ce modèle soit le plus répandu possible dans les cas d’utilisation, tant du côté de la source d’identité que de la fourniture d’accès du côté du service cible, nous recommandons de mettre en œuvre votre plate-forme en suivant les normes du marché afin de maximiser l’interopérabilité (SAML, OpenID Connect, OAuth, FIDO, etc.).

Une relation de confiance à 360° : Enfin, le dernier pilier consiste à assurer l’établissement d’une relation de confiance à 360°. En d’autres termes, il faut faire preuve de diligence raisonnable et établir des seuils de confiance pour accepter l’interconnexion (« confiance technique ») des plateformes d’identité. La diligence raisonnable doit s’étendre à tous les processus en amont qui permettent d’alimenter la plateforme en identités, par exemple les processus RH/achats pour vérifier les identités, jusqu’au processus d’intégration informatique lui-même – parce que la confiance dans une plateforme d’identité est une première étape pour que ces identités puissent accéder à vos ressources numériques, vous devez être dans la tolérance du risque qu’elle comporte. Cette relation de confiance doit ensuite être mise en œuvre par le biais des attentes en matière de niveau de sécurité, de l’auditabilité des clauses contractuelles, et être appliquée par le biais de la gouvernance de la gestion des services des fournisseurs. Avec des exigences aussi strictes, une organisation doit être prête à intégrer temporairement des fournisseurs ou des partenaires au sein de sa propre plate-forme, pendant que les fournisseurs ou partenaires remettent leurs processus et plates-formes en conformité.

Deux facteurs clés de succès

Afin de mettre en œuvre ces trois piliers clés, Wavestone a identifié deux facteurs clés de succès : être parrainé par un niveau de gestion approprié et renforcer la résilience et la protection de la vie privée dès la conception. Un programme de transformation visant à établir ce modèle aurait des implications et des exigences dans plusieurs départements de votre organisation (RH, approvisionnement, juridique, informatique, risques, sécurité, etc.), et devrait donc être parrainé par la direction générale et mené avec une approche panorganisationnelle.

En outre, comme toujours, la plateforme de support doit être conçue et construite en tenant compte dès le départ des questions de sécurité, de confidentialité et de résilience.

Réflexions finales

Comme vous avez pu le comprendre tout au long de cet article, il est essentiel d’examiner l’expérience de l’utilisateur de bout en bout et d’un cas d’utilisation à l’autre pour vraiment rationaliser les services numériques. Cela peut être réalisé grâce à un changement d’organisation pour imposer une identité unique à tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360° avec les tiers.

Pour aller plus loin dans votre réflexion sur le sujet et comprendre l’état actuel de votre organisation, réfléchissez à ces questions et essayez d’y répondre : en choisissant des utilisateurs de différents services, à quoi ressemble l’expérience numérique quotidienne typique ? Combien de temps faut-il à mon organisation pour embarquer des sous-traitants et des tiers ? Comment mon organisation donne-t-elle effectivement accès à ses données et ressources aux utilisateurs externes ? Combien d’identités doubles existe-t-il dans mon parc informatique ? 

Cet article Les facteurs clés pour créer une expérience utilisateur transparente et sécurisée est apparu en premier sur RiskInsight.

Nous avons proposé 5 facteurs clés de succès pour mener un projet de mise sous contrôle des risques liés aux habilitations des ERP :

Les deux premiers facteurs clés de succès ont été vus dans le précédent article ; les trois derniers sont détaillés ci-après.

3. Industrialiser le déploiement

Services, filières, entités géographiques ou légales… la remédiation des risques sur les habilitations nécessite de passer en revue les comptes utilisateurs de différents – et souvent nombreux – périmètres. Afin de tenir les plannings, de limiter la charge de travail, mais également de rassurer les contributeurs locaux, il est préférable « d’industrialiser » au maximum le déploiement. Cela passe notamment par :

• la définition et la communication d’une méthodologie d’analyse et de remédiation des risques ;
• la mise en place d’outils de pilotage ;
• la mise en place d’outils d’analyse plus ou moins automatisés pour faire face à la volumétrie ;
• la formalisation de supports d’ateliers et de restitution ;
• la documentation de la méthodologie et de l’outil pour former les utilisateurs.

Tous les documents produits dans ce cadre constitueront le « kit » de déploiement utilisé par le projet sur les différents périmètres, et qui pourra également servir après le projet.

« Kit » de déploiement d’un projet de remédiation des risques liés aux habilitations d’un ERP

La méthodologie de déploiement va nécessairement s’articuler autour des activités suivantes, à reproduire pour chaque périmètre :

• Analyse des risques et définition d’indicateurs.
• Ateliers de remédiation des risques portés par les utilisateurs.
• Validation et exécution des plans de remédiation.
• Formation et accompagnement à la montée en compétence.

Cette méthodologie doit néanmoins s’adapter à l’organisation de l’entreprise et aux moyens de chaque entité : effectifs, déclinaisons locales des processus métiers, maturité dans la gestion des risques et des habilitations…

En particulier, il s’agira de mobiliser des sachants locaux aussi bien sur le volet technique des habilitations (correspondants habilitations, responsables applicatifs, responsables sécurité) que sur le volet métier des processus (représentants métiers, responsables de processus, contrôleurs internes, managers d’équipe…). À ce titre, la contribution attendue de leur part et la charge qu’ils devront y consacrer devra être annoncée le plus tôt possible et rester « raisonnable ». Le management local devra donc être impliqué pour garantir la mobilisation des contributeurs et aider dans la prise de décisions.

Lors des ateliers de remédiation, les contributeurs participeront notamment à l’analyse des risques portés par les utilisateurs et seront amenés à étudier différentes stratégies de remédiation telles que celles-ci :

Stratégies à considérer dans un projet de remédiation des risques liés aux habilitations d’un ERP

Il est bien entendu préférable de valider cette méthodologie sur un périmètre pilote, d’une volumétrie limitée tout en restant représentatif de l’entreprise. Suivant le contexte, il peut être plus stratégique de choisir un périmètre a priori « favorable » au projet, ou bien au contraire un périmètre qui demandera de toute façon plus d’accompagnement. Les leçons apprises dans le cadre du pilote permettront d’ajuster la méthodologie et l’outillage qui l’accompagne avant la phase de déploiement généralisé.

4. Bien s’outiller

Les outils mis en place doivent aider à mener à bien la phase projet, mais aussi et surtout être utilisés dans la durée en support de la méthodologie, les deux fonctionnant de concert.

Bien s’outiller, c’est déjà être au clair quant aux contrôles à réaliser a priori (au moment de la demande d’une nouvelle habilitation) et aux contrôles à réaliser a posteriori (une fois que les habilitations ont été données). Avoir beaucoup de contrôles a priori peut certes aider à prévenir plus de risques, mais l’efficacité opérationnelle peut aussi en pâtir (délais, difficultés dans le traitement des demandes), d’où l’intérêt de trouver le bon équilibre.

D’un point de vue fonctionnel, il s’agit d’être en mesure de réaliser plusieurs familles de contrôles typiques pour un tel projet, à savoir :

• Contrôles sur la qualité des données : complétude et cohérence des données, respect des nomenclatures…
• Contrôles sur des règles de sécurité IT : comptes orphelins, dormants et administrateurs, permissions temporaires ou rémanentes, comptes IT avec des permissions métier et réciproquement…
• Contrôles sur des règles métier / conformité : écarts entre la fonction et les permissions, écarts de permissions entre les membres d’une même équipe, infractions aux règles de séparation des tâches, accès en dehors du périmètre de responsabilité…
• Contrôles sur les usages et le comportement : usages excessifs ou inhabituels, comportements suspects, scénarios de fraude typiques…

Familles de contrôles typiques pour un projet de remédiation des risques liés aux habilitations d’un ERP

Bien s’outiller, c’est aussi prioriser et automatiser les contrôles qui en valent le coup. Le retour sur investissement doit être évalué au regard de la pertinence de chaque contrôle dans le contexte de l’entreprise (le contrôle ne coûte-t-il pas plus cher que l’impact du risque qu’il est censé couvrir ?) et du gain potentiel lié à l’automatisation (combien économise-t-on par rapport à une réalisation manuelle ?).

La volumétrie et la complexité des modèles d’habilitation des ERP imposent le recours à des outils adaptés : il n’est en effet pas étonnant de voir par exemple des systèmes SAP avec plusieurs milliers de rôles et plus d’une centaine de milliers de permissions fines (transactions et objets d’autorisation).

Les besoins se retrouvent à la croisée de plusieurs marchés logiciels particulièrement dynamiques en ce moment et aux frontières assez poreuses : « Gestion des identités et des accès », « Contrôle continu », « Outils de Gouvernance-Risque-Conformité spécialisés sur un ERP donné »… L’approche, la maturité, la couverture fonctionnelle et le mode de delivery (sur site ou cloud/SaaS) peuvent ainsi varier sensiblement d’un produit à l’autre.

Lors du choix de l’outil, il s’agira de considérer attentivement les éléments suivants :

• L’ergonomie et la facilité d’utilisation – une fois le projet terminé, les utilisateurs de l’outil seront majoritairement « Métier » et peu « IT ».
• Les possibilités de personnalisation – pour que l’outil vienne véritablement en support de la méthodologie (vocabulaire et écrans, règles et contrôles, tableaux de bord et rapports spécifiques à l’entreprise…).
• Le référentiel des contrôles déjà préconfigurés pour l’ERP de l’entreprise – généralement basés sur des bonnes pratiques.
• La capacité à réaliser des contrôles sur d’autres applications et entre applications – dans une logique moyen terme pour l’entreprise.
• Les fonctionnalités d’aide à l’analyse et à la décision – mise en évidence des anomalies, simulation de changements sur les habilitations, analyses approfondies et suggestions de remédiations…

Bien que les outils soient généralement peu « intrusifs » vis-à-vis des applications, il s’agira tout de même d’automatiser et de fiabiliser le transfert des données depuis l’ERP et les autres référentiels éventuels. Les équipes IT concernées devront donc être sollicitées également.

5. S’inscrire dans la durée

Un tel projet n’a de sens que s’il permet de maîtriser efficacement et dans la durée les risques liés aux habilitations. Il s’agit en effet d’éviter que les risques couverts en phase projet ne soient de nouveau présents quelques temps plus tard.

Pour favoriser l’appropriation de la méthodologie et des outils mis en place, il est indispensable d’investir dès le début et tout au long du projet dans la conduite du changement : réunions et lettres d’information régulières, séances de formation et de coaching, documentation et tutoriels… On préfèrera diversifier les canaux et supports d’échange afin de toucher un maximum de personnes sans donner l’impression de les sursolliciter.

Il convient par ailleurs d’aider les futurs responsables des risques liés aux habilitations à inscrire les nouveaux contrôles dans leurs activités récurrentes. On peut ainsi définir à quelles fréquences les contrôles plus ou moins avancés doivent être réalisés, quels sont les objectifs à atteindre ou les seuils de risques à ne pas dépasser. Ces objectifs se doivent d’être réalistes et progressifs : « Visons loin mais jalonnons court. »

Dans une logique de « communauté », il est important de favoriser les échanges entre responsables des différents périmètres afin qu’ils partagent leurs retours d’expérience et leurs bonnes pratiques. Il peut également être intéressant de créer une émulation saine entre les différents périmètres, voire même d’organiser de petits challenges. On veillera néanmoins dans un premier temps à valoriser plus la progression que l’atteinte d’un objectif chiffré donné, les différents périmètres n’ayant probablement pas tous la même situation de départ ni les mêmes moyens.

Enfin, il convient de mettre en place le mode « nominal », garantissant que les risques liés aux habilitations restent sous contrôle une fois le projet terminé. Cela passe notamment par :

• la nomination d’un référent de la méthodologie et de l’outil de contrôle des habilitations ;
• la montée en compétence des équipes techniques pour assurer le maintien en condition opérationnelle des outils et assurer l’évolution des rapports et des contrôles lorsque nécessaire ;
• la documentation et la capitalisation des connaissances acquises durant la phase projet.

La définition d’une feuille de route pour l’extension ultérieure du périmètre est également à envisager, afin de mettre sous contrôle de nouveaux processus, risques, applications, populations…

Inscrire dans la durée la maîtrise des risques liés aux habilitations d’un ERP

En conclusion, c’est possible !

Comme nous venons de le voir au travers de ces deux articles, maîtriser les risques liés aux habilitations d’un ERP nécessite de mener plusieurs chantiers importants, de la mise en place de l’outillage à la conduite d’ateliers avec les métiers, en passant par la formation et la conduite du changement.

Mais avec de la méthode et les bons contributeurs IT et Métiers embarqués dans le projet, rien d’impossible ! Des résultats tangibles peuvent être obtenus dans un délai raisonnable et initier une dynamique d’entreprise pour retrouver la maîtrise des habilitations sur l’ensemble du SI. Les facteurs clés de succès présentés ici sont en effet tout à fait applicables à des applications autres que les ERP.

Cet article ERP : comment mettre sous contrôle les risques liés aux habilitations ? (2/2) est apparu en premier sur RiskInsight.

Les commissaires aux comptes, les contrôleurs internes et les auditeurs ne s’y sont d’ailleurs pas trompés, augmentant la pression depuis plusieurs années pour mettre ces risques sous contrôle et s’assurer de la conformité avec les règlementations afférentes.

Les enjeux de la mise sous contrôle des habilitations d’un ERP

Il convient dès lors de se pencher sérieusement sur le sujet des « habilitations » (appelées également droits, permissions, rôles ou encore profils d’accès). C’est en effet grâce aux habilitations qui leur sont octroyées sur les ERP que les utilisateurs peuvent réaliser une grande partie de leurs activités, qu’elles soient légitimes ou non. Donner les bonnes habilitations, aux bonnes personnes, au bon moment, doit donc permettre de réduire significativement les risques évoqués précédemment.

Au travers de deux articles, nous présentons notre vision du sujet et partageons des bonnes pratiques éprouvées permettant de mettre sous contrôle les risques liés aux habilitations des ERP.

Une maîtrise toute relative des habilitations sur les ERP

L’écosystème des ERP se révèle relativement complexe et les entreprises dépensent généralement beaucoup de temps et d’énergie pour leur mise en place. Pourtant, le volet « gestion des identités et des habilitations » est bien souvent traité a minima. Au fil du temps, cela se traduit par une dégradation du niveau de maîtrise et de sécurité :

• Comptes obsolètes, génériques ou partagés qui s’accumulent.
• Nombre de rôles qui explose.
• Non-respect du principe de moindre privilège.
• Combinaisons toxiques de droits (infractions à la séparation des tâches, Segregation of Duties en anglais), etc.

Autant de facteurs qui tendent à augmenter l’exposition aux risques évoqués plus haut.

Ainsi, rares sont les entreprises pouvant se targuer d’avoir la pleine maîtrise des identités et des habilitations sur leurs ERP. Pour s’en convaincre, les quelques questions symptomatiques ci-dessous peuvent aider à évaluer sa propre maturité sur le sujet :

• Combien de comptes ne peuvent pas être rattachés à une personne physique (comptes génériques, comptes non réconciliés avec les référentiels RH ou Active Directory…) ?
• Combien d’utilisateurs peuvent changer les droits d’accès d’autres utilisateurs ?
• Combien d’utilisateurs disposent de profils à forts privilèges (tels que « SAP_ALL» et « SAP_NEW » dans SAP ECC) ? Parmi ceux-ci, combien sont réellement légitimes ?
• Combien d’utilisateurs peuvent changer les données de base fournisseurs ?
• En moyenne, combien de rôles sont affectés aux utilisateurs ? Plutôt 2 ou 3 rôles par utilisateur, ou bien la dizaine de rôles est-elle régulièrement dépassée ?
• Combien de rôles IT sont affectés à des utilisateurs métiers… et inversement ?
• Combien de rôles donnent en réalité plus de droits que ceux prévus théoriquement (rôles supposés en lecture mais donnant des droits en écriture, rôles avec périmètres plus larges que prévu, etc.) ?

Comment s’y prendre ?

Maintenant que le constat est posé, que faire ? Surtout ne pas s’avouer vaincu ni se décourager face au chantier en apparence titanesque qui s’annonce ! Améliorer la situation et remettre les risques liés aux habilitations sous contrôle, c’est possible. Il faut pour cela, outre s’en donner les moyens évidemment, respecter quelques facteurs clés de succès déterminants détaillés ci-après.

Facteurs clés de succès d’un projet de remédiation des risques liés aux habilitations d’un ERP

1. Piloter de façon rapprochée

Dans un tel projet, il ne faut bien évidemment pas chercher à tout traiter tout de suite. Il s’agit donc de cibler stratégiquement des « périmètres » qui permettront de montrer des résultats significatifs dans un délai raisonnable. Il peut s’agir par exemple d’une application clé ou d’un module central de l’ERP, d’un processus particulièrement mis en lumière lors d’un récent audit, ou encore d’une série de risques déjà identifiés comme critiques dans le référentiel d’entreprise. L’analyse des données réelles, extraites des systèmes ERP, peut s’avérer d’une grande aide quant à la priorisation et la justification de cette priorisation.

En termes de démarche, le projet doit nécessairement prendre en compte 3 volets :

• L’analyse et la mise sous contrôle des risques liés aux habilitations, cœur du projet.
• La mise en place d’une solution technique, en support de la méthodologie.
• Le pilotage et la conduite du changement, indispensables pour la bonne réussite d’un tel projet.

Il est important de cadencer ce projet avec des jalons réguliers sur chacun des trois volets et durant chaque phase du projet :

• La phase de préparation, qui comprend le cadrage à proprement parler, la mise en place de l’outillage et la préparation des prérequis.
• La phase de déploiement, dite Get-clean, qui vise à mettre sous contrôle les risques à date : validation de la démarche sur un pilote, déploiement généralisé et adaptation de l’outillage en fonction des retours.
• Le mode nominal, dit Stay-clean, qui prend la suite du projet mais doit se préparer pendant celui-ci, afin d’assurer la maîtrise des risques dans la durée.

Démarche type d’un projet de remédiation des risques liés aux habilitations d’un ERP

Il sera impératif de suivre de près les actions des différents contributeurs et décisionnaires, et plus globalement la bonne atteinte des engagements pris pour chaque étape. Ces engagements pourront se matérialiser par des résultats aussi bien quantitatifs (réduction de X% du nombre de risques critiques, pas plus de 5 risques par utilisateur désormais…) que qualitatifs (évolution des processus ou des contrôles compensatoires). Il s’agira dès lors d’être en capacité de mesurer et de valoriser ces résultats auprès des sponsors du projet et des représentants métiers.

2. Préparer le terrain

Les aspects techniques et métiers sont étroitement liés dans les projets qui ont trait aux habilitations, et encore davantage dans le cas des ERP. Il est donc nécessaire de trouver dès le début les bons sponsors pour le projet, à la fois côté Sécurité ou IT et côté Métier ou Contrôle Interne par exemple.

Il pourra par ailleurs être nécessaire de solliciter de nombreux acteurs : correspondants habilitations, responsables sécurité, représentants métiers, responsables de processus, managers d’équipe, contrôleurs internes, etc. La coordination va s’avérer essentielle tout au long du projet et il faudra dès le début embarquer et mobiliser les futurs contributeurs et personnes concernées par le projet en leur partageant les enjeux, les objectifs et la démarche. L’approche se doit d’être « bienveillante » : il ne s’agit pas de stigmatiser une situation, des comportements, ou un périmètre par rapport à un autre, mais bien de faire progresser l’entreprise et les collaborateurs dans la maîtrise des risques.

La phase de préparation va consister dans un premier temps à recueillir les différents entrants nécessaires au projet, et particulièrement tout ce qui permettra de réaliser une première analyse des données : informations organisationnelles sur les utilisateurs (département, métier…), habilitations, journaux d’accès, référentiels de contrôle, matrice de séparation des tâches, etc. Sur ce dernier point en particulier, des ateliers sont certainement à prévoir pour compléter cette matrice et la « traduire » en permissions techniques afin d’automatiser les contrôles dans un outil.

Il s’agira par ailleurs de définir les indicateurs, tableaux de bord et rapports qui seront utilisés à la fois pendant la phase projet mais également dans la durée par les personnes en charge du contrôle continu.

Un autre point important durant cette phase de préparation sera de mettre en qualité les données. Ce prérequis se révèlera d’autant plus indispensable que le niveau de maturité de l’entreprise en termes de gestion des identités et des habilitations sera faible. La mise en qualité porte non seulement sur les comptes utilisateurs, mais également et surtout sur le modèle d’habilitation de l’ERP. En effet, si les rôles ou les profils d’accès sont eux-mêmes porteurs de risques (en termes de séparation des tâches notamment), il faudra y remédier avant de s’attaquer aux risques individuels portés par les utilisateurs.

Exemples de prérequis pour un projet de remédiation des risques liés aux habilitations d’un ERP

Nous venons de voir les deux premiers facteurs clés de succès pour mener à bien un projet de remédiation des risques liés aux habilitations d’un ERP, à savoir piloter de façon rapprochée et préparer le terrain. Les trois facteurs clés suivants seront détaillés dans un second article, à venir très prochainement.

Cet article ERP : comment mettre sous contrôle les risques liés aux habilitations ? (1/2) est apparu en premier sur RiskInsight.

Dans un précédent article, nous évoquions l’importance d’une bonne relation Métiers-DSI, sachant qu’un ensemble de leviers centrés autour de la valorisation du capital humain peuvent être actionnés.

Dans ce cadre, nous avons identifié sept rôles clés à installer ou à renforcer dans les organisations, tant côté Métier qu’au sein de la DSI. Ce sont la qualité et l’efficacité de leurs interactions directes au quotidien qui vont concrétiser et rendre visible l’apport de valeur de l’IT.

Deux rôles pour garantir l’apport de valeur IT

La performance opérationnelle et économique de la majorité des entreprises repose sur la bonne intégration des processus et de l’IT qui permet d’industrialiser les processus clés, tout en garantissant leur évolutivité. Dès l’émergence d’une demande métier associée à des objectifs de productivité interne et/ou un enjeu commercial, il faut évaluer quelle part de réponse peut être apportée soit par l’évolution des procédures métiers soit par l’IT. L’estimation globale des coûts et bénéfices va ensuite conduire à définir le périmètre exact d’évolution à faire porter par l’IT.

Des Business analysts pour améliorer la conception

Dans environ 2/3 des entreprises françaises, l’emploi d’« analyste métier » n’a pas été déployé suffisamment. Il est resté axé principalement sur les compétences de traduction des demandes métier en exigences, et sur celles de rédaction de spécifications fonctionnelles. Les processus métiers ne sont pris en compte que lors de la rédaction des supports de formation utilisateurs dans le cadre de la conduite du changement. Ce mode de fonctionnement montre ses limites. Aujourd’hui, le Business analyst doit être en capacité d’identifier, de clarifier, d’analyser et de documenter les besoins de l’entreprise et la valeur associée. Il travaille à traduire les besoins de l’entreprise en objectifs fonctionnels et techniques, en garantissant la valeur générée. Il participe ainsi à la recherche de solutions innovantes, tant IT que processus, afin de répondre aux besoins Métiers identifiés. Il est donc « en charge de l’efficience des organisations et de l’amélioration des processus, des services et des produits, depuis l’analyse initiale des besoins jusqu’à la conduite du changement ».

Dans cette recherche de solutions maximisant la valeur générée pour l’entreprise, les Business analysts travaillent étroitement avec les concepteurs IT et les métiers. Ces deux rôles (Business analyst et concepteur) sont même amenés à fusionner dans le cas d’équipes agiles ou de progiciels.

Des Business process owners pour garantir la performance des processus

Dans le dialogue avec les Métiers, les Business analysts doivent s’appuyer sur les Business Process Owners (BPO). Ces BPO Métiers ont la responsabilité de la performance d’un processus d’entreprise (mesurée par des KPI). Ils ont le niveau de responsabilité et les compétences pour décider et faire mettre en œuvre les changements nécessaires. Afin d’améliorer la performance opérationnelle, le BPO pourra par exemple proposer de spécialiser une équipe sur une activité, ou bien a contrario de centraliser un ensemble d’activités sur un groupe de collaborateurs. De son côté, le Business analyst missionné sur une demande métier sollicitera le BPO pour définir les changements envisageables sur les processus impactés dont ce dernier a la charge. Cette responsabilité de BPO n’est pas à date toujours clairement identifiée dans les entreprises, notamment en raison de la responsabilité transverse qu’elle implique dans le pilotage de processus impactant plusieurs directions. Dans le cas où les BPO n’existent pas, les Business analysts auront un rôle accru. C’est sur eux que reposera la constitution d’une vision transverse des besoins et des processus impactés. Ils devront être force de proposition sur le bon équilibre d’évolution en termes de processus et d’IT.

Deux rôles pour intégrer la voix des utilisateurs dans la chaîne de valeur IT

La multiplicité des offres et l’interpénétration des canaux de la relation client se traduisent par une complexité accrue des postes de travail utilisateurs, non seulement en front-office mais également en back-office.

Leur environnement évolue régulièrement suite à des demandes qui s’enchaînent et s’entrecroisent, venant des directions commerciales, marketing, juridiques, financières… Inévitablement, il devient de plus en plus difficile de garantir une ergonomie des positions de travail permettant une exécution performante des différentes procédures et activités qui sont mises en œuvre au sein de chaque équipe opérationnelle. Cet aspect global est imparfaitement pris en compte dans l’expression des demandes métiers, souvent axées sur des évolutions d’offres et de services. Cela peut parfois aller jusqu’à la dégradation de la performance de certaines équipes et même du climat social, souvent perceptible par les clients finaux. Pour y répondre, les équipes IT doivent intégrer la voix des utilisateurs dans la chaîne de valeur IT afin d’améliorer la qualité de service rendue et la piloter efficacement dans le cadre du partenariat business-IT.

L’objectif est d’aller au-delà de la vision technique du poste de travail et de renforcer la légitimité de la DSI dans la connaissance de la perception terrain des outils mis à disposition dans l’entreprise. Pour cela, il leur faut développer la mesure de la satisfaction utilisateur et les dispositifs qui vont permettre d’identifier et de mettre en œuvre les actions d’amélioration nécessaires.

Des Key users pour incarner la « voix des utilisateurs »

L’identification de Key users côté Métier, au sein des unités opérationnelles de l’entreprise (plateau de vente, agence bancaire…), est primordiale, car ce sont les utilisateurs eux-mêmes qui sont les mieux placés pour identifier ce qui peut leur apporter plus d’efficacité dans leur travail au quotidien. Le Key user, c’est la combinaison entre la vision terrain maîtrisant très bien le métier et la capacité à prendre du recul pour identifier les trucs et astuces qui font gagner du temps. Le rôle du Key user permet de détecter des « signaux faibles », ou « irritants » qui pénalisent la satisfaction utilisateur (trop de copier / coller entre écrans, mise à jour d’une donnée trop tardive pour mener à bien une procédure…). Il est donc impliqué dans des boucles d’amélioration qualité qui vont au-delà d’une sollicitation ponctuelle dans le cadre de recette et d’UAT (User Acceptance Test).

Des Representant users pour porter les attentes des utilisateurs

Le Key user dispose toutefois d’une voix trop faible au sein des équipes IT. Il est donc nécessaire que la DSI lui associe un Representant user, côté équipes IT, qui va qualifier et relayer intelligemment les demandes des utilisateurs en s’assurant qu’elles sont traitées au bon niveau.

Jouant le rôle de Business analyst sur un périmètre « Environnement/position de travail », le Representant user qualifie, centralise, priorise les demandes des utilisateurs et mobilise les bons interlocuteurs afin de les insérer dans les projets/évolutions en cours. Il représente les utilisateurs en phase d’étude et s’assure de la cohérence et de la qualité des formations utilisateurs dans une vision d’ensemble des projets en cours. Il propose les objectifs chiffrés d’amélioration de la satisfaction utilisateurs pertinents sur son périmètre. Sa nomination doit être basée sur les compétences de leadership, d’intermédiation et de communication.

Trois rôles pour garder le cap de l’alignement du SI avec l’entreprise

Les rôles évoqués précédemment ont leur propre valeur. Pour en tirer pleinement parti, il est essentiel de les coordonner à différents niveaux.

Des Client managers pour renforcer la proximité avec les Métiers

Le Client manager incarne personnellement la proximité avec un ou plusieurs métiers clairement identifiés. Il est responsable de la qualité de l’animation de la relation Métiers – DSI et organise les comités opérationnels de suivi de cette relation, tant sur le suivi des investissements que sur la qualité du service rendu. Il est présent au Codir Métier. Il est le point d’entrée de toute nouvelle demande et est fortement impliqué dans le pilotage du portefeuille projet et la construction des schémas directeurs sur son périmètre.

Bien plus qu’un responsable de compte, il représente au sein de la DSI le(s) Métier(s) dont il est l’interlocuteur privilégié et s’assure de l’appropriation de leurs enjeux au sein des équipes IT, grâce à sa double compétence Métier-IT. Il est garant de la cohérence des solutions mises en place pour un Métier donné. Il est force de proposition et facilitateur en cas d’arbitrage à faire valider par le Métier, notamment pour expliquer les coûts de run impliqués par le projet. Il apporte sa vision globale des enjeux métiers aux Business analysts et aux Representant users afin de rendre leurs propositions plus pertinentes. Il s’appuie sur le(s) Service(s) Delivery Manager(s) qui pilotent opérationnellement la qualité des services récurrents et avec qui il définit les orientations à suivre en termes d’amélioration continue (évolution des engagements, plan d’action qualité sur un périmètre applicatif…). Le Client manager occupe généralement un poste de manager des équipes SI pour un domaine métier donné.

Un Chef de projet solutions pour s’engager d’une seule voix auprès des Métiers

Dans la plupart des organisations, la responsabilité d’un projet est portée par trois chefs de projet, l’un métier, le deuxième MOA et le troisième SI / MOE.

Pour autant, l’une des principales difficultés rencontrées actuellement dans le delivery des projets est la dilution des responsabilités entre les différents acteurs mobilisés dans un projet et la déresponsabilisation du ou des chefs de projet nommés côté MOA et MOE. Il est essentiel de redonner du poids à la gestion de projet en nommant un unique Chef de projet solutions, portant la responsabilité MOA et MOE en regard des Métiers et intervenant dès les phases d’étude. Il doit disposer de l’ensemble des moyens (économiques, opérationnels) pour s’engager. Il challenge les besoins et la valeur de la solution identifiée, il dispose d’un pouvoir décisionnel sur les moyens nécessaires pour délivrer la solution et est l’interlocuteur clé pour les Métiers sur le projet qu’il pilote.

Le Chef de projet est aujourd’hui un acteur incontournable dans la relation Métiers-DSI. Il porte la responsabilité de délivrer la solution, alignée avec les demandes relayées par le(s) Business analyst(s) et le(s) Representant users et avec les enjeux métiers relayés par le Client manager. Il est garant du respect des engagements réciproques Métiers et IT dans le cadre du projet et s’assure de la bonne intégration de la solution dans le SI existant et à venir (performance fonctionnelle et technique et optimisation des coûts en build et en run).

Il doit être choisi en fonction de l’enjeu, de la complexité du projet et du niveau d’impact sur le SI. Par exemple, dans le cas d’un projet dont le facteur clé de succès est essentiellement l’évolution des procédures opérationnelles métier, un acteur MOA ou venant du métier pourra être nommé Chef de projet, renforcé éventuellement avec un profil type PMO.

L’Architecte d’entreprise pour garantir l’alignement stratégique et la cohérence du SI

Il faut de plus assurer la cohérence globale des initiatives lancées par chaque Métier d’un point de vue entreprise (stratégie générale et orientations SI) grâce à un rôle clé : l’Architecte d’entreprise. Il intervient en tant que référent de l’architecture IT de l’entreprise et est garant de la cohérence globale de l’évolution du SI avec la stratégie et les processus d’entreprise. Il définit la stratégie d’évolution du SI et avalise les évolutions dans un souci d’alignement. Il est l’animateur de la communauté d’architectes qu’ils soient fonctionnels ou techniques. Il exerce son devoir de conseil en identifiant les solutions transverses pertinentes. Enfin, il est un conseiller avisé des Business analysts et des Chefs de projet solutions et les aide à optimiser leurs investissements dans le respect des orientations stratégiques.

In fine, c’est en renforçant l’ensemble de ces « nouveaux » rôles dans l’entreprise que se tissera pas à pas une relation Métiers/DSI de confiance durable à même de servir toujours mieux la stratégie globale de l’entreprise.

Cet article De nouveaux rôles pour transformer la relation Métiers – DSI est apparu en premier sur RiskInsight.

Guy Bellot : Au cours des dernières années, dans une volonté d’industrialisation et de réduction des coûts, nos structures ont évolué vers des « centres de services » ayant recours à de l’externalisation. Les actions de massification ont mécaniquement entraîné une concentration de l’activité sur quelques grands fournisseurs qui représentent aujourd’hui une part significative de la dépense IT.
Au vu de l’importance de ces fournisseurs dans nos activités IT, il est devenu essentiel de pouvoir à la fois :

• Accroître notre écoute respective, augmenter la visibilité donnée sur les attentes du business et aider à anticiper les variations de charge ;
• Objectiver la qualité de service fournie, par une mesure régulière et partagée d’indicateurs, en intégrant la vision d’un service « de bout en bout » délivrés aux utilisateurs finaux ;
• Garantir indépendance et souplesse pour Carrefour en favorisant la comparaison avec le marché tout en challengeant réversibilité et flexibilité des modèles déployés.

En étroite collaboration avec la Direction des Achats IT, le VMO doit animer et renforcer la relation de Carrefour avec ses fournisseurs stratégiques (au nombre de 6).

Quels en sont les premiers résultats ?

GB : Initié au cours du deuxième semestre 2012, le VMO a tout d’abord conduit une phase pilote qui nous a permis d’étoffer notre connaissance de nos fournisseurs et de tester la mise en oeuvre d’indicateurs suivant le principe des Balanced Score Card (BSC).
À ce jour, 3 outils correspondant à 3 niveaux d’information distincts sont utilisés ou en cours de déploiement :

• l’enquête de satisfaction semestrielle, qui nous permet de capter la perception des équipes IT quant à nos fournisseurs ;
• la BSC, qui complète la perception d’indicateurs de mesures sur les aspects performance financière, satisfaction client, performance des processus, ainsi qu’innovation et amélioration continue ;
• et enfin le dossier de suivi fournisseur qui enrichit les informations précédentes par d’un côté les informations externes (analyses financières, informations de tendances communiquées par les cabinets, retours d’autres grands groupes) et de l’autre les informations communiquées par le fournisseur (sa perception de son positionnement, de ses forces et ses faiblesses, ses retours sur l’enquête de satisfaction et les plans d’actions qu’il propose de mettre en oeuvre).

Ces dossiers sont construits et partagés avec les fournisseurs et avec les directeurs IT des entités et pays Carrefour. Ils permettent d’initier puis de suivre des plans d’actions, induisant ainsi une dynamique plus forte dans la relation.

Quels enseignements, quelles recommandations pour d’autres DSI ?

GB : L’animation du VMO demande un changement d’état d’esprit dans la relation. Il faut privilégier la transparence, la recherche de synergies, la collaboration avec nos partenaires et entre les partenaires. En même temps, il faut rester vigilant aux attitudes opportunistes, aux visions trop court terme, et aux situations de concurrence entre ces partenaires. Les modèles de sourcing doivent permettre de maintenir l’équilibre (dual sourcing). Il faut aussi adresser les bons niveaux hiérarchiques pour partager l’ambition et leur permettre de s’inscrire dans une démarche qui va demander du temps et de la maturité. Une phase pilote avec peu de fournisseurs (2 ou 3) sur un périmètre restreint permet assez vite d’identifier les limites et de régler les ambitions réciproques, pour ainsi sortir du diktat du « Quarter ».

Cet article 3 questions à Guy BELLOT (Carrefour) est apparu en premier sur RiskInsight.