Mẫu dữ liệu quản lý thay đổi của bạn

BMC Helix ITSM
Mẫu dữ liệu quản lý thay đổi của bạn

Mẫu dữ liệu quản lý thay đổi của bạn

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. Bạn sẽ tìm thấy các thuộc tính được đề xuất, những hoạt động chính cần theo dõi và hướng dẫn thực tế để trích xuất dữ liệu trực tiếp từ hệ thống. Hãy dùng tài nguyên này để chuẩn bị dữ liệu cho hoạt động process mining hiệu quả.
  • Các thuộc tính nên thu thập để phân tích kỹ lưỡng
  • Các hoạt động chính và mốc cần theo dõi trong quy trình
  • Hướng dẫn trích xuất dữ liệu từ các hệ thống nguồn liên quan
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ý thay đổi

Đây là những trường dữ liệu nên có trong event log để phân tích quy trình quản lý thay đổi và hiểu rõ hơn cách quy trình vận hành.
5 Bắt buộc 6 Nên có 11 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ể được thực hiện trong quy trình quản lý thay đổi.
Mô tả

Thuộc tính này thể hiện một bước hoặc lần đổi trạng thái trong vòng đời của yêu cầu thay đổi, chẳng hạn 'Gửi yêu cầu thay đổi' hoặc 'Phê duyệt yêu cầu thay đổi'. Các hoạt động này tạo nên sơ đồ quy trình.

Phân tích trình tự và thời lượng của từng hoạt động giúp xác định luồng quy trình, phát hiện điểm khác với quy trình chuẩn và tìm ra điểm nghẽn. Tên hoạt động thường được lấy từ các lần chuyển trạng thái ghi trong nhật ký kiểm tra của hệ thống.

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 và phân tích luồng quy trình, nền tảng của process mining.

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

Được xác định từ các lần chuyển trạng thái trong biểu mẫu 'CHG:ChangeRequest_AuditLog' hoặc bằng cách theo dõi thay đổi của trường 'Status' trong biểu mẫu 'CHG:Infrastructure Change'.

Ví dụ
Gửi yêu cầu thay đổiĐánh giá rủi ro hoàn tấtPhê duyệt yêu cầu thay đổiTriển khai thay đổi
ID yêu cầu thay đổi
ChangeRequestID
Mã định danh duy nhất do hệ thống tạo cho một yêu cầu thay đổi, dùng làm mã nhận diện chính của hồ sơ.
Mô tả

ID yêu cầu thay đổi là khóa duy nhất nhận diện từng sáng kiến thay đổi trong suốt vòng đời. Mã này nhóm tất cả hoạt động, phê duyệt và tác vụ liên quan, tạo thành một hồ sơ riêng trong process mining.

Phân tích quy trình theo ID này giúp bạn theo dõi toàn bộ quá trình quản lý thay đổi, từ yêu cầu ban đầu đến khi đóng. Đây là cơ sở để theo dõi thời gian chu trình, xác định điểm nghẽn và hiểu sự khác biệt giữa từng yêu cầu thay đổi.

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

Đây là thuộc tính cốt lõi liên kết mọi sự kiện liên quan thành một phiên bản quy trình, giúp phân tích toàn bộ quy trình quản lý thay đổi từ đầu đến cuối.

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

Có trong trường 'Infrastructure Change ID' (Field ID 1000000182) của biểu mẫu 'CHG:Infrastructure Change'.

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

Thuộc tính này ghi lại chính xác ngày giờ diễn ra hoạt động. Ví dụ, thuộc tính cho biết thời điểm gửi, phê duyệt hoặc đóng yêu cầu thay đổi.

Dấu thời gian này rất quan trọng để phân tích tiến trình theo thời gian. Thuộc tính được dùng để tính thời gian chu trình giữa các hoạt động, đo thời gian chờ, nhận biết xu hướng hiệu suất theo thời gian và xác định trình tự sự kiện. Dấu thời gian chính xác là nền tảng cho mọi phân tích quy trình theo thời gian.

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

Thuộc tính này cung cấp dữ liệu thời gian cần thiết để tính thời lượng, phân tích hiệu suất và hiểu trình tự các sự kiện trong quy trình.

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

Lấy từ trường 'Audit Date' trong biểu mẫu 'CHG:ChangeRequest_AuditLog' hoặc trường 'Last Modified Date' gắn với các lần thay đổi trạng thái cụ thể.

Ví dụ
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
Hệ thống nguồn
SourceSystem
Tên hệ thống được trích xuất dữ liệu.
Mô tả

Thuộc tính này xác định nguồn gốc dữ liệu quy trình, trong trường hợp này là 'BMC Helix ITSM'. Thuộc tính hỗ trợ quản trị và truy xuất dữ liệu, nhất là khi phân tích kết hợp dữ liệu từ nhiều hệ thống.

Ví dụ, nếu sau này dữ liệu thay đổi được kết hợp với dữ liệu từ hệ thống tài chính hoặc quản lý dự án, trường này giúp phân biệt rõ nguồn dữ liệu.

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

Thuộc tính này cung cấp thông tin quan trọng về nguồn gốc dữ liệu, giúp truy xuất và diễn giải dữ liệu chính xác, nhất là khi phân tích nhiều hệ thống.

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

