En quoi le matériel industriel est différent du logiciel B2B |


Les produits sont des produits, oui? Lorsque nous parlons de manière large et générique de la gestion des produits, nous supposons que tous les produits / services sont suffisamment similaires pour que nous puissions appliquer les mêmes outils, techniques, modèles de planification financière, approches de conception, objectifs et paramètres. Mais j’ai travaillé avec plusieurs clients qui fabriquent du matériel industriel à longue durée de vie – et dont les principales hypothèses de fonctionnement peuvent rendre difficile l’ajout de produits logiciels de revenus à leur portefeuille.

Les entreprises industrielles sérieuses construisent de sérieux équipements industriels à longue durée de vie. Pensez à l’infrastructure de la chaîne de montage automobile. Ou des grues massives pour charger / décharger les conteneurs des cargos commerciaux. Ou des turbines de centrales électriques et des installations solaires à grande échelle. Ou des ascenseurs pour les immeubles de bureaux de grande hauteur. Ou des plates-formes de forage pétrolier offshore. Ou des moteurs à réaction. Ces entreprises ont besoin d’un mélange spécial d’expertise en génie physique, de savoir-faire en matière de fabrication, de contrôles financiers rigoureux et de longs horizons de planification.

De plus en plus, ces mêmes sociétés créent des logiciels pour surveiller, ajuster et analyser les performances en temps réel de leurs équipements sous-jacents. Pour vendre des fournitures en fonction de l’utilisation réelle. Pour partager des données avec des partenaires. Pour répondre aux attentes des clients en matière d’utilisation des logiciels de type consommateur. Pour répondre aux menaces de concurrents uniquement logiciels.

Mais des processus de gestion et de développement de produits qui fonctionnent bien pour un matériel à longue durée de vie peuvent handicaper les organisations de logiciels. Les entreprises qui connaissent des décennies de succès en matière de matériel industriel ont souvent du mal à adapter leurs procédures d’exploitation standard aux offres numériques.

Identifions quelques hypothèses sous-jacentes sur la façon dont le matériel industriel est conçu / construit / vendu, puis mappons-les à des produits logiciels B2B. Selon le côté de l’allée d’où vous venez, la moitié de ces affirmations seront complètement évidentes et l’autre moitié mystifiante.

[1] Pour le matériel industriel, le cycle de développement / conception est distinct du cycle de fabrication. Nous pouvons passer des mois (ou des années) à construire un prototype physique presque parfait de notre prochaine version, en spécifiant complètement notre prochaine itération de produit en concevant et en construisant rigoureusement une ou deux unités de test – puis en publiant les spécifications détaillées, la nomenclature, les estimations de coûts et des statistiques de performance à nos équipes de fabrication / opérations / achats. La plupart du temps, les coûts, les risques, la planification et l’optimisation financière se situent dans le cycle de fabrication (et non dans le cycle d’ingénierie et de conception), car chaque unité est coûteuse à construire. Il se peut que nous devions réorganiser un processus d’assemblage complet, trouver des pièces spéciales et prévoir de manière semi-précise la demande physique d’unités physiques.

Pour les produits logiciels, le processus de développement et de conception * est * le processus de fabrication. Nous travaillons à partir d’histoires d’utilisateurs ou d’épopées ou d’objectifs / KPI de niveau supérieur, prenant des décisions incrémentielles de produit et techniques chaque jour. Avec de solides outils DevOps ou CI / CD, notre «publication aux clients» formelle consiste en quelques frappes ou une poussée vers notre plateforme SaaS multi-locataire.

Contrairement au matériel principal, il n’y a pas de spécification logicielle parfaitement précise. Il est impossible de décrire complètement chaque vérification de validation des données, option, branche logique, boîte de dialogue, placement des pixels, message d’erreur et flux de travail sans dupliquer le code lui-même. Nous répondons donc à certaines questions en exécutant notre application – pour voir exactement ce qui se passe dans une situation obscure – ou en regardant directement dans le logiciel. La nature en couches des logiciels d’entreprise, où nous nous appuyons sur des systèmes d’exploitation et des plates-formes cloud et des kits d’outils commerciaux qui évoluent chacun sous nous, ce qui signifie que nous n’avons pas de produit stable («fini») en permanence comme le font nos partenaires matériels.

