Core activiteiten versterken met innovators en API’s.

Een van de manieren voor corporates om te innoveren met Startups is het openstellen van core assets en capabilities voor developers / Startups. Dit past dit uitstekend in de drive van grotere ondernemingen om zicht te richten op core activiteiten, terwijl de noodzakelijk innovaties toch dichtbij plaats vinden. Vrijwel altijd wordt dit gedaan met API’s.

De bedrijfsfuncties die sterk gerelateerd zijn aan de bedrijfsstrategie worden ook wel de core activiteiten genoemd, met natuurlijk de bijbehorende assets en middelen. Deze zijn iha direct verbonden met het toevoegen van waarde voor de klanten. De meeste bedrijven hebben zo’n 3 tot 5 core activiteiten en de uitdaging is vaak hoe deze in waarde toe te laten nemen. Dat gebeurt in ieder geval door eigen innovaties en ook het steeds efficienter inrichten daarvan. In steeds meer sectoren zijn de innovaties niet meer bij te houden met eigen innovaties. In dat soort gevallen is het verstandig om te zoeken naar mogelijkheden om hierbij toch aan te sluiten. Het gecontroleerd open stellen van de eigen core activiteiten aan externe innovators is daarbij een van de mogelijkheden. Hierbij is het van belang om te realiseren dat slechts een klein gedeelte van innovaties succesvol zal zijn. Het is nl zo dat de kans op success zo’n 10-20% is als het aantal “pogingen” echt groot is; dus niet 10 innovatie pogingen, maar meer in de richting van tientallen. Daarom is het verstandig een standaard interface op de core activiteiten te realiseren om zo veel mogelijk innovators te kunnen bedienen. Als distributie een van de core activiteiten is, dan is een standaard intake en integratie proces vaak een goede oplossen. En als het gaat om een technisch platform, dan liggen API’s (Application Programming Interface) voor de hand. Er zijn overigens ook niet technische core activiteiten die door IT ondersteund worden die ook door API’s beschikbaar gemaakt kunnen worden.

Een voordeel van deze aanpak is ook dat er meer aandacht komt voor de echte core activiteiten. Doordat er hierdoor meer van buiten naar de core activiteiten gekeken wordt, ontstaat er een objectiever beeld over de kwaliteit en dus een drive om deze activiteiten beter te doen.

De meest schaalbare manier om core activiteiten beschikbaar te stellen, is door ze via API’s (Application Programming Interfaces) beschikbaar te maken. API’s kunnen kortweg beschouwd worden als de lijm tussen twee stukken software, waarmee ze elkaar beïnvloeden. Een mooi voorbeeld van een API is de Google Maps API, waarmee iedereen Goolge maps op z’n eigen manier kan inzetten, bv door het plaatsen van pinnetjes op de kaart of het aanbieden van route informatie tot je eigen locatie.

Ik gebruik regelmatig het fictieve voorbeeld van een supermarkt. Je zou kunnen stellen dat een supermarkt logistiek, schapruimte en kassa / balie diensten als core activiteiten heeft.

Één van de innovatie mogelijkheden is het open te stellen van de kassa / balie diensten voor innovators. Hierbij zouden bv innovators in de deel economie het tijd / plaats probleem kunnen oplossen. Zou zou een partij als marktplaats een optie kunnen bieden om het bekijken en afrekening in de supermarkt plaats kunnen laten vinden. Strikt genomen zou er ook gefocussed kunnen worden op een rechtstreekse deal met één of meer partners, maar dat vereist vrij intensief partner-management met nog steeds beperkte zekerheid op succes. Door het onder gestandaardiseerde voorwaarden open stellen van de balie dienst, kunnen veel meer innovators hiermee aan de slag, waardoor de kans op succes, zoals eerder beschreven, toeneemt. De beste manier de innovaties mogelijk te maken is het standaardiseren van de interfaces, zowel contractueel als technisch (met API’s).

Doordat andere partijen op de core activiteiten innoveren, worden deze sowieso relevanter, waardevoller en wordt er ook loyaliteit gecreëerd. In vrijwel alle gevallen is die niet voldoende om de kosten die gemaakt worden te rechtvaardigen. Bij het kwantificeren van de waarde of het genereren van verdien modellen, zijn er de volgende mogelijkheden:

