การอนุมัติพึ่งพากรุ๊ปแชทใน WeChat: ทำให้ระบบงานอนุมัติ หนังสือราชการ และสิทธิ์การเข้าถึงขององค์กรเป็นไปอย่างไร

บทนำ: การอนุมัติการเดินทางต่างถิ่นอาศัยข้อความในกลุ่ม ขณะที่การหาผู้อนุมัติก็อาศัยการถาม

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

นี่ไม่ใช่เพียงกรณีเฉพาะ กระบวนการอนุมัติในบริษัทจำนวนมากทั่วประเทศดำเนินไปเช่นนี้:

• การหาคนต้องอาศัยการถาม: ในสัปดาห์แรกของการเข้าทำงานของพนักงานใหม่ คำถามที่พบบ่อยที่สุดคือ “ฉันจะขอลาต้องไปขออนุมัติกับใคร? แล้วการเบิกค่าใช้จ่ายต้องให้ใครตรวจสอบ?”
• ข้อความกลุ่มเมื่อเป็นหลักฐาน: การใช้ “@หัวหน้า ได้รับอนุมัติแล้ว” ในกลุ่มวีแชทหรือ DingTalk ถือเป็นการอนุมัติผ่าน และไม่สามารถตรวจสอบย้อนหลังได้
• ข้อมูลระหว่างแผนกไม่ตรงกัน: ฝ่ายขายเห็นว่าการเยี่ยมลูกค้าได้รับอนุมัติแล้ว แต่ฝ่ายการตลาดกลับมองว่ายังไม่ได้รับอนุมัติ และฝ่ายการเงินก็ได้ชำระเงินตามภาพหน้าจอของฝ่ายขาย
• สิทธิ์อนุญาตขึ้นอยู่กับคำพูด: ผู้จัดการคนหนึ่งลาออก แต่ยังไม่ได้ถอนสิทธิ์เข้าถึงระบบ ทำให้ผู้มาใหม่ไม่ทราบว่าสัญญาที่ผู้จัดการคนเก่าอนุมัติอยู่ในมือใคร

ปัญหาเหล่านี้มีต้นตอไม่ได้อยู่ที่ว่า “การอนุมัตินั้นซับซ้อนเพียงใด” แต่อยู่ที่เส้นทางการอนุมัติไม่ได้เข้าสู่ระบบ. ข้อความกลุ่ม การพูดคุย และภาพหน้าจอล้วนเป็นสื่อชั่วคราว สิ่งที่ขาดไปคือตัวกลางที่มีโครงสร้าง มีการบันทึกไว้ และสามารถตรวจสอบย้อนกลับได้ ระบบ OA (ระบบสำนักงานอัตโนมัติ) คือการจัดโครงสร้างเรื่องนี้ โดยรวบรวม “ใคร เรื่องอะไร เมื่อใด ได้ติดต่อใคร อนุมัติตามกฎเกณฑ์ใด และหลังจากอนุมัติแล้วข้อมูลจะถูกบันทึกอย่างไร” ทั้งหมดไว้ในเส้นทางการอนุมัติเพียงเส้นเดียว

01 แบ่งแยกธุรกิจอย่างไร: โครงสร้างสามชั้นของเส้นทางการอนุมัติ

การแยกเรื่องการอนุมัตินี้ออกเป็นสามระดับ ที่จริงแล้วมีอยู่สามชั้น:

