Finir ce que l’on commence avant de commencer autre chose

Finir ce que l’on commence avant de commencer autre chose

Finir ce que l’on commence, avant de commencer autre chose, n’est pas seulement une question de délais. C’est également une question d’argent.

Petite étude de cas.

Imaginons 5 « projets » d’applications informatiques qui pèsent chacune une charge de 5 jours, chacun des 5 jours étant « siloté » dans une étape indépendante. Par ailleurs, chaque application doit générer 500 euros de chiffre d’affaires par jour et 50 % de marge brute (donc 250 euros) dès sa livraison.

Quel pourrait bien être l’intérêt de choisir de les développer dans leur intégralité l’une après l’autre ou de fractionner et d’alterner équitablement notre investissement par tranche d’un jour ? Comme un dessin vaut bien deux discours aux desseins pas toujours très clairs, voici une première illustration que nous appellerons organisation «  A ».

Dans cette illustration, on voit que les différents projets sont traités alternativement par tranche d’une journée. Tout le monde est content puisque son projet est en mains et avance.

L’ensemble des projets cumulera un temps total d’attentes de 115 jours.

Pendant les 25 jours présentés, il y aura eu 25 jours de travail cumulés.

Pendant cette même période, les projets auront généré 5000 euros de chiffre d’affaires.

Prenons une deuxième organisation possible illustrée ci-après. Nous l’appellerons organisation « B » :

Dans cette illustration, on voit que les différents projets sont traités successivement jusqu’à leur terme. Au début, un seul commanditaire sur les 5 voit que son projet est en cours de développement. Les 4 autres commanditaires craignent probablement que leur projet commence en retard.

Néanmoins, comme dans le cas précédent, il n’y a pas de dérive dans cet exemple et l’ensemble des projets cumulera un temps total d’attentes de 75 jours.

Pendant les 25 jours présentés, il y aura eu 25 jours de travail cumulés.

Pendant cette même période, les projets auront généré 27 500 euros de chiffre d’affaires.

Imaginons que chacun des 25 jours de travail cumulé soit réalisé par un consultant informatique au tarif journalier de 500€. Dans les deux types d’organisations, le coût des développements est de 12 500 euros pour 25 jours.

Regardons maintenant l’autofinancement des développements par la marge brute générée lors des 25 premiers jours :

L’ organisation « B » a largement couvert ses coûts de développement là où l’organisation « A » en couvre seulement 20 % !

Naturellement, il se trouvera toujours quelqu’un qui viendra pinailler sur le pourcentage réel de marge brute applicable au chiffre d’affaires d’une application informatique. Il est très certainement très variable d’un métier à l’autre, et plus important qu’on ne l’imagine. Mais il est évident que plus la marge brute est forte plus l’organisation A est pénalisante financièrement pour l’entreprise par rapport à l’organisation B. Accessoirement, je peux difficilement imaginer, qu’à l’heure où les développements informatiques sont pilotés par la valeur, il existerait encore des entreprises qui développeraient des systèmes d’information à faible valeur ajoutée et donc à faible marge !

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s