Quy trình quản lý thay đổi

PHỤ LỤC 05
QUY TRÌNH QUẢN LÝ THAY ĐỔI
I. Mục đích vi phạm vi áp dụng
1. Mục đích
Xây dựng một quy trình nguyên tắc cho việc hoạch định, phối hợp, triển khai và giám sát các thay đổi tác động
đến môi trường CNTT và đặt các thay đổi trong tầm kiểm soát.
Đảm bảo các phương pháp tiêu chuẩn dược sử dụng cho việc xử lý hiệu quả, kịp thời vá giảm thiểu tối đa tác
động bất lợi của bất kỳ sự cố nào phát sinh từ thay đổi tới chất lượng dịch vụ CNTT.
2. Phạm vi
Quy trình này áp dụng cho việc quản lý các thay đổi liên quan đến phát triển sản phẩm dịch vụ mới. Việc quản
lý những thay đổi khác được thực hiện theo các Hướng dẫn, Quy định có liên quan của Cơng ty ABC trong
từng thời kỷ.
II. Giải thích từ ngữ và chữ viểt tắt
Thuật ngữ

Ý nghĩa

Cấp
phê
duyệt
(Change Authority)

Là người được ủy quyển phê duyệt các thay đổi có mức ảnh hưởng được đề cập
phân loại trong mục V của Phụ lục Quy trình QLTĐ.

Đơn vị cấu hình (CI)

Đơn vị cấu hình xác định các thuộc tính cần phải có và các mối quan hệ của một
bản ghi cấu hình. Các loại cấu hình thơng thường bao gồm phần cứng, tài liệu,
thông tin người sử dụng,...

Để xuất thay đổi
(Change Proposal)

Tài liệu bao gồm các mô tả ở mức cao về khả năng giới thiệu hoặc thay dổi chính
với các dịch vụ, cùng với các kế hoạch kinh doanh tương ứng và lịch trình triển
khai dự kiến. Đề xuất thay đổi thường được tạo ra bởi quy trinh quản lý danh mục
dịch vụ và được chuyển cho quy trình quản lý thay đổi để phê duyệt. Quản lý thay
đổi sẽ xem xét đánh giá các ảnh hưởng có thể có trên các dịch vụ khác, nguồn lực
chia sẻ và lịch thay đổi tổng thể. Một khi đề xuất thay đổi được phê duyệt, quy
trình quản lý danh mục dịch vụ sẽ xác nhận dịch vụ đó.

CAB
(Change
Advisory Board - Ban
tham vấn thay đổi)

Ban tham vấn thay đổi là một nhóm các thành viên được thành lập từ nhiều phịng
ban khác nhau của Khối Công nghệ Thông tin hoặc của Cơng ty ABC có trách
nhiệm xem xét các mức độ rủi ro, tác động của các yêu cầu thay đổi đến các hoạt
động kinh doanh, nghiệp vụ, mức độ ưu tiên, phân tích hiệu quả chi phí và tác
động đến các hệ thống IT. CAB đưa ra các lưu ý nếu triển khai thay đổi, đưa ra
các phân tích chi tiết, các tìi hỗn hoặc huỷ bỏ RFC. Nhân sự tham gia trong các
cuộc họp có thể thay đổi tùy thuộc vào loại thay đổi.

Đánh giá thay đổi
(Change Evaluation)

Đánh giá chính thức về dịch vụ CNTT mới hoặc thay đổi các dịch vụ CNTT cũ để
đảm bảo rằng các rủi ro được quản lý và giúp cho việc xác định xem có nên phê
duyệt thay đổi hay khơng.

Quản lý thay đổi
(Change Management)

Kiểm sốt vịng đời của mọi thay đổi, cho phép các thay đổi có lợi được thực hiện,
đổng thời giảm thiểu tối đa gián đoạn dịch vụ CNTT.

Người quản lý thay đổi
(Change Manager)

Là người bảo đảm các thay đổi được kiểm soát theo đúng Quy trinh Quản lý thay
đổi, đảm bảo mọi thay đổi đều mang lại lợi ích, giảm thiểu tối đa sự gián đoạn
dịch vụ công nghệ thông tin.


Bộ phận thực hiện thay
đổi (Department to
make changes)

Là một/một số bộ phận chức năng trong một/một số phòng ban của Khối Cơng
nghệ Thơng tín hoặc kết hợp giữa nhiều phịng ban trong Cơng ty ABC có trách
nhiệm triển khai các yêu cầu thay đổi.

Phiên bản phát hành
(Release)

Một hoặc nhiều thay đổi đối với một dịch vụ CNTT được thiết lâp, thử nghiệm và
triền khai cùng nhau. Một phát hành đơn lẻ có thể bao gồm nhiều thay đổi với
phần cứng, phần mềm, tài liệu, các quy trình và thành phần khác nhau.

Bên thứ 3

Là các đối tác, nhà cung cấp dịch vụ của Khối CNTT và của Công ty ABC.

Sự cố (Incident)

Sự cố là các gián đoạn hoặc suy giảm chất lượng của dịch vụ CNTT không nằm
trong kế hoạch. Một cấu phần của hệ thống bị hỏng/ngừng hoạt động tuy nhiên
chưa ảnh hưởng trực tiểp đến dịch vụ CNTT cũng được coi là sự cố. Ví dụ: hỏng
một thành phẩn trong hệ thống dự phòng.

Sự cố nghiêm trọng
(Major Incident)

Là một sự cố có mức độ tác động cao và yêu cầu một sự phản ứng nhanh hơn hoặc
đặc biệt hơn các sự cố thông thường.

Vấn đề (Problem)

Là một nguyên nhân nào đó chưa chẩn đốn được có thể làm phát sinh một hoặc
nhiều sự cố.

Lỗi đã xác định được
(Known error)

Là một vấn đề đã tìm được nguyên nhân.

CCR (Change
Configuration
Release)

Là bộ phận Quản lý thay đổi thuộc Phỏng Vận hành Dịch vụ có chức năng xử lý
các yêu cầu thay đổi (RFC).

Họp CCR (CCR
Meeting)

Lả cuộc họp thảo luận diễn ra giữa bộ phận CCR vá các thành viên Ban tư vấn
thay đổi (CAB) nhằm mục đích đưa ra những đánh giá về mức độ tác động, rủi ro
của sự thay đổi và có kết luận đồng ý cho việc thực hiện thay đổi hay không?

Problem Owner

Problem Owner là trưởng bộ phận, phụ trách kỹ thuật thuộc Khối CNTT đang
quản lý vận hành những thành phần công nghệ, được ủy quyền để điều phối quá
trình xử lý vấn đề.

Service Owner

Là người chịu trách nhiệm cung cắp dịch vụ đúng thời gian theo SLA đã cam kết.

Danh bạ dịch vụ
(Service Catalog)

Là danh sách các dịch vụ công nghệ được công bố cho người sử dụng, khách hàng
với các chỉ tiêu chất lượng đã được quy định.

Thỏa thuận chất lượng
dịch vụ (Service Level
Agreement - SLA)

