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

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 Mục đích Xây dựng quy trình nguyên tắc cho việc hoạch định, phối hợp, triển khai giám sát thay đổi tác động đến môi trường CNTT đặt thay đổi tầm kiểm soát Đảm bảo 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ố phát sinh từ thay đổi tới chất lượng dịch vụ CNTT Phạm vi Quy trình áp dụng cho việc quản lý thay đổi liên quan đến phát triển sản phẩm dịch vụ Việc quản lý thay đổi khác thực theo Hướng dẫn, Quy định có liên quan Cơng ty ABC thời kỷ II Giải thích từ ngữ chữ viểt tắt Thuật ngữ Ý nghĩa Cấp phê duyệt (Change Authority) Là người ủy phê duyệt thay đổi có mức ảnh hưởng đề cập phân loại mục V Phụ lục Quy trình QLTĐ Đơn vị cấu hình (CI) Đơn vị cấu hình xác định thuộc tính cần phải có mối quan hệ 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 mô tả mức cao khả giới thiệu thay dổi với dịch vụ, với kế hoạch kinh doanh tương ứng lịch trình triển khai dự kiến Đề xuất thay đổi thường tạo quy trinh quản lý danh mục dịch vụ chuyển cho quy trình quản lý thay đổi để phê duyệt Quản lý thay đổi xem xét đánh giá ảnh hưởng có dịch vụ khác, nguồn lực chia sẻ lịch thay đổi tổng thể Một đề xuất thay đổi phê duyệt, quy trình quản lý danh mục dịch vụ xác nhận dịch vụ CAB (Change Advisory Board - Ban tham vấn thay đổi) Ban tham vấn thay đổi nhóm thành viên thành lập từ nhiều phòng ban khác Khối Công nghệ Thông tin Cơng ty ABC có trách nhiệm xem xét mức độ rủi ro, tác động yêu cầu thay đổi đến hoạt động kinh doanh, nghiệp vụ, mức độ ưu tiên, phân tích hiệu chi phí tác động đến hệ thống IT CAB đưa lưu ý triển khai thay đổi, đưa phân tích chi tiết, tìi hỗn huỷ bỏ RFC Nhân tham gia họp thay đổi tùy thuộc vào loại thay đổi Đánh giá thay đổi (Change Evaluation) Đánh giá thức dịch vụ CNTT thay đổi dịch vụ CNTT cũ để đảm bảo rủi ro quản lý 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 thay đổi, cho phép thay đổi có lợi thực hiện, 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 thay đổi kiểm soát theo Quy trinh Quản lý thay đổi, đảm bảo thay đổi mang lại lợi ích, giảm thiểu tối đa gián đoạn dịch vụ công nghệ thông tin Bộ phận thực thay đổi (Department to make changes) Là một/một số phận chức một/một số phịng ban Khối Cơng nghệ Thơng tín kết hợp nhiều phịng ban Cơng ty ABC có trách nhiệm triển khai yêu cầu thay đổi Phiên phát hành (Release) Một nhiều thay đổi dịch vụ CNTT thiết lâp, thử nghiệm triền khai Một phát hành đơn lẻ bao gồm nhiều thay đổi với phần cứng, phần mềm, tài liệu, quy trình thành phần khác Bên thứ Là đối tác, nhà cung cấp dịch vụ Khối CNTT Công ty ABC Sự cố (Incident) Sự cố gián đoạn suy giảm chất lượng dịch vụ CNTT không nằm kế hoạch Một cấu phần hệ thống bị hỏng/ngừng hoạt động nhiên chưa ảnh hưởng trực tiểp đến dịch vụ CNTT coi cố Ví dụ: hỏng thành phẩn hệ thống dự phòng Sự cố nghiêm trọng (Major Incident) Là cố có mức độ tác động cao yêu cầu phản ứng nhanh đặc biệt cố thông thường Vấn đề (Problem) Là nguyên nhân chưa chẩn đốn làm phát sinh nhiều cố Lỗi xác định (Known error) Là vấn đề tìm nguyên nhân CCR (Change Configuration Release) Là phận Quản lý thay đổi thuộc Phỏng Vận hành Dịch vụ có chức xử lý yêu cầu thay đổi (RFC) Họp CCR (CCR Meeting) Lả họp thảo luận diễn phận CCR vá thành viên Ban tư vấn thay đổi (CAB) nhằm mục đích đưa đánh giá mức độ tác động, rủi ro thay đổi có kết luận đồng ý cho việc thực thay đổi hay không? Problem Owner Problem Owner trưởng phận, phụ trách kỹ thuật thuộc Khối CNTT quản lý vận hành thành phần công nghệ, ủy quyền để điều phối trình xử lý vấn đề Service Owner Là người chịu trách nhiệm cung cắp dịch vụ thời gian theo SLA cam kết Danh bạ dịch vụ (Service Catalog) Là danh sách dịch vụ công nghệ công bố cho người sử dụng, khách hàng với tiêu chất lượng quy định Thỏa thuận chất lượng dịch vụ (Service Level Agreement - SLA) Là cam kết Khối Công nghệ Thông tin với khối kinh doanh khách hàng dịch vụ cung cấp với mức chất lượng thống Thoả thuận chất lượng nội (Operating Level Agreement OLA) Là cam kết phòng ban chức Khổi Cơng nghệ Thơng tin với phịng ban chức Cơng ty q trình phối hợp nhằm đảm bảo tiêu chất lượng 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 yêu cầu thay đổi (RFC) theo Quy trình QLTĐ, sở hữu RFC người lập kể hoạch cho RFC Application Owner Là người nhóm có trách nhiệm đảm bảo chương trinh, thành phần tạo nên ứng dụng hoạt động yêu cầu đặt ra, bao gồm yêu cầu 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 ban CAB có trách nhiệm tham gia đánh giá thức dịch vụ CNTT thay đổi dịch vụ CNTT cũ để đảm bảo rủi ro quản lý 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 đóng vai trị người thực thay đổi, đảm bảo trình triển khai thay đổi theo 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 thay đổi theo kế hoạch định sẵn System Owner Là người nhóm có trách nhiệm đảm bào hệ thống (DC, DR, Servers), 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 yêu cầu 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à phận hạ tầng mạng thuộc phòng Vận hành mạng 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ở liệu thay dồi (Database Changed) Cơ sở liệu Thay đổi sở liệu lưu thơng tin liên quan tồn thay đổi Tại Công ty ABC, sở liệu thay đổi lưu Service Desk Plus Test Plan Kế hoạch kiểm tra (Test) đưa phận Kiểm thử cho 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 Khối nghiệp vụ 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 lịch chuyển giao sản phẩm dịch vụ CNTT cho khối nghiệp vụ Công ty QLTĐ Quản lý thay đổi Bộ phận triến khai Bao gồm Cán nhân viên Khối CNTT cỏ khả thực thay đổi nhiều Phịng ban Khối CNTT tập hợp thành Bộ phận triển khai Phịng, Bộ phận Trách nhiệm đơn vị Các Đơn vị có trách nhiệm theo quy định “Quy trình Phát triển sản phẩm - Dịch vụ CNTT trách nhiệm cụ thể Quy trình Quản lý thay đổi sau: Phòng Vận hành Dịch vụ (đóng vai trị CCR) a) Vai trị Đảm bảo sử dụng hiệu phương pháp chuẩn quy định Quy trình QLTĐ để quản lý thay đổi bảo đảm thay đối hạ tầng CNTT thực theo Quy trình QLTĐ b) Trách nhiệm - Giám sát thành cơng chất lượng quy trình quản lý thay đổi - Đảm bảo Quy trình quản lý thay đổi tuân thủ xác - Đảm bào cho cá nhân, Đơn vị có trách nhiệm Quy trình QLTĐ hiểu thực 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 Khối Cơng nghệ Thơng tin - Giữ vai trị tăng cấp lên CAB (Ban tham vấn thay đổi) 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ông ty Change Owner a) Vai trị - Chịu trách nhiệm toàn thay đổi từ bắt đầu tới kết thúc Quy trình QLTĐ - Nắm rõ yêu cầu hoạt động kịch - Là đầu mối cung cấp thông tin RFC b) Trách nhiệm - Lập phiếu yêu cầu thay đổi (RFC) - Đưa tư vấn, lập kế hoạch, lập lịch thay đổi - Cung cấp hiểu biết, thông tin mục đích, rủi ro, ảnh hưởng thay đổi - Cung cấp thông tin tài liệu cần thiết để đưa RFC - Xác định phân loại phù hợp - Tham gia giám sát trình triển khai thay đổi Phòng Hỗ trợ người sử dụng (SD) a) Vai trò - Là đầu mối tiếp nhận tất 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 kiểm tra tình trạng hồ sơ RFC - Khởi tạo/cập nhập thông tin ban đầu thay đổi lên hệ thống Servicedesk Plus (SDP) - Tiếp nhận kết việc triển khai thay đổi từ Bộ phận triển khai Bộ phận Kiểm thử - Đóng yêu cầu thay đổi III Người Đánh giá kỹ thuật (Technical Assessor) a) Vai trị - Cung cấp kiến thức chun mơn việc đánh giá ảnh hưởng yêu cầu thay đổi b) Trách nhiệm Đưa đánh giá kỹ thuật cho RFC Chấp nhận chuẩn bị nguồn lực sẵn sàng tham gia thực thay đổi đảm bảo thay đổi triển khai kế hoạch - Đảm bảo kết đánh giá cập nhật vào ghi thay đổi - Đóng vai trị tăng cấp 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) - a) Vai trò - Phê duyệt thay đổi chấp nhận nguồn lực cần thiết để thực thay đổi b) Trách nhiệm - Xem báo cáo định kỳ thay đổi theo tuần/tháng/quý - Xác nhận hoạt động cần thiết cho thay đổi - Đưa vấn đề ảnh hưởng tới hoạt động cùa ứng dụng dịch vụ hạ tầng CNTT - Xác nhận biện pháp truyền thông phù hợp - Phê duyệt/từ chối thay đổi 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 b) Trách nhiệm - Nhận nhiệm vụ chuẩn bị thay đổi, xác nhận việc triển khai theo kế hoạch - Xem 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 RFC - Triển khai thời gian hiệu - Thực hỉện q trình khơi phục với thay đổi gặp 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 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 sau thay đổi (tùy theo loại thay đổi) b) Trách nhiệm - Chấp nhận nhiệm vụ chuẩn bị cho RFC cách xác nhận kiểm thử theo kế hoạch - Kiểm tra thay đổi với test plan lập - Thông báo kết test sau thay đổi đến tất thành viên (VHDV, CAB, SD,…) 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 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 phê duyệt Triển khai thay đỏi Tester Khôi phục thay đối Thông báo kết Cập nhập nhật ký thay đối Đóng thay đổi Đánh giá kỹ thuật Kiểm tra nhập thông tin vào 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 cam kết SLAs nội 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ừ nhận RFC) ĐÍNH KÈM Giám đốc TTXDGP Các thay đổi liên quan đến ứng dụng: T24, Way4, Ebank, - Sàn phẩm - Cải tiến/sửa đổi sản phẩm ứng dụng Giám đốc CCDV Tối thiểu: TP Hỗ trợ Người sử dụng - TT CCDV TP Vận hành hệ thổng - TT CCDV TP Kiểm thử Giải pháp TP ứng dụng Công ty Quy định Mục VI Các Trưởng phòng có liên quan TTXDGP 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 phức tạp TP Vận hành Mạng Viễn thông-TTCCDV Thay đổi liên quan đến hạ tầng Nelwork/Firewall Kiến trúc sư network – P Kiến trúc giải pháp - TTXDGP TP Bảo mật CNTT-TTCCDV TP Vận hành Hệ thống (Tùy chọn) GĐ TT XDGP/Trưởng phòng/Trưởng phận thuộc TT XDGP (Tùy chọn) Mội số thành viên liên quan Tối thiểu: TP Vận hành Mạng Viễn thông Quy định 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 phức tạp STT 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 thiết ị máy chủ, SAN, máy chủ DB, Thay đổi liên quan đến swich site DC DR THÀNH PHẦN BAN CAB TP Vận hành Hệ thống - TTCCDV Trưởng phận thuộc P Vận hành ứng dụng Middleware GĐ TT XDGP/Trưởng phòng/Trưởng phận thuộc TT XDGP (Tùy chọn) TP.Bảo mật CNTT (Tùy chọn) Mội số thành viên liên quan TP Vận hành Hệ thống Trưởng phận thuộc P Vận hành ứng dụng Middleware GĐ TT XDGP/Trưởng phòng/Trưởng phận thuộc TT XDGP (Tùy chọn) TP.Bảo mật CNTT (Tùy chọn) 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ừ nhận RFC) ĐÍNH KÈM Tối thiểu: TP.VHHT Quy định 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 phức tạp Tổi thiếu: TP.VHHT Quy định 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 phức tạp STT LOẠI DỊCH VỤ THAY ĐỔI Thay đổi liên quan đến Bảo mật: Thay dổi sách/mật khầu/nâng cấp thay Thay đổi liên quan đến dich vụ Domain/ Website: Trang web chủ Công ty ABC - Eoflice Webmail Web nội LDAP THÀNH PHẦN BAN CAB TP.Bảo mật CNTT thuộc TTCCDV Phòng Vận hành Mạng Viễn thơng TP.VHHT GĐ TT XDGP/Trưởng phịng/Truởng phận thuộc TT XDGP (Tùy chọn) Mội số thành viên liên quan TP Vận hành Mạng Viễn thông thuộc TTCCDV TP Bảo mật GĐ TT XDGP/Trưởng phòng/Trưởng phận thuộc TT XDGP (Tùy chọn) TP Hỗ trợ Nguời sử dụng - TT VHDV 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ừ nhận RFC) Tối thiểu: TP Bảo mật CNTT Quy định 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 phức tạp Tối thiểu: TP Vận hành Mạng Viễn thông Quy định 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 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: - Core T24 - Way4 - Citad - VCB - Thay đổi quan trọng khác SLA (CCR phản hồi từ nhận RFC) Tổi thiểu: Các Giám đốc/Trưởng phòng/Trưởng phận thảnh viên liên quan Khối CNTT Ban CAB Quy định 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 phức tạp V Phân loại mức độ ưu tiên cấp phê duyệt \ STT PHÂN MƠ TẢ TÌNH HUỐNG LOẠI 1 Rất khẩn cấp Là thay đổi để khắc phục cổ xảy diện rộng toản khu vực, toàn hàng gián đoạn giao dịch, khắc phục cố, phục hồi liệu Lả thay đổi yêu cầu cấp thiết phục vụ kiểm tra kiểm toán, ban lãnh dạo phê duyệt Là thay đổi để khoanh vùng, cô lập cố, 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ấp tìển hành, sau hồn thành hồ sơ 2 Khẩn cấp Trung bỉnh V Thấp Là thay đổi để khắc phục cố tỉềm ẩn xảy ra, nhung chưa gây gián đoạn hệ thống thời điểm Những thay đổi để khắc phục cố xảy cục bộ, phạm vi ảnh hưởng nhỏ Lả thay đổi cho hạng mục có mức độ ưu tiên cao, đến hạn thực Tích hợp chương trình vào hệ thống Những thay đổi định kỳ cần thực Là thay đổi mà tác động không trực tiếp gây ảnh hưởng đến các đơn vị kinh doanh/tài chính, gây ảnh hưởng tiềm ẩn 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 thảo luận với phòng ban liên quan tự chủ thực theo quy ưỉnh Change Manager (CM) Cả nhân có trình thay đổi theo phê duyệt trưởng đơn vị Là thay đổi tác động đén nhãn Là 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 Diễn giải thực Bước Mô tả công việc Trách nhiệm thực Sản phấm/Mẫu biểu/ Tàí liệu tham chiếu Đánh giá sơ 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 cố/vấn đề phát sinh 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 hạ tầng, dịch vụ - Khi IT Demand làm rõ yêu cầu thay đổi từ Người sử dụng, IT Demand chuyền yâu cầu đến phòng ban/admin liên quan đến thay đổi để phân tích, lập Change Owner yêu cầu thay đổi - phịng ban/admin liên quan đóng vai trò Change IT Demand Owner - Change Owner nhận yêu cầu thay đổi từ IT Demand cần thực thay đổi Các thông tin 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ơ tác động, rủi ro (dưới góc nhìn cùa Admin triển khai thay đổi) thực 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 cố/vấn đề phát sinh thay đổi - MB0I.PL05.QTCNTT/03: Phiểu yêu cầu thay đổi 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 Đơn vị Quản lý dự án chuyển Phiếu yêu cầu thay đổi duyệt Change Owner hồ sơ liên quan tới Phịng SD tiếp nhận - Phiếu u cầu cần có đủ thông tin người yêu cầu, thời gian, lý thay dổi, đánh giá sơ rủi ro, Danh mục hồ sơ quy định Mục VI Phụ lục MB01.PL05.QT-CNTT/03: Phiếu yêu cầu thay đổi Các tài liệu liên quan RFC 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 sau: + Số hiệu RFC - Change Owner lấy số hiệu RFC từ Phòng Quàn trị Dịch vụ trước chuyển Phòng SD + Phạm vi mục đích 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 vấn đề/ lỗi biết liên quan + Mô tả đơn vị cấu hình (cũ/mới) liên quan + Lý thay đổi bao gồm thông tin chứng minh cần thiết/bắt buộc cho việc thay đổi (như theo Quyết định TGĐ 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, ) lợi ích mang lại cho hoạt động thay đổi + Phiên phiên CI bị thay đổi (nếu có) + Tên, Vị trí, số điện thoại 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 thời gian triển khai (dự kiến) + Danh mục thực + 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) chuyển tiếp tới Bộ phận CCR - Hổ sơ không đạt yêu cầu chuyển lại cho Change Owner xem xét lại (Bước 2) Cập nhật thông tin SDP Đánh giá lại RFC SD thực cập nhập thông tin RFC lên hệ thống Servicedesk Plus (SDP) chuyển cho Trưởng SD ký xác nhận trước 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 mô tả RFC - Xác định độ ưu tiên phân loại thay đổi CCR xem xét phù hợp cùa RFC, phân loại xác định mức độ ưu tiên RFC Việc dựa vào mức độ ảnh hưởng mức độ khẩn cấp yêu cầu thay đổi Ví dụ, yêu cầu thay đổi dựa vào múc độ ảnh hưởng vấn đề khẩn cấp 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 cấp phê duyệt” Mục V Phụ lục để 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 đánh giá lại RFC Với ảnh hưởng, tác động chưa đánh giá, chưa đánh giá đầy đủ, CCR yêu cầu phận chuyên môn tương ứng thực đánh giá lại Bộ phận chuyên môn chịu trách nhiệm chỉnh đánh giá cho loại thay đổi quy định “Bảng phân loại RFC cam kết SLAs” Mục Phụ lục nảy Một số yếu tố cần cân nhắc đánh giá thay đổi: Đảm bảo nguồn lực: CCR cần đảm bảo cống tác chuẩn bị triển khai thay đổi khơng xung đột vớí 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 từ chổi với 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 hoạt dộng dịch vụ quan trọng Công ty Quản lý xung đột: Ngoài việc đàm bảo nguồn lực, cần ý tới xung đột kỹ thuật xảy như: Các thiết bi (phần cứng) thay 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 phần mềm không phủ hợp với hệ điều hành dùng; Phối hợp: Đảm bảo toàn Đơn vị phối hợp tốt suốt trình diễn thay đổi Tham gia bên thứ “ Một số thay đổi cần dịch vụ hỗ trợ từ bên thứ 3, cần phối hợp từ xa, khác múi giờ, địa lý Truyền thông nội / bên ngồi - Một số thay đổi phức tạp, ảnh hưởng tới dịch vụ cung cấp bân Với thay đổi này, cần có test nghiệp vụ test kỹ thuật đảm bảo thành công Các phận 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 thông báo thay đổi để thơng báo tới người dùng tốt Quản lý rủi ro — Mỗi thay đổi có kế hoạch cần đánh giá rủi ro cách toàn diện 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 thơng tin phù hợp có u cầu thay đổi q trình thay đổi diễn theo quy trình Họp CCR (KS03) Sau phân loại RFC, Phòng Vận hành Dịch vụ làm việc trực tiếp tổ chức họp CCR với tất nhóm/cá nhân kỹ thuật/chuyên gia liên quan để phân tích, đánh giá RFC: thông tin chưa rõ ràng? Không hợp logic? Không khả thi? Mức độ tác động rủi ro? + Tùy thuộc vào loại thay đổi, thành viên tham gia họp đánh giá thay đổi + Các thành viên tham gia họp đánh giá đồng ý không đồng ý RFC ký xác nhận biên họp CCR Nội dung đánh giá bao gồm: + Đánh giá tổng quan cập nhật vào ghi RFC theo quan điểm người đánh gỉá + Kiểm tra thơng tin đính kèm liên quan đầy đủ (từ quan điểm kỹ thuật) + Kiểm tra kịch cung cẩp đảm bảo xác không chứa hoạt động không phủ hợp + Kiểm tra hệ (hống liên quan bị ảnh hưởng trực tiếp đến việc thay đổi liệt kê đầy đủ RFC như: Servers, DataBase, SAN, + Kiểm tra xác nhận thời gian, ảnh hưởng đầy đủ tinh huống, làm sở đưa dịnh + Kiểm tra có dịch vụ bị ảnh hưởng cần đảm bảo người liên quan biết chấp nhận 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 nội dung u cầu đảm bảo khơng cịn điếm khả nghỉ ngăn chặn q trình triển khai làm việc triển khai diễn khơng xác Kiểm tra thông tin phận kỹ thuật phận liên quan cần ý lập kế hoạch thay đổi: o Năng lực, tải dịch vụ bị ảnh hưởng o Độ tin cậy khả khôi phục o Các kế hoạch khơi phục o An tồn bảo mật o Ảnh hưởng thay đồi lên dịch vụ khác o Các tài nguyên cần thiết chi phí (hỗ trợ, bảo trì) o Số lượng cần thiểt, số lượng sẵn có chuyên viên o Các tài nguyên cần mua sắm kiểm thử o Ảnh hưởng tới hoạt động o Xung đột tới 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 xung đột thời gian Vai trò thành viên quy dịnh cụ thể “mục III Vai trò trỉch nhiệm đơn vị” Căn kết họp: + Nếu CCR CAB không thống nội dung thay đổi thông tin/đánh giá tác động/tài liệu cịn thiếu/ trả lại RFC cho Change owner xem xét lại RFC (bước 7) + Nếu CCR CAB thống đồng ý thực thay đổi, biê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 đủ RFC trình cán CAB ủ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 Xem xét “Yêu cầu thay đổi” (KS04) Trinh phê duyệt triển khai thay đổi Change Owner sau nhận lại RFC CCR, CAB cần thực xem xét lại RFC: Đánh giá lại tính hợp lý, cần thiết thay đổi bổ sung thông tin/chứng cần thiết Dựa thông tin cập nhật, đánh giá lại, Change Owner dịnh có đóng RFC hay khơng: - Nếu định đóng yêu cầu: Thực bước 16, Nếu khơng đóng u cầu: Thực bước - Căn thông tin RFC bien nội dung họp CCR đa thống nhất, CCR trình hồ sơ RFC lên BLĐ/cán CAB ủy quyền để phê duyệt từ chối triền khai thay đổi - Truờng hợp BLĐ/Cán CAB ủy quyền có tham gia họp CCR đánh giá cho thay đổi việc trình ký duyệt hồ sơ RFC mang tinh chất ký thủ tục nội dung thống họp CCR BLD/Cán CAB ủy quyền chấp nhận phê duyệt thay đổi Bộ phận triển khai thực 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) 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 CAB Phòng Vận hành dịch vụ “ Hồ sơ RFC - Biên họp CCR BLĐ/Cánbộ CAB ủy quyền Bộ phận triển khai đảm bảo bước chuẩn bị hoàn thành theo kế hoạch thay đổi Bao gồm việc đảm bảo thành viên tham gia (Khối Công nghệ Thông tin đối tác) triển khai kiểm thử hiểu rõ vai trò thay đổi 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 hoạt động sau: + Kiểm tra ghi thơng tin đầy dù khơng có thay đổi mong đợi vào phút cuối -> Kiểm tra thay đổi phê duyệt -> Kiểm tra tất 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 - 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 hệ thống liên quan 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 cần + Lưu trữ log ghi khác trình triển khai + Cập nhật ghi thay đổi (Trên SDP, Nhật ký thay đổi, ) để Phịng SD có đóng yêu cầu kết thúc 11 Kiểm tra kết (KS06) Bộ phận Kiểm thử (Test) tiến hành thực kiếm tra xem đơn vị cấu hình, dịch vụ CNTT, quy trình,.V V có thỏa mãn đặc tả u cầu cùa thay đơei Nói cách khác Tester bắt đầu kiểm tra theo test plan định sẵn yêu cầu thay đổi Nếu test không thành công, thực 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 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, phận triến khai cần khởi động q trình khơi phục theo kế hoạch có RFC Q trình cần bao gồm hoạt động: • Khơi phục thay đổi triển khai khơng thành cơng • Làm việc phận test để đảm bảo toàn mơi trường quay lại trạng thái trước thành công Bộ phận triển khai cần thực theo phạm vi thay đổi cần báo cáo cấp cao phát sinh không mong đợi trình triển khai (với thay đổi khẩn) Cụ thể: • Bộ phận triển khai phận Kiểm thử liên lạc với Change Owner Nếu không liên lạc cần liên lạc với Change Manager để thơng báo tình lấy đồng ý việc liệu có thêm hành động cần thực bổ sung nằm 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 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 việc triển khai thay đổi thất bại: + Liên lạc với phận hỗ trợ nghiệp vụ, phận vận hành (IT SD, IT Khu vực, ) + Khởi dộng theo Quy trình quản lý cố sử dụng nội Khối CNTT Sau thực khôi phục trạng thái truớc thay đổi cần kiểm tra lại kết theo bước 11 13 Thông báo kết thay đổi Bộ phận Kiểm thừ sau thực công việc kiểm tra theo test plan có thêm hành động cần thực bổ sung trình test sau thay đổi (bao gồm: thành công hay không thành cơng) gửi email thơng báo cho ban CAB, CCR, Change owner SD kết 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 thông tin liên quan đến việc triển khai thay đổi hệ thống SDP Bộ phận triền khai 15 Cập nhập Service Catalogue Căn thông tin cập nhập phận triên khai SDP, Phòng SD cập nhập thêm Service Catalogue đóng lại yêu cầu Phịng Hỗ trợ người sử dụng (SD) 16 Đóng u câu Đóng lại yêu cầu thay đổi hệ thống SDP - đưa trạng thái yêu cầu 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 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 test sau thay dồi IX Quy định lưu hồ sơ Các hồ sơ thay đổi (RFC) đầy đủ, hợp lệ (ngoài Phiếu yêu cầu thay đổi đủ chữ ký bên yêu cầu (Change Owner, TP), bên tiếp nhận (SD), xác nhận Change Owner bao gồm chữ ký xác nhận đầy đủ tài liệu kèm theo hồ sơ RFC) 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 MB01.PL05.QT-CNTT/03 MB02.PL05.QT-CNTT/03 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 dịch vụ trang thiết bị công nghệ) Tên người yê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 dịch vụ: Status: Mở Mơ tả tóm tắt u cầu: Mơ tả chi tiết trạng (cấu hình) cũ: Mơ tả u cầu (cấu hình) mới: Lý thay đổi: Đề xuất thay đỗi: Xác nhận người yêu câu (ký 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ý 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 Phân loại u câu hợp lý: Có Khơng Danh mục tài liệu: Từ chối yêu cầu: Đánh giá rủi ro, tác động Tác động rủi ro có Tăng cấp lên lãnh đạo: Có Danh sách thành viên CAB đề xuất: Bà Ổng Bà Ơ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 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 thức xem xét: Ý kiến CAB/lãnh đạo: Kết quả: Đồng ý Không đồng ý Thời gian đáp ứng thay đổi: Thời gian xác triển khai: Ngân sách duyệt: Các phòng ban, cá nhân thực hiện: - Phòng - Phòng - Phòng Phê duyệt lãnh đạo/cán CAB uỷ quyền Ngày tháng: BẢNG THEO DÕI KẾ HOẠCH & NHẬT KÝ THAY ĐỔI (Theo yêu cầu thay đổi số RFC ) TT Nội dung công việc Ứng dụng/Loại Ngày LẬP BẢNG MB02.PL05.QT - CNTT/03 Mô tả công việc Kể hoạch thực Thời gian Thời gian Nhân thực bắt đầu dự kết thúc dự dự kiến kỉến kiến Ngày KIẾM SOÁT Nhật ký thay đổi Thời gian Thời gian kết Nhân thực bắt đầu thúc thực tế thực tể thực tế Ngày PHÊ DUYỆT Kết thực tế BIÊN BẢN TEST SAU THAY ĐỔI TRÊN MÔI TRƯỜNG LIVE (Cho yêu cầu thay đổi “… ” ) Nội Dung Hạng Mục STT Xác nhận hồn thành cơng việc theo nội dung PYC thay đổi Đơn vị - Người thực Ký Xác Nhận Phòng ban: Tên người đại diện Test xác nhận ứng dụng hoạt Phịng ban: động bình thường sau thực thay Tên người đại diện đổi … … … … Kết luận: Với kểt test trên, bên thống golive “ ” Nếu có vấn đề phát sinh sau golive, tất Phòng ban/bộ phận có trách nhiệm cung cấp nguồn lực phối hợp xỷ lý theo yêu cầu lãnh đạo 3.Đại diện Phòng ban/bộ phận xác nhận MB03.PL05.QT - CNTT/03 ... chuẩn quy định Quy trình QLTĐ để quản lý thay đổi bảo đảm thay đối hạ tầng CNTT thực theo Quy trình QLTĐ b) Trách nhiệm - Giám sát thành công chất lượng quy trình quản lý thay đổi - Đảm bảo Quy trình. .. Quy trình quản lý thay đổi tn thủ xác - Đảm bào cho cá nhân, Đơn vị có trách nhiệm Quy trình QLTĐ hiểu thực 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... giản - 3-5 ngày với thay đổi phức tạp - 5-7 ngảy với thay đổi phức tạp STT LOẠI DỊCH VỤ THAY ĐỔI Thay đổi liên quan đến Bảo mật: Thay dổi sách/mật khầu/nâng cấp thay Thay đổi liên quan đến dich