Series ITIL cho người mới bắt đầu- Service Transition

Chúng ta thảo luận về giai đoạn tiếp theo trong vòng đời là  Service Transition:

Nội dung bao gồm:

  • Các đặc điểm chính của giai đoạn vòng đời chuyển tiếp dịch vụ ITIL
  • Các quy trình, quy trình con và KPI chính thức tạo nên giai đoạn vòng đời chuyển tiếp dịch vụ ITIL

Giai đoạn vòng đời chuyển đổi dịch vụ và khối lượng cốt lõi tương ứng của nó trong ITIL được dành để đảm bảo rằng các thay đổi trong dịch vụ được thực hiện theo cách phối hợp tốt, đáp ứng mong đợi đã thiết lập và cung cấp trải nghiệm gần như liền mạch cho khách hàng tin cậy hoặc sẽ tin cậy dịch vụ.

Việc chuyển đổi dịch vụ không nhất thiết đòi hỏi phải hoán đổi dứt khoát một dịch vụ này với dịch vụ khác. Chuyển đổi dịch vụ có thể bao gồm việc mở rộng một dịch vụ hiện có. Nó cũng có thể bao gồm dịch vụ mới mà trước đây không có. Chuyển đổi dịch vụ cũng có thể giám sát việc loại bỏ một dịch vụ hiện tại ngay cả khi không có dịch vụ thay thế nào được thiết lập để được thiết lập tại vị trí của nó. Quan trọng nhất, việc chuyển đổi dịch vụ phải được thực hiện theo cách để duy trì sự phù hợp với các mục tiêu kinh doanh được ghi chép cẩn thận trong chiến lược dịch vụ và các giai đoạn thiết kế dịch vụ. Chuyển đổi dịch vụ thể hiện sự khởi đầu của hoạt động thực hành trong ITIL. Khi quá trình chuyển đổi dịch vụ đang được sử dụng để tạo, sửa đổi hoặc mở rộng dịch vụ, thì đầu ra là một dịch vụ hoạt động sẽ được chuyển sang hoạt động dịch vụ trong phần còn lại của tuổi thọ. Trong một số trường hợp nhất định, quá trình chuyển đổi dịch vụ được sử dụng để chịu trách nhiệm đối với một dịch vụ mà hiện đang được cung cấp bởi một nhà cung cấp bên ngoài. Ví dụ, nếu một công ty đang phát triển quyết định lưu trữ trang web của riêng mình sau nhiều năm dựa vào nhà cung cấp dịch vụ lưu trữ bên ngoài, đây sẽ là một ví dụ về chuyển đổi dịch vụ.

Tương tự, khi một công ty quyết định ủy thác một dịch vụ cụ thể cho một nhà cung cấp bên ngoài, các nguyên tắc, vai trò, quy trình và quy trình chuyển đổi dịch vụ sẽ lại được áp dụng.

Trong bài viết này, chúng ta đã xem xét quy trình phối hợp thiết kế trong giai đoạn vòng đời thiết kế dịch vụ và giới thiệu khái niệm gói thiết kế dịch vụ (SDP), một trong những đầu ra chính của giai đoạn thiết kế dịch vụ nói chung. SDP cũng đóng vai trò là đầu vào chính cho quá trình chuyển đổi dịch vụ. Quá trình chuyển đổi dịch vụ tiến hành kiểm tra thường xuyên để đảm bảo kết quả mong muốn và thậm chí có một quy trình quản lý kiến ​​thức về giáo dục tại chỗ để đảm bảo rằng dữ liệu được sử dụng cho mục đích kiểm tra là toàn vẹn nhất.

Chuyển đổi dịch vụ bổ sung giá trị kinh doanh quan trọng cho một tổ chức. Trọng tâm của giá trị phụ gia này là khả năng chuyển đổi dịch vụ hiệu quả để thu hẹp đáng kể khoảng cách giữa kết quả ước tính và thực tế. Các doanh nghiệp cũng dựa vào quá trình chuyển đổi dịch vụ để đáp ứng nhu cầu tuân thủ khi chúng phát sinh. Chẳng hạn, nếu một bộ quy định mới được áp đặt bởi một cơ quan chính phủ, việc chuyển đổi dịch vụ sẽ rất cần thiết để cập nhật các dịch vụ để đảm bảo tuân thủ. Chuyển đổi dịch vụ cũng có thể đóng một vai trò to lớn khi các công ty đang sáp nhập hoặc theo đuổi việc mua lại. Để giảm thiểu chi phí, sự nhầm lẫn và khó khăn cho khách hàng, các dịch vụ CNTT kết hợp của cả hai công ty phải được tích hợp hiệu quả nhất có thể và theo cách đảm bảo dịch vụ sẽ đạt tiêu chuẩn. Chuyển đổi dịch vụ cũng yêu cầu CNTT phải thận trọng trong việc theo dõi tài sản của mình. Sự ra đời của một dịch vụ mới hoặc mở rộng thường có nghĩa là công nghệ mới và mở rộng, có thể làm cho sự hiện diện của nó cảm thấy tốt hơn hoặc xấu hơn trong toàn bộ doanh nghiệp. Do đó, điều bắt buộc là các tác động của những thay đổi xảy ra trong quá trình chuyển đổi dịch vụ được theo dõi và phân tích. Khi hoàn thành thành công, việc nâng cấp, mở rộng, mua lại và sáp nhập công nghệ sẽ mang lại hiệu quả tích cực rõ ràng cho danh mục dịch vụ, một điều sẽ làm lu mờ bất kỳ sự phức tạp hoặc gián đoạn dịch vụ nào do quá trình chuyển đổi.

