Tải bản đầy đủ (.doc) (165 trang)

Bai 16 quan li su thay doi

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (3.61 MB, 165 trang )

Bài 16 – Kiểm soát sự Thay đổi

BÀI 16 – KIỂM SOÁT SỰ THAY ĐỔI
Giới thiệu

Đây là một phần trong Góc vuông Thay đổi MOF. Phần này cho một cái nhìn tổng
quát về quản lí thay đổi SMF và đưa những thay đổi vào môi trường CNTT.

Quan hệ với những SMF Khác
Có quan hệ chặt chẽ giữa ba chức năng quản lí dịch vụ (Quản lí Thay đổi, Quản lí Cấu
hình, Quản lí Phiên bản) mà tạo nên Góc vuông Thay đổi MOF (MOF Changing
Quadrant). Hình sau đây minh hoạ quan hệ giữa ba SMF này.
Quản lí Thay đổi:
 Cung cấp qui trình cấp phép và theo dõi (RFC, bản ghi thay đổi và
duyệt) đê bảo đảm chỉ những thay đổi được duyệt là được triển khai.
 Cần quản lí cấu hình để đánh giá tác động của thay đổi lên tất cả
khoản mục cấu hình tiềm tàng (CI).
 Cần quản lí phiên bản để gói những thay đổi cho việc triển khai đạt
kết quả với sự phá hỏng ít nhất lên sản phẩm.
Quản lí Cấu hình:
 Cung cấp CSDL quản lí được (CMDB) cho những bản ghi thay đổi,
RFC, thư viện phần mềm cuối cùng (DSL), nơi lưu giữ phần cứng
cuối cùng (HDS), gói phiên bản và tất cả CI.

Trang 1


Bài 16 – Kiểm soát sự Thay đổi
 Cần quản lí thay đổi để bảo đảm rằng chỉ những thay đổi đã phê
chuẩn được triển khai và tất cả việc theo dõi (đường đi) của qui trình
cấp phép được hoàn thành.


 Cần quản lí phiên bản để cập nhật CMDB với những gói phiên bản
sau triển khai.
Quản lí phiên bản:
 Cung cấp phiên bản đã đóng gói cho tất cả thay đổi vào sản phẩm.
 Cần quản lí thay đổi để phê chuẩn và theo dõi suốt qui trình phiên
bản.
 Cần quản lí cấu hình để đánh giá tác động của thay đổi đối với CI và
cung cấp nơi lưu giữ cuối cùng cho gói phiên bản.
Lưu đồ Qui trình góc vuông Thay đổi MOF

Tất cả các chức năng quản lí dịch vụ khác có quan hệ với quản lí thay đổi theo cái mà
nó tác động trực tiếp lên lên mỗi SMF khi quản lí thay đổi được áp dụng cho lĩnh vực
cụ thể đó. Cái này không chỉ áp dụng cho lĩnh vực kĩ thuật được bao hàm, trong Góc
vuông Vận hành (Operating Quadrant), mà còn đối với thay đổi mà có thể tác động lên
những qui trình SMF trong Góc vuông Hỗ trợ và Tối ưu (Supporting and Optimizing
quadrants).

Trang 2


Bài 16 – Kiểm soát sự Thay đổi

Mục tiêu của bài 16: Kiểm soát sự Thay đổi

Mục tiêu của SMF quản lí thay đổi là cung cấp một qui trình có kỉ luật để đưa những
yêu cầu thay đổi vào môi trường CNTT với ít phá hỏng nhất cho vận hành hiện thời.
Để đạt được mục đích này, qui trình quản lí thay đổi phải bao gồm những mục tiêu
sau:
 Khởi tạo thay đổi một cách chính thức thông qua đệ trình yêu cầu cho
thay đổi (RFC).

 Gán mức ưu tiên và thứ hạng cho thay đổi sau việc đánh giá sự khẩn
cấp và tác động của nó vào hạ tầng cơ sở và những người dùng cuối.
Việc gán này tác động đến tốc độ và làm thay đổi việc tiến hành và
cách thức nhận quyền cấp phép.
 Để tạo lập qui trình hiệu quả cho việc chuyển RFC cho người quản lí
thay đổi và ban cố vấn thay đổi (CAB) để phê chuẩn hoặc loại bỏ thay
đổi.
 Để lập kế hoạch triển khai thay đổi, qui trình có thể thay đổi một cách
rộng lớn trong phạm vi và bao gồm việc duyệt tại những mốc chủ
chốt tạm thời.
 Để làm việc với SMF của Quản lí Phiên bản, được nhúng trong qui
trình quản lí thay đổi và nó quản lí phiên bản và việc triển khai thay
đổi vào môi trường sản phẩm.
 Để nâng cao kiến thức xem trang Web sau:
/> Để chỉ đạo qui trình sau-thực thi, mà việc duyệt xem thay đổi có đạt
được mục tiêu đề ra không và xác định duy trì thay đổi hay cuộn
ngược.
Trang 3


Bài 16 – Kiểm soát sự Thay đổi

CHỦ ĐỀ 16A – KHÁI NIỆM VỀ SỰ THAY ĐỔI

Giới thiệu
Trong Chủ đề 16A những khái niệm cơ bản về thay đổi được xem xét, đầu tiên là tổng
quan về quản lí thay đổi và sau đó là các mức ưu tiên và thứ hạng của thay đổi.
Trong ngữ cảnh của quản lí thay đổi, thay đổi là bất kì thừ gì- phần cứng, phần mềm,
thành phần hệ thống, dịch vụ, tài liệu, qui trình được đưa vào môi trường CNTT có
chủ ý và có thể tác động lên mức thoả thuận dịch vụ (SLA) hoặc nếu không thì tác

động lên hoạt động của môi trường hoặc thành phần của nó.Thay đổi có thể là tạm thời
hoặc cố định. Thay đổi có thể thay thế hoàn toàn một bản version hiện thời của một
thành phần, hoặc với một thành phần mới, hoặc một bản mới của thành phần, hoặc có
thể bao gồm việc cài đặt một thành phần hoàn toàn khác hoặc loại bỏ một thành phần
lỗi thời.
Dù là tạm thời hoặc vĩnh viễn, mới hoặc làm mới, tất cả thay đổi rơi vào định nghĩa
trên phải được quản lí bởi qui trình quản lí thay đổi. Điều quan trọng là quản lí thay
đổi phải quản lí tất cả thay đổi trong môi trường CNTT, bởi vì thay đổi có thể:
 Tác động lên nhiều người dùng.
 Có nguy cơ tiềm tàng phá hỏng những dịch vụ sứ mệnh- hoặc nghiệp
vụ-chủ chốt.
 Bao gồm cải tiến , thay đổi phần cứng (như máy phục vụ, hoặc thiết
bị liên mạng) hoặc phần mềm.
 Bao gồm những cải tiến vận hành và qui trình mà tác động lên nhiều
người dùng.

Trang 4


Bài 16 – Kiểm soát sự Thay đổi

Mục tiêu của chủ đề 16A – Khái niệm về sự Thay đổi

Trong chủ đề này, những vấn đề sau được làm rõ:
 Xác định thay đổi trong ngữ cảnh của quản lí thay đổi
 Liệt kê qui trình cơ sở của các bước trong qui trình quản lí thay đổi
 Mô tả hoạt động chủ yếu trong mỗi bước của qui trình quản lí thay đổi

Trang 5



Bài 16 – Kiểm soát sự Thay đổi

Thay đổi là gì?
Thay đổi có thể được biểu diễn dưới dạng đồ hoạ như một lưu đồ qui trình của những
nhiệm vụ cần thiết để triển khai có kết quả một thay đổi.

