Is a procurement operating model the same as a target operating model?

A target operating model is the intended future-state design. The operating model is how that design actually runs once decision rights, governance, process and systems are made executable. A TOM that stops at the design layer is exactly where most value is lost.

Do we need to choose centralised or decentralised first?

No. The leverage-versus-fit choice matters, but it is not where behaviour is decided. Decision rights are. A model with clear decision rights behaves predictably regardless of the label. A model without them behaves as decentralised in every contested case.

Our roles are already documented. Why does execution still break?

Documented roles describe accountability. They do not enforce it. Execution breaks at the handoffs, thresholds and contested decisions the documentation never resolved, and that the systems quietly decide instead.

Should we fix the operating model before or during an S/4HANA rollout?

Before, wherever possible. A systems programme hard-codes ownership and approval flows. If the operating model is unresolved when it lands, the ambiguity becomes permanent and far more expensive to change afterwards.

Where does this start?

With one senior diagnosis of where your intended model and your executed model diverge, before any new program, tool or consulting layer.

Conception du modèle opérationnel des achats

Symptômes

Ce que les dirigeants voient en général

Conception globale, contournements locaux
Responsabilité floue entre catégorie, pays, service partagé et métier
Trop d’escalade pour des décisions qui devraient être intégrées au modèle

Diagnostic

Ce que je diagnostique

Lacunes de responsabilité
Des couches de gouvernance qui ralentissent la valeur
La logique opérationnelle nécessaire pour faire circuler le travail entre les entités

Résultat

Ce avec quoi vous repartez

Un plan directeur pragmatique pour la responsabilité, le flux de décision et la gouvernance, qui peut être exécuté.

Définition

Ce qu’est réellement un modèle opérationnel des achats

Un modèle opérationnel des achats est le système de travail qui transforme une stratégie et un organigramme en exécution reproductible. Il répond à quatre questions auxquelles un schéma de structure ne répond jamais. Qui a le droit de décider. Sur quoi. Dans quelles limites. Et ce qui se passe quand la réponse n’est pas claire.

Concrètement, il définit le mandat des achats, la façon dont la responsabilité se répartit entre catégorie, fournisseur, pays et unité d’affaires, les décisions qui sont intégrées au modèle plutôt qu’escaladées, et le rythme selon lequel la valeur est gouvernée. Quand tout cela est explicite, le travail circule entre les entités sans réunion pour autoriser chaque étape. Quand c’est implicite, chaque cas non standard devient une escalade.

Deux confusions coûteuses

Ce n’est pas un organigramme, et ce n’est pas une stratégie achats

Organigramme

Il montre les lignes hiérarchiques. Il ne dit rien des droits de décision, des passations ni de la cadence de gouvernance. Deux organisations aux organigrammes identiques peuvent exécuter de manière totalement différente.

Stratégie achats

Elle fixe la direction : catégories à prioriser, ambition d’économies, posture envers les fournisseurs, agenda numérique. Une stratégie sans modèle opérationnel est un ensemble d’intentions sans mécanisme pour les porter.

Modèle opérationnel

La couche intermédiaire. C’est celle que la plupart des transformations sautent, et celle où la valeur se gagne ou se perd réellement.

Schéma

Les huit composants d’un modèle opérationnel exécutable

Un modèle est exécutable quand les huit sont définis ensemble. Le schéma d’échec n’est presque jamais un composant manquant. Ce sont des composants conçus séparément.

01MandatCe que les achats sont autorisés à porter et à décider, et où s’arrête leur autorité.

02Structure organisationnelleComment les équipes sont regroupées, et si ce regroupement sert le mandat ou la tradition.

03Droits de décisionQui décide, qui est consulté, qui est informé, à quels seuils.

04GouvernanceInstances, jalons et cadence qui pilotent la valeur sans taxer la vitesse.

05Responsabilité des catégories et des fournisseursUne responsabilité claire là où les intérêts centraux et locaux se concurrencent.

06Processus S2P et P2PLes flux par lesquels passe le modèle, y compris chaque passation où la responsabilité change.

07Données et technologieL’ERP, la suite S2P et les données de base qui permettent le modèle ou le contredisent en silence.

08Performance et rythmeIndicateurs et revues qui gardent le modèle vivant après l’atelier de conception.

Conçus ensemble, ces huit composants se comportent comme un seul système. Conçus séparément, un modèle de gouvernance suppose des droits de décision que les systèmes ne font pas respecter, et la responsabilité des catégories perd face à la culture de l’escalade.

La mauvaise première question

Centralisé, décentralisé, piloté par le centre, hybride

La plupart des débats sur le modèle opérationnel se réduisent à une question : centraliser ou décentraliser. C’est la mauvaise question pour commencer.

CentraliséFort effet de levierAdaptation locale plus faible

DécentraliséForte adaptation localeLevier et données fragmentés

Piloté par le centreLa cible la plus couranteLa plus difficile à rendre réelle

HybrideVarie selon la catégorieNe fonctionne que si les droits de décision sont sans ambiguïté

L’étiquette n’est pas la décision. Un modèle piloté par le centre avec des droits de décision flous se comporte comme un modèle décentralisé dans chaque cas contesté. Ce qui détermine le comportement n’est pas le nom sur l’organigramme. C’est l’endroit où se trouve l’autorité quand deux intérêts légitimes s’opposent.

