> Cải tiến quy trình liên tục > Quản lý thay đổi > Jira Service Management > Mẫu dữ liệu

Mẫu dữ liệu quản lý thay đổi

Jira Service Management

Thuộc tính quản lý thay đổi(19) Hoạt động quản lý thay đổi(13) Hướng dẫn trích xuất dữ liệu(3)

Mẫu dữ liệu quản lý thay đổi

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 quản lý thay đổi. Tài liệu nêu các thuộc tính thiết yếu, hoạt động chính cần theo dõi và cách trích xuất dữ liệu từ Jira Service Management. Dùng tài nguyên này để tạo nhật ký sự kiện chính xác và hiểu rõ hơn quy trình thay đổi của bạn.

Các thuộc tính nên thu thập
Các hoạt động chính cần theo dõi trong 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.

Tải mẫu xuống

Thuộc tính quản lý thay đổi

Đâ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ý thay đổi một cách đầy đủ.

5 Bắt buộc 7 Nên có 7 Không bắt buộc

	Tên	Mô tả
	Hoạt động ActivityName	Tên của một sự kiện nghiệp vụ hoặc tác vụ cụ thể diễn ra trong quy trình quản lý thay đổi.
Mô tả Thuộc tính này ghi lại tên hoạt động diễn ra tại một thời điểm cụ thể trong yêu cầu thay đổi. Hoạt động được xác định từ các lần chuyển trạng thái, bước trong quy trình làm việc hoặc mục nhật ký cụ thể trên Jira, chẳng hạn như 'Đã gửi thay đổi để xem xét' hoặc 'Đã bắt đầu triển khai'. Phân tích trình tự và tần suất của các hoạt động là trọng tâm của process mining. Việc này giúp khám phá các luồng quy trình thực tế, xác định điểm nghẽn giữa các bước và phân tích các biến thể so với quy trình vận hà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 trong quy trình, làm cơ sở để khám phá sơ đồ quy trình, phân tích các biến thể và xác định điểm nghẽn. Lấy dữ liệu ở đâu Thông thường, dữ liệu được lấy từ lịch sử issue Jira, cụ thể là các lần chuyển trạng thái hoặc cập nhật trường tùy chỉnh thể hiện các cột mốc của quy trình. Ví dụ Đã phê duyệt yêu cầu thay đổiĐã đánh giá rủi roĐã triển khai thay đổiĐã hoàn tất đánh giá sau triển khai
	Mã yêu cầu thay đổi ChangeRequestId	Mã định danh duy nhất của một trường hợp yêu cầu thay đổi, liên kết mọi hoạt động liên quan từ lúc tạo đến khi đóng.
Mô tả Mã yêu cầu thay đổi là khóa chính dùng để nhận diện duy nhất từng sáng kiến thay đổi trong Jira Service Management. Mã này đóng vai trò định danh trường hợp cho process mining, liên kết mọi sự kiện, thay đổi trạng thái và cập nhật thành một bức tranh quy trình xuyên suốt. Khi phân tích, mã này cho phép tái dựng toàn bộ vòng đời của từng thay đổi. Mã rất cần thiết để theo dõi từng thay đổi qua các giai đoạn như đánh giá rủi ro, phê duyệt, triển khai và xem xét. Mọi chỉ số, KPI và dashboard đều dựa vào thuộc tính này để tổng hợp và liên kết chính xác dữ liệu sự kiện của từng thay đổi. Vì sao điều này quan trọng Đây là mã định danh trường hợp cơ bản, giúp theo dõi toàn bộ hành trình của yêu cầu thay đổi và phân tích hiệu suất. Lấy dữ liệu ở đâu Đây là Jira Issue Key tiêu chuẩn, nằm trong trường `key` của các issue thuộc loại yêu cầu thay đổi. Ví dụ ITSM-1024CHG-2023-001CR-5921
	Thời gian bắt đầu EventTime	Dấu thời gian chính xác cho biết một hoạt động hoặc sự kiện cụ thể đã diễn ra khi nào.
Mô tả Thời gian bắt đầu, hay dấu thời gian sự kiện, cho biết chính xác ngày giờ một hoạt động được ghi nhận trong yêu cầu thay đổi. Mỗi hoạt động trong nhật ký sự kiện, từ lúc tạo đến khi đóng, đều có dấu thời gian tương ứng. Thuộc tính này rất quan trọng đối với mọi phân tích thời gian trong process mining. Thuộc tính được dùng để tính thời gian chu kỳ, khoảng thời gian giữa các hoạt động, thời gian chờ và xác định trình tự sự kiện. Đây là cơ sở để theo dõi hiệu suất, tính mức độ đáp ứng SLA và xác định điểm nghẽn. Vì sao điều này quan trọng Dấu thời gian này là cơ sở cho mọi phân tích hiệu suất và thời lượng, giúp tính thời gian chu kỳ và xác định chậm trễ. Lấy dữ liệu ở đâu Dấu thời gian của từng mục trong nhật ký lịch sử issue Jira. Với sự kiện tạo, đây là trường `created`. Ví dụ 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-05T09:00:00Z
	Hệ thống nguồn SourceSystem	Cho biết hệ thống đã trích xuất dữ liệu quản lý thay đổi.
Mô tả Thuộc tính này cho biết hệ thống nguồn của dữ liệu quy trình. Trong trường hợp này, giá trị luôn là 'Jira Service Management'. Trong phạm vi doanh nghiệp rộng hơn, khi dữ liệu có thể được gộp từ nhiều hệ thống, trường này rất quan trọng để truy xuất nguồn gốc dữ liệu, xử lý sự cố và hiểu các khác biệt về quy trình giữa các hệ thống. Trường này giúp xác định rõ nguồn gốc của dữ liệu đang được phân tích. Vì sao điều này quan trọng Giúp xác định rõ nguồn gốc dữ liệu, điều cần thiết khi kết hợp dữ liệu từ nhiều hệ thống hoặc phục vụ kiểm toán. Lấy dữ liệu ở đâu Đây là giá trị tĩnh được thêm trong quá trình trích xuất dữ liệu để ghi nhãn nguồn gốc của bộ dữ liệu. Ví dụ Jira Service Management
	Lần cập nhật dữ liệu gần nhất LastDataUpdate	Dấu thời gian cho biết lần gần nhất dữ liệu của bản ghi này được làm mới hoặc trích xuất.
Mô tả Thuộc tính này ghi lại ngày giờ dữ liệu được lấy lần gần nhất từ hệ thống nguồn. Thuộc tính cho biết mức độ cập nhật của dữ liệu trong công cụ process mining. Phân tích thuộc tính này giúp người dùng biết dữ liệu quy trình mới đến đâu, điều quan trọng đối với dashboard vận hành và việc theo dõi theo thời gian thực. Thông tin này bổ sung bối cảnh cho phân tích, giúp tránh đưa ra quyết định dựa trên dữ liệu đã cũ. 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 vẫn phù hợp và 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 được công cụ trích xuất dữ liệu điền vào khi lấy dữ liệu. Ví dụ 2024-01-15T02:00:00Z2024-01-16T02:00:00Z
	Loại thay đổi ChangeRequestType	Phân loại thay đổi, chẳng hạn như Tiêu chuẩn, Thông thường hoặc Khẩn cấp.
Mô tả Loại thay đổi phân nhóm yêu cầu dựa trên tính chất, mức độ khẩn cấp và ảnh hưởng của thay đổi. Các loại thường gặp gồm 'Tiêu chuẩn' cho thay đổi ít rủi ro đã được phê duyệt trước, 'Thông thường' cho thay đổi định kỳ cần được phê duyệt đầy đủ và 'Khẩn cấp' cho thay đổi cần xử lý gấp để khắc phục sự cố. Thuộc tính này rất quan trọng khi phân tích quy trình, vì mỗi loại thay đổi thường đi theo một luồng xử lý riêng và có SLA khác nhau. Bạn có thể dùng thuộc tính này để tính KPI 'Tỷ lệ thay đổi khẩn cấp' và lọc bảng điều khiển nhằm so sánh hiệu suất cũng như rủi ro của từng loại. Vì sao điều này quan trọng Thuộc tính này giúp chia quy trình thành từng nhóm để phân tích các quy trình làm việc khác nhau, chẳng hạn như thay đổi tiêu chuẩn và thay đổi khẩn cấp, vốn có kỳ vọng về hiệu suất và mức độ rủi ro riêng. Lấy dữ liệu ở đâu Đây thường là trường tùy chỉnh trong các dự án Jira Service Management. Tên trường có thể khác nhau, nhưng thường là 'Loại thay đổi'. Ví dụ Tiêu chuẩnThông thườngKhẩn cấp
	Mức độ rủi ro RiskLevel	Mức độ rủi ro được đánh giá cho thay đổi, chẳng hạn như Thấp, Trung bình hoặc Cao.
