1. Trang chủ
  2. » Công Nghệ Thông Tin

Bai 16 quan li su thay doi

164 309 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 164
Dung lượng 12,41 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Cái này không chỉ áp dụng cho lĩnh vực kĩ thuật được bao hàm, trong Gócvuông Vận hành Operating Quadrant, mà còn đối với thay đổi mà có thể tác động lênnhững qui

Trang 1

BÀI 16 – KIỂM SOÁT SỰ THAY ĐỔI

Giới thiệu

Nhập môn về

Phần thay đổi MOF (MOF Changing Quadrant)

Quản lí thay đổi

Lập kế hoạ ch, Xây dựng và

Kiểm thử phiên bản

Triển khai phiên bản―

Lập kế hoạ ch, Chuẩn bi, và

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ấuhình, Quản lí Phiên bản) mà tạo nên Góc vuông Thay đổi MOF (MOF ChangingQuadrant) 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:

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.

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

Trang 2

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ựccụ 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ócvuông Vận hành (Operating Quadrant), mà còn đối với thay đổi mà có thể tác động lênnhững qui trình SMF trong Góc vuông Hỗ trợ và Tối ưu (Supporting and Optimizingquadrants)

Trang 3

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

Thay đổi.

 Liệt kê trình tự cơ sở củ a các bước trong qui trình

Quản lí Thay đổi.

Quản lí 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ữngyê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êusau:

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:

http://www.microsoft.com/technet/itsolutions/cits/mo/smf/default.mspx

Để 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 4

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

Tổ chức và phương pháp của Thay đổi

Ban cố vấn Thay đổi (CAB), Ủy ban chấp hành

CNTT (ITEC), Qui trình ủy quyền (AP)

Phát triển, tạo Phiên bản và duyệt Thay đổ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ĩatrê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 5

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

Tổng quan về Quả n lí Thay đổi

Các mức ưu tiên và thứ hạ ng của 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 6

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ữngnhiệm vụ cần thiết để triển khai có kết quả một thay đổi

hủy bỏ một thành phần CNTT có chủ tâm được thực hiện trong môi

trường CNTT mà:

 Có thể tá c động đến mức dịch vụ

 Hoặc nếu không thì ả nh hưởng đến sự hoạ t động của môi trường

hoặc một phần của nó.

Quản lí Thay đổi là đặc biệt quan trọng đối với sự Thay đổi vì:

 Tác động đến người dùng mức cao và/hoặc phần lớn người dùng

 Có thể tiềm tàng phá vỡ chức năng của nhiệm vụ then chốt.

 Bao gồm phần cứng, phần mềm hoặc các qui trình sửa đổi.

 Bao gồm những thay đổi đói với những kiểu nào đó củ a dữ liệu lưu

trữ trong các hệ thống CNTT

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ácthà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ôitrườ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 quantrọ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êucầ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 7

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

một qui trình cơ sở.

doanh hoặc CNTT.

nhiệm đối với vận hành và hỗ trợ

chuyển cho các Góc vuông Vận

hành và Hỗ trợ MOF.

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áchthứ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ạmthờ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 8

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

Yêu cầu Thay đổi được khởi tạo

bằng cách đệ trì nh một RFC.

RFC là một tài liệu mà:

 Phải trả lời câu hỏi “ai, cái gì, khi

nào, ở đâu và ra sao” về Thay đổi được đề xuất.

 Phải chứa đủ thông tin để đánh giá

nhanh và chí nh xác về Thay đổi.

các nhóm kinh doanh được phục vụ

bởi CNTT hoặc các Góc vuông Hỗ

trợ và Tối ưu hoá MOF

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 CNTThoặ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 thamkhả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 đổivà 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ấtthay đổ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 quitrì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ẹnvà 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êubiểu là được khởi xướng và đệ trình bởi một trong cụm vai trò củ Mô hình NhómMOF (MOF Team Model role clusters) Thông thường, mỗi cụm vai trò đệ trình yêucầ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 trò Kiểu Yêu cầu Thay đổi

Trang 9

Cụm vai trò Kiểu Yêu cầu Thay đổi

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ộ.

bản.

hoặc an ninh mạng.

đổi đối với hệ thống help desk.

á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ộtdị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ữngnhu 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ệuchuẩn trong đó tất thông tin liên quan về thay đổi được đề xuất được ghi lại, xếp loạitừ 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ươngphá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ườnghợp hỏng, chi phí cho thay đổi, bàn giao (sign-off) ngân sách phê chuẩn nếu, và tínhkhẩn cấp của thay đổi được đề xuất Nó phải chứa thông tin đầy đủ để cho phép ngườiquản lí thay đổi đánh giá nhanh và chính xác thay đổi tại giai đoạn trình chiếu ban đầuvà 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épchúng để quyết định xem thực thi thay đổi Sử dụng định dạng chuẩn cũng buộc ngườikhở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ếtquả 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ụmvai 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 10

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ụngmộ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ậpdễ 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ắtbuộ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 đượchoàn thành càng sớm càng tốt để và để giảm nhu cầu trả RFC về cho người khởixướ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ì

Trang 11

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ộtchủ 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 choRFC

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.

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ụ.

Trang 12

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ợpnghiệ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ảnlí 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ị caohơ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ởinghiệ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 (bestpractice) 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ồntạ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ốnthê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ùngmộ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ậnthứ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áccho 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ênnà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ênkhác ở chỗ nó có lộ trình khác thông qua qui trình duyệt để thực thi thay đổi càngnhanh càng tốt Mức ưu tiên này được dành cho những thay đổi mà nếu không đượcthự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 chiphí 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ễnlập kế hoạch tốt

Thứ hạng thay đổi

Trang 13

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ậtmộ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 đinhbở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ụ, phòng 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 phòng 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 phòng 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ữngdị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ạngphả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ườngtươ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ướcbở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 quitrì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 địnhtrước có thể được phân loại như vậy Thí dụ về thay đổi chuẩn bao gồm bảo trì theolị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ườidùng trong tổ chức, người có thẩm quyền đệ trình RFC phải được hạn chế Nếu ngườidù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

Trang 14

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àykhông liên quan đến phê duyệt hoặc phê chuẩn yêu cầu thay đổi, nhưng xác định xemquyết định để ủy nhiệm hoặc từ chối thay đổi dựa trên thông tin trong RFC và nhữngtham 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ởixướ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ếukiến thức về qui trình quản lí thay đổi

