Mẫu dữ liệu quản lý yêu cầu dịch vụ

ServiceNow
Mẫu dữ liệu quản lý yêu cầu dịch vụ

Mẫu dữ liệu quản lý yêu cầu dịch vụ

Mẫu dữ liệu này giúp bạn bắt đầu process mining cho quy trình quản lý yêu cầu dịch vụ dễ dàng hơn. Mẫu hướng dẫn rõ những thuộc tính cần thu thập, hoạt động quan trọng cần theo dõi và cách trích xuất dữ liệu phù hợp với ServiceNow. Sử dụng mẫu này giúp bạn thu thập đủ dữ liệu cần thiết để phân tích chính xác và cải tiến hiệu quả.
  • Các thuộc tính nên thu thập
  • Hoạt động chính cần theo dõi để khám phá quy trình
  • Hướng dẫn trích xuất dữ liệu từng bước
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 của quy trình quản lý yêu cầu dịch vụ

Đâ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ý yêu cầu dịch vụ.
5 Bắt buộc 6 Nên có 10 Không bắt buộc
Tên Mô tả
Hoạt động
ActivityName
Tên sự kiện hoặc tác vụ cụ thể xảy ra trong vòng đời yêu cầu dịch vụ.
Mô tả

Thuộc tính Hoạt động ghi lại tên của từng bước hoặc lần thay đổi trạng thái trong quy trình yêu cầu dịch vụ. Ví dụ: 'Tạo yêu cầu', 'Phê duyệt yêu cầu', 'Phân công cho nhân viên xử lý' hoặc 'Đóng yêu cầu'.

Phân tích các hoạt động này giúp trực quan hóa luồng quy trình, xác định các lộ trình phổ biến và phát hiện sai lệch so với quy trình chuẩn. Đây là nền tảng để hiểu thực tế diễn ra như thế nào trong quá trình xử lý yêu cầu.

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

Đây là thuộc tính bắt buộc, xác định các bước trên sơ đồ quy trình. Thuộc tính này là nền tảng cho mọi hoạt động phân tích quy trình, bao gồm tìm điểm nghẽn, vòng lặp làm lại và vấn đề về tuân thủ.

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

Được xác định từ các thay đổi trong trường 'State' hoặc 'Stage' ở những bảng như 'sc_request' hoặc 'sc_req_item', hoặc từ lịch sử kiểm tra (sys_audit).

Ví dụ
Tạo yêu cầu dịch vụPhân công yêu cầu cho nhómYêu cầu dịch vụ được xử lý xongYêu cầu người dùng cung cấp thông tin
Service Request ID
ServiceRequestID
Mã định danh duy nhất của từng bản ghi yêu cầu dịch vụ.
Mô tả

Service Request ID là khóa chính, giúp nhận diện duy nhất từng yêu cầu dịch vụ do người dùng hoặc hệ thống gửi. Mã này liên kết mọi sự kiện tiếp theo, từ lúc ghi nhận ban đầu đến khi đóng yêu cầu. Trong process mining, mã này cần thiết để dựng lại toàn bộ hành trình của từng yêu cầu và phân tích vòng đời của yêu cầu đó.

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

Đây là Case ID bắt buộc. Mã này liên kết mọi hoạt động liên quan thành một phiên bản quy trình, cho phép phân tích luồng quy trình, các biến thể và thời gian xử lý.

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

Bảng ServiceNow Request [sc_request], trường 'number'.

Ví dụ
REQ0010001REQ0010025REQ0010112
Thời gian bắt đầu
EventTime
Dấu thời gian cho biết một hoạt động hoặc sự kiện bắt đầu khi nào.
Mô tả

Thuộc tính này ghi lại chính xác ngày giờ từng hoạt động trong quy trình yêu cầu dịch vụ diễn ra. Dữ liệu này cung cấp trình tự thời gian của các sự kiện để tạo sơ đồ quy trình và thực hiện các phân tích theo thời gian.

Dấu thời gian chính xác rất quan trọng để tính thời gian xử lý, thời gian chờ và thời lượng xử lý. Nhờ dữ liệu này, bạn có thể xác định điểm nghẽn, trường hợp vi phạm SLA và xu hướng hiệu suất theo thời gian.

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

Đây là dấu thời gian bắt buộc để sắp xếp sự kiện đúng thứ tự. Dữ liệu này là cơ sở cho mọi phân tích hiệu suất và thời lượng, bao gồm tính thời gian xử lý và xác định điểm nghẽn.

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

Thường nằm trong các trường 'sys_updated_on' hoặc 'sys_created_on' của bảng ServiceNow liên quan, chẳng hạn như sc_request, sc_task, hoặc trong lịch sử kiểm tra (sys_audit).

Ví dụ
2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
Hệ thống nguồn
SourceSystem
Hệ thống nơi dữ liệu được tạo ra.
Mô tả

Thuộc tính này xác định hệ thống nguồn của dữ liệu, trong trường hợp này là ServiceNow. Thuộc tính này hữu ích khi kết hợp dữ liệu từ nhiều hệ thống để có cái nhìn tổng thể về quy trình.