• Promotionele waarde; voor de partijen die voorlopers zijn in het openstellen van hun core assets, is het relatief eenvoudig om hiermee in de pers te komen.
• Transaction revenue; het is mogelijk om per transactie (mn API aanroep) een kleine vergoeding te vragen. Dit kan direct, in staffels, maar ook in een freemium model. De Google Maps API is een goed voorbeeld van dat laatste. Iedereen kan de API’s gebruiken, maar als het volume van de aanroepen een bepaalde waarde overstijgt, moet er een vergoeding betaald worden.
• Future revenue; door het monitoren van het gebruik, kan achterhaald worden welke toepassingen het meest succesvol zijn. Deze informatie kan gebruikt worden voor het ontwikkelen van eigen nieuwe diensten, maar het is ook mogelijk om de waardevolste oplossingen op te nemen in het eigen portfolio. Daarnaast is het natuurlijk ook mogelijk om in de succesvolste innovators te investeren voor toekomstige omzet.
• Revenue share; in een aantal gevallen is het praktisch mogelijk om te delen in de omzet van de innovator. In het voorbeeld van de supermarkt is dit mogelijk door een deel van de transactie waarde te nemen. Er moet hierbij wel goed gekeken worden naar de schaalbaarheid van het model, waarbij de focus zou moeten zijn dat het te standariseren is.
• Interne efficiency; doordat de API’s extern aangeboden worden, ontstaat er ook de mogelijkheid om dit intern ook te gebruiken. In veel gevallen is de interne wens tot standarisatie er wel, maar lukt het onvoldoende. Er is een geval bekend waarbij 60% van de (externe bedoelde) transacties intern gegenereerd werd.

Deze mogelijkheden zijn natuurlijk allemaal erg mooi, maar ook weinig voorspelbaar en de voordelen komen meestal pas op de middellange termijn. Daarom is het ook van belang om de kosten hiervan onder controle te houden.

Het is altijd aan te raden om de interne systemen via een tussenliggend systeem aan de buitenwereld beschikbaar te stellen. Dit soort API platformen zorgen voor een verschillende soorten beveiligingen. Natuurlijk voor de logische afscherming van de interne systemen, maar ze kunnen ook het aantal transacties beperken, zodat de belasting van de systemen beperkt blijkt. Daarnaast zorgen API platformen vaak ook voor monitoring, rapportage, accounting (om transacties in rekening te kunnen brengen) en tooling om innovators goed te kunnen ondersteunen.

Er zijn er behoorlijk wat API management systemen, varieerend van omvangrijk en ondersteund door grote ondernemingen tot Open Source oplossingen.

• WSO2 API Manager (Open Source); http://wso2.com/products/api-manager/
• APIgee; http://apigee.com/about/
• Layer7; http://www.layer7tech.com/
• SOA Software; http://www.soa.com/
• Intel Mashery; http://www.mashery.com/
• 3Scale; http://www.3scale.net/
• Apiary.io; http://apiary.io/
• WebServius; http://www.webservius.com/
• Axway; http://www.axway.com/
• The Social Foundry; http://www.thesocialfoundry.com/
• Neosesame; http://neosesame.com/
• Windows Azure; http://azure.microsoft.com/nl-nl/
• apiGrove; http://apigrove.net/
• StrikeIron; http://www.strikeiron.com/about-the-ironcloud-platform/
• MuleSoft; https://www.mulesoft.com/platform/api/manager

Het lijkt recht-toe-recht-aan om core activiteiten open te stellen aan innovators dmv API’s maar dit vereist eigenlijk altijd leiderschap in een organisatie. Vooral ook omdat naast de benoemde voordelen, de kannibalisatie op bestaande diensten op kan treden; dit argument zal in ieder geval zeer veel gebruikt worden.

Daarom moet ook eigenlijk een API programma afgewogen worden tov ander manieren om met innovators samen te werken. Om hierin de juiste keuze te maken heb ik de Externe Innovatie Scan ontwikkeld, waarbij in een korte periode een strategie bepaald wordt maximaal gebruik te maken van innovaties van anderen zoals startups.

Vragen? neemt contact  op of zet ze in de comments