Nous sommes des consultants en transformation digitale, c’est à dire des praticiens de la transformation numérique des entreprises, et pour ce faire nous respectons des principes auxquels nous sommes attachés mais avec deux limites :
Un de nos principes d’action est la ségrégation des rôles sur les projets de transformation numérique, notamment entre les métiers et les solutions architectes. Mais parfois notre rôle de consultant en transformation digitale, jouant le rôle de go-between entre les métiers et les architectes ou les chefs de projet IT, est fondamental pour coller à la réalité du terrain et du contexte de nos clients. Exemple choisi sur l’opportunité de profiter d’actifs ou de solutions existantes.
Un de nos principes d’action : la séparation des préoccupations
Un des principes que nous appliquons toujours, que ce soit en phase amont de cadrage de transformation, ou en phase de mise en œuvre est ce que j’appelle le respect des rôles de chaque acteur sur l’utilisation des technologies.
Ce principe s’inspire du MDA (Model Driven Architecture) de l’OMG. C’est à dire qu’il y a 3 grands niveaux d’abstraction à définir lorsqu’on veut construire ou intégrer un actif numérique dans une organisation :
- le modèle métier (Computation Independent Model – CIM)
- le modèle logique (Platform Independant Model, PIM)
- le modèle physique (Platfom Specific Model, PSM)
Nous ne nous suivons pas du tout le MDA en tant que méthode de réalisation par les modèles. Simplement, pour nous, ces 3 grands modèles permettent de distinguer 3 rôles majeurs sur les projets de transformation
- le métier : qui doit rester sur des préoccupations métiers : processus, données et exprimer un besoin indépendant des solutions numériques
- l’architecte : qui propose des solutions
- les chefs de projets informatiques : qui vont définir avec le métier ce qui est dans et hors périmètre, en fonction des solutions retenues, puis, toujours en dialogue constant avec les métiers : implémenter (coder ou paramétrer) des réponses aux besoins détaillés avec les solutions identifiées
Une interprétation, parmi d’autres, de ce principe de séparation
Nous constatons souvent que cette séparation claire des préoccupations est souvent extrapolée au cycle de vie des projets sur le mode : « la seule façon de faire un projet est d’exprimer un besoin (par les métiers), puis l’architecte va chercher des solutions éligibles et aider le métier à finaliser un choix, puis ensuite on va passer dans une phase de réalisation / implémentation, ….
Bref un schéma de ce type, classique et que nous expliquons également dans nos formations à la gestion de projet numérique
Cycle de vie d’un projet IT sur base progicielle
Mais cette démarche n’est qu’une interprétation parmi d’autres de ce principe de séparation des préoccupations et modèles entre les métiers, les architectes et les chefs de projet informatiques.
La réalité est parfois plus complexe. Par exemple, nombre de nos clients sont confrontés à des opportunités d’utilisation d’un actif technologique existant.
- une filiale qui peut bénéficier d’un actif technologique de sa maison mère
- le rachat d’une société par un fond d’investissement qui permet de bénéficier d’un ERP plus moderne
- …
Dans d’autres cas et simplement pour reprendre un des principes de l’effectuation propre à Philipe Silberzahn : on part des moyens disponibles pour imaginer de nouveaux buts. Sans entrer dans le détail de la théorie de l’effectuation par Philippe Silberzahn je vous invite à lire le chapitre « Construire la stratégie à partir de la technologie » de cet article.
Le rôle du consultant en transformation digitale pour coller à la réalité ou au contexte client tout en respectant le principe de séparation
Dans ce type de contexte, le consultant en transformation digitale trouve sa place aux côté de l’architecte. A condition qu’il connaisse bien un actif technologique, ou a minima qu’il sache activer chez l’éditeur ou le constructeur les sachants pouvant répondre à ses questions ET qui qu’il puisse vérifier et tester ce qui lui est annoncé.
Le consultant en transformation digitale et l’architecte SI
Le rôle du consultant en stratégie et transformation va être de trouver un chemin qui permette de tirer parti d’un actif technologique (ou d’enterrer définitivement cette opportunité si aucune cible d’utilisation pertinente ne peut être trouvée). Pour cela il va :
- Ramener en permanence les métiers à leurs besoins et leurs enjeux (et les y aider),
- Lutter contre leur enthousiasme inconditionnel pour une solution (les commerciaux des éditeurs ont encore de beaux jours devant eux !)
- Lutter contre leur découragement soudain et leur envie de tout abandonner et de repartir d’une feuille blanche (en espérant le grand soir et en oubliant tous les risques et coûts liés à ce grand retour à zéro)
- Qualifier le nécessaire de l’accessoire, quantifier les besoins pour ramener du chiffre et du rationnel et limiter l’émotionnel dans les arbitrages (périmètre, priorisation de cas d’usage, …)
- Définir des solutions organisationnelles ou de processus lorsque la solution ne répond pas à un besoin et ne peut pas être adaptée sous peine de faire exploser les coûts du projet et surtout les coûts récurrents du maintien en condition opérationnelle (c’est souvent le cas pour les solutions de type ERP)
- Eclairer en permanence les différents scénarios notamment leurs impacts sur les coûts de projet et sur les coûts récurrents de Maintien en Condition Opérationnelle (MCO)