Khi chỉ phân tích dữ liệu từ một nguồn, thuộc tính này vẫn cung cấp bối cảnh quan trọng và hỗ trợ quản trị dữ liệu. Nhờ đó, người dùng luôn biết dữ liệu đang phân tích đến từ đâu.

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

Cung cấp siêu dữ liệu cần thiết cho việc quản trị, truy xuất nguồn gốc và xác định bối cảnh dữ liệu, đặc biệt khi kết hợp dữ liệu từ nhiều hệ thống doanh nghiệ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 và chuyển đổi dữ liệu.

Ví dụ
ServiceNow
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
Dấu thời gian của lần làm mới hoặc trích xuất dữ liệu gần nhất.
Mô tả

Thuộc tính này cho biết ngày giờ dữ liệu được trích xuất lần gần nhất từ hệ thống nguồn và tải vào công cụ process mining. Nhờ đó, bạn biết dữ liệu đang phân tích được cập nhật đến thời điểm nào.

Chuyên viên phân tích dùng thông tin này để kiểm tra dữ liệu có mới nhất hay không. Đây là yếu tố quan trọng khi theo dõi vận hành và đưa ra quyết định kịp thời. Thông tin này cũng giúp bạn hiểu rõ mức độ cập nhật của các kết quả phân tích.

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

Giúp người dùng biết dữ liệu mới đến đâu, yếu tố quan trọng để tin cậy kết quả phân tích và đưa ra quyết định kịp thời dựa trên dữ liệu.

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

Đây là trường siêu dữ liệu được thêm trong quá trình nạp dữ liệu, thể hiện dấu thời gian hoàn tất tác vụ ETL.

Ví dụ
2023-10-27T04:00:00Z
Danh mục
Category
Phân loại chính của yêu cầu dịch vụ, chẳng hạn như phần cứng hoặc phần mềm.
Mô tả

Danh mục giúp phân loại yêu cầu dịch vụ ở cấp tổng quan. Thông tin này thường được dùng để chuyển yêu cầu đến đúng nhóm và thống kê các loại yêu cầu được gửi.

Trong process mining, Danh mục là thuộc tính hữu ích để lọc và phân tích theo chiều dữ liệu. Chuyên viên phân tích có thể so sánh luồng quy trình, thời gian xử lý và tỷ lệ tự động hóa giữa các loại yêu cầu, từ đó phát hiện những khác biệt khó thấy khi chỉ xem dữ liệu tổng hợp. Ví dụ, quy trình xử lý yêu cầu “Phần cứng” có thể khác hẳn quy trình xử lý yêu cầu “Phần mềm”.

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

Giúp phân nhóm và so sánh quy trình giữa các loại dịch vụ, qua đó xác định vấn đề và cơ hội cải tiến riêng cho từng danh mục.

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

Bảng ServiceNow Request Item [sc_req_item], thường lấy từ danh mục Catalog Item [sc_cat_item] liên quan.

Ví dụ
Phần cứngPhần mềmYêu cầu cấp quyền truy cậpMạng
Đạt SLA
MadeSLA
Giá trị đúng/sai cho biết yêu cầu dịch vụ có được xử lý trong thời hạn cam kết dịch vụ hay không.
Mô tả

Thuộc tính này cho biết yêu cầu dịch vụ có đáp ứng thời hạn xử lý theo Thỏa thuận mức dịch vụ (SLA) đã quy định hay không. Đây là chỉ số kết quả quan trọng, đo trực tiếp hiệu suất dịch vụ so với cam kết.

Phân tích thuộc tính này giúp tính KPI Tỷ lệ đáp ứng SLA. Bạn cũng có thể dùng thuộc tính này làm chiều phân tích để so sánh đường đi của các yêu cầu đáp ứng SLA với các yêu cầu vi phạm SLA, qua đó tìm ra những mẫu hoặc hoạt động thường dẫn đến việc không đạt SLA. Đây là cơ sở cần thiết để chủ động theo dõi rủi ro và liên tục cải thiện dịch vụ.

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

Đo trực tiếp hiệu suất so với cam kết dịch vụ, đồng thời hỗ trợ phân tích nguyên nhân gốc rễ của các trường hợp vi phạm SLA bằng cách so sánh các trường hợp đạt và không đạt.

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

Bảng ServiceNow Task SLA [task_sla], trường 'has_breached'. Cần đảo ngược giá trị này, ví dụ: MadeSLA = NOT has_breached.

Ví dụ
truefalse
Mức độ ưu tiên
Priority
Mức độ ưu tiên của yêu cầu dịch vụ, yếu tố ảnh hưởng đến mức độ khẩn cấp.
Mô tả

Mức độ ưu tiên phân loại tầm quan trọng và tính khẩn cấp tương đối của yêu cầu dịch vụ. Mức này thường được xác định dựa trên tác động và mức độ khẩn cấp, giúp nhân viên biết yêu cầu nào cần xử lý trước.

Phân tích dữ liệu theo mức độ ưu tiên giúp bạn biết yêu cầu ưu tiên cao có được xử lý nhanh hơn yêu cầu ưu tiên thấp hay không. Bạn có thể lọc bảng điều khiển để kiểm tra việc đáp ứng SLA cho các yêu cầu quan trọng và đánh giá hệ thống ưu tiên có hoạt động hiệu quả không.

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

