itil in practice (public version)

ITIL IN PRACTICE

Lê Thành Trung

01/2014

Strictly Confidential – Do Not Distribute 2

GIỚI THIỆU

Strictly Confidential – Do Not Distribute

VỀ CÁ NHÂN

3

• Lê Thành Trung

– Senior Operation Manager

• Kinh nghiệm:

– 13 năm làm việc trong lĩnh vực IT

– 8 năm làm việc tại VNG

• 4 năm làm Software Development Manager

• 4 năm làm Operation Manager


VỀ VNG

4

• VNG là công ty hàng đầu Việt Nam trong lĩnh

vực Internet (www.vng.com.vn)

“Phát triển Internet để thay đổi cuộc sống

người Việt Nam”

http://www.vng.com.vn/


MỤC ĐÍCH

5

• Chia sẻ bài học và kinh nghiệm triển khai

quy trình vận hành (theo ITIL) tại VNG

– Service Desk

– Incident Management

– Configuration Management

– Change Management

– Problem Management

– Capacity Management

– Risk Management


QUÁ TRÌNH TRIỂN KHAI

6

• 2008 – Thành lập Operation Office

• 2009 – Triển khai hệ thống ITSM

• 2009 – Triển khai đào tạo ITIL V2

• 2009 – Áp dụng Incident Management

• 2009 – Ứng dụng Configuration Management

• 2010 – Áp dụng Change Management

2011 - Áp dụng Problem Management

Capacity Management

• 2013 – Áp dung Risk Management

• 2014 – Bắt đầu tiến hành áp dụng ITIL V3


1. THÀNH LẬP OPERATION OFFICE


VNG 2008

8

• ~ 200 Engineer

• ~15 products cho Game + Web Business

• ~ 5 Share Systems

• Tự vận hành Data center

– Hàng trăm server

– Sử dụng 1/2 bandwidth của toàn VN


TỔ CHỨC

9

Web Technical Operation

Game Business

Game Technical Operation

Web Business

Share Systems

Data Center

NOC Network Facility Server & Storage

Service Desk


TỔ CHỨC

10


Game Business


Web Business

Share Systems

Data Center

NOC Network Facility Server & Storage

Service Desk

?

? ?

? ?

?

Dept. Head

Technical Operation Team Leader

SE Level 1

SE Level 2

TỔ CHỨC

11

• Technical Operation Team

Product(s)

SE = System Engineer


VẤN ĐỀ

12

• Các nhóm hoạt động độc lập

• Trao đổi thông tin không tốt giữa

• Không rõ ràng về cam kết chất lượng và

escalation contact point

• Không có số đo về chất lượng vận hành

• Không tổng hợp được các vấn đề

• Không đánh giá được hiệu quả giải pháp

• Không có chiến lược chung về vận hành


OPERATION OFFICE

13

• 2008 – VNG có COO

• 2009 – Thành lập Operation Office

– Thiết lập các quy trình vận hành

– Triển khai các công cụ hỗ trợ vận hành

– Theo dõi chất lượng vận hành

– Nghiên cứu và thực hiện các cải tiến công

cụ/quy trình nhằm tăng chất lượng vận hành


NGUYÊN TẮC

14

Con người

Công cụ

Quy trình

Chất Lượng Vận Hành


THỰC HIỆN

15

• Thành lập Technical Operation Management

(TOM) Dept.

• Các nhóm vận hành sản phẩm báo cáo cho

COO

COO

Technical Operation

Teams Data Center Service Desk TOM

Ảnh hưởng thông qua Operation Processes &

Policy


THỰC HIỆN

16

• Quyết định sử dụng ITIL làm cơ sở để phát triển các quy trình vận hành

– ITIL là gì?

ITIL là tập các “best practices” (quy định, quy trình, checklist,…) giúp bộ phận IT cung cấp các dịch vụ IT (IT Services) phục vụ yêu cầu của Business

– IT Service là gì? Là các dịch vụ liên quan đến IT cung cấp bởi bộ phận IT.


ITIL V2

17


ITIL V2 - SERVICE SUPPORT

18

