งานเอกสารและการอนุมัติแบบดิจิทัล: เริ่มจากกระบวนการ ไม่ใช่เครื่องมือ

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

แต่โครงการลักษณะนี้มักสะดุดที่จุดเดียวกัน คือเริ่มจากเลือกเครื่องมือ แล้วย้ายขั้นตอนเดิมทั้งหมดขึ้นหน้าจอ เอกสารจึงยังรอนานเท่าเดิม เพียงแต่เปลี่ยนจากรอบนโต๊ะเป็นรอในกล่องข้อความ บทความนี้ชวนหัวหน้าฝ่ายปฏิบัติการ ธุรการ การเงิน และ IT Manager เริ่มจากกระบวนการ เลือกรูปแบบระบบ และตรวจประเด็นกฎหมายไทยที่เกี่ยวข้อง ก่อนลงมือพัฒนาหรือจัดซื้อ

ทำไมงานเอกสารและการอนุมัติจึงเหมาะเป็นก้าวแรก

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

หากกำลังจัดลำดับโครงการทั้งภาพ อ่านประกอบได้ที่ แผนงาน Digital Transformation สำหรับองค์กรไทย บทความนี้จะเจาะเฉพาะงานเอกสารและการอนุมัติ

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

ขั้นที่ 1: เขียนแผนผังกระบวนการปัจจุบันก่อนเลือกเครื่องมือ

แนวคิด Value-Stream Mapping ของ Lean Enterprise Institute แยกแผนผังเป็น Current State ที่บันทึกสภาพการทำงานจริง และ Future State ที่เป็นภาพเป้าหมายของการไหลของงานและข้อมูล

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

รอบแรกไม่จำเป็นต้องแม่นยำระดับนาที การประทับวันที่รับและส่งต่อบนเอกสารตัวอย่างสักสองสามสัปดาห์ ก็มักเพียงพอให้เห็นว่าเวลาหายไปที่ขั้นใด

ขั้นที่ 2: ลดขั้นตอนที่ไม่จำเป็นก่อนเปลี่ยนเป็นดิจิทัล

Michael Hammer เสนอไว้ใน Reengineering Work: Don't Automate, Obliterate (Harvard Business Review, 1990) ว่าควรออกแบบกระบวนการใหม่ แทนการนำวิธีทำงานเดิมไปทำให้อัตโนมัติ จากนั้นใช้แผนผัง Current State ไล่ถามทีละขั้นดังนี้

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

การเปลี่ยนอำนาจอนุมัติเป็นเรื่องนโยบาย ไม่ใช่เรื่องระบบ ควรให้ผู้มีอำนาจและฝ่ายตรวจสอบภายในเห็นชอบ Future State ก่อนพัฒนา เพื่อไม่ต้องรื้อ Workflow ภายหลัง

ขั้นที่ 3: เปลี่ยนเป็นดิจิทัล เริ่มจากเลือกรูปแบบระบบให้ตรงกับงาน

ส่วนใหญ่องค์กรใช้หลายรูปแบบร่วมกัน หากระบบที่ต้องเชื่อมเป็นระบบเก่าที่ไม่มีช่องทางเชื่อมต่อ ดูแนวทางใน บทความเรื่องการปรับปรุงระบบ Legacy

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

ตรวจประเด็นกฎหมายไทย

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

กฎหมายธุรกรรมทางอิเล็กทรอนิกส์

ตามเอกสาร Digital Law ของ ETDA และตัวบท พ.ร.บ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พ.ศ. 2544 รับรองสถานะของข้อมูลอิเล็กทรอนิกส์และลายมือชื่ออิเล็กทรอนิกส์ ฉบับที่ 2 พ.ศ. 2551 เพิ่มหลักเกณฑ์ความน่าเชื่อถือของลายมือชื่อ การประทับตราอิเล็กทรอนิกส์ของนิติบุคคล และการแปลงเอกสารเป็นข้อมูลอิเล็กทรอนิกส์ (ม.12/1) ส่วนฉบับที่ 3 และ 4 พ.ศ. 2562 เพิ่มเรื่องสัญญาระหว่างประเทศและการพิสูจน์ตัวตนทางดิจิทัล