Một số quy trình chuyển đổi dịch vụ ITIL chính thức, chẳng hạn như quản lý thay đổi, được sử dụng trong tất cả các giai đoạn của vòng đời dịch vụ ITIL. Những người khác, chẳng hạn như quản lý phát hành và triển khai, tập trung nhiều hơn vào giai đoạn chuyển đổi dịch vụ.

Hãy cùng xem các quy trình chính mà ITIL xác định là một phần của quá trình chuyển đổi dịch vụ:

 Change Management

Mục tiêu của quản lý thay đổi là triển khai các dịch vụ CNTT mới với sự gián đoạn tối thiểu đối với cơ sở hạ tầng dịch vụ CNTT hiện có. Quản lý thay đổi được coi là một quá trình rất quan trọng phải được thực hiện một cách cẩn thận và chính xác. Các chuyên gia CNTT thường sẽ chỉ ra mức độ có thể sai khi quản lý thay đổi bị xử lý sai. Kết quả quản lý thay đổi kém có thể bao gồm thời gian chết quá mức, lỗi dữ liệu mất nhiều thời gian để sửa chữa, phân công trách nhiệm không rõ ràng, vi phạm tuân thủ và một số tác động tiêu cực khác.

Dưới đây là một số thuật ngữ cơ bản được sử dụng trong quy trình quản lý thay đổi:

Change

Định nghĩa cho sự thay đổi như ITIL đã nêu là việc bổ sung, sửa đổi hoặc loại bỏ bất cứ điều gì có thể có ảnh hưởng đến các dịch vụ CNTT. Phạm vi nên bao gồm các thay đổi đối với tất cả kiến trúc, quy trình, công cụ, số liệu và tài liệu, cũng như thay đổi đối với các dịch vụ CNTT và các thành phần khác. Thay đổi được mô tả đơn giản là các thay đổi sẽ tuân theo các giao thức chuẩn được xác định trong quản lý thay đổi. Tuy nhiên, có hai loại thay đổi, thay đổi tiêu chuẩn và thay đổi khẩn cấp, có thể tuân theo các giao thức được sửa đổi

 Standard Change

Khái niệm về thay đổi tiêu chuẩn được thiết lập về cơ bản như là một phương tiện bỏ qua các giao thức mở rộng thường đi theo trong quy trình quản lý thay đổi. Những thay đổi tiêu chuẩn là những điều xảy ra thường xuyên và không có nhiều tiềm năng để phá vỡ các dịch vụ. Ví dụ: nếu dịch vụ của tôi là máy bán hàng tự động và tôi đã hết hang hóa năm ngày trước khi tôi dùng lại cho một đợt đặt hang mới, thì tôi có thể yêu cầu thay đổi tiêu chuẩn để tôi có thể nhận được đơn hang mới sớm hơn một chút. Các thay đổi tiêu chuẩn thường không có yêu cầu sự tham gia của các nhân viên chuyên ngành nhưng thay vào đó có thể được giải quyết bởi bàn dịch vụ của tổ chức. Hơn nữa, trong hầu hết các trường hợp, các thay đổi tiêu chuẩn sẽ hoàn toàn bỏ qua quy trình quản lý thay đổi chính thức trong quá trình chuyển đổi dịch vụ ITIL và thay vào đó sẽ được tham gia bởi các quy trình khác như quy trình thực hiện yêu cầu trong giai đoạn vòng đời hoạt động dịch vụ ITIL. Khi một sự thay đổi tiêu chuẩn được tham dự bởi services desk, nó được gọi là một yêu cầu dịch vụ.

Emergency Changes

