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

Jira Service Management
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 này hướng dẫn bạn thu thập dữ liệu cần thiết để phân tích quy trình yêu cầu dịch vụ. Mẫu nêu rõ các thuộc tính cần lấy, những hoạt động chính cần theo dõi và cách trích xuất thông tin từ hệ thống. Dùng tài nguyên này để chuẩn bị dữ liệu nhanh hơn và hiểu rõ hơn về hoạt động vận hành.
  • Các thuộc tính nên có để phân tích đầy đủ
  • Các 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ừ Jira Service Management
Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Thuộc tính quản lý yêu cầu dịch vụ

Đây là các 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 5 Nên có 7 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ể diễn ra trong vòng đời của yêu cầu dịch vụ.
Mô tả

Thuộc tính này mô tả hành động hoặc lần chuyển trạng thái cụ thể diễn ra tại một thời điểm trong quá trình xử lý yêu cầu dịch vụ. Ví dụ: 'Đã tạo yêu cầu', 'Đã phân công yêu cầu', 'Đã triển khai giải pháp' và 'Đã đóng yêu cầu'.

Phân tích trình tự và tần suất của các hoạt động này là trọng tâm của process mining. Việc này giúp trực quan hóa sơ đồ quy trình, xác định điểm nghẽn và phát hiện sai lệch so với workflow chuẩn. Đây là cơ sở quan trọng để hiểu hiệu quả và mức độ tuân thủ của 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 quy trình, giúp trực quan hóa sơ đồ quy trình và phân tích các mẫu workflow cũng như sai lệch.

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

Thông thường, dữ liệu được lấy từ lịch sử chuyển trạng thái 'status' của vấn đề Jira. Mỗi mục trong changelog của trường trạng thái tương ứng với một hoạt động.

Ví dụ
Yêu cầu được phân loạiYêu cầu cung cấp thông tinĐã triển khai giải phápYêu cầu dịch vụ đã đóng
Mã yêu cầu dịch vụ
ServiceRequestId
Mã định danh duy nhất của mỗi yêu cầu dịch vụ, dùng làm khóa chính cho tất cả sự kiện liên quan.
Mô tả

Mã yêu cầu dịch vụ, thường được gọi là Issue Key trong Jira, giúp nhận diện duy nhất từng yêu cầu 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, để bạn phân tích toàn bộ hành trình của từng yêu cầu dịch vụ.

Trong process mining, mã này rất cần thiết để liên kết các sự kiện với đúng trường hợp. Nhờ đó, mọi hoạt động, thay đổi trạng thái và dấu thời gian đều gắn với yêu cầu tương ứng, tạo thành một phiên bản quy trình thống nhất để phân tích.

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

Đây là mã định danh cốt lõi của từng trường hợp. Mã này kết nối mọi hoạt động liên quan thành một luồng quy trình xuyên suốt, giúp bạn phân tích quy trình.

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

Đây là trường 'key' của một vấn đề trong Jira Service Management.

Ví dụ
SR-2023-001IT-45892HELP-105
Thời gian bắt đầu
EventTime
Ngày và giờ chính xác khi một hoạt động hoặc sự kiện diễn ra.
Mô tả

Thời gian bắt đầu, hay dấu thời gian của sự kiện, ghi lại chính xác lúc một hoạt động diễn ra. Đây là thành phần quan trọng trong mọi phân tích process mining vì cung cấp mốc thời gian cho toàn bộ quy trình.

Dấu thời gian giúp sắp xếp sự kiện theo trình tự, tính khoảng thời gian giữa các hoạt động, đo tổng thời gian xử lý từng trường hợp và đánh giá hiệu suất quy trình so với các mục tiêu theo thời gian như SLA. Nếu dấu thời gian không chính xác, bạn sẽ không thể hiểu luồng quy trình, xác định chậm trễ hay đo lường hiệu quả.

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

Dấu thời gian này rất cần thiết để sắp xếp sự kiện, tính thời lượng và thời gian xử lý, cũng như xác định điểm nghẽn trong quy trình.

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

Đây là dấu thời gian gắn với mỗi lần chuyển trạng thái trong changelog của vấn đề Jira. Thời điểm tạo vấn đề nằm trong trường 'created'.

Ví dụ
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
Hệ thống nguồn
SourceSystem
Hệ thống nơi dữ liệu yêu cầu dịch vụ được trích xuất.
Mô tả

