| On n’insistera jamais assez auprès des chefs de projet sur le fait que ce qui est demandé n’est ni un programme ni une machine, mais un service rendu par un ensemble de composants informatiques et humains. La différence n’est pas que philosophique. |
Cycle ITIL de gestion des applications : |
Gestion de la valeur du métier de l’entreprise
Depuis son origine, l’informatique d’entreprise a une tendance marquée à considérer qu’elle ne travaille que pour elle-même. Il n’est pas naturel à un informaticien de penser son activité en tant que « bailleur de logement », « banquier », « assureur », … L’informaticien se voit principalement comme un technicien. Ce problème est généralement source d’incompréhension car le technicien fier de son art n’arrive pas à comprendre les choix de son management et encore moins à le relier à un choix stratégique d’entreprise, tendance qui peut être renforcée si le middle management n’est pas assez percutant.
ITIL insiste sur la nécessité de réconcilier l’informaticien et son entreprise : « It is not technology itself that supplies returns to a business, but how technology is employed to meet business requirements. »
J’ajouterais que j’ai pu remarquer que ce phénomène de « fascination technologique » touche souvent les maîtrises d’ouvrage elles-même. En effet, alors qu’elles partent d’objectifs métiers (gérer les relations avec leurs clients, communiquer plus efficacement, …) elles en arrivent trop souvent à la question du meilleur logiciel, de la technologie « à la pointe »,… jusqu’au jour où le meilleur logiciel et la meilleure technologie n’arrivant pas à rendre le service métier qui était à la base de leur démarche, elle s’y intéresse à nouveau, mais trop tard hélas pour la performance de leur business et la maîtrise des coûts.
La dérive technologique est un mal contagieux…
Les relations entre vue stratégique de l’entreprise, schéma directeur de la DSI, organisation de la DSI et technologie de cette même DSI vont déterminer le rôle stratégique de l’informatique pour l’entreprise : suiveur (voire frein au développement), centre de profit, et dans le meilleur des cas, initiateur ou créateur d’affaires.
La période e-business des années 2000-2001 a bien illustré ces aspects : un écart immense s’est créé entre les sociétés qui ont su inventer un commerce qui n’éxistait pas (google, amazone, e-voyagistes, …), ceux qui ont investi pour de pures raisons d’image (et qui ont dû arrêter l’expérience), et ceux qui se sont accrochés tant bien que mal à une vague de fond tout en ne sachant pas bien faire la différence entre la nouveauté technologique (sans intérêt en elle-même) et une nouvelle réalité économique. Les échecs et les succès de cette période montre l’importance fondamentale du rôle de directeur des systèmes d’informations dans une entreprise. Pourtant, presque dix ans plus tard, on mesure combien ces technologies sont génératrices de richesse dès l’instant où l’on sait créer une activité et un business model qui savent les utiliser au mieux.
Une stratégie DSI en accord avec les ojectifs commerciaux de l’entreprise et son organisation
Il y a bien des façons de faire échouer un projet : que se soit par optimisme, fascination technologique, incompréhension de la stratégie des directions générales ou tout simplement orgueil, on rencontre encore beaucoup trop de système d’information plombés par des problèmes qu’ils s’auto-génèrent au détriment des services qu’ils sont censés rendre. ITIL insiste sur la nécessité d’aligner la technologie et l’organisation de la DSI avec les besoins et capacités réels liés aux affaires de l’entreprise. Ceci est vrai aussi bien en phase de conception que plus tard en phase de production et de support.
Il faut également noter que ce n’est pas parce que l’on propose la meilleure informatique du monde que l’on est en mesure de rendre le meilleur service informatique à sa société : s’il est rejeté par les utilisateurs parce que le service produit n’est pas le service métier attendu, un système informatique ne sert à rien. Le management du changement doit prendre une place importante dans la mise en place des actions stratégiques du DSI. ITIL conseille d’établir clairement le niveau de risque de la réalisation d’un projet (un « risco-mètre »). Il s’agit entre autres de mesurer le fossé qui existe entre les besoins du business et la capacité de réponse de la DSI. Ceci peut se faire en comparant l’expression de besoin du service métier attendu et le catalogue des services techniques que la production a démontré savoir produire, à condition de savoir comment assembler les services techniques pour arriver au service métier.
ITIL propose une classification des organisations liées aux risques qu’elles induisent (avec des compléments personnels) :
| Niveau de maturité | Caractéristiques | Problèmes induits |
| Artisanal (somme d’individus) | Travail basé sur les capacités d’individus communiquant peu ou pas | Planification de projet et management très aléatoires |
| Cellules artisanales (petit groupe autour d’un « artisan leader ») | Travail basé sur les capacités de petites équipes repliées sur elles-même | Pas de standard d’entreprise, pas de métrologie échangée avec « l’extérieur » |
| Organisation définie dans une vision « purement informatique » | Travail basé sur des équipes au périmètre clairement établi | Les équipes comprennent mal leur travail en tant que partie prenant d’un processus d’entreprise, l’analyse des dysfonctionnements « organisationnels » est difficile |
| Organisation avec un management DSI | Responsabilisation des équipes en tant que partie prenante d’un processus d’entreprise | Gestion difficile des changements, en particulier technologiques |
| Organisation DSI optimisée | Vision sur le long terme avec adaptation constante des processus de la DSI avec ceux de l’entreprise | Automatisation (ou plus clairement, les hommes risquent de se sentir dépossédés de leur travail – qu’ils soient informaticiens ou utilisateurs). |
NB : Il est bien nécessaire de comprendre que la recherche du niveau de maturité le plus élevé n’est pas dans l’absolu la meilleure chose à faire. Si la structure même des affaires de l’entreprise nécessite de faire travailler des individus très qualifiés mais isolés (des « artistes »), forcer le passage à une organisation avec un management DSI par exemple serait une erreur, ou dans la terminologie ITIL, on mesurerait un très grand risque d’inadéquation entre l’alignement de l’organisation de l’informatique et les besoins du business de l’entreprise.
Pour un processus donné, ITIL propose de mesurer l’écart entre besoin estimé et maturité actuelle à travers un diagramme radar prenant en compte :
| – la qualité d’exécution au sein du processus, – son niveau d’intégration, – sa capacité métrologique, – son niveau d’outillage, – son niveau méthodologique, – son niveau d’organisation, – le niveau de compétence des équipes – et le niveau atteint en terme d’objectifs du processus. |
 |