Thay đổi khẩn cấp về cơ bản là ngược lại với thay đổi tiêu chuẩn; thay đổi khẩn cấp là bất cứ điều gì nhưng tiêu chuẩn. Một sự thay đổi khẩn cấp là cần thiết khi hoàn cảnh hiện tại gây ra mối đe dọa lớn cho hoạt động kinh doanh và phải được thay đổi càng sớm càng tốt. Một sự thay đổi khẩn cấp có thể là cần thiết trong trường hợp sa thải bất ngờ một giám đốc điều hành cấp cao nhất với những thông tin an ninh quan trọng và độc quyền. Để tổ chức hoạt động phù hợp và an toàn, thông tin đăng nhập điều hành bị sa thải phải bị thu hồi và thông tin đăng nhập mới phải được thiết lập cho những người chịu trách nhiệm. Mặc dù các thay đổi khẩn cấp phải diễn ra nhanh hơn các thay đổi thông thường, vẫn phải có một quy trình rõ ràng được áp dụng.

Quản lý sự thay đổi có các quy trình con như sau:

 Change Management Support

Cung cấp các mẫu quản lý để giúp hướng dẫn các thay đổi hoặc bổ sung, sửa đổi hoặc xóa bất kỳ yếu tố liên quan nào có thể ảnh hưởng đến các dịch vụ CNTT. Quy trình con này cũng cung cấp thông tin cho các thành phần quản lý dịch vụ CNTT khác để hỗ trợ điều chỉnh và tiếp thu các thay đổi sắp tới hoặc đang diễn ra.

Assessment of Change Proposals

Đánh giá những thay đổi trong tương lai. Quy trình con này thường được thông báo bởi chiến lược dịch vụ, giúp đảm bảo rằng đề xuất thay đổi phản ánh nhu cầu của doanh nghiệp và xác định các vấn đề có thể gặp phải trong quá trình thay đổi.

Theo dõi và đánh giá các yêu cầu thay đổi (RFC hoặc yêu cầu chính thức cho các thay đổi được đề xuất bao gồm các chi tiết có thể được gửi trên giấy hoặc điện tử) và lọc ra những thông tin không khả thi hoặc chưa có tất cả thông tin liên quan.

Assessment & Implementation of Emergency Change

Đánh giá, ủy quyền và thực hiện các thay đổi khẩn cấp phải được đưa vào thực tế càng sớm càng tốt và hoạt động trong các khung thời gian ngắn. Quy trình con này được sử dụng khi doanh nghiệp ra lệnh rằng quy trình đánh giá và đề xuất thay đổi tiêu chuẩn sẽ không tiến hành đủ nhanh để đáp ứng nhu cầu kinh doanh cấp bách. Điều quan trọng là quy trình con này đặt các biện pháp bảo vệ để ngăn chặn việc lạm dụng các thay đổi khẩn cấp, họ chỉ nên thực hiện để đáp ứng nhu cầu kinh doanh khẩn cấp.

Change Assessment by the Change Manager

Xác định mức độ ủy quyền cần thiết để thực hiện thay đổi được đề xuất. Một số thay đổi cần có sự cho phép của người quản lý thay đổi, người chịu trách nhiệm giám sát vòng đời của thay đổi, trong khi những người khác đến một ban cố vấn đặc biệt được gọi là Hội đồng tư vấn thay đổi (Change Advisory Board-CAB), một nhân viên ngang hàng hỗ trợ người quản lý thay đổi đánh giá ưu tiên, và thay đổi lịch trình. Xem quy trình con tiếp theo.

Change Assessment by the Change Advisory Board (CAB)

Đánh giá một sự thay đổi được đề xuất và phát triển một quy trình lập kế hoạch thay đổi. Đôi khi, quy trình con này có thể thực thi tự động thông qua thẩm quyền của CAB; mặt khác, nó có thể cần phải chuyển sang một cấp thẩm quyền khác, chẳng hạn như quản lý CNTT, để nhận được ủy quyền.

Change Scheduling & Build Authorization

Cho phép quy trình lập kế hoạch chi tiết hơn cho các thay đổi tiềm năng và đánh giá Kế hoạch dự án kết quả, một tài liệu chính thức yêu cầu phê duyệt và biểu thị các nguồn lực, cột mốc và hoạt động quan trọng cho một dự án, còn được gọi là Kế hoạch chuyển đổi dịch vụ, được sử dụng để ủy quyền thay đổi giai đoạn xây dựng, là tốc ký cho việc lập lịch thay đổi và xây dựng quy trình ủy quyền theo quy trình quản lý thay đổi.

Change Deployment Authorization

Đánh giá sự sẵn sàng thay đổi bằng cách đánh giá các thành phần sẽ tham gia vào quá trình chuyển đổi và liệu các yếu tố đó đã được kiểm tra đúng chưa. Sau khi các đánh giá này được thực hiện, quy trình con này có thể cho phép giai đoạn triển khai thay đổi, là cách viết tắt cho quy trình ủy quyền triển khai thay đổi theo quy trình quản lý thay đổi.

Minor Change Deployment

Quản lý phát hành các bước bên, nghĩa là toàn bộ chức năng phát hành và triển khai và thực hiện các thay đổi rủi ro đơn giản, tối thiểu.

Post-implementation Review & Change Closure

