Mẫu dữ liệu quản lý incident

Quản lý vấn đề trong ServiceNow
Mẫu dữ liệu quản lý incident

Mẫu dữ liệu quản lý incident

Mẫu này hướng dẫn bạn thu thập dữ liệu cần thiết để phân tích và tối ưu hóa quy trình quản lý incident. Mẫu nêu rõ các thuộc tính dữ liệu cần thu thập, hoạt động chính cần theo dõi và cách lấy thông tin từ hệ thống nguồn. Dùng tài nguyên này để tạo nhật ký sự kiện phục vụ phân tích và cải tiến quy trình chuyên sâu.
  • 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 cho Problem Management trong ServiceNow
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.

Các thuộc tính quản lý incident

Đây là những trường dữ liệu nên có trong nhật ký sự kiện để phân tích quy trình quản lý incident một cách đầy đủ.
5 Bắt buộc 4 Nên có 10 Không bắt buộc
Tên Mô tả
Mã sự cố
IncidentId
Mã định danh duy nhất của mỗi bản ghi sự cố, dùng làm khóa chính để theo dõi toàn bộ vòng đời sự cố.
Mô tả

Mã sự cố là mã tham chiếu duy nhất được cấp cho mỗi sự cố được báo cáo trong ServiceNow. Mã này đóng vai trò định danh chính của hồ sơ, liên kết mọi hoạt động, cập nhật và trao đổi liên quan từ lúc tạo sự cố đến khi đóng.

Trong phân tích process mining, mã này giữ vai trò nền tảng. Công cụ dùng mã để ghép chuỗi sự kiện của từng hồ sơ, làm cơ sở khám phá sơ đồ quy trình, phân tích các biến thể và tính thời lượng từ đầu đến cuối. Nếu mỗi hồ sơ không có mã sự cố duy nhất, bạn sẽ không thể theo dõi toàn bộ quá trình xử lý sự cố.

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

Đây là mã hồ sơ thiết yếu, liên kết mọi sự kiện trong vòng đời sự cố và giúp phân tích quy trình từ đầu đến cuối.

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

Bảng incident của ServiceNow, trường number.

Ví dụ
INC0010001INC0010045INC0010239
Tên hoạt động
ActivityName
Tên của sự kiện hoặc tác vụ cụ thể diễn ra tại một thời điểm trong vòng đời sự cố.
Mô tả

Tên hoạt động mô tả một bước cụ thể hoặc thay đổi trạng thái trong quy trình quản lý sự cố, chẳng hạn như 'Sự cố được tạo', 'Giao cho nhân viên hỗ trợ' hoặc 'Đóng sự cố'. Dữ liệu này thường được suy ra từ các thay đổi trong những trường quan trọng của sự cố như 'State' hoặc 'Assignment Group', hoặc từ các mục nhật ký cụ thể.

Thuộc tính này rất quan trọng để tạo sơ đồ quy trình. Nó xác định các nút trong sơ đồ, giúp chuyên viên phân tích hình dung luồng xử lý sự cố, xác định lộ trình phổ biến, tìm điểm nghẽn giữa các hoạt động và phân tích các biến thể quy trình. Mức độ chi tiết và độ chính xác của tên hoạt động ảnh hưởng trực tiếp đến chất lượng phân tích 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 trong sơ đồ quy trình, nền tảng cho mọi hoạt động phân tích và trực quan hóa bằng process mining.

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

Đây là thuộc tính được tạo ra từ dữ liệu, thường do logic chuyển đổi dữ liệu tạo dựa trên các thay đổi ở những trường như state, assignment_group và assigned_to trong bảng sys_audit hoặc incident.

Ví dụ
Sự cố được tạoNhóm phụ trách thay đổiĐề xuất giải phápĐóng sự cố
Thời điểm sự kiện
EventTime
Dấu thời gian chính xác cho biết hoạt động diễn ra khi nào.
Mô tả

Thời điểm sự kiện, thường được gọi là dấu thời gian, ghi lại chính xác ngày giờ một hoạt động hoàn tất hoặc trạng thái thay đổi. Trong ServiceNow, thông tin này thường được ghi trong trường sys_updated_on cho mỗi thay đổi trong nhật ký kiểm tra.

Thuộc tính này rất cần thiết để sắp xếp sự kiện đúng thứ tự và thực hiện mọi phân tích dựa trên thời gian. Thuộc tính được dùng để tính thời gian xử lý, thời gian chờ và khoảng thời gian giữa các hoạt động. Đây là cơ sở để xác định điểm nghẽn, đo hiệu suất theo SLA và hiểu hiệu quả quy trình. Dấu thời gian phải chính xác để các chỉ số dựa trên thời lượng có giá trị.

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

