Org Topologies & Stratégie Kanban pour augmenter son agilité business - Premier volet

Introduction

Toute organisation peut être analysée via la cartographie proposée par Org Topologies.

Sur cette cartographie le saint Graal se trouve en haut à droite, représentant une organisation capable de s'adapter ultra rapidement pour faire face à tous les périls semés sur son chemin. Une organisation par ailleurs en capacité de délivrer rapidement et avec une grande efficience de la valeur à ses clients.

Les startups se situent généralement dans cette zone et si ce n'est pas le cas, elles ne subsistent pas très longtemps dans ce monde de fortes compétitions, où il est crucial d’être à un très haut niveau de performance. Un niveau où la consommation du peu de moyens disponibles permet de rapidement trouver le produit que des premiers clients adoreront et qui permettra de continuer l’aventure.

Lorsque la petite organisation s'agrandit, la tendance générale est à la segmentation des responsabilités. Des départements spécialisés dans différents domaines sont créés (marketing, commercial, après-vente, etc.), entraînant une baisse de capacité d'adaptation et une baisse de capacité à délivrer rapidement et à moindre coût de la valeur.

L'accroissement d'une organisation tend à l'amener vers la zone basse à gauche, où les équipes et les individus la composant n'ont plus une vision holistique de ce qui est le mieux à faire pour la clientèle actuelle et pour continuer à prospérer en atteignant de nouveaux marchés par exemple.

Dans cet article, nous allons suivre l'histoire de Paul, un consultant spécialisé dans les tests d'application numérique au début de sa carrière. Paul rejoint lors d'une mission une organisation avec de multiples départements, des équipes et individus dispersés, mais qui doivent se coordonner pour in fine servir la clientèle de l’entreprise.

Dans cette histoire vous verrez comment cette organisation, et plus précisément la business unit que rejoint Paul, entreprend un chemin pour retrouver le saint-Graal, notamment en s'appuyant sur la stratégie Kanban.

Chapitre 1 : Le commencement

L'unité business que Paul rejoint, délivrant des services numériques à ses clients est un collectif d'environ 50 personnes. Ces 50 personnes couvrent l'ensemble des compétences permettant de délivrer à une partie des clients de l’entreprise un produit numérique (Business, IT, Marketing, Commercial, Hotline etc.). 

Cette unité business se situe à l’intérieur d’une entreprise plus large servant d’autres produits et services, pour un panel plus large de clients.

En utilisant les 4 strates verticales de la cartographie Org Topologies (C, B, A ,Y),  cela donnerait cette forme de représentation :

L’histoire qui va être racontée tout au long de ces différents chapitres, fait le focus sur l’unité business X que Paul rejoint.

La situation organisationnelle de cette unité business au moment où Paul rejoint cette entreprise est représentée sur la cartographie org topologies suivante :

Les liens entre les individus ou équipes (pseudo équipe) sont représentés par les connecteurs.

Le silotage au sein de cette organisation est très présent, jamais un membre du groupe de commerciaux  (C1) pourtant au plus proche des clients n'échange avec le groupe développant le produit (A1).

Pour faire l'interface entre les commerciaux occupés sur le terrain à vendre les différents produits et services que l’entreprise propose, et les personnes développant le produit, l'organisation a choisi de placer des interlocuteurs métier (B0), plusieurs, chacun avec son périmètre (chef de projet marketing pour les clients de type X, un autre pour les clients de type Y, etc.). Il n'y a pas une unité cohérente, partageant la connaissance, mais X interlocuteurs distincts avec sa connaissance business dédiée. Ces personnes se retrouvent sans une vision globale orientée client, mais une vision partielle centrée sur leur domaine business, leur domaine de clientèle. La hotline (B1) a une connaissance plus large, plus partagée, entre ses membres qui font face à tout type de clients et divers problèmes remontés, mais elle répond et débloque des situations au cas par cas sans avoir le pouvoir de décision et la capacité d'action pour apporter des changements pérennes bénéfiques aux clients.

Dans cette situation, beaucoup de coordination nécessaire entre ces différents acteurs et inévitablement de la déperdition d'informations utiles pour prendre les bonnes décisions pour le business et rendre au mieux service aux clients. 

Ces personnes n'ont pas les compétences pour maintenir et faire évoluer le produit. Ils vont se reposer sur une filière informatique, généralement découpée en deux parties MOA et MOE, Business Analyst et Codeur. 

C'est le cas ici, un groupe de personnes avec des compétences liant le business à l'IT vont analyser les problématiques et les besoins remontés par la Hotline ou par les interlocuteurs métiers. Il n'est pas rare non plus que ce groupe consiste en des personnes très spécialisées sur des domaines business, mais que tout le monde ne puisse adresser les sujets des différentes clientèles. L'organisation présentée ici est dans ce cas avec ses Business Analyst (B0) spécialisés avec des domaines de prédilection.