Đây thường là giá trị cố định được thêm trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL) để ghi rõ nguồn của tập dữ liệu.

Ví dụ
BMC Helix ITSMHelix ITSM ProdBMC Remedy AR System
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 từ hệ thống nguồn.
Mô tả

Thuộc tính này cho biết ngày giờ dữ liệu được trích xuất lần gần nhất từ BMC Helix ITSM. Đây không phải thời điểm sự kiện diễn ra mà là thời điểm lấy dữ liệu. Thông tin này rất cần thiết để biết dữ liệu đang phân tích mới đến đâu và quản lý chu kỳ làm mới dữ liệu.

Trong dashboard và báo cáo, dấu thời gian này cho người dùng biết dữ liệu phân tích được cập nhật đến thời điểm nào. Điều này đặc biệt quan trọng khi theo dõi các quy trình đang diễn ra.

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

Thuộc tính này cho biết dữ liệu mới đến đâu, yếu tố quan trọng để bảo đảm các phân tích và dashboard phản ánh trạng thái quy trình mới nhất.

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

Đây là trường siêu dữ liệu thường do công cụ ETL hoặc luồng dữ liệu tạo và điền vào lúc trích xuất dữ liệu.

Ví dụ
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
Loại thay đổi
ChangeType
Phân loại thay đổi, chẳng hạn Standard, Normal hoặc Emergency.
Mô tả

Thuộc tính này phân loại yêu cầu thay đổi theo tính chất và quy trình cần thực hiện. Các loại phổ biến gồm Standard (được phê duyệt trước, rủi ro thấp), Normal (cần đánh giá và phê duyệt đầy đủ) và Emergency (cần xử lý nhanh do vấn đề khẩn cấp).

Phân tích theo loại thay đổi rất quan trọng để hiểu sự khác biệt giữa các quy trình. Ví dụ, dashboard 'Emergency Change Volume & Impact' sử dụng trường này để theo dõi các thay đổi khẩn cấp và ảnh hưởng của chúng đến độ ổn định dịch vụ. Trường này cũng giúp đánh giá các loại thay đổi có đi đúng quy trình đã quy định hay không.

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

Thuộc tính này cho phép chia quy trình thành các nhóm để phân tích và so sánh những quy trình làm việc khác nhau, rất cần thiết khi phân tích tuân thủ và hiệu suất.

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

Có trong trường 'Change Type' của biểu mẫu 'CHG:Infrastructure Change'.

Ví dụ
Tiêu chuẩnThông thườngKhẩn cấpKhông ảnh hưởng
Mức độ rủi ro
RiskLevel
Đánh giá rủi ro tiềm ẩn khi triển khai thay đổi.
Mô tả

Mức độ rủi ro là đánh giá định tính hoặc định lượng về khả năng xảy ra hậu quả tiêu cực nếu triển khai thay đổi. Đây là yếu tố đầu vào quan trọng của quy trình phê duyệt, trong đó các thay đổi rủi ro cao được xem xét kỹ hơn.

Thuộc tính này đóng vai trò trọng tâm trong dashboard 'Change Risk Profile Analysis', giúp các bên liên quan hiểu mức độ rủi ro tổng thể của danh mục thay đổi. Thuộc tính cũng giúp xác định các vòng lặp làm lại khi đánh giá rủi ro ban đầu chưa đầy đủ, dẫn đến phải đánh giá lại sau đó.

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

Thuộc tính này cung cấp khía cạnh quan trọng để phân tích mức độ tuân thủ và hiệu quả của quy trình, giúp bảo đảm các thay đổi rủi ro cao được xem xét phù hợp.

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

Có trong trường 'Risk Level' của biểu mẫu 'CHG:Infrastructure Change'.

Ví dụ
1 - Nghiêm trọng2 - Cao3 - Trung bình4 - Thấp5 - Đang lập kế hoạch
Mức độ ưu tiên
Priority
Mức độ ưu tiên được gán cho yêu cầu thay đổi, thể hiện tầm quan trọng đối với hoạt động kinh doanh.
Mô tả

Mức độ ưu tiên thường được xác định dựa trên mức độ ảnh hưởng và tính khẩn cấp. Mức này quyết định thứ tự và tốc độ xử lý yêu cầu thay đổi. Thay đổi có mức ưu tiên cao thường cần được xử lý nhanh hơn và có thể phải đáp ứng thỏa thuận mức dịch vụ (SLA) nghiêm ngặt hơn.

Thuộc tính này được dùng trong dashboard 'Change SLA Performance' để phân nhóm và phân tích hiệu suất theo từng mức ưu tiên. Thuộc tính giúp trả lời những câu hỏi như 'Chúng ta có đáp ứng SLA cho các thay đổi ưu tiên cao không?' và hỗ trợ quyết định phân bổ tài nguyên.

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 theo tầm quan trọng đối với hoạt động kinh doanh, giúp xử lý hiệu quả các thay đổi quan trọng nhất và đáp ứng mục tiêu.

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

Có trong trường 'Priority' của biểu mẫu 'CHG:Infrastructure Change'.