Thay đổi trong ngữ cảnh của quản lí thay đổi bao gồm phần cứng, phần mềm, các
thành phần hệ thống, tài liệu và các qui trình. Bởi vì môi trường CNTT là một môi
trường sản phẩm-các thành phần của nó liên kết và phụ thuộc lẫn nhau - điều quan
trọng là hiểu rõ thay đổi đối với một thành phần có thể tác động lên thành phần khác.
Thuật ngữ

Mô tả
Mức dịch vụ Một chuẩn được chấp nhận, xác đinh trách nhiệm quản lí CNTT
để cung cấp một dịch vụ đặc biệt có chất lượng và khối lượng cụ thể.

Lưu ý rằng nhiều tổ chức sử dụng hợp đồng chính thức - thoả thuận mức dịch vụ
(service level agreements (SLAs)) để xác đinh chất lượng và khối lượng dịch vụ mà
quản lí môi trường CNTT sẽ cung cấp cho nghiệp vụ. Những thoả thuận này cũng yêu
cầu người dùng có thể đặt cho dịch vụ những hạn chế được xác định bởi thoả thuận.

Trang 6


Bài 16 – Kiểm soát sự Thay đổi

SMF của Quản lí sự Thay đổi

Các bước của qui trình quản lí thay đổi như sau:

 Yêu cầu thay đổi. Sự khởi đầu chính thức cho một thay đổi thông qua đệ trình
cho một yêu cầu thay đổi (RFC)
 Phân loại thay đổi. Gán mức ưu tiên và thứ hạng cho thay đổi, sử dụng tính
khẩn cấp và tác động của nó lên hạ tầng cơ sở như là tiêu chí. Nó cung cấp cách
thức để liên kết tác động đến nghiệp vụ của thay đổi với tốc độ thực thi và lộ trình.
 Cấp phép cho thay đổi. Một qui trình thay đổi được chỉ đạo bởi người quản lí
thay đổi, cung cấp cho tổ chức việc kiểm soát về những thay đổi được phát triển và
triển khai.
 Phát triển thay đổi. Lập kế hoạch và phát triển thay đổi, là một qui trình có thể
thay đổi rộng lớn trong phạm vi và bao gồm việc duyệt ở những mốc chủ chốt tạm
thời.
 Phiên bản thay đổi. Phiên bản của sự thay đổi đối với quản lí thay đổi cho việc
triển khai vào môi trường sản phẩm.
 Duyệt thay đổi. Qui trình sau - thực thi duyệt xem thay đổi có đạt được những
mục tiêu đề ra cho thay đổi không.
 Hoàn thành thay đổi. Thay đổi đạt được mục tiêu. Thay đổi chính thức chuyển
cho góc vuông vận hành và hỗ trợ MOF.
Lưu ý. Lưu đồ qui trình mức - cao đối với quản lí thay đổi SMF, cùng với biểu đồ mức-2 chỉ
ra những tiến trình được biểu diễn bởi mỗi hộp trong biểu đồ mức-cao được in trong Phụ lục
A để thuận tiện tham khảo.

Trang 7


Bài 16 – Kiểm soát sự Thay đổi

Yêu cầu một Thay đổi

Những yêu cầu thay đổi thường đến từ các nhóm nghiệp vụ được phục vụ bởi CNTT
hoặc bởi các bản thân nhóm CNTT, tiêu biểu là góc vuông hỗ trợ hoặc góc vuông tối

ưu. Tuy nhiên, thay đổi có thể được khởi xướng bởi bất kì ai thuộc những cụm mô
hình vai trò của nhóm MOF, mà thực hiện những chức năng cần thiết một cách tập thể
để vận hành môi trường CNTT.
Tài liệu RFC được lưu giữ trong bản ghi thay đổi (change log) và trở thành điểm tham
khảo cho mọi hoạt động liên quan đến thay đổi.
Thường thường, một người bất kì trong môi trường nghiệp vụ có thể yêu cầu thay đổi
và bằng cách làm sau, trở thành người khởi xướng thay đổi. Bởi vì nhiều người đề xuất
thay đổi tiềm tàng và với những mức hiểu biết khác nhau về thủ tục bao hàm, một qui
trình được yêu cầu để tạo ra yêu cầu thay đổi có chất lượng nhất quán và sự trọn vẹn
và loại bỏ những yêu cầu không thích hợp.
Mặc dù một thay đổi có thể được yêu cầu bởi bất kì ai trong nghiệp vụ, nhưng tiêu
biểu là được khởi xướng và đệ trình bởi một trong cụm vai trò củ Mô hình Nhóm
MOF (MOF Team Model role clusters). Thông thường, mỗi cụm vai trò đệ trình yêu
cầu thay đổi liên quan đến lĩnh vực trách nhiệm của mình.

Kiểu Thông thường của Yêu cầu cho Thay đổi theo Cụm Vai trò của Mô
hình Nhóm
Cụm vai tro Kiểu Yêu cầu Thay đổi
Hạ tầng cơ sở

Những hệ mới và cải tiến hệ đang tồn tại và hạ tầng cơ sở.

Vận hành

Những thay đổi mà tác động hoặc cải thiện hoạt động hàng ngày của công
nghệ.

Trang 8



Bài 16 – Kiểm soát sự Thay đổi
Cụm vai tro Kiểu Yêu cầu Thay đổi
Đối tác

Những thay đổi của bên-thứ ba và nhà cung cấp-liên quan - thí dụ, những
thay đổi thuê hệ thống của đối tác ngoài tác động lên hệ thống nội bộ.

Phiên bản

Những thay đổi đối với hệ quản lí và qui trình thay đổi, cấu hình, và phiên
bản.

An ninh

Những thay đổi đối với qui trình an ninh - thí dụ, cải tiến về xác thực hoặc
an ninh mạng.

Hỗ trợ

Những thay đổi cho phép giải quyết vấn đề và tình huống và những thay đổi
đối với hệ thống help desk.

Dịch vụ

Những thay đổi được kéo theo bởi những thay đổi mức dịch vụ mới, dự án
cải tiến dịch vụ hoặc chiến lược nghiệp vụ.

Qui trình để yêu cầu một thay đổi.
Một nhu cầu thay đổi, hoặc đó là một cải tiến đối với hoặc xác định pha thay đổi một
dịch vụ tồn tại hoặc tạo một dịch vụ mới, dẫn đến qui trình quản lí thay đổi, những

nhu cầu này tất cả thúc đẩy việc tạo một yêu cầu thay đổi (RFC). RFC là một tài liệu
chuẩn trong đó tất thông tin liên quan về thay đổi được đề xuất được ghi lại, xếp loại
từ sự kiện cơ sở về thay đổi (thí dụ, thay đổi tên trường trong một hệ cơ sở dữ liệu)
cho tới thông tin chi tiết hơn, như những tác động đạt đến-diện rộng hơn của thay đổi
(ví dụ, hệ thống tương tác với hoặc báo cáo về tên trường được thay đổi).
RFC phải trả lời câu hỏi cái gì, ai, khi nào, ở đâu và như thế nào của thay đổi được đề
xuất. Nó phải mô tả thay đổi, nỗ lực mà nó có để thực thi thay đổi và bởi ai, phương
pháp thực thi và khoản mục cấu hình (CI) bao hàm. Nó cũng bao gồm thông tin hỗ trợ
về mục đích của thay đổi, tác động của nó lên tổ chức, kế hoạch rút lui lại trong trường
hợp hỏng, chi phí cho thay đổi, bàn giao (sign-off) ngân sách phê chuẩn nếu, và tính
khẩn cấp của thay đổi được đề xuất. Nó phải chứa thông tin đầy đủ để cho phép người
quản lí thay đổi đánh giá nhanh và chính xác thay đổi tại giai đoạn trình chiếu ban đầu
và lần nữa tại những giai đoạn duyệt chính thức của nó để phê chuẩn hoặc loại loại bỏ.
RFC phải được tạo ra trong định dạng chuẩn, mà bảo đảm rằng người khởi xướng thay
đổi cung cấp thông tin đầy đủ cho người quản lí thay đổi và sau đó CAB cho phép
chúng để quyết định xem thực thi thay đổi. Sử dụng định dạng chuẩn cũng buộc người
khởi xướng thay đổi nhận diện và làm tài liệu đầy đủ cho phạm vi, sự ảnh hưởng và rủi
ro của thay đổi đang yêu cầu, cũng như kế hoạch khôi phục nếu thay đổi không đạt kết
quả. Trong nhiều trường hợp, người khởi xướng thay đổi sẽ không biết hoặc hiểu đầy
đủ về những ảnh hưởng của thay đổi. Vì lẽ này, RFC phải được xem xét bởi tất cả cụm
vai trò của Mô hình Nhóm MOF để xác định tác động có thể của thay đổi lên hoạt
động CNTT.

