Onko liiketoimintamallissasi tilaa API-tuotteille?

Nämä yhteiset linjaukset inspiroivat minua avaamaan esimerkkejä siitä, kuinka voit ajatella eri tavalla sekä ohjelmointirajapinnoistasi (API) että tuotteistasi. Osa viimeaikaisista asiakkaistani ovat olleet teollisilta tai muilta "laitteistosegmenteiltä", joissa he tyypillisesti valmistavat ja myyvät fyysisiä tuotteita. Esimerkkini ovat siis palohälyttimien maailmasta, mutta niitä voidaan soveltaa lähes kaikilla toimialoilla, joilla on muita tuotteita tai palveluita kuin ohjelmistoja tai ohjelmistorajapintoja (API).

Myymmekö palohälytystuotteita vai API-tuotteita?

Tuotestrategian näkökulmasta katsottuna palohälyttimien kaltaiset "laitteistotuotteet" ja API-tuotepäätökset kannattaa pitää erillään.

Yksi laitteistotuote voi sisältää useita API-tuotteita. Yhtä API-tuotetta voidaan käyttää useiden laitteistotuotteiden kanssa arvolupauksesta riippuen.Erään suuren maailmanlaajuisen laitteistotuoteyrityksen asiakas kysyi minulta hiljattain erittäin hyvän kysymyksen kahdesta aiheesta käydyn keskustelun jälkeen. Ensimmäinen aihe oli API-tuotteiden erot kumppanisegmenttien välillä . Toinen aihe liittyi kumppaneiden kokemusten ja heidän liiketoiminnallisten ja toiminnallisten tarpeidensa ymmärtämiseen.

Sitten asiakas esitti kysymyksen.

"Mutta mitä eroa näiden segmenttien välillä on APIn näkökulmasta, jos meillä on edelleen sama fyysinen tuote?"

Erinomainen kysymys, johon ei välttämättä ole yksiselitteistä vastausta.

Otetaan esimerkiksi palohälytysjärjestelmien maailma, niin voimme löytää vastauksia näihin kysymyksiin. Palovaroitin voidaan asentaa yksittäisiin asuntoihin, kerrostaloihin, liikerakennuksiin ja joihinkin kriittisiin tiloihin, kuten sairaaloihin tai datakeskuksiin. Nämä ovat kaikki esimerkkejä asiakassegmenteistä. Näitä tiloja hallinnoivat yritykset ovat yksi kumppanisegmentti. Asennus- ja huoltoyritykset ovat esimerkkejä muista kumppanisegmenteistä.

Mitä eroa kumppaneillasi on API-tuotteisiisi?

Eroja on havaittavissa monilla aloilla, jotka liittyvät liiketoimintamalliin sekä API-tuotteiden luomiseen ja hallinnointiin. Käytän termiä ohjelmistorajapintojen (API) tuotteistaminen tai akateemisesti ilmaistuna tuotteistaminen*). Käytän tätä termiä kuvaamaan jotain abstraktia, kuten ohjelmointirajapintaa, ja tapaa, jolla tuoteperiaatteita voidaan soveltaa siihen. Tämä ei tarkoita sitä, että API-tuotetta markkinoidaan suurelle yleisölle tai edes yrityksen ulkopuolelle. Samanlaiset periaatteet pätevät kuitenkin myös tässä tilanteessa.

Investopedia määrittelee tuotteistamisen seuraavasti: "prosessi, jossa kehitetään tai muutetaan prosessia, ideaa, taitoa tai palvelua, jotta se voidaan markkinoida myytäväksi yleisölle". Määritelmä jatkuu: "Tuotteistaminen tarkoittaa sitä, että sisäisesti käytetty taito kehitetään standardituotteeksi, täysin testatuksi, pakatuksi ja markkinoitavaksi tuotteeksi."

Yritysarkkitehdit käyttävät mielellään sanaa 'kyky' kuvaamaan tällaista teknistä "taitoa tai palvelua", meidän tapauksessamme ohjelmointirajapintoja (API). Termi 'tuotteistaminen' liittyy termiin 'palvelullistaminen'. Tuotantoliiketoiminnassa tuotteen "palvelullistamiseen" liittyvä trendi on ollut olemassa jo monta vuotta, ja sen tavoitteena on ollut pitää tuote markkinoilla. Tämä tarkoittaa, että lisäpalvelut on suunniteltu tukemaan esimerkiksi koneiden (ydintuotteen) myyntiä.

