โหมดมืด
ระดับความเข้มของการตรวจ
การตรวจข้อมูลมีสองคำถามที่แยกกัน — ตรวจเรื่องอะไร กับ ตรวจเข้มแค่ไหน เรื่องแรกขึ้นกับธุรกิจของคุณ (อ่านด้านล่าง) เรื่องที่สองคือส่วนที่เหลือของหน้านี้
| ระดับ | ทำอะไร | จังหวะ |
|---|---|---|
| L1 · Detect | เฉพาะรายการที่ร้ายแรง · รายงานอย่างเดียว | หลังปิดงวด |
| L2 · Assure | ครบทุกกฎ · จับกลุ่มต้นเหตุ · เสนอรายการปรับปรุงพร้อมผลกระทบ · คำนวณเกรด | ต่อเนื่องระหว่างงวด |
| L3 · Guard | กันที่ต้นทาง — ตรวจตอนบันทึก · เตือนก่อนสิ้นงวดว่าถ้าไม่แก้จะปิดงบไม่ได้ | ก่อนเกิดปัญหา |
L3 ยังไม่เปิดให้บริการ
ส่วนที่กันที่ต้นทางยังอยู่ระหว่างพัฒนา ปัจจุบันระดับสูงสุดที่ส่งมอบได้จริงคือ L2 เอกสารนี้อธิบาย L3 ไว้เพื่อให้เห็นทิศทาง ไม่ใช่เพื่อให้สั่งซื้อ
เพดานสี่ชั้น — และสามชั้นที่เงินซื้อไม่ได้
ระดับที่คุณได้จริงคือค่าที่ต่ำที่สุดในสี่ข้อนี้ ไม่ใช่ระดับที่สั่งซื้อ
| เพดาน | ตัวกำหนด | ทะลุได้ด้วย |
|---|---|---|
| ระบบต้นทาง | ระบบที่ข้อมูลอยู่ ทำอะไรได้บ้าง | ย้ายระบบเท่านั้น |
| คุณภาพการบันทึก | บันทึกละเอียดแค่ไหน — ไม่ระบุล็อต = ตามรอยล็อตไม่ได้ | เปลี่ยนวิธีบันทึก |
| การเข้าถึง | ตัวเชื่อมดึงข้อมูลออกมาได้ครบไหม | ปรับตัวเชื่อม (ถ้าต้นทางมีข้อมูลอยู่จริง) |
| ที่สั่งซื้อ | ระดับที่ตกลงกันไว้ | จ่ายเพิ่ม |
สามข้อแรกเป็นข้อจำกัดทางกายภาพ ข้อสุดท้ายเท่านั้นที่เป็นเรื่องการค้า ระบบจึงไม่ยอมให้ขายระดับที่ส่งมอบไม่ได้ตั้งแต่ต้น การขายเกินสิ่งที่ทำได้ แล้วมาชดเชยด้วยแรงคนทีหลัง คือปัญหาที่ชั้นนี้ถูกสร้างมาเพื่อเลิกทำ
ตัวอย่างที่ต่างกันชัด
| ERPNext | ระบบบัญชีสำเร็จรูปที่อ่านได้อย่างเดียว | |
|---|---|---|
| ตรวจบัญชีแยกประเภทและงบทดลอง | ✅ | ✅ |
| ตรวจต้นทุนสต๊อกรายรายการ | ✅ | ❌ ไม่มีข้อมูล |
| ตามรอยล็อตและวันหมดอายุ | ✅ | ❌ |
| เตือนระหว่างเดือนทันทีที่เกิด | ✅ | ❌ ตรวจเป็นรอบเท่านั้น |
| เขียนรายการปรับปรุงกลับเข้าไป | ✅ เป็นร่างให้กดยืนยัน | ❌ ออกเป็นรายการให้ไปคีย์เอง |
| ระดับสูงสุด | L2 (L3 เมื่อพร้อม) | L2 |
ตัวเลขจริงของการตรวจ: บน ERPNext กฎ 115 ข้อรันได้ครบทุกข้อ บนระบบที่อ่านได้เฉพาะบัญชีแยกประเภท รันได้ 13 ข้อ
อีก 102 ข้อรายงานว่า "ไม่ได้ตรวจ" ไม่ใช่ "ผ่าน"
นี่คือความต่างที่สำคัญที่สุดในหน้านี้ กฎที่ไม่เคยรันให้ผลเป็นศูนย์เหมือนกับ กฎที่รันแล้วไม่พบอะไร — รายงานจึงบอกเสมอว่ากฎข้อไหนไม่ได้ตรวจและเพราะอะไร
รอบการแก้ต่างกันตามระบบต้นทาง
บน ERPNext ระบบสร้างร่างเอกสารให้ คนกดยืนยันในระบบเดียวจบ
บนระบบที่เขียนกลับไม่ได้ ระบบออกเป็นรายการสิ่งที่ต้องไปแก้ — เรียงตามเอกสาร ระบุค่าเดิมกับค่าที่ควรเป็น ให้ไปคีย์ที่ต้นทางแล้วดึงข้อมูลมาตรวจใหม่ เป็นการทำงานไป-กลับหลายรอบ ซึ่งช้ากว่าโดยธรรมชาติ ไม่ใช่เพราะตั้งใจให้ต่างกัน
ระดับต่ำไม่ได้แปลว่าเกรดต่ำ
เพดานวัดขีดจำกัดของเครื่องมือ ส่วนเกรดวัดวินัยของคุณ ลูกค้าที่ใช้ระบบต้นทางที่ตรวจได้ตื้นกว่า แต่บันทึกข้อมูลเรียบร้อย ต้องได้เกรดดีในขอบเขตที่ตรวจได้ — ไม่ถูกลงโทษเพราะเลือกซอฟต์แวร์คนละตัว
อ่านต่อ: เกรดวินัยข้อมูล
วัดจริงแล้ว ไม่ใช่ประกาศไว้เฉย ๆ
ตัวเลขขอบเขตของแต่ละระบบต้นทางมาจากการรันกับไฟล์จริง ไม่ใช่จากตารางที่เขียนไว้ล่วงหน้า
| ระบบต้นทาง | กฎที่อยู่ในขอบเขต | หมายเหตุ |
|---|---|---|
| ERPNext | 115 จาก 115 | อ่านได้ทุกอย่างที่กฎต้องใช้ |
| ระบบบัญชีที่อ่านได้อย่างเดียว | 13 จาก 115 | ไม่มีข้อมูลสต็อกและแบตช์ |
กฎที่เหลือ ไม่ได้แปลว่า "ผ่าน" — รายงานจะบอกว่า ไม่ได้ตรวจ พร้อมเหตุผลว่าขาดข้อมูลอะไร ศูนย์ที่มาจากกฎที่ไม่เคยรัน หน้าตาเหมือนศูนย์ที่มาจากบัญชีที่สะอาด และสองอย่างนี้ ต้องแยกกันให้ออกก่อนเสมอ
ตรวจเรื่องอะไร ขึ้นกับว่าคุณทำธุรกิจอะไร
ตารางข้างบนตอบแค่ว่า ระบบต้นทางให้ข้อมูลอะไรได้บ้าง ยังมีอีกคำถามที่ไม่เกี่ยวกัน เลย — ธุรกิจของคุณมีสิ่งที่กฎข้อนั้นตรวจหรือเปล่า
ห้างสรรพสินค้าที่ใช้ ERPNext อ่านข้อมูลได้ครบทุกอย่างเหมือนโรงงาน แต่ไม่มีสายการผลิต กฎเรื่องการปันโสหุ้ยเข้าต้นทุนสินค้าจึงไม่มีวันดัง — ไม่ใช่เพราะทำถูก แต่เพราะไม่มีสิ่งนั้น ให้ทำผิดตั้งแต่ต้น
| กลุ่มธุรกิจ | กฎที่อยู่ในขอบเขต (บน ERPNext) |
|---|---|
| ผลิต | 115 จาก 115 |
| โรงแรม · ร้านอาหาร | 66 จาก 115 |
| อสังหาริมทรัพย์ · ศูนย์การค้า | 49 จาก 115 |
66 ข้อที่ตัดออกจากศูนย์การค้า แบ่งเป็นสองพวก — 49 ข้อที่ต้องมีสายการผลิตจริง (ผลผลิตจากใบสั่งผลิต · ของเสียและผลได้ · การปันโสหุ้ย · สายพันธุ์แบตช์) และ 17 ข้อที่ต้องถือของซึ่งมีวันหมดอายุหรือติดตามเป็นล็อตได้ ซึ่งพื้นที่เช่าไม่มีโดยธรรมชาติ
"ไม่เกี่ยวกับธุรกิจคุณ" ต่างจาก "เราอ่านข้อมูลไม่ได้"
รายงานแยกสองเหตุผลนี้ออกจากกันเสมอ
- ไม่เกี่ยวกับธุรกิจคุณ — ไม่มีอะไรต้องทำ และไม่ควรมีใครเสียเวลากับมัน
- เราอ่านข้อมูลไม่ได้ — แก้ได้ด้วยการปรับตัวเชื่อมหรือเปลี่ยนวิธีบันทึก
ถ้ารวมสองอย่างนี้เป็นก้อนเดียว คุณจะแยกไม่ออกว่าอันไหนคุ้มที่จะลงแรง
กลุ่มธุรกิจตั้งไว้ตอนเชื่อมระบบ ถ้ายังไม่ได้ตั้ง ระบบจะตรวจให้ทุกข้อ — เลือกไว้แบบนี้เพราะค่าที่ยังไม่ได้ตัดสิน ไม่ควรทำให้ระบบเงียบลงเองโดยที่ไม่มีใครรู้
ตัวเลขเกรดไม่ขยับจากเรื่องนี้ — กฎที่ไม่มีวันดังก็ไม่เคยให้ผลอะไรอยู่แล้ว สิ่งที่เปลี่ยนคือคำกล่าวอ้างว่าตรวจครอบคลุมแค่ไหน · "ตรวจครบ 115 จาก 115 ข้อ" อ่านได้ว่าตรวจละเอียดมาก ทั้งที่ 66 ข้อในนั้นไม่มีอะไรให้ตรวจตั้งแต่แรก ตัวเลขที่ตรงกับความจริงคือ 49 จาก 49
เรื่องอายุสินค้า — สิ่งที่ระบบยังตอบไม่ได้
กฎเรื่องวันหมดอายุที่ใช้งานได้ตอนนี้ ตอบคำถามชุด "ของที่ถืออยู่" ได้ครบ
- มีของหมดอายุค้างอยู่ในคลังเท่าไร และยังตีราคาเต็มอยู่หรือเปล่า
- มีของใกล้หมดอายุที่ถึงเกณฑ์ต้องประเมินมูลค่าสุทธิที่จะได้รับแล้วหรือยัง
- วันหมดอายุของแบตช์ขัดแย้งกับที่ตั้งไว้ในสินค้าหรือไม่
- การหยิบของออกเรียงตามวันหมดอายุจริงหรือไม่ และมีการใช้รหัสข้อยกเว้นซ้ำ ๆ ไหม
ยังตอบไม่ได้คือคำถามชุด "ของที่เคลื่อนไหวไปแล้ว" — รับของที่อายุเหลือน้อยเข้ามาหรือเปล่า เคยเบิกของที่หมดอายุแล้วเข้าไลน์ผลิตไหม และเคยส่งของที่หมดอายุออกไปหาลูกค้าแล้วหรือยัง
สามข้อนี้ต้องอ่านถึงระดับเอกสารรายใบ (ใบรับ ใบเบิกผลิต ใบส่งของ) ซึ่งเป็นงานที่กำลังทำอยู่ ไม่ใช่ข้อจำกัดถาวร แต่วันนี้ยังไม่มี และเราเขียนไว้ตรงนี้เพราะรายงานที่เงียบเรื่องนี้ อ่านได้ง่าย ๆ ว่า "ไม่มีปัญหา" ทั้งที่แปลว่า "ยังไม่ได้ถาม"