เทมเพลตข้อมูลการจัดการคุณภาพของคุณ
เทมเพลตข้อมูลการจัดการคุณภาพของคุณ
นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ การจัดการคุณภาพ หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.
เลือกระบบที่ต้องการ- ฟิลด์ข้อมูลมาตรฐานสำหรับบันทึกเหตุการณ์.
- กิจกรรมสำคัญที่ควรติดตามเพื่อให้เห็นกระบวนการได้ครบถ้วน.
- คำแนะนำในการดึงข้อมูลจากระบบต่างๆ.
แอตทริบิวต์การจัดการคุณภาพ
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อของงาน เหตุการณ์ หรือขั้นตอนที่เกิดขึ้นในกระบวนการจัดการคุณภาพ. | ||
| คำอธิบาย ชื่อกิจกรรมอธิบายการดำเนินการหรือหมุดหมายที่เกิดขึ้นในวงจรของเหตุการณ์ด้านคุณภาพ เช่น 'ประเมินเบื้องต้นเสร็จแล้ว' 'เริ่มตรวจสอบแล้ว' หรือ 'ดำเนินการแก้ไขแล้ว' กิจกรรมเหล่านี้เป็นองค์ประกอบพื้นฐานของกระบวนการจัดการคุณภาพ ในการวิเคราะห์กระบวนการ คุณลักษณะนี้จำเป็นต่อการสร้างแผนผังกระบวนการ ซึ่งแสดงลำดับกิจกรรมและเส้นทางของกรณีต่างๆ ช่วยให้นักวิเคราะห์ระบุคอขวด ค้นหารูปแบบกระบวนการที่พบบ่อยและไม่ค่อยพบ และตรวจสอบการปฏิบัติตามขั้นตอนการปฏิบัติงานมาตรฐาน การทำความเข้าใจลำดับกิจกรรมเป็นจุดเริ่มต้นของการปรับปรุงกระบวนการ. เหตุผลที่สำคัญ คุณลักษณะนี้กำหนดขั้นตอนในกระบวนการ เป็นโหนดในแผนผังกระบวนการ และช่วยวิเคราะห์เส้นทางกับความแตกต่างของกระบวนการ. แหล่งข้อมูล โดยทั่วไปได้มาจากบันทึกเหตุการณ์ รายการเปลี่ยนสถานะ หรือตารางงานที่เกี่ยวข้องกับรายการเหตุการณ์ด้านคุณภาพหลัก. ตัวอย่าง เริ่มการสอบสวนวิเคราะห์สาเหตุที่แท้จริงเสร็จสิ้นยืนยันประสิทธิผลแล้ว | |||
| รหัสเหตุการณ์ด้านคุณภาพ QualityEventId | รหัสเฉพาะของเหตุการณ์ด้านคุณภาพแต่ละรายการ ใช้ระบุกรณีและเชื่อมโยงกิจกรรมที่เกี่ยวข้องทั้งหมดตั้งแต่เริ่มต้นจนปิดรายการ. | ||
| คำอธิบาย Quality Event ID คือคีย์เฉพาะที่ใช้ระบุปัญหาด้านคุณภาพแต่ละรายการ เช่น การไม่เป็นไปตามข้อกำหนด ข้อร้องเรียนจากลูกค้า ความคลาดเคลื่อน หรือข้อค้นพบจากการตรวจสอบ รหัสนี้มีความสำคัญ เพราะเชื่อมโยงขั้นตอน เอกสาร และข้อมูลทั้งหมดที่เกี่ยวข้องกับเหตุการณ์ตลอดวงจรการทำงาน ใน process mining แอตทริบิวต์นี้เป็นพื้นฐานสำหรับสร้างลำดับการทำงานตั้งแต่ต้นจนจบของ Quality Event แต่ละรายการ นักวิเคราะห์สามารถจัดกลุ่มกิจกรรมที่เกี่ยวข้องไว้ภายใต้ Quality Event ID เดียวกัน แล้วแสดงแผนผังกระบวนการ คำนวณระยะเวลาของเคส และวิเคราะห์ความแตกต่างระหว่างเส้นทางของเหตุการณ์แต่ละแบบได้ จึงช่วยให้เห็นภาพชัดเจนและวิเคราะห์ได้อย่างแม่นยำว่ามีการจัดการปัญหาด้านคุณภาพตั้งแต่เริ่มต้นจนจบอย่างไร เหตุผลที่สำคัญ นี่คือคีย์หลักสำหรับ process mining ที่ใช้เชื่อมโยงเหตุการณ์ที่เกี่ยวข้องทั้งหมดให้เป็นกระบวนการหรือกรณีเดียวกัน. แหล่งข้อมูล โดยทั่วไปจะพบในส่วนหัวหรือตารางหลักของการแจ้งเตือน เหตุการณ์ หรือรายการความไม่สอดคล้องด้านคุณภาพ. ตัวอย่าง QN-2023-00123NC-450008761COMP-5501-A | |||
| เวลาเริ่มเหตุการณ์ EventStartTime | วันที่และเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์เริ่มต้นหรือเกิดขึ้น. | ||
| คำอธิบาย เวลาเริ่มเหตุการณ์คือเวลาที่ระบุจุดเริ่มต้นของแต่ละกิจกรรมในวงจรของเหตุการณ์ด้านคุณภาพ ช่วยให้เข้าใจลำดับและประสิทธิภาพของกระบวนการตามช่วงเวลา และจำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลาและคำนวณระยะเวลา ใน process mining จะใช้เวลานี้เรียงกิจกรรมของแต่ละกรณีให้ถูกลำดับ และคำนวณตัวชี้วัดประสิทธิภาพที่สำคัญ เช่น ระยะเวลาดำเนินการ ระยะเวลารอ และเวลาที่ใช้ทำงาน การวิเคราะห์เวลาช่วยระบุความล่าช้าระหว่างขั้นตอน วัดประสิทธิภาพการใช้ทรัพยากร และติดตามการปฏิบัติตามข้อตกลงระดับการให้บริการ นี่คือข้อมูลพื้นฐานสำหรับการวิเคราะห์กระบวนการตามเวลา. เหตุผลที่สำคัญ เวลานี้จำเป็นต่อการเรียงลำดับเหตุการณ์ คำนวณระยะเวลาดำเนินการและระยะเวลารอ รวมถึงค้นหาคอขวดในกระบวนการ. แหล่งข้อมูล มักพบในบันทึกเหตุการณ์หรือระเบียนธุรกรรมควบคู่กับชื่อกิจกรรม โดยอาจใช้ชื่อว่า 'วันที่สร้าง', 'วันที่เกิดเหตุการณ์' หรือ 'การประทับเวลา' ตัวอย่าง 2023-04-15T09:00:00Z2023-07-21T14:35:10Z2024-01-05T11:20:00Z | |||
| ระบบต้นทาง SourceSystem | ระบบที่ดึงข้อมูลมา เช่น อินสแตนซ์ ERP, QMS หรือ MES ที่ใช้งานอยู่. | ||
| คำอธิบาย คุณลักษณะระบบต้นทางระบุแอปพลิเคชันหรือฐานข้อมูลที่บันทึกข้อมูลการจัดการคุณภาพ ในสภาพแวดล้อมไอทีที่มีหลายระบบ ข้อมูลเหตุการณ์ด้านคุณภาพอาจมาจากหลายแหล่ง เช่น ข้อมูลวัสดุจาก ERP และข้อมูลกระบวนการจากระบบจัดการคุณภาพโดยเฉพาะ การระบุระบบต้นทางมีความสำคัญต่อการกำกับดูแลข้อมูล การตรวจสอบความถูกต้อง และการแก้ไขปัญหา ช่วยให้เข้าใจบริบทของข้อมูลและใช้แบ่งกลุ่มการวิเคราะห์ได้ ตัวอย่างเช่น นักวิเคราะห์อาจเปรียบเทียบกระบวนการด้านคุณภาพที่จัดการในระบบหรือสถานที่ต่างกัน เพื่อค้นหาวิธีปฏิบัติที่ดีหรือความไม่สอดคล้อง. เหตุผลที่สำคัญ ช่วยให้ทราบที่มาของข้อมูล ซึ่งจำเป็นต่อการตรวจสอบความถูกต้อง การแก้ไขปัญหา และการวิเคราะห์แยกกลุ่มในสภาพแวดล้อมที่มีหลายระบบ. แหล่งข้อมูล ข้อมูลนี้อาจไม่มีอยู่ในตารางต้นทาง แต่อาจเพิ่มเข้ามาระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL). ตัวอย่าง SAP S/4HANA QMVeeva Vault QualityMasterControl QMS | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ระบุว่ามีการรีเฟรชข้อมูลของกระบวนการหรือดึงข้อมูลจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย คุณลักษณะอัปเดตข้อมูลล่าสุดบันทึกเวลาที่ซิงค์ข้อมูลจากระบบต้นทางครั้งล่าสุด ใช้บ่งชี้ความใหม่ของข้อมูลและแสดงว่าข้อมูลที่ใช้วิเคราะห์เป็นปัจจุบันเพียงใด ซึ่งสำคัญอย่างยิ่งต่อการติดตามอย่างต่อเนื่องและการตัดสินใจที่ใกล้เคียงเวลาจริง คุณลักษณะนี้ช่วยให้ผู้ใช้ทราบว่าข้อมูลในแดชบอร์ดและการวิเคราะห์ process mining เป็นปัจจุบันเพียงใด ผู้เกี่ยวข้องจึงตรวจสอบความใหม่ของข้อมูลก่อนตีความ KPI และโมเดลกระบวนการได้ ลดความเสี่ยงจากการตัดสินใจโดยใช้ข้อมูลเก่า และเป็นข้อมูลกำกับสำคัญที่ช่วยสร้างความเชื่อมั่นในข้อมูล. เหตุผลที่สำคัญ แสดงความใหม่ของข้อมูล เพื่อให้ผู้ใช้ทราบว่าการวิเคราะห์กระบวนการและ KPI เป็นข้อมูลล่าสุดเพียงใด. แหล่งข้อมูล โดยทั่วไปเป็นข้อมูลกำกับที่สร้างขึ้นระหว่างกระบวนการดึงข้อมูล (ETL) และมักไม่อยู่ในตารางธุรกรรมของระบบต้นทาง. ตัวอย่าง 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| ทรัพยากร Resource | ผู้ใช้ พนักงาน หรือระบบอัตโนมัติที่ทำหรือได้รับมอบหมายให้ทำกิจกรรมหรือจัดการเหตุการณ์ด้านคุณภาพ. | ||
| คำอธิบาย คุณลักษณะทรัพยากรระบุบุคคลหรือระบบที่รับผิดชอบงานหนึ่งๆ เช่น ผู้ตรวจสอบ ผู้อนุมัติด้านคุณภาพ หรือผู้ใช้ระบบอัตโนมัติ การติดตามว่าใครทำแต่ละกิจกรรมเป็นพื้นฐานในการทำความเข้าใจการกระจายภาระงาน ประสิทธิภาพของทีม และรูปแบบการทำงานร่วมกัน การวิเคราะห์กระบวนการแยกตามทรัพยากรช่วยให้เห็นความแตกต่างด้านประสิทธิภาพระหว่างบุคคลหรือทีม ระบุความต้องการในการฝึกอบรม และปรับสมดุลภาระงานได้ นอกจากนี้ยังช่วยให้เห็นทรัพยากรที่มีภาระงานมากเกินไปจนกลายเป็นคอขวด หรือรูปแบบการส่งต่องานระหว่างบุคคลซึ่งมักทำให้กระบวนการล่าช้า การวิเคราะห์นี้มีส่วนสำคัญต่อการเพิ่มประสิทธิภาพขององค์กร. เหตุผลที่สำคัญ คุณลักษณะนี้สำคัญต่อการวิเคราะห์ตามทรัพยากร ทั้งการกระจายภาระงาน การเปรียบเทียบประสิทธิภาพ และการระบุคอขวดในองค์กร. แหล่งข้อมูล มักพบในตารางธุรกรรมหรือบันทึก โดยอาจใช้ชื่อฟิลด์ว่า 'User Name', 'Changed By', 'Owner' หรือ 'Assigned To'. ตัวอย่าง j.doem.smithSystem.Batch | |||
| ประเภทเหตุการณ์ด้านคุณภาพ QualityEventType | การจัดประเภทเหตุการณ์ด้านคุณภาพ เช่น ความไม่สอดคล้อง ข้อร้องเรียนจากลูกค้า ข้อค้นพบจากการตรวจประเมิน หรือความเบี่ยงเบน. | ||
| คำอธิบาย ประเภทเหตุการณ์ด้านคุณภาพใช้จัดหมวดหมู่ลักษณะของปัญหาด้านคุณภาพที่กำลังจัดการ เหตุการณ์แต่ละประเภทมักมีขั้นตอน ระดับความเร่งด่วน และขั้นตอนการปฏิบัติงานมาตรฐานที่แตกต่างกัน การกรองและเปรียบเทียบกระบวนการตามคุณลักษณะนี้ช่วยให้นักวิเคราะห์เห็นความแตกต่างที่สำคัญ ตัวอย่างเช่น กระบวนการจัดการ 'ข้อร้องเรียนจากลูกค้า' อาจเข้มงวดและต้องดำเนินการเร็วกว่า 'ปัญหาภายใน' มาก การทำความเข้าใจความแตกต่างเหล่านี้จำเป็นต่อการประเมินว่ากระบวนการแต่ละรูปแบบมีประสิทธิภาพและเป็นไปตามข้อกำหนดเฉพาะหรือไม่. เหตุผลที่สำคัญ ช่วยแบ่งกลุ่มการวิเคราะห์เพื่อเปรียบเทียบวิธีจัดการปัญหาด้านคุณภาพแต่ละประเภท และเผยให้เห็นความแตกต่างที่สำคัญของกระบวนการ. แหล่งข้อมูล พบข้อมูลนี้ในส่วนหัวของเหตุการณ์ด้านคุณภาพ โดยมักอยู่ในฟิลด์ 'ประเภทการแจ้งเตือน', 'ประเภทเหตุการณ์' หรือ 'หมวดหมู่' ตัวอย่าง ข้อร้องเรียนจากลูกค้ารายงานความไม่สอดคล้อง (NCR)ความเบี่ยงเบน | |||
| ระดับความรุนแรง Severity | การจัดระดับผลกระทบที่อาจเกิดจากเหตุการณ์ด้านคุณภาพ เช่น วิกฤต ร้ายแรง หรือเล็กน้อย. | ||
| คำอธิบาย คุณลักษณะระดับความรุนแรงใช้จัดประเภทเหตุการณ์ด้านคุณภาพตามผลกระทบต่อธุรกิจ ความเสี่ยง หรือความเร่งด่วน การจัดประเภทนี้ช่วยจัดลำดับความสำคัญในการใช้ทรัพยากรและให้ความสนใจกับปัญหาที่สำคัญที่สุด โดยทั่วไประดับความรุนแรงกำหนดไว้ในนโยบายด้านคุณภาพขององค์กร คุณลักษณะนี้ใช้กรองและแบ่งกลุ่มข้อมูลใน process mining ได้ นักวิเคราะห์สามารถเปรียบเทียบเส้นทางกระบวนการของเหตุการณ์ 'Critical' กับ 'Minor' เพื่อให้แน่ใจว่าจัดการปัญหาที่มีความรุนแรงสูงได้รวดเร็วตามที่กำหนด นอกจากนี้ยังช่วยให้เห็นว่าปัญหา 'Minor' ใช้ทรัพยากรมากเกินสัดส่วนหรือไม่ หรือปัญหา 'Critical' ติดค้างอยู่ในกระบวนการหรือไม่ ข้อมูลนี้ช่วยปรับกระบวนการให้เหมาะกับการจัดการตามความเสี่ยง. เหตุผลที่สำคัญ ช่วยวิเคราะห์กระบวนการตามความเสี่ยง จัดลำดับความสำคัญของการตรวจสอบ และยืนยันว่าเหตุการณ์ที่มีผลกระทบสูงได้รับการจัดการอย่างเร่งด่วนเหมาะสม. แหล่งข้อมูล เป็นฟิลด์มาตรฐานในข้อมูลส่วนหัวของเหตุการณ์ด้านคุณภาพ โดยมักใช้ชื่อว่า 'Severity Level' หรือ 'Priority'. ตัวอย่าง วิกฤตร้ายแรงเล็กน้อย | |||
| เวลาสิ้นสุดเหตุการณ์ EventEndTime | วันที่และเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์เสร็จสิ้น. | ||
| คำอธิบาย เวลาสิ้นสุดเหตุการณ์คือเวลาที่ระบุว่ากิจกรรมเสร็จสิ้น เมื่อนำมาใช้คู่กับเวลาเริ่มเหตุการณ์ จะคำนวณเวลาที่ใช้ทำงานแต่ละรายการในกระบวนการจัดการคุณภาพได้อย่างแม่นยำ สำหรับเหตุการณ์ที่เกิดขึ้นทันที เวลาเริ่มต้นและเวลาสิ้นสุดอาจตรงกัน คุณลักษณะนี้สำคัญต่อการวิเคราะห์ประสิทธิภาพในระดับกิจกรรม เมื่อนำเวลาสิ้นสุดมาลบเวลาเริ่มต้นเพื่อคำนวณระยะเวลาของแต่ละงาน นักวิเคราะห์จะเห็นว่าขั้นตอนใดใช้เวลามากที่สุดและควรปรับปรุง นอกจากนี้ยังช่วยคำนวณระยะเวลาดำเนินการโดยรวมของแต่ละกรณีได้แม่นยำขึ้น และใช้วิเคราะห์ภาระงานกับประสิทธิภาพของทรัพยากรได้. เหตุผลที่สำคัญ ช่วยคำนวณเวลาที่ใช้ทำกิจกรรม ซึ่งจำเป็นต่อการวิเคราะห์ประสิทธิภาพอย่างละเอียดและระบุงานที่ใช้ทรัพยากรมาก. แหล่งข้อมูล มักพบในบันทึกเหตุการณ์หรือรายการธุรกรรมเดียวกับเวลาเริ่มต้น ในบางระบบอาจต้องอนุมานจากเวลาเริ่มต้นของเหตุการณ์ถัดไป. ตัวอย่าง 2023-04-15T17:30:00Z2023-07-22T10:05:45Z2024-01-05T11:25:00Z | |||
| หน่วยงานที่รับผิดชอบ ResponsibleDepartment | หน่วยงาน ทีม หรือสายงานที่รับผิดชอบเหตุการณ์ด้านคุณภาพหรือกิจกรรมใดกิจกรรมหนึ่ง. | ||
| คำอธิบาย คุณลักษณะหน่วยงานที่รับผิดชอบระบุหน่วยงานในองค์กรที่รับผิดชอบเหตุการณ์ด้านคุณภาพหรือขั้นตอนใดขั้นตอนหนึ่งในกระบวนการ เช่น 'การผลิต' 'การประกันคุณภาพ' 'การวิจัยและพัฒนา' หรือ 'โลจิสติกส์' คุณลักษณะนี้จำเป็นต่อการวิเคราะห์ในระดับองค์กร ช่วยให้ผู้จัดการเห็นว่างานส่งต่อระหว่างหน่วยงานต่างๆ อย่างไร วัดประสิทธิภาพของแต่ละสายงาน และระบุปัญหาหรือความล่าช้าระหว่างหน่วยงานได้ ตัวอย่างเช่น การวิเคราะห์อาจพบว่าการส่งต่องานระหว่างฝ่ายผลิตกับฝ่ายประกันคุณภาพเป็นสาเหตุหลักของความล่าช้า การแยก KPI ตามหน่วยงานช่วยระบุจุดที่ควรปรับปรุงกระบวนการได้ตรงเป้าหมาย. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพกระบวนการแยกตามหน่วยงาน ระบุความล่าช้าระหว่างสายงาน และช่วยกำหนดผู้รับผิดชอบ. แหล่งข้อมูล โดยทั่วไปอยู่ในข้อมูลส่วนหัวของรายการเหตุการณ์ด้านคุณภาพ หรืออนุมานจากผู้ใช้ที่รับผิดชอบกิจกรรม. ตัวอย่าง การควบคุมคุณภาพสายการผลิต Bคุณภาพซัพพลายเออร์ | |||
| หมวดหมู่สาเหตุราก RootCauseCategory | การจัดประเภทสาเหตุรากของเหตุการณ์ด้านคุณภาพในภาพรวม. | ||
| คำอธิบาย หมวดหมู่สาเหตุรากใช้จัดประเภทสาเหตุหลักของปัญหาด้านคุณภาพ เช่น “ความผิดพลาดของบุคลากร” “อุปกรณ์ขัดข้อง” “ข้อบกพร่องของกระบวนการ” หรือ “ปัญหาจากซัพพลายเออร์” โดยทั่วไปจะระบุข้อมูลนี้หลังจากตรวจสอบและวิเคราะห์สาเหตุรากเสร็จแล้ว การวิเคราะห์ความถี่ของสาเหตุแต่ละหมวดช่วยให้เห็นแนวทางปรับปรุงในภาพรวม หากพบ “ข้อบกพร่องของกระบวนการ” บ่อย อาจเป็นสัญญาณว่าควรออกแบบกระบวนการใหม่ หากพบ “อุปกรณ์ขัดข้อง” บ่อย อาจต้องทบทวนแผนบำรุงรักษา process mining ช่วยเชื่อมโยงหมวดหมู่เหล่านี้กับรูปแบบการทำงานของกระบวนการได้ เช่น แสดงให้เห็นว่าเหตุการณ์ที่เกิดจาก “ความผิดพลาดของบุคลากร” ใช้เวลาแก้ไขนานกว่าหรือไม่. เหตุผลที่สำคัญ ข้อมูลนี้สำคัญต่อการวิเคราะห์เชิงกลยุทธ์ เพราะช่วยให้เห็นสาเหตุเบื้องหลังความล้มเหลว ไม่ใช่แค่ลำดับการทำงาน และช่วยกำหนดมาตรการป้องกันได้ตรงจุด. แหล่งข้อมูล ดูได้จากส่วนการตรวจสอบหรือการวิเคราะห์สาเหตุรากในระเบียนเหตุการณ์ด้านคุณภาพ ข้อมูลอาจเป็นรหัสหรือข้อความอิสระ. ตัวอย่าง อุปกรณ์ขัดข้องความผิดพลาดของบุคลากรข้อบกพร่องของวัสดุ | |||
| ผลการตรวจสอบประสิทธิผล EffectivenessCheckOutcome | ผลการตรวจสอบเพื่อยืนยันว่ามาตรการแก้ไขและป้องกันที่นำไปใช้ได้ผลหรือไม่. | ||
| คำอธิบาย ผลการตรวจสอบประสิทธิผลบันทึกผลจากขั้นตอนตรวจสอบหลังจากนำมาตรการแก้ไขไปใช้ โดยทั่วไปผลจะระบุว่า “ได้ผล” หรือ “ไม่ได้ผล” เพื่อแสดงว่ามาตรการนั้นแก้สาเหตุรากของปัญหาได้สำเร็จหรือไม่ ข้อมูลนี้สำคัญต่อการวัดผลสำเร็จที่แท้จริงของกระบวนการจัดการคุณภาพ หากพบผล “ไม่ได้ผล” ในสัดส่วนสูง อาจมีปัญหาเชิงระบบในขั้นตอนวิเคราะห์สาเหตุรากหรือวางแผนมาตรการ ส่งผลให้ต้องทำงานซ้ำและเกิดปัญหาเดิมอีก process mining ใช้วิเคราะห์วงจรการทำงานซ้ำได้ เช่น กรณีที่ผล “ไม่ได้ผล” มักย้อนกลับไปยังขั้นตอนตรวจสอบหรือวิเคราะห์สาเหตุราก ทำให้ระยะเวลาดำเนินการและต้นทุนเพิ่มขึ้นอย่างมาก. เหตุผลที่สำคัญ วัดผลสำเร็จของมาตรการแก้ไขโดยตรง และจำเป็นต่อการวิเคราะห์วงจรการทำงานซ้ำ รวมถึงประสิทธิผลของกระบวนการวิเคราะห์สาเหตุราก. แหล่งข้อมูล ดูได้จากระเบียนที่เกี่ยวข้องกับการตรวจสอบหรือปิดขั้นตอนมาตรการแก้ไขและป้องกัน (CAPA). ตัวอย่าง ได้ผลไม่ได้ผลรอการตรวจสอบ | |||
| ผลิตภัณฑ์ที่ได้รับผลกระทบ AffectedProduct | ผลิตภัณฑ์ วัสดุ หรือชิ้นส่วนที่เกี่ยวข้องกับเหตุการณ์ด้านคุณภาพ. | ||
| คำอธิบาย คุณลักษณะผลิตภัณฑ์ที่ได้รับผลกระทบระบุรายการ วัสดุ หรือสายผลิตภัณฑ์ที่ได้รับผลกระทบจากปัญหาด้านคุณภาพ การเชื่อมโยงข้อมูลกระบวนการกับผลิตภัณฑ์มีความสำคัญต่อการวิเคราะห์สาเหตุรากและประเมินผลกระทบ การวิเคราะห์เหตุการณ์ด้านคุณภาพแยกตามผลิตภัณฑ์ช่วยให้ธุรกิจเห็นแนวโน้ม เช่น ผลิตภัณฑ์บางรายการมีความไม่สอดคล้องสูงผิดปกติ ซึ่งอาจนำไปสู่การตรวจสอบการออกแบบหรือกระบวนการผลิตของผลิตภัณฑ์นั้นเพิ่มเติม นอกจากนี้ยังช่วยจัดลำดับความสำคัญของเหตุการณ์ตามความสำคัญเชิงกลยุทธ์หรือยอดขายของผลิตภัณฑ์ที่ได้รับผลกระทบ เพื่อให้จัดการปัญหาสำคัญก่อน. เหตุผลที่สำคัญ เชื่อมโยงข้อมูลกระบวนการกับข้อมูลผลิตภัณฑ์ ช่วยวิเคราะห์ปัญหาด้านคุณภาพแยกตามสายผลิตภัณฑ์ เพื่อหาแนวโน้มและจัดลำดับความสำคัญของปัญหาที่มีผลกระทบสูง. แหล่งข้อมูล พบในรายการหลักของเหตุการณ์ด้านคุณภาพ โดยมักใช้ชื่อฟิลด์ว่า 'Material Number', 'Product ID' หรือ 'Part Number'. ตัวอย่าง PROD-100-XLMAT-RAW-05BFG-2055-ASSY | |||
| วันที่เป้าหมายในการแก้ไข TargetResolutionDate | วันที่กำหนดหรือวันที่ต้องดำเนินการให้เหตุการณ์ด้านคุณภาพได้รับการแก้ไขและปิดเรื่องเรียบร้อย. | ||
| คำอธิบาย วันที่เป้าหมายในการแก้ไขคือกำหนดเวลาที่ต้องปิดเหตุการณ์ด้านคุณภาพ โดยมักกำหนดตามข้อบังคับ ข้อตกลงระดับการให้บริการกับลูกค้า หรือนโยบายภายในที่พิจารณาจากความรุนแรงของเหตุการณ์ ข้อมูลนี้จำเป็นต่อการติดตามผลการดำเนินงานและวิเคราะห์การปฏิบัติตามข้อกำหนด เมื่อนำวันที่ปิดเรื่องจริงมาเทียบกับวันที่เป้าหมาย องค์กรจะคำนวณ KPI “อัตราการแก้ไขตรงเวลา” ได้ process mining ช่วยระบุประเภทเหตุการณ์หรือขั้นตอนที่มักทำให้เกิดความล่าช้าและพลาดกำหนดเวลา ทำให้มุ่งปรับปรุงเพื่อให้บรรลุเป้าหมายด้านเวลาได้ตรงจุด. เหตุผลที่สำคัญ ใช้วัดผลการดำเนินงานเทียบกับเป้าหมายด้านเวลา ช่วยคำนวณอัตราการแก้ไขตรงเวลาและระบุสาเหตุของความล่าช้า. แหล่งข้อมูล โดยทั่วไปอยู่ในส่วนหัวหรือข้อมูลการวางแผนของระเบียนเหตุการณ์ด้านคุณภาพ. ตัวอย่าง 2024-06-302024-07-152024-08-01 | |||
| สถานที่ Location | สถานที่ตั้งทางกายภาพหรือเชิงตรรกะ เช่น โรงงาน ไซต์งาน หรือคลังสินค้า ซึ่งเป็นจุดที่เกิดเหตุการณ์ด้านคุณภาพหรือมีการจัดการเหตุการณ์นั้น. | ||
| คำอธิบาย แอตทริบิวต์สถานที่ระบุพื้นที่ทางภูมิศาสตร์หรือหน่วยงานที่เกี่ยวข้องกับเหตุการณ์ด้านคุณภาพ เช่น โรงงานผลิต สายการผลิต ศูนย์กระจายสินค้า หรือหน่วยธุรกิจ การวิเคราะห์ผลการดำเนินงานของกระบวนการแยกตามสถานที่ช่วยเปรียบเทียบผลและค้นหาแนวปฏิบัติที่ดีได้ คุณอาจพบว่าบางไซต์งานแก้ปัญหาด้านคุณภาพได้มีประสิทธิภาพกว่า หรือบางพื้นที่เป็นแหล่งของปัญหาที่เกิดซ้ำ การวิเคราะห์ตามภูมิศาสตร์หรือไซต์งานช่วยให้ฝ่ายบริหารจัดสรรทรัพยากรได้เหมาะสม และกำหนดกระบวนการที่มีผลการดำเนินงานดีให้เป็นมาตรฐานทั่วทั้งองค์กร. เหตุผลที่สำคัญ ช่วยเปรียบเทียบผลการดำเนินงานระหว่างไซต์งานหรือโรงงาน เพื่อใช้เป็นเกณฑ์เทียบและค้นหาปัญหาหรือแนวปฏิบัติที่ดีเฉพาะพื้นที่. แหล่งข้อมูล ข้อมูลนี้มักอยู่ในระเบียนเหตุการณ์ด้านคุณภาพหลัก โดยอาจใช้ชื่อ “โรงงาน” “ไซต์งาน” หรือ “หน่วยธุรกิจ”. ตัวอย่าง สถานประกอบการ A อาคาร 2คลังสินค้าหลักโรงงาน 0010 | |||
| สถานะเหตุการณ์ด้านคุณภาพ QualityEventStatus | สถานะปัจจุบันของเหตุการณ์ด้านคุณภาพในวงจรการดำเนินงาน เช่น เปิดอยู่ อยู่ระหว่างตรวจสอบ หรือปิดแล้ว. | ||
| คำอธิบาย สถานะเหตุการณ์ด้านคุณภาพแสดงสถานะปัจจุบันของกรณี เหตุการณ์ด้านคุณภาพเป็นคุณลักษณะที่เปลี่ยนแปลงไปตามความคืบหน้าของกรณี และช่วยให้เห็นภาพรวมว่าเหตุการณ์อยู่ในขั้นตอนใด ณ เวลานั้น ใน process mining คุณลักษณะนี้มีประโยชน์ต่อการวิเคราะห์ภาระงานปัจจุบันและงานค้าง ผู้จัดการสามารถกรองเหตุการณ์ที่มีสถานะ 'Open' หรือ 'In Progress' เพื่อติดตามจำนวนกรณีที่กำลังดำเนินการได้ นอกจากนี้ยังช่วยตรวจสอบความสอดคล้อง โดยเปรียบเทียบการเปลี่ยนสถานะจริงกับเส้นทางกระบวนการที่คาดไว้ ตัวอย่างเช่น ไม่ควรปิดเหตุการณ์ก่อนดำเนินการแก้ไข. เหตุผลที่สำคัญ แสดงสถานะปัจจุบันของกรณี ซึ่งจำเป็นต่อการติดตามงานค้าง ภาระงานที่กำลังดำเนินการ และตรวจสอบความสอดคล้องของกระบวนการ. แหล่งข้อมูล เป็นฟิลด์สำคัญในรายการส่วนหัวของเหตุการณ์ด้านคุณภาพ และจะอัปเดตตามความคืบหน้าของเหตุการณ์. ตัวอย่าง เปิดอยู่รออนุมัติปิดแล้ว | |||
กิจกรรมในการจัดการคุณภาพ
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| ดำเนินการแก้ไขแล้ว | ระบุว่าดำเนินงานตามแผนปฏิบัติการแก้ไขที่อนุมัติแล้วเสร็จ ขั้นตอนนี้ยืนยันว่าได้ดำเนินการที่จำเป็นเพื่อแก้ปัญหาเฉพาะหน้าแล้ว. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้เป็นจุดสิ้นสุดของการลงมือแก้ไข เวลาตั้งแต่อนุมัติแผนจนถึงการนำไปใช้สะท้อนประสิทธิภาพของทีมในการทำงานที่กำหนดให้เสร็จ. แหล่งข้อมูล โดยทั่วไปจะบันทึกขั้นตอนนี้เมื่อผู้รับผิดชอบทำเครื่องหมายว่ารายการดำเนินการหรืองานที่ได้รับมอบหมายเสร็จแล้วในระบบ. บันทึก ใช้เวลาที่งานแก้ไขที่เกี่ยวข้องเสร็จสิ้น หรือเวลาที่อัปเดตสถานะในรายการแผนปฏิบัติการเป็น 'Implemented'. ประเภทเหตุการณ์ explicit | |||
| ปิดเหตุการณ์ด้านคุณภาพแล้ว | ขั้นตอนสุดท้ายที่ระบุว่าแก้ไขเหตุการณ์ด้านคุณภาพและปิดรายการในระบบเรียบร้อยแล้ว เมื่อถึงจุดนี้ถือว่ากระบวนการเสร็จสมบูรณ์ และเก็บรายการไว้เป็นประวัติ. | ||
| เหตุผลที่สำคัญ นี่คือจุดสิ้นสุดหลักของกระบวนการ ระยะเวลาจนถึงการปิดรายการเป็น KPI สำคัญ และการวิเคราะห์เหตุการณ์ที่ปิดแล้วช่วยให้เห็นกระบวนการตั้งแต่ต้นจนจบ. แหล่งข้อมูล นี่คือเหตุการณ์สำคัญที่บันทึกไว้อย่างชัดเจนเมื่อเปลี่ยนสถานะสุดท้ายของรายการเป็น 'Closed' หรือ 'Completed' พร้อมระบุเวลา. บันทึก ใช้เวลาที่เปลี่ยนสถานะสุดท้ายเป็น 'Closed', 'Completed' หรือสถานะสิ้นสุดที่มีความหมายเทียบเท่ากัน. ประเภทเหตุการณ์ explicit | |||
| ยืนยันประสิทธิผลแล้ว | ยืนยันว่าการดำเนินการแก้ไขและป้องกันช่วยแก้สาเหตุรากและป้องกันไม่ให้เกิดซ้ำได้ ขั้นตอนนี้เป็นการตรวจสอบอย่างเป็นทางการ ซึ่งมักทำหลังจากเฝ้าติดตามผลตามระยะเวลาที่กำหนด. | ||
| เหตุผลที่สำคัญ นี่คือเกณฑ์สำคัญที่ใช้วัดว่าการดำเนินการด้านคุณภาพได้ผลหรือไม่ โดยยืนยันว่าทรัพยากรที่ใช้ในการตรวจสอบและดำเนินการให้ผลลัพธ์ที่ดี และช่วยป้องกันการทำงานซ้ำในอนาคต. แหล่งข้อมูล บันทึกขั้นตอนนี้เมื่องานตรวจสอบประสิทธิผลเสร็จสิ้น หรือเมื่ออัปเดตสถานะของรายการเป็น 'Effectiveness Verified' ซึ่งมักมีลายเซ็นอิเล็กทรอนิกส์ประกอบ. บันทึก ใช้เวลาที่งานตรวจสอบประสิทธิผลเสร็จสิ้น หรือเวลาที่อนุมัติการตรวจสอบขั้นสุดท้าย. ประเภทเหตุการณ์ explicit | |||
| เริ่มการสอบสวน | ระบุจุดเริ่มต้นอย่างเป็นทางการของขั้นตอนการสอบสวน เพื่อกำหนดขอบเขตและสาเหตุที่แท้จริงของเหตุการณ์ด้านคุณภาพ โดยมีการมอบหมายกรณีให้ผู้สอบสวนหรือทีมอย่างเป็นทางการ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นของขั้นตอนหลักในการแก้ปัญหา การติดตามเวลาตั้งแต่สร้างเหตุการณ์จนถึงเริ่มสอบสวนช่วยให้เห็นงานค้างสะสมที่อาจเกิดขึ้นในทีมคุณภาพ. แหล่งข้อมูล โดยทั่วไปจะบันทึกเหตุการณ์นี้เมื่อเปลี่ยนสถานะของระเบียนเป็น 'Under Investigation' หรือเมื่อมอบหมายผู้สอบสวนให้กับระเบียนอย่างเป็นทางการ. บันทึก ใช้เวลาที่สถานะเปลี่ยนเป็น 'Under Investigation' หรือเวลาที่มอบหมายเจ้าของงานหรือผู้สอบสวนเป็นครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| วิเคราะห์สาเหตุที่แท้จริงเสร็จสิ้น | หมายถึงการสอบสวนเสร็จสิ้นและระบุพร้อมบันทึกสาเหตุที่แท้จริงของเหตุการณ์ด้านคุณภาพแล้ว นี่เป็นหมุดหมายสำคัญก่อนวางแผนการดำเนินการแก้ไข. | ||
| เหตุผลที่สำคัญ หมุดหมายนี้เป็นจุดสิ้นสุดของขั้นตอนการวิเคราะห์ การตรวจสอบระยะเวลาที่ใช้วิเคราะห์สาเหตุที่แท้จริงช่วยระบุความซับซ้อนและคอขวดในกิจกรรมการแก้ปัญหา. แหล่งข้อมูล อนุมานเหตุการณ์นี้ได้เมื่อกรอกและบันทึกฟิลด์ 'Root Cause' หรือฟิลด์การวิเคราะห์ที่เกี่ยวข้อง ในบางระบบ เหตุการณ์นี้ตรงกับการทำงาน RCA ที่กำหนดไว้เสร็จสิ้น. บันทึก บันทึกเวลาที่งานวิเคราะห์สาเหตุที่แท้จริงโดยเฉพาะถูกระบุว่าเสร็จสิ้น หรือเวลาที่กรอกคำอธิบายสาเหตุที่แท้จริงเป็นครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| สร้างเหตุการณ์ด้านคุณภาพ | กิจกรรมแรกนี้คือการสร้างระเบียนเหตุการณ์ด้านคุณภาพอย่างเป็นทางการ ผู้ใช้ระบุและบันทึกปัญหาด้านคุณภาพ เช่น การไม่เป็นไปตามข้อกำหนด ข้อบกพร่อง หรือข้อร้องเรียน ลงในระบบเพื่อเริ่มกระบวนการ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นหลักของกระบวนการ และใช้วัดเวลาทั้งหมดตั้งแต่ระบุปัญหาจนถึงแก้ไขเสร็จ นอกจากนี้ยังจำเป็นต่อการติดตามจำนวนเหตุการณ์ด้านคุณภาพที่เข้ามา. แหล่งข้อมูล โดยทั่วไป เหตุการณ์นี้จะถูกบันทึกไว้อย่างชัดเจนในบันทึกการตรวจสอบหรือบันทึกรายการธุรกรรมเมื่อมีการสร้างระเบียนใหม่ ให้ค้นหาเวลาที่สร้างในตารางเหตุการณ์ด้านคุณภาพหลัก. บันทึก ใช้เวลาที่สร้างระเบียนเหตุการณ์ด้านคุณภาพ เช่น Quality Notification, Non-conformance หรือ Complaint. ประเภทเหตุการณ์ explicit | |||
| อนุมัติแผนปฏิบัติการแก้ไข | ระบุว่าผู้มีอำนาจที่ได้รับมอบหมายอนุมัติแผนปฏิบัติการแก้ไขที่เสนออย่างเป็นทางการแล้ว การอนุมัตินี้เป็นจุดสำคัญที่ทำให้เริ่มนำแผนไปใช้ได้. | ||
| เหตุผลที่สำคัญ การรออนุมัติมักทำให้กระบวนการล่าช้า การวิเคราะห์ระยะเวลาและความถี่ของขั้นตอนนี้ช่วยระบุคอขวดในเวิร์กโฟลว์การตรวจสอบและอนุมัติ. แหล่งข้อมูล โดยทั่วไปจะบันทึกการอนุมัติไว้อย่างชัดเจนพร้อมเวลาในเวิร์กโฟลว์ เช่น ลายเซ็นอิเล็กทรอนิกส์หรือการเปลี่ยนสถานะที่กำหนด. บันทึก ใช้เวลาจากรายการลายเซ็นอิเล็กทรอนิกส์ หรือเวลาที่เปลี่ยนสถานะเป็น 'Approved' หรือ 'Released for Implementation'. ประเภทเหตุการณ์ explicit | |||
| แจ้งผู้เกี่ยวข้องแล้ว | ระบุว่ามีการแจ้งผลการแก้ไขเหตุการณ์ด้านคุณภาพอย่างเป็นทางการแก่ผู้เกี่ยวข้อง เช่น ผู้รายงานเหตุการณ์หรือหน่วยงานที่ได้รับผลกระทบ. | ||
| เหตุผลที่สำคัญ แม้การแจ้งผู้เกี่ยวข้องจะไม่ใช่ขั้นตอนหลักของกระบวนการเสมอไป แต่การติดตามการสื่อสารช่วยให้เห็นว่ากระบวนการครบถ้วนเพียงใดและให้บริการได้ตามระดับที่คาดหวังหรือไม่. แหล่งข้อมูล ขั้นตอนนี้ติดตามได้ยาก และอาจบันทึกเป็นรายการดำเนินการไว้อย่างชัดเจน หรืออนุมานจากการทำงาน 'Final Notification' ในเวิร์กโฟลว์ที่เสร็จสิ้น. บันทึก ใช้เวลาที่บันทึกการส่งอีเมลแจ้งเตือนอัตโนมัติ หรือเวลาที่ทำเครื่องหมายว่างานสื่อสารด้วยตนเองเสร็จแล้ว. ประเภทเหตุการณ์ inferred | |||
| ดำเนินการป้องกันแล้ว | ระบุว่าดำเนินงานเพื่อกำจัดสาเหตุของความไม่สอดคล้องที่อาจเกิดขึ้นเสร็จแล้ว เพื่อป้องกันไม่ให้เกิดซ้ำ ขั้นตอนเชิงป้องกันนี้มักเกิดขึ้นหลังการแก้ไขปัญหา. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้แสดงให้เห็นว่ากระบวนการด้านคุณภาพให้ความสำคัญกับการป้องกัน ไม่ใช่แค่การแก้ไข การติดตามการดำเนินการป้องกันช่วยวัดผลการปรับปรุงกระบวนการในระยะยาว. แหล่งข้อมูล บันทึกขั้นตอนนี้เมื่อทำเครื่องหมายว่างานป้องกันที่ได้รับมอบหมายเสร็จแล้ว ซึ่งมักอยู่ในรายการที่เชื่อมโยงกับเหตุการณ์ด้านคุณภาพต้นทาง. บันทึก ใช้เวลาที่งานป้องกันที่เกี่ยวข้องเสร็จสิ้น หรือเวลาที่อัปเดตสถานะในรายการการดำเนินการป้องกัน. ประเภทเหตุการณ์ explicit | |||
| ตรวจสอบขั้นสุดท้ายเสร็จแล้ว | ตรวจสอบรายการเหตุการณ์ด้านคุณภาพทั้งหมดเป็นครั้งสุดท้าย เพื่อให้แน่ใจว่าเอกสารครบถ้วนและดำเนินการตามขั้นตอนที่กำหนดแล้ว โดยทั่วไปนี่คือขั้นตอนอนุมัติสุดท้ายก่อนปิดรายการ. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้เป็นจุดตรวจสอบคุณภาพสุดท้ายก่อนปิดกรณี ความล่าช้าในขั้นตอนนี้อาจทำให้ระยะเวลาดำเนินการยาวขึ้น และอาจบ่งชี้ว่ามีปัญหาเกี่ยวกับเอกสาร. แหล่งข้อมูล โดยทั่วไปจะเป็นขั้นตอนอนุมัติอย่างชัดเจนหรือลายเซ็นอิเล็กทรอนิกส์จากผู้รับผิดชอบด้านการประกันคุณภาพ ก่อนเปลี่ยนสถานะเป็น 'Closed'. บันทึก ใช้เวลาจากการอนุมัติผลตรวจสอบคุณภาพขั้นสุดท้าย หรือเวลาที่เปลี่ยนสถานะเป็น 'Pending Closure' หรือ 'Final Review Complete'. ประเภทเหตุการณ์ explicit | |||
| ตรวจสอบประสิทธิผลไม่ผ่าน | ระบุว่าพบว่าการดำเนินการที่นำไปใช้ไม่ได้ผลในการแก้ปัญหา ผลลัพธ์นี้มักทำให้ต้องเริ่มการตรวจสอบใหม่หรือเริ่มวงจรการดำเนินการแก้ไขรอบใหม่. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้บ่งชี้ถึงความล้มเหลวครั้งสำคัญของกระบวนการและการทำงานซ้ำหลายขั้น การวิเคราะห์เหตุการณ์เหล่านี้ช่วยให้เข้าใจว่าเหตุใดแนวทางแก้ไขจึงไม่ได้ผล และปรับปรุงกระบวนการ RCA. แหล่งข้อมูล บันทึกขั้นตอนนี้เมื่อการตรวจสอบไม่ผ่านและมีการเปลี่ยนสถานะเพื่อเปิดการตรวจสอบหรือการวางแผน CAPA อีกครั้ง. บันทึก ใช้เวลาที่เปลี่ยนสถานะเพื่อระบุว่าการตรวจสอบไม่ผ่าน เช่น 'Effectiveness Failed' หรือ 'Re-Investigation Required'. ประเภทเหตุการณ์ explicit | |||
| ปฏิเสธแผนปฏิบัติการแก้ไข | ระบุว่ามีการตรวจสอบแผนปฏิบัติการแก้ไขที่เสนอแล้ว แต่ไม่อนุมัติ จึงต้องแก้ไขแผนและส่งใหม่ ทำให้เกิดวงจรการทำงานซ้ำในกระบวนการ. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้ชี้ให้เห็นความไม่มีประสิทธิภาพและการทำงานซ้ำในกระบวนการ อัตราการปฏิเสธที่สูงอาจบ่งบอกว่าข้อกำหนดไม่ชัดเจนหรือวิเคราะห์สาเหตุรากไม่เพียงพอ. แหล่งข้อมูล บันทึกขั้นตอนนี้เมื่อเปลี่ยนสถานะเป็น 'Rejected' หรือ 'Revision Required' ซึ่งมักมีรหัสเหตุผลหรือความคิดเห็นประกอบ. บันทึก ใช้เวลาที่เปลี่ยนสถานะเป็น 'Rejected' หรือ 'Sent Back for Revision'. ประเภทเหตุการณ์ explicit | |||
| ประเมินเบื้องต้นเสร็จสิ้น | หมายถึงการตรวจสอบหรือคัดแยกเหตุการณ์ด้านคุณภาพที่สร้างขึ้นใหม่ในเบื้องต้นเสร็จสิ้น ในขั้นตอนนี้จะจัดประเภทเหตุการณ์ กำหนดระดับความรุนแรง และจัดลำดับความสำคัญเพื่อกำหนดเวิร์กโฟลว์ถัดไป. | ||
| เหตุผลที่สำคัญ การวิเคราะห์เวลาที่ใช้ในช่วงแรกนี้ช่วยระบุความล่าช้าในการรับทราบและดำเนินการกับเหตุการณ์ด้านคุณภาพใหม่ อีกทั้งยังให้คุณลักษณะที่ใช้กรองกรณีตามระดับความรุนแรงหรือประเภทได้. แหล่งข้อมูล มักอนุมานเหตุการณ์นี้จากการเปลี่ยนสถานะจาก 'New' เป็น 'Under Assessment' หรือ 'In Progress' นอกจากนี้ยังบันทึกได้เมื่อมีการกรอกข้อมูลการจัดประเภทและลำดับความสำคัญเป็นครั้งแรก. บันทึก บันทึกเวลาที่สถานะเปลี่ยนเพื่อแสดงว่าการประเมินเสร็จสิ้น หรือเวลาที่บันทึกข้อมูลการจัดประเภทและลำดับความสำคัญเป็นครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| ยกเลิกเหตุการณ์ด้านคุณภาพ | เป็นจุดสิ้นสุดอีกแบบหนึ่ง โดยยุติเหตุการณ์ด้านคุณภาพก่อนแก้ไขเสร็จ อาจเกิดขึ้นเมื่อพบว่าเหตุการณ์ไม่ถูกต้อง เป็นรายการซ้ำ หรือสร้างขึ้นโดยผิดพลาด. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้เป็นการสิ้นสุดกระบวนการอีกแบบหนึ่งที่ไม่ก่อให้เกิดผลลัพธ์ การยกเลิกเหตุการณ์จำนวนมากอาจบ่งชี้ว่าผู้ใช้ยังต้องได้รับการฝึกอบรม หรือมีปัญหาในขั้นตอนบันทึกข้อมูลเริ่มต้น. แหล่งข้อมูล บันทึกขั้นตอนนี้เมื่อเปลี่ยนสถานะสิ้นสุดเป็น 'Canceled' หรือ 'Void' ซึ่งมักมีรหัสเหตุผลประกอบ. บันทึก ใช้เวลาที่อัปเดตสถานะรายการเป็น 'Canceled', 'Void' หรือ 'Invalid'. ประเภทเหตุการณ์ explicit | |||
| เสนอแผนการดำเนินการแก้ไข | กิจกรรมนี้เกิดขึ้นเมื่อมีการจัดทำแผนอย่างเป็นทางการเพื่อจัดการสาเหตุที่แท้จริงที่พบ และส่งแผนให้ตรวจสอบ โดยระบุการดำเนินการแก้ไขที่จะทำไว้อย่างชัดเจน. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้เริ่มช่วงแก้ไขปัญหาในกระบวนการ การติดตามเวลาที่ใช้ในการเสนอแผนช่วยให้เห็นว่าทีมเปลี่ยนจากการวิเคราะห์ไปสู่การลงมือทำได้เร็วเพียงใด. แหล่งข้อมูล โดยทั่วไปจะบันทึกขั้นตอนนี้เมื่อสร้างรายการแผนปฏิบัติการแก้ไขที่เกี่ยวข้อง หรือเมื่อเปลี่ยนสถานะเพื่อระบุว่าแผนพร้อมให้ตรวจสอบแล้ว. บันทึก ใช้เวลาที่สร้างรายการ Corrective Action หรือ CAPA ที่เชื่อมโยงกัน หรือเวลาที่เปลี่ยนสถานะเป็น 'Pending Approval'. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด
พร้อมเริ่มต้นหรือยัง?
หากต้องการเริ่มปรับปรุงกระบวนการจัดการคุณภาพ ให้เลือกคู่มือดึงข้อมูลสำหรับระบบของคุณด้านล่าง หรือใช้เทมเพลตทั่วไปนี้เพื่อเริ่มเตรียมข้อมูล.
เริ่มปรับปรุงการจัดการคุณภาพวันนี้
ระบุคอขวดและยกระดับการปฏิบัติตามข้อกำหนดด้วยข้อมูลเชิงลึก.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายใน 5 นาที.