Thuộc tính này cho biết dữ liệu đến từ đâu, trong trường hợp này là Jira Service Management. Thông tin này có thể không đáng chú ý khi chỉ phân tích dữ liệu từ một nguồn, nhưng rất quan trọng khi kết hợp dữ liệu quy trình từ nhiều hệ thống.

Khi phân tích, thuộc tính này giúp truy vết nguồn gốc dữ liệu và đảm bảo chất lượng dữ liệu. Bạn cũng có thể lọc và so sánh các quy trình trải rộng trên nhiều nền tảng phần mềm hoặc có tương tác với nhau.

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

Cho biết nguồn gốc dữ liệu, rất quan trọng đối với quản trị dữ liệu và khi kết hợp dữ liệu quy trình từ nhiều hệ thống doanh nghiệp.

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 và chuyển đổi dữ liệu để ghi nhãn nguồn gốc của tập dữ liệu.

Ví dụ
Jira Service ManagementJiraSM
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
Dấu thời gian cho biết lần gần nhất dữ liệu được làm mới từ hệ thống nguồn.
Mô tả

Thuộc tính này ghi lại ngày giờ lần gần nhất dữ liệu được trích xuất từ Jira Service Management. Thông tin này giúp bạn biết dữ liệu trong các bảng điều khiển và KPI còn mới đến đâu.

Để đưa ra quyết định phù hợp, bạn cần biết dữ liệu được cập nhật khi nào. Dấu thời gian này cho biết bạn đang xem thông tin gần thời gian thực hay ảnh chụp dữ liệu tại một thời điểm trước đó, từ đó đánh giá mức độ phù hợp của các kết quả phân tích.

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

Cho biết dữ liệu mới đến đâu, giúp đảm bảo phân tích dựa trên thông tin cập nhật.

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

Đây là trường siêu dữ liệu do công cụ hoặc tập lệnh trích xuất dữ liệu tạo và lưu sau khi chạy xong.

Ví dụ
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Hạn SLA
SlaDueDate
Ngày và giờ mục tiêu cần giải quyết xong yêu cầu dịch vụ theo SLA.
Mô tả

Hạn SLA là dấu thời gian được tính để xác định thời hạn giải quyết yêu cầu. Thời hạn này phụ thuộc vào mức độ ưu tiên, loại yêu cầu và chính sách Service Level Agreement (SLA) được cấu hình trong Jira Service Management.

Thuộc tính này là cơ sở cho bảng điều khiển 'Hiệu suất SLA của yêu cầu dịch vụ' và KPI 'Tỷ lệ đáp ứng SLA'. Bằng cách so sánh thời gian giải quyết thực tế với hạn này, hệ thống có thể xác định yêu cầu được hoàn tất đúng hạn, trễ hạn hay có nguy cơ vi phạm SLA.

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

Đây là mốc chuẩn để đo lường hiệu suất. Thuộc tính này hỗ trợ trực tiếp việc tính mức độ tuân thủ SLA và giúp ưu tiên công việc.

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

Jira Service Management quản lý thông tin SLA và cung cấp thông tin này qua API. Dữ liệu thường được lưu trong các trường tùy chỉnh và cập nhật linh hoạt.

Ví dụ
2023-10-28T16:00:00Z2023-11-01T09:00:00Z
Loại yêu cầu
RequestType
Phân loại yêu cầu dịch vụ, chẳng hạn như 'Yêu cầu cấp quyền truy cập' hoặc 'Sự cố phần cứng'.
Mô tả

Loại yêu cầu phân nhóm yêu cầu dịch vụ theo tính chất. Đây là chiều phân tích cơ bản vì mỗi loại yêu cầu thường có quy trình giải quyết, SLA và nhu cầu tài nguyên riêng.

Bằng cách phân tích quy trình theo loại yêu cầu, tổ chức có thể điều chỉnh cải tiến cho từng workflow cụ thể. Chẳng hạn, điểm nghẽn của yêu cầu 'Đặt lại mật khẩu' sẽ khác hẳn yêu cầu 'Cấp máy chủ mới'. Thuộc tính này cũng giúp xây dựng các bảng điều khiển phù hợp, chẳng hạn như 'Chất lượng giải quyết theo danh mục'.

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

Thuộc tính này rất cần thiết để so sánh quy trình, khối lượng công việc và hiệu suất giữa các loại yêu cầu dịch vụ.

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

