Pertes de temps

Nos projets doivent être complétés à une date qu’on appelle DDNC: Date Dūe Négociée avec le Client. Le nom est traître, puisque le client n’a pas son mot à dire et en est même informé après coup. Le DDNC est (par exemple) le 4 Septembre 2014, c’est nous qui décidons, point.

Elle est facile à calculer, elle consiste en la date de livraison standarde donnée par le cablo-opérateur + 2 semaines pour tout le reste. Evidemment, ça ne veut pas dire que tout le travail en dehors de la ligne WAN est fait en 2 semaines, puisque qu’on le fait en parallèle du travail fait pour la ligne WAN. C’est juste qu’on a deux semaines standard pour installer le routeur et faire toute les config/tests.

Ratez le DDNC, et c’est la ca-tas-tro-phe. Ça monte trois crans au-dessus de moi (senior Director), et ça redescend aussi vite sur votre gueule via le téléphone.

Quand on rate le DDNC, il faut “coder” le projet avec un code retard. La liste des codes est longue, mais ce qui est vraiment important au final est de savoir de qui est la faute: notre boite, ou le client.

On a le management qui regarde chaque semaine un rapport qui liste tous les projets de la planète qui ont dépasssé le DDNC, avec leur code. On a une target de 0% pour les DDNC dépassées avec notre boite comme responsable du retard.

Pour résumer:
Règle numéro 1: ne pas rater la DDNC
Règle numéro 2: si on la dépasse, il ne faut pas que ce soit de notre faute

Bien sûr, les disputes de responsabilités sont nombreuses, mais heureusement ma division n’est pas trop impliquée; une fois qu’on a codé le projet, les  commerciaux ne peuvent que faire appel au high management pour contester, pas à nous.

Tout va globalement bien jusqu’à ce qu’un jour un directeur décide que les DDNC sont trop longues. “Quoi? 89 jours pour un site en Ethernet au Japon? Non, c’est abusé, on va la mettre à 74 jours.”. Sur quoi s’est-il basé pour prendre cette décision, mystère. Il devait sans doute regarder un rapport sur le temps de complétion des projets, et il voulait l’améliorer. (accesssoirement, la division qui est en charge de surveiller les stats de temps de livraison des circuits par les cablo-opérateurs et de négocier avec eux a hurlé quand elle a été mise au courant après coup.)

La règle “DDNC = temps de livraison du circuit par le cablo-opérateur + 2 semaines”: passée aux oubliettes. Mais du coup, on n’a plus aucune chance de livrer dans les temps. Et ça, c’est inacceptacle pour le management.

Il y avait un process qui existait et qu’on utilisait rarement: le DCE (Date de Complétion Etendue). Le DCE était utilisé quand un opérateur livrait son circuit en retard. On utilisait le process du DCE dans 5% des projets. Il s’agissait concretement de lancer une requête d’extension du DDNC au management (avec détails), qui transférait à un manager régional en charge du DCE, qui allait dans les systêmes changer une date DDNC-bis. Un projet qui dépasse le DDNC mais ne dépasse pas le DDNC-bis n’est pas compté comme un échec dans nos stats.

Temps total perdu par requête DCE: 20 minutes. Pas énorme, mais multipliez par quelques milliers de projets annuellement, et on arrive à des mois/années de temps de travail perdu (étalé sur plusieurs chefs de projet). Parce que maintenant, un bon pourcentage des projets suivent le process DCE.

Et tout ça pour quoi? Pour qu’un directeur A soit content de voir que tous nos projets sont “livrés en heure”. Pour qu’un directeur B soit satisfait d’avoir “écourté” nos temps de complétion des projets.

Nous, le temps que ça nous prend pour finir un projet n’a pas changé. Rien n’a changé pour le client. Rien n’a changé pour le cablo-opérateur. On perd 10 minutes par projet, le management aussi. On perd un temps de travail affolant sur l’année.

Faites ce genre de changement de process 3 ou 4 fois par an. Insérer de nouveaux directeurs dans le management qui auront chacun leur vision de quel rapport est important et quel rapport ne l’est pas, et qui ajouteront des nouvelles règles selon le temps qu’il fait. A la fin, on prend 10 fois plus de temps qu’il n’en faut pour boucler un projet, avec aucune valeur ajoutée pour qui que ce soit. Ça devient terriblement difficile de se motiver parfois.

2 thoughts on “Pertes de temps

  1. ben1

    +1

    C’est comme ça dans toutes les grosses boites… La politique d’entreprise passe par la guerre des chiffres par les managers.

    Au final c’est a chaque fois simplement une autre manière d’interpréter les résultats et c’est les exécutants qui trinquent.

    Reply

Leave a Reply

Your email address will not be published.