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
- Các thuộc tính nên thu thập
- Các hoạt động chính cần theo dõi để khám phá quy trình chính xác
- Hướng dẫn trích xuất dữ liệu từ ServiceNow
Thuộc tính quản lý thay đổi
| Tên | Mô tả | ||
|---|---|---|---|
|
ID Change Request
ChangeRequestNumber
|
Mã định danh duy nhất của Change Request, dùng làm ID hồ sơ chính để nhóm tất cả sự kiện liên quan. | ||
|
Mô tả
ID Change Request là nền tảng để phân tích quy trình quản lý thay đổi. Đây là mã duy nhất được gán cho mỗi Change Request, chẳng hạn như 'CHG0030001', giúp liên kết mọi hoạt động, phê duyệt và tác vụ liên quan. Trong process mining, thuộc tính này được dùng để dựng lại toàn bộ hành trình của từng change. Nhờ đó, chuyên viên phân tích có thể theo dõi vòng đời từ lúc tạo đến khi đóng và hiểu rõ từng change đi qua hệ thống như thế nào. Nhóm quy trình theo ID này là việc cần thiết để tính thời gian chu kỳ, xác định các vòng lặp làm lại và hiểu các biến thể của quy trình.
Vì sao điều này quan trọng
ID này rất cần thiết để theo dõi toàn bộ vòng đời của change, từ đó phân tích đầy đủ luồng quy trình, thời lượng và mức độ tuân thủ của từng yêu cầu.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, trường: number
Ví dụ
CHG0030001CHG0030045CHG0030112
|
|||
|
Thời điểm sự kiện
EventTime
|
Dấu thời gian chính xác khi một hoạt động hoặc sự kiện cụ thể diễn ra. | ||
|
Mô tả
Thời điểm sự kiện ghi lại chính xác ngày giờ một hoạt động được thực hiện hoặc một thay đổi trạng thái được ghi nhận. Dấu thời gian này rất quan trọng để sắp xếp sự kiện theo trình tự thời gian và phân tích mọi loại thời lượng. Trong process mining, thuộc tính này giúp tính thời gian chu kỳ, thời gian xử lý và thời gian chờ giữa các hoạt động. Đây là dữ liệu cần thiết cho các dashboard phân tích hiệu suất, chẳng hạn như Change Approval Cycle Time và End-to-End Change Process Flow. Dấu thời gian chính xác là cơ sở để phát hiện chậm trễ và đo hiệu quả quy trình so với SLA.
Vì sao điều này quan trọng
Dấu thời gian này rất quan trọng để sắp xếp sự kiện chính xác và tính mọi chỉ số dựa trên thời gian, bao gồm thời gian chu kỳ, thời lượng và mức độ đáp ứng SLA.
Lấy dữ liệu ở đâu
Bảng ServiceNow: sys_audit, trường: sys_created_on. Trường này cung cấp dấu thời gian cho mỗi thay đổi được ghi nhận.
Ví dụ
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
|
|||
|
Tên hoạt động
ActivityName
|
Tên của một sự kiện hoặc tác vụ cụ thể diễn ra trong quy trình quản lý thay đổi. | ||
|
Mô tả
Tên hoạt động mô tả một bước riêng lẻ hoặc lần thay đổi trạng thái trong vòng đời của Change Request. Ví dụ: 'Change chờ đánh giá', 'Gửi yêu cầu phê duyệt' và 'Hoàn tất triển khai change'. Các hoạt động này tạo thành những nút trên sơ đồ quy trình được phát hiện. Phân tích các hoạt động này giúp xem xét chi tiết luồng quy trình. Bằng cách theo dõi trình tự và tần suất hoạt động, tổ chức có thể xác định các lộ trình phổ biến, điểm khác với quy trình chuẩn và điểm nghẽn khiến change thường bị đình trệ. Đây là cơ sở để trực quan hóa quy trình và tính các chỉ số như thời gian chuyển tiếp giữa các bước.
Vì sao điều này quan trọng
Thuộc tính này tạo nên cấu trúc chính của sơ đồ quy trình, giúp trực quan hóa luồng quy trình, xác định điểm nghẽn và phân tích các điểm khác biệt.
Lấy dữ liệu ở đâu
Được xác định từ các thay đổi trong trường 'state' hoặc những trường trạng thái quan trọng khác của bảng 'change_request', thường được ghi lại trong bảng 'sys_audit'.
Ví dụ
Change được phê duyệtBắt đầu triển khaiĐóng ChangeHủy Change
|
|||
|
Loại Change
ChangeType
|
Phân loại change, chẳng hạn như 'Standard', 'Normal' hoặc 'Emergency'. | ||
|
Mô tả
Loại Change phân loại Change Request dựa trên tính chất, rủi ro và yêu cầu phê duyệt. Change Standard được phê duyệt trước, Change Normal tuân theo quy trình đầy đủ, còn Change Emergency đi theo lộ trình rút gọn. Đây là chiều phân tích cơ bản vì mỗi loại change có quy trình riêng phù hợp. So sánh hiệu suất của Change Normal và Change Emergency có thể cho thấy mức độ tuân thủ quy trình và hiệu quả. Thuộc tính này cũng được dùng trong các dashboard như 'Risk Assessment Standardization' để bảo đảm các change tương tự được xử lý nhất quán.
Vì sao điều này quan trọng
Cho phép phân nhóm phân tích, vì mỗi loại change tuân theo luồng quy trình được phê duyệt riêng và có kỳ vọng hiệu suất khác nhau.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, trường: type
Ví dụ
StandardNormalEmergency
|
|||
|
Mục cấu hình
ConfigurationItem
|
Thành phần, dịch vụ hoặc hệ thống CNTT cụ thể chịu tác động của change. | ||
|
Mô tả
Mục cấu hình (CI) là tài sản trong Cơ sở dữ liệu quản lý cấu hình (CMDB) chịu tác động của change. Đó có thể là máy chủ, ứng dụng phần mềm, thiết bị mạng hoặc dịch vụ nghiệp vụ. Thuộc tính này cung cấp bối cảnh quan trọng cho change. Trong process mining, thuộc tính này cho phép phân nhóm phân tích theo loại tài sản được thay đổi. Ví dụ, dashboard 'Change Testing Duration Analysis' dùng thuộc tính này để so sánh thời gian kiểm thử giữa các ứng dụng hoặc hệ thống, giúp xác định CI nào thường có chu kỳ kiểm thử dài hơn.
Vì sao điều này quan trọng
Cung cấp bối cảnh nghiệp vụ cần thiết, cho phép lọc phân tích theo ứng dụng, dịch vụ hoặc hệ thống chịu tác động để xác định vấn đề riêng của từng thành phần.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, trường: cmdb_ci
Ví dụ
SAP ERPOracle Database 19cDịch vụ emailWebServer-01
|
|||
|
Mức độ rủi ro
RiskLevel
|
Mức rủi ro đã đánh giá của change, chẳng hạn như 'High', 'Moderate' hoặc 'Low'. | ||
|
Mô tả
Mức độ rủi ro là kết quả đánh giá rủi ro của Change Request. Mức này cho biết khả năng xảy ra hậu quả bất lợi nếu change được triển khai, giúp xác định mức độ xem xét và phê duyệt cần thiết. Thuộc tính này đóng vai trò quan trọng trong dashboard 'Risk Assessment Standardization', nơi dùng để kiểm tra xem các change tương tự có được đánh giá rủi ro nhất quán hay không. Phân tích luồng quy trình theo mức độ rủi ro cũng giúp xác định change rủi ro cao có tuân theo quy trình phê duyệt và kiểm thử chặt chẽ hơn change rủi ro thấp hay không. Đây là bước kiểm tra tuân thủ quan trọng.
Vì sao điều này quan trọng
Cần thiết để phân tích tuân thủ và bảo đảm change rủi ro cao được xem xét đúng mức, đồng thời tuân theo quy trình chặt chẽ hơn.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, trường: risk
Ví dụ
CaoTrung bìnhThấp
|
|||
|
Mức độ ưu tiên
Priority
|
Mức độ ưu tiên của Change Request, được xác định dựa trên tác động và mức độ khẩn cấp. | ||
|
Mô tả
Mức độ ưu tiên cho biết tầm quan trọng của Change Request và thứ tự cần xử lý. Mức này thường được xác định dựa trên tác động và mức độ khẩn cấp của change, với các giá trị như 'Critical', 'High', 'Moderate' và 'Low'. Phân tích theo mức độ ưu tiên giúp bảo đảm change ưu tiên cao được xử lý nhanh hơn change ưu tiên thấp. Thuộc tính này hỗ trợ dashboard 'Critical Change Performance', cho phép chuyên viên phân tích theo dõi thời gian chu kỳ và tỷ lệ thất bại riêng cho những change quan trọng nhất. Nếu change ưu tiên thấp hoàn tất nhanh hơn change ưu tiên cao, có thể đã xảy ra vấn đề trong phân bổ tài nguyên hoặc thực hiện quy trình.
Vì sao điều này quan trọng
Rất quan trọng để đánh giá tài nguyên có được phân bổ phù hợp cho những change cấp thiết nhất hay không và theo dõi riêng hiệu suất của chúng.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, trường: priority
Ví dụ
1 - Cấp thiết2 - Cao3 - Trung bình4 - Thấp
|
|||
|
Nhóm được giao
AssignmentGroup
|
Nhóm chịu trách nhiệm xử lý Change Request. | ||
|
Mô tả
Nhóm được giao cho biết nhóm nào hiện chịu trách nhiệm xử lý Change Request, chẳng hạn như 'CAB Approval', 'Network Engineering' hoặc 'Database Administrators'. Đây là chiều phân tích quan trọng để đánh giá hiệu suất quy trình giữa các bộ phận chức năng. Thuộc tính này được dùng để đo hiệu quả ở cấp nhóm, xác định điểm nghẽn trong từng nhóm và phân tích hiệu quả bàn giao giữa các nhóm. Các dashboard như 'Cross-Functional Handoff Efficiency' và 'Change Implementation Throughput' phụ thuộc nhiều vào dữ liệu này để xác định chậm trễ do sự phụ thuộc giữa các nhóm.
Vì sao điều này quan trọng
Cho phép phân tích hiệu suất theo nhóm, làm rõ điểm nghẽn riêng của từng nhóm và đo hiệu quả bàn giao giữa các bộ phận chức năng.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, trường: assignment_group
Ví dụ
CAB ApprovalNhóm mạngHỗ trợ máy chủQuản trị cơ sở dữ liệu
|
|||
|
Thời điểm kết thúc
EndTime
|
Dấu thời gian khi một hoạt động kết thúc. Thường được xác định từ thời điểm bắt đầu của hoạt động tiếp theo. | ||
|
Mô tả
Thời điểm kết thúc đánh dấu lúc một hoạt động hoàn tất. Hệ thống nguồn thường ghi lại thời điểm bắt đầu sự kiện, còn thời điểm kết thúc thường được suy ra. Thông thường, thời điểm này được tính bằng dấu thời gian của hoạt động tiếp theo trong cùng một hồ sơ. Thuộc tính này cần thiết để tính thời lượng của từng hoạt động, còn gọi là thời gian xử lý. Hiểu mỗi bước mất bao lâu là điều cơ bản để xác định điểm nghẽn và điểm kém hiệu quả trong quy trình. Với hoạt động cuối cùng của một hồ sơ, thời điểm kết thúc trùng với thời điểm bắt đầu.
Vì sao điều này quan trọng
Cho phép tính thời gian xử lý hoạt động, yếu tố quan trọng để xác định điểm nghẽn và đo thời lượng của từng bước trong quy trình.
Lấy dữ liệu ở đâu
Thuộc tính này thường được tính trong quá trình chuyển đổi dữ liệu, bằng cách lấy StartTime của sự kiện tiếp theo có cùng CaseId.
Ví dụ
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Trạng thái Change
ChangeState
|
Trạng thái hiện tại hoặc trước đây của Change Request, chẳng hạn như 'Assess', 'Authorize', 'Implement' hoặc 'Closed'. | ||
|
Mô tả
Thuộc tính Trạng thái Change thể hiện trạng thái của Change Request tại một thời điểm cụ thể. Thuộc tính này tóm tắt change đang ở giai đoạn nào trong vòng đời. Khác với Hoạt động, vốn thể hiện một sự kiện cụ thể, Trạng thái cho biết tình trạng sau sự kiện đó. Khi phân tích, Trạng thái Change được dùng để phân loại hồ sơ và tìm hiểu kết quả. Thuộc tính này rất cần thiết để lọc change, chẳng hạn chỉ phân tích các change 'Closed' hoặc tìm hiểu vì sao nhiều change bị kẹt ở trạng thái 'Authorize'. Thuộc tính này cũng hỗ trợ trực tiếp các KPI như Change Failure Rate khi có trạng thái 'Failed'.
Vì sao điều này quan trọng
Cung cấp thông tin tổng quan về trạng thái Change Request, giúp phân tích kết quả, lọc hồ sơ và xác định các change bị đình trệ.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, trường: state
Ví dụ
Đánh giáCấp phépĐã lên lịchTriển khaiXem xétĐã đóngĐã hủy
|
|||
|
Hệ thống nguồn
SourceSystem
|
Hệ thống trích xuất dữ liệu, thường là 'ServiceNow'. | ||
|
Mô tả
Thuộc tính này cho biết nguồn gốc của dữ liệu quy trình. Trong trường hợp này, nguồn dự kiến là ServiceNow. Đây cũng là trường quan trọng để quản trị dữ liệu và xử lý các tình huống cần kết hợp dữ liệu từ nhiều hệ thống. Khi phân tích, thuộc tính này giúp làm rõ nguồn gốc dữ liệu và xác minh dữ liệu đến từ đâu. Với tổ chức sử dụng nhiều công cụ ITSM hoặc hệ thống tích hợp, thuộc tính này cho phép lọc và so sánh quy trình giữa các nền tảng.
Vì sao điều này quan trọng
Giúp ghi lại rõ nguồn gốc dữ liệu quy trình, yếu tố quan trọng đối với việc quản trị dữ liệu và 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 và chuyển đổi dữ liệu (ETL).
Ví dụ
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
Là công việc làm lại
IsRework
|
Cờ boolean có giá trị true nếu một hoạt động lặp lại bước đã thực hiện trước đó trong cùng một trường hợp. | ||
|
Mô tả
Thuộc tính được tính toán này xác định các hoạt động phải làm lại. Công việc làm lại xảy ra khi quy trình phải quay lại một bước đã hoàn tất, chẳng hạn như thay đổi bị từ chối sau khi phê duyệt và được gửi lại để đánh giá. Cờ này rất quan trọng để định lượng mức độ kém hiệu quả của quy trình. Cờ này hỗ trợ trực tiếp KPI “Tỷ lệ làm lại thay đổi” và dashboard “Phân tích thay đổi thất bại và công việc làm lại”. Bằng cách lọc các hoạt động có “Là công việc làm lại” bằng true, nhà phân tích có thể tách riêng và tìm hiểu nguyên nhân làm lại, chẳng hạn như đánh giá ban đầu chưa đầy đủ hoặc yêu cầu thay đổi, rồi hành động để giảm lãng phí.
Vì sao điều này quan trọng
Định lượng trực tiếp mức độ kém hiệu quả của quy trình bằng cách đánh dấu công việc lặp lại, giúp xác định và xử lý nguyên nhân gốc rễ của các vòng lặp quy trình và công sức bị lãng phí.
Lấy dữ liệu ở đâu
Được tính trong quá trình chuyển đổi dữ liệu bằng cách kiểm tra xem cùng một hoạt động (hoặc hoạt động trước đó trong luồng chuẩn) đã xảy ra với CaseId tương ứng hay chưa.
Ví dụ
truefalse
|
|||
|
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 cung cấp dấu thời gian của lần trích xuất dữ liệu gần nhất. Đây là trường siêu dữ liệu quan trọng, giúp xác định dữ liệu đang phân tích có mới hay không. Chuyên viên phân tích dùng dấu thời gian này để xác nhận thông tin đang cập nhật và biết dữ liệu được lấy gần đây đến mức nào. Thuộc tính này đặc biệt quan trọng với các dashboard vận hành theo dõi hiệu suất quy trình đang diễn ra, giúp bạn không đư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 còn mới hay không, giúp bảo đảm các phân tích và dashboard dựa trên thông tin hiện hành, phù hợp.
Lấy dữ liệu ở đâu
Đây là trường siêu dữ liệu được tạo trong quá trình trích xuất và chuyển đổi dữ liệu (ETL), cho biết thời điểm lấy dữ liệu.
Ví dụ
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Mã đóng yêu cầu
CloseCode
|
Mã cho biết kết quả khi yêu cầu thay đổi được đóng, chẳng hạn như “Thành công” hoặc “Không thành công”. | ||
|
Mô tả
Mã đóng yêu cầu ghi lại kết quả cuối cùng của một yêu cầu thay đổi đã hoàn tất. Mã này cho biết chính thức thay đổi được triển khai thành công, gặp sự cố hay phải khôi phục. Thuộc tính này là dữ liệu đầu vào trực tiếp cho KPI “Tỷ lệ thay đổi thất bại”. Bằng cách phân tích tỷ lệ các mã đóng yêu cầu, tổ chức có thể định lượng mức độ thành công của các sáng kiến thay đổi. Lọc sơ đồ quy trình để xem các thay đổi có mã đóng “Không thành công” là cách hiệu quả để phân tích nguyên nhân gốc rễ, qua đó tìm ra những mẫu quy trình thường dẫn đến thất bại.
Vì sao điều này quan trọng
Đo trực tiếp kết quả của một thay đổi, cung cấp dữ liệu chính để tính tỷ lệ thay đổi thất bại và phân tích nguyên nhân gốc rễ của các thay đổi không thành công.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, Trường: close_code
Ví dụ
Thành côngThành công nhưng có sự cốKhông thành công / Đã khôi phục
|
|||
|
Mức độ khẩn cấp
Urgency
|
Mức độ khẩn cấp cho biết cần xử lý thay đổi nhanh đến đâu, thường được xếp loại Cao, Trung bình hoặc Thấp. | ||
|
Mô tả
Mức độ khẩn cấp cho biết cần triển khai thay đổi nhanh đến đâu. Đây là mức độ nhạy cảm về thời gian của yêu cầu xét từ góc độ kinh doanh. Kết hợp với Mức độ ảnh hưởng, thông tin này được dùng để tính Mức độ ưu tiên tổng thể. Mức độ ưu tiên là trường chính để phân tích, còn Mức độ khẩn cấp cung cấp thêm bối cảnh. Bạn có thể dùng thông tin này để tìm hiểu vì sao một số thay đổi được đánh dấu là khẩn cấp và quy trình có xử lý chúng hiệu quả mà vẫn đảm bảo ổn định hay không. Thông tin này cũng giúp xác định liệu tổ chức có thường xuyên phải xử lý tình huống khẩn cấp theo hướng phản ứng tức thời hay không.
Vì sao điều này quan trọng
Cho biết mức độ nhạy cảm về thời gian của một thay đổi, giúp phân tích xem quy trình có xử lý hiệu quả các yêu cầu cần giải quyết gấp hay không.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, Trường: urgency
Ví dụ
1 - Cao2 - Trung bình3 - Thấp
|
|||
|
Người dùng được giao
AssignedToUser
|
Người dùng chịu trách nhiệm xử lý Change Request tại một thời điểm cụ thể. | ||
|
Mô tả
Thuộc tính này xác định người được giao xử lý Change Request. Người phụ trách có thể thay đổi nhiều lần trong vòng đời yêu cầu khi công việc chuyển qua các giai đoạn và nhóm khác nhau. Phân tích theo người dùng giúp hiểu cách phân bổ khối lượng công việc, hiệu suất cá nhân và nhu cầu đào tạo. Thuộc tính này cũng rất quan trọng khi phân tích bàn giao. Khi kết hợp với Nhóm được giao, bạn có thể xem công việc được chuyển giữa các cá nhân hiệu quả đến đâu.
Vì sao điều này quan trọng
Giúp theo dõi khối lượng công việc và hiệu suất của từng người dùng, đồng thời hỗ trợ phân tích chậm trễ khi bàn giao giữa các tài nguyên.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, trường: assigned_to
Ví dụ
Beth AnglinDavid LooAbel Tuter
|
|||
|
Tác động
Impact
|
Ảnh hưởng tiềm tàng của change đến hoạt động kinh doanh, được đánh giá theo các mức như Cao, Trung bình hoặc Thấp. | ||
|
Mô tả
Tác động cho biết ảnh hưởng tiềm tàng đến hoạt động kinh doanh nếu Change Request không được xử lý đúng cách. Đây là yếu tố quan trọng, cùng với Mức độ khẩn cấp, để xác định Mức độ ưu tiên chung của change. Phân tích theo Tác động giúp bảo đảm các change ảnh hưởng đến dịch vụ thiết yếu được quản lý cẩn trọng. Thuộc tính này được dùng trong dashboard 'Critical Change Performance' để lọc và theo dõi các change có tác động lớn đến hoạt động kinh doanh. Thuộc tính này cũng giúp kiểm tra tính nhất quán trong đánh giá rủi ro, bảo đảm change có tác động lớn không bị xếp vào mức rủi ro thấp nếu thiếu căn cứ.
Vì sao điều này quan trọng
Giúp ưu tiên change dựa trên ảnh hưởng tiềm tàng đến hoạt động kinh doanh và xác minh các change có tác động lớn được xử lý cẩn trọng.
Lấy dữ liệu ở đâu
Bảng ServiceNow: change_request, trường: impact
Ví dụ
1 - Cao2 - Trung bình3 - Thấp
|
|||
|
Thời gian chu kỳ
CycleTime
|
Tổng thời gian từ lúc tạo đến khi đóng yêu cầu thay đổi. | ||
|
Mô tả
Thời gian chu kỳ là chỉ số ở cấp trường hợp, đo tổng thời lượng vòng đời của một yêu cầu thay đổi. Chỉ số này được tính bằng cách lấy dấu thời gian của sự kiện cuối cùng trừ dấu thời gian của sự kiện đầu tiên trong yêu cầu thay đổi đó. Đây là KPI quan trọng để đo tốc độ tổng thể của quy trình. Chỉ số này được dùng trong dashboard “Luồng quy trình thay đổi từ đầu đến cuối” để cung cấp cái nhìn tổng quan về hiệu suất quy trình. Phân tích xu hướng thời gian chu kỳ và so sánh theo các chiều như Loại thay đổi hoặc Mức độ ưu tiên giúp tổ chức tìm ra cơ hội cải tiến quy trình.
Vì sao điều này quan trọng
Đo tổng thời lượng của quy trình thay đổi từ đầu đến cuối, cung cấp chỉ báo quan trọng về tốc độ và hiệu quả chung của quy trình.
Lấy dữ liệu ở đâu
Được tính ở cấp trường hợp trong quá trình phân tích dữ liệu bằng cách lấy StartTime lớn nhất trừ StartTime nhỏ nhất cho từng CaseId.
Ví dụ
60480012096002592000
|
|||
|
Trạng thái SLA
SlaState
|
Trạng thái của yêu cầu thay đổi so với Thỏa thuận mức dịch vụ (SLA), chẳng hạn như “Đúng tiến độ”, “Có nguy cơ trễ” hoặc “Vi phạm”. | ||
|
Mô tả
Trạng thái SLA cho biết yêu cầu thay đổi có đang tiến triển trong khung thời gian quy định trong SLA hay không. Bạn có thể theo dõi trạng thái này ở từng giai đoạn của quy trình. Thuộc tính này rất cần thiết để theo dõi việc tuân thủ các cam kết về mức dịch vụ. Đây là nguồn dữ liệu chính cho dashboard “Tổng quan hiệu suất SLA thay đổi” và KPI “Tỷ lệ tuân thủ SLA thay đổi”. Phân tích vị trí và nguyên nhân SLA bị vi phạm giúp tổ chức xử lý tình trạng chậm trễ mang tính hệ thống và cải thiện khả năng dự đoán thời gian cung cấp dịch vụ.
Vì sao điều này quan trọng
Đo trực tiếp hiệu suất so với thời hạn, giúp chủ động theo dõi và phân tích các trường hợp vi phạm SLA để cải thiện việc cung cấp dịch vụ.
Lấy dữ liệu ở đâu
Có thể lấy dữ liệu từ bảng “task_sla” trong ServiceNow, nơi theo dõi SLA của các tác vụ như yêu cầu thay đổi, hoặc tính toán dựa trên các trường ngày đến hạn.
Ví dụ
Đúng tiến độCó nguy cơ trễVi phạm
|
|||
Hoạt động quản lý thay đổi
| Hoạt động | Mô tả | ||
|---|---|---|---|
|
Change được lên lịch
|
Change đã được phê duyệt, có ngày bắt đầu và kết thúc dự kiến, đồng thời được đưa chính thức vào lịch triển khai. Có thể suy ra bước này khi trạng thái Change Request chuyển thành 'Scheduled'. | ||
|
Vì sao điều này quan trọng
Hoạt động này phân định giai đoạn lập kế hoạch và phê duyệt với giai đoạn triển khai thực tế. Thời gian ở trạng thái này có thể cho thấy công việc bị chậm giữa lúc phê duyệt và lúc bắt đầu.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này khi trường 'state' trong bảng change_request chuyển thành 'Scheduled'. Dấu thời gian được lấy từ mục nhật ký kiểm tra tương ứng.
Thu thập
Theo dõi lịch sử kiểm tra của bảng change_request để tìm các lần trường state chuyển thành 'Scheduled'.
Loại sự kiện
inferred
|
|||
|
Change được phê duyệt
|
Change Request đã nhận đủ phê duyệt cần thiết để chuyển sang giai đoạn lên lịch và triển khai. Đây là cột mốc quan trọng, được ghi nhận khi phê duyệt cuối cùng được cấp và trường 'approval' được đặt thành 'approved'. | ||
|
Vì sao điều này quan trọng
Cột mốc này kết thúc giai đoạn phê duyệt. Đây là dữ liệu cần thiết để đo thời gian chu kỳ phê duyệt và xác định điểm nghẽn trong quá trình ra quyết định.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này khi trường 'approval' trong bảng change_request chuyển thành 'approved'. Dấu thời gian được lấy từ lịch sử kiểm tra của thay đổi này.
Thu thập
Ghi nhận dấu thời gian khi trường 'approval' chuyển thành 'approved'.
Loại sự kiện
inferred
|
|||
|
Đánh giá rủi ro và tác động
|
Hoạt động này đánh dấu việc hoàn tất phân tích rủi ro và tác động của Change Request. Đây là cột mốc quan trọng trước khi xin phê duyệt. Thường có thể suy ra bước này khi trạng thái change chuyển từ 'Assess' sang 'Authorize' hoặc 'Awaiting Approval'. | ||
|
Vì sao điều này quan trọng
Theo dõi thời lượng giai đoạn đánh giá là yếu tố then chốt để tính KPI 'Avg. Risk Assessment Cycle Time'. Việc này giúp chuẩn hóa quy trình đánh giá và xác định khâu phân tích nào đang mất quá nhiều thời gian.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này khi trường 'state' trong bảng change_request chuyển từ 'Assess' sang 'Authorize'. Dấu thời gian được lấy từ nhật ký kiểm tra của lần thay đổi trạng thái này.
Thu thập
Xác định thời điểm trường 'state' chuyển từ 'Assess' sang trạng thái tiếp theo, chẳng hạn như 'Authorize'.
Loại sự kiện
inferred
|
|||
|
Đóng Change
|
Change Request đã hoàn tất thành công, được xem xét và hiện được coi là kết thúc. Đây là điểm kết thúc thành công chính của quy trình, được ghi nhận khi trạng thái change chuyển thành 'Closed'. | ||
|
Vì sao điều này quan trọng
Hoạt động này đánh dấu việc hoàn tất thành công vòng đời change. Đây là sự kiện kết thúc dùng để đo thời lượng quy trình từ đầu đến cuối và mức độ đáp ứng SLA.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này khi trường 'state' trong bảng change_request được đặt thành 'Closed'. Dấu thời gian được lấy từ lịch sử kiểm tra của lần thay đổi trạng thái cuối cùng.
Thu thập
Ghi nhận dấu thời gian khi trường 'state' được cập nhật thành 'Closed'.
Loại sự kiện
inferred
|
|||
|
Hoàn tất triển khai change
|
Công việc triển khai đã hoàn tất. Change đã sẵn sàng để xem xét, xác minh hoặc kiểm thử. Có thể suy ra hoạt động này khi trạng thái Change Request chuyển từ 'Implement' sang 'Review'. | ||
|
Vì sao điều này quan trọng
Đây là cột mốc quan trọng, đánh dấu kết thúc giai đoạn triển khai. Sự kiện này là cơ sở để tính các KPI 'Change Failure Rate' và 'Change Rework Rate'.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này khi trạng thái chuyển từ 'Implement' sang trạng thái tiếp theo, chẳng hạn như 'Review'. Dấu thời gian được lấy từ lịch sử kiểm tra trường 'state' trong bảng change_request.
Thu thập
Xác định thời điểm trường 'state' chuyển từ 'Implement' sang 'Review'.
Loại sự kiện
inferred
|
|||
|
Hủy Change
|
Change Request đã bị rút lại hoặc hủy trước khi hoàn tất triển khai. Đây là trạng thái kết thúc thay thế, được ghi nhận khi trường state được đặt thành 'Canceled'. | ||
|
Vì sao điều này quan trọng
Phân tích các change bị hủy có thể cho thấy điểm kém hiệu quả trong quy trình, chẳng hạn như tạo yêu cầu không cần thiết hoặc để yêu cầu chờ phê duyệt quá lâu đến mức không còn phù hợp.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này khi trường 'state' trong bảng change_request được đặt thành 'Canceled'. Dấu thời gian được lấy từ nhật ký kiểm tra của lần thay đổi trạng thái này.
Thu thập
Ghi nhận dấu thời gian khi trường 'state' được cập nhật thành 'Canceled'.
Loại sự kiện
inferred
|
|||
|
Tạo Change Request
|
Hoạt động này ghi nhận thời điểm tạo bản ghi Change Request mới trong hệ thống. Đây là điểm bắt đầu chính thức của quy trình quản lý thay đổi, được ghi nhận khi một mục mới được thêm vào bảng change_request. | ||
|
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 xử lý và phát hiện chậm trễ ngay từ đầu quy trình.
Lấy dữ liệu ở đâu
Sự kiện này tương ứng với dấu thời gian tạo bản ghi (sys_created_on) trong bảng change_request của ServiceNow.
Thu thập
Dùng dấu thời gian sys_created_on trong bảng change_request.
Loại sự kiện
explicit
|
|||
|
Bắt đầu triển khai
|
Công việc triển khai change đã bắt đầu. Sự kiện được ghi nhận khi trạng thái của Change Request chuyển thành 'Implement', đánh dấu bước chuyển từ lập kế hoạch sang thực hiện. | ||
|
Vì sao điều này quan trọng
Đây là thời điểm bắt đầu công việc triển khai thực tế. Mốc này dùng để tính KPI 'Average Implementation Duration' và phân tích hiệu quả của nhóm.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này khi trường 'state' trong bảng change_request chuyển thành 'Implement'. Dấu thời gian được lấy từ nhật ký kiểm tra của lần chuyển trạng thái này.
Thu thập
Ghi nhận dấu thời gian trường state chuyển thành 'Implement' từ lịch sử kiểm tra của change_request.
Loại sự kiện
inferred
|
|||
|
Change bị từ chối
|
Người phê duyệt hoặc CAB đã từ chối Change Request. Đây là trạng thái kết thúc của yêu cầu, trừ khi yêu cầu được chỉnh sửa rồi gửi lại. Sự kiện được ghi nhận khi trường 'approval' được đặt thành 'rejected'. | ||
|
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 những lý do phổ biến, chẳng hạn như thiếu thông tin hoặc rủi ro cao. Phân tích này có thể giúp nâng cao chất lượng các yêu cầu thay đổi sau này.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này khi trường 'approval' trong bảng change_request chuyển thành 'rejected'. Dấu thời gian được lấy từ lịch sử kiểm tra.
Thu thập
Ghi nhận dấu thời gian khi trường 'approval' chuyển thành 'rejected'.
Loại sự kiện
inferred
|
|||
|
Change chờ đánh giá
|
Change Request đã được gửi và đang chờ đánh giá về kỹ thuật và nghiệp vụ. Thường có thể nhận biết bước này khi trạng thái của Change Request chuyển thành 'Assess' hoặc trạng thái tương tự, cho biết yêu cầu đã rời khỏi giai đoạn nháp. | ||
|
Vì sao điều này quan trọng
Hoạt động này giúp đo thời gian bàn giao ban đầu từ người yêu cầu đến nhóm đánh giá. Nếu bước này bị chậm, nguyên nhân có thể là dữ liệu ban đầu chưa đạt chất lượng hoặc nhóm đánh giá thiếu tài nguyên.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này từ thay đổi trong trường 'state' của bảng change_request, thường là sang giá trị như 'Assess'. Dấu thời gian được lấy từ lịch sử kiểm tra (sys_audit) của thay đổi trường này.
Thu thập
Theo dõi lịch sử kiểm tra của bảng change_request để tìm các lần trường state chuyển thành 'Assess'.
Loại sự kiện
inferred
|
|||
|
Đang xem xét
|
Đang tiến hành đánh giá sau triển khai (PIR) để xác định change có thành công và đạt mục tiêu hay không. Sự kiện được ghi nhận khi trạng thái Change Request được đặt thành 'Review'. | ||
|
Vì sao điều này quan trọng
Phân tích thời lượng giai đoạn xem xét giúp phát hiện chậm trễ trong việc xác minh kết quả của change. Việc này cũng làm rõ các change không tuân thủ vì đã bỏ qua bước này.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này khi trường 'state' trong bảng change_request chuyển thành 'Review'. Dấu thời gian được lấy từ nhật ký kiểm tra của lần thay đổi trạng thái này.
Thu thập
Ghi nhận dấu thời gian trường state chuyển thành 'Review' từ lịch sử kiểm tra của change_request.
Loại sự kiện
inferred
|
|||
|
Gửi yêu cầu phê duyệt
|
Hoạt động này cho biết Change Request đã được chính thức gửi để xin phê duyệt, thường là từ quản lý hoặc Hội đồng tư vấn thay đổi (CAB). Sự kiện được ghi nhận khi trạng thái phê duyệt của Change Request được đặt thành 'requested'. | ||
|
Vì sao điều này quan trọng
Đây là thời điểm bắt đầu chu kỳ phê duyệt. Đo khoảng thời gian từ sự kiện này đến 'Change Approved' sẽ cho biết KPI 'Average Change Approval Time'.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này khi trường 'approval' trong bảng change_request chuyển thành 'requested'. Dấu thời gian của thay đổi trường này được ghi trong bảng sys_audit.
Thu thập
Dấu thời gian ghi nhận lúc trường 'approval' trong bảng change_request được đặt thành 'requested'.
Loại sự kiện
inferred
|
|||
|
Mở lại Change
|
Sau khi đến giai đoạn sau, Change Request được chuyển về trạng thái trước đó, chẳng hạn như 'Implement' hoặc 'Assess'. Có thể suy ra sự kiện này từ lần chuyển trạng thái không theo trình tự, cho thấy cần làm lại. | ||
|
Vì sao điều này quan trọng
Hoạt động này rất quan trọng để xác định các vòng lặp làm lại và tính KPI 'Change Rework Rate'. Việc mở lại thường xuyên cho thấy có vấn đề về chất lượng triển khai, kiểm thử hoặc lập kế hoạch.
Lấy dữ liệu ở đâu
Có thể suy ra sự kiện này bằng cách phân tích chuỗi thay đổi trạng thái trong lịch sử kiểm tra của change_request. Nếu trạng thái chuyển từ giai đoạn sau (ví dụ: 'Review') về giai đoạn trước (ví dụ: 'Implement'), đó là một lần mở lại.
Thu thập
Phát hiện lần chuyển ngược, không theo trình tự trong lịch sử trường 'state'.
Loại sự kiện
inferred
|
|||
Hướng dẫn trích xuất dữ liệu
Bạn đã sẵn sàng bắt đầu chưa?
Dùng mẫu này để chuẩn bị dữ liệu và tìm hiểu quy trình quản lý thay đổi trong ServiceNow. Bắt đầu tối ưu hóa để nâng cao hiệu quả ngay hôm nay.
Ngăn thay đổi thất bại, nâng cao hiệu quả ServiceNow ngay hôm nay!
Dễ dàng xác định điểm nghẽn để đạt tỷ lệ thay đổi thành công 95%.
Không cần thẻ tín dụng, thiết lập chỉ trong vài phút.