Une demande inhabituelle pendant une période de grande chaleur
Pendant une période de grande chaleur, un employé d’une usine au Québec n’arrivait pas à dormir à cause de la chaleur. Puisqu’il était déjà réveillé, il a demandé s’il pouvait plutôt travailler pendant la nuit.
La demande était raisonnable, mais imprévue. La règle de suivi du temps en place supposait des activités normales de jour et empêchait l’employé d’enregistrer l’horaire proposé.
La règle initiale n’était pas mauvaise
Au moment du déploiement, l’usine fonctionnait normalement le jour. L’horaire configuré assurait la cohérence des entrées de temps et permettait de repérer les situations qui devaient réellement être vérifiées.
La règle reflétait donc bien les opérations de l’époque. Il ne s’agissait ni d’une mauvaise conception ni d’un bogue. La réalité venait simplement de créer une exception légitime que la règle initiale ne prévoyait pas.
Les opérations ont changé avant le logiciel
La météo change. Les horaires changent. Les engagements envers les clients et les contraintes de main-d’œuvre changent aussi. Une règle qui protégeait le processus hier peut devenir un obstacle lorsque les conditions évoluent.
Une entreprise ne devrait pas avoir à choisir entre refuser une adaptation opérationnelle raisonnable et demander à ses employés de contourner le système.
La règle a été ajustée, testée et déployée
La règle d’horaire a d’abord été revue pour comprendre sa raison d’être et déterminer quelles protections demeuraient nécessaires. Elle a ensuite été ajustée et testée avec les scénarios de suivi du temps concernés.
Même si le changement a été réalisé rapidement, la règle d’affaires révisée a tout de même été validée dans l’environnement de développement avant son déploiement en production. Aller vite ne voulait pas dire contourner les vérifications qui protègent les opérations.
Ce type de changement demande tout de même du jugement et de la vérification. L’avantage était qu’une grande partie de la logique de l’application se trouvait au niveau des règles d’affaires dans DAZZM Studio, plutôt que d’être dispersée dans des flux profondément codés en dur. Le changement a donc pu être implanté plus vite qu’il ne le serait habituellement dans un développement sur mesure traditionnel.
Un exemple d’agilité opérationnelle, pas seulement une correction
La technologie n’est pas l’histoire principale. Le résultat utile, c’est que le système a pu suivre un changement raisonnable dans la façon dont l’entreprise devait fonctionner.
Un logiciel standard impose souvent les hypothèses de son fournisseur. Un logiciel sur mesure rigide peut créer une autre version du même problème si chaque exception exige des modifications dans plusieurs couches. Un système opérationnel construit autour de règles d’affaires explicites donne à une PME une façon plus pratique de s’adapter, sans transformer chaque exception du terrain en nouveau projet logiciel.
La leçon du terrain
Les règles d’affaires doivent créer de la cohérence, sans figer pour toujours les conditions opérationnelles d’hier.
Pour une PME, l’adaptabilité consiste à pouvoir examiner une règle, conserver les contrôles encore pertinents et modifier ce qui ne correspond plus à la réalité. La grande chaleur a rendu cet exemple très concret. Le même principe s’applique lorsque les horaires, les responsabilités, les politiques ou les exigences des clients changent.