Mẫu dữ liệu xử lý yêu cầu bồi thường

Guidewire ClaimCenter
Mẫu dữ liệu xử lý yêu cầu bồi thường

Mẫu dữ liệu xử lý yêu cầu bồi thường

Mẫu này giúp bạn chuẩn bị dữ liệu để cải thiện quy trình xử lý yêu cầu bồi thường. Mẫu nêu rõ các thuộc tính dữ liệu cần thu thập, những hoạt động cần theo dõi và cách trích xuất dữ liệu. Hãy dùng mẫu để đảm bảo bạn có đủ thông tin cần thiết cho việc phân tích quy trình.
  • Các thuộc tính nên thu thập
  • Các hoạt động chính cần theo dõi
  • Hướng dẫn trích xuất dữ liệu từ Guidewire ClaimCenter
Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Thuộc tính xử lý yêu cầu bồi thường

Các trường dữ liệu được đề xuất này giúp bạn tạo event log đầy đủ để phân tích hiệu quả quy trình xử lý yêu cầu bồi thường.
3 Bắt buộc 4 Nên có 14 Không bắt buộc
Tên Mô tả
Claim ID
ClaimID
Mã định danh duy nhất của mỗi yêu cầu bảo hiểm, được dùng làm mã hồ sơ chính.
Mô tả

Claim ID là nền tảng để phân tích quy trình xử lý yêu cầu bồi thường, giúp nhận diện duy nhất từng hồ sơ từ lúc gửi đến khi đóng. Mã này liên kết mọi hoạt động, tài liệu, khoản thanh toán và trao đổi liên quan, đảm bảo bạn có cái nhìn đầy đủ, nhất quán về vòng đời của một yêu cầu.

Trong process mining, mọi sự kiện trong tập dữ liệu đều gắn với một Claim ID, nhờ đó có thể tái dựng luồng quy trình từ đầu đến cuối. Đây là điều cần thiết để phân tích thời gian xử lý, xác định các biến thể quy trình và theo dõi hành trình của yêu cầu qua nhiều phòng ban và chuyên viên giám định.

Vì sao điều này quan trọng

Đây là khóa cơ bản liên kết mọi sự kiện liên quan, giúp bạn theo dõi và phân tích toàn bộ hành trình của một yêu cầu bồi thường.

Lấy dữ liệu ở đâu

Đây là khóa chính trong Guidewire ClaimCenter, thường nằm ở trường Claim.ClaimNumber hoặc một trường tương tự trong thực thể Claim cốt lõi.

Ví dụ
000-123-45678000-987-65432001-456-11223
Tên hoạt động
ActivityName
Tên của hoạt động nghiệp vụ hoặc sự kiện xảy ra tại một thời điểm cụ thể trong vòng đời xử lý yêu cầu bồi thường.
Mô tả

Thuộc tính này mô tả một bước hoặc cột mốc cụ thể trong quy trình xử lý yêu cầu bồi thường, chẳng hạn như 'Tạo yêu cầu bồi thường', 'Bắt đầu điều tra' hoặc 'Phát hành thanh toán'. Chuỗi hoạt động của một Claim ID tạo thành luồng quy trình.

Phân tích thứ tự, tần suất và thời gian giữa các hoạt động là trọng tâm của process mining. Việc này giúp khám phá mô hình quy trình, xác định điểm nghẽn, phát hiện các vòng lặp làm lại và phân tích những sai lệch trong quy trình.

Vì sao điều này quan trọng

Thuộc tính này xác định các bước của quy trình, giúp trực quan hóa sơ đồ quy trình và phân tích luồng quy trình cũng như các điểm nghẽn.

Lấy dữ liệu ở đâu

Thông tin này thường được lấy từ các bảng sự kiện hoặc nhật ký kiểm tra trong ClaimCenter, bằng cách ánh xạ các sự kiện hệ thống hoặc thay đổi trạng thái cụ thể sang tên hoạt động chuẩn hóa.

Ví dụ
Tạo yêu cầu bồi thườngĐưa ra quyết định về trách nhiệmPhát hành thanh toánĐóng yêu cầu bồi thường
Thời gian sự kiện
EventTime
Ngày và giờ chính xác khi hoạt động diễn ra.
Mô tả

Dấu thời gian này ghi lại chính xác thời điểm hoạt động được lưu vào hệ thống. Đây là dữ liệu nền tảng cho mọi phân tích quy trình theo thời gian.

Sắp xếp EventTime theo thứ tự thời gian cho từng Claim ID giúp tái dựng luồng quy trình. Chênh lệch thời gian giữa các sự kiện liên tiếp được dùng để tính thời gian chu kỳ, thời gian chờ và thời gian xử lý. Đây là những chỉ số quan trọng để phân tích hiệu suất, xác định điểm nghẽn và theo dõi SLA.

Vì sao điều này quan trọng

Dấu thời gian này cần thiết để sắp xếp sự kiện, tính thời gian chu kỳ và thời lượng, đồng thời xác định các chậm trễ trong quy trình.

Lấy dữ liệu ở đâu

Thông tin này thường có trong các bảng lịch sử hoặc kiểm tra của Guidewire ClaimCenter, cùng dữ liệu sự kiện hoặc hoạt động, dưới dạng trường 'CreateTime' hoặc 'UpdateTime'.

Ví dụ
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
Chuyên viên xử lý được phân công
AssignedAdjuster
Tên hoặc ID của người dùng được giao xử lý yêu cầu bồi thường hoặc một hoạt động cụ thể.
Mô tả