Cho phép phân nhóm yêu cầu để kiểm tra xem các yêu cầu ưu tiên cao có được xử lý nhanh hơn hay không. Đây là yếu tố quan trọng trong phân tích SLA và phân bổ tài nguyên.

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

Bảng ServiceNow Request [sc_request] hoặc Request Item [sc_req_item], trường 'priority'.

Ví dụ
1 - Khẩn cấp2 - Cao3 - Trung bình4 - Thấp
Người được phân công
AssignedTo
Người dùng chịu trách nhiệm xử lý yêu cầu dịch vụ tại một thời điểm nhất định.
Mô tả

Thuộc tính này xác định nhân viên hoặc kỹ thuật viên cụ thể được giao xử lý yêu cầu dịch vụ. Giá trị thay đổi khi yêu cầu được bàn giao giữa những người khác nhau.

Phân tích trường 'Assigned To' 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à tác động của việc bàn giao đến thời gian xử lý. Thuộc tính này giúp trả lời các câu hỏi về mức sử dụng tài nguyên và xác định cơ hội đào tạo hoặc làm rõ quy trình để giảm số lần phân công lại.

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

Cho phép phân tích khối lượng công việc, hiệu suất và việc bàn giao giữa các nhân viên. Đây là thông tin cần thiết để quản lý tài nguyên và xác định điểm nghẽn liên quan đến từng người.

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

Bảng ServiceNow Request Item [sc_req_item] hoặc Catalog Task [sc_task], trường 'assigned_to'.

Ví dụ
Beth AnglinDavid LooHoward Johnson
Nhóm được phân công
AssignmentGroup
Nhóm chịu trách nhiệm xử lý yêu cầu dịch vụ.
Mô tả

Nhóm được phân công là đội chịu trách nhiệm xử lý yêu cầu dịch vụ ở một giai đoạn cụ thể, chẳng hạn như 'Bộ phận hỗ trợ dịch vụ', 'Vận hành mạng' hoặc 'Quản trị cơ sở dữ liệu'. Đây là thuộc tính quan trọng để phân tích luồng quy trình giữa các bộ phận.

Theo dõi thay đổi của nhóm được phân công giúp tổ chức trực quan hóa việc bàn giao giữa các nhóm, đo thời gian yêu cầu nằm trong hàng đợi của từng nhóm và xác định sự phụ thuộc hoặc chậm trễ giữa các nhóm. Đây là thông tin quan trọng để cải thiện phối hợp liên phòng ban.

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

Theo dõi cách phân bổ công việc giữa các nhóm, làm rõ các lần bàn giao và giúp xác định điểm nghẽn hoặc vấn đề hiệu suất của từng nhóm.

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

Bảng ServiceNow Request Item [sc_req_item] hoặc Catalog Task [sc_task], trường 'assignment_group'.

Ví dụ
Bộ phận hỗ trợ dịch vụHỗ trợ CNTT cấp 2Cấp phát thiết bị
Trạng thái
State
Trạng thái hiện tại của yêu cầu dịch vụ trong quá trình xử lý.
Mô tả

Thuộc tính Trạng thái cho biết yêu cầu dịch vụ đang ở giai đoạn nào trong vòng đời, chẳng hạn như 'Open', 'Work in Progress', 'Pending' hoặc 'Closed'. Các thay đổi trong trường này thường được dùng để tạo hoạt động trên sơ đồ quy trình.

Phân tích trạng thái rất quan trọng để hiểu yêu cầu mất bao lâu ở từng trạng thái, đặc biệt là trạng thái chờ. Nhờ đó, bạn có thể xác định hàng đợi và chậm trễ, chẳng hạn như thời gian chờ 'Awaiting User Information', vốn thường kéo dài thời gian xử lý.

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

Cho biết trạng thái của yêu cầu tại từng thời điểm, giúp phân tích thời gian chờ, hàng đợi và thời lượng của từng giai đoạn trong quy trình.

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

Bảng ServiceNow Request [sc_request] hoặc Request Item [sc_req_item], trường 'state' hoặc 'stage'.

Ví dụ
MởĐang xử lýChờ thông tin từ người dùngĐã đóng hoàn tất
Có làm lại
IsRework
Cờ được tính để cho biết một hoạt động có lặp lại hoạt động trước đó trong cùng một trường hợp hay không.
Mô tả

Cờ đúng/sai này được tính để xác định các vòng lặp làm lại trong một yêu cầu dịch vụ. Cờ được đặt thành 'true' nếu cùng một hoạt động đã xảy ra trước đó trong cùng trường hợp. Ví dụ: yêu cầu được giao cho cùng một nhóm hai lần hoặc người dùng bị yêu cầu cung cấp thông tin nhiều lần.

Thuộc tính này rất cần thiết cho bảng điều khiển Bàn giao giữa nhân viên và sự cố làm lại, cũng như KPI Tỷ lệ yêu cầu phải làm lại. Thuộc tính này giúp hiển thị và định lượng trực tiếp các vòng lặp kém hiệu quả trong quy trình, vốn thường bị che khuất trong dữ liệu tổng hợp.

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

