The same order is typed in twice.
It arrives in one system, someone reads it there and enters it in the next one. Sometimes a third person enters it again for invoicing.
Connected systems
We have the systems. We need them to work together.
We connect the flow between them and leave the systems that do their job in place.
Order · Stock · Delivery note · Invoice · Customer record
Each system was bought for a good reason and each one does its part. Carrying an order from one of them to the next is done by people, and that is the part we take over.
ERPCRME-shopRetypedExportedThe gaps are staffed by people
Is this your case?
Each system does its job. The work between them is yours.
The systems are rarely the problem. The time goes into carrying the same order from one of them to the next.
Two systems, two versions of one customer.
The address, the payment terms or the discount differ depending on where you look. Everyone has their own answer for which one to trust.
Nobody knows what an update will break.
A connection was built once by someone who has since left. Every upgrade of the ERP turns into a week of waiting to see what stopped arriving.
A spreadsheet sits between two systems.
Someone exports from one, adjusts the rows and imports into the other. That file is part of your operation now, and it has no owner.
Where the flow breaks
Your people are the connection between the systems.
The cost sits in the gaps. How many orders you can take this week depends on how many people are free to carry data between the systems, so capacity gets decided in the office. A hand-over that failed is usually found days later, by a customer asking where the delivery is. The systems then get blamed for a flow that nobody ever built, and the next thing discussed is replacing a tool that was doing its job.
- 01Order
- 02Retyped
- 03Warehouse
- 04Exported
- 05Invoicing
- 06Matched by hand
- 07Reporting
The dashed steps are the ones where a person moves data between two systems that both did their part. Count how often each of them happens in a week, and you have the size of the problem.
Your options
Several of these leave every system exactly where it is.
If the flow between your systems were a standard one, a supported connector would already cover it. We check what your vendors and your own licences already do before we propose anything custom.
The connector your vendor supports
Fits when
the supported connector carries the whole hand-over, start to finish.
Several systems ship a supported connection to the ones you already run. When it carries the whole hand-over, including what happens on a failure, we will tell you to use it.
Configuration inside the product
Fits when
the missing piece stays inside one product you already pay for.
A field, a status, an import or a supported extension often settles it. It stays inside the vendor's support, which keeps it cheap to own.
One flow built for your rules
Fits when
the meaning of the data, the permissions or the failures decide the outcome.
We build the path for one business event and write down which system owns each field, who may change it and what happens when one side is down. Everything else stays where it is.
An operational layer around what you keep
Fits when
the flow itself is missing from every system you own.
Orders, statuses and documents live in one place that reads from the ERP and the CRM and writes back to them. The systems keep doing their own work.
Wait
Fits when
nobody owns the field that the two systems disagree about.
Connecting two systems that hold different rules copies the disagreement faster. Where the rule has no owner yet, we will say so and stop there.
How we work on it
We follow one order before we connect anything.
The hard part is knowing which system is right when two of them disagree. That is business knowledge, and it lives with your people.
We follow one real order
We sit with the people who enter it, export it and check it, and we write down every point where it changes hands. The exceptions get written down in the same pass.
One flow, agreed before it is built
We name the event that starts it, the system that owns each field and what has to happen when one side is unavailable. The scope and the estimate are written down first.
Reading before writing
The first version can read from your systems and prepare the write for a person to confirm. The people who do the job see it on real orders while it is still small enough to change.
We stay with it in production
Retries, reconciliation and alerts make a broken hand-over findable the same day. Monitoring and the responsibility for it have a named owner.
Relevant work
Operations where one item crosses several systems without a person carrying it.
Transport and bulk materials, Czech Republic
From the depot to the invoice without a hand-over
400+ daily users
Ridera supplies solid fuels, aggregates and recycled materials, and its trucks and wagons leave the yards on what the internal system says. Dispatch, drivers, administration and finance work on the same records, and documents from the field reach invoicing on the same day.
Hardware distribution, CEE
Partners, suppliers and invoicing on one record
An enquiry to the right contact in minutes
A fast growing distributor sits between the manufacturers and the end customers, with the agenda spread across spreadsheets and separate tools. Partners now fill in what the company needs through their own link, availability and prices arrive from a supplier database, and invoices are created, sent and matched to payments through the accounting service.
The sector changes and the situation repeats. One item has to cross several systems, and the question is the same every time. Which system is right about each field, and what happens when one of them is not there.
We start with one order
The questions we will ask in the first meeting.
- Which event starts this, and what has to be true for it to count as finished?
- When two systems disagree about a price, an address or a status, which one is right?
- Which of these writes can happen on their own, and which ones need a person to approve them?
- What happens today when one of the systems is down or refuses the data?
Why Moravio
A software partner for connecting the systems you keep
Build or buy advice
We check the supported connectors and the settings in your own licences first. Custom work starts where the rules, the permissions or the failures require it.
Built around what you keep
ERP, CRM, e-shop and the specialist tools stay in place. The flow we build reads from them and writes back to them.
Failures you can see
A hand-over that fails raises an alert, retries and can be reconciled. Nobody has to find it days later in a customer email.
Yours to own
The code, the field mappings and the rules stay with your team, and the flow can run on your infrastructure.
The first step
One order, followed across every system it touches.
We take one real order and follow it from the moment it arrives to the moment it is invoiced and reported. You need nothing prepared and no specification. You talk to the people who design and build the flow, so nothing is lost on the way to a delivery team.
01
The order we follow
We pick one ordinary order from last week and start at the point where it arrived. An everyday case shows where the work really goes.
02
Where it changes hands
We mark every point where a person moves it from one system to the next, and how long it waits at each of them.
03
Who owns which field
We write down which system is right for each field and status, who may change it, and which writes could happen without a person.
04
The first hand-over to remove
We put the hand-overs side by side with what each one costs today, and we name the one to start with, with its scope and its estimate.
What you bring
One real order from last week and the people who handle it. Nothing prepared, no specification.
What you leave with
The path of that order with the hand-overs marked, which system owns which field, the options for the first hand-over including buying it and waiting, and a scope and estimate for it.
FAQ
Frequently asked questions
That is the first part of the work. We sit with the people who enter, export and check the data, and we write down the decisions and the exceptions before anything is connected. We have done it in transport, in hardware distribution and in retail, and the operation was different every time.
No. The systems that do their job stay where they are, and we connect or extend around them. Replacing a tool comes up only where it forces a way of working your company cannot use.
The first flow runs on real orders with the people who handle them, while it is small enough to change. We change it with them. The old way stays available until the new one has earned trust in daily work.
You leave the first step with a written scope, an estimate, the options we rejected and the reason, and the risks. IT gets the technical path in their own terms: permissions, which system is authoritative for each field, how a failed write is retried, and who owns the code.
It is the next one along. This page is about the flow between the systems, so that an order stops being retyped on its way to invoicing. Reports that disagree with each other are their own subject, and our page on reliable company data and reporting covers it.
Often yes, and we will look at it with you. A supported connector that carries the whole hand-over, including what happens when the other side rejects the data, is cheaper to own than anything we would build for you.
Usually. Our integration work includes SAP for DATART and Česká zbrojovka and Odoo for Švihej.cz, and the ERP, CRM and e-shop products used in Czech companies are familiar ground. If a system can exchange data in a supported way, it can usually be connected.
Start with the situation
What do you need but you can’t buy off the shelf?
Send us the messy version. We will help make the next decision clear.