Implication: il est tout à fait logique que les responsables de matériel industriel demandent des caractéristiques précises, des coûts de fabrication, des statistiques de performance, des nomenclatures et des calendriers de livraison avant de s’engager dans la production complète d’un nouveau produit. Nous utilisons le cycle de développement / conception du matériel pour éliminer les risques avant de consacrer M $ à la production effective des marchandises. Cela n’a cependant guère de sens pour les produits logiciels, où nous passons tout notre temps et notre argent à créer la première unité. Les gens des produits logiciels sont généralement stupéfaits par les demandes des dirigeants pour des horaires précis, des coûts précis, des dates de livraison des fonctionnalités fixes ou des garanties de performance.

[2] Pour le matériel industriel, la marge par unité est notre principale mesure de réussite. La marge unitaire est la différence entre le «revenu net de chaque turbine que nous construisons» et le «coût total de construction et de livraison d’une turbine de plus», nos coûts de conception étant amortis sur la production annuelle de turbine. Nous dépensons beaucoup d’énergie pour améliorer la marge par unité et réduire les coûts de fabrication, en veillant à ce que chaque unité soit individuellement rentable. De la société PL place «Revenu» et «Coût des marchandises vendues» en haut, pour que le monde puisse le voir. La plupart des employés connaissent la marge brute de leurs produits à une fraction d’un pour cent.

Et la société consacre une énergie considérable à l ‘«expansion des marges»: dégager plus de bénéfices par unité en réduisant le nombre de pièces, en remplaçant les matériaux, en trouvant des fournisseurs alternatifs, en externalisant l’assemblage et en gérant les coûts de stockage des stocks. («Si nous pouvons réduire nos coûts de production unitaires de 95 000 $ à 92 000 $ par bande transporteuse, nous pouvons augmenter les revenus de 15 millions de dollars par an.») L’équipe Achats insiste sur les fournisseurs secondaires et tertiaires pour nous donner un levier d’achat et éviter les temps d’arrêt. («Nous achetons 70% de nos attaches en platine 5 mm personnalisées auprès du fournisseur X, mais nous achetons également auprès du fournisseur Y dans le cas où X a un problème de production ou menace d’augmenter les prix.»)

La marge unitaire n’a guère de sens dans le secteur des logiciels. Nous dépensons la majeure partie de notre argent à construire un produit libérable (le premier exemplaire, si vous voulez) mais vendre des exemplaires supplémentaires presque gratuitement. Tous les aspects économiques du logiciel sont à l’échelle – vendre des milliers de copies de bits identiques – pour atteindre le seuil de rentabilité et atteindre des niveaux de rentabilité absurdes.

Et l’application de leçons de réduction des coûts matériels aux logiciels est incohérente. Nous voulons embaucher les meilleurs développeurs et concepteurs et chefs de produit (plutôt que les moins chers) car les excellents produits dépassent considérablement les inférieurs. Des designs brillants augmentent notre base de fans et nous permettent d’atteindre le seuil de rentabilité plus tôt. Et il y a peu de coûts autres que les salaires: lésiner sur les moniteurs ou les tableaux blancs ou les référentiels GitHub n’est ni utile ni matériel. A plus forte raison, les Achats sélectionnent notre fournisseur d’outils d’automatisation de test en fonction du prix le plus bas.

Implication: les entreprises de quincaillerie industrielle vivent et meurent avec une marge unitaire, qui se reflète dans chaque processus d’entreprise, des rapports de vente à la dotation en personnel en passant par la budgétisation. Cependant, cela n’a aucun sens pour les éditeurs de logiciels, qui doivent concentrer leurs rapports et leur définition d’objectifs sur le nombre d’abonnés et le taux de désabonnement. Les équipes de direction ont besoin d’un ensemble distinct de mesures opérationnelles et d’outils financiers pour comprendre leurs deux activités distinctes.

