Votre DSI débarque avec une liste de 23 outils différents, chacun acheté par une direction distincte. Les achats ont leur ERP, les finances leur logiciel comptable, les opérations leur système de suivi, et le service client sa plateforme CRM. Rien ne communique. Les mêmes données sont ressaisies trois fois entre la demande initiale et la livraison finale. Personne n'a décidé de ce chaos, mais tout le monde le subit.
Le problème n'est pas technique. C'est un problème d'architecture décisionnelle : vous avez découpé votre système d'information selon l'organigramme, pas selon vos flux opérationnels. Résultat, chaque outil s'arrête à la frontière de sa direction, et chaque processus métier traverse plusieurs outils qui ne se parlent pas.
Voici comment passer d'une logique de silos à une architecture par processus, sans tout jeter.
Comment le SI se fragmente : personne ne décide, chaque direction achète
Le scénario commence toujours pareil. La direction des achats constate qu'Excel ne suit plus, donc elle consulte trois éditeurs et choisit un ERP achats. Deux mois plus tard, la finance découvre que l'ERP achats ne lui envoie pas les données dans le bon format, donc elle achète son propre logiciel comptable. Pendant ce temps, les opérations lancent un appel d'offres pour un système de gestion des demandes d'intervention parce qu'elles reçoivent les informations avec cinq jours de retard.
Chaque décision est rationnelle au niveau local, mais personne ne voit qu'un même processus métier (par exemple, achat-facture-paiement) traverse maintenant quatre outils distincts. Les frontières techniques suivent les frontières hiérarchiques, et chaque passage d'une direction à l'autre devient un point de friction : export CSV manuel, resaisie partielle, délai incompressible.
Ce qui génère le chaos, ce n'est pas l'absence de standardisation technique. C'est l'absence de cartographie par processus. Si vous ne savez pas quels flux métier traversent quelles directions, vous ne pouvez pas savoir si un outil est pertinent ou s'il ajoute un nouveau maillon isolé.
Le symptôme mesurable : combien de fois la même donnée est ressaisie entre l'entrée et la sortie d'un processus
Voici un test simple pour diagnostiquer une architecture en silos. Prenez un processus métier de bout en bout (achat d'une prestation, traitement d'une demande client, paiement d'un fournisseur), et comptez combien de fois une même information (référence client, montant HT, date de livraison) doit être ressaisie ou copiée-collée d'un outil à l'autre.
Si la réponse est zéro, votre SI est déjà structuré par processus. Si la réponse est deux, vous êtes dans la moyenne des grandes organisations au Maroc. Si la réponse est quatre ou plus, vous êtes en situation de fragmentation avancée.
La resaisie n'est pas seulement un irritant opérationnel. C'est un indicateur de couplage architectural faible : chaque direction possède sa propre copie de la vérité, et personne ne sait quelle version est la bonne. Quand un litige survient (date de paiement erronée, quantité contestée), il faut reconstituer la chaîne manuellement, et chaque outil raconte une version différente.
Mesurer la fréquence de resaisie vous donne deux chiffres : le nombre de transitions inter-outils dans un processus, et le nombre de transitions sans API automatisée. Si vous avez un ratio élevé, vous savez que chaque nouvelle couche logicielle ajoutée par une direction agrandit le problème plutôt que de le résoudre.
Découper par processus : la matrice processus x direction à construire avant toute consultation
Le correctif, ce n'est pas d'imposer un éditeur unique ou de fusionner les budgets IT. C'est de forcer une cartographie processus avant toute décision d'achat. Concrètement, vous construisez une matrice à deux axes : en ligne, vos processus métier de bout en bout (achat-facture-paiement, demande-validation-exécution, entrée-traitement-archivage), et en colonne, vos directions opérationnelles (achats, finance, opérations, service client).
Chaque cellule de la matrice indique quelle direction intervient à quelle étape du processus. Par exemple, pour le processus achat-facture-paiement :
- Achats : demande, sélection fournisseur
- Opérations : validation technique, réception
- Finance : comptabilisation, paiement
Une fois la matrice construite, vous voyez immédiatement qu'un outil acheté par la seule direction Achats ne couvrira jamais le processus complet, parce que ce processus traverse trois directions. L'outil doit donc soit être multi-directions (un ERP partagé), soit communiquer automatiquement avec les outils des deux autres directions (via API), soit être remplacé par une solution qui couvre le flux de bout en bout.
Cette matrice devient votre filtre décisionnel. Avant toute consultation, posez la question : quel processus ce nouvel outil adresse-t-il ? Quelles directions traversent ce processus ? Si l'outil ne couvre qu'une seule case de la matrice, il créera un silo supplémentaire, sauf si une intégration automatique avec les cases adjacentes est prévue dès le départ.
Trois processus qui traversent toujours l'organisation : achat-facture-paiement, demande-validation-exécution, entrée-traitement-archivage
Certains processus se retrouvent dans presque toutes les organisations, quels que soient le secteur ou la taille. En cartographier trois suffit généralement à révéler 80 % des frictions inter-directions.
Achat-facture-paiement : de la demande d'achat initiale (un service opérationnel) au paiement effectif (finance), en passant par la validation budgétaire, la sélection du fournisseur, la réception, et la comptabilisation. Ce processus traverse souvent quatre ou cinq directions. Si chaque étape utilise un outil différent sans API, vous obtenez des cycles de paiement de 45 jours au lieu de 15, simplement à cause du temps de propagation inter-systèmes.
Demande-validation-exécution : toute organisation reçoit des demandes (clients, employés, partenaires), les valide (conformité, budget, priorité), puis les exécute (livraison, intervention, paiement). Ce flux traverse toujours au moins trois services. Si la demande arrive dans un système CRM, que la validation se fait dans une feuille Excel partagée, et que l'exécution se pilote dans un ERP opérationnel, le processus accumule des délais incompressibles à chaque frontière.
Entrée-traitement-archivage : toute donnée reçue (facture, contrat, demande) suit un cycle identique. Elle est saisie une première fois, traitée par plusieurs services, puis archivée pour audit ou contentieux. Si chaque service utilise son propre référentiel, vous ne savez pas où se trouve la version de référence. Résultat : en cas d'audit ou de litige, vous perdez deux jours à reconstituer le dossier complet.
En cartographiant ces trois processus via la matrice processus x direction, vous savez immédiatement où se trouvent vos frictions structurelles, et quel outil ou quelle intégration doit être prioritaire.
Quand un outil par direction reste légitime (et le test pour le savoir)
Tous les outils ne doivent pas être mutualisés. Certains processus sont strictement intra-direction, et dans ce cas, un outil dédié est non seulement légitime, mais préférable.
Voici le test : tracez le processus complet de bout en bout. Si toutes les étapes du processus (de l'entrée à la sortie) se déroulent au sein d'une seule direction, sans handoff vers une autre, alors un outil spécifique à cette direction est justifié. Par exemple, un logiciel de planification de tournées pour la logistique interne, ou un outil de conception technique pour un bureau d'études.
En revanche, si le processus traverse plusieurs directions, même partiellement, l'outil doit soit couvrir toutes les étapes, soit exposer une API pour permettre aux étapes suivantes de récupérer les données automatiquement. Le critère, c'est la continuité du flux : si un humain doit copier-coller des données d'un outil à un autre, ou si un export CSV hebdomadaire est nécessaire pour passer à l'étape suivante, c'est un silo, pas une spécialisation légitime.
La règle simple : si la donnée quitte l'outil pour continuer son parcours métier, cet outil doit parler automatiquement avec le suivant. Si la donnée ne quitte jamais l'outil, il peut rester isolé.
Ce que la matrice change dans votre appel d'offres : un périmètre, pas une liste de modules
Les appels d'offres classiques ressemblent à une liste de courses : 47 fonctionnalités obligatoires, 23 fonctionnalités souhaitables, chacune notée sur 5 points. Les éditeurs cochent toutes les cases, puis implémentent un module par direction, et vous vous retrouvez avec le même silo qu'avant, mais dans un seul progiciel.
Avec la matrice processus x direction, l'appel d'offres change de nature. Vous ne demandez plus "couvrez-vous la gestion des achats, la comptabilité, et le suivi opérationnel ?". Vous demandez "comment votre solution gère-t-elle le processus achat-facture-paiement de bout en bout, sans resaisie, entre les trois directions concernées ?".
Concrètement, cela signifie :
- Spécifier les transitions inter-directions comme des exigences fonctionnelles (exemple : "la validation budgétaire en finance doit déclencher automatiquement la notification au service demandeur, sans export manuel")
- Demander une démonstration de flux complet, pas de modules isolés (montrez-nous le parcours d'un achat, de la demande initiale au paiement effectif, dans votre plateforme)
- Évaluer les éditeurs sur le nombre de resaisies manuelles nécessaires pour compléter un processus de bout en bout, pas sur le nombre de modules disponibles
Le changement, c'est que vous achetez un périmètre opérationnel (un processus entier), pas une collection de fonctionnalités. Si un éditeur ne peut pas couvrir le processus complet, il doit prouver que son outil s'intègre avec les outils existants des autres directions, via API, sans export CSV ni copier-coller.
Séquencer : par quel processus commencer, et sur quel critère
Vous ne pouvez pas restructurer tout le SI d'un coup. Il faut choisir un premier processus à rendre fluide, puis itérer. Voici les trois critères pour décider par où commencer.
Critère 1 : fréquence. Quel processus se répète le plus souvent ? Si vous traitez 200 demandes d'achat par mois et seulement 10 litiges client, commencez par le processus achat-facture-paiement. Chaque optimisation aura un impact immédiat sur le quotidien des équipes.
Critère 2 : coût de friction. Quel processus génère le plus de retard ou d'erreur à cause de la fragmentation ? Si vos cycles de paiement fournisseur atteignent 60 jours alors que le contrat prévoit 30, et que ce retard provient d'une resaisie entre finance et achats, c'est un signal clair. Mesurez le temps passé en resaisie, export, réconciliation manuelle, puis multipliez par la fréquence annuelle.
Critère 3 : valeur métier. Quel processus a l'impact le plus direct sur votre chiffre d'affaires ou votre capacité opérationnelle ? Un processus de facturation client fluide réduit votre DSO (Days Sales Outstanding) et améliore votre trésorerie. Un processus de traitement de demandes d'intervention plus rapide augmente la satisfaction client et réduit les pénalités contractuelles.
Appliquez ces trois critères à vos processus cartographiés dans la matrice. Le processus qui cumule fréquence élevée, coût de friction important, et impact métier direct devient votre priorité. Commencez par celui-ci, implémentez une solution qui couvre le flux de bout en bout, puis passez au suivant.
L'erreur fréquente, c'est de commencer par le processus le plus complexe ou le plus "stratégique". Commencez par celui qui génère le plus de resaisies répétitives et qui touche le plus de personnes, parce que vous aurez un retour sur investissement visible en quelques semaines, et que vous aurez construit une référence interne pour la suite.
FAQ
Peut-on garder les outils existants et juste ajouter des API entre eux ?
Oui, si les outils exposent des API standardisées (REST, GraphQL) et que vous avez une équipe capable de maintenir ces intégrations. Le risque, c'est que chaque mise à jour d'un outil peut casser l'intégration avec les autres, et que vous passiez plus de temps à maintenir les connecteurs qu'à améliorer les processus. La règle : si vous avez moins de cinq outils et qu'ils exposent tous des API documentées, l'intégration est faisable. Au-delà de cinq outils ou si certains sont des progiciels fermés, il vaut mieux remplacer par une plateforme unifiée sur les processus prioritaires.
Comment convaincre les directions de renoncer à leur outil dédié ?
Ne leur demandez pas de renoncer à leur outil. Demandez-leur de mesurer combien de fois elles resaisissent des données qui viennent d'un autre service, et combien de temps elles passent à réconcilier les versions contradictoires. Ensuite, montrez-leur la matrice processus x direction et faites calculer le coût annuel de ces frictions. Quand une direction voit qu'elle passe 15 jours par mois à exporter, importer, et nettoyer des données, elle accepte plus facilement une solution qui réduit ce temps à zéro, même si elle perd un peu de contrôle local.
Doit-on attendre d'avoir cartographié tous les processus avant de lancer un projet ?
Non. Cartographiez les trois processus transverses de base (achat-facture-paiement, demande-validation-exécution, entrée-traitement-archivage), identifiez celui qui génère le plus de friction, et lancez un projet pilote sur celui-ci uniquement. Une fois ce processus fluide, vous aurez un modèle de référence et des métriques avant-après qui faciliteront la cartographie et l'optimisation des autres processus. L'approche séquentielle (un processus à la fois) réduit le risque et génère des résultats tangibles plus rapidement qu'un projet de refonte globale.
Quel est le rôle de la DSI dans cette restructuration ?
La DSI devient gardienne de la matrice. Elle refuse tout achat d'outil qui ne spécifie pas quel processus il adresse et comment il s'intègre avec les outils des directions adjacentes dans ce processus. Elle impose une règle simple : avant toute consultation, la direction demandeuse doit remplir la ligne du processus concerné dans la matrice et identifier quelles autres directions sont impliquées. Si l'outil proposé ne couvre qu'une seule case, la DSI exige soit une API d'intégration documentée, soit une justification prouvant que ce processus est strictement intra-direction.
Combien de temps faut-il pour passer d'une architecture en silos à une architecture par processus ?
Cela dépend du nombre de processus prioritaires et de la taille de votre SI actuel. Pour une organisation de 200 à 500 personnes, restructurer un premier processus critique (achat-facture-paiement, par exemple) prend généralement entre 4 et 6 mois, de la cartographie initiale au déploiement complet. Si vous séquencez correctement (un processus à la fois), vous obtenez des résultats mesurables tous les semestres, et vous évitez les projets de transformation multi-annuels qui échouent souvent à mi-parcours. L'objectif, ce n'est pas de tout refaire en une fois, mais de réduire progressivement le nombre de resaisies jusqu'à atteindre zéro sur les processus les plus fréquents.
Besoin d'aide pour cartographier vos processus métier et structurer votre SI ? ClaroDigi accompagne les entreprises marocaines dans leur transformation digitale, de l'audit initial à la mise en œuvre. Nous réalisons également des audits SI complets pour identifier vos frictions opérationnelles et prioriser vos investissements, ainsi que des projets d'intégration de systèmes pour fluidifier vos processus. Si vous développez des applications métier sur mesure, nous vous aidons à les concevoir autour de vos flux opérationnels, pas autour de votre organigramme.