Cet article présente une démarche pour concevoir la structure organisationnelle de votre département informatique afin d’optimiser votre Time to Market sur un axe donné (ou tout autre axe d’optimisation découlant de votre stratégie métier).

Optimisation de la valeur

Il constitue mon retour d’expérience de coaching d’organisation visant à définir la structure organisationnelle informatique dans le cadre d’une transformation « d’agilité à l’échelle » impliquant 7 000 personnes !

Structure organisationnelle

Mise en œuvre dans le cadre de la définition de la structure organisationnelle des départements informatique, la démarche est sans doute en partie généralisable au reste de l’entreprise. Elle consiste à identifier dans un premier temps la macrostructure organisationnelle puis la microstructure logique et enfin d’associer les personnes aux équipes. Les chapitres suivant correspondent aux différentes étapes :

1 / Identifiez les flux de valeur opérationnels de votre entreprise et les unités organisationnelles informatique associées

Ce chapitre est dédié à l’identification des unités organisationnelles informatique. Par unité organisationnelle, j’entends un groupe de personnes dont la taille est inférieure au « nombre de Dunbar ». Ce nombre est une limite cognitive qui définit le nombre de personnes avec lesquelles une personne peut maintenir des relations sociales stables (la valeur couramment utilisée du nombre de Dunbar est de 150 personnes ; parfois le nombre de 125 est également utilisé).

Selon les organisations, leur taille et les mécanismes d’agilité à l’échelle mis en œuvre, ces unités organisationnelles peuvent s’appeler départements, divisions, services, tribus, trains, groupe produit….

La première étape est d’identifier vos flux de valeur opérationnels. C’est-à-dire, des processus métier de haut niveau, fournissant de la valeur aux clients. Le schéma ci-dessous présente un exemple simple de flux de valeur.

 

gestion patient

La règle d’or est la suivante : “Une unité organisationnelle informatique peut être basée sur un ou plusieurs flux de valeur, mais un flux de valeur ne doit pas traverser plusieurs unités organisationnelles“.

Ainsi, étant donné qu’une modification du ou des systèmes supportant le flux de valeur est gérée dans une seule unité organisationnelle, les mécanismes de synchronisation à mettre en œuvre sont plus simples ce qui conduit à un meilleur délai de mise sur le marché.

flux de valeur

Mais que se passe-t-il si plusieurs flux de valeur traversent certains composants centraux de taille importante tels que des entrepôts de données ou des référentiels (ces composants pouvant nécessiter plusieurs centaines de personnes à maintenir) ? Devez-vous intégrer des tranches d’entrepôt de données dans chaque unité organisationnelle ou bien conserver les entrepôts de données dans une unité organisationnelle dédiée ? Dans le premier cas, vous optimisez le temps de mise sur le marché et dans le second cas vous optimisez la cohérence et le coût. C’est donc à vous de choisir la meilleure solution en gardant à l’esprit les avantages et les inconvénients de chaque scénario.

A noter que cet article ne traite pas de la conception des départements transversaux qui peuvent être nécessaires.

 2 / Identifier les équipes constituantes de chaque unité organisationnelle.

Nous allons maintenant plonger dans la conception de chaque unité organisationnelle et réfléchir à la manière de la diviser en équipes et si possible en « feature teams ».

Mais définissons d’abord ce qu’est une feature team : c’est un groupe pérenne de 5 à 9 personnes, responsable d’un périmètre fonctionnel, colocalisé, polyvalent et autonome sur son périmètre fonctionnel.

Mais pourquoi organiser votre unité organisationnelle en feature teams ? Parce qu’elles sont alignées sur les flux de valeur et permettent donc de développer une fonctionnalité potentiellement multi-applications à vitesse optimale.

De plus, contrairement à une équipe dédiée à un projet, les feature teams sont pérennes ce qui permet de capitaliser sur les compétences et les connaissances de l’équipe.

Le premier axe de découpage de votre unité organisationnelle en feature teams doit être a priori basé sur vos flux de valeur afin d’optimiser le temps de mise sur le marché.

Mais il faut souvent envisager un deuxième axe de découpage lorsque le flux de valeur correspond à la taille de plusieurs feature teams. Une solution optimale serait que les équipes soient interchangeables sans spécialisation particulière, permettant, à l’aide des mécanismes de synchronisation d’agilité à l’échelle une allocation dynamique des features aux différentes feature teams. En pratique, cela n’est pas aussi simple que cela en raison des spécialisations fonctionnelles et techniques.

