Définir organisation et rôles de la Transformation

  1. Demander un bilan de la Transformation

    La Direction Générale identifie bien des domaines de progression dans les Opérations comme l’optimisation de la Supply Chain, ou les Processus de Vente, ou les Processus de Back Office.
    Des moyens sont budgétés pour améliorer ces Processus Opérationnels.

    Par contre la Direction Générale n’accorde généralement que peu de ressources à l’amélioration des Processus de Transformation. D’une part parce qu’elle a rarement conscience du coût global de la Transformation, d’autre part parce qu’elle n’imagine pas qu’il soit possible de fortement progresser dans ce domaine : les projets comportent des risques, on n’y peut pas grand-chose.

    Il est donc nécessaire d’effectuer : Un bilan de ce que coûte la Transformation à l’Entreprise : non seulement les coûts des Développements Informatiques, mais aussi la charge pour les Acteurs Métier, les Outils de Transformation, les coûts pour le management et la gouvernance associée, les formations pour les Acteurs opérationnels, les traitements en double, les migrations d’informations, ... Un bilan du degré de satisfaction sur les délais de création ou modification de Solutions, et sur la qualité des Solutions.

    Ce bilan fera nécessairement apparaitre que le coût global de la Transformation et que la frustration des Métiers vis-à-vis de l’Agilité des Solutions méritent que l’on prenne ce problème à bras le corps.

  2. Il existe de nombreux Rôles dans la Transformation

    Il existe de nombreux Rôles Métier dans la Transformation tels que:

    • Administrateur de Données
    • Analyste
    • Architecte Métier Fondations
    • Architecte Composants
    • Architecte Sécurité
    • Architecte Métier Solution
    • Chef de Projet Métier
    • Concepteur de Produit/Service
    • Concepteur Solution Métier
    • Configurateur de Solution
    • Ergonome
    • Formateur
    • Gestionnaire du Changement
    • Maitre d’Ouvrage
    • Marketer
    • Méthodologue
    • Organisateur
    • Responsable Qualité
    • Responsable Sécurité
    • Responsable Solution Métier
    • Sponsor
    • Stratège
    • Urbaniste Métier

    La liste est loin d’être exhaustive ; qui plus est, elle change selon les organisations.

  3. Comment classifier les rôles de la Transformation ?

    Plutôt que de lister un sur-ensemble des Rôles qui peuvent exister dans la Transformation, nous avons cherché à structurer cette liste en respectant les découpages qui ont été préconisés.

    • Stratégie : Stratège, Sponsor
    • Offre de Produits et Services
    • Modèle d'Opération
      • Architecture d’Entreprise : Architecte Métier, urbaniste, administrateur de données
      • Modèles de Solutions : chef de projet, analyste, concepteur de Solution informatique, configurateur de Solution
      • Fondation de composants pour construire les Modèles de Solutions : Architecte Métier et Architecte Technique, Architecte Sécurité , ergonome, support des fondations auprès des constructeurs de Solutions
      • Déploiement de Solutions : Formateur, gestionnaire du changement, organisateur, évaluateur de Solution
    • Modèles de Transformation : méthodologue, responsable qualité
    • Support de la Solution auprès des utilisateurs : hotline

    Dans chacune des catégories peuvent exister différents niveaux hiérarchiques selon la taille de l’équipe.

    La seule recommandation que l’on peut faire est de ne pas multiplier les Rôles d’Acteur pour ne pas multiplier les tâches de gestion et d’interaction : si on a le choix, il vaut mieux peu d’Acteurs de haut niveau et donc polyvalents, plutôt que de nombreux Acteurs spécialistes.

    Ce n’est pas parce que « qualité », « sécurité », « ergonomie », « urbanisme », « organisation », « méthode », « intégration », « performance », « tests »...sont importants qu’il faut avoir autant de Rôles différents. La multiplication des Rôles accroit les problèmes de suivi, de coordination et d’intégration, et déresponsabilise les équipes. Encore une fois, chercher plutôt des intervenants de qualité capables d’assumer plusieurs rôles.

    Pour chaque rôle il faut ensuite préciser la mission. Nous en donnons quelques exemples :

    Role Mission
    Sponsor Définit le But, approuve le nouveau Modèle d’Entreprise qui respecte ce But, accorde le budget, suit l’avancement de la Transformation et supporte l’équipe de Transformation dans ses difficultés.
    Marketer Définit les nouvelles Offres : Produits et Services offerts par l’Entreprise, Marché, prix, construit l’Image de l’entreprise
    Chef de projet Solution Décrit les exigences, conçoit les Informations et les Processus, choisit d’acquérir ou de construire la Solution, mène le projet, organise la personnalisation de la Solution, les tests, la recette
    Configurateur Solution Utilise paramétrage, moteur de règles et moteur de workflow pour configurer le Modèle de Solution (règles de tarification, de contrôle, de commissionnement...)
    Gestionnaire du changement Communique auprès des Acteurs Opérationnels, installe matériels et logiciels, forme les utilisateurs, organise la hot line, suit la migration des Informations
    Architecte Métier Définit ce qui est commun aux différentes Solutions : les Objets du Métier, le plan d’ensemble des Solutions, les échanges entre Solutions, les composants communs aux différentes Solutions (sécurité, ergonomie, tarification…), les patterns de processus
    Méthodologue Définit l’Approche de Transformation, forme les Transformateurs, aide les chefs de projets, audite les projets, choisit les Outils des Transformateurs
                   

  4. Des rôles nouveaux apparaissent

    Le Big Data génére de nouveaux Rôles ; difficile de s’y retrouver entre les

    • « Chief data officer » : transmettre au comité de direction les observations fondées sur les données, afin d’éclairer les prises de décision
    • « Directeur de l’expérience client » : fonction trasversale pour aider les lignes métier
    • Chief Customer Officer » (CCO) : supervise le marketing, les ventes, ou le service à la clientèle
    • « Data scientist »
    • « Data Officer »
    Mais cette éclosion de nouveaux rôles illustre la nécessité d’Acteurs transversaux aux Unités qui gèrent les lignes Produits : on ne gère pas que les Produits/Services, on doit aussi gérer le Client dans sa globalité.

  5. Focus sur les Rôles qui concernent le « Bien commun »

    Les rôles de Constructeurs de Solutions ou de Produits/Services existent dans les Entreprises actuelles, sous des noms différents.
    Par contre les Rôles transversaux qui créent la synergie, la cohérence, les économies d’échelle au sein de l’Entreprise ne sont pas toujours présents. Il s’agit des rôles qui prennent en charge le Bien commun et qui sont rattachés à l’équipe « Fondation »:

    • Les Composants pour construire les Modèles de Produits et Services : elle est spécifique à chaque domaine d’activité. Les composants dans les bâtiments ne sont les mêmes que dans la chimie.
    • Les Composants pour construire les Modèles de Solutions ***: par contre cette Fondation de composants peut être utile à différents Métiers
      • Fonctions Métier telles que Tarifer, Contrôler l’éligibilité, Rechercher l’’information sur un Client...
      • Fonctions d'Organisation telles que Habiliter, Affecter des Activités aux Acteurs, Gérer des tâches de chaque Acteur, Journaliser des Actions, Gérer l’interface utilisateur, la GED, les impressions
      • Patterns de Processus métier réutilisables tels que Modèle de Processus de souscription qui peut servir de pattern à tous les Processus de souscription
      • normes d’usage : présentation, navigation, normes d’impression
      • les Modèles de Solutions communes que l’on souhaite voir utiliser par les différentes compagnies d’un groupe.
    • L’Architecture d’Entreprise qui définit le plan d’ensemble des Solutions ***
      • Classification des Processus et des Fonctions
      • Plan des Solutions et flux entre Solutions
      • Référentiels d’Informations réutilisables
        • Entités Métier telles que Produit, Acteurs, Contrat, Compte etc.
        • Entités Organisation telles qu’Unité, Rôle, Profil, Droit, Panier de tâches,....
    • Le Modèle de Transformation réutilisé par les différentes équipes de Transformation ***
      • Processus de Transformation que doivent respecter les Transformateurs.
      • Outils qui automatisent certaines Fonctions des Processus de Transformation.
    • Les Solutions réutilisables par différentes Unités d’un groupe : Solution RH ou Solution comptable…qu’il faut savoir personnaliser par configuration ***
    • Les Produits réutilisables par différentes Unités d’un groupe qu’il faut savoir personnaliser par configuration ***

    Ils représentent tout ce qui contribue à mettre de l’ordre, à simplifier, à donner de la cohérence et à faciliter les synergies : le Bien Commun qui est géré par l’équipe Fondation.

    L’absence totale ou partielle de ces Rôles est dû au fait qu’il n’existe pas d’Unité transversale aux Métiers. La Direction Générale est éloignée de ces préoccupations et les Directions Métier qui se consacrent à l’efficacité de leur propre Métier n’ont pas en charge le bien commun : elles ont besoin de Produits/services proposées à leurs Clients et d’un ensemble de Solutions pour œuvrer efficacement.

    C’est pourquoi ces responsabilités sont généralement effectuées par la DSI : cette dernière n’a pas les compétences Métier, mais elle comprend mieux les enjeux de synergie, de mise en commun, de réutilisation parce qu’elle doit Modéliser les Solutions pour tous les Métiers.

    Il faut impérativement expliquer à la Direction Générale l’importance de ces préoccupations pour que des ressources Métier de qualité les prennent en charge au sein de la DSI ou ailleurs.

  6. Principes d’Organisation de la Transformation

    Une fois les Rôles définis, on peut choisir une Organisation adaptée à l’Agilité et à la cohérence.
    Les principes d’organisation sont simples : (voir organisation des Opérations)

    • Séparer Opérations et Transformation parce que les préoccupations présentes sont toujours prioritaires vis-à-vis des préoccupations futures : un incident de fonctionnement dans les Opérations nécessite une réaction prioritaire par rapport aux incidents qui peuvent affecter des Projets de Transformation en cours. Si une Unité souhaite favoriser l’Agilité, elle doit donc impérativement séparer les responsabilités de Transformation des responsabilités Opérationnelles. Cette séparation peut avoir lieu au sein de chaque Unité ou globalement pour l’Entreprise.
    • Isoler le Bien Commun : réunir des compétences pluridisciplinaires au sein de la même équipe pour qu’ils produisent l’Architecture d’Entreprise, les Fondations, les Solutions réutilisées, et l’Approche adaptée. Il faut leur donner le pouvoir de faire respecter la réutilisation de Composants.
    • Une question est souvent avancée dans l’organisation des équipes : faut-il organiser par Compétence (séparer marketing des maitrises d’ouvrage des informaticiens…) ou par livrable (séparer les équipes qui ont des livrables différents)?
      • La réponse est claire, il faut organiser par livrable.
      • Chaque équipe de Transformation doit rassembler les compétences Métier et IT parce que les compromis sont alors résolus au niveau le plus proche des Projets : appliquer le principe de subsidiarité.
      • La cohérence entre équipes Projet est assurée par l’équipe Fondation.
    • L’Entreprise doit maîtriser son Modèle Global et ne sous-traiter auprès des partenaires que des Modèles détail : c’est la clé de son évolutivité.

  7. Découper en équipes de 7 personnes

    Existe-t-il une règle en matière de taille d’équipe de Transformation ?
    On pourrait penser qu’il est impossible de fixer une règle compte tenu de la diversité des projets de Transformation. Mais un certain nombre d’experts se sont penchés sur la question et ont fini par définir une règle universelle : un consensus se dégage sur un nombre de 5 à 12, l’idéal étant de 7.

    • Au-dessous de 5 l’équipe devient fragile aux évènements extérieurs et manque de créativité.
    • Au-dessus de 12, la productivité baisse, la cohésion diminue, les lutte de pouvoir se développent.
    (voir « les géants du Web » publié par Octo).
    • Amazon déclare que la taille d’une équipe ne doit pas dépasser le nombre de personnes que l’on peut nourrir avec 2 pizzas (soit environ 8 personnes).
    • Chez Yahoo la règle est de 5 à 10 personnes.
    La productivité baisse assez fortement à partir de 7 personnes.

    Il est étonnant d’observer que la taille des équipes informatiques d’une banque est proportionnelle à la taille de la banque alors que le travail de Modélisation est à peu près le même quel que soit la taille : ce sont les mêmes opérations que l’on doit traiter.
    Il semble que la taille des équipes soit plutôt liée à ce que l’on peut financer et non au véritable besoin : on augmente la variété des Produits et des Processus jusqu’au niveau où on ne peut plus le financer.

    Si la taille moyenne d’une équipe est de 7 personnes, et qu’un responsable a du mal à diriger directement plus de 7 personnes, cela signifie
    • qu’une équipe d’une cinquantaine de personnes ne devrait avoir que 2 niveaux hiérarchiques (puisque 7 fois 7 font 49)
    • qu’une équipe de 350 personnes ne devrait avoir que 3 niveaux hiérarchiques
    • et ainsi de suite : c’est une bonne règle pour limiter le nombre de niveaux hiérarchiques célèbre dans l’armée mexicaine

  8. Les qualités d’un Chef de Projet Transformation : Modélisateur et Gestionnaire

    • Un chef de projet qui n’est que Gestionnaire sans avoir de talents de Modélisation n’aura pas les réflexes de bon sens de celui qui sait ce qui est réaliste, ce qui s’implémente aisément, ce qui remet en cause le Modèle profondément. Pour compenser ce manque de jugement ou d’expérience, il aura tendance à se protéger en alourdissant les procédures de contrôle, de reporting, ou de réunions pour obtenir un consensus qui le protège.
    • Un chef de projet qui n’est que Modélisateur sans avoir de talents de Gestionnaire sera confronté à d’autres problèmes bien identifiés : entre autres, il ne saura pas arrêter l’afflux d’exigences, il négligera les aspects reporting ou documentation.
    • S’il a des compétences Métier et IT, c’est un profil parfait, mais rare.
    • S’il ne les a pas, il faut qu’il s’entoure d’experts qui lui apportent cette Compétence.

    La tendance naturelle est d’abandonner la Modélisation pour se consacrer à des tâches de gestion.
    On voit même des chefs de projet de Transformation qui n’ont aucune compétence en Modélisation, ce qui les empêche d’identifier rapidement les problèmes attachés à un Modèle mal construit. Ils essaient de compenser ce manque par la mise en place de procédures de contrôle qui peuvent aboutir à une bureaucratie qui noie le projet. Les grands Entrepreneurs ou les grands chefs de programmes de transformation savent définir un Modèle d’Entreprise dans ses différentes composantes.

  9. Evolution du rôle de la DSI

    Ce mouvement remet en cause le rôle actuel de la DSI :

    • D’une part la séparation Opérations/Transformation conduit à séparer la production informatique des Etudes
    • D’autre part la pluridisciplinarité de projets qui consistent à transformer le business model en profondeur et non à simplement informatiser les processus existants : la DSI n’est plus l’intervenant essentiel sur les projets.
    • Enfin le « BYOD » (« Bring Your Own Device », qui représente la tendance qu’ont les Acteurs à utiliser leur propres Mobiles au bureau), détourne une grande partie du budget informatique : 30% à 40% des dépenses informatiques sont effectuées hors DSI.

    Les Entreprises sont aujourd'hui prêtes à repenser leur Organisation :

    • Certaines entreprises, comme Voyage SNCF, ont supprimé la DSI. Ils préfèrent constituer des groupes de travail mixant informaticiens, marketing, et gestion client.
    • D’autres comme Air France ont créé des comités numériques où la direction informatique joue un rôle important.
    • D’autres comme Pernod-Ricard ont créé une « Digital Accelerator Team » qui regroupe 80 experts dans le monde pour répertorier les initiatives en cours et initier des Projets de Transformation Numériques.
    • BNPParibas a isolé l’activité de banque directe qui sert de prototype pour le reste de la banque. Permet de s’affranchir des lourdeurs de l’organisation en place. Elle ne représente que 4% de l’activité aujourd’hui, mais croit de 15% à 20% par an.

    Pour résumer, le contexte a profondément changé :

    Approche Classique Approche Numérique
    Terminaux corporate Tous types de terminaux
    Infrastructure IT lourde Infrastructure IT légère
    Silos Accès de tout lieu
    Productivité individuelle Collaboratif

    La DSI conserve deux atouts pour jouer un rôle fondamental dans ces nouvelles Transformations :

    • elle est la seule direction de l’Entreprise qui a de l’expérience pour promouvoir le bien commun, elle comprend le mieux ce qu’est une Fondation qui donne de la cohérence à l’Entreprise
    • elle connait la complexité des logiciels et peut apporter une dose de réalisme dans les phases de décision

    Ses représentants actuels devraient jouer un rôle essentiel dans les nouvelles équipes de Transformation.

     
comments powered by Disqus
▲ Retour