Sekä tuotteistamisen että palvelullistamisen tarkoitus on laajentaa alkuperäistä tarjontaa ja tehdä siitä konkreettisempaa. Muiden palveluiden tapaan APIt ovat hyvin "aineettomia", jos tuotteistamista ei sovelleta. Oma organisaatiosi tai tulevat API-kuluttajasi eivät tiedä, mihin niitä käytetään, miten niitä käytetään, mistä ne löytyvät jne. Tuntuu siltä, että tuotteen pakkaus puuttuu.

Entä API-tuotteiden erot kumppanisegmenttien välillä?

Jokainen kumppanisegmentti tai API-kuluttajasegmentti vaikuttaa API-tuotepäätöksiisi. Näihin kuuluvat "pakkaukset": API-suunnittelu, palvelutasot ja muut ehdot, hinnoittelustrategiat ja käyttöönottomallit, muutamia mainitakseni.

Otetaan esimerkki, jossa API-asiakkaat ovat kiinnostuneita yhdestä kerrostalosta.

API-kuluttajien tai kumppaneiden segmentit voivat tässä tapauksessa olla rakennuksen omistajat tai huoltoyhtiö. Kun kyseessä on yksittäinen rakennus, API voi olla melko yksinkertainen. API on suunniteltu erittäin helposti todennettavaksi, ja tietomalli on yksinkertainen.

Segmentin API-kuluttajien ymmärtäminen on tärkeää. API-suunnittelun on heijastettava API-kuluttajan (käyttäjän ja sovelluksen) asiantuntemuksen tasoa ja tarpeita. Tässä tapauksessa ohjelmistorajapintojen (API) käyttö tarkoittaisi yksinkertaista integrointia minimaalisella budjetilla ja API-kokemuksella. Siksi yksinkertaisella API-suunnittelulla pääsee pitkälle.

Tyypillisesti tämän segmentin käyttäjät eivät koskaan käyttäisi APIa suoraan, vaan rakennuksen ylläpitojärjestelmän kautta. Tämän tyyppisessä järjestelmässä voisi olla valmiina integrointi palohälytysjärjestelmään APIn kautta.

API-kaupallistamisen kannalta malli olisi epäsuora. Huoltoyhtiö maksaisi APIn käytöstä ilman, vaikkei välttämättä edes tietäisi siitä. API-käyttö maksettaisiin osana ohjelmiston kuukausi- tai vuosimaksuja. Tämä on esimerkki epäsuorasta tulomallista huoltoyhtiön ja järjestelmän tarjoajan näkökulmasta.

Tässä tapauksessa rakennuksen omistajat tai kunnossapitoyritykset ovat todennäköisesti palohälytystuotteiden ostajia, eivätkä suoraan ohjelmointirajapintoja.

Mitä huoltoyhtiöiden pakettiin sisältyy?

Pakkausvaihtoehtoja on vähintään kolme:

1. palohälytyslaitteet,
2. palohälytyslaitteet myyjän omalla sovelluksella tai
3. integrointi huoltojärjestelmään lisäpalveluna.

Muista, että puhuimme vain yhdestä kerrostalosta. Entä jos sama yritys hallinnoi useita rakennuksia? Entä jos jotkut niistä olisivat kerrostaloja ja toiset kaupallisia tai korkean turvallisuuden rakennuksia?

Näissä tapauksissa yrityksen olisi käsiteltävä monia erilaisia palohälytysjärjestelmiä ja vuokralaisia. Vaikka he käyttäisivät yhtä palohälytystoimittajaa, kullekin segmentille voi olla erilliset tuotelinjat tai lisäominaisuudet. Huoltoyhtiöt haluaisivat todennäköisesti käyttää APIa suoraan sen sijaan, että käytettäisiin palohälytysvalmistajan omaa järjestelmää tai järjestelmän toimittajan tarjoamaa integrointia. Heillä voi olla oma integraatiokumppaninsa.