Thuộc tính này xác định chuyên viên xử lý yêu cầu bồi thường chịu trách nhiệm tại một thời điểm nhất định. Một chuyên viên có thể được giao phụ trách toàn bộ yêu cầu hoặc một số tác vụ cụ thể.

Phân tích theo chuyên viên được phân công rất quan trọng để cân bằng khối lượng công việc, quản lý hiệu suất và xác định nhu cầu đào tạo. Phân tích này giúp trả lời các câu hỏi như: 'Chuyên viên nào đang xử lý nhiều hồ sơ nhất?', 'Hiệu suất giữa các chuyên viên có khác nhau không?' và 'Công việc có được phân chia đồng đều không?'.

Vì sao điều này quan trọng

Theo dõi mức độ tham gia của người dùng, giúp phân tích khối lượng công việc, so sánh hiệu suất và xác định điểm nghẽn liên quan đến nguồn lực.

Lấy dữ liệu ở đâu

Có trong thực thể Claim hoặc Exposure của ClaimCenter, thường liên kết với đối tượng User, chẳng hạn như Claim.Assignee.

Ví dụ
j.doem.smiths.jones
Loại yêu cầu bồi thường
ClaimType
Nhóm yêu cầu bồi thường bảo hiểm, chẳng hạn như ô tô, tài sản hoặc trách nhiệm dân sự.
Mô tả

Loại yêu cầu bồi thường là cách phân nhóm cơ bản dựa trên lĩnh vực kinh doanh hoặc tính chất tổn thất. Mỗi loại thường có quy trình riêng, mức độ phức tạp khác nhau và chịu sự điều chỉnh của các quy định khác nhau.

Phân tích quy trình theo loại yêu cầu bồi thường là cần thiết để có được thông tin hữu ích. Cách phân nhóm này giúp so sánh hiệu suất giữa các lĩnh vực kinh doanh, xác định điểm nghẽn riêng của từng loại và điều chỉnh hoạt động cải tiến quy trình theo đặc điểm của từng nhóm yêu cầu.

Vì sao điều này quan trọng

Giúp phân nhóm yêu cầu bồi thường, vì mỗi loại, chẳng hạn như ô tô và tài sản, thường có quy trình và mục tiêu hiệu suất khác nhau.

Lấy dữ liệu ở đâu

Được lấy từ thực thể Policy hoặc Claim trong ClaimCenter, thường dựa trên mã Line of Business (LOB).

Ví dụ
Ô tô cá nhânTài sản thương mạiTrách nhiệm dân sự chungBồi thường tai nạn lao động
Nguyên nhân tổn thất
LossCause
Lý do hoặc nguyên nhân cụ thể gây ra tổn thất, chẳng hạn như va chạm, hỏa hoạn hoặc hư hại do nước.
Mô tả

Thuộc tính này cung cấp thông tin chi tiết về lý do nộp yêu cầu bồi thường. Nguyên nhân tổn thất thường quyết định các bước điều tra cần thực hiện, loại chuyên gia cần tham gia và mức độ phức tạp của toàn bộ hồ sơ.

Phân tích quy trình theo nguyên nhân tổn thất có thể làm lộ ra những xu hướng khó nhận thấy. Chẳng hạn, yêu cầu liên quan đến 'Hư hại do nước' có thể cần làm lại nhiều hơn hoặc cần nhiều chuyên gia hơn so với yêu cầu liên quan đến 'Trộm cắp'. Những thông tin này giúp xây dựng quy trình xử lý chuyên biệt và hiệu quả hơn.

Vì sao điều này quan trọng

Cung cấp bối cảnh về tính chất của yêu cầu bồi thường, giúp phân tích nguyên nhân tổn thất khác nhau ảnh hưởng thế nào đến luồng và thời lượng quy trình.

Lấy dữ liệu ở đâu

Đây là trường tiêu chuẩn trong thực thể Claim, thường có tên 'LossCause'.

Ví dụ
Va chạmHỏa hoạnHư hại do nướcTrộm cắp
Trạng thái yêu cầu bồi thường
ClaimStatus
Trạng thái tổng thể của yêu cầu bồi thường tại thời điểm sự kiện diễn ra, chẳng hạn như đang mở, đã đóng hoặc bị từ chối.
Mô tả

Thuộc tính này thể hiện trạng thái tổng quát của yêu cầu bồi thường. Các trạng thái chính gồm 'Đang mở', 'Đã đóng', 'Bị từ chối' và 'Mở lại'. Trạng thái cuối cùng là chỉ số quan trọng về kết quả xử lý.

Theo dõi thay đổi trạng thái giúp xác định các cột mốc và kết quả chính của quy trình. Thông tin này được dùng để xác định kết quả xử lý cuối cùng, tính tỷ lệ từ chối và phân tích tần suất yêu cầu được mở lại sau khi đóng. Tình trạng mở lại thường cho thấy vấn đề trong quy trình hoặc khách hàng chưa hài lòng.

Vì sao điều này quan trọng

Cho biết kết quả xử lý yêu cầu bồi thường, cần thiết để phân tích tỷ lệ từ chối, cách đóng hồ sơ và tần suất mở lại.

Lấy dữ liệu ở đâu

Đây là trường cốt lõi trong thực thể Claim, thường có tên 'State' hoặc 'Status'.

Ví dụ
Đang mởĐã đóngBị từ chốiĐã mở lại
Có làm lại
IsRework
Cờ cho biết hoạt động có thuộc vòng lặp làm lại hay không, tức là quay lại một giai đoạn trước đó của quy trình.
Mô tả

Thuộc tính được tính toán này đánh dấu các hoạt động thuộc vòng lặp làm lại. Ví dụ, nếu quy trình chuyển từ 'Hoàn tất điều tra' trở lại 'Bắt đầu điều tra', lần 'Bắt đầu điều tra' thứ hai sẽ được đánh dấu là làm lại.

