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

Trang 1

PHỤ LỤC 05 QUY TRÌNH QUẢN LÝ THAY ĐỔI

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

Đơ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 hoã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

Trang 2

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

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

Thoả thuận chất lượng

Trang 3

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

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

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ề toà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

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

Trang 4

III 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ề toà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

- 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

- 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

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

- Đư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

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

Trang 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

- 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 chuyên môn kỹ thuật để triển khai thay đổi

- 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 quá 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

- 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,…)

Trang 6

IV Bảng phân loại RFC và cam kết SLAs nội bộ trong khối CNTT

STT LOẠI DỊCH VỤ THAY

YÊU CẦU TÀI SẢN ĐÍNH KÈM

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

Tối thiểu:

- 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

2 Thay đổi liên quan đến hạ

tầng Nelwork/Firewall

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

2 Kiến trúc sư network – P Kiến trúc và giải pháp - TTXDGP

Quy định tại Mục VI

Tối thiểu:

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

Trang 7

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

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

4 Thay đổi liên quan đến

swich site giữa DC và DR

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

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

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

Trang 8

SLA (CCR phản hồi từ khi nhận

được RFC)

5

Thay đổi liên quan đến

Bảo mật: Thay dổi chính

Tối thiểu:

Quy định tại Mục VI

Tối thiểu:

Trang 9

SLA (CCR phản hồi từ khi nhận

Ban CAB Quy định tại Mục VI

Tổi thiểu:

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

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

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

Lãnh đạo Khối

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

đó hoàn thành hồ sơ

Trang 10

4 Tích hợp các chương trình mới vào hệ thống

5 Những thay đổi định kỳ cần thực hiện

GĐ TTCCDV Được ưu tiên cho việc hoàn thành

thủ tục thay đổi theo quy trình

3 Trung bỉnh

1 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

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

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

4 Thấp Là những thay đổi mang tính cục bộ, thay đổi không gây ảnh hưởng, rủi ro đến

Trang 11

STT Loại tài liệu Yêu cầu về nội dung Mục đích Các đơn vị thẩm định

1 Phiếu yêu cầu thay đổi (Bắt buộc) Hoàn thành nội dung yêu cầu theo mẫu 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

liên quan đến CNTT xuất phát từ người sử

dụng/nghiệp vụ)

Là quyết định của các cấp có thẩm quyền Cơ sở pháp lý trình duyệt

golive

Change Owner/Requester

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)

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

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

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 (đặt ở đâu, cấu hình, lớp mạng nào, firewall nào )

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

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à

đảm bảo tính bảo mật

Cơ sở pháp lý trình duyệ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ì)

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

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

Trang 12

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ệ thống Admin liên quan sẽ thẩm định tải liệu

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 Admin, vận hành dịch vụ

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 động Phục vụ SD phân loại, hỗ trợ, cam kết thời gian hỗ trợ SD

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 quyết định/ cho đến khi các yêu cầu 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

Đề có bức tranh tổng thể khi phê duyệt thay đổ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 đặc thù Theo yêu cầu thực tế

VII Quy trình thực hiện

1 Thông số tổng hợp:

Đầ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 đồ:

Trang 14

3 Diễn giải thực hiện

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 yêu cầu thay đổi - khi đó các phòng ban/admin liên quan sẽ đóng vai trò là Change 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)

Change Owner

IT Demand

- 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.QT- CNTT/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

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

Change Owner

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

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

- 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

Định dạng
Số trang	27
Dung lượng	660,88 KB