Un cahier des charges GMAO n'est pas un document administratif. C'est l'outil qui décide si les réponses des éditeurs seront comparables ou non. Quand le document est flou, chaque éditeur répond à sa propre question, les chiffrages varient du simple au triple sans qu'on sache pourquoi, et l'armateur choisit au feeling. Quand il est précis, les écarts de prix deviennent lisibles et les impasses techniques apparaissent avant la signature, pas six mois après la mise en service.
Ce guide s'adresse à ceux qui ont déjà arbitré le principe : la flotte passe sur une GMAO maritime, le tableur a atteint ses limites. Reste à écrire le document qu'on enverra aux éditeurs. Chaque section ci-dessous donne le pourquoi, le piège classique, et des formulations d'exigences que vous pouvez reprendre telles quelles, en remplaçant les valeurs entre crochets par les vôtres.
Cadrer le périmètre : la section qui fausse tout le reste
Le périmètre est la première section du document et la seule que tous les éditeurs lisent en entier, parce que c'est elle qui détermine le chiffrage. Un périmètre mal cadré ne produit pas une erreur de quelques pour cent sur le devis : il produit un devis qui ne veut rien dire.
Ce qu'il faut poser noir sur blanc : le nombre de navires et leur typologie, les pavillons concernés, la répartition des utilisateurs entre le bord et le terre, l'organisation technique (un superintendant pour toute la flotte, ou un responsable par navire), et la cible à trois ans. Une compagnie de six navires qui en visera quatorze dans trois ans ne doit pas se retrouver à renégocier sa licence au premier rachat.
Le piège classique
Compter les navires et oublier les utilisateurs. Un ferry avec quatre officiers mécaniciens, un second capitaine et un service technique à terre de trois personnes, ce n'est pas la même charge de licence qu'un fileyeur de 24 mètres avec un patron et un mécanicien. Deuxième piège : ne pas dire si les équipages doubles comptent pour un ou deux utilisateurs. C'est la ligne qui fait dériver le budget dès la première relève.
Exigences à reprendre
- PER-01 — « La solution devra couvrir [N] navires à la mise en service, avec une capacité d'extension à [N+X] navires sur la durée du contrat sans refonte de l'architecture ni migration de données. Le soumissionnaire indiquera le mode de tarification appliqué à l'ajout d'un navire en cours de contrat. »
- PER-02 — « Les navires concernés sont : [type, longueur, pavillon, zone d'exploitation, effectif embarqué] pour chacun. Le soumissionnaire précisera si sa solution impose une configuration distincte par pavillon. »
- PER-03 — « L'organisation comprend [N] utilisateurs embarqués et [N] utilisateurs à terre. Le soumissionnaire précisera si la tarification est fondée sur les comptes nominatifs, les connexions simultanées ou le navire, et le traitement appliqué aux équipages en rotation. »
Le fonctionnement hors connexion : ne jamais écrire « doit fonctionner hors ligne »
« Le logiciel doit fonctionner hors ligne » est la phrase la plus inutile d'un cahier des charges GMAO maritime. Tous les éditeurs répondront oui. Certains entendent par là une application embarquée complète, d'autres un cache de consultation en lecture seule, d'autres encore un formulaire mis en file d'attente qui perd la saisie si l'application se ferme.
La bonne méthode consiste à spécifier trois choses séparément : ce qui doit être consultable sans réseau, ce qui doit être créable ou modifiable sans réseau, et ce qui se passe à la resynchronisation. C'est le troisième point qui distingue vraiment les solutions. Deux mécaniciens, l'un à bord et l'autre à terre, modifient la même gamme pendant que le navire est hors couverture : que garde le système, que signale-t-il, à qui ?
Le piège classique
Accepter une démonstration en mode avion pendant trente secondes comme preuve. Le mode hors connexion se juge sur une traversée, pas sur une démo. Demandez explicitement la durée maximale d'autonomie hors réseau et le volume de données conservé localement.
Exigences à reprendre
- OFF-01 — « Sans aucune connectivité, l'utilisateur embarqué devra pouvoir : consulter l'arborescence complète des équipements du navire et leurs documents attachés, consulter le plan de maintenance des [90] jours à venir, créer et clôturer un ordre de travail, saisir un relevé de compteur, déclarer une anomalie avec photo, et consulter le stock de pièces du bord. »
- OFF-02 — « L'autonomie hors connexion devra être d'au moins [N] jours sans perte de saisie. Le soumissionnaire précisera le volume de données répliqué localement et le comportement de l'application en cas de saturation de l'espace de stockage du terminal. »
- OFF-03 — « À la resynchronisation, le système devra détecter les modifications concurrentes portant sur le même objet, conserver les deux versions et signaler le conflit à un rôle désigné pour arbitrage. L'écrasement silencieux d'une saisie bord par une saisie terre sera considéré comme non conforme. »
- OFF-04 — « Le soumissionnaire décrira le protocole de synchronisation, la bande passante consommée par une synchronisation quotidienne type, et la possibilité de synchroniser sur liaison satellite bas débit. »
Le référentiel équipements : profondeur, sisterships, reprise de l'existant
Le référentiel est le socle. Tout le reste — plan de maintenance, historique, pièces, coûts — s'y accroche. Une arborescence trop plate et vous ne saurez jamais si la panne récurrente vient du turbocompresseur ou du refroidisseur d'air de suralimentation. Une arborescence trop profonde et personne ne la remplit.
Trois exigences comptent vraiment. La profondeur de l'arborescence : navire, système, équipement, sous-ensemble, composant remplaçable, avec la possibilité de descendre au niveau de l'article suivi en numéro de série. La réplication sur sisterships : sur une flotte de ferries identiques, ressaisir le référentiel navire par navire représente des semaines de travail et garantit des divergences. Et la reprise de l'existant, presque toujours sous-estimée.
Le piège classique
Écrire « reprise des données existantes » sans dire dans quel format elles existent. Vos données sont dans un classeur de quarante onglets, un PDF scanné de la liste de machines du chantier, et la tête du chef mécanicien qui part à la retraite au printemps. Ces trois sources ne se reprennent pas de la même manière et n'ont pas le même coût. Dites lesquelles vous fournirez et sous quelle forme.
Exigences à reprendre
- EQP-01 — « Le référentiel devra permettre une arborescence d'au moins [5] niveaux (navire, système, équipement, sous-ensemble, composant), avec attributs libres par niveau et rattachement d'un numéro de série, d'un fabricant et d'une documentation à chaque nœud. »
- EQP-02 — « La solution devra permettre de dupliquer le référentiel et le plan de maintenance d'un navire vers un sistership, puis de gérer les écarts navire par navire sans rompre le lien avec le modèle de flotte. »
- EQP-03 — « La reprise portera sur les sources suivantes : [fichiers tableur, listes de machines chantier, extraction de l'outil actuel, documentation fabricant]. Le soumissionnaire indiquera les formats d'import acceptés, le volume traitable, le nombre de reprises d'essai incluses, et qui, de l'éditeur ou du client, réalise le nettoyage des données. »
Plan de maintenance et déclencheurs : la partie que les outils génériques ratent
C'est la section qui sépare une GMAO maritime d'un outil conçu pour un site à terre. Ailleurs, la maintenance préventive est presque toujours calendaire. À bord, elle est mixte : le moteur principal se révise aux heures de fonctionnement, le matériel de sécurité à la date, les injecteurs à la combinaison des deux, et certains organes sur état mesuré. Si le cahier des charges ne décrit pas cette mixité, vous achèterez un agenda.
Le point qui coince le plus souvent est la combinaison de déclencheurs. « Toutes les 500 heures ou tous les 12 mois, au premier des deux termes échu, avec remise à zéro du compteur à la réalisation » est une règle banale à bord et impossible à exprimer dans beaucoup d'outils. Demandez une démonstration sur ce cas précis. Le second point est la tolérance : une échéance à 500 heures réalisée à 512 heures pendant une escale n'est pas un retard, c'est une réalisation dans la fenêtre admise, et le système doit savoir l'enregistrer comme telle.
| Type de déclencheur | Exemple à bord | Ce que le système doit gérer |
|---|---|---|
| Calendaire | Inspection annuelle du matériel de sécurité SOLAS | Date fixe, récurrence, report avec justification tracée |
| Compteur d'heures | Révision d'un groupe électrogène | Saisie manuelle ou automatique du compteur, projection de la date d'échéance |
| Cycles et événements | Nombre de démarrages, nombre de traits de chalut, nombre de manœuvres de guindeau | Compteur incrémental non temporel |
| État mesuré | Analyse d'huile, relevé vibratoire, épaisseur d'anode | Seuil déclenchant une tâche, historisation de la mesure |
| Combiné | 500 h ou 12 mois, premier terme échu | Règle multicritère, réinitialisation à la réalisation |
Sur la construction du plan lui-même, notre guide en quatre étapes pour un plan de maintenance préventive détaille ce qui doit exister avant même d'ouvrir un logiciel.
Exigences à reprendre
- PMS-01 — « La solution devra gérer des déclencheurs calendaires, à compteur d'heures, à cycles et sur seuil de mesure, ainsi que leur combinaison logique (ET / OU) sur une même tâche, avec réinitialisation automatique du compteur à la clôture de l'intervention. »
- PMS-02 — « Chaque tâche devra porter une tolérance paramétrable exprimée en jours et/ou en heures de fonctionnement. Une intervention réalisée dans la tolérance ne devra pas être comptabilisée en retard dans les indicateurs. »
- PMS-03 — « Une gamme de maintenance devra contenir a minima : les opérations détaillées, les pièces et consommables associés, la durée estimée, la qualification requise, les consignes de sécurité applicables et les documents de référence. »
- PMS-04 — « Le report d'une échéance devra être tracé : auteur, date, motif, nouvelle échéance, et validation par un rôle habilité au-delà de [N] jours de report. »
La conformité : ISM, classification, certificats, Port State Control
C'est la section que les éditeurs non maritimes traitent par une phrase générique sur la « conformité réglementaire ». Elle mérite d'être la plus détaillée du document, parce que c'est là que se joue la différence entre un outil de confort et un outil qui vous évite une déficience.
Quatre blocs à couvrir. Les enregistrements exigés par le code ISM : le système de gestion de la sécurité impose de tenir la preuve de l'entretien du navire et de ses équipements, et cette preuve doit être produisible à l'audit. Les équipements critiques au sens du chapitre 10.3 du code, pour lesquels des mesures spécifiques et des essais périodiques sont attendus : le système doit permettre de les marquer comme tels et de les traiter différemment du reste. Le PMS approuvé par la société de classification, si votre flotte est concernée, avec ses contraintes propres de traçabilité et de rapport. Et les certificats, navire comme équipage, avec alertes d'expiration. Nos articles sur la conformité ISM appuyée sur une GMAO et sur le PMS approuvé par les sociétés de classification détaillent ces deux blocs.
Le piège classique
Se contenter d'exiger que « les données soient conservées ». Un inspecteur du Port State Control ne demande pas des données, il demande un dossier, sur un poste, en quelques minutes, souvent en anglais. Spécifiez la production du document, pas seulement le stockage.
Exigences à reprendre
- CNF-01 — « La solution devra permettre d'identifier les équipements critiques au sens du chapitre 10.3 du code ISM, de leur associer des tâches et essais périodiques spécifiques, et d'éditer la liste de ces équipements avec l'état de leurs échéances à une date donnée. »
- CNF-02 — « Le système devra produire, en moins de [5] minutes et sans intervention de l'éditeur, un dossier exportable au format PDF comprenant, pour un équipement ou un système donné : l'historique complet des interventions sur [période], les pièces remplacées, les intervenants et les documents joints. Ce dossier devra être disponible en français et en anglais. »
- CNF-03 — « La solution devra gérer les certificats du navire et de l'équipage avec date d'émission, date d'expiration, fenêtre d'inspection, pièce jointe et alerte paramétrable à [90 / 60 / 30] jours, adressée à des destinataires distincts bord et terre. »
- CNF-04 — « Le soumissionnaire précisera si sa solution est déjà utilisée dans le cadre d'un système de maintenance planifiée approuvé par une société de classification, et lesquelles. »
Stocks et achats : la liaison pièce-équipement avant tout
Une GMAO qui gère les stocks sans les rattacher aux équipements ne sert à rien de plus qu'un inventaire. La seule question qui compte à bord est : quelles pièces vont avec cette machine, et lesquelles ai-je réellement à disposition ? Le reste en découle.
Le second point spécifiquement maritime est la double localisation. Une pièce peut être au magasin du bord, dans un local du navire, au dépôt à terre, ou en transit vers le prochain port d'escale. Les quatre situations sont différentes et un modèle de stock mono-site ne les représente pas. Notre article sur la gestion des stocks MRO et les ruptures de pièces critiques développe la logique de seuils applicable aux pièces critiques.
Le piège classique
Oublier les pièces de rechange obligatoires imposées par la classification ou le pavillon. Elles ne se gèrent pas comme du consommable : elles doivent être identifiées comme obligatoires, leur consommation doit déclencher un réapprovisionnement suivi, et leur absence doit être visible avant la visite, pas pendant.
Exigences à reprendre
- STK-01 — « Chaque article devra pouvoir être rattaché à un ou plusieurs équipements du référentiel, avec référence fabricant, référence interne et emplacement physique. Depuis la fiche d'un équipement, l'utilisateur devra accéder directement à la liste des pièces compatibles et à leur disponibilité par lieu de stockage. »
- STK-02 — « La solution devra gérer des seuils d'alerte par article et par lieu de stockage, distinguer le stock embarqué du stock à terre, et permettre de marquer un article comme pièce de rechange obligatoire au titre de la classification ou du pavillon. »
- STK-03 — « La clôture d'un ordre de travail devra décrémenter automatiquement le stock des pièces consommées et générer, le cas échéant, une demande d'approvisionnement rattachée à l'équipement et au navire concernés. »
- STK-04 — « Le cycle d'achat devra couvrir : demande d'achat, circuit de validation à [N] niveaux avec seuils de montant, consultation fournisseurs, commande, réception partielle ou totale, et rapprochement avec la facture. »
Utilisateurs, rôles et traçabilité : le sujet des relèves
À bord, les comptes partagés deviennent la norme quand personne n'a spécifié le contraire. Un poste en machine, un identifiant collé sur l'écran, et tout l'historique devient inexploitable, en audit comme en analyse de panne. Le cahier des charges doit fermer cette porte dès le départ.
Le sujet propre au maritime est la relève. Un second mécanicien qui embarque pour six semaines doit hériter d'un rôle, pas d'un compte. Le système doit permettre d'attribuer et de retirer des droits en quelques secondes, sans supprimer l'historique de l'utilisateur sortant, et sans qu'un compte reste actif six mois après le débarquement.
Exigences à reprendre
- USR-01 — « Chaque utilisateur devra disposer d'un compte nominatif. Les droits devront être attribués par rôle (chef mécanicien, second mécanicien, capitaine, superintendant, acheteur, auditeur en lecture seule) et modifiables navire par navire. »
- USR-02 — « Toute création, modification ou suppression d'un enregistrement devra être horodatée et attribuée à un utilisateur identifié. L'historique devra être inaltérable : aucune suppression définitive ne doit être possible depuis l'interface, y compris pour un administrateur. »
- USR-03 — « La clôture d'une intervention devra pouvoir exiger une validation par un rôle distinct de celui qui a réalisé le travail, avec signature électronique ou validation tracée, paramétrable par type de tâche. »
- USR-04 — « La solution devra permettre la désactivation immédiate d'un compte au débarquement sans perte de l'historique attaché, et la reprise du rôle par l'utilisateur relevant. »
Les données : propriété, export, réversibilité, hébergement
Cette section s'écrit dans le cahier des charges, pas à la résiliation. Une fois le contrat signé, la position de négociation a disparu. Plusieurs années d'historique de maintenance sur toute une flotte représentent un actif technique considérable, et le jour où vous voudrez changer d'outil, la seule chose qui comptera sera ce que le contrat prévoit.
Quatre points. La propriété des données, qui doit être affirmée sans ambiguïté au bénéfice du client. Le format d'export, qui doit être structuré et exploitable, pas un PDF de plusieurs milliers de pages. La réversibilité en fin de contrat, avec un délai et un périmètre. Et l'hébergement, avec la localisation physique des serveurs et les modalités de sauvegarde. Si votre flotte relève d'exigences de cybersécurité de type IACS UR E26 et E27, ajoutez-les ici plutôt qu'en annexe.
Exigences à reprendre
- DAT-01 — « Le client demeure propriétaire de l'intégralité des données saisies, importées ou générées, y compris les documents joints et les journaux d'audit. Le contrat ne devra conférer à l'éditeur aucun droit d'usage de ces données à d'autres fins que l'exécution du service. »
- DAT-02 — « Le client devra pouvoir déclencher lui-même, à tout moment et sans coût supplémentaire, un export complet de ses données dans un format structuré et documenté, accompagné d'un dictionnaire de données, incluant les fichiers joints. »
- DAT-03 — « En fin de contrat, quelle qu'en soit la cause, l'éditeur devra fournir l'export complet sous [30] jours et attester de la suppression des données à l'issue d'un délai de conservation de [90] jours. »
- DAT-04 — « Le soumissionnaire précisera la localisation physique des données, la fréquence des sauvegardes, la durée de rétention, la procédure de restauration et le délai de restauration après incident. »
Intégration : ERP, comptabilité, paie, systèmes de bord
L'intégration est le poste où les mauvaises surprises coûtent le plus cher, parce qu'elle n'apparaît jamais dans les démonstrations. Deux familles à traiter séparément.
Côté gestion : l'ERP, la comptabilité, la paie. Ce qui circule, ce sont les commandes, les réceptions, les factures, les centres de coût par navire, et parfois les temps passés. Précisez le sens du flux et sa fréquence. Côté bord : les automates, les systèmes d'alarme et de surveillance, les passerelles de données. Récupérer automatiquement les compteurs d'heures depuis un bus NMEA 2000 supprime la source d'erreur la plus banale du plan de maintenance : le relevé manuel oublié ou mal recopié.
Le piège classique
Se contenter de la mention « API disponible ». Demandez la documentation publique de l'API, les limites d'appel, le mode d'authentification, et si l'accès est inclus dans l'abonnement ou facturé en supplément. Une API facturée au connecteur change l'économie du projet.
Exigences à reprendre
- INT-01 — « La solution devra exposer une API documentée et accessible au client, permettant a minima la lecture des équipements, des ordres de travail, des mouvements de stock et des commandes. Le soumissionnaire fournira le lien vers la documentation publique et précisera les quotas d'appel. »
- INT-02 — « Le soumissionnaire décrira les intégrations déjà réalisées avec [nom de l'ERP ou de l'outil comptable] et indiquera, pour chacune, s'il s'agit d'un connecteur standard maintenu ou d'un développement spécifique, ainsi que son coût. »
- INT-03 — « La solution devra permettre l'alimentation automatique des compteurs d'heures depuis les systèmes de bord, ou à défaut par import de fichier planifié. »
Déploiement, formation et support : la section qu'on écrit trop vite
Le logiciel coûte rarement autant que le temps qu'il faut pour le mettre en service. Cette section doit répondre à trois questions simples : qui reprend les données, qui forme, et qui répond quand ça bloque à trois heures du matin heure de Marseille parce que le navire est au large de Singapour.
Le point le plus souvent négligé est le fuseau horaire du support. Un support « en heures ouvrées » depuis un seul pays ne couvre pas une flotte mondiale : pour une compagnie exploitant en Asie du Sud-Est, une plage 9h-18h heure de Paris tombe en pleine nuit à bord, c'est-à-dire précisément au moment où l'équipe de quart a besoin d'une réponse. Écrivez les heures en UTC, pas en « heures ouvrées ».
Exigences à reprendre
- SUP-01 — « Le soumissionnaire précisera la répartition des tâches de reprise de données entre l'éditeur et le client, le nombre de jours d'accompagnement inclus, et le coût unitaire des jours supplémentaires. »
- SUP-02 — « La formation devra couvrir les profils bord et terre séparément, en français et en anglais, et inclure un dispositif permettant de former un nouvel embarqué sans mobiliser l'éditeur. Le soumissionnaire indiquera le format (présentiel, distanciel, support écrit, vidéos) et la durée. »
- SUP-03 — « Le support devra être joignable de [HH:MM] à [HH:MM] UTC, [N] jours par semaine, par [canaux]. Le soumissionnaire s'engagera sur un délai de première réponse de [N] heures et sur un délai de prise en charge des incidents bloquants de [N] heures, mesurés en heures calendaires et non en heures ouvrées. »
- SUP-04 — « Le soumissionnaire décrira la procédure applicable lorsqu'un navire signale un dysfonctionnement alors qu'il est hors couverture réseau. »
Les erreurs classiques de mise en place viennent presque toutes de cette section traitée à la légère.
La trame du document, section par section
Un cahier des charges GMAO tient en quinze à trente pages. Au-delà, personne ne le lit en entier et les réponses deviennent approximatives. Voici la structure qui permet de dépouiller sans se perdre.
| Section | Contenu attendu | Erreur fréquente |
|---|---|---|
| 1. Contexte et objectifs | Activité, flotte, organisation technique, raison du projet, échéance visée | Rédiger un argumentaire commercial au lieu d'un état des lieux |
| 2. Périmètre | Navires, pavillons, utilisateurs bord et terre, cible à trois ans | Compter les navires et oublier les utilisateurs |
| 3. Exigences fonctionnelles | Équipements, maintenance, stocks, achats, certificats, conformité, indicateurs | Mélanger le besoin et la solution technique attendue |
| 4. Exigences techniques | Hors connexion, mobilité, intégration, données, hébergement, sécurité | Écrire « doit fonctionner hors ligne » sans rien préciser |
| 5. Exigences de service | Reprise de données, formation, support, délais engagés, réversibilité | Traiter le support en une ligne |
| 6. Critères de notation | Grille pondérée, exigences éliminatoires, méthode de notation, scénario de démonstration | Ne pas communiquer la pondération aux soumissionnaires |
| 7. Calendrier et modalités | Date limite de réponse, démonstrations, décision, mise en service cible | Prévoir une démonstration sans scénario imposé |
| 8. Annexes | Liste des navires, extrait du référentiel actuel, volumétrie, formats de données | Ne rien joindre et demander un chiffrage ferme |
Distinguer l'obligatoire du souhaitable
Chaque exigence doit porter un niveau : obligatoire (une réponse négative élimine le soumissionnaire), important (noté et pondéré), souhaitable (départage à égalité). Sans cette distinction, tous les éditeurs répondent « oui » partout et vous n'avez plus rien à comparer. Trois ou quatre exigences éliminatoires suffisent : au-delà, vous n'aurez plus de candidats.
Numéroter, toujours
Les codes du type PER-01 ou OFF-03 utilisés dans cet article ne sont pas décoratifs. Ils permettent d'exiger que chaque soumissionnaire réponde exigence par exigence, dans l'ordre, avec un niveau de couverture et un commentaire. Un éditeur qui répond par une plaquette commerciale au lieu d'un tableau ligne à ligne vous dit déjà quelque chose sur la suite de la relation.
Pondérer les critères et dépouiller les réponses
La pondération se fixe avant de recevoir les réponses, et se communique aux soumissionnaires. C'est ce qui garantit qu'on ne réajuste pas les poids après coup pour faire gagner celui qu'on préférait. Voici une répartition de départ, à ajuster selon la flotte : une compagnie de pêche hauturière montera le poids du hors connexion, un armateur de ferries celui de la conformité et de la disponibilité.
| Domaine | Poids indicatif | Ce qu'on note | Exigence éliminatoire possible |
|---|---|---|---|
| Couverture fonctionnelle maintenance | 20 % | Déclencheurs combinés, gammes, tolérances, historique | Absence de déclencheur à compteur d'heures |
| Fonctionnement hors connexion | 15 % | Périmètre créable hors réseau, gestion des conflits, autonomie | Aucune création d'ordre de travail hors réseau |
| Conformité et certificats | 15 % | Équipements critiques, production du dossier d'audit, alertes d'expiration | Impossibilité d'exporter un dossier d'historique |
| Référentiel et reprise de données | 10 % | Profondeur, sisterships, formats d'import, effort de reprise | — |
| Stocks et achats | 10 % | Liaison pièce-équipement, seuils, multi-lieux, circuit de validation | — |
| Ergonomie et adoption à bord | 10 % | Nombre d'actions pour clôturer un ordre de travail, usage mobile, langues disponibles | — |
| Données, hébergement, réversibilité | 8 % | Propriété, export autonome, localisation, sauvegarde | Refus de garantir l'export complet |
| Support et formation | 7 % | Couverture horaire en UTC, délais engagés, langues | — |
| Intégration | 5 % | API documentée, connecteurs existants, coût | — |
| Coût complet sur [5] ans | Noté à part | Licences, mise en service, reprise, formation, options, ajout de navire | — |
Noter sur une échelle courte
Une échelle à quatre niveaux suffit et évite les demi-points de complaisance : 0 non couvert, 1 couvert partiellement ou par contournement, 2 couvert en standard, 3 couvert en standard et démontré sur votre propre jeu de données. Le niveau 3 ne s'accorde qu'après démonstration sur un scénario que vous avez écrit vous-même. Par exemple : créer hors réseau un ordre de travail sur un auxiliaire, y consommer deux pièces, resynchroniser, puis éditer le dossier d'historique de l'équipement.
Le coût se note à part
Ne noyez pas le prix dans la grille fonctionnelle. Demandez un coût complet sur cinq ans : abonnement, mise en service, reprise de données, formation initiale et de rattrapage, options, coût d'ajout d'un navire, coût d'ajout d'un utilisateur. C'est le seul moyen de comparer une offre à faible abonnement et forte prestation de démarrage avec une offre construite à l'inverse. Notre analyse du vrai coût d'un tableur face à une GMAO maritime donne le cadre de raisonnement pour construire ce total.
Où se situe cette étape dans votre projet
Le cahier des charges est la deuxième des trois étapes d'un projet GMAO. Il ne sert pas à grand-chose si les deux autres sont sautées.
Avant : comparer les solutions du marché et comprendre ce qui distingue réellement une GMAO maritime d'un outil générique. Si vous en êtes encore là, commencez par notre grille de 32 critères pour choisir un logiciel de GMAO maritime : elle vous dira quoi regarder avant d'écrire quoi que ce soit.
Après : déployer. Une fois l'éditeur retenu, le projet se joue sur la reprise des données, l'appropriation par les équipages et les premières semaines d'usage réel. Notre check-list de mise en place d'une GMAO maritime reprend le fil à partir de la signature.
Un dernier conseil de méthode : faites relire le document par un chef mécanicien avant de l'envoyer. C'est lui qui saisira les données tous les jours, et c'est cette relecture qui fait disparaître les exigences théoriques que personne n'utilisera jamais. Si vous voulez confronter votre projet de cahier des charges à des cas réels de flottes de pêche, de ferries, de pilotage ou de navires de service, écrivez-nous.
Une fois le cahier des charges rédigé, la sélection puis le déploiement suivent une logique que nous déroulons pas à pas dans le guide complet de la GMAO maritime.

.jpg)