Là một cam kết giữa Khối Công nghệ Thông tin với một khối kinh doanh hoặc
khách hàng nào đó về các dịch vụ được cung cấp với các mức chất lượng đã được
thống nhất.

Thoả thuận chất lượng
nội bộ (Operating
Level Agreement OLA)

Là một cam kết giữa các phòng ban chức năng Khổi Cơng nghệ Thơng tin hoặc
với các phịng ban chức năng nào đó của Cơng ty trong q trình phối hợp nhằm
đảm bảo các chỉ tiêu chất lượng đã được công bố cho khách hàng.


Service Desk (SD)

Phòng Hỗ trợ Người sử dụng - Trung tâm Cung cấp Dịch vụ - Khối Công nghệ
Thông tin

Change Owner (CO)

Là người đưa ra yêu cầu thay đổi (RFC) theo Quy trình QLTĐ, sở hữu RFC và là
người lập kể hoạch chính cho RFC.

Application Owner

Là một người hoặc một nhóm có trách nhiệm đảm bảo các chương trinh, các thành
phần tạo nên ứng dụng hoạt động đúng yêu cầu đã đặt ra, bao gồm cả các yêu cầu
về bảo mật liên quan đến hoạt động thay đổi.

Người Đánh giá kỹ
thuật (Technical
Assessor)

Là thành viên trong ban CAB có trách nhiệm tham gia đánh giá chính thức về dịch
vụ CNTT mới hoặc thay đổi các dịch vụ CNTT cũ để đảm bảo rằng các rủi ro
được quản lý và cũng giúp cho việc xác định xem có nên phê duyệt thay đổi hay
khơng.
Người Đánh giá kỷ thuật cũng có thể đóng vai trò là người thực hiện thay đổi, đảm
bảo quá trình triển khai thay đổi theo đúng kế hoạch.

Người Triển khai thay
đơi (Change
Implemented

Là người trực tiếp có hành động tham gia thực hiện các thay đổi theo kế hoạch đã
định sẵn.

System Owner

Là một người hoặc một nhóm có trách nhiệm đảm bào các hệ thống (DC, DR,
Servers), các thảnh phần tạo nên hệ thống CNTT hoạt động dúng yêu cầu đã đặt
ra, bao gồm cả các yêu cầu về bảo mật liên quan đển hoạt động thay đổi

System

Là phòng Vận hành hệ thống, thuộc Trung tâm Cung cấp dịch vụ, Khối CNTT.

Network

Là bộ phận hạ tầng mạng thuộc phòng Vận hành mạng và viễn thông, thuộc Trung
tâm Cung cẩp dịch vụ, Khối CNTT.

Sercurity

Là phòng Bảo mật CNTT thuộc trung tâm Cung cấp dịch vụ, Khối CNTT

Cơ sở dữ liệu thay dồi
(Database Changed)

Cơ sở dữ liệu Thay đổi là một cơ sở dữ liệu lưu các thông tin liên quan về tồn bộ
các thay đổi. Tại Cơng ty ABC, cơ sở dữ liệu thay đổi được lưu trong Service
Desk Plus.

Test Plan

Kế hoạch kiểm tra (Test) được đưa ra bởi bộ phận Kiểm thử cho các yêu cầu thay
đổi.

SDP

Hệ thống Service Desk Plus

Phòng Quản lý nhu cầu
CNTT (IT Demand
Manager - ITDM)

Tiếp nhận, quản lý yêu cẩu CNTT của các Khối nghiệp vụ trong Cơng ty. Phân
tích định hình, đề xuất giải pháp công nghệ, lên kế hoạch đáp ứng yêu cầu phát
triển ứng dụng CNTT cho phân khúc khách hàng bán lẻ. Định hình danh mục dịch

vụ, SLA dịch vụ, quản lý danh mục yêu cầu và lịch chuyển giao sản phẩm dịch vụ
CNTT cho các khối nghiệp vụ trong Công ty.

QLTĐ

Quản lý thay đổi

Bộ phận triến khai

Bao gồm các Cán bộ nhân viên của Khối CNTT cỏ khả năng thực hiện thay đổi có thể nhiều Phịng ban của Khối CNTT tập hợp thành 1 Bộ phận triển khai hoặc
cũng có thể chỉ 1 Phòng, 1 Bộ phận.


Trách nhiệm của các đơn vị
Các Đơn vị dưới đây có trách nhiệm theo quy định tại “Quy trình Phát triển sản phẩm - Dịch vụ CNTT
và các trách nhiệm cụ thể trong Quy trình Quản lý sự thay đổi như sau:
1. Phịng Vận hành Dịch vụ (đóng vai trị CCR)
a) Vai trò
Đảm bảo sử dụng hiệu quả các phương pháp chuẩn được quy định tại Quy trình QLTĐ để quản lý
sự thay đổi và bảo đảm mọi sự thay đối trong hạ tầng CNTT được thực hiện theo đúng Quy trình
QLTĐ.
b) Trách nhiệm
- Giám sát thành cơng và chất lượng của quy trình quản lý thay đổi
- Đảm bảo rằng Quy trình quản lý thay đổi được tuân thủ chính xác.
- Đảm bào cho những cá nhân, Đơn vị có trách nhiệm trong Quy trình QLTĐ hiểu thực hiện đúng
theo Quy trình.
- Duy trì kế hoạch cải tiến liên tục cho quy trình quản lý thay đổi
- Xem xét đánh giá lại Quy trình QLTĐ với Lãnh đạo trong Khối Cơng nghệ Thơng tin.
- Giữ vai trị tăng cấp lên CAB (Ban tham vấn thay đổi) đối với những thay đổi có mức tác động
rùi ro lớn/nghiêm trọng đến hạ tầng công nghệ, kinh doanh của Công ty.

2. Change Owner
a) Vai trị
- Chịu trách nhiệm chính về tồn bộ thay đổi từ bắt đầu tới kết thúc của Quy trình QLTĐ
- Nắm rõ các yêu cầu của hoạt động và các kịch bản
- Là đầu mối cung cấp thông tin trong RFC
b) Trách nhiệm
- Lập phiếu yêu cầu thay đổi (RFC)
- Đưa ra tư vấn, lập kế hoạch, lập lịch thay đổi.
- Cung cấp các hiểu biết, thông tin về mục đích, rủi ro, ảnh hưởng của thay đổi.
- Cung cấp thông tin và các tài liệu cần thiết để đưa ra RFC.
- Xác định phân loại phù hợp
- Tham gia giám sát quá trình triển khai thay đổi.
3. Phòng Hỗ trợ người sử dụng (SD)
a) Vai trò
- Là đầu mối tiếp nhận tất cả các yêu cầu thay đổi (RFC) từ Change Owner
b) Trách nhiệm
- Chịu trách nhiệm tiếp nhận và kiểm tra tình trạng hồ sơ RFC
- Khởi tạo/cập nhập thông tin ban đầu của thay đổi lên hệ thống Servicedesk Plus (SDP)
- Tiếp nhận kết quả của việc triển khai thay đổi từ Bộ phận triển khai và Bộ phận Kiểm thử
- Đóng yêu cầu thay đổi.
III.

