How to implement ERP in a medical device manufacturing company

ERP projects in device plants seldom fail on the software. They stall because the master data is not ready, because validation is treated as a separate project that starts after go-live, or because operators and inspectors are asked to change how they record work without being shown why. What follows is a plan that starts with one line and one product family, and brings validation in from the first week.

Before you start: decide what the system will hold

Write down the records your auditors, customers and QA reviewers ask for most. For most device and precision parts plants the list is short: the batch record, the lot-to-unit trace, inspection results with the instrument, nonconformance and dispositions, the status of parts at vendors, and the cost of a batch. Those define the first scope.

• Name an owner from the plant, usually the plant head with the quality head alongside, not IT alone.
• Decide early who owns validation. The manufacturer validates the system for its intended use; plan that work from the start, with your own procedure for computer system validation.
• Choose the first line: one with steady volume, a willing supervisor and products whose batch records cause review findings.
• Agree what will stop when the line goes live, such as the paper traveller or the inspection workbook, and what has to happen before it can stop.

What data do you need to prepare?

Machine rates do not need to be exact on day one. Inspection plans and BOM revisions do. A rough rate corrects itself from the floor's counts; a wrong tolerance or revision goes straight into the batch record.

The stages of an implementation

1. Configure the plant as it runs

Work centres, shifts, products, BOMs, routings with their checks, instruments, roles and reason codes are set up in the plant's own terms. Opening stock is loaded by lot and status, and the accounting sync is connected. By the end of this stage a test batch should run from receipt to release on the screens, and the validation team should have what it needs to write its test scripts.

2. Run the first line on real batches

Operators, supervisors and QC on the first line are trained at their stations and record real batches. In a device plant the existing paper record usually stays the official record during this stage, while the plant runs its validation testing against the system. Gaps show quickly: a routing step that needs splitting, a missing characteristic, a role that can release when it should not. Fix them and record the change.

3. Switch the first line over

Once validation for that scope is complete and QA approves, the first line runs on the system alone and its paper traveller stops. Batch records for that line are reviewed from the system.

4. Extend line by line

The remaining lines, the cleanroom and the vendor operations follow on the same pattern. Each goes faster than the last, because the masters, the training and the validation approach are already proven.

How long does a medical device ERP implementation take?

It depends on scope, data readiness, the system and the plant's validation approach. A broad enterprise ERP across finance, procurement and several sites is a much larger project than putting production, inventory and inspection live on one line. FleekERP's implementation plan is built to put the first production line live in 18 days. Your own validation of the system, migrating years of history from another ERP, or BOMs and inspection plans that need rework first will take longer.

Common ERP implementation mistakes in medical device manufacturing

1. Configuring software before understanding the process

Setting up screens before anyone has walked the floor gives a system that matches a template rather than the plant. Map the real route of one batch first: where bar is issued, where each check happens, what goes to vendors, where the cleanroom starts. Configure to that. In a regulated plant this map also becomes the basis of your user requirements for validation.

2. Poor master-data preparation

A wrong BOM revision, a tolerance copied incorrectly from the drawing, opening stock without lot or status: each one breaks the first batch records. Check the masters for the products you start with against the approved documents before go-live. The opposite mistake is as common: migrating every historical batch. Open orders, current stock by lot and active masters are usually enough; old batch records stay where they are, retrievable for their retention period.

3. Ignoring shop-floor users

Operators and inspectors make most of the entries in a batch record, yet they are often trained last, in a meeting room. Train them at their station on real batches and keep their entries to what they need: count, scrap with a reason, measured value with the instrument. FleekERP's shop floor apps run on ordinary Android phones, so check early how phones will be used in the cleanroom under your gowning rules. If batch counts are passed around on chat today, read why WhatsApp ends up running the production floor before training starts.

4. Trying to digitise everything at once

Production, stores, quality, purchasing, vendor operations and costing across every line on the same day spreads the team thin, and multiplies the validation work before anything is live. One line validated and running is worth more than five lines half configured.

5. Unclear BOM and routing ownership

If nobody owns the BOM, the routing and the inspection plan in the system, they drift away from the approved documents: engineering releases a new drawing, the routing still carries the old check, and a batch is made to the wrong revision. Name an owner for each and tie changes in the system to your existing change control, so the system never runs ahead of, or behind, the approved document.

6. No pilot, or a pilot with no end

Switching the machining cells, the cleanroom and the vendor steps over together means a missing characteristic or a wrong role shows up in every batch at once. One pilot line, with one product family, surfaces those gaps while they are few. Set the condition and the date for ending it, though: a pilot that runs beside the paper traveller indefinitely becomes a second record nobody trusts, and a parallel record is itself an audit question.

7. Measuring software usage instead of operational outcomes

Logins and entry counts show that people are using the system. They do not show whether batch records are better or traces faster. Track the batch record and trace measures below instead.

After go-live: what to measure

• The time from the last operation to a batch record ready for QA review.
• Findings at batch record review: missing entries, missing instruments, unexplained corrections.
• The time taken to answer a complaint trace from unit to material lot.
• Held batches waiting for a disposition, and how long they wait.
• Rejection by operation and cause, reviewed weekly.
• Short returns from anodising or sterilisation caught on the batch, not at packing or month end.

The share of entries made at the station rather than added later is worth watching in the first weeks, as an early sign the outcomes will follow. For how the full flow runs once the plant is live, see FleekERP for medical device makers. FleekERP keeps the audit trail; it is not validated for ISO 13485 or 21 CFR Part 11, and the validation and certification remain the plant's.