1. ระดับรายการ: พนักงานสามารถส่งคำขอ “การเดินทางเพื่อธุรกิจ การลา การเบิกค่าใช้จ่าย สัญญา การประทับตราเอกสาร การจัดซื้อ” และรายการอื่นๆ ได้ โดยแต่ละรายการจะมีข้อมูลเกี่ยวกับจำนวนเงิน ระยะเวลา ไฟล์แนบ และวัตถุประสงค์ทางธุรกิจที่เกี่ยวข้อง (เช่น คำขอเดินทางเพื่อธุรกิจเชื่อมโยงกับใบสั่งขาย หรือการเบิกค่าใช้จ่ายเชื่อมโยงกับใบกำกับภาษี)
2. ชั้นกระบวนการ: รายการจะไหลจากโหนดหนึ่งไปยังอีกโหนดหนึ่ง โดยผู้อนุมัติของแต่ละโหนดจะคำนวณแบบไดนามิก (ตามแผนก ระดับ เงินจำนวน และประเภทสินค้า) ไม่ใช่กำหนดตายตัวไว้ล่วงหน้า
3. ชั้นข้อมูล: หลังจากได้รับการอนุมัติหรือถูกปฏิเสธแล้ว ข้อมูลจะต้องถูกบันทึกกลับไปยังระบบธุรกิจ (HR, การเงิน, ฝ่ายขาย, คลังสัญญา) ไม่ใช่เพียงแค่หยุดอยู่ในกระบวนการอนุมัติเท่านั้น

ความสัมพันธ์สามระดับคือ:เรื่องคือทางเข้า กระบวนการคือแกนหลัก และข้อมูลคือทางออก. หากพัฒนาระบบ OA โดยทำเฉพาะกระบวนการแต่ไม่ได้สร้างช่องทางส่งออกข้อมูล กระบวนการอนุมัติก็จะกลายเป็นเกาะที่แยกตัวออกมา; หากทำเฉพาะรายการแต่ไม่ได้กำหนดกระบวนการ ก็จะย่อหย่อนลงกลายเป็นเพียง “ระบบกรอกแบบฟอร์ม” เท่านั้น

02 ออกแบบอย่างไร: ชุดสามส่วนประกอบ ได้แก่ โหนดแบบไดนามิก เมทริกซ์สิทธิ์ และการบันทึกข้อมูล

การออกแบบโหนด: ผู้อนุมัติไม่ได้ถูกกำหนดตายตัว

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

วิธีการที่ถูกต้อง:ผู้อนุมัติถูกคำนวณแบบไดนามิกตามกฎ. มิติของกฎมักมีสี่ประการ:

• มิติของแผนก: แผนกของผู้สมัครจะถูกแมปไปยังหัวหน้าแผนกปัจจุบันของแผนกนั้น (ตรวจสอบตามลำดับชั้นองค์กรแบบเรียลไทม์)
• มิติระดับ: ยอดเงิน จำนวนวัน และยอดสัญญาจะสอดคล้องกับช่วงต่าง ๆ ซึ่งมีระดับการอนุมัติที่แตกต่างกันไป
• มิติของบทบาท: ยอดสัญญาเกิน 500,000 หยวน ฝ่ายกฎหมายต้องเข้ามามีส่วนร่วม; พนักงานที่เดินทางไปต่างประเทศ ต้องมีการลงนามรับรองด้านความปลอดภัยและข้อกำหนดตามกฎหมาย
• มิติของตัวแทน: เมื่อผู้อนุมัติลาหรือไปทำงานต่างถิ่น ระบบจะส่งต่อไปยังผู้แทนโดยอัตโนมัติ โดยผู้แทนจะถูกกำหนดโดยโครงสร้างองค์กรหรือฝ่ายทรัพยากรบุคคล

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

การออกแบบสิทธิ์: สามระดับ ได้แก่ เมนู ข้อมูล และฟิลด์

สิทธิ์ไม่ใช่เรื่องว่า “เข้าระบบได้หรือไม่” แต่เป็นระดับสามขั้น:

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

เมื่อแยกสิทธิ์ระดับสามออกแล้ว ระบบ OA ก็สามารถรองรับโครงสร้างองค์กรที่ซับซ้อนได้: กลุ่มบริษัท–สาขา–แผนก–กลุ่มย่อย โดยข้อมูลข้ามระดับจะต้องควบคุมแบบขนานตามกฎสองข้อ คือ “ฉันสามารถมองเห็นเฉพาะสายงานของตนเอง + ฉันเป็นหัวหน้าของสายงานนั้น”

