Pourquoi ne pas simplement intégrer la base de données BIM directement dans la GMAO ou la GTB ?

Il s’agit de l’approche courante pour toutes les applications existantes voulant passer au BIM : Garder le même outil mais avec un module d’initialisation qui récupère les données de la maquette BIM. 

 

Nous contacter

GTB bâtiment : le rôle du Building Operating System

Pourquoi ne pas simplement intégrer la base de données BIM directement dans la GMAO ou la GTB ?

Il s’agit de l’approche courante pour toutes les applications existantes voulant passer au BIM : Garder le même outil mais avec un module d’initialisation qui récupère les données de la maquette BIM”. 

Les limites de cette approche 

Cependant, cette approche reste très limitée à nos yeux. Elle ne permet pas de faire vivre un seul et même référentiel partagé et d’en garantir sa qualité. Très rapidement, dans la vie du bâtiment, les différents référentiels vivants séparément ne seront plus équivalents les uns aux autres et le gain initial sera très vite perdu. Autrement dit, limiter l’intégration BIM à cette approche revient à conserver les silos.

 

Cela réduit le champ des scénarios possibles et par conséquent les bénéfices pour le client. Par exemple, je ne peux pas créer un ticket GMAO à partir de l’avatar de l’équipement dans la visionneuse BIM. Il me faudra ouvrir la GMAO, rechercher l’équipement et créer le ticket. Un autre exemple, dans le cas où la GMAO a une visionneuse BIM (c’est très peu le cas aujourd’hui), je peux facilement localiser l’équipement lié au ticket. En revanche, il me faudra aller sur le superviseur GTB pour récupérer les mesures générées comme la volumétrie, débit d’air …). Je multiplie donc les sources de données et par conséquent le temps d’intervention.

Aller plus loin

Pour aller plus loin, il faudra de toute façon connecter les systèmes. Le choix entre une intégration type “spaghettiware” ou de type “middleware” sera toujours indispensable et l’expérience de déploiement des systèmes ERP, PLM… conduit naturellement à préférer une approche middleware.

Pour résumer, cette approche vise, à proposer une solution de façade permettant d’éviter l’évolution des offres logicielles et l’implémentation d’API ouvertes. Ce qui, d’une part, peut se révéler très coûteux et qui, d’autre part, nécessite des modifications stratégiques et culturelles profondes chez des éditeurs historiquement fermés.

Découvrez SpinalCore, notre solution de Building Operating System

Retour à l’accueil du blog