Mô tả Trong hầu hết quy trình quản lý thay đổi, mức độ rủi ro là thông tin bắt buộc để phân loại tác động tiêu cực tiềm ẩn của một thay đổi. Mức độ này được xác định trong giai đoạn đánh giá rủi ro và thường ảnh hưởng đến quy trình phê duyệt cần áp dụng. Trong process mining, thuộc tính này rất quan trọng để phân tích dựa trên rủi ro. Thuộc tính này hỗ trợ bảng điều khiển 'Độ chính xác và kết quả đánh giá rủi ro' bằng cách đối chiếu rủi ro ban đầu với kết quả thực tế. Đây cũng là chiều phân tích chính của KPI 'Tỷ lệ thay đổi thất bại theo mức độ rủi ro', giúp đánh giá hiệu quả quản lý các thay đổi rủi ro cao. Vì sao điều này quan trọng Thuộc tính này giúp đánh giá các biện pháp kiểm soát và quy trình phê duyệt có hiệu quả với từng mức độ rủi ro hay không, đồng thời đối chiếu rủi ro với tỷ lệ thay đổi thất bại. Lấy dữ liệu ở đâu Đây thường là trường tùy chỉnh trong Jira Service Management. Tên thường dùng gồm 'Mức độ rủi ro' hoặc 'Ảnh hưởng'. Ví dụ ThấpTrung bìnhCaoNghiêm trọng
	Mức độ ưu tiên Priority	Mức độ ưu tiên của yêu cầu thay đổi, thể hiện tầm quan trọng đối với hoạt động kinh doanh.
Mô tả Trường Mức độ ưu tiên giúp các nhóm xác định thứ tự xử lý yêu cầu thay đổi. Trường này phản ánh sự kết hợp giữa mức độ ảnh hưởng và tính cấp bách, đồng thời định hướng việc sắp xếp lịch và phân bổ tài nguyên. Phân tích mức độ ưu tiên giúp so sánh hiệu suất giữa các thay đổi ưu tiên cao và thấp. Chẳng hạn, bạn có thể kiểm tra xem thay đổi ưu tiên cao có thực sự hoàn tất nhanh hơn không, hay vẫn mắc ở những điểm nghẽn như các thay đổi khác. Thông tin này giúp phân bổ nguồn lực hợp lý và đáp ứng kỳ vọng của doanh nghiệp. Vì sao điều này quan trọng Thuộc tính này cho phép phân tích hiệu suất quy trình theo mức độ ưu tiên của doanh nghiệp, để kiểm tra các thay đổi quan trọng có được xử lý nhanh như kỳ vọng hay không. Lấy dữ liệu ở đâu Đây là trường `priority` tiêu chuẩn của một issue trong Jira. Ví dụ Cao nhấtCaoTrung bìnhThấp
	Ngày hoàn tất mục tiêu TargetCompletionDate	Thời hạn dự kiến hoặc thời hạn theo Thỏa thuận mức dịch vụ (SLA) để hoàn tất yêu cầu thay đổi.
Mô tả Thuộc tính này lưu ngày dự kiến hoàn tất yêu cầu thay đổi để đáp ứng SLA. Đây là mốc dùng để so sánh với thời gian hoàn tất thực tế. Ngày này là cơ sở để theo dõi việc thực hiện cam kết. Thuộc tính này được dùng trong bảng điều khiển 'Theo dõi hiệu suất SLA của thay đổi' và KPI 'Tỷ lệ đáp ứng SLA của thay đổi'. Bằng cách so sánh ngày xử lý thực tế với ngày mục tiêu, tổ chức có thể đo lường hiệu quả cung cấp dịch vụ. Vì sao điều này quan trọng Đây là dữ liệu chính để tính mức độ đáp ứng SLA và xác định những thay đổi có nguy cơ trễ hạn. Lấy dữ liệu ở đâu Đây thường là trường `duedate` trong Jira hoặc giá trị từ chỉ số SLA được cấu hình trong Jira Service Management. Ví dụ 2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T09:00:00Z
	Người được giao Assignee	Người dùng hiện chịu trách nhiệm xử lý yêu cầu thay đổi.
Mô tả Người được giao là người dùng chịu trách nhiệm cho bước hoặc hoạt động hiện tại trong quy trình quản lý thay đổi. Người được giao có thể thay đổi nhiều lần trong suốt vòng đời của yêu cầu, khi yêu cầu được chuyển giữa các cá nhân và nhóm. Thuộc tính này giúp phân tích cách phân bổ khối lượng công việc, xác định điểm nghẽn ở từng người dùng và hiểu cách phân bổ tài nguyên. Bảng điều khiển 'Khối lượng công việc theo hoạt động của nhóm thay đổi' dùng dữ liệu này để cho biết cá nhân hoặc nhóm nào đang xử lý nhiều hoạt động nhất. Vì sao điều này quan trọng Thuộc tính này giúp phân tích hiệu suất và khối lượng công việc, đồng thời xác định điểm nghẽn ở từng cá nhân hoặc nhóm. Lấy dữ liệu ở đâu Đây là trường `assignee` tiêu chuẩn của một issue trong Jira. Ví dụ Alice JohnsonBob WilliamsCharlie Brown
	Trạng thái SLA SLAStatus	Cho biết yêu cầu thay đổi có được hoàn tất trước ngày mục tiêu hay không.
Mô tả Đây là thuộc tính được tính bằng cách so sánh ngày xử lý thực tế của yêu cầu thay đổi với 'Ngày hoàn tất mục tiêu'. Kết quả là một trạng thái đơn giản, chẳng hạn như 'Đạt' hoặc 'Quá hạn'. Trạng thái này giúp bạn nhanh chóng nắm được hiệu suất trên bảng điều khiển 'Theo dõi hiệu suất SLA của thay đổi'. Việc tính sẵn trạng thái cho từng trường hợp cũng giúp tạo KPI như 'Tỷ lệ đáp ứng SLA của thay đổi' dễ dàng hơn. Bạn có thể lọc và tổng hợp dữ liệu để xem loại thay đổi, nhóm hoặc dịch vụ nào thường không đáp ứng SLA nhất. Vì sao điều này quan trọng Thuộc tính này cho biết rõ từng trường hợp có đáp ứng SLA hay không, giúp đơn giản hóa việc báo cáo và phân tích mức độ đáp ứng SLA. Lấy dữ liệu ở đâu Được tính bằng cách so sánh dấu thời gian của hoạt động 'Đóng yêu cầu thay đổi' cuối cùng với thuộc tính 'TargetCompletionDate'. Ví dụ ĐạtQuá hạn
	Trạng thái thay đổi ChangeRequestStatus	Trạng thái hiện tại hoặc trạng thái trong quá khứ của yêu cầu thay đổi tại thời điểm sự kiện diễn ra.
Mô tả Thuộc tính này cho biết trạng thái của yêu cầu thay đổi, chẳng hạn như 'Chờ phê duyệt', 'Đang thực hiện' hoặc 'Đã đóng'. Trường trạng thái trong Jira là thành phần cốt lõi của workflow, và các thay đổi ở trường này là yếu tố chính làm quy trình chuyển sang bước tiếp theo. Phân tích trạng thái giúp theo dõi tiến độ của các yêu cầu đang xử lý và hiểu kết quả của những yêu cầu đã hoàn tất, chẳng hạn như 'Đã đóng - Thành công' và 'Đã đóng - Thất bại'. Đây cũng là dữ liệu quan trọng để tạo bảng điều khiển về thông lượng và phân tích các vòng lặp làm lại, khi trạng thái quay về bước trước đó. Vì sao điều này quan trọng Thuộc tính này cho thấy rõ tiến độ và kết quả cuối cùng của một yêu cầu thay đổi, rất cần thiết để phân tích thông lượng và công việc phải làm lại. Lấy dữ liệu ở đâu Đây là trường `status` tiêu chuẩn của một issue trong Jira. Các trạng thái có thể dùng được xác định trong cấu hình workflow của dự án. Ví dụ Lập kế hoạchChờ phê duyệtĐang triển khaiĐã đóngĐã hủy
	Có làm lại IsRework	Giá trị đúng/sai cho biết yêu cầu thay đổi có trải qua vòng lặp làm lại hay không.