การออกแบบการบันทึก: องค์ประกอบเจ็ดประการของบันทึกการอนุมัติ

การดำเนินการอนุมัติแต่ละครั้งต้องบันทึกข้อมูลทั้งเจ็ดรายการ:

1. ผู้ดำเนินการ: ใครเป็นคนกดนะ
2. เวลาดำเนินการ: แม่นยำถึงวินาที
3. การดำเนินการ: อนุมัติ ปฏิเสธ ส่งต่อ เพิ่มลายเซ็น ถอนกลับ
4. ข้อเสนอแนะในการดำเนินงาน: ต้องกรอกความคิดเห็นการปฏิเสธ หากเห็นด้วยสามารถเว้นว่างได้
5. ตำแหน่งของโหนด: ปัจจุบันอยู่ในขั้นตอนใดของกระบวนการ
6. สแนปช็อตข้อมูลที่เชื่อมโยง: ขณะอนุมัติ ค่าฟิลด์ของวัตถุทางธุรกิจ (ยอดเงิน ไฟล์แนบ) จะถูกเก็บรักษาไว้ตามเดิม และไม่อนุญาตให้แก้ไขวัตถุทางธุรกิจภายหลังโดยที่บันทึกการอนุมัติยังคงเหมือนเดิม
7. อุปกรณ์และร่องรอย IP: ส่งจากอุปกรณ์เครื่องใด และ IP ใด (เพื่อการตรวจสอบตามกฎระเบียบ)

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

03 วิธีการพัฒนา: ชุดสามส่วนประกอบ ได้แก่ เครื่องมือขับเคลื่อนกระบวนการ เครื่องมือสร้างแบบฟอร์ม และบัสข้อความ

หัวใจสำคัญของการพัฒนา OA คือกลไกสามตัว ไม่ใช่หน้าจอ N หน้า:

เอนจินกระบวนการ

เอนจินกระบวนการไม่ต้องเขียนโค้ด สามารถรันกระบวนการได้เพียงผ่านการกำหนดค่า คุณสมบัติที่รองรับมีดังนี้:

• แบบอนุกรม แบบขนาน แบบลงนามร่วม หรือแบบลงนามตามลำดับ: กระบวนการพื้นฐานสี่ประเภท โดยการยื่นขอรับตำแหน่งเป็นแบบลำดับ (HR → หัวหน้า → ซีอีโอ) ส่วนการอนุมัติซ้ำของฝ่ายจัดซื้อเป็นแบบขนาน (ฝ่ายการเงินและหัวหน้าฝ่ายจัดซื้อพิจารณาพร้อมกัน)
• การแยกเงื่อนไข: แยกตามมูลค่า ประเภทสินค้า และระดับของผู้ยื่นคำขอ โดยคำสั่งซื้อที่มีมูลค่าต่ำกว่า 5,000 หยวนจะผ่านกระบวนการแบบเรียบง่าย คำสั่งซื้อระหว่าง 5,000 ถึง 50,000 หยวนจะต้องผ่านการตรวจสอบสองขั้นตอนโดยฝ่ายงานและฝ่ายการเงิน และคำสั่งซื้อที่มีมูลค่าเกิน 50,000 หยวนจะต้องได้รับการอนุมัติจากซีอีโอเพิ่มเติม
• การย้อนกลับและการปฏิเสธ: รองรับการปฏิเสธกลับไปยังผู้สมัคร การปฏิเสธกลับไปยังโหนดใดก็ได้ และการปฏิเสธกลับไปยังโหนดก่อนหน้า โดยต้องรองรับทั้งสามประเภทนี้
• การลงนามเพิ่มเติมและการส่งต่อการลงนาม: ผู้อนุมัติสามารถส่งต่อภารกิจให้เพื่อนร่วมงานได้ (การส่งต่อการอนุมัติ) และยังสามารถเชิญเพื่อนร่วมงานเข้ามาช่วยพิจารณาพร้อมกันได้ด้วย (การเพิ่มการอนุมัติ)
• ยกเลิกและทำให้เป็นโมฆะ: ผู้สมัครสามารถถอนรายการที่ยังไม่ได้รับการอนุมัติได้; ผู้ดูแลระบบสามารถยกเลิกรายการที่มีความผิดปกติได้.

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

