Organigramme du processus de développement de produits (modèle de porte d'étape)
Un organigramme du processus de développement de produits étape par étape : sélection des idées, analyse de rentabilisation, étape 1, go or kill, conception, validation, pilote, étape 2 et examen du lancement.
Qu'est-ce que le processus organigramme du processus de développement de produits (modèle de porte d'étape) ?
Un processus de développement de produits transforme un flux d’idées en un petit nombre de produits lancés, et le travail qu’il effectue consiste principalement en une soustraction. Toute organisation peut générer des concepts ; la discipline consiste à décider lesquels arrêter et à les arrêter suffisamment tôt pour que l'argent n'ait pas déjà été dépensé. C’est à cela que sert une structure de porte de scène. Le travail est regroupé en étapes, chaque étape se termine par une porte, et une porte n'est une porte que si elle peut dire non. Sans kill branche, vous n'avez pas de portail, vous avez une réunion de statut : les projets arrivent avec élan, personne ne veut être la personne qui en termine un, et le portefeuille se remplit silencieusement de programmes à moitié vivants qui consomment de la capacité d'ingénierie sans jamais prendre de décision de lancement.
Cette page cartographie l'ensemble du cycle, de l'idée à l'examen post-lancement, pour une équipe produit interfonctionnelle. Sa portée est volontairement plus large que trois modèles voisins. Il ne s'agit pas du processus de publication du logiciel chez /fr/templates/organigramme-du-processus-de-publication-du-logiciel, qui démarre lors d'une construction complète du code et se termine lors de la surveillance de la production, et ce n'est pas non plus l'arbre de décision go/no-go chez /fr/templates/processus-de-decision-go-no-go-arbre-de-decision-de-preparation-au-lancement, qui zoome jusqu'à la porte de préparation au lancement et l'étend en une douzaine de questions de preuves. Si votre produit est déjà lancé et que vous y apportez des modifications, le processus souhaité est le contrôle des changements chez /fr/templates/processus-de-controle-des-changements. Ici, la porte de lancement est un nœud à trois branches ; tout ce qui se trouve devant lui, de la sélection d'idées à un pilote de production limité, constitue la substance du tableau.
Le modèle comporte vingt étapes réparties en cinq couloirs (gestion de produit, ingénierie et R&D, conception, qualité et commercial) répartis en cinq étapes : idée et sélection, analyse de rentabilisation, conception et développement, validation, lancement et examen. Il inclut les boucles que la plupart des versions dessinées laissent de côté : une branche de recyclage qui renvoie une analyse de rentabilisation faible pour la retravailler plutôt que de la tuer, une révision de conception échouée qui revient à une conception détaillée, un message « Répond aux exigences ? » décision selon laquelle la validation a échoué vers la conception plutôt que vers un projet pilote, et une branche d'extension du pilote à la porte 2 pour un produit qui est presque prêt mais pas encore.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq axes fonctionnels (Gestion de produits, Ingénierie et R&D, Conception, Qualité et Commercial) répartis en cinq étapes : Idée et sélection, Analyse de rentabilisation, Conception et développement, Validation, et Lancement et revue.
- Une étape de sélection avant toute dépense : une idée est capturée dans le pipeline et comparée à la stratégie dans la voie de gestion des produits, de sorte que les concepts faibles sont filtrés avant que quatre fonctions ne soient sollicitées.
- Quatre entrées distinctes dans l'analyse de rentabilisation, une par fonction : la faisabilité technique de l'ingénierie et de la R&D, le concept de produit de la conception, les exigences réglementaires de la qualité et le dimensionnement du marché du commercial, le tout intégré dans "Construire l'analyse de rentabilisation".
- Porte 1 avec trois résultats nommés : « Porte 1 : développer ou tuer ? branches Accédez aux exigences et aux spécifications, recyclez vers l'analyse de rentabilisation pour la retravailler et tuez vers « Idée mise de côté avec justification » comme rejet final.
- Deux boucles de retouche distinctes dans « Développer la conception détaillée » : « Révision de la conception réussie ? » revient sur Retravailler avant la tentative de validation, et « Répond aux exigences ? renvoie Non après le test de validation, donc un test échoué ne s'infiltre jamais dans le pilote.
- Porte 2 comme décision de lancement : « Porte 2 : approuver le lancement ? branches Lancement sur le marché dans la voie commerciale, extension du pilote jusqu'au pilote de production limitée et mise à mort jusqu'à "Lancement arrêté à la porte 2", avec un examen post-lancement et une fermeture mettant fin au flux.
Quand utiliser ce modèle
- Vous introduisez un processus d'étape-porte pour la première fois et avez besoin d'une image convenue des étapes, des portes et de qui en est propriétaire, avant qu'elle ne devienne un pack de modèles et un ensemble d'invitations à des réunions.
- Les projets de votre portefeuille ne semblent jamais s'arrêter : rien n'est formellement tué, la capacité est répartie sur trop de programmes en cours et personne ne peut indiquer la décision qui a autorisé chacun d'entre eux.
- Le travail de développement commence avant que l'analyse de rentabilisation n'existe, ou la spécification est rédigée après la conception, et vous devez montrer l'ordre prévu aux personnes effectuant le travail.
- Vous alignez le processus sur un système de gestion de la qualité (la clause 8.3 de la norme ISO 9001 couvre la conception et le développement et prévoit que la planification, les examens, la vérification et la validation soient effectués et enregistrés) et vous avez besoin du flux avant de rédiger la procédure.
- Les transferts entre le produit, l'ingénierie, la conception, la qualité et le commerce constituent le véritable goulot d'étranglement, et vous souhaitez voir quelle fonction maintient le travail à chaque étape plutôt que d'en discuter après une date de lancement manquée.
Comment cela fonctionne
Renommez les voies selon vos fonctions réelles
Remplacez la gestion des produits, l'ingénierie et la R&D, la conception, la qualité et le commerce par les fonctions dont vous disposez réellement. Les équipes matérielles divisent généralement l'ingénierie en ingénierie mécanique, électronique et manufacturière ; Les équipes logicielles n'ont souvent pas de voie qualité distincte et devraient intégrer la validation à l'ingénierie plutôt que de laisser une bande vide. Fusionnez toutes les voies auxquelles vous ne pouvez pas associer un propriétaire nommé et conservez le nombre de voies à ce qui tient sur un seul écran.
Rédigez les critères de porte avant le premier examen
Un portail sans critères écrits devient une présentation. Pour la porte 1, indiquez ce que l'analyse de rentabilisation doit contenir et les seuils qui en font un objectif : la taille du marché qui, selon vous, mérite d'être poursuivie, les questions de faisabilité auxquelles il faut répondre plutôt que de supposer, et la portée réglementaire. Pour la porte 2, indiquez quelle preuve pilote est requise. D'accord les deux alors que rien n'attend à la porte, car les critères négociés le jour même sont des critères écrits par celui qui s'est le plus investi dans un Go.
Décidez de ce que signifie réellement le projet pilote Recycler and Extend
Les deux branches molles sont celles où pourrissent les processus de porte d’étape. Le recyclage à la porte 1 doit comporter une liste spécifique de ce qui doit changer, un propriétaire et une date de retour ; sinon c'est un Kill que personne n'a voulu dire. Le pilote d'extension à la porte 2 doit nommer ce qui est appris, la durée de l'extension et le critère qui y met fin. Enregistrez les deux par rapport au projet plutôt que dans les notes de réunion, et comptez la fréquence à laquelle chacun est utilisé : un portail qui ne fait que recycler ne décide de rien.
Conservez la révision et la validation de la conception sous forme de contrôles distincts
Ils répondent à différentes questions. L'examen de la conception demande si la conception et le prototype répondent aux spécifications convenues au début du développement, et il s'agit d'une vérification par les pairs et les parties prenantes de la conception elle-même. Les tests de validation demandent si le produit fini répond aux besoins de l'utilisateur et aux exigences réglementaires dans des conditions réelles. C'est en les séparant que les deux boucles de remaniement de ce graphique sont significatives : l'une détecte un problème de conception avant de dépenser sur des unités de test, l'autre détecte un problème d'exigences avant de dépenser sur un pilote.
Définir le pilote et ses critères de sortie
« Lancer un projet pilote de production limité » signifie quelque chose de différent dans chaque organisation : un lot de pré-production, un lancement en douceur dans une région, une cohorte d'accès anticipé. Notez de quoi il s'agit, le volume ou le nombre de clients, ce qui est mesuré (rendement, taux de défauts, charge de support, activation) et combien de temps cela dure avant que la porte 2 ne soit convoquée. Un pilote sans fin définie, c'est ainsi que les dates de lancement glissent sans qu'aucune décision ne soit prise.
Nommer les propriétaires des portes et enregistrer les décisions
Pour chaque porte, nommez la personne qui tient l'appel et le groupe qui doit être présent. Mieux vaut un propriétaire nommé par porte qu’un comité qui décide par absence d’objection. Capturez le résultat, la date, les critères appliqués et la justification : surtout pour un Kill, puisqu'un kill non enregistré réapparaît sous la même idée dans six mois. Si vous travaillez selon un système de gestion de la qualité, cet enregistrement constitue également la preuve que des examens ont eu lieu.
Publiez-le, puis révisez-le après chaque lancement
Partagez le tableau où se déroule le travail, à côté des modèles de portail plutôt que dans un dossier de politique, et demandez aux propriétaires de voies de le signer. Après chaque lancement, parcourez le flux avec l'équipe : quelle porte a été ignorée, quelle boucle a été effectuée et pourquoi, et si l'examen post-lancement a réellement eu lieu ou a été dépassé par le projet suivant. Conservez les versions précédentes afin de pouvoir montrer quand le processus a changé et ce qui l'a motivé.
Questions fréquentes
Quelles sont les étapes d’un processus de développement de produit ?
Cinq étapes couvrent la plupart des organisations de produits. Premièrement, l'idée et la sélection : capturez l'idée et testez-la par rapport à la stratégie, avant qu'une fonction n'engage des efforts. Deuxièmement, l'analyse de rentabilisation : évaluer la faisabilité technique, décrire le concept, identifier les exigences réglementaires et dimensionner le marché, puis rassembler les quatre dans un seul cas et l'amener à la porte 1. Troisièmement, la conception et le développement : convenir des exigences et des spécifications, développer la conception détaillée, construire un prototype fonctionnel et procéder à une revue de conception. Quatrièmement, validation : planifiez et exécutez des tests de validation par rapport à la spécification, puis exécutez un pilote de production limité une fois qu'il est réussi. Cinquièmement, lancement et examen : prenez la décision de lancement de la porte 2, lancez-le sur le marché, puis effectuez un examen post-lancement et clôturez le projet.
Qu’est-ce qu’un processus de gate et que peut décider un gate ?
Un processus par étapes regroupe le travail de développement en étapes et place un point de décision entre chacune d'elles, de sorte que le financement et les efforts soient débloqués par étapes plutôt qu'au début. Les résultats conventionnels sont les suivants : aller, tuer, conserver et recycler : passer à l'étape suivante, arrêter le projet, le garer en fonction de sa capacité ou de sa priorité, ou le renvoyer pour retravailler l'étape en cours avant de décider. Ce modèle montre aller, recycler et tuer à la porte 1, et lancer, étendre le pilote et tuer à la porte 2. Si vos portes ne produisent jamais autre chose que partir, ce ne sont pas des portes et la gestion de portefeuille qu'elles sont censées assurer n'a pas lieu.
Quelle est la différence entre une revue de conception et des tests de validation ?
Une revue de conception vérifie la conception par rapport à ses entrées : la conception détaillée et le prototype répondent-ils aux spécifications convenues au début du développement et les risques ouverts sont-ils compris. Les tests de validation vérifient le produit par rapport aux besoins : fonctionne-t-il pour l'utilisateur, dans des conditions réalistes, par rapport aux exigences, y compris celles réglementaires. La vérification est la première question, la validation la seconde, et les normes de gestion de la qualité les traitent comme des activités distinctes pour de bonnes raisons. Dans ce tableau, il s'agit de deux décisions avec deux chemins de retour distincts vers la conception détaillée, car un défaut de conception découvert lors de l'examen est bien moins coûteux que le même défaut découvert après la construction des unités de test.
En quoi est-ce différent d'un processus de publication de logiciel ou d'un arbre de décision go/no-go ?
Portée. Ce graphique couvre l'ensemble du cycle de développement, depuis l'entrée d'une idée dans le pipeline jusqu'à l'examen post-lancement, et traite chaque décision de lancement comme un nœud unique. Le processus de publication du logiciel chez /fr/templates/organigramme-du-processus-de-publication-du-logiciel commence beaucoup plus tard, lors d'une construction complète du code, et détaille les suppressions de branches, les portes de test, la préparation, le déploiement, la restauration et les correctifs. L'arbre de décision go/no-go de /fr/templates/processus-de-decision-go-no-go-arbre-de-decision-de-preparation-au-lancement va dans l'autre sens et étend une porte en une douzaine de questions de preuves avec cinq résultats nommés. Utilisez cette page pour définir le cycle, et l'une ou l'autre des autres pour la partie dont vous avez besoin plus en détail.
À qui revient chaque décision de porte ?
Une personne nommée par porte, les fonctions contributives étant considérées comme des preuves plutôt que comme des votes. La porte 1 appartient généralement à celui qui possède le portefeuille et le budget (un directeur de produit, un directeur général ou le groupe de direction d'une petite organisation), car il s'agit d'une décision sur la destination de la capacité de développement. Gate 2 est une décision de préparation et une décision commerciale, le propriétaire a donc besoin de l'autorité nécessaire pour organiser un lancement lorsque la qualité ou l'approvisionnement ne sont pas prêts, et pas seulement pour l'approuver. Notez les droits de décision avant la première porte : une porte non attribuée est attribuée par défaut à celui qui est le plus ancien dans la pièce ce jour-là.
Combien de portes un processus de développement de produits doit-il comporter ?
Moins que vous ne le pensez, et seulement là où une véritable décision existe. Deux sont présentés ici car ils marquent les deux points où les dépenses engagées sautent : la porte 1 autorise le développement, la porte 2 autorise le lancement et les coûts de production, de marketing et de support qui s'ensuivent. Les programmes plus importants ou plus réglementés ajoutent généralement une porte entre le concept et la conception détaillée, et une avant le début de la validation. Le test utile est de savoir si la porte pourrait vraisemblablement renvoyer autre chose que "Go". Si une évaluation n’a jamais arrêté ou modifié un projet, supprimez-le ou déplacez-le là où l’argent est réellement engagé.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus passe le relais à Organigramme du processus d'introduction de nouveaux produits (NPI).
C'est une étape de Développement de produits.
Étape 1: Organigramme du processus de développement de produits (modèle de porte d'étape) Vous êtes ici
Un organigramme du processus de développement de produits étape par étape : sélection des idées, analyse de rentabilisation, étape 1, go or kill, conception, validation, pilote, étape 2 et examen du lancement.
Étape 2: Organigramme du processus d'introduction de nouveaux produits (NPI)
Modèle d'organigramme de processus d'introduction de nouveaux produits (NPI) : transfert, examen de la fabricabilité, outillage, qualification des fournisseurs, construction pilote et montée en puissance.
Étape 3: Organigramme du processus de demande de modification technique (ECR à ECN)
Fait partie de
- Fabrication
- Développement de produits