An ERP's behavior mapped for the people and the agents who had to use it

The operating team needed a usable reference for the ERP’s behavior, limits and common workflows.

Vendor documentation describes the product as shipped. It does not describe the configuration a particular company chose, the fields that team decided to use, the workflow that was adopted because the intended one did not fit, or the limit somebody discovered the hard way on a Friday afternoon. That second layer usually lives in the heads of two or three people and in a scatter of messages.

The cost shows up as repeated questions, inconsistent answers to the same question, and work that stalls whenever the person who knows is unavailable. It also blocks anything automated: software written against an assumed behavior fails against the real one.

I specified the corpus and directed its assembly. The vendor’s material and the company’s configuration inside it are not mine, and none of it is published.

I specified a reference corpus covering product behavior, API evidence, runbooks and interface workflows. The source index lists twelve API playbooks and seventeen workflow maps, with provenance and known gaps. It was incorporated into the company’s operating reference material.

This public account describes the capability. The vendor material, tenant configuration and private evidence remain private.

The corpus covers product behavior, API evidence, runbooks and interface workflows, with provenance and known gaps. A reference like this earns its keep when it is organized around the questions people actually bring to it rather than around a vendor’s table of contents, and when it records what was observed rather than only what was documented.

Two properties make a reference of this kind maintainable. Provenance, so a reader can tell an observed behavior from a documented one and knows what to recheck after an upgrade. And gaps written down as gaps. A reference that quietly omits what nobody verified teaches people to trust it uniformly, which is exactly the wrong lesson.

The same material serves people and software. A person reads a workflow map before doing the task; an agent reads the same evidence before writing code against the system. Keeping one source for both is what stops the two from drifting apart.

No usage was measured.

Nothing is claimed about time saved, questions avoided or errors prevented. No usage was counted, so there is no basis for a figure and none is offered.

What could be measured, in a business that wanted to know, is how often a question is answered from the reference rather than a person, and how much of a new hire’s first month is spent asking things the reference already covers.

If the answers a business needs are buried in documents and people, the knowledge and reference engagement starts by testing which questions the existing material can and cannot answer. The retrieval side of the same problem is in connected records and search, and the checking side, binding a written claim to a source, is in document checks that bind claims to a source.