Project AI Command Center

20 ÷ 25 = 80.0% · (20 + 11) ÷ (25 + 18) = 31 ÷ 43 = 72.1% ✓ · ส่วนต่าง 7.9 จุด · โครงการที่เลยกำหนดแล้วแต่ยังไม่ปิด 7 โครงการ คิดเป็น 38.9% ของโครงการที่กำลังดำเนินการ

นี่คือความผิดพลาดแบบตัวหารมีแต่ผู้รอด ซึ่งเกิดขึ้นเองโดยไม่มีใครตั้งใจ — เพราะโครงการจะเข้าสถิติได้ก็ต่อเมื่อปิดแล้ว และโครงการที่ช้ามากที่สุดคือโครงการที่ยังปิดไม่ได้ · ผลคือยิ่งโครงการช้ามากเท่าไร ยิ่งไม่ปรากฏในตัวเลขนานเท่านั้น ซึ่งเป็นทิศทางที่ตรงข้ามกับที่ควรเป็น · 7 โครงการที่เลยกำหนดแล้วคิดเป็น 38.9% ของโครงการที่กำลังดำเนินการทั้งหมด ซึ่งเป็นสัดส่วนที่ถ้าเห็นตั้งแต่แรกจะเปลี่ยนบทสนทนาในที่ประชุมทันที · ทางแก้ไม่ใช่การรอให้ปิดแล้วค่อยนับ แต่คือนับโครงการที่ยังเปิดอยู่ด้วยสถานะ ณ วันที่รายงาน โครงการที่ยังไม่ถึงกำหนดนับเป็นตรงเวลา โครงการที่เลยกำหนดแล้วนับเป็นไม่ตรงเวลาทันที ไม่ต้องรอผลสุดท้าย · ตัวเลข 72.1% จะขยับทุกเดือนตามสถานะจริง ซึ่งเป็นสิ่งที่ 80.0% ทำไม่ได้เพราะขยับเฉพาะตอนมีโครงการปิด · ระบบจึงแสดง 72.1% เป็นตัวหลัก และแสดง 80.0% ไว้ข้าง ๆ พร้อมป้ายว่านับเฉพาะที่ปิดแล้ว

950.60 ÷ 1,284.60 = 74.0% · 1,284.60 × 68.0% = ฿873.53M · ดัชนีต้นทุน 873.53 ÷ 950.60 = 0.919 — ทุกบาทที่จ่ายได้งานมูลค่า 0.92 บาท · ประมาณการเมื่อจบ 1,284.60 ÷ 0.919 = ฿1,397.82M เกินงบ ฿113.22M = 8.8%

ตัวเลขทั้งหมดในตารางนี้ตั้งอยู่บนความคืบหน้า 68.0% ซึ่งเป็นตัวเลขที่ผู้จัดการโครงการรายงานเอง ไม่ได้วัดจากงานที่ตรวจรับแล้ว — ถ้าตัวเลขนั้นสูงเกินจริง ส่วนต่างที่แท้จริงจะมากกว่า ฿77.07M · และเนื่องจากผู้จัดการโครงการถูกประเมินด้วยความคืบหน้าที่ตัวเองรายงาน แรงจูงใจจึงเอนไปทางรายงานสูงไว้ก่อน ซึ่งไม่ใช่เรื่องของความซื่อสัตย์ส่วนบุคคล แต่เป็นผลของการออกแบบตัวชี้วัด · วิธีที่ลดปัญหานี้คือผูกความคืบหน้ากับสิ่งที่ตรวจรับได้ เช่นงานที่ผ่านการตรวจรับแล้ว หรือใบส่งของที่รับเข้าแล้ว ไม่ใช่การประเมินเป็นเปอร์เซ็นต์ · ปัจจุบันมีเพียง 6 โครงการจาก 18 โครงการที่วัดความคืบหน้าจากงานที่ตรวจรับแล้ว ที่เหลืออีก 12 โครงการยังเป็นการประเมิน · ระบบจึงติดป้ายบอกทุกโครงการว่าความคืบหน้ามาจากการวัดหรือการประเมิน และไม่รวมสองแบบเข้าเป็นตัวเลขเดียวโดยไม่บอก · ประมาณการเกินงบ ฿113.22M ยังไม่ถือเป็นการขอเพิ่มงบ เป็นการเตือนล่วงหน้าเพื่อให้ตรวจสอบ ซึ่งการขออนุมัติเพิ่มงบเป็น Level E ที่ต้องผ่านคณะกรรมการ