Miksi yksi API ei riitä?

API suunnittelu on varmasti monimutkaisempaa hallinnoitaessa useita rakennuksia ja sidosryhmiä. Siihen olisi sisällytettävä enemmän rakennustyyppejä ja monimutkaisempia palohälytysasetuksia. Se edellyttäisi hienojakoisempaa kulunvalvontaa. Tuotestrategian näkökulmasta on harkittava huolellisesti, onko kaikkia näitä ominaisuuksia koskaan tarvetta käyttää samanaikaisesti? Vai liittyykö siihen vielä suurempi riski?  

Skenaarioita kartoitettaessa on otettava huomioon seuraavat seikat:

• On mahdollista, että kaikkien rakennustyyppien ja palohälytystuotteiden hallintaan käytettyjä yrityksiä, järjestelmiä ja käyttötapauksia ei koskaan olisi saman yrityksen järjestelmä- ja palveluportfoliossa. Tämä tarkoittaa, että kunkin segmentin erilliset ohjelmointirajapinnat voisivat tehdä APIen suunnittelusta ja hyödyntämisestä paljon yksinkertaisempaa.
• Yksi järjestelmä voi myös käyttää useita ohjelmointirajapintoja kattamaan tarvittaessa useita arvolupauksia.
• Huolellisella suunnittelulla voi olla mahdollista päästä yksinkertaiseen API designiin jopa monimutkaisessa käyttötapauksessa. Tämä edellyttää yleensä monien sisäisten rakenteiden yksinkertaistamista ja älykkään orkestrointikerroksen lisäämistä ensimmäiseksi APIn uloimmalle kerrokselle.

APIt markkinointi- ja tukikanavissasi sekä suhteiden rakentajina

APIt voivat olla kanava olemassa olevien tuotteiden markkinoinniin ja tilaamiseen. APIt voivat olla tapa jakaa tuotteiden myyntitietoja kumppaneiden kanssa. APIt voivat luoda uusia arvolupauksia tai uusia tuotekategorioita olemassa olevien tuotteiden täydentämiseksi. Ne voivat tarjota pääsyn tuotteen käyttötietoihin tai muihin lisäominaisuuksiin.  

Yleisin oletus on usein ansaita rahaa eli käyttää suoria ansaintamalleja hinnoittelemalla APIt. Useimmiten näin ei ole. Epäsuorat ansaintamallit ja hyödyt voivat olla paljon tuottoisampi mahdollisuus. Olen käsitellyt kirjassa "API-talous 101" (Moilanen, Niinioja, Seppänen, Honkane  2019) muutamia erilaisia tapoja, joilla ohjelmointirajapinnat sopivat liiketoimintamalliisi ja tuote- tai palvelustrategiaasi. Jos haluat oppia lisää, suosittelen lukemaan, miten Matthias Biehl selittää epäsuorien ja suorien ansaintamallien väliset erot.

Epäsuorat ansaintamallit sisältävät monia etuja. Näitä voidaan parantaa asiakkaiden pysyvyyttä, lisätä asiakas- ja kumppanityytyväisyyttä ja nopeuttaa tuotteiden toimitusta. Mitä enemmän asiakkaat voivat luoda kokemuksia integroimalla omat järjestelmänsä ja tietonsa tuotteisiisi, sitä sitoutuneempia he ovat.

Digitaalinen tuotehallinta keksittiin uudelleen: APIt vastaan käyttöliittymät

Palohälytysjärjestelmä voisi tarjota mukavan käyttöliittymän, dataa ja analytiikkaa omille tuotteilleen suoraan loppukäyttäjille, isännöitsijöille. Mutta he voivat myös "ulkoistaa" ongelman huoltojärjestelmien tarjoajille. Näin he saattaisivat luopua myös jonkin verran yhteydenpidosta ja vaikutusvallasta asiakaskokemukseen loppukäyttäjien kanssa. Toisaalta he voivat myös hyötyä siitä, että he voivat myydä enemmän ja tavoittaa laajemman yleisön.