Xác định việc làm lại là bước quan trọng để phát hiện điểm kém hiệu quả và vấn đề chất lượng trong quy trình. Dashboard Tần suất làm lại và từ chối dùng chỉ số này để đo mức độ yêu cầu bồi thường đi chệch khỏi luồng xử lý lý tưởng. Phân tích nguyên nhân làm lại có thể giúp cải thiện đáng kể chất lượng và tốc độ xử lý.

Vì sao điều này quan trọng

Làm rõ điểm kém hiệu quả và vấn đề chất lượng bằng cách đánh dấu cụ thể các hoạt động thuộc vòng lặp làm lại.

Lấy dữ liệu ở đâu

Công cụ process mining tính giá trị này bằng cách phân tích chuỗi hoạt động của từng hồ sơ.

Ví dụ
truefalse
Có tự động hóa
IsAutomated
Cờ cho biết hoạt động do hệ thống tự động thực hiện hay do người dùng thực hiện.
Mô tả

Thuộc tính dạng boolean này phân biệt hoạt động do hệ thống thực hiện, chẳng hạn như tự động tạo khoản dự phòng hoặc gửi thư tự động, với hoạt động do chuyên viên xử lý thực hiện thủ công.

Phân tích thuộc tính này giúp hiểu mức độ tự động hóa trong quy trình xử lý yêu cầu bồi thường. Việc này giúp xác định những khâu cần can thiệp thủ công, đo hiệu quả của các sáng kiến xử lý tự động từ đầu đến cuối và tìm thêm cơ hội tự động hóa bằng cách phát hiện các tác vụ lặp lại, dựa trên quy tắc mà hiện con người đang thực hiện.

Vì sao điều này quan trọng

Phân biệt hoạt động do hệ thống thực hiện với hoạt động do con người thực hiện, giúp phân tích tự động hóa và xác định điểm nghẽn do thao tác thủ công.

Lấy dữ liệu ở đâu

Thông tin này thường cần được suy ra. Ví dụ, có thể đánh dấu là tự động các sự kiện được ghi bởi người dùng hệ thống chung.

Ví dụ
truefalse
Hệ thống nguồn
SourceSystem
Hệ thống nơi dữ liệu được trích xuất.
Mô tả

Thuộc tính này xác định nguồn gốc của dữ liệu sự kiện. Trong môi trường doanh nghiệp hiện đại, sự kiện liên quan đến yêu cầu bồi thường có thể đến từ nhiều hệ thống, chẳng hạn như hệ thống lõi Guidewire, hệ thống quản lý tài liệu hoặc cổng thông tin khách hàng.

Việc ghi rõ hệ thống nguồn rất quan trọng để quản trị dữ liệu, xử lý sự cố dữ liệu không nhất quán và hiểu rõ các hệ thống công nghệ tham gia vào quy trình. Nhờ đó, bạn có thể phân biệt các bước chính của quy trình với hoạt động hỗ trợ từ những hệ thống liên quan.

Vì sao điều này quan trọng

Cho biết nguồn gốc dữ liệu, yếu tố quan trọng để quản trị dữ liệu và phân tích quy trình có nhiều hệ thống tích hợp.

Lấy dữ liệu ở đâu

Đây thường là giá trị tĩnh được thêm trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL).

Ví dụ
Guidewire ClaimCenter v10API cổng thông tin khách hàngDocumentum
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
Dấu thời gian cho biết lần gần nhất dữ liệu được làm mới hoặc trích xuất từ hệ thống nguồn.
Mô tả

Thuộc tính này ghi lại thời điểm gần nhất dữ liệu được lấy từ hệ thống nguồn. Đây là trường siêu dữ liệu cần thiết để biết dữ liệu phân tích còn mới hay không.

Dashboard và báo cáo phân tích nên hiển thị rõ thông tin này để người dùng biết dữ liệu được cập nhật đến thời điểm nào. Nhờ đó, họ có thể đánh giá liệu kết quả phân tích phản ánh tình hình vận hành hiện tại hay dựa trên dữ liệu cũ.

Vì sao điều này quan trọng

Cho biết dữ liệu mới đến đâu, giúp người dùng hiểu phân tích quy trình phản ánh tình hình hiện tại như thế nào.

Lấy dữ liệu ở đâu

Giá trị này được tạo và lưu trong quá trình ETL, thể hiện thời điểm tải dữ liệu.

Ví dụ
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
Loại hợp đồng bảo hiểm
PolicyType
Loại hợp đồng bảo hiểm cụ thể được dùng để nộp yêu cầu bồi thường.
Mô tả

Loại hợp đồng bảo hiểm phân loại chi tiết hơn loại yêu cầu bồi thường, cho biết sản phẩm bảo hiểm cụ thể như 'Bảo hiểm nhà ở', 'Bảo hiểm trách nhiệm ô tô thương mại' hoặc 'Bảo hiểm trách nhiệm an ninh mạng'. Mức độ chi tiết này có thể cho thấy sự khác biệt trong quy trình giữa các sản phẩm.

Phân tích quy trình theo loại hợp đồng bảo hiểm giúp phát hiện điểm kém hiệu quả riêng của từng sản phẩm. Ví dụ, yêu cầu bồi thường theo một hợp đồng mới ra mắt có thể đi theo quy trình chưa hoàn thiện, dẫn đến chậm trễ. Kết quả phân tích này có thể hỗ trợ thiết kế sản phẩm và chuẩn hóa quy trình.

