Organisation par domaine métier

Modèle d’organisation d’un domaine métier

Dans le monde de l’entreprise, il est un sujet qui revient régulièrement : réorganisation. Il s’agit soit de la conséquence d’un changement de direction, de management, d’envie de satisfaire les consommateurs des services fournis par l’entreprise. Mais beaucoup plus rarement, cette initiative est initiée pour que le travail d’équipe fonctionne vraiment au sein de l’organisation.

Dans la plupart des entreprises où j’ai travaillé, une organisation plus ou moins hiérarchique était en place. Elles avaient des structures soit fonctionnelles, matricielles, purement hiérarchiques, horizontales ou plates, ou encore d’autres combinaison de ces variantes.

Alors que l’on parle continuellement de réorganisation, quel modèle pouvons-nous apporter pour redonner de l’agilité à l’organisation et ainsi rendre de meilleurs services ?

Cet article propose un modèle d’organisation d’un domaine métier pour atteindre ces buts.

Introduction

Cet article propose un modèle d’organisation adapté à la fourniture de services pour des organisations clientes. Cette fourniture de services se veut en accord avec de que nos clients attendent de nous : agilité, cohérence, évolutivité, résilience.

Le modèle se base sur des constats et des hypothèses qui sont présentés ci-dessous. Ces constats et ces hypothèses proviennent d’un exemple réel d’une organisation d’une centaine de personnes fournissant des services informatiques pour un groupement d’organisations fédérées.

Constats

L’organisation possède un modèle d’organisation hiérarchique que l’on retrouve dans beaucoup d’organisations. Les modèles hiérarchiques génèrent de considérables discussions et controverses. Sans aller dans ces discussions philosophiques, on peut toutefois relever les points d’attention présentés ci-après dans cette organisation.

Rôles

Actuellement, certains services fournis par l’organisation le sont par des groupes dont les rôles sont groupés par métier informatique : e.g. les administrateur·rice·s système font partie de l’équipe d’infrastructure, les technicien·ne·s de l’assistance sont dans un groupe d’assistance, les analystes métier dans un groupe d’analystes métier, et ainsi de suite. Il s’agit d’une sorte d’organisation matricielle sous certains aspects et fonctionnelle sous d’autres angles. Mais comme on le verra plus bas, ce n’est pas systématiquement le cas.

L’organisation par type de rôle métier informatique conduit généralement à un clivage de l’organisation, à des silos de fonctions. On constate alors qu’une équipe constituée de rôles A ne sait pas communiquer avec une équipe constituée de rôles B et vice-versa. Cela est généralement dû à la méconnaissance des tâches qui incombent à ces rôles et de leur éloignement autant physique que de leurs préoccupations respectives.

Il en résulte une création d’interfaces compliquées entre groupes de rôles. Ces interfaces alourdissent par conséquent l’organisation. Voir ci-après la section bureaucratie.

En outre, ces rôles ne sont présents officiellement que dans certaines unités d’organisation : e.g. le rôle d’analyste métier ou d’architecte n’existe officiellement que dans une unité fonctionnelle.

Pour autant, tous les rôles sont essentiels pour fournir les services d’un domaine métier.

Bureaucratie

À mesure que l’organisation grandit, plus d’interactions entre les unités organisationnelles sont nécessaires. Le réseau de relations est donc plus complexe à maintenir, car il y a plus d’agents humains dans le système.

Toutefois, aujourd’hui, étant donné la nature de la structure de l’entreprise ces interactions deviennent bureaucratiques : demandes entre groupes, gestion centralisée des demandes, gestion centralisée des changements, reporting entre équipes, etc. Le tout par formulaires interposés. Au lieu de privilégier les interactions humaines, on leur préfère un processus très mécanique, qui ne manquera pas d’être dysfonctionnel au moindre grain de sable dans un rouage du processus.

La paperasserie, je déteste la paperasserie. […] Si tout votre système de chauffage prenait feu, hein, j’aurais pas le droit d’ouvrir le robinet à moins de présenter le bon 27B-6 en règle. Putain de paperasserie.

Harry Tuttle dans Brazil

Si des règles sont nécessaires pour que les domaines interagissent de manière fluide, elles doivent être réduites à leur minimum.

Commande et contrôle

La prise de décision dans un groupe est souvent uniquement attribuée à leur chef·fe. Les collaborateur·rice·s n’ont pas l’autonomie de prendre des décisions pour lesquelles pourtant iels sont compétent·e·s.

Au lieu donc d’avoir une distribution des décisions, toute décision est centralisée et va habituellement jusqu’au directeur. Même pour une demande de ventilateur, une validation par le directeur est nécessaire.

Rigidité

La structure hiérarchique accroît la rigidité de l’organisation. Comme expliqué plus haut, certaines unités organisationnelles ne possèdent pas tous les rôles pour mener à bien leur mission.

Néanmoins, aujourd’hui, il n’est généralement pas possible pour un collaborateur ayant des compétences spécifiques de travailler dans une autre unité organisationnelle le temps d’un projet. À ce propos, on pourrait conclure qu’une organisation matricielle répondrait à ce problème. Nous le verrons plus bas, ce type d’organisation est loin d’être idéal, car il empêche la connaissance spécifique du domaine métier d’y rester.

Niveau hiérarchique

Il existe parfois une confusion entre le niveau hiérarchique et la valeur du collaborateur. Par exemple, le fait qu’un·e expert·e d’un domaine ne puisse pas prendre de décision sur un sujet qu’iel maîtrise lui donne le sentiment d’infériorité et provoque une frustration et une résignation à long terme.

Hypothèses

Les hypothèses ci-dessous sont des propositions d’explications obtenues par la généralisation des constats mentionnés auparavant.

