Quản lý sự thay đổi IT – IT Change Management

Một trong những khó khăn lớn nhất cho doanh nghiệp là phải đối mặt với sự phức tạp của hệ thống IT do các thành tố tạo thành của nó không chỉ do một tổ chức đơn lẻ cung cấp mà là sự kết hợp của rất nhiều tổ chức.

 1. Tổng quan

Hệ thống IT của doanh nghiệp không ngừng phải được cải tiến, bổ sung, sửa đổi hoặc thậm chí phải loại bỏ. Một trong những khó khăn lớn nhất cho doanh nghiệp là phải đối mặt với sự phức tạp của hệ thống IT do các thành tố tạo thành của nó không chỉ do một tổ chức đơn lẻ cung cấp mà là sự kết hợp của rất nhiều tổ chức (thậm chí đôi khi còn mất mơ hồ và không được xác định rõ).

Bên cạnh đó, các phát minh và sáng chế trong lĩnh vực IT (hiện đang có tốc độ phát triển nhanh nhất trong tất cả các linh vực) cũng không ngừng thâm nhập vào hệ thống IT của doanh nghiệp – nơi mà yêu cầu phải có sự nhất quán và đồng bộ rất cao mới có thể vận hành và khai thác hiệu quả.

Do vậy, yêu cầu đặt ra cho doanh nghiệp là phải kiểm soát và theo dõi được tất cả các biến động của hệ thống IT cũng như những tác động đến hệ thống này mới có cơ may sống sót và phát triển trong môi trường cạnh tranh khốc liệt đang diễn ra.

2. Quản lý sự thay đổi

Quản lý thay đổi thật sự cần thiết nhằm đảm bảo rằng tất cả các thay đổi đối với hệ thống IT không ảnh hưởng tiêu cực đến các cấp độ dịch vụ. Các thay đổi phải được thực hiện theo các phương pháp và thủ tục đã chuẩn hóa một cách hiệu quả và nhanh chóng để giảm tối đa sự ảnh hưởng.

Các từ viết tắt và định nghĩa

Từ viết tắt Diễn giải
RFC (Request for Change) Một yêu cầu thay đổi được đề xuất của bất kỳ sự thêm, bỏ hoặc thay đổi đối với bất kỳ CI nào trong hệ thống IT.
RFC LOG (Request for Change Log) Mỗi yêu cầu thay đổi đều được cấp một mã số để có thể theo dõi và tham chiếu. Thông tin được ghi nhận trong nhật ký sẽ được sử dụng trong các cuộc họp xem xét các yêu cầu thay đổi và cho các yêu cầu tương tự trong tương lai.
FSC (Forward Schedule of Change) Thông tin được ghi nhận trong quản lý thay đổi về bất kỳ sự xuất hiện nào của thay đổi được gửi đến. Thông tin này rất quan trọng đối với PSA (Projected Service Availability).
CAB (Change Advisory Board) Một tổ chức bao gồm từ Phụ trách Quản lý thay đổi đến các nhân viên hỗ trợ và các chuyên gia tư vấn SME (Subject Matter Experts). Các thành viên của tổ chức này sẽ gặp gỡ định kỳ để phê duyệt và đánh giá các yêu cầu thay đổi. Nhân sự tham gia trong các cuộc họp có thể thay đổi tùy thuộc vào loại RFC.
CAB/EC (Change Advisory Board Executive Committee) Các thành viên được chọn từ tổ chức CAB để làm đầu mối liên hệ để đánh giá và phê duyệt các thay đổi trong các tình huống nghiêm trọng hoặc khẩn cấp nằm ngoài kế hoạch xem xét định kỳ.
Board (Senior Management Board Level) Quản lý cao cấp ra các quyết định chiến lược có thể dẫn đến sự thay đổi quan trọng đối với hệ thống IT. Sau khi đã được phê duyệt, các thay đổi này sẽ được chuyển cho CAB để được cấp phép và lên lịch thực hiện.
CM (Change Manager) Có các nhiệm vụ sau đây:-          Quản lý toàn bộ các RFC-          Tổ chức và chủ trì các cuộc họp của CAB, quyết định những ai tham dự đối với mỗi cuộc họp.-          Cung cấp các FSC thông qua Service Desk
PSA (Projected Service Availability) PSA là bản báo cáo và là kết quả của FSC. Nó chứa các chi tiết của sự thay đổi liên quan đến SLA (Service Level Agreement).Thông tin này cũng được sử dụng để phát triển các SLA mới.

Sự thay đổi là gì?

Sự thay đổi là một hành động thay đổi trạng thái của một CI trong hệ thống IT.

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

Sàng lọc

 Phụ trách thay đổi phải đánh giá tất cả RFC được đề xuất. Việc đánh giá dựa trên nội dung của tài liệu RFC; do vậy cần phải xem xét thông tin về RFC đã chuyển đến có đầy đủ thông tin hay không? Thông tin đầy đủ sẽ đảm bảo sự thay đổi có thể được thực hiện nhưng hạn chế phá vỡ các cấp độ dịch vụ.

 