Mô tả Thuộc tính được tính toán này xác định các yêu cầu thay đổi bị trả về bước trước để chỉnh sửa, chẳng hạn như chuyển từ 'Chờ phê duyệt' về 'Lập kế hoạch'. Điều này cho thấy thông tin gửi ban đầu chưa đầy đủ, chưa chính xác hoặc chưa đáp ứng tiêu chí cần thiết. Cờ này là cơ sở để tính KPI 'Tỷ lệ thay đổi phải làm lại' và tạo bảng điều khiển 'Phân tích việc làm lại và từ chối thay đổi'. Khi đánh dấu các trường hợp phải làm lại, chuyên viên phân tích có thể dễ dàng lọc và tìm nguyên nhân gốc, chẳng hạn như lập kế hoạch ban đầu chưa tốt, yêu cầu chưa rõ hoặc đánh giá rủi ro chưa đầy đủ. Vì sao điều này quan trọng Thuộc tính này làm rõ những trường hợp phát sinh công việc ngoài kế hoạch, giúp phát hiện điểm kém hiệu quả trong quy trình và phân tích nguyên nhân gốc của việc làm lại. Lấy dữ liệu ở đâu Được tính bằng cách phân tích thứ tự hoạt động trong nhật ký sự kiện. Hệ thống phát hiện việc làm lại khi một hoạt động ở giai đoạn sau được tiếp nối bởi hoạt động ở giai đoạn trước. Ví dụ truefalse
	Dịch vụ kinh doanh BusinessService	Dịch vụ kinh doanh hoặc ứng dụng chịu ảnh hưởng từ thay đổi.
Mô tả Thuộc tính này liên kết yêu cầu thay đổi với một dịch vụ kinh doanh cụ thể trong Cơ sở dữ liệu quản lý cấu hình (CMDB), chẳng hạn như 'Dịch vụ email' hoặc 'CRM khách hàng'. Đây là khái niệm quan trọng để hiểu tác động kinh doanh của thay đổi. Phân tích thay đổi theo dịch vụ kinh doanh giúp xác định thứ tự ưu tiên và trao đổi về tác động với các bên liên quan. Bạn có thể biết dịch vụ nào đang có nhiều thay đổi nhất, dịch vụ nào có rủi ro cao nhất và sự cố liên quan đến thay đổi thường tập trung ở đâu. Đây là thông tin thiết yếu để quản lý thay đổi kỹ thuật theo góc nhìn kinh doanh. Vì sao điều này quan trọng Thuộc tính này kết nối thay đổi kỹ thuật với tác động kinh doanh, giúp ưu tiên công việc và phân tích rủi ro dựa trên mức độ quan trọng của dịch vụ chịu ảnh hưởng. Lấy dữ liệu ở đâu Đây thường là trường tùy chỉnh trong JSM, thường được liên kết với Jira Assets (trước đây là Insight) hoặc một CMDB khác. Ví dụ Trang web công tySAP ERPWiki nội bộ
	Kết quả xử lý Resolution	Kết quả cuối cùng của một yêu cầu thay đổi đã đóng, cho biết yêu cầu được xử lý như thế nào.
Mô tả Khi đóng yêu cầu thay đổi, trường Kết quả xử lý cung cấp thông tin cụ thể về kết quả. Chẳng hạn, 'Đã hoàn tất' cho biết thay đổi thành công, còn 'Không thực hiện' hoặc 'Trùng lặp' nêu lý do đóng khác. Trường này cung cấp thêm thông tin so với trạng thái 'Đã đóng'. Thuộc tính này rất cần thiết để phân tích tỷ lệ thay đổi thành công và thất bại. Ví dụ, bạn có thể hiểu rõ hơn KPI 'Tỷ lệ sự cố sau triển khai' bằng cách lọc các thay đổi có kết quả 'Thất bại' hoặc 'Đã hoàn tác'. Thuộc tính này giúp phân biệt thay đổi được triển khai thành công với thay đổi bị hủy hoặc từ chối sau khi phê duyệt. Vì sao điều này quan trọng Thuộc tính này cung cấp thông tin chi tiết về kết quả cuối cùng của thay đổi, rất cần thiết để tính chính xác tỷ lệ thành công và thất bại. Lấy dữ liệu ở đâu Đây là trường `resolution` tiêu chuẩn trong Jira, thường được thiết lập khi issue chuyển sang nhóm trạng thái 'Đã hoàn tất'. Ví dụ Đã hoàn tấtKhông thực hiệnTrùng lặpĐã hủyĐã hoàn tác
	Lý do thay đổi ChangeReason	Cơ sở hoặc lý do kinh doanh đề xuất thay đổi.
Mô tả Thuộc tính này ghi lại lý do cốt lõi của thay đổi, chẳng hạn như 'Triển khai tính năng mới', 'Sửa lỗi' hoặc 'Nâng cấp hạ tầng'. Nhờ đó, bạn có thêm thông tin ngoài phần tóm tắt hoặc mô tả. Khi phân tích, bạn có thể đối chiếu lý do thay đổi với các chỉ số khác như thời gian xử lý, tỷ lệ thất bại và mức độ rủi ro. Từ đó, bạn có thể trả lời những câu hỏi như: 'Thay đổi để sửa lỗi có được phê duyệt nhanh hơn thay đổi để triển khai tính năng mới không?' hoặc 'Nâng cấp hạ tầng có tỷ lệ thất bại cao hơn không?'. Vì sao điều này quan trọng Thuộc tính này cung cấp bối cảnh kinh doanh để phân tích sâu hơn bằng cách đối chiếu mục đích thay đổi với hiệu suất và kết quả. Lấy dữ liệu ở đâu Đây thường là trường tùy chỉnh trong Jira Service Management, thường là danh sách lựa chọn hoặc trường văn bản. Ví dụ Bản vá bảo mậtNâng cấp phần mềmLắp đặt phần cứng mới
	Người báo cáo Reporter	Người dùng khởi tạo hoặc gửi yêu cầu thay đổi.
Mô tả Người báo cáo là người tạo issue yêu cầu thay đổi trong Jira. Đây thường là chủ sở hữu thay đổi hoặc người khởi tạo thay đổi thay mặt cho một nhóm. Phân tích người báo cáo giúp xác định phòng ban, nhóm hoặc cá nhân nào khởi tạo nhiều thay đổi nhất. Bạn cũng có thể nhận ra xu hướng về nguồn yêu cầu, rồi hướng dẫn hoặc đào tạo những nhóm thường gửi yêu cầu thay đổi thiếu thông tin hoặc chưa đạt chất lượng. Vì sao điều này quan trọng Thuộc tính này giúp xác định nguồn của các yêu cầu thay đổi để phân tích và cải thiện chất lượng thông tin gửi ban đầu. Lấy dữ liệu ở đâu Đây là trường `reporter` tiêu chuẩn của một issue trong Jira. Ví dụ David MillerEva GreenFrank Wright
	Nhóm Team	Nhóm chịu trách nhiệm về yêu cầu thay đổi hoặc một hoạt động cụ thể.
Mô tả Thuộc tính này cho biết nhóm được giao xử lý thay đổi. Jira có trường 'Người được giao' để chỉ định cá nhân, còn trường 'Nhóm' thường dùng để giao việc cho một nhóm chức năng, chẳng hạn như 'Vận hành mạng' hoặc 'Quản trị cơ sở dữ liệu'. Thuộc tính này rất cần thiết cho bảng điều khiển 'Khối lượng công việc theo hoạt động của nhóm thay đổi'. Thuộc tính này cho phép phân tích hiệu suất và điểm nghẽn ở cấp nhóm, thay vì chỉ ở cấp cá nhân. Cách nhìn này thường hữu ích hơn khi lập kế hoạch và quản lý tài nguyên. Vì sao điều này quan trọng Thuộc tính này hỗ trợ phân tích khối lượng công việc và hiệu suất ở cấp nhóm hoặc phòng ban, giúp phát hiện các điểm nghẽn mang tính hệ thống. Lấy dữ liệu ở đâu Đây thường là trường tùy chỉnh trong Jira vì Jira không có trường 'Nhóm' tiêu chuẩn. Trường này có thể thuộc loại 'Group Picker' hoặc là danh sách lựa chọn đơn giản. Ví dụ Nhóm hạ tầngDịch vụ cốt lõiHỗ trợ ứng dụng
	Sự cố sau triển khai PostImplementationIssue	Cờ cho biết có sự cố hoặc vấn đề nào được liên kết với thay đổi sau khi triển khai hay không.
