Article publié dans le blog.pentalog.fr

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.

Frédéric LASNIER

À propos de Frédéric LASNIER

President & Chief Executive Officer

Après un passage éclair au marketing d’une SSII à rayonnement national, Frédéric Lasnier fonde Pentalog en 1993 avec quatre camarades, universitaires comme lui. En 1995, le marasme ambiant incite Frédéric à orienter l’entreprise vers des marchés peu ou non encore occupés : le client/serveur micro/unix et l’internet. Là, tout est à faire et l’offre tellement rare que même une petite structure peut trouver sa place.
Dès 1995 également, il décide d’ouvrir le capital à la participation des salariés, laquelle atteint aujourd’hui 56%. Il s’agit pour lui de concrétiser une vision politique des membres fondateurs. A partir de 1997, il recherche les premiers clients export de Pentalog. Le pourcentage des activités développées pour l’étranger atteindra 60% en 2006.
En 1999, dans le cadre d’un grand projet logiciel (10 000 jours/homme en J2EE), il effectue ses premiers voyages en Roumanie et pose les bases de la politique de low cost européenne de Pentalog. En 2005, il initie le lancement de l’offre BPO (Business Process Outsourcing) et propose le nouveau Business Model de Pentalog.
En 2006, avec l’aide d’Ausy, l’un des 5 plus importants acteurs français du marché des services de R&D externalisée, il crée Pentalog Technology, a venture by Ausy and Pentalog, co-détenue à parité égale par les deux entreprises associées. Cette Joint Venture a pour vocation de fournir des services de R&D low cost, mais de haut niveau qualitatif, aux ténors de l’industrie mondiale. Frédéric Lasnier prend la direction opérationnelle de cette alliance.
En 2008, il crée Pentalog Deutschland, la filiale allemande du groupe et Pentalog Vietnam. Dans l’ensemble de ces productions, le pilotage est assuré depuis Orléans où est également consolidé 70% des valeurs ajoutées.

Arrière

2 réponses à Organisation et méthode de production design to cost

  1. nilmer74 dit :

    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 …

  2. Fred dit :

    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.

Laisser un commentaire


8 + = 10