Thường tương ứng với trường 'issuetype' trong Jira hoặc trường tùy chỉnh 'Request Type' trong Jira Service Management.

Ví dụ
Yêu cầu tạo tài khoản mớiYêu cầu hỗ trợ CNTTTiếp nhận nhân viên mới
Mức độ ưu tiên của yêu cầu
RequestPriority
Mức độ ưu tiên được gán cho yêu cầu dịch vụ, chẳng hạn như Thấp, Trung bình, Cao hoặc Khẩn cấp.
Mô tả

Mức độ ưu tiên của yêu cầu cho biết tính cấp bách và ảnh hưởng đến hoạt động kinh doanh. Phân loại này quyết định thứ tự xử lý yêu cầu, đồng thời thường xác định thời hạn giải quyết mục tiêu và SLA.

Khi phân tích quy trình, mức độ ưu tiên là một chiều phân tích quan trọng. Bạn có thể 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 xem yêu cầu ưu tiên cao có được xử lý nhanh hơn và đạt mục tiêu hay không. Qua đó, bạn có thể đánh giá hiệu quả của hệ thống ưu tiên.

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

Cho phép phân nhóm kết quả phân tích để kiểm tra xem yêu cầu ưu tiên cao có được xử lý nhanh hơn và đáp ứng các mức dịch vụ nghiêm ngặt hơn hay không.

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

Tương ứng với trường 'priority' của vấn đề Jira.

Ví dụ
Cao nhấtCaoTrung bìnhThấp
Người xử lý
Assignee
Người dùng hoặc nhân viên hiện được phân công xử lý yêu cầu dịch vụ.
Mô tả

Người xử lý là người chịu trách nhiệm thực hiện bước tiếp theo hoặc giải quyết yêu cầu dịch vụ. Giá trị của thuộc tính này có thể thay đổi nhiều lần trong vòng đời yêu cầu khi công việc được chuyển giữa các nhân viên hoặc nhóm.

Thuộc tính này rất quan trọng để phân tích khối lượng công việc, đo lường hiệu suất và quản lý tài nguyên. Bạn có thể lọc quy trình theo nhân viên, so sánh thời gian giải quyết giữa các cá nhân, đồng thời xác định nhu cầu đào tạo hoặc tình trạng phân bổ công việc mất cân đối gây ra điểm nghẽn.

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

Thuộc tính này rất cần thiết để phân tích khối lượng công việc của nhân viên, đo lường hiệu suất cá nhân và hiểu cách phân bổ tài nguyên.

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

Tương ứng với trường 'assignee' của vấn đề Jira.

Ví dụ
Alice JohnsonBob WilliamsChưa phân công
Trạng thái yêu cầu
RequestStatus
Trạng thái hiện tại của yêu cầu dịch vụ trong vòng đời xử lý.
Mô tả

Thuộc tính này cho biết trạng thái hiện tại của yêu cầu dịch vụ, chẳng hạn như 'Đang mở', 'Đang xử lý', 'Chờ khách hàng' hoặc 'Đã giải quyết'. Thuộc tính này cho biết yêu cầu đang ở bước nào tại một thời điểm cụ thể.

Nhật ký hoạt động cho thấy luồng xử lý trong quá khứ, còn trạng thái hiện tại giúp phân tích khối lượng công việc đang xử lý và tìm các yêu cầu bị đình trệ. Chẳng hạn, bạn có thể tập trung vào những yêu cầu đã ở trạng thái 'Chờ nhà cung cấp' quá lâu để phát hiện sự phụ thuộc bên ngoài và tình trạng chậm trễ.

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

Cung cấp ảnh chụp hiện trạng của từng trường hợp, giúp phân tích công việc đang xử lý và xác định yêu cầu bị đình trệ hoặc tồn đọng lâu.

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

Đây là trường 'status' của vấn đề Jira.

Ví dụ
Đang mởĐang xử lýChờ khách hàngĐã giải quyết
Đã mở lại
IsReopened
Giá trị đúng/sai cho biết yêu cầu dịch vụ có được mở lại sau khi giải quyết hay không.
Mô tả

Thuộc tính được tính toán này có giá trị đúng hoặc sai. Giá trị là đúng nếu workflow của yêu cầu có hoạt động 'Đã mở lại yêu cầu'. Giá trị được suy ra bằng cách phân tích trình tự hoạt động của từng trường hợp.

