Why the workflow comes before the database

Two teams can build the same system with the same stack and end up with very different results. The difference is usually not the code. It is what the team understood before the code was written.

The org chart is not the process

Ask a business how an order is handled and you will hear the official version: sales creates it, stores picks it, accounts invoices it. Sit at the counter for a morning and you will see the real one — the phone call that changes the quantity, the supervisor who overrides a price, the invoice that waits for a stamp. The real process is where the data model has to fit.

Map hand-offs, exceptions and evidence

A workflow map worth having answers three questions for every step: who hands the work to whom, what can go wrong at that point, and what proof is kept. Those three answers become states, validation rules and audit records. Skip the mapping and the same facts arrive later as change requests.

Then the data model almost writes itself

Once the states and hand-offs are clear, entities and relationships follow: an order has a status history, a price override has an approver, a delivery has a proof. The schema is a consequence of the process rather than a guess about it — and it changes less often, because it was right the first time.

Practical signs you skipped this step

• A "notes" field carrying information that should have been structured.
• Status columns with values nobody can explain.
• Reports that are rebuilt in spreadsheets every month.