Đánh giá kết quả cuối cùng của việc thực hiện thay đổi và xem xét lịch sử đầy đủ của các hoạt động được thực hiện và kết quả của chúng. Quy trình con này phải đánh giá các lỗi đã xảy ra trong quá trình thay đổi và báo cáo các số liệu thống kê quan trọng có thể học và ghi lại.

KPI trong quản lý sự thay đổi :

Số lượng thay đổi lớn

– Số lượng thay đổi lớn được đánh giá bởi CAB

Số lượng các cuộc họp CAB

– Số lần CAB gặp trong khi thực hiện chức năng Quản lý thay đổi mà Cam kết thực hiện.

Thời gian phê duyệt / từ chối thay đổi

– Lượng thời gian để phê duyệt hoặc từ chối thay đổi được đề xuất như được trình bày trong RFC.

Thay đổi tỷ lệ chấp nhận

– Số lượng thay đổi giành được phê duyệt liên quan đến tổng số RFC được gửi.

Số lượng thay đổi khẩn cấp

– Số lượng Thay đổi khẩn cấp được đánh giá bởi Hội đồng tư vấn thay đổi khẩn cấp (ECAB)

Change Evaluation

Quá trình đánh giá thay đổi được thiết kế để chỉ sử dụng cho các thay đổi quản lý dịch vụ chính. Quá trình này cung cấp một kiểm tra nghiêm ngặt về những thay đổi tiềm năng phải diễn ra trước khi những thay đổi tiến vào giai đoạn tiếp theo trong vòng đời của chúng. Tuy nhiên, đánh giá thay đổi có thể được yêu cầu nhiều lần trong suốt vòng đời thay đổi để cung cấp kiểm tra, khuyến nghị và xác minh rằng dịch vụ đang được triển khai đáp ứng các yêu cầu nghiệp vụ được nêu trong các giai đoạn của vòng đời trước. Đầu ra chính của quá trình đánh giá thay đổi là một báo cáo đánh giá thay đổi, ghi lại quá trình đánh giá thay đổi. Thay đổi quy trình đánh giá bao gồm:

Change Evaluation Prior to Planning

Đánh giá một đề xuất thay đổi lớn trước khi giai đoạn lập kế hoạch thay đổi được cho phép.

Change Evaluation Prior to Build

Đánh giá một đề xuất thay đổi lớn trước giai đoạn xây dựng thay đổi.

Change Evaluation Prior to Deployment

Đánh giá một đề xuất xây dựng thay đổi lớn trước giai đoạn triển khai thay đổi.

Change Evaluation After Deployment

Đánh giá một sự thay đổi lớn sau khi thực hiện. Quy trình con này chịu trách nhiệm thu thập dữ liệu về hiệu quả của thay đổi, đánh giá các mục tiêu và liệu chúng có được đáp ứng đầy đủ hay không và xác định các bài học rút ra từ thay đổi.

Không có KPI cụ thể được đính kèm với quá trình đánh giá thay đổi.

Transition Planning & Support

Quá trình này là nơi cao su gặp đường, nơi tất cả các chiến lược và kế hoạch hoàn thành trong các giai đoạn vòng đời trước được thực hiện trong quá trình thực hiện một dự án thực tế. Quy trình hỗ trợ và lập kế hoạch chuyển đổi về cơ bản là thiết kế quản lý dự án của ITIL và trong khi ITIL nêu bật vô số các hoạt động quản lý dự án có liên quan, điều quan trọng cần biết là có rất nhiều khung quản lý dự án có thể bổ sung cho việc thực hiện quy trình này, trong số đó có PRINCE2 và PMBOK. Các khung này thực sự được khuyến nghị trong sách ITIL v3. Đối với mục đích hướng dẫn được cung cấp cụ thể bởi ITIL, các chủ đề chính được tóm tắt là điều phối các dự án chuyển đổi dịch vụ, đảm bảo có sẵn các nguồn lực cần thiết và giải quyết xung đột.

Các dự án được bắt đầu khi quản lý danh mục dịch vụ giới thiệu một dịch vụ mới, quyết định theo đuổi thay đổi đáng kể đối với dịch vụ hiện có hoặc quyết định đưa dịch vụ hiện đã nghỉ hưu hoạt động trở lại. Tại thời điểm này, quy trình hỗ trợ và lập kế hoạch chuyển tiếp gọi các quy trình khác trong khung ITIL như phối hợp thiết kế và quản lý phát hành và triển khai. Các quy trình này hỗ trợ lập kế hoạch cấp chi tiết cuối cùng sẽ xác định cách thức dự án mở ra. Các quy trình con để lập kế hoạch chuyển đổi và hỗ trợ như sau:

Project Initiation

Thiết lập nền tảng sớm cho một dự án. Trong quy trình bắt đầu dự án, các bên liên quan trong dự án được xác định, các nguồn lực sẵn có được thu thập và trách nhiệm được xác định. Rủi ro, ràng buộc và giả định liên quan đến dự án được ghi lại trong quy trình con này.