Cờ này rất cần thiết để tính KPI 'Tỷ lệ mở lại yêu cầu dịch vụ' và cung cấp dữ liệu cho bảng điều khiển 'Số lượng yêu cầu dịch vụ được mở lại'. Tỷ lệ mở lại cao cho thấy chất lượng giải quyết ngay lần đầu chưa tốt, dẫn đến phải làm lại và giảm mức độ hài lòng của khách hàng. Phân tích loại yêu cầu hoặc kết quả giải quyết nào gắn với cờ này có thể giúp xác định điểm cần cải thiện.

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

Đo trực tiếp công việc phải làm lại và chất lượng giải quyết ngay lần đầu, hai chỉ số quan trọng về hiệu quả quy trình và mức độ hài lòng của khách hàng.

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 trình tự hoạt động của một trường hợp có lần chuyển sang 'Đã mở lại' sau lần chuyển sang 'Đã giải quyết' hay không.

Ví dụ
truefalse
Kênh gửi yêu cầu
Channel
Cách gửi yêu cầu dịch vụ, chẳng hạn như email, cổng thông tin hoặc API.
Mô tả

Thuộc tính Kênh cho biết yêu cầu dịch vụ được gửi vào hệ thống bằng cách nào. Các kênh thường dùng trong Jira Service Management gồm cổng thông tin khách hàng, email hoặc nhân viên tạo yêu cầu trực tiếp.

Phân tích quy trình theo kênh giúp bạn hiểu hành vi người dùng và tối ưu việc cung cấp dịch vụ. Qua đó, bạn có thể phát hiện yêu cầu từ một số kênh mất nhiều thời gian giải quyết hơn hoặc cần làm rõ nhiều hơn. Điều này có thể cho thấy cần cải thiện biểu mẫu trên cổng thông tin hoặc quy tắc xử lý email. Phân tích này hỗ trợ bảng điều khiển 'Xu hướng thông lượng yêu cầu dịch vụ'.

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

Giúp phân tích xem kênh gửi yêu cầu có ảnh hưởng đến thời gian giải quyết, độ rõ ràng của yêu cầu hay hiệu quả chung của quy trình hay không.

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

Thông tin này có trong Jira Service Management, tại trường 'Request channel type'. Có thể cần quyền truy cập API cụ thể hoặc trường này được lưu trong một trường tùy chỉnh.

Ví dụ
cổng thông tinemailAPI
Kết quả giải quyết
Resolution
Kết quả cuối cùng của một yêu cầu dịch vụ đã được giải quyết.
Mô tả

Trường Resolution cho biết lý do yêu cầu dịch vụ được đóng. Các giá trị thường gặp gồm 'Đã hoàn tất', 'Không thực hiện', 'Trùng lặp' hoặc 'Không thể tái hiện'. Trường này cung cấp thêm thông tin về kết quả, ngoài trạng thái 'Đã giải quyết' hoặc 'Đã đóng'.

Phân tích kết quả giải quyết giúp bạn hiểu chất lượng và tính chất của các kết quả. Ví dụ, nhiều yêu cầu được đánh dấu 'Trùng lặp' có thể cho thấy vấn đề trong quy trình gửi yêu cầu. Việc theo dõi những kết quả nào dẫn đến yêu cầu mở lại cũng giúp phát hiện giải pháp chưa hiệu quả.

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

Cho biết bối cảnh và kết quả xử lý yêu cầu, giúp phân tích chất lượng giải quyết và tìm xu hướng về lý do đóng yêu cầu.

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

Tương ứng với trường 'resolution' của vấn đề Jira. Trường này thường được thiết lập khi vấn đề chuyển sang trạng thái thuộc nhóm 'done'.

Ví dụ
Đã hoàn tấtKhông thực hiệnTrùng lặpĐã sửa
Người báo cáo
Reporter
Người dùng đầu tiên tạo hoặc báo cáo yêu cầu dịch vụ.
Mô tả

Người báo cáo là cá nhân, thường là người dùng cuối hoặc khách hàng, đã gửi yêu cầu dịch vụ. Thuộc tính này xác định bên liên quan khởi tạo quy trình.

