7 bài học sáng tạo từ leonardo da vinci
TRANSCRIPT
7 bài học sáng tạo từ Leonardo Da Vinci1book.vn December 5, 2013 Phòng đọc, Truyện, Truyện hay cuộc sống No CommentHọa sỹ thiên tài người Ý không những sở hữu ý tưởng và kỹ năng tuyệt vời, mà
ông còn có khả năng tìm kiếm sự khác biệt đối với thế giới.
Chắc chắn có thể nói rằng kể từ khi Leonardo da Vinci mất đi, thế giới tuyệt nhiên
không thể có một người thứ 2 như ông ấy.
Trong khi tên tuổi của ông gắn liền với những nhân vật cùng nghề huyền thoại như
Mona Lisa, The Last Supper or Vitruvian Man, Leonardo da Vinci dường như sở hữu
nhiều những khả năng hơn. Thực tế, ông ấy là một kỹ sư, nhà soạn nhạc, nhà toán
học, kiến trúc sư, phát minh, chuyên gia về giải phẫu học, địa chất…
Tóm lại, ông ấy là một thiên tài.
Michael Gelb – đã viết 13 quyển sách nói về sự sáng tạo và đổi mới. Trong đó, cuốn
sách nổi tiếng nhất là “How to Think Like Leonardo da Vinci: Seven Steps to Genius
Every Day,” (Làm thế nào để suy nghĩ giống Leonardo da Vinci: 7 bước trở thành thiên
tài mỗi ngày) đã được bán trên 500 nghìn bản và được phiên dịch tới hơn 120 quốc gia
trên thế giới.
Gelb nói rằng sự thành công của cuốn sách đến từ những nghiên cứu về tài liệu của
Leonardo. Cùng với tất cả tài năng khác của mình, Leonardo đã viết ra rất nhiều và đưa
vào 13.000 trang ghi chú và bản vẽ. Sau đây là những điều mà Gelb đã nghiên cứu về
Leonardo để tạo nên sự sáng tạo.
Sự tò mò: Vốn dĩ con người ta sinh ra đã có sự tò mò, nhưng điều này sẽ bị “ăn mòn”
theo thời gian.“Hầu hết tất cả trẻ em đều có rất nhiều câu hỏi. Đó là lý do tại sao, trong
khoảng 5 năm đầu tiên, trẻ em tiếp thu được rất nhiều kiến thức. Nhưng sau đó, chúng
ta đưa chúng vào trường, nơi dạy chúng biết rằng câu trả lời quan trọng hơn là câu
hỏi,” theo Gelb.
Tuy nhiên, những người thiên tài như Da Vinci, họ duy trì một sự đam mê, tò mò trong
suốt cuộc sống của mình.
Suy nghĩ độc lập: Sự độc lập trong suy nghĩ là yếu tố quan trọng cho sự sáng tạo và
đổi mới mà tại đó chính là điểm để bạn tạo nên sự khác biệt.
Vấn đề ở đây là mọi người thường có xu hướng nghe theo những ý kiến của các
chuyên gia, và gần như mặc định đó là phương án tốt nhất. Vì vậy, càng trở thành
những chuyên gia, bạn càng phải biết cách tiếp thu những ý kiến khác nhau. Sau đó,
việc chọn lọc các ý kiến và đưa ra những ý tưởng là lúc thể hiện sự độc lập trong suy
nghĩ của bạn.
Vận dụng các giác quan: Trong công việc, sự lắng nghe và quan sát luôn được
khuyến khích, tuy nhiên, dường như những lời khuyên đơn giản thật khó để lắng nghe
khi mà xung quanh bạn có quá nhiều sự phân tâm.
“Người Ý có la dolce vita, với tình cảm ngọt ngào. Người Pháp có joie de vivre, niềm vui
của cuộc sống,” Gelb nói.
Nói về những quan niệm và những điều xảy ra ngay bây giờ, không chỉ giúp bạn có
nhiều sự sáng tạo hơn mà còn giúp nội dung dễ dàng kết nối với cuộc sống.
Gelb giúp người kinh doanh tốt hơn trong việc kết hợp với các giác quan của mình
bằng cách đào tạo biết cách đánh giá cái đẹp. Ông thực hiện điều này bởi khi họ nghe
nhạc, thưởng thức nghệ thuật, họ sẽ biết cách để tạo nên sự sáng tạo riêng cho mình.
Không quá chắc chắn về bất cứ điều gì: Sự tự tin khi thực hiện một dự án là một
nguyên tắc quan trọng của nhà lãnh đạo. Nhưng đừng quá chắc chắn về những gì
mình biết, bởi chính điều này giới hạn sự sáng tạo của bạn.
Cân bằng giữa suy luận và thực tiễn : Ngày trước, người ta phân chia việc những
người có bán cầu não phải phát triển hơn sẽ thiên về sáng tạo, tưởng tượng, trong khi
bán cầu não trái phụ trách sự tính toán và suy luận. Ngày nay, bạn có cả 2 thứ.
Để mọi người có thể sử dụng hài hòa cả 2 bán cầu, Gelb dạy cho họ biện pháp “Bản đồ
tâm trí”, một cách tổ chức những ý tưởng tích hợp sự suy luận và trí tưởng tượng, giúp
mọi người tạo nên những ý tưởng hay hơn trong thời gian ngắn hơn.
Để làm điều đó, bạn bắt đầu bằng cách vẽ một cái gì đó đại diện cho chủ đề bạn đang
suy nghĩ. Từ đó bạn tạo nên những liên kết tới sản phẩm trung tâm. Ví dụ, một củ hành
bạn sẽ liên tưởng đến rau quả. Cà rốt khiến bạn nghĩ tới con thỏ và con mèo….
Gelb nói “Làm cho đến khi thành phản xạ và vượt qua sự phán xét của mọi người.
Chính điều này giúp đánh thức sự hoạt động của một trong hai bán cầu não, vốn dĩ bị
“ngủ” quên quá lâu.”
Cân bằng giữa trạng thái và thể trạng : Bạn có thể không biết rằng Leonardo là một
vận động viên đặc biệt, được biết đến rộng rãi như là người đàn ông khỏe nhất ở
Florence và một vận động viên tài năng, tay kiếm, và cưỡi ngựa.
“Chúng tôi nghĩ rằng sự sáng tạo như một bài tập trí tuệ nhưng nó đòi hỏi năng lượng
rất lớn. Học cách nuôi dưỡng năng lượng cuộc sống của bạn để phục vụ cho những
điều trên” Gelb nói.
Tạo nên sự kết nối mới: Tất nhiên dù bất cứ ai cũng rất khó khăn trong việc tạo ra
những kết nối mới, nhưng làm như vậy là chìa khóa cho sự sáng tạo. Một lần nữa,
Gelb thích sử dụng “Bản đồ tâm trí”, mặc dù phải mất một thời gian để luyện tập.
“Lúc đầu, mọi người cảm thấy rất lộn xộn, mất thời gian, tuy nhiên, việc làm này tạo ra
rất nhiều các từ khóa và hình ảnh với các hướng khác nhau”, ông nói.
Kết luận
Bạn có thể là một người có tài năng sáng tạo bẩm sinh, được rèn luyện trong một môi
trường tuyệt vời, hoặc bạn sẽ học cách sáng tạo của người khác và biến nó thành của
mình (tất nhiên không copy 100%).
Con người ai cũng có thể sáng tạo, vậy nên đừng ép mình vào bất kỳ khuôn khổ nào
hoặc coi ý kiến của một cá nhân hay tập thể là hoàn toàn đúng.
Hãy nhường chỗ cho sự tư duy và suy nghĩ đổi mới!
Theo SINH VIÊN VIỆT NAM- See more at: http://1book.vn/7-bai-hoc-sang-tao-tu-leonardo-da-vinci/#sthash.VUkKmStx.dpuf
1. ITIL IN PRACTICE Lê Thành Trung 01/2014
2. GIỚI THIỆU Strictly Confidential – Do Not Distribute 2
3. VỀ CÁ NHÂN • 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
Strictly Confidential – Do Not Distribute 3
4. VỀ VNG • 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” Strictly Confidential – Do Not Distribute 4
5. MỤC ĐÍCH • 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 Strictly
Confidential – Do Not Distribute 5
6. QUÁ TRÌNH TRIỂN KHAI • • • • • • 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 Strictly
Confidential – Do Not Distribute 6
7. 1. THÀNH LẬP OPERATION OFFICE Strictly Confidential – Do Not
Distribute 7
8. VNG 2008 • • • • ~ 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 Strictly Confidential – Do Not
Distribute 8
9. TỔ CHỨC Web Business Game Business Service Desk Game
Technical Operation NOC Share Systems Network Facility Web Technical
Operation Server & Storage Data Center Strictly Confidential – Do Not
Distribute 9
10. TỔ CHỨC Game Business ? Service Desk Web Business ? Game
Technical Operation ? Share Systems ? ? Web Technical Operation ?
NOC Network Facility Server & Storage Data Center Strictly Confidential –
Do Not Distribute 10
11. TỔ CHỨC • Technical Operation Team Dept. Head Technical
Operation Team Leader SE Level 1 Product(s) SE Level 2 SE = System
Engineer 11
12. VẤN ĐỀ • 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 Strictly Confidential – Do Not Distribute 12
13. OPERATION OFFICE • 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 Strictly
Confidential – Do Not Distribute 13
14. NGUYÊN TẮC Quy trình Chất Lượng Vận Hành Công cụ Con người
Strictly Confidential – Do Not Distribute 14
15. THỰC HIỆN • 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 Ảnh hưởng
thông qua Operation Processes & Policy TOM Strictly Confidential – Do
Not Distribute Technical Operation Teams Data Center Service Desk 15
16. THỰC HIỆN • 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. Strictly Confidential – Do Not Distribute 16
17. ITIL V2 Strictly Confidential – Do Not Distribute 17
18. ITIL V2 - SERVICE SUPPORT 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 Strictly Confidential – Do Not
Distribute 18
19. ITIL V2 - SERVICE DELIVERY Đả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 Strictly
Confidential – Do Not Distribute 19
20. ITIL V2 • 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% Strictly Confidential – Do Not
Distribute 20
21. ITIL V2 • 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.) Strictly Confidential – Do Not Distribute 21
22. ITIL V2 • 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.) Strictly Confidential – Do Not
Distribute 22
23. 2. LỰA CHỌN HỆ THỐNG ITSM Strictly Confidential – Do Not
Distribute 23
24. LỰA CHỌN HỆ THỐNG ITSM • 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 Strictly
Confidential – Do Not Distribute 24
25. LỰA CHỌN HỆ THỐNG ITSM • 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 Strictly Confidential – Do Not Distribute 25
26. LỰA CHỌN HỆ THỐNG ITSM • Các hệ thống được chọn – Axios – HP
ITSM – IBM Maximo -> Lựa chọn: HP ITSM Strictly Confidential – Do Not
Distribute 26
27. TRIỂN KHAI • 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 Strictly
Confidential – Do Not Distribute 27
28. TRIỂN KHAI • 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 Strictly Confidential – Do Not
Distribute 28
29. 3. SERVICE DESK Strictly Confidential – Do Not Distribute 29
30. 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 Strictly Confidential – Do Not Distribute
30
31. THAY ĐỔI TỔ CHỨC • 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
đủ Strictly Confidential – Do Not Distribute 31
32. THAY ĐỔI TỔ CHỨC Web Business Game Business Service Desk
Game Technical Operation TOM NOC Share Systems Network Web
Technical Operation Facility Server & Storage Data Center Strictly
Confidential – Do Not Distribute 32
33. NHÂN LỰC • Service Desk – Trực ca 24/7 – Tool Dev. Team – System
Operation – Process Quality Assurance (PQA) Strictly Confidential – Do
Not Distribute 33
34. SERVICE DESK KPI • % 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 –… Strictly Confidential – Do Not Distribute 34
35. GHI CHÚ • 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. Strictly Confidential – Do
Not Distribute 35
36. 4. INCIDENT MANAGEMENT Strictly Confidential – Do Not Distribute
36
37. 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. Strictly Confidential – Do Not Distribute 37
38. INCIDENT • 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ụ. Strictly Confidential – Do Not Distribute 38
39. YÊU CẦU • • • • 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 Strictly Confidential – Do Not
Distribute 39
40. QUY TRÌNH TƯƠNG TÁC Strictly Confidential – Do Not Distribute 40
41. CÂU HỎI • Giá trị của Incident Management với Business? • Giá trị của
Incident Management đối với Operation? Strictly Confidential – Do Not
Distribute 41
42. INCIDENT MANAGEMENT & BUSINESS • 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 Strictly Confidential – Do Not Distribute 42
43. INCIDENT MANAGEMENT & OPERATION • 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ả Strictly
Confidential – Do Not Distribute 43
44. INCIDENT MANAGEMENT & OPERATION • Phân nhóm Incident theo
category & sub category Category Can’t Identify Human Security Software
CDN Virtualization Server Network Facility • Phân nhóm Incident theo loại
Controllable & Non-controllable Strictly Confidential – Do Not Distribute 44
45. INCIDENT ANALYSIS SAMPLE Incident root cause trend (by area)
140 120 100 80 60 40 20 0 1 2 3 Software 4 1 2 3 Network Strictly
Confidential – Do Not Distribute 4 1 2 3 N/A 4 1 2 3 Management 4 1 4
Facility 1 2 3 Hardware 4 2 3 3 1 4 Security Vendor Capacity 45
46. INCIDENT MANAGEMENT & TEAMS Functional Teams Product Tech.
Operation Teams Service Desk Customer Support Management Teams
Strictly Confidential – Do Not Distribute 46
47. INCIDENT MANAGEMENT & TEAMS Hỗ trợ bộ phận sản phẩm khắc
phục incident hoặc xử lý incident Product Tech. Operation Teams 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 Strictly Confidential – Do Not Distribute Functional
Teams Service Desk Management 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 Customer Support Các
team đều chịu chung KPI là Incident Downtime -> tăng mức độ hợp tác 47
48. INCIDENT MANAGEMENT POLICY • 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 Strictly Confidential – Do Not
Distribute 48
49. INCIDENT MANAGEMENT POLICY • 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 Strictly Confidential – Do Not Distribute 49
50. LIÊN KẾT INCIDENT • 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. Strictly Confidential – Do Not Distribute 50
51. CÁC HỆ THỐNG PHÁT SINH • 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)
Strictly Confidential – Do Not Distribute 51
52. INCIDENT MANAGEMENT & KPI • 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, …) Strictly Confidential – Do Not Distribute 52
53. INCIDENT MANAGEMENT & CSF • 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 53
54. 5. CONFIGURATION MANAGEMENT Strictly Confidential – Do Not
Distribute 54
55. Joseph M. Juran Data are of high quality "if they are fit for their
intended uses in operations, decision making, and planning" 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" Strictly Confidential – Do Not Distribute 55
56. YÊU CẦU • 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 Strictly Confidential –
Do Not Distribute 56
57. HP Universal CMDB Strictly Confidential – Do Not Distribute 57 CMDB
= Configuration Management Database
58. CMDB Configuration Item (CI) Server Configuration IP/MAC OS
Service/ Software System Linkages Product Layer Physical Server Storage
Virtual Server Server & Storage Layer Facility Equipment & linkages
Network Equipment & linkages VLAN ACL Bandwidth Network
Configuration Layer Rack Cables … Infrastructure & Data center Layer
Strictly Confidential – Do Not Distribute 58
59. VAI TRÒ CỦA CMDB • 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 Strictly
Confidential – Do Not Distribute 59
60. QUẢN LÝ CMDB • 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 Strictly
Confidential – Do Not Distribute 60
61. QUẢN LÝ CMDB 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ể Strictly
Confidential – Do Not Distribute 61
62. QUẢN LÝ CMDB Strictly Confidential – Do Not Distribute 62
63. MÔ HÌNH fCMDB & MDR fCMDB MDR 1 MDR 2 MDR 3 MDR 4 MDR
1 Information Mng. Process MDR 2 Information Mng. Process MDR 3
Information Mng. Process MDR 4 Information Mng. Process fCMDB =
Federal CMDB MDR = Master Data Repository Strictly Confidential – Do
Not Distribute 63
64. MÔ HÌNH fCMDB & MDR • 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 Strictly Confidential – Do Not Distribute 64
65. CMDB & CSF • 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 Strictly Confidential – Do Not Distribute 65
66. 6. CHANGE MANAGEMENT Strictly Confidential – Do Not Distribute
66
67. 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. Strictly
Confidential – Do Not Distribute 67
68. CHANGE • 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 Strictly Confidential – Do Not Distribute 68
69. YẾU CẦU • Đư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 Strictly Confidential
– Do Not Distribute 69
70. QUY TRÌNH Strictly Confidential – Do Not Distribute 70
71. CÂU HỎI • Giá trị của Change Management với Business? • Giá trị của
Change Management đối với Operation? Strictly Confidential – Do Not
Distribute 71
72. CHANGE MANAGEMENT & BUSINESS • 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 Strictly Confidential – Do Not
Distribute 72
73. CHANGE MANAGEMENT & OPERATION • 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 Strictly Confidential – Do Not Distribute 73
74. CHANGE MANAGEMENT & OPERATION • 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
Strictly Confidential – Do Not Distribute 74
75. CHANGE MANAGEMENT & OPERATION • 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 Strictly Confidential – Do Not Distribute 75
76. CHANGE MANAGEMENT & COMMUNICATION • 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 Strictly Confidential – Do Not Distribute 76
77. CHANGE MANAGEMENT & CAB • 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 Strictly Confidential – Do Not Distribute 77
78. CHANGE MANAGEMENT & CAB • 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 Strictly Confidential – Do Not Distribute 78
79. CHANGE MANAGEMENT & KPI • 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 Strictly Confidential – Do Not Distribute 79
80. CHANGE MANAGEMENT & CSF • 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 Strictly Confidential – Do Not Distribute 80
81. 7. PROBLEM MANAGEMENT Strictly Confidential – Do Not Distribute
81
82. Problems are not stop signs, they are guidelines. Robert H. Schuller
Strictly Confidential – Do Not Distribute 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). 82
83. PROBLEM • Problem là nguyên nhân (cause) gây ra nhiều Incident
hoặc Incident có ảnh hưởng đến nhiều User Strictly Confidential – Do Not
Distribute 83
84. MỤC TIÊU • 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 Strictly Confidential – Do Not Distribute Problem Workaround
Known Error 84
85. QUY TRÌNH Strictly Confidential – Do Not Distribute 85
86. XÁC ĐỊNH PROBLEM • 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 Strictly Confidential – Do Not Distribute 86
87. XÁC ĐỊNH PROBLEM • 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á Strictly Confidential – Do
Not Distribute 87
88. XÁC ĐỊNH PROBLEM 88
89. CÂU HỎI • Giá trị của Problem Management với Business? • Giá trị
của Problem Management đối với Operation? Strictly Confidential – Do Not
Distribute 89
90. PROBLEM MANAGEMENT & BUSINESS • 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 Strictly Confidential – Do Not Distribute 90
91. PROBLEM MANAGEMENT & OPERATION • 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ả Strictly
Confidential – Do Not Distribute 91
92. 8. CAPACITY MANAGEMENT Strictly Confidential – Do Not Distribute
92
93. Mong chờ kết quả tốt nhất Chuẩn bị cho khả năng xấu nhất Strictly
Confidential – Do Not Distribute 93
94. MỤC TIÊU • 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
Strictly Confidential – Do Not Distribute 94
95. CAPACITY MANAGEMENT • Đị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 Strictly Confidential – Do Not Distribute Capacity
Profile Capacity Report Capacity Plan 95
96. CÂU HỎI • Giá trị của Capacity Management với Business? • Giá trị
của Capacity Management đối với Operation? Strictly Confidential – Do
Not Distribute 96
97. CAPACITY MANAGEMENT & BUSINESS • 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 Strictly Confidential – Do Not Distribute 97
98. CAPACITY MANAGEMENT & OPERATION • 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 Strictly Confidential – Do Not Distribute 98
99. 9. RISK MANAGEMENT Strictly Confidential – Do Not Distribute 99
100. The more we think about risk, the more risk seem to be. Ben Carson
Strictly Confidential – Do Not Distribute Càng nghĩ nhiều về rủi ro thì càng
có nhiều rủi ro (có thể xảy ra) 100
101. YÊU CẦU • 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 Strictly Confidential – Do Not Distribute
101
102. TRIỂN KHAI • Nghiên cứu các Risk Managemet Framework và lựa
chọn – COBIT Strictly Confidential – Do Not Distribute 102
103. TRIỂN KHAI • 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) Strictly Confidential
– Do Not Distribute 103
104. TRIỂN KHAI • Đá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 Strictly Confidential – Do Not Distribute 104
105. RISK & CONTROL Assets Risks Controls • 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 Strictly Confidential – Do Not Distribute 105
106. COBIT Risk IT Practitioner Guide Strictly Confidential – Do Not
Distribute 106
107. COBIT Risk IT Practitioner Guide Strictly Confidential – Do Not
Distribute 107
108. ĐÁNH GIÁ RISK • 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
Strictly Confidential – Do Not Distribute 108
109. RISK ASSESSMENT TEMPLATE Strictly Confidential – Do Not
Distribute 109
110. RISK ASSESSMENT TEMPLATE Strictly Confidential – Do Not
Distribute 110
111. RISK CONTROL TEMPLATE Strictly Confidential – Do Not Distribute
111
112. RISK CONTROL TEMPLATE Strictly Confidential – Do Not Distribute
112
113. CÂU HỎI • Giá trị của Risk Management với Business? • Giá trị của
Risk Management đối với Operation? Strictly Confidential – Do Not
Distribute 113
114. RISK MANAGEMENT & BUSINESS • 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 Strictly
Confidential – Do Not Distribute 114
115. RISK MANAGEMENT & OPERATION • 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 Strictly Confidential – Do Not Distribute 115
116. RISK MANAGEMENT & PROCESS KHÁC Incident Management Risk
Assessment (Hàng Quý) Risk & Control Data Thực hiện Control Change
Management Strictly Confidential – Do Not Distribute 116
117. RISK MANAGEMENT & KPI • Tỉ lệ % số Risk được control • Số
incident xảy ra do control không hiệu quả Strictly Confidential – Do Not
Distribute 117
118. RISK MANAGEMENT & CSF • 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.)
Strictly Confidential – Do Not Distribute 118
119. 10. BÀI HỌC KINH NGHIỆM Strictly Confidential – Do Not Distribute
119
120. CAM KẾT • 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 Strictly Confidential – Do Not Distribute 120
121. CÁC BƯỚC TRIỂN KHAI • • • • • Lựa chọn hệ thống ITSM Service
Desk Incident Management Change Management Risk Management –
Capacity Management – Problem Management –… Strictly Confidential –
Do Not Distribute 121
122. TEAMS • 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
Strictly Confidential – Do Not Distribute 122
123. KPI • 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 Strictly Confidential – Do Not
Distribute 123
124. TIẾP CẬN TRIỂN KHAI • 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 Strictly
Confidential – Do Not Distribute 124
125. THEO DÕI TRIỂN KHAI • 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 Strictly Confidential – Do Not
Distribute 125
126. 11. Q&A Strictly Confidential – Do Not Distribute 126
127. Q&A Strictly Confidential – Do Not Distribute 127
128. 12. ITIL V3 Strictly Confidential – Do Not Distribute 128
129. ITIL V3 • 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ẻ Strictly
Confidential – Do Not Distribute 129
130. 13. HUẤN LUYỆN Strictly Confidential – Do Not Distribute 130
131. NỘI DUNG • • • • • • • • 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ự Strictly Confidential – Do Not Distribute 131
132. XIN CÁM ƠN! CHÚC MỪNG NĂM MỚI 2014 Strictly Confidential –
Do Not Distribute 132