Dấu thời gian này sắp xếp mọi hoạt động theo trình tự thời gian và cho phép tính các chỉ số dựa trên thời lượng, như thời gian xử lý và điểm nghẽn.

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

Bảng sys_audit của ServiceNow, trường sys_created_on hoặc trường sys_updated_on trong bảng incident cho trạng thái cuối cùng.

Ví dụ
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
Hệ thống nguồn
SourceSystem
Hệ thống dùng để trích xuất dữ liệu này.
Mô tả

Thuộc tính này cho biết nguồn gốc của dữ liệu sự cố, trong trường hợp này là ServiceNow Problem Management. Đây thường là giá trị cố định được thêm vào trong quá trình trích xuất và chuyển đổi dữ liệu.

Khi phân tích dữ liệu kết hợp từ nhiều hệ thống, trường này rất quan trọng để theo dõi nguồn gốc và phân tách dữ liệu. Trường giúp đảm bảo các chỉ số và quy trình được phân tích đúng bối cảnh, đồng thời cho phép chuyên viên phân tích so sánh quy trình giữa các hệ thống nguồn.

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

Thuộc tính này cung cấp bối cảnh quan trọng về nguồn gốc dữ liệu, giúp theo dõi nguồn dữ liệu và diễn giải chính xác trong môi trường có nhiều hệ thống.

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

Đây thường là giá trị cố định được thêm vào trong quá trình trích xuất dữ liệu.

Ví dụ
Quản lý vấn đề trong ServiceNowServiceNow
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ủa bản ghi này được làm mới từ hệ thống nguồn.
Mô tả

Thuộc tính này ghi lại ngày giờ của lần trích xuất hoặc cập nhật dữ liệu gần nhất từ ServiceNow. Đây là trường siêu dữ liệu cho biết dữ liệu đang phân tích mới đến mức nào, không phải một sự kiện trong quy trình.

Thông tin này rất cần thiết để hiểu dữ liệu có được cập nhật kịp thời hay không. Thông tin cho người dùng biết dữ liệu mới đến đâu, điều quan trọng đối với bảng điều khiển vận hành và các quyết định dựa trên sự kiện gần đây. Nhờ đó, người dùng có thể đánh giá mức độ phù hợp và tính cập nhật của dữ liệu.

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

Thuộc tính này cho người dùng biết dữ liệu mới đến đâu, yếu tố quan trọng đối với tính phù hợp và độ chính xác của phân tích.

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

Dấu thời gian này được công cụ hoặc quy trình trích xuất dữ liệu tạo và điền vào lúc tải dữ liệu.

Ví dụ
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Mức ưu tiên
Priority
Mức ưu tiên của sự cố, quyết định mức độ khẩn cấp cần thiết khi phản hồi.
Mô tả

Priority là trường quan trọng trong ServiceNow, xác định thứ tự và tốc độ xử lý sự cố. Trường này thường được xác định dựa trên mức độ ảnh hưởng và tính khẩn cấp của sự cố, đồng thời tác động trực tiếp đến mục tiêu SLA.

Thuộc tính này là cơ sở cho việc phân nhóm và phân tích hiệu suất. Bảng điều khiển 'Tổng quan tuân thủ SLA' dùng Priority để đánh giá liệu các sự cố có mức ưu tiên cao có được xử lý trong thời gian mục tiêu hay không. Phân tích thời gian xử lý theo mức ưu tiên giúp xác nhận các sự cố nghiêm trọng có được xử lý nhanh hơn những sự cố ít quan trọng hay không. Đây là chiều phân tích quan trọng đối với hầu hết KPI và bảng điều khiển.

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

Thuộc tính này cho phép phân nhóm sự cố theo mức độ quan trọng với hoạt động kinh doanh, yếu tố thiết yếu để theo dõi tuân thủ SLA và phân bổ tài nguyên.

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

Bảng incident của ServiceNow, trường priority.

Ví dụ
1 - Nghiêm trọng2 - Cao3 - Trung bình4 - Thấp
Người được giao
AssignedTo
Người dùng hoặc nhân viên hỗ trợ hiện được giao xử lý sự cố.
Mô tả

Thuộc tính này xác định nhân viên hỗ trợ cụ thể chịu trách nhiệm xử lý sự cố tại một thời điểm nhất định. Thông tin này 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ủa nhân viên và việc bàn giao giữa các cá nhân.

Trong phân tích, 'Người được giao' giúp trực quan hóa việc phân bổ tài nguyên và xác định nhân viên đang quá tải. Thuộc tính này cũng được dùng trong bảng điều khiển Bàn giao và phân công lại để theo dõi số lần sự cố đổi người phụ trách, một dấu hiệu có thể cho thấy quy trình kém hiệu quả hoặc thiếu kiến thức. Phân tích thời gian xử lý theo từng nhân viên cũng có thể giúp nhận diện người làm tốt hoặc người cần được đào tạo thêm.

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