Vì sao điều này quan trọng

Cho phép phân tích quy trình theo từng sản phẩm bảo hiểm cụ thể, giúp xác định khác biệt trong cách xử lý tùy theo điều khoản hợp đồng.

Lấy dữ liệu ở đâu

Thông tin này nằm trong thực thể Policy, được liên kết với Claim.

Ví dụ
Bảo hiểm nhiều rủi ro cho chủ nhàBảo hiểm trách nhiệm ô tô thương mạiBảo hiểm hàng hải nội địa
Ngày mục tiêu giải quyết
ResolutionTargetDate
Ngày dự kiến giải quyết xong yêu cầu bồi thường theo SLA nội bộ hoặc quy định.
Mô tả

Ngày mục tiêu giải quyết là hạn chót đóng yêu cầu bồi thường, thường được xác định dựa trên các yếu tố như khu vực pháp lý, loại yêu cầu và điều khoản hợp đồng. Đây là mốc để đo hiệu suất và mức độ tuân thủ.

Thuộc tính này rất quan trọng khi xây dựng dashboard và KPI theo dõi việc đáp ứng SLA. Bằng cách so sánh ngày thực tế 'Đóng yêu cầu bồi thường' với ngày mục tiêu, phân tích có thể tự động đánh dấu hồ sơ trễ hạn, đo tỷ lệ xử lý đúng hạn và xác định loại yêu cầu hoặc phòng ban nào chưa đạt mục tiêu.

Vì sao điều này quan trọng

Đây là mốc để đo mức độ đáp ứng Thỏa thuận mức dịch vụ (SLA) và xác định các yêu cầu có nguy cơ trễ hạn.

Lấy dữ liệu ở đâu

Đây có thể là trường tùy chỉnh hoặc giá trị được suy ra từ các quy tắc nghiệp vụ cấu hình trong ClaimCenter, có thể liên quan đến một số chỉ số cụ thể của yêu cầu.

Ví dụ
2023-06-142023-07-202023-08-28
Ngày xảy ra tổn thất
LossDate
Ngày xảy ra sự cố hoặc tổn thất dẫn đến yêu cầu bồi thường.
Mô tả

Ngày xảy ra tổn thất là ngày sự việc thực tế diễn ra, chẳng hạn như tai nạn ô tô hoặc hư hại tài sản, dẫn đến yêu cầu bồi thường. Ngày này khác với ngày báo cáo hoặc tạo yêu cầu.

Khoảng thời gian từ ngày xảy ra tổn thất đến hoạt động 'Tạo yêu cầu bồi thường', còn gọi là độ trễ báo cáo, là một KPI quan trọng. Phân tích khoảng thời gian này giúp hiểu hành vi khách hàng và hiệu quả của các kênh tiếp nhận thông báo tổn thất ban đầu.

Vì sao điều này quan trọng

Cung cấp bối cảnh quan trọng về nguồn gốc yêu cầu bồi thường và giúp phân tích độ trễ báo cáo, tức thời gian từ khi xảy ra sự cố đến khi gửi yêu cầu.

Lấy dữ liệu ở đâu

Đây là trường ngày cơ bản trong thực thể Claim, thường có tên 'LossDate'.

Ví dụ
2023-05-102023-04-202023-05-28
Phòng ban
Department
Đơn vị hoặc phòng ban chịu trách nhiệm xử lý hoạt động liên quan đến yêu cầu bồi thường.
Mô tả

Thuộc tính này cho biết phòng ban hoặc nhóm của chuyên viên được phân công, chẳng hạn như 'Bồi thường ô tô', 'Bồi thường tài sản' hoặc 'Đơn vị điều tra đặc biệt'. Thông tin này đặt quy trình trong bối cảnh tổ chức.

Phân tích theo phòng ban rất quan trọng để hiểu hiệu suất quy trình ở cấp tổ chức. Việc này giúp xác định chậm trễ khi bàn giao giữa các phòng ban, so sánh hiệu quả giữa các nhóm và phân bổ nguồn lực hợp lý hơn trong bộ phận xử lý bồi thường.

Vì sao điều này quan trọng

Cung cấp bối cảnh tổ chức để phân tích hiệu suất giữa các nhóm và phát hiện vấn đề khi bàn giao giữa các phòng ban.

Lấy dữ liệu ở đâu

Thông tin này thường gắn với hồ sơ người dùng hoặc nhóm được phân công trong ClaimCenter.

Ví dụ
Bộ phận bồi thường ô tôĐơn vị bồi thường tài sảnĐơn vị điều tra đặc biệt (SIU)
Số tiền thanh toán
PaymentAmount
Số tiền thực tế được thanh toán cho một hoạt động thanh toán.
Mô tả

Thuộc tính này ghi lại giá trị của từng khoản thanh toán cho một yêu cầu bồi thường. Một yêu cầu có thể phát sinh nhiều khoản thanh toán trong suốt vòng đời xử lý.

Đây là dữ liệu thiết yếu cho phân tích tài chính trong process mining. Bạn có thể dùng dữ liệu này để theo dõi tổng số tiền chi trả cho mỗi yêu cầu, phân tích thời gian phê duyệt theo số tiền và liên hệ điểm kém hiệu quả trong quy trình với kết quả tài chính. Ví dụ, hồ sơ có thời gian xử lý dài có thể đi kèm tổng số tiền thanh toán cao hơn.

Vì sao điều này quan trọng

Theo dõi các giao dịch tài chính trong một yêu cầu bồi thường, giúp phân tích giá trị thanh toán và mối liên hệ với các hoạt động trong quy trình.

Lấy dữ liệu ở đâu

