ตัวอย่างวิธีปฏิบัติงานมาตรฐาน: 3 ตัวอย่างพร้อมขั้นตอน
ดูตัวอย่าง standard operating procedure 3 รายการ พร้อมขั้นตอน ระบบ และกรณียกเว้น เรียนรู้ว่า SOP ควรมีอะไรบ้างและจะดูแลให้เป็นปัจจุบันได้อย่างไร.
ตัวอย่าง standard operating procedure จะมีประโยชน์ที่สุดเมื่อแสดงขั้นตอน ระบบ และกรณียกเว้นที่เกิดขึ้นจริง ไม่ใช่แค่รายชื่อหัวข้อ ด้านล่างมีตัวอย่างที่กรอกข้อมูลแล้ว 3 รายการ ตามด้วยส่วนประกอบของขั้นตอนปฏิบัติงานที่ดูแลต่อได้ วิธีบันทึกข้อมูลไว้ตรงจุดที่ทำงาน และวิธีตรวจสอบว่าเนื้อหายังตรงกับงานจริงหรือไม่.
standard operating procedure คืออะไร?
SOP อธิบายวิธีทำงานที่ต้องทำซ้ำ โดยระบุว่าใครทำ ทำตามลำดับใด ใช้ระบบไหน และต้องทำอย่างไรเมื่อไม่สามารถใช้ขั้นตอนปกติได้ SOP เป็นข้อมูลอ้างอิงร่วมกันสำหรับทีมและใช้ฝึกอบรมผู้เริ่มงานใหม่ แต่จะมีประโยชน์ก็ต่อเมื่อมีคนตรวจสอบให้ตรงกับงานจริงอยู่เสมอ.
SOP ต่างจากนโยบาย วิธีปฏิบัติงาน หรือแผนผังกระบวนการอย่างไร?
เอกสารเหล่านี้มีวัตถุประสงค์ต่างกัน
- นโยบายระบุสิ่งที่องค์กรตัดสินใจไว้ เช่น “ใบแจ้งหนี้ที่มียอดเกิน 10,000 ต้องได้รับอนุมัติจากสองคน”
- วิธีปฏิบัติงานอธิบายวิธีทำขั้นตอนใดขั้นตอนหนึ่ง เช่น ต้องใช้หน้าจอ ช่องข้อมูล หรือปุ่มใด SOP บอกว่าขั้นตอนต่อไปคืออะไร ส่วนวิธีปฏิบัติงานบอกว่าต้องทำขั้นตอนนั้นอย่างไร
- แผนผังกระบวนการแสดงการไหลของงานผ่านบทบาทและระบบต่างๆ ส่วน SOP อธิบายงานหนึ่งอย่างละเอียด ดูคู่มือการทำแผนที่กระบวนการของเรา
เขียน SOP โดยคำนึงถึงผู้ที่ทำงาน รวมถึงกรณีที่ต้องตัดสินใจหรือจัดการข้อยกเว้น
ตัวอย่างวิธีปฏิบัติงานมาตรฐาน 3 รายการ
ตัวอย่างแต่ละรายการใช้ตารางขั้นตอนที่ระบุบทบาท ระบบ ผลลัพธ์ที่คาดหวัง และแนวทางจัดการข้อยกเว้น รายละเอียดเหล่านี้ช่วยให้ทำตามขั้นตอนได้ง่ายขึ้น และเปรียบเทียบกับงานที่บันทึกไว้ในระบบของคุณได้สะดวกขึ้น.
ตัวอย่างขั้นตอนการปฏิบัติงานมาตรฐาน 3 แบบ
ขั้นตอนนี้เริ่มเมื่อใบแจ้งหนี้ไม่ผ่านการจับคู่สามทาง คอลัมน์ข้อยกเว้นอธิบายว่าควรทำอย่างไรเมื่อขั้นตอนไม่เป็นไปตามแผน.
| ขั้นตอน | ผู้รับผิดชอบ | ระบบ | ผลลัพธ์ | หากเกิดปัญหา |
|---|---|---|---|---|
| 1 | เจ้าหน้าที่บัญชีเจ้าหนี้ | ERP | สร้างเคสข้อยกเว้นพร้อมรหัสสาเหตุ | ไม่มีรหัสสาเหตุ: ส่งต่อให้หัวหน้าทีมบัญชีเจ้าหนี้ก่อนตรวจสอบ |
| 2 | เจ้าหน้าที่บัญชีเจ้าหนี้ | ERP, พอร์ทัลซัพพลายเออร์ | ระบุส่วนต่าง: ราคา จำนวน หรือการจัดส่ง | ราคาคลาดเคลื่อนไม่เกิน 2%: บันทึกใบแจ้งหนี้และลงรายการส่วนต่าง |
| 3 | ผู้จัดซื้อ | ERP | ยืนยันว่าได้รับสินค้าตามที่สั่ง | ผู้จัดซื้อไม่พร้อม 2 วัน: ส่งต่อให้ผู้จัดการหมวดสินค้า |
| 4 | เจ้าหน้าที่บัญชีเจ้าหนี้ | ERP | ขอใบลดหนี้หรืออนุมัติใบแจ้งหนี้เพื่อชำระเงิน | ซัพพลายเออร์โต้แย้งใบลดหนี้: เปลี่ยนไปใช้ขั้นตอนจัดการข้อพิพาท อย่าปล่อยเคสค้างไว้ |
| 5 | หัวหน้าทีมบัญชีเจ้าหนี้ | ERP | ปิดเคสพร้อมบันทึกสาเหตุ | พบสาเหตุเดิมต่อเนื่อง 3 เดือน: ยื่นคำขอเปลี่ยนแปลงกระบวนการ |
แถวสุดท้ายช่วยให้ทีมแจ้งปัญหาที่เกิดซ้ำเพื่อนำไปทบทวน โดยไม่ตั้งสมมติฐานว่าข้อยกเว้นทุกกรณีต้องแก้ด้วยวิธีเดียวกัน.
ตัวอย่างที่ 2: การรับสินค้าและจัดเก็บเข้าที่
| ขั้นตอน | ผู้รับผิดชอบ | ระบบ | ผลลัพธ์ | หากเกิดปัญหา |
|---|---|---|---|---|
| 1 | พนักงานรับสินค้า | WMS | ตรวจสอบการจัดส่งกับ ASN | ไม่มี ASN: บันทึกรับสินค้าด้วยตนเองและแจ้งซัพพลายเออร์ |
| 2 | พนักงานรับสินค้า | WMS | บันทึกจำนวนและความเสียหาย | พบความเสียหาย: ถ่ายภาพ กักพาเลตไว้ และแจ้งฝ่ายจัดซื้อ |
| 3 | ผู้ตรวจสอบคุณภาพ | QMS | ตัดสินใจอนุมัติสินค้าล็อตนั้น | สินค้าล็อตนั้นถูกระงับ: เก็บสินค้าไว้ในพื้นที่กักกัน ห้ามเริ่มจัดเก็บเข้าที่ |
| 4 | พนักงานคลังสินค้า | WMS | จัดเก็บเข้าตำแหน่งที่ระบบแนะนำ | ตำแหน่งถูกปิดใช้งาน: ใช้ช่องเก็บสำรองและบันทึกไว้ |
| 5 | พนักงานคลังสินค้า | WMS | สินค้าพร้อมให้หยิบ | บันทึกรับสินค้าหลังเวลาตัดรอบ: ตรวจสอบว่าต้องวางแผนคำสั่งซื้อที่ยังเปิดใหม่หรือไม่ |
ตัวอย่างที่ 3: การคัดแยกเหตุขัดข้องที่ศูนย์บริการไอที
| ขั้นตอน | ผู้รับผิดชอบ | ระบบ | ผลลัพธ์ | หากเกิดปัญหา |
|---|---|---|---|---|
| 1 | เจ้าหน้าที่ศูนย์บริการ | ITSM | บันทึกเหตุขัดข้องพร้อมบริการ ผลกระทบ และความเร่งด่วน | ติดต่อผู้ใช้ไม่ได้: บันทึกแทนผู้ใช้ พร้อมระบุแหล่งที่มาของข้อมูล |
| 2 | เจ้าหน้าที่ศูนย์บริการ | ITSM, CMDB | กำหนดลำดับความสำคัญตามตารางผลกระทบและความเร่งด่วน | กลุ่มผู้แก้ไขไม่เห็นด้วยกับลำดับความสำคัญ: ส่งต่อให้เจ้าของบริการ อย่าเปลี่ยนข้อตกลงโดยไม่แจ้ง |
| 3 | กลุ่มผู้แก้ไข | ITSM | วินิจฉัยและพยายามแก้ไขภายในกรอบเวลา SLA | ต้องเปลี่ยนแปลงระบบเพื่อแก้ไข: เชื่อมโยงบันทึกการเปลี่ยนแปลงและเปิดเหตุขัดข้องไว้ |
| 4 | เจ้าหน้าที่ศูนย์บริการ | ITSM | ยืนยันกับผู้ใช้และปิดเคส | ผู้ใช้ไม่ยืนยันภายใน 3 วัน: ปิดเคสพร้อมบันทึกสาเหตุ |
SOP ควรมีอะไรบ้าง?
ใช้โครงสร้างนี้เป็นจุดเริ่มต้นสำหรับจัดทำขั้นตอนการปฏิบัติงานครั้งถัดไป:
- วัตถุประสงค์และขอบเขต: ระบุว่าขั้นตอนนี้ครอบคลุมเรื่องใดและไม่ครอบคลุมเรื่องใด การกำหนดขอบเขตให้ชัดช่วยให้ SOP แต่ละฉบับมุ่งเน้นงานเดียว
- จุดเริ่มต้น: ระบุเหตุการณ์ที่ทำให้เริ่มขั้นตอน เพื่อให้ผู้อ่านทราบว่าเมื่อใดควรใช้
- บทบาท: ระบุความรับผิดชอบตามบทบาท ไม่ใช่ตามรายบุคคล เพราะคนเปลี่ยนได้ แต่บทบาทมักคงเดิม
- ขั้นตอนและระบบที่ใช้: อธิบายแต่ละขั้นตอนว่าใครเป็นผู้ทำและใช้ระบบใด
- แนวทางจัดการข้อยกเว้น: อธิบายว่าต้องทำอย่างไรเมื่อใช้ขั้นตอนปกติไม่ได้ ระบุกรณีที่เบี่ยงเบนจากปกติซึ่งพบบ่อย ไม่ใช่แค่กรณีที่เป็นไปตามแผน
- การควบคุมและหลักฐาน: ระบุว่าต้องบันทึกอะไร บันทึกไว้ที่ใด และเก็บไว้นานเท่าใด
- เจ้าของและประวัติการแก้ไข: ระบุผู้รับผิดชอบ พร้อมบันทึกวันที่และรายละเอียดของการเปลี่ยนแปลงแต่ละครั้ง
- เงื่อนไขให้ทบทวน: ระบุเหตุการณ์ที่ควรทำให้ทบทวน เช่น การเปลี่ยนระบบ กฎระเบียบ หรือทีมงาน หรือผลการดำเนินงานที่เปลี่ยนไปตามข้อมูลที่วัดได้.
ประวัติการแก้ไขแสดงว่าเปลี่ยนอะไรและเมื่อใด ส่วนเหตุที่ต้องทบทวนช่วยให้คุณกลับมาตรวจสอบขั้นตอนก่อนที่จะล้าสมัย.
จะตรวจสอบได้อย่างไรว่า SOP พร้อมใช้งานแล้ว?
ก่อนเผยแพร่หรือแก้ไขขั้นตอน ให้ลองถามคำถามเหล่านี้:
- ขอบเขตระบุหรือไม่ว่า SOP นี้ไม่ครอบคลุมเรื่องใด?
- ระบุจุดเริ่มต้นไว้อย่างชัดเจนตั้งแต่ต้นหรือไม่?
- แต่ละขั้นตอนระบุบทบาท ระบบ และผลลัพธ์ที่คาดหวังหรือไม่?
- ขั้นตอนที่ทำในแอปพลิเคชันแสดงหน้าจอที่ผู้อ่านจะเห็นหรือไม่?
- ขั้นตอนอธิบายหรือไม่ว่าควรทำอย่างไรเมื่อใช้แนวทางปกติไม่ได้?
- มีการระบุเจ้าของเอกสารและประวัติการแก้ไขหรือไม่?
- มีเหตุการณ์เฉพาะที่ทำให้ต้องทบทวนหรือไม่?
- คุณเปรียบเทียบขั้นตอนกับข้อมูลเหตุการณ์ได้หรือไม่ และได้ตรวจสอบความแตกต่างกับเจ้าของกระบวนการแล้วหรือยัง?
หากยังตอบคำถามสุดท้ายไม่ได้ ให้เริ่มจากระบุว่าระบบใดบันทึกงานนั้น วิธีนี้ช่วยให้ตรวจสอบได้ว่าขั้นตอนยังตรงกับสิ่งที่เกิดขึ้นจริงหรือไม่ และทำให้การจัดทำ SOP เป็นวงจรทบทวน แทนที่จะเป็นเพียงการเก็บเอกสาร.
วิธีจัดการ SOP
การเขียน SOP เป็นเพียงครึ่งแรก ส่วนที่ยากกว่าคือการจัดการ SOP ทั้งชุด ทั้งที่จัดเก็บขั้นตอน เวอร์ชันปัจจุบัน และผู้รับผิดชอบการทบทวน ไม่ว่าคุณจะใช้ซอฟต์แวร์จัดการขั้นตอนการปฏิบัติงานโดยเฉพาะ หรือเก็บเอกสารไว้ในโฟลเดอร์ การแยกสำเนาให้แต่ละทีมเป็นวิธีที่ทำให้เอกสารล้าสมัย ProcessMind เก็บขั้นตอนไว้กับกระบวนการที่อธิบาย เพื่อให้การกำกับดูแลอยู่กับเนื้อหา:
- เพิ่มขั้นตอนไว้ในกิจกรรมที่อธิบาย แต่ละกระบวนการมีโครงสร้างเอกสารที่กำหนดไว้ครั้งเดียวในระดับสภาพแวดล้อม ทำให้ทุกขั้นตอนเริ่มจากหัวข้อเดียวกัน ทั้งคำอธิบาย ขอบเขต บทบาท เป้าหมาย และการกำกับดูแล เพิ่มหัวข้อที่องค์กรต้องการได้ และเก็บคู่มือการทำงานไว้กับขั้นตอนที่เกี่ยวข้อง แทนการแยกไว้ในโฟลเดอร์ที่ต้องค้นหา
- ทบทวนพร้อมกับกระบวนการส่วนอื่น กระบวนการจะเปลี่ยนสถานะตั้งแต่ฉบับร่าง อยู่ระหว่างตรวจสอบ อนุมัติแล้ว เผยแพร่ เลิกใช้งานแล้ว ไปจนถึงเก็บถาวร ผู้ตรวจสอบค้นหางานได้จากตัวกรองรอให้ฉันตรวจสอบ และการอนุมัติสามารถสร้างเวอร์ชันที่เผยแพร่แล้วได้ในขั้นตอนเดียว เอกสารจึงไม่ถูกอนุมัติไว้ที่หนึ่งแล้วแก้ไขอีกที่หนึ่ง
- แสดงความคิดเห็นตรงจุดที่ทำงาน ใช้ เพิ่มความคิดเห็น ในขั้นตอนเพื่อเริ่มการสนทนาเกี่ยวกับกิจกรรมนั้น คำถามเกี่ยวกับช่องข้อมูล การควบคุม หรือข้อยกเว้นจะอยู่ข้างคู่มือ ไม่หายไปในกล่องจดหมาย
- เก็บประวัติเวอร์ชันไว้ ประวัติเวอร์ชัน บันทึกว่าอะไรเปลี่ยนแปลง เมื่อใด และใครเป็นผู้เปลี่ยน ส่วนการเผยแพร่จะกำหนดว่าเวอร์ชันใดที่ผู้อ่านเห็น
- ดึงบทบาทจากโมเดล เมทริกซ์ RACI ในเอกสารจะดึงข้อมูลจากบทบาทที่กำหนดให้กิจกรรมในโมเดล ทำให้ความรับผิดชอบในข้อความตรงกับแผนภาพ
- บันทึกขั้นตอนบนหน้าจอไว้ตรงจุดที่ใช้งาน จับภาพหน้าจอหรือบันทึกวิดีโอหน้าจอจาก ProcessMind ครอบตัดให้เหลือเฉพาะส่วนควบคุมที่เกี่ยวข้อง ปิดบังข้อมูลส่วนบุคคลในภาพที่บันทึกไว้ แล้วเพิ่มคำแนะนำด้วย Markdown เครื่องมือแก้ไขยังช่วยตรวจหาช่องข้อมูลที่อาจมีข้อมูลอ่อนไหว และคุณแก้ไขกรอบที่ระบบทำเครื่องหมายไว้ได้ก่อนบันทึก ภาพที่บันทึกจะเก็บเป็นไฟล์แนบของกิจกรรมนั้น
- ส่งออกเป็นไฟล์ให้ผู้อ่าน ใช้ Word สำหรับรอบการตรวจสอบและระบบคุณภาพ ใช้ Markdown สำหรับควบคุมเวอร์ชัน และใช้ PDF หรือไฟล์พิมพ์สำหรับเผยแพร่และจัดเก็บ การตั้งค่าส่งออกกำหนดได้ว่าจะให้แสดงองค์ประกอบโมเดลที่ยังไม่มีเอกสาร แผนภาพกระบวนการ และ RACI ของแต่ละกิจกรรมหรือไม่ การแสดงองค์ประกอบที่ยังไม่มีเอกสารมักเป็นวิธีที่เร็วที่สุดในการหาจุดที่ขั้นตอนยังขาดหายไป.
เอกสารเป็นเพียงครึ่งหนึ่ง อีกครึ่งคือการตรวจสอบ ซึ่งควรทำในที่เดียวกัน โดยเปรียบเทียบขั้นตอนที่บันทึกไว้กับกิจกรรมที่ระบบของคุณบันทึก แล้วตัดสินใจว่าควรเปลี่ยนการฝึกอบรม เอกสาร หรือกระบวนการ การเปลี่ยนแปลงที่ได้รับอนุมัติจะถูกบันทึกกลับไปในเอกสาร พร้อมสถานะเวอร์ชันของตนเอง.
มีข้อจำกัดสองข้อที่ควรระบุให้ชัด ProcessMind จัดระเบียบระเบียนและให้หลักฐานสำหรับการทบทวน แต่ไม่ได้รับรองการปฏิบัติตามข้อกำหนด และไม่ได้แทนการลงนามอนุมัติที่ระบบบริหารคุณภาพของคุณกำหนด หรือคลังนโยบายที่ทีมกฎหมายดูแล เครื่องมือบันทึกหน้าจอที่อยู่นอกเวิร์กโฟลว์นี้ เช่น Scribe ก็บันทึกวิธีที่คนทำงานได้เช่นกัน และวิกิอาจเพียงพอสำหรับขั้นตอนไม่กี่รายการที่ทีมเดียวดูแล สิ่งที่ทั้งวิกิและคลังเอกสารแยกต่างหากบอกคุณไม่ได้ คือขั้นตอนยังตรงกับงานที่ทำอยู่หรือไม่.
ทำไมขั้นตอนที่เขียนไว้จึงไม่ตรงกับงานจริง?
ขั้นตอนคลาดเคลื่อนจากงานจริง เพราะงานเปลี่ยนไปหลังจากมีคนบันทึกไว้ นั่นไม่ได้หมายความว่าการเขียนล้มเหลวเสมอไป แต่อาจเป็นสัญญาณว่ากระบวนการพัฒนาไปแล้ว
ขั้นตอนอาศัยความทรงจำ เวิร์กช็อปช่วยบันทึกความเข้าใจของผู้คนเกี่ยวกับกระบวนการ ซึ่งอาจสะท้อนวิธีที่ออกแบบไว้ มากกว่าวิธีที่ทำจริง ข้อยกเว้นมักหลุดรอดไปได้ง่าย ทั้งที่อาจเกิดขึ้นกับงานจำนวนมาก
ทีมพัฒนาวิธีทำงานลัด มีคนพบวิธีที่เร็วกว่าในการจัดการกรณีที่พบบ่อย แล้วบอกต่อให้เพื่อนร่วมงาน หากการแก้ SOP ใช้แรงมากกว่าการทำตามวิธีลัด เอกสารก็อาจตามงานไม่ทัน
ระบบเปลี่ยนแปลง มีการเปลี่ยนชื่อช่องข้อมูล ระบบตรวจสอบอัตโนมัติ หรือปรับเกณฑ์อนุมัติ ขั้นตอนอาจยังอธิบายการตั้งค่าแบบเดิม
สังเกตการเปลี่ยนแปลงได้ยาก เอกสารที่เขียนไว้ไม่ได้แสดงว่างานเริ่มเปลี่ยนไปตั้งแต่เมื่อใด หากไม่มีหลักฐานจากกระบวนการ คุณอาจต้องขอให้ผู้คนย้อนเล่าว่าเกิดอะไรขึ้น
อะไรช่วยให้ขั้นตอนเป็นปัจจุบัน
เอกสารที่เก็บไว้ในโฟลเดอร์เพียงอย่างเดียวตอบคำถามนี้ไม่ได้ แต่การทำให้ขั้นตอนเป็นเอกสารที่ปรับปรุงต่อเนื่องช่วยได้ โดยผูกเอกสารไว้กับกระบวนการและกิจกรรมที่อธิบาย เมื่อมีการเปลี่ยนขั้นตอนและเอกสารประกอบ ก็จะทบทวนไปพร้อมกันโดยใช้บทบาทที่ระบุไว้ในโมเดล เวอร์ชันที่เผยแพร่แล้วเป็นแหล่งข้อมูลหลักเพียงแห่งเดียวที่ทีมอ่านได้ใน Process Portal และไฟล์ส่งออกทุกไฟล์มาจากข้อมูลชุดนั้น ไม่ใช่สำเนาที่มีคนแก้ไขไว้ในเครื่อง
จากนั้นมีสองสิ่งที่ช่วยให้ข้อมูลตรงกับความจริง การตรวจสอบความสอดคล้องวัดความแตกต่างระหว่างกระบวนการที่บันทึกไว้กับกิจกรรมที่ระบบของคุณบันทึก ทำให้ตรวจสอบความคลาดเคลื่อนได้ แทนที่จะได้แต่สงสัย การกำกับดูแลกระบวนการช่วยให้เห็นชัดว่าใครเป็นเจ้าของคำตอบนั้น ส่วนการกำกับดูแลและการเผยแพร่เป็นที่จัดเก็บการทบทวนและเวอร์ชัน
เอกสารขั้นตอนการทำงานจะเริ่มคลาดเคลื่อนจากการทำงานจริงเมื่อมีการเปลี่ยนแปลง และถึงตอนนั้นก็ไม่มีใครบอกได้ว่าความเปลี่ยนแปลงเริ่มขึ้นเมื่อไร จากประสบการณ์ของฉัน วิธีเดียวที่จะสังเกตเห็นได้ตั้งแต่เนิ่นๆ คือบันทึกขั้นตอนไว้ในกระบวนการ ข้างกิจกรรมที่อธิบายไว้ อ่านเอกสารควบคู่กับหลักฐาน ไม่เช่นนั้นข้อมูลอย่างใดอย่างหนึ่งก็จะล้าสมัยเสมอ
จะเขียน SOP จากข้อมูลเหตุการณ์ได้อย่างไร?
ข้อมูลเหตุการณ์แสดงขั้นตอนที่ผู้คนทำในระบบซึ่งบันทึกงานอยู่แล้ว เช่น ERP, ITSM หรือ WMS ใช้ข้อมูลนี้ควบคู่กับความรู้เกี่ยวกับกระบวนการ เพื่อร่างและทบทวนขั้นตอน นี่เป็นหนึ่งในสิ่งที่process miningช่วยได้:
-
โหลดบันทึกเหตุการณ์
ระบุรหัสเคส กิจกรรม และเวลาที่บันทึกไว้ในระบบซึ่งเก็บข้อมูลกระบวนการ จากนั้นกำหนดรูปแบบเคสและช่วงเวลาให้ชัดเจน เพื่อให้เปรียบเทียบข้อมูลได้ -
จับคู่กับกระบวนการที่บันทึกไว้
นำลำดับกิจกรรมที่บันทึกไว้มาเทียบกับขั้นตอนใน SOP บางขั้นตอนที่ระบุไว้ปรากฏในทุกเคส บางขั้นตอนพบไม่บ่อย และบางขั้นตอนไม่ปรากฏเลย ทั้งหมดนี้เป็นประเด็นที่ควรตรวจสอบ -
วิเคราะห์ความแตกต่าง
วัดว่าแต่ละเส้นทางเกิดขึ้นบ่อยแค่ไหน งานค้างอยู่ตรงไหน และมีขั้นตอนใดที่ทำซ้ำ ความแตกต่างในข้อมูลเป็นจุดเริ่มต้นให้ตรวจสอบ ไม่ได้ยืนยันว่าการทำงานผิดพลาด -
เพิ่มความแตกต่างที่สำคัญลงใน SOP
นำรูปแบบที่เกิดซ้ำมาเขียนเป็นแถวข้อยกเว้น โดยระบุบทบาท ระบบ และผลลัพธ์ที่คาดหวัง เช่นเดียวกับตัวอย่างทั้งสามข้อข้างต้น แล้วให้ผู้ปฏิบัติงานช่วยยืนยันส่วนที่ข้อมูลแสดงให้เห็นไม่ได้
คุณใช้ข้อมูลกระบวนการตรวจสอบขั้นตอนได้ แต่ข้อมูลไม่ได้อธิบายการตัดสินใจทุกอย่างหรือกำหนดว่ากระบวนการควรเป็นอย่างไร ให้ยืนยันสิ่งที่พบกับคนที่ทำงานและเจ้าของกระบวนการ พร้อมระบุเจ้าของขั้นตอนและเหตุที่ต้องทบทวน เพราะขั้นตอนที่ไม่มีเจ้าของย่อมคลาดเคลื่อนจากงานจริง.
Where to Go From Here
คุณมีขั้นตอนและวิธีตรวจสอบแล้ว เปรียบเทียบขั้นตอนที่บันทึกไว้กับกิจกรรมที่ระบบของคุณบันทึกอยู่แล้ว แล้วใช้ความแตกต่างเป็นแนวทางว่าควรทบทวนเรื่องใดกับทีมกระบวนการ.