Mô tả Thuộc tính này cho biết thay đổi có dẫn đến kết quả tiêu cực, chẳng hạn như sự cố trong môi trường sản xuất, hay không. Thông tin này thường được xác định bằng cách liên kết issue yêu cầu thay đổi với một hoặc nhiều issue sự cố trong Jira. Dữ liệu này rất cần thiết để tính KPI 'Tỷ lệ sự cố sau triển khai' và 'Tỷ lệ thay đổi thất bại'. Đây là thước đo trực tiếp về chất lượng thay đổi và hiệu quả của việc lập kế hoạch, kiểm thử và đánh giá rủi ro. Phân tích những thay đổi dẫn đến sự cố giúp cải thiện biện pháp kiểm soát và ngăn ngừa thất bại trong tương lai. Vì sao điều này quan trọng Thuộc tính này đo trực tiếp chất lượng và mức độ thành công của thay đổi bằng cách theo dõi xem thay đổi có gây ra vấn đề trong vận hành sau đó hay không. Lấy dữ liệu ở đâu Thông tin này thường được xác định bằng cách kiểm tra các issue được liên kết trong Jira, cụ thể là xem issue Thay đổi có liên kết 'do sự cố gây ra' từ các issue Sự cố hay không. Ví dụ truefalse

Bắt buộc Nên có Không bắt buộc

Hoạt động quản lý thay đổi

Đâ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á chính xác quy trình quản lý thay đổi.

5 Nên có 8 Không bắt buộc

	Hoạt động	Mô tả
	Đã đóng thay đổi	Đánh dấu việc đóng yêu cầu thay đổi sau cùng, cho biết mọi hoạt động liên quan đã hoàn tất. Sự kiện này được ghi nhận khi trạng thái issue Jira chuyển sang trạng thái cuối cùng đã xử lý như 'Closed' hoặc 'Done'.
Vì sao điều này quan trọng Đây là điểm kết thúc chính của quy trình. Thông tin này được dùng để tính tổng thời gian xử lý và xác định mức độ đáp ứng SLA. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách tìm dấu thời gian khi trường 'status' chuyển sang trạng thái đóng cuối cùng. Trường resolution thường cũng được thiết lập vào thời điểm này. Thu thập Theo dõi dấu thời gian khi trạng thái chuyển sang 'Closed' hoặc 'Done'. Loại sự kiện inferred
	Đã phê duyệt yêu cầu thay đổi	Đây là cột mốc quan trọng, cho biết thay đổi đã được phê duyệt chính thức để triển khai. Sự kiện này hầu như luôn được xác định từ việc trạng thái trong quy trình làm việc Jira chuyển sang 'Approved' hoặc 'Ready for Implementation'.
Vì sao điều này quan trọng Sự kiện này đánh dấu kết thúc chu kỳ phê duyệt và bắt đầu giai đoạn triển khai. Đây là dữ liệu cần thiết để đo thời gian phê duyệt và theo dõi các thay đổi chưa được phép. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách tìm dấu thời gian khi trường 'status' chuyển sang trạng thái 'Approved'. Thu thập Theo dõi dấu thời gian khi trạng thái chuyển sang 'Approved' hoặc 'Ready to Implement'. Loại sự kiện inferred
	Đã tạo yêu cầu thay đổi	Đây là thời điểm tạo phiếu yêu cầu thay đổi trên Jira Service Management. Sự kiện được ghi lại cùng dấu thời gian tạo khi một issue loại 'Change' được lưu lần đầu.
Vì sao điều này quan trọng Đây là điểm bắt đầu của mọi yêu cầu thay đổi, rất quan trọng để đo tổng thời gian xử lý và phân tích số lượng thay đổi tiếp nhận theo thời gian. Lấy dữ liệu ở đâu Lấy từ dấu thời gian 'created' trên đối tượng issue của Jira. Đây là trường hệ thống tiêu chuẩn có trong mọi issue và có thể truy xuất qua lịch sử issue hoặc API. Thu thập Dùng dấu thời gian của trường 'created' trong issue Jira. Loại sự kiện explicit
	Đã triển khai thay đổi	Đây là cột mốc quan trọng, cho biết công việc liên quan đến thay đổi đã hoàn tất. Sự kiện này được ghi nhận khi trạng thái trong quy trình làm việc Jira chuyển sang 'Implemented' hoặc 'Pending Verification'.
Vì sao điều này quan trọng Sự kiện này đánh dấu kết thúc giai đoạn triển khai và rất quan trọng để tính thời gian triển khai. Đây cũng là thời điểm bắt đầu các hoạt động đánh giá và xác minh sau triển khai. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách tìm dấu thời gian khi trường 'status' chuyển sang 'Implemented' hoặc 'Pending Post-Implementation Review'. Thu thập Theo dõi dấu thời gian khi trạng thái chuyển sang 'Implemented' hoặc trạng thái tương tự. Loại sự kiện inferred
	Thay đổi đang chờ phê duyệt	Cho biết yêu cầu thay đổi đã qua bước xem xét ban đầu và đang chờ quyết định chính thức từ Hội đồng tư vấn thay đổi (CAB) hoặc người phê duyệt được chỉ định. Thông tin này được lấy từ thay đổi trạng thái trong quy trình làm việc, chẳng hạn chuyển sang 'Pending Approval' hoặc 'Awaiting CAB'.
Vì sao điều này quan trọng Hoạt động này rất quan trọng để đo thời gian chờ phê duyệt và xác định điểm nghẽn trong giai đoạn ra quyết định, vốn ảnh hưởng trực tiếp đến KPI Thời gian chu kỳ phê duyệt thay đổi. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách tìm dấu thời gian khi trường 'status' chuyển sang trạng thái chờ phê duyệt như 'Pending CAB Approval' hoặc 'Awaiting Approval'. Thu thập Theo dõi dấu thời gian khi trạng thái chuyển sang trạng thái 'Awaiting Approval' đã chỉ định. Loại sự kiện inferred
	Đã bắt đầu triển khai	Đánh dấu thời điểm bắt đầu triển khai kỹ thuật thay đổi đã được phê duyệt. Thông thường, sự kiện này được ghi nhận khi trạng thái Jira chuyển từ 'Approved' hoặc 'Scheduled' sang 'In Progress' hoặc 'Implementing'.
Vì sao điều này quan trọng Hoạt động này bắt đầu tính Thời gian triển khai trung bình, giúp xác định điểm nghẽn trong giai đoạn thực hiện. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách tìm dấu thời gian khi trường 'status' chuyển sang trạng thái triển khai đang diễn ra như 'In Progress'. Thu thập Theo dõi dấu thời gian khi trạng thái chuyển sang 'In Progress' hoặc 'Implementing'. Loại sự kiện inferred
	Đã đánh giá rủi ro	Đánh dấu thời điểm hoàn tất phân tích rủi ro và tác động của thay đổi được đề xuất. Sự kiện này thường được xác định từ lịch sử issue khi các trường tùy chỉnh liên quan đến rủi ro, như 'Risk Level' hoặc 'Impact', được điền hoặc cập nhật.
Vì sao điều này quan trọng Phân tích hoạt động này giúp đánh giá độ chính xác của việc đánh giá rủi ro và đảm bảo tuân thủ chính sách thay đổi. Đây là dữ liệu cần thiết để tính KPI dựa trên rủi ro, chẳng hạn Tỷ lệ thay đổi gây sự cố theo mức độ rủi ro. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách ghi nhận dấu thời gian khi các trường như 'Risk Level', 'Impact' hoặc 'Urgency' được thiết lập hoặc thay đổi lần đầu. Thu thập Theo dõi dấu thời gian lần đầu điền các trường như 'Risk Level' hoặc 'Impact'. Loại sự kiện inferred
	Đã gửi thay đổi để xem xét	Đánh dấu thời điểm thông tin ban đầu của yêu cầu thay đổi đã đầy đủ và được gửi chính thức để đánh giá. Thông thường, thời điểm này được xác định từ thay đổi trạng thái trong quy trình làm việc Jira, chẳng hạn từ 'Draft' sang 'Pending Review'.