[3] Pour le matériel industriel, nous «connaissons» à l’avance les dimensions clés de l’amélioration des produits. Notamment sur des marchés établis de longue date pour des biens d’équipement coûteux, nous et nos concurrents nous efforçons d’améliorer progressivement la matérialité essentielle de nos produits: coût, débit, poids, fiabilité / MTBF, dimensions, facilité d’entretien. Si nous pouvons régler notre équipement de moulage par injection pour qu’il soit 4% plus économe en énergie ou 2% plus rapide ou 6% moins susceptible d’avoir besoin d’un entretien hors cycle ou 3% moins cher à construire, nous pouvons augmenter les marges et gagner plus d’offres. La nécessité de ces améliorations est (relativement) évidente pour nous et nos clients – le plus difficile est Comment nous pourrions concevoir de telles améliorations. Nous passons beaucoup de temps / argent / énergie à faire des recherches Comment pour rendre nos produits un peu meilleurs, en se concentrant sur l’exploration technique. Pas besoin de valider si les clients industriels «souhaitent» de telles améliorations.

Les options concurrentielles pour les produits logiciels sont beaucoup plus larges, avec des résultats moins prévisibles. Plutôt que de rivaliser sur les limites physiques et les performances, nous avons une large palette d’améliorations comprenant flux de travail plus faciles; intégrations de données; analytique; auto-configuration; l’image de marque; Mises à jour automatiques; intégration plus rapide; rapports montrant les économies réalisées par les clients à ce jour; stockage en ligne; interfaces vocales; authentification multifacteur; autorisations de sécurité déléguées; autodiagnostic; notification par SMS; et tableaux de bord personnalisables. Pendant ce temps, nos concurrents choisissent leurs propres stratégies d’amélioration. Tout cela dépend de la compréhension de la valeur relative que différents groupes de clients peuvent voir dans nos diverses améliorations.

Implication: cela met une énorme prime sur une validation rigoureuse des utilisateurs / du marché avant de créer des fonctionnalités potentiellement intéressantes. Il est beaucoup moins évident de savoir quelles améliorations logicielles feront écho à quels segments d’audience, d’autant plus que les utilisateurs veulent souvent voir notre logiciel plutôt que de l’entendre décrit. Et construire une fonctionnalité pleinement fonctionnelle signifie dépenser de l’argent réel. Notre équipe de développement est rémunérée (généreusement!), Qu’elle crée une fonctionnalité que nos utilisateurs adorent ou une fonctionnalité qui n’a jamais été utilisée. Nous investissons donc d’abord dans des croquis, des prototypes de papier, des démos cliquables et d’autres artefacts de conception à faible coût. Et nous testons continuellement nos premiers concepts. Il est facile de se tromper en substituant des opinions personnelles à une bonne validation continue sur le terrain – la nature expérientielle des logiciels rend beaucoup plus difficile de prédire ce qui motivera les utilisateurs. Et respecter notre calendrier ou nos engagements budgétaires en livrant quelque chose qui ne passionne pas notre public est un gaspillage à 100%.

(Bien sûr, cela suppose un marché du matériel stable avec peu de perturbations. Mais le changement nous envahit. Les fabricants d’horloges, d’appareils photo, de calculatrices, de jetons de sécurité, d’appareils GPS, de podomètres, de matériel d’expédition en vrac, de matériel de radiodiffusion, de machines à écrire et de thermostats résidentiels ont chacun * soudainement * découvert qu’ils étaient moins pertinents à l’ère numérique. Ainsi, même les entreprises de matériel industriel doivent effectuer des études de marché / clients pour éviter de disparaître.)

[4] Le matériel industriel est installé une fois, à grands frais, et reste en place pendant des années ou des décennies. Cette unité doit donc être presque parfaite à la livraison et inclure déjà toutes les fonctionnalités dont notre client a besoin. La maintenance et les mises à niveau sont peu fréquentes et planifiées des mois à l’avance, car elles nécessitent l’arrêt des équipements ou l’arrêt des processus de production.