Thuộc tính này cho phép phân tích khối lượng công việc, hiệu suất của nhân viên và các lần bàn giao cá nhân, những yếu tố quan trọng để hiểu hiệu quả sử dụng tài nguyên.

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

Bảng incident của ServiceNow, trường assigned_to.

Ví dụ
Beth AnglinDavid LooHoward Johnson
Nhóm phụ trách
AssignmentGroup
Nhóm hỗ trợ chịu trách nhiệm xử lý sự cố.
Mô tả

Nhóm phụ trách là nhóm nhân viên được giao xử lý sự cố. Sự cố thường được điều phối giữa các nhóm khác nhau, chẳng hạn từ bộ phận hỗ trợ cấp 1 đến nhóm mạng chuyên trách cấp 2.

Thuộc tính này rất cần thiết để phân tích việc bàn giao giữa các nhóm và xác định điểm nghẽn mang tính hệ thống. Bảng điều khiển 'Tỷ lệ bàn giao và phân công lại' dựa nhiều vào dữ liệu này để cho biết những nhóm thường xuyên tham gia xử lý chuyển tiếp. Thuộc tính cũng cho phép so sánh hiệu suất giữa các nhóm hỗ trợ và giúp xác định chuyên môn xử lý sự cố nằm ở đâu trong tổ chức.

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

Thuộc tính này theo dõi nhóm chịu trách nhiệm, giúp phân tích hiệu suất, khối lượng công việc và việc bàn giao giữa các nhóm.

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

Bảng incident của ServiceNow, trường assignment_group.

Ví dụ
Bộ phận hỗ trợ dịch vụHỗ trợ mạngQuản trị viên cơ sở dữ liệu
Trạng thái sự cố
IncidentState
Trạng thái hiện tại của sự cố trong vòng đời xử lý.
Mô tả

Trạng thái sự cố cho biết giai đoạn hiện tại, chẳng hạn như 'New', 'In Progress', 'On Hold' hoặc 'Resolved'. Các thay đổi trạng thái thường là nguồn chính để tạo hoạt động trong nhật ký sự kiện phục vụ process mining.

Phân tích thời gian ở từng trạng thái là cách hiệu quả để xác định điểm nghẽn. Ví dụ, thời gian dài ở trạng thái 'On Hold' có thể cho thấy quy trình phụ thuộc vào yếu tố bên ngoài hoặc người dùng. Trình tự thay đổi trạng thái cũng là cơ sở tạo sơ đồ quy trình, cho thấy sự cố tiến triển như thế nào cho đến khi được xử lý.

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

Thuộc tính này theo dõi tiến độ xử lý sự cố, giúp phân tích thời gian ở từng giai đoạn và xác định điểm nghẽn trong quy trình.

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

Bảng incident của ServiceNow, trường incident_state hoặc state.

Ví dụ
MớiĐang xử lýChờ thông tin từ người dùngĐã xử lýĐã đóng
Cấu phần cấu hình
ConfigurationItem
Thành phần, dịch vụ hoặc tài sản CNTT cụ thể bị incident ảnh hưởng.
Mô tả

Configuration Item (CI) là tài sản trong Cơ sở dữ liệu quản lý cấu hình (CMDB) bị incident ảnh hưởng. Đó có thể là máy chủ, ứng dụng, máy tính xách tay hoặc thiết bị mạng.

Phân tích incident theo CI giúp phát hiện tài sản hoặc dịch vụ hoạt động không ổn định. Bạn có thể xác định phần nào của hạ tầng CNTT gây ra nhiều incident nhất, từ đó cân nhắc đầu tư nâng cấp hoặc thay thế. Trong process mining, lọc theo CI giúp bạn xem các incident liên quan đến ứng dụng quan trọng có được xử lý khác hoặc hiệu quả hơn những incident khác hay không.

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

Thuộc tính này xác định tài sản bị ảnh hưởng, giúp tìm ra các thành phần có vấn đề trong hạ tầng CNTT và tập trung nỗ lực cải tiến.

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

Bảng incident của ServiceNow, trường cmdb_ci.

Ví dụ
SAP ERP ProductionOracle DB Server 05Dịch vụ email
Có vi phạm SLA không
IsSlaBreached
Cờ cho biết thời gian xử lý incident có vượt quá thời hạn SLA hay không.
Mô tả

Đây là thuộc tính đúng/sai được tính toán để đánh dấu incident vi phạm Thỏa thuận mức dịch vụ (SLA). Giá trị được xác định bằng cách so sánh thời điểm xử lý thực tế với “Thời hạn SLA”. Nếu xử lý sau thời hạn, cờ được đặt thành true.