Vì sao điều này quan trọng Hoạt động này bắt đầu chu kỳ phê duyệt. Đo thời gian từ đây đến lúc được phê duyệt rất quan trọng để tính KPI thời gian phê duyệt và xác định điểm nghẽn ở giai đoạn đầu. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách tìm dấu thời gian khi trường 'status' chuyển sang trạng thái xem xét như 'Pending Review' hoặc 'Awaiting Assessment'. Thu thập Theo dõi dấu thời gian khi trạng thái chuyển sang 'Pending Review', 'Submitted' hoặc trạng thái tương tự. Loại sự kiện inferred
	Đã hoàn tất đánh giá sau triển khai	Cho biết đã hoàn tất đánh giá chính thức về mức độ thành công của thay đổi và những bài học kinh nghiệm. Thông thường, sự kiện này được ghi nhận khi trạng thái trong quy trình làm việc chuyển từ 'Post-Implementation Review' sang 'Verified'.
Vì sao điều này quan trọng Hoạt động này rất cần thiết để cải tiến quy trình. Đo thời gian hoàn tất đánh giá giúp đảm bảo bài học kinh nghiệm được ghi nhận kịp thời. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách tìm dấu thời gian khi trường 'status' chuyển khỏi trạng thái 'Post-Implementation Review'. Thu thập Theo dõi dấu thời gian khi trạng thái chuyển từ 'PIR' sang trạng thái tiếp theo. Loại sự kiện inferred
	Đã hủy thay đổi	Đánh dấu việc chấm dứt yêu cầu thay đổi trước khi triển khai hoặc hoàn tất. Sự kiện này được ghi nhận khi trạng thái issue Jira chuyển sang trạng thái kết thúc như 'Canceled' hoặc 'Withdrawn'.
Vì sao điều này quan trọng Điểm kết thúc thay thế này giúp phân tích lý do thay đổi bị bỏ dở. Tỷ lệ hủy cao có thể cho thấy kế hoạch ban đầu chưa tốt hoặc ưu tiên kinh doanh đã thay đổi. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách tìm dấu thời gian khi trường 'status' chuyển sang trạng thái 'Canceled' và trường resolution tương ứng được thiết lập. Thu thập Theo dõi dấu thời gian khi trạng thái chuyển sang 'Canceled' hoặc 'Withdrawn'. Loại sự kiện inferred
	Đã kiểm thử	Đánh dấu thời điểm hoàn tất kiểm thử sau triển khai để xác nhận thay đổi. Đây có thể là trạng thái riêng như 'In Testing' hoặc được xác định từ bình luận hay cập nhật của nhóm QA sau sự kiện 'Đã triển khai thay đổi'.
Vì sao điều này quan trọng Phân tích thời lượng và kết quả kiểm thử giúp đánh giá chất lượng triển khai và hiệu quả của quy trình kiểm thử. Đây là dữ liệu quan trọng để tính Tỷ lệ sự cố sau triển khai. Lấy dữ liệu ở đâu Có thể xác định sự kiện này từ việc trạng thái chuyển sang 'Testing' hoặc 'Under Test', hoặc bằng cách phân tích bình luận và thay đổi người được giao trong lịch sử issue sau khi triển khai. Thu thập Theo dõi dấu thời gian khi trạng thái chuyển sang 'In Testing' hoặc lấy từ bình luận. Loại sự kiện inferred
	Đã lên lịch thay đổi	Cho biết thay đổi đã được phê duyệt và được ấn định khung thời gian triển khai cụ thể. Sự kiện này được xác định khi các trường 'Planned start date' và 'Planned end date' trong issue Jira được điền hoặc cập nhật.
Vì sao điều này quan trọng Hoạt động này giúp theo dõi kế hoạch triển khai thay đổi. Thông tin hỗ trợ quản lý tài nguyên và đánh giá khoảng thời gian từ lúc phê duyệt đến khi lên lịch triển khai. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách ghi nhận dấu thời gian khi các trường ngày như 'Planned start date' hoặc 'Change window' được điền. Thu thập Theo dõi dấu thời gian khi trường 'Planned start date' được điền. Loại sự kiện inferred
	Đã từ chối yêu cầu thay đổi	Đánh dấu việc chính thức từ chối một yêu cầu thay đổi. Yêu cầu thường được gửi lại cho người yêu cầu để bổ sung thông tin hoặc bị hủy. Sự kiện này được ghi nhận khi trạng thái trong quy trình làm việc Jira chuyển sang 'Rejected' hoặc 'Needs More Info'.
Vì sao điều này quan trọng Theo dõi các lần từ chối là việc cần thiết để phân tích Tỷ lệ làm lại thay đổi. Hoạt động này xảy ra thường xuyên cho thấy chất lượng yêu cầu thay đổi ban đầu có vấn đề. Lấy dữ liệu ở đâu Xác định từ lịch sử issue Jira bằng cách tìm dấu thời gian khi trường 'status' chuyển sang trạng thái kết thúc 'Rejected' hoặc trạng thái tương tự. Thu thập Theo dõi dấu thời gian khi trạng thái chuyển sang 'Rejected' hoặc 'Declined'. 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

Các bước

Mở Issue Navigator trong Jira: Đăng nhập vào Jira Service Management. Trên thanh điều hướng chính, chọn 'Issues', rồi chọn 'Search for issues' để mở Issue Navigator.
Chuyển sang tìm kiếm JQL: Nếu đang ở chế độ tìm kiếm 'Basic', hãy chuyển sang chế độ nâng cao bằng cách nhấp vào 'JQL' (hoặc 'Advanced' ở một số phiên bản). Bạn có thể nhập truy vấn Jira Query Language (JQL) tùy chỉnh.
Lọc yêu cầu thay đổi: Nhập truy vấn JQL trong phần 'query' của tài liệu này vào thanh tìm kiếm. Thay các giá trị giữ chỗ bằng khóa dự án, tên loại sự cố dành cho thay đổi và khoảng ngày mong muốn.
Chạy tìm kiếm và xuất dữ liệu: Chạy tìm kiếm. Khi danh sách yêu cầu thay đổi hiện ra, tìm nút 'Export', thường nằm ở góc trên bên phải. Chọn 'Export Excel CSV (all fields)'. Định dạng này rất quan trọng vì có lịch sử sự cố chi tiết cần thiết để dựng lại luồng quy trình.
Nạp CSV để chuyển đổi: Mở tệp CSV đã tải xuống bằng công cụ chuẩn bị dữ liệu như Power Query, tập lệnh Python dùng thư viện pandas hoặc công cụ ETL khác. Tệp xuất thô có một hàng cho mỗi sự cố, nhưng các cột chứa dữ liệu lịch sử.
Tạo dữ liệu nền: Với mỗi hàng trong tệp nguồn, tạo sự kiện ban đầu 'Change Request Created'. Dùng 'Issue key' làm ChangeRequestId, đặt ActivityName thành 'Change Request Created' và lấy thời gian trong cột 'Created' làm EventTime.
Chuyển lịch sử trạng thái thành từng hàng: Tìm các cột chứa lịch sử chuyển trạng thái. Mỗi lần đổi trạng thái là một sự kiện. Với mỗi yêu cầu thay đổi, tạo một hàng mới cho từng lần chuyển trạng thái liên quan, chẳng hạn từ 'Draft' sang 'Pending Review' hoặc từ 'Pending Approval' sang 'Approved'. Ánh xạ các lần chuyển này sang ActivityName tương ứng, chẳng hạn 'Change Submitted For Review', 'Change Awaiting Approval', 'Change Request Approved'. Thời điểm đổi trạng thái là EventTime.
Chuyển lịch sử cập nhật trường thành từng hàng: Một số hoạt động được suy ra từ việc cập nhật trường, không phải đổi trạng thái. Xử lý lịch sử của các trường như 'Risk Level', 'Planned start date' và 'Planned end date'. Tạo hàng mới cho các sự kiện 'Risk Assessment Performed' và 'Change Scheduled', dùng thời điểm các trường này được điền hoặc cập nhật lần đầu.
Ánh xạ và bổ sung thuộc tính: Với mỗi hàng sự kiện vừa tạo, ánh xạ các trường Jira tương ứng vào thuộc tính cần thiết như ChangeRequestStatus, ChangeRequestType, Assignee và Priority. Dùng giá trị có hiệu lực tại thời điểm xảy ra sự kiện.
Thêm cột siêu dữ liệu: Thêm cột SourceSystem với giá trị cố định 'Jira Service Management'. Thêm cột LastDataUpdate và điền thời điểm trích xuất dữ liệu.
Tính các chỉ số suy ra: Sau khi tạo xong nhật ký sự kiện, hãy tính các thuộc tính cần nhiều điểm dữ liệu, chẳng hạn ApprovalCycleTime. Để làm vậy, tìm khoảng thời gian giữa sự kiện 'Change Submitted For Review' và 'Change Request Approved' của từng ChangeRequestId.
Hoàn tất và xuất để tải lên: Đảm bảo bảng cuối có các cột bắt buộc: ChangeRequestId, ActivityName và EventTime. Xóa các cột trung gian hoặc cột nguồn. Lưu dữ liệu đã chuyển đổi thành tệp CSV, mã hóa UTF-8, rồi tải lên công cụ process mining.