ตารางด้านล่างแปลงมาตราหลักเป็นข้อกำหนดระบบ ตัวบทอ้างอิงคือ ฉบับรวมแก้ไขถึงฉบับที่ 2 ซึ่งยังไม่รวมฉบับที่ 3 และ 4 ที่แก้ไขภายหลัง รวมถึงถ้อยคำของมาตรา 9 ตามที่สรุปในเอกสาร Digital Law ของ ETDA

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

เลือกระดับลายมือชื่อตามความเสี่ยง

เอกสาร Digital Law ของ ETDA ยกตัวอย่างการเข้าสู่ระบบด้วย Username และ Password เป็นลายมือชื่อตามมาตรา 9 ส่วนข้อเสนอแนะมาตรฐานฯ ว่าด้วยแนวทางการลงลายมือชื่ออิเล็กทรอนิกส์ (ขมธอ. 23-2563) ที่ ETDA ประกาศเมื่อ 29 พฤษภาคม 2563 แบ่งลายมือชื่ออิเล็กทรอนิกส์เป็นสามประเภท ซึ่ง LawPlus สรุปพร้อมตัวอย่างไว้ ดังนี้

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

สแกนเอกสารเก่าต้องมีขั้นตอน

ประกาศคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์ว่าด้วยการจัดทำหรือแปลงเอกสารฯ พ.ศ. 2553 กำหนดหลักเกณฑ์สำคัญไว้ดังนี้

• มีผู้ตรวจและรับรองว่าตรงกับต้นฉบับ
• ระบุตัวผู้แปลงเอกสารได้
• ป้องกันการแก้ไข และบันทึกหลักฐานการแปลงพร้อม Metadata
• มีมาตรการควบคุมการเข้าถึง ได้แก่ การระบุตัวตน (Identification) การยืนยันตัวตน (Authentication) การกำหนดสิทธิ์ (Authorization) และการตรวจสอบย้อนหลังได้ (Accountability)
• คงความละเอียดของต้นฉบับ

จึงควรแยกงานสแกนย้อนหลังเป็นโครงการย่อย และตัดสินใจร่วมกับฝ่ายกฎหมายว่าจะเก็บต้นฉบับกระดาษต่อหรือไม่

PDPA และระยะเวลาเก็บรักษา

คู่มือ PDPA สำหรับผู้ประกอบการของสภาดิจิทัลฯ สรุปประเด็นที่ใช้ออกแบบแบบฟอร์มได้ดังนี้

• เก็บเท่าที่จำเป็น: ทุกช่องควรตอบได้ว่าใช้เพื่ออะไร
• ไม่ใช่ทุกแบบฟอร์มต้องขอความยินยอม: มาตรา 24 ของ PDPA มีฐานอื่น เช่น สัญญาหรือหน้าที่ตามกฎหมาย แต่ยังต้องแจ้งรายละเอียดตามมาตรา 23 เช่น วัตถุประสงค์และระยะเวลาเก็บ
• ข้อมูลอ่อนไหว: ข้อมูลสุขภาพเป็นข้อมูลอ่อนไหวตามมาตรา 26 ของ PDPA (คนละฉบับกับมาตรา 26 ของกฎหมายธุรกรรมฯ) ใบลาที่แนบใบรับรองแพทย์จึงควรจำกัดผู้เข้าถึงเป็นพิเศษ
• RoPA และเหตุละเมิด: แบบฟอร์มใหม่ควรอัปเดตบันทึกรายการตามมาตรา 39 และคู่มือระบุให้แจ้งเหตุละเมิดต่อสำนักงานภายใน 72 ชั่วโมงนับแต่ทราบเหตุเท่าที่ทำได้

ด้านระยะเวลาเก็บรักษา แนววินิจฉัยกรมสรรพากร กค 0811/8629 ลงวันที่ 4 กันยายน 2544 ตอบตามมาตรา 14 แห่ง พ.ร.บ.การบัญชี พ.ศ. 2543 ว่าต้องเก็บบัญชีและเอกสารประกอบการลงบัญชีไว้ 5 ปีนับแต่วันปิดบัญชี