Trang 9


Bài 16 – Kiểm soát sự Thay đổi

Lưu đồ qui trình thay đổi


RFC trở thành điểm tham khảo cho tất cả hoạt động liên quan tới thay đổi. Sử dụng
một định dạng chuẩn, như một mẫu trong Using Microsoft Word, định dạng thư
Microsoft Outlook®, Microsoft InfoPath™ hoặc dạng Web, mà có thể được truy nhập
dễ dàng bởi các bên quan tâm tại thời điểm bất kì.
Để giúp đỡ qui trình quản lí thay đổi, định dạng RFC có thể được phê chuẩn, là bắt
buộc, và các trường tùy chọn để hoàn thành bảo đảm rằng thông tin chủ chốt được
hoàn thành càng sớm càng tốt để và để giảm nhu cầu trả RFC về cho người khởi
xướng để có nhiều thông tin hơn trước khi nó được đen duyệt.

Tạo yêu cầu cho Thay đổi
Một người (người khởi xướng thay đổi) mà muốn tạo ra một thay đổi cho phần bất kì
của hạ tầng cơ sở CNTT được chi phối bởi qui trình quản lí thay đổi bắt đầu qui trình
bởi việc hoàn thành một RFC. Những sự kiện mà tạo ra một RFC một cách tiêu biểu
bao gồm:
Trang 10


Bài 16 – Kiểm soát sự Thay đổi
 Một giải pháp được đề xuất cho một tình huống hoặc vấn đề.
 Bất mãn của người dùng hoặc khách hàng biểu lộ qua quan hệ khách
hàng (thường là service desk) hoặc từ việc thúc đẩy cải tiến dịch vụ
của cách thức quản lí mức dịch vụ.
 Việc đưa vào hoặc loại bỏ một khoản mục cấu hình (CI) theo đề xuất.
 Một nâng cấp được đề xuất đối với môt vài thành phần của hạ tầng
cơ sở.
 Ảnh hưởng của Chiến lược nghiệp vụ đối với yêu cầu từ CNTT.
 Pháp chế mới hoặc được thay đổi thúc đẩy thay đổi dịch vụ.
 Thay đổi vị trí vật lí.
 Thay đổi sản phẩm hoặc dịch vụ từ người bán hoặc người hợp đồng.
Người đề xướng thay đổi có thể là vị trí hợp lí trong nghiệp vụ để đệ trình thay đổi,

nhưng có thể không luôn luôn am hiểu môi trường CNTT. Trong trường hợp này, một
chủ nhân của thay đổi từ môi trường CNTT phải được phân công, là người có khả
năng cung cấp thông tin cần thiết liên quan đến đặc trưng công nghệ của thay đổi cho
RFC.
Thông tin RFC
Khi hoàn thành một RFC, người đề xướng thay đổi phải cung cấp càng nhiều thông tin
như sau càng tốt:
 Tên, chức vụ, thông tin liên lạc (địa chỉ, telephone,..) của người khởi
xướng thay đổi.
 Tên, chức vụ, thông tin liên lạc (địa chỉ, telephone,..) của chủ nhân
của thay đổi.
 Mô tả thay đổi, là một tính toán đầy đủ về bản chất của thay đổi.
 Đề xuất về mức ưu tiên và thứ hạng của thay đổi dựa trên thông tin
sẵn có.
 Số hiệu của báo cáo vấn đề (problem report - PR) của vấn đề bất kì
mà liên quan tới thay đổi, hoặc số hiệu tình huống bất ngờ, nếu được
biết.
 Mô tả và nhận diện (xác định) khoản mục bất kì mà được thay đổi,
bao gồm nhận diện mọi CI.
 Lí do thay đổi
 Phân tích lợi ích-chi phí của thay đổi và việc phê chuẩn ngân sách,
nếu được yêu cầu.
 Ảnh hưởng của việc không thực hiện thay đổi, bao gồm SLA bất kì tại
rủi ro.
 Đánh gíá tác động và tài nguyên, đó là, người dùng nào bị tác động và
ảnh hưởng lớn đến mức nào.
 Vị trí của phiên bản và kế hoạch thực thi đề xuất với lịch biểu thời
gian.

Trang 11



Bài 16 – Kiểm soát sự Thay đổi
 Kế hoạch rút lui bao gồm các điểm trigger và chi tiết tiếp xúc người-ra
quyết định.
 Tác động lên tính liên tục và bất ngờ của nghiệp vụ.
 Rủi ro được bao gồm trong khi thực hiện thay đổi.
Người khởi xướng thay đổi có thể cũng cần cung cấp tài liệu hỗ trợ, như là trường hợp
nghiệp vụ, phân tích lợi ích-chi phí hoặc kế hoạch thực thi đã đề xuất cho người quản
lí thay đổi và những người khác được bao gồm trong qui trình phê chuẩn thay đổi.
Hai khoản mục RFC trong danh sách của người khởi xướng thay đổi - mức ưu tiên và
thứ hạng đề xuất hoặc những khuyến dụ - xứng đáng được giải thích thêm nữa.
Change Priority
Thường có mức nhầm lẫn về định nghĩa về mức ưu tiên, theo từ điển đó là: “Địa vị cao
hơn, đặc biệt được thiết lập bởi thứ tự quan trọng và khẩn cấp.Trong qui trình quản lí
thay đổi, mức khẩn cấp được xác định cho thay đổi được đòi hỏi nhanh ra sao bởi
nghiệp vụ.
Có 4 mức ưu tiên được khuyến dụ như sau:
 Khẩn cấp. Thay đổi mà không được thực thi ngay thức thì, sẽ gây ra
cho rủi ro lớn - thí dụ, áp dụng cho miếng vá an ninh.
 Cao. Thay đổi mà là quan trọngđối với tổ chức và phải được thực thi
sớm–thí dụ, nâng cấp để phù hợp với yêu cầu pháp chế.
 Trung bình. Thay đổi mà phải được thực thi để đạt được lợi ích từ
dịch vụ thay đổi - thí dụ, giữa những bản nâng cấp cho dịch vụ phản
hồi của khách hàng.
 Thấp. Thay đổi không gây áp lực, nhưng có thể có lợi - thí dụ, việc
thêm vào để hay hơn cho khái lược (profile) người dùng.
Những mức ưu tiên này đã được định nghĩa phụ thuộc vào thực tiễn tốt nhất (best
practice) của công nghiệp. Tuy nhiên, phụ thuộc vào kích cỡ của tổ chức và SLA tồn
tại giữa các phòng ban CNTT và nghiệp vụ mà nó phục vụ, tổ chức có thể cần thay đổi