Ví dụ
Nghiêm trọngCaoTrung bìnhThấp
Nhóm phê duyệt
ApproverGroup
Nhóm chịu trách nhiệm phê duyệt yêu cầu thay đổi ở một giai đoạn cụ thể.
Mô tả

Thuộc tính này cho biết nhóm được giao xem xét và phê duyệt một thay đổi. Vì một thay đổi có thể trải qua nhiều giai đoạn phê duyệt, nhóm phụ trách có thể khác nhau ở từng giai đoạn, chẳng hạn như nhóm phê duyệt kỹ thuật và hội đồng phê duyệt nghiệp vụ.

Đây là thuộc tính quan trọng trong dashboard “Điểm nghẽn phê duyệt thay đổi”, giúp phân tích thời gian phê duyệt theo nhóm phụ trách. Nhờ đó, bạn có thể xác định nhóm nào đang quá tải hoặc làm việc chưa hiệu quả, khiến quy trình bị chậm trễ.

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

Thuộc tính này giúp xác định điểm nghẽn trong quy trình phê duyệt bằng cách phân tích thời gian phê duyệt của từng nhóm phụ trách.

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

Dữ liệu lấy từ biểu mẫu “AP:Signature”, dùng để quản lý việc phê duyệt và được liên kết với yêu cầu thay đổi. Nhóm của người phê duyệt được ghi trong bản ghi này.

Ví dụ
Hội đồng tư vấn thay đổiBảo mật CNTTKỹ thuật mạngPhát triển ứng dụng
Nhóm triển khai
ImplementationTeam
Nhóm chịu trách nhiệm thực hiện việc triển khai thay đổi.
Mô tả

Thuộc tính này cho biết nhóm kỹ thuật hoặc vận hành được giao thực hiện công việc theo yêu cầu thay đổi. Trong các giai đoạn triển khai thay đổi, đây thường là nhóm được ghi trong trường “Assigned Group”.

Thông tin này rất quan trọng đối với dashboard “Điểm nghẽn tài nguyên trong quy trình thay đổi”. Bằng cách phân tích thời lượng và số lượng hoạt động của từng nhóm triển khai, người quản lý có thể nhận ra tình trạng phân bổ công việc mất cân đối, thiếu kỹ năng hoặc các hạn chế về tài nguyên khác làm chậm việc triển khai thay đổi.

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

Thuộc tính này giúp xác định điểm nghẽn về tài nguyên trong giai đoạn triển khai bằng cách phân tích hiệu suất của từng nhóm phụ trách.

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

Có trong trường “ASGRP” (Assigned Group) của biểu mẫu “CHG:Infrastructure Change”.

Ví dụ
Vận hành máy chủQuản trị cơ sở dữ liệuNhóm SAP BasisHạ tầng đám mây
Trạng thái
Status
Trạng thái hoặc giai đoạn hiện tại của yêu cầu thay đổi trong vòng đời.
Mô tả

Trường Status cho biết chính xác yêu cầu thay đổi đang ở giai đoạn nào tại một thời điểm, chẳng hạn 'Draft', 'Request For Authorization' hoặc 'Completed'. Hoạt động được xác định từ các lần chuyển trạng thái, còn trạng thái hiện tại giúp phân tích khối lượng công việc.

Thuộc tính này rất cần thiết cho dashboard 'Change Throughput & Current Status', cung cấp ảnh chụp số lượng thay đổi ở từng giai đoạn của quy trình. Nhờ đó, người quản lý hiểu được công việc đang xử lý và cách phân bổ tài nguyên.

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

Thuộc tính này cung cấp cái nhìn cập nhật về luồng xử lý thay đổi, giúp phân tích công việc đang thực hiện và trạng thái hiện tại của mọi yêu cầu thay đổi.

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

Có trong trường 'Status' của biểu mẫu 'CHG:Infrastructure Change'.

Ví dụ
Bản nhápYêu cầu phê duyệtĐã lên lịchĐang triển khaiĐã hoàn tất
Có làm lại
IsRework
Cờ cho biết một hoạt động có phải là vòng lặp làm lại hoặc bước lùi trong quy trình hay không.
Mô tả

Thuộc tính boolean này được đặt thành true khi yêu cầu thay đổi quay lại giai đoạn trước trong vòng đời, chẳng hạn từ “Đã lên lịch” về “Đánh giá rủi ro”. Những lần quay lại này thể hiện việc phải làm lại, vốn thường gây giảm hiệu quả.

Cờ này được dùng để tính KPI “Tỷ lệ làm lại trong quy trình thay đổi” và hỗ trợ dashboard “Làm lại và hiệu quả đánh giá thay đổi”. Cờ giúp đo tần suất phải làm lại và xác định các bước thường xảy ra tình trạng này, qua đó chỉ ra những khâu cần cải thiện trong việc lập kế hoạch và đánh giá ban đầu.

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

Thuộc tính này đánh dấu các hoạt động thuộc vòng lặp làm lại, giúp xác định điểm kém hiệu quả trong quy trình và tập trung cải tiến đúng chỗ.

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

Đây là thuộc tính được tính toán bằng cách phân tích thứ tự hoạt động của một trường hợp. Logic phát hiện các bước lùi trong luồng quy trình được áp dụng khi chuyển đổi dữ liệu.