Schéma d’échec

Où les modèles opérationnels se rompent

Conception globale sur le papier, contournements locaux dans la pratique.
Responsabilité floue entre catégorie, pays, service partagé et métier, si bien qu’elle ne se pose nulle part.
Trop d’escalade pour des décisions qui auraient dû être intégrées au modèle.
Des couches de gouvernance qui ajoutent des validations plus vite qu’elles n’ajoutent de la valeur.
Des systèmes qui font respecter un autre modèle que celui convenu par la direction.

Chacun de ces points est un défaut de conception, pas un problème de discipline. C’est pourquoi plus de formation et plus d’efforts les corrigent rarement.

Concrètement

Les droits de décision, une décision à la fois

Les droits de décision sont le composant qui se lit le mieux et fonctionne le plus mal. Les rendre concrets, c’est nommer, pour un type de décision et un seuil donnés, exactement qui décide et qui est consulté. Choisissez une décision ci-dessous pour voir la forme que prend une réponse exécutable.

Une catégorie stratégique, au-dessus du seuil de valeur convenu.

Décide: Le responsable de catégorie, dans le cadre de la stratégie de sourcing convenue.
Consulté: L’unité d’affaires, sur les exigences et l’impact sur le service.
Informé: La gouvernance achats, qui ne revoit que les exceptions.
Sous le seuil: Même décision, déléguée, jamais escaladée.

L’essentiel n’est pas cette répartition précise. C’est que la répartition soit décidée une fois, dans le modèle, au lieu d’être rediscutée à chaque cas.

Complexité

Logique multi-entités et services partagés

La complexité augmente fortement dès que le travail traverse des entités juridiques, des pays ou un centre de services partagés. Une responsabilité claire au sein d’une activité devient contestée entre plusieurs. Un centre de services partagés introduit une passation où la responsabilité peut disparaître discrètement.

Un modèle multi-entités exécutable rend trois choses explicites. Quelles décisions sont réservées au centre et lesquelles restent locales. Comment le travail et les données passent entre les entités et le centre de services sans perdre leur responsable. Et où se situe la gouvernance quand les intérêts locaux et centraux s’opposent légitimement. Sans cela, le centre de services devient un endroit où le travail va attendre plutôt qu’un endroit qu’il traverse.

La réalité du système

ERP, S/4HANA, IA et automatisation

Un modèle opérationnel ne vit pas dans un document. Il vit dans les systèmes qui font tourner les achats chaque jour. L’ERP et l’outillage S2P font respecter les droits de décision et les passations convenus, ou bien ils font respecter en silence un autre modèle.

Un programme S/4HANA code en dur la responsabilité, les circuits d’approbation et la logique des données de base. Si le modèle opérationnel n’est pas tranché quand il arrive, le système fige l’ambiguïté. Il en va de même pour l’IA. Automatiser un processus avant que les droits de décision qui le sous-tendent soient clairs ne supprime pas l’ambiguïté. Cela la passe à l’échelle. Être prêt pour l’IA dans les achats, c’est en grande partie être prêt sur le modèle opérationnel : une responsabilité claire, des données de base propres et des décisions assez bien définies pour qu’un système puisse agir dessus.

Les questions que les dirigeants posent en premier

Avant de commander quoi que ce soit

Un modèle opérationnel des achats est-il la même chose qu’un modèle opérationnel cible ?

Un modèle opérationnel cible est la conception visée de l’état futur. Le modèle opérationnel, c’est la façon dont cette conception fonctionne réellement une fois que les droits de décision, la gouvernance, le processus et les systèmes sont rendus exécutables. Un TOM qui s’arrête à la couche de conception, c’est exactement là que la plus grande part de la valeur se perd.

Faut-il d’abord choisir entre centralisé et décentralisé ?

Non. Le choix entre levier et adaptation compte, mais ce n’est pas là que le comportement se décide. Ce sont les droits de décision. Un modèle aux droits de décision clairs se comporte de façon prévisible quelle que soit l’étiquette. Un modèle qui n’en a pas se comporte comme un modèle décentralisé dans chaque cas contesté.

Nos rôles sont déjà documentés. Pourquoi l’exécution se rompt-elle encore ?

Les rôles documentés décrivent la responsabilité. Ils ne la font pas respecter. L’exécution se rompt aux passations, aux seuils et aux décisions contestées que la documentation n’a jamais tranchés, et que les systèmes tranchent en silence à sa place.

Faut-il corriger le modèle opérationnel avant ou pendant un déploiement S/4HANA ?

Avant, chaque fois que c’est possible. Un programme de systèmes code en dur la responsabilité et les circuits d’approbation. Si le modèle opérationnel n’est pas tranché quand il arrive, l’ambiguïté devient permanente et bien plus coûteuse à changer ensuite.

Par où cela commence-t-il ?

Par un diagnostic senior de l’endroit où votre modèle voulu et votre modèle exécuté divergent, avant tout nouveau programme, outil ou couche de conseil.

Preuves

La preuve avant la méthodologie.

Utilisez les preuves pour réduire le risque d’achat, puis commencez par un diagnostic senior avant d’ajouter un programme, un outil, un atelier ou une couche de conseil.

Ouvrir les preuves

Conception du modèle opérationnel des achats pour une exécution complexe à travers plusieurs unités d’affaires.