How We Built OPTIMUS: An ERP You Configure by Conversation

The controller at a packaging plant is staring at the unit cost of a roll of film. It went up 4%, and she can’t tell why. The ERP shows the number. It doesn’t show where it came from. Figuring it out means exporting three reports, stitching them together in a spreadsheet and calling the purchasing manager. Half a day, gone. Meanwhile, someone needs a single new field on the order form — “print type” — and the implementation partner quotes two weeks and a change order.

That scene is where OPTIMUS started: an ERP system you configure by conversation, not by programming. Here are the decisions we made at the very beginning, and why.

Four decisions that shaped everything

We started with principles, not screens. These four drive everything else.

The core is code; everything industry-specific is data. Inventory, lots, production, journal entries — shared code for every customer. Your custom sections, fields, lookups, statuses, reports and print forms are configuration, stored as data. No customer plugins or scripts, by design.
Anything configurable should be configurable through a conversation with an agent, not by editing code.
Operational settings live in the ERP; financial ones live in accounting. Bills of materials, standards, units and labor hours belong in OPTIMUS. Chart of accounts, journal entries, taxes and payroll belong in BUHUS. Between them run agreed-upon streams of facts, not one shared pile of tables.
Every number should explain itself. If unit cost went up, the system shows you why.

Here’s what those decisions look like in practice.

Decision 1. Core in code, industry in data

A typical ERP gives you a choice: run it as shipped, or pay for customization. Every customization is code that has to be maintained through every upgrade.

In OPTIMUS, a lot is configurable without code:

custom sections with their own table, menu, list view, record view and lifecycle;
extra fields on standard objects, lookups, statuses on any entity;
restriction rules, record visibility, checklists;
reports, print forms, numbering;
roles and permission scopes — by warehouse, work center, equipment, or “mine only”;
workstations: screens built for a specific job.

All of that configuration rolls up into a profile — a snapshot of the whole setup in one package. Profiles move as files, say from a sandbox company to production.

When your industry needs a building block that doesn’t exist yet — a new module type or data source — the agent doesn’t quietly write code. It files a request with the product team, and the new block ships in a release for every customer. That work is handled by DEVUS, an AI development team that proves with tests that nothing else broke.

Workstations without a developer

A shift supervisor’s screen, a warehouse wallboard or a dispatcher’s board is assembled from 16 ready-made modules: KPI tile, list, record card, status kanban, resource board, floor plan, shift clock, checklist and more. Build it with a mouse, or describe it to the agent.

The server validates the entire screen, including whether every role has permission for every module and button. Only an error-free screen can be published, and a second person has to approve publication. Rollback means a new validated version — not “restore and hope.”

Decision 2. Configuration by conversation

The ERP implementation agent works like an experienced consultant with a perfect memory. It keeps a dossier: what’s known about the company and where it came from.

Every fact has a source — who said it, which document, the exact quote. Until a person confirms it, a fact stays a hypothesis.

Every question comes with options and the consequences of each one. For example:

How should materials be issued to production? — FIFO: cost tracks actual purchase prices more closely, but reconciliation is harder when items get mixed up. — Weighted average: simpler and more stable, but lot-level cost gets blurred. I recommend FIFO: your lots vary in price and shelf life.

When data is missing, the agent records an assumption: “We assume scrap at this operation is under 2%. This will be closed once the plant manager sends last quarter’s numbers.” Assumptions don’t vanish; they stay in the dossier until someone closes them.

Every decision has seven parts

We argued for a while about what a decision record should contain. We landed on seven parts:

Part	Why it’s there
What was decided	The gist, in one sentence
Why	The reasoning
Based on	Facts from the dossier, with links
What happens next	Operational consequences
What it rules out later	Which doors close
Options rejected	What else was considered, and why not
How to undo it	The rollback plan

“What it rules out later” turned out to be the most useful line. A year from now, nobody will remember why a choice was made. The dossier will.

Dry run before anything is written

Before applying anything, the agent runs a dry run and shows before → after without saving a thing. After your approval, the plan is applied step by step. Then the agent checks the configuration against the dossier and lists any mismatches. Any change can generate its own rollback plan.

Irreversible steps — publishing a new section or installing a profile — can only be confirmed on the ERP screen itself, not in chat. That’s protection against an accidental yes.

Decision 3. Costing that explains itself

OPTIMUS calculates cost on a FIFO basis from materials, overhead, labor and equipment wear. The formula matters less than this: every number can be taken apart.

Overhead isn’t one big bucket

Each type of overhead — freight, duties, insurance — is tracked separately, with its own account and its own allocation driver. Freight is allocated by weight or volume; duties and insurance by value. That’s also what the international inventory standard, IAS 2, expects. The report doesn’t say “other costs +12%.” It says “freight on this lot.”

Labor at the fully loaded rate

Hours come in from the shop floor. The hourly rate is fully loaded: base pay plus employer taxes. Hours times rate are charged to work in process with a separate entry — for example, 6.5 hours × 31,000 = 201,500.

If hours arrive without a rate, they aren’t dropped. They’re accepted with a flag and become a blocking question for whoever is configuring the system.

Order, receipt and invoice have to match

The classic headache: goods are received, but the supplier’s invoice hasn’t arrived — or it has, for a different amount. OPTIMUS and BUHUS run a three-way match between purchase order, receipt and invoice. Default tolerance is zero.

Here’s how it played out in a test on live data. We received 1,200 kg at 37,500 per kilogram. The supplier invoiced at 39,000. The system:

booked 45,000,000 to the receipt and 1,800,000 to purchase price variance;
put the invoice on payment hold with the reason “price variance”;
refused an attempt to pay it, with a plain-language explanation;
released the hold only when someone gave a reason, and logged it.

If the supplier bills for more than was delivered, the invoice is held too, with the reason “invoiced quantity exceeds received.”

Accounting no longer hunts for where the difference came from. It’s already broken out and labeled.

Decision 4. Rules that are checked, not guessed

Product configurators, shipping rules, lot restrictions — this is logic where a mistake costs real money. Here OPTIMUS relies on LOGUS: a rule isn’t guessed by an AI “in its head”; it’s checked against every possible value. If the rule breaks somewhere, LOGUS shows a concrete counterexample.

One product record for the whole system

A product or service is created once and used everywhere: in the CRM for quotes, in documents for contracts, in the ERP for production and inventory. Names in three languages, tax rates and national tax classification codes, price lists by date and currency. A won deal in the CRM becomes a sales order or estimate in the ERP on the same lines — no re-keying.

Who OPTIMUS is for

manufacturing, distribution and service companies of roughly 30 to 300 people;
companies that need local accounting, national product-marking compliance and government reference data, especially in Central Asia;
anyone tired of paying for every new field.

The warehouse runs on camera phones, handheld scanners, barcode readers and scales. The warehouse terminal works offline and syncs when the connection returns.

Implementation: a separate phase, the same conversation

We’re upfront that ERP is not part of the 14-day first working setup. Org chart, permissions, CRM and tasks go live in 14 days. Manufacturing with bills of materials and costing is a separate phase, because it involves many decisions that only people can make. But it runs the same way: conversation, dossier, plan, approval, undo. For why traditional ERP rollouts take months, see Why ERP implementation takes months. How our process works is on the implementation page.

The bottom line

OPTIMUS is an ERP where your industry is configuration, not customization. The agent keeps a dossier with sources, proposes decisions with their consequences and changes nothing without your approval. Cost is broken down by cost type, and orders, receipts and invoices reconcile themselves. For the logic that must never break, read LOGUS: AI that cannot be wrong.

Want to hear how the agent would talk through your production setup? Request a demo.