Mẫu dữ liệu quản lý sự cố
Mẫu dữ liệu quản lý sự cố
- Các thuộc tính nên thu thập
- Các hoạt động cần theo dõi
- Hướng dẫn trích xuất dữ liệu từ Jira Service Management
Thuộc tính quản lý sự cố
| Tên | Mô tả | ||
|---|---|---|---|
|
Hoạt động
ActivityName
|
Tên sự kiện hoặc thay đổi trạng thái cụ thể đã xảy ra với sự cố. | ||
|
Mô tả
Hoạt động là một bước hoặc sự kiện riêng trong vòng đời quản lý sự cố, chẳng hạn như “Tạo sự cố”, “Phân công sự cố” hoặc “Đề xuất cách giải quyết”. Các hoạt động này thường được xác định từ những lần chuyển trạng thái hoặc sự kiện cập nhật được ghi trong lịch sử hay nhật ký thay đổi của vấn đề trên Jira. Phân tích trình tự và thời lượng của các hoạt động là mục tiêu chính của process mining, giúp làm rõ luồng quy trình thực tế, điểm nghẽn và các sai lệch.
Vì sao điều này quan trọng
Các hoạt động tạo nên nền tảng của sơ đồ quy trình, giúp bạn trực quan hóa và phân tích vòng đời sự cố.
Lấy dữ liệu ở đâu
Được lấy từ lịch sử vấn đề và nhật ký thay đổi của Jira, ghi lại các lần chuyển trạng thái và cập nhật những trường quan trọng.
Ví dụ
Sự cố được giao xử lýBắt đầu điều traSự cố đã được xử lý
|
|||
|
Mã sự cố
IncidentId
|
Mã định danh duy nhất của mỗi phiếu sự cố trong Jira Service Management. | ||
|
Mô tả
Mã sự cố, thường được gọi là Issue Key trong Jira, là mã định danh duy nhất cho mỗi sự cố được báo cáo. Mã này liên kết mọi hoạt động, bình luận và thay đổi trạng thái liên quan, từ lúc tạo phiếu đến khi đóng. Trong process mining, mã này giúp dựng lại toàn bộ vòng đời của từng sự cố để bạn phân tích quy trình từ đầu đến cuối.
Vì sao điều này quan trọng
Đây là mã chính dùng để liên kết mọi sự kiện liên quan thành một hồ sơ duy nhất, làm nền tảng cho mọi phân tích process mining.
Lấy dữ liệu ở đâu
Đây là trường “Key” tiêu chuẩn của một vấn đề trong Jira Service Management (ví dụ: “ITSM-123”).
Ví dụ
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Thời gian bắt đầu
EventTimestamp
|
Ngày giờ chính xác khi hoạt động diễn ra. | ||
|
Mô tả
Thuộc tính này ghi lại dấu thời gian của từng hoạt động trong vòng đời sự cố. Đây là dữ liệu cần thiết để tính thời lượng, thời gian xử lý và thời gian chờ giữa các bước. Dấu thời gian chính xác giúp phân tích hiệu suất chi tiết, theo dõi SLA và xác định điểm nghẽn. Mọi chỉ số hiệu suất, như thời gian giải quyết và thời gian chẩn đoán, đều được tính từ các dấu thời gian này.
Vì sao điều này quan trọng
Dấu thời gian cần thiết để tính các chỉ số thời gian, hiểu tổng thời lượng quy trình và tìm ra điểm nghẽn ảnh hưởng đến hiệu suất.
Lấy dữ liệu ở đâu
Đây là ngày “created” gắn với mỗi mục trong lịch sử hoặc nhật ký thay đổi của vấn đề trên Jira.
Ví dụ
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30: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 cho biết dữ liệu đến từ đâu, trong trường hợp này là Jira Service Management. Thuộc tính đặc biệt 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. Ghi rõ hệ thống nguồn giúp theo dõi nguồn gốc dữ liệu và tìm nguyên nhân khi dữ liệu có vấn đề hoặc trích xuất không thành công. Trong mô hình này, giá trị sẽ cố định.
Vì sao điều này quan trọng
Cho biết nguồn gốc dữ liệu, giúp bạn hiểu rõ và truy vết dữ liệu, nhất là khi phân tích nhiều hệ thống.
Lấy dữ liệu ở đâu
Đây là giá trị cố định, cần được thêm vào trong quá trình trích xuất dữ liệu.
Ví dụ
Jira Service ManagementJira Cloud
|
|||
|
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 thời điểm bộ dữ liệu được cập nhật gần nhất. Nhờ đó, người phân tích biết dữ liệu còn mới hay không. Điều này đặc biệt quan trọng với dashboard theo dõi liên tục, nơi thông tin cập nhật giúp bạn đưa ra quyết định kịp thời. Giá trị này thường giống nhau cho mọi sự kiện trong cùng một đợt trích xuất dữ liệu.
Vì sao điều này quan trọng
Cho người dùng biết dữ liệu được cập nhật đến thời điểm nào, yếu tố quan trọng để phân tích còn phù hợp và chính xác.
Lấy dữ liệu ở đâu
Đây là dấu thời gian của lần chạy trích xuất dữ liệu, được thêm trong quá trình chuyển đổi dữ liệu.
Ví dụ
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Mức độ ưu tiên
Priority
|
Mức độ ưu tiên được gán cho sự cố, cho biết cần giải quyết khẩn cấp đến đâu. | ||
|
Mô tả
Mức độ ưu tiên xác định tốc độ cần thiết để xử lý sự cố. Mức này thường dựa trên mức độ ảnh hưởng và tính khẩn cấp, đồng thời tác động trực tiếp đến mục tiêu SLA. Phân tích sự cố theo mức độ ưu tiên giúp bạn biết sự cố ưu tiên cao có được xử lý nhanh hơn sự cố ưu tiên thấp hay không, và việc phân loại ưu tiên có nhất quán không. Đây là tiêu chí quan trọng để lọc và so sánh hiệu suất quy trình.
Vì sao điều này quan trọng
Cần thiết để phân tích hiệu suất SLA và kiểm tra xem tài nguyên có được phân bổ phù hợp cho những sự cố nghiêm trọng nhất hay không.
Lấy dữ liệu ở đâu
Trường “Priority” tiêu chuẩn trên một vấn đề Jira.
Ví dụ
Cao nhấtCaoTrung bìnhThấp
|
|||
|
Ngày giải quyết
ResolutionDate
|
Ngày giờ sự cố được đánh dấu là đã giải quyết. | ||
|
Mô tả
Thuộc tính này ghi lại dấu thời gian khi sự cố lần đầu được chuyển sang trạng thái đã giải quyết. Mốc này đánh dấu kết thúc giai đoạn xử lý chủ động và là điểm cuối để tính thời gian giải quyết. So sánh ngày giải quyết với ngày tạo là cách chính để đo hiệu quả quy trình. Đây cũng là dữ liệu quan trọng để xác định mức độ tuân thủ SLA.
Vì sao điều này quan trọng
Đánh dấu thời điểm kết thúc quy trình giải quyết, giúp tính tổng thời gian xử lý và hiệu suất SLA.
Lấy dữ liệu ở đâu
Trường “Resolved” tiêu chuẩn trên một vấn đề Jira.
Ví dụ
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Ngày tạo
CreatedDate
|
Ngày giờ sự cố được tạo lần đầu trong hệ thống. | ||
|
Mô tả
Thuộc tính này đánh dấu thời điểm chính thức bắt đầu vòng đời sự cố. Đây là mốc thời gian cơ sở để tính các chỉ số tổng thể như tổng thời gian giải quyết. Ngày tạo là giá trị cố định của mỗi sự cố và là điểm bắt đầu của toàn bộ hồ sơ trong phân tích process mining.
Vì sao điều này quan trọng
Là mốc bắt đầu để tính thời gian xử lý từ đầu đến cuối và đo lường SLA.
Lấy dữ liệu ở đâu
Trường “Created” tiêu chuẩn trên một vấn đề Jira.
Ví dụ
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Người được giao xử lý
Assignee
|
Người dùng hiện được giao xử lý sự cố. | ||
|
Mô tả
Người được giao xử lý là nhân viên hỗ trợ hoặc người dùng chịu trách nhiệm về sự cố tại một thời điểm nhất định. Theo dõi các lần thay đổi người xử lý giúp phân tích việc bàn giao, hiểu cách phân bổ khối lượng công việc và xác định ai tham gia từng bước của quy trình. Thuộc tính này giúp trả lời các câu hỏi về hiệu suất cá nhân và phân bổ tài nguyên trong nhóm hỗ trợ.
Vì sao điều này quan trọng
Giúp theo dõi khối lượng công việc của từng người, tìm điểm nghẽn liên quan đến nhân viên hỗ trợ cụ thể và phân tích ảnh hưởng của việc bàn giao đến thời gian giải quyết.
Lấy dữ liệu ở đâu
Trường “Assignee” tiêu chuẩn trên một vấn đề Jira.
Ví dụ
John SmithEmily JonesServiceDeskAgent1
|
|||
|
Nhóm được giao xử lý
AssignmentGroup
|
Nhóm chịu trách nhiệm xử lý sự cố. | ||
|
Mô tả
Nhóm được giao xử lý là nhóm phụ trách sự cố. Đó có thể là một cấp hỗ trợ như “Bộ phận hỗ trợ L1”, nhóm chuyên môn như “Vận hành mạng” hoặc nhóm phát triển. Phân tích các lần chuyển giữa các nhóm giúp bạn hiểu rõ việc chuyển cấp và bàn giao trong quy trình. Qua đó, bạn có thể đo lường hiệu suất của nhóm, xác định điểm nghẽn ở cấp nhóm và phân tích sự phụ thuộc giữa các nhóm.
Vì sao điều này quan trọng
Cần thiết để phân tích hiệu suất nhóm, lượng công việc xử lý và luồng công việc giữa các cấp hỗ trợ hoặc nhóm chuyên môn.
Lấy dữ liệu ở đâu
Trường này thường được tạo riêng trong Jira, chẳng hạn như “Team” hoặc “Assignment Group”. Đôi khi có thể xác định từ Jira Components hoặc Project Roles.
Ví dụ
Hỗ trợ cấp 1Nhóm hạ tầngQuản trị viên cơ sở dữ liệu
|
|||
|
Trạng thái
Status
|
Giai đoạn hiện tại của sự cố trong vòng đời xử lý. | ||
|
Mô tả
Trường Status cho biết trạng thái hiện tại của sự cố trong workflow đã thiết lập, chẳng hạn như “Đang mở”, “Đang xử lý”, “Chờ khách hàng” hoặc “Đã giải quyết”. Các lần thay đổi trạng thái là nguồn chính để tạo nhật ký hoạt động cho process mining. Phân tích thời gian ở từng trạng thái là bước cơ bản để xác định điểm nghẽn và biết sự cố mất nhiều thời gian nhất ở đâu.
Vì sao điều này quan trọng
Phản ánh trực tiếp tiến độ xử lý sự cố và là nguồn chính để xác định các bước trong quy trình cũng như thời gian chờ.
Lấy dữ liệu ở đâu
Trường “Status” tiêu chuẩn trên một vấn đề Jira.
Ví dụ
Đang xử lýĐang chờ khách hàngĐã giải quyếtĐã đóng
|
|||
|
Cách giải quyết
Resolution
|
Kết quả cuối cùng hoặc lý do sự cố được chuyển sang trạng thái đã giải quyết. | ||
|
Mô tả
Trường Resolution cho biết lý do sự cố được chuyển sang trạng thái đã giải quyết. Các giá trị thường gặp gồm “Đã sửa”, “Trùng lặp”, “Không xử lý” hoặc “Không thể tái hiện”. Phân tích tỷ lệ các cách giải quyết giúp bạn hiểu chất lượng báo cáo đầu vào và hiệu quả của quy trình xử lý. Ví dụ, nhiều trường hợp được đánh dấu “Trùng lặp” có thể cho thấy vấn đề ở khâu tạo sự cố hoặc phân loại ban đầu.
Vì sao điều này quan trọng
Cho biết bối cảnh của kết quả xử lý sự cố, giúp phân loại cách giải quyết và tìm xu hướng trong cách đóng sự cố.
Lấy dữ liệu ở đâu
Trường “Resolution” tiêu chuẩn trên một vấn đề Jira. Trường này thường được thiết lập khi vấn đề chuyển sang nhóm trạng thái “Done”.
Ví dụ
Hoàn tấtĐã sửaTrùng lặpKhông sửa
|
|||
|
Có làm lại
IsRework
|
Cờ cho biết sự cố có phải xử lý lại, chẳng hạn như mở lại, hay không. | ||
|
Mô tả
Thuộc tính boolean được tính toán này xác định các sự cố bị đưa về bước trước trong quy trình, thường là do được mở lại sau khi đã giải quyết. Các vòng lặp làm lại gây lãng phí đáng kể và khiến khách hàng không hài lòng. Cờ này giúp dễ dàng tính tỷ lệ làm lại và tập trung phân tích lý do sự cố không được giải quyết đúng ngay từ lần đầu.
Vì sao điều này quan trọng
Đánh dấu các sự cố cần xử lý nhiều lần để làm rõ vấn đề về chất lượng và hiệu quả quy trình, hỗ trợ trực tiếp cho việc phân tích công việc làm lại.
Lấy dữ liệu ở đâu
Được tính bằng cách phát hiện các trình tự chuyển trạng thái cụ thể trong nhật ký sự kiện, chẳng hạn như “Đã giải quyết” -> “Đã mở lại”.
Ví dụ
truefalse
|
|||
|
Loại vấn đề
IssueType
|
Loại vấn đề, chẳng hạn như sự cố, yêu cầu dịch vụ hoặc vấn đề cần xử lý. | ||
|
Mô tả
Jira dùng Issue Types để phân biệt các loại công việc. Trong quy trình quản lý sự cố, loại chính là “Incident”, nhưng các loại khác như “Sub-task” cũng có thể liên quan. Thuộc tính này rất quan trọng để lọc bộ dữ liệu, chỉ giữ lại các sự cố và bảo đảm phân tích process mining tập trung đúng quy trình.
Vì sao điều này quan trọng
Giúp giới hạn phân tích đúng vào các sự cố, tách chúng khỏi những loại công việc khác như yêu cầu dịch vụ hoặc yêu cầu thay đổi.
Lấy dữ liệu ở đâu
Trường “Issue Type” tiêu chuẩn trên một vấn đề Jira.
Ví dụ
Sự cốHỗ trợ CNTTLỗi phần mềm
|
|||
|
Loại yêu cầu của khách hàng
CustomerRequestType
|
Loại yêu cầu cụ thể mà khách hàng gửi qua cổng dịch vụ. | ||
|
Mô tả
Trường này phân loại yêu cầu theo cách khách hàng nhìn nhận, như hiển thị trên cổng Jira Service Management (ví dụ: “Báo sự cố hệ thống”). Trường cung cấp cách phân loại dễ hiểu với người dùng, có thể khác với “Issue Type” nội bộ. Phân tích thuộc tính này giúp bạn hiểu cách khách hàng nhìn nhận và báo cáo vấn đề, từ đó cải thiện thiết kế cổng dịch vụ và các dịch vụ cung cấp.
Vì sao điều này quan trọng
Cho thấy các nhóm sự cố theo góc nhìn của khách hàng, hữu ích khi phân tích nhu cầu và cải thiện trải nghiệm khách hàng.
Lấy dữ liệu ở đâu
Trường “Customer Request Type”, chỉ có trong các dự án Jira Service Management.
Ví dụ
Nhận hỗ trợ CNTT > Báo sự cố hệ thốngEmail > Yêu cầu cấp quyền truy cập
|
|||
|
Mã vấn đề được liên kết
LinkedProblemId
|
Mã của phiếu vấn đề được liên kết với sự cố này. | ||
|
Mô tả
Sự cố là dấu hiệu của một vấn đề lớn hơn thường được liên kết với phiếu Problem. Trường này lưu mã của vấn đề liên quan. Phân tích các liên kết này giúp bạn hiểu mối quan hệ giữa sự cố và vấn đề, đo lường hiệu quả của quy trình quản lý vấn đề, đồng thời xác định các sự cố tái diễn cần được khắc phục triệt để.
Vì sao điều này quan trọng
Liên kết sự cố với vấn đề gốc, giúp phân tích mức độ hiệu quả của tổ chức trong việc xử lý nguyên nhân gốc rễ để ngăn sự cố tái diễn.
Lấy dữ liệu ở đâu
Thông tin này được lưu trong mục “Issue Links” của một vấn đề Jira.
Ví dụ
PROB-123PROB-456Không có
|
|||
|
Mức độ nghiêm trọng
Severity
|
Mức độ ảnh hưởng của sự cố đến hoạt động kinh doanh. | ||
|
Mô tả
Mức độ nghiêm trọng cho biết sự cố ảnh hưởng đến hoạt động kinh doanh nhiều đến đâu, từ việc chỉ một người dùng bị ảnh hưởng đến sự cố làm gián đoạn hệ thống trọng yếu. Mức độ ưu tiên quyết định thứ tự xử lý, còn mức độ nghiêm trọng thể hiện ảnh hưởng tổng thể đến hoạt động kinh doanh. Phân tích theo mức độ nghiêm trọng giúp bạn hiểu hiệu suất xử lý những sự cố quan trọng nhất, thường kết hợp với mức độ ưu tiên để có góc nhìn chi tiết hơn.
Vì sao điều này quan trọng
Cho thấy mức độ ảnh hưởng đến hoạt động kinh doanh, giúp tập trung phân tích vào những sự cố gây thiệt hại lớn nhất.
Lấy dữ liệu ở đâu
Thường là trường được tạo riêng trong Jira vì không có sẵn trong hệ thống. Hãy kiểm tra cấu hình dự án Jira Service Management.
Ví dụ
Nghiêm trọngLớnNhẹKhông đáng kể
|
|||
|
Mục tiêu thời gian giải quyết
TimeToResolutionTarget
|
Thời hạn SLA để giải quyết sự cố. | ||
|
Mô tả
Thuộc tính này xác định thời gian tối đa dự kiến để giải quyết sự cố thuộc một mức độ ưu tiên hoặc loại nhất định. Đây là mốc chuẩn để so sánh với thời gian giải quyết thực tế và xác định mức độ tuân thủ SLA. Giá trị thường được thiết lập linh hoạt theo các quy tắc dựa trên mức độ ưu tiên, mức độ nghiêm trọng hoặc loại vấn đề. Đây là dữ liệu thiết yếu cho mọi dashboard theo dõi hiệu suất SLA.
Vì sao điều này quan trọng
Là mốc chuẩn để đo lường mức độ tuân thủ SLA và làm cơ sở cho KPI Tỷ lệ vi phạm SLA sự cố.
Lấy dữ liệu ở đâu
Giá trị này được lấy từ cấu hình SLA trong Jira Service Management. Cần xác định mục tiêu cụ thể, chẳng hạn như “Thời gian giải quyết”.
Ví dụ
4 giờ8 giờ3 ngày
|
|||
|
Người báo sự cố
Reporter
|
Người dùng đầu tiên tạo hoặc báo cáo sự cố. | ||
|
Mô tả
Người báo sự cố là cá nhân, thường là người dùng cuối hoặc một hệ thống khác, đã ghi nhận sự cố đầu tiên. Phân tích sự cố theo người báo giúp xác định người dùng hoặc phòng ban thường gặp vấn đề. Bạn cũng có thể dùng thuộc tính này để hiểu cách trao đổi thông tin, nhất là khi phân tích các hoạt động như “Chờ khách hàng” và “Khách hàng đã phản hồi”.
Vì sao điều này quan trọng
Giúp phân tích nguồn phát sinh sự cố, tìm xu hướng liên quan đến người dùng hoặc phòng ban cụ thể và hiểu nguyên nhân khách hàng phản hồi chậm.
Lấy dữ liệu ở đâu
Trường “Reporter” tiêu chuẩn trên một vấn đề Jira.
Ví dụ
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Nhóm nguyên nhân gốc rễ
RootCauseCategory
|
Phân loại nguyên nhân gốc rễ của sự cố. | ||
|
Mô tả
Thuộc tính này ghi lại nguyên nhân cốt lõi khiến sự cố xảy ra, chẳng hạn như “Lỗi phần mềm”, “Hỏng phần cứng” hoặc “Lỗi người dùng”. Thông tin thường được điền sau khi điều tra và rất cần thiết để quản lý vấn đề hiệu quả, ngăn sự cố tái diễn. Phân tích các nhóm nguyên nhân gốc rễ giúp xác định điểm yếu mang tính hệ thống và ưu tiên các sáng kiến cải tiến. Nếu có nhiều nguyên nhân được ghi là “Không rõ”, có thể cần cải thiện quy trình điều tra.
Vì sao điều này quan trọng
Hỗ trợ phân tích nguyên nhân gốc rễ, giúp chuyển từ xử lý bị động sang chủ động bằng cách xác định và khắc phục nguồn gây ra sự cố.
Lấy dữ liệu ở đâu
Đây hầu như luôn là trường được tạo riêng trong Jira. Tên và các lựa chọn phụ thuộc nhiều vào cấu hình cụ thể của tổ chức.
Ví dụ
Lỗi cấu hìnhMất kết nối mạngLỗi phần mềm
|
|||
|
Số lần bàn giao
HandoffCount
|
Số lần sự cố được chuyển cho nhóm hoặc người dùng khác. | ||
|
Mô tả
Chỉ số được tính toán này đếm số lần trường “Assignee” hoặc “AssignmentGroup” thay đổi trong vòng đời sự cố. Số lần bàn giao cao thường cho thấy quy trình kém hiệu quả, không giải quyết được ngay từ lần liên hệ đầu tiên hoặc thiếu kiến thức, dẫn đến thời gian giải quyết lâu hơn. Phân tích KPI này giúp tinh gọn quy trình phân công và cải thiện phối hợp giữa các nhóm.
Vì sao điều này quan trọng
Đo lường trở ngại và sự kém hiệu quả do việc phân công lại, giúp xác định cơ hội cải tiến quy trình.
Lấy dữ liệu ở đâu
Được tính bằng cách đếm số lần trường “Assignee” hoặc “AssignmentGroup” thay đổi trong nhật ký thay đổi của vấn đề.
Ví dụ
015
|
|||
|
Thành phần
Component
|
Hệ thống, ứng dụng hoặc phần hạ tầng bị ảnh hưởng bởi sự cố. | ||
|
Mô tả
Components là các phần nhỏ trong một dự án Jira, dùng để nhóm vấn đề theo từng khu vực như “Giao diện người dùng”, “Cơ sở dữ liệu” hoặc “API”. Phân tích sự cố theo thành phần giúp xác định phần nào của hệ thống thường phát sinh vấn đề nhất. Thông tin này hữu ích cho việc phân tích nguyên nhân gốc rễ, cải thiện dịch vụ và giảm nợ kỹ thuật.
Vì sao điều này quan trọng
Cho phép lọc và phân tích theo sản phẩm hoặc khu vực hệ thống bị ảnh hưởng, giúp xác định các điểm nóng về công nghệ.
Lấy dữ liệu ở đâu
Trường “Components” tiêu chuẩn trên một vấn đề Jira.
Ví dụ
Dịch vụ xác thựcDashboard báo cáoỨng dụng di động
|
|||
|
Vi phạm SLA
SlaBreach
|
Cờ cho biết thời gian giải quyết sự cố có vượt mục tiêu SLA hay không. | ||
|
Mô tả
Thuộc tính boolean được tính toán này cho biết sự cố có vi phạm SLA “Time to Resolution” hay không. Giá trị là true nếu “IncidentResolutionCycleTime” lớn hơn “TimeToResolutionTarget”. Cờ này giúp đơn giản hóa việc phân tích và trực quan hóa, cho phép lọc và tổng hợp dữ liệu dễ dàng để tính KPI Tỷ lệ vi phạm SLA tổng thể. Đây là chỉ số kết quả chính trên dashboard Theo dõi hiệu suất SLA.
Vì sao điều này quan trọng
Cho biết rõ kết quả đạt hay vi phạm SLA, giúp dễ tính tỷ lệ vi phạm và xác định khu vực cần xử lý.
Lấy dữ liệu ở đâu
Được tính bằng ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
Ví dụ
truefalse
|
|||
Hoạt động quản lý sự cố
| Hoạt động | Mô tả | ||
|---|---|---|---|
|
Bắt đầu điều tra
|
Cho biết nhân viên được giao đã bắt đầu chủ động chẩn đoán sự cố. Thông thường, sự kiện này được suy ra khi trạng thái vấn đề chuyển từ 'Open' hoặc 'New' sang 'In Progress'. | ||
|
Vì sao điều này quan trọng
Cột mốc quan trọng này đánh dấu thời điểm bắt đầu nỗ lực xử lý thực tế. Đo thời gian đến hoạt động này giúp xác định chậm trễ ban đầu do xếp hàng và vấn đề về khả năng sẵn sàng của tài nguyên.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử thay đổi trạng thái của vấn đề. Dấu thời gian sự kiện là lúc trạng thái chuyển sang trạng thái thể hiện công việc đang được thực hiện, chẳng hạn như 'In Progress'.
Thu thập
Xác định dấu thời gian khi trạng thái chuyển sang 'In Progress'.
Loại sự kiện
inferred
|
|||
|
Chờ khách hàng
|
Đánh dấu thời điểm nhóm hỗ trợ đang chờ khách hàng cung cấp thông tin hoặc thực hiện hành động. Sự kiện này được suy ra từ việc trạng thái chuyển sang trạng thái chờ riêng, chẳng hạn như 'Waiting for customer'. | ||
|
Vì sao điều này quan trọng
Tách riêng khoảng thời gian 'tạm dừng' này rất quan trọng để đo SLA chính xác, vì thời gian chờ thường không được tính vào thời gian xử lý. Qua đó, bạn có thể phân tích chậm trễ trong phản hồi của khách hàng.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử thay đổi trạng thái của vấn đề. Sự kiện tương ứng với dấu thời gian khi trạng thái chuyển sang 'Waiting for customer' hoặc trạng thái tương tự.
Thu thập
Xác định dấu thời gian khi trạng thái chuyển sang 'Waiting for customer'.
Loại sự kiện
inferred
|
|||
|
Chuyển sự cố cho người khác
|
Sự kiện này xảy ra khi sự cố được chuyển từ nhân viên hoặc nhóm này sang nhân viên hoặc nhóm khác sau lần giao xử lý ban đầu. Sự kiện được suy ra từ mọi thay đổi của trường 'Assignee' hoặc 'Assigned Group'. | ||
|
Vì sao điều này quan trọng
Theo dõi việc chuyển giao lại rất quan trọng để phân tích khâu bàn giao. Nhiều lần chuyển giao lại thường cho thấy quy trình kém hiệu quả, thiếu kiến thức hoặc định tuyến ban đầu chưa đúng, khiến thời gian xử lý kéo dài.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử vấn đề bằng cách phát hiện mọi cập nhật của trường 'Assignee' sau lần đầu trường này được điền. Mỗi thay đổi được tính là một lần chuyển giao lại.
Thu thập
Tìm các thay đổi tiếp theo của trường 'Assignee' sau lần giao xử lý ban đầu.
Loại sự kiện
inferred
|
|||
|
Đề xuất giải pháp
|
Hoạt động này cho biết giải pháp đã được xác định và áp dụng, và sự cố đang chờ xác nhận hoặc kiểm tra cuối cùng. Sự kiện được suy ra từ việc trạng thái chuyển sang 'Resolved'. | ||
|
Vì sao điều này quan trọng
Đây là cột mốc quan trọng, đánh dấu thời điểm nhóm hỗ trợ kết thúc công việc xử lý trực tiếp. Sự kiện này thường cũng là lúc đồng hồ SLA dừng lại.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử thay đổi trạng thái của vấn đề. Dấu thời gian sự kiện là lúc trạng thái chuyển sang 'Resolved' hoặc trạng thái tương đương.
Thu thập
Xác định dấu thời gian khi trạng thái chuyển sang 'Resolved'.
Loại sự kiện
inferred
|
|||
|
Đóng sự cố
|
Cho biết phiếu sự cố đã được đóng chính thức sau khi sự cố được xử lý và xác minh. Sự kiện này được suy ra từ việc trạng thái chuyển sang 'Closed'. | ||
|
Vì sao điều này quan trọng
Đây là sự kiện kết thúc quy trình. Phân tích thời gian từ 'Resolved' đến 'Closed' giúp phát hiện chậm trễ trong khâu hoàn tất thủ tục hoặc chờ người dùng xác nhận.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử thay đổi trạng thái của vấn đề. Sự kiện tương ứng với dấu thời gian khi trạng thái chuyển sang trạng thái cuối cùng 'Closed'.
Thu thập
Xác định dấu thời gian khi trạng thái chuyển sang 'Closed'.
Loại sự kiện
inferred
|
|||
|
Sự cố đã được xử lý
|
Hoạt động này xác nhận sự cố đã được xử lý thành công và dịch vụ đã khôi phục. Sự kiện thường trùng với thời điểm trạng thái chuyển sang 'Resolved'. | ||
|
Vì sao điều này quan trọng
Đây là cột mốc chính đánh dấu thành công của quy trình. Thời gian đến thời điểm này là KPI phổ biến nhất, thể hiện thời gian xử lý (TTR).
Lấy dữ liệu ở đâu
Suy ra từ thay đổi trạng thái sang 'Resolved'. Trong nhiều workflow, sự kiện này trùng với 'Resolution Proposed' và thể hiện thời điểm xử lý chính.
Thu thập
Xác định dấu thời gian khi trạng thái chuyển sang 'Resolved'.
Loại sự kiện
inferred
|
|||
|
Sự cố được tạo
|
Đánh dấu thời điểm chính thức bắt đầu vòng đời sự cố, khi có báo cáo sự cố và một vấn đề mới được tạo trong Jira. Hệ thống ghi nhận rõ sự kiện này khi một vấn đề thuộc loại 'Incident' được 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. Phân tích 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
Đây là sự kiện được ghi nhận rõ từ dấu thời gian 'created' của vấn đề sự cố trong Jira. Lịch sử vấn đề lưu lại sự kiện tạo mới.
Thu thập
Dùng dấu thời gian tạo vấn đề.
Loại sự kiện
explicit
|
|||
|
Chuyển cấp cho nhóm chuyên trách
|
Cho biết sự cố đã được chuyển cấp đến nhóm chuyên trách, chẳng hạn như Tier 2 hoặc nhóm phát triển, để được hỗ trợ chuyên sâu. Sự kiện này được suy ra từ thay đổi của trường 'Support Team' tùy chỉnh hoặc một lần chuyển giao cụ thể. | ||
|
Vì sao điều này quan trọng
Làm rõ những sự cố cần kiến thức chuyên môn và theo dõi luồng chuyển giao giữa các cấp hỗ trợ. Qua đó, bạn có thể xác định điểm nghẽn trong nhóm chuyên trách và phân tích cách chuyển cấp.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử vấn đề bằng cách theo dõi thay đổi của trường tùy chỉnh thể hiện nhóm được giao xử lý, hoặc phát hiện trường 'Assignee' được đổi sang thành viên của nhóm chuyên trách đã biết.
Thu thập
Phát hiện thay đổi trong trường tùy chỉnh 'Assigned Team' hoặc các thay đổi cụ thể của người được giao xử lý.
Loại sự kiện
inferred
|
|||
|
Đã cung cấp giải pháp tạm thời
|
Cho biết giải pháp tạm thời đã được áp dụng để khôi phục dịch vụ trong khi xây dựng giải pháp lâu dài. Sự kiện này có thể được suy ra từ thay đổi trạng thái hoặc một bình luận cụ thể. | ||
|
Vì sao điều này quan trọng
Đo thời gian cung cấp giải pháp tạm thời là chỉ số quan trọng cho biết tốc độ khôi phục dịch vụ. Qua đó, bạn có thể phân biệt biện pháp giảm thiểu tạm thời với giải pháp xử lý triệt để.
Lấy dữ liệu ở đâu
Sự kiện này thường được suy ra. Có thể dựa vào việc trạng thái chuyển sang 'Workaround Provided' hoặc một bình luận công khai có từ khóa cụ thể như 'workaround'.
Thu thập
Tìm một thay đổi trạng thái cụ thể hoặc từ khóa trong bình luận.
Loại sự kiện
inferred
|
|||
|
Khách hàng đã phản hồi
|
Cho biết khách hàng đã cung cấp thông tin được yêu cầu và sự cố có thể tiếp tục được xử lý. Sự kiện này được suy ra khi trạng thái chuyển khỏi 'Waiting for customer' về trạng thái đang xử lý. | ||
|
Vì sao điều này quan trọng
Hoạt động này đánh dấu thời điểm kết thúc chậm trễ do khách hàng. Phân tích khoảng thời gian từ 'Waiting For Customer' đến sự kiện này giúp xác định thời gian phản hồi trung bình của khách hàng.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử thay đổi trạng thái của vấn đề. Sự kiện xảy ra khi trạng thái chuyển từ 'Waiting for customer' sang trạng thái như 'In Progress', thường sau khi khách hàng thêm bình luận.
Thu thập
Phát hiện thay đổi trạng thái từ 'Waiting for customer' sang 'In Progress'.
Loại sự kiện
inferred
|
|||
|
Liên kết với phiếu vấn đề
|
Sự kiện này xảy ra khi sự cố được liên kết với vấn đề thuộc loại 'Problem' để phân tích nguyên nhân gốc rễ. Đây là sự kiện được ghi nhận rõ khi tạo liên kết 'relates to' hoặc 'caused by' với vấn đề thuộc loại Problem. | ||
|
Vì sao điều này quan trọng
Theo dõi liên kết này giúp hiểu tổ chức chuyển từ giảm thiểu sự cố sang phân tích nguyên nhân gốc rễ và phòng ngừa hiệu quả đến đâu.
Lấy dữ liệu ở đâu
Đây là sự kiện được ghi rõ trong lịch sử liên kết của vấn đề. Mỗi lần tạo liên kết đều có dấu thời gian và có thể lọc theo liên kết đến vấn đề thuộc loại 'Problem'.
Thu thập
Dùng dấu thời gian tạo liên kết đến vấn đề thuộc loại 'Problem'.
Loại sự kiện
explicit
|
|||
|
Mở lại sự cố
|
Cho biết sự cố đã xử lý trước đó được kích hoạt lại vì vấn đề tái diễn hoặc giải pháp không hiệu quả. Sự kiện này được suy ra khi trạng thái chuyển từ 'Resolved' hoặc 'Closed' về trạng thái đang mở. | ||
|
Vì sao điều này quan trọng
Sự cố được mở lại là thước đo trực tiếp về chất lượng xử lý và là dấu hiệu chính cho thấy phải làm lại. Phân tích các sự kiện này giúp phát hiện trường hợp đóng quá sớm và giải pháp không hiệu quả.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử thay đổi trạng thái của vấn đề. Sự kiện được ghi nhận khi trạng thái chuyển từ trạng thái kết thúc như 'Resolved' hoặc 'Closed' về 'Open' hoặc 'In Progress'.
Thu thập
Phát hiện thay đổi trạng thái từ 'Resolved' hoặc 'Closed' sang trạng thái đang mở.
Loại sự kiện
inferred
|
|||
|
Sự cố được giao xử lý
|
Hoạt động này đánh dấu lần đầu sự cố được giao cho nhân viên hoặc nhóm hỗ trợ xử lý. Hệ thống ghi nhận bằng cách theo dõi lần đầu trường 'Assignee' hoặc 'Assigned Group' được điền. | ||
|
Vì sao điều này quan trọng
Đo thời gian phản hồi và giao xử lý ban đầu, một thành phần quan trọng trong các chỉ số SLA. Qua đó, bạn có thể xác định chậm trễ trước khi bắt đầu điều tra.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử vấn đề bằng cách tìm thay đổi đầu tiên của trường 'Assignee' khi giá trị trước đó là 'Unassigned'.
Thu thập
Tìm lần cập nhật đầu tiên của trường 'Assignee' trong lịch sử vấn đề.
Loại sự kiện
inferred
|
|||
|
Sự cố được phân loại ưu tiên
|
Cho biết mức ưu tiên và/hoặc mức độ nghiêm trọng của sự cố, từ đó xác định tính cấp bách và ảnh hưởng đến hoạt động kinh doanh. Thông thường, sự kiện này được suy ra từ lần đầu các trường 'Priority' hoặc 'Severity' được điền hay cập nhật sau khi tạo sự cố. | ||
|
Vì sao điều này quan trọng
Theo dõi việc phân loại ưu tiên giúp đánh giá sự cố có được xem xét kịp thời và nhất quán hay không. Chậm trễ ở bước này có thể ảnh hưởng trực tiếp đến việc tính SLA và phân bổ tài nguyên.
Lấy dữ liệu ở đâu
Suy ra từ nhật ký lịch sử vấn đề, nơi ghi lại thay đổi của mọi trường. Tìm lần cập nhật đầu tiên cho trường 'Priority' hoặc trường 'Severity' tùy chỉnh sau khi tạo vấn đề.
Thu thập
Tìm thay đổi đầu tiên của trường 'Priority' trong lịch sử vấn đề.
Loại sự kiện
inferred
|
|||
|
Thêm bình luận
|
Cho biết người dùng đã thêm bình luận vào phiếu sự cố để trao đổi hoặc ghi chú. Đây là sự kiện được ghi nhận rõ mỗi khi có bình luận mới. | ||
|
Vì sao điều này quan trọng
Phân tích tần suất bình luận giúp hiểu cách trao đổi thông tin, hiệu quả phối hợp và mức độ phức tạp của sự cố. Qua đó, bạn có thể phát hiện những sự cố cần trao đổi quá nhiều.
Lấy dữ liệu ở đâu
Đây là sự kiện được ghi nhận rõ. Jira lưu dấu thời gian và tác giả của từng bình luận, có thể xem trong lịch sử bình luận của vấn đề hoặc qua API.
Thu thập
Dùng dấu thời gian của từng bình luận được thêm vào vấn đề.
Loại sự kiện
explicit
|
|||
Hướng dẫn trích xuất dữ liệu
Bắt đầu ngay?
Dùng mẫu dữ liệu này để cải thiện quy trình quản lý sự cố, tìm ra điểm chưa hiệu quả và rút ngắn thời gian xử lý. Bắt đầu tối ưu quy trình ngay hôm nay.
Cải thiện quy trình quản lý sự cố, xử lý nhanh hơn
Giảm MTTR 35% và nâng cao mức độ hài lòng của người dùng nhờ quy trình được tinh gọn.
Không cần thẻ tín dụng • Thiết lập trong 5 phút