Thông tin này có trong các thực thể liên quan đến Payment được liên kết với yêu cầu bồi thường, thường nằm trong bảng giao dịch hoặc séc.

Ví dụ
4500.00125000.00500.00
Số tiền yêu cầu bồi thường
ClaimedAmount
Tổng số tiền ban đầu mà bên mua bảo hiểm yêu cầu bồi thường.
Mô tả

Thuộc tính này thể hiện giá trị tổn thất do người yêu cầu bồi thường khai báo. Đây thường là ước tính ban đầu và có thể thay đổi trong quá trình điều tra, xác định khoản dự phòng.

Phân tích số tiền yêu cầu bồi thường giúp phân nhóm hồ sơ theo mức độ ảnh hưởng tài chính. Hồ sơ có giá trị lớn thường cần quy trình chặt chẽ và phức tạp hơn hồ sơ giá trị thấp. So sánh quy trình giữa các nhóm giá trị có thể giúp tìm cách đơn giản hóa việc xử lý hồ sơ nhỏ hoặc áp dụng kiểm soát nghiêm ngặt hơn với hồ sơ lớn.

Vì sao điều này quan trọng

Giúp phân nhóm yêu cầu bồi thường theo giá trị tài chính, vì hồ sơ giá trị cao có thể cần quy trình khác và phức tạp hơn.

Lấy dữ liệu ở đâu

Thông tin này có thể không nằm trong một trường duy nhất mà được suy ra từ ước tính tổn thất ban đầu ghi nhận trong các Exposure.

Ví dụ
5000.00150000.00750.50
Thời gian kết thúc
EndTime
Dấu thời gian cho biết khi nào một hoạt động hoàn tất.
Mô tả

Thời gian kết thúc ghi nhận lúc một hoạt động hoàn tất, đặc biệt với các tác vụ có thời lượng đo được như 'Điều tra' hoặc 'Rà soát tài liệu'. Nhiều hoạt động trong process mining diễn ra tức thời nên chỉ cần StartTime. Với hoạt động có thời điểm bắt đầu và kết thúc riêng biệt, nên ghi nhận cả hai dấu thời gian.

Thuộc tính này giúp tính chính xác thời gian xử lý hoạt động, tách biệt với thời gian chờ. Nhờ đó, bạn có thể xác định tác vụ nào thực sự mất nhiều thời gian, thay vì chỉ thấy khoảng trễ dài giữa các bước.

Vì sao điều này quan trọng

Thuộc tính này giúp đo chính xác thời gian hoàn tất một hoạt động, đồng thời phân biệt thời gian xử lý với thời gian chờ.

Lấy dữ liệu ở đâu

Có thể cần suy ra thời điểm này từ một sự kiện tiếp theo đánh dấu hợp lý việc hoàn tất hoạt động, chẳng hạn như trạng thái chuyển từ 'Đang xử lý' sang 'Đã hoàn tất'.

Ví dụ
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
Tiểu bang thuộc thẩm quyền pháp lý
JurisdictionState
Tiểu bang hoặc khu vực pháp lý điều chỉnh yêu cầu bồi thường và quy định các yêu cầu pháp lý liên quan.
Mô tả

Thuộc tính này xác định khu vực pháp lý, chẳng hạn như tiểu bang tại Hoa Kỳ, nơi yêu cầu bồi thường được xử lý. Quy định bảo hiểm có thể khác nhau đáng kể giữa các khu vực, ảnh hưởng đến các bước cần thực hiện, thời hạn liên lạc và hồ sơ cần lưu.

Đây là thuộc tính quan trọng để theo dõi tuân thủ. Phân tích quy trình theo khu vực pháp lý giúp đảm bảo đáp ứng các yêu cầu pháp lý riêng của từng tiểu bang. Thông tin này cũng có thể giải thích sự khác biệt về thời gian chu kỳ hoặc luồng quy trình do ràng buộc pháp lý, chứ không phải do vận hành kém hiệu quả.

Vì sao điều này quan trọng

Rất quan trọng khi phân tích tuân thủ, vì mỗi khu vực pháp lý có quy định riêng ảnh hưởng đến quy trình xử lý yêu cầu bồi thường.

Lấy dữ liệu ở đâu

Đây là trường tiêu chuẩn trong thực thể Claim, thường có tên 'JurisdictionState'.

Ví dụ
CANYTXFL
Trạng thái SLA
SLAState
Cho biết yêu cầu bồi thường có được đóng trước ngày mục tiêu giải quyết hay không.
Mô tả

Thuộc tính được tính toán này phân loại mức độ đáp ứng SLA của từng yêu cầu đã đóng. Giá trị được xác định bằng cách so sánh dấu thời gian của hoạt động 'Đóng yêu cầu bồi thường' với 'Ngày mục tiêu giải quyết'.

Thuộc tính này hỗ trợ trực tiếp dashboard 'Mức độ đáp ứng mục tiêu giải quyết yêu cầu bồi thường' bằng cách phân loại kết quả rõ ràng như 'Đúng hạn' hoặc 'Trễ hạn'. Bạn có thể dễ dàng lọc và tổng hợp dữ liệu để tính tỷ lệ đáp ứng SLA chung, đồng thời đi sâu xuống một cấp để tìm nguyên nhân chậm trễ.

Vì sao điều này quan trọng

Phân loại rõ kết quả đáp ứng SLA, giúp dễ dàng lọc, tổng hợp và phân tích hiệu suất xử lý đúng hạn.

Lấy dữ liệu ở đâu

Trường được tính toán: IF (ActualCloseDate <= ResolutionTargetDate, 'Đúng hạn', 'Trễ hạn').