Kaupallistamisen kannalta kysymys siitä, maksavatko nämä huoltojärjestelmän tarjoajat APIn vai eivät. He odottavat, että API vähentää palohälytysjärjestelmän toimittajan kustannuksia ilman, että heidän tarvitsee kehittää omaa ohjelmistoaan tai tukea asiakkaita integraatioissa. Ne voisivat myös saada suuremmat markkinat. On tietenkin mahdollista, että kumppaneilla on jo oma ohjelmisto ja voi olla muitakin syitä, miksi API räjäyttää kumppaneiden liiketoimintamallin sen sijaan, että mahdollistaisi sen. On parasta yrittää löytää win-win-skenaario, ja siksi kumppanikokemuksen tutkiminen on välttämätöntä.

Mitä enemmän asiakkaita sitä ennemmän tarvitaan huomiota ja vaivannäköä kumppanien perehdyttämiseen ja kumppanien hallintaan. Myynti- ja markkinointitoimet tälle segmentille toimivat eri logiikalla kuin perinteisesti. Tämä edellyttää omia työkaluja, resursseja ja käytäntöjä.

‍

Jos haluat löytää sopivan apitasi ja liiketoimintamallisi kanssa tai pikemminkin hyvän liiketoimintamallin kullekin ohjelmointirajapinnallesi tai API tuoteluokat (!) kokeile sitten lean- ja liiketoimintalähtöistä APIOps Cycles -menetelmää , jota monet yritykset käyttävät osana työkalulaatikkoaan ja toimintamalliaan. Kehitin sen yhdessä muiden harrastajien kanssa muutama vuosi sitten, - koska ei vain ollut mitään kehystä, että yritysjohtajat, API tuotepäälliköt, palvelukokemus ja API Suunnittelijat API arkkitehdit ja API kehittäjät voisivat käyttää niitä yhdessä.

Näitä aiheita käsittelemme päivittäin asiakkaidemme kanssa Osaangossa ja "The API Collective" -yhteisössä. APIt koskettavat niin monia liiketoimintamallin, teknisen arkkitehtuurin ja organisaatiosiilojen näkökohtia, että APIen takana olevat ihmiset saattavat joskus kadota mahdollisuuksien ja sidosryhmien mereen. Suosittelen lukemaan Claire Barrettin artikkelin siitä, miten löytää päättäjät ja saada API-tuotteiden kehitysohjelmiin budjetit. Ei ole kysymys vain teknisistä muutoksista. Sinun täytyy saada aika monta ihmistä asian taakse, jotta organisaatiomuutos tapahtuu.

*) Joitakin selityksiä vaikeiden akateemisten termien valinnasta. Sekä tuotteistuksen että palvelullistamisen termeillä on erittäin vankka suomalainen alkuperä ja tutkimusperinteet. Suosittelen esimerkiksi lukemaan lisää "API Economy 101" -kirjasta (puolueettomuuden nimissä olen yksi kirjoittajista) tai esimerkiksi tästä tutkimuksesta Simula, H., Lehtimäki, T., & Salo, J. (2008, kesäkuu). Re-thinking the product: from innovative technology to productized offering. In Proceedings of the 19th international society for professional innovation management conference, Tours, France (pp. 15-18).

Kolme peruspilaria rahan ansaitsemiseen APIen avulla

Rahan ansaitseminen APIen avulla on usein toiveajattelua, ja sitä voi olla vaikea toteuttaa käytännössä ilman: 1) oikeaa liiketoimintamallia, 2) soveltuvaa ansaintamallia APIlle ja (3) tukea organisaatiolta. Tässä artikkelisarjassa tutkimme näitä perustuksia yksityiskohtaisemmin.

1. Marjukka näyttää, miten valita oikea liiketoimintamalli Onko liiketoimintamallissasi tilaa API-tuotteelle?
2. Matthias näyttää 5 helppoa epäsuoraa ansaintamallia APIen käyttöön 5 helppoa epäsuoraa ansaintamallia APIen käyttöön
3. Claire keskustelee perinteisten organisaatioiden haasteista sitoutumisen saamiseksi APIen tuotteistamiseen.

‍