เทมเพลตข้อมูลสำหรับกระบวนการจัดการเคลม

เทมเพลต process mining สำหรับทุกกระบวนการ
เทมเพลตข้อมูลสำหรับกระบวนการจัดการเคลม

เทมเพลตข้อมูลสำหรับกระบวนการจัดการเคลม

เทมเพลต process mining สำหรับทุกกระบวนการ

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

เลือกระบบที่ต้องการ
  • คำแนะนำทีละขั้นตอนเกี่ยวกับคุณลักษณะข้อมูลที่จำเป็น.
  • กิจกรรมสำคัญในกระบวนการ เพื่อให้เห็นเส้นทางการดำเนินงานครบถ้วน.
  • กรอบการทำงานที่ยืดหยุ่นและปรับใช้ได้กับระบบจัดการเคลมทุกประเภท.
เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

คุณลักษณะข้อมูลสำหรับกระบวนการจัดการเคลม

ด้านล่างนี้คือรายการฟิลด์ข้อมูลที่แนะนำพร้อมคำอธิบาย ซึ่งจำเป็นต่อการสร้างบันทึกเหตุการณ์โดยละเอียดสำหรับวิเคราะห์กระบวนการจัดการเคลมประกันภัย.
5 จำเป็น 7 แนะนำ 6 ไม่บังคับ
ชื่อ คำอธิบาย
ชื่อกิจกรรม
ActivityName
ชื่อกิจกรรมทางธุรกิจหรือเหตุการณ์ที่เกิดขึ้นกับเคลม ณ เวลาหนึ่ง.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

โดยทั่วไปพบในบันทึกเหตุการณ์ บันทึกการตรวจสอบ หรือระเบียนธุรกรรมในระบบจัดการเคลม.

ตัวอย่าง
ลงทะเบียนเคสสินไหมแล้วประเมินความเสียหายแล้วจ่ายเงินแล้วปฏิเสธเคลมแล้ว
รหัสเคลม
ClaimId
รหัสเฉพาะของเคลมประกันแต่ละรายการ ซึ่งใช้เป็นรหัสหลักของกรณีในการทำ process mining.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

โดยทั่วไปจะพบในส่วนหัวหรือระเบียนหลักของแฟ้มเคลม หรือในธุรกรรมของระบบจัดการเคลม.

ตัวอย่าง
CL-2023-001234A789-C54329876543210
เวลาเริ่มต้น
StartTime
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เริ่มต้นเมื่อใด.
คำอธิบาย

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

ในการทำ process mining เวลาเริ่มต้นจำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลา เพื่อสร้างเส้นทางของแต่ละกรณีได้อย่างถูกต้อง และใช้คำนวณตัวชี้วัดสำคัญ เช่น ระยะเวลารอบงาน เวลารอ และเวลาประมวลผล การวิเคราะห์เวลาช่วยระบุความล่าช้าระหว่างขั้นตอน วัดการปฏิบัติตามข้อตกลงระดับการให้บริการ (SLA) และทำความเข้าใจจังหวะการดำเนินงานของกระบวนการเคลม.

เหตุผลที่สำคัญ

เวลานี้จำเป็นต่อการเรียงเหตุการณ์ให้ถูกต้องและคำนวณตัวชี้วัดด้านเวลา เช่น ระยะเวลารอบงานและคอขวด.

แหล่งข้อมูล

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

ตัวอย่าง
2023-03-15T09:00:00Z2023-05-20T14:35:10Z2023-07-01T11:21:05Z
ระบบต้นทาง
SourceSystem
ระบบบันทึกข้อมูลที่ดึงข้อมูลเหตุการณ์ออกมา.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ระบุแหล่งที่มาของข้อมูลเหตุการณ์ ซึ่งจำเป็นต่อการตรวจสอบข้อมูลและวิเคราะห์การดำเนินกระบวนการในระบบ IT หลายระบบ.