Thêm thông tin còn 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 RFCvà 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ơnnhiề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ờigian 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ờigian, người quản lí thay đổi được ủy quyền hay những người được ủy quyền phải đượcchỉ đị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áolê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ếuthích hợp, e-mail này có thể được sao cho ủy ban chấp hành CNTT hoặc theo đường đitheo 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àngtháng để cho phép mức-cao hơn biết Sự kiện RFC đã không được trình chiếu tronghạ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 15

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ảnghi thay đổi được cập nhật và người khởi xướng thay đổi được thông báo, và RFCchuyể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 đíchtheo 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 ghithay đổ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ểmsoá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ếtcủ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ậpnhậ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 ghithay đổ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 16

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

Phân loại

phê chuẩn và triển khai một Thay đổi được yêu cầu.

tàng của thay đổi đến mức dịch vụ và những yêu cầu về tà i nguyên để triển khai.

Cấp phép

phát triển và tạ o phiên bản

đóng.

Mọi thay đổi được phân loại theo mức độ ưu tiên và thứ hạng để giúp cho tổ chứcphâ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ủachúng đối với tổ chức Bảng sau đây mô tả hai lớp

Mô tả thuật ngữ

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.

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 đếntrong phần tiếp theo Cấp phép cho thay đổi cung cấp phê chuẩn chính thức để thay đổichuyể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ấpphé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

Trang 17

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ựatrê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ởixướ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 ghithay đổi Sau khi được đóng, RFC không được mở lại Nếu người khởi xướng thay đổimuố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ấtcả 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 ưutiê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ầugố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ấpphé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 cungcấ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ứ

yếu

Thay đổi Khẩn cấp

Thay đổi Quan 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 CABThành viên CAB

Vận hành Đã được cấp

phép trước

Không can dự Thành viên CABThành viên CAB

Đối tác Cấp phép Không can dự Thành viên CABThành viên CABPhiên bản Cấp phép Cấp phép Thành viên CABThành viên CAB

An ninh Đã được cấp

phép trước

Không can dự Thành viên CABThành viên CAB

Hỗ trợ Đã được cấp

phép trước

Không can dự Thành viên CABThành viên CAB

Dịch vụ Đã được cấp

phép trước Không can dự Thành viên CABThành viên CAB

Trang 18

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ếtlậ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 đổikhô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ìnhchiếu ban đầu để bảo đảm rằng yêu cầu thay đổi mà đã được gán ưu tiên chuẩn, chínhlà 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 rothấ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ủathay đổ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 đổithứ 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ềnphê 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ễntrong lưu đồ sau đây

Trang 19

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 tincầ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 20

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ìnhnà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ảilà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ảnghi 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ự trongviệ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 địnhthay đổ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ụngnhữ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 đượcCAB 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ủamộ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 đổivề 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ộngrã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 21

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

