Deux directeurs d'agence demandent la même chose avec des mots différents : « Les approbations au-dessus de 2 millions de shillings peuvent-elles nécessiter une double signature ? » Une agence veut ce seuil à 2 millions. L'autre le veut à 5 millions, avec le directeur régional en copie, pas le directeur financier. Les deux demandes sont raisonnables. Aucune, en soi, ne justifie d'écrire du nouveau code.
C'est le moment que tout projet ERP finit par atteindre : une exigence arrive sur la table, et quelqu'un doit décider s'il s'agit d'un réglage, d'une intégration, ou réellement d'un développement spécifique. Prenez cette décision correctement, et le système reste rapide à faire évoluer, facile à mettre à jour et économique à maintenir. Prenez-la mal — traitez chaque demande comme un projet de codage — et le système « flexible » que vous avez acheté devient un fardeau de maintenance en dix-huit mois.
Kraal Code, la plateforme ERP de Chwezi, est construite de façon paramétrable et multi-tenant précisément pour que l'essentiel de ce dont une organisation a besoin — seuils d'approbation, rôles, présentation des rapports, règles de devise et de localisation — soit un réglage, et non un projet logiciel. Cet article expose comment nous décidons, avec nos clients, quand le paramétrage suffit et quand le développement est le bon choix.
Demandez-vous quelle différence est commercialement nécessaire
Partez des deux agences et de leurs seuils d'approbation. Avant d'estimer quoi que ce soit, posez une seule question : cette différence reflète-t-elle une distinction commerciale ou réglementaire réelle entre les agences, ou est-ce simplement « la façon dont on a toujours fait ici » ?
Un seuil différent parce qu'une agence traite des volumes de transactions plus élevés, ou opère sous un plafond réglementaire différent, est une différence commerciale qui mérite d'être préservée. Un seuil différent parce qu'un directeur préfère un certain style de contrôle est une habitude de processus — et les habitudes de processus sont précisément ce qu'une implémentation ERP devrait permettre d'aligner, pas une raison de scinder le système en deux versions qui divergent avec le temps.
C'est le filtre qui précède toute classification technique : cette différence mérite-t-elle d'être conservée ? Ce n'est qu'une fois cette réponse positive que l'on passe à la façon de la prendre en charge.
Quatre catégories, en langage clair
Chaque exigence que nous recevons est classée dans l'une de ces quatre catégories :
- Réglages. Une valeur, une règle ou un seuil qui modifie le comportement sans toucher au code — une limite d'approbation, un taux de taxe, un filtre de rapport, un rôle utilisateur. C'est exactement à cela que sert la couche de paramétrage de Kraal Code, et cela couvre la grande majorité des demandes quotidiennes.
- Extensions. Un nouveau champ, un nouveau rapport ou un nouveau modèle de document qui s'ajoute au système standard sans altérer sa logique centrale. Risque faible, coût maîtrisé, compatible avec les mises à jour.
- Intégrations. Une connexion à un autre système — une passerelle de paiement, un portail fiscal gouvernemental, une API bancaire. La complexité réside ici dans la connexion et le mappage des données, pas dans le cœur de l'ERP lui-même.
- Modifications du cœur. Un changement réel dans le fonctionnement de la logique sous-jacente du système — une nouvelle structure de processus d'approbation, un nouveau type de transaction que la plateforme ne modélise pas actuellement. C'est là que l'effort de développement réel a sa place.
La plupart des demandes sont des réglages. Certaines sont des extensions. Un nombre plus restreint sont des intégrations. Les véritables modifications du cœur sont, et doivent rester, rares — et chacune doit être une décision délibérée, pas une réponse par défaut à « le système ne fait pas encore X ».
Documentez la règle avant d'estimer le travail
Avant qu'une exigence ne reçoive une estimation — que la réponse soit « changer un réglage cet après-midi » ou « cadrer une tâche de développement » — notez-la sous une forme qui résistera à l'épreuve d'un développeur, d'un testeur et d'un auditeur dans dix-huit mois :
- La règle. Formulée comme une règle métier, pas comme une description d'écran : « Les achats au-dessus de 2 000 000 UGX nécessitent l'approbation du directeur régional », pas « ajouter un deuxième bouton d'approbation ».
- L'acteur. Qui déclenche la règle, et qui l'approuve ou agit sur elle.
- L'exception. Que se passe-t-il lorsque la règle standard ne s'applique pas — un achat d'urgence, une délégation d'autorité pendant un congé, une dérogation ponctuelle.
- L'exemple d'acceptation. Un exemple concret, avec des chiffres réalistes (anonymisés si nécessaire), qu'un testeur peut utiliser pour confirmer que la règle se comporte comme spécifié.
Une exigence rédigée ainsi est sans ambiguïté à paramétrer, tester et auditer. Une exigence formulée comme « rendez-le plus flexible » n'est claire pour personne, et c'est précisément là que la dérive de périmètre commence discrètement.
Comparez le coût complet, pas seulement la première estimation
L'estimation de développement est le plus petit chiffre de cette décision. Avant de vous engager dans un développement spécifique, comparez-la à :
- Les mises à jour futures. Le paramétrage et les extensions standard avancent avec chaque mise à jour de la plateforme. Les modifications du cœur logique doivent être retestées, et parfois reconstruites, à chaque nouvelle version.
- L'effort de test. Un changement de réglage nécessite une vérification de régression rapide. Une modification du cœur nécessite un cycle de test complet sur chaque processus qu'elle touche.
- La responsabilité du support. Qui la corrige en année trois, quand la personne qui l'a écrite est partie ? Le paramétrage standard est pris en charge dans le cadre de la plateforme. Le code sur mesure est pris en charge par celui qui accepte, par écrit, d'en être responsable.
- La portabilité des données. Le changement conserve-t-il vos données dans une structure standard et exportable, ou introduit-il une forme de données sur mesure que seul ce module spécifique comprend ?
Pesée face à ces quatre facteurs, une « personnalisation rapide » qui semblait moins chère que de revoir un processus s'avère souvent, sur trois ans, le chemin le plus coûteux — non pas parce que le développement initial était surévalué, mais parce que personne n'avait chiffré ce qui se passe après la mise en production.
Deux exemples concrets
Le paramétrage suffit : Une entreprise de distribution souhaite acheminer différemment les approbations d'achat selon qu'il s'agit d'articles de stock ou de fournitures de bureau, avec des seuils différents pour chaque catégorie. Il s'agit d'un rôle, d'un indicateur de catégorie et d'une règle d'approbation — tous relevant du paramétrage standard au sein des modules achats et approbations de Kraal Code. Aucun développement n'est nécessaire.
Le développement est réellement nécessaire : Une entreprise de logistique doit répartir une seule facture client sur trois centres de coûts selon des ratios de poids de livraison calculés à partir de données que l'ERP ne capture pas actuellement au niveau de la ligne. Il s'agit d'une nouvelle logique de calcul et d'une nouvelle structure de données — une véritable modification du cœur, à cadrer et estimer comme telle.
La différence entre ces deux cas n'est pas la complexité de la demande — les deux paraissent compliqués quand un directeur les décrit pour la première fois. La différence est de savoir si les règles et le modèle de données du système standard ont déjà une place pour l'exigence, ou si la plateforme doit réellement apprendre quelque chose de nouveau.
Consignez la décision — et révisez-la
Chaque décision paramétrage-ou-développement doit être consignée par écrit : ce qui a été demandé, dans quelle catégorie cela est tombé, pourquoi, et qui a validé. Ce registre remplit deux fonctions. Il évite que le même débat ne se répète dix-huit mois plus tard quand plus personne ne se souvient pourquoi un seuil est fixé ainsi. Et il vous donne un déclencheur clair pour revoir la décision — quand la politique change, quand l'organisation franchit un seuil de taille, ou quand une solution de contournement construite pour une agence est discrètement copiée par trois autres.
Où se situe Kraal Code
Kraal Code est construit de façon paramétrable dans les domaines du contrôle financier, des achats, de l'inventaire, de la paie, des ventes, des actifs et des approbations — précisément pour que la classification ci-dessus penche bien plus souvent vers le paramétrage que vers le développement. Lorsqu'une véritable modification du cœur ou une intégration est nécessaire, l'équipe de développement spécifique de Chwezi la cadre comme un travail défini et estimé, avec la responsabilité du support convenue avant sa construction — pas supposée après coup.
Si votre équipe pèse actuellement une exigence délicate, apportez-la à une conversation Kraal Code et demandez-nous de la classifier : paramétrage, intégration ou développement. Cette classification, effectuée honnêtement avant qu'une seule ligne de code ne soit écrite, est l'étape à plus fort effet de levier de toute la décision.
| Exigence | Adéquation standard | Alternative | Travail spécifique | Responsable futur | Preuve d'acceptation |
|---|---|---|---|---|---|
| ex. Seuil d'approbation d'agence | Oui / Non | ? | ? | ? | ? |
Foire aux questions
Comment savoir si une demande est « juste un réglage » ou quelque chose de plus important ?
Notez la règle en utilisant quatre éléments : la règle, l'acteur, l'exception, l'exemple d'acceptation. Si les exceptions se multiplient à mesure que vous les écrivez, c'est généralement le signe que la demande nécessite un véritable cadrage de développement plutôt qu'un simple changement de réglage.
Chaque fonctionnalité personnalisée augmente-t-elle le coût à long terme ?
Pas automatiquement, mais chaque fonctionnalité personnalisée ajoute une obligation de support que quelqu'un doit assumer, par écrit, dès le premier jour. Les fonctionnalités cadrées et estimées en tenant compte de cette obligation deviennent rarement des fardeaux.
Le paramétrage peut-il gérer les différences entre agences ou régions ?
Souvent, oui. La couche de paramétrage de Kraal Code prend en charge les approbations basées sur les rôles, le traitement multi-devises et les règles spécifiques à la localisation en tant que réglages standard.
Que se passe-t-il si nous construisons quelque chose de spécifique et voulons ensuite revenir au paramétrage standard ?
La portabilité des données compte au moment de la décision. Une fonctionnalité spécifique construite sur le modèle de données standard peut généralement être retirée au profit du paramétrage plus tard. Une fonctionnalité construite sur une structure de données sur mesure est bien plus difficile à défaire.
Poursuivez avec Votre organisation est-elle prête à déployer un ERP ? pour les questions de préparation qui précèdent celle-ci.
