Practice analysis · Automation
Variant: this RPA case is really about connecting systems intelligently
The public Variant case describes employees moving data between very different applications. The transferable lesson is not “put a bot everywhere”; it is to choose the best available interface per system and automate the chain in a governable way.
Variant was automation-ready because the problem was concrete, recurring and digital, while several systems already exposed databases, web services or APIs. RPA was part of a broader integration approach, not the objective itself.
What the public case actually states
- The public case describes several heterogeneous applications including Firebase, Exact OnPremise/MSSQL, web services and a mobile/web application using REST APIs.
- Employees frequently had to print or copy information from one system and enter it into another.
- The case reports a 100% reduction in manual errors and a 75% reduction in scheduling errors.
- Automate was used across planning, finance, IT, HR and customer support and worked with databases, web services/OData, REST/JSON, CSV and XML/XSLT.
The problem was system friction, not “too few robots”
Variant is useful because the classic image of RPA as a screen-clicking robot is incomplete here. The original pain was information being moved manually between heterogeneous systems. That makes this primarily an integration and orchestration problem.
- Several applications needed data from one another.
- Databases, web services and REST APIs were available.
- Manual re-keying created time loss and errors.
- The need existed across several departments, increasing the value of reuse.
Why a hybrid automation layer was logical
| Available interface | Logical first route |
|---|---|
| MSSQL/database | Direct database connector or governed data layer. |
| REST API / JSON | API integration where the interface is stable and supported. |
| Web services / OData | System integration through existing services. |
| CSV/XML | Controlled file/data-processing workflow. |
| No usable interface | RPA/UI automation as a bridge where needed. |
The case supports a core Boermans rule: RPA is not automatically the first choice. Use the best available interface for each step and orchestrate the chain as a whole.
Why this kind of manual work is often a good first candidate
- The work is recurring and digital.
- Source and destination can be identified.
- The failure mechanism — manual re-keying — is concrete.
- Existing systems do not have to be replaced immediately.
- Value can be measured through errors, lead time and handling time.
What should not be generalised
- That every manual error can be eliminated completely.
- That the reported 100% and 75% reductions transfer to another organisation.
- That one technology is best for every interface in your landscape.
- That a missing native connector automatically means RPA is required.
- The implementation cost, payback period or operating effort in this case.
Sources and strength of evidence
The facts below come from the listed public source. The surrounding analysis is by Boermans Digital.
Boundary: The results are published in a Korper/Fortra customer case. Boermans Digital does not present Variant as its own client and uses the source solely to analyse process and architecture choices.