An ERP against a dedicated procurement system

What InPlace refuses to be

• Not another dashboard of metrics with no decision on it
• Not an expense product that defines value through spending alone
• Not a heavy general ERP
• Not a loud or colourful SaaS brand

The practical difference

When an ERP is the right choice

When the organisation needs one system for manufacturing, inventory, people, finance and procurement, and when it has the time and the people for an implementation of that size. In that case the ERP’s procurement module works against the same data as the rest of the organisation, and that is worth something.

The businesses InPlace was built for sit on the other side of that line: they need control over procurement now, not a project.

The cost of implementation, not the cost of the licence

The large expense in an enterprise system is not the monthly price but the time of the people who have to learn it, configure it and migrate data into it. An ERP is built on the assumption that this project exists and is budgeted for.

InPlace was built on the opposite assumption: that you can start with one supplier on a Monday, and that the system has to prove itself before anybody allocates a project to it.

What happens when you need both

It happens. An organisation with an ERP running manufacturing and inventory can still suffer from procurement managed over WhatsApp, because the ERP’s procurement module was never implemented to the end.

In that case the question is not which system wins but where the payment decision is taken. Whichever system holds that decision should also hold the comparison that leads to it.

What they have in common

Both require the work to pass through them. A system somebody bypasses over WhatsApp is not a system, whether it cost a hundred thousand or nothing at all.

The difference is how easy it is to bypass. When the system covers one complete chain and speaks the language of the people working in it, going around it stops being the short way.

What an ERP does that this does not

A great deal. Manufacturing, complex inventory, human resources, full bookkeeping, project management and costing. All of it is out of scope here, not because it does not matter but because this product does one thing: the journey from the order to the bank transfer.

That is said plainly because a feature list is where it is easy to promise more than exists. A business that needs those things will be better served by an ERP, and that is the right answer even when it is not the convenient one.

Why three fixed roles instead of flexible permissions

In an ERP, permissions are built during implementation, to whatever the organisation asks for. That is flexible, and that is exactly the weakness: a separation of duties somebody configured is a separation somebody can unconfigure, usually under pressure and in the middle of a month.

Here there are three roles and no more: owner, procurement manager and accountant. They cannot be redefined, and what each of them sees and does is fixed in the structure of the system. The accountant is the only one who moves money, and the procurement manager does not touch payments or the bank at all.

The cost is flexibility. What you get for it is that the separation still exists in the third month, when nobody remembers why it was set up that way.

What happens to the data if you stop

It belongs to the customer, and that is written into the terms of use rather than only asserted here. Moving between plans deletes nothing: what has accumulated stays in full even on the way down, because the difference between plans is the number of documents a month and not the list of features.

That is a question worth asking any software supplier before the implementation rather than after it, and particularly one that holds the payment chain of the business.