เอนจินฟอร์ม

แบบฟอร์มต้องการ “การออกแบบแบบไม่ใช้โค้ด”: ประเภทของฟิลด์ (ข้อความ, ตัวเลข, วันที่, เอกสารแนบ, ผู้เกี่ยวข้องกับวัตถุทางธุรกิจ), กฎการตรวจสอบ, การกำหนดให้กรอกหรือไม่จำเป็นต้องกรอก, เงื่อนไขการแสดงหรือซ่อน ล้วนสามารถกำหนดได้ด้วยการลากและวางแบบภาพรวม ด้วยวิธีนี้ ฝ่ายทรัพยากรบุคคลสามารถปรับเปลี่ยนฟิลด์การเบิกจ่าย ขณะที่ฝ่ายขายสามารถเพิ่มฟิลด์สัญญาได้ไม่ต้องจัดคิวไอที。

เอนจินฟอร์มต้องรองรับ:

• สิทธิ์ระดับฟิลด์: แบบฟอร์มเดียวกัน แต่ผู้อนุมัติที่แตกต่างกันจะเห็นช่องข้อมูลที่ไม่เหมือนกัน (ผู้อนุมัติทั่วไปจะไม่เห็นหมายเลขโทรศัพท์มือถือของผู้ยื่นคำขอ)
• การเชื่อมโยงฟิลด์: เมื่อเลือก “ประเภทสัญญา = สัญญาบริการ” จะขยายฟิลด์เฉพาะของสัญญาบริการโดยอัตโนมัติ
• การเขียนข้อมูลกลับไปยังระบบธุรกิจ: หลังจากได้รับการอนุมัติแล้ว จะเขียนข้อมูลกลับไปยังระบบธุรกิจ (สถานะสัญญา, การเข้างานของฝ่ายบุคคล, เอกสารทางการเงิน) โดยอัตโนมัติ

บัสข้อความ

เมื่อการอนุมัติผ่านหรือถูกปฏิเสธ ผู้ยื่นคำขอและระบบธุรกิจที่เกี่ยวข้อง (ฝ่ายบุคคล, การเงิน, ฝ่ายขาย) จะได้รับแจ้งเตือนทันที บัสข้อความจะส่งข้อมูลแบบรวมศูนย์:

• การแจ้งเตือนภายในระบบ: ข้อความในระบบพร้อมรายการที่ต้องดำเนินการ
• การแจ้งเตือนผ่าน IM: webhook ของ WeCom, DingTalk, Feishu จะถูกส่งไปยังกลุ่มหรือบุคคลที่เกี่ยวข้อง
• อีเมลและ SMS: การแจ้งเตือนสำรองในจุดสำคัญ (การอนุมัติสัญญา, การเดินทางต่างประเทศ)
• ข้อความจากระบบธุรกิจ: หลังจากได้รับการอนุมัติแล้ว จะส่งข้อความไปยังรายการที่ต้องดำเนินการของระบบธุรกิจ (ฝ่ายการเงินได้รับรายการเบิกค่าใช้จ่ายที่ต้องดำเนินการ, ฝ่ายบุคคลได้รับรายการเริ่มงานที่ต้องดำเนินการ)

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

บทสรุป: ลำดับขั้นตอน การจัดการความเสี่ยง และตัวชี้วัด

การนำระบบ OA มาใช้งานแบ่งออกเป็นสามขั้นตอน:

1. ระยะแรก (1 เดือน): นำสามเรื่องที่มีความถี่สูง ได้แก่ การลา การเดินทาง และการเบิกค่าใช้จ่าย มาใช้ในระบบ ครอบคลุมพนักงานทุกคน เริ่มย้ายกระบวนการอนุมัติจากกลุ่ม WeChat เข้าสู่ระบบก่อน แม้จะย้ายเพียงสามเรื่องนี้ ก็ทำให้ข้อมูลระหว่างหน่วยงานสอดคล้องกันทันที
2. ระยะที่สอง (2–3 เดือน): นำสี่เรื่องที่มีความถี่ปานกลาง ได้แก่ สัญญา การประทับตรา การจัดซื้อ และการชำระเงิน มาใช้ในระบบ เชื่อมต่อกับระบบการเงิน ระยะนี้ต้องทำให้สามารถเขียนข้อมูลกลับไปยังระบบได้ (เมื่อการอนุมัติสัญญาผ่าน จะถูกจัดเก็บลงคลังสัญญาโดยอัตโนมัติ)
3. ระยะที่สาม (ตามความต้องการ): นำกระบวนการบุคคลทั้งหมด เช่น การประเมินผล การเลื่อนตำแหน่ง การบรรจุเป็นพนักงานประจำ การสรรหาและการออกจากงาน มาใช้ในระบบ ระยะนี้นำโดยฝ่ายบุคคล และต้องเชื่อมต่อข้อมูลหลักของฝ่ายบุคคลให้สมบูรณ์

ความเสี่ยงที่พบบ่อย:

• กฎระเบียบที่ยืดหยุ่นเกินไป: การกำหนดกระบวนการอนุมัติที่อิสระเกินไป ทำให้ไม่มีใครรู้ว่าขั้นตอนต่อไปควรให้ใครเป็นผู้อนุมัติ หลักการ: แม่แบบกระบวนการไม่ควรมีมากกว่า 30 ขั้นตอน หากมีมากเกินไปจะควบคุมไม่ได้
• การไม่กำหนดผู้แทน: เมื่อผู้อนุมัติเดินทางและไม่ได้กำหนดผู้แทน กระบวนการจะติดขัดนานถึง 3 วันโดยไม่มีใครตรวจสอบ ระบบจะตรวจจับ “กระบวนการติดขัดเกิน 24 ชั่วโมง” และส่งสัญญาณเตือนโดยอัตโนมัติ
• การไม่เขียนข้อมูลกลับไปยังระบบ: แม้การอนุมัติจะผ่านแล้ว แต่ระบบฝ่ายบุคคลยังไม่อัปเดตข้อมูลการเข้างาน และระบบการเงินก็ยังไม่มีเอกสารทางการเงิน การเขียนข้อมูลกลับต้องมี “การตรวจสอบสองชั้น” หลังจาก OA เขียนเสร็จ ระบบจะเรียกใช้ API ของระบบธุรกิจเพื่อยืนยันว่าได้รับข้อมูลแล้ว

ตัวชี้วัดว่าโครงการประสบความสำเร็จหรือไม่:

• ระยะเวลาเฉลี่ยในการอนุมัติ: ก่อนเปิดใช้งาน กระบวนการในกลุ่มใช้เวลา 3 วัน หลังเปิดใช้งาน ระบบสามารถปิดลูปได้ภายใน 1 วัน
• ความสอดคล้องของข้อมูลระหว่างหน่วยงาน: อัตราความผิดพลาดในการตรวจสอบข้อมูลระหว่างฝ่ายบุคคล การเงิน และฝ่ายขาย ลดลงกว่า 80%
• อัตราการตรวจสอบย้อนกลับได้: สุ่มตรวจสอบการอนุมัติในอดีต 20 รายการ อัตราความครบถ้วนของข้อมูลทั้งเจ็ดองค์ประกอบอยู่ที่ 100%

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