Thuộc tính này là cơ sở cho bảng điều khiển “SLA Compliance Overview” và các KPI liên quan. Nó đơn giản hóa việc phân tích bằng cách chuyển phép so sánh thời gian phức tạp thành giá trị đúng/sai. Bạn có thể dễ dàng lọc tất cả incident vi phạm SLA rồi phân tích các đặc điểm chung như danh mục, nhóm phụ trách hoặc mức độ ưu tiên.

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

Thuộc tính này giúp phân tích mức độ tuân thủ SLA đơn giản hơn, cho phép lọc và đi sâu phân tích các incident không đạt thời hạn.

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

Tính bằng cách so sánh dấu thời gian “Resolved At” với “SlaDueDate”. (Resolved At > SlaDueDate).

Ví dụ
truefalse
Đã mở lại
IsReopened
Cờ cho biết incident có được mở lại sau khi xử lý xong hay không.
Mô tả

Cờ đúng/sai này được đặt thành true nếu trạng thái incident chuyển lại trạng thái đang xử lý, chẳng hạn “In Progress”, sau khi đã chuyển sang “Resolved” hoặc “Closed”. Thông thường, có thể xác định việc này bằng cách tìm hoạt động “Incident Reopened” trong nhật ký sự kiện.

Incident được mở lại thường cho thấy việc xử lý chưa đầy đủ hoặc chưa hiệu quả. Phân tích các trường hợp này giúp phát hiện việc đóng incident quá sớm hoặc vấn đề tái diễn chưa được khắc phục triệt để. Tỷ lệ mở lại cao có thể làm giảm mức độ hài lòng của người dùng và năng suất của nhóm, vì vậy đây là chỉ số quan trọng để kiểm soát chất lượng.

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

Cờ này cho thấy quy trình xử lý chưa đạt yêu cầu, bằng cách đánh dấu các incident cần làm thêm sau khi đã được xem là xử lý xong.

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

Tính bằng cách kiểm tra thứ tự hoạt động của từng incident để xác định trạng thái “open” có xuất hiện sau trạng thái “resolved” hay không.

Ví dụ
truefalse
Danh mục
Category
Phân loại tổng quát của sự cố, chẳng hạn như Phần cứng, Phần mềm hoặc Mạng.
Mô tả

Category phân loại tổng quát bản chất của sự cố. Trường này thường được dùng cùng với danh mục phụ để điều phối sự cố đến đúng nhóm hỗ trợ, đồng thời phục vụ báo cáo và phân tích xu hướng.

Trong process mining, thuộc tính này rất quan trọng đối với các bảng điều khiển 'Độ chính xác phân loại sự cố' và 'Số sự cố tái diễn'. Bằng cách phân tích các sự cố bị đổi danh mục giữa chừng, tổ chức có thể xác định vấn đề trong khâu đánh giá ban đầu. Lọc sơ đồ quy trình theo danh mục cũng có thể cho thấy một số loại sự cố có lộ trình xử lý khác hoặc gặp những điểm nghẽn riêng.

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

Thuộc tính này cho phép phân tích các loại sự cố, đo độ chính xác khi phân loại và hỗ trợ điều phối cũng như phân tích xu hướng.

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

Bảng incident của ServiceNow, trường category.

Ví dụ
Phần cứngPhần mềmMạngCơ sở dữ liệu
Mã giải quyết
ResolutionCode
Mã cho biết cách sự cố được xử lý cuối cùng.
Mô tả

Resolution Code cho biết cách áp dụng giải pháp, chẳng hạn như người dùng tự xử lý, xử lý bằng cách khắc phục lỗi đã biết hoặc áp dụng giải pháp tạm thời. Nhân viên hỗ trợ thường điền trường này khi đóng sự cố.

Thuộc tính này hỗ trợ trực tiếp cho bảng điều khiển 'Hiệu quả theo loại giải pháp'. Thuộc tính cho phép phân tích số sự cố được đóng bằng cách khắc phục lâu dài so với giải pháp tạm thời. Đây là chỉ báo quan trọng về chất lượng dịch vụ và độ ổn định lâu dài. Tỷ lệ dùng giải pháp tạm thời cao có thể cho thấy các vấn đề gốc chưa được xử lý thỏa đáng.

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

Thuộc tính này làm rõ phương thức xử lý, cho phép phân tích cách khắc phục lâu dài so với giải pháp tạm thời và hỗ trợ tìm nguyên nhân gốc rễ.

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

Bảng incident của ServiceNow, trường close_code hoặc trường mã xử lý tùy chỉnh.