Đánh dấu và định lượng trực tiếp công việc phải làm lại trong quy trình, giúp phân tích nguyên nhân và tác động của các vòng lặp kém hiệu quả làm tăng chi phí và thời gian xử lý.

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

Được tính trong quá trình chuyển đổi dữ liệu bằng cách kiểm tra xem tên hoạt động đó đã xuất hiện trước đó trong cùng trường hợp hay chưa.

Ví dụ
falsetrue
Có tự động hóa
IsAutomated
Cờ cho biết hoạt động do hệ thống hoặc quy trình tự động thực hiện.
Mô tả

Thuộc tính đúng/sai này phân biệt hoạt động do nhân viên thực hiện với hoạt động do hệ thống tự động thực hiện, chẳng hạn qua workflow hoặc tích hợp. Ví dụ, bước “Gửi yêu cầu phê duyệt” có thể được tự động hóa, còn bước “Giao yêu cầu cho nhân viên xử lý” có thể cần thao tác thủ công.

Phân tích thuộc tính này giúp đo lường và tăng mức độ tự động hóa trong quy trình xử lý yêu cầu dịch vụ. Thuộc tính này cũng giúp xác định những tác vụ thủ công tốn nhiều thời gian nhất và có thể tự động hóa trong tương lai, qua đó nâng cao hiệu quả và giảm chi phí.

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

Giúp đo tỷ lệ tự động hóa và xác định cơ hội tự động hóa các tác vụ thủ công, từ đó nâng cao hiệu quả và giảm chi phí vận hành.

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

Được xác định bằng cách kiểm tra xem người dùng thực hiện hành động, chẳng hạn 'sys_updated_by', có phải là tài khoản hệ thống hoặc tài khoản tích hợp được chỉ định hay không.

Ví dụ
truefalse
Điểm hài lòng
SatisfactionScore
Điểm đánh giá mức độ hài lòng do người yêu cầu gửi khi đóng yêu cầu.
Mô tả

Thuộc tính này ghi nhận điểm hài lòng, thường theo thang điểm từ 1 đến 5, do người dùng cuối gửi sau khi yêu cầu dịch vụ được xử lý. Đây là thước đo trực tiếp về chất lượng dịch vụ theo cảm nhận của người dùng.

Dữ liệu này rất cần thiết cho bảng điều khiển Phân tích tác động đến mức độ hài lòng của khách hàng. Bạn có thể đối chiếu trực tiếp các chỉ số quy trình như thời gian xử lý, khối lượng làm lại và số lần bàn giao với trải nghiệm thực tế của khách hàng. Nhờ đó, bạn có thể chứng minh lợi ích kinh doanh của việc cải tiến quy trình bằng cách liên kết hiệu quả vận hành với kết quả dành cho khách hàng.

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

Liên kết trực tiếp các chỉ số hiệu suất quy trình với kết quả dành cho khách hàng, giúp định lượng tác động của những điểm kém hiệu quả trong quy trình đến trải nghiệm người dùng.

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

Thường nằm trong bảng Survey [asmt_assessment_instance] liên quan, được liên kết với yêu cầu ban đầu.

Ví dụ
5431
Kênh
ContactType
Cách người yêu cầu gửi yêu cầu dịch vụ.
Mô tả

Contact Type, hay kênh gửi yêu cầu, cho biết yêu cầu dịch vụ được khởi tạo bằng cách nào. Các kênh phổ biến gồm cổng dịch vụ, email, điện thoại hoặc cảnh báo tự động.

Thông tin về kênh rất quan trọng khi phân tích những khác biệt trong quy trình có thể xuất phát từ cách gửi yêu cầu. Chẳng hạn, yêu cầu gửi qua cổng thông tin có thể có cấu trúc rõ ràng và được tự động hóa nhiều hơn, nên xử lý nhanh hơn yêu cầu gửi qua email. Phân tích này giúp khuyến khích sử dụng các kênh hiệu quả hơn.

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

Giúp xác định các kênh gửi yêu cầu khác nhau ảnh hưởng thế nào đến hiệu quả quy trình, mức độ tự động hóa và thời gian xử lý, từ đó định hướng cải thiện tương tác với người dùng.

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

Bảng ServiceNow Request [sc_request] hoặc Interaction [interaction]. Trường này thường có tên 'contact_type'.

Ví dụ
Cổng thông tinEmailĐiện thoạiTự phục vụ
Mã xử lý
ResolutionCode
Mã phân loại kết quả xử lý cuối cùng của yêu cầu dịch vụ.
Mô tả

Mã xử lý phân loại theo cấu trúc cách yêu cầu dịch vụ được giải quyết. Ví dụ: “Đã xử lý tự động”, “Lỗi người dùng” hoặc “Không còn cần thiết”.

Thuộc tính này rất cần thiết cho bảng điều khiển Phân tích nguyên nhân gốc rễ gây chậm trễ. Khi đối chiếu mã xử lý với thời gian xử lý dài hoặc tỷ lệ làm lại cao, chuyên viên phân tích có thể xác định vấn đề mang tính hệ thống. Ví dụ, nếu các yêu cầu có mã “Thiếu thông tin” thường xuyên mất nhiều thời gian, có thể khâu thu thập dữ liệu ban đầu đang gặp vấn đề.

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