Ví dụ
Đúng hạnTrễ hạn
Yêu cầu thông tin nhiều lần
RepeatedInfoRequestFlag
Cờ cho biết hoạt động 'Yêu cầu bổ sung thông tin' có xảy ra nhiều hơn một lần với cùng một yêu cầu bồi thường hay không.
Mô tả

Cờ boolean này được đặt thành true nếu một yêu cầu bồi thường có nhiều hơn một hoạt động 'Yêu cầu bổ sung thông tin'. Tình trạng này thường cho thấy khâu thu thập thông tin ban đầu chưa hiệu quả.

Thuộc tính này hỗ trợ trực tiếp KPI 'Tỷ lệ yêu cầu thông tin nhiều lần'. Chỉ số này giúp đo lường vấn đề xác minh thông tin ban đầu chưa đầy đủ, vốn có thể gây chậm trễ đáng kể và khiến khách hàng không hài lòng. Phân tích các hồ sơ được đánh dấu có thể giúp cải thiện danh sách kiểm tra và quy trình làm việc của chuyên viên, để họ yêu cầu đầy đủ thông tin cần thiết ngay từ đầu.

Vì sao điều này quan trọng

Giúp xác định tình trạng thu thập thông tin chưa đầy đủ ngay lần đầu, gây chậm trễ và phải làm lại.

Lấy dữ liệu ở đâu

Công cụ process mining tính giá trị này bằng cách đếm số lần hoạt động 'Yêu cầu bổ sung thông tin' xuất hiện trong mỗi hồ sơ.

Ví dụ
truefalse
Bắt buộc Nên có Không bắt buộc

Hoạt động xử lý yêu cầu bồi thường

Đây là những bước chính và mốc quan trọng cần ghi lại trong event log để khám phá và phân tích chính xác quy trình xử lý yêu cầu bồi thường.
7 Nên có 7 Không bắt buộc
Hoạt động Mô tả
Đóng yêu cầu bồi thường
Đánh dấu việc đóng yêu cầu bồi thường thành công sau khi hoàn tất mọi hoạt động và khoản thanh toán. Đây là sự kiện kết thúc thành công chính, được suy ra từ thay đổi trạng thái chính của yêu cầu.
Vì sao điều này quan trọng

Là sự kiện kết thúc chính, hoạt động này rất cần thiết để tính thời gian xử lý từ đầu đến cuối và đo mức độ đáp ứng SLA. Nó đánh dấu việc hoàn tất vòng đời yêu cầu bồi thường.

Lấy dữ liệu ở đâu

Suy ra từ việc trường State trong bảng cc_claim chuyển sang 'Closed'. Dấu thời gian sự kiện là CloseDate trên bản ghi yêu cầu.

Thu thập

Xác định thời điểm trường trạng thái chính của yêu cầu bồi thường được cập nhật thành 'Closed'.

Loại sự kiện inferred
Phát hành thanh toán
Hoạt động này đánh dấu bước cuối của quy trình thanh toán, khi khoản thanh toán chính thức được phát hành và gửi đến hệ thống tài chính. Đây là giao dịch tài chính được ghi nhận rõ ràng.
Vì sao điều này quan trọng

Hoạt động này rất quan trọng để đo hiệu quả của khâu gửi thanh toán. Nó giúp phân biệt chậm trễ do phê duyệt với chậm trễ trong việc thực sự phát hành tiền.

Lấy dữ liệu ở đâu

Ghi nhận từ IssueDate hoặc thay đổi trạng thái sang 'Issued' hay 'Submitted' trên thực thể cc_check hoặc cc_transaction. Đây thường là sự kiện có dấu thời gian được ghi nhận rõ ràng.

Thu thập

Xác định IssueDate hoặc dấu thời gian khi bản ghi thanh toán chuyển trạng thái sang 'Issued'.

Loại sự kiện explicit
Phê duyệt thanh toán
Đây là việc chính thức phê duyệt khoản thanh toán quyết toán. Sự kiện kiểm tra quan trọng này được ghi nhận rõ ràng khi người có thẩm quyền phê duyệt giao dịch.
Vì sao điều này quan trọng

Mốc quan trọng này cho phép tiến hành bước thanh toán cuối cùng. Phân tích thời gian trước và sau hoạt động này giúp xác định riêng các chậm trễ do workflow phê duyệt hoặc người quản lý chưa sẵn sàng.

Lấy dữ liệu ở đâu

Đây thường là sự kiện được ghi nhận rõ ràng trong bảng cc_history, liên quan đến thực thể cc_check hoặc cc_transaction, thể hiện thay đổi trạng thái từ 'Pending Approval' sang 'Approved'.

Thu thập

Theo dõi sự kiện đổi trạng thái sang 'Approved' của một giao dịch thanh toán cụ thể.

Loại sự kiện explicit
Tạo hạng mục tổn thất
Hoạt động này đánh dấu việc tạo một hạng mục tổn thất, đại diện cho một khoản trách nhiệm tiềm ẩn hoặc loại tổn thất cụ thể trong yêu cầu bồi thường, chẳng hạn như hư hỏng xe hoặc thương tích. Đây là sự kiện được ghi nhận rõ ràng trong Guidewire.
Vì sao điều này quan trọng

Hạng mục tổn thất là cơ sở để phân nhóm và phân tích yêu cầu bồi thường. Theo dõi thời điểm tạo hạng mục giúp bạn hiểu các biến thể quy trình theo độ phức tạp của yêu cầu và loại tổn thất.

Lấy dữ liệu ở đâu

Ghi nhận từ CreateTime của bản ghi mới trong bảng cc_exposure. Mỗi bản ghi được liên kết với một Claim ID duy nhất.