Ví dụ
truefalse
Dịch vụ bị ảnh hưởng
AffectedService
Dịch vụ nghiệp vụ hoặc kỹ thuật 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ụ cụ thể trong Cơ sở dữ liệu quản lý cấu hình (CMDB). Dịch vụ đó có thể là dịch vụ nghiệp vụ dành cho người dùng, như “Dịch vụ email”, hoặc dịch vụ kỹ thuật chạy ở hệ thống phía sau, như “Dịch vụ xác thực”.

Thuộc tính này được dùng trong dashboard “Số lượng và tác động của thay đổi khẩn cấp” để đối chiếu các thay đổi với dịch vụ chịu ảnh hưởng. Nhờ đó, bạn có thể đánh giá độ ổn định của từng dịch vụ và xác định dịch vụ nào thường xuyên cần can thiệp khẩn cấp.

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

Thuộc tính này bổ sung bối cảnh nghiệp vụ cần thiết, liên kết thay đổi kỹ thuật với tác động lên dịch vụ nghiệp vụ và hỗ trợ phân tích quy trình theo từng dịch vụ.

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

Dữ liệu lấy từ trường “ServiceCI” hoặc các mối quan hệ với Configuration Item (CI) liên quan trong biểu mẫu “CHG:Infrastructure Change”.

Ví dụ
Email doanh nghiệpSAP ERPQuản lý quan hệ khách hàngCổng ngân hàng trực tuyến
ID sự cố liên quan
RelatedIncidentID
Mã định danh của sự cố phát sinh do thay đổi này.
Mô tả

Thuộc tính này liên kết yêu cầu thay đổi với các sự cố có thể phát sinh sau đó. Mối liên kết này rất quan trọng để hiểu tác động của thay đổi đến độ ổn định dịch vụ.

Đây là thuộc tính chính để tính KPI “Tỷ lệ sự cố do thay đổi gây ra”. Bằng cách theo dõi các mối liên kết này, tổ chức có thể đo lường chất lượng quy trình thay đổi và xác định loại thay đổi, nhóm hoặc dịch vụ nào thường đi kèm với nhiều vấn đề sau triển khai hơn.

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

Thuộc tính này đo trực tiếp tác động tiêu cực của các thay đổi, cung cấp KPI quan trọng để đánh giá chất lượng thay đổi và hiệu quả quản lý rủi ro.

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

Mối liên kết này thường được thiết lập trên biểu mẫu sự cố (“HPD:Help Desk”), nơi sự cố có thể được liên kết với yêu cầu thay đổi là nguyên nhân.

Ví dụ
INC000000987654INC000000987655INC000000987656
Là thay đổi khẩn cấp
IsEmergencyChange
Cờ boolean có giá trị true nếu thay đổi thuộc loại “Khẩn cấp”.
Mô tả

Cờ được tạo từ thuộc tính “ChangeType” giúp đơn giản hóa việc phân tích bằng cách đánh dấu rõ thay đổi khẩn cấp theo dạng có/không.

Thuộc tính này chủ yếu hỗ trợ dashboard “Số lượng và tác động của thay đổi khẩn cấp” và KPI “Tỷ lệ thay đổi khẩn cấp”. Bạn có thể dễ dàng lọc và tổng hợp dữ liệu về các thay đổi khẩn cấp, theo dõi tần suất và xu hướng theo thời gian mà không cần thiết lập logic lọc phức tạp trong công cụ phân tích.

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

Thuộc tính này giúp phân tích thay đổi khẩn cấp dễ dàng hơn, từ lọc dữ liệu, hiển thị trên dashboard đến tính KPI liên quan đến loại thay đổi quan trọng này.

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

Đây là thuộc tính được tạo trong quá trình chuyển đổi dữ liệu. Logic: IF 'ChangeType' = 'Emergency' THEN true ELSE false.

Ví dụ
truefalse
Mã đóng yêu cầu
CloseCode
Mã cho biết kết quả cuối cùng của thay đổi khi yêu cầu được đóng.
Mô tả

Mã đóng yêu cầu cung cấp lý do chuẩn hóa cho việc đóng yêu cầu thay đổi, chẳng hạn như “Thành công”, “Thành công nhưng có vấn đề”, “Đã hoàn tác” hoặc “Đã hủy”. Thuộc tính này cho biết kết quả thay đổi chi tiết hơn so với trạng thái cuối cùng.

Phân tích mã đóng yêu cầu giúp đánh giá chất lượng và tỷ lệ thành công của các thay đổi đã triển khai. Ví dụ, nếu có nhiều thay đổi “Đã hoàn tác”, có thể khâu lập kế hoạch hoặc kiểm thử đang gặp vấn đề. Đây là chỉ số hữu ích để cải tiến quy trình.

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

Thuộc tính này ghi lại kết quả của từng thay đổi theo cấu trúc rõ ràng, giúp phân tích tỷ lệ thành công và lý do thất bại hoặc hủy bỏ.

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

Có trong trường “Status Reason” hoặc trường mã đóng tương tự của biểu mẫu “CHG:Infrastructure Change”. Trường này được kích hoạt ở các giai đoạn cuối.

