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

Mã yêu cầu bồi thường là khóa cốt lõi liên kết mọi hoạt động, sự kiện và điểm dữ liệu trong suốt vòng đời của một yêu cầu. Nhờ đó, bạn có thể theo dõi liền mạch mọi điểm tiếp xúc trong cùng một hồ sơ, từ lúc gửi yêu cầu đến khi đóng hồ sơ.

Trong process mining, thuộc tính này rất cần thiết để tái dựng hành trình từ đầu đến cuối của từng yêu cầu. Thuộc tính này cho phép phân tích luồng quy trình, tính tổng thời gian giải quyết và xác định sự khác biệt trong cách xử lý từng yêu cầu.

Đây là mã định danh cốt lõi liên kết mọi sự kiện liên quan thành một phiên bản quy trình duy nhất, giúp phân tích vòng đời yêu cầu từ đầu đến cuối.

Đây là khóa chính trong các bảng quản lý hồ sơ yêu cầu bồi thường chính của FINEOS Claims.

Thuộc tính này mô tả một bước hoặc mốc cụ thể trong quy trình xử lý yêu cầu, chẳng hạn 'Đã gửi yêu cầu bồi thường', 'Đã hoàn tất đánh giá ban đầu' hoặc 'Đã phát hành thanh toán'. Mỗi hoạt động thể hiện một hành động riêng được thực hiện đối với yêu cầu.

Phân tích trình tự và tần suất của các hoạt động là nền tảng của process mining. Việc này cho thấy luồng quy trình thực tế, giúp phát hiện điểm nghẽn nơi công việc bị dồn lại và làm rõ các luồng xử lý phổ biến hoặc ngoại lệ của yêu cầu.

Thuộc tính này xác định các bước trong quy trình, giúp trực quan hóa sơ đồ quy trình và phân tích các mẫu quy trình làm việc cũng như sai lệch.

Thường được lấy từ nhật ký sự kiện, thay đổi trạng thái tác vụ hoặc nhật ký kiểm tra trong hệ thống FINEOS Claims.

Thời điểm sự kiện ghi lại chính xác ngày giờ một hoạt động xử lý yêu cầu bồi thường diễn ra. Dữ liệu theo trình tự thời gian này rất quan trọng để sắp xếp sự kiện đúng thứ tự và hiểu tiến trình xử lý yêu cầu.

Khi phân tích, dấu thời gian này được dùng để tính thời lượng, thời gian xử lý và thời gian chờ giữa các bước. Đây là dữ liệu thiết yếu để phát hiện chậm trễ, đo hiệu suất theo SLA và hiểu diễn biến theo thời gian của quy trình.

Dấu thời gian này xác định thứ tự các sự kiện, rất cần thiết để tính mọi chỉ số dựa trên thời gian như thời gian xử lý và phát hiện điểm nghẽn.

Thông tin này thường có sẵn dưới dạng dấu thời gian tạo hoặc cập nhật gắn với từng sự kiện hay bản ghi trạng thái trong FINEOS Claims.

Thuộc tính này cho biết nguồn gốc của dữ liệu quy trình. Trong phân tích này, giá trị sẽ luôn là 'FINEOS Claims'. Tuy nhiên, trong môi trường có nhiều hệ thống, thuộc tính này rất quan trọng để truy vết nguồn gốc dữ liệu và bảo đảm chất lượng dữ liệu.

Trong bối cảnh phân tích rộng hơn, thuộc tính này giúp phân biệt các quy trình có thể trải qua nhiều hệ thống và bảo đảm dữ liệu được diễn giải chính xác theo nguồn.

Thuộc tính này cung cấp thông tin quan trọng về nguồn gốc dữ liệu, cần thiết cho việc quản trị, xác thực dữ liệu và tích hợp với các hệ thống khác.

Đây thường là giá trị cố định được thêm trong quá trình trích xuất dữ liệu để ghi rõ nguồn của tập dữ liệu.