4. Người Đánh giá kỹ thuật (Technical Assessor)
a) Vai trò
- Cung cấp các kiến thức chuyên môn trong việc đánh giá ảnh hưởng của yêu cầu thay đổi.
b) Trách nhiệm
Đưa ra đánh giá về kỹ thuật cho RFC
Chấp nhận và chuẩn bị nguồn lực sẵn sàng tham gia thực hiện thay đổi đảm bảo thay đổi được
triển khai đúng kế hoạch
- Đảm bảo kết quả đánh giá được cập nhật vào bản ghi thay đổi.

- Đóng vai trị tăng cấp khi triển khai thay đổi gặp vấn đề liên quan kỹ thuật
Ban tham vấn thay đỏi (Change Advisory Board - CAB)
-

5.


a) Vai trò
- Phê duyệt thay đổi và chấp nhận nguồn lực cần thiết để thực hiện thay đổi.
b) Trách nhiệm
- Xem bản báo cáo định kỳ thay đổi theo tuần/tháng/quý.
- Xác nhận các hoạt động cần thiết cho thay đổi
- Đưa ra mọi vấn đề ảnh hưởng tới hoạt động cùa các ứng dụng dịch vụ trong hạ tầng CNTT.
- Xác nhận các biện pháp truyền thông phù hợp
- Phê duyệt/từ chối thay đổi.
6. Người Triền khai thay đổi (Change Implemented)
a) Vai trị
- Cung cấp chun mơn kỹ thuật để triển khai thay đổi.
b) Trách nhiệm
- Nhận nhiệm vụ và chuẩn bị thay đổi, xác nhận việc có thể triển khai theo kế hoạch.
- Xem và chấp nhận kế hoạch triển khai.
- Xác nhận sẵn sàng vào thời gian dự kiến triển khai trong RFC
- Triển khai đúng thời gian và hiệu quả
- Thực hỉện q trình khơi phục với các thay đổi gặp sự cố/không thành công.
- Cập nhật RFC với trạng thái thành công /không thành công.
7. Phòng Kiểm thử Giải pháp
a) Vai trò
- Sử dụng chuyên môn kỹ thuật để tiến hành kiểm tra trước và sau thay đổi (tùy theo từng loại thay
đổi).
b) Trách nhiệm

- Chấp nhận nhiệm vụ và chuẩn bị cho RFC bằng cách xác nhận có thể kiểm thử theo kế hoạch
- Kiểm tra thay đổi với test plan đã lập
- Thông báo kết quả test sau thay đổi đến tất cả các thành viên (VHDV, CAB, SD,…)
8. Ma trận RACI

A/R
A/R
R

C
C
I
A
I
I
I
I
I
A/R

R

I
I
I

I

I

I

I

C
C
I

C

Triển khai thay
đổi

I

C

C
C

C
C

C
C

R
I
I
I

I
I
I
I

I
I
A/R

I
I
I
A/R

A
I

A/R
I
A/R
I

C
A/R
1
1

I
I
I

C

I

I

CAB

R

Vận hành dịch
vụ

Quản lý thực hiệu quy trình thay đối

A/R

Kiễm thử

Đánh gỉá tác động
Lập kế hoạch thay đổi
Trinh CAB phê duyệt
Xem lại yêu cầu không được phê duyệt
Triển khai thay đỏi
Tester
Khôi phục thay đối
Thông báo kết quả
Cập nhập nhật ký thay đối
Đóng thay đổi

Đánh giá kỹ
thuật

Kiểm tra và nhập thơng tin vào trong SDP

Bộ phận tiếp
nhận (SD)

Hoạt động

Người yêu
cầu (change
owner)

Vai trò

C

A/R


IV.
STT

Bảng phân loại RFC và cam kết SLAs nội bộ trong khối CNTT
LOẠI DỊCH VỤ THAY
ĐỔI

THÀNH PHẦN BAN CAB

OWNER

YÊU CẦU TÀI SẢN SLA (CCR phản hồi từ khi nhận được
RFC)
ĐÍNH KÈM

1. Giám đốc TTXDGP

1

Các thay đổi liên quan
đến ứng dụng: T24,
Way4, Ebank,...
- Sàn phẩm mới
- Cải tiến/sửa đổi sản
phẩm ứng dụng

2. Giám đốc CCDV
Tối thiểu:

3. TP. Hỗ trợ Người sử dụng - TT CCDV.
4. TP. Vận hành hệ thổng - TT CCDV
5. TP. Kiểm thử Giải pháp

TP ứng dụng
Công ty

Quy định tại Mục VI

6. Các Trưởng phịng có liên quan của
TTXDGP
7. Mội sổ thành viên liên quan.

- 2-3 ngày với thay đổi đơn giản
- 3-5 ngày với thay đổi phức tạp
- 5-7 ngày với thay đổi rất phức tạp

1. TP Vận hành Mạng và Viễn
thông-TTCCDV

2

Thay đổi liên quan đến hạ
tầng Nelwork/Firewall

2. Kiến trúc sư network – P. Kiến trúc và
giải pháp - TTXDGP
3. TP Bảo mật CNTT-TTCCDV
4. TP. Vận hành Hệ thống (Tùy chọn)
5.
GĐ TT XDGP/Trưởng phòng/Trưởng
bộ phận thuộc TT XDGP (Tùy chọn)
6. Mội số thành viên liên quan.

Tối thiểu:
TP Vận hành
Mạng
và
Viễn thông

Quy định tại Mục VI

- 2-3 ngày với thay đổi đơn giản
- 3-5 ngày với thay đổi phức tạp
- 5-7 ngày với thay đối rất phức tạp


STT

3

4

LOẠI DỊCH VỤ THAY
ĐÒI

Thay đổi liên quan đến
Hệ thống máy chủ bao
gồm: sửa chữa/nâng
cấp/thay thế các thiết ị
máy chủ, SAN, máy chủ
DB,...

Thay đổi liên quan đến
swich site giữa DC và DR

THÀNH PHẦN BAN CAB

1.

TP Vận hành Hệ thống - TTCCDV

2.

Trưởng bộ phận thuộc P. Vận hành
ứng dụng và Middleware

3.
4.

GĐ TT XDGP/Trưởng phòng/Trưởng
bộ phận thuộc TT XDGP (Tùy chọn)
TP.Bảo mật CNTT (Tùy chọn)

5.

Mội số thành viên liên quan.

1.

TP Vận hành Hệ thống

2.

Trưởng bộ phận thuộc P. Vận hành
ứng dụng và Middleware

3.
4.

GĐ TT XDGP/Trưởng phòng/Trưởng
bộ phận thuộc TT XDGP (Tùy chọn)
TP.Bảo mật CNTT (Tùy chọn)

5.

Mội số thành viên liên quan.

OWNER

