Mẫu dữ liệu quản lý thay đổi
Mẫu dữ liệu quản lý thay đổi
- Các thuộc tính nên thu thập
- Các hoạt động chính cần theo dõi
- Hướng dẫn trích xuất dữ liệu từ Ivanti Cherwell
Thuộc tính quản lý thay đổi
| Tên | Mô tả | ||
|---|---|---|---|
|
Mã yêu cầu thay đổi
ChangeRequestId
|
Mã định danh duy nhất của một yêu cầu thay đổi, dùng để nhóm mọi hoạt động liên quan từ lúc khởi tạo đến khi đóng. | ||
|
Mô tả
Mã yêu cầu thay đổi là khóa chính, giúp nhận diện duy nhất từng sáng kiến thay đổi trong suốt vòng đời. Trong process mining, mã này đóng vai trò định danh hồ sơ, liên kết mọi sự kiện như gửi yêu cầu, đánh giá, phê duyệt và triển khai thành một quy trình thống nhất. Phân tích dữ liệu theo Mã yêu cầu thay đổi giúp bạn xem toàn bộ quy trình quản lý thay đổi từ đầu đến cuối. Nhờ đó, bạn có thể theo dõi từng thay đổi, tính tổng thời gian xử lý và xác định các sai lệch hoặc điểm nghẽn riêng của từng yêu cầu.
Vì sao điều này quan trọng
Đây là mã định danh hồ sơ thiết yếu, kết nối mọi sự kiện liên quan để bạn theo dõi toàn bộ hành trình của một yêu cầu thay đổi và phân tích hiệu quả xử lý.
Lấy dữ liệu ở đâu
Đây thường là mã định danh chính của đối tượng nghiệp vụ Change Request trong Ivanti Cherwell.
Ví dụ
CR-105421CR-105422CR-105423
|
|||
|
Tên hoạt động
ActivityName
|
Tên sự kiện hoặc tác vụ cụ thể diễn ra tại một thời điểm trong quy trình quản lý thay đổi. | ||
|
Mô tả
Tên hoạt động mô tả một bước hoặc mốc cụ thể trong vòng đời của yêu cầu thay đổi, chẳng hạn như 'Change Submitted For Assessment' hoặc 'Change Approved by CAB'. Các hoạt động này tạo thành những nút trong sơ đồ quy trình được phát hiện. Khi phân tích, thuộc tính này giúp trực quan hóa luồng quy trình, xác định trình tự sự kiện và phát hiện sai lệch so với quy trình chuẩn. Bạn có thể dùng thuộc tính này để tính thời gian chuyển tiếp giữa các hoạt động và tìm ra nơi xảy ra chậm trễ.
Vì sao điều này quan trọng
Thuộc tính này rất quan trọng để phát hiện và trực quan hóa luồng quy trình thực tế, qua đó xác định điểm nghẽn, vòng lặp làm lại và các luồng không tuân thủ.
Lấy dữ liệu ở đâu
Được tạo từ các lần đổi trạng thái, mục nhật ký hoặc nhật ký sự kiện cụ thể liên quan đến đối tượng Change Request trong Ivanti Cherwell.
Ví dụ
Đã gửi thay đổi để đánh giáThay đổi đang chờ phê duyệtĐã triển khai thay đổi
|
|||
|
Thời điểm sự kiện
EventTime
|
Dấu thời gian cho biết một hoạt động hoặc sự kiện cụ thể của yêu cầu thay đổi đã diễn ra khi nào. | ||
|
Mô tả
Thời điểm sự kiện, còn gọi là dấu thời gian, ghi lại chính xác ngày giờ một hoạt động diễn ra. Dữ liệu thời gian này cần thiết để sắp xếp sự kiện theo trình tự và là cơ sở cho mọi phân tích process mining dựa trên thời gian. Thuộc tính này được dùng để tính thời lượng giữa các hoạt động, đo tổng thời gian xử lý hồ sơ và xác định thời gian chờ hoặc chậm trễ trong quy trình. Đây cũng là dữ liệu nền tảng để tạo dashboard theo dõi hiệu suất so với các mục tiêu thời gian, chẳng hạn như Thời gian xử lý phê duyệt thay đổi.
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. Nhờ đó, bạn có thể tính thời gian xử lý, xác định điểm nghẽn và theo dõi SLA.
Lấy dữ liệu ở đâu
Thường có trong nhật ký đổi trạng thái, lịch sử kiểm tra hoặc dấu thời gian của mục nhật ký gắn với đối tượng Change Request trong Ivanti Cherwell.
Ví dụ
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Hệ thống nguồn
SourceSystem
|
Hệ thống lưu trữ dữ liệu gốc được trích xuất. Trong chế độ xem này, hệ thống nguồn là 'Ivanti Cherwell'. | ||
|
Mô tả
Thuộc tính này xác định hệ thống nguồn của dữ liệu sự kiện. Trong môi trường có nhiều hệ thống, thuộc tính giúp phân biệt dữ liệu từ các nguồn khác nhau. Với mô hình dữ liệu này, giá trị sẽ cố định để cho biết dữ liệu đến từ Ivanti Cherwell. Dù có vẻ không thay đổi trong mô hình chỉ dùng một nguồn, thuộc tính này vẫn rất quan trọng đối với quản trị dữ liệu, khả năng truy xuất và tích hợp với các hệ thống khác trong tương lai. Thuộc tính giúp làm rõ nguồn gốc dữ liệu và hỗ trợ quản lý chất lượng dữ liệu.
Vì sao điều này quan trọng
Cho biết dữ liệu đến từ đâu, thông tin cần thiết cho quản trị dữ liệu, xử lý sự cố và bảo đảm khả năng truy xuất.
Lấy dữ liệu ở đâu
Đây thường là giá trị cố định được thêm trong quá trình trích xuất và chuyển đổi dữ liệu để ghi rõ nguồn gốc của tập dữ liệu.
Ví dụ
Ivanti Cherwell
|
|||
|
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
|
Dấu thời gian cho biết dữ liệu của sự kiện này được trích xuất hoặc làm mới từ hệ thống nguồn lần gần nhất vào khi nào. | ||
|
Mô tả
Thuộc tính này ghi lại ngày giờ dữ liệu được lấy từ Ivanti Cherwell lần gần nhất. Đây không phải là sự kiện trong quy trình mà là siêu dữ liệu cho biết độ mới của dữ liệu. Thông tin này giúp người xem dashboard biết dữ liệu phân tích được cập nhật đến thời điểm nào. Thuộc tính cũng hỗ trợ quản lý lịch làm mới dữ liệu và bảo đảm các quyết định dựa trên dữ liệu có thời điểm cập nhật rõ ràng.
Vì sao điều này quan trọng
Cho biết dữ liệu mới đến đâu, giúp người dùng tin cậy kết quả phân tích và hiểu mức độ phù hợp của dữ liệu với tình hình vận hành hiện tại.
Lấy dữ liệu ở đâu
Dấu thời gian này được tạo và ghi vào từng bản ghi trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL).
Ví dụ
2024-05-21T02:00:00Z
|
|||
|
Loại thay đổi
ChangeType
|
Phân loại thay đổi, chẳng hạn như 'Standard', 'Normal' hoặc 'Emergency'. | ||
|
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à tác động. Các loại thường gặp 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 triển khai ngay). Thuộc tính này cho phép so sánh hiệu suất quy trình giữa các nhóm thay đổi. Chẳng hạn, bạn có thể xác định thay đổi khẩn cấp có đi theo luồng nhanh hơn không, hoặc thay đổi tiêu chuẩn có thực sự được xử lý thuận lợi hay không. Đây là thuộc tính chính của dashboard 'Hiệu suất theo loại thay đổi có vấn đề'.
Vì sao điều này quan trọng
Phân tích quy trình theo Loại thay đổi giúp so sánh hiệu suất và xác định liệu một nhóm cụ thể, chẳng hạn 'Emergency', có gây ra điểm nghẽn hoặc sai lệch hay không.
Lấy dữ liệu ở đâu
Tương ứng với trường phân loại, có thể tên là 'Change Type' hoặc 'Category', trên đối tượng nghiệp vụ Change Request.
Ví dụ
Tiêu chuẩnThông thườngKhẩn cấp
|
|||
|
Mức độ rủi ro của thay đổi
ChangeRiskLevel
|
Mức rủi ro được đánh giá cho thay đổi, chẳng hạn như 'Low', 'Medium' hoặc 'High'. | ||
|
Mô tả
Mức độ rủi ro của thay đổi là phân loại được xác định trong giai đoạn đánh giá để đo lường tác động tiêu cực tiềm ẩn của một thay đổi. Kết quả đánh giá thường ảnh hưởng đến quy trình phê duyệt và mức độ xem xét cần thiết. Trong process mining, thuộc tính này giúp phân tích tính nhất quán của việc đánh giá rủi ro và mối liên hệ giữa rủi ro với cách quy trình diễn ra. Chẳng hạn, bạn có thể kiểm tra xem thay đổi rủi ro cao có đi qua quy trình phê duyệt chặt chẽ hơn hoặc mất nhiều thời gian triển khai hơn không. Thuộc tính này hỗ trợ trực tiếp cho dashboard 'Tính nhất quán trong đánh giá rủi ro thay đổi'.
Vì sao điều này quan trọng
Giúp phân tích ảnh hưởng của rủi ro đến luồng quy trình, thời gian phê duyệt và tỷ lệ thành công, qua đó bảo đảm các thay đổi rủi ro cao được xem xét phù hợp.
Lấy dữ liệu ở đâu
Giá trị này được lưu trong trường 'Risk Level' hoặc trường tương tự trên đối tượng Change Request, thường được điền trong hoạt động đánh giá rủi ro.
Ví dụ
ThấpTrung bìnhCaoNghiêm trọng
|
|||
|
Ngày hoàn tất mục tiêu
TargetCompletionDate
|
Thời hạn dự kiến hoặc đã thống nhất để hoàn tất việc triển khai thay đổi. | ||
|
Mô tả
Ngày hoàn tất mục tiêu là thời điểm dự kiến hoàn tất triển khai và xác minh thay đổi. Ngày này thường được quy định trong Thỏa thuận mức dịch vụ (SLA) và là mốc chính để đánh giá hiệu suất. Thuộc tính này cần thiết để theo dõi tiến độ đúng hạn và việc tuân thủ thời hạn. Bạn có thể so sánh ngày này với ngày hoàn tất thực tế để tính KPI 'Tỷ lệ hoàn tất thay đổi đúng hạn' và 'Tỷ lệ tuân thủ SLA thay đổi'. Thuộc tính cũng giúp sớm xác định những thay đổi có nguy cơ trễ hạn.
Vì sao điều này quan trọng
Là mốc cơ sở để đo lường việc hoàn tất đúng hạn và tuân thủ SLA, những chỉ số quan trọng về hiệu quả và độ tin cậy của quy trình.
Lấy dữ liệu ở đâu
Đây thường là trường ngày cụ thể trên đối tượng Change Request, có thể mang tên 'Target Date', 'Due Date' hoặc 'SLA Target'.
Ví dụ
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
|
|||
|
Người phụ trách thay đổi
ChangeOwner
|
Người dùng hoặc cá nhân hiện chịu trách nhiệm xử lý yêu cầu thay đổi. | ||
|
Mô tả
Người phụ trách thay đổi là người được giao và chịu trách nhiệm về yêu cầu ở một giai đoạn cụ thể. Người phụ trách thường thay đổi khi yêu cầu đi qua các bước trong vòng đời, cho thấy trách nhiệm được bàn giao giữa các cá nhân. Phân tích người phụ trách thay đổi giúp bạn hiểu khối lượng công việc và xác định điểm nghẽn liên quan đến từng cá nhân. Thuộc tính này cũng rất quan trọng để phân tích các lần bàn giao, vốn có thể gây chậm trễ đáng kể. Thuộc tính hỗ trợ dashboard 'Bàn giao thay đổi và mức sử dụng tài nguyên'.
Vì sao điều này quan trọng
Theo dõi trách nhiệm của từng cá nhân, giúp phân tích phân bổ khối lượng công việc, tần suất bàn giao và điểm nghẽn liên quan đến tài nguyên cụ thể.
Lấy dữ liệu ở đâu
Thường là trường 'Owned By' hoặc 'Assigned To' trong đối tượng nghiệp vụ Change Request.
Ví dụ
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Nhóm phụ trách thay đổi
ChangeTeam
|
Nhóm hoặc bộ phận hiện chịu trách nhiệm xử lý yêu cầu thay đổi. | ||
|
Mô tả
Nhóm phụ trách thay đổi là nhóm hoặc bộ phận được giao xử lý yêu cầu. Tương tự người phụ trách, nhóm này có thể thay đổi trong suốt quy trình, cho thấy trách nhiệm được chuyển giao giữa các nhóm, chẳng hạn từ bộ phận hỗ trợ dịch vụ sang nhóm kỹ thuật mạng. Thuộc tính này cần thiết để phân tích việc bàn giao giữa các nhóm và xác định chậm trễ mang tính hệ thống do một số nhóm gây ra. Thuộc tính giúp trả lời câu hỏi nhóm nào đang quá tải hoặc khâu nào xảy ra gián đoạn giao tiếp, đồng thời hỗ trợ trực tiếp cho phân tích 'Bàn giao thay đổi và mức sử dụng tài nguyên'.
Vì sao điều này quan trọng
Xác định trách nhiệm ở cấp nhóm, giúp phân tích điểm nghẽn trong quy trình, đo lường hiệu suất nhóm và tìm hiểu chậm trễ khi bàn giao giữa các nhóm.
Lấy dữ liệu ở đâu
Thông tin này thường được lưu trong trường 'Owned By Team' hoặc một trường tương tự dùng để gán nhóm trên đối tượng Change Request.
Ví dụ
Vận hành mạngQuản trị cơ sở dữ liệuHỗ trợ ứng dụng
|
|||
|
Trạng thái thay đổi
ChangeStatus
|
Trạng thái hiện tại hoặc cuối cùng của yêu cầu thay đổi, chẳng hạn như 'Closed', 'Rejected' hoặc 'In Progress'. | ||
|
Mô tả
Trạng thái thay đổi cho biết tình trạng của yêu cầu tại một thời điểm nhất định hoặc kết quả cuối cùng. Đây là thuộc tính quan trọng để hiểu cách xử lý hồ sơ và xác định các trường hợp ngoại lệ. Trong phân tích quy trình, bạn có thể dùng thuộc tính này để lọc theo kết quả cụ thể, chẳng hạn chỉ phân tích các thay đổi bị từ chối hoặc hủy. Thuộc tính này hỗ trợ các KPI như 'Tỷ lệ từ chối yêu cầu thay đổi' và giúp đánh giá sức khỏe cũng như hiệu quả chung của quy trình quản lý thay đổi.
Vì sao điều này quan trọng
Xác định kết quả của yêu cầu thay đổi, giúp phân tích tỷ lệ từ chối, tỷ lệ hoàn tất và tỷ trọng hồ sơ đang mở so với đã đóng.
Lấy dữ liệu ở đâu
Tương ứng với trường 'Status' trên đối tượng nghiệp vụ Change Request trong Ivanti Cherwell.
Ví dụ
Đã phê duyệtĐã từ chốiĐã đóngĐã hủyĐang chờ phê duyệt
|
|||
|
Dịch vụ bị ảnh hưởng
ServiceAffected
|
Dịch vụ kinh doanh hoặc cấu phần cấu hình (CI) chính chịu tác động của thay đổi. | ||
|
Mô tả
Thuộc tính này xác định dịch vụ CNTT, ứng dụng hoặc hạ tầng chính mà yêu cầu thay đổi nhắm đến. Thuộc tính kết nối quy trình quản lý thay đổi với bức tranh tổng thể về quản lý dịch vụ CNTT. Phân tích theo Dịch vụ bị ảnh hưởng rất quan trọng đối với KPI 'Các loại thay đổi có vấn đề nhiều nhất'. Phân tích này giúp xác định dịch vụ nào thường xuyên có thay đổi và dịch vụ nào đi kèm tỷ lệ từ chối cao hoặc chậm trễ. Nhờ đó, người phụ trách dịch vụ có thêm thông tin để cải thiện độ ổn định và quản lý nợ kỹ thuật.
Vì sao điều này quan trọng
Liên kết thay đổi với từng dịch vụ kinh doanh, giúp xác định dịch vụ nào kém ổn định nhất hoặc phát sinh nhiều thay đổi có vấn đề nhất.
Lấy dữ liệu ở đâu
Thông tin này thường được liên kết từ Cơ sở dữ liệu quản lý cấu hình (CMDB) và lưu trong trường 'Primary CI' hoặc 'Service' trên đối tượng Change Request.
Ví dụ
Dịch vụ email (Exchange)Hệ thống ERP (SAP)Bộ chuyển mạch mạng lõi (CISCO-4500X)
|
|||
|
Đơn vị kinh doanh
BusinessUnit
|
Đơn vị hoặc bộ phận yêu cầu thay đổi hoặc sẽ hưởng lợi từ thay đổi đó. | ||
|
Mô tả
Thuộc tính này gắn yêu cầu thay đổi với một bộ phận cụ thể trong tổ chức, chẳng hạn như 'Tài chính', 'Tiếp thị' hoặc 'Vận hành'. Nhờ đó, một quy trình vốn mang tính kỹ thuật có thêm bối cảnh kinh doanh. Phân tích theo Đơn vị kinh doanh giúp xác định nhu cầu thay đổi đến từ đâu. Thông tin này có thể hỗ trợ mô hình phân bổ chi phí, làm rõ tác động của thay đổi CNTT đến các bộ phận kinh doanh và xác định liệu một số đơn vị có thay đổi phức tạp hơn hoặc bị chậm trễ nhiều hơn hay không.
Vì sao điều này quan trọng
Bổ sung bối cảnh kinh doanh, giúp phân tích nhu cầu, tác động và hiệu suất của thay đổi từ góc độ tổ chức.
Lấy dữ liệu ở đâu
Thông tin này có thể nằm trong một trường trên đối tượng Change Request hoặc được lấy từ hồ sơ người dùng gửi yêu cầu.
Ví dụ
Tài chínhNhân sựKinh doanh và tiếp thịVận hành
|
|||
|
Hoàn tất đúng hạn
IsOnTimeCompletion
|
Cờ được tính là true nếu thay đổi hoàn tất vào hoặc trước ngày mục tiêu. | ||
|
Mô tả
Đây là thuộc tính boolean, được tính bằng cách so sánh 'ActualCompletionDate' với 'TargetCompletionDate'. Thuộc tính này giúp phân tích dễ hơn nhờ cho biết rõ từng yêu cầu thay đổi có hoàn tất đúng hạn hay không. Cờ này là cơ sở để tính KPI 'Tỷ lệ hoàn tất thay đổi đúng hạn'. Bạn có thể dùng cờ làm bộ lọc trên dashboard để nhanh chóng tìm và phân tích các thay đổi trễ hạn, từ đó xác định nguyên nhân phổ biến gây chậm trễ.
Vì sao điều này quan trọng
Cho biết rõ kết quả đạt hay không đạt thời hạn, giúp phân tích hiệu suất và tính trực tiếp các KPI về hoàn tất đúng hạn.
Lấy dữ liệu ở đâu
Thuộc tính này không có trong hệ thống nguồn. Thuộc tính được tính trong quá trình chuyển đổi dữ liệu bằng cách so sánh 'ActualCompletionDate' <= 'TargetCompletionDate'.
Ví dụ
truefalse
|
|||
|
Lý do từ chối
ChangeRejectionReason
|
Mô tả bằng văn bản hoặc danh mục giải thích lý do yêu cầu thay đổi bị từ chối. | ||
|
Mô tả
Khi yêu cầu thay đổi bị từ chối, thuộc tính này ghi lại lý do người phê duyệt đưa ra. Lý do có thể được chọn từ danh sách có sẵn hoặc nhập dưới dạng văn bản. Thông tin này rất cần thiết cho dashboard 'Phân tích yêu cầu thay đổi bị từ chối'. Bằng cách phân loại và phân tích lý do từ chối, tổ chức có thể xác định các vấn đề thường gặp trong yêu cầu, chẳng hạn thiếu thông tin, đánh giá rủi ro chưa đầy đủ hoặc xung đột với hoạt động kinh doanh. Từ đó, tổ chức có thể nâng cao chất lượng các yêu cầu thay đổi sau này.
Vì sao điều này quan trọng
Cho biết trực tiếp lý do thay đổi không được chấp thuận, giúp cải thiện đúng trọng tâm khâu gửi yêu cầu và đánh giá để giảm tỷ lệ từ chối chung.
Lấy dữ liệu ở đâu
Dữ liệu này thường được ghi trong trường riêng 'Rejection Reason' hoặc trường ghi chú, được điền khi trạng thái chuyển thành 'Rejected'.
Ví dụ
Kế hoạch triển khai thiếu chi tiếtĐánh giá rủi ro chưa hoàn tấtXung đột với các thay đổi khác đã lên lịch
|
|||
|
Mức độ ưu tiên của thay đổi
ChangePriority
|
Mức độ ưu tiên của yêu cầu thay đổi, cho biết tính cấp bách và tác động đến hoạt động kinh doanh. | ||
|
Mô tả
Mức độ ưu tiên của thay đổi được xác định dựa trên mức độ khẩn cấp và tác động của thay đổi. Thuộc tính này giúp các nhóm sắp xếp công việc và phân bổ tài nguyên hiệu quả, để xử lý các thay đổi quan trọng nhất trước. Khi phân tích, bạn có thể dùng mức độ ưu tiên để xem các thay đổi ưu tiên cao có được xử lý nhanh hơn những thay đổi ưu tiên thấp hay không. Nếu kết quả khác với dự kiến, có thể quy trình sắp xếp ưu tiên hoặc thực hiện đang kém hiệu quả hay có điểm nghẽn.
Vì sao điều này quan trọng
Giúp phân tích liệu quy trình có ưu tiên đúng các thay đổi tác động lớn và có thực sự đẩy nhanh việc xử lý những thay đổi đó như dự kiến hay không.
Lấy dữ liệu ở đâu
Thường là trường 'Priority' trên đối tượng Change Request. Giá trị có thể được đặt thủ công hoặc suy ra từ các trường về tác động và mức độ khẩn cấp.
Ví dụ
1 - Nghiêm trọng2 - Cao3 - Trung bình4 - Thấp
|
|||
|
Ngày hoàn tất thực tế
ActualCompletionDate
|
Thời điểm thay đổi thực sự được triển khai và xác nhận là đã hoàn tất. | ||
|
Mô tả
Ngày hoàn tất thực tế đánh dấu thời điểm công việc triển khai yêu cầu thay đổi kết thúc. Đây là mốc quan trọng để so sánh với thời hạn đã lên kế hoạch và đánh giá hiệu suất. Bạn có thể kết hợp thuộc tính này với Ngày hoàn tất mục tiêu để xác định thay đổi có hoàn tất đúng hạn hay không. Đây là dữ liệu đầu vào thiết yếu để tính các KPI như 'Tỷ lệ hoàn tất thay đổi đúng hạn' và phân tích nguyên nhân chậm trễ trong giai đoạn triển khai.
Vì sao điều này quan trọng
Ghi lại thời điểm hoàn tất thực tế, cần thiết để tính tỷ lệ hoàn tất đúng hạn và phân tích mức độ chậm trễ.
Lấy dữ liệu ở đâu
Ngày này thường được ghi nhận khi trạng thái yêu cầu thay đổi chuyển thành 'Implemented' hoặc 'Completed'. Ngày có thể nằm trong một trường riêng hoặc được suy ra từ dấu thời gian của lần đổi trạng thái đó.
Ví dụ
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
|
|||
|
Người gửi yêu cầu thay đổi
ChangeSubmitter
|
Người dùng khởi tạo hoặc gửi yêu cầu thay đổi. | ||
|
Mô tả
Thuộc tính này xác định người khởi tạo yêu cầu thay đổi. Người này có thể khác với người phụ trách thay đổi, người sẽ chịu trách nhiệm triển khai ở giai đoạn sau. Phân tích người gửi yêu cầu thay đổi giúp phát hiện các xu hướng liên quan đến chất lượng yêu cầu. Chẳng hạn, bạn có thể thấy một số cá nhân hoặc nhóm thường gửi yêu cầu thiếu thông tin, dẫn đến bị từ chối hoặc phải làm lại. Từ đó, tổ chức có thể đào tạo đúng đối tượng và nâng cao chất lượng yêu cầu.
Vì sao điều này quan trọng
Giúp truy tìm nguồn khởi tạo yêu cầu thay đổi, phân tích chất lượng yêu cầu theo cá nhân hoặc nhóm và xác định nhu cầu đào tạo.
Lấy dữ liệu ở đâu
Thường là trường 'Created By' hoặc 'Requested By' trên đối tượng Change Request.
Ví dụ
Susan MillerDavid ChenMaria Garcia
|
|||
|
Thời gian triển khai thay đổi
ImplementationCycleTime
|
Khoảng thời gian được tính từ lúc bắt đầu triển khai thay đổi đến khi hoàn tất. | ||
|
Mô tả
Chỉ số này đo thời gian thực hiện giai đoạn triển khai thay đổi. Chỉ số được tính bằng khoảng thời gian từ hoạt động 'Bắt đầu triển khai thay đổi' đến hoạt động 'Đã triển khai thay đổi'. Thuộc tính này được dùng để tính KPI 'Thời gian triển khai thay đổi trung bình' và hỗ trợ dashboard 'Luồng triển khai thay đổi và độ trễ'. Nhờ đó, bạn có thể phân biệt chậm trễ trong khâu lập kế hoạch với chậm trễ khi thực hiện, để đội ngũ tập trung cải tiến công việc triển khai kỹ thuật.
Vì sao điều này quan trọng
Tách riêng hiệu suất của giai đoạn triển khai thực tế, giúp xác định điểm nghẽn về kỹ thuật hoặc tài nguyên, không nhầm với chậm trễ do phê duyệt.
Lấy dữ liệu ở đâu
Được tính trong công cụ process mining hoặc khi chuyển đổi dữ liệu bằng cách lấy thời điểm của sự kiện bắt đầu trừ thời điểm của sự kiện kết thúc triển khai.
Ví dụ
4 giờ 15 phút1 ngày 2 giờ30 phút
|
|||
Hoạt động quản lý thay đổi
| Hoạt động | Mô tả | ||
|---|---|---|---|
|
CAB đã phê duyệt thay đổi
|
Đây là cột mốc quan trọng khi Hội đồng tư vấn thay đổi (CAB) hoặc cơ quan được chỉ định phê duyệt cho phép thực hiện thay đổi. Sự kiện được suy ra khi trạng thái yêu cầu thay đổi được cập nhật thành 'Đã phê duyệt'. | ||
|
Vì sao điều này quan trọng
Hoạt động này là điểm kết thúc để đo thời gian chu kỳ phê duyệt. Sau khi được phê duyệt, quy trình có thể chuyển sang lập kế hoạch và triển khai. Đây cũng là dữ liệu quan trọng cho KPI Thời gian chu kỳ phê duyệt thay đổi.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử kiểm tra của đối tượng Yêu cầu thay đổi, cụ thể là dấu thời gian trường 'Status' chuyển thành 'Đã phê duyệt'.
Thu thập
Suy ra từ việc trạng thái chuyển thành 'Đã phê duyệt'.
Loại sự kiện
inferred
|
|||
|
Đã đánh giá tác động và rủi ro
|
Hoạt động này cho biết việc phân tích rủi ro và tác động của yêu cầu thay đổi đã hoàn tất. Thông thường, sự kiện được suy ra khi trạng thái yêu cầu chuyển sang trạng thái cho biết đã sẵn sàng phê duyệt, chẳng hạn như 'Đang chờ phê duyệt'. | ||
|
Vì sao điều này quan trọng
Theo dõi hoạt động này giúp đo thời lượng của giai đoạn đánh giá và đảm bảo rủi ro luôn được phân tích trước khi phê duyệt, hỗ trợ KPI Tỷ lệ tuân thủ đánh giá rủi ro.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử của đối tượng Yêu cầu thay đổi. Sự kiện được ghi nhận tại dấu thời gian trường 'Status' được cập nhật từ 'Đang đánh giá' sang trạng thái như 'Đang chờ CAB phê duyệt'.
Thu thập
Suy ra từ việc trạng thái chuyển sang 'Đang chờ CAB phê duyệ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 ngày và giờ triển khai thay đổi được xác nhận chính thức và ghi lại. Sự kiện được ghi nhận khi trạng thái được cập nhật thành 'Đã lên lịch'. | ||
|
Vì sao điều này quan trọng
Đây là một mốc cam kết quan trọng. Mốc này đánh dấu bước chuyển từ ý tưởng đã được phê duyệt sang hành động có kế hoạch, đồng thời là điều kiện cần trước khi triển khai.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử của đối tượng Change Request bằng cách ghi nhận thời điểm trường 'Status' được cập nhật thành 'Scheduled'.
Thu thập
Suy ra từ lần đổi trạng thái thành 'Scheduled'.
Loại sự kiện
inferred
|
|||
|
Đã tạo yêu cầu thay đổi
|
Hoạt động này đánh dấu thời điểm tạo yêu cầu thay đổi mới trong hệ thống. Thông thường, sự kiện được ghi nhận khi tạo bản ghi mới trong đối tượng nghiệp vụ Yêu cầu thay đổi, xác định điểm bắt đầu của toàn bộ quy trình. | ||
|
Vì sao điều này quan trọng
Đây là sự kiện bắt đầu chính của quy trình. Phân tích khoảng thời gian từ hoạt động này đến các hoạt động khác giúp xác định tổng thời gian vòng đời và phát hiện chậm trễ ở giai đoạn đầu.
Lấy dữ liệu ở đâu
Sự kiện này được ghi nhận từ dấu thời gian tạo bản ghi Yêu cầu thay đổi. Trong Ivanti Cherwell, thông tin này thường được lưu trong trường 'CreatedDateTime' của đối tượng nghiệp vụ Yêu cầu thay đổi.
Thu thập
Ghi nhận trực tiếp từ dấu thời gian tạo bản ghi.
Loại sự kiện
explicit
|
|||
|
Đã tiến hành đánh giá sau triển khai
|
Hoạt động này cho biết đã có buổi đánh giá chính thức về thay đổi sau khi hoàn tất, nhằm xem xét kết quả và ghi lại bài học kinh nghiệm. Thường có thể suy ra mốc này từ lần đổi trạng thái thành 'Post Implementation Review'. | ||
|
Vì sao điều này quan trọng
Theo dõi mốc này giúp khép lại vòng phản hồi về các thay đổi. Đây là việc cần thiết để cải tiến liên tục và góp phần trực tiếp vào KPI Tỷ lệ đánh giá sau triển khai.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử của đối tượng Change Request bằng cách ghi nhận thời điểm 'Status' chuyển sang trạng thái như 'Post Implementation Review'.
Thu thập
Suy ra từ lần đổi trạng thái thành 'Post Implementation Review'.
Loại sự kiện
inferred
|
|||
|
Đã triển khai thay đổi
|
Mốc này cho biết công việc kỹ thuật của thay đổi đã hoàn tất. Ghi nhận mốc này khi trạng thái yêu cầu thay đổi thành 'Implemented' hoặc một trạng thái tương tự đang chờ xác minh. | ||
|
Vì sao điều này quan trọng
Đây là mốc quan trọng để xác nhận thành công và là dữ liệu đầu vào chính cho KPI Tỷ lệ hoàn tất thay đổi đúng hạn và Thời gian triển khai thay đổi trung bình. Mốc này đánh dấu kết thúc giai đoạn thực hiện.
Lấy dữ liệu ở đâu
Suy ra từ nhật ký kiểm tra của đối tượng Change Request, dựa trên thời điểm trạng thái đổi thành 'Implemented' hoặc 'Pending Verification'.
Thu thập
Suy ra từ lần đổi trạng thái thành 'Implemented'.
Loại sự kiện
inferred
|
|||
|
Đóng thay đổi
|
Đây là điểm kết thúc cuối cùng, xác nhận quy trình quản lý thay đổi đã hoàn tất thành công. Ghi nhận khi trạng thái yêu cầu thay đổi được đặt thành 'Closed', cho biết mọi công việc đã xong. | ||
|
Vì sao điều này quan trọng
Là mốc kết thúc chính để xác nhận thành công, hoạt động này cần thiết khi tính tổng thời gian xử lý từ đầu đến cuối của các thay đổi đã hoàn tất. Mốc này xác nhận mọi bước trong quy trình đã kết thúc.
Lấy dữ liệu ở đâu
Suy ra từ thời điểm đổi trạng thái cuối cùng thành 'Closed' trong lịch sử kiểm tra của đối tượng Change Request.
Thu thập
Suy ra từ lần đổi trạng thái cuối cùng thành 'Closed'.
Loại sự kiện
inferred
|
|||
|
Bắt đầu triển khai thay đổi
|
Đánh dấu thời điểm bắt đầu thực hiện thay đổi về mặt kỹ thuật. Thường có thể suy ra mốc này khi trạng thái yêu cầu thay đổi thành 'In Progress' hoặc 'Implementing'. | ||
|
Vì sao điều này quan trọng
Hoạt động này đánh dấu thời điểm bắt đầu triển khai. Khoảng thời gian từ mốc này đến 'Change Implemented' là thời lượng triển khai thực tế, một phần quan trọng trong tổng thời gian xử lý.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử kiểm tra của đối tượng Change Request. Đây là thời điểm trường 'Status' được cập nhật thành một giá trị như 'In Progress' hoặc 'Implementing'.
Thu thập
Suy ra từ lần đổi trạng thái thành 'In Progress'.
Loại sự kiện
inferred
|
|||
|
Đã gửi thay đổi để đánh giá
|
Đây là thời điểm chính thức gửi yêu cầu thay đổi mới tạo để đánh giá ban đầu. Thông thường, sự kiện được suy ra khi trạng thái yêu cầu thay đổi chuyển từ 'Mới' hoặc 'Bản nháp' sang trạng thái như 'Đang đánh giá'. | ||
|
Vì sao điều này quan trọng
Hoạt động này đánh dấu thời điểm bắt đầu quy trình thay đổi chính thức sau khi nhập dữ liệu ban đầu. Khoảng thời gian từ lúc tạo đến lúc gửi yêu cầu có thể cho thấy nhu cầu đào tạo người dùng hoặc trở ngại trong quy trình.
Lấy dữ liệu ở đâu
Suy ra từ nhật ký kiểm tra hoặc lịch sử của đối tượng Yêu cầu thay đổi bằng cách xác định dấu thời gian trường 'Status' chuyển sang giá trị như 'Đang đánh giá' hoặc 'Đã gửi'.
Thu thập
Suy ra từ việc trạng thái chuyển từ 'Mới' sang 'Đang đánh giá'.
Loại sự kiện
inferred
|
|||
|
Đã lập kế hoạch triển khai
|
Đánh dấu thời điểm hoàn tất kế hoạch chi tiết cho thay đổi, bao gồm xác định các nhiệm vụ, tài nguyên và kế hoạch khôi phục. Sự kiện này thường được suy ra khi trạng thái thay đổi chuyển từ 'Đã phê duyệt' sang 'Đã lên lịch'. | ||
|
Vì sao điều này quan trọng
Thời lượng hoạt động này cho thấy hiệu quả của giai đoạn lập kế hoạch thay đổi. Chậm trễ ở đây có thể ảnh hưởng đến toàn bộ tiến độ thay đổi, ngay cả khi đã được phê duyệt.
Lấy dữ liệu ở đâu
Có thể suy ra từ dấu thời gian trạng thái chuyển từ 'Đã phê duyệt' sang 'Đã lên lịch'. Ngoài ra, sự kiện cũng có thể được xác định khi điền các trường lập kế hoạch cụ thể.
Thu thập
Suy ra từ việc trạng thái chuyển từ 'Đã phê duyệt' sang 'Đã lên lịch'.
Loại sự kiện
inferred
|
|||
|
Đã xác minh thay đổi
|
Đánh dấu giai đoạn kiểm thử và xác nhận để bảo đảm thay đổi thành công và không gây tác động bất lợi. Có thể suy ra mốc này từ lần đổi trạng thái thành 'Verification' hoặc 'Testing'. | ||
|
Vì sao điều này quan trọng
Phân tích tần suất và thời lượng của hoạt động này giúp bảo đảm các bước kiểm tra chất lượng không bị bỏ qua. Đây là bước quan trọng để ngăn sự cố phát sinh do thay đổi.
Lấy dữ liệu ở đâu
Ghi nhận từ thời điểm trạng thái của đối tượng Change Request thay đổi, chẳng hạn khi chuyển sang 'Verification' hoặc 'User Acceptance Testing'.
Thu thập
Suy ra từ lần đổi trạng thái thành 'Verification'.
Loại sự kiện
inferred
|
|||
|
Hủy thay đổi
|
Đây là trạng thái kết thúc khi yêu cầu thay đổi đã được phê duyệt hoặc đang thực hiện bị rút lại trước khi hoàn tất. Ghi nhận sự kiện này khi trạng thái được cập nhật thành 'Cancelled'. | ||
|
Vì sao điều này quan trọng
Đây là một điểm kết thúc khác của quy trình. Phân tích lý do và thời điểm hủy thay đổi có thể giúp phát hiện vấn đề trong khâu lập kế hoạch, phân bổ tài nguyên hoặc thay đổi ưu tiên kinh doanh.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử kiểm tra bằng cách ghi nhận thời điểm trường 'Status' của đối tượng Change Request được cập nhật thành 'Cancelled'.
Thu thập
Suy ra từ lần đổi trạng thái thành 'Cancelled'.
Loại sự kiện
inferred
|
|||
|
Thay đổi bị từ chối
|
Hoạt động này thể hiện quyết định cuối cùng từ chối yêu cầu thay đổi trong giai đoạn phê duyệt. Sự kiện được ghi nhận khi trạng thái yêu cầu thay đổi được đặt thành 'Bị từ chối'. | ||
|
Vì sao điều này quan trọng
Đây là điểm kết thúc quan trọng của một trường hợp thất bại. Phân tích các thay đổi bị từ chối và lý do từ chối giúp cải thiện chất lượng yêu cầu ban đầu, đồng thời hỗ trợ KPI Tỷ lệ yêu cầu thay đổi bị từ chối.
Lấy dữ liệu ở đâu
Suy ra từ dấu thời gian trường 'Status' trong đối tượng Yêu cầu thay đổi được cập nhật thành 'Bị từ chối' trong lịch sử kiểm tra.
Thu thập
Suy ra từ việc trạng thái chuyển thành 'Bị từ chối'.
Loại sự kiện
inferred
|
|||
|
Thay đổi đang chờ phê duyệt
|
Hoạt động này thể hiện khoảng thời gian yêu cầu thay đổi chính thức chờ quyết định từ Hội đồng tư vấn thay đổi (CAB) hoặc cơ quan phê duyệt khác. Sự kiện được suy ra từ trạng thái như 'Chờ phê duyệt' hoặc 'Đang chờ CAB'. | ||
|
Vì sao điều này quan trọng
Đây là hoạt động có thời gian chờ quan trọng. Phân tích thời lượng giúp xác định điểm nghẽn trong quy trình phê duyệt, vốn thường là nguyên nhân gây chậm trễ trong quản lý thay đổi.
Lấy dữ liệu ở đâu
Ghi nhận từ dấu thời gian trường 'Status' trong đối tượng nghiệp vụ Yêu cầu thay đổi được cập nhật thành 'Chờ phê duyệt' hoặc giá trị tương đương.
Thu thập
Xác định khi yêu cầu chuyển sang trạng thái 'Chờ phê duyệt'.
Loại sự kiện
inferred
|
|||
Hướng dẫn trích xuất
Sẵn sàng bắt đầu?
Dùng mẫu này để bắt đầu phân tích quy trình quản lý thay đổi và tìm ra cơ hội cải tiến đáng kể. Bắt đầu tối ưu hóa các đợt cập nhật để quy trình hiệu quả hơn ngay hôm nay.
Đạt tỷ lệ thay đổi thành công 95%: Tối ưu Ivanti Cherwell ngay
Gỡ bỏ điểm nghẽn, giảm rủi ro và đạt tỷ lệ thay đổi thành công 95%.
Không cần thẻ tín dụng. Bắt đầu ngay.