Thu thập

Xác định dấu thời gian tạo bản ghi mới trong bảng thực thể Exposure.

Loại sự kiện explicit
Tạo yêu cầu bồi thường
Hoạt động này đánh dấu lần thông báo tổn thất đầu tiên (FNOL) và thời điểm chính thức tạo hồ sơ yêu cầu bồi thường mới trong Guidewire ClaimCenter. Sự kiện được ghi nhận rõ ràng khi một thực thể Claim mới được lưu vào cơ sở dữ liệu lần đầu.
Vì sao điều này quan trọng

Là sự kiện bắt đầu chính, hoạt động này rất cần thiết để đo thời gian xử lý yêu cầu từ đầu đến cuối. Đây là mốc cơ sở cho mọi KPI về hiệu suất và thời lượng tiếp theo.

Lấy dữ liệu ở đâu

Đây là sự kiện được ghi nhận rõ ràng từ CreateTime của bảng cc_claim. Việc tạo bản ghi mới với Claim ID duy nhất là yếu tố kích hoạt sự kiện.

Thu thập

Xác định dấu thời gian tạo bản ghi mới trong bảng thực thể Claim gốc.

Loại sự kiện explicit
Thiết lập khoản dự phòng ban đầu
Đánh dấu thời điểm tạo giao dịch dự phòng tài chính đầu tiên cho một hạng mục tổn thất, nhằm ước tính chi phí tiềm năng của yêu cầu bồi thường. Đây là sự kiện tài chính quan trọng và được ghi nhận rõ ràng.
Vì sao điều này quan trọng

Mốc này rất quan trọng để phân tích tài chính và hiểu tốc độ đánh giá khoản trách nhiệm tiềm ẩn. Chậm trễ có thể ảnh hưởng đến việc lập kế hoạch và báo cáo tài chính.

Lấy dữ liệu ở đâu

Sự kiện này được ghi nhận khi tạo bản ghi cc_reserveline đầu tiên liên kết với một hạng mục tổn thất trong yêu cầu bồi thường. CreateTime của giao dịch là dấu thời gian sự kiện.

Thu thập

Tìm dấu thời gian tạo sớm nhất trong tất cả các dòng dự phòng của những hạng mục tổn thất thuộc một yêu cầu bồi thường.

Loại sự kiện explicit
Từ chối yêu cầu bồi thường
Đây là quyết định cuối cùng từ chối yêu cầu bồi thường, đánh dấu điểm kết thúc quy trình. Sự kiện này được suy ra khi trạng thái yêu cầu chuyển sang trạng thái đóng với lý do 'Denied'.
Vì sao điều này quan trọng

Đây là sự kiện thể hiện kết quả quan trọng. Phân tích tần suất, lý do và luồng quy trình dẫn đến việc từ chối giúp phát hiện vấn đề trong khâu tiếp nhận, điều tra hoặc diễn giải hợp đồng.

Lấy dữ liệu ở đâu

Suy ra từ việc trường State trong bảng cc_claim chuyển sang 'Closed', kết hợp với trường CloseReason có giá trị 'Denied' hoặc giá trị tương tự. CloseDate là dấu thời gian của sự kiện.

Thu thập

Lọc các trường hợp trạng thái yêu cầu chuyển sang 'Closed' với mã lý do thể hiện việc bị từ chối.

Loại sự kiện inferred
Bắt đầu điều tra
Cho biết giai đoạn điều tra một yêu cầu bồi thường hoặc tổn thất chính thức bắt đầu. Thông tin này thường được suy ra từ việc tạo 'Hoạt động' (nhiệm vụ) đầu tiên liên quan đến điều tra trong Guidewire.
Vì sao điều này quan trọng

Hoạt động này đánh dấu điểm bắt đầu của một giai đoạn quan trọng, thường kéo dài. Phân tích thời gian từ lúc tiếp nhận đến khi bắt đầu điều tra, cùng thời lượng điều tra, giúp phát hiện các điểm nghẽn lớn.

Lấy dữ liệu ở đâu

Suy ra từ CreateTime của bản ghi cc_activity có ActivityPattern liên quan đến điều tra, chẳng hạn như 'Điều tra ban đầu' hoặc 'Liên hệ nhân chứng'.

Thu thập

Xác định thời điểm tạo tác vụ đầu tiên có mẫu hoặc chủ đề liên quan đến điều tra.

Loại sự kiện inferred
Đưa ra quyết định về trách nhiệm
Đánh dấu thời điểm xác định trách nhiệm hoặc lỗi đối với một hạng mục tổn thất. Sự kiện này thường được suy ra từ thay đổi trạng thái của thực thể Exposure.
Vì sao điều này quan trọng

Đây là mốc quyết định quan trọng, mở đường cho các giai đoạn quyết toán và thanh toán. Phân tích thời gian đến khi đưa ra quyết định giúp phát hiện điểm nghẽn trong các khâu điều tra và đánh giá.

Lấy dữ liệu ở đâu

Suy ra từ bảng cc_history bằng cách theo dõi thay đổi trong State hoặc trường trạng thái trách nhiệm tùy chỉnh của thực thể cc_exposure. Dấu thời gian của bản ghi lịch sử cho biết thời điểm sự kiện xảy ra.

Thu thập

Theo dõi nhật ký kiểm tra hoặc bảng lịch sử để phát hiện cập nhật trạng thái hay trạng thái trách nhiệm của hạng mục tổn thất.