Ví dụ
Thành côngThành công nhưng có vấn đềĐã hoàn tácĐã hủy
Mức độ ảnh hưởng
Impact
Mức độ ảnh hưởng được đánh giá của thay đổi đối với dịch vụ kinh doanh và hạ tầng CNTT.
Mô tả

Mức độ ảnh hưởng cho biết thay đổi có thể tác động ra sao đến hoạt động kinh doanh, dịch vụ và người dùng. Đây là yếu tố quan trọng cùng với tính khẩn cấp để xác định mức độ ưu tiên của yêu cầu thay đổi.

Trong phân tích, mức độ ảnh hưởng được dùng trong dashboard 'Change Risk Profile Analysis' để cung cấp cái nhìn tổng quan về những hệ quả tiềm ẩn đối với hoạt động kinh doanh của danh mục thay đổi. Hiểu được tỷ lệ các thay đổi có ảnh hưởng lớn giúp định hướng chiến lược quản lý rủi ro và lập kế hoạch tài nguyên.

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

Thuộc tính này giúp định lượng hệ quả tiềm ẩn của thay đổi đối với hoạt động kinh doanh, từ đó phân tích rủi ro và sắp xếp ưu tiên dựa trên mức độ ảnh hưởng đến dịch vụ.

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

Có trong trường 'Impact' của biểu mẫu 'CHG:Infrastructure Change'.

Ví dụ
1 - Rộng khắp2 - Đáng kể3 - Vừa phải4 - Nhỏ, cục bộ
Ngày mục tiêu SLA
SLATargetDate
Ngày và giờ mục tiêu cần hoàn tất yêu cầu thay đổi.
Mô tả

Ngày mục tiêu SLA (Service Level Agreement) là hạn chót hoàn tất yêu cầu thay đổi, được xác định dựa trên mức độ ưu tiên và loại thay đổi. Đây là mốc để so sánh với thời điểm hoàn tất thực tế.

Thuộc tính này là cơ sở cho dashboard “Hiệu suất SLA của thay đổi”. Bằng cách so sánh thời điểm đóng yêu cầu thực tế với ngày mục tiêu, bạn có thể xác định thay đổi có đáp ứng SLA hay không. Phân tích hiệu suất SLA giúp đánh giá hiệu quả chung của quy trình và mức độ đáp ứng cam kết dịch vụ.

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

Thuộc tính này cung cấp mốc chuẩn để đo hiệu suất, tính tỷ lệ tuân thủ SLA và xác định các thay đổi có nguy cơ trễ hạn.

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

Thông tin này thường được lưu trong các biểu mẫu quản lý SLA liên quan và liên kết với yêu cầu thay đổi. Bạn thường có thể xem thông tin ngay trên biểu mẫu thay đổi.

Ví dụ
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
Người gửi yêu cầu thay đổi
ChangeSubmitter
Người tạo và gửi yêu cầu thay đổi.
Mô tả

Thuộc tính này cho biết người khởi tạo yêu cầu thay đổi. Trong hệ thống, người này thường được ghi ở trường “Submitter” hoặc “Reported By”.

Dù không phải lúc nào cũng là chiều phân tích chính, thuộc tính này vẫn hữu ích để tìm hiểu nguồn phát sinh yêu cầu thay đổi. Chẳng hạn, phân tích xem phần lớn yêu cầu đến từ phòng ban hoặc vai trò nào có thể giúp bạn hiểu rõ hơn nhu cầu nghiệp vụ và cách lập kế hoạch.

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

Thuộc tính này giúp xác định người khởi tạo yêu cầu thay đổi, từ đó phân tích xu hướng nhu cầu và hành vi người dùng trong quy trình.

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

Có trong trường “Submitter” của biểu mẫu “CHG:Infrastructure Change”.

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

Thời gian kết thúc đánh dấu lúc một hoạt động hoàn tất. Trong process mining, giá trị này thường được tính bằng thời gian bắt đầu của hoạt động tiếp theo trong cùng hồ sơ, qua đó xác định rõ thời lượng của bước trước. Với hoạt động cuối cùng trong hồ sơ, thời gian kết thúc có thể trùng với thời gian bắt đầu hoặc là dấu thời gian đóng cụ thể.

Thuộc tính này cần thiết để tính ProcessingTime của từng hoạt động, một chỉ số cốt lõi khi phân tích hiệu suất và xác định điểm nghẽn. Nhờ đó, bạn có thể phân tích chi tiết thời gian thực hiện từng bước.

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

Thuộc tính này giúp tính chính xác thời lượng hoạt động, nền tảng để xác định điểm nghẽn và đo hiệu suất quy trình.

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

Đây là thuộc tính được tính toán, thường được xác định trong quá trình chuyển đổi dữ liệu bằng thời gian bắt đầu của sự kiện tiếp theo trong cùng một hồ sơ.

Ví dụ
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
Tính khẩn cấp
Urgency
Mức độ khẩn cấp của thay đổi, thể hiện thời hạn cần triển khai.
Mô tả

Tính khẩn cấp cho biết cần triển khai thay đổi nhanh đến mức nào. Đây là yếu tố chính cùng với mức độ ảnh hưởng để tính mức độ ưu tiên tổng thể của yêu cầu thay đổi.