định nghĩa ưu tiên của riêng mình. Trong một vài tổ chức, thí dụ, nếu cá nhân muốn
thêm cho đẹp (“nice to have”) vào khái lược công việc trong lĩnh vực nghiệp vụ-chủ
chốt, khi đó thay đổi có thể được nhận thức như ưu tiên mức cao. Ngược lại, nếu cùng
một thay đổi được yêu cầu cho lĩnh vực nghiệp vụ thôi dần, thay đổi có thể được nhận
thức như mức ưu tiên thấp. Điều chủ yếu là mỗi tổ chức xem xét việc dùng chính xác
cho của các mức ưu tiên này đối với môi trường của riêng mình, vì các mức ưu tiên
này xác định khi nào và như thế nào thay đổi được thực thi. Chúng cũng xác định thứ
tự, theo đó yêu cầu thay đổi được duyệt.
Điều quan trọng cần lưu ý là thay đổi ưu tiên khẩn cấp khác hẳn những mức ưu tiên
khác ở chỗ nó có lộ trình khác thông qua qui trình duyệt để thực thi thay đổi càng
nhanh càng tốt. Mức ưu tiên này được dành cho những thay đổi mà nếu không được
thực thi nhanh, có thể tác động nghiêm trọng lên mức dịch vụ hoặc hậu qủa trong chi
phí lớn đối với nghiệp vụ. Thay đổi khẩn cấp phải được giữ nhỏ nhất tuyệt đối bởi vì
rủi ro được bao gồm trong thực thi chúng; việc dùng nó không được thay thế thực tiễn
lập kế hoạch tốt.
Trang 12


Bài 16 – Kiểm soát sự Thay đổi
Thứ hạng thay đổi
Trong khi mức ưu tiên của thay đổi chỉ ra thay đổi được yêu cầu được thực thi khẩn
cấp đến mức nào, thứ hạng của thay đổi được dùng để xác định tác động của thay đổi
lên lên hạ tầng cơ sở, người dùng hoặc nghiệp vụ. Thí dụ, thay đổi ảnh hưởng đến một
người, một phòng hoặc mỗi người dùng trong tổ chức? Thay đổi bao gồm cập nhật
một thiết bị chuyển mạch mạng đơn lẻ hoặc là đại tu của toàn bộ hệ thống mạng? Trả
lời cho những câu hỏi như vậy xác định thứ hạng thay đổi.
Quyết định mức ưu tiên tạo thành mỗi mức ưu tiên cho từng thay đổi được xác đinh
bởi tổ chức. Những thứ hạng sau được đề xuất và được dùng hiệu qủa trong tổ chức.
 Chủ yếu. Thay đổi ảnh hưởng đến nhóm đông - thí dụ, phong hoặc
thay đổi mức Công ty hoặc thay đổi mức mạng hoặc thay đổi mức

dịch vụ.
 Quan trọng. Thay đổi ảnh hưởng trải rộng, nhưng không lớn - thí dụ,
thay đổi tác động nhóm trong một phong hay một nhóm CI.
 Thứ yếu. Thay đổi ảnh hưởng đến số ít cá nhân hay CI - thí dụ, thay
đổi cho máy in được dùng bởi một phong gồm ít thành viên.
 Chuẩn. Thay đổi được thực hiện trước và là một phần của thực tế vận
hành của nghiệp vụ, cập nhật khái lược của người dùng.
Giống như mức ưu tiên thay đổi, thứ hạng thay đổi cũng gắn liền với tổ chức cụ thể.
Thay đổi tác động lên một phòng cụ thể có thể cho là quan trọng trong một vài tổ
chức, nhưng lại được xem như thứ hạng chuẩn trong tổ chức khác, trong đó phòng
được xem như ít cấp bách hơn. Điều này đúng cho những thay đổi để phân phát những
dịch vụ cụ thể hoặc sử dụng những sản phẩm nào đó. Thông tin để xác định thứ hạng
phải được thu thập từ Cụm Vai trò Dịch vụ (Service Role Cluster), catalog dịch vụ và
Quản lí Mức Dịch vụ SMF.
Một thứ hạng của thay đổi cần quan tâm đặc biệt, tuy nhiên, được gọi là thay đổi
chuẩn trong hướng dẫn này. Thay đổi chuẩn rơi vào đáy của thang thứ hạng thay đổi
trong đó tác động của nó thấp trong thuật ngữ tác động lên người dùng hoặc hạ tầng cơ
sở. Nỗ lực yêu cầu để thực thi cũng tương đối nhỏ và rủi ro của nó đối với môi trường
tương ứng cũng nhỏ.
Tập những thay đổi chuẩn thủ tục chuẩn để thực thi chúng thường được xác định trước
bởi CAB. Tập này của thay đổi chuẩn có thể được tự động phê chuẩn không cần phải
được biểu quyết bởi CAB hoặc người quản lí thay đổi, bằng cách này lộ trình qua qui
trình phê chuẩn thay đổi ngắn hơn. Chỉ những thay đổi mà rơi vào tập chuẩn xác định
trước có thể được phân loại như vậy. Thí dụ về thay đổi chuẩn bao gồm bảo trì theo
lịch biểu thường kì, những nhiệm vụ quản trị được thực hiện thường xuyên (như thay
đổi khái lược) và yêu cầu dịch vụ ít nhất.