Par exemple, nous pourrions installer un compresseur d’air massif dans notre usine d’embouteillage de soda pour mettre les bulles dans notre pop. Coûtant six ou sept chiffres et pesant plusieurs tonnes, cet équipement doit fonctionner sans problème dès le départ: fonctionner pendant des années avec peu de pannes et seulement un entretien occasionnel. Chaque minute d’arrêt signifie qu’une minute ne produit pas de soude. Et le remplacer pourrait nécessiter le démontage d’une section entière de l’usine pour déplacer des tonnes d’autres équipements. Nous sommes donc fortement incités à disposer de procédures et de listes de contrôle extrêmement détaillées – pour nous assurer que nous l’installons correctement la première fois et que chaque fonction fonctionne parfaitement. Comme Planification de la NASA pour Apollo 11, nous pratiquons chaque étape à l’avance plutôt que de découvrir des problèmes pour la première fois sur site. (Astuce: parfois la cascade est précisément la bonne approche.)

L’ajout d’une nouvelle fonctionnalité ou le réglage des performances de notre matériel existant est probablement une entreprise énorme. Ainsi, notre prochaine chance d’amélioration spectaculaire pourrait se situer à la fin du cycle de vie de cet équipement, dans dix ou vingt ans, lorsque nous le remplacerons. Ce qui signifie que la fin de vie d’un produit majeur pourrait prendre des décennies.

Les produits SaaS fonctionnent exactement à l’opposé. Nos clients nous paient chaque mois pour un flux d’améliorations, de mises à jour et de nouvelles fonctionnalités – une partie supposée de chaque abonnement. Nous devons donc pousser les corrections de bogues et les mises à jour mineures de manière parfaite et transparente aussi souvent que nécessaire (toutes les heures!) Après avoir testé qu’aucun utilisateur actuel ne perdra de données (via des tests de régression entièrement automatisés!) Et nos plans de déploiement pour des améliorations majeures équilibrent l’urgence du client contre une formation / notification / promotion suffisante.

Par exemple, nous pourrions déployer une série de nouveaux connecteurs de base de données pour notre système ERP multi-locataire. Différents clients doivent échanger des données avec différentes sources, nous avons donc une feuille de route pour ajouter 15 nouveaux connecteurs cette année. À mesure que chacun est terminé, nous ajoutons une option pour configurer cette base de données et l’annoncer à tous nos clients. Certains l’utilisent, d’autres attendent des mises à jour ultérieures. Nous maintenons une codeline.

Les logiciels sur site sont à mi-chemin. Les clients veulent considérer le logiciel sur site comme permanent et ignorable. Et ils n’installent pas nos mises à jour très souvent, car cela nécessite du temps et des efforts et une planification et des tests par rapport à d’autres systèmes. Mais ils nous pressent parfois pour des correctifs quand quelque chose se casse. Nous avons donc probablement autant de lignes de code que de grands clients sur site, et nous avons du mal à ajouter de la valeur au fil du temps. Et la temporisation des logiciels sur site peut prendre une décennie.

Implication: les chefs de produit matériel supposent un équipement essentiellement stable; les chefs de produits logiciels apprennent à aimer les mises à jour constantes et fréquentes.

[5] La tarification du matériel commence par le coût des marchandises et la fabrication. Nous calculons ce qu’il en coûte pour construire une unité de plus, ajoutons notre marge cible et ajustons en fonction de la concurrence ou des conditions du marché. S’il nous en coûte 150 000 $ pour construire une grue de construction et que nos investisseurs veulent une marge de 50%, notre prix de vente moyen doit être proche de 300 000 $. Les concurrents ayant des structures de coûts similaires peuvent gagner des offres en abandonnant la marge. Les fabricants plus avertis peuvent réduire les coûts, et donc les prix. Les clients ont une assez bonne idée de ce qui entre dans notre produit, ils peuvent donc repérer des profits scandaleux.