Project Planning & Coordination

Các quản lý cùng  tài nguyên từ các giai đoạn và quy trình khác của vòng đời ITIL và điều phối chúng để phục vụ nhu cầu của dự án đang được tiến hành. Quy trình con này đảm bảo tuân thủ các nguyên tắc quản lý dự án của tổ chức. Lập kế hoạch và điều phối dự án là sự phối hợp nhiều hơn vì lợi ích của việc lập kế hoạch hơn là kế hoạch thuần túy. Hầu hết các yếu tố lập kế hoạch quan trọng cho quy trình con này dựa vào tài nguyên được mua bởi các quy trình và quy trình con khác.

Project Control

Giám sát việc thực hiện dự án, theo dõi tiến độ và theo dõi quá trình hoàn thành cột mốc. Quá trình điều khiển dự án cũng chịu trách nhiệm giám sát mức độ sẵn có và tiêu thụ tài nguyên. Ngoài ra, quy trình con này được chuẩn bị để sửa khóa học nếu dự án bắt đầu chạy sai.

Project Reporting & Communication

Tóm tắt dữ liệu trên bảng từ nhiều dự án chuyển đổi dịch vụ đang diễn ra và cung cấp tóm tắt cho khách hàng. Quy trình con này cũng chuyển tiếp thông tin đến các quy trình quản lý dịch vụ khác.

KPI được sử dụng để đánh giá quá trình hỗ trợ và lập kế hoạch chuyển đổi bao gồm:

Số lượng dự án

– Số lượng các bản phát hành chính được giám sát bởi Quản lý dự án.

Tỷ lệ dự án có Điều lệ dự án

– Một tỷ lệ phần trăm các dự án chỉ bắt đầu sau khi Điều lệ dự án hoàn thành và được ký kết đã được mua.

– Điều lệ dự án phác thảo các mục tiêu của dự án, xác định các bên liên quan và chỉ định một người quản lý dự án.

Số lượng thay đổi Điều lệ dự án

– Số lượng thay đổi Điều lệ dự án sau dự án.

Tuân thủ ngân sách dự án

– Đo lường ngân sách theo kế hoạch so với chi tiêu thực tế, bao gồm cả nguồn lực tài chính và nhân sự.

Trì hoãn dự án

– So sánh ngày hoàn thành dự án thực tế và ngày hoàn thành dự án theo kế hoạch.

Release & Deployment Management

Quá trình này chi phối việc thử nghiệm và phát hành các nỗ lực dịch vụ mới vào thực tiễn. Mối quan tâm cụ thể của quá trình này là bảo vệ tính toàn vẹn trong thực tiễn. Khi đưa ra một thay đổi lớn đối với một hệ thống dịch vụ CNTT hiện có, nguy cơ làm hỏng các hoạt động bình thường của hệ thống hiện tại là không bao giờ có. Thiệt hại tiềm tàng này dao động từ tác động thấp đến thảm họa toàn diện. Quản lý phát hành và triển khai có trách nhiệm đảm bảo rằng các thành phần chính xác được phát hành và sẽ không có hại cho các hệ thống hiện có. Cũng như một số quy trình khác trong giai đoạn vòng đời chuyển tiếp dịch vụ, quản lý phát hành và triển khai phải giao tiếp với một số quy trình khác từ thiết kế dịch vụ và các giai đoạn vòng đời khác. Phát hành và triển khai là một kiểm tra lớn đối với năng lực thiết kế dịch vụ. Nếu thiết kế dịch vụ được hoàn thành chính xác, thì việc phát hành và triển khai sẽ diễn ra khá suôn sẻ. Tuy nhiên, gặp phải một số vấn đề không lường trước là bình thường và dự kiến. Một phần của quá trình phát hành và triển khai là việc tạo điều kiện cho các yêu cầu cho các thành phần bổ sung. Có lẽ cần thêm một chút băng thông so với dự đoán ban đầu hoặc có lẽ bạn đã đánh giá thấp khối lượng yêu cầu hỗ trợ sẽ đánh vào bàn dịch vụ của bạn. Có lẽ có một số trách nhiệm pháp lý hoặc rủi ro kinh doanh đối với dịch vụ của bạn mà bạn không thể dự đoán đầy đủ trong giai đoạn thiết kế dịch vụ. Nếu quy trình quản lý phát hành và triển khai của bạn đang được thực thi đúng cách, thì bạn sẽ có thể đáp ứng nhanh chóng và đầy đủ các nhu cầu không lường trước được.

Các quy trình con của quy trình quản lý phát hành và triển khai bao gồm:

Release Management Support

