One system for all your branches, or one for each

This comes up with every business that has more than one location, and it arrives dressed as a technical question. It is not one. It is a question about whether you want a single version of your numbers, and what you are willing to give up to have it.

What one system buys you

When somebody senior asks how much stock the group is holding, or what was invoiced last month, the answer is a number. Not four spreadsheets, three of them a week old and one of them counting things differently. That sounds minor until you have spent a Thursday afternoon working out which of your own figures is the correct one.

You also get one place to fix a problem, one place to train new staff, one supplier to hold responsible, and the ability to move somebody between branches without teaching them a new system on arrival.

What separate systems buy you

Speed, mostly. A branch manager who wants a change can have it without waiting for another country to approve it, and each location gets something shaped around how they actually work rather than something negotiated between five offices.

For two branches doing the same thing in the same country, that is a reasonable arrangement for a while. It stops being reasonable at the point where somebody has to produce a group figure every month, and it tends to stop abruptly rather than gradually.

Where we let the local office win

We run one system for an engineering consultancy working across four countries: thirty-five working parts covering projects, finance, HR and procurement, with more than 150 people in it every day. It is deliberately one system. A short list of things are set per country, and always were:

• Tax, and how invoices are numbered, worded and printed, because that is decided by the country rather than by you
• The working week and the public holidays, since a day that is a weekend in one place and a working day in another changes what every report means by the word week
• Currency, which exchange rate a report converts at, and on what date
• What a manager may approve on their own, which differs by office and sometimes by law
• The language and the format of anything a client sees
• Who is allowed to look at another country's records, which is a legal question in some places and a political one in others

The list is short on purpose. Everything on it is there because the outside world forces it, not because an office preferred it that way.

What has to stay the same, whatever anyone says

The definitions. What counts as a project. When a sale becomes a sale. What delivered means. What a customer record is and when somebody is allowed to create a second one.

Allow one branch its own definition of a finished job and your group report becomes arithmetic performed on four different things and presented as though it were one. Nobody notices for two quarters. Then somebody does, and it is usually an auditor.

That is a management decision rather than a software one, and it needs somebody senior enough that a branch manager cannot go around them. Get that person named before the project starts. If nobody will take it on, you already have the honest answer to the original question.

What one system actually costs you

A change one branch wants affects everybody. Somebody has to be able to say no, or at least to put things in an order. Without that person, one system slowly turns into a system with forty optional settings, which is several systems wearing the same badge and costing more than all of them put together.

Then the dull operational costs. Releases have to happen at a time that is the middle of the night for somebody. Support has to cover a working day that starts before yours and ends after it. Availability matters more than it otherwise would, because when one system stops, everybody stops. Ours has been available 99% of the time, and that figure comes out of unexciting choices rather than clever ones.

Before you decide either way, take last month's group report and go through it figure by figure, asking where each number came from and how the branch that produced it arrived at it. If two branches count the same thing in two different ways, you have found the actual project, and it is a conversation between people rather than something software will settle for you. If you want to talk it through with somebody who has run one system across borders, that is an hour well spent before you commit.