Ví dụ
Đã xử lý (có giải pháp tạm thời)Đã xử lý (triệt để)Chưa xử lý (người dùng đã hủy)Lỗi đã biết
Mã sự cố
ProblemId
Mã của bản ghi Problem liên quan nếu incident được liên kết với một vấn đề lớn hơn.
Mô tả

Problem ID liên kết một incident với bản ghi tương ứng trong mô-đun Problem Management. Việc này được thực hiện khi xác định incident là triệu chứng của một vấn đề tiềm ẩn lớn hơn, ảnh hưởng đến nhiều người dùng hoặc dịch vụ.

Liên kết này rất quan trọng với bảng điều khiển “Recurring Incident Volume” và KPI “Recurring Incident Rate”. Nhờ đó, chuyên viên phân tích có thể nhóm các incident cùng nguyên nhân gốc, đo lường đầy đủ tác động của vấn đề và theo dõi hiệu quả xử lý. Nhiều incident liên kết với các vấn đề cho thấy đội hỗ trợ thường phải xử lý sự việc sau khi chúng xảy ra.

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

Thuộc tính này liên kết incident với nguyên nhân gốc, giúp phân tích sự cố tái diễn và đo lường hiệu quả của hoạt động quản lý vấn đề.

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

Bảng incident của ServiceNow, trường problem_id.

Ví dụ
PRB0040001PRB0040015PRB0040102
Mức độ nghiêm trọng
Severity
Mức độ ảnh hưởng của incident đến hoạt động kinh doanh.
Mô tả

Mức độ nghiêm trọng cho biết incident ảnh hưởng đến hoạt động kinh doanh nhiều đến đâu. Cùng với mức độ khẩn cấp, thuộc tính này thường được dùng để tự động tính mức độ ưu tiên của incident.

Khi phân tích, mức độ nghiêm trọng là chiều dữ liệu quan trọng trong bảng điều khiển “SLA Compliance Overview”. Thuộc tính này giúp tổ chức biết mình có đáp ứng mức dịch vụ cho những incident gây gián đoạn lớn nhất hay không. Nó bổ sung góc nhìn theo tác động kinh doanh cho góc nhìn vận hành mà mức độ ưu tiên cung cấp.

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

Thuộc tính này đo lường tác động của incident đến hoạt động kinh doanh, giúp ưu tiên xử lý và phân tích hiệu quả đối với các vấn đề nghiêm trọng.

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

Bảng incident của ServiceNow, trường severity.

Ví dụ
1 - Cao2 - Trung bình3 - Thấp
Người báo sự cố
CallerId
Người dùng đầu tiên báo incident.
Mô tả

Caller xác định người dùng cuối hoặc khách hàng bị ảnh hưởng và đã báo incident. Thông tin này cho biết ai đang chịu tác động khi dịch vụ bị gián đoạn.

Caller không phải lúc nào cũng gắn trực tiếp với luồng quy trình, nhưng phân tích incident theo người báo có thể cho thấy một số cá nhân hoặc phòng ban thường xuyên gặp vấn đề hơn. Đây có thể là dấu hiệu cần đào tạo hoặc có vấn đề tại một môi trường cụ thể. Thông tin này cũng giúp liên hệ trực tiếp với khách hàng để khảo sát mức độ hài lòng và trao đổi tình hình.

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

Thuộc tính này xác định người dùng bị ảnh hưởng, giúp phân tích theo phòng ban hoặc cá nhân và cung cấp thông tin cần thiết để trao đổi với người dùng.

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

Bảng incident của ServiceNow, trường caller_id.

Ví dụ
Abel TuterCarolina PashDon Goodliffe
Số lần phân công lại
ReassignmentCount
Số lần incident được chuyển sang nhóm hoặc nhân viên khác.
Mô tả

Trường này ghi lại tổng số lần incident được chuyển giữa các nhóm phụ trách. Đây là thước đo trực tiếp mức độ vướng mắc trong quy trình và thường được dùng làm chỉ số hiệu quả chính.

Thuộc tính này là cơ sở cho bảng điều khiển “Handoff and Reassignment Rate” và KPI “Average Handoffs per Incident”. Số lần phân công lại cao thường cho thấy vấn đề như định tuyến ban đầu không chính xác, nhóm hỗ trợ thiếu kỹ năng cần thiết hoặc chưa rõ ai chịu trách nhiệm về quy trình. Giảm số lần này là mục tiêu phổ biến trong các sáng kiến cải tiến quy trình, vì thường giúp rút ngắn thời gian xử lý.

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

Thuộc tính này đo trực tiếp số lần bàn giao trong quy trình, một dấu hiệu quan trọng cho thấy quy trình kém hiệu quả, định tuyến sai và có cơ hội cải tiến.

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

