Aller au contenu principal
Blog
Mise à jour produit3 min de lecture

Les événements de réclamation, trouvés pendant que la piste est chaude

La plupart des événements qui pourraient donner lieu à une réclamation n'en font jamais l'objet, faute d'avoir été trouvés à temps. Le nouveau module de réclamation les détecte à partir de vos retards d'échéancier, relie la piste documentaire et évalue la force de chacun.

Un glissement d'échéancier et une piste documentaire reliée convergeant en un événement de réclamation détecté et évalué dans Storia.
Guillaume Ah-kiFull Stack Lead | Ex-Amazon | AI Agent Manager

Partager l’article :

Storia peut désormais trouver vos événements de réclamation pour vous. Le nouveau module de réclamation lit chaque mise à jour de l'échéancier, relie la piste documentaire derrière chaque glissement, et rédige un événement de réclamation dont la preuve est déjà jointe et évaluée.

Cela compte parce que la plupart des événements réclamables ne font jamais l'objet d'une réclamation. Non pas parce qu'ils étaient faibles, mais parce que personne n'a remarqué qu'ils s'étaient produits pendant que la piste était encore chaude. Quand une réclamation arrive à échéance, l'instant qui comptait est déjà loin derrière, depuis des mois, et le reconstituer à partir d'un dossier refroidi, c'est la partie qui épuise les gens.

Le module change le moment où la découverte a lieu : au fil des travaux, et non comme une analyse a posteriori à la fin du chantier.

Il trouve les événements pendant que la piste est encore chaude

Trouver un événement de réclamation demande deux recherches, menées sur deux parties différentes du dossier.

La première, c'est l'échéancier. Une analyse de retard par fenêtres compare chaque mise à jour à la précédente et fait ressortir les activités qui ont bougé, de combien, et si le glissement s'est posé sur le chemin critique ou a grugé de la marge.

L'Échéancier n° 6 par rapport à la mise à jour précédente : la date de fin du projet tient, mais six activités sont à risque et environ une semaine de marge a été grugée. Chaque activité ayant glissé se relie directement à sa cause.

Un glissement d'échéancier n'est pas un événement de réclamation. C'est une question : qu'est-ce qui l'a provoqué, et pouvez-vous le prouver.

La seconde recherche porte sur la trace écrite : le QRT qui a signalé le conflit, la directive qui a ordonné l'arrêt, l'ordre de changement qui a chiffré la reprise. Le module relie chaque glissement aux documents qui l'expliquent, un travail qui supposait autrefois de lire à travers plusieurs systèmes et de faire concorder les dates à la main.

Un événement trouvé, c'est une cause, un effet et la preuve des deux

Prenez un événement tiré d'un vrai projet. « Installation des poutres » s'est terminée seize jours en retard. À elle seule, ce n'est qu'un chiffre sur un diagramme de Gantt. Retracée, elle devient une réclamation : une directive d'arrêt des travaux a interrompu l'installation des poutres dans deux zones en raison d'un conflit non résolu, un QRT ultérieur a imposé un changement de dégagement de six pouces qui a obligé à réacheminer des installations mécaniques, et un ordre de changement a chiffré la reprise à 263 700 $ CA. Une cause, un effet, et les documents qui prouvent chaque lien, chacun cité jusqu'à sa source.

Un événement de réclamation rédigé : le glissement de 16 jours sur « Installation des poutres » retracé jusqu'à une directive d'arrêt des travaux et des QRT sur le dégagement poutres-MEP, l'impact sur les coûts estimé, et chaque point cité jusqu'à sa source.

Chaque événement arrive avec un score de force de la preuve

Ce que pèse le score de force de la preuve

Le score de force de la preuve pèse trois choses : si le contrat vous donne le bien-fondé, si le glissement est important pour le chemin critique, et à quel point le dossier appuie complètement le récit. Une directive datée, un ordre de changement chiffré et un QRT clair obtiennent un meilleur score qu'un glissement que vous ne pouvez expliquer que de mémoire.

Le score est attaché dès le point de découverte, de sorte que les événements faibles se distinguent des solides avant que vous n'investissiez du temps à monter quoi que ce soit.

Ce que vous pouvez en faire dès maintenant

Ouvrez n'importe quelle mise à jour de l'échéancier et les glissements du chemin critique sont déjà mis en évidence. Cliquez sur l'un d'eux et l'événement de réclamation est rédigé pour vous : la preuve reliée, citée et évaluée. Le travail qui prenait un après-midi par événement se fait désormais à mesure que la mise à jour arrive.

C'est tout le changement. Les événements étaient autrefois reconstitués au moment de la réclamation, à partir d'une boîte de documents et de ce dont les gens se souvenaient. Ils sont désormais trouvés au fil des travaux, déjà reliés à leur cause.

La piste froide commence par une boîte de documents, sous la pression de l'échéance. La piste chaude commence par le glissement, déjà relié à sa cause.

À partir de là, le même événement se reporte sans nouvelle découverte, vers un dossier de réclamation si vous en montez un, ou vers un litige si le bien-fondé est contesté.

Deux signaux, le glissement et les documents qui l'expliquent, deviennent un seul événement de réclamation évalué qui se reporte dans un dossier de réclamation ou un litige.

L'événement que vous trouvez pendant que la piste est chaude, c'est celui que vous pouvez encore prouver.


Guillaume Ah-ki est responsable du développement full-stack chez Storia. Écrivez à info@storiatechnologies.com si vous souhaitez voir le module de réclamation tourner sur vos propres mises à jour d'échéancier.

Guillaume Ah-kiFull Stack Lead | Ex-Amazon | AI Agent Manager

Partager l’article :

Articles connexes

Nouveau module de réclamation et évaluation de la force de la preuve · Storia