Un projet d’IAM, est ce vraiment “cher, long et peu profitable” ?


J’ai lu il y a peu un article sur les nouvelles du net, titré « Un projet d’IAM, c’est cher, long et peu profitable » (voir http://www.lesnouvelles.net/articles/business/iam-cher-long-et-peu-profitable-selon-idc).

Cela doit faire près de 7 ans que je vends des projets IAM (Identity & Access Management, Gestion des Identités et des Accès) au sein de Devoteam, vous devinez que l’article m’a quelque peu interpellé… !

« Cher », « long » et « peu profitable », voilà trois sentences qui méritent bien qu’on y accorde un peu d’attention.

Les problématiques que cet article soulève, et notamment son titre – un tantinet provocateur – sont en effet d’importance, car elles résument les enjeux que nous travaillons systématiquement avec nos clients durant les phases d’avant-projet ou d’avant-vente, afin de construire le business case du projet IAM :
- Quels sont les drivers du projet ?
-
Y’a-t-il des retours sur investissement à en attendre et lesquels ?
-
Comment structurer le projet : quel lotissement, quel planning ?
-
Jusqu’où aller et où s’arrêter ?

J’avoue que je ne vois plus de clients partir la fleur au fusil sur des projets et qu’ils ont même tendance à se montrer très soucieux de visibilité sur les bénéfices attendus d’un projet IAM et sur tous les types d’efforts à fournir pour y arriver : investissements économiques, humains et organisationnels. 

A la lecture de l’article, « cher » semble être intimement lié à « long » (lire l’article); par ailleurs, la logique de l’ensemble semble indiquer que « cher » et « long » sont les éléments constitutifs du « peu profitable ».

Finalement, on pourrait synthétiser la problématique par : « est ce qu’un projet IAM est peu profitable ? ».

C’est d’ailleurs la question que posent tous les clients que je rencontre depuis des années : le retour sur investissement d’un projet IAM !

Afin de répondre à cette question, il est nécessaire de revenir un instant sur les fondamentaux de ce qu’est un projet IAM, au risque sinon de ne pas comprendre les paramètres de l’équation.

Ce projet réunit différents types d’enjeux :
-
La sécurité du SI en tout premier lieu, à travers la capacité à maîtriser les accès des utilisateurs et à en garantir la conformité, tant en termes de processus et de procédures que de réglementations,
-
L’industrialisation d’une gestion complexe, à travers l’automatisation de tout – le maximum surtout ! –  le récurrent et la « dé technicisation » des demandes et des droits d’accès,
-
L’amélioration de la qualité de service offerte aux utilisateurs, afin de professionnaliser et fluidifier cette partie sensible que sont les besoins et demandes d’accès.

Vis-à-vis de ces enjeux, il existe plusieurs « recettes » d’implémentation d’une solution IAM pour chaque client, qui vont se construire à partir des ingrédients suivants :
-
Les besoins de sécurité, de production et d’ergonomie utilisateurs,
-
Le périmètre à couvrir et l’éligibilité des applications à y intégrer en fonction de critères d’utilisation et de volume, ainsi que de critères économiques et de productivité,
-
Le lotissement permettant d’apporter des bénéfices visibles, périodiques, en évitant les effets tunnels de projets qui tardent à délivrer et dont la conception peut à la longue devenir caduque,
-
Le retour sur investissement, par l’automatisation du récurrent, les économies sur les services de support, etc.

Lorsque je relis ces dernières lignes, j’ai la conviction que tout ceci tient du bon sens commun, mais je vois encore des projets IAM se lancer sur des périmètres exubérants, sans lotissement itératif « intelligent » permettant de progresser, d’adapter, de faire en sorte que la vie de la solution en production fasse mûrir les guidelines des lots ultérieurs.

Je ne recommande que trop, notamment à la lecture de l’article des nouvelles du net, que le cadrage de projets IAM construise un business case du projet clair et partagé :
- De quoi ai-je réellement besoin, d’une voiture ou d’une limousine ?
-
Ai-je besoin de tout maintenant ou est-il pertinent de décomposer ?
-
Dois-je prendre du prêt-à-porter que j’adapterais et auquel je m’adapterais, ou dois-je faire un développement spécifique « haute-couture » ?
-
Combien ca me coûte, que cela me rapporte t-il , et surtout que cela me permet-il d’économiser ?

Les projets IAM, « longs » ? Ce sont des projets entre 1 et 3 ans, selon le périmètre…

Les projets IAM, « peu profitables » ? Non, définitivement non…

Travaillons sur le cadrage de votre projet et construisons le Business Model d’un projet IAM profitable.

1 Star2 Stars3 Stars4 Stars5 Stars (6 votes)
Loading ... Loading ...

  1. No comments yet.
(will not be published)
  1. No trackbacks yet.

Le Groupe Devoteam | Devoteam International | Devoteam Jobs | Devoteam Consulting
| Devoteam Opérations | Devoteam Solutions | Devoteam Blog | Devoteam Finance

Devoteam Blog, specialist talk point : Welcome !

Authorize

Lost Password

Register

Please contact the administrator.