Organisation et méthode de production design to cost
La question du sourcing ou du lieu de production, dans le logiciel, est celle que l’on pose en premier lieu à celui qui dit mener une recherche en diminution de ses coûts opérationnels.
De son côté, Il y a bien longtemps (en fait bien avant de songer à délocaliser) que l’industrie s’est posée des questions visant à réduire les coûts de production. Elle l’a toujours fait en fait, grâce à des services méthodes et études adaptés, en portant la réflexion sur l’ordonnancement des tâches, sur la gestion de sous-ensembles plus ou moins faciles à manipuler, mais aussi par la sous-traitance d’opérations spécifiques…
Puis sont venues les crises de surproduction industrielle des années 80 et 90. Beaucoup pour survivre, en particulier dans l’automobile, ont intégralement repensé la productivité :
– soit en considérant que le design était lui-même un facteur de productivité (Ford Ka et Focus par exemple, dont le design pourtant original est parti des formes les plus faciles à produire)
- soit en cherchant à réaliser des économies fiscales et sociales par la délocalisation
Au confluant des deux stratégies se niche la Logan de Renault. Renault a en effet imaginé un design partant d’anciennes presses et moules existants en même temps qu’il a lancé sa production en Roumanie. Mieux encore, plutôt que de partir d’une méthode up to date en occident, Renault a décidé d’oublier l’ultra robotisation et de lui préférer un vaste recours à la main d’œuvre locale, particulièrement peu onéreuse. On pourrait craindre pour la qualité du résultat… non, une Logan est une voiture solide mais qui est basée sur des matériaux un peu moins chic que d’autres productions portant des marques plus prestigieuses que Dacia.
Dans notre secteur d’activité, franchement, la réflexion sur la méthode de production laisse à désirer. J’irai presque jusqu’à dire, qu’en dehors des méthodes de gestion de projet, elle n’existe pas. C’est triste du point de vue de l’ingénieur mais ça l’est aussi du point de vue général de la performance économique : micro économique (au niveau de l’entreprise qui produit du logiciel) ainsi qu’au niveau macro économique (état producteur de logiciel).
Aussi, et un peu tout à trac, je livre quelques éléments mis en œuvre ici ou là, y compris chez nous, et qui pourraient être structurés dans une vraie analyse de la valeur (valeur travail, bien sûr 
) :
- 1. faire réellement démarrer les projets par une phase de préparation
- 2. assurer l’inventaire et le suivi réguliers des fonctions et sous ensemble déjà réalisés dans le passé
- 3. concevoir autour de ces sous-ensembles quand c’est possible
- 4. choisir la technologie la moins coûteuse et la plus adaptée en fonction des points 2 et 3 (quand le client nous laisse le conseiller sur cette question)
- 5. Faire rédiger, par les testeurs, les documentations utilisateurs à partir des analyses fonctionnelles, techniques et des cahiers des tests. A la clef, il y aura réduction des coûts (en tous cas en offshore), spécialisation fonctionnelle et amélioration de la compréhension par le développeur qui disposera d’un document supplémentaire
- 6. Faire directement des PA après la réalisation des tests, alors que les développeurs sont toujours mobilisés
- 7. Ne pas hésiter à écarter des PA
Franchement qui peut penser que la qualité en pâtirait ?
La liste n’est pas exhaustive, car je n’ai pas l’intention d’aller plus loin dans ce billet. Mais je vois beaucoup d’autres idées à développer sur lesquelles Pentalog reviendra. En particulier, nous avons une idée autour d’un mode de contractualisation visant à transformer une régie délocalisée en forfait lorsqu’un ensemble livré, ayant subi un process de QA reçoit un visa. Nous y reviendrons, car cette idée s’inscrit dans la même ligne de recherche de compétitivité opérationnelle.
 |
Posted on jeu., 14 jun. 2007 16:50 by flasnier (2197 day(s) old) | |||||||
|
Déposé le mar., 28 aou. 2007 20:27 par nilmer74
Bonsoir, je viens de lire avec interêt votre article si dessus …
Je travaille actuellement chez un éditeur de logiciel et
depuis maintenant plus d’un an, dans le cadre de mon projet je mets en place des méthodologies de développement afin de maitriser nos développements réalisés hors de la France : en Roumanie par exemple. Par rapport à mon expérience, je tiens à préciser qu’il existe des méthodologies et des outils sur le marché qui nous permettent d’industrialiser les processus de fabrication/production et surtout dans mon cas de sécuriser des développements hors de France. Typiquement dans le cadre de mon projet, nous portons notre effort – en amont des développements – sur la définition des exigences fonctionnelles que nous modélisons en UML. Les exigences fonctionnelles ainsi définies et validées sont utilisées pour définir des exigences de tests auquels sont rattachés des plans de tests, ce qui nous permet par la suite de connaître la couverture de test. A partir de la modélisation UML on peut utiliser des outils d’aide au développement ce qui permet entre autre de structurer les développements. On pourrait aussi parler des outils de type MAVEN/Continum, qui permettent de maitriser le contenu et la génération des livrables en toute sécurité. Conclusion si l’on souhaite vraiement mettre en place des processus/méthodes de production : ils existent mais tout cela à un coût …. coût qui peut être compensée par un coût de main d’oeuvre moins chére …
Déposé le lun., 3 sep. 2007 18:32 par Fred
Ce n’est pa exactement comme ça que nous voyons les choses.
Quand on parle de qualité, on parle déjà de réduction des coûts. Un plan de qualité valable, ne saurait avoir pour effet d’augmenter les coûts de production et d’exploitation de l’entreprise éditrice de logiciels… au contraire.
La division des tâches idoine, le plan de test adéquat, les outils (et leur usage scrupuleux) de documentation et de gestion de la connaissance, ne devrait avoir d’autre fin, pour l’éditeur que de gagner du temps sur la mainteance, afn de fair plus de R&D, donc d’innover plus vite dans un contexte e maintenance réduite.
Après, il est vrai que le recours à l’offshore peut permettre d’appuyer plus encore sur les fonctions qualité. Pour deux raisons :
1. l’offshoring va obliger l’entreprise a travailer mieux (nécessité de disposer de bonnes specs, documentation et suivi de projet plus “continus”
2. Pour l’entreprise qui ne dispose pas du fond de roulement nécessaire à l’amorce d’une politique qualité, elle va s’apercevoir que là où elle ne pouvait se payer aucun IQ, ou pire, basiquement, aucun testeur, que pour le prix d’un seul à l’ouest, elle peut s’en payer 2 à l’Est et blinder ses produits… c’est ce qu’on appelle l’offshore à effet de levier. D’abord je paye moins cher et en plus je vais plus loin.
Ce même raisonnement s’appliue à l’entreprise qui peut employer 2 testeurs mais qui aurait besoin de 2,5. Ele peut tout simplement en prendre 3 en offhore et en profiter pour augmenter son niveau de contrôle.
Je dirais en conclusion que réfléchir sur la réflexion sur ola qualité et l’organisation vont déjà diminuer les coûts. Ensuite une bonne description permettra un recours plus aisé à l’offshore.