บล็อก ·
การออกแบบระบบหน้างานโรงงานให้ทำงานแบบออฟไลน์ — เมื่อ Wi-Fi หลุดคือสิ่งที่ต้องยอมรับตั้งแต่ต้น
เอาระบบหน้างานโรงงานบนมือถือไปใช้จริงในโรงงานที่ประเทศไทย และ Wi-Fi ของสายการผลิตจะหลุดที่จุดใดจุดหนึ่งแน่นอน — ระหว่างชั้นเหล็ก หลังเครื่องจักรใหญ่ อีกด้านของกำแพงคอนกรีต และในบางไซต์ ช่วงพักเที่ยง พนักงาน 200 คนหยิบโทรศัพท์พร้อมกัน ทำให้สาย uplink ที่แชร์กันบางลงไป 20 นาทีเต็ม ๆ
ถ้าออกแบบระบบโดยสมมติว่าเน็ตต่อเสถียรตลอด สายการผลิตจะหยุดหลัง go-live คอลัมน์นี้เป็นบันทึกของนักพัฒนาจากงานโรงงานหลายแห่งในไทย — รวมถึง ระบบสแกน QC สายการส่งของออก — ว่าเราออกแบบระบบหน้างานโรงงานให้มองว่า "เน็ตหลุด" คือสถานะปกติ ไม่ใช่ข้อยกเว้น อย่างไร โดยเล่าผ่านฉากจริงที่เจอในหน้างาน
ก่อนอื่น — 3 รูปแบบความล้มเหลวที่เกิดขึ้นซ้ำ ๆ
แม้ระบบที่บอกว่า "สร้างให้รองรับออฟไลน์แล้ว" ก็ยังเจอความล้มเหลว 3 รูปแบบที่ต่างกันหลังเริ่มใช้งานจริง
1. หน้าจอค้างทันทีที่เน็ตหลุด
พนักงานสแกน กด "ยืนยัน" แล้ว spinner ที่กลางจอหมุนไปเรื่อย ๆ ไม่หยุด อยากไปกล่องถัดไป แต่ระบบไม่ยอมให้ไป รอ 30 วินาที ยอมแพ้ รีเฟรชหน้าจอ — และสแกนก่อนหน้าหายไป
เกิดจากการที่ระบบแค่ "รอเซิร์ฟเวอร์ตอบ" เงียบ ๆ พอเน็ตหลุด การรอนั้นก็ไม่มีวันจบ ในมุมมองพนักงาน ระบบทั้งระบบ "เงียบเฉย" ไปเฉย ๆ
2. ดูเหมือนใช้งานได้ แต่จริง ๆ ไม่มีอะไรถูกบันทึกเลย
อันนี้แย่กว่าอันแรก พนักงานสแกน เห็นหน้าจอยืนยัน เดินหน้าต่อ คิดว่าตัวเองทำงานสมบูรณ์แบบ 1 ชั่วโมงถัดมา ผู้จัดการดูแดชบอร์ดในออฟฟิศ — 1 ชั่วโมงที่ผ่านมามีสแกน 0 รายการ
ในเบื้องหลัง ระบบเขียนลงหน่วยความจำของเครื่องเท่านั้น ไม่มีอะไรถึงเซิร์ฟเวอร์เลย และหน้าจอของพนักงานก็ไม่ได้บอกอะไรว่ามีปัญหา ถึงจุดนี้ อาจจะมีรถบรรทุกที่บรรจุกล่องซึ่งไม่มีบันทึกการตรวจสอบใด ๆ ในระบบ ออกจากโรงงานไปแล้ว
3. เมื่อสัญญาณกลับมา ข้อมูลซ้ำหรือถูกทับเงียบ ๆ
เน็ตกลับมาต่อ และสแกนที่คิวไว้ทั้งหมดออกไปพร้อมกัน ข้อผิดพลาดที่เจอเป็นประจำมี 2 อย่าง หนึ่ง — พนักงานที่กดปุ่มส่งซ้ำ ๆ เพราะคิดว่าไม่ทำงาน ทำให้เซิร์ฟเวอร์บันทึกสแกนเดียวกัน 2 - 3 ครั้ง สอง — ผู้จัดการอัปเดตข้อมูลมาสเตอร์ในออฟฟิศระหว่างที่สายออฟไลน์ และสำเนาเก่าจากมือถือทับข้อมูลใหม่เงียบ ๆ ตอนซิงค์
ทั้งสามเกิดคนละที่ จึงต้องแก้แยกกัน ต่อไปนี้คือวิธีที่เราสร้างระบบหน้างานโรงงานให้จัดการทั้งสามได้
วิธีที่ 1. ให้ทุก action มี "หมายเลขประจำตัว" ที่ตัดสินโดยเครื่อง ก่อนส่ง
เมื่อพนักงานยืนยันการสแกน 1 ครั้ง รายงาน 1 ครั้ง อนุมัติ 1 ครั้ง แอปจะกำหนดหมายเลขประจำตัวที่ไม่ซ้ำใครให้กับ action นั้น ในเครื่อง ทันที ก่อนส่ง
เมื่อ action ถึงเซิร์ฟเวอร์ กฎคือ: "ถ้ามี action ที่มีหมายเลขเดียวกันบันทึกไว้แล้ว ไม่ต้องทำอะไรอีก" กดปุ่มส่ง 3 ครั้งเพราะรีบ retry การเชื่อมต่อทำให้ request เดียวกันถึง 2 ครั้ง — เซิร์ฟเวอร์ก็บันทึกเพียง 1 รายการ
จุดสำคัญ: หมายเลขต้องถูกตัดสินที่เครื่อง ไม่ใช่ที่เซิร์ฟเวอร์ ถ้าออกแบบเป็น "เครื่องขอหมายเลขจากเซิร์ฟเวอร์ก่อน แล้วค่อยส่ง" ตอนเน็ตหลุด แอปก็เริ่ม action ไม่ได้ด้วยซ้ำ กลไกออฟไลน์ที่สร้างไว้อย่างอื่นทั้งหมดจะพังตั้งแต่ก้าวแรก
วิธีที่ 2. อย่าบอกพนักงานว่าเน็ตหลุด
การใส่ไอคอน "ออฟไลน์" บนหน้าจอ ดูเหมือนช่วยเหลือ แต่ในหน้างานโรงงานมักส่งผลตรงข้าม
พนักงานที่สแกนกล่องตั้งแต่เช้าถึงเย็น ไม่ควรถูกบังคับให้เช็คว่า "ตอนนี้เน็ตต่ออยู่ไหม" ระหว่างการสแกนทุกครั้ง เมื่อเริ่มสงสัยว่า "error นี้เกิดจากฉันหรือเกิดจากเน็ต?" จังหวะทั้งสายการผลิตช้าลง จากประสบการณ์จริง เคยเกิดกรณีที่พนักงานเริ่มไม่เชื่อแอป และจดลงกระดาษ "เผื่อไว้" ควบคู่กัน — จุดประสงค์ครึ่งหนึ่งของระบบที่ติดตั้งไว้หายไปทันที
วิธีของเราตรงข้าม เอาสถานะออนไลน์/ออฟไลน์ออกจากหน้าจอพนักงานทั้งหมด เมื่อสแกนและกด "ยืนยัน" action ถูกบันทึกในเครื่องอย่างปลอดภัย หน้าจอเดินหน้าต่อทันที ในเบื้องหลัง ส่วนอื่นของแอปทำหน้าที่ส่งข้อมูลไปเซิร์ฟเวอร์อย่างเงียบ ๆ ในมุมมองของพนักงาน แอปก็แค่ทำงานอยู่ — เหมือนเดิม เสมอ
แต่ในแดชบอร์ดของออฟฟิศ เราแสดงชัดเจน: "มี 47 สแกนที่ยังไม่ถึงเซิร์ฟเวอร์ อันเก่าที่สุด 12 นาทีก่อน" ผู้ชม 2 กลุ่มต้องการสัญญาณคนละแบบ พนักงานต้องให้สายการผลิตเดินหน้า หัวหน้าต้องรู้เมื่อมี backlog — และรู้ว่าเมื่อไหร่ควรหยุดสายเองก่อนที่ backlog จะอันตราย
วิธีที่ 3. ซิงค์ต่างกันสำหรับข้อมูลต่างชนิด
"เซิร์ฟเวอร์ยอมรับสิ่งที่มาถึงล่าสุด" เขียนง่าย แต่ทำเงินหายในการใช้งานจริง ข้อมูลต่างชนิดต้องมีกฎต่างกัน
ข้อมูลที่เพิ่มอย่างเดียว ไม่เคยแก้
บันทึก inspection ประวัติสแกน รายงานงาน เขียนครั้งเดียวไม่เปลี่ยน ลำดับไม่สำคัญมาก — รายการใหม่แค่เพิ่มเข้าไปในกอง ไม่มีชนกัน ข้อมูลส่วนใหญ่ในระบบโรงงานเป็นแบบนี้ จัดการง่ายสุด
ข้อมูลที่แก้ไขได้
ข้อมูล Part, สิทธิ์ผู้ใช้, ราคา ถ้าใช้ "เขียนหลังชนะ" ที่นี่ ผิดพลาดแบบนี้: 10 โมงเช้า ผู้จัดการในออฟฟิศเปลี่ยนราคา Part A ในเวลาเดียวกัน มือถือที่สายการส่งของออฟไลน์ ยังถือราคาเก่าของ Part A อยู่ในหน่วยความจำ เที่ยง มือถือกลับมาออนไลน์และซื่อสัตย์ส่ง "นี่คือ Part A ที่ฉันมี" — ทับราคาที่ผู้จัดการเปลี่ยนเมื่อเช้าเงียบ ๆ ไม่มีใครสังเกตเห็นเป็นสัปดาห์ จนกระทั่งทีมบัญชีสงสัยว่าทำไมใบแจ้งหนี้ออกด้วยราคาเก่า
วิธีแก้: ติดหมายเลขเวอร์ชันกับทุกเรคคอร์ดที่แก้ไขได้ และปฏิเสธการอัปเดตที่อ้างจากเวอร์ชันเก่ากว่าที่เซิร์ฟเวอร์ถืออยู่
ข้อมูลที่สะสมเพิ่มขึ้น
พนักงาน A ใส่ 5 ชิ้นในกล่อง พนักงาน B ใส่อีก 3 ชิ้นในกล่องเดียวกัน ถ้ามือถือแต่ละเครื่องส่งค่าสัมบูรณ์ — "กล่องนี้มี 5" "กล่องนี้มี 3" — เครื่องที่มาทีหลังจะทับเครื่องแรก และยอดรวมผิด
สำหรับข้อมูลประเภทนี้ ให้ส่งการเปลี่ยนแปลง: "+5" และ "+3" เซิร์ฟเวอร์บวก ลำดับไม่สำคัญ retry ไม่สำคัญ ยอดสุดท้ายถูกต้องเสมอ
วิธีที่ 4. ระหว่างพัฒนา ตัดเน็ตอย่างโหด
การออกแบบทั้งหมดข้างต้นยังไม่พอเอง ต้องลองจริงบนเครื่องจริง โดยตั้งใจตัดเน็ตในจังหวะที่ร้าย
3 สถานการณ์ทดสอบที่เราทำทุกครั้ง:
- ตัดเน็ตกลาง action — ทันทีหลังพนักงานกดส่ง กลางการสแกน จังหวะที่หน้าจอถัดไปกำลังเปลี่ยน จังหวะ "เน็ตไม่น่าจะหลุดตรงนี้" คือจังหวะที่จับ bug ได้
- สะสม action 5 - 10 รายการแบบออฟไลน์ แล้วต่อเน็ตกลับพร้อมกัน — ในหน้างานจริง เกิดตอน Wi-Fi หลุดครึ่งชั่วโมงแล้วกลับมา ทุกอย่างที่สะสมไว้ออกพร้อมกัน ต้องแน่ใจว่าแอปรอด "หิมะถล่ม"
- เครื่อง 2 เครื่อง เรคคอร์ดเดียวกัน ทั้งคู่ออฟไลน์ ทั้งคู่ต่อเน็ตกลับพร้อมกัน — สถานการณ์ที่เจ็บสุดใน production จำลองเจตนาให้เกิดตอนพัฒนา
Bug ที่ "เจอครั้งแรกใน production" ส่วนใหญ่ถูกจับได้ ถ้าคุณตั้งใจไปเจอ 3 pattern นี้ระหว่างพัฒนา ในทางกลับกัน ระบบที่ส่งมอบโดยไม่ผ่าน 3 pattern นี้ จะไปเจอใน production แน่
สรุป
ตอนออกแบบระบบหน้างานโรงงานสำหรับประเทศไทย เริ่มจาก "เน็ตจะหลุด และการหลุดเป็นสถานะปกติ" ไม่ใช่ "เน็ตเสถียรเป็นส่วนใหญ่ บางทีหลุด" การเปลี่ยนสมมติฐานเพียงข้อเดียวนี้ เปลี่ยนทุกการตัดสินใจถัดจากนี้อย่างเป็นธรรมชาติ
4 ข้อข้างต้น — หมายเลขประจำตัวฝั่งเครื่อง ซ่อนออฟไลน์จากพนักงาน กฎซิงค์ต่อชนิดข้อมูล และทดสอบอย่างโหดระหว่างพัฒนา — ประกอบเข้าในระบบตั้งแต่ต้น ลดสายโทรศัพท์ "สายการผลิตหยุดหลัง go-live" ลงมาก โดยเฉพาะในนิคมอุตสาหกรรมรอบกรุงเทพและอีสเทิร์นซีบอร์ด ที่ base station ผิดพลาดในหน้าฝนอาจทำให้ LTE ทั้งบล็อกหลุดครึ่งชั่วโมง ระบบที่สมมติเน็ตสมบูรณ์แบบ ในที่สุดจะถูกทรยศ
ที่เกี่ยวข้อง: ระบบสแกน QC สายการส่งของออก / บริการปรับปรุงการดำเนินงานในโรงงาน
กำลังพิจารณาระบบหน้างานโรงงานสำหรับโรงงานในไทย? ติดต่อเราได้เลย
