L’un des défis les plus difficiles pour les logiciels de Facility Management est de représenter de grandes quantités de données en un temps extrêmement court, par exemple pour la gestion des locations ou le Help Desk. Pourquoi en est-il ainsi ? Et que signifie exactement « temps extrêmement court » ?
Les utilisateurs de logiciels CAFM ont souvent des portefeuilles complets de bâtiments et d’installations. Ceux-ci sont reliés de diverses manières aux informations, ils ont donc de vastes relations dites d’objet. En voici quelques exemples :
- Données sur la localisation
- Contrats de location, d’entretien, d’achat, etc.
- Centres de coûts
- Frais annexes
- Cautionnements
- Surfaces
- Données d’exploitation
Le nombre de ces relations d’objet peut déjà dépasser 30 pour un simple local, qui doivent être rassemblées à partir des zones les plus diverses d’une base de données. « Ce n’est pas si difficile », pourrait-on objecter, car chaque champ d’une base de données possède un identifiant unique et il suffit donc d’interroger 30 identifiants. C’est une excellente théorie. Mais la pratique la contredit rapidement. En effet :
Une base de données comporte d’une part des centaines de milliers d’identifiants, ce qui constitue le premier obstacle – la performance du serveur, qui est rarement bonne dans le Facility Management.
Et puis les données n’ont pas une structure uniforme. Il y a des chiffres, il y a des mots, il y a des textes et des graphiques. Certains peuvent être affichés directement, d’autres doivent être transférés dans des tableaux de bord. Et la taille de la fenêtre doit toujours rester la même.
Pour que de telles quantités de données pourtant exploitables en moins d’une seconde, il faut combiner différentes approches dans le développement de logiciels. En font partie,
- de réaliser une présentation en cascade qui, à l’instar des pages web, appelle d’abord les contenus qui doivent être actuellement affichés afin de pouvoir charger d’autres contenus en arrière-plan.
- de déterminer à l’avance quelles données doivent être affichées et comment, afin de pouvoir définir des dimensions de fenêtre identiques ainsi que leur répartition et leur structure interne.
- et de savoir quelles données sont disponibles, et à quelle vitesse, afin de pouvoir déterminer rapidement les passages de données critiques et améliorer rapidement leur performance.
Bien entendu, il ne s’agit là que d’un aspect essentiel lorsqu’il s’agit de faire d’un vaste système un outil permettant à l’utilisateur de gagner du temps, même en cas d’exigences complexes. Ce qui est important, c’est surtout une chose : c’est possible, de toutes manières.
speedikon l’a déjà démontré dans différents domaines d’application. Voici deux exemples tirés de la pratique quotidienne :
- Les contrats de location : Ils comprennent un objet loué, l’immeuble correspondant, ainsi qu’un locataire, qui peut être une personne ou une organisation, ce qui nécessite en outre une personne de contact, il peut y avoir un gestionnaire d’objet, les charges doivent être affectées, ainsi que les comptes pour le décompte – et bien sûr pour le versement des montants de location, de sorte que, selon la tâche, les données appropriées soient regroupées dans une seule vue.
- Maintenance : en plus de l’emplacement et des données techniques d’une installation, il faut également, selon la tâche, afficher en un coup d’œil des aspects tels que les durées de fonctionnement, les lots, les garanties, la maintenance, les messages d’erreur, les avis de pannes, l’approvisionnement en pièces de rechange, le fournisseur, le personnel de service et bien plus encore.
Dans les deux cas, cette combinaison rapide et variable de données est essentielle pour pouvoir prendre rapidement les décisions les mieux adaptées en étant bien informé. Car lorsque des aspects importants doivent d’abord être recherchés longuement, les affaires en pâtissent et, dans le pire des cas, les personnes aussi.
Nous pouvons éviter cela en quelques secondes.
