One Integrated System or Specialised Tools?

A specialised program does one thing deeply, because all of its team's effort went there.

An integrated system does ten things at moderate depth, because the same effort was divided.

That is description rather than diplomacy: anyone comparing feature against feature will find the specialist deeper every time — and comparing that way misleads, because it counts what you gain and not what you pay.

What you pay is called the cost of joining: the effort spent making programs talk to each other. It appears on no pricing page, because it is not an amount but hours and error risk.

So the right question is: what is the extra depth in this particular function worth against the cost of joining it? And the answer may differ from one function to another inside the same business.

The fourth is the most dangerous and the least discussed. When two figures disagree you need a rule declared in advance for who owns the truth in each field: who owns physical stock, and who owns its accounting value?

Whoever does not set the rule before joining will set it after the first disagreement — under pressure, and in favour of whoever speaks loudest.

Note that three of the four recur monthly. The cost of joining is not a setup fee paid once but a permanent operating line.

A specialised program wins when the function is the heart of your business rather than a service supporting it.

Clear examples:

• A business whose whole work is complex project management with stages, resources and dependencies
• An activity whose core is design or production, needing specialist tools a business system cannot substitute for
• Work depending on intensive field scheduling with teams and rotas that change daily

The rule: if the function is what the customer is paying for, do not buy average in it.

Conversely, functions the customer does not pay for directly — accounting, invoicing, payroll, stock tracking — rarely justify a separate specialist in a small or medium business, because extra depth there is invisible to the customer and adds no revenue.

A rule you can apply in a minute, suitable for most businesses:

> Unify everything that ends in a figure on the financial statements. Specialise whatever does not.

Applied:

The logic is that financial functions share the same ledger, so unifying them removes reconciliation rather than easing it. What does not touch the ledger creates no meaningful cost of joining when specialised.

Do not decide on a paper comparison. Test in four steps inside a trial:

1. Write your current process in ten lines — from order to payment. Who does what, and where they enter it. 2. Run the whole process inside the one system with real rather than sample data, recording every point where you had to leave it. 3. Measure the exit points: how often, how many minutes, and whether they sit in your core work or in a support function. 4. Decide on the number: one monthly exit in a support function does not justify a second program. A daily exit in your core work does.

The trial in Snad runs 30 days with no card, enough for a full monthly cycle including one close — which is exactly what exposes the cost of joining, because it shows at the close rather than in daily use.

In Snad the ten apps sit inside one system, so you switch on what you need and leave the rest. The limits are stated: it is not a production planning system, a talent management system or a case management system, it does not track expiry dates or batch numbers, and being cloud-based it needs a connection.