Tính khẩn cấp là thuộc tính quan trọng trong dashboard 'Change Risk Profile Analysis', giúp hiểu áp lực thời gian trong quy trình quản lý thay đổi. Phân tích xu hướng về tính khẩn cấp có thể giúp phát hiện vấn đề tiềm ẩn khiến số lượng yêu cầu cần xử lý gấp tăng cao.

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

Thuộc tính này thể hiện mức độ cấp bách về thời gian của các thay đổi, giúp phân tích quy trình xử lý hiệu quả ra sao với yêu cầu có thời hạn khác nhau.

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

Có trong trường 'Urgency' của biểu mẫu 'CHG:Infrastructure Change'.

Ví dụ
1 - Nghiêm trọng2 - Cao3-Trung bình4-Thấp
Trạng thái SLA
SLAState
Trạng thái được tính toán của yêu cầu thay đổi so với mục tiêu SLA.
Mô tả

Thuộc tính này cho biết yêu cầu thay đổi đã hoàn tất có đáp ứng SLA, có nguy cơ vi phạm SLA hay đã vi phạm SLA hay không. Giá trị được tính bằng cách so sánh dấu thời gian hoàn tất thực tế với “SLATargetDate”.

Đây là chỉ số chính trong dashboard “Hiệu suất SLA của thay đổi”. Thuộc tính cung cấp thước đo rõ ràng, ngắn gọn về mức độ đáp ứng cam kết dịch vụ. Bạn có thể phân tích dữ liệu theo mức độ ưu tiên, loại thay đổi hoặc nhóm để xác định những khâu chưa đáp ứng SLA tốt.

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

Thuộc tính này đo trực tiếp mức độ đáp ứng cam kết, là chỉ báo quan trọng về hiệu quả quy trình và chất lượng dịch vụ.

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

Thuộc tính này được tính trong quá trình chuyển đổi dữ liệu bằng cách so sánh dấu thời gian của hoạt động cuối cùng với “SLATargetDate”.

Ví dụ
Đúng hạnCó nguy cơ trễ hạnĐã vi phạm
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 event log để khám phá quy trình chính xác và tìm điểm nghẽn hiệu quả.
7 Nên có 7 Không bắt buộc
Hoạt động Mô tả
Đánh giá rủi ro hoàn tất
Hoạt động này đánh dấu việc hoàn tất đánh giá rủi ro của thay đổi được đề xuất. Sự kiện thường được ghi nhận khi trạng thái yêu cầu thay đổi được cập nhật hoặc một tác vụ đánh giá rủi ro cụ thể được đóng.
Vì sao điều này quan trọng

Theo dõi hoạt động này rất quan trọng để bảo đảm tuân thủ chính sách quản lý thay đổi. Việc này giúp phát hiện chậm trễ trong giai đoạn đánh giá và phân tích KPI Tỷ lệ làm lại do thay đổi nếu quy trình quay lại bước này.

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

Suy ra từ thay đổi trạng thái trên biểu mẫu CHG:Change, chẳng hạn chuyển sang 'Yêu cầu thay đổi', hoặc từ việc hoàn tất một nhiệm vụ liên quan trong biểu mẫu CHG:Task.

Thu thập

Xác định dấu thời gian khi nhiệm vụ 'Đánh giá rủi ro' liên kết trong CHG:Task được đánh dấu 'Đã đóng' hoặc 'Đã hoàn tất'.

Loại sự kiện inferred
Đóng yêu cầu thay đổi
Đây là hoạt động cuối cùng, đánh dấu yêu cầu thay đổi được chính thức đóng trong hệ thống. Sự kiện được ghi nhận khi trạng thái yêu cầu chuyển thành 'Closed'.
Vì sao điều này quan trọng

Hoạt động này đánh dấu kết thúc thành công vòng đời thay đổi. Đây là mốc cần thiết để đo tổng thời gian quy trình từ đầu đến cuối và thông lượng tổng thể.

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

Xác định từ lịch sử thay đổi trạng thái trong biểu mẫu CHG:Change khi trạng thái chuyển sang 'Closed'.

Thu thập

Xác định dấu thời gian khi trường 'Status' trong CHG:Change được cập nhật thành 'Closed'.

Loại sự kiện inferred
Kiểm thử hoàn tất
Cho biết việc kiểm thử hoặc xác thực sau triển khai đã hoàn tất. Sự kiện thường được ghi nhận khi đóng tác vụ kiểm thử riêng liên kết với yêu cầu thay đổi.
Vì sao điều này quan trọng

Theo dõi hoạt động này giúp đo KPI Thời gian chu trình kiểm thử trung bình và bảo đảm chất lượng. Việc này giúp phát hiện điểm nghẽn trong quy trình xác thực trước khi kiểm tra lần cuối.

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

Suy ra từ việc hoàn tất bản ghi nhiệm vụ kiểm thử trong biểu mẫu CHG:Task, được liên kết với yêu cầu thay đổi chính.

Thu thập

Xác định dấu thời gian khi nhiệm vụ 'Kiểm thử' hoặc 'Xác thực' liên kết trong CHG:Task được đánh dấu 'Đã đóng' hoặc 'Đã hoàn tất'.

