Modélisation des flux d’information associés aux processus

1. Vision générale

L’objectif final est d’exhiber une structure, que nous pourrions appeler diamètre organisationnel ou graphe de transfert, qui est une abstraction de l’organisation de l’entreprise qui représente sa capacité à transférer de l’information, du point de vue du débit, du temps de propagation (latence) et de la fidélité.
Il s’agit ensuite de pouvoir la caractériser en fonction des choix d’organisation de l’entreprise et de préciser son impact sur le fonctionnement de l’entreprise. Cette vision correspond au postulat suivant : dans la société de la connaissance, le rôle principal de l’organisation est de favoriser le transfert de l’information.
Cet objectif est très général et très ambitieux. La première étape, que nous avons commencé à développer dans les messages précédents, est de modéliser la dimension temporelle, c’est-à-dire le temps qu’il faut pour transférer l’information.
Mon objectif en 2006 est de réaliser une première version du modèle, qui s’appuie sur la méthode «simulation par jeux et apprentissage » pour essayer de faire apparaître des propriétés de ce modèle, en particulier en ce qui effets combinés des 5 leviers d’organisation que nous avons évoqué précédemment.


2. Simplifications associées à la version 1 du modèle

Les simplifications majeures sont de deux types :

1. Les ressources sont séparées en deux catégories, U pour les agents qui effectuent des activités et H pour les agents qui participent au management et au transfert d’information. Cela signifie que nous avons « virtualisée » l’activité de management et pilotage de chaque unité, et l’avons rattaché à l’entité globale de management. Ce regroupement évite de se poser des questions d’allocation de ressource de management, il représente une abstraction idéale du fonctionnement et rend la simulation plus simple.
2. Le cœur du modèle est un ordonnanceur de blocs de temps, en fonction de priorités. Comme nous raisonnons de façon macroscopique, il n’est pas possible de modéliser des chaînes de propagation. Si un bloc représente un ensemble de réunions, nous ne savons pas « à quel moment la décision de réallouer des ressource va être prise ». En ne représentant pas dans le modèle des éléments qui dépendent du temps de propagation, nous faisons également une simplification qui est une idéalisation du fonctionnement de l’entreprise.

Dans les deux cas, il m’aura fallu un peu de temps pour me convaincre qu’il était plus raisonnable de faire abstraction des deux dimensions que j’avais du mal à formaliser de façon simple, plutôt que de faire des demi-mesures. Il sera toujours possible, dans une deuxième version, de revenir sur ces limitations et de proposer des modèles plus riches.
Pourquoi ne pas faire, plutôt que de faire simplement ? C’est parce que l’abstraction du pilotage de l’enterprise doit être au moins aussi efficace que son fonctionnement réel ! Les deux règles de simplifications font que je représente une entreprise idéale dans les deux dimensions de l’allocation des ressources de pilotage et de management, et dans la priorisation de ses décisions à l’intérieur de ses activités de pilotage. Si je commence à rentrer dans le détail, il faut que le modèle soit pertinent, sinon les conclusions seront invalidées.


3. Typologie des flux et canaux

Nous avions une typologie simple en terme de flux que nous pouvons encore simplifier puisque n’avons pas besoin d’associer des actions à la réalisation de l’ensemble des types de flux. Nous obtenons le deux catégories suivantes :
- Monitoring & Feedback :
- Transfert & synchronisation :

Puisque l’exécution d’un flux est abstrait au point de ne représenter qu’une charge temporelle à placer sur l’ordonnanceur, cela nous permet de caractériser les canaux avec trois paramètres :

1. le taux de répétition : nombre moyen de fois ou le message a besoin d’être émis pour être efficace. Ce paramètre est notre approche dans cette version pour représenter la notion de fidélité d’un canal.
2. Mutualisation : le nombre de récepteurs moyen d’un message. Cela permet de représenter la mutualisation obtenue en réunion ou avec l’envoi d’un email.
3. utilisation: le nombre de personnes occupées durant l’échange d’information, y compris les personnes qui sont pas concernées de façon utile (participants qui s’ennuient en réunion, destinataires inutiles en cc d’un email, etc.)
   

Par exemple, voici un tableau qui peut représenter un des scénarios à tester en terme d’efficacité des canaux (à titre d’illustration) :

• SYNCH: taux répétition:1, mutualisation: 1, utilisation: 1
• ASYNCH: taux répétition:1 à 2, mutualisation: 1 à 3, utilisation: 1 à 10
• MEET: taux répétition:1 à 1.5, mutualisation: 1 à 5, utilisation: 3 à 10
• HIER: taux répétition:1, mutualisation: 1, utilisation: D = profondeur
  
  

4. A suivre

Cette simplification a un intérêt : on limite fortement le nombre de paramètres inconnus qu’il faudra tester par instantiation Monte-Carlo. Non seulement on simplifie l’implémentation, mais on obtient un modèle qui est plus convaincant, puisque nous reposons sur un nombre plus faible de « paramètres tirés du chapeau ».
La vraie question est maintenant : avec un fonctionnement aussi idéalisé, pouvons nous constater encore les effets des leviers d’organisation ?
Les « leviers » ont encore un impact sur ce modèle. Par exemple :
(1) la profondeur de la hiérarchie joue sur l’utilisation du canal hiérarchique
(2) la répartition matricielle (horizontale/verticale) est représentée par l’allocation du temps entre MEET et HIER dans les ressources de H
La réponse dans deux mois …lorsque le simulateur sera opérationnel !