Khi phân tích, bạn có thể dùng thông tin người báo cáo để hiểu xu hướng yêu cầu theo người dùng, phòng ban hoặc nhóm khách hàng. Thuộc tính này giúp trả lời các câu hỏi như 'Phòng ban nào gửi nhiều yêu cầu nhất?' hoặc 'Có người dùng nào liên tục gặp cùng một vấn đề không?'. Thông tin này hữu ích cho việc chủ động quản lý vấn đề và cải thiện đào tạo người dùng.

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

Xác định người khởi tạo yêu cầu, giúp phân tích số lượng và loại yêu cầu theo người dùng, phòng ban hoặc khách hàng.

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

Tương ứng với trường 'reporter' của vấn đề Jira.

Ví dụ
Charles DarwinMarie CurieIsaac Newton
Nhóm được phân công
AssignedTeam
Nhóm chịu trách nhiệm xử lý yêu cầu dịch vụ.
Mô tả

Thuộc tính này cho biết nhóm được phân công xử lý yêu cầu, thường ở cấp cao hơn người xử lý riêng lẻ. Thuộc tính này hữu ích khi phân tích hiệu suất ở cấp nhóm, chẳng hạn như so sánh nhóm Hỗ trợ cấp 1 với nhóm Vận hành mạng.

Đây là chiều phân tích quan trọng cho các bảng điều khiển như 'Khối lượng công việc và chỉ số giải quyết của nhân viên'. Thuộc tính này cho phép tổng hợp chỉ số hiệu suất ở cấp nhóm, giúp so sánh công bằng và hiểu đóng góp của từng nhóm vào hoạt động cung cấp dịch vụ.

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

Cho phép phân tích hiệu suất và cân bằng khối lượng công việc ở cấp nhóm hoặc phòng ban, thay vì chỉ theo từng nhân viên.

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

Đây có thể là trường tùy chỉnh trong Jira, chẳng hạn như 'Team', hoặc được suy ra từ thông tin hồ sơ người dùng của người xử lý.

Ví dụ
Hỗ trợ CNTT - Cấp 1Nhóm hạ tầngHỗ trợ ứng dụng
Tổ chức
Organization
Tổ chức khách hàng hoặc phòng ban nội bộ mà người báo cáo trực thuộc.
Mô tả

Thuộc tính này nhóm người báo cáo theo tổ chức hoặc phòng ban. Jira Service Management có tính năng 'Organizations' tích hợp sẵn, cho phép nhân viên quản lý yêu cầu từ nhiều khách hàng hoặc nhóm nội bộ.

Phân tích theo tổ chức cung cấp bối cảnh kinh doanh hữu ích. Bạn có thể xác định khách hàng hoặc phòng ban nào sử dụng nhiều tài nguyên hỗ trợ nhất, nhóm nào thường xuyên gặp vấn đề và liệu các SLA có được đáp ứng nhất quán giữa các đơn vị kinh doanh hay không.

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

Giúp phân tích nhu cầu dịch vụ và hiệu suất theo khách hàng hoặc phòng ban nội bộ, từ đó cung cấp thông tin quan trọng cho hoạt động kinh doanh.

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

Dữ liệu này lấy từ trường 'Organizations' gắn với yêu cầu dịch vụ trong Jira Service Management.

Ví dụ
Acme CorporationPhòng tài chínhGlobal Tech Inc.
Trạng thái SLA
SlaState
Cho biết yêu cầu dịch vụ đã đáp ứng, vi phạm hay vẫn đang trong thời hạn SLA.
Mô tả

Trạng thái SLA là thuộc tính được tính toán để phân loại từng yêu cầu dịch vụ theo kết quả so với hạn SLA. Các giá trị có thể gồm 'Đạt', 'Vi phạm' hoặc 'Đang xử lý'. Trạng thái được xác định bằng cách so sánh dấu thời gian giải quyết với 'SlaDueDate'.

Đây là thuộc tính cốt lõi của bảng điều khiển 'Hiệu suất SLA của yêu cầu dịch vụ' và được dùng để tính KPI 'Tỷ lệ đáp ứng SLA'. Thuộc tính này cho biết rõ mức độ tuân thủ cam kết dịch vụ, rất quan trọng cho việc báo cáo, quản lý hợp đồng và duy trì chất lượng dịch vụ.

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

Cho biết nhanh và rõ hiệu suất SLA, một thước đo quan trọng về chất lượng dịch vụ và mức độ tuân thủ hợp đồng.

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