Cấu hình

Bộ lọc JQL: Truy vấn JQL là công cụ chính để chọn đúng tập dữ liệu. Các bộ lọc quan trọng gồm project, issuetype và khoảng ngày trên trường created để giới hạn dữ liệu trích xuất.
Khoảng ngày: Nên bắt đầu với dữ liệu trong 3 đến 6 tháng để có tập dữ liệu đại diện mà không gây vấn đề về hiệu năng. Ví dụ: created >= "-180d".
Loại sự cố: Bạn cần chỉ định chính xác tên loại sự cố dùng cho quản lý thay đổi trong Jira, chẳng hạn issuetype = "Change" hoặc issuetype = "Change Request".
Định dạng xuất: Luôn chọn 'Export Excel CSV (all fields)'. Tùy chọn này đảm bảo tệp xuất có tất cả trường tùy chỉnh và quan trọng nhất là toàn bộ lịch sử changelog về trạng thái và trường. Tệp chỉ xuất một số trường sẽ không có đủ dữ liệu để tạo nhật ký sự kiện.
Quyền Jira: Người xuất dữ liệu cần có quyền 'Browse Projects' cho dự án được chỉ định và các quyền cần thiết để xem mọi trường sự cố liên quan.
Xác định trường tùy chỉnh: Trước khi chuyển đổi, bạn cần xác định chính xác tên các trường tùy chỉnh trong Jira tương ứng với thuộc tính quy trình như 'Risk Level', 'Planned start date' và 'Change Type'.

Truy vấn mẫu config

project = "[Your_Project_Key]" AND issuetype = "Change" AND created >= "[Start_Date_YYYY-MM-DD]" AND created <= "[End_Date_YYYY-MM-DD]" ORDER BY created ASC

Các bước

Kết nối cơ sở dữ liệu: Xin thông tin đăng nhập chỉ có quyền đọc vào cơ sở dữ liệu nền của Jira Server hoặc Data Center. Cơ sở dữ liệu có thể là PostgreSQL, MySQL, SQL Server hoặc Oracle. Dùng ứng dụng khách SQL thông dụng như DBeaver, SQL Developer hoặc pgAdmin để kết nối.
Xác định cấu hình Jira: Trước khi chạy truy vấn, bạn cần xác định các tên cụ thể trong cấu hình Jira Service Management. Đăng nhập Jira và mở dự án quản lý thay đổi. Ghi lại các thông tin sau:
- Khóa dự án: Mã ngắn của dự án, chẳng hạn 'CSM'.
- Tên loại sự cố: Tên chính xác của yêu cầu thay đổi, thường là 'Change'.
- Trạng thái workflow: Tên từng trạng thái trong workflow thay đổi, chẳng hạn 'Pending Review', 'Pending Approval', 'In Progress', 'Closed'.
- Tên trường tùy chỉnh: Tên các trường tùy chỉnh dùng cho 'Change Type', 'Risk Level', 'Planned start date' và 'Planned end date'.
Tùy chỉnh truy vấn SQL: Mở truy vấn SQL được cung cấp trong ứng dụng khách SQL. Thay các giá trị giữ chỗ bằng thông tin đã thu thập ở bước trước. Các giá trị chính cần cập nhật gồm [Your_JSM_Project_Key], [Your Change Type Field Name], [Your Risk Level Field Name], [Your Planned Start Date Field Name], [Your Planned End Date Field Name] và tất cả tên trạng thái trong mệnh đề WHERE.
Đặt khoảng ngày: Tìm dòng AND i.created >= '[YYYY-MM-DD]' trong Common Table Expression (CTE) đầu tiên. Sửa ngày để xác định thời điểm bắt đầu trích xuất dữ liệu. Bước này giúp giới hạn khối lượng dữ liệu và cải thiện hiệu năng truy vấn.
Chạy truy vấn: Chạy truy vấn SQL đã chỉnh sửa trên cơ sở dữ liệu Jira. Tùy quy mô Jira và khoảng ngày đã chọn, quá trình có thể mất vài phút.
Kiểm tra kết quả: Khi truy vấn chạy xong, kiểm tra nhanh kết quả trong ứng dụng khách SQL để đảm bảo có hàng dữ liệu và các cột như ChangeRequestId, ActivityName, EventTime có giá trị như mong đợi.
Xuất dữ liệu sang CSV: Xuất toàn bộ kết quả từ ứng dụng khách SQL sang tệp CSV. Trong phần cài đặt xuất, hãy giữ tiêu đề cột, dùng dấu phẩy làm dấu phân cách và chọn mã hóa UTF-8.
Chuẩn bị tải lên: Đặt tên tệp dễ nhận biết, chẳng hạn jira_change_management_log.csv. Tệp này đã sẵn sàng để tải lên công cụ process mining và phân tích.

Cấu hình

Quyền truy cập cơ sở dữ liệu: Cần có tài khoản chỉ đọc cho cơ sở dữ liệu Jira production. Chỉ có thể truy cập trực tiếp cơ sở dữ liệu với Jira Server và Jira Data Center, không áp dụng cho Jira Cloud.
Khóa dự án Jira: Cần cấu hình truy vấn bằng khóa cụ thể của dự án Jira Service Management. Tìm khóa trong mệnh đề p.pkey IN ('[Your_JSM_Project_Key]').
Loại sự cố dành cho thay đổi: Truy vấn giả định loại sự cố cho yêu cầu thay đổi có tên 'Change'. Nếu cấu hình của bạn dùng tên khác, hãy cập nhật bộ lọc issuetype.pname = 'Change'.
Ánh xạ trạng thái workflow: Độ chính xác của nhật ký sự kiện phụ thuộc hoàn toàn vào việc ánh xạ đúng tên trạng thái trong các mệnh đề WHERE với trạng thái workflow thực tế của dự án. Kiểm tra kỹ và cập nhật từng chuỗi 'Status Name'.
Ánh xạ trường tùy chỉnh: Truy vấn dựa vào tên trường tùy chỉnh để theo dõi một số hoạt động ('Risk Assessment Performed', 'Change Scheduled') và thuộc tính. Hãy kiểm tra và cập nhật các tên như '[Your Risk Level Field Name]' cho khớp với cấu hình Jira.
Khoảng ngày: Nên bắt đầu với khoảng ngày giới hạn, chẳng hạn 3 đến 6 tháng (i.created >= '[YYYY-MM-DD]'), để kiểm soát khối lượng dữ liệu và hiệu năng truy vấn. Trích xuất dữ liệu nhiều năm có thể rất chậm.
Hiệu năng: Với Jira có hàng triệu sự cố, chạy truy vấn này có thể ảnh hưởng đến hiệu năng cơ sở dữ liệu. Tốt nhất nên chạy ngoài giờ cao điểm. Hãy áp dụng bộ lọc khoảng ngày để giới hạn phạm vi.

Truy vấn mẫu sql