แหล่งข้อมูล

ข้อมูลนี้อาจอยู่ในตรรกะการดึงข้อมูล หรือจัดเก็บเป็นฟิลด์ในบันทึกเหตุการณ์ของระบบที่เชื่อมต่อกัน.

ตัวอย่าง
ชุดระบบจัดการเคลมพอร์ทัล CRMระบบจัดการเอกสาร
อัปเดตข้อมูลล่าสุด
LastDataUpdate
เวลาที่ดึงหรือรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุด.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

โดยทั่วไปเป็นข้อมูลเมตาที่สร้างขึ้นระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL).

ตัวอย่าง
2023-10-26T02:00:00Z2023-10-27T02:00:00Z2023-10-28T02:00:00Z
ประเภทเคลม
ClaimType
หมวดหมู่ของเคลมประกัน ซึ่งช่วยแบ่งกลุ่มและเปรียบเทียบประสิทธิภาพของกระบวนการสำหรับเคลมแต่ละประเภท.
คำอธิบาย

ประเภทเคลมคือการจัดกลุ่มเคลมตามสายธุรกิจหรือลักษณะความเสียหาย เช่น 'รถยนต์' 'ทรัพย์สิน' 'ความรับผิด' หรือ 'ทุพพลภาพ' เคลมแต่ละประเภทมักมีเส้นทางกระบวนการ ระดับความซับซ้อน และ SLA ที่แตกต่างกัน.

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

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

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

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

พบได้ในระเบียนธุรกรรม บันทึกการตรวจสอบ หรือฟิลด์การมอบหมายผู้ใช้ในระบบจัดการเคลม.

ตัวอย่าง
John SmithUSER789Emily Jonesadjuster_team_a
แผนก
Department
หน่วยงาน ทีม หรือแผนกที่รับผิดชอบกิจกรรมหรือเคลม ณ เวลาหนึ่ง.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ช่วยวิเคราะห์การส่งต่องานระหว่างทีมและระบุคอขวดระหว่างแผนก เพื่อใช้ประเมินประสิทธิภาพขององค์กร.

แหล่งข้อมูล

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

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

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อยู่ในระเบียนการเงินหรือการจ่ายเงินที่เชื่อมโยงกับเคลม และสรุปยอดเมื่อปิดเคลมหรือจ่ายเงิน.

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

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

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

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

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

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

เหตุผลที่สำคัญ

ช่วยวัดการดำเนินงานให้เสร็จตาม SLA หรือกำหนดเวลาตามข้อบังคับ ซึ่งเป็นตัวชี้วัดสำคัญของประสิทธิผลกระบวนการ.

แหล่งข้อมูล

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

ตัวอย่าง
2023-04-142023-06-192023-08-30
เวลาสิ้นสุด
EndTime
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

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

ตัวอย่าง
2023-03-15T11:30:00Z2023-05-20T15:05:45Z2023-07-01T11:29:15Z
จำนวนเงินที่เรียกร้อง
ClaimedAmount
ยอดเงินรวมที่ผู้ถือกรมธรรม์เรียกร้องในเบื้องต้นเมื่อยื่นเคลม.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

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

ตัวอย่าง
2000.0035000.00500.00
ช่องทางการยื่นเคลม
SubmissionChannel
วิธีหรือช่องทางที่ใช้ยื่นเคลมครั้งแรก.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

โดยทั่วไปบันทึกระหว่างขั้นตอน 'แจ้งเหตุความเสียหายครั้งแรก' (FNOL) และจัดเก็บไว้ในระเบียนหลักของเคลม.

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

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ข้อมูลสำคัญที่บันทึกเมื่อรับแจ้งเคลม และจัดเก็บไว้ในส่วนหัวของระเบียนเคลม.

ตัวอย่าง
POL-987654A-100-200-300555444333
วันที่เกิดความเสียหาย
LossDate
วันที่เกิดเหตุหรือความเสียหายซึ่งเป็นเหตุให้ยื่นเคลมประกันภัย.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

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