YÊU CẦU TÀI LIỆU SLA (CCR phản hồi từ khi nhận được
RFC)
ĐÍNH KÈM

Tối thiểu:
TP.VHHT

Quy định tại Mục VI

- 2-3 ngày với thay đổi đơn giản
- 3-5 ngày với thay đổi phức tạp
- 5-7 ngày với thay đổi rất phức tạp

Tổi thiếu:
TP.VHHT

Quy định tại Mục VI

- 2-3 ngảy với thay đổi đơn giản

- 3-5 ngày với thay đổi phức tạp
- 5-7 ngảy với thay đổi rất phức tạp


STT

5

LOẠI DỊCH VỤ THAY
ĐỔI

Thay đổi liên quan đến
Bảo mật: Thay dổi chính
sách/mật khầu/nâng cấp
thay thế...

Thay đổi liên quan đến
dich vụ Domain/
Website:
6

Trang web chủ Công ty
ABC
-

Eoflice
Webmail
Web nội bộ
LDAP

THÀNH PHẦN BAN CAB

1.

TP.Bảo mật CNTT thuộc TTCCDV

2.

Phịng Vận hành Mạng và Viễn thơng

3.

TP.VHHT

4.

GĐ TT XDGP/Trưởng phòng/Truởng
bộ phận thuộc TT XDGP (Tùy chọn)

5.

Mội số thành viên liên quan.

1.

TP. Vận hành Mạng và Viễn thông
thuộc TTCCDV

2.

TP. Bảo mật

3.

GĐ TT XDGP/Trưởng phòng/Trưởng
bộ phận thuộc TT XDGP (Tùy chọn)

4.

TP Hỗ trợ Nguời sử dụng - TT VHDV

5.

Mội số thành viên liên quan.

OWNER

YÊU CẦU TÀI
LIỆU ĐÍNH KÈM

SLA (CCR phản hồi từ khi nhận
được RFC)

Tối thiểu:
TP Bảo mật
CNTT

Quy định tại Mục VI

- 2-3 ngày với thay đổi đơn giản

- 3-5 ngày với thay đổi phức tạp
- 5-7 ngày với thay đổi rất phức tạp

Tối thiểu:
TP Vận hành
Mạng và
Viễn thông

Quy định tại Mục VI

- 2-3 ngày với thay đổi đơn giản
- 3-5 ngày với thay đổi phức tạp
- 5-7 ngày với thay đổi rất phức tạp


STT

LOẠI DỊCH VỤ THAY
ĐỔI

THÀNH PHẦN BAN CAB

YÊU CẦU TÀI
LIỆU ĐÍNH KÈM

OWNER

Thay đổi liên quan việc
nâng cấp version phần
mềm/ứng dụng:

8

- Core T24
- Way4
- Citad
- VCB
- Thay đổi quan trọng
khác.

SLA (CCR phản hồi từ khi nhận
được RFC)

Tổi thiểu:
Các Giám đốc/Trưởng phòng/Trưởng bộ
phận và các thảnh viên liên quan của Khối
CNTT

Ban CAB

Quy định tại Mục VI

- 2-3 ngày vởi thay đổi đơn giản
- 3-5 ngày với thay đổi phức tạp
- 5-7 ngày với thay đổi rất phức tạp

V. Phân loại mức độ ưu tiên và cấp phê duyệt
\

STT

PHÂN

MƠ TẢ TÌNH HUỐNG

LOẠI
1.

1

Rất khẩn
cấp

Là những thay đổi ngay lập tức để khắc phục sự cổ xảy ra trên diện rộng
toản khu vực, toàn hàng như gián đoạn giao dịch, khắc phục sự cố, phục
hồi dữ liệu

2.

Lả những thay đổi do yêu cầu cấp thiết phục vụ kiểm tra kiểm toán, được
ban lãnh dạo phê duyệt

3.

Là những thay đổi để khoanh vùng, cô lập sự cố, tấn công bảo mật...

CẤP PHÊ DUYỆT
(Change Authority)

Lãnh đạo Khối

GHI CHÚ

Trong trường hợp tối khẩn, yêu
cầu thay đổi có thề thảo luận trực
tiếp với các cấp và tìển hành, sau
đó hồn thành hồ sơ


1.
2.
2

Khẩn cấp
3.
4.
5.

1.
3

Trung bỉnh
2.

4

V.

Thấp

Là những thay đổi để khắc phục những sự cố tỉềm ẩn có thể xảy ra, nhung

chưa gây gián đoạn hệ thống tại thời điểm hiện tại
Những thay đổi để khắc phục các sự cố xảy ra cục bộ, phạm vi ảnh hưởng
nhỏ
Lả các thay đổi cho các hạng mục có mức độ ưu tiên cao, đến hạn thực
hiện
Tích hợp các chương trình mới vào hệ thống...
Những thay đổi định kỳ cần thực hiện

Là những thay đổi mà tác động không trực tiếp gây ảnh hưởng đến các các
đơn vị kinh doanh/tài chính, và cũng ít gây ảnh hưởng tiềm ẩn khi thay
đổi.

GĐ TTCCDV

Được ưu tiên cho việc hồn thành
thủ tục thay đổi theo quy trình

Change Manager (CM)

Đơn vị thay đổi có thể thảo luận
với các phịng ban liên quan và tự
chủ thực hiện theo quy ưỉnh

Change Manager (CM)

Cả nhân có trình thay đổi theo
phê duyệt của trưởng đơn vị mình

Là những thay đổi chỉ tác động đén cả nhãn.

Là những thay đổi mang tính cục bộ, thay đổi không gây ảnh hưởng, rủi ro đến
hệ thống.

Danh mục tài liệu


STT

Loại tài liệu

Yêu cầu về nội dung
Hoàn thành nội dung yêu cầu theo mẫu

Mục đích

Các đơn vị thẩm định

1

Phiếu yêu cầu thay đổi (Bắt buộc)

Căn cứ đề xác nhận yêu cầu SD/CCR

2

Các Quyết định/Quy định/Tờ trình liên quan đã
được phê duyệt (Bắt buộc với mọi thay đổi liên quan
đển dự án, các đề xuất cải tiến và các nhu câu thay đổi Là quyết định của các cấp có thẩm quyền
liên quan đến CNTT xuất phát từ người sử
dụng/nghiệp vụ)

3

Tài liệu đặc tả sản phẩm (Tùy theo sán phẩm mua
ngoài hay do Cơng ty ABC phát triển)

Phân tích đặc tả sản phẩm, được thiết kế ra sao...
(BRD: tài liệu do Đơn vị nghiệp vụ viết. SRS: tải
liệu do BA cúa Khối CNTT viết)

4

Sơ đồ thiết kế về System/Network/Sercurity
(Tùy theo là thay đổi có liên quan đến phạm vi
Network/securrities hay khơng)

Mơ tả kết nối vật lý, logic, các thông tin hệ thống Cơ sở pháp lý trình duyệt
(đặt ở đâu, cấu hình, lớp mạng nào, firewall nào...) golive

System/Network/Sercurit
y

5