Thuộc tính này cho biết ngày giờ dữ liệu được trích xuất hoặc cập nhật gần nhất. Thông tin này giúp bạn biết dữ liệu đang phân tích mới đến đâu và còn phù hợp với hiện tại hay không.

Thông tin này rất quan trọng đối với việc quản trị dữ liệu và giúp người dùng biết họ có đang xem dữ liệu quy trình mới nhất hay không. Thuộc tính này cũng giúp quản lý kỳ vọng về độ trễ dữ liệu và rất cần thiết khi báo cáo các quy trình gần thời gian thực.

Cho biết dữ liệu mới đến đâu, giúp người dùng hiểu khoảng thời gian mà phân tích bao quát và thời điểm dữ liệu được làm mới gần nhất.

Dấu thời gian này thường do công cụ trích xuất dữ liệu hoặc ETL tạo và lưu khi hoàn tất một lượt tải dữ liệu.

Thuộc tính này xác định cá nhân hoặc nhóm đã thực hiện một tác vụ cụ thể trong quy trình xử lý yêu cầu. Đây là cách chính để liên kết hoạt động trong quy trình với nhân sự.

Phân tích dữ liệu theo chuyên viên giám định được phân công rất quan trọng để hiểu cách phân bổ khối lượng công việc, hiệu suất cá nhân và hiệu quả sử dụng tài nguyên. Việc này có thể giúp phát hiện chuyên viên đang quá tải, xác định nhu cầu đào tạo qua so sánh hiệu suất và hỗ trợ phân bổ tài nguyên hợp lý hơn để cân bằng khối lượng công việc.

Thuộc tính này liên kết các bước trong quy trình với người thực hiện, giúp phân tích khối lượng công việc, đánh giá hiệu quả sử dụng tài nguyên và so sánh hiệu suất.

Tham khảo tài liệu FINEOS Claims. Thông tin này thường được lưu trong các trường chủ sở hữu tác vụ hoặc người dùng được phân công, gắn với sự kiện yêu cầu.

Thuộc tính này ghi lại cách tiếp nhận yêu cầu bồi thường, chẳng hạn qua cổng trực tuyến, email, thư giấy hoặc đại lý. Kênh gửi khác nhau có thể ảnh hưởng đáng kể đến chất lượng dữ liệu và thời gian xử lý ban đầu.

Phân tích quy trình theo kênh gửi giúp bạn xác định kênh nào xử lý nhanh hơn, có tỷ lệ làm lại cao hơn (ví dụ do thiếu thông tin) hoặc cho kết quả tốt hơn. Từ đó, bạn có thể quyết định đầu tư cải thiện kênh, chẳng hạn như nâng cấp biểu mẫu trực tuyến để giảm lỗi.

Giúp xác định kênh tiếp nhận nào xử lý hiệu quả hơn hoặc có tỷ lệ làm lại cao hơn, làm cơ sở cho chiến lược và quyết định đầu tư vào kênh.

Tham khảo tài liệu FINEOS Claims. Thông tin này thường được ghi nhận trong quá trình tiếp nhận yêu cầu và lưu trong hồ sơ yêu cầu bồi thường chính.

Loại yêu cầu bồi thường phân loại hồ sơ theo loại hợp đồng bảo hiểm hoặc sự cố gây tổn thất. Mỗi loại thường có các biến thể quy trình riêng, yêu cầu tuân thủ khác nhau và cần cách xử lý chuyên biệt.

Đây là chiều phân tích quan trọng để so sánh. Khi lọc hoặc chia quy trình theo loại yêu cầu bồi thường, chuyên viên phân tích có thể tìm ra điểm nghẽn riêng của từng loại, so sánh hiệu quả giữa các nhóm và điều chỉnh hoạt động cải tiến quy trình theo nhu cầu cụ thể. Nhờ đó, bạn có thể xác định liệu có loại yêu cầu nào vốn mất nhiều thời gian xử lý hơn hay không.

Cho phép chia quy trình thành các nhóm để so sánh hiệu quả và tìm ra khác biệt giữa các loại yêu cầu bồi thường, từ đó tập trung cải tiến đúng chỗ.