ตัวอย่าง
2023-03-102023-05-182023-06-25
สถานะเคลม
ClaimStatus
สถานะโดยรวมของเคลม ณ เวลาหนึ่ง เช่น เปิดอยู่ รอดำเนินการ หรือปิดแล้ว.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

เป็นฟิลด์หลักในระเบียนเคลม ซึ่งอัปเดตเมื่อเคลมดำเนินไปตามวงจรการทำงาน.

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

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ผู้ประเมินสินไหมเลือกจากรายการที่กำหนดไว้หรือกรอกเป็นข้อความ เมื่อเกิดกิจกรรม “ปฏิเสธเคลม”.

ตัวอย่าง
กรมธรรม์ไม่คุ้มครองสงสัยว่ามีการทุจริตเอกสารไม่ครบยื่นเคลมซ้ำ
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในกระบวนการจัดการเคลม

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

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

แหล่งข้อมูล

ระบบบันทึกเหตุการณ์นี้เป็นรายการธุรกรรมอย่างชัดเจน หรืออัปเดตสถานะการจ่ายเงินขั้นสุดท้าย ซึ่งมักเกิดจากการเชื่อมต่อกับระบบการเงิน.

บันทึก

ระบุเหตุการณ์ที่รายการจ่ายเงินของเคลมเปลี่ยนสถานะเป็น 'จ่ายแล้ว' 'ออกจ่ายแล้ว' หรือ 'โอนเงินแล้ว'.

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

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

แหล่งข้อมูล

มักอนุมานจากการเปลี่ยนสถานะในระบบ เช่น เปลี่ยนจาก 'New' หรือ 'Assigned' เป็น 'Under Review' หรือ 'Investigation'.

บันทึก

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

ประเภทเหตุการณ์ inferred
ตัดสินเคลมแล้ว
เหตุการณ์สำคัญที่บริษัทประกันตัดสินอย่างเป็นทางการว่าจะอนุมัติ อนุมัติบางส่วน หรือปฏิเสธเคลม โดยพิจารณาจากผลการสืบสวน นี่คือผลการพิจารณาเคลมอย่างเป็นทางการ.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

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

บันทึก

ค้นหาการอัปเดตสถานะครั้งแรกที่เปลี่ยนเป็นสถานะการตัดสินขั้นสุดท้าย เช่น 'อนุมัติ' หรือ 'ปฏิเสธ'.

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

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

แหล่งข้อมูล

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

บันทึก

ค้นหาการอัปเดตสถานะสุดท้ายเป็น 'ปฏิเสธ' 'ไม่รับอนุมัติ' หรือสถานะสิ้นสุดอื่นที่คล้ายกัน ซึ่งอาจเกิดขึ้นหลังการตัดสินเบื้องต้น.

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

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

แหล่งข้อมูล

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

บันทึก

บันทึกเวลาของธุรกรรมแรกในบันทึกเงินสำรองทางการเงินของเคลม.

ประเภทเหตุการณ์ explicit
ปิดเคลมแล้ว
นี่เป็นกิจกรรมธุรการขั้นสุดท้าย ซึ่งปิดแฟ้มเคลมหลังจากจ่ายเงินแล้วหรือปฏิเสธเคลมแล้ว เมื่อถึงขั้นตอนนี้ กิจกรรมทั้งหมดเสร็จสิ้น.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ระบบบันทึกเหตุการณ์นี้เมื่ออัปเดตสถานะสุดท้ายเป็น 'ปิดแล้ว' หรือ 'ดำเนินการเสร็จสิ้น' หลังจากประมวลผลขั้นตอนอื่นทั้งหมด.

บันทึก

ระบุเวลาที่อัปเดตช่องสถานะหลักของเคลมเป็น 'ปิดแล้ว' ซึ่งเป็นสถานะสุดท้าย.

