การกำกับดูแลกระบวนการ: ทำให้เอกสารกระบวนการเป็นปัจจุบัน

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

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

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

การกำกับดูแลกระบวนการหมายถึงอะไร?

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

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

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

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

กรอบการกำกับดูแลกระบวนการควรกำหนดเรื่องใดบ้าง 4 ข้อ?

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

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

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

ทำไมเอกสารกระบวนการจึงล้าสมัย?

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

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

การกำกับดูแลกระบวนการต้องมีบทบาทและความรับผิดชอบอะไรบ้าง?

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

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

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

กำหนดรอบการทบทวนควบคู่กับบทบาทเหล่านี้ ทบทวนเมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้อง และกำหนดตารางทบทวนสำหรับกระบวนการที่ยังใช้งานอยู่.

ควรเริ่มกำกับดูแลกระบวนการใดก่อน?

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

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

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

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

ควรกำกับดูแลโมเดลที่ AI สร้างอย่างไร?

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

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

การกำกับดูแลให้ประโยชน์สองด้านในกรณีนี้ ระเบียนที่มีการกำกับดูแลซึ่งผู้ใช้อ่านได้ ยังเปิดให้ AI assistant อ่านผ่านAPI (ทุกแพ็กเกจ คิดค่าบริการตามการใช้งาน) และMCP server (แพ็กเกจ Enterprise) โดยใช้สิทธิ์การเข้าถึงชุดเดียวกัน เมื่อ assistant ตอบจากโมเดลที่เผยแพร่และอนุมัติแล้ว คำตอบก็มาจากกระบวนการ ไม่ใช่สำเนาที่คัดลอกไปใส่ในพรอมป์ต์ ดูข้อมูลที่ MCP server เปิดให้ใช้งานได้.

ประวัติเวอร์ชันของโมเดลกระบวนการแสดงเวอร์ชันก่อนหน้าและเวอร์ชันที่เผยแพร่แล้ว

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

มีสัญญาณ 5 ข้ออะไรบ้างที่บอกว่าเอกสารกระบวนการยังถูกต้อง?

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

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

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

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

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

5. คุณตอบคำถามการตรวจสอบได้จากระเบียนกระบวนการ การรวบรวมหลักฐานจากโฟลเดอร์ที่กระจัดกระจายอาจใช้เวลาหลายสัปดาห์ ใน ProcessMind ผู้รับผิดชอบ เวอร์ชัน การอนุมัติ และเอกสารแนบอยู่ในระเบียนเดียว ซึ่งส่งออกและนำไปแสดงได้.

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

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

จะนำการกำกับดูแลกระบวนการไปใช้จริงได้อย่างไร?

เริ่มจากกระบวนการหนึ่งที่คุณดูแลอยู่แล้ว และกำหนด 4 เรื่องให้ชัดเจนในโมเดลนั้นก่อนเขียนนโยบายใดๆ.

1. ระบุชื่อเจ้าของกระบวนการ

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

2. ตกลงว่าใครแก้ไขและใครอนุมัติ

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

3. เผยแพร่เพียงเวอร์ชันเดียว

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

4. กำหนดรอบการทบทวน

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

5. ตรวจสอบ 5 ข้อซ้ำ

   อีกหนึ่งเดือนให้ตรวจสอบ 5 ข้อข้างต้นซ้ำ หากข้อใดต้องใช้เวลาค้นหานานกว่าปกติ ให้เริ่มแก้ข้อนั้นก่อน

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