Web App · 2026 · 4 months
QC Apps — NCR & Quality Disposition System
A thesis project building a Flutter and Spring Boot Non-Conformance Report system for PT. Ohgishi Indonesia, with a Fuzzy Logic engine that gives QA consistent, objective repair, rework, or scrap recommendations instead of manual, subjective paper-based decisions.
- Mobile Development
- Backend Development
- Algorithm Design
Overview
This is my undergraduate thesis (skripsi) at Universitas Bhayangkara Jakarta Raya: an intelligent Non-Conformance Report (NCR) system built for PT. Ohgishi Indonesia, a manufacturer producing structural components (like excavator main frames) that has to meet ISO 9001:2015 quality traceability standards. I designed and built the system solo — mobile app, backend, and the decision-support algorithm at its core — over roughly four months on-site at the company.
The system does two things at once: it replaces a paper-based NCR process with a real-time digital one, and it embeds a Fuzzy Logic decision-support engine that recommends whether a defective product should be repaired, reworked, or scrapped — turning a judgment call that used to vary by inspector into a consistent, rule-based recommendation.
The Challenge
Quality control on a manufacturing floor runs on a document called a Non-Conformance Report (NCR) — the record of what went wrong with a product and what happens to it next. At PT. Ohgishi Indonesia, that record was still paper-based.
Paper-based NCR reporting causes slow data processing, physical document loss, and latency moving information between departments — but the real bottleneck was something else: inconsistent, subjective disposition decisions.
The clearest example from the field: two inspectors looking at the same scratch might disagree — one calls it a minor defect that just needs a repair, the other calls it a major defect requiring a full rework. That inconsistency isn’t just an annoyance; it wastes resources on unnecessary rework, or worse, lets a product through that later fails and has to be scrapped anyway.
Digitizing the paperwork alone doesn’t fix that — a faster form is still a subjective form. The project’s core bet was that Fuzzy Logic, which can reason in degrees (“slightly severe,” “moderately available”) instead of forcing a defect into a rigid category, was a better match for how quality inspectors actually think than a simple digital checklist would be.
Research objectives
- Build an NCR information system that manages non-conformance data and the disposition process in one integrated place.
- Design and implement a Fuzzy Logic model for disposition decisions, built around the quality criteria PT. Ohgishi Indonesia actually uses.
- Embed that decision-support model directly into the NCR workflow, so QA and Managers get faster, more standardized recommendations without losing the ability to make the final call.
Technical Implementation
Architecture & stack
The system follows a Model-View-Controller (MVC) pattern, built using the Rapid Application Development (RAD) methodology so the workflow could be validated with actual QC/QA staff early and often:
- Flutter (Dart) — cross-platform client app used by all four roles.
- Firebase (Realtime Database & Storage) — real-time data sync across departments and storage for defect photos and signatures.
- Java Spring Boot — server-side service responsible for generating standardized, audit-ready PDF reports.
Role-based workflow
Every user sees only what their role needs, enforced through Role-Based Access Control (RBAC):
- Staff QC — reports defects directly from the shop floor: severity/cost/availability ratings, defect photos, and product details.
- Staff QA — reviews pending NCRs, sees the fuzzy engine’s disposition recommendation, and can either accept it or override it manually.
- Staff Production — receives the approved disposition instruction and updates execution status (repair performed, root cause, preventive action) in real time.
- Manager — oversees the full document lifecycle end-to-end and can export the finalized report as an audit-ready PDF.
The Fuzzy Logic decision engine
This was the technical core of the thesis. The engine uses Mamdani Fuzzy Logic across three input variables, each with three linguistic sets:
- Severity — Minor / Moderate / Major
- Cost — Low / Medium / High
- Availability (of materials/machine) — Low / Medium / High
With 3 variables × 3 sets each, the rule base needed 27 expert-defined rules (a full 3×3×3 permutation), each mapping a combination like “Minor severity AND Low cost AND High availability → Repair” to a disposition outcome. The engine resolves these using the Centroid of Area (COA) defuzzification method to produce a single numeric recommendation score alongside the suggested disposition — while QA always retains the authority to override it.
Results
The system was validated with Black-box testing, checking end-to-end behavior against the specification rather than internal code structure. All tested functional flows passed:
- RBAC login — each role was correctly routed to its own dashboard (QC, QA, PROD, or Manager), with unauthorized/incorrect credentials consistently rejected.
- NCR creation — severity/cost/availability sliders and photo uploads saved correctly to Firebase without data loss.
- QA override authority — when QA chose to override a fuzzy recommendation (e.g., the engine suggested “Scrap” but QA chose “Rework” for a specific business reason), the manual decision was accepted and carried forward correctly.
- Cross-department sync — when Production marked a repair as complete, every relevant dashboard updated to “Awaiting Manager Review” in real time via Firebase.
- PDF export — the Spring Boot service correctly pulled all NCR data, defect photos, and digital sign-offs into a single ISO 9001:2015-compliant report.
Impact & Learnings
The finished system replaced a paper trail with a synchronized, role-aware digital workflow, and gave QA a consistent, rule-based starting point for disposition decisions instead of a judgment call made from scratch every time — while keeping a human firmly in the loop to override it.
Two limitations shaped what I’d tackle next. First, severity is still assessed by visual inspection — the system isn’t yet connected to computer vision or IoT sensors that could measure defect severity automatically. Second, the 27-rule base is static, agreed on with PT. Ohgishi Indonesia’s internal experts rather than learned from data, so it can’t yet adapt its own weights as historical repair outcomes accumulate. Both point toward the same next step: pairing the fuzzy engine with computer vision for automatic defect capture and exploring a hybrid ANFIS (Adaptive Neuro-Fuzzy Inference System) so the rule base can eventually train itself on the company’s own NCR history.
Design Process Gallery