ประเภทเหตุการณ์ inferred
ลงทะเบียนเคสสินไหมแล้ว
กิจกรรมนี้หมายถึงการสร้างระเบียนสินไหมอย่างเป็นทางการในระบบจัดการ หลังจากได้รับแจ้งเหตุความเสียหายครั้งแรก (FNOL) ณ จุดนี้ ระบบจะกำหนด Claim ID ที่ไม่ซ้ำกันและเปิดเคสเพื่อเริ่มดำเนินการอย่างเป็นทางการ.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

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

บันทึก

ค้นหาเหตุการณ์การสร้างเคสหรือการอัปเดตสถานะครั้งแรกในประวัติของสินไหม.

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

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

แหล่งข้อมูล

โดยทั่วไป ระบบบันทึกเหตุการณ์นี้จากการเปลี่ยนสถานะเฉพาะ เช่น 'Pending Information' หรือจากการบันทึกเหตุการณ์การติดต่อออกไป.

บันทึก

ค้นหาการเปลี่ยนสถานะเป็น 'pending information' หรือการสร้างงานหรือการติดต่อที่เกี่ยวข้องกับการขอข้อมูล.

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

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

แหล่งข้อมูล

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

บันทึก

ระบุเวลาที่มีการกรอกยอดชำระสินไหมขั้นสุดท้าย หรือเวลาที่สร้างรายการจ่ายเงินซึ่งมีสถานะ 'รออนุมัติ'.

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

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

แหล่งข้อมูล

โดยทั่วไป อนุมานจากการเปลี่ยนสถานะสินไหมจาก 'Pending Information' กลับไปเป็นสถานะที่กำลังดำเนินการ เช่น 'Under Review'.

บันทึก

ตรวจจับการเปลี่ยนสถานะจากสถานะ 'pending' กลับไปเป็นสถานะที่กำลังดำเนินการ.

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

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

แหล่งข้อมูล

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

บันทึก

ระบุการเปลี่ยนสถานะที่แสดงว่าการสืบสวนสิ้นสุดลงและพร้อมสำหรับการตัดสินขั้นสุดท้าย.

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

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

แหล่งข้อมูล

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

บันทึก

ตรวจจับการเปลี่ยนสถานะจากสถานะสิ้นสุด เช่น 'ปิดแล้ว' กลับไปเป็นสถานะที่ยังดำเนินการอยู่.

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

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

แหล่งข้อมูล

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

บันทึก

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

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

การติดตามเวลาเริ่มตรวจสอบช่วยแยกและวัดระยะเวลาของขั้นตอนนี้ ซึ่งมักซับซ้อนและใช้เวลานานในกระบวนการสินไหม.

แหล่งข้อมูล

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

บันทึก

ค้นหาการเปลี่ยนสถานะเป็น 'Under Investigation' หรือการสร้างงานตรวจสอบอย่างเป็นทางการรายการแรก.

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

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

แหล่งข้อมูล

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

บันทึก

บันทึกเวลาที่อนุมัติการจ่ายเงิน หรือเวลาที่สถานะเปลี่ยนเป็น 'อนุมัติให้จ่ายเงินแล้ว'.

ประเภทเหตุการณ์ explicit
แนะนำ ไม่บังคับ

คู่มือการดึงข้อมูล

เตรียมข้อมูลสำหรับ process mining อย่างไร.

วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด

อ่านคู่มือ ETL ของเรา   หรือ   เลือกกระบวนการและระบบที่ต้องการ.

พร้อมเริ่มต้นหรือยัง?

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

ควบคุมกระบวนการให้ดีขึ้นและเพิ่มประสิทธิภาพได้ตั้งแต่วันนี้

ค้นหาจุดที่ไม่มีประสิทธิภาพ ขับเคลื่อนการปรับปรุง และไปถึงเป้าหมายได้เร็วขึ้น.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงกระบวนการได้วันนี้.