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ụ
- Các thuộc tính nên có để phân tích chuyên sâu
- 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ừ hệ thống nguồn
Thuộc tính quản lý yêu cầu dịch vụ
| Tên | Mô tả | ||
|---|---|---|---|
|
Service Request ID
ServiceRequestID
|
Mã định danh duy nhất của từng yêu cầu dịch vụ. | ||
|
Mô tả
Service Request ID xác định duy nhất từng yêu cầu dịch vụ do người dùng hoặc hệ thống gửi. Đây là mã 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, giúp phân tích toàn bộ hành trình của từng yêu cầu dịch vụ.
Vì sao điều này quan trọng
Đây là mã định danh thiết yếu, liên kết mọi hoạt động liên quan thành một phiên bản quy trình duy nhất, cho phép phân tích quy trình từ đầu đến cuối.
Lấy dữ liệu ở đâu
Đây là khóa chính của đối tượng nghiệp vụ Service Request, thường có tên ServiceReqNumber trong bảng ServiceReq.
Ví dụ
SR-0012345SR-0012346SR-0012347
|
|||
|
Tên hoạt động
ActivityName
|
Tên sự kiện hoặc tác vụ diễn ra tại một thời điểm cụ thể trong vòng đời yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này mô tả một bước cụ thể hoặc lần đổi trạng thái trong quy trình yêu cầu dịch vụ, chẳng hạn như 'Gửi yêu cầu để phê duyệt' hoặc 'Giải quyết yêu cầu dịch vụ'. Phân tích trình tự và tần suất hoạt động là bước cơ bản để hiểu luồng quy trình, xác định điểm nghẽn và phát hiện sai lệch so với quy trình chuẩn.
Vì sao điều này quan trọng
Thuộc tính này xác định các bước trên sơ đồ quy trình, giúp trực quan hóa và phân tích luồng quy trình, bao gồm việc tìm công việc phải làm lại, điểm nghẽn và sai lệch.
Lấy dữ liệu ở đâu
Thường được lấy từ các lần đổi trạng thái, mục nhật ký hoặc nội dung mô tả sự kiện trong nhật ký kiểm tra của Ivanti Service Manager.
Ví dụ
Tạo yêu cầu dịch vụPhê duyệt yêu cầuGiải quyết yêu cầu dịch vụĐóng yêu cầu dịch vụ
|
|||
|
Thời điểm sự kiện
EventTime
|
Dấu thời gian cho biết thời điểm một hoạt động hoặc sự kiện cụ thể diễn ra. | ||
|
Mô tả
Thời điểm sự kiện, còn gọi là thời điểm bắt đầu, là ngày giờ chính xác khi một hoạt động được ghi nhận trong hệ thống. Dấu thời gian này rất quan trọng để sắp xếp sự kiện đúng thứ tự và là cơ sở cho mọi phân tích process mining dựa trên thời gian, chẳng hạn như tính thời gian xử lý, thời gian chờ và thời lượng hoạt động.
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 theo trình tự thời gian và tính mọi chỉ số dựa trên thời lượng, vốn rất quan trọng khi phân tích hiệu suất.
Lấy dữ liệu ở đâu
Có thể tìm thấy trong nhật ký kiểm tra, mục nhật ký như Journal.CreatedDateTime hoặc bản ghi thay đổi trạng thái liên kết với Service Request.
Ví dụ
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
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 quy trình. Trong chế độ xem này, giá trị sẽ không đổi, cho biết toàn bộ dữ liệu đến từ Ivanti Service Manager. Điều này rất quan trọng khi dữ liệu được gộp từ nhiều hệ thống, giúp xác định rõ nguồn gốc và ngữ cảnh của dữ liệu.
Vì sao điều này quan trọng
Thuộc tính này cung cấp thông tin quan trọng về nguồn gốc dữ liệu, đảm bảo kết quả phân tích được gắn đúng với hệ thống nguồn, nhất là 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 trong quá trình trích xuất dữ liệu để ghi rõ nguồn gốc của tập dữ liệu.
Ví dụ
Ivanti Service Manager
|
|||
|
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 dữ liệu gần nhất từ hệ thống nguồn. | ||
|
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ừ Ivanti Service Manager. Thông tin này giúp bạn biết dữ liệu đang phân tích còn mới đến đâu, khoảng thời gian nào được bao quát và khi nào dự kiến có bản cập nhật tiếp theo.
Vì sao điều này quan trọng
Cho biết dữ liệu được cập nhật đến thời điểm nào, yếu tố quan trọng để đưa ra quyết định dựa trên thông tin hiệu suất quy trình mới nhất.
Lấy dữ liệu ở đâu
Giá trị này được tạo và ghi vào tập dữ liệu khi trích xuất dữ liệu.
Ví dụ
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
|
|||
|
Dấu thời gian giải quyết
ResolutionDateTime
|
Ngày và giờ yêu cầu dịch vụ được chính thức giải quyết. | ||
|
Mô tả
Đây là thuộc tính ở cấp hồ sơ, ghi lại thời điểm cuối cùng dịch vụ được cung cấp hoặc sự cố được khắc phục, trước khi yêu cầu chính thức đóng. Dấu thời gian này là mốc kết thúc chính để tính tổng thời gian xử lý yêu cầu dịch vụ từ đầu đến cuối. Đây cũng là thành phần quan trọng để đo hiệu quả chung của quy trình và mức độ đáp ứng SLA.
Vì sao điều này quan trọng
Xác định mốc kết thúc để tính thời gian xử lý chính của quy trình, một KPI quan trọng về hiệu quả cung cấp dịch vụ.
Lấy dữ liệu ở đâu
Trường dấu thời gian riêng trên đối tượng Service Request, thường có tên “ResolvedDateTime” hoặc tương tự.
Ví dụ
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
|
|||
|
Hạn SLA
SLADeadline
|
Thời điểm dự kiến phải giải quyết xong yêu cầu dịch vụ. | ||
|
Mô tả
Hạn SLA là ngày giờ yêu cầu dịch vụ cần được giải quyết để đáp ứng Thỏa thuận mức dịch vụ. Hạn này thường được xác định dựa trên các yếu tố như mức độ ưu tiên và loại yêu cầu. So sánh thời điểm giải quyết thực tế với hạn này là cơ sở để đo mức độ đáp ứng SLA.
Vì sao điều này quan trọng
Đây là mốc chuẩn để so sánh với hiệu suất thực tế, hỗ trợ trực tiếp việc tính tỷ lệ đáp ứng SLA và xác định các yêu cầu có nguy cơ trễ hạn.
Lấy dữ liệu ở đâu
Thông tin này thường được tính trong Ivanti và lưu ở các trường liên quan đến Thỏa thuận mức dịch vụ hoặc Gói dịch vụ, chẳng hạn “ResolutionTargetDateTime”.
Ví dụ
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
|
|||
|
Loại yêu cầu dịch vụ
ServiceRequestType
|
Phân loại hoặc nhóm của yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này phân loại yêu cầu dịch vụ, chẳng hạn như “Yêu cầu phần cứng”, “Cài đặt phần mềm” hoặc “Đặt lại mật khẩu”. Đây là chiều phân tích quan trọng, giúp các nhóm so sánh hiệu quả quy trình, thời gian xử lý và mức độ đáp ứng SLA giữa các loại dịch vụ. Hiểu rõ sự khác biệt này giúp điều chỉnh cải tiến quy trình và phân bổ tài nguyên phù hợp hơn.
Vì sao điều này quan trọng
Phân đoạn quy trình theo loại yêu cầu giúp phân tích đúng trọng tâm, qua đó phát hiện loại yêu cầu nào thường bị chậm trễ, phải làm lại hoặc vi phạm SLA.
Lấy dữ liệu ở đâu
Thông tin này thường nằm trong một trường của đối tượng nghiệp vụ Service Request, có thể mang tên “Service” hoặc “Category”. Hãy xem tài liệu Ivanti Service Manager để tìm tên trường cụ thể, chẳng hạn “SvcReqTmplLink_Category”.
Ví dụ
Yêu cầu phần cứng mớiQuyền truy cập phần mềmThay đổi tài khoảnYêu cầu thông tin
|
|||
|
Mức độ ưu tiên
Priority
|
Mức độ ưu tiên được gán cho yêu cầu dịch vụ. | ||
|
Mô tả
Mức độ ưu tiên cho biết yêu cầu dịch vụ cần được xử lý gấp đến đâu, thường theo các mức như “Thấp”, “Trung bình”, “Cao” hoặc “Khẩn cấp”. Thuộc tính này giúp đánh giá quy trình có ưu tiên xử lý các yêu cầu quan trọng hay không. Phân tích thường so sánh thời gian xử lý và mức độ đáp ứng SLA giữa các mức ưu tiên để kiểm tra quy tắc ưu tiên có hoạt động như mong muốn.
Vì sao điều này quan trọng
Thông tin này rất quan trọng để đánh giá hiệu quả của cách phân loại ưu tiên và bảo đảm yêu cầu ưu tiên cao được giải quyết nhanh hơn yêu cầu ưu tiên thấp.
Lấy dữ liệu ở đâu
Trường tiêu chuẩn trên đối tượng Service Request, thường có tên “Priority”.
Ví dụ
1 - Khẩn cấp2 - Cao3 - Trung bình4 - Thấp
|
|||
|
Nhân viên được giao
AssignedAgent
|
Người dùng hoặc nhân viên cụ thể được giao xử lý yêu cầu dịch vụ. | ||
|
Mô tả
Nhân viên được giao là người trực tiếp chịu trách nhiệm xử lý yêu cầu dịch vụ. Thuộc tính này cho phép phân tích ở cấp cá nhân, hữu ích cho việc đánh giá hiệu suất, cân bằng khối lượng công việc và xác định nhu cầu đào tạo. Theo dõi việc chuyển yêu cầu giữa các nhân viên là cơ sở để tính KPI như “Số lần phân công lại trung bình trên mỗi yêu cầu” và tìm ra điểm chưa hiệu quả trong quy trình.
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à cách phân công lại ở cấp cá nhân. Những thông tin này có thể giúp phát hiện vấn đề về đào tạo, kỹ năng hoặc khâu phân tuyến ban đầu.
Lấy dữ liệu ở đâu
Thông tin này thường nằm trong trường như “Owner” của đối tượng Service Request. Giá trị có thể thay đổi mỗi lần phân công lại và cần được theo dõi trong nhật ký sự kiện.
Ví dụ
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
|
|||
|
Nhóm được giao
AssignedTeam
|
Nhóm hỗ trợ hiện được giao xử lý yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này cho biết nhóm chịu trách nhiệm xử lý yêu cầu dịch vụ tại từng thời điểm. Phân tích việc chuyển giao giữa các nhóm, thời gian mỗi nhóm xử lý và số lượng yêu cầu từng nhóm tiếp nhận giúp hiểu rõ cách phân bổ khối lượng công việc, tìm điểm nghẽn và đánh giá hiệu quả của nhóm. Thông tin này cũng hỗ trợ trực tiếp cho các dashboard theo dõi mức độ đáp ứng SLA và khối lượng công việc của nhân viên hỗ trợ.
Vì sao điều này quan trọng
Theo dõi trách nhiệm và việc chuyển giao để phân tích chậm trễ giữa các nhóm, cân bằng khối lượng công việc và xác định nhóm nào đang tạo điểm nghẽn trong quy trình.
Lấy dữ liệu ở đâu
Thông tin này thường được lưu trong trường như “OwnerTeam” của đối tượng Service Request hoặc trong các bản ghi phân công liên quan.
Ví dụ
Bộ phận hỗ trợ CNTTVận hành mạngHỗ trợ nhân sựQuản lý cơ sở vật chất
|
|||
|
Thời điểm kết thúc sự kiện
EventEndTime
|
Dấu thời gian cho biết một hoạt động đã hoàn tất khi nào. | ||
|
Mô tả
Thời điểm kết thúc sự kiện đánh dấu lúc một hoạt động hoàn tất. Khoảng thời gian từ Thời điểm sự kiện (bắt đầu) đến Thời điểm kết thúc sự kiện là thời gian xử lý của hoạt động đó. Thông tin này giúp xác định bước nào trong quy trình mất nhiều thời gian nhất, từ đó tìm ra điểm chưa hiệu quả và cơ hội cải tiến.
Vì sao điều này quan trọng
Thông tin này giúp tính thời lượng của từng hoạt động, cần thiết để xác định điểm nghẽn trong quy trình và các tác vụ kéo dài.
Lấy dữ liệu ở đâu
Có thể không có trường riêng cho thông tin này. Thông thường, đó là thời điểm bắt đầu của hoạt động tiếp theo trong cùng một hồ sơ.
Ví dụ
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
|
|||
|
Trạng thái SLA
SLAStatus
|
Cho biết yêu cầu dịch vụ có được giải quyết trước hạn SLA hay không. | ||
|
Mô tả
Đây là thuộc tính được suy ra, đánh dấu từng yêu cầu dịch vụ là “Đạt” hoặc “Vi phạm” dựa trên thời điểm giải quyết so với hạn SLA. Thuộc tính này là cơ sở cho dashboard “Hiệu quả đáp ứng SLA” và KPI “Tỷ lệ đáp ứng Thỏa thuận mức dịch vụ”. Logic tính toán so sánh ResolutionDateTime với SLADeadline của từng hồ sơ.
Vì sao điều này quan trọng
Đo trực tiếp hiệu quả thực hiện cam kết dịch vụ, yếu tố quan trọng để đánh giá chất lượng dịch vụ và duy trì niềm tin của người dùng.
Lấy dữ liệu ở đâu
Tính bằng cách so sánh “ResolutionDateTime” với “SLADeadline”. Nếu ResolutionDateTime <= SLADeadline, trạng thái là “Đạt”; nếu không, trạng thái là “Vi phạm”.
Ví dụ
ĐạtVi phạm
|
|||
|
Trạng thái yêu cầu dịch vụ
ServiceRequestStatus
|
Trạng thái của yêu cầu dịch vụ tại thời điểm xảy ra sự kiện. | ||
|
Mô tả
Thuộc tính này ghi lại trạng thái của yêu cầu dịch vụ, chẳng hạn như “Đã ghi nhận”, “Đang xử lý”, “Đang chờ”, “Đã giải quyết” hoặc “Đã đóng”. Các lần đổi trạng thái thường xác định những hoạt động trong nhật ký quy trình. Phân tích thời gian ở từng trạng thái có thể cho thấy điểm nghẽn, chẳng hạn yêu cầu ở trạng thái “Đang chờ” quá lâu.
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. Đây là thông tin cần thiết để tính thời gian ở mỗi trạng thái và xác định lúc quy trình bị đình trệ.
Lấy dữ liệu ở đâu
Trường tiêu chuẩn trên đối tượng Service Request, thường có tên “Status”.
Ví dụ
Đã ghi nhậnĐang hoạt độngĐang chờ khách hàngĐã hoàn tấtĐã đóng
|
|||
|
Có làm lại
IsRework
|
Cờ đúng/sai cho biết yêu cầu dịch vụ có phát sinh hoạt động làm lại hay không. | ||
|
Mô tả
Cờ được tính toán này có giá trị true nếu yêu cầu dịch vụ có dấu hiệu phải làm lại, chẳng hạn được mở lại sau khi giải quyết hoặc có một số hoạt động lặp lại theo vòng. Cờ này giúp tính KPI “Tỷ lệ làm lại yêu cầu dịch vụ” dễ dàng hơn và lọc các trường hợp quy trình kém hiệu quả trong dashboard như “Luồng làm lại và phân công lại”.
Vì sao điều này quan trọng
Giúp nhanh chóng xác định và đo số lượng yêu cầu cần thêm công sức ngoài dự kiến, qua đó làm rõ vấn đề về chất lượng và hiệu quả.
Lấy dữ liệu ở đâu
Được suy ra từ dữ liệu. Logic có thể dựa trên thuộc tính “ReopenCount” lớn hơn 0 hoặc phát hiện chuỗi hoạt động cụ thể, chẳng hạn nhiều sự kiện “Assigned to Agent”.
Ví dụ
truefalse
|
|||
|
Kênh tiếp nhận
Channel
|
Phương thức hoặc kênh gửi yêu cầu dịch vụ. | ||
|
Mô tả
Kênh tiếp nhận cho biết yêu cầu dịch vụ được tạo bằng cách nào, chẳng hạn qua cổng tự phục vụ, email, điện thoại hoặc tự động từ một hệ thống khác. Phân tích số lượng yêu cầu và thời gian giải quyết theo từng kênh giúp xác định kênh nào hiệu quả nhất, kênh nào cần cải tiến quy trình hoặc hướng dẫn người dùng.
Vì sao điều này quan trọng
Giúp hiểu cách người dùng sử dụng dịch vụ và hiệu quả của từng kênh, từ đó đưa ra quyết định về cách cung cấp dịch vụ và cơ hội tự động hóa.
Lấy dữ liệu ở đâu
Thông tin này thường được lưu trong trường như “Source” hoặc “CreatedBy” trên đối tượng Service Request.
Ví dụ
Tự phục vụEmailĐiện thoạiNhập trực tiếp
|
|||
|
Nhóm kết quả giải quyết
ResolutionCategory
|
Phân loại kết quả giải quyết yêu cầu dịch vụ. | ||
|
Mô tả
Nhóm kết quả giải quyết cung cấp cách phân loại có cấu trúc về cách yêu cầu dịch vụ được xử lý cuối cùng. Thông tin này thường được phân cấp, chẳng hạn theo danh mục và danh mục con, giúp phân tích nguyên nhân gốc rễ và báo cáo xu hướng. Ví dụ, dữ liệu có thể cho thấy sự cố nào thường lặp lại hoặc hành động xử lý nào phổ biến, từ đó giúp cải thiện dịch vụ hoặc tạo bài viết trong cơ sở tri thức.
Vì sao điều này quan trọng
Cho biết đặc điểm của các cách giải quyết, giúp xác định vấn đề thường gặp, cơ hội cải thiện dịch vụ và những khâu có thể tự động hóa.
Lấy dữ liệu ở đâu
Thông tin này thường được lưu trong các trường phân loại được điền khi giải quyết yêu cầu, chẳng hạn “ResolutionCategory” hoặc trường mã đóng tùy chỉnh.
Ví dụ
Cần đào tạo người dùngĐã triển khai phần mềmĐã sửa phần cứngĐã cấp quyền truy cập
|
|||
|
Phòng ban của người yêu cầu
RequestorDepartment
|
Phòng ban của người dùng đã gửi yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này cho biết phòng ban của nhân viên hoặc hệ thống khởi tạo yêu cầu dịch vụ, chẳng hạn “Kinh doanh”, “Tài chính” hoặc “Nhân sự”. Thuộc tính này giúp phân tích chất lượng dịch vụ và nhu cầu giữa các bộ phận trong tổ chức. Ví dụ, bạn có thể xác định phòng ban nào thường phải chờ lâu hơn để được giải quyết hoặc gửi nhiều yêu cầu hơn.
Vì sao điều này quan trọng
Cho phép phân tích mức độ sử dụng và chất lượng dịch vụ theo đơn vị kinh doanh, giúp phát hiện vấn đề hoặc xu hướng riêng của từng phòng ban.
Lấy dữ liệu ở đâu
Thông tin này thường được lấy từ hồ sơ người dùng gửi yêu cầu, được liên kết với Service Request. Trường tương ứng có thể là “Department” trong đối tượng Profile.Employee.
Ví dụ
Tài chínhKinh doanhTiếp thịCông nghệ thông tin
|
|||
|
Số lần mở lại
ReopenCount
|
Số lần một yêu cầu dịch vụ đã giải quyết được mở lại. | ||
|
Mô tả
Thuộc tính này tăng thêm một mỗi khi yêu cầu dịch vụ chuyển từ trạng thái “Đã giải quyết” hoặc “Đã đóng” về trạng thái “Đang hoạt động”. Số lần mở lại cao cho thấy khả năng giải quyết ngay lần đầu còn thấp, giải pháp chưa đầy đủ hoặc vấn đề tiếp tục tái diễn. Thuộc tính này hỗ trợ trực tiếp KPI “Tỷ lệ làm lại yêu cầu dịch vụ”.
Vì sao điều này quan trọng
Đo trực tiếp khối lượng công việc phải làm lại và là chỉ báo quan trọng về chất lượng giải quyết. Số lần cao cho thấy cách xử lý ban đầu chưa hiệu quả.
Lấy dữ liệu ở đâu
Đây thường là trường đếm trên đối tượng Service Request, được quy tắc nghiệp vụ tăng giá trị khi trạng thái thay đổi theo điều kiện phù hợp. Trường có thể mang tên “ReopenCounter”.
Ví dụ
0123
|
|||
|
Số lần phân công
AssignmentCount
|
Tổng số lần yêu cầu dịch vụ được phân công hoặc phân công lại. | ||
|
Mô tả
Chỉ số được tính này đếm số hoạt động liên quan đến phân công, chẳng hạn “Assigned to Team” và “Assigned to Agent”, cho mỗi yêu cầu dịch vụ. Số lần phân công lại cao, thường được gọi là “chuyền qua chuyền lại”, cho thấy việc phân tuyến chưa hiệu quả, chưa giải quyết được ngay lần liên hệ đầu tiên hoặc trách nhiệm giữa các nhóm chưa rõ. Thuộc tính này cần thiết để tính KPI “Số lần phân công lại trung bình trên mỗi yêu cầu”.
Vì sao điều này quan trọng
Đo lường tình trạng chuyển giao và phân tuyến kém hiệu quả. Số lần cao là dấu hiệu rõ ràng cho thấy thời gian giải quyết kéo dài và người dùng không hài lòng.
Lấy dữ liệu ở đâu
Được tính bằng cách đếm số lần xuất hiện của các hoạt động liên quan đến phân công cho từng ServiceRequestID duy nhất trong quá trình chuẩn bị dữ liệu.
Ví dụ
12345
|
|||
|
Tên nhà cung cấp
VendorName
|
Tên nhà cung cấp bên ngoài tham gia giải quyết yêu cầu. | ||
|
Mô tả
Thuộc tính này xác định nhà cung cấp bên thứ ba được thuê để hỗ trợ hoặc hoàn tất yêu cầu dịch vụ. Đây là thông tin cần thiết cho dashboard “Thời lượng hoạt động của nhà cung cấp bên ngoài”, giúp đo lường và so sánh hiệu quả giữa các nhà cung cấp. Theo dõi thông tin này hỗ trợ quản lý quan hệ với nhà cung cấp và xác định điểm nghẽn do phụ thuộc bên ngoài.
Vì sao điều này quan trọng
Cho phép phân tích hiệu quả của bên thứ ba và ảnh hưởng của họ đến tổng thời gian giải quyết yêu cầu dịch vụ, qua đó hỗ trợ quản lý nhà cung cấp.
Lấy dữ liệu ở đâu
Thông tin này có thể nằm trong một trường của đối tượng tác vụ liên kết với yêu cầu dịch vụ, hoặc trong trường riêng của Service Request nếu yêu cầu được giao cho nhà cung cấp.
Ví dụ
Dell SupportOracle ConsultingMicrosoft Premiernull
|
|||
Hoạt động quản lý yêu cầu dịch vụ
| Hoạt động | Mô tả | ||
|---|---|---|---|
|
Đóng yêu cầu dịch vụ
|
Yêu cầu dịch vụ được đóng chính thức và không thể thực hiện thêm thao tác nào. Việc này thường diễn ra tự động sau một khoảng thời gian nhất định ở trạng thái 'Resolved', đánh dấu kết thúc vòng đời yêu cầu. | ||
|
Vì sao điều này quan trọng
Hoạt động này đánh dấu điểm kết thúc cuối cùng của quy trình. Khoảng thời gian từ 'Resolved' đến 'Closed' có thể cho thấy chậm trễ trong khâu xác nhận hoặc xử lý tự động của hệ thống.
Lấy dữ liệu ở đâu
Suy ra từ việc trường 'Status' của bản ghi Service Request chuyển thành 'Closed', cùng với dấu thời gian tương ứng.
Thu thập
Phát hiện trường 'Status' được cập nhật thành 'Closed' trong lịch sử kiểm tra.
Loại sự kiện
inferred
|
|||
|
Giải quyết yêu cầu dịch vụ
|
Yêu cầu dịch vụ được xem là đã giải quyết và giải pháp đã được cung cấp cho người dùng. Đây là cột mốc chính, được ghi nhận khi trạng thái chuyển thành 'Resolved', thường là lúc đồng hồ SLA dừng. | ||
|
Vì sao điều này quan trọng
Đây là mốc kết thúc quan trọng để đo thời gian giải quyết và mức độ tuân thủ SLA. Khoảng thời gian từ lúc tạo đến hoạt động này là KPI cốt lõi để đánh giá hiệu suất quy trình.
Lấy dữ liệu ở đâu
Suy ra từ việc trường 'Status' của bản ghi Service Request chuyển thành 'Resolved', cùng với dấu thời gian tương ứng.
Thu thập
Phát hiện trường 'Status' được cập nhật thành 'Resolved' trong lịch sử kiểm tra.
Loại sự kiện
inferred
|
|||
|
Giao yêu cầu cho nhân viên
|
Một nhân viên cụ thể nhận xử lý yêu cầu dịch vụ. Thông thường, hoạt động này được suy ra khi trường 'Owner', dùng để xác định nhân viên phụ trách, được điền hoặc cập nhật lần đầu. | ||
|
Vì sao điều này quan trọng
Sự kiện này đánh dấu thời điểm kết thúc thời gian chờ ban đầu trong hàng đợi. Đo khoảng thời gian trước hoạt động này giúp phát hiện vấn đề phân bổ tài nguyên và hỗ trợ dashboard Khối lượng công việc của nhân viên.
Lấy dữ liệu ở đâu
Suy ra từ việc trường 'Owner' trong bản ghi Service Request được điền hoặc thay đổi, như thể hiện trong lịch sử kiểm tra.
Thu thập
Dấu thời gian đầu tiên ghi nhận tên nhân viên trong trường 'Owner' sau khi tạo yêu cầu hoặc giao cho nhóm.
Loại sự kiện
inferred
|
|||
|
Giao yêu cầu cho nhóm
|
Yêu cầu dịch vụ được giao cho một nhóm hỗ trợ cụ thể xử lý. Có thể ghi nhận sự kiện này bằng cách theo dõi trường 'OwnerTeam' trong bản ghi Service Request khi trường được điền hoặc thay đổi. | ||
|
Vì sao điều này quan trọng
Sự kiện này rất quan trọng để phân tích hiệu suất của từng nhóm, phân bổ khối lượng công việc và thời gian bàn giao giữa các nhóm. Sự kiện giúp xác định nhóm nào đang tạo điểm nghẽn trong quy trình.
Lấy dữ liệu ở đâu
Theo dõi các thay đổi trong trường 'OwnerTeam' ở lịch sử kiểm tra hoặc nhật ký của Service Request.
Thu thập
Sự kiện cập nhật trường 'OwnerTeam', thường được ghi lại trong nhật ký kiểm tra.
Loại sự kiện
explicit
|
|||
|
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ụ, khi yêu cầu mới được gửi chính thức và ghi nhận trong Ivanti. Sự kiện được ghi nhận khi một bản ghi mới được tạo trong đối tượng nghiệp vụ Service Request, tạo ra Service Request ID duy nhất. | ||
|
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ừ lúc này đến khi giải quyết là bước cơ bản để đo thời gian xử lý tổng thể và hiệu quả quy trình.
Lấy dữ liệu ở đâu
Thời điểm này được lấy từ dấu thời gian tạo bản ghi Service Request, chẳng hạn trường CreatedDateTime trong đối tượng nghiệp vụ ServiceReq.
Thu thập
Sự kiện tạo bản ghi trong bảng ServiceReq, được xác định bằng dấu thời gian tạo.
Loại sự kiện
explicit
|
|||
|
Chuyển yêu cầu cho nhà cung cấp bên ngoài
|
Yêu cầu dịch vụ được chuyển cho nhà cung cấp bên ngoài hoặc bên thứ ba xử lý. Thông thường, sự kiện này được ghi nhận khi trạng thái chuyển thành 'Waiting for 3rd Party' hoặc trạng thái tương tự. | ||
|
Vì sao điều này quan trọng
Hoạt động này cần thiết để đo hiệu suất của nhà cung cấp và tác động đến thời gian xử lý tổng thể. Hoạt động này giúp phân tích chậm trễ liên quan đến nhà cung cấp và hỗ trợ dashboard Thời lượng hoạt động của nhà cung cấp bên ngoài.
Lấy dữ liệu ở đâu
Suy ra từ lần đổi trạng thái của bản ghi Service Request sang trạng thái như 'Waiting for 3rd Party' hoặc 'Pending Vendor'.
Thu thập
Phát hiện trường 'Status' chuyển sang trạng thái được quy định là 'chờ nhà cung cấp'.
Loại sự kiện
inferred
|
|||
|
Gửi yêu cầu để phê duyệt
|
Yêu cầu dịch vụ đã được gửi để xin các phê duyệt cần thiết trước khi xử lý. Thông thường, sự kiện này được suy ra khi trạng thái yêu cầu chuyển thành 'Submitted' hoặc 'Pending Approval', thường là lúc quy trình phê duyệt bắt đầu. | ||
|
Vì sao điều này quan trọng
Theo dõi hoạt động này giúp phát hiện chậm trễ trong giai đoạn phê duyệt. Thời gian chờ lâu ở đây có thể trở thành điểm nghẽn đáng kể, ảnh hưởng đến thời gian xử lý tổng thể và mức độ hài lòng của người dùng.
Lấy dữ liệu ở đâu
Suy ra từ lần đổi trạng thái của bản ghi Service Request, thường là sang 'Submitted' hoặc 'Waiting for Approval'. Dữ liệu cũng có thể lấy từ các đối tượng nghiệp vụ FRS_Approval hoặc FRS_ApprovalVoteTracking.
Thu thập
Trường 'Status' của bản ghi Service Request chuyển sang trạng thái chờ phê duyệt.
Loại sự kiện
inferred
|
|||
|
Hoàn tất yêu cầu dịch vụ
|
Nhân viên hoặc hệ thống đã hoàn tất mọi tác vụ cần thiết để xử lý yêu cầu dịch vụ. Sự kiện này được ghi nhận khi trạng thái chuyển thành 'Fulfilled', thường là trước trạng thái cuối cùng 'Resolved'. | ||
|
Vì sao điều này quan trọng
Cột mốc này đánh dấu việc hoàn tất công việc kỹ thuật hoặc theo quy trình. Đây là thời điểm quan trọng để đo thời gian xử lý thực tế trước khi xác nhận và đóng yêu cầu.
Lấy dữ liệu ở đâu
Suy ra từ việc trường 'Status' của bản ghi Service Request chuyển thành 'Fulfilled'.
Thu thập
Phát hiện trường 'Status' chuyển thành 'Fulfilled' trong lịch sử bản ghi.
Loại sự kiện
inferred
|
|||
|
Hủy yêu cầu dịch vụ
|
Người dùng hoặc nhân viên đã hủy yêu cầu dịch vụ trước khi giải quyết. Đây là trạng thái kết thúc thay thế, được ghi nhận khi trạng thái chuyển thành 'Cancelled' hoặc 'Withdrawn'. | ||
|
Vì sao điều này quan trọng
Đây là trường hợp quy trình kết thúc không theo thông lệ. Phân tích lý do hủy yêu cầu có thể giúp phát hiện vấn đề trong chính quy trình gửi yêu cầu hoặc những thay đổi trong nhu cầu của người dùng.
Lấy dữ liệu ở đâu
Suy ra từ việc trường 'Status' của bản ghi Service Request chuyển thành 'Cancelled'.
Thu thập
Phát hiện trường 'Status' được cập nhật thành 'Cancelled' trong lịch sử kiểm tra.
Loại sự kiện
inferred
|
|||
|
Mở lại yêu cầu dịch vụ
|
Yêu cầu dịch vụ đã giải quyết trước đó được kích hoạt lại vì sự cố vẫn còn hoặc giải pháp chưa đáp ứng yêu cầu. Sự kiện này được ghi nhận khi trạng thái chuyển từ 'Resolved' về trạng thái đang xử lý như 'Active' hoặc 'Assigned'. | ||
|
Vì sao điều này quan trọng
Hoạt động này cho thấy rõ công việc phải làm lại và chất lượng giải quyết ngay từ lần đầu chưa tốt. Phân tích các lần mở lại giúp phát hiện điểm yếu trong quy trình và cải thiện KPI Tỷ lệ làm lại yêu cầu dịch vụ.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử kiểm tra khi trường 'Status' chuyển từ 'Resolved' hoặc 'Closed' sang trạng thái đang xử lý.
Thu thập
Trạng thái chuyển từ trạng thái kết thúc ('Resolved', 'Closed') sang trạng thái đang mở ('Active', 'Assigned').
Loại sự kiện
inferred
|
|||
|
Người dùng cung cấp thông tin
|
Người gửi yêu cầu đã cung cấp thông tin cần thiết để nhân viên tiếp tục xử lý. Sự kiện này được ghi nhận khi yêu cầu rời trạng thái 'Waiting for Customer' và chuyển về trạng thái đang xử lý. | ||
|
Vì sao điều này quan trọng
Sự kiện này khép lại vòng yêu cầu bổ sung thông tin. Khoảng thời gian từ lúc yêu cầu đến khi nhận được thông tin là yếu tố quan trọng gây chậm trễ và phát sinh vòng lặp làm lại.
Lấy dữ liệu ở đâu
Suy ra khi trường 'Status' của Service Request chuyển từ trạng thái 'Waiting for Customer' sang trạng thái đang xử lý như 'Active' hoặc 'In Progress'.
Thu thập
Phát hiện trạng thái chuyển từ trạng thái 'chờ người dùng' sang trạng thái đang xử lý.
Loại sự kiện
inferred
|
|||
|
Phê duyệt yêu cầu
|
Yêu cầu dịch vụ đã nhận đủ phê duyệt cần thiết và có thể chuyển sang xử lý. Sự kiện này được ghi nhận khi quy trình phê duyệt kết thúc thành công và trạng thái yêu cầu thay đổi. | ||
|
Vì sao điều này quan trọng
Hoạt động này đánh dấu cột mốc quan trọng, cho biết giai đoạn phê duyệt đã kết thúc và giai đoạn xử lý bắt đầu. Đây cũng là cơ sở để đo hiệu quả của quy trình phê duyệt.
Lấy dữ liệu ở đâu
Suy ra từ lần đổi trạng thái từ 'Waiting for Approval' sang 'Approved' hoặc 'Fulfilled'. Sự kiện này cũng có thể được ghi rõ trong đối tượng nghiệp vụ FRS_Approval.
Thu thập
Trường 'Status' của bản ghi Service Request chuyển từ trạng thái chờ phê duyệt sang trạng thái đang xử lý.
Loại sự kiện
inferred
|
|||
|
Thay đổi mức độ ưu tiên
|
Mức độ ưu tiên của yêu cầu dịch vụ được cập nhật sau khi tạo. Sự kiện này được lấy từ nhật ký kiểm tra hoặc lịch sử ghi lại các thay đổi ở cấp trường. | ||
|
Vì sao điều này quan trọng
Theo dõi thay đổi mức độ ưu tiên là yếu tố quan trọng trong Tổng quan hiệu quả phân loại ưu tiên. Việc này giúp xác định các yêu cầu được chuyển cấp có được xử lý đúng cách hay không và mức ưu tiên ban đầu có chính xác không.
Lấy dữ liệu ở đâu
Đây là sự kiện được ghi rõ trong lịch sử kiểm tra của bản ghi Service Request, nơi lưu lại các thay đổi của trường 'Priority'.
Thu thập
Sự kiện cập nhật trường 'Priority' được ghi lại trong nhật ký kiểm tra của hệ thống.
Loại sự kiện
explicit
|
|||
|
Yêu cầu người dùng cung cấp thông tin
|
Nhân viên được giao xử lý cần thêm thông tin từ người gửi yêu cầu để tiếp tục. Sự kiện này được ghi nhận khi trạng thái yêu cầu chuyển sang trạng thái như 'Waiting for Customer'. | ||
|
Vì sao điều này quan trọng
Hoạt động này cho thấy chậm trễ do thông tin ban đầu chưa đầy đủ. Theo dõi tần suất và thời lượng của hoạt động là điều cần thiết để phân tích tác động của yêu cầu bổ sung thông tin và xác định cơ hội cải tiến quy trình.
Lấy dữ liệu ở đâu
Suy ra từ lần đổi trạng thái của bản ghi Service Request sang trạng thái như 'Waiting for Customer' hoặc 'Pending'.
Thu thập
Phát hiện trường 'Status' chuyển sang trạng thái được quy định là 'chờ người dùng'.
Loại sự kiện
inferred
|
|||
Hướng dẫn trích xuất dữ liệu
Bạn đã sẵn sàng bắt đầu chưa?
Dùng mẫu dữ liệu chi tiết này để khai thác tối đa quy trình quản lý yêu cầu dịch vụ. Bắt đầu tối ưu hoạt động vận hành ngay hôm nay.
Bắt đầu tối ưu quy trình quản lý yêu cầu dịch vụ ngay hôm nay
Giảm thời gian xử lý yêu cầu, hạn chế sự khó chịu của người dùng và đạt tỷ lệ tự động hóa 70%.
Không cần thẻ tín dụng, thiết lập chỉ trong vài phút.