Được tính trong quá trình chuyển đổi dữ liệu. Nếu thời gian giải quyết trước 'SlaDueDate', trạng thái là 'Đạt'; nếu không, trạng thái là 'Vi phạm'.

Ví dụ
ĐạtVi phạmĐang xử lý
Bắt buộc Nên có Không bắt buộc

Hoạt động quản lý yêu cầu dịch vụ

Đây là các bước và mốc chính cần ghi lại trong nhật ký sự kiện để khám phá và cải tiến quy trình chính xác.
5 Nên có 8 Không bắt buộc
Hoạt động Mô tả
Đề xuất giải pháp
Trong nhiều quy trình làm việc của bộ phận dịch vụ, đây là bước riêng để đề xuất giải pháp cho người gửi yêu cầu phê duyệt. Có thể suy ra sự kiện này khi trạng thái vấn đề chuyển sang trạng thái như 'Pending Customer Acceptance' hoặc 'Awaiting Confirmation'.
Vì sao điều này quan trọng

Hoạt động này tách riêng thời gian chờ phản hồi của khách hàng sau khi đã đưa ra giải pháp, giúp phân biệt thời gian chờ với thời gian làm việc nội bộ.

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

Suy ra từ lịch sử vấn đề, ghi nhận tại dấu thời gian khi trạng thái chuyển sang trạng thái cho biết giải pháp đang chờ khách hàng xác nhận.

Thu thập

Xác định dấu thời gian khi trạng thái chuyển sang 'Pending Customer Acceptance' hoặc trạng thái tương đương.

Loại sự kiện inferred
Yêu cầu dịch vụ đã đóng
Đây là bước đóng yêu cầu dịch vụ về mặt hành chính, thường diễn ra tự động sau một khoảng thời gian ở trạng thái 'Đã giải quyết'. Đây là điểm kết thúc vòng đời của vấn đề trong Jira.
Vì sao điều này quan trọng

Đây là sự kiện kết thúc cuối cùng của quy trình. Có thể phân tích khoảng thời gian từ 'Đã giải quyết' đến 'Đã đóng' để hiểu thời gian xử lý hành chính hoặc chính sách tự động đóng.

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

Suy ra từ lịch sử vấn đề. Thời điểm tương ứng với lần chuyển trạng thái cuối cùng sang 'Đã đóng' hoặc trạng thái kết thúc tương đương.

Thu thập

Xác định thời điểm chuyển trạng thái cuối cùng sang 'Đã đóng'.

Loại sự kiện inferred
Yêu cầu dịch vụ đã giải quyết
Ghi nhận thời điểm chính thức yêu cầu được xem là hoàn tất và giải pháp được lưu lại. Jira điền trường 'Resolution Date' khi vấn đề lần đầu chuyển sang trạng thái thuộc nhóm 'Done'.
Vì sao điều này quan trọng

Đây là mốc kết thúc chính của quy trình, rất quan trọng để tính thời gian giải quyết và mức độ đáp ứng SLA. Mốc này đánh dấu lúc công việc xử lý trực tiếp kết thúc.

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

Đây là một sự kiện được ghi nhận rõ ràng. Thời điểm sự kiện là giá trị trong trường 'Resolution Date' của vấn đề Jira, được thiết lập khi vấn đề lần đầu chuyển sang trạng thái thuộc nhóm 'Done'.

Thu thập

Dùng trường 'resolutiondate' của vấn đề Jira. Trường này được tự động điền.

Loại sự kiện explicit
Yêu cầu dịch vụ được tạo
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 người dùng gửi yêu cầu chính thức qua cổng thông tin, email hoặc kênh khác. Jira ghi nhận rõ sự kiện này khi một vấn đề mới thuộc loại 'Service Request' được tạo, cùng với dấu thời gian tạo.
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 thời gian chu kỳ tổng thể và hiểu khối lượng cũng như xu hướng tiếp nhận yêu cầu.

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

Đây là sự kiện được ghi rõ trong bảng lịch sử vấn đề. Dấu thời gian của hoạt động là trường 'created' trên vấn đề Jira.

Thu thập

Dùng dấu thời gian tạo vấn đề từ bảng 'issues' hoặc lịch sử.

Loại sự kiện explicit
Yêu cầu được phân công
Hoạt động này diễn ra khi yêu cầu dịch vụ được giao cho một nhân viên hoặc nhóm cụ thể để xử lý. Jira ghi lại rõ các thay đổi trong trường 'Assignee', cung cấp dấu thời gian chính xác khi yêu cầu được phân công.
Vì sao điều này quan trọng

