Y a-t-il de la place pour les produits API dans votre modèle commercial ?

Ces points communs m'ont incité à présenter quelques exemples sur la manière de penser différemment à la fois en ce qui concerne vos API et vos produits. Certains de mes clients récents provenaient de secteurs industriels ou d'autres secteurs « matériels », où ils produisent et vendent généralement des produits physiques. Mes exemples sont donc tirés du monde des alarmes incendie, mais peut être appliqué à presque tous les secteurs d'activité proposant des produits ou des services autres que des logiciels ou des API.

Vendons-nous des produits d'alarme incendie ou des produits API ?

Depuis le stratégie de produit D'un point de vue, il est généralement judicieux de séparer le « produit matériel », comme les alarmes incendie, par exemple, et les décisions relatives aux produits API.

• Un produit matériel peut inclure de nombreux produits API.
• Un produit API peut être utilisé avec de nombreux produits matériels, en fonction de la proposition de valeur.
  

Récemment, un client d'une grande entreprise mondiale de produits matériels m'a posé une très bonne question après une conversation sur deux sujets. Tout d'abord, le différences entre les produits API entre les segments de partenaires. En second lieu, comprendre les parcours des partenaires ainsi que leurs besoins commerciaux et opérationnels.

Le client a ensuite posé une question.

« Mais quelle est la différence entre ces segments du point de vue de l'API si nous avons toujours le même produit physique ? »

Excellente question, à laquelle il n'y a pas nécessairement de réponse claire.

Découvrez le monde des systèmes d'alarme incendie pour trouver des réponses aux questions précédentes. Les alarmes incendie peuvent être installées dans des appartements individuels, des immeubles d'habitation, des bâtiments commerciaux et certaines installations critiques telles que les hôpitaux ou les centres de données. Ce sont tous des exemples de segments de clientèle. Les entreprises qui gèrent ces installations ne font qu'une segment des partenaires. Les entreprises d'installation et de maintenance sont des exemples d'autres segments de partenaires.

Quelle différence font vos partenaires pour vos produits API ?

Des différences peuvent être observées dans de nombreux domaines liés au modèle commercial ainsi qu'à la création et à la gestion de produits API. J'utilise le terme productifiant ou plus académiquement productisation*) d'API. J'utilise ce terme pour décrire le fait de prendre quelque chose d'abstrait, comme une API, et d'y appliquer les principes du produit. Cela ne signifie pas qu'un produit API est commercialisé auprès du grand public ou même en dehors de l'entreprise. Néanmoins, des principes similaires s'appliquent.

Investopedia définit la productisation comme « le processus de développement ou de modification d'un processus, d'une idée, d'une compétence ou d'un service pour le rendre commercialisable auprès du public ». La définition se poursuit ainsi : « La production implique de transformer une compétence ou un service utilisé en interne en un produit standard, entièrement testé, emballé et commercialisé. » 

Les architectes d'entreprise aiment utiliser le mot capacité pour décrire ce type de « compétence ou service » technique, dans notre cas l'API. Le terme productisation est lié au terme servitisation. Dans le secteur des produits manufacturiers, la tendance à « servir » le produit existe depuis de nombreuses années pour rester sur le marché. Cela signifie que des services supplémentaires ont été conçus pour soutenir, par exemple, les ventes de machines (le produit principal).

Le but de la productisation et de la servitisation est de étendre l'offre initiale et pour le rendre plus concret. Comme tout service, les API sont très « intangibles » si la productisation n'est pas appliquée. Ni votre propre organisation ni vos futurs utilisateurs d'API ne sauront à quoi les utiliser, comment les utiliser, où les trouver, etc. J'ai l'impression que l'emballage du produit est manquant.

Quelles sont les différences entre les différents segments de partenaires en matière de produits API ?

Chaque segment de partenaires ou segment de consommateurs d'API a un impact sur vos décisions en matière de produits API. Il s'agit notamment de l' « emballage » : Conception d'API, niveaux de service et autres termes, stratégies de tarification et modèles de déploiement pour n'en nommer que quelques-uns.

Prenons un exemple qui intéresse les clients de l'API un seul immeuble d'appartements.

Les segments de consommateurs ou de partenaires d'API ici pourraient être les propriétaires du bâtiment ou l'entreprise de maintenance. Lorsqu'il s'agit d'un seul bâtiment, l'API peut être assez simple. L'API est conçue pour être très facile à authentifier et avec un modèle de données simple.

Il est important de faire preuve d'empathie à l'égard des consommateurs d'API du segment. La conception d'une API doit refléter le niveau d'expertise et les besoins du consommateur de l'API (utilisateur et application). Dans ce cas, l'utilisation des API serait une simple intégration avec un budget minimal et une expérience des API. Par conséquent, une conception d'API simple est très utile.

