How you end up with two programs that don't talk to each other
Almost no company chooses to have two business systems, it ends up with them. They were bought at different times for two different problems, and back then nobody asked whether they would ever have to swap data
One follows production, the other the accounts, and each does its own job well. The trouble is that both of them need the same information, the customer record, the item code, the quantity delivered
Since no direct integration exists, the bridge between the two programs is a person, who reads on one side and types it in again on the other. That person isn't doing pointless work, they're holding the company up with their hands
Before a line of code gets written, decide which one is in charge
The most important decision here is organizational, not technical, and for every piece of data you have to settle which of the two programs is in charge
Being in charge means the data is born there and changed there, and the other program takes it without arguing. If the customer record is in charge in the accounts system, the address gets changed in the accounts system, and production finds it already updated
The same program doesn't have to be in charge of everything, it's one piece of data at a time, customer records on this side, item codes on that one. What you need is a single answer for each piece of data, written down, and known to everyone
That decision belongs to whoever knows the company, not to whoever writes the automation, because it depends on who works better where
Why copying in both directions causes trouble
Keeping the two programs in step in both directions looks like the handiest thing to do, and it's the road that does the most damage. If both of them can change the same piece of data, sooner or later both of them will, and then nobody knows which of the two versions is the right one
Whoever edited last isn't an answer, it's a bet. The most recent version isn't necessarily the correct one, it might be the one typed in a hurry by somebody who didn't have the full picture
Copying in one direction only doesn't manage that problem, it takes it off the table
The codes that don't line up, the real dirty work
The part that eats the most time isn't the copying, it's making the two worlds meet, because the same item is called one thing in production and another in the accounts
The solution is trivial to describe and tedious to do. You build a conversion table that says which code on this side matches which code on that side, and you're the one who dictates that table, the system only consults it
Sooner or later a code turns up that isn't in the table, and at that point the automation must not invent the closest-looking match. It has to stop and put that case in a list, because an item paired up wrongly produces a wrong entry
How the data gets across when there's no integration
If one of the two programs offers a direct integration you use that, it's sturdier and there's no reason to be a hero
When there is no integration, and with business software installed inside the company that happens often, you go through the screens. The system opens the program, looks up the record, reads the fields, opens the other one and writes them where they belong, the way the person acting as the bridge does today, except it never gets distracted
This is the part Muffin Suite does on programs with no direct integration, and it's why a closed business system isn't a life sentence of retyping data
A made-up sum, just to show the reasoning
Say that forty entries have to be carried from one program to the other every day, and that each one takes a minute and a half
Forty times a minute and a half is an hour a day, and over twenty days that's twenty hours a month. Multiply by your hourly cost and you have the figure, and you can redo the sum with your own numbers in the savings calculator
That hour is the small part, though. Until the transfer has been made, one of the two programs is telling you something that is no longer true, and any decision taken by looking at that program is taken in the dark
What it has to do when something doesn't add up
A transfer between two business systems has to be built knowing that every so often something jams, and that's where you see whether it holds up or does damage
It has to keep track of what it has already copied, because the duplicate is the worst trouble of all. An entry written twice is harder to spot than a missing one, and it has to be ruled out by design
The doubtful cases have to land in a list with the context beside them, so that whoever looks at it decides in a few minutes
And it needs a log of what was done and when, because the day a number doesn't add up the first question will be who wrote that line
A side effect that's worth it on its own
To have a machine copy the data you have to put in writing who is in charge of what, and inside a company that question has often never had an official answer, it has always been settled by habit
The day that answer exists in writing, you've also settled part of the arguments about which program is telling the truth, and that sheet stays useful to you even if you never build the automation