Các biên bản test về chức năng nghiệp vụ (Yêu
cầu bắt buộc)

Biên bản test chức năng nghiệp vụ để làm căn cứ
pháp lý và hệ thống sản phẩm đã triển khai đáp
ứng yêu cầu của các khối, ban nghiệp vụ

Cơ sở pháp lý trình duyệt
golive

Các Khối/Trung
tâm/Phòng ban nghiệp vụ

6

Biên bản test về hiệu năng (Tùy thuộc loại thay đổi)

Để đánh giá được hệ thống khi triển khai có mức
chịu tải ra sao, đáp ứng được bao lâu...

Cơ sở pháp lý trình duyệt
golive

Admin system

7

Biên bản test bảo mật (Tùy thuộc loại thay đổi)

Để chứng minh được hệ thống sao khi triển khai là Cơ sở pháp lý trình duyệt
đảm bảo tính bảo mật
golive

Bộ phận bảo mật

8

Tải liệu về phân quyền quản trị nội dung, phân
quyền truy cập (Tùy loại thay đổi)

Tài liệu mô tả về phân quyển chức năng, phân
quyền truy cập (ai được phần quyền gì)

Admin liên quan sẽ thẩm
định tài liệu.

Cơ sở pháp lý trình duyệt
golive

Change
Owner/Requester

Cơ sở pháp lý trình duyệt
golive

Kiến trúc ứng dụng,
nghiệp vụ

Các bộ phận quản trị chức
năng


9

Tài liệu quàn trị vận hành
(Tùy loại yêu cầu thay đổi)

Tài liệu mô tả được cách thức vận hành, quản trị
hệ thống hàng ngày sau khi đưa vào vận hành
chính thức, như backup/recovery...

Phục vụ quản trị vận hành hệ Admin liên quan sẽ
thẩm định tải liệu.
thống

10

Tài liệu hướng dẫn sử dụng (Tùy loại thay đổi)

Mô tả các sử dụng sản phẩm, hệ thổng

Phục vụ Bộ phận vận hành
dịch vụ, hỗ trợ người dùng

11

Bảng services Catalog (Tùy loại thay đổi)

Nêu rõ các hạng mục services được đưa vào hoạt Phục vụ SD phân loại, hỗ trợ,
SD
động
cam kết thời gian hỗ trợ

12

Bảng theo dõi kế hoạch và Nhật ký thay đổi.

(yêu câu bảt buộc)

Mô tả tổng quan về kế hoạch, nguổn lực, thời gian
dự kiến thực hiện các hạng mục của một quá trình
thay đổi từ lúc bắt đầu nhận được yêu cầu/đề xuất
Đề có bức tranh tổng thể khi
quyết định/... cho đến khi các yêu cầu thay đổi
phê duyệt thay đổi
được đáp ứng và chi tiết từng bước mà bộ phận
triền khai thay đổi thực hiện trong thời gian trực
tiếp tác động lên hệ thống cho việc thay dối.

Change owner

13

Các tài liệu khác theo yêu cầu của các bộ phận
dự án (tùy yêu cầu cùa dự án)

Theo yêu cầu đặc thù

Theo yêu cầu thực tế

Theo yêu cầu đặc thù

Admin, vận hành dịch
vụ

VII. Quy trình thực hiện
1. Thơng số tổng hợp:

Thơng số

Mơ tả

Yêu cầu

Đầu vào

Yêu cầu thay đổi.

Các yếu tố đầu vào phải có điều kiện/yêu cầu phát triền thành một yêu cầu thay đổi, có thể tác động hoặc rủi ro
đến các dịch vụ công nghệ đang cung cấp.

Đầu ra

Yêu cầu được đóng

Thay đối được triển khai và cập nhật thơng tin.

2. Lưu đồ:



3.

Diễn giải thực hiện
Bước

Mô tả công việc

Trách nhiệm
thực hiện

Sản phấm/Mẫu biểu/ Tàí
liệu tham chiếu

1. Đánh giá sơ bộ
yêu cầu (KS01)

- Người sử dụng sản phấm/dịch vụ gửi (qua email/Scan/fax) Phiêu yêu cầu dịch vụ,
Phiếu đề xuất cải tiến, Quyết định dự án, Báo cáo sự cố/vấn đề phát sinh sự thay đổi
đến/hoặc làm việc trực tiếp vứi ITDM để làm rõ nhu cầu thay đổi là: yêu cầu thêm mới,
thay đối tính năng, hoạt động của hạ tầng, dịch vụ.
- Khi IT Demand đã làm rõ được yêu cầu thay đổi từ Người sử dụng, IT Demand sẽ
chuyền yâu cầu này đến phòng ban/admin liên quan đến sự thay đổi để phân tích, lập Change Owner
yêu cầu thay đổi - khi đó các phịng ban/admin liên quan sẽ đóng vai trò là Change IT Demand
Owner.
- Change Owner khi nhận được yêu cầu thay đổi từ IT Demand cần thực hiện thay đổi.
Các thông tin này sẽ được sử dụng để lập Phiếu yêu cầu thay đổi nhăm phục vụ việc phân
tích, đánh giá sơ bộ các tác động, rủi ro (dưới góc nhìn cùa Admin triển khai thay đổi)
khi thực hiện thay đổi (RFC).

MB-YCDV/01 .KCNTT:
Phiếu yêu cầu dịch vụ từ
người sử dụng
- MB01 .QT-QLCL/02:
Phiếu đề xuất cải tiến
- Quyết định dự án
- Báo cáo sự cố/vấn đề phát
sinh thay đổi.

- MB0I.PL05.QTCNTT/03: Phiểu yêu cầu
thay đổi

2. Lập Phiến yêu
cầu thay đổi

- Lập Phiêu yêu cầu thay đổi (RFC), trình phê duyệt qua Giám đốc TT/Truởng phịng của
Đơn vị mình hoặc Quản lý dự án và chuyển Phiếu yêu cầu thay đổi được duyệt và các
Change Owner
hồ sơ liên quan tới Phòng SD tiếp nhận.
- Phiếu yêu cầu cần có đủ các thông tin về người yêu cầu, thời gian, lý do thay dổi, đánh
giá sơ bộ về rủi ro, ... Danh mục hồ sơ được quy định tại Mục VI Phụ lục này.

MB01.PL05.QT-CNTT/03:
Phiếu yêu cầu thay đổi Các
tài liệu liên quan RFC

3. Kiểm tra RFC
(KS02)

Phịng SD tiếp nhận, kiểm tra tình trạng hồ sơ RFC.
Các nội dung cần kiểm tra như sau:
+ Số hiệu của RFC - Change Owner sẽ lấy số hiệu của RFC từ Phòng Quàn trị Dịch vụ trước
khi chuyển Phịng SD.
+ Phạm vi và mục đích của RFC

MB01.PL05.QT- CNTT/03:
Phiếu yêu cầu thay đổi
(RFC)
- Các tài liệu liên quan

RFC. Gọi tắt Hồ sơ RFC.

Phòng Hỗ trợ
người sử dụng
(SD).


