เว็บแอปฐานข้อมูลกลางและแดชบอร์ด KPI บน Google Cloud สำหรับผู้ผลิตชิ้นส่วนยานยนต์ในไทย

ที่มาของโจทย์

ลูกค้าต้องการรวมข้อมูลภายในองค์กรไว้ในฐานข้อมูลเดียวบน GCP ของบริษัท แล้วดู KPI หลายด้านได้จากเว็บเดียว ก่อนเริ่มงาน ข้อมูลแต่ละด้านอยู่ในไฟล์รายงานคนละชุดจากหลายระบบ

ลูกค้าต้องการให้พนักงานใช้เว็บเดียวกันทั้งกรอกข้อมูลหน้างานและดูแดชบอร์ด เฟสแรกจึงเริ่มจาก KPI ความสูญเสียภายในและของเสีย แล้วจึงเพิ่มข้อมูลของฝ่ายอื่นในระบบเดียวกัน

ข้อกำหนดและข้อจำกัด

ระบบต้องทำงานบน Google Cloud Platform (GCP) ของลูกค้า และต้องผ่านข้อกำหนดของฝ่ายสารสนเทศของลูกค้า ข้อกำหนดและข้อจำกัดหลักมีดังนี้

• เก็บข้อมูลไว้บน GCP ของบริษัทลูกค้า ภายใต้บัญชีและนโยบายขององค์กร
• ลดภาระการดูแลเซิร์ฟเวอร์ให้น้อยที่สุด จึงวางระบบบนบริการคลาวด์แบบ serverless (ผู้ให้บริการคลาวด์ดูแลเครื่องแม่ข่ายให้) เป็นหลัก
• ผู้ใช้ยังทำไฟล์รายงาน Excel ชุดเดิม และกรอกข้อมูลหน้างานบางส่วนผ่านหน้าเว็บ
• ระบบที่ขึ้นคลาวด์ต้องผ่านแบบตรวจความปลอดภัยของฝ่ายสารสนเทศของลูกค้า และต้องขออนุมัติก่อนติดตั้งทุกครั้ง
• ตอนเริ่มเฟสแรก รูปแบบไฟล์ข้อมูลเข้าและออกยังไม่พร้อม และมีการเปลี่ยนข้อกำหนดระหว่างพัฒนา

ระบบฐานข้อมูลกลางนี้ทำงานอย่างไร

ระบบนี้รับไฟล์รายงานเดิมเข้าฐานข้อมูลเดียว แล้วคำนวณ KPI และแสดงเป็นกราฟกับตารางบนเว็บเบราว์เซอร์ เราเลือกรับไฟล์ตามรูปแบบเดิม เพราะข้อมูลส่วนใหญ่มีอยู่แล้วในไฟล์รายงานชุดเดิม หน้ากรอกบนเว็บจึงเปิดเฉพาะข้อมูลหน้างานที่ยังไม่มีในรายงาน

ลูกค้าต้องการลดงานดูแลเซิร์ฟเวอร์ด้วย ระบบจึงใช้บริการที่ GCP ดูแลให้ เช่น Cloud Run และ Cloud SQL เพื่อลดงานดูแลเครื่องแม่ข่าย ขั้นตอนการทำงานของระบบมีดังนี้

1. 1

   นำข้อมูลเข้าระบบ

   ผู้ใช้อัปโหลดไฟล์รายงาน Excel และไฟล์แผนแก้ไข (PDF) ผ่านหน้าอัปโหลด ส่วนข้อมูลหน้างาน เช่น จำนวนของเสียและผลผลิตรายชั่วโมงของแต่ละ Part No. (รหัสชิ้นงาน) กรอกผ่านหน้า Defect Record Sheet และ Production Today

2. 2

   คำนวณ KPI ให้อัตโนมัติ

   หน้า Overall Summary คำนวณ Internal Loss และอัตราของเสียตามช่วงเวลาที่เลือก รายวัน รายสัปดาห์ รายเดือน หรือรายปี หน้า Business KPI Internal Loss แสดงกราฟแยกกลุ่มผลิตภัณฑ์ มูลค่าเงินที่สูญเสีย และเส้นเป้าที่ตั้งไว้ในหน้าตั้งเป้า KPI

3. 3

   ดูของเสียที่ต้องแก้ก่อน

   แดชบอร์ดของเสียจัดอันดับของเสียที่เกิดมากที่สุด และให้ผู้รับผิดชอบกรอกสาเหตุ แนวทางแก้ และกำหนดเสร็จของรายการอันดับต้น ๆ ได้ ผู้ใช้กดที่จุดบนกราฟเพื่อเปิดไฟล์ PDF ที่แนบไว้ได้

4. 4

   เทียบแผนกับผลผลิตจริง

   หน้า Performance Analysis คำนวณแผนการผลิตจากรอบเวลาการผลิตที่ตั้งไว้ในหน้าข้อมูลหลัก (Master Data) แล้วเทียบกับผลผลิตจริงที่กรอกเข้ามา แยกตามกะ พร้อมบันทึกปัญหาที่ทำให้เสียเวลา

5. 5

   คุมความปลอดภัยตามแบบตรวจของลูกค้า

   งานความปลอดภัยบนคลาวด์ครอบคลุมไฟร์วอลล์เว็บแอป Cloud Armor (WAF) การเข้ารหัส SSL โปรแกรมป้องกันไวรัส ClamAV กติการหัสผ่าน การจำกัดสิทธิ์ผู้ดูแลระบบ บันทึกการเข้าใช้และการทำงาน การสำรองฐานข้อมูล และการแยก GCP สำหรับพัฒนากับใช้งานจริง

สิ่งที่ส่งมอบ

เราส่งมอบเว็บแอปเฟสแรกบน GCP ของลูกค้าในปี 2566 พร้อมคู่มือการใช้งานและเอกสารการดูแลระบบ หน้าหลักของเฟสแรกมีดังนี้

• หน้าภาพรวม (Overall Summary): Internal Loss และอัตราของเสียตามช่วงเวลา
• หน้าอัปโหลดไฟล์รายงาน Excel และไฟล์แผนแก้ไข (PDF)
• หน้าตั้งเป้า KPI และหน้า Business KPI Internal Loss แยกกลุ่มผลิตภัณฑ์
• หน้ากรอกและแดชบอร์ดบันทึกของเสีย (Defect Record Sheet)
• หน้ากรอกผลผลิตรายชั่วโมง (Production Today) และหน้าเทียบแผนกับผลผลิตจริงแยกกะ (Performance Analysis)
• หน้าข้อมูลหลัก (Master Data) และหน้าเข้าสู่ระบบของผู้ใช้

ระบบนี้ขยายจากเฟสแรกเป็นหลายโมดูลอย่างไร

เราขยายระบบนี้โดยเพิ่มโมดูลของแต่ละฝ่ายเข้าไปในเว็บแอปและฐานข้อมูลเดียวกันทีละส่วน แต่ละโมดูลมีขอบเขตและเอกสารความต้องการแยกกัน งานความปลอดภัยเพิ่มการแยก GCP สำหรับพัฒนากับใช้งานจริง และขั้นตอนขออนุมัติก่อนติดตั้ง เพื่อใช้ทดสอบโมดูลใหม่ก่อนขึ้นระบบจริง ลำดับงานมีดังนี้

1. ปี 2566 เฟสแรก: KPI ความสูญเสียภายใน ของเสีย ผลผลิต และข้อมูลหลัก ส่งมอบและลงนามตรวจรับ
2. ปี 2566 ปรับโมดูลความสูญเสียภายใน: แนบไฟล์ PDF ในตาราง อัปโหลดไฟล์จากหน้าตาราง และตรวจข้อมูลที่อัปโหลดเทียบกับรายงานของเสียและรายงานยอดผลิต พร้อมแจ้งเตือนที่หน้าอัปโหลด
3. ปี 2566 โมดูลยอดขายและกำไร: Sales Dashboard (แผน ยอดจริง และส่วนต่าง) Profit Dashboard และ Forecast พร้อมหน้าอัปโหลดและส่งออกข้อมูลตามเทมเพลต
4. ปี 2566 งานความปลอดภัยบนคลาวด์ตามแบบตรวจของฝ่ายสารสนเทศของลูกค้า
5. ปี 2566–2567 โมดูลคุณภาพ: เคลมและข้อร้องเรียนจากลูกค้า เคลมจากตลาด และการตั้งค่าอีเมล อยู่ในรอบปรับแก้และตรวจความถูกต้องของข้อมูลในต้นปี 2567

โมดูลค่าใช้จ่ายของลูกค้ารายเดียวกันเป็นงานแยกอีกเคส อ่านรายละเอียดได้ที่เคสเว็บแอปติดตามค่าใช้จ่ายจริงเทียบเป้ารายแผนก

ผลที่ยืนยันได้จากเอกสารตรวจรับ

ผลที่ยืนยันได้ของเคสนี้คือเฟสแรกส่งมอบแล้ว และมีเอกสารตรวจรับที่ผู้แทนลูกค้าลงนาม ส่วนโมดูลที่เพิ่มภายหลังมีเพียงสรุปสถานะโครงการของเรา เอกสารแต่ละชุดยืนยันเรื่องต่างกันดังนี้

• รายการตรวจรับงาน (Exit Criteria Checklist) ของเฟสแรก: ผู้แทนลูกค้า ผู้ตรวจที่รับผิดชอบ และผู้ลงนามฝั่งเรา ลงนามในเดือนกรกฎาคม 2566
• ใบส่งมอบงาน: ผู้แทนลูกค้าลงนามรับระบบเฟสแรกในเดือนสิงหาคม 2566
• เอกสารปิดเฟสแรก: ระบุคู่มือการใช้งาน เอกสารการดูแลระบบ และรายการตรวจรับที่ลงนามแล้วไว้ในรายการส่งมอบ
• สรุปสถานะโครงการของเรา ณ สิ้นปี 2566: เป็นเอกสารภายในของเรา ไม่ใช่เอกสารตรวจรับของลูกค้า และเป็นแหล่งเดียวที่บอกสถานะของโมดูลต่อยอด

โมดูลที่เพิ่มหลังเฟสแรกยังไม่มีเอกสารตรวจรับที่ลงนาม เราจึงไม่เรียกโมดูลเหล่านี้ว่าผ่านการตรวจรับ รายการแก้ไขเพิ่มเติมหลังตรวจรับเฟสแรกมีรอบทดสอบซ้ำแยกต่างหาก เคสนี้ไม่มีตัวเลขวัดผลทางธุรกิจ เราจึงรายงานเฉพาะผลที่มีเอกสารยืนยัน

สิ่งที่เราเรียนรู้

งานนี้ให้หลักการต่อไปนี้สำหรับงานฐานข้อมูลกลางที่รับข้อมูลจากไฟล์รายงาน

• ตกลงรูปแบบไฟล์ต้นทางก่อนพัฒนา ระบบที่อ่านไฟล์รายงานอ่านค่าตามโครงสร้างไฟล์ ในงานนี้รูปแบบไฟล์ข้อมูลเข้าและออกยังไม่พร้อมตอนเริ่ม และมีการเปลี่ยนระหว่างพัฒนา งานถัดไปจึงควรล็อกคอลัมน์ รหัส และสูตร KPI กับเจ้าของตัวเลข พร้อมไฟล์ตัวอย่างจริง ก่อนเริ่มเขียนระบบ
• ระบบที่รับไฟล์อัปโหลดต้องตรวจข้อมูลเทียบกับรายงานต้นทาง ในงานนี้ ขอบเขตการปรับโมดูลความสูญเสียภายในรวมการตรวจข้อมูลเทียบกับรายงานของเสียและรายงานยอดผลิต พร้อมแจ้งเตือนที่หน้าอัปโหลด เพราะแดชบอร์ดจะใช้ตัดสินใจได้เมื่อตัวเลขตรงกับรายงานที่แต่ละฝ่ายใช้อยู่
• ข้อกำหนดความปลอดภัยของฝ่ายสารสนเทศเป็นส่วนหนึ่งของระบบคลาวด์ ไม่ใช่งานเสริมภายหลัง ระบบที่ขึ้นคลาวด์ขององค์กรต้องตอบแบบตรวจ ตั้งค่าไฟร์วอลล์ เก็บบันทึกการใช้งาน และมีขั้นตอนอนุมัติก่อนติดตั้ง จึงควรรวมไว้ในขอบเขตงานตั้งแต่ต้น

นำแนวทางนี้ไปใช้กับงานของคุณได้อย่างไร

ถ้าองค์กรของคุณมีรายงาน KPI หลายด้านอยู่ในไฟล์ Excel หลายชุด และมีบัญชีคลาวด์ของบริษัทอยู่แล้ว คุณใช้แนวทางเดียวกับเคสนี้ได้ คือรับไฟล์รายงานเดิมเข้าฐานข้อมูลกลาง คำนวณ KPI และแสดงบนเว็บเดียว แนวทางนี้เหมาะเมื่อแต่ละฝ่ายเก็บตัวเลขในไฟล์ของตัวเอง และการดูภาพรวมต้องรอคนรวบรวมรายงานก่อน ส่วนที่ต้องปรับคือรูปแบบไฟล์ สูตร KPI และข้อกำหนดความปลอดภัยขององค์กรคุณ

• เตรียมไฟล์รายงานตัวอย่างจริงของทุกชุด และยืนยันว่าจะคงรูปแบบไฟล์ไว้ได้นานแค่ไหน
• ตกลงสูตร KPI และเกณฑ์เขียว/แดงกับเจ้าของตัวเลขของแต่ละฝ่ายก่อนพัฒนา
• ขอแบบตรวจความปลอดภัยของฝ่ายสารสนเทศตั้งแต่ต้น และรวมไว้ในขอบเขตงาน
• เริ่มจากโมดูลที่ข้อมูลพร้อมที่สุด แล้วเผื่อรอบปรับแก้ตาม feedback ของผู้ใช้ในแต่ละโมดูล