Le rapport « Stratégies de migration dans le Cloud” a été publié en janvier 2023 par le Club Informatique des Grandes Entreprises Françaises (CIGREF) ; une association française qui regroupe plus de 150 entreprises, avec en commun, l’usage stratégique des technologies de l’information et de la communication (TIC).
Il traite des différentes approches à prendre en compte lors de la planification et de l’exécution des migrations cloud, en s’appuyant sur les résultats, observations, recommandations et alertes d’expériences concrètes, en cours ou achevées.
Dans cet article nous allons voir différents sujets :
La plupart des membres CIGREF sont engagés dans un processus de migration vers le cloud, a minima par des solutions SaaS, mais son usage se répand de plus en plus vers tous les secteurs d’activités.
Aujourd’hui, les entreprises se lancent dans la migration pour gagner en agilité, réactivité, flexibilité et time-to-market, tout en bénéficiant des évolutions technologiques en continu, le tout avec une couverture mondiale.
Mais une fois la migration engagée, de nouveaux avantages apparaissent ; à savoir l’optimisation des coûts IT, l’inventorisation du SI, l’autonomie des équipes de développement.
Le groupe de travail a aussi relevé une multitude d’obstacles/freins à anticiper et à prendre en considération dans la stratégie de migration :
Protection juridique et technique des données et actifs ;
Exposition aux lois extraterritoriales s’il s’agit d’un fournisseur international ;
Manque de compréhension des enjeux du cloud par les dirigeants ;
Déséquilibre des relations avec les grands fournisseurs ;
Gestion de la réversibilité lors de la migration vers un autre fournisseur ;
Maturité interne de l’organisation vis-à-vis du cloud, en termes de ressources et de compétences.
Périmètre de la migration
Aussi, la migration exige d’effectuer d’importants choix stratégiques, en commençant par le périmètre de la migration : soit des applications, soit des données.
Développement du Cloud hybride
Le cloud hybride est la solution la plus recommandée par les membres, il présente plusieurs avantages :
Optimise les relations fournisseurs et ouvre de nombreuses possibilités ;
Facilite l’optimisation des coûts, surtout avec une bonne démarche FinOps ;
Changement relatif à la perméabilité, les providers fournissent de plus en plus de solutions quasi uniques pour le cloud hybride ;
Recherche d’équilibre entre Cloud privé et public :
Certaines entreprises sont soumises à des règlementations spécifiques et doivent avoir un cloud privé ;
La migration du parc applicatif vers le cloud public est de plus en plus facile ;
Le développement de toutes les nouvelles applications se fera nativement dans le cloud public sauf contraintes spécifiques.
Il faut prendre en compte l’enjeu des données sensibles et critiques.
Le ratio des données sensibles dans l’ensemble des données est déterminant dans l’appréhension de la migration vers du cloud public. S’il est faible, l’entreprise peut migrer la majorité des actifs IT dans le cloud, et garder la partie données sensibles en interne.
L’étude CIGREF sur le “Besoin cloud de confiance” indique que 15% à 25% des données, en fonction du secteur d’activité, sont suffisamment sensibles pour devoir être protégées des risques de services cloud extra-européens.
En parallèle, on remarque une diminution du besoin cloud privé interne :
L’évolution technologique du cloud public exige d’utiliser les solutions les plus standards possibles et d’être en capacité de tenir le rythme de toutes les feuilles de route techniques des logiciels et des composants du SI ;
Pénurie de compétences pointues et rétention des équipes difficile ;
Investissements considérables liés à l’obsolescence des infrastructures ;
Enjeux de sécurité numérique à garantir ;
Exigences environnementales contraignantes sur les équipements.
On se retrouve face à trois différentes hypothèses pour l’avenir du cloud privé :
Option 1 : maintien d’une plateforme cloud privé dans les infras de l’entreprise, basée sur une plateforme spécialisée.
Option 2 : disparition du cloud privé interne au profit d’un cloud unique avec une composante “cloud public” et une “cloud privé” consistant à installer dans le domaine privé, une réplique du cloud public via une solution convergée, proposée par les fournisseurs de cloud public (ex: Azure Stack, AWS Outspot…).
Option 3 : établissement d’un modèle cloud public unique.
Enjeux du multi cloud
Deux acceptations du multi cloud sont admises :
L’utilisation dans le même SI de plusieurs fournisseurs de cloud ;
La capacité de changer facilement de fournisseur sur un plan technique, l’aspect contractuel étant le plus souvent le point d’achoppement. Cela nécessite l’interopérabilité des plateformes d’hébergement, et la portabilité des applications d’une plateforme à l’autre.
Les entreprises expriment quand même quelques doutes/réticences à se lancer dans du multi cloud :
Pour un bon niveau de sécurité, il ne faut pas mettre ses données et ses applications chez un seul fournisseur ;
Complexité du management ;
Utiliser plusieurs cloud publics signifie que les prix seront potentiellement moins avantageux chez chacun des fournisseurs.
Modalités de la migration applicative
Une entreprise participante de l’étude distingue 5 grandes étapes pour gérer sa migration applicative :
La migration applicative pose aussi la question du choix de transformation à effectuer sur les applications, à décider pour chaque application. On distingue plusieurs chemins de transformation :
Reinstall/lift & shift : est l’action de migrer l’application telle quelle.
Rehost : « lift & shift » mais avec un minimum de remédiation du système d’exploitation et des bases de données de l’application.
Replateform : permet de remplacer le niveau bas de l’application (passage vers PaaS).
Redeploy : redéploiement de l’application sur une nouvelle plateforme technique.
Rearchitect/Refactoring/Rewriting : modifie le code de l’application, avec un passage en Continuous Integration and Continuous Delivery (CICD) par exemple.
Replace : correspond à la mise en place d’une alternative.
Repurchasing : correspond aussi à l’achat de nouvelles solutions sur le marché.
Retain : maintien de l’application avec une consolidation des environnements.
Retire (Décommissionnement) : permet de se séparer de l’application.
Accenture avait publié en 2021 les niveaux de bénéfices réalisés par les entreprises en fonction du chemin de migration choisi :
Pour autant, à ce jour, seulement 30% des applications développées par les entreprises sont déployées sur le cloud. Seules les applications les plus simples ou les applications cloud natives le sont. Cet échec qui peut s’expliquer par plusieurs raisons, identifiées par Gartner :
Wrong Team : mauvais choix de partenaire ou manque d’expérience des équipes internes.
Wrong emphasis : mauvais chemin de transformation sur les applications.
Rushed Application Assessment : étude insatisfaisante du parc applicatif et de sa cloud readiness (capacité à migrer vers cloud). Pas de prise en compte de la sécurité de la migration, donc augmentation de la surface d’attaque.
Poor Landing Zone design : mauvaise configuration des environnements dans lesquels les charges de travail sont migrées peut augmenter les coûts de sécurité et de conformité.
Mistimed Work Effort : mauvaise anticipation du temps nécessaire à la transformation, faute d’échéancier réaliste.
Hidden Indirect Costs : mise en place du budget sans considérer les coûts indirects (coûts de formations, coûts des centres de données abandonnés…).
A cela, vient s’ajouter les cas des applications en Legacy, qui, dans ⅓ des cas, nécessitent un rapatriement vers les solutions on-premises de départ.
Enfin, les discussions sur la migration dans le cloud ont aussi mis en lumière 4 points clés à prendre en compte :
Suivi financier de la migration
Approche d’Accenture : évitement des coûts
Le cabinet Accenture propose une approche de comparaison financière de deux scénarios futurs :
L’organisation effectue la migration dans le cloud de son SI,
Le projet de migration n’est pas choisi et la DSI continue avec les projets et les infrastructures actuelles.
Accenture distingue ainsi 5 grandes familles de dépenses de la DSI, qu’il est nécessaire d’identifier pour avoir la cartographie des gains et coûts engendrés par la migration :
En outre, plusieurs types de coûts de pilotage sont associés à la migration dans le cloud :
Réalisation du business case ;
Intégration du FinOps ;
Conduite du changement ;
Nouveau catalogue de services ;
Niveau d’investissement nécessaire des directions métiers ;
Travail avec les métiers sur la roadmap applicative ;
Coûts de transformation des équipes et talents (upskilling en continu).
Suivi financier du passage dans le Cloud
Plusieurs éléments sont à prendre en compte pour la gestion financière des migrations :
Il paraît donc nécessaire d’adopter une démarche “FinOps”, qui permettrait de renouveler les pratiques de gouvernance par les coûts en l’alignant sur les enjeux stratégiques de l’entreprise.
Un des membres du Cigref a défini 3 piliers à cette démarche :
A la clé, les entreprises pourront tirer le maximum de bénéfices du cloud :
Maîtrise des dépenses d’exploitation OPEX ;
Rationalisation des achats ;
Amélioration du contrôle des fournisseurs de services Cloud ;
Elimination des silos organisationnels ;
Renforcement des relations de la DSI avec les services financiers et les directions métiers.
Réorganisation des équipes IT
La migration Cloud ne doit pas être considérée comme une stratégie IT, mais comme une stratégie globale d’entreprise.
Il est donc nécessaire de former une équipe cloud aux compétences multiples, qui constitue à la fois le noyau et le moteur de la migration.
Gestion des fournisseurs
Market share des fournisseurs Cloud
En 2022, le cabinet Gartner a publié son estimation de la répartition des parts de marché entre les différents fournisseurs cloud :
Les Hyperscalers
Si l’on considère les trois grands hyperscalers, Amazon Web Services, Google Cloud et Microsoft, il est intéressant de connaître les points forts et spécificités techniques ou non-techniques des fournisseurs.
Difficultés rencontrées et pistes pour réussir
Les entreprises participantes à l’étude ont identifié plusieurs difficultés quant à la gestion de ces fournisseurs cloud :
La négociation pour obtenir une offre de paiement à l’usage intéressante est plus difficile que pour obtenir des bons prix sur les instances réservées.
L’absence d’estimation fiable de la consommation réelle du service rend difficile la projection sur le nombre d’instances à réserver.
Les intégrateurs bâtissent leur expertise grâce aux connaissances acquises dans leurs REX clients, alors que les expériences achevées sont rares, à fortiori en France, puisque les projets sont récents.
D’un autre côté, leur expérience a permis de ressortir des pistes pour optimiser ses relations avec les fournisseurs :
La coordination avec l’intégrateur est primordiale.
Veiller à préparer le sprint 0 avec l’intégrateur, le faire à posteriori augmente le risque d’un sprint 0 sous-estimé.
Un accompagnement par un intégrateur, voire par un cloud provider, permet de progresser dans le domaine de la sécurité.
Pour une gestion confortable des coûts, le coût de migration cloud présenté par l’intégrateur devrait être doublé, par précaution.
Conclusion
Le sujet cloud reste riche en questions et en perspectives. La capitalisation des connaissances et des retours d’expériences est essentielle, et chaque DSI devrait étudier et analyser ces informations avant de se lancer dans un projet de migration cloud.
10 questions à poser pour transformer l’expérience collaborateur
10 questions à poser pour transformer l’expérience collaborateur
En quelques années, le poste de travail a cédé la place à une digital workplace collaborative, mobile, ouverte, rapide… Une révolution pour le support, qui doit repenser sa valeur autour de la qualité de l’expérience collaborateur.
En quelques années, le poste de travail a cédé la place à une digital workplace collaborative, mobile, ouverte, rapide… Une révolution pour le support, qui doit repenser sa valeur autour de la qualité de l’expérience collaborateur.
Dynamité, dispersé, ventilé, éparpillé façon puzzle. Quelle que soit votre expression favorite, elle décrira assez bien ce qui est arrivé en quelques années à l’environnement de travail de l’utilisateur. Bien sûr, le poste physique – l’ordinateur – existe encore ; mais les usages des collaborateurs auparavant très centrés sur ce poste le dépassent largement. Ce que l’on nomme désormais l’expérience collaborateur – et qui s’avère tout aussi critique pour l’entreprise que l’expérience client – repose sur le parcours de l’utilisateur au sein du système d’information qui lui est proposé. Et le Service Support, sans surprise, s’impose comme un pilier de cette expérience globale.
L’évolution de l’environnement de travail a finalement suivi celle des organisations et des modes de travail (nouveaux usages) – à moins que ce ne soit l’inverse. À l’ordinateur de bureau associé à des collaborateurs attachés à un site – voire à un bureau – a succédé le PC portable, levier de la mobilité externe mais aussi interne avec l’allocation libre des espaces. Aux applications explicitement estampillées « métier » se sont ajoutés des services et plateformes (réseaux sociaux, chatops, la connectivité généralisée…) à travers lesquels les frontières entre usages personnels et professionnels sont plus flous. Aux « données d’entreprise » pas toujours très partagées ont succédé des services analytiques plus largement accessibles pour mettre la donnée au cœur du quotidien de chacun.
Ces environnements plus mobiles, plus collaboratifs, plus ouverts, plus « data-centric » font chaque jour un peu plus du « collaborateur augmenté » une réalité. Et stimulent des organisations plus matricielles, plus agiles aussi. Ne sous-estimons pas cette transformation : même si quelques éléments perdurent (un poste de travail individuel, une suite bureautique…), l’environnement de travail a bien été bouleversé et, avec lui, le support. Là où les équipes IT dédiées géraient un parc et des incidents, elles doivent aussi piloter aujourd’hui la cohérence du parcours utilisateur et l’efficacité de la mise à disposition d’une grande variété d’informations et de services collaboratifs.
La satisfaction est-elle au rendez-vous ? Pas vraiment encore. Ces fonctions de supports (internes ou pas) sont considérées comme trop onéreuses, leur gouvernance s’avère difficile et, surtout, les utilisateurs et métiers sont loin d’être satisfaits… Résultat, les DSI se déclarent majoritairement mécontents des performances des partenaires auxquels ils font appel, et selon une étude IDC menée en mars 2018 près de la moitié d’entre eux (49%) envisagent d’en changer. Il faut dire que la pression monte et que le temps presse…
À l’heure où le système d’information des entreprises se consumérise – entendez que les utilisateurs l’évaluent avec le même regard que celui qu’ils portent sur Facebook ou Amazon – le service support devient la véritable vitrine de la DSI. Se joue donc ici la perception de sa valeur, de son aptitude à se transformer…
Comment assurer un support à la hauteur des nouvelles exigences ? Tout d’abord, en posant les bonnes questions :
Comment redonner de l’autonomie aux utilisateurs et leur permettre d’auto-résoudre leurs sollicitations ?
Comment apporter le bon niveau de support aux utilisateurs selon leurs métiers et leurs problématiques ?
Comment aligner les services proposés sur l’évolution des principes d’usage du web ?
Comment améliorer l’expérience utilisateur, renforcer l’attractivité, augmenter les chances d’aller au-delà du premier clic ?
Comment apporter de la visibilité sur le suivi des sollicitations ?
Comment apporter un maximum de fonctionnalités (par exemple pour la recherche, la consultation d’informations, la mise en relation…) ?
Comment proposer un accès au support 24/7/365 multi-devices, et omnicanal, donc « sans coutures » ?
Comment développer l’assistance fonctionnelle et la prise en charge des processus métier ?
Comment avoir une efficacité collaborative ?
Comment aller vers plus de centres de services tout en gardant la maîtrise ?
À travers ces questions, se dessinent en fait 4 grands chantiers : développer l’autonomie des utilisateurs, différencier le support selon les métiers ou l’utilisateur, intégrer les nouveaux usages et développer l’assistance fonctionnelle. Des chantiers qui dessinent une nouvelle Digital Workplace.
Repenser la chaîne de support en intégrant la dimension digitale liée à des innovations technologiques et des nouvelles pratiques est une réelle opportunité pour la DSI. Elles verraient ainsi leur service support amélioré et leur relation client renforcée.
Industrialiser les processus et automatiser les actions de tous les acteurs du back-office
Apporter de la visibilité sur le suivi des demandes et des incidents ; Piloter vos prestataires infogérants.
Anticiper les incidents et les changements grâce à une CMDB efficace
Gérer et maîtriser son parc informatique matériel et logiciel (ITAM et SAM) et réduire ses dépenses
Proposer la meilleure expérience utilisateur possible tout en renforçant l’attractivité de votre portail de services et en augmentant l’autonomie de vos collaborateurs (Self-Care)
Optimiser les coûts CAPEX & OPEX et le ROI sur vos outils ITSM/ESM
Augmenter la valeur perçue par vos utilisateurs de la chaîne de support et de delivery des DSI
Nos offres
Définir la stratégie ESM
Audit et mesure de la maturité
Co-construction de la stratégie digitale ESM*
Etude et préconisation d’une trajectoire cible
*ESM = Enterprise Service Management (ITSM/ ITAM/ ITOM/ PPM…)
Optimiser les processus
Audit et analyse de l’existants
Optimisation ou refonte des processus selon les référentiels ITIL
Définition de l’organisation cible alignée avec les nouveaux processus
Rationaliser l’usage des outils
Cartographie et analyse des outils existants
Sourcing et accompagnement à la contractualisation de l’outillage et/ou de prestations d’intégration
Préconisation et alignement des outils par rapport aux besoins fonctionnels et aux bonnes pratiques
Accompagnement pour la mise en place du plan d’actions
Pilotage de la mise en oeuvre
Gouvernance dédiée autour des projets ESM
Suivi de la performance des services : éditeur / prestataires intégrateurs
Mise en place d’un plan de conduite du changement
Des bénéfices clés pour votre organisation
Amélioration des niveaux de services
Standardisation des processus à hauteur de 80%
Amélioration de l’expérience utilisateur (accès aux services en 3 clics, augmentation de l’autonomie et du self-care)
Atteinte des objectifs de conformité des actifs IT
Je vous propose une analogie sur l’évolution de l’Homme préhistorique et la métamorphose du métier de contrôleur de gestion depuis son origine à aujourd’hui.
Au cours de mes 20 ans d’expériences professionnelles en Finance, j’ai vu le métier de contrôleur de gestion progresser dans le chemin de la création de valeur et de l’accompagnement des métiers et des opérations sur des enjeux financiers et de performance.
Alors parfois le contrôleur de gestion suscite une certaine suspicion de la part de ses interlocuteurs : Vient-il nous couper les budgets ? Sa vision financière ne va-t-elle pas s’opposer à la vision opérationnelle ? Qui mieux que les opérationnels sont susceptibles de fiabiliser des forecasts ?
Ma conviction est qu’à deux on est plus forts et que c’est la combinaison des 2 mondes Finance & Opérations qui fait et fera la force du Contrôleur de gestion de demain. Alors oui, le contrôle de gestion est une fonction dite « support » dans les organisations et il n’est pas au coeur du réacteur mais c’est un allié incontournable pour sécuriser la stratégie de l’entreprise.
L’âge de pierre & la production taylorienne : le contrôleur budgétaire
Le Contrôleur de gestion homo habilis
Le Contrôleur de gestion Homo habilis (homme adroit) est considéré comme le premier représentant de l’espèce des Contrôleurs de gestion.
Il est apparu il y a environ 100 ans, d’abord aux Etats-Unis puis ensuite en Europe en fonction des besoins des entreprises et de l’évolution du monde technique et économique avec les analyses de Taylor (1905) sur le contrôle de productivité, les recherches de Gantt (1915) sur les charges de structure et les choix de General Motors (1923) et de Saint-Gobain (1935) pour des structures par division.
A l’époque, il ne s’appelait pas encore Contrôleur de gestion, mais il apprenait déjà à s’occuper des activités de production, et à contrôler un certain nombre de tâches déléguées à la tribu.
Jusqu’au début des années 60, il vivait dans des abris parfois rudimentaires inspirés du modèle des premières firmes industrielles américaines. Afin de protéger la production contre d’éventuels prédateurs, il avait adopté les règles de vie et de gestion taylorienne fondée sur 4 principes :
stabilité dans le temps ;
information parfaite des dirigeants ;
recherche d’une minimisation des coûts ;
coût de production dominant dans le coût total.
Il fut le premier à se servir d’outils simples (monofaces) qu’il taillait autour du système de pilotage pour pouvoir mesurer et contrôler la productivité industrielle et en particulier la productivité du travail direct.
Nomade et premier bipède, il se déplaçait sur ses deux jambes Objectifs-Moyens pour aller chercher sa nourriture en réalisant de courtes distances, mais en mettant à disposition tout au long du chemin des informations et des éléments permettant de mesurer le chemin parcouru et les résultats.
Il vivait en petit groupe dans une structure hiérarchique découpée verticalement en centres de responsabilités.
Il se nourrissait essentiellement de gestion de la production et du processus de planification, dans un objectif de productivité et de rationalisation.
Le contrôleur de gestion Homo habilis est donc un contemporain des industries dites de « l’âge de pierre et de la production taylorienne ». Il pratiquait alors le contrôle budgétaire.
L’âge du feu et de l’expertise financière : le contrôleur de gestion
Le Contrôleur de gestion Homo erectus
Le contrôleur de gestion Homo erectus (homme debout) est un grand voyageur.
Il se déplace et est confronté dans le temps, à l’augmentation de la concurrence et à la globalisation de l’économie.
Il apparaît dans les années 60 et commence sa longue mutation en apprenant à vivre aux côtés d’autres tribus émergentes avec lesquelles il s’installe à proximité des lacs et des rivières :
Dans la décennie 60 : la tribu Commerce née de l’augmentation de la concurrence et de la globalisation de l’économie. Il y apprend que tailler la pierre et produire ne sont plus les seuls maîtres mots : il faut, pour lui, adopter une démarche mercatique (l’inverse de celle du producteur de l’âge de pierre de production) pour connaître et répondre aux exigences de son marché avant de produire les biens. Ses outils ne sont plus monofaces mais deviennent bifaces ; lui imposant alors la nécessité d’être flexible dans les choix de production et de diversifier ses produits.
Dans la décennie 70, la tribu Ressources humaines née de la prise en compte de l’individu et de son rôle clef dans la tribu. Durant cette période, le bien être des bipèdes de la production sont mis au cœur des organisations et du système de production. Les abris rudimentaires ne suffisent plus : ils font place à des huttes faites de branches ou d’ossements d’animaux recouvertes de peaux de sorte à ce que chacun s’y sente bien.
Dans la décennie 80, la tribu Finance, à laquelle le Contrôleur de gestion Homo erectus va tout naturellement venir se rattacher. Il apprend à maîtriser le feu et assure ainsi la performance financière de la tribu qui apparaît alors comme prioritaire. La performance va permettre aux premiers hommes : d’éloigner les prédateurs, d’être rentable, de fiabiliser et challenger les forecasts et de pérenniser ainsi la survie de l’espèce.
Dans les années 90, une ère avec une approche systémique apparaît : mettant en évidence les influences réciproques, multiples et permanentes des 4 tribus (Production – Commerce – Finance – Ressources Humaines). La découverte des interdépendances entre tribus et la nécessité de mettre la stratégie au cœur de ses réflexions lui permettent de chasser des animaux plus gros et de se positionner naturellement comme un fédérateur capable d’intégrer toutes les variables de gestion opérationnelles et de faire le lien entre toutes les tribus.
Doté d’une capacité crânienne de 850 à plus de 1000 cm3 et d’une tête osseuse caractéristique : une mâchoire puissante, un prognathisme marqué, des os épais, un front assez bas, pas de menton, un bourrelet sus-orbitaire et une carène sagittale plus ou moins marquée, il a amélioré les techniques de taille en réalisant ses premiers bifaces. Ses outils révèlent l’existence de comportements nouveaux dans la lignée des contrôleurs de gestion : l’élaboration d’outils, une forte adaptation des outils aux conditions locales et aux besoins humains, le développement de modèles parmi lesquels nous retiendrons :
Le développement de la méthode ABC (Activity-Based Costing)
Le développement de l’ABM (Activity-Based Management)
Le développement de l’EVA (Economic Value Added)
Les tableaux de bord & le BSC (Balanced Scorecard)
La maîtrise du feu et des outils informatiques vont favoriser et conforter le Contrôleur de gestion Homo erectus dans son positionnement transverse, faire de lui un acteur privilégié et central dans l’organisation, lui donner sa légitimité d’expert du pilotage de la performance économique.
L’âge de la pierre polie et de la création de valeur : le Business partner
Le Contrôleur de gestion Homo sapiens
Il y un peu plus de 20 ans les premiers Contrôleurs de gestion Homo Sapiens (homme savant) font leur apparition dans un environnement turbulent dans lequel le rythme du changement s’accélère, le cycle de vie des produits se réduit et les transactions se complexifient.
Ils sont les précurseurs directs du contrôleur de gestion moderne de demain.
Ils commencent à cultiver la mise en place de KPI adaptés aux nouveaux objectifs stratégiques de leur communauté ; à savoir la recherche de flexibilité, de réactivité et d’innovation.
C’est surtout dans le domaine de l’art de s’adapter à l’innovation et à l’augmentation exponentielle des données qu’il se distingue de ses ancêtres :
Traitement de l’information : place centrale et prépondérante dans le processus décisionnel. Dans un environnement devenu de plus en plus instable et complexe, les chamans des tribus doivent disposer en permanence d’informations précises et fiables pour mettre au point et déployer leur stratégie.
Maîtrise de l’informatique décisionnelle et des solution informatisées destinée à améliorer la prise de décision des bipèdes leaders dans l’organisation.
Ouverture de ses compétences à la Business Intelligence (BI) et notamment la connaissance et la maîtrise d’applications, d’infrastructures, d’outils et des meilleures pratiques qui permettent l’accès à l’information en vue de son analyse pour améliorer et optimiser les décisions. Cette ouverture permet aux tribus de transformer leurs données en informations exploitables et donc d’accélérer et d’améliorer la prise de décision.
Les contrôleurs de gestion Homo sapiens font parfois face aux réticences de certains membres de la tribu qui ne croient pas en leur valeur ajoutée. Pour contourner ces obstacles, un rattachement à une nouvelle tribu se développe parfois. Le contrôle de gestion n’est plus intégralement rattaché à la tribu Direction financière, mais chaque tribu métier possède son propre contrôleur de gestion : on a ainsi un contrôle de gestion commercial, un contrôle de gestion industriel, un contrôle de gestion du système d’information…
Ils s’y sédentarisent et habitent dans les villages avec les métiers où ils ne sont plus considérés comme l’œil de Moscou et ont accès aux informations opérationnelles. Dans certaines tribus, ce sont des ingénieurs qui sont formés à la gestion qui occupent ces postes. Ils sont parfois jugés plus pertinents et dotés d’une plus grande légitimité car ils ont la maîtrise technique du métier. Ce changement de positionnement a contribué à améliorer leur crédibilité
C’est alors le début du néolithique (âge de la pierre polie), dans laquelle le contrôleur de gestion Homo sapiens doit mettre à profit son rôle de conseil, au-delà du contrôle et du pilotage de la performance économique qu’il exerçait jusqu’à présent. Son savoir-faire repose de plus en plus sur des compétences hybrides qui contribuent à réconcilier les deux tribus de la Finance et des Opérations.
On distingue alors deux profils de bipèdes Contrôleurs de gestion :
Les contrôleurs de gestion dits centraux, au camp, plus éloignés de l’activité opérationnelle d’élevage et d’agriculture. Leur client principal est le Chaman de la tribu et leur activité relève pour l’essentiel du reporting.
les contrôleurs de gestion dits opérationnels, souvent décentralisés et totalement immergés dans l’activité. Ils travaillent en étroite collaboration avec les artisans opérationnels et sont chargés de remonter leurs éléments au contrôle de gestion central à des fins de consolidation.
Le contrôleur de gestion Homo sapiens devient progressivement un artisan clé d’aide à la décision et force de proposition pour orienter des choix souvent stratégiques.
Passé maître dans la façon de tisser et cultiver des liens au contact des tribus métiers afin de leur faire prendre en compte la dimension et les enjeux financiers, il se positionne comme Business partner.
Le contrôleur de gestion expert de l’âge du feu, « gardien du temple » ou « garde-fou » au sens de Lambert et Sponem, évolue vers un métier de Business Partner avec pour principales missions de :
Savoir apprécier les décisions prises et mesurer les risques associés
Savoir conduire les opérationnels vers des objectifs ambitieux
Apporter des idées et suggestions pour améliorer la performance globale
La maîtrise des outils informatiques, la montée en compétences sur des sujets opérationnels et métiers, la recherche de valeur ajoutée constituent les fondamentaux du développement des premières grandes civilisations de Finance Business Partner et permettent au Contrôleur de gestion d’être et de rester un allié incontournable et essentiel à la tribu, notamment dans tout l’Occident.
Ainsi s’achève la Préhistoire du Contrôleur de gestion et….. c’est maintenant que l’Histoire commence…
Dans un monde où les ruptures stratégiques, technologiques ou sanitaires s’accélèrent, les stratégies sont mises à rude épreuve. Ces stratégies intègrent de plus en plus de composantes digitales dans une logique où les business models ne sont plus « simplement » supportés par l’IT mais où c’est l’IT qui réinvente les business models. Aujourd’hui l’IT devient le business.
Imaginer et concevoir des innovations de valeur à fort contenu digital ne suffit plus car il est nécessaire d’organiser une mise en œuvre de l’IT à même de répondre avec flexibilité et rapidité aux enjeux tout en assurant sécurité et résilience des opérations IT. Dans ce contexte, il devient plus délicat de traduire ces nouvelles exigences du Run en capacités opérationnelles. Et sauf à vouloir se prendre les pieds dans le tapis , je ne recommande absolument pas de se « jeter » sur la construction d’organisations cibles avant d’avoir compris pour qui et comment ces organisations doivent créer et délivrer de la valeur.
Tout le monde a une stratégie avant de se prendre un direct en pleine face.
Mike Tyson
Sur la base de mon expérience de conseil, j’ai ainsi souhaité partager dans ce billet une solution relativement élégante pour adresser cet enjeu. Il s’agit d’adapter le modèle opérationnel du Run en créant un modèle opérationnel cible (TOM) qui intègre les différents changements nécessaires au modèle existant afin de traduire les nouvelles exigences du Run en capacités opérationnelles. Ce billet aborde ainsi 3 points :
Qu’est ce qu’un modèle opérationnel et quels étaient jusqu’à présent les principaux modèles opérationnels pour les activités de Run ?
Quelles sont les principales tendances qui poussent à adapter le modèle opérationnel du Run ?
Quand et comment procéder pour adapter le modèle opérationnel du Run ? Quelles sont les nouvelles tendances en matière de modèles opérationnels du Run ?
1. Le modèle opérationnel du RUN
Un modèle opérationnel fait le pont entre stratégie et exécution et décrit comment l’organisation va créer et délivrer la valeur. On peut définir un modèle opérationnel à l’échelle d’une entreprise toute entière, d’une business unit ou même d’une fonction (ex. la DSI) ou encore une sous-fonction (ex. le Run de la DSI). Comme il n’y a pas de définition vraiment standard, je vous propose 3 illustrations que j’ai adopté et qui permettent chacune d’aborder le modèle opérationnel sous un angle différent.
Illustration n°1 : si vous êtes familier avec le business model canvas de Alex Osterwalder et Yves Pigneur, on peut déjà considérer que le modèle opérationnel se positionne comme le back-end du business model en intégrant les activités clés, les ressources clés ainsi que les partenaires/partenariats clés.
Illustration n°2 : d’autres à l’instar de Andrew Campbell de l’université d’Ashbridge tentent de populariser l’operating model canvas en agençant avec plus de détails le back-end de l’illustration n°1
Ce qui est intéressant dans ce modèle, outre la mention des Locations (lieux géographiques d’exécution) et de Information (structures et flux d’information), c’est l’apparition des Value Delivery Chains censées traduire la logique des chaînes de valeur nécessaires au delivery des propositions de valeur. De mon point de vue, cette notion est fondamentale à tout modèle opérationnel.
Illustration n°3: enfin, j’ai aussi dans mon attirail une autre façon de représenter les modèles opérationnels que j’ai peaufiné au fil du temps et à laquelle je tiens beaucoup.
Ce qui est intéressant dans ce modèle est la prise en compte de l’axe culture (organisation informelle et l’humain) qui rappelle que les opérations s’exécutent souvent sur la base d’habitudes de collaboration, de valeurs et de soft-skills spécifiques et ce indépendamment des structures organisationnelles et des processus. L’autre point fondamental est l’introduction de la gouvernance qui représente le système nerveux du modèle opérationnel et sa clé de voûte.
C’est donc en s’appuyant sur un certain nombre de modélisations que l’on se forge à la fois des convictions et des outils pour adapter les modèles opérationnels et plus spécifiquement dans ma pratique : les modèles opérationnels du Run.
Afin d’être plus spécifique et encore à titre d’illustration, je schématise ci-dessous les 2 modèles opérationnels du Run beaucoup rencontrés ces dernières années.
Le modèle des silos technologiques
L’organisation par silos technologiques n’a plus vraiment cours aujourd’hui car elle présente un certain nombre de challenges et inconvénients commentés dans l’illustration ci-dessus.
Le modèle PLAN-BUILD-RUN avec un RUN orienté par activité
Ce modèle opérationnel de Run intégré dans le modèle Plan-Build-Run de la DSI fait la part belle aux activités. Il organise en effet les opérations IT en usines qui regroupent les activités par niveaux d’interventions (N0 – Hébergement, N1 – Exploitation, N2 – Administration, N3 – Expertise) quelles que soient les technologies et métiers concernés. A l’instar des modèles déployés par les grands prestataires, ce modèle vise le plus souvent à industrialiser les opérations en déployant des processus standards ITIL. L’inconvénient majeur de ce modèle est de reléguer le Run en bout de chaîne, sclérosant ainsi toute la chaîne de delivery et ne favorisant ainsi pas l’agilité.
Certaines déclinaisons récentes de ce modèle tentent de fluidifier davantage la chaîne de Build pour conduire à des modèles un peu différents qui distinguent la gestion des socles techniques de celle des services.
Sur ces bases, on a pu voir se dessiner des modèles d’organisations détaillées ressemblants au schéma ci-dessous.
Alors disons le tout de suite, aucun de ces modèles n’est la panacée mais tous ont un intérêt pour exécuter les activités de Run. Il est donc important de capitaliser sur l’expérience des différents modèles et comprendre valeur et utilisation des briques de bases. C’est ainsi que l’on disposera de bonnes bases pour entamer une phase de réflexion et de conception quand il s’agira d’adapter le modèle opérationnel du Run aux nouveaux enjeux. Et justement comme nous allons le voir dans la prochaine section les raisons de changer sont multiples et souvent impérieuses.
2) Tendances d’évolution et d’adaptation des modèles opérationnels du RUN
Comme je le mentionnais en introduction, l’IT est aujourd’hui au coeur du business et les DSI doivent faire face (quand ce ne sont pas les Chief Digital Officer) à de nombreux impératifs pour rendre possible / faciliter la transformation du business et des métiers.
Au-delà de ces impératifs, s’ajoutent plus classiquement les demandes de réduction de coûts et des risques ainsi que le besoin de transparence accrue. Evidemment, et pour finir, on peut trouver les nombreuses tendances technologiques actuelles et à verniret qui sont autant d’opportunités/leviers de transformation.
Ces impératifs pressurisent les modèles opérationnels en place et les tendances technologiques mettent le plus souvent en évidence l’impréparation et l’inadéquation des capacités d’IT Management. C’est donc sur ces bases que les organisations de type DSI doivent se réinventer en adoptant des modèles opérationnels plus adaptés.
3) Quand et comment adapter le modèle opérationnel du run ? quelles pistes d’évolution ?
Avant de s’engager dans un projet d’adaptation du modèle opérationnel du Run, il est nécessaire de bien cadrer les raisons qui poussent à changer et définir un tant soit peu les modalités du projet d’adaptation de TOM. Généralement cela passe par un cadrage stratégique permettant d’établir les éléments structurants du projet d’adaptation du modèle opérationnel :
Objectifs du projet d’adaptation
Évaluation des bénéfices attendus, impacts et facteurs de risques
Définir les meilleures options organisationnelles pour mener le projet d’adaptation
Éclairer la prise de décision
L’élément le plus important et difficile étant l’évaluation des bénéfices attendus et des impacts à anticiper. Sans révéler de secrets, c’est le plus souvent un timing particulier sous tendu par des forts enjeux / opportunités qui incite à se lancer dans l’adaptation d’un modèle opérationnel et ce principalement dans 4 situations types :
Vous démarrez quelque chose de totalement nouveau
Vous changez de stratégie
Vous avez des problèmes de performance
Vous mettez en oeuvre un changement majeur
Dans le contexte d’une DSI et des implications sur le Run, il peut s’agir de plusieurs structures qui fusionnent / se rapprochent avec chacune une organisation de Run; d’un programme structurant de modernisation IT, d’une globalisation des opérations IT pour delivrer des services IT à l’ensemble des pays d’une entreprise, ou encore d’une transformation agile de l’entreprise et/ou de la DSI.
Ensuite vient le travail à proprement parler sur la définition du TOM. La description détaillée d’une méthodologie ne rentre pas dans le cadre de ce billet mais néanmoins je recommande de toujours démarrer par la définition de la Value Chain Map ou chaîne de valeur permettant de délivrer la proposition de valeur attendue / en ligne avec la stratégie à exécuter. A titre d’illustration, ci-dessous la chaîne de valeur que l’on pourrait trouver dans une DSI classique
Cette étape, n’est pas facile car si – par exemple – on souhaitait redéfinir cette chaîne de valeur, il pourrait être difficile de choisir la meilleure manière de la segmenter l’offre de service et de définir l’enchaînement des différents macro-processus créateur de valeur. En général, il faudra choisir de segmenter les chaînes de valeur par type de clients internes/externes ou par besoin clients ou par pays ou par produits/services ou bien encore par technologies (l’exemple du modèle opérationnel par silos technologiques).
Dans tous les cas, il ne faut absolument pas jouer aux apprentis sorciers et improviser : une bonne dose d’analyse et de pragmatisme est nécessaire mais on peut aussi s’inspirer de tendances très actuelles (quoique peu documentées) dans la définition de modèles opérationnels adaptés aux enjeux décrits dans la section n°2.
Une piste qui me paraît intéressante étant de s’inspirer du standard IT4IT de l’Open Group qui propose un début de modèle opérationnel organisé autour d’une chaîne de valeur et de Value Streams spécifiques à L’IT à l’instar de certains domaines métiers qui ont développé des Value Streams maintenant connues comme : make-to-order, order-to-cash,…)
Ainsi le point de départ IT4IT se compose des Value Streams suivantes qui sont orientées besoins client et remplacent avantageusement la classique segmentation Plan, Build, Deliver, Run et sont de nature à casser un fonctionnement en silos peu propice à l’agilité. Ce découpage est d’ailleurs la clé pour évoluer vers un modèle où le Build est beaucoup moins prépondérant et est remplacé par une logique de Broker/Intégrateur/Orchestrateur.
Ce rôle de Broker/Integrateur/Orchestrateur sera principalement mis en oeuvre au travers des capabilities de la value stream « Request to Fulfill » qui seront en charge de cataloguer, mettre en oeuvre et suivre l’usage des différents services standards.
Les impacts de cette nouvelle « value chain » sur le Run sont structurants. Le Run ne sera plus isolé en bout de chaîne et participera aux autres value streams dans une logique de collaboration avec les autres parties prenantes. C’est cette logique d’agilité qui s’affranchit des frontières organisationnelles qui sera propice à la construction de modèles opérationnels Digital Ready intégrant nativement des mécanismes opérationnels comme DevOps et FinOps par exemple.
Une fois la colonne vertébrale de la value chain définie, on peut s’attaquer – sans dogmatisme – aux autres éléments (partenaires, géographies, modèle d’organisation ou capabilities map, culture,..) en fonction de leur importance dans la stratégie et des enjeux de valeur à délivrer.
En guise de conclusion
Voilà pour ce petit tour d’horizon de l’adaptation des modèles opérationnels DSI pour traduire les nouvelles exigences du Run en capacités opérationnelles. Pour conclure, il faut retenir que le modèle opérationnel n’est que le Blueprint de l’organisation cible et que cette logique s’inscrit dans une démarche plus globale de transformation
En attendant, de démarrer vos projets d’adaptation, vous pouvez toujours évaluer si votre modèle opérationnel (qu’il soit formellement défini ou pas) permet de délivrer la bonne valeur aux bons clients (internes ou externes).