Tham khảo tài liệu FINEOS Claims. Đây là thuộc tính cốt lõi của yêu cầu bồi thường, thường được thiết lập khi đăng ký và lưu trong bảng hồ sơ chính.

Mức độ nghiêm trọng cho biết yêu cầu bồi thường phức tạp, cấp bách hoặc có rủi ro tài chính đến đâu. Hồ sơ nghiêm trọng có thể cần thêm bước xử lý, được chuyên gia đánh giá riêng hoặc mất nhiều thời gian hơn hồ sơ ít nghiêm trọng.

Phân tích quy trình theo mức độ nghiêm trọng giúp bạn đánh giá việc phân bổ nguồn lực và thiết kế quy trình có phù hợp với độ phức tạp của từng hồ sơ hay không. Bạn có thể phát hiện hồ sơ nghiêm trọng bị chậm trễ nhiều hơn dự kiến hoặc hồ sơ ít nghiêm trọng bị xử lý quá mức, từ đó phân nhóm quy trình và quản lý nguồn lực hiệu quả hơn.

Chia nhóm theo mức độ nghiêm trọng giúp bạn kiểm tra quy trình có ưu tiên đúng các hồ sơ tác động lớn hay không, đồng thời xác định mức độ phức tạp nào gây ra điểm nghẽn.

Tham khảo tài liệu FINEOS Claims. Thông tin này có thể nằm trong một trường riêng hoặc được suy ra từ các thuộc tính khác, chẳng hạn như số tiền tổn thất ước tính.

Thuộc tính này là hạn hoàn tất quy trình xử lý yêu cầu bồi thường, theo thỏa thuận mức dịch vụ (SLA) hoặc yêu cầu pháp lý. Đây là mốc để so sánh với kết quả thực tế.

Ngày này rất cần thiết để theo dõi việc tuân thủ SLA. So sánh ngày đóng hồ sơ thực tế với ngày mục tiêu giải quyết giúp bạn tính tỷ lệ đáp ứng SLA, tìm các hồ sơ có nguy cơ trễ hạn và phân tích nguyên nhân gốc rễ gây chậm trễ, dẫn đến không tuân thủ.

Đây là mốc để đo lường việc tuân thủ SLA. Thuộc tính này giúp xác định hồ sơ trễ hạn và phân tích nguyên nhân chậm trễ.

Tham khảo tài liệu FINEOS Claims. Ngày này thường được tính theo quy tắc nghiệp vụ, dựa trên ngày gửi yêu cầu và loại yêu cầu.

Thuộc tính này cho biết đơn vị trong tổ chức chịu trách nhiệm thực hiện một hoạt động hoặc quản lý hồ sơ ở một giai đoạn nhất định, chẳng hạn như 'Tiếp nhận ban đầu', 'Bộ phận điều tra' hoặc 'Phòng thanh toán'.

Phân tích quy trình theo phòng ban rất quan trọng để hiểu việc bàn giao giữa các bộ phận, vốn thường gây chậm trễ. Bạn có thể xác định phòng ban nào tạo ra điểm nghẽn, đo lường hiệu quả của từng bộ phận và phân tích cách phân bổ nguồn lực trong tổ chức.

Cho phép phân tích hiệu quả theo từng đơn vị, làm rõ tình trạng chậm trễ khi bàn giao giữa các phòng ban và điểm nghẽn ở từng bộ phận.

Tham khảo tài liệu FINEOS Claims. Thông tin này có thể liên kết với hồ sơ người dùng của chuyên viên xử lý được phân công hoặc hàng đợi nhận nhiệm vụ.

Thuộc tính Thời điểm kết thúc ghi lại chính xác lúc một hoạt động hoàn tất. Khi kết hợp với Thời điểm bắt đầu (EventTime), thuộc tính này giúp tính chính xác thời gian hoàn thành từng bước, tức thời gian xử lý.