Đây là mốc quan trọng để đo thời gian từ phân loại đến phân công và theo dõi cách phân chia khối lượng công việc giữa các nhân viên. Mốc này đánh dấu thời điểm yêu cầu chuyển từ hàng đợi sang được xử lý.

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

Lấy từ lịch sử vấn đề bằng cách tìm lần đầu trường 'Assignee' được điền hoặc thay đổi từ trạng thái chưa phân công.

Thu thập

Dùng dấu thời gian của lần thay đổi đầu tiên trong trường 'Assignee' ở lịch sử vấn đề.

Loại sự kiện explicit
Bắt đầu làm việc với nhà cung cấp
Hoạt động này cho biết yêu cầu dịch vụ đã được chuyển cấp cho nhà cung cấp bên ngoài hoặc cần bên thứ ba xử lý. Có thể suy ra sự kiện này khi vấn đề chuyển sang trạng thái như 'Waiting for vendor' hoặc 'With Third Party'.
Vì sao điều này quan trọng

Theo dõi việc làm việc với nhà cung cấp rất quan trọng để xác định các phụ thuộc và chậm trễ bên ngoài, nằm ngoài khả năng kiểm soát trực tiếp của bộ phận dịch vụ nội bộ.

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

Suy ra từ lịch sử vấn đề. Dấu thời gian là lúc trạng thái vấn đề chuyển sang trạng thái dành riêng cho 'vendor'.

Thu thập

Xác định dấu thời gian khi trường 'status' chuyển sang giá trị như 'Waiting for Vendor'.

Loại sự kiện inferred
Đã cung cấp thông tin
Hoạt động này diễn ra khi 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ý. Có thể suy ra sự kiện này khi vấn đề rời trạng thái 'Waiting for customer', thường sau khi người gửi yêu cầu thêm bình luận.
Vì sao điều này quan trọng

Hoạt động này khép lại vòng trao đổi thông tin với khách hàng. Thời gian từ lúc yêu cầu đến khi nhận được thông tin là một phần quan trọng trong thời gian chờ của quy trình.

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

Suy ra từ lịch sử vấn đề. Dấu thời gian là lúc trạng thái vấn đề chuyển từ 'Waiting for customer' trở lại 'In Progress'.

Thu thập

Xác định dấu thời gian khi trường 'status' chuyển từ trạng thái 'waiting' trở lại trạng thái 'active'.

Loại sự kiện inferred
Đã triển khai giải pháp
Cho biết nhân viên đã thực hiện các thao tác cần thiết hoặc xây dựng giải pháp để xử lý yêu cầu dịch vụ. Sự kiện này thường được suy ra từ thay đổi trạng thái sang 'Pending Review' hoặc trực tiếp sang 'Resolved'.
Vì sao điều này quan trọng

Mốc này đánh dấu phần công việc xử lý chính đã hoàn tất. Thời gian trước hoạt động này thường là phần tạo ra giá trị chính của quy trình.

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

Suy ra từ lịch sử vấn đề, tương ứng với dấu thời gian khi trạng thái chuyển sang 'Resolved', 'Pending Acceptance' hoặc trạng thái tương tự trước khi đóng.

Thu thập

Xác định dấu thời gian khi trường 'status' chuyển sang giá trị cho biết công việc đã hoàn tất.

Loại sự kiện inferred
Kết thúc làm việc với nhà cung cấp
Đánh dấu thời điểm nhà cung cấp bên ngoài hoàn tất công việc và yêu cầu dịch vụ được chuyển lại cho nhóm nội bộ. Có thể suy ra sự kiện này khi vấn đề rời trạng thái 'Waiting for vendor'.
Vì sao điều này quan trọng

Đo thời gian làm việc với nhà cung cấp giúp quản lý hiệu suất của họ và hiểu ảnh hưởng của các bên bên ngoài đến tổng thời gian xử lý.

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

Suy ra từ lịch sử vấn đề. Dấu thời gian là lúc trạng thái vấn đề chuyển từ trạng thái 'vendor' trở lại 'In Progress'.

Thu thập

Xác định dấu thời gian khi trường 'status' chuyển từ trạng thái 'vendor' trở lại trạng thái 'active'.

