In his blog post about customer centricity Ivor Macfarlane attempts to pinpoint the common problems why service integrations fail. The problem is, as with any business transaction - how do we give customers the solution that they need?
The solution is seemingly quite simple - the customers need to be involved and listened to when their project is tailored. This is of course easier said than done and Ivor points out numerous pitfalls explaining why so many integration projects fail.
The root of the problem is that an integration project contains multiple parties with different tools and processes. Speaking from my own experience as a developer - some problems does surface no matter the people who are involved or what project the integration is part of. Different systems have different data structures and processes. Even the same exact concept usually goes by different names in separate systems.
The mapping of these structures and processes has to be resolved by keeping workshops and meetings. Initial understanding from these meetings is then used as a base when incrementally implementing the integration interfaces, until the full implementation is verified with the customer(s).
Mapping the data is where integrations usually fail, which is commonly the main task of the integration. The problems have I personally fought with can be summarized with:
- Wrong data is integrated
- Concepts are mapped in incorrect ways
- Concept mismatch due to different processes
Getting these problems are essentially what service integration is all about, mapping data and processes - So that the service users can ignore the underlying IT solutions.
This is the customer centric conundrum that Ivor Macfarlane wrote about. The problem of mapping the service vendors’ data with the customers’ data is of course what all integrations boil down to, therefore it cannot be avoided, but what we can do is change how it is done.
With Service-Flow the IT integration can be separated from the actual business processes. The customers are empowered to map the data and processes in the Service-Flow tool, focusing on processes rather than implementation. The only thing needed is that both customer and vendor connect their existing interfaces towards Service-Flow once and it will be reusable for all future integrations.
Integrations done the Service-Flow way is letting the respective systems' IT professionals do what they know best - integrate to us on their terms by simply exposing the existing processes.
We transform their respective data structures and let the customers define rules of the integration based on their actual needs. All integrated parties can keep their own tools and standard interfaces. So that you can focus on what matters!