Bước

Mô tả công việc

Trách nhiệm

Sản phẩm/Mẫu biểu/Tài liệu
tham chiếu

+ Số hiệu của vấn đề/ lỗi đã biết liên quan
+ Mô tả các đơn vị cấu hình (cũ/mới) liên quan
+ Lý do của thay đổi bao gồm các thông tin chứng minh về sự cần thiết/bắt buộc
cho việc thay đổi (như theo Quyết định của TGĐ về triển khai sản phẩm mới;
Yêu cầu từ nghiệp vụ liên quan đến hạ tầng ứng dụng CNTT,...) và các lợi ích
mang lại cho hoạt động thay đổi đó.
+ Phiên bản hiện tại và phiên bản mới của CI sẽ bị thay đổi (nếu có)
+ Tên, Vị trí, số điện thoại của người gửi yêu cầu RFC + Thời gian yêu cầu
+ Tài nguyên cần sử dụng và thời gian triển khai (dự kiến)
+ Danh mục thực hiện
+ Các tài liệu liên quan đến RFC.
- Hồ sơ đạt yêu cầu sê dược cập nhật vào SDP (Bước 4) và chuyển tiếp tới Bộ
phận CCR.
- Hổ sơ không đạt yêu cầu được chuyển lại cho Change Owner xem xét lại

(Bước 2)
4. Cập nhật thông tin trên
SDP
5. Đánh giá lại RFC

.

SD thực hiện cập nhập các thông tin RFC lên hệ thống Servicedesk Plus (SDP)
và chuyển cho Trưởng phỏng SD ký xác nhận trước khi chuyển đến Phòng Vận
hành Dịch vụ (CCR) tiếp nhận xử lý.

Phòng Hỗ trợ
người sử dựng
(SD).

Nội dung thông tin được mô
tả trong RFC.

- Xác định độ ưu tiên và phân loại thay đổi
CCR xem xét sự phù hợp cùa RFC, phân loại và xác định mức độ ưu tiên của
RFC. Việc này sẽ dựa vào mức độ ảnh hưởng và mức độ khẩn cấp của yêu cầu
thay đổi. Ví dụ, các yêu cầu thay đổi dựa vào múc độ ảnh hưởng của vấn đề và
sự khẩn cấp của giải pháp: Rất khẩn cấp, Khẩn cấp, Trung bình, Thấp. Tham
khảo bảng “Các mức độ ưu tiên và cấp phê duyệt” Mục V Phụ lục này để phân
loại.

Phòng Vận hành
dịch vụ (CCR)

Hồ sơ RFC

Bước

Mô tả cổng việc
Đánh giá tác động
CCR thực hiện đánh giá lại RFC. Với các ảnh hưởng, tác động chưa được đánh
giá, hoặc chưa đánh giá đầy đủ, CCR yêu cầu bộ phận chuyên môn tương ứng
thực hiện đánh giá lại.
Bộ phận chuyên môn chịu trách nhiệm chỉnh trong đánh giá cho từng loại thay đổi
được quy định trong “Bảng phân loại RFC và cam kết SLAs” tại Mục Phụ lục nảy.
Một số yếu tố cần cân nhắc khi đánh giá thay đổi:
Đảm bảo nguồn lực:
CCR cần đảm bảo cống tác chuẩn bị và triển khai thay đổi không xung đột vớí các
thay đổi khác. Nếu có xung đột, cần yêu cầu Change Owner xem xét lại thời gian
thực hiện hoặc từ chổi với các RFC có mức độ ảnh hưởng khơng cao (Trung bình
- Thấp).
Nguồn lực tham gia thay đổi cần đảm bảo không gây ảnh hưởng/gián đoạn
lớn/kéo dài tới các hoạt dộng dịch vụ quan trọng của Công ty.
Quản lý xung đột: Ngoài việc đàm bảo nguồn lực, cần chú ý tới các xung
đột về kỹ thuật có thể xảy ra như: Các thiết bi (phần cứng) thay thế khơng tương
thích dẫn đến việc hệ thống hoạt dộng không ổn định; Các phiên bản phần mềm
không phủ hợp với hệ điều hành đang dùng;...
Phối hợp: Đảm bảo toàn bộ các Đơn vị phối hợp tốt trong suốt quá trình
diễn ra thay đổi
Tham gia của bên thứ 3 “ Một số thay đổi cần dịch vụ và hỗ trợ từ bên thứ
3, khi đó sẽ cần phối hợp từ xa, khác múi giờ, địa lý...
Truyền thông nội bộ / bên ngồi - Một số thay đổi phức tạp, có thể ảnh
hưởng tới dịch vụ cung cấp ra bân ngoài. Với các thay đổi này, cần có test nghiệp
vụ và test kỹ thuật đảm bảo thành công. Các bộ phận như SD cần

Trách nhiệm

Sản phẩm/Mẫu biểu/Tài liệu
tham chiếu


Bước

Mô tả cổng việc

Trách nhiệm

Sản phẩm/Mẫu biểu/Tài liệu
tham chiếu

được thông báo về thay đổi để có thể thơng báo tới người dùng tốt hơn. Quản lý
rủi ro — Mỗi thay đổi đã có kế hoạch cần được đánh giá rủi ro một cách toàn diện
và thấu đáo, từ mặt tổ chức, chiến lược tầm cao đán yếu tố chi tiết, kỹ thuật. Cần
đảm bảo tồn bộ thơng tin phù hợp đã có trong u cầu thay đổi và q trình thay
đổi diễn ra theo đúng quy trình.

6. Họp CCR (KS03)

Sau khi phân loại được RFC, Phòng Vận hành Dịch vụ sẽ làm việc trực tiếp hoặc
tổ chức họp CCR với tất cả các nhóm/cá nhân kỹ thuật/chuyên gia liên quan để
cùng phân tích, đánh giá RFC: các thơng tin chưa rõ ràng? Không hợp logic?
Không khả thi? Mức độ tác động và rủi ro?
+ Tùy thuộc vào loại thay đổi, các thành viên tham gia họp sẽ đánh giá thay
đổi.