Khi phân tích, thông tin này rất quan trọng để phân biệt thời gian xử lý thực tế với thời gian chờ. Nhờ đó, bạn có thể phân tích điểm nghẽn chi tiết, xác định hoạt động nào tốn nhiều thời gian nhất và hàng đợi hình thành ở đâu giữa các bước.

Cho phép tính chính xác thời gian xử lý của từng hoạt động, giúp phát hiện các bước kém hiệu quả và đo mức sử dụng tài nguyên.

Tham khảo tài liệu FINEOS Claims. Thông tin này có thể có trong nhật ký sự kiện hoặc được suy ra từ thời điểm bắt đầu của sự kiện tiếp theo.

Trạng thái yêu cầu bồi thường cho biết hồ sơ đang ở giai đoạn nào, chẳng hạn như 'Đang mở', 'Chờ thông tin', 'Đã duyệt', 'Bị từ chối' hoặc 'Đã đóng'. Thuộc tính này cho biết tình trạng của hồ sơ tại từng thời điểm.

Trong phân tích quy trình, thay đổi trạng thái thường gắn trực tiếp với các hoạt động xử lý. Theo dõi trạng thái giúp bạn hiểu kết quả hồ sơ, tìm điểm nghẽn khi hồ sơ bị giữ ở một trạng thái quá lâu và phân tích nguyên nhân dẫn đến kết quả cuối cùng như 'Bị từ chối' hoặc 'Đã đóng'.

Thuộc tính này giúp bạn hiểu kết quả xử lý, lọc hồ sơ đang mở hoặc đã đóng và tìm các giai đoạn hồ sơ bị đình trệ.

Tham khảo tài liệu FINEOS Claims. Đây là trường cơ bản trong hồ sơ yêu cầu bồi thường chính và được cập nhật trong suốt vòng đời hồ sơ.

Thuộc tính được tính toán này đánh dấu các hoạt động làm lại, chẳng hạn như sự kiện 'Yêu cầu bổ sung thông tin' lần thứ hai trong cùng một hồ sơ. Thông thường, hệ thống xác định hoạt động lặp lại hoặc vòng quay ngược trong luồng quy trình.

Đánh dấu rõ các bước làm lại giúp phân tích tình trạng kém hiệu quả dễ dàng hơn. Bạn có thể nhanh chóng tính tỷ lệ làm lại, một KPI quan trọng. Bảng điều khiển có thể dùng cờ này để hiển thị tần suất và tác động của việc làm lại, giúp tìm nguyên nhân gốc rễ của các vòng xử lý không hiệu quả.

Đánh dấu trực tiếp các vòng xử lý kém hiệu quả, giúp dễ dàng tính tỷ lệ làm lại và phân tích nguyên nhân khiến công việc phải lặp lại.

Thuộc tính này được suy ra trong quá trình phân tích process mining bằng cách tìm các hoạt động lặp lại trong cùng một hồ sơ. Ví dụ: đánh dấu lần xuất hiện thứ hai của 'Bắt đầu điều tra'.

Thuộc tính này cho biết địa điểm địa lý liên quan đến hồ sơ, có thể dựa trên địa chỉ của người yêu cầu bồi thường hoặc nơi xảy ra tổn thất.

Phân tích theo khu vực có thể làm rõ khác biệt về loại yêu cầu, tần suất và hiệu quả xử lý. Bạn có thể xác định văn phòng khu vực nào hoạt động tốt hơn hoặc yếu tố riêng tại địa phương (ví dụ: quy định, thời tiết) ảnh hưởng đến quy trình xử lý yêu cầu bồi thường ra sao. Nhờ đó, việc quản lý và phân bổ nguồn lực có thể tập trung hơn.

Cho phép chia nhóm theo khu vực địa lý để tìm khác biệt về hiệu quả, mức độ tuân thủ hoặc điểm nghẽn riêng của từng địa phương.

Tham khảo tài liệu FINEOS Claims. Thông tin này thường được lấy từ địa chỉ của chủ hợp đồng hoặc người yêu cầu bồi thường lưu trong hệ thống.