WITH ChangeRequestAttributes AS (
    SELECT
        i.id AS issueid,
        i.pkey AS ChangeRequestId,
        i.created,
        i.duedate AS TargetCompletionDate,
        istat.pname AS ChangeRequestStatus,
        u.display_name AS Assignee,
        prio.pname AS Priority,
        ct.customvalue AS ChangeRequestType,
        rl.customvalue AS RiskLevel
    FROM
        jiraissue i
    JOIN
        project p ON i.project = p.id
    LEFT JOIN
        issuestatus istat ON i.issuestatus = istat.id
    LEFT JOIN
        priority prio ON i.priority = prio.id
    LEFT JOIN
        app_user au ON i.assignee = au.user_key
    LEFT JOIN
        cwd_user u ON au.lower_user_name = u.lower_user_name
    LEFT JOIN (
        SELECT cfv.issue, cfo.customvalue
        FROM customfieldvalue cfv
        JOIN customfield cf ON cfv.customfield = cf.id
        JOIN customfieldoption cfo ON cfv.stringvalue = cfo.id
        WHERE cf.cfname = '[Your Change Type Field Name]'
    ) ct ON i.id = ct.issue
    LEFT JOIN (
        SELECT cfv.issue, cfo.customvalue
        FROM customfieldvalue cfv
        JOIN customfield cf ON cfv.customfield = cf.id
        JOIN customfieldoption cfo ON cfv.stringvalue = cfo.id
        WHERE cf.cfname = '[Your Risk Level Field Name]'
    ) rl ON i.id = rl.issue
    WHERE
        p.pkey IN ('[Your_JSM_Project_Key]')
        AND i.issuetype = (SELECT id FROM issuetype WHERE pname = 'Change')
        AND i.created >= '[YYYY-MM-DD]'
)
-- 1. Change Request Created
SELECT
    cra.ChangeRequestId,
    'Change Request Created' AS ActivityName,
    cra.created AS EventTime,
    'Jira Service Management DB' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    cra.ChangeRequestStatus,
    cra.ChangeRequestType,
    cra.Assignee,
    cra.RiskLevel,
    cra.Priority,
    cra.TargetCompletionDate,
    NULL AS ApprovalCycleTime,
    NULL AS SLAStatus
FROM
    ChangeRequestAttributes cra

UNION ALL

-- All subsequent events from issue history
SELECT
    cra.ChangeRequestId,
    CASE 
        WHEN ci.field = 'status' AND ci.newstring = 'Pending Review' THEN 'Change Submitted For Review'
        WHEN ci.field = 'status' AND ci.newstring = 'Pending Approval' THEN 'Change Awaiting Approval'
        WHEN ci.field = 'status' AND ci.newstring = 'Approved' THEN 'Change Request Approved'
        WHEN ci.field = 'status' AND ci.newstring = 'Rejected' THEN 'Change Request Rejected'
        WHEN ci.field = 'status' AND ci.newstring = 'In Progress' THEN 'Implementation Started'
        WHEN ci.field = 'status' AND ci.newstring = 'Implemented' THEN 'Change Implemented'
        WHEN ci.field = 'status' AND ci.newstring = 'In Testing' THEN 'Testing Performed'
        WHEN ci.field = 'status' AND ci.newstring = 'Verified' AND ci.oldstring = 'Post-Implementation Review' THEN 'Post-Implementation Review Done'
        WHEN ci.field = 'status' AND ci.newstring = 'Closed' THEN 'Change Closed'
        WHEN ci.field = 'status' AND ci.newstring = 'Canceled' THEN 'Change Canceled'
        WHEN ci.field = (SELECT id FROM customfield WHERE cfname = '[Your Risk Level Field Name]') AND ci.oldvalue IS NULL THEN 'Risk Assessment Performed'
        WHEN ci.field = (SELECT id FROM customfield WHERE cfname = '[Your Planned Start Date Field Name]') AND ci.oldvalue IS NULL THEN 'Change Scheduled'
    END AS ActivityName,
    cg.created AS EventTime,
    'Jira Service Management DB' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    cra.ChangeRequestStatus,
    cra.ChangeRequestType,
    cra.Assignee,
    cra.RiskLevel,
    cra.Priority,
    cra.TargetCompletionDate,
    NULL AS ApprovalCycleTime,
    NULL AS SLAStatus
FROM
    changegroup cg
JOIN
    changeitem ci ON cg.id = ci.groupid
JOIN
    ChangeRequestAttributes cra ON cg.issueid = cra.issueid
WHERE
    (
        ci.fieldtype = 'jira' AND ci.field = 'status' AND ci.newstring IN (
            'Pending Review', 'Pending Approval', 'Approved', 'Rejected', 
            'In Progress', 'Implemented', 'In Testing', 'Verified', 'Closed', 'Canceled'
        )
    )
    OR
    (
        ci.fieldtype = 'custom' AND ci.fieldid IN (
            (SELECT id FROM customfield WHERE cfname = '[Your Risk Level Field Name]'),
            (SELECT id FROM customfield WHERE cfname = '[Your Planned Start Date Field Name]')
        ) AND ci.oldvalue IS NULL
    )
ORDER BY
    ChangeRequestId, EventTime;

Các bước

Thiết lập môi trường Python: Đảm bảo bạn đã cài Python 3.6 trở lên. Cài các thư viện cần thiết, requests để gọi API và pandas để xử lý dữ liệu, bằng lệnh: pip install requests pandas.
Tạo Jira API token: Đăng nhập vào tài khoản Jira. Mở cài đặt hồ sơ, chọn 'Account settings', rồi vào thẻ 'Security' và nhấp 'Create and manage API tokens'. Tạo token mới và lưu an toàn. Token này sẽ được dùng làm mật khẩu để xác thực API.
Cấu hình tập lệnh Python: Mở tập lệnh Python được cung cấp bằng trình soạn thảo. Thay các giá trị giữ chỗ JIRA_URL, JIRA_EMAIL và JIRA_API_TOKEN bằng URL Jira, địa chỉ email và API token bạn vừa tạo.
Tùy chỉnh truy vấn JQL: Sửa biến JQL_QUERY trong tập lệnh để chọn đúng dự án và loại sự cố Jira Service Management. Ví dụ, đổi project = "CSM" thành khóa dự án của bạn. Điều chỉnh khoảng ngày trong truy vấn để giới hạn thời gian trích xuất và cải thiện hiệu năng.
Ánh xạ trường tùy chỉnh và trạng thái: Kiểm tra các từ điển STATUS_TO_ACTIVITY_MAPPING và FIELD_TO_ACTIVITY_MAPPING trong tập lệnh. Cập nhật tên trạng thái Jira, chẳng hạn 'Pending Approval', và tên trường tùy chỉnh, chẳng hạn 'Risk Level', cho khớp chính xác với workflow Jira. Dùng trang quản trị trường tùy chỉnh của Jira để tìm đúng ID cho các trường như customfield_10050.
Chạy tập lệnh: Chạy tập lệnh từ terminal bằng lệnh python your_script_name.py. Tập lệnh sẽ kết nối với Jira API, lấy các sự cố yêu cầu thay đổi và xử lý lịch sử của chúng.
Theo dõi quá trình chạy: Tập lệnh sẽ in thông báo tiến độ ra cửa sổ dòng lệnh, cho biết số sự cố đã lấy và xử lý. Với tập dữ liệu lớn, quá trình có thể mất nhiều thời gian.
Kiểm tra kết quả: Khi chạy xong, tập lệnh sẽ tạo tệp CSV jira_change_management_event_log.csv trong cùng thư mục. Tệp này chứa nhật ký sự kiện đã trích xuất.
Chuẩn bị tải lên: Mở tệp CSV bằng ứng dụng bảng tính để kiểm tra dữ liệu được sắp xếp đúng với các cột như ChangeRequestId, ActivityName và EventTime. Tệp đã sẵn sàng để tải lên công cụ process mining.

Cấu hình

Truy vấn JQL: Biến JQL_QUERY là bộ lọc chính để trích xuất dữ liệu. Tối thiểu, truy vấn cần chỉ định project, issuetype = 'Change' và khoảng ngày cho trường created, chẳng hạn created >= -180d để lấy 180 ngày gần nhất. Lọc theo khoảng ngày cụ thể là điều cần thiết để kiểm soát khối lượng dữ liệu.
Ánh xạ trạng thái và trường: Độ chính xác của tập lệnh phụ thuộc hoàn toàn vào các từ điển STATUS_TO_ACTIVITY_MAPPING và FIELD_TO_ACTIVITY_MAPPING. Cần cấu hình các từ điển này khớp chính xác với trạng thái workflow và tên trường tùy chỉnh trong Jira của tổ chức để tạo đúng hoạt động.
Thông tin xác thực API: Tập lệnh cần JIRA_URL, JIRA_EMAIL và JIRA_API_TOKEN hợp lệ để xác thực. Người dùng gắn với token phải có quyền đọc dự án được chỉ định và tất cả trường liên quan.
Phân trang dữ liệu: Tập lệnh dùng tham số maxResults (đặt là 100) để lấy sự cố từ API theo từng nhóm, hay từng trang. Cách này giúp trích xuất số lượng lớn sự cố ổn định mà không bị hết thời gian chờ.
Mở rộng changelog: Tham số expand=changelog trong yêu cầu API rất quan trọng. Tham số này yêu cầu Jira trả về toàn bộ lịch sử thay đổi trường của từng sự cố, nguồn dữ liệu của phần lớn hoạt động.