Loại sự kiện inferred
Lên lịch thay đổi
Hoạt động này đánh dấu thời điểm thay đổi đã được phê duyệt và chính thức lên lịch triển khai. Sự kiện được lấy từ lần chuyển trạng thái sang 'Scheduled' trong hệ thống.
Vì sao điều này quan trọng

Đây là cột mốc quan trọng, cho biết thay đổi đã sẵn sàng triển khai. Đây cũng là điểm bắt đầu để đo KPI Thời gian chu trình triển khai thay đổi và Thời gian chờ triển khai trung bình.

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

Xác định từ lịch sử thay đổi trạng thái trong biểu mẫu CHG:Change khi trạng thái chuyển sang 'Scheduled'.

Thu thập

Xác định dấu thời gian khi trường 'Status' trong CHG:Change được cập nhật thành 'Scheduled'.

Loại sự kiện inferred
Phê duyệt yêu cầu thay đổi
Đây là cột mốc quan trọng, đánh dấu yêu cầu thay đổi được phê duyệt chính thức để tiếp tục. Sự kiện được xác định từ thay đổi trạng thái, thường là sang 'Scheduled' hoặc 'Planning In Progress' sau khi hoàn tất phê duyệt cuối cùng.
Vì sao điều này quan trọng

Cột mốc này đánh dấu kết thúc giai đoạn phê duyệt, rất quan trọng để đo điểm nghẽn phê duyệt và KPI Thời gian phê duyệt thay đổi trung bình. Đây cũng là thời điểm đưa ra quyết định quan trọng trong quy trình.

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

Xác định từ lịch sử thay đổi trạng thái trong biểu mẫu CHG:Change, cụ thể là khi yêu cầu rời khỏi trạng thái phê duyệt như 'Request For Authorization'.

Thu thập

Xác định dấu thời gian khi trường 'Status' trong CHG:Change chuyển qua giai đoạn phê duyệt cuối cùng, chẳng hạn sang 'Scheduled'.

Loại sự kiện inferred
Tạo yêu cầu thay đổi
Hoạt động này ghi nhận thời điểm tạo bản ghi yêu cầu thay đổi đầu tiên trong hệ thống. Sự kiện được lấy từ dấu thời gian tạo mục yêu cầu thay đổi trong biểu mẫu CHG:Change.
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, cần thiết để đo tổng thời gian vòng đời và phân tích số lượng yêu cầu thay đổi mới.

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

Sự kiện này được lấy từ trường 'Submit Date' hoặc dấu thời gian tạo bản ghi trong nhật ký kiểm tra của biểu mẫu CHG:Change (ví dụ: HPD:Help Desk Audit Log).

Thu thập

Dùng dấu thời gian tạo bản ghi trong biểu mẫu CHG:Change.

Loại sự kiện explicit
Triển khai thay đổi
Hoạt động này ghi nhận việc hoàn tất thành công công việc triển khai thay đổi. Thông thường, sự kiện được ghi lại khi trạng thái chuyển thành 'Completed' và lý do cho biết đã thành công.
Vì sao điều này quan trọng

Đây là cột mốc lớn, đánh dấu kết thúc giai đoạn triển khai. Cột mốc này cần thiết để tính Thời gian chu trình triển khai thay đổi và phân tích các sự cố do thay đổi gây ra.

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

Xác định từ biểu mẫu CHG:Change khi 'Status' được đặt thành 'Completed' và 'Status Reason' là 'Successful'.

Thu thập

Xác định dấu thời gian khi trường 'Status' trong CHG:Change được cập nhật thành 'Completed'.

Loại sự kiện inferred
Đánh giá sau triển khai
Ghi nhận việc hoàn tất đánh giá chính thức sau khi thay đổi được triển khai. Hoạt động này thường được lấy từ việc đóng tác vụ đánh giá sau triển khai (PIR).
Vì sao điều này quan trọng

Hoạt động này rất quan trọng để tổ chức rút kinh nghiệm và cải tiến quy trình. Đo KPI Tỷ lệ đánh giá sau triển khai giúp bảo đảm tổ chức rút ra bài học từ các lần thay đổi.

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

Suy ra từ việc hoàn tất nhiệm vụ 'Đánh giá sau triển khai' trong biểu mẫu CHG:Task, được liên kết với yêu cầu thay đổi chính.

Thu thập

Xác định dấu thời gian khi nhiệm vụ 'PIR' liên kết trong CHG:Task được đánh dấu 'Đã đóng' hoặc 'Đã hoàn tất'.

Loại sự kiện inferred
Gửi yêu cầu thay đổi
Ghi nhận việc chính thức gửi yêu cầu thay đổi để xem xét và phê duyệt. Thông thường, sự kiện này được xác định khi trạng thái yêu cầu chuyển từ 'Draft' sang 'Request For Authorization'.
Vì sao điều này quan trọng

Hoạt động này khởi động quy trình phê duyệt. Theo dõi hoạt động giúp đo thời gian yêu cầu chờ được xem xét lần đầu và phân tích KPI Thời gian phê duyệt thay đổi.

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

Xác định từ lịch sử thay đổi trạng thái của yêu cầu trong biểu mẫu CHG:Change, cụ thể là khi chuyển sang 'Request For Authorization'.

Thu thập

Xác định dấu thời gian khi trường 'Status' trong CHG:Change chuyển từ 'Draft' sang 'Request For Authorization'.