+ Các thành viên tham gia họp đánh giá sẽ đồng ý hoặc không đồng ý RFC và
ký xác nhận biên bản họp CCR.
Nội dung đánh giá bao gồm:
+ Đánh giá tổng quan và cập nhật vào bản ghi RFC theo quan điểm của người
đánh gỉá
+ Kiểm tra các thông tin đính kèm liên quan đã đầy đủ (từ quan điểm kỹ thuật).
+ Kiểm tra các kịch bản đã được cung cẩp đảm bảo chính xác và khơng chứa
các hoạt động không phủ hợp
+ Kiểm tra các hệ (hống liên quan bị ảnh hưởng trực tiếp đến việc thay đổi đã
được liệt kê đầy đủ trong RFC như: Servers, DataBase, SAN,...
+ Kiểm tra các xác nhận về thời gian, ảnh hưởng đã đầy đủ mọi tinh huống,
làm cơ sở đưa ra quyết dịnh.
+ Kiểm tra nếu có dịch vụ bị ảnh hưởng cần đảm bảo người liên quan được biết
và chấp nhận các rủi ro liên quan

Phòng Vận hành
dịch vụ CAB

Hồ sơ RFC


Bước

Mô tả công việc
+ Sửa đổi các nội dung trong u cầu đảm bảo khơng cịn các điếm khả nghỉ có
thể ngăn chặn q trình triển khai hoặc làm việc triển khai diễn ra khơng chính
xác.
Kiểm tra thơng tin bộ phận kỹ thuật và các bộ phận liên quan cần chú ý khi lập
kế hoạch thay đổi:
o Năng lực, tải của dịch vụ sẽ bị ảnh hưởng

o Độ tin cậy và khả năng khôi phục
o Các kế hoạch khôi phục
o An toàn bảo mật
o Ảnh hưởng của thay đồi lên các dịch vụ khác.
o Các tài nguyên cần thiết và chi phí (hỗ trợ, bảo trì)
o Số lượng cần thiểt, số lượng sẵn có các chuyên viên
o Các tài nguyên mới cần mua sắm và kiểm thử
o Ảnh hưởng tới hoạt động
o Xung đột tới các thay đổi khác
Phụ trách kỹ thuật cần có trách nhiệm sáp xếp kế hoạch để tránh các xung đột
về thời gian.
Vai trò của các thành viên được quy dịnh cụ thể tại “mục III. Vai trò và trỉch
nhiệm của các đơn vị”.
Căn cứ kết quả cuộc họp:
+ Nếu CCR và CAB không thống nhất nội dung thay đổi do các thông tin/đánh
giá tác động/tài liệu cịn thiếu/...thì sẽ trả lại RFC cho Change owner xem xét
lại RFC (bước 7)
+ Nếu CCR và CAB thống nhất đồng ý thực hiện thay đổi, căn cứ biên bản họp
(có xác nhận cùa cảc Thành viên họp CCR) đính kèm hồ sơ đầy đủ của RFC
trình cán bộ CAB được ủy quyền phê duyệt (bước 8)

Trách nhiệm

Sản phẩm/Mẫu biểu/Tài liệu
tham chiếu


Bước

Mô tả công việc

7. Xem xét “Yêu cầu thay
đổi” (KS04)

8. Trinh phê duyệt triển
khai thay đổi

Change Owner sau khi nhận lại RFC CCR, CAB cần thực hiện xem xét lại
RFC: Đánh giá lại tính hợp lý, cần thiết của thay đổi và bổ sung thông
tin/chứng cứ nếu cần thiết
Dựa trên những thông tin đã cập nhật, đánh giá lại, Change Owner quyết dịnh
có đóng RFC hay khơng:
- Nếu quyết định đóng u cầu: Thực hiện bước 16, Nếu khơng đóng yêu cầu:
Thực hiện bước 1
- Căn cứ thông tin trong RFC và bien bản nội dung họp CCR đa được thống
nhất, CCR sẽ trình hồ sơ RFC lên BLĐ/cán bộ CAB được ủy quyền để phê
duyệt hoặc từ chối triền khai thay đổi.
- Truờng hợp BLĐ/Cán bộ CAB được ủy quyền có tham gia họp CCR đánh giá
cho thay đổi thì việc trình ký duyệt hồ sơ RFC chỉ mang tinh chất ký thủ tục vì
các nội dung đã được thống nhất trong cuộc họp CCR.
BLD/Cán bộ CAB được ủy quyền chấp nhận phê duyệt thay đổi. Bộ phận triển
khai thực hiện theo kế hoạch thay đổi (bước 10). Các thay đổi bị từ chối, CCR
chuyền lại RFC cho Change Owner xem xét (bước 7).

9. Phê duyệt (KSA5)

10. Triền khai thay đổi
-

Trách nhiệm

Sản phẩm/Mẫu biểu/Tài liệu
tham chiếu

Change Owner

Thông tin chỉnh sửa, yêu cầu từ
SD, VHDV hoặc CAB.

Phòng Vận hành
dịch vụ

“ Hồ sơ RFC - Biên bản họp
CCR

BLĐ/Cánbộ
CAB được ủy
quyền.

Bộ phận triển khai sẽ đảm bảo các bước chuẩn bị đã hoàn thành theo đúng kế
hoạch thay đổi. Bao gồm cả việc đảm bảo các thành viên tham gia (Khối Công
nghệ Thông tin và đối tác) triển khai và kiểm thử đã hiểu rõ vai trò trong thay
đổi và sẵn sàng tham gia vào thời gian đã định.
Bộ phận triến khai
Quá trinh triển khai thường bao gồm các hoạt động sau:
+ Kiểm tra các bản ghi thông tin đã đầy dù và khơng có thay đổi ngồi mong
đợi vào phút cuối -> Kiểm tra thay đổi đã được phê duyệt -> Kiểm tra tất cả các
UAT test liên quan đã hoàn thành thành công

Hồ sơ RFC dược phê duyệt.

Danh mục công việc thực hiện.
- MB02.PL05.QT- CNTT/03
Bảng theo dõi Kế hoạch &
Nhật ký thay đổi


Bước

Mô tả công việc

Trách nhiệm

Sản phẩm/Mẫu biểu/Tài liệu
tham chiếu

+ Kiếm tra kê hoạch và các hệ thống liên quan đang ở trạng thái mong muốn.
+ Kiểm tra môi trường làm việc.
+ Triển khai thay đổi theo bảng kể hoạch đã định.
+ Triển khai test plan, làm việc với tester nếu cần.
+ Lưu trữ log hoặc các bản ghi khác của quá trình triển khai.
+ Cập nhật bản ghi thay đổi. (Trên SDP, Nhật ký thay đổi,...) để Phịng SD có căn
cứ đóng yêu cầu khi kết thúc.

11. Kiểm tra kết quả
(KS06)

Bộ phận Kiểm thử (Test) tiến hành thực hiện kiếm tra tại xem một đơn vị cấu
hình, dịch vụ CNTT, quy trình,.V..V.. có thỏa mãn các đặc tả u cầu cùa sự thay
đơei. Nói cách khác lá Tester bắt đầu kiểm tra theo đúng test plan định sẵn trong
yêu cầu thay đổi.

Nếu test không thành công, thực hiện khôi phục trạng thái trước thay đổi (bước
12). Nếu test thành công, thông báo kết quả thay đổi (bước 13).

Bộ phận kiểm
thử (Test)

12. Khơi phục trạng thái
trước thay đổi
(Rollback)

Nếu q trình triền khai thay đổi không thành công, bộ phận triến khai cần khởi
động q trình khơi phục theo kế hoạch đã có trong RFC.
Q trình này cần bao gồm các hoạt động:
• Khơi phục các thay đổi nếu triển khai khơng thành cơng
• Làm việc cùng bộ phận test để đảm bảo tồn bộ mơi trường đã được quay lại
trạng thái trước đó thành cơng.
Bộ phận triển khai cần thực hiện theo đúng phạm vi thay đổi và cần báo cáo cấp
cao hơn mọi phát sinh không mong đợi trong quá trình triển khai (với thay đổi
khẩn). Cụ thể:
• Bộ phận triển khai hoặc bộ phận Kiểm thử liên lạc với Change Owner. Nếu
không liên lạc được cần liên lạc với Change Manager để thơng báo về tình
huống và lấy đồng ý về việc liệu có thêm các hành động cần thực hiện bổ sung
nằm ngồi kế hoạch “khơi phục”

Bộ phận triển
khai

- MB02.PL05.QT-CNTT/03
Bảng theo dõi Kế hoạch &
Nhật ký thay đổi MB03

.PL05.QT-CNTT/03
Biên bản test xác nhận sau
thay đổi.

MB02.PL05.QT-CNTT/03
Bâng theo dõi Kế hoạch &
Nhật ký thay đổi


Bước

Mơ tả cơng việc

Trách nhiệm

• Nếu có dịch vụ bị ảnh hưởng do việc triển khai thay đổi thất bại:
+ Liên lạc với các bộ phận hỗ trợ nghiệp vụ, bộ phận vận hành (IT SD, IT Khu
vực,...)
+ Khởi dộng theo Quy trình quản lý sự cố được sử dụng trong nội bộ Khối CNTT.
Sau khi thực hiện khôi phục trạng thái truớc thay đổi cần kiểm tra lại kết quả theo
bước 11.

13. Thông báo kết quả
thay đổi

Bộ phận Kiểm thừ sau khi thực hiện các công việc kiểm tra theo test plan hoặc có
thêm các hành động cần thực hiện bổ sung trong quá trình test sau thay đổi (bao
gồm: thành cơng hay khơng thành cơng) thì gửi email thông báo cho ban CAB,
CCR, Change owner và SD về kết quả test sau thay đổi (nếu thay đồi khẩn, cần
thơng báo qua điện thoại, sau đó thơng tin lại qua email để ghi nhận).

Bộ phận kiểm
thử (Tester)

14. Cập nhập thông tin
triển khai

Bộ phận triển khai cập nhập các thông tin liên quan đến việc triển khai thay đổi
trên hệ thống SDP.

Bộ phận triền
khai

15. Cập nhập Service
Catalogue

Căn cứ thông tin được cập nhập của bộ phận triên khai trên SDP, Phịng SD cập
nhập thêm Service Catalogue và đóng lại u cầu.

Phịng Hỗ trợ
người sử dụng
(SD).

16. Đóng u câu

Đóng lại một yêu cầu thay đổi trên hệ thống SDP - đưa trạng thái u cầu về đã
hồn thành (Completed).

Phịng Hỗ trợ
người sử dụng

(SD).

Sản phẩm/Mẫu biểu/Tài
liệu tham chiếu


VIII. Mẫu biểu kèm theo
Stt
1.
2.
3.

Mã hiệu
MB01.PL05.QT-CNTT/03
MB02.PL05.QT-CNTT/03
MB03.PL0 .QT-CNTT/03

Tên Mẫu biểu
Phiếu yêu cầu thay đổi
Bảng theo dõi Kế hoạch & Nhật ký thay đổi
Biên bản test sau thay dồi

IX. Quy định lưu hồ sơ
Các hồ sơ thay đổi (RFC) khi đầy đủ, hợp lệ (ngoài Phiếu yêu cầu thay đổi đủ chữ ký của bên yêu cầu
(Change Owner, TP), bên tiếp nhận (SD), xác nhận của Change Owner thì bao gồm cả các chữ ký xác
nhận đầy đủ trong các tài liệu kèm theo hồ sơ RFC) sẽ chuyển Phòng Quản trị dich vụ thuộc Khối CNTT
lưu trữ tài liệu.
Stt
Mã hiệu
1. MB01.PL05.QT-CNTT/03

2.
MB02.PL05.QT-CNTT/03
3. MB03-PL05.QT-CNTT/03

Địa điểm lưu
Khối CNTT
Khối CNTT
Khối CNTT

Phương pháp
Thời gian
Bản cứng
25 năm
Bản cứng
25 năm
Bản cứng
25 năm


Sổ: RFC....

PHIẾU YÊU CẦU THAY ĐỔI
(Yêu Cầu thêm mới, thay đổi, nâng cấp... các dịch vụ và trang thiết bị cơng nghệ)
Tên người u cầu:
Phịng ban/Chi nhánh:
Địa chỉ:
Số điện thoại:

Email:

Mức độ khấn: ...........................
Thời gian yêu cầu: ........................
Thời gian mong muốn đáp ứng:
………….*
Dịch vụ muốn thav đổi: ..............
Kiểu của dịch vụ: .....................

Status: Mở
Mơ tả tóm tắt về u cầu:

Mơ tả chi tiết hiện trạng (cấu hình) cũ:

Mơ tả u cầu (cấu hình) mới:

Lý do thay đổi:

Đề xuất thay đỗi:

Xác nhận của người yêu câu
(ký và ghi rõ họ tên)

PHÂN LOẠI VÀ XỬ LÝ BAN ĐẦU
MB01.PL05.QT- CNTT/03

Xác nhận cùa trưởng phòng ban/Chi nhánh
(ký và ghi rõ họ tên)


Số: RFC....
Bộ phận tăng cấp đến CCR: Có

Khơng

Nhân viên Service Desk tiếp nhận
Ngày tháng:

Trưởng Service Desk tiếp nhận
Ngày tháng:

PHÂN LOẠI VÀ ĐÁNH GIÁ YÊU CẦU THAY ĐỔI
1. Phân loại

Yêu câu hợp lý: Có

Khơng

Danh mục tài liệu:

Từ chối u cầu: ...........................................
2. Đánh giá rủi ro, tác động
Tác động rủi ro nếu có

3. Tăng cấp lên lãnh đạo: Có

Danh sách thành viên CAB đề xuất:
1. Bà ......
2. Ổng .........
3. Bà.................
4. Ông .............

Biện pháp làm giảm

Không
Thời gian dự kiến thực hiện:
Thời gian chinh xác triển khai:
Phòng ban (hoặc nhân sự) thực hiện:
Chi phỉ dự kiến:
Xác nhận của Change Manager
Ngày tháng:

Ỷ KIẾN VÀ PHÊ DUYỆT CỦA CAB/LÃNH ĐẠO

MB01.PL05.QT- CNTT/03

Bộ phận đánh giá


Số: RFC....
Ngày trình xem xét:
Ngày chính thức xem xét: ..............................
Ý kiến của CAB/lãnh đạo: ......................
Kết quả: Đồng ý
Không đồng ý

Thời gian đáp ứng thay đổi: Thời gian chính xác
triển khai:
Ngân sách được duyệt:
Các phòng ban, cá nhân thực hiện:
- Phòng...
- Phòng ...

- Phòng....

Phê duyệt của lãnh đạo/cán bộ CAB được uỷ quyền
Ngày tháng: .........................