ระบบจำลองการบริหารธุรกิจและการเงินเพื่อการเรียนการสอน ที่ตรวจสอบย้อนหลังได้

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

1.1 การอ่านและตีความงบการเงิน ใช้ได้แล้ว

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

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

1.2 มูลค่าเงินตามเวลา กำลังพัฒนา

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

1.3 ความสัมพันธ์ระหว่างความเสี่ยงและผลตอบแทน ใช้ได้แล้ว

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

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

1.4 เครื่องมือทางการเงินและการระดมทุน กำลังพัฒนา

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

2.1 ความแม่นยำของตัวเลขที่ใช้วิเคราะห์ ใช้ได้แล้ว

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

2.2 อัตราส่วนทางการเงินที่ระบบคำนวณให้ ใช้ได้แล้ว

ระบบคำนวณอัตราส่วนให้ยี่สิบสี่ตัว พร้อมคำอธิบายว่าแต่ละตัวคำนวณจากอะไรและควรอ่านอย่างไร ผู้เรียนจึงตรวจสภาพคล่องระยะสั้น ดูอัตราหมุนเวียนสินค้าคงคลัง วัดโครงสร้างหนี้สินต่อทุน และดูความสามารถในการจ่ายดอกเบี้ยได้ครบในที่เดียว

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

2.3 การประเมินมูลค่าโครงการลงทุน กำลังพัฒนา

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

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

3.1 การบริหารเงินสดและวงจรเงินสด ใช้ได้แล้ว

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

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

3.2 การบริหารความเสี่ยง ใช้ได้แล้ว

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

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

3.3 การจัดโครงสร้างเงินทุน กำลังพัฒนา

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

3.4 นโยบายปันผล ใช้ได้แล้ว

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

มิตินี้วัดผลรวมของพฤติกรรมทางการเงิน โดยคิดจากผลประกอบการโดยรวมสามสิบเปอร์เซ็นต์ และทักษะการทำงานร่วมกันกับการเจรจาของทีมอีกสิบห้าเปอร์เซ็นต์

4.1 การตัดสินใจบนฐานข้อมูล ใช้ได้แล้ว

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

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

4.2 หลักฐานที่ตรวจย้อนหลังได้ ใช้ได้แล้ว

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

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

4.3 การอ่านสภาพแวดล้อมภายนอก ใช้ได้แล้ว

ภาวะเศรษฐกิจในระบบเดินเป็นเส้นเวลาที่มีทั้งช่วงขยายตัว ชะลอตัว และถดถอย พร้อมดอกเบี้ยนโยบายและค่าเงินที่ขยับตาม ทีมที่อ่านสัญญาณได้ก่อนจะเตรียมตัวทัน ส่วนทีมที่วางแผนบนสมมติฐานว่าเศรษฐกิจจะดีตลอดไปจะเจอบทเรียนด้วยตัวเอง

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

5.1 ปัญหาของระบบจำลองที่ใช้สอนอยู่

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

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

5.2 โจทย์ด้านการเก็บหลักฐาน

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

ตารางที่ 5.1 · สิ่งที่ต้องเก็บไว้ตรวจ และแหล่งที่มาในระบบ

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

5.3 ขอบเขตของงาน

งานนี้ครอบคลุมการออกแบบเครื่องยนต์จำลอง สมุดบัญชี ชั้นเว็บ กลไกเก็บหลักฐาน การนำขึ้นเครื่องแม่ข่าย และการพิสูจน์ความถูกต้อง ไม่ครอบคลุมการทดลองใช้กับผู้เรียนจริงและการวัดผลสัมฤทธิ์ทางการศึกษา ซึ่งเป็นงานคนละชิ้นและระบุไว้ในบทที่ 6

6.1 เงินเป็นจำนวนเต็มหน่วยสตางค์ ห้ามใช้ทศนิยมลอยตัว