Loại sự kiện inferred
Hủy yêu cầu thay đổi
Ghi nhận việc hủy yêu cầu thay đổi trước khi triển khai hoặc hoàn tất. Sự kiện được ghi nhận khi trạng thái yêu cầu thay đổi được cập nhật thành 'Cancelled'.
Vì sao điều này quan trọng

Theo dõi các yêu cầu bị hủy giúp hiểu lý do thay đổi bị rút lại. Qua đó có thể phát hiện vấn đề như lập kế hoạch ban đầu chưa tốt, ưu tiên thay đổi hoặc thiếu tài nguyên.

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

Xác định từ lịch sử thay đổi trạng thái trong biểu mẫu CHG:Change khi trạng thái chuyển sang 'Cancelled'.

Thu thập

Xác định dấu thời gian khi trường 'Status' trong CHG:Change được cập nhật thành 'Cancelled'.

Loại sự kiện inferred
Lập kế hoạch triển khai
Cho biết kế hoạch chi tiết để triển khai thay đổi đã được lập và ghi lại. Sự kiện thường được ghi nhận khi hoàn tất tác vụ lập kế hoạch liên quan đến thay đổi.
Vì sao điều này quan trọng

Hoàn tất hoạt động này là điều kiện cần để lên lịch và triển khai. Phân tích thời lượng giúp phát hiện chậm trễ trong giai đoạn lập kế hoạch trước khi thực hiện thay đổi.

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

Suy ra từ việc hoàn tất một bản ghi nhiệm vụ lập kế hoạch cụ thể trong biểu mẫu CHG:Task, được liên kết với yêu cầu thay đổi chính.

Thu thập

Xác định dấu thời gian khi nhiệm vụ 'Lập kế hoạch triển khai' liên kết trong CHG:Task được đánh dấu 'Đã đóng' hoặc 'Đã hoàn tất'.

Loại sự kiện inferred
Phân tích tác động hoàn tất
Ghi nhận việc hoàn tất phân tích tác động để xác định những hệ quả có thể xảy ra khi thay đổi được thực hiện. Sự kiện thường được xác định từ cập nhật trạng thái hoặc việc đóng một tác vụ liên quan.
Vì sao điều này quan trọng

Hoạt động này rất quan trọng để hiểu hiệu quả lập kế hoạch và ảnh hưởng của khâu này đến việc làm lại. Phân tích thời lượng và tần suất giúp cải thiện giai đoạn đánh giá ban đầu.

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

Suy ra từ dấu thời gian hoàn tất nhiệm vụ “Impact Analysis” trong biểu mẫu CHG:Task hoặc từ một lần chuyển trạng thái cụ thể trong biểu mẫu CHG:Change.

Thu thập

Xác định dấu thời gian khi nhiệm vụ 'Phân tích tác động' liên kết trong CHG:Task được đánh dấu 'Đã đóng' hoặc 'Đã hoàn tất'.

Loại sự kiện inferred
Từ chối yêu cầu thay đổi
Hoạt động này cho biết người phê duyệt đã chính thức từ chối yêu cầu thay đổi. Sự kiện được ghi nhận khi trạng thái chuyển sang 'Rejected' và đây là trạng thái kết thúc.
Vì sao điều này quan trọng

Theo dõi các yêu cầu bị từ chối giúp xác định lý do, chẳng hạn thiếu thông tin hoặc rủi ro cao. Phân tích này có thể cải thiện chất lượng các yêu cầu thay đổi sau này.

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

Xác định từ lịch sử thay đổi trạng thái trong biểu mẫu CHG:Change, cụ thể là khi chuyển sang trạng thái 'Rejected'.

Thu thập

Xác định dấu thời gian khi trường 'Status' trong CHG:Change được cập nhật thành 'Rejected'.

Loại sự kiện inferred
Xác minh thay đổi
Hoạt động này cho biết các bên liên quan đã chính thức xác nhận thay đổi thành công sau khi triển khai và kiểm thử. Sự kiện thường được thể hiện qua lần chuyển trạng thái trước khi đóng yêu cầu.
Vì sao điều này quan trọng

Xác minh là bước kiểm tra chất lượng cuối cùng trước khi đóng yêu cầu thay đổi. Bước này xác nhận thay đổi đạt mục tiêu và không gây ra tác động tiêu cực ngoài dự kiến.

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

Xác định từ thay đổi trạng thái trong biểu mẫu CHG:Change, chẳng hạn chuyển từ 'Completed' sang trạng thái 'Verification' hoặc 'Closed'.

Thu thập

Xác định dấu thời gian khi trường 'Status' trong CHG:Change chuyển sang 'Closed' sau các hoạt động triển khai.

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ừ BMC Helix ITSM

Bắt đầu ngay?

Hãy chuẩn bị dữ liệu bằng mẫu này để bắt đầu cải thiện quy trình quản lý thay đổi ngay hôm nay. Khám phá thông tin hữu ích và nâng cao hiệu quả vận hành.

Cải thiện quy trình quản lý thay đổi ngay hôm nay, hạn chế gián đoạn

Nâng tỷ lệ thay đổi thành công lên 95% và tránh gián đoạn dịch vụ tốn kém.

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.