Exercice 13
--> Retard rattrapé, hourra !
L’exercice 13 page 182 du livre de Krajewski est d’un tout autre type que le cas Tom Hat, dont une majorité d’étudiants est bien content qu’il soit « expédié » !
L’énoncé était en anglais, mais ne posait pas de grande difficulté à être compris. Le problème : calculer les coûts d’accélération en suivant le chemin critique des tâches afin de minimiser les coûts n’était pas non plus d’une grande difficulté. C’était même plutôt rigolo : à faire sur papier, on s’amuse bien, ce qui m’a pris plus de temps, c’est de refaire les schémas sur Excel, et il a fallu déployer des trésors d’ingéniosité pour le faire en cherchant à en recopier le moins !
En réalité, le problème proposé a suscité maintes interrogations. Je l’ai traité le jeudi 15 janvier avec Pierre-Louis, date limite puisqu’il partait à Prague. La principale difficulté a été d’interpréter « crash cost ». En effet, l’énoncé donnait les « coûts d’accélération » pour gagner par exemple 3 jours sur telle tâche. En amphi, nous l’avions fait en comptant les coûts d’accélération pour une tâche donnée par jour. Or il me semble que l’on peut vouloir réduire une tâche de seulement 2 jours, même si celle-ci peut l’être de 3 jours ; l’accélérer de 3 jours n’étant pas forcément le choix le plus judicieux. Dès lors, fallait-il prendre les 2/3 des coûts d’accélération, ou compter quand même la totalité des coûts, en admettant qu’ils soient indivisibles ?
Nous avons résolu le problème, en évitant la difficulté, non sans la signaler, en comptant les coûts d’accélération par jour, c’est-à-dire en modifiant légèrement les données du problème. Par ailleurs, cette réduction des tâches n’est que théorique. On remarque en effet dans la réalité que les projets et travaux prennent souvent du retard, et ne se terminent qu’avec exception aux dates données, à croire que les coûts supplémentaires de pénalité par jour de retard ne sont pas suffisamment déterminants pour faire respecter les délais !
Par ailleurs, on pouvait considérer le problème sous deux angles. Le premier, le plus simple au niveau de la résolution, était la méthode « classique ». Il s’agit de réduire mécaniquement la durée du projet en accélérant méthodiquement les tâches d’après la façon vue en auditorium. La seconde est, à mon avis, plus difficile à mettre en place, mais aussi plus subtile. Elle demande un peu plus de réflexion, de façon à ne pas se tromper dans les nombres, mais est tout aussi efficace. Il s’agit de déterminer par jour le seuil en dollars en dessous duquel il n’est plus intéressant de réduire. Il se calcule par jour d’après les coûts indirects, les coûts de pénalité et le coût de la tâche pour un jour (si on arrive à le déterminer !). Il suffit ensuite de la comparer au coût d’accélération pour ladite tâche. En effet, si le coût d’accélération reste supérieur au total précédent, il n’est plus intéressant de continuer à réduire, ou bien il faut essayer de réduire une autre tâche (travail qui peut être évité si l’on peut soin de suivre le chemin critique). Cette méthode n’est valide que si l’on considère les coûts d’accélération pour une tâche, et non pas par jour ; autrement, on se rend compte qu’il est pénalisant de réduire la tâche H, ce qui est aberrant.
En fin de compte, les deux méthodes doivent mener au même résultat. J’avoue ne pas avoir essayé la deuxième, par manque de temps. Il ne faut pas oublier de garder à l’esprit le meilleur rapport temps consacré à l’approfondissement sur note ! Mais si quelqu’un peut me dire si ça marche bien…
En réalité, le problème proposé a suscité maintes interrogations. Je l’ai traité le jeudi 15 janvier avec Pierre-Louis, date limite puisqu’il partait à Prague. La principale difficulté a été d’interpréter « crash cost ». En effet, l’énoncé donnait les « coûts d’accélération » pour gagner par exemple 3 jours sur telle tâche. En amphi, nous l’avions fait en comptant les coûts d’accélération pour une tâche donnée par jour. Or il me semble que l’on peut vouloir réduire une tâche de seulement 2 jours, même si celle-ci peut l’être de 3 jours ; l’accélérer de 3 jours n’étant pas forcément le choix le plus judicieux. Dès lors, fallait-il prendre les 2/3 des coûts d’accélération, ou compter quand même la totalité des coûts, en admettant qu’ils soient indivisibles ?
Nous avons résolu le problème, en évitant la difficulté, non sans la signaler, en comptant les coûts d’accélération par jour, c’est-à-dire en modifiant légèrement les données du problème. Par ailleurs, cette réduction des tâches n’est que théorique. On remarque en effet dans la réalité que les projets et travaux prennent souvent du retard, et ne se terminent qu’avec exception aux dates données, à croire que les coûts supplémentaires de pénalité par jour de retard ne sont pas suffisamment déterminants pour faire respecter les délais !
Par ailleurs, on pouvait considérer le problème sous deux angles. Le premier, le plus simple au niveau de la résolution, était la méthode « classique ». Il s’agit de réduire mécaniquement la durée du projet en accélérant méthodiquement les tâches d’après la façon vue en auditorium. La seconde est, à mon avis, plus difficile à mettre en place, mais aussi plus subtile. Elle demande un peu plus de réflexion, de façon à ne pas se tromper dans les nombres, mais est tout aussi efficace. Il s’agit de déterminer par jour le seuil en dollars en dessous duquel il n’est plus intéressant de réduire. Il se calcule par jour d’après les coûts indirects, les coûts de pénalité et le coût de la tâche pour un jour (si on arrive à le déterminer !). Il suffit ensuite de la comparer au coût d’accélération pour ladite tâche. En effet, si le coût d’accélération reste supérieur au total précédent, il n’est plus intéressant de continuer à réduire, ou bien il faut essayer de réduire une autre tâche (travail qui peut être évité si l’on peut soin de suivre le chemin critique). Cette méthode n’est valide que si l’on considère les coûts d’accélération pour une tâche, et non pas par jour ; autrement, on se rend compte qu’il est pénalisant de réduire la tâche H, ce qui est aberrant.
En fin de compte, les deux méthodes doivent mener au même résultat. J’avoue ne pas avoir essayé la deuxième, par manque de temps. Il ne faut pas oublier de garder à l’esprit le meilleur rapport temps consacré à l’approfondissement sur note ! Mais si quelqu’un peut me dire si ça marche bien…
Par ailleurs, on pouvait considérer le problème sous deux angles. Le premier, le plus simple au niveau de la résolution, était la méthode « classique ». Il s’agit de réduire mécaniquement la durée du projet en accélérant méthodiquement les tâches d’après la façon vue en auditorium. La seconde est, à mon avis, plus difficile à mettre en place, mais aussi plus subtile. Elle demande un peu plus de réflexion, de façon à ne pas se tromper dans les nombres, mais est tout aussi efficace. Il s’agit de déterminer par jour le seuil en dollars en dessous duquel il n’est plus intéressant de réduire. Il se calcule par jour d’après les coûts indirects, les coûts de pénalité et le coût de la tâche pour un jour (si on arrive à le déterminer !). Il suffit ensuite de la comparer au coût d’accélération pour ladite tâche. En effet, si le coût d’accélération reste supérieur au total précédent, il n’est plus intéressant de continuer à réduire, ou bien il faut essayer de réduire une autre tâche (travail qui peut être évité si l’on peut soin de suivre le chemin critique). Cette méthode n’est valide que si l’on considère les coûts d’accélération pour une tâche, et non pas par jour ; autrement, on se rend compte qu’il est pénalisant de réduire la tâche H, ce qui est aberrant.
En fin de compte, les deux méthodes doivent mener au même résultat. J’avoue ne pas avoir essayé la deuxième, par manque de temps. Il ne faut pas oublier de garder à l’esprit le meilleur rapport temps consacré à l’approfondissement sur note ! Mais si quelqu’un peut me dire si ça marche bien…
Ecrit par styria, le Mardi 20 Janvier 2004, 10:03 dans la rubrique "Premiers Pas".
Commentaires
Marc Humbert
20-01-04 à 11:57
Votre idée est intéressante mais c'est n'est pas différente de la procédure vue en amphi. Vous proposez un moyen ingénieux d'arrêter plus tôt la recherche du meilleur compromis. C'est bien de chercher à limiter le boulot (il faut être fainéant en MQAD) mais ce n'est pas forcément le mieux ; je m'explique...
Le cours s'appelle MQAD et le "AD" signifie "Aide à la Décision". Le but n'est pas de prendre une décision à la place du décideur mais de proposer une aide et la décision reste humaine. Il est donc plus riche de proposer au chef de projet un tableau COMPLET avec toutes les alternatives = toutes les durées avec à chaque fois le coût minimal correspondant. Le chef de projet peut ensuite décider de réduire encore même si on est plus haut que le "meilleur compromis" parce qu'il juge que le critère temps est le plus important.
Repondre a ce commentaire
Décision chef de projet
styria
20-01-04 à 12:03
Je suis tout à fait d'accord que la décision finale revient au chef de projet ; et il est donc mieux de lui suggérer toutes les solutions possibles. Il prendra sa décision en fonction de ses propres critères : coût, temps ou autre.
Cependant, je ferai juste un petite remarque quant à l'énoncé du problème. Il s'agissait de trouver le chemin aboutissant au coût le moins cher. Dans cette optique, je n'ai pas cherché à réduire au maximum, mais j'ai arrêté lorsque les coûts remontaient. Bref, si on veut être fainéant tout en répondant à la question, je pense que ma méthode reste valable !
Repondre a ce commentaire