ERP et systèmes métier
L’ERP échoue quand il copie un catalogue de modules. Je modèle lots, palettes, factures et rôles tels qu’ils existent sur le terrain.
FRIGO SYS et AnyWare ERP ont été construits ainsi : opérations d'entrepôt et multi-verticales, pas un tableur avec une interface.
FRIGO SYS est un ERP froid construit comme application desktop native Tauri plutôt qu'un dashboard web, parce que le terrain de l'entrepôt n'a pas toujours une connexion fiable, et qu'une app native avec un cœur Rust tourne sans onglet de navigateur ouvert. Chaque mouvement d'entrée ou de sortie est enregistré contre un lot précis, avec emballage, nombre de palettes, tare et poids net saisis comme le faisaient les bons papier avant — le modèle de données reflète le processus physique plutôt que de forcer le processus dans une table produit générique.
AnyWare ERP est la version multi-verticale de la même idée : une plateforme Laravel et React modulaire avec une couche de données partagée, si bien qu'une vente met à jour le stock et la compta dans la même transaction sans étape de synchronisation séparée, et chaque entreprise n'active que les modules dont ses opérations ont réellement besoin — ventes, stock, RH, compta, reporting.
Les rapports sont générés à partir des mêmes mouvements enregistrés qui ont piloté les écrans opérationnels, pas reconstruits séparément en fin de mois. C'est la différence entre un rapport qui prend des secondes parce que les données étaient déjà structurées pour ça, et un qui prend des jours parce qu'il faut d'abord le reconstruire à partir de tableurs.
Problèmes métier
- Un ERP qui copie un catalogue de modules génériques au lieu de modéliser les lots, palettes, factures et rôles tels qu'ils existent sur le terrain de l'entrepôt.
- Stock et facturation suivis dans des tableurs qui divergent de la réalité dès que deux personnes les modifient en même temps, sans traçabilité au niveau du lot.
- Un précédent déploiement ERP qui a forcé l'entreprise à contourner un logiciel construit pour un autre type d'entreprise.
- Un module ERP générique « inventaire » qui n'a aucune notion de lot, de zone de température ou de palette, si bien que l'équipe entrepôt le contourne de toute façon avec un tableur parallèle.
- Des permissions de rôle rajoutées après coup, si bien qu'un opérateur d'entrepôt peut modifier par accident la facture d'un client parce que personne n'a modélisé qui devait pouvoir toucher quoi.
- Aucun moyen de réimprimer ou reconstruire un document historique — une ancienne facture, un ancien bon — parce que le système n'a jamais montré que l'état courant, jamais un historique.
Processus de développement
- Modéliser d'abord les vraies entités — un lot, une palette, le stock d'un client — avant que tout ça devienne un écran ou un rapport.
- Laravel et React pour les opérations multi-verticales, ou une app desktop native Tauri et Rust quand le terrain n'a pas de connexion fiable.
- Brancher facturation et reporting sur les mêmes mouvements enregistrés qui pilotent les écrans opérationnels, pour qu'un rapport soit une requête, pas une reconstruction.
- Définir les rôles autour de ce que fait réellement une personne sur le terrain — réception, préparation, facturation — pas autour d'étiquettes admin/utilisateur génériques qui ne correspondent pas au poste.
- Tester le modèle de données sur une vraie semaine des mouvements réels de l'entreprise avant de construire le reste des écrans, pour que les entités soient prouvées, pas supposées.
- Modéliser devise et localisation comme des champs de premier ordre sur chaque enregistrement pertinent dès le départ si l'entreprise opère dans plusieurs, plutôt que de le rajouter plus tard.
- Garder chaque document généré — facture, bon, rapport — récupérable exactement tel qu'il a été émis, pour qu'un enregistrement historique puisse être réimprimé ou audité des mois plus tard.
Ce que vous obtenez
- Une précision de stock qui reflète ce qui est vraiment dans l'entrepôt, parce que chaque mouvement est enregistré contre un lot précis plutôt qu'un total générique.
- Une facturation générée en secondes à partir des mouvements enregistrés au lieu d'être reconstruite à la main en fin de mois.
- Un système calé sur le vrai fonctionnement de l'entreprise, comme le sont FRIGO SYS et AnyWare ERP pour leurs opérateurs.
- Des permissions qui correspondent à qui doit réellement toucher quoi, plutôt que tout le monde en accès admin parce que personne n'a modélisé les rôles correctement.
- Un système éprouvé sur une vraie semaine d'opérations avant que le reste ne soit construit, pour que les fondations n'aient pas à être refaites plus tard.
- Des opérations multi-devises ou multi-sites gérées nativement plutôt que rafistolées avec des tableurs parallèles de conversion manuelle.
- Tout document historique réimprimable exactement tel qu'émis, des mois ou des années plus tard, pour un audit ou un litige client.
Projets choisis
FAQ
Do you implement Odoo or SAP?
I build custom systems when off-the-shelf ERP does not match the workflow. I can also integrate around existing tools via APIs.