Paul est missionné et rejoint un groupe spécialisé dans les tests (A0). Ce groupe est ici en renfort pour libérer de la bande passant aux BA afin qu'ils se consacrent à la compréhension des besoins, des problématiques et gèrent les "gros" projets en tant que chef de projet SI. Un groupe de testeurs avec des missions souvent spécifiques autour de batteries de tests de non régression. 

Un rythme effréné de tests laissant aucune place au partage de connaissances, amenant les personnes à se spécialiser sur des parties de l'application. 

Paul a bien du mal à entrer dans sa mission, ses collègues étant très peu disponibles pour l'aider à comprendre le fonctionnement de l'application et toutes les subtilités. Heureusement, beaucoup de documentation existe et il arrive au bout de quelques semaines à prendre ses marques. 

Au regard des évolutions à venir, un chef de projet SI lui demande de se focaliser sur une partie de l'application.

Évidemment l'organisation s'est dotée de développeurs informatiques (le produit numérique ne pas se construire par magie !), ces développeurs forment une unité souvent eux-mêmes silotés en domaine de compétence spécifique (A1). C'est le cas dans cette organisation que rejoint Paul avec rarement du partage de connaissance, du pair-programming inexistant. Une unité où chacun selon sa spécialisation sur l'application prend des morceaux de spécifications écrites par les BA afin de coder l'évolution, la correction.

L'organisation a choisi de faire appel à un centre de compétence technique externe (Y1) afin de gérer la fluctuation des besoins de compétences en développement informatique. Cette entreprise est dans une stratégie de contrôle de l’accroissement de la masse salariale sur ces compétences techniques, craignant une baisse d’activité autour de ces compétences dans le futur et ne voulant pas avoir des dizaines de collaborateurs auxquels elle n’aurait plus d’activités à confier. Entre contrat mal ficelé et contraintes autour de la sécurité des SI, ce centre de compétence se retrouve à réaliser des tâches plutôt correctives, qu'évolutives et à déposer des livrables qui doivent être ensuite intégrés par l'équipe de développement interne.

Enfin pour livrer l'application en production, réaliser le monitoring technique et assurer la maintenance et l'évolution de l'infrastructure, l'organisation s'est dotée de spécialistes et les a regroupés dans une unité dédiée (Y1).

Paul regrette de ne pas être en lien avec les interlocuteurs métiers ou la hotline. Ce sont les BA, les chefs de projet SI qui le sont et reçoivent les problématiques pour finalement lorsqu'ils ont besoin les faire redescendre à l'unité dans laquelle se trouve Paul.

Il pense sincèrement qu'il pourrait mieux comprendre les anomalies constatées et plus facilement les reproduire pour aider les développeurs à les corriger. Il a déjà évoqué plusieurs fois le sujet, mais rien ne change.

Une organisation qui réalise de nombreux comités pour coordonner les différentes équipes et personnes, nécessitant de nombreuses heures de préparation de reporting et de nombreuses heures passées dans ces réunions.

Paul doit remonter fréquemment, les compteurs d'anomalies, le pourcentage de cas de tests restants, une appréciation du temps nécessaire restant pour boucler les tests qu'on lui a poussés, chose pour lui compliqué car s'il détecte une anomalie, il est assez souvent coincé pour continuer. N'ayant aucune idée de combien de temps prendra le correctif, il s'engage sur d'autres périmètres de tests à réaliser. Cela l'amène à prendre pas mal de temps à se replonger quelques jours plus tard sur ce qui avait été interrompu.

Au moins, se dit-il : "Je monte en compétence de plus en plus sur tout le périmètre applicatif."

Il se demande sur quelle base les chefs de projet SI communiquent des dates d'atterrissage sur les différents chantiers. Cela lui semble être vraiment fait au feeling plus qu'avec des éléments très factuels. Certes il y a des Gantt, des plannings, mais il y a toujours des imprévus, notamment des bugs ou des régressions, qu’il détecte et qui viennent chambouler les plans.

Un type d'organisation que vous avez peut-être connu, ou dans laquelle vous êtes actuellement à certains détails près.

Une organisation peu efficiente, peu efficace et aucunement prédictible.

Pour cette organisation, les décalages dans les plannings sont constants. Des annonces de corrections et de nouveautés sont communiquées aux clients et ne sont quasi jamais tenues. Le mécontentement client est de plus en plus présent, à un niveau qui devient critique pour le business, ce qui ne laisse pas de marbre la direction. Il est absolument vital pour cette organisation d'accroître la capacité à répondre plus rapidement et de manière plus prédictible.

La suite des aventures de Paul dans cette organisation, dans le prochain chapitre…

Consultez mes classes certifiantes à mon catalogue sur la stratégie Kanban,  je peux aussi enseigner les classes ASPK et APV du catalogue de ProKanban. Contactez-moi pour arranger une classe privée inter-entreprise, ou si vous voulez suivre une classe publique mais n'avez pas les moyens de vous l'offrir.