Cung cấp dữ liệu có cấu trúc về kết quả xử lý, giúp phân tích nguyên nhân gốc rễ của tình trạng chậm trễ, làm lại và các điểm kém hiệu quả khác trong quy trình.

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

Bảng ServiceNow Request Item [sc_req_item] hoặc bảng tác vụ liên quan. Trường này thường có tên 'close_code' hoặc 'resolution_code'.

Ví dụ
Đã giải quyết (vĩnh viễn)Chưa giải quyết (không thể tái hiện)Đã hoàn thành yêu cầuNgười dùng đã hủy
Người mở yêu cầu
OpenedBy
Người đầu tiên gửi yêu cầu dịch vụ.
Mô tả

Thuộc tính này xác định người dùng tạo yêu cầu dịch vụ. Người này thường cũng là người cần dịch vụ, nhưng có thể là quản lý, người được ủy quyền hoặc hệ thống tự động.

Phân tích yêu cầu theo người mở yêu cầu hoặc phòng ban của họ giúp phát hiện các mẫu, chẳng hạn một nhóm người dùng thường gửi yêu cầu phức tạp hoặc có vấn đề. Từ đó, bạn có thể tổ chức đào tạo phù hợp hoặc bổ sung bài viết trong kho kiến thức để khuyến khích người dùng tự phục vụ.

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

Giúp phân tích mẫu yêu cầu theo người dùng, phòng ban hoặc vai trò, từ đó định hướng đào tạo và cải tiến quy trình phù hợp.

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

Bảng ServiceNow Request [sc_request], trường 'opened_by'.

Ví dụ
Abel TuterFred LuddyDon Goodliffe
Số lần mở lại
ReopenCount
Số lần yêu cầu dịch vụ được mở lại sau khi đã xử lý xong.
Mô tả

Thuộc tính này đếm số lần yêu cầu dịch vụ được chuyển từ trạng thái đã xử lý hoặc đã đóng về trạng thái đang mở hoặc đang xử lý. Nếu số lần lớn hơn 0, lần xử lý ban đầu chưa thành công.

Chỉ số này phản ánh trực tiếp khối lượng làm lại và là thành phần quan trọng của KPI Tỷ lệ xử lý thành công ngay lần đầu. Số lần mở lại cao thường cho thấy chất lượng xử lý chưa tốt, yêu cầu chưa được đáp ứng đầy đủ hoặc nhu cầu của người dùng chưa được hiểu đúng. Những vấn đề này làm giảm hiệu quả quy trình và khiến người dùng không hài lòng.

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

Đo khối lượng làm lại và chất lượng xử lý. Số lần mở lại cao cho thấy quy trình kém hiệu quả, tỷ lệ xử lý thành công ngay lần đầu thấp và mức độ hài lòng của khách hàng giảm.

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

Bảng ServiceNow Request [sc_request] hoặc Request Item [sc_req_item], trường 'reopen_count'.

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

Thời gian kết thúc đánh dấu lúc một hoạt động hoàn tất. Đây là dấu thời gian của hoạt động tiếp theo trong chuỗi, dùng để xác định thời lượng của hoạt động hiện tại. Thuộc tính này cần thiết để tính thời gian thực hiện từng bước trong quy trình.

Bằng cách so sánh thời gian bắt đầu và thời gian kết thúc của một hoạt động, chuyên viên phân tích có thể tính thời gian xử lý và thời gian chờ. Đây là cơ sở để xác định điểm nghẽn, đo hiệu quả sử dụng tài nguyên và theo dõi hiệu suất so với các mục tiêu về thời gian.

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

Thuộc tính này cần thiết để tính thời lượng của từng hoạt động, một phần cốt lõi trong phân tích hiệu suất, xác định điểm nghẽn và nghiên cứu mức sử dụng tài nguyên.

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

Đây là thuộc tính được tính toán, lấy 'StartTime' của sự kiện tiếp theo trong trường hợp.

Ví dụ
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
Thời gian xử lý yêu cầu
CaseCycleTime
Tổng thời gian từ khi tạo đến khi đóng yêu cầu dịch vụ.
Mô tả

Thời gian xử lý yêu cầu là chỉ số được tính từ thời điểm ghi nhận sự kiện đầu tiên đến thời điểm ghi nhận sự kiện cuối cùng. Chỉ số này thể hiện toàn bộ thời gian xử lý từ đầu đến cuối theo góc nhìn của khách hàng.

Đây là KPI chính để đánh giá hiệu quả tổng thể của quy trình. Chỉ số này thường xuất hiện trên các bảng điều khiển tổng quan để theo dõi hiệu suất so với mục tiêu và phân tích xu hướng theo thời gian. Bạn có thể phân tích theo các chiều như Danh mục hoặc Mức độ ưu tiên để xác định loại yêu cầu nào mất nhiều thời gian nhất.

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

Đây là KPI quan trọng để đo hiệu suất quy trình từ đầu đến cuối. Chỉ số này cần thiết cho việc theo dõi tổng quan, so sánh hiệu suất và xác định cơ hội cải tiến.

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

Được tính bằng cách lấy 'EndTime' lớn nhất trừ 'StartTime' nhỏ nhất cho từng 'ServiceRequestID' duy nhất.