Truy vấn mẫu python

import requests
import json
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-domain].atlassian.net"
JIRA_EMAIL = class="hl-string">"[your-email@example.com]"
JIRA_API_TOKEN = class="hl-string">"[your_jira_api_token]"

class=class="hl-string">"hl-comment"># JQL to select Change Management issues. Itclass="hl-string">'s recommended to add a date filter, e.g., 'AND created >= -180d'
JQL_QUERY = class="hl-string">'project = "CSM" AND issuetype = "Change" ORDER BY created DESC'

class=class="hl-string">"hl-comment"># --- Mappings - CRITICAL: Customize these to match your Jira workflow --- #
class=class="hl-string">"hl-comment"># Map Jira status names to standardized Activity Names
STATUS_TO_ACTIVITY_MAPPING = {
    class="hl-string">'Pending Review': class="hl-string">'Change Submitted For Review',
    class="hl-string">'Pending Approval': class="hl-string">'Change Awaiting Approval',
    class="hl-string">'Approved': class="hl-string">'Change Request Approved',
    class="hl-string">'Rejected': class="hl-string">'Change Request Rejected',
    class="hl-string">'In Progress': class="hl-string">'Implementation Started',
    class="hl-string">'Implemented': class="hl-string">'Change Implemented',
    class="hl-string">'Post-Implementation Review': class="hl-string">'Post-Implementation Review Done',
    class="hl-string">'Closed': class="hl-string">'Change Closed',
    class="hl-string">'Canceled': class="hl-string">'Change Canceled',
    class=class="hl-string">"hl-comment"># Add other custom statuses from your workflow
}

class=class="hl-string">"hl-comment"># Map Jira field updates to standardized Activity Names
class=class="hl-string">"hl-comment"># Use field names as they appear in the API changelog. Custom fields might have different names.
FIELD_TO_ACTIVITY_MAPPING = {
    class="hl-string">'Risk Level': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'Planned start date': class="hl-string">'Change Scheduled',
    class="hl-string">'Testing Status': class="hl-string">'Testing Performed', class=class="hl-string">"hl-comment"># Example for a custom class="hl-string">'Testing Status' field
}
class=class="hl-string">"hl-comment"># --- End of Configuration --- #

def get_issues(auth):
    class="hl-string">"""Paginates through JQL results to fetch all issues."""
    all_issues = []
    start_at = 0
    max_results = 100

    while True:
        api_endpoint = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'fields': class="hl-string">'*all',
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        try:
            response = requests.get(api_endpoint, auth=auth, params=params, headers={class="hl-string">'Accept': class="hl-string">'application/json'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an error for bad responses (4xx or 5xx)
            data = response.json()
            issues = data.get(class="hl-string">'issues', [])
            all_issues.extend(issues)

            print(fclass="hl-string">"Fetched {len(issues)} issues, total so far: {len(all_issues)}")

            if len(issues) < max_results:
                break class=class="hl-string">"hl-comment"># Exit loop if this is the last page
            start_at += len(issues)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching issues: {e}")
            break

    return all_issues

def parse_issues_to_event_log(issues):
    class="hl-string">"""Parses issues and their changelogs into a structured event log."""
    event_log = []
    source_system = class="hl-string">"Jira Service Management"
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        
        class=class="hl-string">"hl-comment"># 1. Handle class="hl-string">'Change Request Created' event
        event_log.append({
            class="hl-string">'ChangeRequestId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Change Request Created',
            class="hl-string">'EventTime': fields.get(class="hl-string">'created'),
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': last_data_update,
            class="hl-string">'ChangeRequestStatus': fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
            class="hl-string">'ChangeRequestType': fields.get(class="hl-string">'customfield_10037', {}).get(class="hl-string">'value'), class=class="hl-string">"hl-comment"># Example custom field ID
            class="hl-string">'Assignee': fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None,
            class="hl-string">'RiskLevel': fields.get(class="hl-string">'customfield_10039', {}).get(class="hl-string">'value'), class=class="hl-string">"hl-comment"># Example custom field ID
            class="hl-string">'Priority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
            class="hl-string">'TargetCompletionDate': fields.get(class="hl-string">'duedate'),
            class="hl-string">'ApprovalCycleTime': None, class=class="hl-string">"hl-comment"># Requires post-processing to calculate
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># Requires post-processing to calculate
        })

        class=class="hl-string">"hl-comment"># 2. Parse changelog for all other events
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        for history in changelog:
            event_time = history[class="hl-string">'created']
            for item in history.get(class="hl-string">'items', []):
                activity_name = None
                class=class="hl-string">"hl-comment"># Map status changes
                if item.get(class="hl-string">'field', class="hl-string">'').lower() == class="hl-string">'status':
                    activity_name = STATUS_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'toString'))
                class=class="hl-string">"hl-comment"># Map field updates
                elif item.get(class="hl-string">'field') in FIELD_TO_ACTIVITY_MAPPING:
                    activity_name = FIELD_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'field'))

                if activity_name:
                    event_log.append({
                        class="hl-string">'ChangeRequestId': case_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTime': event_time,
                        class="hl-string">'SourceSystem': source_system,
                        class="hl-string">'LastDataUpdate': last_data_update,
                        class="hl-string">'ChangeRequestStatus': item.get(class="hl-string">'toString') if item.get(class="hl-string">'field', class="hl-string">'').lower() == class="hl-string">'status' else fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
                        class="hl-string">'ChangeRequestType': fields.get(class="hl-string">'customfield_10037', {}).get(class="hl-string">'value'),
                        class="hl-string">'Assignee': fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None,
                        class="hl-string">'RiskLevel': fields.get(class="hl-string">'customfield_10039', {}).get(class="hl-string">'value'),
                        class="hl-string">'Priority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                        class="hl-string">'TargetCompletionDate': fields.get(class="hl-string">'duedate'),
                        class="hl-string">'ApprovalCycleTime': None,
                        class="hl-string">'SLAStatus': None
                    })

    return event_log

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Jira data extraction...")
    jira_auth = (JIRA_EMAIL, JIRA_API_TOKEN)
    
    issues_data = get_issues(jira_auth)
    
    if issues_data:
        print(fclass="hl-string">"\nProcessing {len(issues_data)} issues into an event log...")
        event_log_data = parse_issues_to_event_log(issues_data)
        
        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log_data)
        df_sorted = df.sort_values(by=[class="hl-string">'ChangeRequestId', class="hl-string">'EventTime'])
        
        output_filename = class="hl-string">'jira_change_management_event_log.csv'
        df_sorted.to_csv(output_filename, index=False)
        print(fclass="hl-string">"\nExtraction complete. Event log saved to {output_filename}")
    else:
        print(class="hl-string">"No issues found for the given JQL query.")

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

Dùng mẫu dữ liệu này để bắt đầu hành trình process mining cho quy trình quản lý thay đổi. Hãy chuyển dữ liệu thô thành thông tin hữu ích ngay hôm nay.

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Nâng cao hiệu quả quản lý thay đổi: đạt tỷ lệ thành công 95%

Giảm các thay đổi thất bại và dễ dàng nâng tỷ lệ thành công lên 95%.

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.

Mẫu dữ liệu quản lý thay đổi

Mẫu dữ liệu quản lý thay đổi

Thuộc tính quản lý thay đổi

Hoạt động quản lý thay đổi

Hướng dẫn trích xuất dữ liệu

Xuất sự cố sang CSV bằng tính năng có sẵn trong Jira Service Management

Các bước

Cấu hình

Truy vấn mẫu config

Truy vấn SQL trực tiếp cơ sở dữ liệu Jira Server/Data Center

Các bước

Cấu hình

Truy vấn mẫu sql

Trích xuất bằng tập lệnh Python qua Jira REST API và JQL

Các bước

Cấu hình

Truy vấn mẫu python

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

Nâng cao hiệu quả quản lý thay đổi: đạt tỷ lệ thành công 95%