Nội dung Yêu cầu thay đổi (RFC)

  • Mã số RFC
  • Ai sẽ bị ảnh hưởng bởi thay đổi (Who)
  • Mô tả (What, Where)
  • Đánh giá sự ảnh hưởng
  • Thời gian cần thiết để thay đổi (When)
  • Lý do thay đổi (Why)
  • Thông tin người liên hệ (Who)
  • Kế hoạch phục hồi

 

Phụ trách thay đổi phải trả lời các câu hỏi sau đây khi xem xét, đánh giá và phê duyệt các thay đổi:

  • Đã có loại yêu cầu thay đổi nào cùng loại đã được chấp nhận trước đây chưa? Phụ trách thay đổi sẽ xem kỹ lại nếu một RFC như vậy đã có.
  • Có đề xuất nào bị từ chối không? Vì sao?
  • RFC đó có được thực hiện thành công không? Vì sao thành công hoặc vì sao không? Phụ trách thay đổi cần phải hiểu được mục tiêu của thay đổi được đề nghị.

Điều này chỉ có thể được thực hiện bằng cách lập sẵn một tài liệu RFC mẫu để sử dụng cho tất cả các bộ phận IT. Nếu RFC hoàn tất và được phụ trách thay đổi chấp nhận, nó sẽ được chuyển qua cho CAB. Tuy nhiên, sự chấp nhận ở đây không tương đương với việc cấp phép/phê chuẩn (authorization). Nếu thay đổi là đủ nhỏ thì phụ trách thay đổi có thể tự cấp phép. Nếu phụ trách cấp phép đối với một thay đổi và nghĩ rằng điều đó là cần thiết thì ban CAB sẽ được thông báo thay đổi đã được cấp phép.

Xác định độ ưu tiên và phân lớp

Một RFC sau khi đã được phụ trách thay đổi chấp nhận sẽ được phân loại và xác định mức độ ưu tiên. Các công ty đều thiết lập riêng cho mình một “phạm vi mô hình thay đổi” để phân lớp. Phân lớp sẽ dựa vào mức độ ảnh hưởng và mức độ khẩn cấp của yêu cầu thay đổi. Các thay đổi có thể được phân lớp trong phạm vi có thể do công ty xác định. Ví dụ, các yêu cầu thay đổi dựa vào mức độ ảnh hưởng của vấn đề và sự khẩn cấp của giải pháp: Ngay lập tức, Cao, Trung bình, Thấp. Trong đó:

  • Ngay lập tức: Ảnh hưởng nghiêm trọng đến hệ thống hoặc đến nhiều người dùng. Các hành động cấp thời cần được thực hiện (CAB/EC)
  • Cao: Ảnh hưởng nghiêm trọng đến các chức năng kinh doanh và cần phải thiết lập ở độ ưu tiên cao.
  • Trung bình: Không có ảnh hưởng nghiêm trọng nhưng cần phải sửa chữa và hiệu chỉnh trước khi phát hành hoặc nâng cấp.
  • Thấp: Yêu cầu thay đổi là hợp lý nhưng không cấp thiết lắm.

 Cấp phép/Phê duyệt

Phụ trách thay đổi có thể cấp phép cho các thay đổi nhỏ nhưng phải thông báo cho bộ phận CAB là thay đổi đó đã được cấp phép.

  • Bộ phận CAB sẽ cấp phép cho các thay đổi mức độ vừa và quan trọng.
  • Senior Level (Board of Directors-Ban giám đốc) sẽ cấp phép cho các thay đổi lớn mang tính chiến lược. Sau khi được họ cấp phép, việc cấp phép này sẽ chuyển đến cho bộ phân CAB xem lại.

Nội dung cấp phép sẽ đánh giá mức độ ảnh hưởng của tất cả các yêu cầu thay đổi. Việc đánh giá sẽ dựa vào các tiêu chí sau đây:

  • Sự ảnh hưởng đến kinh doanh
  • Sự ảnh hưởng đến các mục tiêu của các SLA
  • Các dịch vụ khác
  • Sự ảnh hưởng nếu không thực hiện
  • Nguồn lực và chi phí (Thời gian và con người)
  • FSC và PSA hiện thời
  • Ảnh hưởng của sự thay đổi đối với sản phẩm/dịch vụ cuối
  • Duy trì hoạt động bảo trì các tài nguyên

Tổ chức thực hiện thay đổi

Từ đầu đến cuối của cả tiến trình tổ chức thực hiện thay đổi là duy trì cập nhật đến thời điểm hiện tại thông qua việc cập nhật vào nhật ký RFC. Phụ trách thay đổi chuyển tất cả các thông tin cập nhật vào nhật ký RFC.

  • XÂY DỰNG