Ceci dit, il faut souvent trouver un compromis : si votre axe de découpage conduit à une feature team avec un périmètre trop étroit le long d’un flux de valeur, la feature team devra sans doute gérer un trop grand nombre d’applications, conduisant au moins temporairement à des silos de spécialisation au sein des équipes ; ce qui n’est pas une bonne chose. Une alternative est d’avoir un groupe de feature teams sur un périmètre moins étroit mais avec des mécanismes de synchronisation d’agilité à l’échelle : il y aura moins de silos de spécialisation et le temps de mise sur le marché restera encore bon grâce aux mécanismes d’agilité à l’échelle (qui permettront aux équipes de se coordonner pour le développement des features multi-équipes).

Avant de travailler sur les différents scénarios de découpage, je vous recommande fortement de prendre connaissance de la stratégie métier, d’identifier les attentes du métier vis-à-vis de la transformation et de les hiérarchiser avec le métier.

Par exemple, j’ai récemment organisé un atelier sur ce sujet avec le métier d’une unité organisationnelle et les résultats ont été les suivants :

  • Pour certains types de fonctionnalités, il était préférable d’optimiser le délai de mise sur le marché le long des flux de valeur (afin qu’une fonctionnalité traversant plusieurs activités du flux de valeur soit développée au plus vite)
  • Pour d’autres types de fonctionnalités, il était préférable d’optimiser le délai de mise sur le marché par activité du processus métier. En effet les fonctionnalités de ce type correspondaient principalement à une seule activité du flux de valeur et la probabilité qu’elles aient des impacts sur des fonctionnalités d’autres activités du flux de valeur était faible. Cela m’a donné une première stratégie de découpage.

Un autre point important est d’identifier les contraintes :

  • Celles liées à la localisation des membres de l’organisation unit
  • Celles liées à la spécialisation technique et fonctionnelle des membres de l’organisation unit

Après avoir identifié la stratégie métier et les contraintes, vous devez identifier les différents axes de découpage par flux de valeur (seulement si ce flux implique plusieurs équipes) : par exemple, un axe de découpage peut être par client, par groupe de types de fonctionnalité, par objet métier, etc …

Un autre axe peut être obtenu en analysant l’urbanisation IT. Si deux systèmes informatiques sont faiblement couplés alors il est préférable de dédier chaque système à des équipes distinctes. Si vous prenez un autre axe de découpage, la loi de Conway peut jouer contre vous. En effet l’architecture du Système d’Information étant influencée par la précédente structure organisationnelle, le changement de structure organisationnelle risque d’engendrer un couplage plus fort entre les équipes.

Vous devez également faire attention au fait que l’axe de découpage conduise à des features teams avec une distribution constante du flux de demandes afin que la feature team ne soit pas régulièrement en sur ou sous capacité. Cela signifie que vous devez également prendre en compte la stratégie métier et sa possible évolution.

axe de découpage

Comme vous le voyez, les paramètres sont nombreux et trouver la meilleure solution n’est pas toujours évident. Je vous recommande donc fortement de formaliser chaque scénario incluant, pour chacun, les avantages et les inconvénients.

Dans le cas de mon exemple où une unité d’organisation correspond à l’entrepôt de données, nous avons identifié deux axes possibles de découpage :

  • Soit par ligne métier,
  • Soit par type de données.

Dans le premier cas, vous optimisez le temps de mise sur le marché. Dans le second, vous optimisez la cohérence et le coût mais l’inconvénient est que les Product Owners doivent gérer les priorités entre plusieurs lignes métier.

Je vous recommande également fortement d’impliquer toutes les parties prenantes et si possible tous les membres de l’unité d’organisation pour sélectionner le meilleur des scénarios. Cela comporte de nombreux avantages. Premièrement, ceux-ci peuvent identifier des avantages, inconvénients ou contraintes qui n’avaient pas été identifiés. Mais surtout, le fait d’impliquer une personne est bénéfique du point de vue de la conduite du changement car la personne se sent acteur de la transformation ce qui apporte de la motivation intrinsèque.

L’axe de découpage sélectionné permet d’identifier les « feature teams » ou les groupes de « feature teams ». À ce stade, les « feature teams » doivent être logiques sans ses membres nominativement affectés. Cela évite les pressions politiques et personnelles.

3 / Associer les membres de l’équipe aux « feature teams »

L’étape suivante consiste à associer les membres de l’équipe aux feature teams. Je recommande pour ce faire d’organiser un atelier dans lequel chaque membre de l’unité d’organisation sélectionne sa propre équipe. Au cours de cet atelier, les Product Owners / Scrum Masters / Managers doivent présenter chaque « feature teams », décrire leur périmètre, leur taille et les compétences requises. J’ai récemment animé un tel atelier et ce fut un grand succès !

feature teams

Stéphane Déprès
Membre de la communauté Agile@scale inspearit (communauté concevant une démarche de transformation agile à l’échelle)
Traduction française par Franck Arsene et Stéphane Déprès —

Comments are closed.