ALI BOYACIAI-Driven Development Engineer
← All Posts

I Built a QMS Module Inside an MES Product and Took It Live

10 min read
mesqmsmanufacturingen-10204software-engineering

The last day of a four-month project

I recently took a new Quality Management System module live.

I worked on this project for about four months. I was the only software engineer on the project.

On the go-live day, the first real production data entered the system. Laboratory results arrived. Shipment data was ready. The system then created its first EN 10204 Type 3.1 certificate.

Before this project, one certificate took four to five hours to prepare. After go-live, the quality team said they could complete the same work in about 15 minutes.

This did not happen because PDF generation became faster.

The real work was connecting the full quality process. It starts with raw material. It continues with laboratory tests, production measurements, final checks, packaging, and shipment. The certificate is the last part of this process.

I work at Konzek. I developed this QMS module inside the company's existing MES product.

I handled the process analysis, architecture, backend services, integrations, React screens, data migration, deployment, training, and on-site support.

The data was in many places

There was no single quality system at the start.

Some data was in the ERP. Some data was in another quality application. Product and operation rules were in Excel files. Some production checks were still on paper.

An EN 10204 Type 3.1 certificate needs data from many places:

  • the real shipment,
  • the product and raw-material lots,
  • chemical and mechanical test results,
  • the production route,
  • measurements from production,
  • final visual and dimensional checks,
  • coating and marking information,
  • the correct standard and strength class.

This data does not arrive at the same time. Different teams create it.

Because of this, I did not treat the project as a certificate form.

I modelled the certificate as the final result of the quality process.

I checked assumptions with live data

At the start, I was told that job-order codes showed the production order.

I tested this idea with live data. It was not correct.

The codes showed when the planner added the job orders. They did not show the real operation order.

If I used these codes, the quality plans would have the wrong operation sequence.

The correct route data already existed in another system. I used one source for the planned route and another source for the completed route.

This also removed the need for a new API.

I followed the same method during the project:

  1. Define the assumption.
  2. Test it with live data.
  3. Change the model if the data does not support it.

I had to rebuild the product model

The MES had more than 36,000 product records.

But these were not 36,000 main products. Each operation step of the same product was stored as a separate product record.

This model worked for production tracking. It did not work for a product-level quality plan.

I needed a different structure:

One main product
  → one or more production routes
  → a revision-controlled quality plan
  → a product PFMEA
  → standards and strength-class limits

I created 4,919 main products from the operation records.

The migration also created:

  • 4,440 product quality profiles,
  • 6,013 workflows,
  • 3,931 quality control plans,
  • a separate PFMEA structure for each product.

I did this migration on a running system.

The migration tools supported dry runs. I could see what would change before changing the live data. They were also idempotent. Running the same migration again did not create the same record twice.

We moved to the new product model without stopping the system.

A certificate belongs to a shipment

One important decision was choosing the main record for a certificate.

Using the sales order looked simple. But one order can use several lots. It can also leave the factory in more than one shipment.

The customer receives a shipment, not a production order.

Because of this, I connected the certificate to the shipment note and its lot items. The QMS does not create a random certificate number. It uses the real shipment record.

This model supports:

  • one order sent in several shipments,
  • several products in one shipment,
  • the same product from different raw-material lots,
  • several items inside one customer certificate.

Every line in the document can point back to its shipment, lot, laboratory, and production data.

What is inside the QMS module?

The result is much more than a certificate screen.

The module includes:

  • incoming material control,
  • laboratory requests, results, and approvals,
  • product workflows and quality control plans,
  • PFMEA-based sample plans,
  • measurement entry from shop-floor kiosks,
  • SPC tracking,
  • final visual and dimensional control,
  • packaging and shipment,
  • EN 10204 Type 3.1 certificate generation,
  • document revisions,
  • customer document access.

Some parts run inside a new quality microservice. A separate integration service connects the QMS to the ERP and other quality data sources.

I developed eight main web screens and one shop-floor kiosk. Existing paper forms were moved into digital reports.

The same data can create different certificate layouts. Certificates are available in six languages.

I did not hide missing data

An empty field on a certificate screen does not look good.

The easy solution is to let the user enter any value on the certificate. But this can break traceability.

For example, if a chemical value is missing, the real problem is not the certificate screen. The approved laboratory result for the material lot is missing.

