MRP system built for a manufacturer operating under FDA compliance requirements

The challenge

Manufacturers working under FDA compliance requirements carry an evidence burden that general production tooling does not cover. Products and components need defined lifecycles. Orders need to be traceable to the steps that produced them, the people who ran them and the approvals that released them. Evidence of that kind is more defensible when the system produces it as the work happens than when it is assembled afterwards.

General production tooling is usually organised around scheduling, with traceability and approvals handled elsewhere. The system of record for production then sits apart from the record an auditor relies on, and the gap is commonly closed with spreadsheets and paper.

The requirement was a single system holding lifecycle definition, order execution and auditability together.

What we built

We built a manufacturing resource planning system, now in use at a company operating under FDA compliance requirements.

One point of accuracy. The system does not hold an FDA certification. It was designed and built with FDA compliance requirements in mind, so that it supports the client’s compliance position rather than working against it.

Live today:

• Admin panel. Where the operating model is defined. Administrators set up project lifecycle management for products and components, specifying the stages an item moves through.
• Workers panel. The floor view, held separate from configuration. Operators run orders against the lifecycle stages defined for the product.
• Order execution. Orders are raised and run through the system against those defined lifecycles.
• Users and workstations. Both are maintained as records in the system, which is what allows work to be attributed to a person and a station.
• Approvals. Approval steps sit inside the workflow rather than outside the system.
• Audit logging. Actions are recorded in an audit log as the work is done.

Planned for later phases: inventory management, production tracking, and reporting over the data the system already holds.

How we worked

Delivery is phased. The current release covers lifecycle definition, order execution, and the identity and audit foundations beneath them. Inventory, tracking and reporting follow on the same data model.

Compliance requirements shaped the design from the first release. Audit logging and approvals are part of the core system rather than a later hardening pass.

Outcomes

No measured results are published for this engagement. The items below are delivered capabilities, stated as such.

• One system of record for product and component lifecycles.
• Order execution tied to those lifecycle definitions, so the process run on the floor is the process defined in the system.
• Audit logging generated by normal work rather than compiled after the fact.
• Approvals captured inside the workflow, giving a consistent record of who authorised what.
• Separate administrator and worker surfaces, so configuration authority and floor execution are not the same view.
• A live data foundation for the planned inventory, tracking and reporting work.