Trois lignes de logique métier. Mise en service dans vingt semaines.

Une compagnie aérienne de fret avait besoin d'une simple modification : une exception de surtaxe pour une marchandise spécifique sur un itinéraire de départ précis. Logique métier : trois lignes. Délai de mise en production : vingt semaines.

Voici ce qui s'est passé entre ces deux points.

La séquence

Premier jour : le service de gestion des revenus transmet la demande au service informatique. Sur une plateforme de fret traditionnelle, les règles de tarification sont intégrées au code source. Trois lignes de logique suffisent pour nécessiter un développement. Le ticket est ajouté à la liste d'attente.

Deuxième semaine : un développeur est affecté. Réunion de définition des besoins. La règle semble simple, mais le moteur de tarification présente des dépendances qu’il faut identifier avant même d’écrire la moindre ligne de code. Deuxième réunion. Troisième.

Semaine 4 : code écrit et relu. L’assurance qualité vérifie que la modification n’affecte pas les autres règles de tarification. Trois jours de tests.

Semaine 5 : le changement est mis en phase de test. Examen de la gestion des revenus. Un scénario non envisagé est identifié. Nouvelle exigence. Retour au développement.

Semaines huit à dix : la modification est prête pour la production. La prochaine fenêtre de lancement est prévue dans deux semaines.

Semaine vingt : l’exception est effective. Le service de gestion des revenus la gérait manuellement depuis la deuxième semaine.

Ce que cela a réellement coûté

Temps de développement : environ cinq jours. Coût total, incluant la coordination interne, les réunions et l’assurance qualité : important. Impact sur le chiffre d’affaires pendant les vingt semaines : réel et non suivi.

L'équipe n'a commis aucune erreur. Elle a travaillé correctement sur une plateforme qui n'était pas conçue pour un tel rythme.

Le schéma sous-jacent

Il ne s'agit pas d'un cas exceptionnel. C'est le comportement habituel des plateformes de fret existantes lorsque la logique de tarification et d'exploitation nécessite des développements supplémentaires.

L'entreprise apprend à contourner le problème. Les interventions manuelles deviennent la norme. L'écart entre ce qu'indique le système et ce que fait réellement l'opération se creuse discrètement.

Comment Nexlog aborde cette question

Nous avons créé Nexlog pour combler cette lacune.

Les changements relevant de décisions commerciales doivent être mis en œuvre au rythme des affaires. Ce principe a guidé chacun de nos choix architecturaux, de la première ligne de code à la structure de nos implémentations actuelles.

Gollog, la branche cargo de Gol Linhas Aéreas et le plus important opérateur de fret aérien d'Amérique latine, a déployé Nexlog sur l'ensemble de ses opérations complexes en quelques semaines seulement, sans aucune interruption de service. Des transporteurs plus petits ont restructuré leurs opérations de A à Z en quelques semaines également.

Dans les deux cas, les modifications qui nécessitaient auparavant de longs cycles de développement ont été mises en œuvre au rythme requis par les équipes de gestion des revenus et des opérations. Le coût de ces modifications était également bien inférieur à celui des plateformes précédentes.

Une objection courante

“ Nos changements ne prennent pas vingt semaines. ”

Certaines équipes ne le font pas. Mais la plupart, lorsqu'elles analysent le déroulement d'une modification, de la demande à la mise en production, constatent que le temps écoulé est plus long qu'elles ne s'en souvenaient. L'attente devient une routine. La routine devient invisible.

Un simple contrôle

Choisissez un changement de prix ou de fonctionnement survenu au cours des six derniers mois. Suivez son parcours depuis la demande de l'entreprise jusqu'à sa mise en production.

Demandez-vous alors : quelle serait la valeur de ce projet si cela prenait des jours au lieu de semaines ?