Duy trì khả năng liên tục , sẵn sàng và chất lượng của các dịch vụ IT đến End User


ITIL V2 - SERVICE DELIVERY

19

Đảm bảo khả năng quản lý các dịch vụ IT để luôn cung cấp cho khách hàng dịch vụ như cam kết


ITIL V2

20

• Ví dụ

Bộ phận IT quản lý hệ thống ERP và cung

cấp dịch vụ cấp quyền truy cập vào hệ

thống.

Cam kết SLA – Service Level Agreement

– Sau 8h sẽ tạo xong account và cấp quyền

cho User tính từ khi nhận được yêu cầu.

– Khó khăn trong việc truy cập vào hệ thống

sẽ được giải quyết trong vòng 4h

– Hệ thống Uptime 99%


ITIL V2

21

• Service Support

– Quy trình hỗ trợ khách hàng khi không thể đăng

nhập/sử dụng hệ thống (Incident Mng.)

– Quy trình ghi nhận nếu có các Incident lặp lại

nhiều lần để xử lý triệt để (Problem Mng.)

– Quy trình thông báo cho End User khi hệ thống

có thay đổi (Change Mng.)

– Quy trình kiểm soát đảm bảo việc cập nhật hệ

thống được Test kỹ trước khi thực hiện (Release

Mng.)


ITIL V2

22

• Service Delivery

– Quy trình kiểm tra định kỳ đảm bảo hệ thống

Uptime 99% (Availability Mng.)

– Quy trình kiểm tra đảm bảo có đủ capacity về

license cung cấp cho End User (Capacity Mng.)

– Quy trình kiểm tra đảm bảo khả năng khôi phục

lại hệ thống khi có sự cố (Continuity Mng.)

– Quy trình kiểm tra đảm bảo ngân sách cho dịch

vụ, cách hạch toán và phân bổ chi phí (Financial

Mng.)


2. LỰA CHỌN HỆ THỐNG ITSM


LỰA CHỌN HỆ THỐNG ITSM

24

• Hiện trạng

– Một số nhóm đã triển khai Incident Mng. Process

– Một số nhóm đã đi học ITIL

– Một số hệ thống quản lý thông tin vận hành đã có

• Nhu cầu

– Quản lý tập trung việc vận hành

– Triển khai thực tế các quy trình trên Tool

• Mục tiêu

– Lựa chọn hệ thống triển khai quy trình ITIL V2

– Chuẩn hóa quy trình áp dụng cho toàn bộ VNG

– Tránh thay đổi quá nhiều quy trình hiện tại



25

• Tiêu chí quan trọng

– Xây dựng theo chuẩn quy trình ITIL

– Có khả năng customize theo nhiều yêu

cầu (giao diện, quy trình, dữ liệu, biểu

mẫu, dữ liệu …)

– Hỗ trợ nhiều module/process để có thể

mở rộng theo nhu cầu tương lai

– Nằm trong ngân sách cho phép



26

• Các hệ thống được chọn

– Axios

– HP ITSM

– IBM Maximo

-> Lựa chọn: HP ITSM


TRIỂN KHAI

27

• Thống nhất quy trình chung

• Làm việc với đối tác triển khai

• Thực hiện UAT

• Hiệu chỉnh quy trình và thương lượng

• Đào tạo chuyển giao hệ thống

-> Kết quả 1 tháng triển khai

- Incident Management Process

- Change Management Process

- Service Request


TRIỂN KHAI

28

• Thuê chuyên gia đào tạo ITIL V2 cho 40

Senior Engineer

• Tuyển dụng bổ sung 1 Senior PQA

• Tập trung vào Service Support

Service Desk

Incident Management

Change Management

Configuration Management