เงินทุกจำนวนในระบบเก็บเป็นจำนวนเต็ม 64 บิต หน่วยสตางค์ อัตราทุกชนิดเก็บเป็นจำนวนเต็มหน่วยหนึ่งในหมื่น เหตุผลไม่ใช่ความสวยงามแต่เป็นเงื่อนไขบังคับ — งบดุลต้องดุลพอดีทุกหลัก ทศนิยมลอยตัวทำให้ผลรวมของรายการหลายหมื่นรายการคลาดเคลื่อนโดยไม่มีใครสังเกต และความคลาดเคลื่อนนั้นจะปรากฏเป็น "งบไม่ดุล" ซึ่งเป็นอาการที่หาสาเหตุยากที่สุด

6.2 บันทึกเหตุการณ์คือแหล่งความจริงเดียว

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

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

6.3 เดินซ้ำแล้วต้องได้ผลเหมือนเดิมทุกหลัก

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

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

6.4 ทิศทางการพึ่งพาแบบทางเดียว

6.5 ไม่ใช้ไลบรารีภายนอกเลย

ไฟล์ go.mod ของโครงการนี้ไม่มีรายการ require แม้แต่รายการเดียว การเข้ารหัสลับ การเซ็นตั๋วเข้าใช้งาน การอ่านไฟล์เคส และตัวเสิร์ฟเว็บ ล้วนเขียนบนไลบรารีมาตรฐาน เหตุผลคือระบบต้องอยู่ได้นานกว่ารอบชีวิตของไลบรารีภายนอก หลักฐานที่ต้องเก็บห้าปีจะไร้ความหมายถ้าเปิดอ่านไม่ได้เพราะไลบรารีที่ใช้เลิกดูแลไปแล้ว

7.1 ภาพรวมเชิงตัวเลข

ตารางที่ 7.1 · ขนาดและองค์ประกอบของระบบ (นับจากโค้ดจริง)

7.2 เครื่องยนต์เดินวันละ 19 เฟส

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

ตารางที่ 7.2 · ลำดับ 19 เฟสของหนึ่งวันจำลอง

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

7.3 การลงบัญชีเกิดจากเหตุการณ์ ไม่ใช่จากหน้าจอ

7.4 เงื่อนไขความถูกต้องที่ตรวจทุกวันจำลอง

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

ตารางที่ 7.3 · เงื่อนไขความถูกต้องที่บังคับทุกวัน

7.5 การให้คะแนน

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

ตารางที่ 7.4 · มิติการให้คะแนนและน้ำหนัก

8.1 ปัญหาที่ต้องแก้

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

8.2 โครงสร้างซองหลักฐาน

ตารางที่ 8.1 · ไฟล์ในซองหลักฐานหนึ่งใบ

ซองหนึ่งใบของห้องสี่ทีมมีขนาดราว 64 กิโลไบต์ ห้าร้อยทีมในห้าปีจึงอยู่ในระดับไม่กี่สิบเมกะไบต์ ซึ่งไม่เป็นข้อจำกัดใด ๆ

8.3 โซ่แฮชและสิ่งที่มันรับประกันจริง

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

บรรทัดที่ผูกแฮชซองก่อนหน้าขึ้นต้นด้วยเครื่องหมาย # จึงเป็นบรรทัดคำอธิบายในสายตาของคำสั่งตรวจแฮชมาตรฐาน ผู้ตรวจภายนอกยังใช้คำสั่ง sha256sum -c ตรวจไฟล์ในซองได้เหมือนเดิม แต่ในสายตาของการคำนวณแฮชซอง บรรทัดนี้เป็นเนื้อหาเต็มตัว — ทดสอบกับเครื่องมือจริงแล้ว

9.1 วิธีพิสูจน์สองทาง

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

1. แก้ข้อบกพร่อง
2. เขียนชุดทดสอบที่ต้องผ่าน
3. ใส่ข้อบกพร่องนั้นกลับเข้าไป แล้วยืนยันว่าชุดทดสอบล้มเหลว
4. คืนโค้ดที่แก้แล้ว และยืนยันว่าทั้งระบบยังผ่าน

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

9.2 การตรวจสอบเชิงลึกแบบพยายามหักล้าง

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

ตารางที่ 9.1 · สรุปผลการตรวจสอบ

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

9.3 ข้อบกพร่องที่ร้ายแรงที่สุดที่พบ