• Un domaine fonctionne mieux si tous les rôles sont permanents et présents dans chaque domaine. La notion de permanence permet de conserver un momentum dans le domaine. Si les membres du domaine ne sont regroupés que pour le temps d’un projet, alors la dynamique disparaît au moment de la dissolution du projet. C’est souvent ce qui arrive avec une organisation matricielle. De surcroît, garder les membres dans la même équipe permet la maintenance des services au-delà de leur projet d’implémentation.

• Une personne peut avoir plusieurs rôles selon la nature du rôle. Selon la taille du domaine et du nombre de services que ce domaine fournit, il se peut qu’un collaborateur joue plusieurs rôles dans l’équipe. Par exemple, le rôle de technicien·ne d’assistance peut très bien incomber à tous les membres du domaine : n’importe qui dans l’équipe est capable de répondre à l’usager du service sans que celui-ci doive passer par des niveaux de support. Les collaborateur·rice·s doivent être dans des rôles correctement définis pour pleinement faire usage de leurs capacités dans le cadre des exigences de l’organisation.

• Les domaines métier on une cadence différente les uns des autres. Il y a des domaines métier où l’évolution est plus lente, car les besoins des usagers changent peu. D’autres, par contre, on une vélocité accrue de par leur nature émergente par exemple.

• Les domaines sont plus agiles s’ils sont autonomes. Un domaine autonome n’est pas un domaine qui vit en autarcie ou qui est indépendant de l’organisation. Il doit définir ses interfaces avec les autres domaines pour une collaboration adéquate. L’autonomie réside dans le fait de pouvoir laisser les décisions aux expert·e·s du domaine et ainsi le rendre plus agile. Cet·te expert·e peut prendre toutes les décisions qu’iel souhaite dans le cadre de son domaine : visions, buts, objectifs, finance, etc.

• L’instauration d’une pratique DevOps améliore la cohésion entre les membres du domaine. Nous avons vu plus haut qu’il existe un clivage entre les rôles. La pratique DevOps, permet à chacun d’avoir cette culture de fournir un service de bout-en-bout à l’usager : ceux et celles qui conçoivent un service l’exploitent. Les préoccupations d’exploitation ne sont donc plus l’unique responsabilité de l’administrateur·rice système et les préoccupations de conception ne sont pas uniquement laissées à l’analyste métier, à l’architecte ou aux développeur·euse·s.

Proposition

Le modèle présenté ci-dessous n’est pas basé sur un modèle académique spécifique. Il découle des constats et des hypothèses présentés plus hauts.

Il est également basé mon expérience de travail faite dans différentes organisations fournissant des services informatiques similaires.

Concept de domaine

La conception de l’organisation par domaine métier fournit un cadre pour les services du système d’information. Un domaine métier conçoit et exploite les services en rapport avec ce domaine.

Pour définir un modèle d’organisation par domaine, il convient de faire la définition de la notion de domaine et plus spécifiquement de domaine métier.

Un domaine métier représente un ensemble d’activités connectées entre elles et qui fonctionne sur un ensemble de règles et de concepts partagés. Il possède une vision et est orienté par ses buts. Il peut changer rapidement. Mais surtout, sa cadence peut être différente de celle des autres domaines. L’étendue du domaine va jusqu’aux limites qui séparent les activités, règles, et concepts partagés au sein d’un domaine par rapport aux domaines extérieurs. Aux limites du domaine des interfaces sont définies.

Dans chaque domaine métier, on retrouve tous les rôles nécessaires au bon fonctionnement du domaine et à la fourniture de ses services. Il est important que ces rôles soient permanents dans l’équipe qui constitue le domaine métier, car ainsi le savoir reste au sein de l’équipe.

Concept de guilde

Les domaines comprennent tous les rôles pour accomplir la mission du domaine. Toutefois, pour que l’organisation dans son entier soit cohérente et intègre, une communication inter-domaine gouvernée existe. Pour cela, les rôles de chaque domaine font partie d’une guilde. Une gouvernance émerge des rôles présents dans chaque domaine et est concrétisée par les guildes.

Une guilde représente une communauté qui partage le même centre d’intérêts, un groupe de personnes qui souhaitent partager leurs connaissances, leurs outils, leurs pratiques, leurs expériences.

La guilde existe donc comme une méta-organisation, dont les membres proviennent des domaines métier.

Représentation graphique

À titre d’illustration ci-dessous, on présente trois domaine métier : A, B, et C. Ces domaines comprennent tous les rôles qui sont nécessaires à la conception et l’exploitation des services qu’ils rendent. Ces rôles sont permanent : c’est-à-dire qu’ils ne sont pas pris dans un pool de personnes pour constituer une équipe de projet et qui sera ensuite dissoute. Les membres restent ainsi ensemble pour être au plus proche des besoins des consommateurs des services pendant tout le cycle de vie de leurs services.

En outre, les membres de ces domaines ne sont pas nécessairement employés de l’organisation. Ils peuvent être externes à l’organisation : indépendants, fournisseurs, expert métier, etc. Ils forment néanmoins une organisation durable et pérenne.

Régulièrement, les guildes se rencontrent pour échanger sur les sujets qui leur incombent. Elles créent ainsi une cohésion entre les domaines métier.

Par la constitution de ces domaines et guildes, qui sont des organes qui vivent leur autonomie et qui provoquent un flux et reflux vivant, l’organisation dans son ensemble prend vie.

Les domaines et les guildes ont donc également un cycle de vie propre : leur création ou leur suppression n’entraîne pas le déclin de l’ensemble de l’organisation.

Et vous, comment imaginez-vous la structure de votre organisation ?