พนักงานคลังควรเห็นต้นทุนสินค้าทุกตัวหรือไม่ ฝ่ายขายควรยกเลิกใบแจ้งหนี้ที่ส่งบัญชีแล้วได้ไหม และใครเป็นคนอนุมัติส่วนลดพิเศษ หากคำตอบคือ “ใช้บัญชี Administrator ไปก่อน” ระบบอาจเปิดใช้งานได้เร็วในช่วงทดสอบ แต่พอมีผู้ใช้จริง ความเสี่ยงด้านข้อมูลและการตรวจสอบย้อนหลังจะเพิ่มตามจำนวนคน
การ ตั้งสิทธิ์ผู้ใช้ ERPNext ที่ดีไม่ใช่การปิดปุ่มให้มากที่สุด แต่เป็นการให้พนักงานทำงานของตัวเองได้ครบ พร้อมจำกัดสิทธิ์ที่เกินหน้าที่ และมีหลักฐานว่าเอกสารสำคัญผ่านใคร เมื่อไร และเปลี่ยนแปลงอะไรบ้าง โดยควรใช้มาตรฐาน Role และ Workflow ก่อนสร้างสคริปต์เฉพาะทาง
เริ่มจาก Role ไม่ใช่สร้าง Permission แยกทีละคน
ERPNext ใช้ Role-based Permission เพื่อให้กำหนดชุดสิทธิ์แก่หน้าที่งาน เช่น Sales User, Stock User, Accounts User หรือผู้อนุมัติที่องค์กรกำหนด เมื่อมีพนักงานย้ายแผนกสามารถแก้ Role ที่ได้รับแทนการไล่ปรับสิทธิ์ในทุก DocType แบบรายบุคคล
ใน Role Permissions Manager สามารถกำหนดสิทธิ์ตามประเภทเอกสาร เช่น Read, Write, Create, Submit, Cancel, Amend และ Export อย่างไรก็ตามการให้สิทธิ์หนึ่งรายการไม่ได้หมายความว่ากระบวนการทุกขั้นจะผ่านได้เสมอ เพราะยังมีเงื่อนไขสถานะเอกสาร Workflow และการตั้งค่าอื่นที่เกี่ยวข้อง
แยกสิทธิ์สร้าง แก้ไข อนุมัติ และยกเลิก
ตัวอย่างฝ่ายจัดซื้ออาจให้พนักงานสร้าง Purchase Order แบบ Draft แต่ต้องให้หัวหน้าฝ่ายอนุมัติก่อน Submit ส่วนการยกเลิกเอกสารหลังมีการรับสินค้าแล้วต้องเป็นสิทธิ์ที่จำกัดกว่า เนื่องจากอาจกระทบทั้งสต็อกและบัญชี การใช้ Role เดียวที่ทำได้ทุกอย่างจะทำให้ควบคุมการเปลี่ยนแปลงยาก
- Create สำหรับผู้เริ่มรายการ เช่น ฝ่ายขายเปิด Quotation หรือเจ้าหน้าที่จัดซื้อเปิดใบสั่งซื้อ
- Write สำหรับการแก้ข้อมูลในขอบเขตที่อนุญาต ควรระวังข้อมูลสำคัญที่ไม่ควรแก้หลังอนุมัติ
- Submit สำหรับผู้มีอำนาจยืนยันเอกสารตามกระบวนการ
- Cancel และ Amend สำหรับกรณีแก้เอกสารที่ยืนยันแล้ว ควรมีเหตุผลและขั้นตอนควบคุม
- Export สำหรับผู้จำเป็นต้องนำข้อมูลออก เพราะข้อมูลลูกค้าและบัญชีอาจมีความละเอียดอ่อน
เมื่อออกแบบสิทธิ์ ควรทดสอบด้วยบัญชีผู้ใช้จริงของแต่ละบทบาท ไม่ใช่ตรวจจาก Administrator อย่างเดียว เพราะ Administrator สามารถข้ามข้อจำกัดจำนวนมาก ทำให้การทดสอบดูผ่านทั้งที่พนักงานทั่วไปยังเข้าเมนูหรือเอกสารไม่ได้
จำกัดขอบเขตข้อมูลด้วย User Permissions
Role บอกว่าใครเข้าถึงเอกสารประเภทใดได้ ส่วน User Permissions ช่วยจำกัดข้อมูลที่ผู้ใช้นั้นเห็น เช่น เฉพาะบริษัท เฉพาะลูกค้าบางกลุ่ม หรือขอบเขตที่อ้างอิงผ่าน Link Field ตามที่ระบบรองรับ เหมาะกับ ERPNext ที่มีหลายบริษัท หลายสาขา หรือทีมขายที่รับผิดชอบลูกค้าคนละชุด
อย่างไรก็ตาม อย่าเข้าใจว่าการซ่อนเมนูหรือกรองรายการบนหน้าจอเป็นการป้องกันข้อมูลเพียงพอ สิทธิ์ต้องบังคับใช้ที่ระดับ Server/API ด้วย และควรทดสอบการเปิดเอกสารโดยตรง การ Export รายงาน และการเรียกข้อมูลผ่าน Integration ที่ได้รับอนุญาตด้วย
Workflow ช่วยให้ขั้นตอนอนุมัติมีเจ้าของชัดเจน
สมมติคำสั่งซื้อเกินวงเงินที่กำหนดต้องให้หัวหน้าฝ่ายขายตรวจ แต่ใบสั่งซื้อทั่วไป Submit ได้จากผู้จัดการสาขา ระบบสามารถกำหนด Workflow State, Transition และผู้มีสิทธิ์กดเปลี่ยนสถานะตาม Role ที่เกี่ยวข้อง เพื่อไม่ให้ทุกคนกดอนุมัติได้จากจุดเดียว
ถ้าองค์กรมีหลายชั้นอนุมัติ ต้องกำหนดกรณีส่งกลับเพื่อแก้ไข ยกเลิก และผู้อนุมัติไม่อยู่ให้ชัดด้วย การตั้ง Workflow ที่ไม่มีเส้นทางย้อนกลับอาจกลายเป็นปัญหาในการปฏิบัติงานมากกว่าช่วยควบคุม อีกทั้งต้องตรวจว่าเงื่อนไข Workflow เข้ากันได้กับ Submit/Cancel ของ DocType เป้าหมาย
Audit Trail ต้องเก็บอะไรบ้างจึงจะตรวจสอบย้อนหลังได้
การบอกว่า “เปิดระบบ ERPNext แล้วมี Audit Trail ครบ” ยังไม่เพียงพอ หลักฐานการตรวจสอบขึ้นกับชนิดเอกสาร ฟิลด์ที่เปิด Track Changes การจัดเก็บ Version ข้อมูลการอนุมัติ และ Log อื่นที่องค์กรเลือกเปิดใช้งาน ข้อมูลบางชนิดอาจไม่ถูกบันทึกทุกค่าหรือถูกล้างตามนโยบายเก็บรักษา จึงต้องทดสอบกับเหตุการณ์จริง
- ระบุผู้สร้าง ผู้แก้ไข ผู้ Submit และผู้อนุมัติเอกสารสำคัญให้ตรวจสอบได้
- เก็บเวลาและเหตุผลของการเปลี่ยนสถานะ รวมถึงการส่งกลับแก้ไขใน Workflow
- กำหนดฟิลด์สำคัญที่ต้องติดตามการเปลี่ยนแปลง เช่น ราคา ส่วนลด บัญชี และวันเอกสาร
- ทบทวนระยะเวลาเก็บรักษา Log/Version และสิทธิ์เข้าถึงหลักฐาน
- วางกระบวนการสำรองข้อมูล ทดสอบ Restore และจัดการสิทธิ์ของผู้ดูแลระบบ
หากองค์กรกำลังเตรียมรับการตรวจ ISO หรือข้อกำหนดของลูกค้า ต้องทำการประเมินช่องว่างและจัดเตรียมหลักฐานตามขอบเขตมาตรฐานนั้นด้วย การมี Role, Workflow หรือ Version ใน ERPNext เป็นเพียงองค์ประกอบควบคุม ไม่ได้ทำให้ระบบหรือองค์กรผ่านการรับรองโดยอัตโนมัติ อ่านแนวคิดเพิ่มเติมที่ AI Governance, Security และ Audit Trail
ระวังสิทธิ์จาก API และ Integration
บางองค์กรล็อกสิทธิ์พนักงานได้แล้ว แต่กลับใช้ API Key ของ Administrator เชื่อมระบบภายนอกทั้งหมด เมื่อเกิด Integration ผิดพลาดหรือข้อมูลรั่วไหล ความเสียหายอาจกว้างเกินงานที่ API นั้นควรทำ ควรสร้างบัญชีบริการที่มี Role เท่าที่จำเป็น แยกตามระบบงาน กำหนดแนวทางหมุนเวียน Credential และตรวจ Log ของการใช้งานที่สำคัญ
หากระบบภายนอกต้องสร้าง Sales Order อย่างเดียว ไม่ควรให้สิทธิ์ลบข้อมูลลูกค้า หรือเข้าถึงเอกสารบัญชีทั้งหมด การออกแบบ API และการควบคุมสิทธิ์ควรไปด้วยกัน ดูแนวทางต่อที่ การเชื่อม ERPNext กับ API
ทดสอบสิทธิ์อย่างไรไม่ให้วัน Go-Live สะดุด
- สร้างบัญชีทดสอบหนึ่งบัญชีต่อบทบาท เช่น Sales, Warehouse, Purchasing, Accounting และ Approver
- ทดสอบเปิดรายการ สร้าง Draft, Submit, Cancel, Export และเปิด URL เอกสารโดยตรง
- ทดสอบเอกสารคนละบริษัท/คลัง/ลูกค้า เพื่อดูว่าข้อจำกัด User Permissions ทำงานจริง
- ทดสอบ Workflow ทั้งอนุมัติ ส่งกลับแก้ไข และกรณีผู้อนุมัติไม่มีสิทธิ์ตรงตามเงื่อนไข
- ตรวจหลักฐาน Version/Workflow ในตัวอย่างที่แก้ราคา แก้จำนวน และยกเลิกเอกสาร
ควรรวมการทดสอบสิทธิ์ไว้ใน Checklist ก่อนเปิดใช้ ERPNext จริง เพื่อแก้ปัญหาก่อนมีข้อมูลธุรกรรมจริง หากต้องเพิ่ม DocType หรือ Field เฉพาะทาง ให้ทบทวนก่อนว่า Role, Permission Level, Workflow หรือ Custom Field แบบมาตรฐานรองรับได้หรือไม่ แล้วค่อยพิจารณา การปรับแต่ง ERPNext ด้วย Frappe App
คำถามที่พบบ่อย
ให้พนักงานเห็นเมนูได้ แต่ห้ามแก้เอกสาร ทำได้ไหม
ทำได้โดยแยกสิทธิ์ Read กับ Write/Create/Submit แต่ต้องตรวจสิทธิ์ที่สัมพันธ์กับเอกสารเชื่อมโยง และทดสอบกับบัญชีผู้ใช้จริง
ต้องสร้าง Role แยกทุกตำแหน่งหรือไม่
ไม่จำเป็น ควรแยกตามหน้าที่และความเสี่ยงจริง ไม่ใช่แยกทุกชื่อตำแหน่งจนดูแลยาก ผู้ใช้หนึ่งคนอาจมีหลาย Role ได้หากมีเหตุผลทางธุรกิจ
เปิด Track Changes แล้วถือว่ามี Audit Trail สมบูรณ์หรือยัง
ยัง ต้องตรวจขอบเขตของข้อมูลที่บันทึก ความครบถ้วนของเหตุการณ์ ระยะเวลาเก็บรักษา และกระบวนการเข้าถึงหลักฐานร่วมด้วย
อ่านเอกสารอ้างอิงได้ที่ ERPNext Role Based Permissions และ Frappe Users and Permissions