Ví dụ
2 10:30:000 04:15:2210 00:05:00
Xử lý thành công ngay lần đầu
IsFirstPassResolution
Cờ cho biết yêu cầu có được xử lý thành công ngay lần đầu mà không cần mở lại hay không.
Mô tả

Thuộc tính được tính này là cờ đúng/sai, chỉ có giá trị 'true' nếu yêu cầu dịch vụ được xử lý và đóng mà không bị mở lại lần nào. Đây là chỉ số quan trọng về chất lượng và hiệu quả xử lý của bộ phận hỗ trợ dịch vụ.

Chỉ số này hỗ trợ trực tiếp KPI Tỷ lệ xử lý thành công ngay lần đầu. Tỷ lệ cao là điều đáng mong muốn vì cho thấy dịch vụ hiệu quả, chất lượng tốt và góp phần nâng cao mức độ hài lòng của khách hàng. Phân tích các trường hợp không được xử lý thành công ngay lần đầu có thể giúp tìm ra nguyên nhân gốc rễ như thiếu đào tạo, tài liệu chưa đầy đủ hoặc chẩn đoán ban đầu chưa chính xác.

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

Đo chất lượng và hiệu quả của quy trình xử lý. Tỷ lệ xử lý thành công ngay lần đầu thấp cho thấy có vấn đề tiềm ẩn dẫn đến phải làm lại và khiến khách hàng không hài lòng.

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

Được tính ở cấp trường hợp. Một trường hợp được xem là xử lý thành công ngay lần đầu nếu 'ReopenCount' bằng 0.

Ví dụ
truefalse
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ý yêu cầu dịch vụ

Đây là những bước chính và mốc quan trọng cần ghi lại trong nhật ký sự kiện để khám phá quy trình chính xác và xác định điểm nghẽn.
6 Nên có 8 Không bắt buộc
Hoạt động Mô tả
Đóng yêu cầu dịch vụ
Đánh dấu thời điểm kết thúc chính thức của vòng đời yêu cầu dịch vụ. Việc này thường diễn ra tự động sau một khoảng thời gian yêu cầu ở trạng thái 'Resolved', trong thời gian đó người dùng vẫn có thể mở lại yêu cầu.
Vì sao điều này quan trọng

Đây là sự kiện kết thúc thành công chính của quy trình. Bạn cũng có thể phân tích khoảng thời gian từ 'Resolved' đến 'Closed' để hiểu rõ chính sách tự động đóng yêu cầu.

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

Suy ra từ việc trường trạng thái của sc_req_item được cập nhật thành trạng thái đóng cuối cùng, chẳng hạn như 'Closed Complete'. Thay đổi này được ghi trong bảng sys_audit.

Thu thập

Xác định dấu thời gian khi sc_req_item.state chuyển thành 'Closed Complete'.

Loại sự kiện inferred
Phân công yêu cầu cho nhân viên xử lý
Hoạt động này xảy ra khi một nhân viên cụ thể được giao xử lý yêu cầu dịch vụ. Sự kiện được ghi nhận bằng cách theo dõi thay đổi ở trường 'Assigned to' trên yêu cầu hoặc các tác vụ xử lý liên quan.
Vì sao điều này quan trọng

Thông tin này rất quan trọng để đo số lần bàn giao, tính khối lượng công việc của từng nhân viên và phân tích thời gian yêu cầu nằm trong hàng đợi trước khi có người bắt đầu xử lý.

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

Suy ra từ thay đổi ở trường assigned_to trong bảng sc_req_item hoặc sc_task. Lịch sử thay đổi được ghi trong bảng sys_audit.

Thu thập

Theo dõi các thay đổi của trường assigned_to trong sys_audit.

Loại sự kiện inferred
Tạo yêu cầu dịch vụ
Hoạt động này đánh dấu thời điểm bắt đầu vòng đời yêu cầu dịch vụ, được ghi nhận khi người dùng gửi yêu cầu qua danh mục dịch vụ. Hệ thống ghi lại sự kiện tạo bản ghi mới trong bảng sc_req_item (Requested Item).
Vì sao điều này quan trọng

Đây là sự kiện bắt đầu chính của quy trình. Sự kiện này cần thiết để tính tổng thời gian xử lý, phân tích số lượng yêu cầu và thời điểm gửi yêu cầu.

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

Đây là sự kiện được ghi nhận trực tiếp từ dấu thời gian tạo bản ghi (trường sys_created_on) trong bảng sc_req_item.

Thu thập

Dùng dấu thời gian sys_created_on từ bản ghi sc_req_item.

Loại sự kiện explicit
Yêu cầu dịch vụ được xử lý xong
Hoạt động này cho biết nhân viên xử lý đã hoàn tất công việc và đưa ra giải pháp. Sự kiện được ghi nhận khi trạng thái yêu cầu chuyển thành 'Resolved' hoặc trạng thái tương tự.
Vì sao điều này quan trọng

Đây là mốc quan trọng, thường đánh dấu thời điểm dừng tính SLA. Mốc này kết thúc giai đoạn xử lý chủ động và là thành phần chính để tính tổng thời gian xử lý.

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

