ERP ou application métier : placer les règles au bon endroit

Distinguer besoin standard et différence réelle

Décrivez le processus actuel, puis recherchez ce que l’ERP peut couvrir par paramétrage. Une préférence d’écran ne justifie pas toujours un logiciel distinct. En revanche, une règle de production particulière ou un parcours terrain peut demander une extension. Faites essayer le cas normal et les exceptions dans une démonstration préparée avec vos scénarios.

Les écarts sont classés : fonction absente, règle configurable, adaptation spécifique ou changement d’organisation accepté. Chaque écart a un décideur et une conséquence. Un développement qui recopie un module standard peut coûter davantage à maintenir ; une contrainte imposée à l’organisation peut aussi créer des ressaisies. Le choix doit rendre ces effets visibles.

Désigner les systèmes qui font autorité

Attribuez un propriétaire aux clients, articles, tarifs, commandes et écritures comptables. Si l’ERP conserve le référentiel client, l’application métier ne doit pas créer une version concurrente sans règle de rapprochement. Les identifiants stables sont plus utiles qu’une correspondance fondée uniquement sur un libellé. Le cahier des charges décrit les créations, modifications et suppressions échangées.

Les échanges peuvent être des fichiers ou des API selon le besoin. Définissez la fréquence, le journal des erreurs et la reprise après indisponibilité. Un flux bidirectionnel demande une règle en cas de modification simultanée. Faites tester une correction comptable ou une annulation de commande : la cohérence est souvent plus difficile à démontrer sur ces opérations que sur la création initiale.

Évaluer le coût des évolutions

Une adaptation d’ERP peut être affectée par les mises à jour du fournisseur. Une application indépendante peut être affectée par une évolution de l’API ou des formats. Le devis doit indiquer qui surveille ces dépendances et qui prend en charge les tests de compatibilité. Les licences et le support des deux ensembles doivent être chiffrés séparément.

Demandez une documentation qui rende explicite la répartition des règles. Si la validation est dans l’application et le calcul financier dans l’ERP, une correction ne doit pas être effectuée dans un seul côté sans vérification. Le responsable métier réceptionne le parcours complet. La capacité à remplacer un composant ou à confier sa maintenance à un tiers doit être étudiée avant la signature.

Exercice fictif pour préparer la recette

Prenez une commande fictive dont le référentiel client appartient à l’ERP et dont une validation particulière serait gérée par l’application. Décrivez les créations et les modifications dans chaque système. Le candidat doit indiquer où l’état de référence est consulté et comment une modification du client est répercutée. Une duplication de libellés sans identifiant commun est un point à traiter.

Simulez une annulation après transmission. La recette vérifie l’état de la commande, la pièce comptable éventuelle et les traces de l’échange. Les responsables des deux outils doivent comprendre la décision attendue. Si le processus exige une correction manuelle, son rôle et son contrôle apparaissent dans le périmètre.

Demandez ensuite comment une mise à jour de l’ERP affectera l’interface. La personne qui suit la compatibilité, l’environnement d’essai et les conditions de maintenance doivent être connus. Cet exercice permet de comparer un paramétrage intégré et une application complémentaire sur le même résultat métier, en tenant compte des responsabilités de part et d’autre de la connexion.

Une fiche de consultation à remplir avec le métier

Pour utiliser cette grille, réunissez le responsable du processus, un utilisateur qui connaît les exceptions et la personne qui suivra le budget. Préparez un exemple fictif représentatif plutôt qu’une base réelle. Pour chaque ligne, faites décrire l’état actuel, le résultat voulu et la personne habilitée à arbitrer un écart. Les éléments inconnus restent identifiés comme des investigations à mener avant l’engagement de réalisation.

Demandez au candidat de reprendre cette grille dans sa proposition, avec les livrables inclus et les exclusions. Une réponse qui ne couvre qu’un cas normal doit être précisée. Les erreurs, les annulations et les reprises après incident peuvent modifier le coût et le fonctionnement. Conservez les hypothèses acceptées avec le périmètre de recette afin que le responsable puisse vérifier la livraison.

Le rôle de Suite Métier est la mise en relation. Le prestataire confirme la faisabilité, son architecture et son devis après examen du besoin. Les modalités de reprise, les droits contractuels et les engagements de support sont à convenir avec lui. Aucun délai de réalisation ni résultat financier n’est garanti par cette fiche. Le décideur reste maître du choix et de la réception.

Questions pratiques

Préparer la suite du projet

• Migration Access vers une application web : cadrage, reprise et devis
• Demander un devis et cadrer votre besoin
• Cahier des charges métier : exprimer usages et critères de recette
• Audit de l’application existante : connaître les dépendances
• Power Apps ou application sur mesure : comparer les contraintes
• Notre méthode de sélection et de traitement des demandes
• Cadrer le remplacement d’un outil Access ou Excel