แนววินิจฉัยเดียวกันยังอธิบายอายุความด้านภาษีเงินได้ว่า เจ้าพนักงานออกหมายเรียกได้ภายใน 2 ปีนับแต่วันยื่นรายการ และขยายได้ไม่เกิน 5 ปีตามมาตรา 19 แห่งประมวลรัษฎากร ส่วนกรณีไม่ยื่นรายการ ใช้อายุความ 10 ปีตามมาตรา 193/31 แห่งประมวลกฎหมายแพ่งและพาณิชย์ เอกสารบางประเภทจึงอาจต้องเก็บนานกว่า 5 ปี ระบบควรกำหนดนโยบายแยกตามประเภทเอกสารและป้องกันการลบก่อนกำหนด โดยยืนยันกับผู้สอบบัญชีอีกครั้งเพราะเป็นแนววินิจฉัยตั้งแต่ปี 2544

ติดตามร่างกฎหมายฉบับใหม่

แนวหน้ารายงานเมื่อ 30 กันยายน 2569 (ค.ศ. 2026) ว่ามีการเสนอร่าง พ.ร.บ.ธุรกรรมทางอิเล็กทรอนิกส์ฉบับใหม่ต่อคณะรัฐมนตรีเมื่อวันก่อนหน้า เพื่อปรับให้สอดคล้องกับกฎหมายต้นแบบของ UNCITRAL ครอบคลุมลายมือชื่อและตราอิเล็กทรอนิกส์ และสัญญาที่ทำผ่านระบบอัตโนมัติ โดยไม่ห้ามการทำธุรกรรมด้วยเอกสาร

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

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

Audit Trail และสิทธิ์การเข้าถึง

• บันทึกทุกเหตุการณ์: ผู้ยื่น ผู้อนุมัติ ผู้ปฏิเสธ วันเวลา ความเห็น และเวอร์ชันที่ถูกอนุมัติ
• ล็อกหลังอนุมัติ: ต้องแก้ไขให้สร้างเวอร์ชันใหม่และเริ่มอนุมัติใหม่ ไม่แก้ทับ
• สิทธิ์ตามบทบาท: เห็นเฉพาะเอกสารที่เกี่ยวกับหน้าที่ และแยกผู้ขอกับผู้อนุมัติ (Segregation of Duties)
• ผู้อนุมัติแทน: กำหนดช่วงเวลา และบันทึกว่าอนุมัติในฐานะผู้แทน
• บันทึกแก้ไม่ได้: ผู้ดูแลระบบไม่ควรลบหรือแก้ Audit Trail โดยไม่เหลือร่องรอย

ทำให้คนใช้จริง

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

ขั้นที่ 4: วัดผลว่าดีขึ้นจริงแล้วจึงขยาย

ตัวอย่างคำนวณ: ใบขอซื้อ

ตัวเลขต่อไปนี้เป็นตัวเลขสมมติเพื่ออธิบายวิธีคิด ไม่ใช่ผลลัพธ์จากลูกค้าหรือการรับประกันผล สมมติมีใบขอซื้อ 200 ใบต่อเดือน ผ่านหัวหน้าแผนก (รอเฉลี่ย 1 วัน) ฝ่ายจัดซื้อ (1.5 วัน) ฝ่ายการเงินตรวจงบ (1.5 วัน) และผู้บริหารอนุมัติทุกยอด (2 วัน) ตัวเลขเวลาในตัวอย่างนับเฉพาะเวลารอ ไม่รวมเวลาลงมือทำและรอบที่ถูกส่งกลับแก้ไข

• ก่อนปรับ: เวลารอเฉลี่ยต่อคำขอ 1 + 1.5 + 1.5 + 2 = 6 วันทำการ ส่งกลับแก้ไข 50 ใบ (25%) และหาเอกสารไม่พบ 4 ใบต่อเดือน
• ปรับกระบวนการ: ผู้บริหารอนุมัติเฉพาะยอดเกินวงเงิน (สมมติ 20% ของคำขอ) ระบบตรวจงบจาก ERP แทนการรอฝ่ายการเงิน และบังคับแนบใบเสนอราคา
• หลังปรับ: หัวหน้าแผนกรอ 0.5 วัน ฝ่ายจัดซื้อ 1 วัน คำขอยอดต่ำจึงใช้ 1.5 วัน ส่วนยอดสูงรอผู้บริหารเพิ่ม 1 วันเป็น 2.5 วัน เวลารอเฉลี่ยต่อคำขอ 0.8 × 1.5 + 0.2 × 2.5 = 1.7 วันทำการ
• ส่งกลับแก้ไขเหลือ 20 ใบ (10%) และทุกใบมีสถานะในระบบ จึงติดตามได้ครบ

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