Cung cấp hướng dẫn và hỗ trợ cho việc triển khai các bản phát hành, chứa một đơn vị phát hành hoặc một bộ đơn vị phát hành có cấu trúc, mỗi đơn vị chứa một bộ các mục cấu hình mới, đã thay đổi hoặc không thay đổi được thử nghiệm và đưa vào môi trường trực tiếp để thực hiện một hoặc một số thay đổi được phê duyệt.

Release Planning

Cung cấp thông tin sẽ được sử dụng để lên lịch, xây dựng, kiểm tra và triển khai bản phát hành. Quy trình con này xem xét và chỉ định các thay đổi cho các gói phát hành (đồng nghĩa với phát hành) dựa trên các yêu cầu nội dung và quy mô cập nhật nhất.

Release Build

Phối hợp tất cả các đơn đặt hàng công việc nội bộ và bên ngoài cần thiết để có được các thành phần phát hành cần thiết. Khi kết thúc quá trình con này, tất cả các thành phần phát hành sẽ được tổ chức hợp lý và sẵn sàng để được kiểm tra.

Release Deployment

Triển khai phát hành vào một môi trường sống. Quy trình con này không phải là một thử nghiệm chính thức, mà thay vào đó là một sự ra mắt sẽ tạo ra một tác động thực sự và trực tiếp đến doanh nghiệp doanh nghiệp. Quy trình triển khai phát hành cũng chịu trách nhiệm đào tạo cả nhân viên và người dùng cuối.

Early Life Support

Giải quyết kịp thời các vấn đề được làm rõ ràng trong các giai đoạn ban đầu của bản phát hành trực tiếp. Quy trình con này chuyên làm sạch các lỗi và thiếu sót với tốc độ, hiệu quả và hiệu quả của chuyên gia. Bởi vì việc phát hành là trực tiếp và đang ảnh hưởng đến kinh doanh, tất cả các hoạt động hỗ trợ đầu đời được thực hiện với tốc độ quan trọng.

Release Closure

Đóng một bản phát hành khi xác minh rằng tất cả các bản ghi hoạt động và nội dung của hệ thống quản lý cấu hình (CMS) đã được cập nhật. CMS là một bộ công cụ và siêu dữ liệu được sử dụng để thu thập, lưu trữ, quản lý, cập nhật, phân tích và trình bày dữ liệu về tất cả các mục cấu hình và các mối quan hệ của chúng.

Quá trình quản lý phát hành và triển khai được đánh giá theo các KPI sau:

Số lượng phát hành

– Số lượng bản phát hành được đưa vào môi trường sống, được nhóm thành các loại chính và nhỏ.

Thời gian triển khai chính

– Thời gian trung bình cần thiết để triển khai một bản phát hành từ phê duyệt đến hoàn thành.

Số lượng bản phát hành

– Số lượng bản phát hành không hoàn thành trước khi chúng bị hủy.

Tỷ lệ phân phối phát hành tự động

– So sánh bản phát hành được phân phối tự động trong tổng số bản phát hành.

Service Validation & Testing

Quá trình kiểm tra và xác nhận dịch vụ xảy ra trong một môi trường trong đó bản phát hành đã được phát hành và phản hồi ban đầu đã được thu thập. Mục tiêu của xác nhận và thử nghiệm dịch vụ là đảm bảo rằng dịch vụ kết quả được thiết lập là đủ để đáp ứng nhu cầu của khách hàng được phục vụ. Quá trình này cũng phải đảm bảo rằng các hoạt động CNTT có phương tiện để liên tục duy trì dịch vụ mới sau khi nó được hiển thị là có hiệu quả.

Trong ITIL 2011, các giao diện mới đã được thêm vào kết nối xác thực và thử nghiệm dịch vụ với kế hoạch và hỗ trợ chuyển đổi nhằm nỗ lực đảm bảo rằng dữ liệu tốt nhất và cập nhật nhất luôn được cung cấp trong quá trình quản lý dự án. Xác nhận và kiểm tra dịch vụ cũng giao diện với quản lý thay đổi và quản lý phát hành và triển khai. Các quy trình sau sẽ kích hoạt xác thực và kiểm tra dịch vụ khi cần thiết để đảm bảo rằng dịch vụ hiện được thêm vào môi trường sống đang hoạt động theo tất cả các SLA, UC và OLA có liên quan. Khi các dịch vụ gần đây đã trải qua thay đổi phải chịu thử nghiệm, điều quan trọng là phải kiểm tra toàn bộ cấu trúc dịch vụ, không chỉ là phần bị ảnh hưởng ngay lập tức bởi thay đổi. Như bạn có thể đã biết nếu bạn làm việc trong CNTT, các thay đổi có thể có các phân nhánh không nhìn thấy sẽ ảnh hưởng và thay đổi hiệu suất trong toàn hệ thống. Xác thực và kiểm tra dịch vụ không chỉ là kiểm tra sản phẩm cuối cùng mà thôi mà còn rất quan trọng để kiểm tra các bước trung gian đóng góp cho sản phẩm cuối cùng. Nếu bạn đang chạy một dịch vụ phát trực tuyến phim, thì thật tuyệt vời khi xác minh rằng dịch vụ đó có thể được sử dụng để phát trực tuyến phim, nhưng đó chỉ là khởi đầu. Điều gì xảy ra với dữ liệu thẻ tín dụng của khách hàng sau khi họ trả tiền cho dịch vụ? Có an toàn không? Điều gì xảy ra khi có một nhu cầu đặc biệt cao đối với một bộ phim được giới thiệu trên mạng của bạn? Máy chủ sẽ bị sập hay nó được cấu hình để tự động khai thác tài nguyên của các máy chủ dự phòng? Xác nhận và kiểm tra dịch vụ phải luôn là một nỗ lực chu đáo, đa chiều.