En règle générale, les utilisateurs de ce segment n'utiliseraient jamais l'API directement, mais via un système de maintenance des bâtiments. Ce type de système pourrait avoir une intégration prête à l'emploi au système d'alarme incendie via une API.

Du point de vue de la monétisation des API, le modèle serait indirecte. La société de maintenance paierait pour l'utilisation de l'API sans même nécessairement le savoir. L'utilisation de l'API serait payée dans le cadre des frais mensuels ou annuels du logiciel. Il s'agit d'un exemple de modèle de revenus indirects du point de vue de l'entreprise de maintenance et du fournisseur du système.

Dans ce cas, les propriétaires du bâtiment ou les entreprises de maintenance sont très probablement les acheteurs du produits d'alarme incendie, pas directement les API.

Qu'est-ce qui serait inclus dans le package pour les entreprises de maintenance ?

Il existe au moins trois options d'emballage différentes :

1) dispositifs d'alarme incendie,

2) dispositifs d'alarme incendie avec la propre application du fournisseur ou

3) intégration au système de maintenance en tant que service supplémentaire.

Souvenez-vous que nous ne parlions que de l'affaire d'un seul immeuble d'appartements. Et si c'est la même entreprise qui gère plusieurs bâtiments? Et si certains d'entre eux étaient immeubles d'habitation et autres bâtiments commerciaux ou de haute sécurité?

Dans ces cas, l'entreprise devrait faire face à de nombreux systèmes d'alarme incendie et à de nombreux locataires différents. Même s'ils faisaient appel à un seul fournisseur de systèmes d'alarme incendie, il pourrait y avoir des gammes de produits distinctes ou des fonctionnalités supplémentaires pour chaque segment. Les entreprises de maintenance souhaiteraient très probablement utilisez directement l'API, au lieu d'utiliser le système propriétaire du fabricant de l'alarme incendie ou une intégration fournie par un fournisseur du système. Ils peuvent avoir un partenaire d'intégration dédié.

Pourquoi une API ne suffirait-elle pas ?

Sans aucun doute, le La conception des API devrait être plus complexe lors de la gestion de plusieurs bâtiments et parties prenantes. Il devrait inclure davantage de types de bâtiments et des installations d'alarme incendie plus complexes. Cela nécessiterait un contrôle d'accès plus précis. Du point de vue de la stratégie produit, faut-il bien réfléchir si toutes ces fonctionnalités doivent être utilisées simultanément ? Ou y a-t-il un risque encore plus grand dans ce cas ?

Un élément à prendre en compte lors de l'élaboration des scénarios :

• Il est possible que les entreprises, les systèmes et les cas d'utilisation utilisés pour gérer tous les types de bâtiments et les produits d'alarme incendie n'existent jamais dans le portefeuille de systèmes et de services de la même entreprise. Cela signifie que des API distinctes pour chaque segment pourraient simplifier considérablement la conception de l'API et l'expérience utilisateur des API.
• Il est également possible pour un système pour utiliser plusieurs API pour couvrir plusieurs propositions de valeur si nécessaire.
• Dans certains scénarios et avec une planification méticuleuse il peut être possible d'obtenir une conception simple et une API même dans un cas d'utilisation complexe. Cela nécessite généralement de simplifier de nombreuses structures internes et d'ajouter une couche d'orchestration intelligente en tant qu'API de premier niveau.

Des API dans vos canaux de marketing et d'assistance et en tant que bâtisseurs de relations

Les API peuvent être un moyen de commercialiser et de commander vos produits existants. Les API peuvent être un moyen de partager des données de vente de produits avec des partenaires. Les API peuvent créer de nouvelles propositions de valeur ou de nouvelles catégories de produits pour compléter les produits existants. Ils peuvent fournir un accès aux données d'utilisation des produits ou à d'autres fonctionnalités supplémentaires.

L'hypothèse la plus courante est souvent de gagner de l'argent, c'est-à-dire d'utiliser monétisation directe en fixant le prix de vos API. Le plus souvent, ce n'est pas le cas. Le modèles de revenus indirects et avantages peut représenter une opportunité beaucoup plus lucrative. J'ai abordé certaines des différentes manières dont les API peuvent s'adapter à votre modèle commercial et à votre stratégie de produit ou de service dans le livre « API Economy 101 » que j'ai co-écrit avec Moilanen & all (2019). Si vous voulez en savoir plus, je vous recommande de lire comment Matthias Biehl explique les différences entre monétisation directe et directe.