เมื่อผลผ่านเกณฑ์ที่ตกลงไว้ก่อนเริ่ม จึงขยายไปแบบฟอร์มถัดไป โดยใช้แผนผัง กติกา และตัวชี้วัดชุดเดียวกัน

แผนดำเนินงานสำหรับแบบฟอร์มนำร่อง

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

1. เตรียม: เลือกแบบฟอร์มนำร่องและเจ้าของกระบวนการ เขียน Current State และเก็บค่าตั้งต้น
2. ออกแบบ: ทบทวนอำนาจอนุมัติ ตัดขั้นตอนซ้ำ ลดช่องข้อมูล และให้ผู้มีอำนาจเห็นชอบ Future State
3. ตรวจข้อกำหนด: ระดับลายมือชื่อ ระยะเวลาเก็บรักษา ประกาศความเป็นส่วนตัว และ RoPA ร่วมกับฝ่ายกฎหมายและผู้สอบบัญชี
4. พัฒนาและทดสอบ: ทดสอบการส่งกลับแก้ไข ผู้อนุมัติแทน กรณีระบบปลายทางไม่ตอบ และความครบของ Audit Trail
5. นำร่องและตัดสินใจ: ใช้กับหนึ่งหน่วยงาน เทียบผลกับเกณฑ์ที่ตกลงไว้ก่อน แล้วประกาศวันเลิกใช้กระดาษและเลือกแบบฟอร์มถัดไป

ก่อนเปิดใช้งานจริง ตรวจว่า: ตารางอำนาจอนุมัติใหม่ได้รับความเห็นชอบเป็นลายลักษณ์อักษร · ทุกช่องในแบบฟอร์มมีวัตถุประสงค์ · Audit Trail แก้ย้อนหลังไม่ได้ · มีผู้อนุมัติแทนและการเตือนเมื่อค้าง · มีทางสำรองพร้อมผู้รับผิดชอบ · มีค่าตั้งต้นและเกณฑ์ตัดสินใจขยาย

ก่อนคุยกับทีมพัฒนา เตรียมอะไรไปบ้าง?

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

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

แหล่งอ้างอิงและอ่านต่อ

• พ.ร.บ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พ.ศ. 2544 (ฉบับรวมแก้ไขถึงฉบับที่ 2 พ.ศ. 2551 ยังไม่รวมฉบับที่ 3 และ 4)
• ETDA — Digital Law
• ETDA — ประกาศข้อเสนอแนะมาตรฐานฯ ว่าด้วยแนวทางการลงลายมือชื่ออิเล็กทรอนิกส์ (ขมธอ. 23-2563)
• ประกาศคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์ เรื่องการจัดทำหรือแปลงเอกสารฯ พ.ศ. 2553
• LawPlus — ETDA E-Signature Guideline
• สภาดิจิทัลฯ — คู่มือเตรียมตัวสำหรับผู้ประกอบการตาม PDPA
• กรมสรรพากร — แนววินิจฉัย กค 0811/8629 (2544)
• แนวหน้า — รับการค้ายุคดิจิทัล รื้อ ก.ม.ธุรกรรมอิเล็กทรอนิกส์
• Harvard Business Review — Reengineering Work: Don't Automate, Obliterate
• Lean Enterprise Institute — Understanding the Fundamentals of Value-Stream Mapping
• บทความที่เกี่ยวข้อง: แผนงาน Digital Transformation สำหรับองค์กรไทย

บทความโดย UNIXDEV Team · 22 ตุลาคม 2026 · สรุปข้อกฎหมายเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย และตัวอย่างคำนวณเป็นตัวเลขสมมติ