Các quy trình con để xác nhận và kiểm tra dịch vụ bao gồm:

Test Model Definition

Xác định các phương pháp mà theo đó phát hành sẽ được thử nghiệm. Quy trình con này xác định một khái niệm thử nghiệm và các trường hợp thử nghiệm sẽ được sử dụng để xác nhận dịch vụ mới.

Release Component Acquisition

Thu thập các bộ phận thành phần khác nhau sẽ được sử dụng trong quá trình phát hành đang chờ xử lý và kiểm tra chúng riêng lẻ. Chỉ các thành phần đáp ứng các tiêu chí chất lượng dự kiến ​​mới được sử dụng trong giai đoạn thử nghiệm và xác nhận mạnh mẽ hơn tiếp theo.

Release Test

Kiểm tra tất cả các thành phần phát hành cùng một lúc, hoạt động song song để cung cấp dịch vụ cuối mong muốn. Nhiệm vụ phụ này là rào cản cuối cùng trước khi thử nghiệm trực tiếp và thử nghiệm được sử dụng phải rất nghiêm ngặt. Khi dịch vụ được phát hành, nó sẽ ảnh hưởng đến doanh nghiệp và việc kiểm tra nghiêm ngặt có thể loại bỏ các gián đoạn và lỗi dịch vụ tốn kém khi dự án hoạt động.

Service Acceptance Testing

Giao tiếp với khách hàng để đảm bảo rằng dịch vụ mới được phát hành sẽ tuân thủ tất cả các yêu cầu cấp độ dịch vụ và xác minh rằng tất cả các điều kiện cần thiết đã được đáp ứng để cho phép kích hoạt dịch vụ mới. Vào thời điểm quy trình con này được bắt đầu, bản phát hành đã vượt qua tất cả các điểm kiểm tra đảm bảo chất lượng và không được tạo ra các lỗi mới.

Dưới đây là các KPI được sử dụng để đo lường quá trình kiểm tra và xác thực dịch vụ:

Số lượng phát hành

– Số lượng bản phát hành được đưa vào môi trường sống, được nhóm thành các loại chính và nhỏ.

Thời gian triển khai chính

– Thời gian trung bình cần thiết để triển khai một bản phát hành từ phê duyệt đến hoàn thành.

Số lượng bản phát hành

– Số lượng bản phát hành không hoàn thành trước khi chúng bị hủy.

Tỷ lệ phân phối phát hành tự động

– So sánh các bản phát hành được phân phối tự động liên quan đến tổng số bản phát hành.

Service Asset & Configuration Management

Quản lý cấu hình và tài sản dịch vụ (SACM) là một quy trình đảm bảo các tài sản phù hợp được triển khai và định cấu hình đúng với nhau. Các quy trình con của tài sản dịch vụ và quản lý cấu hình bao gồm:

Configuration IdentificationXác định và duy trì hệ thống quản lý cấu hình (CMS) để lưu giữ thông tin về các mục cấu hình (CIs), là các tài sản có sẵn có thể được kết hợp thành một cấu hình. Điều này liên quan đến đặc điểm kỹ thuật của các thuộc tính CI và các thành phần phụ của chúng, cũng như xác định bất kỳ mối quan hệ tương quan giữa các bộ phận thành phần.

Configuration Control

Đảm bảo rằng các thành phần của cấu hình được sửa đổi, thêm vào hoặc lấy đi chỉ với sự đồng ý có thẩm quyền. Quá trình con này dựa trên CMS để ghi lại và xác minh tất cả các sửa đổi được ủy quyền đối với cấu hình và nó đảm bảo rằng không có thay đổi trái phép nào xảy ra.

Configuration Verification & Audit

Xác minh thông tin trong CMS so với CIs thực tế được triển khai trong môi trường sản xuất trực tiếp.

Tài sản dịch vụ và quy trình quản lý cấu hình chịu trách nhiệm cho các KPI sau:

Tần suất xác minh

– Tần suất xác minh vật lý của nội dung CMS.