Trang 22

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áccủ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ặcngườ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ácphò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ànhviê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.

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 phòng (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 danhsá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ànhviê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ênphụ 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

Trang 23

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 cả 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ẩnthay đổ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 đượcphê chuẩn nhất trí của CAB Tuy nhiên, sẽ có những thay đổi là bàn cãi và thay đổitrong đó 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ướccuộ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ếnhà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ùnghoặ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ậplogic 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ư 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.

Trang 24

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” Logicthay đổi này khi đó có thể được hiệu chỉnh trên cở sở từng trường hợp cụ thể bởingườ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à aitrong 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 ghithay đổ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íchhợ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 Đốivớ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 địnhcủ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ểuquyế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ạicho 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ờigian 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ọptheo 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 đã

Trang 25

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 đượcnhậ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ờigian 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 nhanhquyế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ữngkhoả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 phòng, 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ênCAB 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 ý choRFC 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ằngNetMeeting 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 đốivớ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ườngtrước Trong trường hợp này, yêu cầu thay đổi được chuyển lên cho ITEC, và bản ghithay đổi được cập nhật một cách tương ứng bởi người quản lí thay đổi, người bao gồm

Trang 26

ITEC là một ủy ban quản lí với thẩm quyền ngân sách và tài nguyên để ra quyết địnhvề thay đổi chủ yếu và quan trọng trong môi trường Quyết định của ITEC là cuốicùng, và một đại diện của ITEC thông báo cho người quản lí thay đổi về quyết địnhcủa ITEC sau khi nó được đưa ra (thủ tục về việc ITEC gặp nhau, duyệt thay đổi vàđạt được quyết định của mình như thế nào không được xét ở đây.)

Khi CAB có khả năng phê chuẩn hoặc loại bỏ RFC, họ cập nhật bản ghi thay đổi vàthông báo cho người khởi xướng thay đổi và những bên liên quan về quyết định Nếuquyết định được hoãn cho ITEC, quyết định được gửi lại cho người khởi xướng thayđổi và những bên liên quan

Cấp phép cho Thay đổi Khẩn cấp

Qui trình thay đổi khẩn cấp, cho phép tổ chức tiếp tục thực hiện hoạt động bình thườnghoặc khôi phục chúng càng nhanh càng tốt, là qui trình tăng tốc, cho phép qui trìnhthay đổi bình thường đối với qui mô mà hạn chế thời gian cho phép Thay đổi khẩncấp cần được thực thi nhanh - thí dụ, để tránh lỗ thủng an ninh tiềm tàng hoặc cố định

(thiết đặt) ứng dụng nghiệp vụ-tới hạn Bởi vì thay đổi khẩn cấp thường là phá hỏng

và gây lỗi, số lượng thay đổi khẩn cấp phải hạn chế ở mức tuyệt đối nhỏ Hạn chế

thời gian cho phép chỉ thực hiện kiểm thử giới hạn và yêu cầu những qui trình và kiểmsoát bình thường được đi vòng Do đó, thay đổi khẩn cấp cần được tìm theo vết nhanhqua hệ thống quản lí thay đổi Thay đổi khẩn cấp không thể được cấp phép bởi một cánhân và phải được phê chuẩn thông qua bởi ban cố vấn thay đổi/ủy ban khẩn cấp(CAB/EC)

CAB/EC có cùng mục đích và thực hiện cùng chức năng như CAB thông thường Sựkhác biệt là số thành viên của CAB/EC ít hơn so với CAB thông thường và CAB/ECcó khả năng gặp mặt và ra quyết định nhanh sau thông báo CAB/EC phải được trangbị quyền để ra quyết định nhanh không tham khảo ITEC và phải có toàn quyền để phêchuẩn hoặc hủy bỏ thay đổi khẩn cấp

Lưu đồ qui trình cho thay đổi khẩn cấp được biểu diễn dưới đây và tương tự như quitrình cho thay đổi không khẩn cấp

Trang 27

Lưu đồ qui trình cấp phép cho thay đổi khẩn cấp

Chọn thành viên CAB/EC

Thành viên CAB/EC bao gồm những thành viên thường trực, cộng với những thànhviên khác, phụ thuộc vào bản chất của thay đổi khẩn cấp Một cách lí tưởng là nhữngthành viên thường trực một mình có kiến thức đầy đủ và thẩm quyền để đưa ra quyếtđịnh Càng nhiều người tham gia họp CAB/EC, càng ít có thể tham dự theo thời hạn

Trang 28

ngày của họ Những thành viên phụ thêm của CAB/EC phải được mời, do vậy, chỉnếu tuyệt đối cần thiết Thí dụ có thể là thay đổi mà tác động lên những lĩnh vực nằmngoài kiến thức và thẩm quyền của thành viên thường trực Người khởi xướng thay đổi

cho một RFC cụ thể là ngoại lệ Người này cần phải là một thành viên của CAB/EC để

cung cấp trả lời nhanh cho câu hỏi của họ Bởi vì thay đổi khẩn cấp có thể được yêucầu tại thời điểm bất kì và yêu cầu được triển khai nhanh, CAB/EC có khung thời gianhẹp để gặp mặt và biểu quyết Do việc biểu quyết yêu cầu đạt được số lượng đại biểutham dự cần thiết, nên thành viên thường trực và người được ủy của CAB/EC phảiluôn luôn có khả năng tham dự trong thời hạn ngắn Tính hiện hữu này có thể đạt đượcnhờ bảng phân công “theo-cuộc gọi” cho mỗi vai trò của CAB/EC, để một người luôncó mặt cho mỗi vị trí trong CAB/EC, tại thời điểm bất kì nào trong ngày-hoặc theotừng người, qua điện thoại, hoặc bằng cách sử dụng những giải pháp công nghệ khác.Người quản lí thay đổi phải có khả năng tập hợp thêm thành viên cho CAB/EC khicần Đối với thay đổi khẩn cấp, logic biểu quyết là phê chuẩn nhất trí

Thông báo cho thành viên CAB/EC

Người quản lí thay đổi phải liên lạc với từng thành viên của CAB/EC để thông báo chohọ về yêu cầu thay đổi khẩn cấp, khi nào nó sẽ được duyệt lại và họp sẽ có dạng nào.Như trình bày dưới đây, những cuộc họp của CAB/EC được tiến hành trên cơ sở khi -cần với những cánh báo nhỏ trước Điều này có nghĩa là những phương pháp thôngbáo bình thường có thể không đủ Nếu yêu cầu họp qua e-mail được dùng, người đượcmời phải dành chút ít thời gian để báo cho biết đã nhận được mời họp cho người quảnlí thay đổi; nếu không thì những phương pháp trực tiếp khác để liên lạc với thành viêncủa CAB/EC phải được dùng

Thành viên CAB/EC Duyệt RFC

CAB/EC duyệt yêu cầu thay đổi khẩn cấp bằng cách sử dụng cùng một tiêu chí đượcdùng cho thay đổi thông thường Việc đánh giá rủi ro và tác động là, theo một vàicách, quan trọng hơn đối với thay đổi khẩn cấp bởi rủi ro thường cao hơn và kiểm thửthay đổi thường nhỏ hoặc không tồn tại

Sự có mặt của người khởi xướng thay đổi tại cuộc họp cho phép những câu hỏi về thayđổi và tác động của nó được đặt trực tiếp và trả lời tức thì Đây có thể là nhu cầu đểthu thập thông tin phụ thêm và tái-trình bày RFC cho CAB/EC trước khi một quyếtđịnh được đưa ra Trong trường hợp này, RFC được đặt trong trạng thái treo cho tớikhi CAB/EC có thể triệu tập lại, có vẻ như trong thời gian ngắn (một giờ chẳng hạn).CAB/EC có thể quyết định là thay đổi không phải khẩn cấp và phải được xử lí như bởiqui trình thay đổi thông thường Trong trường hợp này, người quản lí thay đổi phânloại lại thay đổi và cập nhật bản ghi thay đổi lí do phân loại lại Nếu người khởi xướngthay muốn RFC được xét lại lần nữa như một thay đổi khẩn cấp, nguwowfi này phảicung cấp điều hiển nhiên hỗ trợ phụ để biện minh cho nhu cầu và tái-đệ trình RFC chongười quản lí thay đổi Người quản lí thay đổi có thể đem RFC, chứa thông tin mới, trảvề cho CAB/EC Lần nữa, qui trình này có thể xảy ra rất nhanh - trong vài phút hoặcgiờ, chứ không phải là ngày Nếu người khởi xướng thay đổi đồng ý rằng thay đổi

Trang 29

Nếu không tất cả thành viên của CAB/EC có mặt để họp đối mặt, NetMeeting có thểđược dùng để tạo thuận lợi cho trao đổi.

Thành viên CAB/EC biểu quyết về RFC

Khi thảo luận hoàn thành và nhất trí là tất cả thông tin cần thiết đã có, CAB/EC biểuquyết về thay đổi Để thay đổi khẩn cấp được phê duyệt, cần biểu quyết nhất trí Trongtrường hợp này, đa số chưa đủ, xem xét rủi ro sinh ra trong thay đổi khẩn cấp

Nếu RFC được phê chuẩn, thay đổi chuyển sang giai đoạn phát triển thay đổi, lại tiếptheo lộ trình đến thực thi thay đổi càng sớm càng tốt Bất cứ quyết định nào được đưa

ra, người khởi xướng thay đổi và tất cả được thông báo về quyết định và bản ghi thayđổi được cập nhật

Người quản lí thay đổi phải ghi quyết định và làm tài liệu cho biểu quyết (đồng ý hoặcphản đối) RFC bằng cách cập nhật bản ghi thay đổi

Tóm tắt

Qui trình cấp phép thay đổi:

Định nghĩa cấu trúc để cấp phép cho thay đổi thuộc tất cả thứ hạng và các mức ưu tiên.

Kết hợp chặt chẽ phản hồi từ tất cả các cụm vai trò can dự trong qui trình cấp phép khi cần.

Xác định chức năng của người quản lí thay đổi và thành phần và chức năng của CAB và CAB/EC trong qui trình cấp phép cho thay đổi.

Sử dụng logic biểu quyết để ra quyết định hiệu quả.

Cung cấp chu kì phản hồi, mà sẽ được bao gồm trong qui trình cấp phép cho người đề xướng thay đổi.

Trang 30

Phát triển và tạo Phiên bản cho sự thay đổi

 Phát triển thay đổi bao gồm lập

kế hoạ ch và xây dựng thành

phần CNTT hoặc qui trình mới

 Khi một thay đổi được phát triển

và kiểm thử, nó được triển khai

bởi quản lí phiên bản

Trong quá trình phát triển sự thay đổi thực tế được thực hiện Nó bao gồm thông tinđưa ra như cho cấu hình máy phục vụ, mã cho chương tình ứng dụng và những thiết kếkiến trúc Luật phát triển thay đổi phải được theo dõi trong khi xây dựng thay đổi đểbảo đảm một phiên bản có chất lượng Luật phải bao gồm lập kế hoạch, phát triển,kiểm thử và triển khai

Những thay đổi phức tạp cần thời gian vượt trội, nỗ lực và tài nguyên, có thể yêu cầuchủ nhân của thay đổi quản lí thay đổi cho tới khi hoàn thành

Phát triển thay đổi

Sau khi RFC đã được phê chuẩn (dùng lộ trình thích hợp dựa trên mức ưu tiên và thứhạng), nó chuyển sang pha phát triển thay đổi Pha này gắn với những bước cần thiếtđể lập kế hoạch thay đổi, phát triển những phân phối đưa ra cho thay đổi (thí dụ, pháttriển mã mới hoặc cấu hình phần cứng mới), và bàn giao cho qui trình quản lí phiênbản để triển khai thay đổi vào môi trường sản phẩm

Những qui trình được bao gồm trong pha phát triển thay đổi và phiên bản được biểudiễn trên hình sau

Tốc độ thực hiện của các bước trong qui trình này có thể thay đổi rất lớn Một thay đổinhỏ - nhưng khẩn cấp - có thể được lập kế hoạch, phát triển và thực thi trong vài phút.Một thay đổi bao gồm triển khai một gói phần mềm mới vào xí nghiệp có thể cần vàitháng hoặc cả năm cho pha phát triển và triển khai Do thay đổi lớn này, yêu cầu mứclinh hoạt đáng kể trong mỗi bước đơn lẻ Tuy nhiên, một vài bước, như duyệt, luônphải có, ngay cả khi chỉ là một cuộc trao đổi rất ngắn giữa hai người

Trong khi triển khai thay đổi được chỉ đạo và tổ chức bởi Cụm Vai trò Phiên bản của

Trang 31

động cụ thể phụ thuộc vào kiểu của thay đổi đang triển khai, bảng sau cho một vài thídụ về hoạt động mà những cụm vai trò khác nhau đảm nhận.

Lưu đồ qui trình phát triển thay đổi và phiên bản

Sự can dự của Cụm Vai trò của Mô hình Nhóm MOF trong Phát triển Thay đổi và

Phiên bản Cụm Vai trò của

Mô hình Nhóm MOF Phát triển Thay đổi và Phiên bản

Hạ tầng cơ sở Cung cấp sự tinh thông kĩ thuật trong quá trình phát triển và

triển khai thay đổi

Trang 32

Cụm Vai trò của

Mô hình Nhóm MOF Phát triển Thay đổi và Phiên bản

Vận hành Trợ giúp phát triển thay đổi và triển khai vào môi trường

sản phẩm, bảo đảm rằng thực tế công việc vận hành tạo điều kiện cho thay đổi trong và sau triển khai với phá hỏng cực tiểu

Đối tác Điều phối sự tham dự của tài nguyên bên thứ ba bất kì và

bảo đảm rằng thay đổi được triển khai kết quả vào mọi sắp đặt dịch vụ khoán ngoài bất kì

Phiên bản Quản lí hoạt động triển khai thay đổi

An ninh Bảo đảm rằng những đặc trưng an ninh thích hợp và thành

phần được nhắm tới trong phát triển thay đổi, rằng an ninh là không thoả hiệp trong triển khai, và rằng mọi phần thêm hoặc thay đổi đối với thực tế an ninh được trang bị chính xác

Hỗ trợ Cung cấp hỗ trợ cho phát triển và triển khai thay đổi, bảo

đảm rằng HelpDesk có thể trợ giúp người dùng với nhu cầuhỗ trợ bất kì trong triển khai

Dịch vụ Bảo đảm các mức dịch vụ thực hiện trong dự án và được

nhát trí không bị phủ nhận bởi phát triển thay đổi và rằng tấtcả thay đổi đều được khách hàng phê chuẩn và thích hợp với mục đích của cải tiến dịch vụ

Lập lịch cho thay đổi

Sau khi thay đổi được phê chuẩn, nó phải được giải quyết khi triển khai Ngày và thời

gian thay đổi phải được đưa lịch biểu tiến hành thay đổi, mà được người quản lí thay

đổi giữ Lịch biểu tiến hành thay đổi chỉ ra khi nào tất cả thay đổi được tiến hành Cómột lịch biểu cho thay đổi khiến có thể chỉ ra cử sổ thay đổi tồn tại (thời gian trong đóthay đổi được phép) Nó cũng bảo đảm rằng những thay đổi phức tạp và phụ thuộc lẫnnhau không được lập lịch tại cùng thời điểm; đôi khi thay đổi có thể được lập lịch màngăn cản việc thực hiện mọi thay đổi khác (bao gồm cả thay đổi chuẩn) Khi lập lịchthay đổi, phải ra thông báo về những thay đổi khác mà phụ thuộc vào thay đổi đã đượclập lịch hoặc thay đổi được lập lịch tự nó phụ thuộc vào chúng - thí dụ, một điều kiệntiên quyết

Trong một vài trường hợp, chỉ có thể vào ngày tháng dự định cho thay đổi Đó làtrường hợp cho thay đổi lớn mà yêu cầu pha phát triển dài Do tiến độ dự án phát triểndài và kế hoạch dự án phát triển được vạch ra và theo dõi, ngày thay đổi sẽ được thựcthi vào môi trường sản phẩm trở nên định rõ hơn Tuy thế, ngày cho những thay đổiphải được duyệt theo chu kì thời gian và được hiệu chỉnh khi cần

Trang 33

biểu với tham khảo lịch biểu tiến hành thay đổi Thí dụ, cài đặt một ứng dụng phầnmềm (thay đổi chuẩn) có thể bị ngăn cản bởi nâng cấp mạng (thay đổi chủ yếu).

Khi lập lịch biểu cho một thay đổi, điều quan trọng không chỉ tính toán thứ hạng vàmức ưu tiên của thay đổi, cũng như tác động bất kì từ thay đổi đang đợi triển khai, màcòn khẳng định những tác dụng của lịch biểu bất kì trên các mức ưu tiên nghiệp vụ.Thí dụ, triển khai một thay đổi có thể được lập lịch biểu để xảy ra ngoài giờ làm việcphù hợp với những thoả thuận mức dịch vụ tồn tạicho dịch vụ bị tác động Tuy nhiên,điều này có thể được khẳng định trong trường hợp đã có những thay đổi bất kì cho cácmức ưu tiên nghiệp vụ mà có thể bị tác động nếu thay đổi xảy ra vào ngày đó Thí dụ,có những ngày, tại đó có mức rủi ro thấp cho hiệu suất nghiệp vụ, thay đổi nên rút lui Đánh dấu những ngày ưu tiên nghiệp vụ chính là có lợi, chẳng kết thúc năm tài chính,hoặc những chu kì được dự báo của thu nhập bán hàng cao, trong lịch biểu tiến hànhthay đổi bởi vì những điểm này trở nên dễ nhận biết, cho nên khi đó thay đổi tránhnhững ngày chủ yếu này Nhóm Vai trò Dịch vụ sẽ có khẳ năng cung cấp thông tin nàycho người quản lí thay đổi

Lịch trên Microsoft Outlook, Exchange, hoặc các chương trình e-mail có thể đượcdùng để quản lí lịch biểu tiến hành thay đổi Outlook có thể được dùng để tạo ra cáccuộc hẹn trong lịch biểu thay đổi, và sự cho phép có thể được thiết đặt sao cho phầnlớn người dùng đọc lịch nhưng chỉ cho phép số ít (nhóm người quản lí) cập nhật hoặcthay đổi

Việc thêm vào tạo mã có mầu và sử dụng văn bản có nghĩa trong những đầu vào lịchbiểu cho thay đổi làm cho tương đối dễ nhận biết thay đổi khẩn cấp, chủ yếu và thứyếu hoặc những thay đổi tác động lên phần cụ thể của nghiệp vụ

Chỉ định Chủ nhân của thay đổi

Sau khi thay đổi được lập lịch biểu, người quản lí thay đổi cần nhận diện và chỉ ra chủnhân của thay đổi để quản lí thay đổi trong suốt qui trình phát triển và phiên bản vàvào môi trường sản phẩm Chủ nhân của thay đổi cũng có thể là người đề xướng thayđổi Chủ nhân của thay đổi đã được bao gồm có thể là chuyên gia kĩ thuật trước đâytrong vòng đời thay đổi như người khởi xướng, có thể đã không biết tác động CNTTcủa thay đổi mà họ đưa ra, hoặc chủ nhân của thay đổi có thể là người mới được chỉđịnh, một người dường như là một chuyên gia chuyên về vấn đề trong lĩnh vực kết nốivới RFC và như vậy có khả năng kĩ thuật cần thiết để quản lí thay đổi cho tới hoànthành Trong trường hợp thay đổi nhỏ, chủ nhân của thay đổi có thể thực hiện thay đổiđơn lẻ Đối với những thay đổi lớn, chủ nhân của thay đổi hành động trong vai trò củangười quản lí dự án trong pha phát triển và kiểm thử và xem tổng quan việc thực thithay đổi Mức ưu tiên và thứ hạng thay đổi phải là một phần của tiêu chí dùng để chỉ rachủ nhân của thay đổi phù hợp cho RFC cụ thể Thí dụ, đối với mức ưu tiên cao, thayđổi chủ yếu sẽ được thực thi, thì chủ nhân của thay đổi được chọn có thể cần có mộtmức nào đó về kĩ năng quản lí dự án hoặc thâm niên cao trong tổ chức

Khi chủ nhân của thay đổi thích hợp được chỉ định và được gán cho RFC, người quảnlí thay đổi ghi lại tên của chủ nhân của thay đổi vào bản ghi thay đổi và thay đổichuyển sang giai đoạn phát triển thay đổi

Phương pháp luận Phát triển Thay đổi

Trang 34

Tất cả thay đổi không chuẩn chuyển qua phương pháp luận phát triển thay đổi, thayđổi rất lớn theo kích cỡ và phạm vi phụ thuộc vào bản chất của thay đổi Một vài thayđổi yêu cầu công việc tăng cường và chi tiết hơn trong mỗi pha phát triển thay đổi hơnnhững thay đổi khác.

Do chúng đại diện cho thay đổi rủi ro thấp, được lặp lại, những thay đổi chuẩn khôngqua pha phát triển Đối với những kiểu khác của thay đổi, việc chọn phương pháp luậnđược dùng trong pha phát triển thay đổi là mở, và nhiều phương pháp luận tồn tại Cókhả năng cho phép những bước đơn lẻ của phương pháp luận phát triển thay đổi hoặcqui trình phát triển được dùng bên trong tổ chức Ngoài ra, Mô hình Qui trình MSF(Microsoft Solutions Framework (MSF)) được biểu diễn sau đây có thể được dùng đểxây dựng phát triển phiên bản Thông tin thêm về MSF có thể tìm thấy trong trangWeb http://www.microsoft.com/MSF

Mô hình Qui trình MSF

Phương pháp luận thay đổi được chọn phải đủ lịnh hoạt để xử lí công việc phát triểnvới kích cỡ bất kì nào Thí dụ, một điều gì đó đơn giản như việc cải tiến tài liệu thôngqua quản lí thay đổi, có thể vẫn được phát triển bằng cách dùng MSF một cách khôngchính thức Trong trường hợp này, pha Hình dung và Lập kế hoạch là rất ngắn vàkhông bao gồm nhiều người Pha Phát triển không cần kế hoạch phát triển dự án phứctạp bởi vì đó chủ yếu là bài tập của tác giả và bao gồm chỉ mọt hoặc hai người Nóicách khác, thay đổi phức tạp như nâng cấp tất cả máy desktop với MicrosoftWindows® XP, là một dự án rất lớn, bao gồm nhiều người trong trong toàn công ti,yêu cầu giai đoạn lập kế hoạch và phát triển dài và chi một khoản tiền lớn Trongtrường hợp như vậy, điều quan trọng là theo một phương pháp luận phát triển chínhthức sao cho người quản lí thay đổi có thể theo vết tiến độ thay đổi và điều phối việcdịch bất kì của ngày triển khai đã được lập kế hoạch với những thay đổi khác

Những thay đổi khẩn cấp cũng phải chọn phương pháp luận phát triển để dùng, thậmchí có áp lực thực thi thay đổi càng nhanh càng tốt Tổng chi phí thời gian trong mỗi

Trang 35

pháp luận được chọn phải đủ linh hoạt để cho phép lộ trình theo vết-nhanh này, khôngnhảy cóc những kiểm tra quan trọng theo dọc đường đi.

Lưu ý: Trong Pha Phát triển, và đặc biệt tại các cuộc duyệt theo mốc (xem dưới đây,

nhóm dự án phải từ bỏ thay đổi Điều này có thể xảy ra vì một số lí do Thí dụ, PhaHình dung có thể bộc lộ ra là ngân sách không đủ để đạt được thay đổi mong muốn;hoặc trong Pha Phát triển, những sự kiện như là việc tiếp quản Công ty bằng cổ phầncó thể khiến thay đổi lỗi thời Để cho đơn giản, những điểm quyết định này khôngđược biểu diễn trên lưu đồ Tuy nhiên, nếu thay đổi cần từ bỏ, nó phải được thảo luậntại cuộc họp của CAB tiếp theo, và RFC đóng lại là cần thiết Người quản lí thay đổichú thích lại nguyên nhân từ bỏ thay đổi trong bản ghi thay đổi thông báo cho ngườikhởi xướng thay đổi và các bên quan tâm khác

Duyệt theo mốc

Khung công việc phát triển như MSF có những điểm duyệt khi dự án phát triển chuyểntừ pha này sang pha khác - thí dụ, từ Hình dung sang Lập kế hoạch Duyệt theo mốcbảo đảm rằng pha trước được hoàn thành có kết quả và dự án sẵn sàng chuyển sangpha tiếp theo Trong một vài trường hợp, như trong một dự án rất nhỏ, phê chuẩn củamột số người trong các nhóm khác nhau, có thể yêu cầu một tiểu ban của những đạidiện CAB có mặt cho phê chuẩn thay đổi

Đối với dự án cụ thể bất kì, duyệt theo mốc có thể có các dạng khác nhau từ mốc nàyđến mốc tiếp theo Thí dụ, duyệt Mốc Phê chuẩn Tầm nhìn/Phạm vi toàn bộ(Vision/Scope Approved Milestone) bởi CAB có thể được yêu cầu tại cuối Pha Hìnhdung, khi những chi phí chi tiết của triển khai có thể nhận được và làm tài liệu DuyệtMốc Phê chuẩn Kế hoạch Dự án có thể là đủ, tại cuối Pha Lập kế hoạch Nếu không cónhững vấn đề mới yêu cầu phê chuẩn từ CAB

Qui trình duyệt dự án bảo đảm rằng tiến độ từ một pha MSF này đến poha tiếp theođược nhất trí bởi tất cả các nhóm bị tác động bởi thay đổi Nó nối kết ngược lại với quitrình quản lí thay đổi theo cách RFC được tham khảo và cập nhật trong cuộc duyệt, vànhững người duyệt có tùy chọn dừng thay đổi và đóng RFC, nếu cần, hoặc báo leothang quyết định cho ITEC

Duyệt Mốc Phê chuẩn Kế hoạch Dự án là tương tự theo nhiều cách đối với qui trìnhduyệt của CAB, trong qui trình đó quyế định ban đầu về thay đổi được đưa ra DuyệtMốc Phê chuẩn Kế hoạch Dự án có thể được xem như duyệt RFC lần nữa, nhưng dựatrên thông tin mới nhất được câp nhật nhiều hơn liên quan đến chi phí và rủi ro (nhậnthức rằng thay đổi cơ sở tự nó luôn sẵn sàng đã được phê chuẩn) Cùng tiêu chí đượcdùng để chọn thành viên CAB để cấp phép cho thay đổi, phải được áp dụng khi chọnngười duyệt các mốc qui trình phát triển

Đối với việc duyệt các mốc, người quản lí thay đổi hiệu chỉnh danh sách thành viênCAB cho phù hợp với bản chất của thay đổi, các mốc mà đã đạt được và trạng tháitổng thể hiện thời của dự án (thí dụ, có thể cần số người ra quyết định có thâm niênnhiều hơn, nếu dự án đang thực hiện quá chậm hoặc ngân sách vượt quá hoặc nhữngrủi ro nghiêm trọng khác được nhận diện)

Duyệt theo mốc thường xảy ra cùng thời điểm với các cuộc họp thường lệ của CAB đểduyệt RFC Nếu duyệt theo mốc cần tiến hành sớm hơn lần họp được lập lịch tiếptheo, thì kiểu họp nếu-cần của CAB có thể được yêu cầu Mỗi cuộc duyệt theo mốc

Trang 36

thông tin và thảo luận hoàn thành, CAB biểu quyết về thay, sử dụng logic biểu quyết

đã xác định Nếu không quyết định nào được đưa ra, cùng nguyên lí và thủ tục đượctheo đuổi như trong cuộc duyệt ban đầu của CAB: quyết định được chuyển cho ủy banchấp hành CNTT (ITEC) Xem phần Thành viên CAB Duyệt về mô tả thủ tục leothang, mà giống như là cho duyệt RFC gốc

Nếu CAB biểu quyết để không phê chuẩn duyệt, điều này có thể gây ra một trong haihậu quả:

 CAB có thể quyết định rằng tất cả tiêu chí để chuyển việc duyệt đều

không đạt, nhưng đièu dự án không thể đạt tiêu chí vơi nhiều công việc hơn trong một số lĩnh vực Trong trường hợp này, CAB làm hỏng dự án khi duyệt, nhưng RFC và thay đổi đã phê chuẩn vẫn còn có hiệu lực RFC quay trở về Pha Triển khai mà vừa mới hoàn thành Người quản lí thay đổi cập nhật bản ghi thay đổi, làm chi tiết công việc phụ được yêu cầu cho triển khai thay đổi vào bước pha theo

 Như một lựa chọn, CAB (hoặc có thể ITEC nếu quyết định đã leo thang)

có thể quyết định không phê chuẩn mốc và hủy bỏ tất cả thay đổi Điều này có thể xảy ra trong Pha Lập kế hoạch, thí dụ, nếu quyết định rằng dự án không thể được hoàn thành đúng hạn với chức năng đã yêu cầu và trong ngân sách hiện có Hơn là làm lại kế hoạch, CAB có thể quyết định hủy toàn bộ dự án và cung cấp giải pháp theo cách hoàn toàn khác, như thuê khoán ngoài Trong trường hợp này, RFC được đóng

Trong cả hai trường hợp, thay đổi đước cập nhật với lí do đối với quyết định và ngườikhởi xướng thay đổi và các bên quan tâm bất kì khác được thông báo

Nếu CAB phê chuẩn duyệt theo mốc, thì qui trình triển khai chuyển sang pha tiếp theo,

qui trình phiên bản Hãy xem Hướng dẫn Chức năng Quản lí Dịch vụ của Quản lí Phiên bản (Release Management Service Management Function ) để biết chi tiết về

những thực tế cụ thể liên quan đến qui trình này

Tóm tắt

Qui trình phát triển thay đổi và phiên bản:

 Lập lịch biểu thay đổi theo mức ưu tiên nghiệp vụ, đường ống thay đổi,

thứ hạng, mức ưu tiên.

 Chỉ định chủ nhân của thay đổi thích hợp theo yêu cầu của thay đổi

trong ngữ cảnh của công nghệ, kích cỡ, mức ưu tiên và thứ hạng.

 Bảo đảm qui trình phát triển thay đổi theo một vòng đời phát triển

được chấp nhận.

 Chỉ đạo duyệt theo mốc, với sự tham gia của những thành viên CAB,

để bảo đảm rằng mỗi pha đã hoàn thành đạt kết quả.

 Bảo đảm rằng thay đổi đã phát triên và được chuyển cho qui trình

phiên bản đã nhận được tiêu chí chấp nhận.

Trang 37

Duyệt Thay đổi

Mỗi thay đổi được triển khai cần

một bước duyệt sau-thực thi để xá c

định hiệu qủa.

 Việc thay đổi có đạt được mục đích

không?

 Có bà i học bất kì nào được rút ra

có thể được đưa vào trong phiên

bản trong tương lai không?

Thay đổi được hoàn thành sau khi

duyệt đạt kết qủa, khi trách nhiệm

được chuyển cho các Góc vuông

Vận hành và Hỗ trợ MOF.

CAB, người quản lí phiên bản, chủ nhân của thay đổi, người khởi xướng thay đổi vànhững đại diện từ các Góc vuông Vận hành và Hỗ trợ tham gia vào duyệt sau thực thi(post-implementation review-PIR) Trong quá trình duyệt, tính chức năng của thay đổivà tính hiệu qủa của việc triển khai được duyệt và một quyết đinh cuối cùng về việcchấp nhận thay đổi được đưa ra, bởi vì việc triển khai đã hoàn thành

Thu thập những bài học rút ra được và cất giữ chúng để có thể truy nhập và đượcdùng như hướng dẫn cho những thay đổi trong tương lai

Tiếp sau phiên bản và triển khai kết qủa vào môi trường sản phẩm hoặc, như trongtrường hợp thay đổi chuẩn, chính việc triển khai vào sản phẩm, qui trình duyệt phảiđược tiến hành để thiết lập xem thay đổi có tác động mong muốn và có đạt yêu cầuban đầu cho thay đổi Qui trình cho duyệt thay đổi được biểu diễn trong lưu đồ sau

Trang 38

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

Trong phần lớn trường hợp, qui trình duyệt này phải ngắn gọn Đối với thay đổi chuẩn,thí dụ, khi tác động đã có là nhỏ và kết qủa là tương đối dự đoán được, qui trình duyệtcó thể bị giới hạn rằng người dùng có chức năng mong muốn từ thay đổi, chẳng hạnnhư hiện hữu của mẫu van bản Word mới Những bước khác trong qui trình có thểđược thực hiện trong những cuộc họp khi-cần hoặc những cuộc gọi điện thoại vớingười quản lí thay đổi

Ngoài những thay đổi có lộ trình “bình thường” qua qui trình thay đổi, những thay đổikhẩn cấp cũng phải được duyệt, bất chấp tốc độ triển khai có thể được thực hiện Thựctế là, duyệt thực thi của thay đổi khẩn cấp là điều quan trọng hơn bởi vì việc kiểm thửrút ngắn của chúng dẫn đến những rủi ro lớn Do đó cần thiết xác định càng sớm càngtốt nếu thay đổi gây hậu qủa bất lợi

Trang 39

bản chỉ đạo duyệt thay đổi, nhưng mỗi cụm vai trò của Mô hình Nhóm có những lĩnhvực quan tâm cụ thể liên quan đến trách nhiệm của chúng, như được liệt kê sau đây

Lĩnh vực quan tâm của Cụm Vai trò của Mô hình Nhóm MOF trong hoạt động duyệt

thay đổi Cụm Vai trò của Mô

hình Nhóm MOF

Lĩnh vực quan tâm của Hoạt động Duyệt Thay đổi

Hậ tầng cơ sở Những vấn đề kĩ thuật hoặc năng lực đã xảy ra trong qúa trình thay

đổi?

Vận hành Những vấn đề vận hành bất kì đã xảy ra trong và sau qúa trình thay

đổi?

Đối tác Có những vấn đề bất kì với bên thứ ba hoặc đối tác không?

Phiên bản Tiến độ thay đổi trong quá trình quản lí thay đổi ra sao và bài học

nào có thể rút ra?

An ninh Có những vấn đề an ninh bất kì nào trở nên nhận rõ với thay đổi?Hỗ trợ Có những vấn đề bất kì về tính hỗ trợ được là hiển nhiên trong và sau

thay đổi?

Dịch vụ Có những mức dịch vụ bất kì nào bị hỏng trong và sau thay đổi?

Kiểm soát Thay đổi trong Môi trường Sản phẩm

Để xác định xem thay đổi được triển khai có hiệu qủa và đạt được kết qủa mong muốnkhông, cần phải kiểm soát những thay đổi trong môi trường sản phẩm Đối với thayđổi nhỏ, điều này có thể bao gồm việc kiểm tra chức năng mong muốn - thí dụ, đối vớithay đổi trong Chính sách Nhóm cho phép thay đổi thiết đặt máy desktop Đối vớinhững thay đổi lớn, nó có thể yêu cầu kiểm soát thông tin mạng và của máy phục vụ,dữ liệu hiệu năng, log sự kiện (nhật kí) hoặc thời gian đáp ứng

Tồn tại một số công cụ và công nghệ khác nhau để kiểm soát thay đổi trong môitrường sản phẩm Những công cụ này bao gồm (nhưng không chỉ giới hạn) MicrosoftOperations Manager (MOM), Windows Network Monitor, Replication Monitor vàPerformance Monitor Những công cụ thực tế này được dùng phụ thuộc vào bản chấtcủa thay đổi, những thành phần của hạ tầng cơ sở CNTT bị tác động, và kĩ năng cũngnhư kinh nghiệm của người thực hiện hoạt động kiểm soát

Tiến hành Duyệt Sau-Thực thi

Sau khi thông tin đầy đủ được thu thập từ việc kiểm soát để xác định hiệu qủa của thayđổi, duyệt sau thực thi được tiến hành Khoảng thời gian giữa thực thi thay đổi vàduyệt phụ thuộc vào kích cỡ của thay đổi được thực hiện và tác động của thay đổi cóthể được đo nhanh đến mức nào Thí dụ, một thay đổi có thể có tác động ngược lại, đođược, lên người dùng hoặc mạng, thí dụ như sư gia tăng lớn cuộc gọi của người dùng

Trang 40

xem có rút lui thay đổi hoặc làm những thay đổi khác để cố định tình huống không.Những thay đổi khác như tăng công suất mạng có thể yêu cầu một vài tuần để thu thậpđủ dữ liệu cho việc đo hiệu quả của thay đổi.

Dạng của duyệt sau-thực thi cũng phụ thuộc vào thay đổi đã được lập kế hoạch và tácđộng thực tế của thay đổi Một thay đổi chuẩn với ít tác động tổng thể có thể yêu cầuchỉ người quản lí thay đổi, người khởi xướng thay đổi và chủ nhân thay đổi có cuộchọp ngắn, có thể qua điện thoại hoặc NetMeeting, trong đó họ có thể nhất trí là thayđổi đã hoàn thành Ngược lại, thay đổi chủ yếu bao gồm triển khai vật lí của hệ điềuhành desktop mới sẽ có lẽ yêu cầu họp chính thức của một vài bên quan tâm để duyệtdữ liệu từ pha kiểm soát và so sánh tác động của thay đổi đối với những mục tiêu banđầu

Trong tất cả các trường hợp, người quản lí thay đổi lập lịch biểu và điều tiết họp duyệtvà người khởi xướng thay đổi phải thamn dự Trong quá trình duyệt, phải tham khảoRFC gốc, mà khai báo mục tiêu của thay đổi và, một cách lí tưởng, cung cấp một vàichỉ số đo được để đánh giá hiệu quả của thay đổi Tác động đo được của thay đổi cóthể được so sánh với tác động mong muốn để quyết định xem thay đổi có đạt đượcmục tiêu hay không

Cũng như làm một quyết định thành công/hỏng về thực thi thay đổi, duyệt thay đổicũng phải xem thay đổi đã được triển khai như thế nào và nó đã được thực thi đúngthời hạn và trong ngân sách Bài tập này phải tạo ra tài liệu về bài học rút ra được từthay đổi Phản hồi về duyệt sau đó được gửi cho tất cả các bên can dự trong thay đổiđể khuyến khích và cho phép những cải tiến qui trình tương lai

Phụ thuộc vào số thay đổi đang làm với, một vài thay đổi có thể được duyệt trong mộtphiên duyệt sau-thực thi Tuy nhiên, một vài thay đổi–do kích cỡ và độ phức tạp thấp–có thể được duyệt bởi một cá nhân

Đóng Thay đổi đạt Kết quả

Nếu cho rằng thay đổi đã đạt mục tiêu, bản ghi thay đổi được cập nhật và RFC đượcđóng

Rút lui Thay đổi

Nếu thay đổi không đạt mục tiêu, thì quyết định phải được thực hiện về bất kì cái gìđó Nếu thay đổi tác động lên người dùng hoặc các phần của hạ tầng cơ sở CNTT mộtcách bất lợi, một quyết định phải được thực hiện để rút lui thay đổi và loại bỏ nó khỏimôi trường sản phẩm

Trong trường hợp như vậy, những vấn đề được bao gồm trong việc chỉ đạo rút lui phảiđược đánh giá, gồm:

 Khối lượng về nỗ lực được yêu cầu để thực hiện rút lui.

 Hiệu quả nó có thể có trên cái khác (hoặc thay đổi đã lập kế hoạch,

hoặc đã sẵn sàng triển khai )

 Khả năng mà người dùng sẵn sàng sử dụng hệ thống đã thay đổi, mặc

dù không cho hiệu quả tốt nhất và loại bỏ một vài chức năng mà người dùng đã quen có thể tồi hơn là để chúng như vậy.

Ngày đăng: 13/01/2018, 17:39

TỪ KHÓA LIÊN QUAN

w