สินทรัพย์ต้องเริ่มคิดค่าเสื่อมราคาเมื่ออยู่ในสภาพพร้อมใช้งานตามที่ฝ่ายบริหารตั้งใจ ไม่ใช่เมื่อโครงการปิดทางบัญชี — ทั้งหกโครงการนี้ใช้งานจริงมาแล้วเฉลี่ย 7 เดือน แต่ยังอยู่ในบัญชีงานระหว่างก่อสร้างซึ่งไม่คิดค่าเสื่อม · ผลคือค่าเสื่อมราคาขาดไป ฿10.80M และกำไรสูงกว่าที่ควรเป็นเท่ากัน ซึ่งเป็นรายการที่ผู้สอบบัญชีตรวจพบได้และต้องปรับปรุงย้อนหลัง · สาเหตุที่เกิดขึ้นไม่ใช่เจตนา แต่เป็นเพราะการปิดโครงการทางบัญชีถูกผูกกับการปิดงานทางเทคนิคซึ่งเป็นคนละเรื่องกัน โครงการปรับปรุงสายการผลิตที่รอปิดงานส่วนที่เหลือ 3% เดินเครื่องผลิตของขายมาเก้าเดือนแล้ว · ระบบจึงแยกสองสถานะออกจากกัน คือวันที่พร้อมใช้งานและวันที่ปิดโครงการ และแจ้งโมดูลบัญชีทันทีที่มีการบันทึกวันพร้อมใช้งาน ไม่รอปิดโครงการ · รายการทั้งหกนี้ถูกส่งไปที่โมดูล 13 บัญชีและโมดูล 15 บริหารสินทรัพย์แล้ว พร้อมตัวเลขค่าเสื่อมที่ต้องปรับปรุง

7 โครงการนี้คิดเป็น ฿686.60M หรือ 53.4% ของงบที่กำลังดำเนินการทั้งหมด ฿1,284.60M · ทั้งกลุ่มใช้เงินไป 77% แต่คืบหน้า 67% ซึ่งแย่กว่าค่าเฉลี่ยรวมที่ 74% ต่อ 68%

7 โครงการที่ล่าช้าคิดเป็นเพียง 38.9% ของจำนวนโครงการ แต่เป็น 53.4% ของงบประมาณ — ซึ่งหมายความว่าโครงการใหญ่ล่าช้ามากกว่าโครงการเล็กอย่างเป็นระบบ · สาเหตุที่พบไม่มีข้อไหนเป็นเรื่องที่ควบคุมไม่ได้ทั้งหมด อุปกรณ์นำเข้ามาช้าเป็นเรื่องที่เผื่อเวลาได้ตั้งแต่วางแผน ดินอ่อนเป็นเรื่องที่สำรวจก่อนได้ และขอบเขตที่ขยายระหว่างทางเป็นเรื่องที่ควบคุมได้ทั้งหมด · โครงการระบบวิเคราะห์ข้อมูลด้วย AI ที่ขอบเขตขยายระหว่างทาง เป็นกรณีที่ต้องแยกให้ชัดว่าล่าช้าหรือเปลี่ยนงาน ถ้าขอบเขตเพิ่มโดยไม่ได้เลื่อนกำหนดตามด้วย การนับว่าล่าช้าเป็นการวัดที่ไม่เป็นธรรมกับทีม · ระบบจึงบันทึกทุกการเปลี่ยนขอบเขตพร้อมผลต่อกำหนดเวลาและงบประมาณ และการอนุมัติเปลี่ยนขอบเขตเป็น Level E · ปัจจุบันมี 4 จาก 18 โครงการที่ขอบเขตเปลี่ยนโดยไม่มีการปรับกำหนดเวลาตาม ซึ่งเป็นรายการที่ต้องทบทวนก่อนใช้ตัวเลขความล่าช้าประเมินใคร

การเปลี่ยนขอบเขตและการเพิ่มงบประมาณเป็นสองเรื่องที่ต้องผ่านคน เพราะทั้งคู่เปลี่ยนสิ่งที่คณะกรรมการเคยอนุมัติไว้ — โครงการที่ได้รับอนุมัติมาพร้อมกับเหตุผลว่าคุ้มค่าที่งบเท่านี้และขอบเขตเท่านี้ การเปลี่ยนอย่างใดอย่างหนึ่งทำให้เหตุผลนั้นไม่จริงอีกต่อไป · AI คำนวณผลกระทบของการเปลี่ยนแปลงได้ทั้งต่อกำหนดเวลา ต้นทุน และมูลค่าปัจจุบันสุทธิ แต่ตัดสินใจแทนไม่ได้ · ระบบบันทึกทุกการเปลี่ยนขอบเขตพร้อมผลต่อกำหนดเวลาและงบ ไม่ให้เปลี่ยนโดยไม่ระบุผลกระทบ เพราะการเปลี่ยนขอบเขตแบบไม่บันทึกคือสาเหตุที่ทำให้โครงการดูล่าช้าทั้งที่ทำงานมากขึ้น · การปรับกำหนดเวลางานย่อยที่ไม่กระทบวันส่งมอบทำได้ในกรอบที่กำหนด แต่ระบบจะเตือนเมื่อการปรับสะสมเริ่มกินเวลาสำรองของเส้นทางวิกฤตจนเหลือน้อยกว่า 5 วัน เพราะจากจุดนั้นการปรับครั้งถัดไปจะกระทบวันส่งมอบทันที