Thuộc tính này ghi lại lý do hồ sơ chuyển từ trạng thái 'Đã đóng' trở lại trạng thái đang xử lý. Các lý do thường gặp gồm nhận được thông tin mới, người yêu cầu kháng nghị hoặc cần sửa lỗi.

Phân tích lý do mở lại là cách trực tiếp để đo lường chất lượng quy trình và mức độ xử lý dứt điểm. Nếu có nhiều hồ sơ được mở lại, đặc biệt vì một số lý do nhất định, điều đó cho thấy việc đóng hồ sơ ban đầu chưa đúng. Dữ liệu này giúp xác định điểm yếu trong khâu điều tra hoặc ra quyết định, từ đó tập trung cải tiến quy trình để xử lý đúng ngay từ lần đầu.

Cho thấy trực tiếp các trường hợp quy trình có vấn đề, khi hồ sơ bị đóng quá sớm hoặc không chính xác, qua đó giúp tìm cơ hội nâng cao tỷ lệ xử lý dứt điểm ngay lần đầu.

Tham khảo tài liệu FINEOS Claims. Lý do này thường được ghi lại khi người dùng chọn thao tác 'Mở lại yêu cầu bồi thường' trong hệ thống.

Khi kết quả của yêu cầu bồi thường là 'Bị từ chối', thuộc tính này cho biết lý do cụ thể, chẳng hạn như 'Không thuộc phạm vi bảo hiểm', 'Nghi ngờ gian lận' hoặc 'Thiếu thông tin'.

Đây là thuộc tính quan trọng để phân tích nguyên nhân gốc rễ của việc từ chối. Phân tích tần suất từng lý do giúp tổ chức nhận diện vấn đề thường gặp khi gửi yêu cầu, những điểm khách hàng chưa rõ về phạm vi bảo hiểm hoặc nhu cầu đào tạo chuyên viên xử lý. Từ đó, tổ chức có thể giảm tỷ lệ từ chối và cải thiện mức độ hài lòng của khách hàng.

Rất cần thiết để phân tích nguyên nhân gốc rễ của các quy trình không đạt kết quả, giúp tìm cơ hội giảm số hồ sơ bị từ chối và nâng cao chất lượng tiếp nhận.

Tham khảo tài liệu FINEOS Claims. Đây thường là trường có cấu trúc hoặc mã được chọn khi thực hiện hoạt động 'Từ chối yêu cầu bồi thường'.

Ngày xảy ra tổn thất cho biết thời điểm sự cố thực tế (ví dụ: tai nạn, thương tích) diễn ra. Ngày này khác với ngày gửi yêu cầu và có thể ảnh hưởng đến việc xác minh, xử lý hồ sơ.

Thuộc tính này cung cấp bối cảnh hữu ích. Khoảng thời gian từ ngày xảy ra tổn thất đến ngày 'Gửi yêu cầu bồi thường' (độ trễ báo cáo) có thể là KPI quan trọng. Phân tích khoảng thời gian này giúp phát hiện vấn đề trong quy trình báo cáo và đánh giá ảnh hưởng của chúng đến toàn bộ vòng đời hồ sơ.

Cung cấp bối cảnh cần thiết và giúp tính độ trễ báo cáo (thời gian từ khi xảy ra tổn thất đến khi gửi yêu cầu), yếu tố có thể ảnh hưởng đến độ phức tạp và kết quả xử lý.

Tham khảo tài liệu FINEOS Claims. Đây là trường tiêu chuẩn, thường được ghi nhận khi tiếp nhận 'Thông báo tổn thất đầu tiên' hoặc đăng ký yêu cầu bồi thường.

Số hợp đồng bảo hiểm là mã định danh của hợp đồng bảo hiểm chi trả cho yêu cầu bồi thường. Mã này liên kết hồ sơ với một khách hàng cụ thể, các điều khoản hợp đồng và thông tin quyền lợi bảo hiểm.

