We are more interconnected and interdependent than ever before. In the search for quality and efficiency, businesses are sharing data and capabilities to ensure they can provide competitive, relevant services to their markets. In our research we see examples large and small, particularly in manufacturing, but also in retail, finance, oil and gas – the list goes on.
Whilst attention is often focused on B2C applications, providing information and greater value directly to the consumer, it is in the B2B arena that the rubber really hits the road.
The Need for Connectivity
Geopolitical crises along with a pandemic that has changed the way we live and work since early 2020 have pushed business resilience to the fore – when supply chains are challenged and demand is changing, how do we ensure we can meet the needs of our customers as well as keep our businesses trading profitably and sustainably?
Closer B2B integration has allowed partners to quickly identify, understand, and respond to changing customer and market requirements. Increasing supply chain visibility has helped to ensure ongoing order fulfilment, visibility, and transparency across supply chain networks.
Transparency into means of available transport, close monitoring of the supplier network, and supplier risk assessment tools have been proven to help reduce risk of disruption.
Beyond the fundamental issue of resilience, highly connected supply chains have delivered greater efficiency and service levels by sharing live data on availability, lead times, delays etc whilst combining their data to measure their customer satisfaction and engagement to predict demand more effectively and get as much notice as possible when this changes. Customer service has always been a differentiator, and by working with customers to provide them the data they need to make the right calls, we can make it easy for them to do business with us.
In the past we have made efforts to do this for the biggest-ticket items where the cost of moving the data between organisations is justified by the outcome, but today we are in what is known as the “API Economy”, where business models are increasingly based on the data and capabilities we expose to our partners via the internet.
An application programming interface, or API, is a set of rules that enables data extraction from software to be used in another application. APIs allow for seamless, rapid integration, and they’re valuable for software development.
An Example From Government
APIs are nothing new, but their use is increasing all the time as tools for internal and external partners to build their knowledge and planning systems using source data from various stakeholders’ APIs. An example of a very simple API would be to verify a VAT (Value Added Tax, or Sales Tax) number – the UK government provides an open API so that any software can quickly submit a VAT number to check that it is valid and verify the name and address that it is registered to.
You can see how useful this would be for a billing system when entering the details of a new customer, to ensure data quality and prevent fraud. This service is valuable to the tax office, because it encourages better quality submissions.
This makes the creation of this service a win-win for both the government and their stakeholders.
The questions for CIOs include if and how to implement these tools, how to choose which external APIs to build software for, and how to manage the risks of opening these windows to your systems. Implementation is most often based on return on investment.
For example, what is the cost to develop, run and maintain an API, since they are systems exposed to the world that will require support just like any other. Then we consider the impact of the API, for example in the VAT case, how many submission errors will it remove and how much time/effort will be saved.
For some APIs there is a charge for their use and the monetisation of these services can also be part of the equation. Through careful management and close collaboration with ecosystem partners the case for development can be well established.
When you publish APIs that others rely on you must also publish roadmaps and documentation so that your stakeholders can trust your commitment to the service. Thousands of companies provide details like this and can often be found with a quick internet search. As an example, take the white goods manufacturer Miele.
How Much Can We Rely on Others?
The other side of this coin is the risk of dependence on external services. If my system uses the HMRC VAT API to check any new customer, but the API stops working for some reason at the HMRC side, what happens?
If my system can’t register new customers, this is a risk that I might not be able to justify. Every use of an external API creates a dependence that we must document and mitigate.
Governance and review remain critical in the management of these tools, and proper due diligence done on the provider of the API. Do they have a product manager for APIs, what is the roadmap, will features be added or (worse) change?
There are many practical things to consider along with the benefits of closer integration.
We should take this evolution of business interaction seriously, and consider our position in the ecosystem – do our customers expect us to be providing these services, will our competitors be building the capability, is there potential for collaboration to standardise the interfaces and reduce the development costs?
Sometimes these are competitive advantages and sometimes they are just table stakes. If it’s the latter, perhaps co-opetition is an option. Can we help our suppliers to cut their costs by providing or utilising information more quickly, and if so, how do we initiate that discussion?
This is the start of a much longer conversation, and if you’d like to join in and find how others are approaching this issue, please join us at the IDC Digital Leaders Community discussion on Thursday 26th May, 16:00 UK / 17:00 CEST. Please email Marc Dowd mdowd@idc.com.