Bảng incident của ServiceNow, trường reassignment_count.

Ví dụ
0135
Thời hạn SLA
SlaDueDate
Ngày giờ mục tiêu cần xử lý xong incident theo SLA.
Mô tả

Thời hạn SLA là mốc thời gian được tính để xác định hạn xử lý incident. Mốc này dựa trên Thỏa thuận mức dịch vụ (SLA) gắn với các đặc điểm của incident, chẳng hạn như mức độ ưu tiên.

Thuộc tính này rất cần thiết cho bảng điều khiển “SLA Compliance Overview” và KPI “Critical Incident SLA Breach Rate”. Đây là mốc chuẩn để so sánh với thời gian xử lý thực tế. Phân tích các incident sắp đến hạn SLA giúp bạn chủ động chuyển cấp xử lý và sắp xếp thứ tự ưu tiên.

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

Thuộc tính này xác định thời hạn xử lý, giúp đo lường mức độ tuân thủ SLA và phát hiện incident có nguy cơ trễ hạn.

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

Giá trị này thường nằm trong bảng task_sla, có liên kết với bảng incident. Trường thời gian liên quan là planned_end_time.

Ví dụ
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
Bắt buộc Nên có Không bắt buộc

Các hoạt động trong quy trình quản lý incident

Đây là những bước và mốc chính cần ghi lại trong nhật ký sự kiện để khám phá và tối ưu hóa quy trình chính xác.
6 Nên có 7 Không bắt buộc
Hoạt động Mô tả
Bắt đầu xử lý
Cho biết nhân viên hỗ trợ đã bắt đầu điều tra hoặc xử lý sự cố. Hoạt động này thường được suy ra khi trạng thái sự cố chuyển từ 'New' hoặc 'Assigned' sang trạng thái đang xử lý như 'In Progress'.
Vì sao điều này quan trọng

Mốc này đánh dấu thời điểm kết thúc thời gian chờ ban đầu và bắt đầu xử lý thực tế. Đo thời gian chờ đến khi bắt đầu xử lý là yếu tố quan trọng để phân tích điểm nghẽn.

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

Suy ra từ bảng 'sys_audit' bằng cách xác định thời điểm trường 'state' trong bảng 'incident' chuyển sang trạng thái đang xử lý, chẳng hạn như 'In Progress'.

Thu thập

Xác định dấu thời gian khi trường 'state' chuyển thành 'In Progress' hoặc một giá trị tương tự.

Loại sự kiện inferred
Đề xuất giải pháp
Đánh dấu thời điểm nhân viên hỗ trợ đã áp dụng cách khắc phục và chuyển sự cố sang trạng thái 'Resolved'. Đây là mốc quan trọng trước khi đóng sự cố.
Vì sao điều này quan trọng

Hoạt động này cho biết công việc xử lý đã kết thúc và giai đoạn xác nhận bắt đầu. Khoảng thời gian từ đây đến 'Sự cố đã đóng' có thể cho thấy việc xác nhận của người dùng hoặc kiểm tra còn chậm trễ.

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

Suy ra từ bảng 'sys_audit' khi trường 'state' trong bảng 'incident' chuyển thành 'Resolved'. Dấu thời gian 'resolved_at' thường được điền vào thời điểm này.

Thu thập

Dùng dấu thời gian khi trường 'state' chuyển thành 'Resolved' hoặc dấu thời gian 'resolved_at'.

Loại sự kiện inferred
Đóng sự cố
Đây là hoạt động cuối cùng trong vòng đời sự cố, cho biết sự cố đã được xử lý xong, xác nhận và không cần hành động nào khác. Sự kiện này được ghi nhận trực tiếp bằng dấu thời gian đóng.
Vì sao điều này quan trọng

Là sự kiện kết thúc chính thức, hoạt động này rất cần thiết để tính tổng thời gian vòng đời sự cố và phân tích thời gian xử lý các bước sau khi giải quyết.

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

Dấu thời gian 'closed_at' trong bảng 'incident' là dấu thời gian sự kiện được ghi nhận trực tiếp. Giá trị này thường được thiết lập khi trường 'state' chuyển thành 'Closed'.

Thu thập

Dùng dấu thời gian 'closed_at' trong bản ghi sự cố.

Loại sự kiện explicit
Nhóm phụ trách thay đổi
Đại diện cho lần bàn giao khi sự cố được chuyển từ nhóm hỗ trợ này sang nhóm khác. Hoạt động này được ghi nhận qua các thay đổi tiếp theo ở trường 'assignment_group' sau lần điền đầu tiên.
Vì sao điều này quan trọng

