+22% goods in trucks
Increase against the previous-year reference period, with route optimisation part of the wider project.
Orders get re-entered. Data gets reconciled.
One person knows which button not to press.
I find the problem behind the workaround. And fix it.
You want to keep the systems that work.
You need the work between them to work, too.
Your ERP works.
Your CRM works.
Your team makes them work together.
Manually.
Look familiar? The software is connected.
Your people are filling in the gaps.
Sales application
Order #1042Export. Check. Re-enter. Repeat.
Depends on a personERP & operations
Waiting for the handoffA simplified example of my approach: map the real process, make the rules explicit, then connect the systems.
SAP, TMS and logistics software under growing data pressure.
An architecture intervention spanning visibility, recovery and route optimisation.
Compared with a period in the previous year.
Client identity withheld.
Anonymised project experience; architecture simplified for confidentiality. The 22% result compares goods in trucks with a period in the previous year. Exact dates, the load measurement unit and financial savings are not disclosed.
The project reported 22% more goods in delivery trucks, alongside infrastructure savings centred on servers and RAM usage. The chart illustrates the utilisation improvement as a relative index, not an absolute fill percentage. No financial savings figure is shown.
Explore the system landscape and the main areas of intervention.
A new integration layer connected the existing systems and introduced anomaly detection with corrective actions to support recovery. This made fault detection and recovery part of the architecture, rather than leaving teams to piece together symptoms across disconnected layers.
Billions of records put pressure on an already complex landscape. Queries were slow, bottlenecks were difficult to trace, and the architecture lacked the visibility needed to detect resource issues early. Long-standing parts of the system had remained untouched, while manual work filled the gaps.
The work addressed the architectural blind spots that made failures and resource pressure hard to locate. Understanding behaviour across the connected systems was central to making the operation manageable.
The new integration layer detected anomalies and applied corrective actions to help the system recover. Recovery became an explicit part of the system design.
Route-optimisation algorithms and real-time GPS recording were added. Infrastructure work focused on servers and memory usage, contributing to savings in the hardware footprint.
Increase against the previous-year reference period, with route optimisation part of the wider project.
Infrastructure efficiency was a key source of savings. Financial amounts and resource-reduction percentages are not disclosed.
A connected layer for anomaly detection and corrective actions, supported by real-time vehicle-location data.
Double clicks. Missing data. An unavailable service.
Go on. Throw something at the system.
The second request receives the existing result.
A slow connection. Another click on “Submit”. The same request arrives twice. A shared order identifier lets the system recognise the repeat before creating another delivery.
You don’t need a technical brief.
You probably already know the symptom.
Orders in the CRM. Different numbers in the ERP. A spreadsheet holding everything together. I trace where information changes, gets lost, or arrives too late — then fix the handoff.
Let’s untangle your integrations.A small workaround.
Repeated by a team.
Every. Single. Day.
8 people × 25 min × 20 days ÷ 60
= 66.7 hours per month
That’s 8.3 eight-hour workdays
spent keeping the workaround alive.
Illustrative time estimate based on your inputs, not guaranteed savings. Annual view assumes 12 identical months. Actual improvement depends on the process and the work that can be removed.
The useful question:
what is the smallest change
that solves the real problem?
If the ERP handles inventory and fulfilment well, preserve it. Start by understanding its rules and the interfaces it already supports.
↳ Protect what already works.Open-source tools that reflect how I work: fewer moving parts, clearer interfaces, and systems that fit together.
Vectra unifies vector database clients behind a single Ruby interface. Switch providers without rewriting the integration.
View Vectra ↗Semantic caching for Ruby. Reuse relevant LLM responses based on meaning, instead of making the same model do the same work.
View semantic-cache ↗
MIJO KRISTO / SYSTEMS ENGINEERThen I work on the software.
Ten years inside enterprise software and field sales systems. Business rules buried in code. Integrations that grew one exception at a time. People making the process work despite the tools.
I work through the details, from the real workflow to the production code. Ruby, integrations, and AI are part of the toolkit. Understanding what needs to happen comes first.
Meet me through my codeWhat does your team still do manually
because the software doesn’t?
Start with a few sentences. We’ll discuss the process, the constraints, and whether I’m the right person to help.