Les modèles de revenus indirects comportent de nombreux avantages. Il peut s'agir d'améliorer la fidélisation des clients, d'accroître la satisfaction des clients et des partenaires et d'accélérer la livraison des produits. Plus les clients peuvent co-créer des expériences en intégrant leurs propres systèmes et données dans vos produits, plus ils sont engagés.

La gestion des produits numériques réinventée : des API plutôt que des interfaces utilisateur

Le système d'alarme incendie pourrait offrir une interface utilisateur agréable, des données et des analyses pour leurs propres produits directement aux utilisateurs finaux, les gestionnaires du bâtiment. Mais ils pourraient également choisir de « sous-traiter » le problème aux fournisseurs du système de maintenance. Ce faisant, ils risqueraient également de perdre une partie de la connexion et de l'expérience client avec les utilisateurs finaux. D'autre part, ils peuvent également bénéficier de la possibilité de vendre davantage et de toucher un public plus large.

Du point de vue de la monétisation, la question de savoir si ces fournisseurs de systèmes de maintenance payent ou non pour l'utilisation de l'API. Ils s'attendent à ce que l'API réduise les coûts des fournisseurs de systèmes d'alarme incendie sans avoir à développer leur propre logiciel ou à aider les clients avec des intégrations. Ils pourraient également gagner un marché plus important. Bien entendu, il est possible que les partenaires disposent déjà de leur propre logiciel, et il peut y avoir d'autres raisons pour lesquelles votre API fait exploser le modèle commercial de vos partenaires au lieu de l'activer. Il est préférable d'essayer de trouver un scénario gagnant-gagnant, et c'est pourquoi recherche menée par des partenaires est essentiel.

Plus de clients signifie plus d'attention et d'efforts pour intégration des partenaires et gestion des partenaires. Les efforts de vente et de marketing seront différents de ceux traditionnels pour ce segment. Cela nécessite un ensemble d'outils, de ressources et de pratiques.

‍

Si vous souhaitez trouver la solution adaptée à vos API et à votre modèle économique, ou plutôt un bon modèle économique pour chacune de vos API ou catégories de produits API (!) puis essayez la solution allégée et axée sur les affaires Méthode APIOps Cycles que de nombreuses entreprises utilisent dans le cadre de leur boîte à outils et de leur modèle opérationnel. Je l'ai développé avec d'autres passionnés il y a quelques années, car il n'existait tout simplement pas de framework que les chefs d'entreprise, les chefs de produits API, les concepteurs d'API et d'API de services, les architectes d'API et les développeurs d'API seraient en mesure d'utiliser ensemble.

Voici quelques-uns des sujets que nous abordons quotidiennement avec nos clients chez Osaango et The API Collective. Les API touchant à de nombreux aspects du modèle économique, de l'architecture technique et des silos organisationnels, les humains qui les sous-tendent peuvent parfois se retrouver perdus dans un océan d'opportunités et de parties prenantes. Je recommande de lire Chez Claire Barrett publiez un article expliquant comment trouver les décideurs et obtenir le financement et le soutien de vos produits et programmes d'API. Il ne s'agira pas simplement de changements techniques, vous devez donner du pouvoir à de nombreuses personnes pour que le changement organisationnel se produise.

*) Quelques explications sur le choix des termes académiques difficiles. Les termes productisation et servitisation ont tous deux des origines et des traditions de recherche finlandaises (comme moi) très fermes. Je recommande par exemple de lire davantage dans la section »API Economy 101" -livre (divulgation : je suis l'un des coauteurs) ou par exemple cette recherche Simula, H., Lehtimäki, T., & Salo, J. (juin 2008). Repenser le produit : passer d'une technologie innovante à une offre produite. Dans Actes de la 19e conférence de la Société internationale pour la gestion professionnelle de l'innovation, Tours, France (p. 15-18).

Les trois bases pour gagner de l'argent grâce aux API

Gagner de l'argent grâce aux API est souvent ambitieux et peut être difficile à réaliser dans la pratique sans : (1) le bon modèle commercial, (2) un modèle approprié de monétisation des API et (3) le soutien de l'organisation. Dans cette série d'articles, nous explorons ces fondements plus en détail.

1. Marjukka montre comment sélectionner le bon modèle commercial dans Y a-t-il de la place pour les produits API dans votre modèle commercial ?
2. Matthias montre 5 modèles simples à suivre pour gagner de l'argent grâce aux API qui vont au-delà de la monétisation directe des API.
3. Claire discute de certains des défis auxquels sont confrontées les organisations traditionnelles avec s'engager en faveur d'API produites et comment les contourner.

‍