Việc phân công lại thường xuyên có thể cho thấy điều phối ban đầu chưa đúng, quy trình phức tạp hoặc thiếu kiến thức. Hoạt động này rất quan trọng để đo KPI 'Số lần bàn giao trung bình cho mỗi sự cố'.

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

Suy ra từ bảng 'sys_audit' bằng cách theo dõi mọi thay đổi ở trường 'assignment_group' sau lần phân công ban đầu.

Thu thập

Xác định dấu thời gian của từng thay đổi ở trường 'assignment_group' trong nhật ký kiểm tra.

Loại sự kiện inferred
Sự cố được giao cho nhóm
Hoạt động này diễn ra khi sự cố được giao cho một nhóm hỗ trợ cụ thể xử lý. Đây là bước quan trọng trong quá trình điều phối, được ghi nhận qua các thay đổi ở trường nhóm phụ trách.
Vì sao điều này quan trọng

Theo dõi việc phân công là điều cần thiết để phân tích các lần bàn giao, thời gian chờ của từng nhóm và xác định điểm kém hiệu quả hoặc điểm nghẽn trong điều phối.

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

Suy ra từ bảng 'sys_audit' bằng cách theo dõi thời điểm trường 'assignment_group' trong bảng 'incident' được điền hoặc thay đổi.

Thu thập

Dùng dấu thời gian trong nhật ký kiểm tra cho các thay đổi ở trường 'assignment_group'.

Loại sự kiện inferred
Sự cố được tạo
Đánh dấu thời điểm bắt đầu vòng đời sự cố, khi sự cố mới được ghi nhận chính thức trong ServiceNow. Sự kiện này được ghi nhận trực tiếp bằng dấu thời gian tạo bản ghi sự cố.
Vì sao điều này quan trọng

Đây là sự kiện bắt đầu chính của quy trình. Phân tích khoảng thời gian từ hoạt động này đến khi xử lý xong là cơ sở để đo tổng thời gian xử lý và mức độ tuân thủ SLA.

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

Dấu thời gian 'sys_created_on' trong bảng 'incident' là dấu thời gian sự kiện được ghi nhận trực tiếp cho hoạt động này.

Thu thập

Dùng dấu thời gian 'sys_created_on' trong bản ghi sự cố.

Loại sự kiện explicit
Chờ người dùng xác nhận
Sự cố đang ở trạng thái chờ người dùng xác nhận giải pháp đề xuất có hiệu quả hay không. Trạng thái này thường được suy ra từ một trạng thái cụ thể như 'Awaiting User Info' sau khi sự cố được xử lý xong.
Vì sao điều này quan trọng

Trạng thái này có thể trở thành điểm nghẽn đáng kể nếu người dùng phản hồi chậm. Đo thời gian ở bước này giúp xác định khoảng trống trong trao đổi và cơ hội tự động đóng sự cố.

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

Suy ra từ bảng 'sys_audit' bằng cách xác định sự cố chuyển sang một trạng thái chờ cụ thể sau khi được xử lý xong. Tên trạng thái có thể được tùy chỉnh, chẳng hạn như 'Awaiting Caller'.

Thu thập

Xác định dấu thời gian khi 'state' chuyển sang giá trị cho biết đang chờ người dùng cung cấp thông tin.

Loại sự kiện inferred
Mở lại sự cố
Xảy ra khi người dùng báo rằng vấn đề vẫn còn sau khi sự cố được đánh dấu là đã xử lý xong. Có thể suy ra sự kiện này khi trạng thái sự cố chuyển từ 'Resolved' trở lại trạng thái đang xử lý như 'In Progress'.
Vì sao điều này quan trọng

Sự cố được mở lại cho thấy cách xử lý trước đó chưa hiệu quả và phát sinh công việc phải làm lại. Theo dõi hoạt động này rất quan trọng để đo chất lượng xử lý và tỷ lệ khắc phục ngay lần đầu.

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

Suy ra từ bảng 'sys_audit' bằng cách phát hiện trường 'state' chuyển từ 'Resolved' trở lại trạng thái đang xử lý như 'In Progress' hoặc 'Assigned'.

Thu thập

Xác định dấu thời gian khi 'state' chuyển từ 'Resolved' sang một trạng thái đang xử lý.

Loại sự kiện inferred
Sự cố được giao cho nhân viên hỗ trợ
Đại diện cho thời điểm một nhân viên cụ thể trong nhóm hỗ trợ tiếp nhận xử lý sự cố. Hoạt động này được ghi nhận bằng cách theo dõi các thay đổi ở trường 'assigned_to'.
Vì sao điều này quan trọng