Suy ra từ việc trường trạng thái của sc_req_item được cập nhật thành 'Resolved' hoặc trạng thái kết thúc tương tự trước khi đóng hẳn yêu cầu. Thay đổi được theo dõi trong bảng sys_audit.

Thu thập

Xác định dấu thời gian khi sc_req_item.state chuyển thành 'Resolved'.

Loại sự kiện inferred
Yêu cầu được phê duyệt
Hoạt động này cho biết yêu cầu đã được phê duyệt chính thức và có thể chuyển sang giai đoạn xử lý. Sự kiện được ghi nhận khi người phê duyệt đánh dấu bản ghi phê duyệt liên quan là 'approved'.
Vì sao điều này quan trọng

Đây là mốc quan trọng đánh dấu việc chuyển từ giai đoạn phê duyệt sang giai đoạn xử lý. Phân tích thời gian để đạt đến bước này giúp làm rõ các chậm trễ trước khi xử lý.

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

Suy ra từ việc trường trạng thái của bản ghi sysapproval_approver liên quan chuyển thành 'approved', sau đó làm thay đổi trạng thái của sc_req_item.

Thu thập

Xác định dấu thời gian khi sysapproval_approver.state chuyển thành 'approved'.

Loại sự kiện inferred
Yêu cầu người dùng cung cấp thông tin
Sự kiện xảy ra khi nhân viên xử lý cần thêm thông tin từ người gửi yêu cầu để tiếp tục. Thường có thể suy ra sự kiện này khi trạng thái yêu cầu chuyển thành 'Awaiting User Info' hoặc trạng thái tương tự.
Vì sao điều này quan trọng

Hoạt động này rất cần thiết cho bảng điều khiển 'Phân tích thời gian chờ thông tin từ người gửi yêu cầu', giúp đo thời gian mất đi khi chờ người dùng cung cấp thông tin.

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

Suy ra từ việc trường trạng thái của sc_req_item chuyển sang trạng thái 'awaiting information' được chỉ định. Thay đổi này được ghi trong bảng sys_audit.

Thu thập

Xác định dấu thời gian khi sc_req_item.state chuyển thành 'Awaiting User Info'.

Loại sự kiện inferred
Có sự tham gia của nhà cung cấp bên ngoài
Đánh dấu việc chuyển yêu cầu dịch vụ hoặc một trong các tác vụ của yêu cầu cho nhà cung cấp bên thứ ba để xử lý. Có thể suy ra sự kiện này từ việc phân công cho nhóm của nhà cung cấp hoặc từ một cờ trên yêu cầu.
Vì sao điều này quan trọng

Hoạt động này cho phép phân tích hiệu quả của nhà cung cấp và tác động đến toàn bộ vòng đời yêu cầu. Đây là thông tin cần thiết cho bảng điều khiển 'Chu kỳ làm việc với nhà cung cấp bên ngoài'.

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

Sự kiện này thường được suy ra. Có thể dựa vào việc assignment_group được đặt thành nhóm của nhà cung cấp hoặc một trường cờ cụ thể được bật trên bản ghi sc_req_item hoặc sc_task.

Thu thập

Xác định thời điểm assignment_group được đổi sang một nhóm nhà cung cấp đã biết.

Loại sự kiện inferred
Gửi yêu cầu phê duyệt
Đánh dấu thời điểm yêu cầu dịch vụ được gửi để quản lý hoặc người được chỉ định khác phê duyệt. Sự kiện này thường được suy ra khi trạng thái yêu cầu chuyển thành 'Pending Approval' hoặc trạng thái tương tự.
Vì sao điều này quan trọng

Theo dõi các bước phê duyệt giúp xác định điểm nghẽn trong quy trình phê duyệt và đo thời gian yêu cầu chờ được duyệt trước khi bắt đầu xử lý.

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

Suy ra từ việc trường trạng thái của sc_req_item chuyển sang giá trị chờ phê duyệt hoặc từ lúc tạo bản ghi tương ứng trong bảng sysapproval_approver. Các thay đổi được ghi trong bảng sys_audit.

Thu thập

Xác định dấu thời gian khi sc_req_item.state chuyển thành 'Pending Approval'.

Loại sự kiện inferred
Hủy yêu cầu
Hoạt động này đánh dấu trạng thái kết thúc của yêu cầu bị hủy trước khi hoàn tất, do người dùng hoặc nhân viên xử lý hủy. Sự kiện được ghi nhận khi trạng thái yêu cầu chuyển thành 'Cancelled' hoặc 'Closed Cancelled'.
Vì sao điều này quan trọng

Đây là sự kiện kết thúc không thành công quan trọng. Phân tích lý do yêu cầu bị hủy giúp làm rõ nhu cầu của người dùng, điểm kém hiệu quả trong quy trình hoặc những thay đổi về ưu tiên kinh doanh.

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

Suy ra từ việc trường trạng thái của sc_req_item được cập nhật thành trạng thái hủy cuối cùng, chẳng hạn như 'Closed Cancelled'. Thay đổi này được ghi trong bảng sys_audit.

Thu thập

Xác định dấu thời gian khi sc_req_item.state chuyển thành 'Cancelled'.

