Why every system in an organisation should sit on one database

It is the end of the month. The managing director asks how much of product A is left. The warehouse gives one number, accounts another, sales a third. Nobody is lying; each of them read it from their own software. The people are not the problem. The problem is that the organisation runs on several separate sets of data.

How numbers drift apart

In most organisations software arrived one piece at a time: accounting first, then a stock program, then office automation, then a spreadsheet for the weighbridge. Each works well enough on its own, but between them stands a person who reads a number from one and types it into the next.

That person has three enemies:

• Delay: today’s number reaches the next program tomorrow or at the end of the week. The manager’s report is always a little behind.
• Typos: a zero goes missing, two item codes swap places. Finding it can take days.
• Two versions of the truth: when a document is corrected in one place and not the other, two programs tell two different stories.

What “one database” means

It means every department works on the same database. In FaraERP a sales invoice posts its accounting voucher, reduces stock and lands in the management report the moment it is saved. Nobody carries it across, because there is nowhere to carry it: the number the warehouse sees is the number accounts sees.

The same goes for the rest of the family. FaraClinic is FaraERP set up for clinics, so what reception records reaches the cash desk and the books without being keyed in again. FEDLOG’s panel is FaraERP’s monitoring module, and FaraTozin’s weigh tickets land on the same server.

What it does not mean

• You do not start with everything. Begin with two or three modules and switch the rest on later. A module you have not bought is never switched on on your server.
• Not everyone sees everything. The data is shared, but each user sees only what their role allows, and nobody can grant access above their own level.
• Your data is not mixed with anyone else’s. One database for your organisation, not for every customer: each organisation has its own installation and database.

Signs it is time

• Answering a simple question means collecting numbers from two or three people and adding them up.
• Closing the month takes more than a week, mostly spent reconciling.
• Someone’s real job is moving numbers from one program to another.
• When one person goes on leave, the report only they knew how to build waits too.

Moving across without stopping work

The biggest worry is the old data. Charts of accounts, customers and suppliers, items, warehouses and opening balances all come across. There is a ready converter for Sepidar and an import template for Excel; the amount of old data decides whether this takes one week or three.

Getting started usually takes one to two weeks for a small business with two or three modules, and one to three months for an organisation with production, several warehouses and years of history. A firmer figure needs a look at your current data.

Where the real cost is

Honestly, the hard part is not the software; it is habit. On one database a mistake in one department shows up quickly in another. That is good, but uncomfortable at first. So start where the most retyping happens, and add the rest once the team trusts the system.

One database means recording once, and one number for everyone. Everything else follows from that.

An example: from purchase to sale, with no retyping

Picture a factory that buys raw materials, produces and sells. On separate programs, each step of that chain is recorded once in one program and again in the next. On one database the chain looks like this:

1. Purchasing: purchase request, quotation, order and goods receipt follow one another, and settling with the supplier starts from that receipt.
2. Stock: the goods receipt raises stock at once; using materials in production lowers it.
3. Sales: a pro-forma becomes an invoice, and the invoice posts its own accounting voucher.
4. Management: the manager’s dashboard shows finance, stock, production and people from the same data the day’s work runs on, not from yesterday’s report.

Nobody carries a number from one place to another anywhere in that chain. If a document is wrong it is not deleted but voided, and it is clear who changed what, and when.

Where to start

Our usual advice: start where the most retyping happens. In a trading company that is usually sales and stock; in a food factory, the weighbridge and the warehouse; in a clinic, reception and the cash desk. Once that part has settled on the system, switch on the next. The first part’s data stays put, and the second sees it from day one.

One more practical point: tidy up your item and customer lists once before the move. Every duplicate in those lists today will still be there afterwards — just in one place.

One set of data, one shared language

The biggest change often shows up in management meetings. When everyone reads from the same data, the meeting stops being about whose number is right and starts being about what to do with it. That alone usually frees more time than any feature.

Next step

If you want to see what your own work looks like on one database, book a meeting and we will lay out a working day of yours in the system, with your own data and your own words.