Modèle opérationnel
Qu’est-ce qu’un modèle opérationnel ?
Un modèle opérationnel décrit la façon dont une organisation est agencée pour tenir la promesse faite à ses clients : qui fait quoi, qui tranche à quel niveau, par quels processus le travail circule, sur quels systèmes et quelles données il s’appuie, et quels chiffres disent s’il tient. C’est la mécanique qui relie une stratégie écrite en comité à ce qui se passe le mardi matin derrière une caisse ou dans un entrepôt. Toute entreprise en a un, écrit ou non, et il se remarque surtout quand il grince.
De quoi il est fait.
La chaîne de décision commande le rythme du reste : quelle décision se prend à quel niveau, et sous quel délai. Une exception tarifaire pour un client historique, l’arrêt d’une référence en fin de saison : chacune a un endroit où elle devrait se trancher et un endroit où elle finit réellement. L’écart entre les deux est la première chose que nous mesurons.
Les processus de bout en bout se lisent depuis le client, de la commande jusqu’à la facture réglée. Le travail traverse quatre ou cinq équipes en chemin, et le temps se perd aux passages de relais : un dossier qui attend une validation, une information ressaisie parce qu’elle n’a pas suivi. Un découpage par service laisse ces passages dans l’angle mort de chaque équipe.
L’organisation et les rôles traduisent tout cela en postes. Un rôle tient quand deux choses coïncident : ce dont la personne répond, et ce qu’elle peut décider seule. L’évaluation suit. Quand deux fiches se recouvrent, ce sont les réunions qui absorbent l’écart, semaine après semaine.
Les systèmes et la donnée décident de ce qui est possible en pratique. La question utile porte sur l’origine des chiffres : quel système fait foi pour le stock, pour le prix, pour le client, et qui a le droit d’y écrire. Quand la réponse change selon l’interlocuteur, la donnée se dédouble dans des exports et le modèle se réécrit tout seul.
Les indicateurs disent ce que l’organisation surveille vraiment. Comptez ceux qui sont regardés en réunion du lundi et qui déclenchent une action dans la semaine ; le reste est du reporting.
La culture d’exécution est la partie qu’on ne peut pas dessiner. Elle se lit dans ce qui arrive quand quelqu’un remonte un problème à 17h un vendredi : le sujet trouve un destinataire, ou il attend lundi. Honnêtement, c’est le composant le plus lent à faire bouger. Les cadres classiques, le 7S de McKinsey ou la chaîne de valeur de Porter, servent de repères pour vérifier qu’on n’a rien oublié.
Le target operating model, et ce qui le fait vivre.
Target operating model, ou modèle opérationnel cible, désigne la description de l’état visé : la façon dont l’entreprise fonctionnera une fois la transformation faite. Le terme vient des cabinets anglo-saxons et il prend en général la forme de schémas de macro-processus et d’une cible d’organisation.
Le document s’éteint quand il reste séparé de l’exploitation : écrit par une équipe dédiée, validé en comité, puis rangé pendant que les équipes continuent avec leurs règles à elles. Trois choses le gardent vivant. Une date, à laquelle un périmètre précis bascule pour de bon. Un propriétaire nommé par domaine, qui répond de son domaine devant ses pairs. Et une mesure de l’écart entre le fonctionnement d’aujourd’hui et la cible, relue tous les mois, avec le droit de corriger la cible quand le terrain la contredit.
Les signes qu’il ne tient plus.
Les décisions remontent. Des arbitrages que des responsables d’équipe rendaient seuls l’an dernier arrivent au comité de direction, dont l’ordre du jour se remplit de sujets de détail.
Les processus se contournent. Un fichier partagé apparaît à côté de l’outil officiel, puis un deuxième, et l’équipe y tient sa véritable liste de commandes en cours. Le fichier existe parce que le processus officiel ne couvre pas un cas réel que quelqu’un devait bien traiter.
Les rôles se recouvrent. Deux personnes se croient responsables du même sujet, ou aucune ne l’est, et la question se règle par disponibilité au lieu de se régler par mandat.
Les indicateurs ne servent plus. Le tableau de bord mensuel circule, la pièce jointe reste fermée, et les vraies décisions se prennent sur un chiffre extrait à la main la veille au soir. Un seul de ces signes se traite localement ; trois ensemble décrivent un modèle dépassé par l’activité qu’il devait porter.
Le changer sans arrêter la machine.
Nous commençons par la chaîne de décision, la partie qui bouge sans toucher à un seul système : écrire les niveaux de décision, nommer les propriétaires, fixer les délais de réponse. Le premier effet se voit en quelques semaines, et il achète la patience nécessaire pour la suite.
Pendant la refonte, trois choses restent gelées. Le référentiel qui fait foi pour les données maîtresses, parce qu’en changer pendant la bascule rend toute mesure ininterprétable. La liste des projets en cours, arrêtée à une date, pour que les équipes ne travaillent pas contre deux modèles à la fois. Et le calendrier des pics d’activité : on ne rebâtit pas ses processus de commande en pleine saison haute.
Le nouveau fonctionnement s’éprouve ensuite sur un périmètre réduit, une région ou une famille de produits, sur un cycle complet incluant la clôture mensuelle. Un test plus court valide seulement les jours faciles. Nous y cherchons les cas que le modèle n’avait pas prévus, ceux qui obligent à écrire une règle de plus avant de généraliser. Les systèmes et les fiches de poste viennent après, dans cet ordre.
Dans la pratique.
Notre point de référence : 29 magasins basculés à une seule date nationale, sans perte de chiffre d’affaires. Ce qui rend ce cas utile ici tient moins au jour J qu’au régime permanent qui a suivi. Huit domain leaders tenaient chacun un domaine devant leurs pairs, si bien qu’une question trouvait un nom et pas un service. Côté magasins, environ 145 personnes ont appris un fonctionnement nouveau, et la question qui a guidé la préparation portait sur le lundi suivant autant que sur le samedi de la bascule.
Un modèle opérationnel se juge dans les semaines ordinaires d’après, et c’est là que nous restons.
Le cas particulier du produit.
Une organisation qui vit d’un logiciel a ses propres règles de financement, de découverte et de mesure. Nous traitons ce cas à part, avec les pratiques qui vont avec, sur The Product Engine.
Ailleurs, le modèle opérationnel est l’une des cinq composantes décrites sur transformation d’entreprise : définition. Notre façon de mener ce travail est sur conseil en transformation digitale, et le passage des équipes au nouveau fonctionnement relève de la conduite du changement.
Des questions, des réponses franches.
Quelle est la différence entre un modèle opérationnel et un organigramme ?
L'organigramme montre les lignes hiérarchiques : qui reporte à qui. Le modèle opérationnel décrit le fonctionnement réel autour de ces lignes, les décisions et leur niveau, les processus qui traversent les services, les systèmes et les chiffres qui déclenchent une action. Deux entreprises au même organigramme peuvent fonctionner de façons très différentes, et c'est cette différence que le modèle rend explicite.
Qui doit porter la refonte du modèle opérationnel ?
Le comité de direction, collectivement, avec une personne désignée pour trancher les conflits d'agenda entre métiers. Le travail quotidien se répartit ensuite entre des propriétaires de domaine, un par grand processus, qui répondent devant leurs pairs. Une refonte pilotée depuis la seule DSI est reçue par le reste de l'entreprise comme le projet de ce service-là.
Combien de temps prend une refonte du modèle opérationnel ?
La chaîne de décision et les rôles se réécrivent en quelques semaines, puisqu'ils demandent surtout des arbitrages. Les processus de bout en bout et les indicateurs suivent sur un ou deux trimestres, le temps de les éprouver sur un périmètre réduit et sur un cycle entier, clôture comprise. Les systèmes fixent le reste du calendrier, et c'est la contrainte la plus rigide. Comptez environ un an avant que le nouveau fonctionnement tourne seul.
Faut-il un cabinet pour refaire son modèle opérationnel ?
Pas toujours. Une entreprise qui dispose d'un pilote interne à plein temps et d'une lecture honnête de ses propres processus peut mener le travail elle-même, et c'est souvent le meilleur choix. L'apport extérieur sert quand il faut un arbitre neutre entre directions, ou des bras pour mener la bascule sans arrêter l'exploitation.
Comment savoir qu'il faut revoir son modèle opérationnel ?
Quand les mêmes sujets remontent au comité de direction mois après mois, quand les équipes tiennent leur vraie liste de travail dans des fichiers installés à côté des outils officiels, et quand personne ne sait dire quel système fait foi pour un chiffre donné. Une acquisition ou l'ouverture d'un nouveau canal de vente produisent les mêmes signes en quelques mois.
Target operating model et modèle opérationnel cible, est-ce la même chose ?
Oui, l'un traduit l'autre. Le sigle TOM circule surtout dans les grands groupes. En français, modèle opérationnel cible dit la même chose : la façon dont l'organisation fonctionnera à une date donnée, par opposition au fonctionnement d'aujourd'hui.
Regardons votre modèle actuel.
Apportez le sujet qui remonte trop souvent au comité, et le fichier parallèle que tout le monde utilise. Une demi-heure suffit pour voir quelle composante lâche.