เว็บแอป P-Chart บันทึกของเสียบนเซิร์ฟเวอร์ในโรงงาน สำหรับผู้ผลิตชิ้นส่วนยานยนต์ในไทย
ลูกค้า: ผู้ผลิตชิ้นส่วนยานยนต์ (ในเครือญี่ปุ่น)
P-Chart Control คือเว็บแอปที่ให้ทีมผลิตบันทึกของเสียรายวัน ดูแผนภูมิควบคุมสัดส่วนของเสีย (P-Chart) สรุปของเสีย และส่งออกรายงาน PDF ได้ในระบบเดียว เราพัฒนาและติดตั้งระบบนี้บนเซิร์ฟเวอร์ของโรงงานเอง (On-Premise) ให้ผู้ผลิตชิ้นส่วนยานยนต์ในไทย และลูกค้าลงนามรับงานในเดือนเมษายน 2568
- อุตสาหกรรม
- ยานยนต์
- ปี
- 2567–2568
- ขอบเขตงาน
- ออกแบบ พัฒนา ติดตั้ง และทดสอบเว็บแอป P-Chart Control 1 ระบบบนเซิร์ฟเวอร์ของโรงงาน (ผู้ใช้เข้าระบบและดึงยอดผลิตผ่าน API ของระบบเดิมขององค์กร) ปรับตามคำขอเปลี่ยนแปลงหลายรอบตั้งแต่ ธ.ค. 2567 พร้อมเอกสารการพัฒนา ใบตรวจรับงาน และคู่มือการใช้งาน
- ระยะเวลา
- เริ่ม ก.ย. 2567 ส่งมอบ เม.ย. 2568 และปรับปรุงต่อจนถึงกลางปี 2568
สรุปสั้น
- P-Chart Control คือเว็บแอปที่ให้ทีมผลิตบันทึกของเสียรายวันแยกกะแทนแผ่น P-Chart กระดาษและ Excel แล้วคำนวณเส้นค่าเฉลี่ยและเส้นควบคุมบน (UCL) ให้อัตโนมัติ
- ระบบดึงยอดผลิตจากระบบเดิมขององค์กรผ่าน API (ช่องทางเชื่อมต่อระหว่างระบบ) พนักงานจึงกรอกเฉพาะจำนวนของเสีย
- ระบบติดตั้งด้วย Docker (ชุดติดตั้งซอฟต์แวร์แบบคอนเทนเนอร์) บนเซิร์ฟเวอร์ของโรงงาน (On-Premise) และเก็บข้อมูลใน PostgreSQL (ฐานข้อมูล)
- ผู้ผลิตชิ้นส่วนยานยนต์ในไทยลงนามรับงานในเดือนเมษายน 2568 หลังระบบผ่านรายการตรวจรับ จากนั้นเราปรับปรุงระบบต่อจนปิดงานในปี 2568
- บทเรียนหลักของงานนี้คือคำนึงถึงความเร็วของระบบก่อนความสวยงาม และตกลงกติกาของข้อมูลให้ชัดก่อนเขียนระบบหลังบ้าน
โจทย์หน้างาน
ทีมผลิตจดจำนวนของเสียทุกวันบนแผ่น P-Chart กระดาษร่วมกับไฟล์ Excel แล้วสรุปรายงานเป็นรายเดือน ข้อมูลจึงถูกจดและคัดลอกหลายขั้นก่อนได้รายงานประจำเดือน โรงงานต้องการเว็บแอปที่ทำงานบนเซิร์ฟเวอร์ของโรงงานเอง
สิ่งที่เราทำ
เราพัฒนาเว็บแอป P-Chart Control ด้วย Next.js เก็บข้อมูลใน PostgreSQL (ฐานข้อมูล) และติดตั้งด้วย Docker บนเซิร์ฟเวอร์ของโรงงาน ระบบรับบันทึกของเสียรายวันแยกกะ คำนวณเส้นค่าเฉลี่ยและเส้นควบคุมบน (UCL) ให้อัตโนมัติ สรุปของเสียพร้อม Pareto Chart และส่งออก P-Chart เป็น PDF
ผลลัพธ์
ระบบผ่านรายการตรวจรับ (Exit Criteria) และลูกค้าลงนามในใบส่งมอบและรับงานเดือนเมษายน 2568 หลังส่งมอบ เราปรับปรุงระบบต่อตามคำขอของลูกค้าจนปิดงานในปี 2568
ที่มาของโจทย์
โจทย์คือย้ายงานที่เคยแยกอยู่บนกระดาษและ Excel มาไว้ในเว็บแอปเดียว เว็บแอปนี้ต้องรับบันทึกของเสียแยกตามกะ ไลน์ และชิ้นงาน และเก็บเป้าหมายของเสียทั้งระดับไลน์และระดับองค์กร กราฟ การบันทึกความผิดปกติและการแก้ไข และรายงานต้องใช้ข้อมูลชุดเดียวกันนี้
P-Chart และ UCL คืออะไร
P-Chart (แผนภูมิควบคุมสัดส่วนของเสีย) เป็นเครื่องมือ SPC (การควบคุมกระบวนการเชิงสถิติ) ที่ดูว่าสัดส่วนของเสียแต่ละวันผิดปกติหรือไม่ โดยเทียบกับเส้นค่าเฉลี่ยและเส้นควบคุมบน (UCL: Upper Control Limit) จุดที่เกินเส้นควบคุมบนคือสัญญาณให้หาสาเหตุ เส้น UCL คำนวณจากข้อมูลของกระบวนการเอง จึงไม่ใช่ค่าเป้าหมายของเสียที่โรงงานตั้งไว้
ข้อกำหนดและข้อจำกัด
ระบบต้องทำงานบนเซิร์ฟเวอร์ของโรงงาน และใช้ข้อมูลจากระบบเดิมขององค์กร ข้อกำหนดหลักจากขอบเขตงาน เอกสารความต้องการ และรายการตรวจรับมีดังนี้
- ติดตั้ง 1 ระบบบนเซิร์ฟเวอร์ของโรงงาน (On-Premise) ด้วย Docker บน Ubuntu Server และเก็บข้อมูลใน PostgreSQL
- ผู้ใช้เข้าระบบผ่าน API ของระบบเดิมขององค์กร
- ยอดผลิตที่ใช้คำนวณสัดส่วนของเสียดึงจากระบบเดิมผ่าน API ส่วนจำนวนของเสียให้พนักงานกรอก
- ประเภทของเสีย (Defect Type) เป็นรายการคงที่ที่ระบบกำหนด ผู้ใช้เพิ่มรายการของเสีย (Defect Mode) ภายใต้ประเภทเหล่านั้นเอง
- ระบบต้องเก็บประวัติการบันทึกทุกครั้ง และรายการที่ลบต้องถูกซ่อนจากหน้าจอ
- ผู้ใช้ตั้งเป้าหมายของเสียได้ทั้งระดับไลน์และระดับองค์กร
- ข้อมูลทดสอบที่ไม่ครบถูกระบุเป็นปัจจัยเสี่ยงในขอบเขตงาน
ระบบนี้คำนวณ P-Chart จากข้อมูลอะไร
ระบบคำนวณ P-Chart จากจำนวนของเสียที่พนักงานกรอกในแต่ละกะ และยอดผลิตที่ดึงจากระบบเดิมของโรงงานผ่าน API ระบบนำสองค่านี้มาคำนวณสัดส่วนของเสียรายวัน เส้นค่าเฉลี่ย และเส้นควบคุมบน (UCL) ตามสูตรในเอกสารความต้องการ แล้วแสดงเป็นกราฟ
กราฟ หน้าสรุป และรายงาน PDF อ่านจากฐานข้อมูลชุดเดียวกัน ข้อมูลจึงบันทึกครั้งเดียวที่หน้างาน แทนการคัดลอกหลายขั้นแบบเดิม หน้าจอพัฒนาด้วย Next.js และ Ant Design (เครื่องมือพัฒนาเว็บแอป) พนักงานจึงเปิดใช้งานผ่านเว็บเบราว์เซอร์
- 1
ตั้งค่าข้อมูลหลัก
ในหน้าตั้งค่าข้อมูลหลัก (Master Data) ผู้ใช้ลงทะเบียนรายการของเสียของแต่ละไลน์และชิ้นงาน ภายใต้ประเภทของเสียที่ระบบกำหนดไว้ รวมถึงเป้าหมายของเสียระดับไลน์และระดับองค์กร
- 2
บันทึกของเสียรายวัน
พนักงานเลือกวันที่ กะ ไลน์ และชิ้นงาน แล้วกรอกจำนวนของเสียลงตาราง ระบบเก็บประวัติการบันทึกทุกครั้งไว้ให้ค้นหา แก้ไข หรือลบได้ โดยรายการที่ลบจะถูกซ่อนจากหน้าจอ
- 3
คำนวณ P-Chart ให้อัตโนมัติ
ระบบนำจำนวนของเสียเทียบกับยอดผลิตจากระบบเดิม คำนวณสัดส่วนของเสียรายวัน เส้นค่าเฉลี่ย และเส้นควบคุมบน (UCL) แล้วแสดงเป็นกราฟ
- 4
บันทึกความผิดปกติและการแก้ไข
เมื่อของเสียเกินเกณฑ์ ผู้รับผิดชอบบันทึกปัญหา สาเหตุ และการแก้ไขในตาราง Abnormal Occurrence & Action Record (บันทึกความผิดปกติและการแก้ไข) ที่ผูกกับวันและชิ้นงานนั้น
- 5
สรุปผลและส่งออกรายงาน
หน้าสรุปแสดงของเสียรายวัน รายเดือน และรายปี พร้อม Pareto Chart (กราฟเรียงรายการของเสียจากมากไปน้อย) และส่งออก P-Chart เป็น PDF หรือส่งออกตารางเป็นไฟล์ CSV (ไฟล์ตารางที่เปิดด้วย Excel ได้)
สิ่งที่ส่งมอบ
เราส่งมอบเว็บแอป P-Chart Control 1 ระบบบนเซิร์ฟเวอร์ของโรงงาน หน้าจอครบตามขั้นตอนข้างต้น ตั้งแต่ข้อมูลหลักจนถึงการส่งออกรายงาน นอกจากเว็บแอป งานส่งมอบมีรายการดังนี้
- ชุดติดตั้ง Docker และฐานข้อมูล PostgreSQL บน Ubuntu Server ของโรงงาน
- การเชื่อมต่อ API ของระบบเดิมขององค์กร สำหรับการเข้าระบบและการดึงยอดผลิต
- เอกสารการพัฒนา
- ใบตรวจรับงาน
- คู่มือการใช้งาน
ขั้นตอนดำเนินงานและคำขอเปลี่ยนแปลง
เราพัฒนาเว็บแอป P-Chart Control ตั้งแต่เดือนกันยายน 2567 ส่งมอบในเดือนเมษายน 2568 และปรับปรุงต่อจนถึงกลางปี 2568 ระหว่างพัฒนา ลูกค้าส่งคำขอเปลี่ยนแปลง (Change Requirement) หลายรอบ ทุกรอบถูกบันทึกในเอกสารคำขอเปลี่ยนแปลงที่ปรับรุ่นตามรอบ ลำดับงานมีดังนี้
- ก.ย. 2567: เริ่มออกแบบและพัฒนาตามขอบเขตงานและเอกสารความต้องการ
- ตั้งแต่ ธ.ค. 2567: ปรับระบบตามคำขอเปลี่ยนแปลง เช่น ประวัติการบันทึก การลบแบบซ่อนรายการ และเป้าหมายระดับองค์กร
- เม.ย. 2568: ระบบผ่านรายการตรวจรับ ลูกค้าส่งคำขอเปลี่ยนแปลงอีกรอบเรื่องการรวมยอดเมื่อหลายคนกรอกของเสียรายการเดียวกัน และลงนามในใบส่งมอบและรับงาน
- หลังส่งมอบถึงกลางปี 2568: ปรับปรุงระบบต่อ เช่น เพิ่มรายการของเสียใหม่ในข้อมูลหลัก และปรับการกรอกเป้าหมายระดับองค์กร
ผลที่ยืนยันได้จากการตรวจรับ
ผลที่ยืนยันได้ของเคสนี้คือการตรวจรับและการลงนามรับงาน เว็บแอป P-Chart Control ผ่านรายการตรวจรับ (Exit Criteria) และผู้ผลิตชิ้นส่วนยานยนต์รายนี้ลงนามในใบส่งมอบและรับงานในเดือนเมษายน 2568 รายการตรวจรับครอบคลุมประวัติการบันทึก การลบแบบซ่อนรายการ และเป้าหมายระดับองค์กร ซึ่งมาจากคำขอเปลี่ยนแปลงระหว่างพัฒนา
หลังส่งมอบ ลูกค้าให้เราปรับปรุงระบบต่อจนปิดงานในปี 2568 เคสนี้ไม่มีตัวเลขวัดผลทางธุรกิจ เช่น เวลาทำรายงานหรือจำนวนของเสียที่ลดลง เราจึงรายงานเฉพาะผลที่มีเอกสารยืนยัน
สิ่งที่เราเรียนรู้
งานนี้ให้หลักการสำหรับระบบบันทึกข้อมูลคุณภาพรายวันดังนี้
- ความเร็วของระบบมาก่อนความสวยงาม บทเรียนที่ทีมสรุปหลังปิดงานคือต้องคำนึงถึงความเร็วในการทำงานของระบบก่อนความสวยงาม หน้าบันทึกและหน้ากราฟของระบบที่ออกแบบให้บันทึกทุกวันจึงควรทดสอบความเร็วกับข้อมูลจริงก่อนปรับหน้าตา
- ตกลงกติกาของข้อมูลก่อนเขียนระบบหลังบ้าน คำขอเปลี่ยนแปลงเรื่องประวัติการบันทึก วิธีลบ และเป้าหมายระดับองค์กรเกิดขึ้นระหว่างพัฒนา และเมื่อขอบเขตเปลี่ยนจนต้องแก้ระบบหลังบ้าน (Backend) งานใช้เวลานานขึ้น
- P-Chart ถูกต้องได้เท่ากับยอดผลิตที่ใช้คำนวณ การดึงยอดผลิตจากระบบเดิมผ่าน API ทำให้พนักงานกรอกเฉพาะของเสีย และยอดผลิตมาจากระบบเดียวกับที่องค์กรใช้อยู่
นำแนวทางนี้ไปใช้กับโรงงานของคุณได้อย่างไร
ถ้าโรงงานของคุณยังจดของเสียลงกระดาษร่วมกับ Excel และใช้ P-Chart ติดตามสัดส่วนของเสีย คุณใช้แนวทางเดียวกับเคสนี้ได้ คือบันทึกของเสียครั้งเดียวที่หน้างาน ดึงยอดผลิตจากระบบที่มีอยู่ แล้วให้ระบบคำนวณกราฟ สรุป และรายงาน ส่วนที่ต้องปรับคือแหล่งยอดผลิต วิธีเข้าระบบ และแบบฟอร์มรายงานของโรงงานคุณ
ส่วนที่ใช้ซ้ำได้ และส่วนที่ต้องปรับ
| ส่วนของระบบ | ใช้ซ้ำได้ | ต้องปรับเมื่อ |
|---|---|---|
| การบันทึกของเสีย | หน้าบันทึกรายวันแยกกะ ไลน์ และชิ้นงาน พร้อมประวัติการบันทึก | รายการของเสียและประเภทของเสียของโรงงานคุณต่างจากเคสนี้ ต้องตั้งค่าข้อมูลหลักใหม่ |
| ยอดผลิต | การดึงยอดผลิตจากระบบเดิมผ่าน API | โรงงานยังไม่มีระบบที่ส่งยอดผลิตผ่าน API ต้องตกลงแหล่งข้อมูลหรือวิธีนำเข้าก่อน |
| การคำนวณ P-Chart | การคำนวณเส้นค่าเฉลี่ยและเส้น UCL ให้อัตโนมัติ | โรงงานใช้สูตรหรือรอบการคำนวณต่างจากเคสนี้ ต้องระบุสูตรในเอกสารความต้องการ |
| การเข้าระบบ | การล็อกอินผ่าน API ของระบบเดิมขององค์กร | องค์กรใช้ระบบยืนยันตัวตนแบบอื่น ต้องออกแบบการเชื่อมต่อใหม่ |
| การติดตั้ง | Docker และ PostgreSQL บนเซิร์ฟเวอร์ของโรงงาน | เซิร์ฟเวอร์ภายในยังไม่พร้อม ต้องวางแผนกับทีมไอทีของโรงงานก่อน |
| รายงาน | การส่งออก P-Chart เป็น PDF และตารางเป็นไฟล์ CSV | แบบฟอร์มรายงานของโรงงานคุณต่างออกไป ต้องส่งตัวอย่างแบบฟอร์มให้ตรวจก่อนออกแบบ |
- ตรวจว่ายอดผลิตจะมาจากระบบไหน และขอสิทธิ์เชื่อมต่อ API ตั้งแต่ต้น
- เตรียมรายการของเสีย สูตรคำนวณ และตัวอย่างข้อมูลจริงไว้ทดสอบ
- จองเซิร์ฟเวอร์ภายในกับทีมไอทีของโรงงานล่วงหน้า
- ตกลงวิธีจัดการคำขอเปลี่ยนแปลงไว้ตั้งแต่เริ่มโครงการ
อ่านต่อ
- บริการพัฒนาระบบตรวจสอบและควบคุมเฉพาะงาน
- บริการเชื่อมข้อมูลและพัฒนา AI สำหรับองค์กร
- InQC โปรแกรม SPC บนแท็บเล็ต Android สำหรับค่าที่วัดได้
- บทความ: SPC และ P-Chart คืออะไร ผู้จัดการโรงงานอ่านกราฟควบคุมอย่างไร
- บทความ: On-Premise หรือ Cloud ข้อมูลโรงงานควรอยู่ที่ไหน
- เคสย้ายเว็บข้อมูลการผลิตขึ้นเซิร์ฟเวอร์กลางสำหรับผู้ผลิตชิ้นส่วนยานยนต์
- เคสต้นแบบบอร์ดแผนเทียบผลผลิตรายวัน
เทคโนโลยีที่ใช้
คำถามที่พบบ่อย
ระบบนี้ต้องส่งข้อมูลขึ้นคลาวด์ไหม
ไม่ต้อง ในเคสนี้ระบบติดตั้งด้วย Docker บนเซิร์ฟเวอร์ของโรงงาน และเก็บข้อมูลในฐานข้อมูล PostgreSQL บนเครื่องนั้น พนักงานเปิดใช้งานผ่านเว็บเบราว์เซอร์ และเข้าระบบผ่าน API ของระบบเดิมขององค์กร
ยอดผลิตที่ใช้คำนวณ P-Chart มาจากไหน
ในเคสนี้ระบบดึงยอดผลิตจากระบบเดิมของโรงงานผ่าน API ส่วนจำนวนของเสียให้พนักงานกรอกตามรายการของเสียที่ตั้งค่าไว้ แล้วระบบคำนวณสัดส่วนของเสีย เส้นค่าเฉลี่ย และเส้นควบคุมบนให้เอง
ถ้าหลายคนกรอกของเสียรายการเดียวกันจะเป็นอย่างไร
ระบบที่ผ่านการตรวจรับเก็บประวัติการบันทึกทุกครั้ง และรายการที่ลบจะถูกซ่อนจากหน้าจอ ส่วนการรวมยอดเมื่อหลายคนกรอกของเสียรายการเดียวกันเป็นคำขอเปลี่ยนแปลงรอบเดือนเมษายน 2568 ซึ่งกำหนดให้ระบบตรวจยอดล่าสุดก่อนบันทึกแล้วบวกยอดต่อกัน เพื่อไม่ให้ทับค่าของอีกคน
ระบบนี้ต่างจาก InQC อย่างไร
P-Chart Control เป็นเว็บแอปที่พัฒนาเฉพาะงานสำหรับนับสัดส่วนของเสียตามแบบฟอร์มของโรงงานนี้ ส่วน InQC เป็นโปรแกรม SPC บนแท็บเล็ต Android สำหรับบันทึกค่าที่วัดได้ เช่น ขนาดชิ้นงาน ถ้าโจทย์ของคุณคือการวัดค่า ให้ดู InQC ถ้าเป็นการนับของเสียตามแบบฟอร์มเฉพาะของโรงงาน งานพัฒนาระบบเฉพาะแบบเคสนี้จะเหมาะกว่า
ราคาและระยะเวลาพัฒนาเท่าไร
ไม่มีราคาตายตัว ขึ้นกับจำนวนหน้าจอ สูตรคำนวณ และระบบที่ต้องเชื่อมต่อ เคสนี้เริ่มพัฒนาในเดือนกันยายน 2567 และส่งมอบในเดือนเมษายน 2568 ติดต่อเราพร้อมแบบฟอร์มที่ใช้อยู่เพื่อขอใบเสนอราคา
