Faut-il un logiciel de gestion d’engins quand on a un ERP ?
L’ERP est le plus souvent l’enregistrement principal de la comptabilité et de l’administration, et le logiciel de terrain celui de l’événement qui naît à côté de l’engin ; les deux voient le même travail à une résolution différente. Savoir si un logiciel de gestion d’engins distinct est nécessaire quand on a un ERP dépend de la capacité de votre ERP à répondre aux questions à l’échelle de l’heure et du jour avec un niveau de détail utilisable par l’utilisateur de terrain : quel engin a travaillé quel jour, quand il s’est arrêté, à quel compteur arrive sa maintenance, combien de carburant il a pris.
Si la question ne porte que sur le montant de fin de mois, c’est-à-dire « combien de factures ont été imputées à cet engin ce mois-ci », l’ERP suffit le plus souvent. La différence tient à ceci : l’ERP voit quelque chose quand un document est saisi, il ne voit rien quand l’engin s’arrête. Si vous n’avez pas d’ERP mais Excel et un groupe de messagerie, la comparaison se construit autrement ; pour cela, voyez le guide Excel ou logiciel.
Les domaines dont l’ERP est le propriétaire de l’enregistrement principal
Dans les domaines ci-dessous, un logiciel de terrain qui essaie de remplacer l’ERP produit lui-même des incohérences. Le côté terrain y fait référence, il ne les réécrit pas.
- Comptabilité et reporting financier : écritures de journal, bilan, enregistrements servant de support à la déclaration fiscale.
- Enregistrement de la commande d’achat et compte du fournisseur : numéro de commande, échéance, paiement.
- Clôture de période et valorisation financière : opérations de fin de mois et de fin d’année des écritures officielles.
- Immobilisations : valeur d’entrée à l’actif de l’engin et amortissement. Pour la durée et la méthode, consultez votre expert-comptable.
- Paie : enregistrement officiel de la rémunération du personnel et du coût employeur.
L’événement qui naît à côté de l’engin s’efface avant d’atteindre l’ERP
Exemple : une pelle s’est arrêtée à 9 h 40 à cause d’un flexible hydraulique éclaté et a redémarré à 16 h 10. Dans l’enregistrement de terrain, c’est un arrêt de 6 h 30 min ; l’engin, l’heure et la cause sont connus. Dans l’ERP, le même événement apparaît quand la facture du flexible est saisie, le plus souvent des jours plus tard, comme une seule ligne de dépense de maintenance. La durée de l’arrêt, le projet auquel il appartient, la question de savoir s’il sera déduit de la location, tout cela n’entre jamais dans l’ERP.
Le rôle du logiciel de terrain est de saisir ces instants que l’ERP ne voit pas. Les événements qui naissent à côté de l’engin sont les suivants :
- Panne : qui l’a signalée, quand, sur quel engin ; l’engin était-il en état de fonctionner.
- Compteur : heures de fonctionnement et kilométrage, support du moment de la maintenance.
- Pointage : l’engin a travaillé ce jour-là, était en attente, en panne ou en route.
- Arrêt : avec ses heures de début et de fin, ainsi que sa cause.
- Plein de carburant : sur quel engin, combien de litres, à quelle valeur de compteur.
- Moment de la maintenance : travail planifié qui arrive selon le compteur réel.
L’utilisateur est lui aussi différent : le comptable et le chef d’équipe
Les écrans de comptabilité, d’achats et de finance de l’ERP s’utilisent le plus souvent à un bureau et à partir de documents. Les utilisateurs du logiciel de terrain sont le chef d’équipe, l’opérateur, le chef du matériel et le chef de chantier : sur un téléphone ou une tablette, ils ouvrent un enregistrement toutes les deux minutes, et la personne qui écrit cet enregistrement n’entre le plus souvent jamais dans l’ERP. Transformer tous les utilisateurs de terrain en utilisateurs de l’ERP est une affaire à part en matière de licences, de formation et d’adaptation des écrans ; il est le plus souvent plus réaliste de regarder d’abord si les deux logiciels se complètent.
Les cas où l’ERP suffit à lui seul
Toute société n’a pas besoin d’un logiciel de terrain distinct. L’ERP suffit le plus souvent si les trois conditions suivantes sont réunies à la fois :
- Les engins sont peu nombreux, travaillent sur un seul chantier et vos questions se situent au niveau du mois : quelle dépense a été imputée à quel engin ce mois-ci.
- Une seule personne tient déjà l’information sur les pannes et les arrêts et saisit aussi les données dans l’ERP ; il n’est pas nécessaire que l’enregistrement soit réparti entre d’autres utilisateurs.
- Le décompte de location d’un engin loué se fait non pas par pointage, mais par un montant mensuel fixe.
Où naît chaque donnée, où vit-elle
La répartition ci-dessous est le schéma habituel pour une société avec ERP. Chaque entreprise l’adapte à son propre ERP ; la liaison à mettre en place est déterminée lors de l’étude technique.
Répartition des données entre l’ERP et le logiciel de terrain
| Donnée | Lieu de naissance | Propriétaire de l’enregistrement principal | Ce qui part vers l’autre côté |
|---|---|---|---|
| Fiche engin et immobilisation | ERP : achat et mise à l’actif | Partie financière : ERP ; partie compteur, documents et maintenance : logiciel de terrain | Le code, le nom et la société de l’engin viennent de l’ERP vers le logiciel de terrain ; le compteur et les documents ne vont pas vers l’ERP |
| Projet et centre de coûts | ERP | ERP | Le code de projet vient vers le logiciel de terrain ; le coût de l’engin est écrit sur ce code |
| Compte fournisseur et compte du loueur | ERP | ERP | Le compte reste dans l’ERP ; le code commun avec lequel le loueur et la société de service seront appariés dans les deux systèmes est déterminé lors de l’étude technique |
| Commande d’achat | ERP s’il y en a un ; sinon module de demandes et d’achats | Le système dans lequel la commande a été ouverte | Le numéro de commande sert de référence à l’enregistrement de terrain ; le besoin du terrain part vers l’ERP sous forme de demande |
| Enregistrement de panne et ordre de travail | À côté de l’engin : opérateur ou chef d’équipe | Logiciel de terrain | Le récapitulatif du coût de réparation (main-d’œuvre, pièces, service externe) et la référence de la panne partent vers l’ERP |
| Heures de fonctionnement et compteur | Engin ou télémétrie ; à défaut, Excel | Logiciel de terrain | Sur demande, le récapitulatif des heures de fonctionnement de fin de période |
| Pointage et situation du jour | Chantier ; le brouillon se forme à partir du compteur et de l’arrêt | Logiciel de terrain ; le chef de chantier approuve | Récapitulatif mensuel approuvé ; pour un engin loué, donnée d’entrée du décompte de location |
| Plein de carburant | Point de distribution | Logiciel de terrain (engin, litres, compteur) | Le plein est écrit sur l’engin ; la facture de carburant et la valeur du stock restent dans l’ERP |
| Moment de la maintenance planifiée | Compteur réel | Logiciel de terrain | Coût de l’ordre de travail de maintenance |
| Contrat de location, décompte et paiement | Contrat ; le montant du décompte vient du pointage approuvé | Calcul du décompte : terrain ; facture, échéance et paiement : ERP | Le montant approuvé de la période va vers l’ERP ; la facture du loueur vient de l’ERP pour la comparaison |
| Paie et coût de main-d’œuvre | Paie de l’ERP | ERP | Le coût employeur mensuel d’une personne est saisi dans le logiciel de terrain, converti en taux horaire et écrit comme main-d’œuvre dans l’enregistrement de panne et de maintenance ; le récapitulatif des heures de travail va vers l’ERP |
D’où naissent la double saisie et l’incohérence
Exemple (les chiffres sont des hypothèses) : pour une pelle, l’enregistrement de terrain indique 38 000 TL de dépenses de réparation sur un mois ; 21 000 TL de pièces et de service externe et 17 000 TL de main-d’œuvre interne. Dans l’ERP, le compte de dépenses de maintenance du même mois affiche 21 000 TL, car la main-d’œuvre interne est déjà inscrite en paie comme salaire. Les deux chiffres mesurent des choses différentes et tous deux peuvent être justes. L’incohérence apparaît quand il n’est pas écrit lequel est le coût de l’engin et lequel est la dépense comptable.
La double saisie vient elle aussi du même endroit : un code d’engin écrit différemment dans les deux systèmes, un projet saisi à la main à la fois dans le tableau de chantier et dans l’ERP, une date de facture et une date d’événement tombant sur des mois différents. Quatre règles préviennent la plupart de ces cas :
- Déterminez un seul propriétaire de l’enregistrement principal pour chaque type de donnée ; la troisième colonne du tableau ci-dessus en est l’ébauche.
- Que le code d’engin et le code de projet soient identiques des deux côtés ; la correspondance des références externes conserve cette clé.
- Que la donnée circule dans un seul sens : qu’un même champ ne soit pas écrit depuis deux endroits.
- Écrivez la règle des dates : le terrain travaille avec la date de l’événement, l’ERP avec la date du document. Dans une comparaison mensuelle, on cherche d’abord l’écart dans ces deux dates.
Schémas de connexion, sans jargon technique
La connexion repose sur cinq idées simples. Aucune n’est un préalable au fonctionnement du logiciel ; elles s’ajoutent à mesure que le besoin naît.
- Les données de référence viennent de l’ERP : l’ERP, ou un logiciel intermédiaire, écrit en masse par l’API les informations sur les engins, les projets et les sociétés.
- Les données d’exploitation vont du terrain vers l’ERP sous forme de récapitulatif ou d’événement : le côté ERP les lit par l’API.
- Correspondance des références externes : le numéro de chaque engin, projet et document dans l’ERP est conservé dans l’enregistrement de terrain ; c’est ainsi que le même objet est reconnu des deux côtés.
- Suivi des changements (flux de modifications) : au lieu de relire chaque nuit toute la liste depuis le début, l’autre côté récupère ce qui a changé depuis la dernière interrogation.
- Notification d’événement signée (webhook) : quand une panne est clôturée ou qu’un pointage est approuvé, le système prévient l’adresse définie ; la signature vérifie que la notification vient bien de ce système.
Où en sont SAP et l’API
La lecture par l’API, l’écriture en masse, le flux de modifications, la correspondance des références externes et la notification d’événement signée sont disponibles ; l’accès à l’API est un module complémentaire lié à la licence. Le connecteur SAP, lui, est en préversion et n’est pas ouvert à l’usage général. Son périmètre est confirmé lors de l’étude technique ; ne présumez pas avant l’entretien de la version de SAP ni du type de document pour lesquels il fonctionnera. Pour le détail, voyez la page intégration ERP et SAP.
Dans une société sans ERP, le processus se termine dans le logiciel
Si vous n’avez pas d’ERP, l’achat ne reste pas à moitié fait. Le module de demandes et d’achats de Reper Axis mène le processus du besoin à la demande d’offre, à l’approbation selon le niveau de montant, à la commande, à la réception partielle et au rapprochement de facture ; la logique du contrôle de facture est expliquée dans le guide du rapprochement à trois voies. L’écriture comptable reste en revanche l’affaire de votre logiciel de comptabilité et de votre expert-comptable ; le logiciel de terrain ne s’y substitue pas.
Mettre en place la liaison par étapes dans une société avec ERP
Même avec un ERP, il n’est pas nécessaire de mettre la liaison en place dès le premier jour. L’ordre ci-dessous vérifie à chaque étape l’exactitude de la précédente :
- Chargez la liste des engins, des opérateurs, des projets et des emplacements avec le modèle d’importation Excel ; écrivez les codes d’engin et de projet de la même manière que dans l’ERP.
- Faites fonctionner le flux de pannes, de compteurs et de pointage sur un chantier.
- À la fin du premier mois, comparez à la main la dépense de maintenance de l’ERP avec le coût de la fiche engin, et expliquez l’écart par la date et le périmètre.
- Quand l’écart peut être expliqué par écrit, ajoutez la liaison des données de référence.
- En dernier, envoyez le récapitulatif d’exploitation à l’ERP.