• TOM quản lý hệ thống ITSM (vận hành/

cấu hình/ triển khai quy trình


3. SERVICE DESK


Những khách hàng khó tính nhất của bạn chính là những người giúp bạn học được nhiều bài học nhất


THAY ĐỔI TỔ CHỨC

31

• Tách Service Desk thành Dept. độc lập

• Nhiệm vụ hỗ trợ sản phẩm

– Theo dõi tình trạng kỹ thuật của sản phẩm

– Cung cấp thông tin tình hình xử lý incident

– Dịch vụ First Level Support xử lý Incident

– Đảm bảo thông tin về Incident được quản

lý chính xác và đầy đủ


THAY ĐỔI TỔ CHỨC

32


Game Business


Web Business

Share Systems

Data Center

NOC Network Facility Server & Storage TOM

Service Desk


NHÂN LỰC

33

• Service Desk

– Trực ca 24/7

– Tool Dev. Team

– System Operation

– Process Quality Assurance (PQA)


SERVICE DESK KPI

34

• % số Incident Service Desk tự xử lý được

• Số Incident không thể phát hiện bởi hệ

thống Monitor

• Số Incident không được xử lý theo đúng

hướng dẫn của First Level Support

• Đánh giá PQA về việc tuân thủ quy trình

của Service Desk

– Escalation Timescale

– Độ chính xác của thông tin

– …


GHI CHÚ

35

• Service Desk đóng vai trò “Cực Kỳ Quan

Trọng” trong việc triển khai ITIL & Process

• Service Desk Leader phải hướng đến khách

hàng và chất lượng dịch vụ.

• Service Desk tạo ra sức ép và động lực cho

các dịch vụ IT.

• Service Desk Leader luôn đặt ra yêu cầu

– Phân tích dữ liệu

– Xác định vấn đề

– Đề xuất các thay đổi.


4. INCIDENT MANAGEMENT


Chúng ta chỉ tin tưởng vào Chúa, còn lại đều phải chứng minh bằng số liệu.


INCIDENT

38

• Incident là sự gián đoạn không có kế

hoạch của một dịch vụ IT hoặc là ngưng

hoạt động của một thành phần dịch vụ mà

không làm ảnh hưởng đến dịch vụ.


YÊU CẦU

39

• Một quy trình quản lý Incident chung

• Kênh thông tin thống nhất về Incident

• Có thể quản lý toàn bộ thông tin về Incident

• Đưa ra các quy định để hạn chế ảnh hưởng

của Inc. tới Business

• Làm cơ sở để phân tích

–Nguyên nhân, xu hướng Incident

–Giải pháp hạn chế Incident & ảnh hưởng

–Đánh giá hiệu quả vận hành


QUY TRÌNH TƯƠNG TÁC

40


CÂU HỎI

41

• Giá trị của Incident Management với

Business?

• Giá trị của Incident Management đối với

Operation?


INCIDENT MANAGEMENT & BUSINESS

42

• Incident -> Downtime -> Impact Business

• Business Impact Metrics

– Số lượng User (CCU)

– Thời gian ko truy cập đến được dịch vụ

– …

• Thiết lập 5 level cho incident

– Level 1 = level cấp cao nhất

– Level 5 = level cấp thấp nhất

– Level 6 = có incident nhưng ko gây impact


INCIDENT MANAGEMENT & OPERATION

43

• Thống kê số liệu

– Nhóm incident và số lượng

– Nhóm Incident gây impact nhiều cho

business -> Xác định giải pháp xử lý

– Áp dụng giải pháp -> Đo hiệu quả


INCIDENT MANAGEMENT & OPERATION

44

• Phân nhóm Incident theo

category & sub category

• Phân nhóm Incident theo loại Controllable

& Non-controllable

Category

Can’t Identify

Human

Security

Software

CDN

Virtualization

Server

Network

Facility


INCIDENT ANALYSIS SAMPLE

45

0

20

40

60

80

100

120

140

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 4 1 2 3 4 2 3 3 1 4

Software Network N/A Management Facility Hardware Security Vendor Capacity

Incident root cause trend (by area)


INCIDENT MANAGEMENT & TEAMS

46

Service Desk

Functional Teams

Customer Support

Management Teams

Product Tech. Operation

Teams


INCIDENT MANAGEMENT & TEAMS

47

Service Desk

Functional Teams

Customer Support

Management Teams

Product Tech. Operation

Teams

Chịu trách nhiệm thu thập và nhập thông tin chính xác về quá

trình xử lý incident

Hỗ trợ bộ phận sản phẩm khắc phục incident hoặc xử lý incident

Chịu trách nhiệm cập nhật thông tin cách xử lý và nguyên nhân

của incident Làm báo cáo về incident

Các team đều chịu chung KPI là Incident Downtime

-> tăng mức độ hợp tác


INCIDENT MANAGEMENT POLICY

48

• Escalation Path & Time scales

– Service Desk: 15-60 phút đánh giá inc.

– Engineer Level 1: 60-90 phút để xử lý level 1

– Engineer Level 2: 60-90 phút để xử lý level 2

– High Level Manager: 15-60 phút (inc. level 1,2)

• Incident Close

– Incident phải chuyển trạng thái Close sau 72h

– Team Leader là người thực hiện Close và xác

định root cause, solution/workaround


INCIDENT MANAGEMENT POLICY

49

• Critical Incident Analysts – CIA Team

– Nhóm nhân sự có chuyên môn cao lĩnh vực kỹ

thuật

– Bắt buộc Technical Operation Team liên quan

đến Inc. Level 1,2 phải làm báo cáo, gửi cho CIA

– Tổ chức review phân tích và rút kinh nghiệm

– Đưa ra các action để ngăn ngừa Inc. lặp lại

• TOM theo dõi quá trình tổ chức và thực hiện

theo action


LIÊN KẾT INCIDENT

50

• 1 Incident có thể tạo ra nhiều incident liên

quan ảnh hưởng đến nhiều sản phẩm

• 1 incident có thể gây ra do 1 Change

• 1 incident có thể link tới Problem và Known

Error

-> Operation Team Leader tạo link đến Inc.

Note:

– Liên kết Incident với CI (server, network switch, …) sẽ

giúp có dữ liệu tốt hơn.


CÁC HỆ THỐNG PHÁT SINH

51

• Service Desk

– Monitoring & Alert

– Incident Ticket Open Tool

– Contact Management

– Call center Integration

– Customer Support System Integration

– Knowledge Base Management

• Product Team & Tech. Operation Team

– Incident Data Analysis (Excel)


INCIDENT MANAGEMENT & KPI

52

• Số lượng incident gây ra ảnh hưởng

đến toàn bộ sản phẩm

• Số lượng incident level 1,2

• Số lượng incident liên quan đến

security

• Thời gian downtime & ảnh hưởng tới

business (CCU, …)

INCIDENT MANAGEMENT & CSF

53

• Service Desk Team

– Phải hiểu rõ nhiệm vụ & trách nhiệm

– Chịu khó trong việc nhập dữ liệu chính xác

– Tuân thủ chính xác quy định về xử lý Incident

– Leader hiểu biết về Soft. Dev. & Data Analysis

• Product Operation Team

– Hiểu trách nhiệm

– Set KPI để phối hợp chặt chẽ với Service Desk

– Trung thực và có khả năng phân tích root cause &

action plan

• CIA

– Có khả năng review và phản biện với Operation Team


5. CONFIGURATION MANAGEMENT


Data are of high quality "if they are fit for their intended uses in operations, decision making, and planning" Joseph M. Juran

Dữ are được coi là có chất lượng “khi nó đáp ứng nhu cầu sử dụng trong vận hành, ra quyết định và lập kế hoạch"


YÊU CẦU

56

• Xây dựng hệ thống quản lý dữ liệu phục vụ cho các hoạt động vận hành

– Xác định mức độ ảnh hưởng của CI khi có Inc.

– Dự đoán mức ảnh hưởng của CI khi thực hiện Change

– Có thông tin đánh giá khi thực hiện Release

– Đánh giá rủi ro của CI trong vận hành

– Dữ liệu cơ sở để làm capacity planning & capacity optimization


HP Universal CMDB

57

CMDB = Configuration Management Database

Network Configuration Layer


CMDB

58

Infrastructure & Data center Layer

Facility Equipment &

linkages

Network Equipment &

linkages Rack Cables …

Server & Storage Layer

Physical Server Storage Virtual Server VLAN ACL

Product Layer

Server Configuration

IP/MAC OS

Bandwidth

Service/ Software

System Linkages

Configuration Item (CI)


VAI TRÒ CỦA CMDB

59

• CMDB là nguồn thông tin quan trọng cho

vận hành

• Không có CMDB thì như mù khi vận hành

• Có CMDB nhưng dữ liệu không được cập

nhật thì vận hành mà luôn có rủi ro


QUẢN LÝ CMDB

60

• Việc thu thập dữ liệu cập nhật 1 lần vào CMDB là không đủ tốt

• Đưa các activity cập nhật CMDB vào quy trình

– Change Management

– Service Request/ Request Fulfillment

– …

• Cập nhật thủ công sẽ có sai sót

-> Sử dụng PQA để thực hiện audit dữ liệu

• Triển khai tool tự động cập nhật CMDB -> Khó thực hiện + Đắt tiền


QUẢN LÝ CMDB

61

Kết luận

• CMDB khó đảm bảo chính xác 100%

• Cần có cách thức quản lý và Audit để

đánh giá mức độ chính xác của dữ liệu

• Cần gắn trách nhiệm của mỗi bộ phận với

một loại dữ liệu cụ thể


QUẢN LÝ CMDB

62


MÔ HÌNH fCMDB & MDR

63

fCMDB

MDR 2 MDR 1 MDR 3 MDR 4

fCMDB = Federal CMDB MDR = Master Data Repository

MDR 1 Information

Mng. Process

MDR 2 Information

Mng. Process

MDR 3 Information

Mng. Process

MDR 4 Information

Mng. Process


MÔ HÌNH fCMDB & MDR

64

• Tạo ra sự tự do cho các tool quản lý thông

tin ở từng nhóm vận hành & phân trách

nhiệm

• Đồng bộ dữ liệu về CMDB tập trung

• Thực hiện các phân tích chung tại CMDB

không ảnh hưởng đến các MDR


CMDB & CSF

65

• Các bộ phận hiểu rõ tầm quan trọng của dữ

liệu CMDB trong vận hành

• Hướng tới việc cập nhật dữ liệu tự động

• Có chiến lược quản lý dữ liệu CMDB bằng

cách đưa activity trong process và phân

trách nhiệm theo nhóm

• PQA có hiểu biết về các dữ liệu và phương

pháp quản lý để Audit dữ liệu chính xác


6. CHANGE MANAGEMENT


Không phải loài mạnh nhất cũng như thông minh nhất là có thể tồn tại mà chính là loài có khả năng thích nghi nhất với sự thay đổi.


CHANGE

68

• Là sự bổ sung, sửa đổi hoặc loại bỏ bất cứ

cái gì (kiến trúc, quy trình, công cụ,

metrics, tài liệu, hoặc các CI …) có làm

ảnh hưởng đến dịch vụ IT


YẾU CẦU

69

• Đưa ra một quy trình chung cho toàn bộ

các Change

• Tạo ra một kênh thông tin chung nhất cho

các Change

• Tạo ra các quy định và cách giám sát

(control) để đảm bảo Change

– Được phê duyệt bởi các cấp có thẩm quyền

– Được xem xét kỹ trước khi thực hiện


QUY TRÌNH

70


CÂU HỎI

71

• Giá trị của Change Management với

Business?

• Giá trị của Change Management đối

với Operation?


CHANGE MANAGEMENT & BUSINESS

72

• Giúp Engineer hiểu được ảnh hưởng

của các Change đối với Business

• Engineer có trách nhiệm và chủ động

đánh giá, lập kế hoạch cho các Change -> giảm thiểu ảnh hưởng đối với Business

• Thiết lập các quy định nhằm hạn chế tối

đa các ảnh hưởng của Change đối với

Business


CHANGE MANAGEMENT & OPERATION

73

• Giúp Engineer hiểu được trách nhiệm

và quyền hạn khi thực hiện hoặc phê

duyệt Change

• Quản lý và thông tin về Change và

cập nhật cho các bên liên quan

• Quản lý và đánh giá rủi ro cho các

Change

• Quản lý cập nhật thông tin vào CMDB

đối với các Change



74

• Phân loại Change theo Level

• Change level được xác định dựa trên

level Incident mà Change có thể gây

ra

• Change level 1,2 cần được phê duyệt

bởi CAB (Change Advisory Board)

• Change level 3,4 được phê duyệt bởi

Team Leader



75

• Thiết lập quy định cho việc phê duyệt

change & theo nhu cầu business.

– Emergency Change (CAB phê duyệt +

thực hiện ngay)

– Standard Change (12h-5 ngày)

• VD:

– Không thực hiện Change vào giờ cao điểm

– Không thực hiện liên tiếp các Change Level

1,2 trong 1 tuần


CHANGE MANAGEMENT & COMMUNICATION

76

• Technical Operation Team mở Change Request

• Service Desk thông báo Change với các bên liên quan

• TOM sẽ tổ chức CAB review cho các change level 1,2

• Team Leader -> Close Change

• Change quá thời gian quy định -> Service Desk mở Incident và link đến Change


CHANGE MANAGEMENT & CAB

77

• CAB phê duyệt Change, phản biện các

giải pháp kỹ thuật

– Đảm bảo các Change được chuẩn bị trước

– Đảm bảo đánh giá chính xác rủi ro

– Các kế hoạch phải được lên chi tiết

– Có phương pháp kiểm tra lại kết quả khi

Change

– Có kế hoạch backup nếu Change thất bại


CHANGE MANAGEMENT & CAB

78

• Technical Operation Team phải

chuẩn bị tài liệu kỹ thuật

–Sơ đồ hệ thống

–Cấu hình thiết bị

–Báo cáo kết quả test

–Kế hoạch Change


CHANGE MANAGEMENT & KPI

79

• Số lượng Change gây ra Incident và

Impact đến Business

• Số lượng Change không tuân thủ

theo quy trình

• Kết quả Audit của PQA cho việc tuân

thủ đúng quy trình Change

Management


CHANGE MANAGEMENT & CSF

80

• Product Operation Team

– Hiểu rõ trách nhiệm và ảnh hưởng đến Business

nếu không thực hiện theo Change Process

• CAB

– Có đủ khả năng phản biện với Product Operation

Team

• TOM

– Hỗ trợ các team hiểu quy định và thực hiện theo

đúng quy trình Change

– Giúp các team chuẩn bị đầy đủ tài liệu trước khi

vào review với CAB


7. PROBLEM MANAGEMENT


Robert H. Schuller

Problems are not stop signs, they are guidelines.

Các vấn đề không phải là điểm kết thúc mà nó là những hướng dẫn (của bắt đầu).


PROBLEM

83

• Problem là nguyên nhân (cause) gây

ra nhiều Incident hoặc Incident có

ảnh hưởng đến nhiều User


MỤC TIÊU

84

• Thiết lập quy trình thực hiện

– Phân tích các Incident để xác định

Problem.

– Theo dõi, xử lý Problem để

• Hạn chế việc lặp lại các Incident hoặc

• Ngăn ngừa các Incident ảnh hưởng đến nhiều

User lặp lại

Incident Problem Workaround Known Error


QUY TRÌNH

85


XÁC ĐỊNH PROBLEM

86

• Mỗi Technical Operation Team chỉ định 1

người giữ vai trò Prolem Manager

• Định kỳ Problem Manager phân tích các

Incident để xác định Problem, Root cause,

Workaround và Known Error

• Problem Manager đưa ra action plan để

xử lý hoặc ngăn ngừa Known Error xảy ra



87

• Sử dụng phân tích Pareto xác định nhóm

nguyên nhân Incident

• Đặt câu hỏi “WHY” trên các nguyên nhân

để tìm hiểu sâu

• Sử dụng phân tích sơ đồ xương cá


88


CÂU HỎI

89

• Giá trị của Problem Management với

Business?

• Giá trị của Problem Management đối

với Operation?


PROBLEM MANAGEMENT & BUSINESS

90

• Giải quyết triệt để Inc. -> Ổn định hoạt

động Business

• Khó thấy được giá trị của Problem

Management đối với Business

- > Operation Team không có nhiều động lực

để thực hiện


PROBLEM MANAGEMENT & OPERATION

91

• Problem Management giúp giải quyết triệt để

các Incident lặp lại -> hiệu quả về nhân lực

Incident rơi vào 2 trường hợp

- Incident ảnh hưởng đến nhiều User -> đã

được xử lý theo Incident Mng. Process

- Incident lặp lại -> phụ thuộc vào Vendor

Kết luận

• Problem Management khó phát huy hiệu quả


8. CAPACITY MANAGEMENT


Mong chờ kết quả tốt nhất Chuẩn bị cho khả năng xấu nhất


MỤC TIÊU

94

• Thiết lập quy trình quản lý capacity để

đảm bảo các sản phẩm có đủ capacity

(server, network bandwidth, …) phục vụ

business


CAPACITY MANAGEMENT

95

• Định kỳ hàng quý, các Technical Operation

Team thực hiện review lại capacity của

product và báo cáo

Business Requirement

Capacity Profile

Capacity Report

Capacity Plan


CÂU HỎI

96

• Giá trị của Capacity Management với

Business?

• Giá trị của Capacity Management đối

với Operation?


CAPACITY MANAGEMENT & BUSINESS

97

• Engineer luôn plan over capacity cho

trường hợp “the worst”

• Business luôn nghĩ tới trường hợp “the

best”

-> Khó đánh giá hiệu quả của Capacity

Management cho Business


CAPACITY MANAGEMENT & OPERATION

98

• Capacity cho biết tình hình sử dụng tài

nguyên cho sản phẩm

• Operation bị ảnh hưởng bởi yêu cầu

Business

• Operation luôn chuẩn bị tài nguyên tốt

nhất cho Business

-> Engineer ko có động lực nhiều trong việc

thực hiện Capacity Management


9. RISK MANAGEMENT


The more we think about risk, the more risk seem to be.

Ben Carson

Càng nghĩ nhiều về rủi ro thì càng có nhiều rủi ro (có thể xảy ra)


YÊU CẦU

101

• Triển khai phương pháp đánh giá và

quả lý rủi ro (Risk) cho việc vận hành

kỹ thuật.

• Quản lý rủi ro tốt sẽ giúp việc vận

hành chủ động (proactive) hơn.

• Phương pháp đánh giá – Không quá phức tạp

– Phù hợp với hoạt động vận hành


TRIỂN KHAI

102

• Nghiên cứu các Risk Managemet

Framework và lựa chọn

– COBIT


TRIỂN KHAI

103

• Nghiên cứu các phương pháp đánh giá

- FMEA (Failure Mode and Effects Analysis)

- FAIR (Factor Analysis of Information Risk)

FMEA áp dụng cho đánh giá Risk của Process

FAIR áp dụng cho đánh giá Risk theo các yếu

tố trong vận hành (Factors)


TRIỂN KHAI

104

• Đánh giá Risk theo FMEA -> Khó + Không

phù hợp

• Đánh giá Risk theo Factor

-> Cần có template và Factor chuẩn

COBIT Risk IT Practitioner Guide


RISK & CONTROL

105

• Xác định các Asset

• Xác định các Risk liên quan đến Asset

• Xác định các Control để giảm nhẹ/ngăn

ngừa Risk

Assets Risks Controls



106



107


ĐÁNH GIÁ RISK

108

• Xác định ảnh hưởng của Risk tới Business

– Downtime

– %Business Interruption

– CCU Lost

– …

• Xây dựng bảng đánh giá khả năng/tần xuất xảy ra của Risk

– Tùy thuộc từng loại business

• Xây dựng metrics của Risk Rating

• Xây dựng metrics Risk Response


RISK ASSESSMENT TEMPLATE

109


RISK ASSESSMENT TEMPLATE

110


RISK CONTROL TEMPLATE

111


RISK CONTROL TEMPLATE

112


CÂU HỎI

113

• Giá trị của Risk Management với

Business?

• Giá trị của Risk Management đối với

Operation?


RISK MANAGEMENT & BUSINESS

114

• Xác định các rủi ro để có kế hoạch

giảm thiểu ảnh hưởng tới Business

• Đánh giá các rủi ro và mức độ ảnh

hưởng để xác định hiệu quả các chi

phí đầu tư ngăn ngừa rủi ro.

• Có phân tích cụ thể để xác định đầu

tư giảm thiểu rủi ro cho Business


RISK MANAGEMENT & OPERATION

115

• Xác định rủi ro và chủ động thực hiện giải pháp ngăn ngừa Inc.

• Có kế hoạch phòng ngừa hoặc khắc phục nếu rủi ro xảy ra

• Yêu cầu Review Risk/Control Data khi có Inic. và Change giúp liên tục cập nhật Risk Status

-> Tăng tính chủ động trong vận hành


RISK MANAGEMENT & PROCESS KHÁC

116

Thực hiện Control

Risk Assessment (Hàng Quý)

Incident Management

Change Management

Risk & Control Data


RISK MANAGEMENT & KPI

117

• Tỉ lệ % số Risk được control

• Số incident xảy ra do control không

hiệu quả


RISK MANAGEMENT & CSF

118

• Các team vận hành phải hiểu rõ ý nghĩa

của việc đánh giá rủi ro

• Người thực hiện đánh giá rủi ro phải có

hiểu biết tốt về asset cần đánh giá

• Người review cần có kiến thức tốt để phản

biện về risk data và ảnh hưởng

• Các control được chuẩn hóa theo các

process vận hành (Change Mng., Capacity

Mng., Incident Mng.)


10. BÀI HỌC KINH NGHIỆM


CAM KẾT

120

• Lãnh đạo cấp cao phải có cam kết

thực hiện

–Triển khai KPI

–Xem báo cáo phân tích

–Tham gia họp định kỳ

–Yêu cầu các team phối hợp thực hiện


CÁC BƯỚC TRIỂN KHAI

121

• Lựa chọn hệ thống ITSM

• Service Desk

• Incident Management

• Change Management

• Risk Management

– Capacity Management

– Problem Management

– …


TEAMS

122

• Cần có team dành toàn bộ cho việc

– Phát triển và duy trì process/policy

– Đào tạo Process

– Đưa Process vào hệ thống ITSM

– PQA

– Làm báo cáo định kỳ về tình hình tuân

thủ process trong vận hành


KPI

123

• Toàn bộ các team vận hành cần chia sẻ KPI liên quan đến

– Incident

– Downtime

– Kết quả Audit việc tuân thủ Process của PQA

– …

-> Tạo ra thống nhất trong việc áp dụng process

• Dữ liệu phải được thu thập chính xác, khách quan để đánh giá KPI


TIẾP CẬN TRIỂN KHAI

124

• PQA phải bắt đầu bằng mindset là support

các team vận hành áp dụng quy trình

• PQA cũng cần độc lập và chính xác trong

việc phân tích dữ liệu

• PQA phải có kiến thức và hiểu rõ việc vận

hành sản phẩm để có đánh giá chính xác

và khách quan

• Luôn hướng tới việc tạo nhận thức cho

các team về giá trị của các Process


THEO DÕI TRIỂN KHAI

125

• TOM định kỳ theo dõi các action plan

(Incident/ Change/ Risk Management)

để đảm bảo các team thực hiện.

• Có số liệu thống kê tình hình Incident

và các chỉ số KPI cần thiết để các

team nắm rõ thông tin và hiểu rõ

trách nhiệm


11. Q&A


Q&A


12. ITIL V3


ITIL V3

129

• Chuyển mô hình Platform Infrastructure

theo mô hình hướng Service

– Quản lý SLA

– Quản lý Service Cost

Sẽ tiếp tục chia sẻ


13. HUẤN LUYỆN


NỘI DUNG

131

• Cách thức xây dựng các quy trình

• Lựa chọn ITSM Tool

• Sử dụng các Template

• Thiết lập các tham số (parameters)

• Thiết lập KPI

• Triển khai quy trình vào thực tế

• PQA: Phân tích dữ liệu và Báo cáo

• Lựa chọn và đào tạo nhân sự


XIN CÁM ƠN!

CHÚC MỪNG NĂM MỚI 2014

itil in practice (public version)

Documents