Nous payons notre équipe d’ingénierie logicielle que nous vendions une unité ou dix mille, les coûts unitaires des logiciels ne sont donc pas utiles. (La logique matérielle suggère que nous facturions au premier client 8 millions de dollars et à tous les clients suivants juste assez pour couvrir les commissions de vente.)

Et les clients achètent des logiciels en fonction de la valeur et non du coût. Si notre produit peut leur faire économiser 200 000 $ / an, nous avons le droit de facturer une partie de ces économies (35 000 $). Personne ne se soucie de la difficulté avec laquelle nous avons travaillé sur nos logiciels, de la taille de notre équipe de développement ou de notre méthodologie. Est-ce que font le travail pour lequel ils l’ont embauché? Fournit-il les performances, les économies, les gains d’efficacité ou l’augmentation des revenus que nous avions promis? La tarification des logiciels doit toujours commencer par un calcul des avantages probables pour le client. Et si nous ne pouvons pas gagner de l’argent à ces prix, nous devons construire autre chose.

Implication: la tarification basée sur les coûts est essentiellement tournée vers l’intérieur. La tarification basée sur la valeur client est principalement tournée vers l’extérieur.

[6] Si nous donnons gratuitement nos logiciels, il est difficile de justifier des investissements supplémentaires dans les logiciels. Les sociétés de matériel informatique ont tendance à utiliser les logiciels pour augmenter les prix du matériel: des diagnostics à distance ou des analyses cloud ou des interfaces améliorées sont inclus gratuitement pour différencier notre matériel de ses concurrents. Nous affectons tous les revenus à notre matériel de base, ce qui fait de nos équipes logicielles de purs centres de coûts. Les dirigeants concentrent leurs efforts de vente et de marketing sur le matériel de base, car c’est ce qui apparaît dans les rapports financiers trimestriels. Les équipes commerciales ne passent pas de temps à comprendre les «produits» logiciels car elles ne perçoivent aucune commission. Et nous avons du mal à mesurer (ou à justifier) ​​l’impact global d’un meilleur logiciel – par des enquêtes, des statistiques d’utilisation et des anecdotes.

Nous découvrons inévitablement que le l’équipe logicielle doit se développer, mais nos arguments ROI sont très faibles. («Cette refonte de l’expérience utilisateur stimulera la satisfaction des clients. Mais notre cycle de remplacement de l’équipement est de huit ans, donc nous ne verrons peut-être pas beaucoup d’impact pendant un certain temps. » «Une meilleure surveillance des équipements stimulera les commandes de pièces et de fournitures, mais tous ces revenus sont affectés aux opérations de service. Nous avons donc besoin de ce groupe pour financer notre travail. »)

Lorsque nous facturons un logiciel, nous lui attribuons de la valeur. Il obtient sa propre ligne dans les rapports de revenus. Les équipes commerciales sont rémunérées pour convaincre les prospects qu’il vaut la peine d’acheter. Les chefs de produit peuvent affirmer que les éléments de la feuille de route amélioreront les taux de renouvellement ou généreront de nouvelles offres. Les équipes de développement peuvent fièrement indiquer les prix ou le nombre de clients. Nous pouvons avoir des discussions commerciales frénétiques sur où investir. («Nos entretiens de validation suggèrent que nous pourrions vendre 20 à 25 millions de dollars supplémentaires si nous livrons cette intégration SAP / Hana. Le coût probable est de 2 à 3 millions de dollars, donc un retour sur investissement de 7 à 12 fois. »)

Implication: rendre le logiciel gratuit le dévalue pour nous comme pour nos clients. Nous y penserons toujours comme une dépense plutôt que comme une opportunité pour un avantage stratégique.


Octet sonore

Le matériel industriel et les logiciels d’entreprise peuvent tous deux être de bonnes affaires. Mais ils fonctionnent très différemment – leurs modèles économiques et de développement et la tenue des scores sont en opposition directe. Les équipes de direction doivent donc réorganiser certains de leurs processus opérationnels ainsi que leurs hypothèses fondamentales sur la façon dont nous gérons avec succès des produits rentables.





Source

  • Partager cet article

Laisser un commentaire