Loại sự kiện inferred
Mở lại yêu cầu bồi thường
Đây là việc chuyển yêu cầu bồi thường từ trạng thái 'Closed' trở lại 'Open' để tiếp tục xử lý. Sự kiện này được suy ra từ một chuỗi thay đổi trạng thái cụ thể.
Vì sao điều này quan trọng

Hoạt động này cho thấy có việc xử lý lại. Số lượng yêu cầu được mở lại cao thường báo hiệu vấn đề trong khâu quyết toán ban đầu, thiệt hại bị bỏ sót hoặc lỗi quy trình khác, làm tăng chi phí và giảm hiệu quả.

Lấy dữ liệu ở đâu

Suy ra từ bảng cc_history bằng cách xác định trường State của thực thể cc_claim chuyển từ 'Closed' trở lại 'Open' hoặc một trạng thái đang xử lý khác.

Thu thập

Theo dõi trường trạng thái chính của yêu cầu để phát hiện chuyển đổi từ trạng thái đóng sang trạng thái mở.

Loại sự kiện inferred
Nhận thông tin bổ sung
Đánh dấu thời điểm hoàn tất yêu cầu cung cấp thông tin bổ sung. Ghi nhận sự kiện này khi 'Hoạt động' (nhiệm vụ) tương ứng với yêu cầu cung cấp thông tin được đánh dấu là 'Đã hoàn tất'.
Vì sao điều này quan trọng

Đây là mốc kết thúc để tính KPI 'Thời gian thu thập thông tin bổ sung'. Khoảng thời gian dài từ lúc yêu cầu đến khi nhận được thông tin thường là nguyên nhân gây chậm trễ trong quy trình xử lý yêu cầu bồi thường.

Lấy dữ liệu ở đâu

Ghi nhận từ CloseTime của bản ghi cc_activity có ActivityPattern liên quan đến yêu cầu thông tin. Trạng thái hoạt động phải là 'Completed'.

Thu thập

Xác định dấu thời gian hoàn thành tác vụ yêu cầu thông tin từ bên ngoài.

Loại sự kiện explicit
Phân công yêu cầu bồi thường
Đây là việc phân công một yêu cầu bồi thường cho người dùng cụ thể (chuyên viên giám định) hoặc nhóm phụ trách. Sự kiện này thường được suy ra bằng cách theo dõi thay đổi trong các trường phân công của thực thể Claim.
Vì sao điều này quan trọng

Theo dõi việc phân công rất quan trọng để phân tích khối lượng công việc của chuyên viên giám định, phát hiện điểm nghẽn trong khâu điều phối và đo thời gian từ lúc phân công đến hành động đầu tiên của người phụ trách.

Lấy dữ liệu ở đâu

Suy ra từ bảng cc_history bằng cách theo dõi thay đổi trong các trường AssignedUser hoặc AssignedGroup gắn với một Claim ID cụ thể. Dấu thời gian của thay đổi cho biết thời điểm sự kiện xảy ra.

Thu thập

Theo dõi nhật ký kiểm tra hoặc bảng lịch sử để phát hiện cập nhật trong các trường phân công yêu cầu bồi thường.

Loại sự kiện inferred
Tính toán khoản quyết toán
Hoạt động này đánh dấu thời điểm xác định số tiền quyết toán nhưng chưa được phê duyệt thanh toán. Có thể suy ra sự kiện này từ việc tạo khoản thanh toán ở trạng thái 'Pending Approval'.
Vì sao điều này quan trọng

Đánh dấu bước chuyển từ đánh giá sang thanh toán. Đây là mốc bắt đầu đo KPI 'Thời gian chờ phê duyệt thanh toán', giúp phát hiện chậm trễ trong chuỗi phê duyệt.

Lấy dữ liệu ở đâu

Suy ra từ CreateTime của bản ghi cc_check hoặc cc_transaction có trạng thái ban đầu là 'Pending Approval' hoặc trạng thái tương tự trước khi chuyển sang 'Approved'.

Thu thập

Xác định thời điểm tạo bản ghi thanh toán hoặc giao dịch ở trạng thái chưa được phê duyệt.

Loại sự kiện inferred
Yêu cầu thông tin bổ sung
Thể hiện yêu cầu gửi cho người yêu cầu bồi thường hoặc bên thứ ba để xin thêm thông tin hoặc tài liệu. Thông tin này thường được ghi nhận dưới dạng 'Hoạt động' (nhiệm vụ) được tạo rõ ràng trong ClaimCenter.
Vì sao điều này quan trọng

Hoạt động này là mốc bắt đầu để đo KPI 'Thời gian thu thập thông tin bổ sung'. Sự kiện xảy ra thường xuyên có thể cho thấy quy trình FNOL chưa đầy đủ hoặc việc thu thập thông tin chưa hiệu quả.

Lấy dữ liệu ở đâu

Ghi nhận từ CreateTime của bản ghi cc_activity có ActivityPattern liên quan đến yêu cầu tài liệu hoặc thông tin từ bên ngoài.

Thu thập

Xác định thời điểm tạo tác vụ yêu cầu thông tin từ bên ngoài.

Loại sự kiện explicit
Nên có Không bắt buộc

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ Guidewire ClaimCenter

Sẵn sàng bắt đầu?

Dùng mẫu này để chuẩn bị dữ liệu phân tích và tìm hiểu sâu hơn về quy trình xử lý yêu cầu bồi thường. Bắt đầu cải thiện quy trình làm việc ngay hôm nay.

Rút ngắn thời gian xử lý yêu cầu bồi thường, giải quyết hồ sơ nhanh hơn

Giảm hồ sơ tồn đọng, ngăn chặn gian lận và hướng tới xử lý tự động xuyên suốt 70%.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng, thiết lập chỉ trong vài phút.