ตารางที่ 9.2 · ข้อบกพร่องระดับร้ายแรงและผลกระทบที่วัดได้

9.4 ผลการทดสอบบนเครื่องที่ใช้งานจริง

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

ตารางที่ 9.3 · ผลการทดสอบบนเครื่องที่ใช้งานจริง

ตัวเลขที่ยืนยันการแก้ข้อบกพร่องเรื่องเครื่องหมายบัญชี วัดจากห้องเรียนจริงบนเครื่องแม่ข่าย

ตารางที่ 9.4 · งบดุลของทีมหนึ่ง ณ สิ้นไตรมาสแรก วัดจากเครื่องแม่ข่ายจริง

10.1 ข้อจำกัดของงานนี้

ตารางที่ 10.1 · ข้อจำกัดที่ทราบและระบุไว้อย่างตรงไปตรงมา

10.2 บทเรียนที่ได้จากงานนี้

ชุดทดสอบที่ไม่เคยเห็นว่าตัวเองล้มเหลว ไม่ใช่หลักฐานของความถูกต้อง บทเรียนที่ 1

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

ความผิดพลาดที่อันตรายที่สุด คือความผิดพลาดที่ระบบตอบว่าสำเร็จ บทเรียนที่ 2

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

ลำดับความทนทานต้องสอดคล้องกับลำดับความสำคัญ บทเรียนที่ 3

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

10.3 งานต่อไป

1. ทดลองใช้กับผู้เรียนจริงหนึ่งคาบเต็ม แล้วเก็บข้อมูลการใช้งานและปัญหาที่พบ
2. เพิ่มบทวรรณกรรมและการอ้างอิงให้ครบตามรูปแบบวิทยานิพนธ์
3. พัฒนาการควบรวมกิจการและงบการเงินรวมตามมาตรฐานที่เกี่ยวข้อง
4. นำโครงการเข้าระบบควบคุมรุ่นของซอร์สโค้ด
5. ขยายเงื่อนไขความถูกต้องให้ตรวจถึงระดับรายสินค้า ไม่ใช่เฉพาะมูลค่ารวม

11.1 เกณฑ์การให้คะแนน

ตารางที่ 11.1 · น้ำหนักคะแนนห้ามิติ รวมหนึ่งร้อยเปอร์เซ็นต์

11.2 กลไกของระบบที่ควรอธิบายให้ผู้เรียนฟังก่อนเริ่ม

หนึ่งวันจำลองคือการเดินผ่านขั้นตอนตายตัวสิบเก้าขั้นตามลำดับ ตั้งแต่เลื่อนนาฬิกา รับภาวะเศรษฐกิจ เหตุการณ์ตามบท สร้างอุปสงค์ รับคำสั่งซื้อ ผลิต ส่งมอบ จัดซื้อ วงจรเงินสด ไปจนถึงลงบัญชี ปิดงวด ทดสอบเงื่อนไขสัญญา และตรวจความถูกต้อง

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

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

11.3 สิ่งที่ระบบยังไม่รองรับ

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

ตารางที่ 11.2 · หัวข้อที่ยังต้องสอนเชิงทฤษฎีไปก่อน

11.4 ลิงก์ที่ใช้ในคาบ

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

1. ซอร์สโค้ดของระบบ — 119 ไฟล์ 41,932 บรรทัด ที่ pinksolutions.app/bfsim
2. ชุดทดสอบ — 56 ไฟล์ 596 ฟังก์ชัน ตรวจสอบซ้ำได้ด้วยคำสั่ง go test ./...
3. ระบบที่ใช้งานจริง — sim.pinksolutions.app
4. คลังหลักฐาน — ตรวจทั้งคลังได้ด้วย evidence -verify-chain และตรวจไฟล์ในซองด้วย sha256sum -c
5. ห้องสมุดมาตรฐานการบัญชีและกฎหมายไทยที่ใช้ประกอบการออกแบบ — TFRS, TAS, TFRIC/TSIC, TSA, ประมวลรัษฎากร และประมวลกฎหมายแพ่งและพาณิชย์