A separate system per company, or one organisation with separated data

If you run several companies, sooner or later you face a choice that is rarely named out loud. Either each company gets its own system, or all of them work in one. Both paths have supporters and both carry a cost that only shows up after a year. Let us set them side by side.

The first approach: a separate system in every company

The argument is strong: the companies' data cannot get mixed up, because it physically sits in separate instances. One company's accountant will not see another's invoices, not even by mistake.

The cost appears in configuration. The cost invoice workflow, leave requests and the contract register look almost the same in those companies, so you build the same process several times. After a year you have several versions of it, differing in details: one gained a review stage, another had its deadline changed, a third had a field added. Nobody remembers why any more. Every change in the law or in a procedure means as many rollouts as there are companies, and a group-wide summary is assembled in a spreadsheet by gluing exports together by hand.

The second approach: one organisation, separated data

Opero splits these two concerns into two levels. The organisation owns the configuration: modules, custom objects, fields, forms, layouts, processes, rules, reports, menus, custom lists and custom pages. The company owns the data: records, counterparties, invoices, tasks and process history.

The cost invoice workflow is therefore designed once. Each company works with the same process, but on its own invoices. A new stage or a new rule applies to every company that uses the process, without moving configuration between instances.

The key difference from a system with a “company” field on the record is that every access to data in Opero happens in the context of a specific company. Keeping data apart does not depend on whether someone remembered a filter in a report or on a list.

Where the approaches differ most

• Configuration. With separate systems, a process change means as many rollouts as there are companies. In one organisation it is a single change, published once.

• Sharing. Shared configuration does not mean every company gets everything. Modules, objects, processes, rules, menus and custom pages are shared with all companies or only with selected ones. An equipment rental module runs in the company that rents equipment, while the invoice workflow runs everywhere.

• Permissions. At the same level you decide who in a company has access to a shared element: all members or selected roles. Permissions for modules, objects and fields keep working exactly as in a single company.

• Dictionaries. Cost categories, contract types and risk statuses belong to the organisation, so they mean the same in every company. Without that, a group summary can only be assembled by manually translating one set of names into another.

• Daily work. Someone working in several companies switches context instead of logging into several systems, and each company has its own colour in the interface. It is immediately clear which company a new record belongs to.

• Reports. By default a report runs within the company you open it in, so the same cost report shows each company its own figures, with no separate definition. A report can also run across the data of all companies in the organisation. That scope is switched on deliberately, for a specific report, and who sees it follows from the page it is embedded in and who that page is shared with. With separate systems the same effect needs an export and a spreadsheet.

The limits of shared configuration

Opero does not keep the books or consolidate financial statements. A cross-company report summarises operational data: the number of cases, costs in the workflow, deadlines. Intercompany settlements and consolidation stay in the accounting systems.

Shared configuration also requires discipline. A process change applies to every company the process is shared with, so someone has to decide whether a change concerns everyone. If one company genuinely works differently, it is better to build a separate process for it and share it only with that company than to add exceptions to the common one.

And the most important point: this approach pays off when the companies have similar processes. If your firms have nothing in common beyond their owner, shared configuration will do little for them.

The choice between these paths comes down to one question: would you rather duplicate a process or manage it. That is easiest to judge against a working example. We will show you live one organisation with several companies, the same process shared with selected ones, and a cross-company report visible only to the people who are meant to see it.