Số sự cố do thông tin CMS không chính xác

– Số lượng sự cố xảy ra do thông tin không chính xác trong Hệ thống quản lý cấu hình.

Nỗ lực xác minh CMS

– Một hồ sơ về nỗ lực dành để xác minh nội dung CMS.

Bảo hiểm CMS

– Tỷ lệ phần trăm của các thành phần cấu hình được thể hiện trong CMS.

Số lượng thay đổi trái phép được phát hiện tự động

– Số lượng thay đổi trái phép được tìm thấy bằng cách kiểm toán bằng phần mềm cập nhật cấu hình tự động.

Số lỗi CMS

– Số lượng lỗi được tìm thấy trong CMS trong quá trình kiểm toán.

Knowledge Management

Quy trình quản lý kiến ​​thức tập hợp và phân tích thông tin được tạo ra trong quá trình chuyển đổi dịch vụ và các thành phần vòng đời khác. Mục đích chính của quy trình này là theo dõi và lập tức lập danh mục thông tin đã học ở các điểm quy trình khác nhau, để giảm lượng thời gian đi vào việc khám phá lại kiến ​​thức đã được tạo ra. Thông tin được phát hiện bởi quy trình quản lý tri thức được lưu trữ trong hệ thống quản lý kiến ​​thức dịch vụ, kho lưu trữ dữ liệu, thông tin và kiến ​​thức trung tâm thường được cung cấp bởi vô số nguồn dữ liệu. Quy trình quản lý tri thức tập trung mạnh vào việc duy trì nhận thức của khán giả mà thông tin và kiến ​​thức đang được thu thập và trình bày. Nếu bộ phận CNTT của bạn chịu trách nhiệm chuẩn bị báo cáo cho nhóm tiếp thị của bạn, thì họ sẽ yêu cầu thông tin và kiến ​​thức liên quan đến các hoạt động tiếp thị của họ. Nếu bạn cung cấp thông tin và kiến ​​thức cho khách hàng mua dịch vụ của bạn, thì họ cũng sẽ yêu cầu thông tin và kiến ​​thức độc đáo, chẳng hạn như giá cả của sản phẩm và cách sử dụng chúng.

Sự khác biệt giữa dữ liệu, thông tin, kiến thức và trí tuệ

Nó thường hữu ích khi dựa vào những gì mà người ta gọi là cấu trúc dữ liệu-thông tin-kiến thức-trí tuệ để hiểu bản chất của các thuật ngữ này khi chúng liên quan đến nhau. Dữ liệu chỉ đề cập đến sự khẳng định của một thực tế: Tàu sẽ đến ga trong năm phút. Thông tin yêu cầu bổ sung bối cảnh liên quan vào dữ liệu: Theo lịch trình, chuyến tàu được cho là đã đến mười phút trước; do đó, nó sẽ trễ mười lăm phút. Kiến thức đòi hỏi một phán đoán trừu tượng hơn nhưng đáng tin cậy về một tình huống: Chuyến tàu bị trễ vì kỹ sư đã không nỗ lực đủ để đúng giờ. Trí tuệ sử dụng kiến ​​thức để trau dồi những quan điểm và phân tích hấp dẫn và hữu ích về một chủ đề: Các kỹ sư bị trễ nên phải chịu hành động khắc phục.

Không có quy trình con hoặc KPI liên quan đến quy trình quản lý kiến ​​thức.

Các chuyên gia về chuyển đổi dịch vụ ITIL có thể hướng dẫn một hoạt động trong suốt quá trình khởi chạy một dịch vụ mới hoặc sửa đổi một dịch vụ cũ. Các thành phần chính của giai đoạn vòng đời này bao gồm quản lý các cân nhắc về công nghệ và rủi ro trong quá trình chuyển đổi. Trình độ chuyển tiếp dịch vụ có thể kiếm được thông qua việc hoàn thành khóa đào tạo và kỳ thi được công nhận.

Tóm lại:

  • Giai đoạn vòng đời chuyển tiếp dịch vụ ITIL cung cấp các thực tiễn tốt nhất để di chuyển các dịch vụ ra khỏi giai đoạn thiết kế và vào môi trường làm việc trực tiếp. Chuyển đổi dịch vụ cũng có thể được sử dụng để hỗ trợ ngừng hoạt động hoặc ngừng hoạt động dịch vụ.
  • Quy trình quản lý thay đổi của thiết kế dịch vụ ITIL là một trong những dịch vụ quan trọng và mạnh mẽ nhất trong ITIL.
  • Thành công trong chuyển đổi dịch vụ phụ thuộc vào nhận thức chính xác và chính xác về các tài sản CNTT có sẵn.
  • Việc chuyển đổi dịch vụ phải được tiến hành với nhận thức rằng việc thu thập dữ liệu âm thanh, kiến ​​thức và thông tin về dịch vụ là rất quan trọng.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *