ควบคุมคุณภาพงานก่อสร้าง ทำไมใช้มาตรฐานเดียวกัน แต่ผลลัพธ์แต่ละโครงการต่างกัน?
หลายองค์กรมีมาตรฐานการก่อสร้าง มีแบบก่อสร้าง มี Checklist และมีขั้นตอนการตรวจงานที่กำหนดไว้อย่างชัดเจน แต่เมื่อเปรียบเทียบผลลัพธ์ระหว่างแต่ละโครงการ กลับพบว่าคุณภาพของงาน จำนวน Defect หรือระยะเวลาที่ใช้ในการแก้ไขอาจแตกต่างกัน
สาเหตุหนึ่งคือ การมีมาตรฐานไม่ได้หมายความว่ามาตรฐานนั้นจะถูกนำไปใช้ได้เหมือนกันในทุกพื้นที่และทุกขั้นตอนของโครงการ
ระหว่างการก่อสร้างมีข้อมูลเกิดขึ้นตลอดเวลา ตั้งแต่ผลการตรวจงาน รูปภาพหน้างาน รายการงานที่ไม่ผ่าน ผู้รับผิดชอบ กำหนดแก้ไข ไปจนถึงผลการตรวจซ้ำ หากข้อมูลเหล่านี้ไม่ได้ถูกเชื่อมโยงเข้าด้วยกัน ทีมอาจรู้ว่ามีปัญหาเกิดขึ้น แต่ไม่สามารถมองเห็นได้ชัดเจนว่า ปัญหาอยู่ตรงไหน ค้างมานานเท่าไร ใครกำลังรับผิดชอบ และปัญหาลักษณะเดียวกันกำลังเกิดซ้ำในพื้นที่อื่นหรือไม่
ดังนั้น การควบคุมคุณภาพงานก่อสร้างจึงไม่ได้จบอยู่ที่การ “ตรวจให้เจอ” แต่ต้องทำให้ข้อมูลจากการตรวจนำไปสู่การแก้ไข ติดตาม และป้องกันปัญหาในขั้นตอนถัดไปได้ด้วย
การควบคุมคุณภาพงานก่อสร้าง ไม่ได้จบเมื่อการตรวจเสร็จสิ้น
หากมองการควบคุมคุณภาพเป็นเพียงการตรวจผ่านหรือไม่ผ่าน เราจะเห็นข้อมูลเพียงช่วงเวลาหนึ่งของกระบวนการ แต่ในทางปฏิบัติ สิ่งที่เกิดขึ้นหลังจากพบปัญหามีความสำคัญไม่แพ้กัน
ตัวอย่างเช่น เมื่อวิศวกรตรวจพบว่างานส่วนหนึ่งไม่เป็นไปตามมาตรฐาน สิ่งที่ควรเกิดขึ้นต่อจากนั้นคือ ต้องระบุพื้นที่และรายละเอียดของปัญหา ส่งต่อให้ผู้รับผิดชอบ กำหนดระยะเวลาแก้ไข ตรวจสอบซ้ำ และยืนยันว่าปัญหาได้รับการแก้ไขเรียบร้อยแล้ว
หากขั้นตอนใดขั้นตอนหนึ่งขาดหาย งานที่ถูกตรวจพบแล้วก็ยังสามารถกลายเป็นงานค้าง หรือกลับมาเป็นปัญหาในช่วงส่งมอบได้ ดังนั้น การควบคุมคุณภาพที่มีประสิทธิภาพควรทำให้เกิดวงจรต่อเนื่อง
กำหนดมาตรฐาน >> ตรวจสอบ >> บันทึกหลักฐาน >> มอบหมายแก้ไข
>> ติดตาม >> ตรวจซ้ำ >> ปิดงาน >> นำข้อมูลกลับมาวิเคราะห์
เมื่อมองในลักษณะนี้ ข้อมูลจากการตรวจงานจึงไม่ได้มีหน้าที่เพียงยืนยันว่า “ตรวจแล้ว” แต่เป็นข้อมูลที่ช่วยให้องค์กรบริหารคุณภาพได้ตลอดทั้งกระบวนการ
5 แนวทางควบคุมคุณภาพงานก่อสร้างให้เกิดผลจริง
1. เปลี่ยนมาตรฐานในเอกสาร ให้เป็นเกณฑ์ที่ทีมใช้ตรวจงานได้จริง
องค์กรอาจมี Specification หรือมาตรฐานการก่อสร้างที่ละเอียด แต่ผู้ปฏิบัติงานต้องสามารถแปลงมาตรฐานเหล่านั้นให้เป็นขั้นตอนการตรวจที่ชัดเจนได้ ก่อนเริ่มงานจึงควรกำหนดให้ชัดว่า
- งานประเภทนี้ต้องตรวจอะไรบ้าง
- จุดใดเป็น Critical Point ที่ต้องให้ความสำคัญ
- เกณฑ์ใดถือว่าผ่านหรือไม่ผ่าน
- ต้องมีภาพหรือเอกสารใดเป็นหลักฐาน
- ใครเป็นผู้ตรวจและใครเป็นผู้อนุมัติ
- หากไม่ผ่าน ต้องส่งต่อให้ใครดำเนินการ
ยิ่งเกณฑ์เหล่านี้ชัดเจน การตรวจงานก็ยิ่งลดการพึ่งพาการตีความของแต่ละบุคคล ตัวอย่างเช่น หากองค์กรมีหลายโครงการและแต่ละโครงการใช้วิธีตรวจงานกันคนละรูปแบบ แม้ทุกคนจะอ้างอิงมาตรฐานเดียวกัน แต่ข้อมูลที่ได้กลับมาอาจเปรียบเทียบกันไม่ได้
การสร้าง Checklist กลางจึงไม่ได้มีประโยชน์เพียงช่วยให้ “ตรวจครบ” แต่ยังทำให้องค์กรมีโครงสร้างข้อมูลที่เหมือนกัน และสามารถนำผลการตรวจจากหลายโครงการมาวิเคราะห์ร่วมกันได้ในอนาคต
2. บันทึกข้อมูลให้ตอบได้ว่า “เกิดอะไรขึ้น ที่ไหน เมื่อไร และใครรับผิดชอบ”
รูปภาพหน้างานเพียงอย่างเดียวอาจยังไม่ใช่ข้อมูลที่นำไปบริหารต่อได้ หากไม่ทราบว่ารูปนั้นมาจากพื้นที่ใด เกี่ยวข้องกับงานอะไร และถ่ายขึ้นเพื่อบันทึกประเด็นใด
ข้อมูลคุณภาพที่ดีจึงควรมี Context ประกอบ เช่น โครงการ >> อาคาร >> ชั้น >> ห้อง/พื้นที่ >> ประเภทงาน >> วันที่ตรวจ >> ผลการตรวจ >> ผู้รับผิดชอบ
โครงสร้างเหล่านี้ทำให้รูปภาพและรายงานที่เกิดขึ้นทุกวันไม่กลายเป็นเพียงไฟล์จำนวนมาก แต่สามารถค้นหาและนำกลับมาใช้ได้เมื่อต้องการ
เมื่อเกิดข้อสงสัยในภายหลัง ทีมสามารถย้อนกลับไปดูได้ว่า งานบริเวณนั้นผ่านการตรวจเมื่อใด ใครเป็นผู้ตรวจ พบปัญหาอะไร และมีหลักฐานก่อน-หลังการแก้ไขหรือไม่ ยิ่งโครงการมีขนาดใหญ่หรือมีหลายฝ่ายเกี่ยวข้อง ความสามารถในการค้นหาที่มาของข้อมูลยิ่งมีความสำคัญต่อการประสานงานและการตรวจสอบย้อนหลัง
3. ติดตาม Defect ด้วย “สถานะ” ไม่ใช่เพียงรายการปัญหา
การมี Defect List ไม่ได้หมายความว่าองค์กรสามารถบริหาร Defect ได้ดีเสมอไป สิ่งสำคัญกว่าจำนวนรายการ คือการรู้ว่าแต่ละรายการกำลังอยู่ในขั้นตอนไหน
ตัวอย่างสถานะอาจประกอบด้วย พบปัญหา >> มอบหมาย >> อยู่ระหว่างแก้ไข >> รอตรวจซ้ำ >> ผ่านการตรวจ >> ปิดงาน
เมื่อสถานะถูกอัปเดตอย่างต่อเนื่อง ผู้จัดการโครงการจะสามารถแยกได้ว่า งานใดเพิ่งเกิด งานใดอยู่ระหว่างดำเนินการ และงานใดค้างเกินระยะเวลาที่กำหนด
สิ่งนี้ช่วยเปลี่ยน Defect จาก “รายการปัญหาที่เคยพบ” ให้กลายเป็นเครื่องมือสำหรับบริหารงานค้าง และหากมีข้อมูลระยะเวลาเพิ่มเข้ามา ก็สามารถวิเคราะห์ต่อได้อีกว่า Defect ประเภทใดใช้เวลาแก้ไขนาน พื้นที่ใดมีงานค้างสะสม หรือขั้นตอนไหนเป็นคอขวดของกระบวนการ
4. ทำให้ข้อมูลชุดเดียวกันตอบโจทย์คนแต่ละระดับได้
วิศวกร ผู้จัดการโครงการ และผู้บริหาร ไม่จำเป็นต้องเห็นข้อมูลในระดับเดียวกัน วิศวกรอาจต้องการรู้ว่า วันนี้มีงานใดต้องตรวจ และ Defect จุดใดต้องติดตาม ผู้จัดการโครงการอาจต้องการเห็นจำนวนงานค้าง แยกตามพื้นที่ ผู้รับผิดชอบ หรือระยะเวลาที่ค้าง ขณะที่ผู้บริหารอาจต้องการเห็นภาพรวมว่า โครงการใดมีแนวโน้มเกิดปัญหาคุณภาพมากกว่าปกติ จำนวน Defect เพิ่มขึ้นหรือลดลง และมีประเด็นใดที่ควรเข้าไปจัดการ
หัวใจสำคัญจึงไม่ใช่การทำให้ทุกคนเห็น Dashboard เดียวกัน แต่คือ การทำให้ข้อมูลต้นทางชุดเดียวกันสามารถถูกนำเสนอในระดับที่เหมาะกับการตัดสินใจของแต่ละคน เมื่อข้อมูลถูกเชื่อมโยงตั้งแต่หน้างานถึงระดับบริหาร การรายงานก็ไม่จำเป็นต้องเริ่มต้นใหม่ทุกครั้งที่มีการประชุม เพราะสามารถย้อนกลับไปยังข้อมูลต้นทางที่ใช้ประกอบตัวเลขได้
5. เปลี่ยนข้อมูล Defect ให้เป็นความรู้ขององค์กร
หากข้อมูลคุณภาพถูกเก็บไว้เฉพาะรายโครงการ ประโยชน์ของข้อมูลจะสิ้นสุดลงพร้อมกับการปิดโครงการ แต่หากองค์กรเก็บข้อมูลในรูปแบบที่สามารถนำมาเปรียบเทียบกันได้ ข้อมูลเหล่านั้นจะเริ่มตอบคำถามที่มีประโยชน์มากขึ้น เช่น
- งานประเภทใดเกิด Defect บ่อยที่สุด
- ปัญหาประเภทใดเกิดซ้ำหลายโครงการ
- จุดใดในกระบวนการควรเพิ่มการตรวจสอบ
- Defect ประเภทใดใช้เวลาแก้ไขนาน
- ผู้รับเหมาหรือทีมใดมีประเด็นที่ควรติดตามเพิ่มเติม
- ปัญหาใดสามารถป้องกันได้ตั้งแต่ก่อนเริ่มงาน
สมมติว่าองค์กรพบว่า Defect งานกันซึมเกิดซ้ำในหลายโครงการ การวิเคราะห์ข้อมูลอาจนำไปสู่การเพิ่ม Inspection Point ก่อนปิดผิวงาน ปรับ Checklist หรือกำหนดหลักฐานที่ต้องบันทึกเพิ่มเติม นี่คือจุดที่ข้อมูลจากหน้างานเริ่มเปลี่ยนบทบาท จากข้อมูลสำหรับ “รายงานสิ่งที่เกิดขึ้น” ไปสู่ข้อมูลสำหรับ “ป้องกันสิ่งที่ไม่ควรเกิดซ้ำ”
เมื่อจำนวนโครงการเพิ่มขึ้น ปัญหาอาจไม่ใช่ข้อมูลไม่พอ แต่เป็นข้อมูลเชื่อมกันไม่พอ
ในหนึ่งโครงการอาจมีรูปภาพ รายงานตรวจงาน รายการ Defect Checklist และการสื่อสารเกิดขึ้นจำนวนมากในแต่ละวัน หากองค์กรดูแลหลายโครงการพร้อมกัน จำนวนข้อมูลจะเพิ่มขึ้นอีกหลายเท่า Spreadsheet, กลุ่มแชต หรือ Folder กลางยังสามารถเป็นเครื่องมือที่มีประโยชน์ได้ แต่ข้อจำกัดจะเริ่มเห็นชัดเมื่อข้อมูลหนึ่งเรื่องกระจายอยู่หลายช่องทาง
ตัวอย่างเช่น Defect หนึ่งรายการอาจถูกแจ้งผ่านแชต รูปภาพอยู่ในโทรศัพท์ รายการติดตามอยู่ใน Spreadsheet และผลการแก้ไขถูกส่งกลับมาเป็นรูปภาพอีกครั้ง
แต่ละข้อมูลมีอยู่ครบ เพียงแต่การเชื่อมโยงว่า ทั้งหมดเป็นเรื่องเดียวกัน ต้องอาศัยคนเป็นผู้รวบรวม เมื่อจำนวนโครงการและผู้เกี่ยวข้องเพิ่มขึ้น ภาระของทีมจึงไม่ได้อยู่ที่การสร้างข้อมูลเพียงอย่างเดียว แต่รวมถึงการรวบรวม ตรวจสอบ และสรุปข้อมูลก่อนนำไปใช้ตัดสินใจด้วย
นี่เป็นหนึ่งในเหตุผลที่หลายองค์กรเริ่มมองหา โปรแกรมบริหารหน้างานก่อสร้าง เพื่อช่วยจัดโครงสร้างและเชื่อมโยงข้อมูลที่เกิดขึ้นระหว่างการทำงาน
ถ้ามีโปรแกรมบริหารหน้างานก่อสร้าง จะช่วยอะไรได้บ้าง?
คำถามสำคัญก่อนเลือกระบบอาจไม่ใช่โปรแกรมมีฟังก์ชันอะไรบ้าง แต่คือเมื่อเกิดข้อมูลขึ้นที่หน้างาน ข้อมูลนั้นสามารถเดินทางไปจนถึงการติดตามและการตัดสินใจได้หรือไม่ เพราะโปรแกรมที่มีฟังก์ชันจำนวนมาก แต่ไม่สอดคล้องกับ Workflow ของทีม อาจกลายเป็นอีกหนึ่งระบบที่ผู้ใช้งานต้องกรอกข้อมูลเพิ่ม โดยไม่ได้ช่วยลดภาระการทำงานจริง
การพิจารณาโปรแกรมบริหารหน้างานก่อสร้างจึงควรมองอย่างน้อย 5 เรื่องต่อไปนี้
1. เก็บข้อมูล ณ จุดที่งานเกิดขึ้นได้ง่ายหรือไม่
ข้อมูลที่ดีควรถูกบันทึกใกล้กับเวลาที่เหตุการณ์เกิดขึ้นมากที่สุด เพราะยิ่งต้องกลับมากรอกข้อมูลภายหลัง ความเสี่ยงที่รายละเอียดจะตกหล่นก็ยิ่งเพิ่มขึ้น
ระบบจึงควรรองรับการทำงานผ่านอุปกรณ์ที่ทีมใช้จริง เช่น โทรศัพท์หรือ Tablet และทำให้ผู้ใช้งานสามารถบันทึกผลตรวจ แนบรูป ระบุพื้นที่ และเพิ่มรายละเอียดที่จำเป็นได้โดยไม่ต้องผ่านหลายขั้นตอน
สิ่งที่ควรพิจารณาจึงไม่ใช่แค่ “มี Mobile Application หรือไม่” แต่ต้องดูต่อว่า หนึ่งกระบวนการใช้เวลากี่ขั้นตอน และผู้ใช้งานหน้างานสามารถทำได้จริงในกิจวัตรประจำวันหรือไม่
2. ข้อมูลแต่ละส่วนเชื่อมโยงกันหรือเป็นเพียงไฟล์ที่ถูกนำมาเก็บรวมกัน
ระบบบริหารหน้างานที่ดีไม่ควรทำหน้าที่เป็นเพียง Digital Storage ตัวอย่างเช่น เมื่อเปิด Defect หนึ่งรายการ ควรสามารถเชื่อมโยงได้ว่า Defect นั้นอยู่โครงการใด พื้นที่ไหน เกี่ยวข้องกับงานประเภทใด ใครรับผิดชอบ มีภาพก่อนแก้ไขอย่างไร และหลังแก้ไขแล้วมีผลการตรวจซ้ำอย่างไร
การเชื่อมโยงข้อมูลในลักษณะนี้ทำให้ทีมไม่ต้องเสียเวลาประกอบเรื่องราวจากหลายแหล่งเมื่อจำเป็นต้องตรวจสอบย้อนหลัง
3. ระบบช่วยบริหาร Workflow หลังจากพบปัญหาได้หรือไม่
การบันทึก Defect เป็นเพียงจุดเริ่มต้น หลังจากนั้นระบบควรช่วยให้ทีมเห็นกระบวนการต่อเนื่อง ตั้งแต่การมอบหมายผู้รับผิดชอบ กำหนด Due Date ติดตามสถานะ แจ้งเตือนงานที่ยังไม่ดำเนินการ ไปจนถึงการตรวจซ้ำและปิดงาน
เพราะในทางปฏิบัติ ปัญหาจำนวนมากไม่ได้เกิดจากไม่มีใครรู้ว่าต้องแก้อะไร แต่เกิดจาก ไม่มีระบบที่ทำให้เห็นว่างานใดยังไม่ได้รับการจัดการ ดังนั้น ความสามารถในการติดตามสถานะจึงมีความสำคัญไม่แพ้ความสามารถในการบันทึกข้อมูล
4. เปลี่ยนข้อมูลจำนวนมากให้เป็นสิ่งที่ผู้บริหารนำไปใช้ได้หรือไม่
การมี Dashboard ไม่ได้หมายความว่าจะช่วยในการตัดสินใจเสมอไป Dashboard ที่มีประโยชน์ควรช่วยตอบคำถามทางการบริหาร เช่น
- ตอนนี้โครงการใดมีงานค้างมากผิดปกติ
- Defect ส่วนใหญ่อยู่ในหมวดงานใด
- งานค้างส่วนใหญ่เกิดขึ้นในพื้นที่ไหน
- มีรายการใดเกินกำหนดแล้ว
- แนวโน้มปัญหาคุณภาพดีขึ้นหรือแย่ลง
- ประเด็นใดควรได้รับการจัดการก่อน
ดังนั้น ก่อนเลือกโปรแกรม องค์กรควรกำหนดก่อนว่า แต่ละระดับขององค์กรต้องใช้ข้อมูลอะไรในการตัดสินใจ แล้วจึงพิจารณาว่าระบบสามารถเปลี่ยนข้อมูลจากหน้างานให้เป็นข้อมูลเหล่านั้นได้หรือไม่
5. รองรับมาตรฐานขององค์กร โดยไม่บังคับให้องค์กรเปลี่ยนทุกอย่างตามโปรแกรม
แต่ละองค์กรมีวิธีทำงานไม่เหมือนกัน แม้จะทำธุรกิจก่อสร้างประเภทเดียวกันก็ตาม บางบริษัทมีขั้นตอนอนุมัติหลายระดับ บางบริษัทแบ่งพื้นที่ตรวจละเอียด บางแห่งมี Checklist เฉพาะของตัวเอง หรือมี Workflow ที่เชื่อมโยงกับการเบิกงวดและการส่งมอบงาน
ดังนั้น ระบบที่เหมาะสมควรสามารถนำมาตรฐานขององค์กรเข้าไปใช้ได้ และปรับ Workflow ให้สอดคล้องกับกระบวนการที่ต้องการควบคุม ก่อนนำระบบมาใช้จริง จึงควรเริ่มจากการตอบให้ได้ว่า “ปัจจุบันข้อมูลเดินทางอย่างไร และจุดใดของกระบวนการที่เราต้องการปรับปรุง”
เทคโนโลยีช่วยควบคุมคุณภาพได้ แต่ไม่สามารถสร้างมาตรฐานแทนองค์กรได้
สิ่งสำคัญ คือ โปรแกรมบริหารหน้างานก่อสร้างไม่สามารถแก้ปัญหาคุณภาพได้ด้วยตัวเอง หากองค์กรยังไม่มีมาตรฐานที่ชัดเจน ไม่มีผู้รับผิดชอบ หรือไม่มี Workflow สำหรับจัดการปัญหาหลังจากตรวจพบ บทบาทของเทคโนโลยีคือช่วยให้กระบวนการเหล่านั้นเกิดขึ้นได้ง่ายและตรวจสอบได้มากขึ้น
ตัวอย่างเช่น หากองค์กรมี Checklist ที่ดีอยู่แล้ว ระบบสามารถช่วยให้ Checklist เดียวกันถูกนำไปใช้ในหลายโครงการได้อย่างสม่ำเสมอ หากองค์กรมีขั้นตอนติดตาม Defect อยู่แล้ว ระบบสามารถช่วยให้สถานะ ผู้รับผิดชอบ และหลักฐานเชื่อมโยงกันโดยไม่ต้องรวบรวมข้อมูลจากหลายช่องทาง
ดังนั้น ก่อนลงทุนกับระบบ องค์กรควรพิจารณาทั้ง People, Process และ Technology ไปพร้อมกัน เพราะเทคโนโลยีจะสร้างผลลัพธ์ได้ดีที่สุด เมื่อถูกนำไปสนับสนุนกระบวนการที่องค์กรต้องการพัฒนาอย่างชัดเจน
จากข้อมูลหน้างาน สู่มาตรฐานที่พัฒนาได้ในทุกโครงการ
เป้าหมายของการควบคุมคุณภาพงานก่อสร้างไม่ควรจบเพียงการทำให้โครงการปัจจุบันมี Defect น้อยลง แต่ควรทำให้องค์กรเรียนรู้จากสิ่งที่เกิดขึ้นและนำกลับไปปรับปรุงโครงการถัดไปได้ เมื่อข้อมูลการตรวจ งานแก้ไข ระยะเวลาการปิด Defect และปัญหาที่เกิดซ้ำถูกจัดเก็บอย่างมีโครงสร้าง องค์กรจะเริ่มมองเห็น Pattern ที่ไม่สามารถเห็นได้จากการดูแต่ละโครงการแยกกัน
ข้อมูลเหล่านี้สามารถนำกลับไปปรับ Checklist เพิ่มจุดตรวจ วางมาตรการป้องกัน หรือกำหนดมาตรฐานการทำงานใหม่ได้ ท้ายที่สุด การควบคุมคุณภาพที่มีประสิทธิภาพจึงไม่ได้หมายถึงการ “ตรวจให้มากขึ้น” แต่คือการสร้างกระบวนการที่ทำให้
มาตรฐาน >> การทำงาน >> ข้อมูล >> การติดตาม >> การเรียนรู้ เชื่อมโยงถึงกันตลอดทั้งโครงการ และเมื่อองค์กรสามารถทำให้วงจรนี้เกิดขึ้นได้อย่างต่อเนื่อง ข้อมูลจากหน้างานจะไม่ได้เป็นเพียงหลักฐานว่าเกิดอะไรขึ้น แต่จะกลายเป็นส่วนหนึ่งของการยกระดับมาตรฐานการทำงานขององค์กรในระยะยาว
บริหารข้อมูลหน้างานให้เชื่อมต่อกับการควบคุมคุณภาพ
BUILK iNSITE เป็นโปรแกรมบริหารหน้างานก่อสร้างที่ช่วยนำแนวทางเหล่านี้ไปใช้ในการทำงานจริง ตั้งแต่การกำหนด Checklist และมาตรฐานการตรวจ บันทึกผลพร้อมหลักฐานจากหน้างาน ติดตาม Defect และผู้รับผิดชอบ ไปจนถึงการรวบรวมข้อมูลเป็น Dashboard เพื่อให้ทีมโครงการและผู้บริหารติดตามสถานะจากข้อมูลชุดเดียวกัน ช่วยให้กระบวนการควบคุมคุณภาพมีความต่อเนื่องและสามารถตรวจสอบย้อนหลังได้ตลอดโครงการ