Phụ trách thay đổi sẽ đảm bảo rằng các tài nguyên hợp lý đã được phân công để xây dựng thay đổi. Các thông tin này được nêu trong RFC và sẽ được ghi nhận bởi các cá nhân hoặc các nhóm.

  • KIỂM THỬ

Kiểm thử sẽ được tổ chức thực hiện bởi người yêu cầu sau khi việc xây dựng thay đổi hoàn tất. Các chỉ định kiểm thử cũng nên đưa vào trong tài liệu RFC. Những người xây dựng chỉ được tham gia kiểm thử đối với các thay đổi khẩn cấp nếu thời gian cho phép.

  • TRIỂN KHAI

Sau khi kiểm thử hoàn tất và thỏa mãn được người yêu cầu thay đổi cũng như người xây dựng, phụ trách thay đổi sẽ tổ chức triển khai để đưa thay đổi vào hệ thống.

Xem xét sau triển khai

Sau khi các thay đổi đã được đưa vào hệ thống, phụ trách thay đổi sẽ tổ chức xem xét lại kết quả sau khi triển khai để biết được quy trình thay đổi hoạt động như thế nào đối với thay đổi đã được triển khai. Một số câu hỏi cần được giải đáp trong giai đoạn này là:

  • Điều gì đã dẫn đến cần phải thay đổi? Nếu sự thay đổi này là một kết quả từ một vấn đề nào đó thì việc quản lý vấn đề cần phải tham gia trong quá trình xem xét và đánh giá lại sau triển khai.
  • Làm như thế nào để tránh được các vấn đề đã dẫn đến sự thay đổi này?

 

Xử lý các thay đổi khẩn cấp

Sẽ không có nhiều thời gian để xử lý khi một thay đổi được coi là khẩn cấp. Phụ trách thay đổi-người phải đương đầu với loại thay đổi này- sẽ khởi động tiến trình được CAB/EC triệu tập để đánh giá sự thay đổi. CAB/EC sẽ gồm các thành viên được được lựa chọn từ CAB-những người có trách nhiệm hoặc được ủy quyền để ra các quyết định ở cấp độ cao. Các chỉ dẫn rõ ràng cùng với một tiến trình phối hợp cần thiết được thiết lập khi có thay đổi được coi là khẩn cấp. CAB/EC sẽ được triệu tập một khi được thông báo. Họ sẽ đánh giá thật nhanh tình huống, cấp phép và tổ chức thay đổi. Sau khi thay đổi đã được xây dựng và triển khai hoàn tất, CAB/EC sẽ tham gia vào trong quá trình xem xét lại sau khi triển khai thay đổi đó.

Đánh giá sự ảnh hưởng và nguồn lực

  • Sự ảnh hưởng của thay đổi đến kinh doanh
  • Cần thiết phải cân nhắc cẩn thận về thay đổi và các đơn vị kinh doanh bị ảnh hưởng bởi thay đổi
  • Sự ảnh hưởng đến các mục tiêu của các SLA
  • Sự ảnh hưởng đến các dịch vụ khác
  • Ảnh hưởng đến các dịch vụ khác không phải là IT
  • Sự ảnh hưởng nếu không thực hiện thay đổi
  • Nguồn lực và chi phí (Thời gian và con người)
  • FSC và PSA hiện thời
  • Duy trì hoạt động bảo trì của các tài nguyên

Một số vấn đề tiềm ẩn trong tiến trình Quản lý Thay đổi

  • Có sự thay đổi lớn về văn hóa IT
  • Nhận thức một cách quan liêu
  • Cố gắng đi tắt (không tuân thủ đầy đủ các yêu cầu)
  • Sự phục tùng tùy tiện của Nhà cung cấp hay đối tác trong các thỏa thuận
  • Song hành – Phụ trách thay đổi sẽ song hành cùng với tất cả các dịch vụ IT cần thiết cho kinh doanh dựa trên các thay đổi được chuyển đến. Phụ trách thay đổi cần phải hiểu rõ sự ảnh hưởng của bất kỳ thay đổi nào đến kinh doanh.
  • Hiệu quả được cải thiện cho cả người dùng lẫn nhân sự IT:
    • Người dùng: Các thay đổi có chất lượng tốt hơn với sự hỏng hóc ít hơn
    • Các nhân sự IT: Phụ trách thay đổi đảm bảo rằng các nhân sự IT hỗ trợ hợp lý tham gia xử lý các thay đổi sẽ dẫn đến kết quả sử dụng tài nguyên tốt hơn.
  • Rủi ro: Quản lý thay đổi đánh giá và chọn lọc tất cả các RFC nên rủi ro triển khai một thay đổi kém sẽ được giảm xuống.
  • Chất lượng: Các báo cáo liên quan đến thay đổi đều được ghi nhận sẽ cho phép nâng cao chất lượng khi thực hiện thay đổi. Quản lý thay đổi cần phải tạo các báo cáo cho tất cả các thay đổi,  thông tin bao gồm:
    • Mã số yêu cầu thay đổi
    • Phân loại
    • Kết quả (Thành công/Không thành công)