Dù không phải thuộc tính quy trình trực tiếp, thông tin này cung cấp bối cảnh nghiệp vụ cần thiết. Bạn có thể tổng hợp dữ liệu yêu cầu bồi thường theo hợp đồng hoặc khách hàng để phân tích tần suất yêu cầu, trải nghiệm khách hàng và tìm các hợp đồng phát sinh nhiều hồ sơ phức tạp.

Cung cấp bối cảnh nghiệp vụ quan trọng, liên kết hồ sơ với hợp đồng của khách hàng và hỗ trợ phân tích quy trình theo góc nhìn khách hàng.

Tham khảo tài liệu FINEOS Claims. Đây là dữ liệu cơ bản được ghi nhận khi đăng ký yêu cầu bồi thường và lưu trong hồ sơ chính.

Số tiền thanh toán là khoản tiền cuối cùng được chi trả sau khi yêu cầu bồi thường được giải quyết và phê duyệt. Với hồ sơ có nhiều lần thanh toán, giá trị này có thể là số tiền của từng giao dịch riêng lẻ.

Thuộc tính này cần thiết cho việc đối soát tài chính và phân tích kết quả tài chính của quy trình. Bạn có thể so sánh số tiền tổn thất ước tính ban đầu với khoản chi trả cuối cùng. Trong phân tích quy trình, thuộc tính này giúp làm rõ tác động tài chính của các biến thể quy trình hoặc quyết định khác nhau.

Theo dõi kết quả tài chính của quy trình, giúp đo lường hiệu quả tài chính và phân tích giá trị của các yêu cầu bồi thường.

Tham khảo tài liệu FINEOS Claims. Dữ liệu này nằm trong các bảng giao dịch thanh toán được liên kết với hồ sơ.

Số tiền tổn thất là ước tính ban đầu hoặc khoản dự phòng tài chính dành cho yêu cầu bồi thường. Giá trị này có thể thay đổi khi hồ sơ được điều tra và đánh giá.

Dữ liệu tài chính này rất quan trọng để phân nhóm hồ sơ và tìm hiểu mối liên hệ giữa tác động tài chính với cách quy trình diễn ra. Ví dụ, bạn có thể xác định hồ sơ có giá trị cao mất nhiều thời gian xử lý hơn hoặc cần làm lại nhiều hơn hay không. Đây cũng là dữ liệu đầu vào quan trọng cho dự báo tài chính và quản lý rủi ro.

Cung cấp bối cảnh tài chính cho quy trình, giúp phân tích giá trị yêu cầu bồi thường ảnh hưởng thế nào đến thời gian xử lý, độ phức tạp và luồng xử lý.

Tham khảo tài liệu FINEOS Claims. Thông tin này thường nằm trong các bảng tài chính hoặc dự phòng được liên kết với hồ sơ.

Thuộc tính này cho biết rõ trạng thái thực hiện SLA của từng hồ sơ. Hệ thống so sánh ngày 'Đóng yêu cầu bồi thường' với 'Ngày mục tiêu giải quyết', rồi phân loại kết quả là 'Đúng hạn' hoặc 'Trễ hạn'.

Nhờ đó, việc báo cáo và phân tích mức độ đáp ứng SLA trở nên đơn giản hơn. Thay vì xử lý ngày tháng thô, chuyên viên phân tích có thể dùng các nhóm trạng thái này để tạo bảng điều khiển về tỷ lệ tuân thủ SLA, lọc các hồ sơ trễ hạn để tìm điểm chung và theo dõi xu hướng theo thời gian. Thuộc tính này hỗ trợ trực tiếp bảng điều khiển và KPI về mức độ đáp ứng SLA.

Cung cấp chỉ báo rõ ràng, dễ hiểu về hiệu quả SLA của từng hồ sơ, giúp đo lường và phân tích tỷ lệ tuân thủ SLA.

Đây là trường được tính toán bằng cách so sánh dấu thời gian của hoạt động cuối cùng với 'ResolutionTargetDate' của từng hồ sơ.