Loại sự kiện inferred
Xác nhận đã xử lý xong
Hoạt động này diễn ra khi người gửi yêu cầu chính thức chấp nhận giải pháp được đề xuất, thường kích hoạt chuyển trạng thái tự động sang 'Resolved'. Sự kiện này thường được suy ra từ thay đổi trạng thái đó.
Vì sao điều này quan trọng

Mốc này xác nhận giải pháp có hiệu quả và là thời điểm dừng đồng hồ SLA. Mốc này giúp đo thời gian khách hàng cần để xác nhận đã khắc phục được vấn đề.

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

Suy ra từ lịch sử vấn đề. Dấu thời gian là lúc trạng thái chuyển từ 'Pending Customer Acceptance' sang 'Resolved' hoặc 'Closed'.

Thu thập

Xác định thời điểm trạng thái chuyển từ 'Chờ khách hàng xác nhận' sang 'Đã giải quyết' hoặc 'Đã đóng'.

Loại sự kiện inferred
Yêu cầu cung cấp thông tin
Đánh dấu thời điểm nhân viên cần người gửi yêu cầu cung cấp thêm thông tin để tiếp tục xử lý. Hoạt động này thường được suy ra khi vấn đề chuyển sang trạng thái như 'Waiting for customer' hoặc 'Pending Input'.
Vì sao điều này quan trọng

Các vòng yêu cầu cung cấp thông tin thường xuyên hoặc kéo dài có thể cho thấy nội dung gửi ban đầu chưa rõ ràng hoặc việc trao đổi chưa hiệu quả, gây chậm trễ đáng kể.

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

Suy ra từ lịch sử vấn đề. Dấu thời gian là lúc trạng thái vấn đề chuyển sang 'Waiting for customer' hoặc trạng thái tương đương.

Thu thập

Xác định dấu thời gian khi trường 'status' chuyển sang giá trị cho biết quy trình đang chờ khách hàng.

Loại sự kiện inferred
Yêu cầu được mở lại
Hoạt động này ghi nhận trường hợp yêu cầu dịch vụ đã xử lý được chuyển lại sang trạng thái đang xử lý. Có thể suy ra sự kiện này từ thay đổi trạng thái từ đã xử lý hoặc đã đóng sang đang mở hoặc đang xử lý.
Vì sao điều này quan trọng

Theo dõi yêu cầu được mở lại rất quan trọng để đo chất lượng xử lý và tỷ lệ giải quyết ngay lần đầu. Tỷ lệ mở lại cao cho thấy giải pháp chưa hiệu quả hoặc vấn đề tái diễn.

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

Suy ra từ lịch sử vấn đề bằng cách xác định trạng thái chuyển từ nhóm 'Resolved' hoặc 'Closed' sang nhóm 'Open' hoặc 'In Progress'.

Thu thập

Tìm thay đổi trạng thái từ nhóm 'Done' sang nhóm 'To Do' hoặc 'In Progress'.

Loại sự kiện inferred
Yêu cầu được phân loại
Đây là bước đánh giá ban đầu một yêu cầu dịch vụ, trong đó xác định mức độ ưu tiên, danh mục và mức độ ảnh hưởng. Hoạt động này thường được suy ra từ thay đổi trạng thái, chẳng hạn từ 'New' sang 'In Progress' hoặc sang trạng thái riêng 'Triaged'.
Vì sao điều này quan trọng

Phân tích thời gian phân loại giúp đánh giá hiệu quả của khâu tiếp nhận yêu cầu ban đầu. Chậm trễ ở bước này có thể ảnh hưởng đáng kể đến tổng thời gian xử lý và mức độ đáp ứng SLA.

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

Suy ra từ lịch sử vấn đề bằng cách xác định dấu thời gian đầu tiên khi trạng thái chuyển từ 'New' hoặc 'Open' sang trạng thái đang xử lý như 'In Progress'.

Thu thập

Xác định lần đầu trạng thái chuyển khỏi 'New' hoặc trạng thái ban đầu tương đương, dựa trên quy trình làm việc của dự án.

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ừ Jira Service Management

Bắt đầu ngay?

Dùng mẫu này để bắt đầu với process mining và cải thiện đáng kể 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.

Tối ưu quy trình quản lý yêu cầu dịch vụ trong Jira ngay

Tự động hóa 70% và chấm dứt tình trạng xử lý chậm. Nâng cao hiệu quả ngay!

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

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