Loại sự kiện inferred
Mở lại yêu cầu
Hoạt động này ghi nhận trường hợp yêu cầu từng được đánh dấu là đã xử lý xong nhưng sau đó chuyển lại trạng thái mở. Sự kiện được suy ra từ việc trạng thái chuyển từ 'Resolved' về 'Work in Progress' hoặc trạng thái tương tự.
Vì sao điều này quan trọng

Đây là chỉ số trực tiếp về việc phải làm lại và rất quan trọng để tính KPI 'Tỷ lệ xử lý thành công ngay lần đầu'. Số lần mở lại cao cho thấy giải pháp chưa tốt hoặc yêu cầu chưa được xử lý đầy đủ.

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

Suy ra từ việc trường trạng thái của sc_req_item chuyển từ trạng thái đã xử lý xong hoặc đã đóng về trạng thái mở hoặc đang xử lý. Thay đổi này được ghi trong sys_audit.

Thu thập

Phát hiện thay đổi trạng thái từ 'Resolved' sang 'Work in Progress' trong sys_audit.

Loại sự kiện inferred
Người dùng cung cấp thông tin
Hoạt động này đánh dấu thời điểm người gửi yêu cầu cung cấp thông tin cần thiết. Sự kiện được suy ra khi yêu cầu chuyển từ trạng thái 'Awaiting User Info' sang trạng thái đang xử lý như 'Work in Progress'.
Vì sao điều này quan trọng

Kết hợp với hoạt động 'Yêu cầu người dùng cung cấp thông tin', hoạt động này giúp đo chính xác thời gian chậm trễ do chờ người dùng và đánh giá hiệu quả trao đổi thông tin.

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

Suy ra từ việc trường trạng thái của sc_req_item chuyển từ trạng thái 'awaiting information' sang trạng thái đang xử lý. Việc này thường xảy ra khi người dùng thêm bình luận hoặc trả lời email.

Thu thập

Xác định dấu thời gian khi trạng thái chuyển từ 'Awaiting User Info' sang 'Work in Progress'.

Loại sự kiện inferred
Phân công yêu cầu cho nhóm
Cho biết yêu cầu dịch vụ đã được giao cho một nhóm hoặc đội xử lý cụ thể. Sự kiện này được suy ra khi phát hiện trường nhóm được phân công thay đổi trên yêu cầu hoặc các tác vụ liên quan.
Vì sao điều này quan trọng

Theo dõi việc phân công nhóm giúp phân tích khối lượng công việc giữa các nhóm và xác định chậm trễ trước khi yêu cầu được chuyển đến đúng nhóm xử lý.

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

Suy ra từ thay đổi ở trường assignment_group trong bảng sc_req_item hoặc sc_task. Lịch sử thay đổi được ghi trong bảng sys_audit.

Thu thập

Theo dõi các thay đổi của trường assignment_group trong sys_audit.

Loại sự kiện inferred
Tạo tác vụ xử lý
Đây là sự kiện tạo một hạng mục công việc hoặc nhiệm vụ cụ thể cần thiết để xử lý yêu cầu dịch vụ. Sự kiện được ghi nhận rõ ràng khi một bản ghi mới được tạo trong bảng Catalog Task.
Vì sao điều này quan trọng

Với các yêu cầu phức tạp, phân tích thời điểm tạo và hoàn tất từng tác vụ giúp bạn thấy rõ hơn quy trình xử lý và vị trí xảy ra chậm trễ.

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

Đây là sự kiện được ghi nhận trực tiếp từ dấu thời gian tạo bản ghi (trường sys_created_on) trong bảng sc_task liên kết với sc_req_item.

Thu thập

Dùng dấu thời gian sys_created_on từ các bản ghi sc_task.

Loại sự kiện explicit
Từ chối yêu cầu
Hoạt động này ghi nhận trường hợp yêu cầu chính thức bị từ chối trong giai đoạn phê duyệt. Đây là một nhánh kết thúc khác, được ghi nhận khi người phê duyệt đánh dấu yêu cầu là 'rejected'.
Vì sao điều này quan trọng

Theo dõi các yêu cầu bị từ chối giúp xác định yêu cầu không hợp lệ hoặc gửi nhầm, vấn đề trong quy trình gửi yêu cầu và các trường hợp ngoại lệ cần phân tích.

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

Suy ra từ việc trường trạng thái của bản ghi sysapproval_approver liên quan chuyển thành 'rejected'. Việc này thường khiến sc_req_item cha chuyển sang trạng thái đóng nhưng chưa hoàn tất.

Thu thập

Xác định dấu thời gian khi sysapproval_approver.state chuyển thành 'rejected'.

Loại sự kiện inferred
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ừ ServiceNow

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

Dùng mẫu này để bắt đầu sáng kiến process mining và cải thiện hiệu quả quản lý yêu cầu dịch vụ. Hãy bắt đầu cải tiến quy trình làm việc ngay hôm nay để xử lý yêu cầu nhanh hơn và nâng cao mức độ hài lòng của khách hàng.

Cải thiện quản lý yêu cầu dịch vụ, bắt đầu ngay hôm nay

Tự động hóa 70% và xử lý yêu cầu dịch vụ nhanh hơn.

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.