Reste cependant à définir objectivement tous ces niveaux et à y plaquer une métrologie.
Stratégie DSI pour la fourniture des nouveaux services
Une fois les objectifs clarifiés pour la DSI et l’analyse interne sur sa capacité de les atteindre, il faut mettre en œuvre les changements destinés à supprimer les manques. ITIL liste plusieurs stratégies possibles (avec des compléments personnels) :
| Stratégies | Avantages | Inconvénients |
| Insourcing (on accueille une équipe d’une société extérieure) | Contrôle, liberté de choix, acquisition rapide du savoir-faire, mise en place rapide | Coût élevé (si les compétences sont rares), problèmes légaux (délit de marchandage), fusion avec la culture d’entreprise |
| Outsourcing (une société extérieure gère chez elle vos besoins), SaaS | Économie d’échelle, pas de gestion de compétences jugées non stratégiques, on ne se préoccupe plus des problèmes « d’intendance » | Perte de contrôle, coût de désengagement, gestion plus complexe des risques, implique un plus grand contrôle des processus d’entreprise, problème postérieur du support |
| Co-sourcing (mélange in/out) | Y-a-t-il vraiment des avantages ? | Complexité du management en général, qui a la propriété intellectuelle de quoi ?, problème postérieur du support |
| Partenariat | Temps de réponse, gestion des coûts d’entrée sur un marché, compétitivité, partage d’expertise, partage des risques | Complexité des projets, qui a la propriété intellectuelle de quoi ?, problèmes de culture d’entreprise, problème d’intégration des organisation, problème d’intégration des moyens techniques, requiert un haut niveau de confiance |
| Fusion / Acquisition (ou création ex nihilo) | Contrôle, réponse rapide au marché, compétitivité maîtrisée | Coût très élevé, problème de culture d’entreprise |
Conclusion
Les rédacteurs ITIL semblent très attachés à la philosophie de management de W. Deming (planifier, faire, vérifier, (ré)agir puis recommencer le cycle). Implicitement, en adoptant cette approche, on adopte un management DSI top/down basé sur une vision stratégique et un contrôle qualité omniprésent, sans laisser beaucoup de place à l’initiative individuelle. C’est un choix discutable car la population des informaticiens est généralement qualifiée, dynamique et motivée : il faut donc veiller à les associer à la définition des objectifs.
Pour ce qui est du choix stratégique lié à la fourniture de nouveaux services informatiques, il est primordial que le DSI ait une vision exacte de ce qui est vraiment vital pour le business de l’entreprise (pas ce qui semble l’être…), ce qui est ici un problème de communication sur la stratégie de l’entreprise.
Une façon simple pour commencer à (r)établir la liste des priorités est de se demander, équipe par équipe, ce qui se passerait en cas d’absence totale pendant un jour, une semaine ou un mois (PRA/PCA). Une équipe entraînant une cessation d’activité de l’entreprise pour cause d’absence pendant un jour est vitale, pendant une semaine demande des relations réactives et de confiance, pendant un mois peut être laissé au hasard du marché. Je ne peux que déconseiller l’idée d’abandonner tout contrôle direct sur une équipe gérant une activité vitale à moins d’avoir des garanties contractuelles très solides.
Philippe RIS,
fondateur d’@uris Solutions