Thông tin này cho thấy chi tiết khối lượng công việc của từng nhân viên và tỷ lệ xử lý ngay từ lần tiếp xúc đầu tiên. Qua đó, bạn có thể biết sự cố phải chờ bao lâu sau khi được giao cho nhóm mới bắt đầu được xử lý.

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

Suy ra từ bảng 'sys_audit' bằng cách theo dõi thời điểm trường 'assigned_to' trong bảng 'incident' được điền hoặc thay đổi.

Thu thập

Dùng dấu thời gian trong nhật ký kiểm tra cho các thay đổi ở trường 'assigned_to'.

Loại sự kiện inferred
Sự cố được liên kết với vấn đề
Hoạt động này diễn ra khi sự cố được liên kết chính thức với một bản ghi vấn đề, cho biết sự cố thuộc về một vấn đề lớn hơn, có nguyên nhân sâu xa. Có thể suy ra sự kiện này khi trường 'problem_id' trong bản ghi sự cố được điền.
Vì sao điều này quan trọng

Liên kết sự cố với vấn đề là bước quan trọng để chuyển từ xử lý sự cố bị động sang phân tích nguyên nhân gốc rễ chủ động. Thông tin này hỗ trợ bảng điều khiển 'Số sự cố tái diễn'.

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

Suy ra bằng cách phát hiện thời điểm trường tham chiếu 'problem_id' trong bảng 'incident' được điền giá trị.

Thu thập

Xác định dấu thời gian trong nhật ký kiểm tra khi trường 'problem_id' được điền.

Loại sự kiện inferred
Sự cố được nâng mức ưu tiên
Xảy ra khi mức ưu tiên hoặc mức độ nghiêm trọng của sự cố tăng lên, thường đòi hỏi phản hồi nhanh hơn hoặc cần tài nguyên khác. Có thể suy ra sự kiện này bằng cách phát hiện giá trị trong trường 'priority' tăng lên.
Vì sao điều này quan trọng

Việc nâng mức ưu tiên thường cho thấy sự cố nghiêm trọng hơn dự kiến ban đầu hoặc sắp vi phạm SLA. Phân tích các sự kiện này giúp hiểu rõ những trường hợp ngoại lệ trong quy trình.

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

Suy ra từ bảng 'sys_audit' bằng cách xác định trường 'priority' thay đổi sang giá trị có mức độ khẩn cấp cao hơn.

Thu thập

Phát hiện khi giá trị trường 'priority' tăng lên (ví dụ: từ '3 - Moderate' thành '2 - High').

Loại sự kiện inferred
Sự cố được phân loại
Đại diện cho bước phân loại ban đầu của sự cố, khi các trường như Category, Subcategory và Priority được thiết lập. Sự kiện này thường được suy ra từ nhật ký kiểm tra khi các trường này được điền lần đầu hoặc cập nhật ngay sau khi tạo sự cố.
Vì sao điều này quan trọng

Phân loại chính xác rất quan trọng để điều phối và xác định mức ưu tiên phù hợp. Theo dõi hoạt động này giúp phân tích tỷ lệ phân loại lại và ảnh hưởng của việc đó đến thời gian xử lý.

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

Suy ra từ bảng 'sys_audit' bằng cách xác định lần thay đổi đầu tiên đối với các trường như 'category', 'subcategory' hoặc 'priority' của từng sự cố.

Thu thập

Xác định dấu thời gian của lần cập nhật đầu tiên đối với các trường phân loại trong nhật ký kiểm tra.

Loại sự kiện inferred
Thêm bình luận hỗ trợ
Nhân viên hỗ trợ thêm ghi chú công việc hoặc bình luận hiển thị với người dùng. Đây là sự kiện được ghi nhận trực tiếp trong luồng hoạt động của sự cố.
Vì sao điều này quan trọng

Theo dõi hoạt động trao đổi và điều tra của nhóm hỗ trợ. Phân tích tần suất và thời điểm đăng bình luận giúp hiểu rõ hơn quá trình điều tra.

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

Ghi nhận từ bảng 'sys_journal_field', nơi lưu các mục trong trường 'work_notes' và 'comments' của bảng 'incident'.

Thu thập

Dùng dấu thời gian tạo các mục nhật ký có element là 'work_notes' hoặc 'comments'.

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ừ Problem Management trong ServiceNow

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

Mẫu này cung cấp những gì bạn cần để bắt đầu hành trình process mining cho quy trình quản lý incident. Bắt đầu cải thiện quy trình xử lý incident ngay hôm nay.

Xử lý incident nhanh hơn: nâng cao hiệu quả ServiceNow ngay hôm nay

Giảm MTTR 35% trong ServiceNow. Xác định vấn đề, cải thiện mức độ hài lòng.

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

Không cần thẻ tín dụng. Bắt đầu tối ưu hóa chỉ trong vài phút.