Đệ trình RFC để phê chuẩn
Người đề xướng thay đổi làm tài liệu tất cả thông tin cần thiết để mô tả thay đổi đã đề
xuất và đệ trình RFC cho người quản lí thay đổi. (Vai trò của người quản lí thay đổi là

một vai trò được bao gồm trong Cụm Vai trò Phiên bản của Mô hình nhóm MOF. Để
cung cấp mức khởi đầu của trình chiếu và “thực tế” kiểm tra RFC, số lượng người
dùng trong tổ chức, người có thẩm quyền đệ trình RFC phải được hạn chế. Nếu người

Trang 13


Bài 16 – Kiểm soát sự Thay đổi
dùng khác muốn khởi xướng RFC, một người nào đó khác đầu tiên phải phê chuẩn nó,
trước khi nó được đệ trình và chuyển cho người quản lí thay đổi.

Trình chiếu RFC
Sau đây là sự đệ trình RFC, RFC phải được trình chiếu. Qui trình trình chiếu này
không liên quan đến phê duyệt hoặc phê chuẩn yêu cầu thay đổi, nhưng xác định xem
quyết định để ủy nhiệm hoặc từ chối thay đổi dựa trên thông tin trong RFC và những
tham khảo bất kì được thực hiện bởi RFC.
Việc trình chiếu ban đầu này phải được thực hiện bởi người quản lí của người khởi
xướng. Như một chuỗi các phê chuẩn-trước phải được giữ ngắn gọn - nếu không thì nó
trở thành gánh nặng quản lí và hậu cần, chủ đề của lỗi.
Qui trình trình chiếu này phải bao gồm:
 Kiểm tra thực tế để bảo đảm rằng RFC là thích hợp. Bởi vì người
dùng bất kì có thể tạo ra RFC, có nghĩa là RFC có thể được sinh ra là:
o Không thích hợp cho qui trình quản lí thay đổi CNTT.
o Không đủ chi tiết.
o Không được hiểu trọn vẹn sự liên can của chúng.
o Không được hoàn thành chính xác do người đề xướng thay đổi thiếu
kiến thức về qui trình quản lí thay đổi.
 Thêm thông tin con thiếu, cần cho những người đánh giá để hiểu trọn
vẹn tác động của thay đổi (thí dụ, kết qủa phân tích tác động từ cơ sở
dữ liệu quản lí thay đổi).

 Phân loại lại mức ưu tiên và thứ hạng nếu cần. RFC đã được đệ trình
như thay đổi chuẩn, nhưng không tuân theo một trong những kiểu
xác định trước của thay đổi chuẩn, khi đó nó cần phải được phân loại
lại.
Người được chỉ định để trình chiếu RFC chịu trách nhiệm thực hiện trình chiếu RFC
và những hoạt động khác trong một tập chu kì thời gian, phụ thuộc vào mức ưu tiên củ
thay đổi đã yêu cầu. Những thay đổi khẩn cấp phải có hạn định thời gian ngắn hơn
nhiều cho trình chiếu so với nhưng thay đổi không-khẩn cấp. Những hạn định thời
gian này được xác định trong SLA. Đối với những thời gian này khi người quản lí
thay đổi không có mặt hoặc không có kả năng trình chiếu RFC trong hạn định thời
gian, người quản lí thay đổi được ủy quyền hay những người được ủy quyền phải được
chỉ định và cấp phép để hành động thế chỗ người quản lí thay đổi.
Nếu RFC không được trình chiếu trọng hạn định thời gian, nó phải được tự động báo
lên cho người được thay thế người trình chiếu. Thông báo này có thể bằng e-mail. Nếu
thích hợp, e-mail này có thể được sao cho ủy ban chấp hành CNTT hoặc theo đường đi
theo cấp khác. Những chi tiết này cũng phải xuất hiện trong báo cáo theo cấp bậc hàng
tháng để cho phép mức-cao hơn biết. Sự kiện RFC đã không được trình chiếu trong
hạn định thời gian phải được thêm vào bản ghi thay đổi cho RFC đó.
Nếu người được chỉ định trình chiếu RFC xác định rằng RFC không chứa thông tin
đầy đủ để ra quyết định, RFC được trả về cho người khởi xướng thay đổi. Người quản
Trang 14


Bài 16 – Kiểm soát sự Thay đổi
lí thay đổi xác định trong bản ghi thay đổi thông tin phụ cần thiết và lí do cần. Trạng
thái RFC được thiết đặt để treo và người khởi xướng thay đổi phải được thông báo.
Người khởi xướng thay đổi khi đó có thể thêm thông tin cho RFC và tái-đệ trình nó, ở
đó chỉ ra chu kì vượt quá cho trình chiếu khởi động lại.
Nếu việc trình chiếu xác định rằng RFC có đủ nội dung và quyền hạn thay đổi, thì bản
ghi thay đổi được cập nhật và người khởi xướng thay đổi được thông báo, và RFC

chuyển sang giai đoạn phân loại thay đổi. Tham khảo Lưu đồ qui trình thay đổi.
Một khi RFC được trình chiếu, người quản lí thay đổi gán cho nó một ID vì mục đích
theo dõi và ghi lại sự kiện là RFC đã chuyển trình chiếu vào bản ghi thay đổi. Bản ghi
thay đổi là thành phần chính của quản lí thay đổi và bảo đảm mọi thay đổi được kiểm
soát và báo cáo bởi người quản lí thay đổi. Nó hành động như nơi chứa lịch sử chi tiết
của mọi thay đổi - từ tạo RFC cho tới phiên bản thay đổi hoặc hủy bỏ - và được cập
nhật với mỗi thay đổi trong trạng thái của RFC. Tổ chức có thể quyết định bản ghi
thay đổi là cơ sở dữ liệu (CSDL) tách biệt hoặc được chứa trong CMDB.

Tóm tắt
Qui trình yêu cầu thay đổi gồm những bước sau:
 Người khởi xướng thay đổi tạo và đệ trình tính toán đầy đủ về thay
đổi phải cần trong dạng RFC.
 Người trình chiếu được chỉ định xác định xem có thông tin đầy đủ
trình bày trong RFC để cho nó được cấp phép.
 Nếu không có thông tin đầy đủ, người trình chiếu thay đổi trả RFC
cho người khởi xướng để có thêm chi tiết hơn cho những chỗ cần
thiết.
 Kết qủa qui trình tuần hoàn này trong RFC đã trình chiếu sẵn sàng
cho lối vào qui trình phân loại thay đổi.

Trang 15


Bài 16 – Kiểm soát sự Thay đổi

Phân loại và cấp phép cho Thay đổi

Mọi thay đổi được phân loại theo mức độ ưu tiên và thứ hạng để giúp cho tổ chức
phân biệt chúng một cách nhất quán với nhau, phụ thuộc vào mức độ quan trọng của

chúng đối với tổ chức. Bảng sau đây mô tả hai lớp.
Mô tả thuật ngữ
Lớp
Ưu tiên

Thứ hạng

Mô tả
Phân loại thay đổi xác định tốc độ một yêu cầu thay đổi được phê chuẩn và
triển khai. Sự cấp bách của nhu cầu đối với giải pháp và rủi ro nghiệp vụ của
việc không thực hiện thay đổi hoặc việc không thực thi một biện pháp là tiêu
chí chính để xác định mức ưu tiên.
Việc xác định tác động triển khai của thay đổi lên CNTT và nghiệp vụ. Tài
nguyên bao gồm con người, tiền của và thời gian là thước đo để xác định
thứ hạng. Rủi ro của triển khai, bao gồm nguy cơ thời gian máy chết (ngừng
vận hành) cũng được cân nhắc.

Qui trình cấp phép phụ thuộc rất nhiều vào qui trình phân loại, như sẽ được xét đến
trong phần tiếp theo. Cấp phép cho thay đổi cung cấp phê chuẩn chính thức để thay đổi
chuyển sang các qui trình phát triển và xây dựng phiên bản.

Cấp phép cho Thay đổi
Sau khi một thay đổi được gán ưu tiên và thứ hạng chính xác, thay đổi phải được cấp
phép. Qui trình cấp phép một yêu cầu thay đổi phụ thuộc vào mức ưu tiên và thứ hạng
thay đổi:
 Thay đổi ưu tiên khẩn cấp được báo lên CAB/EC để phê chuẩn theo
dõi-nhanh.

Trang 16



Bài 16 – Kiểm soát sự Thay đổi
 Thay đổi chuẩn được phê chuẩn tự động và chuyển trực tiếp cho pha
phát triển thay đổi và phiên bản.
 Thay đổi thứ yếu có thể được người quản lí thay đổi phê chuẩn
không cần tham khảo CAB.
 Tất cả những thay đổi khác phải được CAB phê chuẩn.
Những qui trình thảo luận thay đổi được bàn chi tiết sau đây. Trong mỗi trường hợp,
người hoặc hội đồng thích hợp ra quyết định xem thay đổi có thể được tiến hành dựa
trên thông tin được cung cấp trong RFC không.
Nếu RFC bị loại và thay đổi không được phê chuẩn, RFC được đóng lại và người khởi
xướng thay đổi được thông báo về quyết định này. Lí do loại được thêm vào bản ghi
thay đổi. Sau khi được đóng, RFC không được mở lại. Nếu người khởi xướng thay đổi
muốn đệ trình lại yêu cầu, người đó phải mở một RFC mới, tham khro RFC gốc mà bị
loại và thêm thông tin phụ cầgn thiết để yêu cầu nhận được phê chuẩn. Những lí do
được ghi lại cho RFC gốc mà bị loại phải chỉ ra thông tin phụ thêm mà có thể cần. Tất
cả thời gian SLA được xác định cho những giai đoạn khác nhau của qui trình thay đổi
(thí dụ, thời gian để trình chiếu ban đầu) được khởi động lại bởi vì đó là RFC mới.
Nếu RFC là tới hạn về thời gian, RFC đã tái-đệ trình này không cần được gán mức ưu
tiên cao hơn mức ưu tiên ban đầu do trễ phải gánh chịu trong quá trình xử lí yêu cầu
gốc.
Những hoạt động của những cụm vai trò của Mô hình Nhóm MOF trong việc cấp
phép cho thay đổi phụ thuộc vào kích cỡ và bản chất của thay đổi. Bảng sau đây cung
cấp thí dụ về sự tham gia của mỗi vai trò:
Tham gia của các Cụm Vai trò của Mô hình Nhóm MOF trong Cấp phép cho
Thay đổi.
Cụm Vai trò Thay đổi Chuẩn Thay đổi Thứ Thay đổi Khẩn Thay đổi Quan
yếu
cấp
trọng và Chủ

yếu
Hạ tấng cơ sở Đã được cấp
phép trước

Không can dự

Thành viên CAB Thành viên CAB

Vận hành

Đã được cấp
phép trước

Không can dự

Thành viên CAB Thành viên CAB

Đối tác

Cấp phép

Không can dự

Thành viên CAB Thành viên CAB

Phiên bản

Cấp phép

Cấp phép


Thành viên CAB Thành viên CAB

An ninh

Đã được cấp
phép trước

Không can dự

Thành viên CAB Thành viên CAB

Hỗ trợ

Đã được cấp
phép trước

Không can dự

Thành viên CAB Thành viên CAB

Dịch vụ

Đã được cấp
phép trước

Không can dự

Thành viên CAB Thành viên CAB


Trang 17


Bài 16 – Kiểm soát sự Thay đổi

Cấp phép Thay đổi Chuẩn
Thay đổi chuẩn là một thay đổi đối với hạ tầng cơ sở, cho phép một lộ trình được thiết
lập, là tương đối chung và là giải pháp chấp nhận được cho một hoặc nhiều yêu cầu cụ
thể. Thí dụ có thể bao gồm thay đổi password hoặc cập nhật những mẫu tài liệu nào
đó. Những thành phần cốt yếu của thay đổi chuẩn là:
 Những nhiệm được vụ biết rõ và được chứng minh.
 Thẩm quyền được CAB cấp trước có hiệu quả.
 Qui trình thay đổi thường được khởi đầu bởi service desk.
 Phê chuẩn ngân sách thường được định trước hoặc trong kiểm soát
của người khởi xướng.
Thay đổi chuẩn được phê chuẩn tự động và chuyển trực tiếp cho pha triển khai thay
đổi của qui trình quản lí thay đổi (xem phần Phát triển thay đổi và Phiên bản). Bởi vì
kiểu của thay đổi mà đã được phê chuẩn trước, khi thay đổi chuẩn được biết là có tác
động thấp lên môi trường và có rủi ro thấp cho nó, CAB hoặc người quản lí thay đổi
không cần duyệt lại chúng. Tuy nhiên, điều này có nghĩa là phải cẩn thận khi trình
chiếu ban đầu để bảo đảm rằng yêu cầu thay đổi mà đã được gán ưu tiên chuẩn, chính
là một trong những kiểu thay đổi chuẩn được phê chuẩn trước.

Cấp phép cho Thay đổi Thứ yếu
Thay đổi thứ yếu là một thay đổi rơi vào cuối thang bậc thứ hạng, có tác động và rủi ro
thấp. Nó khác thay đổi chuẩn ở chỗ, mặc dù rủi ro thấp, thay đổi này có thể không
được thực hiện trước và do vậy không được phê chuẩn. Cái gì thực tế tạo nên một thay
đổi thứ yếu phụ thuộc vào tiêu chí được chọn bởi tổ chức. Bởi vì rủi ro và tác động của
thay đổi thứ yếu thấp và yêu cầu về tài nguyên để thực thi cũng thấp, do vậy thay đổi
thứ yếu không cần CAB phê chuẩn. Thay vì, người quản lí thay đổi lại có thẩm quyền

phê chuẩn hoặc loại bỏ thay đổi. Người quản lí thay đổi vẫn có quyền tùy chọn để
trình bày RFC cho CAB nếu nghĩ là cần thiết.
Qui trình cấp phép cho thay đổi thứ yếu bởi người quản lí thay đổi được biểu diễn
trong lưu đồ sau đây.

Trang 18


Bài 16 – Kiểm soát sự Thay đổi

Lưu đồ qui trình cấp phép cho thay đổi thứ yếu bởi người quản lí thay đổi.

Nếu thông tin trong RFC không đủ để cho phép người quản lí thay đổi ra quyết định,
người quan lí thay đổi phải tiếp xúc với người khởi xướng thay đổi để nhận thông tin
cần thiết.
Khi có thông tin đầy đủ để ra quyết định, người quản lí thay đổi áp dụng tiêu chí
thường dùng để chấp nhận hoặc loại bỏ RFC. Việc áp dụng những tiêu chí này phải trả
lời những câu hỏi sau:
 Thay đổi có cần thiết không?
 Lợi ích của thay đổi là “nặng kí hơn” những rủi ro bất kì, gây mất ổn
định môi trường?

Trang 19


Bài 16 – Kiểm soát sự Thay đổi
 Chi phí chấp là nhận được?
Bởi vì thay đổi thứ yếu được phê chuẩn bởi người quản lí thay đổi một mình, qui trình
này phải được minh bạch và rõ ràng. Bất kì nghi ngờ nào về việc phê chuẩn RFC phải
làm thay đổi thứ hạng của thay đổi và báo cáo cho CAB.

Người quản lí thay đổi ghi lại quyết định phê chuẩn hoặc loại bỏ thay đổi trong bản
ghi thay đổi. Nếu thay đổi bị loại, người quản lí thay đổi ghi thêm lí do tại sao làm như
vậy trong bản ghi thay đổi, đóng RFC và thông báo cho người khởi xướng thay đổi.
Nếu thay đổi thứ yếu được phê chuẩn, người khởi xướng thay đổi được thông báo và
yêu cầu thay đổi chuyển cho pha triển khai thay đổi. Mặc dù CAB không can dự trong
việc phê chuẩn thay đổi thứ yếu, người quản lí thay đổi vẫn phải thông báo quyết định
thay đổi vào cuộc họp tiếp theo.
Là tiện lợi nếu người quản lí thay đổi báo cáo trạng thái RFC bằng cách sử dụng
những truy vấn đơn giản như: “hiển thị tất cả RFC chủ yếu, đang chờ phê chuẩn”,
“hiển thị tất cả thay đổi thứ yếu” hoặc “hiển thị tất cả thay đổi chuẩn trong tiến độ.”

Cấp phép cho Thay đổi Quan trọng và Thay đổi Chủ yếu
Như thảo luận ở trên, những thay đổi bất kì, khác thay đổi chuẩn và thứ yếu phải được
CAB phê chuẩn trước. Bởi vì tác động của chúng lên môi trường và số người dùng bị
ảnh hưởng lớn hơn, những thay đổi này không thể được phê chuẩn chỉ bởi một cá
nhân. Một cá nhân không thể hiểu toàn bộ tác động trong tổ chức theo quan điểm của
một chức năng cụ thể. Thí dụ, một cá nhân không thể hiểu hậu quản của một thay đổi
về an ninh, hiệu suất hoặc các mức dịch vụ. Nói cách khác, CAB có thành phần rộng
rãi, có kiến thức tích lũy đủ để hiểu trọn vẹn việc ảnh hưởng của thay đổi.
Qui trình cấp phép của CAB cho thay đổi quan trọng và chủ yếu được biểu diễn sau
đây.

Trang 20


Bài 16 – Kiểm soát sự Thay đổi

Lưu đồ qui trình cho cấp phép cho thay đổi quan trọng và chủ yếu

Trang 21



Bài 16 – Kiểm soát sự Thay đổi
Chọn thành viên CAB
Một yêu cầu cho thay đổi quan trọng và chủ yếu phải đến CAB trước và người quản lí
thay đổi phải quyết định ai phải ngồi trên hội đồng nào để duyệt RFC đặc biệt này.
Những thành viên CAB phải được chọn cho mỗi RFC, bởi vì người thích hợp nhất
được chọn để duyệt thay đổi đã được yêu cầu này phụ thuộc vào bản chất chính xác
của RFC. CAB bao gồm một số thành viên thường trực, luôn luôn nằm trong (hoặc
người được ủy quyền khi khi nhân vật chính vắng mặt) và duyệt tất các RFC được đệ
trình cho họ. Ngoài những người này ra, CAB phải bao gồm những chuyên gia từ các
phòng ban bị tác động bởi thay đổi hoặc ai có thể có đóng góp giá trị cho thay đổi.
Những thành viên phụ này được chọn tùy từng trường hợp. CAB phải chứa một thành
viên từ mỗi cụm vai trò như được định nghĩa trong Mô hình Nhóm MOF.
Thành viên thường trực tiêu biểu của CAB gồm:
 Người quản lí thay đổi
 Những khách hàng hoặc người quản lí nghiệp vụ đại diện cho khách
hàng.
 Chuyên gia/cố vấn kĩ thuật.
 Chuyên gia an ninh.
Những vai trò khác có thể được yêu cầu để tham gia trong CAB cho một vài thay đổi
gồm:
 Đại diện hạ tầng cơ sở mạng.
 Những người phát triển/ bảo trì ứng dụng.
 Nhân sự dịch vụ.
 Nhân sự dịch vụ văn phong (trong đó thay đổi có thể tác động lên tiện
nghi và ngược lại).
 Người hợp đồng hoặc đại diện bên thứ ba khi cần (thí dụ, trong
trường hợp thuê khoán ngoài).
Qui trình chọn thành viên CAB có thể được thực hiện dễ hơn bằng cách đưa ra danh

sách thành viên CAB cho mỗi kiểu thay đổi - thí dụ, thay đổi hạ tầng cơ sở mạng, thay
đổi tiện nghi, ứng dụng mới, dữ liệu mới, cố định/nâng cấp hệ điều hành hoặc cố định
(thiết lập) desktop. Đối với mỗi thay đổi đang duyệt, thành viên CAB cũng vẫn phải
được giới hạn để cho các cuộc họp của CAB hiệu quả và quản lí được.
Thường thường thành viên CAB họp thường kì, chẳng hạn hàng tuần. Những thành
viên thường trực luôn tham dự hoặc gửi người được ủy quyền mà được phép ra quyết
định thay cho họ.
Thông báo thành viên CAB
Hội đồng cố vấn thay đổi thường thường được tập hợp lại trên cơ sở hàng tuần với sự
có mặt của tất cả thành viên thường trực và người được ủy quyền. Những thành viên
phụ của CAB thường được thông báo họp qua điện thoại hoặc e-mail.
Khi người quản lí thay đổi đã chọn thành viên CAB - người sẽ thực hiện duyệt thay
đổi, RFC là sẵn sàng cho duyệt.

Trang 22


Bài 16 – Kiểm soát sự Thay đổi
Trước vài ngày họp CAB diễn ra, người quản lí thay đổi có thể gửi thông báo họp và
e-mail tóm tắt cho tất cả thành viên của CAB. Nội dung được đề xuất cho e-mail là:
 Ngày, thời gian và địa điểm họp.
 Định dạng của cuộc họp. Như một lựa chọn để tiến hành họp đối mặt,
những cuộc họp của CAB có thể được tiến hành bằng cách sử dụng
phần mềm hội thảo Microsoft NetMeeting® hoặc bởi các cuộc gọi
điện thoại hội thảo. NetMeeting được chuộng hơn vì nó cho phép
thành viên CAB chia sẻ tài liệu và sử dụng bảng trắng điện tử.
 Thứ tự duyệt RFC (chương trình nghị sự). Thành viên CAB có thể có
thể quan tâm đến chỉ một số thay đổi đã đề xuất và có thể chỉ tham
gia họp khi cần.
 Liên kết với tất ca RFC đang được duyệt trong cuộc họp và cũng liên

kết với lịch biểu tiến triển của lịch thay đổi để thảo luận.
Lưu ý: Thông báo họp phải được gửi cho người tham gia trước khi họp tương đối sớm
để họ có thể xem xét trước.
Xác nhận và Thay đổi Logic Biểu quyết
Sau khi mọi thành viên của CAB được chọn và thông báo, phương pháp phê chuẩn
thay đổi phải được xác định. Một cách lí tưởng là yêu cầu thay đổi có thể nhận được
phê chuẩn nhất trí của CAB. Tuy nhiên, sẽ có những thay đổi là bàn cãi và thay đổi
trong đó việc cân đối rủi ro/lợi ích là không thuyết phục được. Trong trường hợp này,
người quản lí thay đổi phải chỉ định tiêu chí biểu quyết để phê chuẩn thay đổi trước
cuộc họp của CAB sao cho mọi người hiểu qui tắc trước khi biểu quyết được tiến
hành.
Để xác định qui trình biểu quyết, một số phần của biểu quyết “logic” có thể được dùng
hoặc đơn độc hoặc kết hợp với nhau. Người quản lí thay đổi chịu trách nhiệm thiết lập
logic biểu quyết nào sẽ được tổ chức dùng để phê chuẩn thay đổi và sau đó áp dụng nó
cho mỗi thay đổi riêng lẻ. Thí dụ về chủ đề logic biểu quyết có thể cần được quan tâm,
gồm:
 Nhất trí/quyết định đa số/Số phiếu trắng. Thay đổi yêu cầu phê chuẩn
của tất cả thành viên CAB, như vậy là, liệu một biểu quyết đơn lẻ về
loại bỏ có gây ra loại bỏ RFC không? Hoặc đa số của biểu quyết phê
chuẩn có đủ để thực hiện thay đổi không và, nếu như vậy, số lượng
đa số phải là bao nhiêu phần trăm? Liệu số phiếu trắng được phép là
bao nhiêu, đặc biệt khi quyết định nhất trí được chọn?
 Quyền phủ quyết. Có phải thành viên bất kì của CAB có quyền phủ
quyết không, có nghĩa rằng nếu họ loại thay đổi, thì việc loại bỏ vẫn
đứng vững, bất chấp kích cỡ của biểu quyết đa số cho thay đổi? Thí
dụ, phủ quyết của người quản lí mạng có thể có trọng lượng cho bất
kì thay đổi nào liên quan đền trang Web bên ngoài. Tương tự, một
quyết định cho phép phê chuẩn thay đổi bất chấp biểu quyết đa số
chống lại nó phải không được phép.
 Một “nhóm”, một biểu quyết. CAB thường tạo nên (tiềm tàng) một số

đại diện từ các nhóm cụ thể trong tổ chức - thí dụ, vài người từ nhóm
mạng có thể tham dự họp của CAB. Trong những trường hợp như
Trang 23


Bài 16 – Kiểm soát sự Thay đổi
vậy, chỉ một biểu quyết được phép từ nhóm mạng. Điều này cân bằng
hệ thống biểu quyết.
 Số đại biểu qui định/số người biểu quyết được yêu cầu. Phải có số
người tham dự tối thiểu trong cuộc họp của CAB và biểu quyết để
cho quyết định phê chuẩn/loại bỏ được thực hiện? Điều này phải
được xem xét trong trường hợp một số thành viên CAB không có khả
năng tham dự họp hoặc không ủy quyền được người đến dự, trong
trường hợp này quyết định có thể được thực hiện bởi một nhóm ít
người không đại diện.
Logic biểu quyết phải là tại chỗ mà áp dụng cho tất cả RFC theo mặc định. Thí dụ,
“75% biểu quyết đa số được yêu cầu, tất cả thành viên thường trực của CAB phải có
mặt và biểu quyết, và người quản lí an ninh có thể luôn luôn phản đối thay đổi”. Logic
thay đổi này khi đó có thể được hiệu chỉnh trên cở sở từng trường hợp cụ thể bởi
người quản lí thay đổi. Những hiệu chỉnh này sẽ phụ thuộc vào kiểu thay đổi và ai
trong thành viên của CAB đối với thay đổi đó.
Biểu quyết hiện thời có thể được thực hiện một cách lí tưởng thông qua thư điện tử.
Trong họp đối mặt, có thể khó ép buộc những qui tắc biểu quyết đã xác định trước để
giữ cho thảo luận trung lập. Những người biểu quyết có thể lưỡng lự do nhận thấy doạ
dẫm (thí dụ, một vài người với tính cách hiếu chiến hơn hoặc hướng ngoại có thể áp
đặt ý kiến của mình lên người khác) hơn là những sự kiện và giá trị của thay đổi
Người quản lí thay đổi ghi lại logic biểu quyết mà được áp dụng cho RFC vào bản ghi
thay đổi.
Nếu CAB dùng định dạng ảo, người quản lí thay đổi có thể dùng dạng biểu quyết để
xác định số lượng biểu quyết cần thiết để phê chuẩn thay đổi (đa số hoặc số phần trăm)

và để định danh những nhóm hay những thành viên riêng lẻ của CAB, mà là người có
quyền lực phủ quyết, mặc dù những biện pháp giống nhau không phải luôn luôn thích
hợp dùng trong cuộc họp đối mặt của CAB.
Những thành viên CAB duyệt RFC
Mỗi RFC trong chương trình nghị sự được CAB duyệt tại cuộc họp theo lịch biểu.
Người quản lí thay đổi lập lịch, điều phối và tạo thuận lợi cho cuộc họp của CAB. Đối
với mỗi cuộc duyệt, người quản lí thay đổi phải đầu tiên bảo đảm số đại biểu qui định
của những người tham gia biểu quyết có mặt tại cuộc họp, đó là, tất cả những người
iểu quyết đuợc yêu cầu (hoặc người được ủy nhiệm) và số lượng tối thiểu của người
biểu quyết phải có mặt, như được xác định bởi logic biểu quyết cho RFC. Nếu biểu
quyết không được thông qua tại chỗ, người quản lí thay đổi phải phải lập lịch biểu lại
cho duyệt và RFC được đặt trong trạng thái treo tới khi đó.
Duyệt có thể bị hoãn lại đến lần họp theo lịch tiếp theo, nếu những hạn chế về thời
gian cho phép. Nếu không (thí dụ, bởi vì thay đổi phải được thực hiện trước cuộc họp
theo lịch tiếp theo), khi đó người quản lí thay đổi phải bố trí một cuộc họp phụ thêm
để duyệt RFC và có lẽ phải tăng mức ưu tiên.
Lưu ý: Những thành viên của CAB không phải có mặt toàn bộ cuộc họp. Họ có thể
đến để thảo luận và biểu quyết về thay đổi liên quan tới họ và ra về khi thích hợp.
Người đề xướng thay đổi thường có mặt tại phiên họp của CAB, xem xét thay đổi đã
đề xuất của mình. Họ có thể được yêu cầu để nhận thông tin phụ và sau đó trình diễn
Trang 24


Bài 16 – Kiểm soát sự Thay đổi
lại RFC, hoặc thông tin hỗ trợ phụ có thể được yêu cầu từ một vài thành viên khác của
CAB. Thí dụ, thông tin chi tiết hơn về ảnh hưởng an ninh của thay đổi có thể cần từ
người quản lí an ninh mạng hoặc dữ liệu về tác động rộng hơn lên mức dịch vụ có thể
được yêu cầu từ người quản lí dịch vụ. CAB khi đó lập lịch biểu cuộc họp khác để
duyệt chứng cớ mới này và đặt RFC vào trạng thái treo trong khi thông tin đang được
nhận. Bản ghi thay đổi được cập nhật với yêu cầu thêm thông tin và ngày tháng và thời

gian cho cuộc duyệt tiếp theo.
CAB cũng có thể muốn làm một số sửa đổi trong RFC. Bởi vì người khởi xướng thay
đổi phải đồng ý với những sửa đổi bất kì, sự có mặt của họ tại cuộc họp sẽ làm nhanh
quyết định về RFC trong kiến thức của sửa đổi này.
Khi duyệt RFC những cho yêu cầu của tác động và tài nguyên CAB phải xét những
khoản mục sau:
 Tác động mà thay đổi sẽ có trên vận hành nghiệp vụ.
 Hiệu quả cho hạ tầng cơ sở và dịch vụ khách hàng, như được xác
định trong SLA, và cho hiệu năng và công suất, tính hiệu quả và tính
chịu đựng, kế hoạch cho tình huống bất ngờ và an ninh.
 Tác động lên những phần dịch vụ khác mà cùng chạy trên hạ tầng cơ
sở (hoặc trên dự án phát triển phần mềm).
 Tác động lên hạ tầng cơ sở phi - CNTT bên trong tổ chức - thí dụ, an
ninh, dịch vụ văn phong, vận chuyển, và những help desk mà phục vụ
khách hàng nghiệp vụ.
 Hiệu quả của việc không thực thi thay đổi.
 Nghiệp vụ CNTT và những tài nguyên đã yêu cầu để thực thi thay đổi,
gồm chi phí, số lượng và sự hiện hữu của người được yêu cầu, thời
gian trôi qua và những thành phần mới được yêu cầu của hạ tầng cơ
sở.
 Những tài nguyên phụ hiện thời được yêu cầu nếu thay đổi được
thực thi.
Dựa trên những đánh giá này và những ích lợi tiềm tàng của thay đổi, mỗi thành viên
CAB phải có khả năng quyết định xem nên phê chuẩn thay đổi không.
Việc dùng công nghệ có thể cho phép thành viên CAB duyệt và biểu quyết đồng ý cho
RFC không cần họp mặt. Trong trường hợp họp đối mặt với tất cả các bên quan tâm là
không thực tế, vì những hạn chế của việc phân lịch và khoảng, NetMeeting có thể
được dùng. NetMeeting cho phép những thành viên ở xa có thể chia sẻ tài liệu, sử
dụng bảng trắng điện tử, truyền tệp và tiến hành trao đổi văn bản. Lưu ý rằng
NetMeeting cũng có thể được dùng để trao đổi giọng nói và hình ảnh, nếu cần.

Những thành viên của CAB biểu quyết về RFC
Sau khi tất cả thông tin cần thiết được trình bày, sự đồng ý bất kì về những sửa đổi đối
với RFC được thực hiện, và những thảo luận đã được hoàn thành, CAB biểu quyết về
thay đổi dựa trên logic biểu quyết đã xác định.
Đối với một vài thay đổi, CAB có thể xác định rằng nó không có thẩm quyền để phê
chuẩn thay đổi. Thí dụ, thành viên của CAB có thể không có thẩm quyền ngân sách đã
yêu cầu hoặc việc mở rộng quyền hạn có thể không chứa tác động nghiệp vụ lường
Trang 25


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Tải bản đầy đủ ngay
×