แอปรับทราบนโยบาย: ออกแบบโครงสร้างให้เหมาะกับพนักงาน

เหตุใดการรับทราบนโยบายจึงติดตามได้ยาก

อีเมลแจ้งนโยบายยังใช้ได้ดีเมื่อบริษัทมีพนักงาน 12 คน ฝ่ายทรัพยากรบุคคลแนบไฟล์ PDF ขอให้ทุกคนตอบกลับ แล้วเก็บคำตอบไว้ในกล่องจดหมาย วิธีนี้เริ่มใช้ไม่ได้เมื่อมีการเปลี่ยนนโยบาย ทีมงานขยายตัว หรือผู้จัดการต้องการหลักฐานว่าพนักงานคนใดยอมรับเอกสารฉบับใด

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

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

ระบบควรตอบคำถามที่ใช้งานจริงได้ดังนี้:

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

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

หากไม่มีโครงสร้างนี้ ฝ่ายทรัพยากรบุคคลอาจต้องใช้เวลาหลายชั่วโมงเปรียบเทียบเธรดอีเมล แถวในสเปรดชีต และไฟล์ชื่อ «จรรยาบรรณฉบับสุดท้าย» กับ «จรรยาบรรณฉบับสุดท้าย 2» ข้อมูลอาจดูครบถ้วนจนกว่าจะมีคนขอหลักฐานย้อนหลังหกเดือน

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

กำหนดบทบาทก่อนสร้างเวิร์กโฟลว์

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

ทีมส่วนใหญ่ต้องมีห้าบทบาท ในบริษัทขนาดเล็ก คนหนึ่งอาจรับผิดชอบมากกว่าหนึ่งบทบาทได้ แต่ควรแยกสิทธิ์ออกจากกัน

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

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

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

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

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

สร้างระเบียนนโยบายและเวอร์ชันที่ชัดเจน

ทุกนโยบายควรมีระเบียนที่เชื่อถือได้หนึ่งรายการ หลีกเลี่ยงชื่อไฟล์อย่าง «คู่มือ_ฉบับสุดท้าย_v3» เพราะจะสร้างความสับสนเมื่อพนักงาน ผู้จัดการ หรือผู้ตรวจสอบต้องยืนยันว่าเอกสารใดมีผลในวันที่กำหนด

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

กำหนดหมายเลขเวอร์ชันที่ชัดเจนให้ทุกนโยบายที่เผยแพร่ เช่น 1.0, 1.1 หรือ 2.0 กฎง่ายๆ ที่ใช้ได้ดีคือ การแก้ไขถ้อยคำเล็กน้อยให้เพิ่มเลขทศนิยม ส่วนการเปลี่ยนหน้าที่หรือกฎของพนักงานให้เพิ่มเลขหลัก การใช้แนวทางเดียวกันสำคัญกว่าระบบหมายเลขที่ซับซ้อน

แยกฉบับร่างออกจากนโยบายที่เผยแพร่แล้ว

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

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

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

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

ใช้ขั้นตอนอนุมัติและเผยแพร่ที่เรียบง่าย

เจ้าของนโยบายสร้างฉบับร่างที่มีชื่อ เนื้อหาภาษาง่าย หมายเลขเวอร์ชัน และวันที่มีผลที่เสนอ เจ้าของยังแก้ไขได้ขณะที่ฉบับร่างอยู่ระหว่างการตรวจทาน

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

เผยแพร่เวอร์ชันที่ล็อกไว้

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

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

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

ยกเลิกนโยบายโดยไม่ลบประวัติ

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

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

ทำให้พนักงานรับรองได้ง่าย

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

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

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

หน้าจอยืนยันช่วยป้องกันข้อผิดพลาดก่อนส่ง อาจแสดงข้อมูลดังนี้:

• นโยบายการทำงานทางไกล เวอร์ชัน 3.0
• วันที่มีผล: 1 มิถุนายน 2025
• กำหนดเวลาตอบ: 15 มิถุนายน 2025
• สถานะ: รับทราบแล้วเมื่อเวลา 10:42 น.

เพิ่มช่องความคิดเห็นหรือคำถามแบบไม่บังคับเมื่อจำเป็นต้องขอคำอธิบาย พนักงานอาจถามว่า «กฎการเดินทางใช้กับการไปพบลูกค้าในเดือนหน้าหรือไม่» ส่งคำถามให้เจ้าของนโยบาย แต่ไม่ต้องขัดขวางการรับทราบ เว้นแต่บริษัทกำหนดว่าต้องได้รับคำตอบก่อน

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

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

ส่งนโยบายให้พนักงานที่เกี่ยวข้อง

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

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

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

ใช้กลุ่มและรองรับข้อยกเว้น

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

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

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

แยกการส่งออกจากการรับทราบ

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

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

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

เตือนผู้ที่ยังไม่ตอบโดยไม่รบกวนทุกคน

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

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

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

กำหนดการยกระดับที่พอดี

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

ตารางสั้นๆ มักใช้ได้ดี:

• ส่งการเตือนครั้งแรกก่อนกำหนด 5 ถึง 7 วัน
• ส่งการเตือนครั้งสุดท้ายในวันครบกำหนด
• แจ้งผู้จัดการหรือผู้ติดต่อฝ่ายทรัพยากรบุคคลหลังพ้นกำหนด
• ติดตามอีกครั้งเฉพาะรายการที่ยังเกินกำหนด

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

ใน AppMaster กระบวนการธุรกิจแบบภาพสามารถกรองผู้รับตามสถานะการรับทราบ ตั้งเวลาส่งข้อความ และอัปเดตงานเมื่อมีคนตอบ

ทำให้ประวัติการตรวจสอบอ่านง่าย

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

ใช้จำนวนจากรายชื่อผู้รับเดิม หาก 80 คนได้รับเวอร์ชัน 3.0 ให้แสดงว่ามอบหมาย 80 คน แม้ภายหลังจะมี 5 คนย้ายทีม การทำเช่นนี้ช่วยรักษาประวัติที่ถูกต้อง ณ วันที่เผยแพร่

ทำให้ค้นหาระเบียนได้ง่าย

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

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

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

ส่งออกระเบียนพร้อมบริบท

สำหรับการตรวจสอบภายใน ให้ส่งออกรายงานที่มีวันที่ แทนการส่งรายชื่อเปล่าๆ รายงานควรมีชื่อนโยบาย เวอร์ชัน วันที่เผยแพร่ กำหนดเวลา รายละเอียดพนักงาน สถานะ เวลารับทราบ และวันที่สร้างรายงาน

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

ตัวอย่าง: อัปเดตนโยบายการทำงานทางไกล

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

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

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

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

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

ข้อผิดพลาดที่ทำให้ประวัติไม่น่าเชื่อถือ

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

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

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

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

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

เริ่มจากเวิร์กโฟลว์ขนาดเล็ก

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

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

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

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

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

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