I kept the owner of every value clear:

  • customer and quantity data come from the shipment,
  • raw-material lots come from production and ERP data,
  • chemical and mechanical values come from approved laboratory results,
  • dimensional and visual results come from production or final control,
  • the certificate number comes from the shipment note.

When data is missing, the system shows which source needs a correction.

It does not ask the user to copy the same data into another screen.

For quality software, an empty field is safer than a value with no clear source.

History cannot be added later

The system must keep the history of quality records.

When a measurement, laboratory result, or published certificate changes, the old record is not deleted. The system creates a new revision.

A production plan also keeps the document revision that created it. A later master-data change does not change an old production record.

When a published certificate changes, the certificate number stays the same. The system creates a new document revision. The old version stays in the audit history.

The system can answer more than “What is the current value?”

It can also answer:

  • Where did this value come from?
  • Who entered it?
  • Who approved it?
  • Which document revision was used?
  • Which certificate version did the customer receive?

This needed more work than a normal CRUD screen. But a QMS needs this history.

Not every shipment follows the same path

Normal production can use the full quality chain:

Raw material
→ Laboratory
→ Production plan
→ Operator measurements
→ Final control
→ Packaging
→ Shipment
→ Certificate

But some shipments do not have a full production history.

This can happen with commercial products, older orders, or urgent shipments. If I blocked every case, users would go back to Excel.

I designed three paths:

  • a full path with sample-level traceability,
  • a standard path with a final-control record,
  • a direct certificate path when no production record is expected.

The interface shows what each path contains.

The fast path does not pretend to have full traceability. Its limits are clear.

I made the certificate flow simpler

The first version had many steps.

The user had to prepare the certificate, choose a language, select a layout, edit the document, publish it, and download it.

Each step had a technical reason. But the flow was slow for the user.

During testing, a quality user asked a simple question:

“I can see it on the left. Why can I not download it?”

The user was right.

I moved the work into one window. The user opens the certificate and sees the real document. They can update document-only fields, choose the language and layout, and download the PDF.

Publishing, revision control, and audit records continue in the background.

I also improved the slowest queries. Some list screens took about 30 seconds to open. I reduced this time to about 1.5 seconds.

On a shop-floor system, 30 seconds is not a small technical problem. It can decide if people use the system or avoid it.

What did I own as the sole engineer?

I did not work on only the backend or frontend.

I was responsible for:

  • process analysis with production and quality teams,
  • live-data analysis,
  • domain and data-model design,
  • the quality microservice,
  • ERP and quality-system integrations,
  • React office and kiosk screens,
  • PDF and Excel reports,
  • certificate generation in six languages,
  • data-cleaning and migration tools,
  • roles, permissions, approvals, and revision rules,
  • tests with real production cases,
  • live-server setup and deployment,
  • on-site support after go-live,
  • user training and the user guide.

A database field can have one meaning for a developer and another meaning for a laboratory user.

Working on every layer helped me find these differences early.

What evidence do I have?

The numbers in this project are not estimates.

They come from live-data measurements, migration reports, Git history, go-live records, and feedback from real users.

Some recorded results are:

  • 36,634 operation-level product records were analysed.
  • 34,165 job orders were checked.
  • 4,919 main products were created.
  • 4,440 product quality profiles were built.
  • 6,013 workflows were created.
  • 3,931 quality control plans were prepared.
  • 118 standard and strength-class specifications were checked from the source standards.
  • Eight main screens and one shop-floor kiosk were developed.
  • The system creates certificates in six languages.
  • The Git history has about 600 commits and more than 100 merge requests.
  • I prepared a 43-page user guide with real screens and flows.
  • The first real certificate was created on the go-live day.
  • The quality team reported that preparation time went from 4–5 hours to about 15 minutes.
  • List screens that took about 30 seconds now open in about 1.5 seconds.

What did I learn?

Developing the code was not the hardest part.

The hard part was understanding how different teams used the same data.

My main lessons were:

  1. Do not build a data model from an assumption that was not tested.
  2. Traceability must start with the source data.
  3. A fast path must show which records it does not have.
  4. Missing data should be fixed at its real source.
  5. A migration must be measurable and safe to run again.
  6. Users should not need to understand the internal states of the system.

I was the only software engineer from analysis to go-live.

If the data model was wrong, I had to fix it. If an integration failed, I had to find the reason. If a screen was slow or a certificate used the wrong data, I was responsible for the result.

At the end of four months, I did not deliver only a new feature.

I added a real QMS module to an existing MES product and took it live at its first customer.