04-211202 Axelos - ITILv3 - Service Operation - Vi - Van Hanh Dich Vu

AXELOS® ITIL V3
CORE PUBLISH #4: SERVICE OPERATION
VẬN HÀNH
DỊCH VỤ
I T I L v 3 – V Ậ N HÀ N H D Ị C H V Ụ - S ERV I CE OP E RA T I ON
Chuyển ngữ: Nguyễn Thế Hùng – email: nguyenthehung.it@gmail.com 1|Page
Cốt lõi của ITIL bao gồm 5 ấn phẩm. Mỗi ấn phẩm cung cấp hướng dẫn cần thiết
cho một phương pháp tiếp cận được tích hợp, như được yêu cầu bởi đặc tả kỹ
thuật trong tiêu chuẩn ISO/IEC 27000:
- Chiến lược dịch vụ

- Thiết kế dịch vụ
- Chuyển tiếp dịch vụ
- Vận hành dịch vụ
- Liên tục cải tiến dịch vụ
Mụ c l ụ c
L ờ i t ự a .....................................................................................................................................................................17
L ờ i t ự a c ủ a O C G ...........................................................................................................................................17
L ờ i t ự a c ủ a K i ế n t r ú c s ư t r ư ở n g ........................................................................................................19
L ờ i g i ớ i t h i ệ u ......................................................................................................................................................21
T h ô n g t i n l i ê n h ệ .........................................................................................................................................21
L ờ i c ả m ơ n ............................................................................................................................................................23
K i ế n t r ú c s ư t r ư ở n g v à c á c t á c g i ả .................................................................................................23
N h ó m t h i ế t k ế I T I L .....................................................................................................................................23
C á c c ố v ấ n ........................................................................................................................................................23
N h ữ n g đ ó n g g ó p k h á c ...............................................................................................................................23
N h ó m T ư v ấ n I T I L ...................................................................................................................................25
N h ữ n g n g ư ờ i đ á n h g i á ..........................................................................................................................25
1 G i ớ i t h i ệ u ......................................................................................................................................................27
1.1 T ổ n g q u a n ...........................................................................................................................................27
1.2 B ố i c ả n h ................................................................................................................................................29
1.2.1 Q u ả n l ý D ị c h v ụ ..........................................................................................................................29
1.2.2 N h ữ n g t h ự c t i ễ n t ố t t r o n g l ĩ n h v ự c c ô n g ..................................................................29
1.2.3 I T I L v à n h ữ n g t h ự c t i ễ n t ố t t r o n g Q u ả n l ý D ị c h v ụ ...........................................32
1.2.3.1 C h i ế n l ư ợ c D ị c h v ụ ...............................................................................................................34
1.2.3.2 T h i ế t k ế D ị c h v ụ .....................................................................................................................35
1.2.3.3 C h u y ể n t i ế p D ị c h v ụ ............................................................................................................36
1.2.3.4 V ậ n h à n h D ị c h v ụ ..................................................................................................................36
1.2.3.5 L i ê n t ụ c C ả i t i ế n D ị c h v ụ .................................................................................................37
1.3 M ụ c đ í c h ...............................................................................................................................................37
1.4 S ử d ụ n g .................................................................................................................................................38
1.5 T ổ n g q u a n v ề c á c c h ư ơ n g ........................................................................................................39
2 Q u ả n l ý D ị c h v ụ n h ư m ộ t t h ự c t i ễ n .............................................................................................40
2.1 Q u ả n l ý D ị c h v ụ l à g ì ? ................................................................................................................40
2.2 D ị c h v ụ l à g ì ? ....................................................................................................................................43
2.2.1 Đ ề x u ấ t g i á t r ị .............................................................................................................................43
2.3 C á c c h ứ c n ă n g v à q u y t r ì n h t r o n g v ò n g đ ờ i ................................................................44
2.3.1 C á c c h ứ c n ă n g ..............................................................................................................................44
2.3.2 C á c q u y t r ì n h ................................................................................................................................44
2.3.3 C h u y ê n m ô n h ó a v à s ự p h ố i h ợ p t r o n g s u ố t v ò n g đ ờ i .....................................46
2.4 N ề n t ả n g c ơ b ả n c ủ a V ậ n h à n h D ị c h v ụ .........................................................................47
2.4.1 M ụ c đ í c h / đ í c h đ ế n / m ụ c t i ê u ...............................................................................................47
2.4.2 P h ạ m v i .............................................................................................................................................48
2.4.3 G i á t r ị đ ố i v ớ i d o a n h n g h i ệ p ..............................................................................................49
2.4.4 T ố i ư u h ó a h i ệ u s u ấ t V ậ n h à n h D ị c h v ụ .....................................................................51
2.4.5 C á c q u y t r ì n h t r o n g V ậ n h à n h D ị c h v ụ ........................................................................52
2.4.5.1 Q u ả n l ý S ự k i ệ n ......................................................................................................................52
2.4.5.2 Q u ả n l ý S ự c ố v à V ấ n đ ề ..................................................................................................52
2.4.5.3 T h ự c h i ệ n Y ê u c ầ u ................................................................................................................52
2.4.5.4 Q u ả n l ý Q u y ề n t r u y c ậ p ....................................................................................................53
2.4.6 C á c c h ứ c n ă n g t r o n g V ậ n h à n h D ị c h v ụ .....................................................................53
2.4.6.1 B ộ p h ậ n H ỗ t r ợ D ị c h v ụ ( S e r v i c e D e s k ) .................................................................54
2.4.6.2 Q u ả n l ý K ỹ t h u ậ t ....................................................................................................................54
2.4.6.3 Q u ả n l ý V ậ n h à n h C N T T ....................................................................................................54
2.4.6.4 Q u ả n l ý Ứ n g d ụ n g .................................................................................................................55
2.4.6.5 Các tương tác với các giai đoạn khác của Vòng đời Quản lý Dịch vụ
55
3 C á c n g u y ê n t ắ c V ậ n h à n h D ị c h v ụ ...............................................................................................56
3.1 C á c c h ứ c n ă n g , đ ộ i , n h ó m , p h ò n g b a n ............................................................................56
3.2 Đ ạ t đ ư ợ c s ự c â n b ằ n g t r o n g V ậ n h à n h D ị c h v ụ ........................................................59
3.2.1 Q u a n đ i ể m C N T T n ộ i b ộ s o v ớ i q u a n đ i ể m d o a n h n g h i ệ p b ê n n g o à i ......59
3.2.2 T í n h ổ n đ ị n h s o v ớ i k h ả n ă n g ứ n g p h ó .......................................................................66
3.2.3 C h ấ t l ư ợ n g c ủ a d ị c h v ụ s o v ớ i c h i p h í c ủ a d ị c h v ụ ............................................71
3.2.4 Đ ố i p h ó s o v ớ i c h ủ đ ộ n g .......................................................................................................77
3.3 C u n g c ấ p d ị c h v ụ ............................................................................................................................83
3.4 Nhân viên Vận hành tham gia vào Thiết kế Dịch vụ và Chuyển tiếp Dịch
vụ 84
3.5 S ứ c k h ỏ e V ậ n h à n h .......................................................................................................................86
3.6 T r u y ề n t h ô n g .....................................................................................................................................89
3.6.1 C á c c u ộ c h ọ p .................................................................................................................................92
3.6.1.1 C á c c u ộ c h ọ p V ậ n h à n h .....................................................................................................94
3.6.1.2 C á c c u ộ c h ọ p P h ò n g / B a n , đ ộ i h o ặ c n h ó m .............................................................95
3.6.1.3 C á c c u ộ c h ọ p v ớ i k h á c h h à n g .......................................................................................95
3.7 T à i l i ệ u ..................................................................................................................................................96
4 C á c q u y t r ì n h V ậ n h à n h D ị c h v ụ ....................................................................................................97
4.1 Q u ả n l ý s ự k i ệ n .............................................................................................................................100
4.1.1 M ụ c đ í c h / đ í c h đ ế n / m ụ c t i ê u .................................................................................................101
4.1.2 P h ạ m v i ...............................................................................................................................................102
G i á t r ị đ ố i v ớ i d o a n h n g h i ệ p ..................................................................................................................103
4.1.3 C á c c h í n h s á c h / n g u y ê n t ắ c / ý t ư ở n g c ơ b ả n ...............................................................104
4.1.4 C á c h o ạ t đ ộ n g , p h ư ơ n g p h á p v à k ỹ t h u ậ t q u y t r ì n h ............................................106
4.1.4.1 S ự k i ệ n x ả y r a ............................................................................................................................106
4.1.4.2 T h ô n g b á o v ề s ự k i ệ n ...........................................................................................................107
4.1.4.3 N h ậ n d i ệ n s ự k i ệ n ...................................................................................................................110
4.1.4.4 L ọ c s ự k i ệ n ...................................................................................................................................110
4.1.4.5 T ầ m q u a n t r ọ n g c ủ a s ự k i ệ n ............................................................................................111
4.1.4.6 S ự t ư ơ n g q u a n c ủ a s ự k i ệ n ...............................................................................................113
4.1.4.7 Đ i ề u k i ệ n k í c h h o ạ t ................................................................................................................115
4.1.4.8 L ự a c h ọ n p h ả n ứ n g .................................................................................................................116
4.1.4.9 X e m x é t c á c h à n h đ ộ n g .......................................................................................................121
4.1.4.10 Đ ó n g s ự k i ệ n ..........................................................................................................................121
4.1.5 Các điều kiện kích hoạt, đầu vào và đầu ra/các tương tác qua lại giữa
c á c q u y t r ì n h .....................................................................................................................................................122
4.1.6 Q u ả n l ý T h ô n g t i n ........................................................................................................................125
4.1.7 C á c c h ỉ s ố ..........................................................................................................................................126
4.1.8 N h ữ n g t h á c h t h ứ c , Y ế u t ố T h à n h c ô n g Q u a n t r ọ n g v à r ủ i r o ........................127
4.1.8.1 N h ữ n g t h á c h t h ứ c ....................................................................................................................127
4.1.8.2 C á c Y ế u t ố T h à n h c ô n g Q u a n t r ọ n g ............................................................................128
4.1.8.3 R ủ i r o ...............................................................................................................................................129
4.1.9 T h i ế t k ế đ ố i v ớ i Q u ả n l ý S ự k i ệ n ......................................................................................129
4.1.9.1 C ô n g c ụ Đ o đ ạ c .........................................................................................................................130
4.1.9.2 T h ô n g đ i ệ p l ỗ i ............................................................................................................................131
4.1.9.3 N h ậ n d ạ n g S ự k i ệ n v à c á c C ơ c h ế C ả n h b á o .........................................................132
4.1.9.4 X á c đ ị n h c á c n g ư ỡ n g .............................................................................................................133
4.2 Q u ả n l ý s ự c ố ..................................................................................................................................134
4.2.2 P h ạ m v i ...............................................................................................................................................134
4.2.3 G i á t r ị đ ố i v ớ i d o a n h n g h i ệ p ................................................................................................135
4.2.4.1 K h u n g t h ờ i g i a n ........................................................................................................................136
4.2.4.2 C á c m ô h ì n h S ự c ố ..................................................................................................................137
4.2.4.3 C á c s ự c ố n g h i ê m t r ọ n g ......................................................................................................138
4.2.5.1 N h ậ n d ạ n g s ự c ố ......................................................................................................................140
4.2.5.2 G h i n h ậ t k ý s ự c ố ....................................................................................................................141
4.2.5.3 P h â n l o ạ i s ự c ố ..........................................................................................................................142
4.2.5.4 T h i ế t l ậ p đ ộ ư u t i ê n c ủ a s ự c ố .......................................................................................146
4.2.5.5 C h ẩ n đ o á n b a n đ ầ u .................................................................................................................148
4.2.5.6 L e o t h a n g s ự c ố ........................................................................................................................149
L ư u ý l i ê n q u a n đ ế n v i ệ c p h â n b ổ S ự c ố .......................................................................................151
4.2.5.7 Đ i ề u t r a v à C h ẩ n đ o á n .........................................................................................................151
4.2.5.8 G i ả i q u y ế t v à k h ô i p h ụ c ......................................................................................................153
4.2.5.9 Đ ó n g S ự c ố ...................................................................................................................................154
C á c q u y t ắ c đ ể m ở l ạ i c á c s ự c ố .........................................................................................................155
4.2.6 Các điều kiện kích hoạt, đầu vào và đầu ra/các tương tác qua lại giữa
c á c q u y t r ì n h .....................................................................................................................................................156
4.2.7 Q u ả n l ý T h ô n g t i n ........................................................................................................................158
4.2.8 C á c c h ỉ s ố ..........................................................................................................................................159
4.2.9 N h ữ n g t h á c h t h ứ c , c á c Y ế u t ố T h à n h c ô n g Q u a n t r ọ n g v à r ủ i r o ..............161
4.2.9.1 N h ữ n g t h á c h t h ứ c ....................................................................................................................161
4.2.9.2 C á c y ế u t ố T h à n h c ô n g Q u a n t r ọ n g .............................................................................162
4.2.9.3 R ủ i r o ...............................................................................................................................................162
4.3 T h ự c h i ệ n c á c y ê u c ầ u ..............................................................................................................163
4.3.2 P h ạ m v i ...............................................................................................................................................164
4.3.4.1 C á c M ô h ì n h Y ê u c ầ u .............................................................................................................166
4.3.5.1 L ự a c h ọ n M e n u ..........................................................................................................................166
4.3.5.2 P h ê d u y ệ t t à i c h í n h ................................................................................................................167
4.3.5.3 C á c p h ê d u y ệ t k h á c ................................................................................................................167
4.3.5.4 T h ự c h i ệ n ......................................................................................................................................168
4.3.5.5 Đ ó n g .................................................................................................................................................168
4.3.6 Điều kiện kích hoạt, đầu vào và đầu ra/các tương tác qua lại giữa các
q u y t r ì n h ..............................................................................................................................................................168
4.3.7 Q u ả n l ý T h ô n g t i n ........................................................................................................................169
4.3.8 C á c c h ỉ s ố ..........................................................................................................................................170
4.3.9 N h ữ n g t h á c h t h ứ c , c á c Y ế u t ố T h à n h c ô n g Q u a n t r ọ n g v à r ủ i r o ..............171
4.3.9.1 N h ữ n g t h á c h t h ứ c ....................................................................................................................171
4.3.9.2 C á c Y ế u t ố T h à n h c ô n g Q u a n t r ọ n g ............................................................................171
4.3.9.3 R ủ i r o ...............................................................................................................................................172
4.4 Q u ả n l ý V ấ n đ ề ..............................................................................................................................173
4.4.2 P h ạ m v i ...............................................................................................................................................173
4.4.4.1 C á c M ô h ì n h V ấ n đ ề ...............................................................................................................175
4.4.5.1 P h á t h i ệ n v ấ n đ ề ......................................................................................................................178
4.4.5.2 G h i n h ậ t k ý v ấ n đ ề .................................................................................................................179
4.4.5.3 P h â n l o ạ i v ấ n đ ề ......................................................................................................................179
4.4.5.4 T h i ế t l ậ p đ ộ ư u t i ê n c h o v ấ n đ ề ....................................................................................180
4.4.5.5 Đ i ề u t r a v à C h ẩ n đ o á n V ấ n đ ề .......................................................................................181
4.4.5.6 C á c h g i ả i q u y ế t .........................................................................................................................187
4.4.5.7 Đ ư a r a m ộ t H ồ s ơ L ỗ i Đ ã b i ế t .........................................................................................187
4.4.5.8 C á c h g i ả i q u y ế t v ấ n đ ề ........................................................................................................188
4.4.5.9 Đ ó n g v ấ n đ ề ................................................................................................................................189
4.4.5.10 X e m x é t V ấ n đ ề n g h i ê m t r ọ n g ....................................................................................189
4.4.5.11 C á c l ỗ i đ ư ợ c p h á t h i ệ n t r o n g m ô i t r ư ờ n g p h á t t r i ể n ..................................190
4.4.6 Điều kiện kích hoạt, đầu vào và đầu ra/các tương tác qua lại giữa các
q u y t r ì n h ..............................................................................................................................................................191
4.4.7 Q u ả n l ý T h ô n g t i n ........................................................................................................................194
4.4.7.1 C M S ....................................................................................................................................................194
4.4.7.2 C ơ s ở d ữ l i ệ u L ỗ i Đ ã b i ế t ...................................................................................................194
4.4.8 C á c c h ỉ s ố ..........................................................................................................................................197
4.4.9 N h ữ n g T h á c h t h ứ c , c á c Y ế u t ố T h à n h c ô n g Q u a n t r ọ n g v à r ủ i r o ..............198
4.5 Q u ả n l ý T r u y c ậ p ..........................................................................................................................198
4.5.2 P h ạ m v i ...............................................................................................................................................199
4.5.5.1 Y ê u c ầ u q u y ề n t r u y c ậ p .......................................................................................................201
4.5.5.2 X á c m i n h ........................................................................................................................................202
4.5.5.3 C u n g c ấ p q u y ề n ( t r u y c ậ p ) ...............................................................................................203
4.5.5.4 G i á m s á t t ì n h t r ạ n g c ủ a n h â n d ạ n g ............................................................................205
4.5.5.5 G h i n h ậ t k ý v à t h e o d õ i q u y ề n t r u y c ậ p ..................................................................207
4.5.5.6 L o ạ i b ỏ h o ặ c h ạ n c h ế q u y ề n ( t r u y c ậ p ) ...................................................................208
4.5.6 Điều kiện kích hoạt, đầu vào và đầu ra/các tương tác giữa các quy
trình 209
4.5.7 Q u ả n l ý T h ô n g t i n ........................................................................................................................210
4.5.7.1 N h â n d ạ n g .....................................................................................................................................210
4.5.7.2 N g ư ờ i d ù n g , c á c n h ó m , v a i t r ò v à c á c n h ó m d ị c h v ụ .....................................213
4.5.8 C á c c h ỉ s ố ..........................................................................................................................................214
4.5.9 N h ữ n g T h á c h t h ứ c , c á c Y ế u t ố T h à n h c ô n g Q u a n t r ọ n g v à r ủ i r o ..............215
4.6 Các hoạt động vận hành của các quy trình được bao gồm trong các giai
đ o ạ n v ò n g đ ờ i k h á c ..................................................................................................................................216
4.6.1 Q u ả n l ý T h a y đ ổ i ..........................................................................................................................216
4.6.2 Q u ả n l ý C ấ u h ì n h ..........................................................................................................................217
4.6.3 Q u ả n l ý P h á t h à n h v à T r i ể n k h a i .......................................................................................217
4.6.4 Q u ả n l ý C ô n g s u ấ t .......................................................................................................................218
4.6.4.1 G i á m s á t C ô n g s u ấ t v à H i ệ u s u ấ t .................................................................................219
4.6.4.2 X ử l ý c á c s ự c ố l i ê n q u a n đ ế n c ô n g s u ấ t – h o ặ c h i ệ u s u ấ t ........................222
4.6.4.3 X u h ư ớ n g c ô n g s u ấ t v à h i ệ u s u ấ t .................................................................................223
4.6.4.4 D ữ l i ệ u Q u ả n l ý C ô n g s u ấ t v à L ư u t r ữ ......................................................................223
4.6.4.5 Q u ả n l ý N h u c ầ u .......................................................................................................................224
4.6.4.6 Q u ả n l ý k h ố i l ư ợ n g c ô n g v i ệ c ..........................................................................................225
4.6.4.7 M ô h ì n h h ó a v à đ ị n h c ỡ ứ n g d ụ n g ...............................................................................226
4.6.4.8 H o ạ c h đ ị n h c ô n g s u ấ t ...........................................................................................................226
4.6.5 Q u ả n l ý t í n h S ẵ n s à n g ..............................................................................................................228
4.6.6 Q u ả n l ý K i ế n t h ứ c ........................................................................................................................230
4.6.7 Q u ả n l ý T à i c h í n h đ ố i v ớ i c á c d ị c h v ụ C N T T .............................................................231
4.6.8 Q u ả n l ý L i ê n t ụ c D ị c h v ụ C N T T ...........................................................................................232
5 C á c h o ạ t đ ộ n g V ậ n h à n h D ị c h v ụ p h ổ b i ế n ..........................................................................233
5.1 G i á m s á t v à K i ể m s o á t ..............................................................................................................237
5.1.1 C á c đ ị n h n g h ĩ a ...............................................................................................................................238
5.1.2 V ò n g l ặ p K i ể m s o á t G i á m s á t ...............................................................................................240
5.1.2.1 V ò n g l ặ p K i ể m s o á t G i á m s á t p h ứ c t ạ p ....................................................................242
5.1.2.2 V ò n g l ặ p K i ể m s o á t G i á m s á t I T S M .............................................................................246
5.1.2.3 X á c đ ị n h n h ữ n g g ì c ầ n đ ư ợ c g i á m s á t .......................................................................250
5.1.2.4 K i ể m s o á t v à G i á m s á t N ộ i b ộ v à B ê n n g o à i .........................................................251
5.1.2.5 X á c đ ị n h m ụ c t i ê u đ ố i v ớ i G i á m s á t v à K i ể m s o á t ............................................252
5.1.2.6 C á c k i ể u g i á m s á t ....................................................................................................................255
5.1.2.7 G i á m s á t t r o n g n h ữ n g M ô i t r ư ờ n g K i ể m n g h i ệ m .................................................260
5.1.2.8 B á o c á o v à h à n h đ ộ n g ..........................................................................................................260
5.1.2.9 C á c c u ộ c k i ể m t o á n V ậ n h à n h D ị c h v ụ ......................................................................262
5.1.2.10 Đ o l ư ờ n g , c á c c h ỉ s ố v à K P I ........................................................................................263
Đ o l ư ờ n g ..............................................................................................................................................................263
C á c c h ỉ s ố ...........................................................................................................................................................264
C á c C h ỉ s ố H i ệ u s u ấ t T h e n c h ố t ..........................................................................................................264
5.1.2.11 C á c t ư ơ n g t á c v ớ i n h ữ n g t h ự c t i ễ n V ò n g đ ờ i D ị c h v ụ k h á c ....................265
G i á m s á t V ậ n h à n h v à L i ê n t ụ c C ả i t i ế n D ị c h v ụ .....................................................................265
5.2 V ậ n h à n h C N T T ..............................................................................................................................267
5.2.1 Q u ả n l ý B ả n g đ i ề u k h i ể n ( c o n s o l e ) / C ầ u n ố i H o ạ t đ ộ n g .....................................267
5.2.2 L ậ p l ị c h t r ì n h C ô n g v i ệ c ..........................................................................................................269
5.2.3 S a o l ư u v à K h ô i p h ụ c .................................................................................................................271
5.2.3.1 S a o l ư u ............................................................................................................................................272
5.2.3.2 K h ô i p h ụ c ......................................................................................................................................275
5.2.4 I n ấ n v à Đ ầ u r a .............................................................................................................................276
5.3 Q u ả n l ý M á y t í n h l ớ n ( M a i n f r a m e ) ...................................................................................278
5.4 Q u ả n l ý v à H ỗ t r ợ M á y c h ủ ....................................................................................................279
5.5 Q u ả n l ý M ạ n g ..................................................................................................................................281
5.6 L ư u t r ữ v à C ấ t g i ữ .......................................................................................................................284
5.7 Q u ả n l ý C ơ s ở d ữ l i ệ u ...............................................................................................................286
5.8 Q u ả n l ý c á c D ị c h v ụ D a n h b ạ ( D i r e c t o r y ) ...................................................................288
5.9 H ỗ t r ợ M á y t í n h b à n ...................................................................................................................290
5.10 Q u ả n l ý P h ầ n m ề m t r u n g g i a n ........................................................................................291
5.11 Q u ả n l ý I n t e r n e t / W e b ...........................................................................................................292
5.12 Q u ả n l ý T r u n g t â m D ữ l i ệ u v à C ơ s ở v ậ t c h ấ t .....................................................294
5.12.1 N h ữ n g c h i ế n l ư ợ c T r u n g t â m D ữ l i ệ u .........................................................................296
5.13 Q u ả n l ý B ả o m ậ t T h ô n g t i n v à V ậ n h à n h D ị c h v ụ ..............................................298
5.13.1 L ậ p c h í n h s á c h v à B á o c á o ................................................................................................299
5.13.2 T r ợ g i ú p k ỹ t h u ậ t .....................................................................................................................300
5.13.3 K i ể m s o á t b ả o m ậ t v ậ n h à n h ...........................................................................................300
5.13.4 S à n g l ọ c v à x e m x é t l ý l ị c h ..............................................................................................301
5.13.5 Đ à o t ạ o v à n â n g c a o n h ậ n t h ứ c .....................................................................................302
5.13.6 C á c c h í n h s á c h v à t h ủ t ụ c đ ư ợ c l ậ p t h à n h v ă n b ả n .........................................302
5.14 C ả i t h i ệ n c á c h o ạ t đ ộ n g v ậ n h à n h ...............................................................................302
5.14.1 T ự đ ộ n g h ó a c á c t á c v ụ t h ủ c ô n g .................................................................................302
5.14.2 Đ á n h g i á c á c h o ạ t đ ộ n g h o ặ c t h ủ t ụ c t ạ m t h ờ i ..................................................303
5.14.3 C á c c u ộ c k i ể m t o á n v ậ n h à n h .........................................................................................303
5.14.4 V i ệ c s ử d ụ n g Q u ả n l ý S ự c ố v à V ấ n đ ề ....................................................................303
5.14.5 T r u y ề n t h ô n g ..............................................................................................................................304
5.14.6 G i á o d ụ c v à Đ à o t ạ o ..............................................................................................................304
6 V i ệ c t ổ c h ứ c V ậ n h à n h D ị c h v ụ ....................................................................................................304
6.1 C á c c h ứ c n ă n g ................................................................................................................................304
6.1.1 C á c c h ứ c n ă n g v à h o ạ t đ ộ n g ................................................................................................309
6.2 B ộ p h ậ n H ỗ t r ợ D ị c h v ụ ...........................................................................................................312
6.2.1 B i ệ n m i n h v à v a i t r ò c ủ a B ộ p h ậ n H ỗ t r ợ D ị c h v ụ .................................................314
6.2.2 M ụ c t i ê u c ủ a B ộ p h ậ n H ỗ t r ợ D ị c h v ụ ............................................................................315
6.2.3 C ấ u t r ú c t ổ c h ứ c c ủ a B ộ p h ậ n H ỗ t r ợ D ị c h v ụ .........................................................316
6.2.3.1 B ộ p h ậ n H ỗ t r ợ D ị c h v ụ đ ị a p h ư ơ n g ...........................................................................317
6.2.3.2 B ộ p h ậ n H ỗ t r ợ D ị c h v ụ đ ư ợ c t ậ p t r u n g h ó a .........................................................318
6.2.3.3 B ộ p h ậ n H ỗ t r ợ D ị c h v ụ đ ư ợ c ả o h ó a .........................................................................319
6.2.3.4 ( H ỗ t r ợ ) T h e o m ú i g i ờ ( F o l l o w t h e S u n ) ..................................................................320
6.2.3.5 C á c n h ó m H ỗ t r ợ D ị c h v ụ đ ư ợ c c h u y ê n m ô n h ó a ...............................................321
6.2.3.6 M ô i t r ư ờ n g ....................................................................................................................................322
6.2.3.7 L ư u ý v ề v i ệ c x â y d ự n g đ i ể m l i ê n h ệ đ ơ n l ẻ ........................................................323
6.2.4 B ố t r í n h â n s ự B ộ p h ậ n H ỗ t r ợ D ị c h v ụ ........................................................................324
6.2.4.1 C á c m ứ c đ ộ b ố t r í n h â n s ự ................................................................................................325
6.2.4.2 C á c c ấ p đ ộ k ỹ n ă n g ................................................................................................................327
6.2.4.3 Đ à o t ạ o ...........................................................................................................................................331
6.2.4.4 X o a y v ò n g n h â n s ự .................................................................................................................333
6.2.4.5 N g ư ờ i d ù n g S i ê u c ấ p .............................................................................................................334
6.2.5 C á c c h ỉ s ố c ủ a B ộ p h ậ n H ỗ t r ợ D ị c h v ụ ........................................................................336
6.2.5.1 C á c k h ả o s á t m ứ c đ ộ h à i l ò n g c ủ a k h á c h h à n g / n g ư ờ i d ù n g .......................339
6.2.6 T h u ê n g o à i B ộ p h ậ n H ỗ t r ợ D ị c h v ụ ................................................................................344
6.2.6.1 C á c c ô n g c ụ v à t h ủ t ụ c p h ổ b i ế n ..................................................................................344
6.2.6.2 C á c đ í c h n h ắ m m ụ c t i ê u c ủ a S L A ..................................................................................347
6.2.6.3 T r u y ề n t h ô n g r õ r à n g ............................................................................................................347
6.2.6.4 C h ủ s ở h ữ u d ữ l i ệ u .................................................................................................................349
6.3 Q u ả n l ý K ỹ t h u ậ t ...........................................................................................................................349
6.3.1 V a i t r ò Q u ả n l ý K ỹ t h u ậ t .........................................................................................................349
6.3.2 C á c m ụ c t i ê u c ủ a Q u ả n l ý K ỹ t h u ậ t .................................................................................351
6.3.3 C á c h o ạ t đ ộ n g p h ổ b i ế n c ủ a Q u ả n l ý K ỹ t h u ậ t ........................................................352
Chuyển ngữ: Nguyễn Thế Hùng – email: nguyenthehung.it@gmail.com 10 | P a g e
6.3.4 S ự t ổ c h ứ c Q u ả n l ý K ỹ t h u ậ t ................................................................................................356
6.3.5 T h i ế t k ế K ỹ t h u ậ t v à D u y t r ì v à H ỗ t r ợ K ỹ t h u ậ t ....................................................358
6.3.6 C á c c h ỉ s ố c ủ a Q u ả n l ý K ỹ t h u ậ t .......................................................................................359
6.3.7 T à i l i ệ u Q u ả n l ý K ỹ t h u ậ t .......................................................................................................361
6.3.7.1 T à i l i ệ u K ỹ t h u ậ t ......................................................................................................................362
6.3.7.2 C á c l ị c h t r ì n h b ả o t r ì .............................................................................................................362
6.3.7.3 K h o k ỹ n ă n g .................................................................................................................................362
6.4 Q u ả n l ý V ậ n h à n h C N T T ...........................................................................................................363
6.4.1 V a i t r ò Q u ả n l ý V ậ n h à n h C N T T .........................................................................................365
6.4.2 C á c m ụ c t i ê u c ủ a Q u ả n l ý V ậ n h à n h C N T T .................................................................367
6.4.3 S ự t ổ c h ứ c Q u ả n l ý V ậ n h à n h C N T T ................................................................................368
6.4.4 C á c c h ỉ s ố c ủ a Q u ả n l ý V ậ n h à n h C N T T ........................................................................369
6.4.5 T à i l i ệ u Q u ả n l ý V ậ n h à n h C N T T .......................................................................................370
6.4.5.1 T h ủ t ụ c V ậ n h à n h T i ê u c h u ẩ n .........................................................................................371
6.4.5.2 N h ậ t k ý V ậ n h à n h ....................................................................................................................371
6.4.5.3 C á c L ị c h t r ì n h v à B á o c á o C ô n g v i ệ c ..........................................................................372
6.4.5.4 L ị c h t r ì n h V ậ n h à n h ................................................................................................................373
6.5 Q u ả n l ý Ứ n g d ụ n g ........................................................................................................................374
6.5.1 V a i t r ò Q u ả n l ý Ứ n g d ụ n g ......................................................................................................374
6.5.2 C á c m ụ c t i ê u c ủ a Q u ả n l ý Ứ n g d ụ n g ...............................................................................376
6.5.3 C á c n g u y ê n t ắ c Q u ả n l ý Ứ n g d ụ n g ...................................................................................376
6.5.3.1 X â y d ự n g h a y M u a ? ................................................................................................................376
6.5.3.2 C á c m ô h ì n h V ậ n h à n h ..........................................................................................................378
6.5.4 V ò n g đ ờ i Q u ả n l ý Ứ n g d ụ n g ..................................................................................................379
6.5.4.1 C á c y ê u c ầ u .................................................................................................................................382
6.5.4.2 T h i ế t k ế ..........................................................................................................................................383
6.5.4.3 X â y d ự n g ........................................................................................................................................384
6.5.4.4 T r i ể n k h a i ......................................................................................................................................385
6.5.4.5 V ậ n h à n h ........................................................................................................................................386
6.5.4.6 T ố i ư u h ó a ....................................................................................................................................386
6.5.5 C á c h o ạ t đ ộ n g Q u ả n l ý Ứ n g d ụ n g n ó i c h u n g .............................................................388
6.5.6 S ự t ổ c h ứ c Q u ả n l ý Ứ n g d ụ n g .............................................................................................392
6.5.6.1 V a i t r ò t ổ c h ứ c ..........................................................................................................................394
6.5.7 V a i t r ò v à t r á c h n h i ệ m c ủ a Q u ả n l ý Ứ n g d ụ n g ........................................................399
6.5.7.1 C á c N h à q u ả n l ý / T r ư ở n g n h ó m Ứ n g d ụ n g ...............................................................399
6.5.7.2 C h u y ê n v i ê n p h â n t í c h / K i ế n t r ú c s ư Ứ n g d ụ n g ...................................................400
6.5.8 C á c c h ỉ s ố Q u ả n l ý Ứ n g d ụ n g ...............................................................................................402
6.5.9 T à i l i ệ u Q u ả n l ý Ứ n g d ụ n g .....................................................................................................404
6.5.9.1 D a n h m ụ c Ứ n g d ụ n g ...............................................................................................................404
6.5.9.2 C á c y ê u c ầ u Ứ n g d ụ n g .........................................................................................................406
6.5.9.3 C á c t r ư ờ n g h ợ p S ử d ụ n g v à T h a y đ ổ i ........................................................................408
6.5.9.4 T à i l i ệ u t h i ế t k ế ........................................................................................................................409
6.5.9.5 H ư ớ n g d ẫ n s ử d ụ n g ................................................................................................................410
6.6 C á c v a i t r ò v à t r á c h n h i ệ m V ậ n h à n h D ị c h v ụ ..........................................................412
6.6.1 C á c V a i t r ò B ộ p h ậ n H ỗ t r ợ D ị c h v ụ ................................................................................412
6.6.1.1 N h à Q u ả n l ý B ộ p h ậ n H ỗ t r ợ D ị c h v ụ .........................................................................412
6.6.1.2 G i á m s á t v i ê n B ộ p h ậ n H ỗ t r ợ D ị c h v ụ ......................................................................413
6.6.1.3 N h à p h â n t í c h B ộ p h ậ n H ỗ t r ợ D ị c h v ụ .....................................................................414
6.6.1.4 N g ư ờ i d ù n g S i ê u c ấ p .............................................................................................................414
6.6.2 C á c V a i t r ò Q u ả n l ý K ỹ t h u ậ t ...............................................................................................415
6.6.2.1 N h à Q u ả n l ý / T r ư ở n g n h ó m K ỹ t h u ậ t ...........................................................................415
6.6.2.2 C h u y ê n v i ê n p h â n t í c h / K i ế n t r ú c s ư K ỹ t h u ậ t ......................................................416
6.6.2.3 N h â n v i ê n v ậ n h à n h K ỹ t h u ậ t ..........................................................................................417
6.6.3 C á c V a i t r ò Q u ả n l ý V ậ n h à n h C N T T ...............................................................................417
6.6.3.1 N h à Q u ả n l ý V ậ n h à n h C N T T ............................................................................................417
6.6.3.2 T r ư ở n g n h ó m ...............................................................................................................................419
6.6.3.3 C h u y ê n v i ê n p h â n t í c h H o ạ t đ ộ n g C N T T ..................................................................419
6.6.3.4 N h â n v i ê n v ậ n h à n h C N T T .................................................................................................420
6.6.4 C á c V a i t r ò Q u ả n l ý Ứ n g d ụ n g .............................................................................................420
6.6.4.1 N h à Q u ả n l ý / T r ư ở n g n h ó m Ứ n g d ụ n g ........................................................................420
6.6.4.2 C h u y ê n v i ê n p h â n t í c h / K i ế n t r ú c s ư Ứ n g d ụ n g ...................................................421
6.6.5 C á c V a i t r ò Q u ả n l ý S ự k i ệ n .................................................................................................422
6.6.5.1 V a i t r ò c ủ a B ộ p h ậ n H ỗ t r ợ K ỹ t h u ậ t .........................................................................423
6.6.5.2 V a i t r ò c ủ a Q u ả n l ý K ỹ t h u ậ t v à Q u ả n l ý Ứ n g d ụ n g .........................................423
6.6.5.3 V a i t r ò c ủ a Q u ả n l ý V ậ n h à n h C N T T ...........................................................................424
6.6.6 C á c V a i t r ò Q u ả n l ý S ự c ố ......................................................................................................425
6.6.6.1 N h à Q u ả n l ý S ự c ố ..................................................................................................................425
6.6.6.2 T u y ế n đ ầ u ( h ỗ t r ợ ) .................................................................................................................425
6.6.6.3 T u y ế n t h ứ h a i .............................................................................................................................426
6.6.6.4 T u y ế n t h ứ b a ..............................................................................................................................426
6.6.7 C á c V a i t r ò T h ự c h i ệ n Y ê u c ầ u ...........................................................................................427
6.6.8 C á c V a i t r ò Q u ả n l ý V ấ n đ ề ...................................................................................................428
6.6.8.1 N h à Q u ả n l ý V ấ n đ ề ...............................................................................................................428
6.6.8.2 C á c N h ó m G i ả i q u y ế t - V ấ n đ ề ...........................................................................................429
6.6.9 C á c V a i t r ò Q u ả n l ý T r u y c ậ p ...............................................................................................429
6.6.9.1 V a i t r ò c ủ a B ộ p h ậ n H ỗ t r ợ D ị c h v ụ ............................................................................430
6.6.9.2 V a i t r ò c ủ a Q u ả n l ý K ỹ t h u ậ t v à Q u ả n l ý Ứ n g d ụ n g .........................................431
6.6.9.3 V a i t r ò c ủ a Q u ả n l ý V ậ n h à n h C N T T ...........................................................................432
6.7 C á c C ấ u t r ú c T ổ c h ứ c V ậ n h à n h D ị c h v ụ ......................................................................432
6.7.1 T ổ c h ứ c t h e o c h u y ê n m ô n k ỹ t h u ậ t .................................................................................432
6.7.2 T ổ c h ứ c t h e o h o ạ t đ ộ n g ..........................................................................................................436
6.7.3 T ổ c h ứ c đ ể q u ả n l ý c á c q u y t r ì n h .....................................................................................439
6.7.4 T ổ c h ứ c V ậ n h à n h C N T T t h e o k h u v ự c đ ị a l ý ............................................................441
6.7.5 C á c c ấ u t r ú c t ổ c h ứ c h ỗ n h ợ p .............................................................................................444
6.7.5.1 C á c c h ứ c n ă n g đ ư ợ c k ế t h ợ p ...........................................................................................446
6.7.5.2 T ổ c h ứ c Q u ả n l ý K ỹ t h u ậ t v à Q u ả n l ý Ứ n g d ụ n g ................................................447
6.7.5.3 K h u v ự c đ ị a l ý ............................................................................................................................448
6.7.5.4 C ấ u t r ú c Q u ả n l ý K ỹ t h u ậ t v à Q u ả n l ý Ứ n g d ụ n g h ỗ n h ợ p ..........................450
7 N h ữ n g c â n n h ắ c v ề c ô n g n g h ệ .....................................................................................................451
7.1 C á c y ê u c ầ u c h u n g ......................................................................................................................451
7.1.1 T ự - H ỗ t r ợ ...........................................................................................................................................452
7.1.2 Đ ộ n g c ơ l u ồ n g c ô n g v i ệ c h o ặ c q u y t r ì n h .....................................................................452
7.1.3 C M S đ ư ợ c t í c h h ợ p ......................................................................................................................452
7.1.4 C ô n g n g h ệ K h á m p h á / T r i ể n k h a i / C ấ p p h é p ................................................................453
7.1.5 K i ể m s o á t t ừ x a .............................................................................................................................454
7.1.6 C á c t i ệ n í c h c h ẩ n đ o á n .............................................................................................................454
7.1.7 B á o c á o ...............................................................................................................................................454
7.1.8 B ả n g t h ô n g t i n t ổ n g q u a n ......................................................................................................455
7.1.9 T í c h h ợ p v ớ i Q u ả n l ý D ị c h v ụ N g h i ệ p v ụ .....................................................................455
7.2 Q u ả n l ý S ự k i ệ n .............................................................................................................................456
7.3 Q u ả n l ý S ự c ố .................................................................................................................................458
7.3.1 C ô n g n g h ệ I T S M đ ư ợ c t í c h h ợ p ..........................................................................................458
7.3.2 Q u y t r ì n h c ô n g v i ệ c v à l e o t h a n g đ ư ợ c t ự đ ộ n g h ó a ...........................................459
7.4 T h ự c h i ệ n y ê u c ầ u .......................................................................................................................459
7.5 Q u ả n l ý V ấ n đ ề ..............................................................................................................................460
7.5.1 C ô n g n g h ệ Q u ả n l ý D ị c h v ụ đ ư ợ c T í c h h ợ p ................................................................460
7.5.2 Q u ả n l ý T h a y đ ổ i ..........................................................................................................................460
7.5.3 C M S đ ư ợ c T í c h h ợ p .....................................................................................................................461
7.5.4 C ơ s ở d ữ l i ệ u L ỗ i đ ã b i ế t ........................................................................................................461
7.6 Q u ả n l ý T r u y c ậ p ..........................................................................................................................462
7.7 B ộ p h ậ n H ỗ t r ợ D ị c h v ụ ...........................................................................................................462
7.7.1 H ệ t h ố n g đ i ệ n t h o ạ i ...................................................................................................................462
7.7.2 C á c c ô n g c ụ h ỗ t r ợ ......................................................................................................................464
7.7.2.1 C ơ s ở d ữ l i ệ u L ỗ i đ ã b i ế t ....................................................................................................464
7.7.2.2 C á c t ậ p l ệ n h c h ẩ n đ o á n .......................................................................................................464
7.7.2.3 G i a o d i ệ n w e b T ự - H ỗ t r ợ ....................................................................................................465
7.7.2.4 K i ể m s o á t t ừ x a .........................................................................................................................467
7.7.3 H o ạ c h đ ị n h L i ê n t ụ c D ị c h v ụ đ ố i v ớ i c á c c ô n g c ụ h ỗ t r ợ I T S M ....................467
8 N h ữ n g c â n n h ắ c v ề t r i ể n k h a i .......................................................................................................468
8.1 Q u ả n l ý s ự t h a y đ ổ i t r o n g V ậ n h à n h D ị c h v ụ ............................................................468
8.1.1 C á c đ i ề u k i ệ n k í c h h o ạ t s ự t h a y đ ổ i ...............................................................................468
8.1.2 Đ á n h g i á t h a y đ ổ i ........................................................................................................................469
8.1.3 Đ o l ư ờ n g s ự t h à n h c ô n g c ủ a t h a y đ ổ i ...........................................................................470
8.2 V ậ n h à n h D ị c h v ụ v à Q u ả n l ý D ự á n ...............................................................................470
8.3 Đ á n h g i á v à q u ả n l ý r ủ i r o t r o n g V ậ n h à n h D ị c h v ụ ............................................471
8.4 Nhân viên vận hành trong quá trình Thiết kế Dịch vụ và Chuyển tiếp
D ị c h v ụ ..............................................................................................................................................................472
8.5 H o ạ c h đ ị n h v à T r i ể n k h a i n h ữ n g c ô n g n g h ệ Q u ả n l ý D ị c h v ụ .......................473
8.5.1 G i ấ y p h é p s ử d ụ n g ......................................................................................................................473
8.5.1.1 G i ấ y p h é p c h u y ê n b i ệ t ..........................................................................................................474
8.5.1.2 G i ấ y p h é p đ ư ợ c c h i a s ẻ .......................................................................................................474
8.5.1.3 G i ấ y p h é p t ừ t r a n g w e b .......................................................................................................474
8.5.1.4 D ị c h v ụ t h e o n h u c ầ u ............................................................................................................475
8.5.2 T r i ể n k h a i ..........................................................................................................................................476
8.5.3 K i ể m t r a c ô n g s u ấ t ......................................................................................................................477
8.5.4 T h ờ i đ i ể m t r i ể n k h a i c ô n g n g h ệ .........................................................................................478
8.5.5 K i ể u g i ớ i t h i ệ u ................................................................................................................................479
9 N h ữ n g t h á c h t h ứ c , C á c y ế u t ố T h à n h c ô n g Q u a n t r ọ n g v à r ủ i r o ........................480
9.1 N h ữ n g t h á c h t h ứ c ........................................................................................................................480
9.1.1 T h i ế u g ắ n k ế t v ớ i n h â n v i ê n d ự á n v à p h á t t r i ể n ..................................................480
9.1.2 C h ứ n g m i n h đ ể g ọ i v ố n t à i t r ợ ...........................................................................................482
9.1.3 N h ữ n g t h á c h t h ứ c đ ố i v ớ i c á c N h à q u ả n l ý V ậ n h à n h D ị c h v ụ ......................483
9.2 C á c Y ế u t ố T h à n h c ô n g q u a n t r ọ n g .................................................................................486
9.2.1 S ự h ỗ t r ợ c ủ a C ấ p Q u ả n l ý ....................................................................................................486
9.2.2 S ự h ỗ t r ợ c ủ a d o a n h n g h i ệ p .................................................................................................488
9.2.3 N h à v ô đ ị c h ......................................................................................................................................489
9.2.4 P h â n b ổ n h â n s ự v à d u y t r ì ...................................................................................................490
9.2.5 Đ à o t ạ o Q u ả n l ý D ị c h v ụ .........................................................................................................491
9.2.6 C á c c ô n g c ụ p h ù h ợ p .................................................................................................................492
9.2.7 T í n h h i ệ u l ự c c ủ a k i ể m n g h i ệ m ..........................................................................................492
9.2.8 Đ o l ư ờ n g v à b á o c á o ..................................................................................................................493
9.3 N h ữ n g r ủ i r o ........................................................................................................................................493
9.3.1 T ổ n t h ấ t d ị c h v ụ ...........................................................................................................................494
9.3.2 R ủ i r o đ ố i v ớ i V ậ n h à n h D ị c h v ụ t h à n h c ô n g ............................................................494
L ờ i b ạ t ...................................................................................................................................................................497
P h ụ l ụ c A : H ư ớ n g d ẫ n b ổ s u n g t r o n g n g à n h ...............................................................................498
A 1 C O B I T .........................................................................................................................................................499
A 2 I S O / I E C 2 0 0 0 0 .....................................................................................................................................500
A 3 C M M I ...........................................................................................................................................................501
A 4 T h ẻ đ i ể m C â n b ằ n g ...........................................................................................................................502
A 5 Q u ả n l ý C h ấ t l ư ợ n g ...........................................................................................................................503
A 6 I T I L v à K h u ô n k h ổ O S I ...................................................................................................................503
P h ụ l ụ c B : T r u y ề n t h ô n g t r o n g q u á t r ì n h V ậ n h à n h D ị c h v ụ ...........................................505
B 1 T r u y ề n t h ô n g v ậ n h à n h t h ư ờ n g l ệ ..........................................................................................505
B 2 T r u y ề n t h ô n g g i ữ a c á c c a l à m v i ệ c ........................................................................................507
B 3 B á o c á o H i ệ u s u ấ t ..............................................................................................................................508
H i ệ u s u ấ t D ị c h v ụ C N T T ........................................................................................................................508
H i ệ u s u ấ t n h ó m h o ặ c b ộ p h ậ n V ậ n h à n h D ị c h v ụ ................................................................509
H i ệ u s u ấ t c ủ a c ơ s ở h ạ t ầ n g h o ặ c q u y t r ì n h ..........................................................................511
B 4 T r u y ề n t h ô n g t r o n g c á c d ự á n ..................................................................................................514
B 5 T r u y ề n t h ô n g c ó l i ê n q u a n đ ế n n h ữ n g t h a y đ ổ i ...........................................................518
B 6 T r u y ề n t h ô n g c ó l i ê n q u a n đ ế n c á c n g o ạ i l ệ ...................................................................520
B 7 T r u y ề n t h ô n g c ó l i ê n q u a n đ ế n c á c t ì n h h u ố n g k h ẩ n c ấ p ......................................523
B 8 T r u y ề n t h ô n g v ớ i n g ư ờ i d ù n g v à k h á c h h à n g .................................................................526
P h ụ l ụ c C : K e p n e r v à T r e g o e .................................................................................................................528
C 1 X á c đ ị n h v ấ n đ ề ..................................................................................................................................528
C 2 M ô t ả v ấ n đ ề .........................................................................................................................................529
C 3 X á c l ậ p c á c n g u y ê n n h â n k h ả d ĩ ..............................................................................................530
C 4 K i ể m n g h i ệ m n g u y ê n n h â n k h ả d ĩ n h ấ t ...............................................................................530
C 5 X á c m i n h n g u y ê n n h â n t h ự c s ự ................................................................................................530
P h ụ l ụ c D : S ơ đ ồ I s h i k a w a ......................................................................................................................531
P h ụ l ụ c E : M ô t ả c h i t i ế t v ề Q u ả n l ý C ơ s ở v ậ t c h ấ t ............................................................534
E 1 Q u ả n l ý T ò a n h à ..................................................................................................................................535
E 2 L ư u t r ữ T h i ế t b ị ...................................................................................................................................536
E 3 Q u ả n l ý N g u ồ n đ i ệ n ..........................................................................................................................538
E 4 Đ i ề u k i ệ n M ô i t r ư ờ n g v à c á c H ệ t h ố n g C ả n h b á o .........................................................540
E 5 A n t o à n ......................................................................................................................................................543
E 6 K i ể m s o á t T r u y c ậ p V ậ t l ý ............................................................................................................543
E 7 G i a o n h ậ n h à n g h ó a .........................................................................................................................544
E 8 T h a m g i a v à o Q u ả n l ý H ợ p đ ồ n g .............................................................................................545
E 9 B ả o t r ì ........................................................................................................................................................546
P h ụ l ụ c F : K i ể m s o á t T r u y c ậ p V ậ t l ý ..............................................................................................547
C h ú g i ả i ................................................................................................................................................................556
D a n h s á c h t ừ v i ế t t ắ t ..............................................................................................................................556
D a n h s á c h c á c đ ị n h n g h ĩ a ....................................................................................................................563
Lờ i t ự a
Lờ i t ự a c ủa O CG
Kể từ khi ra đời, ITIL đã không ngừng phát triển để trở thành
phương pháp tiếp cận được chấp nhận rộng rãi nhất trên thế giới để
quản lý dịch vụ CNTT. Tuy nhiên, cùng với sự thành công này là
trách nhiệm phải đảm bảo rằng các hướng dẫn giữ được nhịp độ tiến
triển tương xứng với một môi trường kinh doanh toàn cầu đang
không ngừng thay đổi. Các yêu cầu quản lý dịch vụ, không nghi ngờ
gì, được định hình bởi sự phát triển của công nghệ, các mô hình
kinh doanh được điều chỉnh và sự gia tăng của những kỳ vọng của
khách hàng. Phiên bản ITIL mới nhất của chúng tôi đã được tạo ra
để thích ứng với những sự phát triển đó.
Ấn phẩm này là một trong năm ấn phẩm cốt lõi tạo nên ITIL mô tả
về những thực tiễn quản lý dịch vụ CNTT. Chúng là kết quả của một
dự án 2 năm để xem xét và cập nhật các hướng dẫn. Số lượng
chuyên gia quản lý dịch vụ trên toàn thế giới, những người đã giúp
phát triển nội dung của các ấn phẩm này là rất ấn tượng. Những
kinh nghiệm và kiến thức của họ đã đóng góp cho nội dung để mang
đến cho bạn một bộ hướng dẫn nhất quán có chất lượng cao. Điều
này được hỗ trợ bởi sự phát triển liên tục của một chương trình phát
triển toàn diện cùng với sự đào tạo và tham vấn đã được công nhận.
Dù cho bạn là nhân viên của một công ty toàn cầu, một cơ quan
chính phủ hoặc một doanh nghiệp nhỏ, ITIL mang đến cho bạn
quyền tiếp cận với những kiến thức chuyên môn quản lý dịch vụ
đẳng cấp thế giới. Về cơ bản, nó đặt các dịch vụ CNTT ở đúng nơi
mà chúng thuộc về - tại trung tâm của sự thành công của các hoạt
động kinh doanh.
Peter Fanning
Quyền Giám đốc Điều hành
Văn phòng Thương mại Chính phủ (Vương quốc Anh)
Lờ i t ự a c ủa Ki ến tr úc sư trư ở ng
Hướng dẫn Thực tiễn Quản lý Dịch vụ ITIL được cấu trúc xoay quanh
Vòng đời Dịch vụ. Điều phổ biến trong suốt vòng đời là, thực tiễn
tổng thể, tự bản thân nó, vốn dựa trên các quy trình, chức năng,
hoạt động, mô hình tổ chức và biện pháp đo lường, cùng với nhau
để cho phép Quản lý Dịch vụ CNTT (ITSM) được tích hợp với các quy
trình nghiệp vụ, mang lại những giá trị vô giá và thúc đẩy ngành
CNTT tiến về phía trước trong việc theo đuổi của chúng ta về sự
xuất sắc của dịch vụ.
Không có nơi nào trong Vòng đời Dịch vụ ITIL có ảnh hưởng đến
cách làm thế nào chúng ta thực hiện như cách mà nhà cung cấp dịch
vụ tiếp xúc với khách hàng một cách mật thiết như Vận hành Dịch
vụ. Đây là nơi mà chiến lược, thiết kế, chuyển tiếp và các cải thiện
được phân phối và hỗ trợ trên cơ sở hàng ngày.
Ấn phẩm Vận hành Dịch vụ mang Quản lý Dịch vụ vào đời sống
doanh nghiệp, và chịu trách nhiệm cho hiệu suất của các dịch vụ,
con người tạo ra chúng và những công nghệ cho phép chúng được
giám sát, kiểm soát và cung cấp trong giai đoạn này của Vòng đời
Dịch vụ.
Ấn phẩm này giúp hướng dẫn chúng ta mọi thứ để đạt được sự xuất
sắc của dịch vụ và tìm kiếm giá trị của ITSM theo một quan điểm
được tập trung vào-doanh nghiệp, rộng lớn hơn về nó. Bất kể bạn là
một người mới tiếp cận thực tiễn ITIL hay là một học viên dày dạn
kinh nghiệm, hướng dẫn trong ấn phẩm này sẽ mở rộng tầm nhìn và
kiến thức của bạn về cách làm thế nào để trở thành nhà cung cấp
dịch vụ tốt nhất thông qua việc triển khai Vận hành Dịch vụ.
Có một câu nói rằng thước ngắm là 20/20. Hướng dẫn trong Vận
hành Dịch vụ được đúc kết từ hơn 20 năm kinh nghiệm của các
chuyên gia ITSM, các doanh nhân và nh ững người thực hành ITSM
trên toàn thế giới và những bài học kinh nghiệm của họ về việc dịch
vụ xuất sắc là gì và làm thế nào để đạt được nó.
Bất kỳ ai tham gia vào việc vận hành các dịch vụ sẽ hưởng lợi từ
hướng dẫn trong những trang sách của ấn phẩm này dưới đây. Vận
hành Dịch vụ đưa ra những lời khuyên và hướng dẫn tốt nhất từ
khắp nơi trên thế giới và lộ trình dẫn đến những gì khả dĩ trong
tương lai của bạn.
Sharon Taylor
Kiến trúc sư trưởng, Thực tiễn Quản lý Dịch vụ ITIL
Lờ i gi ớ i thi ệu
Ấn phẩm này bao gồm và thay thế cho những khía cạnh thuộc về vận
hành của các ấn phẩm Hỗ trợ Dịch vụ và Cung cấp Dịch vụ ITIL và
cũng bao hàm phần lớn phạm vi của Quản lý Cơ sở hạ tầng ICT. Nó
cũng kết hợp các yếu tố thuộc về vận hành từ các ấn phẩm Hoạch
định để Triển khai, Quản lý Ứng dụng, Quản lý Tài sản Phần mềm và
Quản lý Bảo mật.
Những nguyên tắc cơ bản của thực tiễn tốt nhất của quản lý dịch vụ
CNTT đã được bao gồm trong các phiên bản trước đây của ITIL vẫn
có hiệu lực. Lẽ thường vẫn là lẽ thường!
Tuy nhiên, những công nghệ, công cụ và mối quan hệ đã thay đổi
một cách đáng kể, thậm chí trong một thời điểm tương đối ngắn
ngủi kể từ khi phiên bản mới nhất của ITIL đã được hoàn thành.
Trong khi ấn phẩm này tái sử dụng và cập nhật những tài liệu liên
quan từ các phiên bản cũ hơn, khi thích hợp, nó cũng bao gồm rất
nhiều khái niệm mới và những thực tiễn trong ngành để đưa ra phạm
vi hoàn chỉnh của hướng dẫn thực tiễn-tốt nhất cho Vận hành Dịch
vụ ngày nay trong một tập đơn lẻ, cho môi trường kinh doanh và
công nghệ ngày nay.
Thông tin li ê n h ệ
Toàn bộ chi tiết của một loạt tài liệu đã được công bố theo quảng bá
của ITIL có thể được tìm thấy trên trang web tại địa chỉ www.best-
management-practice.com/itil
Nếu bạn muốn báo cho chúng tôi về bất kỳ thay đổi nào có thể cần
thiết cho ấn phẩm này, xin vui lòng ghi nhận chúng tại địa chỉ
www.best-management-practice.com/changelog
Thông tin thêm về việc chứng nhận và đào tạo công nhận, vui lòng
truy cập trang web www.itil-officialsite.com. Ngoài ra, hãy liên hệ:
APMG Service Desk

Sword House
Totteridge Road
High Wycombe
Buckinghamshire
HP13 6DG
Điện thoại: +44 (0) 1494 452 450
Email: servicedesk@apmgroup.co.uk
Lờ i c ả m ơn
Kiến trúc sư trưởng và các tác giả
Sharon Taylor (Aspect Group Inc) Kiến trúc sư trưởng
David Cannon (HP) Tác giả
David Wheeldon (HP) Tác giả
Nhóm thiết kế ITIL

Nhóm thiết kế ITIL đã đóng góp cho hướng dẫn này thông qua các
bình luận và căn chỉnh với toàn bộ các ấn phẩm. Vì vậy, xin dành lời
cảm ơn cho các tác giả ITIL khác, đặc biệt là Jeroen Bronkhorst
(HP), Gary Case (Pink Elephant), Ashley Hanna (HP), Majid Iq bal
(Carnegie Mellon University), Shirley Lacy (ConnectSphere), Vernon
Lloyd (Fox IT), Ivor Macfarlane (Guillemot Rock), Michael Nieves
(Accenture), Stuart Rance (HP), Colin Rudd (ITEMS) và George
Spalding (Pink Elephant).
Các cố vấn
Christian Nissen và Paul Wilkinson.
Những đóng góp khác

Một số người đã đóng góp một cách hào phóng thời gian và kiến
thức chuyên môn của họ cho ấn phẩm Vận hành Dịch vụ này. Jim
Clinch, Giám đốc Dự án của OGC, rất biết ơn sự hỗ trợ của HP đối
với nhóm thiết kế trong việc phát triển ấn phẩm này và đặc biệt là
sự đóng góp của Peter Doherty và Robert Stroud, và cho s ự hỗ trợ
của Jenny Dugmore, Convenor of Working Group ISO/IEC 20000,
Janine Eves, Carol Hulm, Aidan Lawes và Michiel van der Voort.
Các tác giả cũng muốn bày tỏ lòng biết ơn đến Stuart Rance và
Ashley Hanna từ Hewlett-Packard, Christian F Nissen (Itilligence),
Maria Vase (Itilligence), Eu Jin Ho (UBS), Jan Bjerregaard, (Sun
Microsystems), Jan Øberg (ØBERG Partners), Lars Zobbe Mortensen
(Zobbe Consult & Zoftware), Mette Nielsen (Carlsberg IT), Michael
Imhoff (IBM), Niels Berner (Novo Nordisk), Nina Schertiger (HP),
Signe-Marie Hernes Bjerke (DNV), Steen Sverker Nilsson
(Westergaard CSM), Ulf Myrberg (BiTa), Russell Jukes, Debbi
Jancaitis, Sheldon Parmer, Ramon Alanis, Tim Benson và Nenen Ong
từ Hewlett-Packard IT, Jaye Thompson, Dee Seymour, Vàranik
Ziyalyan, Young Chang, Lauren Abernethy, April McCowan, Becky
Wershbale, Rob Garman, Scott McPherson, Svàra Breading, Rick
Streeter, Leon Gantt, Charlotte Devine, Greg Algorri, Mary Fischer,
Bill Thayer và Diana Osberg từ The Walt Disney Company’s
Enterprise IT, Dennis Deane và John Sowerby of DHL, Richard Fahey
và Chris Hughes từ HP Global Delivery Application Services, Cindi
Locker và Dhiraj Gupta of Progressive Casualty Insurance Company,
Peter Doherty và Robert Stroud t ừ Computer Associates và Paul
Tillston từ Hewlett-Packard, Brian Jakubec, Vernon Blakes, Angela
Chin, Colin Lovell, Ken Hamilton, Rose Lariviere, Jenny McPhee, Tom
Nielsen, Roc Paez, Lloyd Robinson, Paul Wilmot, Jeanette Smith và
Ken Wendle of Hewlett-Packard.
Nhằm phát triển những Thực tiễn Quản lý Dịch vụ ITIL để phản ảnh
thực tiễn tốt nhất hiện hành và đưa ra những ấn phẩm có giá trị lâu
dài, OGC đã tham vấn một cách rộng rãi với các bên liên quan trên
toàn thế giới tại mọi giai đoạn trong quá trình. OGC cũng mu ốn cảm
ơn những cá nhân dưới đây và tổ chức của họ vì những đóng góp
của họ để làm mới những hướng dẫn ITIL:
Nhóm Tư vấn ITIL
Pippa Bass, OGC; Tony Betts, Independent; Signe -Marie Hernes
Bjerke, Det Norske Veritas; Alison Cartlidge, Xansa; Diane Colbeck,
DIYmonde Solutions Inc; Ivor Evans, DIYmonde Solutions Inc; Karen
Ferris, ProActive; Malcolm Fry, FRY -Consultants; John Gibert,
Independent; Colin Hamilton, RENARD Consulting L td; Lex Hendriks,
EXIN; Carol Hulm, British Computer Society -ISEB; Tony Jenkins,
DOMAINetc; Phil Montanaro, EDS; Alan Nance, ITPreneurs; Christian
Nissen, Itilligence; Don Page, Marval Group; Bill Powell, IBM; Sergio
Rubinato Filho, CA; James Siminoski, SO Scorp; Robert E. Stroud, CA;
Jan van Bon, Inform-IT; Ken Wendle, HP; Paul Wilkinson, Getronics
PinkRoccade; Takashi Yagi, Hitachi.
Những người đánh giá

Jorge Acevedo, Computec S.A; Balaji Alapilla; Valerie Arraj, InteQ;
Colin Ashcroft, City of London; Will iam Bagley, Amgreetings; Martijn
Bakker, Getronics PinkRoccade; Jeff Bartrop, BT & Customer Service
Direct; Rajesh Basava Amatyappa Bellary, Satyam; John Bennett,
Centram Ltd; Ian Bevan, Fox IT; Enrico Boverino, CA; Bart Van
Brabant, Post; Ronald Browning, CA; Stephen Bull, Sierra Systems;
Bradley Busch, InTotality; Howard Carpenter, IBM; Liang Cheng,
IBM; John Clark, HP; Nicole Conboy, Nicole Conboy & Associates;
Sharon Dale, aQuip International; Sandra Daly, Dawling Consultancy;
Tony Domain, Blue Yonder; Michael Donahue, IBM; Ken Doughty;
Andre J. Emmell, DKMStech; Matthew Evans, Process Worx; Juan
Antonio Fernandez, Quint Wellington Redrood; Karen Ferris,
Proactive Services; Juan Jose Figueiras, Globant; Liz Gallacher; Rae
Garrett, Pink Elephant; Klaus Go edel, HP; David Gooda, Genesys
Consulting; Detlef Gross, Automation Consulting Group GmbH;
Matthias Hall, University of Dundee; John Hannan, Best Practice IT;
Jonas Hansen, MMIT; Oliver Hast, Scoops; Jabe Hickey, IBM; Graham
Hill, Metisc; Kevin Hite, Micro soft; Sergio Hrabinski, Xelere; Scott
Jaegar, Plexant; Chris Jay; Chunyang Jia, Microsoft; Masthan Kadhar
Kadhar, Cognizant; Tony Kelman -Smith, HP; Peter Koepp,
Independent; Joanne Kopcho, Capgemini America; Rene van Kuijen;
Debbie Langenfield, IBM; Horacio Laprea; Sarah Lascelles,
Interserve Project Services Ltd; Peter Loos, Accenture Services
GmbH; Marcos Lopez, Microsoft; Emmanuel Marchand, Advens;
James Marmion, Yell Group; Jesus Martin, Ibermatica SA; Luis
Moran, Independent; Steve Morgan, KPMG; Ron Mo rton, HP; Philip
Mougis, TCS; Richard Mulholland, IBM; Ron Muns, HDI; Darren
Murtagh, Retravision; Krisna Nugraha, Cleon Consulting; Shuichi
Owa, Niandc; Sampo Pasanen, Efecte; Rodrigo Pementa, Pink
Elephant; Eddy Peters, CTG; Steve Phelan, Moon Monkey; C arol
Piccus, CA; Poul Mols Poulsen, Coop Norden IT; Roger Purdie, The
Art of Service; Glen Ralph, iCore Ltd; Padmini Ramamurthy, Satyam
Computer Services Ltd; Keith Reynolds, NSS Consulting; Manfred
Rieder, HP; Stephanie Roddy, Camelot Group; Mieke Roelen s, CTA;
Frances Scarff, OGC; Markus Schiemer, Unisys; Barbara Schiesser,
Swiss ICT; Klaus Seidel, Microsoft; Migel Sergey; Mamak Shafai;
Prakash Sharma; Gilbert Silva, Techbiz Informatica Ltd; Jim
Siminoski, Soscorp; Dierk Soellner, Mod -gruppe; Joseph Stephen,
Department of Transportation, US Government; Michala Sterling, Mid
Sussex District Council; Helen Sussex, Logic acmg; Rohan
Thuraisingham, Friends Provident Management Services Ltd;
Matthew Tolman, Sandvik; Cheryl Tovizi, MWH Global; Frank Victor,
Victor GmbH; Corde Wagner; Christoph Wettstein, CLAVIS klw AG;
Andi Wijaya, IBM; Aaron Wolfe, Pink Elephant; Mike Yang, IBM;
YoungHoon Youn, IBM.
1 Giớ i th i ệu
Ấn phẩm này cung cấp những lời khuyên và hướng dẫn về thực tiễn
tốt nhất trên mọi khía cạnh của việc quản lý hoạt động hàng ngày
của các dịch vụ công nghệ thông tin (CNTT) của một tổ chức. Nó
bao gồm các vấn đề liên quan đến con người, quy trình, công nghệ
cơ sở hạ tầng và các mối quan hệ cần thiết để đảm bảo cung cấp
Dịch vụ CNTT có chất lượng cao, hiệu quả về chi phí, cần thiết đế
đáp ứng các nhu cầu của doanh nghiệp.
Sự ra đời của những công nghệ mới và ranh giới mờ nhạt giữa các
hầm ngầm công nghệ truyền thống về quản lý phần cứng, mạng,
điện thoại và phần mềm ứng dụng có nghĩa là một phương pháp tiếp
cận được cập nhật để quản lý vận hành dịch vụ là điều cần thiết.
Các tổ chức ngày càng gia tăng khả năng cân nhắc những cách thức
khác nhau về việc cung cấp CNTT của họ với chi phí và tính linh
hoạt tối ưu, với việc ra mắt tiện ích CNTT, các Dịch vụ CNTT thanh
toán-khi-sử dụng, cung cấp CNTT ảo hóa, công suất linh động và
điện toán Thích ứng Doanh nghiệp, cũng như các tùy chọn cung ứng-
tác vụ và thuê ngoài.
Những giải pháp thay thế này đã dẫn đến vô số mối quan hệ kinh
doanh CNTT, cả trong nội bộ lẫn bên ngoài, đã gia tăng mức độ
phức tạp cũng nhiều như những công nghệ đang được quản lý. Sự
phụ thuộc của doanh nghiệp vào những mối quan hệ phức tạp đó
ngày càng trở nên tối quan trọng để tồn tại và thành công.
1.1 Tổng quan

Vận hành Dịch vụ là một giai đoạn trong Vòng đời ITSM chịu trách
nhiệm cho các hoạt động ‘kinh doanh-như-thường lệ’.
Vận hành Dịch vụ có thể được xem như là ‘nhà máy’ của CNTT. Điều
này hàm ý về sự tập trung gần gũi hơn vào các hoạt động hàng ngày
và cơ sở hạ tầng được sử dụng để cung cấp dịch vụ. Tuy nhiên, ấn
phẩm này dựa trên việc thấu hiểu rằng mục đích quan trọng hơn của
Vận hành Dịch vụ là để cung cấp và hỗ trợ cho các dịch vụ. Quản lý
cơ sở hạ tầng và các hoạt động vận hành phải luôn luôn hỗ trợ cho
mục đích này.
Các quy trình được hoạch định và triển khai tốt sẽ hoàn toàn không
có giá trị nếu như hoạt động hàng ngày của các quy trình đó không
được tiến hành, kiểm soát và quản lý một cách đúng đắn. Cải tiến
dịch vụ cũng sẽ không thể khả thi nếu như các hoạt động hàng ngày
để giám sát hiệu suất, đánh giá các chỉ số và thu thập dữ liệu không
được tiến hành một cách có hệ thống trong quá trình Vận hành Dịch
vụ.
Nhân viên Vận hành Dịch vụ nên có sẵn các quy trình và công cụ hỗ
trợ để cho phép họ có một cái nhìn tổng thể về Vận hành Dịch vụ và
cung cấp (dịch vụ) (thay vì chỉ là các thành phần riêng biệt, chẳng
hạn như phần cứng, phần mềm ứng dụng và mạng, vốn tạo nên dịch
vụ từ đầu-đến-cuối, theo quan điểm của doanh nghiệp) và để nhận
diện bất kỳ mối đe dọa hoặc lỗi đối với chất lượng dịch vụ.
Khi dịch vụ có thể được cung cấp, toàn bộ hoặc từng phần, bởi một
hoặc nhiều đối tác/tổ chức nhà cung cấp, quan điểm của Vận hành
Dịch vụ về dịch vụ từ đầu-đến-cuối phải được mở rộng để kết hợp
các khía cạnh bên ngoài của việc cung cấp dịch vụ - khi các quy
trình và công cụ tương tác hoặc được chia sẻ cần thiết là cần có để
quản lý các quy trình công việc trên toàn tổ chức.
Vận hành Dịch vụ có thể là một đơn vị thuộc tổ chức hoặc là một
quy trình đơn lẻ - nhưng nó bao gồm một vài chức năng và rất nhiều
quy trình và hoạt động, sẽ được mô tả trong các Chương 4, 5 và 6.
1.2 Bối cảnh
1.2.1 Quản lý Dịch vụ

CNTT là một thuật ngữ được sử dụng một cách phổ biến và thay đổi
ý nghĩa theo bối cảnh. Từ quan điểm đầu tiên, các hệ thống CNTT,
các ứng dụng và cơ sở hạ tầng là các thành phần hoặc tổ hợp-con
của một sản phẩm lớn hơn. Chúng cho phép hoặc đưuọc nhúng vào
trong các quy trình và dịch vụ. Xét từ quan điểm thứ hai, CNTT là
một tổ chức với bộ các năng lực và tài nguyên của riêng mình. Các
tổ chức CNTT có thể có nhiều kiểu khác nhau như các chức năng
nghiệp vụ, các đơn vị dịch vụ được chia sẻ và toàn bộ các đơn vị cốt
lõi của doanh nghiệp.
Nhìn từ quan điểm thứ ba, CNTT là một loại dịch vụ được sử dụng
bởi doanh nghiệp. Chúng thường là các ứng dụng và cơ sở hạ tầng
CNTT được đóng gói và đề xuất dưới hình thức các dịch vụ bởi tổ
chức CNTT nội bộ hoặc các nhà cung cấp bên ngoài. Chi phí CNTT
được tính là chi phí kinh doanh. Và quan đi ểm thứ tư cho rằng CNTT
là một loại tài sản doanh nghiệp cung cấp một dòng lợi ích cho các
chủ sở hữu của chúng, bao gồm, nhưng không giới hạn, doanh thu,
doanh số và lợi nhuận. Chi phí IT được xem là các khoản đầu tư.
1.2.2 Những thực tiễn tốt trong lĩnh vực công

Các tổ chức hoạt động trong những môi trường năng động với nhu
cầu học hỏi và thích nghi. Nhu cầu cải thiện hiệu suất tồn tại song
song với việc quản lý sự đánh đổi. Dưới áp lực tương tự, khách hàng
cũng tìm kiếm lợi thế từ các nhà cung cấp dịch vụ. Họ theo đuổi các
chiến lược nguồn cung ứng phục vụ tốt nhất cho các mối bận tâm
trong kinh doanh của mình. Tại rất nhiều quốc gia, các cơ quan
chính phủ và các doanh nghiệp phi-lợi nhuận cũng có xu hướng
tương tự để thuê ngoài vì tính hiệu quả của hoạt động. Điều này gây
ra thêm áp lực cho các nhà cung cấp dịch vụ để duy trì một lợi thế
cạnh tranh liên quan đến các giải pháp thay thế mà khách hàng có
thể có. Việc gia tăng xu hướng thuê ngoài đã đặc biệt khiến cho các
nhà cung cấp nội bộ đã gặp phải sự cạnh tranh bất thường.
Để ứng phó với áp lực này, các tổ chức đo lường điểm chuẩn chính
bản thân mình so với các đối thủ và tìm cách thu hẹp khoảng cách
về năng lực. Một cách để thu hẹp những khoảng cách như vậy là
thông qua những thực tiễn tốt trong toàn ngành. Có một số nguồn
cung cấp những thực tiễn tốt, bao gồm các khuôn khổ, tiêu chuẩn và
công khai, những kiến thức độc quyền của các tổ chức và các cá
nhân (xem Hình 1.1).
Hình 1.1 – Nguồn cung cấp Thực tiễn Quản lý Dịch vụ
Các khuôn khổ và tiêu chuẩn công khai rất thu hút khi so sánh với
những kiến thức độc quyền:
 Kiến thức độc quyền được nhúng sâu vào trong các tổ chức và
do đó rất khó để áp dụng, sao chép hoặc truyền tải, thậm chí
cả với sự cộng tác của các chủ sở hữu. Những kiến thức đó
thường có dạng kiến thức ngầm, vốn thường không thể thoát
được và được lập thành tài liệu một cách kém cỏi.
 Kiến thức độc quyền được tùy chỉnh cho các bối cảnh cục bộ và
những nhu cầu kinh doanh cụ thể, đến mức mang một phong
cách riêng. Trừ khi những người nhận được kiến thức đó phù
hợp với hoàn cảnh, tình huống, kiến thức có thể sẽ không được
sử dụng hiệu quả.
 Chủ sở hữu của kiến thức độc quyền kỳ vọng nhận được phần
thưởng cho khoản đầu tư dài hạn của họ. Họ có thể khiến cho
những kiến thức đó chỉ sẵn sàng với các điều kiện thương mại,
thông qua các thỏa thuận mua sắm và cấp phép.
 Các khuôn khổ và tiêu chuẩn sẵn có công khai chẳng hạn như
ITIL, Control Objectives for IT (COBIT), CMMI, eSCM -SP,
PRINCE2, ISO 9000, ISO 20000 và ISO 27001 đã đư ợc thẩm
định qua nhiều môi trường và tình huống khác nhau thay vì
kinh nghiệm bị giới hạn của một tổ chức đơn lẻ. Chúng là đối
tượng của sự xem xét rộng rãi trên nhiều tổ chức và ngành
khoa học. Chúng được kiểm tra bởi rất nhiều đối tác, nhà cung
cấp và đối thủ cạnh tranh.
 Những kiến thức của các khuôn khổ công khai có nhiều khả
năng được phân phối một cách rộng rãi giữa cộng đồng của rất
nhiều chuyên gia thông qua các khóa đào t ạo và chứng nhận
sẵn có công khai. Các tổ chức dễ dàng hơn để có được kiến
thức đó thông qua thị trường nhân lực.
Việc bỏ qua các khuôn khổ và tiêu chuẩn công khai có thể không
nhất thiết đặt một tổ chức vào tình huống bất lợi. Các tổ chức nên
trau dồi những kiến thức độc quyền của riêng mình trên những trang
đầu của khối kiến thức dựa trên các khuôn khổ và tiêu chuẩn công
khai. Sự cộng tác và phối hợp giữa các tổ chức sẽ dễ dàng hơn trên
cơ sở những thực tiễn và tiêu chuẩn được chia sẻ.
1.2.3 ITIL và những thực tiễn tốt trong Quản lý

Dịch vụ
Bối cảnh của ấn phẩm này là Khuôn khổ ITIL như là một nguồn cung
cấp của thực tiễn tốt trong Quản lý Dịch vụ. ITIL được sử dụng bởi
các tổ chức trên toàn thế giới để xác lập và cải thiện những năng
lực Quản lý Dịch vụ. ISO/IEC 20000 cung cấp một tiêu chuẩn phổ
quát và chính thức cho các tổ chức đang tìm cách để có được năng
lực Quản lý Dịch vụ đã được kiểm nghệm và chứng nhận. Trong khi
ISO/IEC là một tiêu chuẩn cần đạt được và duy trì, ITIL cung cấp
một khối kiến thức hữu ích để đạt được tiêu chuẩn đó.
Thư viện ITIL có những thành phần sau đây:
 Cốt lõi ITIL: hướng dẫn thực tiễn-tốt nhất có thể được áp
dụng cho mọi loại tổ chức cung cấp các dịch vụ cho doanh
nghiệp.
 Hướng dẫn bổ sung ITIL: một bộ các ấn phẩm bổ sung với
các hướng dẫn cụ thể cho các lĩnh vực ngành, các loại hình tổ
chức, các mô hình hoạt động và các kiến trúc công nghệ.
Cốt lõi ITTIL bao gồm 5 ấn phẩm (xem Hình 1.2). Từng ấn phẩm
cung cấp những hướng dẫn cần thiết cho một phương pháp tiếp cận
được tích hợp được yêu cầu bởi đặc tả kỹ thuật của tiêu chuẩn
ISO/IEC 20000:
 Chiến lược Dịch vụ,

 Thiết kế Dịch vụ,
 Chuyển tiếp Dịch vụ,
 Vận hành Dịch vụ,
 Liên tục Cải tiến Dịch vụ.
Hình 1.2 – Cốt lõi ITIL
Mỗi ấn phẩm xác định các năng lực có tác động trực tiếp đến hiệu
suất của nhà cung cấp dịch vụ. Cấu trúc của cốt lõi có hình thái một
vòng đời. Nó là sự lặp đi lặp lại và đa chiều. Nó đảm bảo rằng các
tổ chức được thiết lập để tận dụng năng lực trong một lĩnh vực để
học hỏi và cải thiện trong những lĩnh vực khác. Cốt lõi được kỳ vọng
là cung cấp được cấu trúc, sự ổn định và sức mạnh cho năng lực
Quản lý Dịch vụ, với các nguyên tắc, phương pháp và công cụ bền
bỉ. Điều này phụng sự để bảo vệ cho các khoản đầu tư và cung cấp
cơ sở cần thiết để đo lường, học hỏi và cải thiện.
Những hướng dẫn trong ITIL có thể được thích ứng để thay đổi việc
sử dụng trong các môi trường kinh doanh và chiến lược tổ chức khác
nhau. Hướng dẫn Bổ sung cung cấp sự linh hoạt để triển khai Cốt lõi
trong một loạt các môi trường đa dạng. Những người thực hiện có
thể lựa chọn Hướng dẫn Bổ sung khi cần để cung cấp lực kéo đối với
Cốt lõi trong bối cảnh kinh doanh nhất định, nhiều như loại lốp xe
được lựa chọn dựa trên loại xe ô tô, mục đích và điều kiện đường
sá. Việc này là nhằm để gia tăng tính bền bỉ và linh động của tài sản
kiến thức và để bảo vệ các khoản đầu tư vào năng lực Quản lý Dịch
vụ.
1.2.3.1 Chiến lược Dịch vụ

Ấn phẩm Chiến lược Dịch vụ cung cấp hướng dẫn về việc làm thế nào
để thiết kế, phát triển và triển khai Quản lý Dịch vụ không chỉ như
một năng lực của tổ chức mà còn như là một tài sản chiến lược.
Hướng dẫn được cung cấp trên các nguyên tắc làm nền tảng cho
thực tiễn Quản lý Dịch vụ vốn rất hữu ích cho việc phát triển các
chính sách, hướng dẫn và quy trình Quản lý Dịch vụ trong toàn bộ
vòng đời dịch vụ ITIL. Hướng dẫn Chiến lược Dịch vụ rất hữu ích
trong bối cảnh của Thiết kế Dịch vụ, Chuyển tiếp Dịch vụ, Vận hành
Dịch vụ và Liên tục Cải tiến Dịch vụ. Các chủ đề được đề cập đến
trong Chiến lược Dịch vụ bao gồm sự phát triển của thị trường, nội
bộ và bên ngoài, các tài sản dịch vụ, mục lục dịch vụ, và sự triển
khai chiến lược thông qua vòng đời dịch vụ. Quản lý Tài chính, quản
lý Danh mục Dịch vụ, phát triển tổ chức và các rủi ro chiến lược nằm
giữa các chủ đề chính yếu này.
Các tổ chức sử dụng hướng dẫn này để thiết lập các mục tiêu và kỳ
vọng về hiệu suất hướng tới việc phục vụ khách hàng và không gian
thị trường, và để xác định, lựa chọn và thiết lập độ ưu tiên cho các
cơ hội. Chiến lược Dịch vụ là về việc đảm bảo rằng các tổ chức ở vị
thế sẵn sàng xử lý các chi phí và rủi ro liên quan đến Danh mục Dịch
vụ của họ, và được thiết lập không chỉ để hoạt động hiệu quả mà
còn vì hiệu suất khác biệt. Các quyết định được đưa ra về Chiến
lược Dịch vụ có những hậu quả sâu rộng bao gồm cả những quyết
định có hiệu lực chậm.
Các tổ chức đang thực hành ITIL sử dụng ấn phẩm này để hướng
dẫn một đánh giá chiến lược về những năng lực Quản lý Dịch vụ dựa
trên-ITIL của mình và để cải thiện sự liên kết giữa những năng lực
đó và các chiến lược kinh doanh. Ấn phẩm ITIL này khuyến khích
độc giả nên dừng lại và suy nghĩ về việc tại sao một số điều được
hoàn thành trước khi nghĩ về việc như thế nào. Những câu trả lời
cho kiểu câu hỏi thứ nhất gần gũi hơn với việc kinh doanh của khách
hàng. Chiến lược Dịch vụ mở rộng phạm vi của khuôn khổ ITIL vượt
khỏi các chuyên gia vốn là đối tượng truyền thống của Quản lý Dịch
vụ CNTT.
1.2.3.2 Thiết kế Dịch vụ

Ấn phẩm Thiết kế Dịch vụ cung cấp hướng dẫn dành cho thiết kế và
phát triển các dịch vụ và các quy trình Quản lý Dịch vụ. Nó bao gồm
các nguyên tắc và phương pháp thiết kế để chuyển đổi các mục tiêu
chiến lược thành các danh mục dịch vụ và tài sản dịch vụ. Phạm vi
của Thiết kế Dịch vụ không chỉ giới hạn ở các dịch vụ mới. Nó bao
gồm cả những thay đổi và cải thiện cần thiết để gia tăng hoặc duy
trì giá trị cho khách hàng thông qua vòng đ ời của các dịch vụ, tính
liên tục của các dịch vụ, việc đạt được các mức dịch vụ, và tuân thủ
các tiêu chuẩn và quy định. Nó hướng dẫn cho các tổ chức về cách
làm thế nào để phát triển những năng lực thiết kế cho Quản lý Dịch
vụ.
1.2.3.3 Chuyển tiếp Dịch vụ
Ấn phẩm Chuyển tiếp Dịch vụ cung cấp hướng dẫn cho việc phát
triển và cải thiện những năng lực chuyển tiếp các dịch vụ mới và đã
được thay đổi vào hoạt động. Ấn phẩm này cung cấp hướng dẫn cách
các yêu cầu của Chiến lược Dịch vụ được mã hóa trong Thiết kế Dịch
vụ được hiện thực hóa một cách hiệu quả trong Vận hành Dịch vụ
như thế nào đồng thời kiểm soát những rủi ro từ thất bại và gián
đoạn. Ấn phẩm này kết hợp các thực tiễn trong quản lý phát hành,
quản lý chương trình và quản lý rủi ro và đặt chúng vào trong bối
cảnh thực tế của Quản lý Dịch vụ. Nó cung cấp hướng dẫn về việc
quản lý độ phức tạp liên quan tới những thay đổi trong các dịch vụ
và quy trình Quản lý Dịch vụ, ngăn ngừa những hậu quả không mong
muốn đồng thời cho phép đổi mới. Hướng dẫn được cung cấp về việc
chuyển đổi quyền kiểm soát các dịch vụ giữa khách hàng và nhà
cung cấp dịch vụ.
1.2.3.4 Vận hành Dịch vụ

Ấn phẩm này bao gồm những thực tiễn trong việc quản lý Vận hành
Dịch vụ. Nó bao gồm hướng dẫn về việc đạt được tính hiệu suất và
hiệu quả trong việc cung cấp và hỗ trợ các dịch vụ để đảm bảo giá
trị cho khách hàng và nhà cung cấp dịch vụ. Các mục tiêu chiến lược
cuối cùng được hiện thực hóa thông qua Vận hành Dịch vụ, do đó
làm cho nó trở thành một năng lực tối quan trọng. Hướng dẫn được
cung cấp về cách làm thế nào để duy trì tính ổn định trong Vận hành
Dịch vụ, cho phép những thay đổi trong thiết kế, quy mô, phạm vi
và các mức dịch vụ. Các tổ chức được cung cấp các hướng dẫn chi
tiết về quy trình, phương pháp và công cụ để sử dụng theo hai quan
điểm kiểm soát chủ yếu: ứng phó và chủ động. Các nhà quản lý và
người thực hành được cung cấp những kiến thức cho phép họ đưa ra
quyết định tốt hơn trong các lĩnh vực như quản lý tính sẵn sàng của
dịch vụ, kiểm soát nhu cầu, tối ưu hóa công suất sử dụng, lập lịch
trình vận hành và khắc phục sự cố. Hướng dẫn được cung cấp về
việc hỗ trợ các hoạt động vận hành thông qua các mô hình và ki ến
trúc mới như dịch vụ được chia sẻ, điện toán tiện ích, dịch vụ web
và thương mại di động.
1.2.3.5 Liên tục Cải tiến Dịch vụ

Ấn phẩm Liên tục Cải tiến Dịch vụ cung cấp hướng dẫn đo đạc trong
việc tạo ra và duy trì giá trị cho khách hàng thông qua thiết kế, giới
thiệu và vận hành các dịch vụ tốt hơn. Nó bao gồm các nguyên tắc,
thực tiễn và phương pháp từ quản lý chất lượng, Quản lý Thay đổi
và cải thiện công suất. Các tổ chức học hỏi để hiện thực hóa những
cải thiện ngày càng tăng và quy mô-lớn trong chất lượng dịch vụ,
hiệu quả vận hành và liên tục kinh doanh. Hướng dẫn được cung cấp
để liên kết những nỗ lực cải thiện và những kết quả với Chiến lược
Dịch vụ, thiết kế và chuyển tiếp. Một hệ thống vòng lặp phản hồi
khép kín, dựa trên mô hình Plan-Do-Check-Act (PDCA) được xác định
trong ISO/IEC 20000 được thiết lập và có khả năng nhận các đầu
vào đối với những thay đổi từ bất kỳ quan điểm hoạch định nào.
1.3 Mục đích

Vận hành Dịch vụ là một giai đoạn quan trọng trong vòng đời ITSM.
Các quy trình được hoạch định và triển khai tốt sẽ không có ý nghĩa
nếu như hoạt động hàng ngày của các quy trình đó không được tiến
hành, kiểm soát và quản lý một cách đúng đắn. Cũng không thể thực
hiện các cải tiến dịch vụ nếu các hoạt động hàng ngày để giảm sát
hiệu suất, các chỉ số tài sản và thu thập dữ liệu không được tiến
hành một cách có hệ thống trong quá trình Vận hành Dịch vụ.
Nhân viên Vận hành Dịch vụ nên có sẵn các quy trình và công cụ hỗ
trợ để cho phép họ có một cái nhìn tổng thể về Vận hành Dịch vụ và
việc cung cấp (thay vì chỉ là các thành phần riêng biệt, chẳng hạn
như phần cứng, phần mềm ứng dụng và mạng, vốn cấu thành nên
dịch vụ từ đầu-đến-cuối theo quan điểm của doanh nghiệp) và để
phát hiện bất kỳ mối đe dọa hoặc lỗi nào đối với chất lượng của dịch
vụ.
Khi dịch vụ có thể được cung cấp, toàn bộ hoặc từng phần, bởi một
hoặc nhiều đối tác/tổ chức nhà cung cấp, quan điểm Vận hành Dịch
vụ về dịch vụ từ đầu-đến-cuối phải được mở rộng để bao gồm những
khía cạnh bên ngoài của việc cung cấp dịch vụ - và khi cần thiết, các
quy trình và công cụ tương tác hoặc được chia sẻ cần thiết để quản
lý các quy trình công việc trên toàn tổ chức.
1.4 Sử dụng
Ấn phẩm này nên được sử dụng kết hợp với bốn ấn phẩm khác tạo
thành Vòng đời Dịch vụ ITIL.
Độc giả nên nhận thức được rằng những hướng dẫn thực tiễn tốt
nhất trong ấn phẩm này và những ấn phẩm khác không có dự định là
đề ra những luật lệ. Mỗi tổ chức là duy nhất và phải ‘áp dụng và
thích ứng’ hướng dẫn cho nhu cầu, môi trường và văn hóa của riêng
mình. Điều này sẽ liên quan đến việc tính đến quy mô, kỹ
năng/nguồn lực, văn hóa, nguồn vốn, các ưu tiên và độ trưởng
thành của ITSM hiện hữu của tổ chức và việc điều chỉnh hướng dẫn
một cách tương xứng để phù hợp với nhu cầu của tổ chức.
Đối với các tổ chức lần đầu tiếp cận với ITIL, một số hình thái đánh
giá ban đầu để so sánh các quy trình và thực tiễn hiện hành của tổ
chức với những gì được khuyến cáo bởi ITIL sẽ là một điểm khởi đầu
cực kỳ giá trị. Những đánh giá này được mô tả chi tiết hơn trong ấn
phẩm Liên tục Cải tiến Dịch vụ ITIL.
Khi tồn tại những khoảng cách đáng kể, có thể sẽ cần phải giải
quyết chúng theo từng các giai đoạn trong một khoảng thời gian để
đáp ứng các ưu tiên của tổ chức và giữ được nhịp độ với những gì
mà tổ chức có khả năng hấp thụ và đủ điều kiện.
1.5 Tổng quan về các chương

Chương 2 giới thiệu khái niệm Quản lý Dịch vụ như một thực tiễn. Ở
đây, Quản lý Dịch vụ được định vị như là một thành phần chiến lược
và chuyên nghiệp của bất kỳ tổ chức nào. Chương này cũng cung
cấp tổng quan về Vận hành Dịch vụ như là một thành phần tối quan
trọng của Thực tiễn Quản lý Dịch vụ.
Những nguyên tắc then chốt của Vận hành Dịch vụ được đề cập
trong Chương 3 của ấn phẩm này. Những nguyên tắc này phác thảo
một số ý tưởng và nguyên tắc cơ bản mà ấn phẩm này dựa trên đó.
Chương 4 bao gồm các quy trình được thực hiện trong quá trình Vận
hành Dịch vụ - hầu hết các quy trình Vận hành Dịch vụ mang tính
ứng phó do bản chất của công việc được tiến hành để duy trì các
dịch vụ CNTT ở trạng thái mạnh mẽ và ổn định. Chương này cũng đề
cập đến các quy trình chủ động để nhấn mạnh rằng mục đích của
Vận hành Dịch vụ là tính ổn định – chứ không phải là sự đình trệ.
Vận hành Dịch vụ nên liên tục tìm kiếm những cách làm tốt hơn và
hiệu quả chi phí hơn, và các quy trình ch ủ động đóng một vai trò
quan trọng ở đây.
Chương 5 đề cập đến một số các hoạt động Vận hành Dịch vụ Phổ
biến, vốn là một nhóm các hoạt động và thủ tục được thực hiện bởi
các Chức năng Vận hành Dịch vụ. Chúng được chuyên biệt hóa, và
thường là (các hoạt động) mang tính kỹ thuật, các hoạt động không
phải là các quy trình theo đúng ý nghĩa của từ này, nhưng chúng
thực sự là điều sống còn đối với khả năng để cung cấp chất lượng
của các dịch vụ CNTT với chi phí tối ưu.
Chương 6 đề cập đến những khía cạnh mang tính tổ chức của Vận
hành Dịch vụ - các cá nhân hoặc nhóm có thể thực hiện các quy
trình hoặc hoạt động – và bao gồm một số hướng dẫn về cấu trúc tổ
chức của Vận hành Dịch vụ.
Chương 7 mô tả các công cụ và công nghệ được sử dụng trong quá

trình Vận hành Dịch vụ.
Chương 8 bao gồm một số khía cạnh của việc triển khai cần phải
được cân nhắc trước giai đoạn vận hành của vòng đời hoạt động.
Chương 9 làm nổi bật những thách thức, các Yếu tố Thành công
Quan trọng và rủi ro phải đối mặt trong quá trình Vận hành Dịch vụ,
trong khi phần Lời bạt tóm tắt và kết luận về ấn phẩm.
ITIL không đơn độc trong việc cung cấp hướng dẫn cho các nhà
quản lý CNTT và các phụ lục phác thảo một số khuôn khổ, phương
pháp luận và phương pháp tiếp cận bổ sung chủ chốt được sử dụng
một cách phổ biến kết hợp với ITIL trong quá trình Vận hành Dịch
vụ.
2 Q u ả n lý D ịch v ụ như m ột th ực ti ễn
2.1 Quản lý Dịch vụ là gì?

Vận hành Dịch vụ là một bộ các năng lực tổ chức được chuyên môn
hóa để cung cấp giá trị cho các khách hàng dưới hình thái các dịch
vụ. Những năng lực dưới dạng chức năng và quy trình để quản lý các
dịch vụ qua một vòng đời, với sự chuyên môn hóa trong chiến lược,
thiết kế, chuyển tiếp, vận hành và liên tục cải tiến. Những năng lực
này đại diện cho công suất, năng lực và sự tự tin đối với hoạt động
của một tổ chức dịch vụ. Hoạt động chuyển tiếp những nguồn lực
thành các dịch vụ có giá trị nằm ở cốt lõi của Quản lý Dịch vụ.
Không có các năng lực này, một tổ chức dịch vụ chỉ đơn thuần là
một tập hợp các dịch vụ mà bản thân nó chỉ có giá trị nội tại thấp
đối với khách hàng.
Định nghĩa về Quản lý Dịch vụ
Quản lý Dịch vụ là một tập hợp các năng lực mang tính tổ chức được chuyên môn
hóa để mang lại giá trị cho các khách hàng dưới hình thức các dịch vụ.
Những năng lực tổ chức được định hình bởi những thách thức mà
chúng được kỳ vọng sẽ phải vượt qua. Một ví dụ về việc này là cách
mà trong những năm 1950 Toyota đã phát tri ển những năng lực độc
đáo để vượt qua những thách thức từ quy mô nhỏ và nguồn vốn tài
chính khi so sánh với những đối thủ cạnh tranh ở Mỹ. Toyota đã
phát triển những năng lực mới trong kỹ thuật sản xuất, quản lý hoạt
động và quản lý nhà cung cấp để bù đắp cho việc không có khả năng
cung cấp lượng hàng tồn kho lớn, sản xuất linh kiện, sản xuất vật
liệu thô hoặc sở hữu những công ty sản xuất ra chúng (linh kiện
hoặc vật liệu thô – người dịch). [Nguồn: Magretta, Joan 2002. Quản
lý là gì: Nó hoạt động như thế nào và tại sao đó lại là việc kinh
doanh của mọi người. Nhà Xuất bản Tự do – Free Press.] Năng lực
Quản lý Dịch vụ cũng chịu ảnh hưởng tương tự bởi những thách thức
dưới đây mà phân biệt các dịch vụ với các hệ thống tạo ra giá trị
khác, chẳng hạn như sản xuất, khai khoáng và nông nghiệp:
 Bản chất vô hình của đầu vào và những sản phẩm trung gian
của quy trình dịch vụ: Khó đo lường, kiểm soát và xác thực
(hoặc chứng minh).
 Nhu cầu được kết hợp một cách chặt chẽ với các tài sản của
khách hàng: Người dùng và những tài sản khác của khách hàng
chẳng hạn như các quy trình, ứng dụng, tài liệu và giao dịch đi
kèm với nhu cầu và kích thích sản xuất dịch vụ.
 Mức độ tiếp xúc cao đối với nhà sản xuất và người tiêu thụ
dịch vụ: Ít hoặc không có vùng đệm giữa khách hàng, tiền
tuyến (front-office) và hậu phương (back-office).
 Bản chất dễ hư hỏng của đầu ra dịch vụ và công suất dịch vụ:
Có những giá trị cho khách hàng đến từ sự bảo đảm về việc
cung cấp được chất lượng nhất quán liên tục. Các nhà cung cấp
cần phải bảo đảm nguồn cung cầu ổn định từ các khách hàng.
Tuy nhiên, Quản lý Dịch vụ còn nhiều hơn là chỉ là một bộ các năng
lực. Nó cũng là một thực tiễn chuyên nghiệm được hỗ trợ bởi một cơ
sở kiến thức, kinh nghiệm và kỹ năng toàn diện. Một cộng đồng toàn
cầu bao gồm các cá nhân và tổ chức trong lĩnh vực công và tư nhân
đang thúc đẩy sự tăng trưởng và trưởng thành của nó. Các kế hoạch
chính thức tồn tại để giáo dục, đào tạo và chứng nhận cho các tổ
chức và cá nhân đang hành nghề có ảnh hưởng đến chất lượng của
nó. Những thực tiễn tốt nhất trong ngành, nghiên cứu học thuật và
các tiêu chuẩn chính thức góp phần vào vốn tri thức của nó và được
rút ra từ nó.
Nguồn gốc của Quản lý Dịch vụ là trong các doanh nghiệp dịch vụ
truyền thống như các hãng hàng không, ngân hàng, khách s ạn và
công ty điện thoại. Thực tiễn của nó đã phát triển cùng với sự áp
dụng phương pháp tiếp cận định hướng-dịch vụ của các tổ chức
CNTT để quản lý các ứng dụng, cơ sở hạ tầng và quy trình CNTT.
Các giải pháp cho các vấn đề kinh doanh, và sự hỗ trợ cho các mô
hình, chiến lược và hoạt động kinh doanh ngày càng gia tăng dư ới
hình thái các dịch vụ. Sự phổ biến của các dịch vụ được chia sẻ và
xu hướng thuê ngoài đã góp phần vào sự gia tăng của số lượng các
tổ chức cung cấp dịch vụ, bao gồm cả các đơn vị tổ chức nội bộ.
Điều này, đến lượt nó, đã củng cố thêm thực tiễn Quản lý Dịch vụ và
đồng thời áp đặt nhiều thách thức hơn nữa lên nó.
2.2 Dịch vụ là gì?
2.2.1 Đề xuất giá trị
Định nghĩa về dịch vụ
Một dịch vụ là một phương tiện mang lại giá trị cho khách hàng bằng cách tạo
điều kiện cho các kết quả mà khách hàng muốn đạt được mà không cần sở hữu
chi phí hoặc rủi ro cụ thể.
Các dịch vụ là một phương tiện mang lại giá trị cho các khách hàng
bằng cách tạo điều kiện cho các kết quả mà khách hàng muốn đạt
được mà không cần sở hữu chi phí hoặc rủi ro cụ thể. Các dịch vụ
tạo điều kiện cho các kết quả bằng cách tăng cường hiệu suất của
các tác vụ liên quan và giảm hiệu lực của các ràng buộc. Kết quả là
sự gia tăng trong xác suất của các kết quả mong muốn.
Hình 2.1 Một cuộc đối thoại về định nghĩa và ý nghĩa của các dịch
vụ
2.3 Các chức năng và quy trình trong vòng đ ời
2.3.1 Các chức năng

Các chức năng là các đơn vị của tổ chức, được chuyên môn hóa để
thực hiện một kiểu công việc và trách nhiệm nhất định để có các kết
quả cụ thể. Chúng (các chức năng) là tự-đóng gói, với các năng lực
và tài nguyên cần thiết cho hiệu suất và các kết quả của chúng.
Năng lực bao gồm các phương pháp làm việc nội bộ đối với các chức
năng. Các chức năng có khối kiến thức của riêng mình được tích lũy
từ kinh nghiệm. Chúng cung cấp cấu trúc và tính ổn định cho các tổ
chức.
Các chức năng là một phương tiện cấu trúc tổ chức để triển khai các
nguyên tắc chuyên môn hóa. Các chức năng thường xác định các vai
trò và quyền hạn và trách nhiệm tương ứng đối với hiệu suất và kết
quả cụ thể. Sự phối hợp giữa các chức năng thông qua các quy trình
được chia sẻ là một hình mẫu phổ biến trong thiết kế tổ chức. Các
chức năng có khuynh hướng tối ưu hóa hoạt động của chúng một
cách cục bộ để tập trung vào các kết quả được chỉ định. Sự phối hợp
kém giữa các chức năng cộng với trọng tâm hướng vào trong dẫn
đến các hầm ngầm chức năng gây cản trở cho sự liên kết và phản
hồi quan trọng đối với sự thành công của toàn thể tổ chức. Các mô
hình quy trình giúp tránh được vấn đề này với những cấu trúc phân
cấp chức năng bằng cách cải thiện sự phối hợp và kiểm soát chức
năng-chéo. Các quy trình được định nghĩa rõ ràng có thể cải thiện
năng suất trong và trên các chức năng.
2.3.2 Các quy trình

Các quy trình là những ví dụ về các hệ thống vòng lặp-khép kín bởi
vì chúng mang lại sự thay đổi và chuyển đổi hướng tới một mục tiêu
và sử dụng sự phản hồi để tự-củng cố toàn bộ quy trình hoặc cách
mà một quy trình phù hợp với quy trình khác như thế nào.
Hình 2.2 – Một quy trình cơ bản
Các định nghĩa quy trình mô tả các hành động, phụ thuộc và hệ quả.
Các quy trình có những đặc điểm sau:
 Có thể đo lường được: Chúng ta có thể đo lường được quy

trình theo một cách phù hợp. Đó là định hướng hiệu suất. Các
nhà quản lý muốn đo lường chi phí, chất lượng và các biến số
khác trong khi những người thực hiện quan tâm đến thời lượng
và năng suất.
 Các kết quả cụ thể: Lý do mà một quy trình tồn tại là để
mang lại kết quả cụ thể. Kết quả này phải có thể xác định và
đo đếm được một cách riêng rẽ. Mặc dù chúng ta có thể đếm
được sự thay đổi nhưng không thể đếm đưuọc có bao nhiêu
Bàn Dịch vụ đã được hoàn thành.
 Khách hàng: Mọi quy trình đều cung cấp các kết quả chủ yếu
của nó cho một khách hàng hoặc bên liên quan. Chúng có th ể
là nội bộ hoặc bên ngoài tổ chức nhưng quy trình phải đáp ứng
được những kỳ vọng của chúng.
 Phản ứng đối với một sự kiện cụ thể: Mặc dù một quy trình
có thể là tiếp diễn hoặc lặp đi lặp lại, nó nên có thể theo dõi
được theo một điều kiện kích hoạt cụ thể.
Các chức năng thường được hiểu nhầm với các quy trình. Ví dụ, có
những quan niệm sai lầm về việc Quản lý Công suất là một quy trình
Quản lý Dịch vụ. Đầu tiên, Quản lý Công suất là một năng lực mang
tính tổ chức với các quy trình và phương pháp làm vi ệc được chuyên
môn hóa. Nó có phải là một chức năng hay quy trình phụ thuộc vào
toàn bộ thiết kế tổ chức. Một sai lầm nữa là giả định rằng Quản lý
Công suất chỉ có thể là một quy trình. Có thể đo lường và kiểm soát
công suất và xác định liệu nó có phù hợp với một mục đích nhất
định hay không. Việc giả định rằng nó luôn luôn là một quy trình,
với các kết quả rời rạc có thể đo lường được, có thể trở thành một
lỗi.
2.3.3 Chuyên môn hóa và sự phối hợp trong suốt

vòng đời
Chuyên môn hóa và sự phối hợp là điều cần thiết trong phương pháp
tiếp cận kiểu vòng đời. Sự phản hồi và kiểm soát giữa các chức năng
và quy trình trong và trên toàn bộ các phần tử của vòng đời khiến
cho điều này trở nên khả thi. Hình mẫu chủ đạo trong vòng đời là
tiến trình tuần tự bắt đầu từ Chiến lược Dịch vụ đến Thiết kế Dịch
vụ - Chuyển tiếp Dịch vụ - Vận hành Dịch vụ và quay trở lại Chiến
lược Dịch vụ thông qua Liên tục Cải tiến Dịch vụ. Tuy nhiên, đó
không phải là hình mẫu hoạt động duy nhất. Mọi phần tử của vòng
đời đều cung cấp các điểm phản hồi và kiểm soát.
Sự kết hợp của nhiều quan điểm cho phép mức độ linh động và kiểm
soát nhiều hơn qua các môi trường và các tình huống. Phương pháp
tiếp cận kiểu vòng đời mô phỏng thực tế của hầu hết các tổ chức khi
mà tính hiệu quả trong quản lý đòi hỏi phải sử dụng nhiều quan
điểm kiểm soát. Những ai chịu trách nhiệm đối với thiết kế, phát
triển và cải thiện các quy trình đối với Quản lý Dịch vụ có thể áp
dụng một quan điểm kiểm soát dựa trên-quy trình. Những ai chịu
trách nhiệm cho việc quản lý các thỏa thuận, hợp đồng và dịch vụ có
thể được phục vụ tốt hơn bởi một quan điểm kiểm soát dựa trên-
vòng đời với các giai đoạn khác nhau. Tất cả những quan điểm kiểm
soát nói trên được hưởng lợi từ tư duy hệ thống. Mỗi quan điểm
kiểm soát có thể tiết lộ các hình mẫu mà có thể không rõ ràng đối
với các quan điểm khác.
2.4 Nền tảng cơ bản của Vận hành Dịch vụ
2.4.1 Mục đích/đích đến/mục tiêu

Mục đích của Vận hành Dịch vụ là để điều phối và tiến hành các hoạt
động và quy trình cần thiết để cung cấp và quản lý các dịch vụ ở
mức đã được thỏa thuận cho người dùng và khách hàng của doanh
nghiệp. Vận hành Dịch vụ đồng thời cũng chịu trách nhiệm cho việc
quản lý liên tục những yếu tố công nghệ được sử dụng để cung cấp
và hỗ trợ dịch vụ.
Các quy trình được thiết kế-rõ ràng và triển khai-tốt sẽ ít có giá trị
nếu những hoạt động hàng ngày của các quy trình đó không được
thực hiện, kiểm soát và quản lý một cách đúng đắn. Các cải tiến
dịch vụ cũng sẽ không khả thi nếu các hoạt động hàng ngày để giám
sát hiệu suất, đánh giá các chỉ số và thu thập dữ liệu không được
tiến hành một cách có hệ thống trong quá trình Vận hành Dịch vụ.
2.4.2 Phạm vi
Vận hành Dịch vụ bao gồm việc thực thi mọi hoạt động liên tục cần
thiết để cung cấp và hỗ trợ các dịch vụ. Phạm vi của Vận hành Dịch
vụ bao gồm:
 Bản thân các dịch vụ. Bất kỳ hoạt động nào hình thành nên
các thành phần của một dịch vụ được bao gồm trong quá trình
Vận hành Dịch vụ, bất kể được thực hiện bởi Nhà cung cấp
Dịch vu, hoặc một nhà cung cấp bên ngoài hoặc người dùng
hoặc khách hàng của dịch vụ đó.
 Các quy trình Quản lý Dịch vụ. Việc Quản lý và thực thi liên
tục rất nhiều quy trình Quản lý Dịch vụ được tiến hành trong
phạm vi Vận hành Dịch vụ, ngay cả khi một số quy trình ITIL
(chẳng hạn như Quản lý Thay đổi và Quản lý Công suất) có
nguồn gốc từ giai đoạn Thiết kế Dịch vụ hoặc Chuyển tiếp Dịch
vụ củ Vòng đời Dịch vụ, chúng vẫn đang được sử dụng liên tục
trong Vận hành Dịch vụ. Một số quy trình không được bao gồm
một cách cụ thể trong Vận hành Dịch vụ, chẳng hạn như Định
nghĩa về Chiến lược, bản thân quy trình thiết kế thực tế.
Những quy trình đó tập trung nhiều hơn vào các hoạt động
hoạch định và cải thiện dài hạn, vốn nằm ngoài phạm vi trực
tiếp của Vận hành Dịch vụ, tuy nhiên, Vận hành Dịch vụ sẽ
cung cấp đầu vào và ảnh hưởng đến những điều này một cách
thường xuyên như là một phần của vòng đời của Quản lý Dịch
vụ.
 Công nghệ. Mọi dịch vụ đều đòi hỏi một số hình thái công
nghệ để cung cấp chúng (các dịch vụ). Việc quản lý công nghệ
này không phải là một vấn đề tách biệt mà là một phần không
thể thiếu của việc quản lý chính bản thân các dịch vụ đó. Do
đó, một phần lớn của ấn phẩm này liên quan đến việc quản lý
cơ sở hạ tầng được sử dụng để cung cấp dịch vụ.
 Con người. Bất kể những dịch vụ, quy trình và công nghệ nào
được quản lý, tất cả đều là về con người. Chính con người thúc
đẩy nhu cầu đối với các dịch vụ và sản phẩm của tổ chức và
chính con người quyết định việc này được thực hiện như thế
nào. Cuối cùng, chính con người quản lý công nghệ, các quy
trình và dịch vụ. Thất bại trong việc công nhận điều này sẽ dẫn
đến (và đã dẫn đến) việc thất bại của các dự án Quản lý Dịch
vụ.
2.4.3 Giá trị đối với doanh nghiệp

Mỗi giai đoạn trong Vòng đời Dịch vụ ITIL đều mang lại giá trị cho
doanh nghiệp. Ví dụ, giá trị dịch vụ được mô hình hóa trong Chiến
lược Dịch vụ, chi phí của dịch vụ được thiết kế, dự đoán trước và
xác thực trong Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ; và các biện
pháp tối ưu hóa được xác định trong Liên tục Cải tiến Dịch vụ. Sự
vận hành của các dịch vụ là nơi mà những kế hoạch, thiết kế và tối
ưu hóa đó được thực thi và đo lường. Từ quan điểm của khách hàng,
Vận hành Dịch vụ là nơi mà giá trị thực sự (của dịch vụ) được nhìn
thấy.
Tuy nhiên, điều này vẫn có mặt trái của nó, bao gồm:
 Khi một dịch vụ đã được thiết kế và kiểm nghiệm, nó được kỳ

vọng hoạt động trong phạm vi ngân sách và các đích nh ắm mục
tiêu về Lợi nhuận trên khoản Đầu tư (ROI) đã được thiết lập
sớm trong vòng đời. Tuy nhiên, trong thực tế, có rất ít tổ chức
lập kế hoạch một cách hiệu quả đối với chi phí của việc quản lý
liên tục các dịch vụ. Rất dễ để định lượng chi phí cho một dự
án nhưng rất khó để định lượng chi phí của dịch vụ sẽ như thế
nào sau 3 năm vận hành.
 Rất khó để có được nguồn vốn trong suốt giai đoạn vận hành
để khắc phục các lỗi thiết kế hoặc các yêu cầu không được
nhìn thấy trước – vì đây không phải là một phần của đề xuất
giá trị nguyên thủy. Trong rất nhiều trường hợp, chỉ sau một
thời gian vận hành thì những vấn đề này mới phát sinh. Hầu
hết các tổ chức đều không có một cơ chế chính thức để đánh
giá vận hành dịch vụ về mặt thiết kế và giá trị. Việc này được
giao cho Quản lý Vấn đề và Quản lý Sự cố giải quyết – như thể
đó hoàn toàn là một vấn đề vận hành.
 Rất khó để có được nguồn vốn bổ sung cho các công cụ hoặc
hoạt động (bao gồm việc đào tạo) được nhắm mục đích hỗ trợ
tính hiệu quả của Vận hành Dịch vụ. Điều này một phần là bởi
vì chúng không được liên kết trực tiếp với chức năng của một
dịch vụ cụ thể và một phần bởi vì có một kỳ vọng xuất phát từ
khách hàng rằng những chi phí đó nên được tích hợp trong chi
phí của dịch vụ từ khi bắt đầu. Thật không may, tỷ lệ thay đổi
trong công nghệ là rất cao. Rất nhanh ngay sau khi, một giải
pháp đã được triển khai mà sẽ quản lý một cách hiệu quả một
tập hợp các dịch vụ, công nghệ mới trở nên sẵn sàng và có thể
thực hiện điều đó nhanh chóng hơn, rẻ hơn và hiệu quả hơn.
 Khi một dịch vụ đã được vận hành trong một thời gian, nó trở
thành một phần của đường cơ sở của những gì mà doanh
nghiệp kỳ vọng từ các Dịch vụ CNTT. Những nỗ lực tối ưu hóa
dịch vụ hoặc sử dụng những công cụ mới để quản lý nó một
cách hiệu quả hơn chỉ được xem là thành công nếu dịch vụ đã
từng cực kỳ có vấn đề trong quá khứ. Nói cách khác, một số
dịch vụ được coi là điều đương nhiên, và bất kỳ hành động nào
để tối ưu hóa chúng đều được xem là ‘sửa chữa những dịch vụ
không bị hư hỏng’.
Ấn phẩm này đề xuất một số quy trình, chức năng và biện pháp
nhằm mục đích giải quyết những lĩnh vực này.
2.4.4 Tối ưu hóa hiệu suất Vận hành Dịch vụ

Vận hành Dịch vụ được tối ưu hóa theo hai cách:
 Cải thiện gia tăng dần trong dài hạn. Điều này căn cứ trên
sự đánh giá hiệu suất và đầu ra của mọi quy trình Vận hành
Dịch vụ, các chức năng và kết quả đầu ra theo thời gian. Các
báo cáo được phân tích và một quyết định được đưa ra về việc
liệu cải thiện có cần thiết không, và nếu có, làm thế nào để
triển khai nó tốt nhất trong suốt quá trình Thiết kế Dịch vụ và
Chuyển tiếp Dịch vụ. Các ví dụ bao gồm việc triển khai một bộ
công cụ mới, những thay đổi đối với các thiết kế quy trình, tái
thiết lập cấu hình của cơ sở hạ tầng, v.v… Loại cải thiện này
được đề cập chi tiết trong ấn phẩm Liên tục Cải tiến Dịch vụ.
 Cải thiện liên tục trong ngắn hạn những thực tế công việc
trong phạm vi các quy trình, chức năng Vận hành Dịch vụ, và
bản thân công nghệ. Những cải thiện này nói chung là những
cải thiện nhỏ hơn những gì được triển khai mà không cần bất
kỳ thay đổi nào đối với bản chất nền tảng của một quy trình
hoặc công nghệ. Các ví dụ bao gồm tính chỉnh, cân bằng khối
lượng công việc, triển khai lại nhân sự và đào tạo, v.v…
Mặc dù cả hai loại cải tiến được thảo luận trong một số chi tiết
trong phạm vi của Vận hành Dịch vụ, ấn phẩm Liên tục Cải tiến Dịch
vụ sẽ cung cấp một khuôn khổ và giải pháp thay thế trong phạm vi
những gì mà sự cải thiện có thể được thúc đẩy như là một phần của
hỗ trợ tổng thể của các mục tiêu kinh doanh.
2.4.5 Các quy trình trong Vận hành Dịch vụ
Có một số quy trình Vận hành Dịch vụ then chốt cần phải được liên
kết với nhau để cung cấp một cấu trúc hỗ trợ CNTT tổng thể hiệu
quả. Cấu trúc tổng thể được mô tả tóm tắt dưới đây và sau đó, từng
quy trình được mô tả chi tiết trong Chương 4.
2.4.5.1 Quản lý Sự kiện

Quản lý Sự kiện giám sát mọi sự kiện xảy ra trong toàn bộ cơ sở hạ
tầng CNTT, để giám sát sự vận hành bình thường và phát hiện và leo
thang những điều kiện ngoại lệ.
2.4.5.2 Quản lý Sự cố và Vấn đề

Quản lý Sự cố tập trung vào việc khôi phục các dịch vụ bị sụt giảm
hoặc gián đoạn ngoài ý muốn cho người dùng càng nhanh càng tốt,
nhằm tối thiểu tác động đến doanh nghiệp.
Quản lý Vấn đề liên quan đến: phân tích nguyên nhân-gốc để xác
định và giải quyết nguyên nhân của các sự cố, các hoạt động chủ
động để phát hiện và ngăn ngừa các vấn đề/sự cố trong tương lai và
một quy trình con Lỗi Đã biết để cho phép chẩn đoán và giải quyết
nhanh chóng hơn nếu các sự cố tiếp theo xảy ra.
2.4.5.3 Thực hiện Yêu cầu

Thực hiện Yêu cầu là một quy trình xử lý các Yêu cầu Dịch vụ - thực
tế, rất nhiều trong số chúng là những thay đổi nhỏ hơn, ít rủi ro hơn
– khởi đầu thông qua Thiết kế Dịch vụ, nhưng sử dụng một quy trình
tách biệt tương tự với những gì của Quản lý Sự cố nhưng với các hồ
sơ/bảng Thực hiện Yêu cầu riêng biệt – nơi cần thiết phải được liên
kết với (các) Hồ sơ Vấn đề hoặc Sự cố khởi đầu cho nhu cầu đối với
yêu cầu. Để trở thành một Yêu cầu Dịch vụ, thường thì sẽ có một số
điều kiện tiên quyết cần được xác định và đáp ứng (ví dụ, nhu cầu
cần được chứng minh, lặp lại, phê duyệt trước, thủ tục hóa).
Để giải quyết một hoặc nhiều sự cố, vấn đề hoặc Lỗi Đã biết, một số
hình thức thay đổi là cần thiết. Những thay đổi nhỏ hơn, thường
chuẩn hóa, có thể được xử lý trong một quy trình Thực hiện Yêu
cầu, nhưng những thay đổi lớn hơn, rủi ro cao hơn hoặc không
thường xuyên phải đi qua một quy trình Quản lý Thay đổi chính
thức.
2.4.5.4 Quản lý Quyền truy cập

Quản lý Quyền truy cập là quy trình cấp quyền cho người dùng đã
được ủy quyền để sử dụng một dịch vụ, trong khi hạn chế quyền
truy cập đối với những người dùng trái phép. Điều này dựa trên việc
có khả năng xác định một cách chính xác những người dùng được ủy
quyền và sau đó quản lý khả năng truy cập dịch vụ của họ như được
yêu cầu trong các giai đoạn khác của vòng đời Nhân sự (HR) hoặc
hợp đồng của họ. Quản lý Quyền truy cập cũng còn được gọi là Quản
lý Quyền hoặc Quản lý Nhân dạng trong một số tổ chức.
2.4.6 Các chức năng trong Vận hành Dịch vụ

Các quy trình đơn độc sẽ không có kết quả trong Vận hành Dịch vụ
hiệu quả. Một cơ sở hạ tầng ổn định và những con người có kỹ năng
thích hợp cũng rất cần thiết. Để đạt được điều này, Vận hành Dịch
vụ dựa trên một số nhóm người có kỹ năng, tất cả tập trung vào
việc sử dụng các quy trình để khớp năng lực của cơ sở hạ tầng với
các nhu cầu của doanh nghiệp.
Những nhóm này chia thành 4 ch ức năng chính được liệt kê dưới đây
và được thảo luận chi tiết trong Chương 6.
2.4.6.1 Bộ phận Hỗ trợ Dịch vụ (Service Desk)
Bộ phận Hỗ trợ Dịch vụ là đầu mối liên lạc chủ yếu đối với người
dùng khi có một sự gián đoạn dịch vụ, đối với các Yêu cầu Dịch vụ,
hoặc thậm chí, đối với một số loại Yêu cầu Thay đổi. Bộ phận Hỗ trợ
Dịch vụ cung cấp một điểm liên lạc cho người dùng và một điểm
điều phối một số nhóm và quy trình CNTT.
2.4.6.2 Quản lý Kỹ thuật

Quản lý Kỹ thuật cung cấp những kỹ năng và tài nguyên kỹ thuật cần
thiết để hỗ trợ cho vận hành liên tục của Cơ sở hạ tầng CNTT. Quản
lý Kỹ thuật cũng đóng một vai trò quan trọng trong thiết kế, kiểm
nghiệm, phát hành và cải thiện các Dịch vụ CNTT. Trong các tổ chức
nhỏ, có thể quản lý kiến thức chuyên môn này trong một phòng ban
đơn lẻ nhưng các tổ chức lớn hơn thường tách ra thành một số
phòng ban được chuyên môn hóa kỹ thuật.
2.4.6.3 Quản lý Vận hành CNTT

Quản lý Vận hành CNTT thực hiện các hoạt động vận hành hàng
ngày cần thiết để quản lý Cơ sở hạ tầng CNTT. Điều này được hoàn
thành tùy theo các Tiêu chuẩn Hiệu suất đã xác định trong quá trình
Thiết kế Dịch vụ. Trong một số tổ chức, đây là một phòng ban đơn
lẻ được tập trung hóa, trong khi một số hoạt động và nhân viên
khác được tập trung hóa và một số khác được cung cấp bởi các
phòng ban phân tán hoặc chuyên biệt. Quản lý Vận hành CNTT có
hai chức năng độc đáo và nói chung là các cấu trúc tổ chức chính
thức. Đó là:
 Kiểm soát Vận hành CNTT, vốn thường được sắp xếp nhân sự
theo ca của các nhân viên vận hành và đảm bảo rằng các tác
vụ vận hành thường lệ được thực hiện. Kiểm soát Vận hành
CNTT cũng sẽ cung cấp các hoạt động giám sát và kiểm soát
được tập trung hóa, thường sử dụng một Cầu nối Vận hành
hoặc Trung tâm Vận hành Mạng.
 Quản lý Cơ sở vật chất đề cập đến việc quản lý môi trường
CNTT vật lý, thường là các trung tâm dữ liệu hoặc phòng máy
tính. Trong rất nhiều tổ chức, Quản lý Ứng dụng và Quản lý Kỹ
thuật thường được đặt cùng với Vận hành CNTT trong một
trung tâm dữ liệu lớn.
2.4.6.4 Quản lý Ứng dụng

Quản lý Ứng dụng chịu trách nhiệm cho việc quản lý các Ứng dụng
trong toàn bộ vòng đời của chúng. Chức năng Quản lý Ứng dụng hỗ
trợ và duy trì các ứng dụng vận hành và cũng đóng một vai trò quan
trọng trong thiết kế, kiểm nghiệm và cải thiện các ứng dụng hình
thành nên một phần của các dịch vụ CNTT. Quản lý Ứng dụng
thường được chia thành các phòng ban dựa trên danh mục ứng dụng
của tổ chức, điều đó cho phép chuyên môn hóa d ễ dàng hơn và sự
hỗ trợ được tập trung hơn.
2.4.6.5 Các tương tác với các giai đoạn khác của Vòng
đời Quản lý Dịch vụ
Có một số các quy trình khác sẽ được thực thi hoặc hỗ trợ trong quá
trình Vận hành Dịch vụ, nhưng được thúc đẩy trong các giai đoạn
khác của Vòng đời Quản lý Dịch vụ. Chúng sẽ được thảo luận trong
phần cuối cùng của Chương 4 và bao gồm:
 Quản lý Thay đổi, vốn là một quy trình chính yếu nên được liên kết
chặt chẽ với Quản lý Cấu hình và Quản lý Phát hành. Những chủ đề
này chủ yếu được đề cập trong ấn phẩm Chuyển tiếp Dịch vụ.
 Quản lý Công suất và Quản lý Tính sẵn sàng, được đề cập trong ấn
phẩm Thiết kế Dịch vụ.
 Quản lý Tài chính, được đề cập trong ấn phẩm Chiến lược Dịch vụ.
 Quản lý Kiến thức, được đề cập trong ấn phẩm Chuyển tiếp Dịch vụ.
 Liên tục Dịch vụ CNTT, được đề cập trong ấn phẩm Thiết kế Dịch
vụ.
 Báo cáo và Đo lường Dịch vụ, được đề cập trong Liên tục Cải tiến
Dịch vụ.
3 Các nguyên t ắ c V ậ n hành D ịch v ụ

Khi xem xét Vận hành Dịch vụ, bạn chỉ nên tập trung vào việc quản
lý các hoạt động hàng ngày và tự bản thân công nghệ. Tuy nhiên,
Vận hành Dịch vụ tồn tại với một bối cảnh rộng hơn nhiều. Là một
phần của Vòng đời Quản lý Dịch vụ, nó chịu trách nhiệm cho việc
thực thi và hoàn thành các quy trình t ối ưu hóa chi phí và chất
lượng của dịch vụ. Là một phần của tổ chức, nó chịu trách nhiệm
cho việc tạo điều kiện cho doanh nghiệp đạt được các mục tiêu của
mình. Là một phần của toàn bộ công nghệ, nó chịu trách nhiệm cho
sự hoạt động hiệu quả của các chức năng của thành phần hỗ trợ cho
các dịch vụ. Các nguyên tắc trong chương này nhằm mục đích giúp
những người thực hiện Vận hành Dịch vụ đạt được sự cân bằng giữa
mọi vai trò nêu trên và tập trung vào việc quản lý một cách hiệu quả
các khía cạnh hằng ngày trong khi vẫn duy trì được một quan điểm
về bối cảnh rộng lớn hơn.
3.1 Các chức năng, đội, nhóm, phòng ban
Ấn phẩm Vận hành Dịch vụ sử dụng một số thuật ngữ theo cách mà
trong đó, con người được tổ chức để thực hiện các quy trình hoặc
hoạt động. Có một số các định nghĩa đã được công bố cho từng
thuật ngữ và đó không phải là mục đích của ấn phẩm này để tham
gia vào việc tranh luận xem định nghĩa nào là tốt nhất. Xin lưu ý
rằng các định nghĩa dưới đây là chung chung và không mang tính áp
đặt. Chúng được cung cấp một cách đơn giản để xác định các giả
định và để tạo điều kiện hiểu rõ về tài liệu này. Người đọc nên áp
dụng các nguyên tắc cho thực tế tổ chức đối với tổ chức của chính
mình.
 Chức năng: Một chức năng là một khái niệm mang tính logic
đề cập đến con người và các biện pháp được tự động hóa để
thực thi một quy trình, một hành động hoặc sự kết hợp các quy
trình hoặc các hoạt động đã được xác định. Trong các tổ chức
lớn, một chức năng có thể được chia nhỏ và được thực hiện bởi
một số phòng ban, đội nhóm, hoặc nó có thể được hợp nhất
trong một đơn vị tổ chức (ví dụ, Bộ phận Hỗ trợ Dịch vụ).
Trong các tổ chức nhỏ hơn, một cá nhân hoặc một nhóm có thể
thực hiện nhiều chức năng – ví dụ, một phòng Quản lý Kỹ thuật
cũng có thể kết hợp với chức năng Bộ phận Hỗ trợ Dịch vụ.
 Nhóm: Một nhóm là một số người giống nhau về một số mặt
nào đó. Trong ấn phẩm này, các nhóm đề cập đến những người
thực hiện các hoạt động giống nhau – thậm chí ngay cả khi họ
có thể làm việc trên nền công nghệ khác nhau hoặc báo cáo
trong các cấu trúc tổ chức khác nhau hoặc thậm chí là khác
công ty. Các nhóm thường là các cấu trúc tổ chức không chính
thức nhưng rất hữu ích trong việc xác định các quy trình phổ
biến trên phạm vi tổ chức – ví dụ, đảm bảo rằng mọi người liên
quan đến việc giải quyết các sự cố hoàn thành Hồ sơ Sự cố
theo cùng một cách. Trong ấn phẩm này, thuật ngữ ‘nhóm’
không đề cập đến một nhóm các công ty được sở hữu bởi cùng
một pháp nhân.
 Đội: Đội là một hình thức chính thức hơn của nhóm. Đây là
những người làm việc cùng nhau để đạt được một mục tiêu
chung, nhưng không nhất thiết trong cùng cấu trúc tổ chức.
Thành viên của đội có thể cùng-địa điểm, hoặc làm việc trong
nhiều địa điểm khác nhau và vận hành một cách ảo hóa. Các
đội là rất hữu ích cho sự cộng tác, hoặc cho việc xử lý một tình
huống tạm thời hoặc mang bản chất giao dịch. Các ví dụ về các
đội bao gồm đội dự án, đội phát triển ứng dụng (thường bao
gồm một số người từ các đơn vị kinh doanh khác nhau) và đội
giải quyết vấn đề và sự cố.
 Phòng: Các phòng là những cấu trúc tổ chức chính thức tồn tại
để thực hiện một tập hợp cụ thể bao gồm các hoạt động đã
được xác định trên cơ sở liên tục. Các phòng có một cấu trúc
báo cáo phân cấp với các nhà quản lý thường chịu trách nhiệm
cho việc thực thi các hoạt động và cho việc quản lý hàng ngày
những nhân viên trong phòng.
 Bộ phận: Một bộ phận đề cập đến một số các phòng được
nhóm lại cùng nhau, thường theo khu vực địa lý hoặc dây
chuyền sản phẩm. Một bộ phận thường là tự-đóng gói và có
khả năng lập kế hoạch và thực thi mọi hoạt động trong một
chuỗi cung ứng.
 Vai trò: Một vai trò đề cập đến một tập hợp các hành vi hoặc
hành động được kết nối được thực hiện bởi một cá nhân, đội
hoặc nhóm trong một bối cảnh cụ thể. Ví dụ, một phòng Quản
lý Kỹ thuật có thể thực hiện vai trò Quản lý Vấn đề khi chẩn
đoán nguyên nhân gốc của sự cố. Phòng tương tự này cũng có
thể được kỳ vọng để đóng một số vai trò khác tại thời điểm
khác, ví dụ, nó có thể đánh giá tác động của những thay đổi
(vai trò Quản lý Thay đổi), quản lý hiệu suất của thiết bị dưới
quyền kiểm soát của họ (vai trò Quản lý Công suất), v.v… Phạm
vi của vai trò của họ và những gì thúc đẩy họ thực hiện vai trò
đó được xác định bởi quy trình có liên quan và được thỏa thuận
bởi cấp trên trực tiếp của họ.
3.2 Đạt được sự cân bằng trong Vận hành Dịch vụ

Vận hành Dịch vụ còn nhiều hơn là chỉ lặp lại việc thực thi một tập
hợp tiêu chuẩn các thủ tục hoặc hành động. Mọi chức năng, quy
trình và hoạt động được thiết kế để cung cấp một mức dịch vụ cụ
thể và đã được thống nhất, nhưng chúng cũng phải được cung cấp
trong một môi trường luôn thay đổi.
Điều này hình thành nên một sự xung đột giữa việc duy trì tình
trạng hiện tại và việc thích nghi với những thay đổi trong môi
trường kinh doanh và công nghệ. Do đó, một trong những vai trò
then chốt của Vận hành Dịch vụ là xử lý xung đột này và đạt được
sự cân bằng giữa các tập hợp các mức độ ưu tiên.
Phần này của ấn phẩm nêu bật một số căng thẳng và xung đột chính
yếu và xác định cách mà các tổ chức CNTT có thể nhận ra rằng họ
đang phải trải qua sự mất cân bằng bởi khuynh hướng nghiêng nhiều
hơn về trạng thá cực đoan này hay trạng thái cực đoan khác. Nó
cũng cung cấp một số hướng dẫn cấp-cao về cách làm thế nào để
giải quyết xung đột và từ đó, tiến lên về phía một phương pháp tiếp
cận kiểu thực tiễn-tốt nhất. Do đó, mọi xung đột đại diện cho một
cơ hội tăng trưởng và cải thiện.
3.2.1 Quan điểm CNTT nội bộ so với quan điểm

doanh nghiệp bên ngoài
Hầu hết các xung đột nền tảng trong mọi giai đoạn của Vòng đời
ITSM là giữa quan điểm về CNTT như là một tập hợp các dịch vụ
CNTT (quan điểm doanh nghiệp bên ngoài) và quan điểm về CNTT
như là một tập hợp các thành phần công nghệ (quan điểm CNTT nội
bộ).
 Quan điểm bên ngoài về CNTT là cách mà theo đó, các dịch vụ
được trải nghiệm bởi người dùng và khách hàng của chúng.
Chúng thường không hiểu hoặc không quan tâm về chi tiết của
những công nghệ nào được sử dụng để quản lý các dịch vụ đó.
Tất cả những gì mà chúng quan tâm là về việc các dịch vụ được
cung cấp như được yêu cầu và thỏa thuận.
 Quan điểm nội bộ về CNTT là cách mà theo đó các thành ph ần
và hệ thống CNTT được quản lý để cung cấp các dịch vụ. Bởi vì
các hệ thống CNTT rất phức tạp và đa dạng, điều này thường
có nghĩa rằng công nghệ được quản lý bởi vài nhóm hoặc
phòng khác nhau – mỗi nhóm hoặc phòng tập trung vào việc
đạt được hiệu suất tốt và tính sẵn sàng cao của hệ các thống
‘của họ’.
Cả hai quan điểm đều cần thiết khi cung cấp các dịch vụ. Tổ chức
chỉ tập trung vào các yêu cầu kinh doanh mà không suy nghĩ về cách
chúng sẽ cung cấp như thế nào thì cuối cùng sẽ đưa ra những lời
hứa không thể giữ được. Tổ chức chỉ tập trung vào các hệ thống nội
bộ mà không nghĩ về những dịch vụ nào mà họ hỗ trợ cuối cùng sẽ
dẫn đến những dịch vụ có chi phí cao nhưng mang lại giá trị thấp.
Tiềm năng xung đột vai trò giữa các quan điểm nội bộ và bên ngoài
là kết quả của rất nhiều biến số, bao gồm sự trưởng thành của tổ
chức, văn hóa quản lý của nó, lịch sử của nó, v.v… Điều này khiến
cho khó mà đạt được sự cân bằng, và hầu hết các tổ chức đều có
khuynh hướng chỉ hướng đến một vai trò hơn những vai trò khác. Dĩ
nhiên, không có tổ chức nào sẽ chỉ tập trung hoàn toàn vào nội bộ
hoặc bên ngoài, nhưng sẽ tìm thấy chính mình trong một vị trí nào
đó cùng với một dải phổ giữa cả hai (quan điểm nội bộ và bên ngoài
– người dịch). Điều này được minh họa trong Hình 3.1.
Hình 3.1 – Việc đạt được sự cân bằng giữa sự tập trung vào bên
ngoài và nội bộ
Bảng 3.1 phác thảo một số ví dụ về các vị trí ở hai cực của dải phổ.
Mục đích của bảng này là để giúp đỡ các tổ chức trong việc xác định
họ đang ở gần thái cực nào hơn, không phải để xác định các vị trí-
thực tế mà tổ chức nên mong muốn.
Thái cực tập trung nội bộ Thái cực tập trung bên ngoài
Trọng tâm Hiệu suất và quản lý của các thiết bị, hệ thống và Đạt được mức hiệu suất cao của dịch vụ CNTT
chính nhân viên Cơ sở hạ tầng CNTT, với một chút liên với một chút liên quan đến cách đạt được nó như
quan đến kết quả sau cùng về dịch vụ CNTT. thế nào.
Các chỉ số  Tập trung vào hiệu suất kỹ thuật mà không cho  Tập trung vào các Chỉ số Bên ngoài mà không
thấy điều này có ý nghĩa gì đối với các dịch vụ. cho nhân viên trong nội bộ thấy rằng chúng
 Các chỉ số nội bộ (ví dụ, thời gian hoạt động (các chỉ số) có được như thế nào hoặc chúng
của mạng) đã báo cáo cho doanh nghiệp thay có thể được cải thiện như thế nào.
vì các chỉ số hiệu suất dịch vụ.  Nhân viên trong nội bộ được kỳ vọng là sẽ
nghĩ ra những chỉ số của họ để đo lường hiệu
suất nội bộ.
Trải nghiệm  Tính nhất quán cao trong việc cung cấp, nhưng  Tính nhất quán trong việc cung cấp là kém.
khách chỉ cung cấp một tỷ lệ phần trăm những gì  ‘CNTT bao gồm những người giỏi với những ý
hàng/người doanh nghiệp cần. định tốt, nhưng không thể luôn luôn thực thi’.
dùng  Sử dụng một phương pháp tiếp cận ‘đẩy’ để  Chế độ vận hành ứng phó.
cung cấp, ví dụ, muốn có một bộ dịch vụ tiêu  Sử dụng một phương pháp tiếp cận ‘kéo’ để
chuẩn cho mọi đơn vị kinh doanh. cung cấp, ví dụ, muốn cung cấp các dịch vụ
đã được tùy chỉnh tùy theo nhu cầu.
Chiến lược  Hoạt động tiêu chuẩn trên Hội đồng.  Nhiều nhóm cung cấp và nhiều công nghệ.
vận hành  Mọi dịch vụ mới cần phải phù hợp với kiến trúc  Những công nghệ mới đòi hỏi những phương
và thủ tục hiện hành. pháp tiếp cận vận hành mới và thường là các
đội Vận hành CNTT mới
Các thủ tục Tập trung hoàn toàn vào cách quản lý công nghệ Tập trung chủ yếu vào những gì cần phải được
và hướng dẫn như thế nào, không phải là về việc hiệu suất của hoàn thành và khi nào và ít tập trung vào việc
nó liên quan đến các dịch vụ CNTT như thế nào. điều đó nên đạt được như thế nào.
Chiến lược  Giảm chi phí đạt được hoàn toàn thông qua  Ngân sách được phân bổ trên cơ sở đơn vị
chi phí việc hợp nhất công nghệ. kinh doanh nào được cho là có nhu cầu nhất.
 Tối ưu hóa các thủ tục và tài nguyên vận hành.  Các đơn vị kinh doanh ít rõ ràng hoặc ít có
 Tác động kinh doanh của việc cắt giảm chi phí tiếng nói thường có các dịch vụ kém hơn do
chỉ được hiểu muộn màng. không có đủ nguồn vốn được phân bổ cho các
 Tính toán Lợi nhuận trên khoản Đầu tư (ROI) dịch vụ của họ.
dược tập trung hoàn toàn vào tiết kiệm chi phí
hoặc ‘các chu kỳ thu hồi vốn’.
Đào tạo Việc đào tạo được tiến hành như một đào tạo học  Việc đào tạo được tiến hành trên cơ sở theo-
nghề, nơi mà nhân viên Vận hành mới học hỏi về dự án.
các mà mọi việc được hoàn thành như thế nào  Không có các khóa đào tạo tiêu chuẩn vì các
chứ không phải tại sao. thủ tục và công nghệ vận hành luôn luôn thay
đổi.
Nhân viên  Nhân viên được chuyên môn hóa, được tổ chức  Đội ngũ nhân viên tổng hợp, được tổ chức một
vận hành tùy thuộc vào đặc trưng kỹ thuât. phần tùy theo năng lực kỹ thuật và một phần
 Nhân viên làm việc với giả định sai lầm rằng tùy theo mối quan hệ của họ với một đơn vị
thành tựu kỹ thuật tốt cũng chính là dịch vụ kinh doanh.
khách hàng tốt.  Phụ thuộc vào ‘anh hùng’, khi nhân viên thoát
ra khỏi cách làm việc của họ để giải quyết các
vấn đề mà có thể được ngăn chặn bằng các
quy trình nội bộ tốt hơn.
Bảng 3.1 Các ví dụ về thái cực tập trung nội bộ và bên ngoài
Điều này không có nghĩa rằng trọng tâm bên ngoài là không quan
trọng. Toàn bộ các điểm của Quản lý Dịch vụ là để cung cấp các
dịch vụ đáp ứng được các mục tiêu của toàn thể tổ chức. Đây là điều
tối quan trọng để cấu trúc các dịch vụ xoay quanh các khách hàng.
Tại cùng thời điểm, có thể làm tổn hại đến chất lượng của dịch vụ
bằng cách không nghĩ về cách chúng sẽ được cung cấp như thế nào.
Việc xây dựng Vận hành Dịch vụ với một sự cân bằng giữa trọng tâm
nội bộ và bên ngoài đòi hỏi một phương pháp tiếp cận dài hạn,
chuyên biệt phản ảnh được mọi giai đoạn của Vòng đời Dịch vụ
ITSM. Việc này sẽ đòi hỏi những điều dưới đây:
 Một sự hiểu biết về những dịch vụ nào được sử dụng bởi doanh
nghiệp và tại sao.
 Một sự hiểu biết về tầm quan trọng và tác động tương đối của
những dịch vụ đó với doanh nghiệp.
 Một sự hiểu biết về việc công nghệ được sử dụng như thế nào
để cung cấp các dịch vụ CNTT.
 Sự tham gia của Vận hành Dịch vụ vào Liên tục Cải tiến Dịch vụ
với mục đích xác định những cách thức cung cấp nhiều hơn, gia
tăng chất lượng của dịch vụ và chi phí thấp hơn.
 Các thủ tục và hướng dẫn phác thảo nên vai trò của Vận hành
CNTT trong cả hai khía cạnh quản lý công nghệ và cung cấp
các dịch vụ CNTT.
 Một bộ các chỉ số được phân biệt một cách rõ ràng để báo cáo
cho doanh nghiệp về thành tựu của các mục tiêu dịch vụ, và để
báo cáo cho các nhà quản lý CNTT về tính hiệu quả và hiệu
suất của Vận hành Dịch vụ.
 Mọi nhân viên Vận hành Dịch vụ hiểu một cách chính xác về
cách hiệu suất của công nghệ ảnh hưởng đến việc cung cấp các
dịch vụ CNTT như thế nào và đến lượt nó, ảnh hưởng đến
doanh nghiệp và các mục tiêu kinh doanh như thế nào.
 Một bộ các dịch vụ tiêu chuẩn được cung cấp một cách nhất
quán cho mọi Đơn vị Kinh doanh và một bộ các dịch vụ không-
tiêu chuẩn (đôi khi được tùy chỉnh) được cung cấp cho các Đơn
vị Kinh doanh cụ thể - cùng với một bộ các Thủ tục Vận hành
Tiêu chuẩn (SOP) có thể đáp ứng được cả hai nhóm yêu cầu.
 Một chiến lược chi phí được hỗ trợ nhằm cân bằng các yêu cầu
của các đơn vị kinh doanh khác nhau với mức tiết kiệm chi phí
sẵn có thông qua việc tối ưu hóa công nghệ hiện tại hoặc đầu
tư vào công nghệ mới – và một sự hiểu biết về chiến lược chi
phí bởi mọi nguồn lực CNTT có liên quan.
 Một chiến lược Lợi nhuận trên khoản Đầu tư dựa trên-giá trị,
thay vì dựa trên-chi phí.
 Sự tham gia của nhân viên Vận hành Dịch vụ vào các giai đoạn
Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ của Vòng đời ITSM.
 Đầu vào từ phản hồi đối với Liên tục Cải tiến Dịch vụ để xác
định những lĩnh vực có sự mất cân bằng và phương tiện để xác
dịnh và thực thi biện pháp cải thiện.
 Một kế hoạch đào tạo và truyền thông rõ ràng cho doanh
nghiệp. Mặc dù rất nhiều tổ chức rất giỏi trong việc phát triển
các Kế hoạc Truyền thông cho các dự án nhưng điều này
thương không kéo dài trong giai đo ạn vận hành của chúng (các
dự án).
3.2.2 Tính ổn định so với khả năng ứng phó

Bất kể chức năng của một dịch vụ CNTT tốt đến mức nào và bất kế
nó đã được thiết kế tốt như hế nào, nó sẽ có giá trị thấp hơn nhiều
nếu như các thành phần dịch vụ không sẵn sàng hoặc nếu chúng
hoạt động một cách không nhất quán.
Điều này có nghĩa là Vận hành Dịch vụ cần phải đảm bảo rằng Cơ sở
hạ tầng CNTT ổn định và sẵn sàng như đã được thiết kế. Tại cùng
thời điểm, Vận hành Dịch vụ cũng cần công nhận rằng các yêu cầu
của doanh nghiệp và của CNTT cũng đang thay đổi.
Một vài trong số những thay đổi đó mang tính cách mạng. Ví dụ,
chức năng, hiệu suất và kiến trúc của một nền tảng có thể thay đổi
sau một vài năm. Mỗi thay đổi mang đến cùng nó một cơ hội để cung
cấp các mức dịch vụ tốt hơn cho doanh nghiệp. Trong những thay
đổi mang tính cách mạng, có thể lập kế hoạch về cách ứng phó với
thay đổi như thế nào và do đó, duy trì được sự ổn định trong khi
vẫn ứng phó với những thay đổi.
Tuy nhiên, rất nhiều thay đổi diễn ra rất nhanh chóng và thỉnh
thoảng dưới áp lực khủng khiếp. Ví dụ, một Đơn vị Kinh doanh bất
ngờ giành được một hợp đồng đòi hỏi các dịch vụ CNTT bổ sung,
nhiều công suất hơn và thời gian phản hồi nhanh hơn. Khả năng
phản ứng lại với loại thay đổi này mà không ảnh hưởng đến các dịch
vụ khác là một thách thức đáng kể.
Rất nhiều tổ chức CNTT không thể đạt được sự cân bằng này và có
khuynh hướng tập trung vào hoặc là tính ổn định của Cơ sở hạ tầng
CNTT hoặc khả năng ứng phó một cách nhanh chóng với các thay
đổi.
Hình 3.2 – Đạt được sự cân bằng giữa sự tập trung vào tính ổn định
và khả năng ứng phó
Bảng 3.2 phác thảo một số ví dụ về các đặc điểm của các vị trí tại
hai cực điểm của dải phổ. Mục đích của bảng này là để giúp các tổ
chức xác
định xem họ đang ở gần với cực nào chứ không phải để xác định vị
trí thực tế mà tổ chức nên mong muốn.
Tập trung thái quá vào tính ổn Tập trung thái quá và khả năng
định ứng phó
Trọng tâm  Công nghệ  Đầu ra đối với doanh nghiệp
chủ yếu  Phát triển và tinh chỉnh các kỹ  Thỏa thuận về những thay đổi cần
thuật và quy trình quản lý CNTT thiết trước khi xác định những gì
tiêu chuẩn sẽ được thực hiện để cung cấp

chúng
Các vấn CNTT có thể chứng minh rằng nó Nhân viên CNTT không sẵn sàng để
đề điển đang tuân thủ các SOP và Thỏa thuận xác định hoặc thực thi các tác vụ
hình phải Mức Vận hành (OLA), ngay cả khi mất thường lệ vì họ bận bịu với các dự
trải qua liên kết rõ ràng với các yêu cầu của án cho các dịch vụ mới
doanh nghiệp
Chiến  Chiến lược tăng trưởng dựa trên  Công nghệ được mua sắm cho
lược tăng một phân tích về nhu cầu hiện tại từng yêu cầu của doanh nghiệp
trưởng trên các hệ thống hiện tại  Sử dụng nhiều công nghệ và giải
công nghệ  Các dịch vụ mới bị phản kháng và pháp đối với các giải pháp tương
đôi khi các Đơn vị Kinh doanh tụ, để đáp ứng các yêu cầu doanh
chiếm quyền sở hữu của các hệ nghiệp khác nhau không đáng kể
thống ‘của riêng họ’ để có quyền

tiếp cận tới các dịch vụ mới
Công Công nghệ hiện hữu hoặc tiêu chuẩn Cung cấp quá mức. Không có nỗ lực
nghệ được được sử dụng, các dịch vụ phải được nào được thực hiện để mô hình hóa
sử dụng điều chỉnh để hoạt động trong phạm dịch vụ mới trên cơ sở hạ tầng hiện
để cung vi các tham số hiện hữu tại. Công nghệ mới, chuyên biệt,
cấp các được mua sắm cho từng dự án
dịch vụ
CNTT
Quản lý  Dự báo căn cứ vào các dự đoán về  Dự báo căn cứ vào hoạt động kinh
Công suất khối lượng công việc hiện tại doanh tương lai cho từng dịch vụ
 Hiệu suất hệ thống được duy trì ở một cách riêng lẻ và không tính
mức nhất quán thông qua việc tinh đến các hoạt động CNTT hoặc các
chỉnh và quản lý nhu cầu, không dịch vụ CNTT khác
phải bởi việc dự báo và quản lý  Khối lượng công việc hiện tại là
khối lượng công việc không có liên quan
Bảng 3.2 Các ví dụ về sự tập trung thái quá vào tính ổn định và khả
năng ứng phó
Việc xây dựng một tổ chức CNTT đạt được sự cân bằng giữa tính ổn
định và khả năng ứng phó trong Vận hành Dịch vụ sẽ đòi hỏi những
hành động dưới đây:
 Đảm bảo khoản đầu tư vào những công nghệ và quy trình có
tính thích nghi thay vì cứng nhắc, ví dụ, công nghệ máy chủ và
ứng dụng ảo và sử dụng các Mô hình Thay đổi (xem thêm ấn
phẩm Chuyển tiếp Dịch vụ).
 Xây dựng một quy trình Quản lý Mức Dịch vụ (SLM) mạnh mẽ,
hoạt động từ giai đoạn Thiết kế Dịch vụ đến giai đoạn Liên tục
Cải tiến Dịch vụ của Vòng đời ITSM.
 Thúc đẩy sự tích hợp giữa SLM và các quy trình Thiết kế Dịch
vụ khác để đảm bảo sự ánh xạ phù hợp giữa các yêu cầu kinh
doanh với các hoạt động vận hành CNTT và các thành phần của
Cơ sở hạ tầng CNTT. Điều này khiến cho việc lập mô hình ảnh
hưởng của những thay đổi và cải thiện trở nên dễ dàng hơn.
 Khởi đầu những thay đổi tại các giai đoạn thích hợp sớm nhất
trong Vòng đời ITSM. Điều này sẽ đảm bảo rằng các yêu cầu về
chức năng (nghiệp vụ) lẫn quản lý (vận hành CNTT) đều có thể
được đánh giá và xây dựng hoặc được thay đổi cùng nhau.
 Đảm bảo sự tham gia của CNTT vào những thay đổi của doanh
nghiệp càng sớm càng tốt trong quy trình thay đổi để đảm bảo
khả năng mở rộng, tính nhất quán và có thể đạt được của các
dịch vụ CNTT duy trì những thay đổi của doanh nghiệp.
 Các đội Vận hành Dịch vụ nên cung cấp đầu vào cho thiết kế và
tinh chỉnh liên tục các kiến trúc và dịch vụ CNTT (xem thêm
các ấn phẩm Thiết kế Dịch vụ và Chiến lược Dịch vụ).
 Triển khai và sử dụng SLM để ngăn ngừa những tình huống khi
các nhà quản lý doanh nghiệp và CNTT và nhân viên thương
thảo về các thỏa thuận không chính thức.
3.2.3 Chất lượng của dịch vụ so với chi phí của dịch
vụ
Vận hành Dịch vụ được yêu cầu phải có tính nhất quán để cung cấp
mức dịch vụ CNTT đã được thỏa thuận cho các khách hàng và người
dùng của nó, trong khi đồng thời vẫn giữ được chi phí và sử dụng
tài nguyên ở mức tối ưu.
Hình 3.3 thể hiện khoản đầu tư được thực hiện để cung cấp một dịch
vụ với chất lượng ngày càng tăng.
Hình 3.3 – Sự cân bằng giữa chất lượng và chi phí dịch vụ
Trong Hình 3.3, một sự gia tăng trong mức chất lượng thường kéo
theo sự gia tăng trong chi phí của dịch vụ đó, và ngược lại. Tuy
nhiên, mối quan hệ này không phải lúc nào cũng là tỷ lệ thuận:
 Ngay từ ban đầu trong vòng đời dịch vụ đã có khả năng đạt
được sự gia tăng đáng kể trong chất lượng dịch vụ với một
khoản tiền tương đối nhỏ. Ví dụ, việc cải thiện tính sẵn sàng
của dịch vụ từ 55% lên 75% là tương đối đơn giản và có thể
không đòi hỏi một khoản đầu tư quá lớn.
 Sau đó trong vòng đời của dịch vụ, thậm chí những khoản đầu
tư nhỏ vào chất lượng cũng sẽ rất đắt đỏ. Ví dụ, việc cải thiện
tính sẵn sàng của cùng một dịch vụ từ 96% lên 99.9% cũng có
thể đòi hỏi những khoản đầu tư lớn vào công nghệ sẵn sàng-
cao và nhân viên hỗ trợ và công cụ.
Mặc dù điều này trông có vẻ đơn giản nhưng rất nhiều tổ chức đang
phải chịu sức ép phải gia tăng chất lượng của dịch vụ trong khi phải
giảm thiểu được chi phí của mình. Trong Hình 3.3, mối quan hệ giữa
chất lượng và chi phí thỉnh thoảng bị đảo ngược. Có khả năng
(thường trong phạm vi của tối ưu hóa) gia tăng chất lượng trong khi
vẫn giảm được chi phí. Điều này thường được khởi đầu trong phạm
vi Vận hành Dịch vụ và được tiếp tục thực hiện bởi Liên tục Cải tiến
Dịch vụ. Một vài chi phí có thể được giảm thiểu dần theo thời gian,
nhưng phần lớn chi phí chỉ có thể được tiết kiệm một lần. Ví dụ, khi
một công cụ phần mềm nhân bản đã được loại bỏ, nó không thể bị
loại bỏ thêm một lần nữa để tiết kiệm thêm chi phí.
Việc đạt được một điểm cân bằng tối ưu giữa chi phí và chất lượng
(được hiển thị giữa hai đường chấm chấm trong Hình 3.3) là vai trò
chính của Quản lý Dịch vụ. Không có một tiêu chuẩn ngành nào cho
việc phạm vi này nên là gì, vì từng dịch vụ sẽ có phạm vi tối ưu hóa
khác nhau, tùy thuộc vào bản chất của dịch vụ và kiểu của mục tiêu
kinh doang đang được đáp ứng. Ví dụ, doanh nghiệp có thể sẵn sàng
tiêu tốn nhiều hơn để đạt được mức sẵn sàng cao cho một dịch vụ
có nhiệm vụ cực kỳ quan trọng, trong khi sẵn sàng cho thực tế chất
lượng thấp hơn của một công cụ quản trị.
Việc xác định điểm cân bằng thích hợp của chi phí và chất lượng nên
được thực hiện trong các giai đoạn Chiến lược Dịch vụ và Vòng đời
Thiết kế Dịch vụ, mặc dù trong rất nhiều tổ chức, việc này được giao
cho nhóm Vận hành Dịch vụ - nhiều người trong số họ nói chung
không có đủ dữ kiện hoặc thẩm quyền để có thể đưa ra những quyết
định kiểu này.
Thật không may, điều rất phổ biến là các tổ chức đang tiêu tốn một
lượng lớn tiền bạc nhưng vẫn không đạt được bất kỳ cải thiện rõ
ràng nào trong chất lượng. Một lần nữa, Liên tục Cải tiến Dịch vụ sẽ
có khả năng xác định nguyên nhân của sự không hiệu quả, đánh giá
sự cân bằng tối ưu cho dịch vụ đó và hình thành một kế hoạch khắc
phục.
Đạt được sự cân bằng thích hợp là điều rất quan trọng. Tập trung
quá nhiều vào chất lượng sẽ dẫn đến việc các dịch vụ CNTT cung
cấp nhiều hơn mức cần thiết, với chi phí cao hơn, và có thể dẫn đến
một cuộc tranh luận về việc giảm chi phí của các dịch vụ. Tập trung
quá nhiều vào chi phí sẽ dẫn đến việc CNTT cung cấp theo đúng
hoặc dưới mức ngân sách nhưng đặt doanh nghiệp vào tình huống
rủi ro qua các dịch vụ CNTT dưới mức tiêu chuẩn.
Lưu ý đặc biệt: bao nhiêu là đủ?
Trong vài năm qua, các tổ chức CNTT đã phải chịu nhiều sức ép từ việc phải cắt
giảm chi phí. Trong rất nhiều trường hợp, điều này đã dẫn đến việc chi phí và
chất lượng được tối ưu hóa. Nhưng trong nhiều trường hợp khác, chi phí đã bị
cắt giảm cắt giảm đến mức mà chất lượng bắt đầu bị ảnh hưởng. Lúc đầu, các
dấu hiệu khá tinh vi – thời gian giải quyết sự cố tăng thêm một chút và số lượng
các sự cố cũng tăng nhẹ. Theo thời gian, dẫu vậy, tình huống trở nên nghiêm
trọng hơn khi nhân viên phải làm việc nhiều hơn để xử lý rất nhiều khối lượng
công việc và các dịch vụ chạy trên cơ sở hạ tầng cũ kỹ hoặc lỗi thời.
Không có một tính toán đơn giản để xác định khi nào thì chi phí đã bị cắt giảm
quá mức, nhưng SLM là cực kỳ quan trọng để khiến cho khách hàng nhận thức
được về tác động của việc cắt giảm (chi phí) quá mức, do đó, việc nhận thức
được những dấu hiệu và triệu chứng cảnh báo này có thể tăng cường một cách
đáng kể khả năng khắc phục tình huống của một tổ chức.
Các Yêu cầu Mức Dịch vụ (Service Level Requirements – SLM) – cùng
với một hiểu biết rõ ràng về mục đích kinh doanh của dịch vụ và
những rủi ro tiềm năng – sẽ giúp đảm bảo rằng dịch vụ được cung
cấp với một mức chi phí thích hợp. Chúng cũng sẽ giúp tránh được
việc ‘định cỡ quá mức’ của dịch vụ chỉ bởi vì đang có sẵn ngân sách,
hoặc ‘định cỡ quá thấp’ chỉ vì doanh nghiệp không hiểu về các yêu
cầu về khả năng quản lý của giải pháp. Dù kết quả sẽ khiến cho
khách hàng không hài lòng ho ặc thậm chí đắt hơn khi giải pháp được
tái cấu trúc hoặc được trang bị thêm những bộ phận mới đối với các
yêu cầu lẽ ra đã phải được chỉ định trong quá trình Thiết kế Dịch vụ.
Hình 3.4 Đạt được sự cân bằng giữa tập trung vào chi phí và chất
lượng
Bảng 3.3 phác thảo nên một số ví dụ về những đặc trưng của những
vị trí ở cực điểm của dải phổ chi phí/chất lượng. Mục đích của bảng
này là để hỗ trợ cho tổ chức trong việc xác định họ đang gần thái
cực nào hơn, chứ không chỉ để xác định vị trí trong đời thực mà tổ
chức nên khao khát.
Tập trung quá mức vào chất Tập trung quá mức vào chi phí
lượng
Trọng tâm Cung cấp mức chất lượng được yêu Đáp ứng ngân sách và giảm thiểu
chính cầu bởi doanh nghiệp bất kể những chi phí.
gì tổ chức cần.
 CNTT giới hạn chất lượng của

Các vấn đề  Ngân sách leo thang,
dịch vụ dựa trên ngân sách
điển hình  Các dịch vụ CNTT nói chung
sẵn có của họ.
đã trải qua cung cấp nhiều hơn cần thiết
 Những leo thang từ phía doanh
cho sự thành công của doanh
nghiệp để có thêm nhiều dịch
nghiệp.
vụ từ CNTT.
 Nhu cầu leo thang đối với các
dịch vụ có chất lượng cao hơn.
Quản lý tài CNTT thường không có một phương Các báo cáo tài chính được thực
chính pháp truyền đạt về chi phí của các hiện hoàn toàn theo số lượng đã
dịch vụ CNTT. Các phương pháp kế được lập ngân sách. Không có
toán dựa trên một phương pháp cách nào để liên kết các hoạt
tổng hợp (ví dụ, chi phí của CNTT động trong CNTT với việc cung
tính theo đầu người). cấp các dịch vụ CNTT.
Bảng 3.3 Các ví dụ về tập trung thái quá vào chất lượng và chi phí
Việc đạt được sự cân bằng sẽ đảm bảo cung cấp được mức dịch vụ
cần thiết để đáp ứng các yêu cầu của doanh nghiệp với chi phí tối
ưu (trái ngược với thấp nhất có thể). Việc này sẽ đòi hỏi những điều
sau đây:
 Một quy trình và những công cụ Quản lý Tài chính có thể tính
toán chi phí của việc cung cấp các dịch vụ CNTT, và mô hình
nào thay thế các phương pháp cung cấp dịch vụ ở các mức chi
phí khác nhau. Ví dụ, so sánh chi phí của việc cung cấp một
dịch vụ ở mức sẵn sàng 98% và 99.9%, hoặc chi phí của việc
cung cấp một dịch vụ có hoặc không có chức năng bổ sung.
 Đảm bảo rằng các quyết định xoay quanh chi phí so với chất
lượng được đưa ra bởi các nhà quản lý thích hợp trong quá
trình Chiến lược Dịch vụ và Thiết kế Dịch vụ. Các nhà Quản lý
Vận hành CNTT thường không được trang bị để đánh giá những
cơ hội kinh doanh và chỉ nên được yêu cầu đưa ra những quyết
định tài chính có liên quan đến việc đạt được tính hiệu quả của
vận hành.
3.2.4 Đối phó so với chủ động

Một tổ chức đối phó là một tổ chức không hành động cho đến khi họ
được nhắc nhở để thực hiện điều đó bởi một động cơ từ bên ngoài,
ví dụ, một yêu cầu kinh doanh mới, một ứng dụng đã được phát
triển hoặc sự leo thang trong những lời phàn nàn của người dùng và
khách hàng. Một thực tế đáng tiếc trong rất nhiều tổ chức là sự tập
trung vào quản lý ứng phó bị nhầm lẫn là phương tiện duy nhất để
đảm bảo các dịch vụ có tính nhất quán và ổn định cao, tích cực ngăn
chặn những hành vi tích cực của nhân viên vận hành. Điều trớ trêu
đáng tiếc của phương pháp tiếp cận này là nó ngăn cản nỗ lực đầu
tư vào Quản lý Dịch vụ chủ động mà cuối cùng có thể làm gia tăng
nỗ lực và chi phí của các hoạt động ứng phó và sự bền vững và nhất
quán của rủi ro hơn nữa trong các dịch vụ.
Một tổ chức chủ động luôn tìm cách để cải thiện tình huống hiện tại.
Tổ chức sẽ liên tục tìm hiểu môi trường nội bộ và bên ngoài, tìm
kiếm những dấu hiệu của những thay đổi tác động có khả năng gây
ra tác động. Hành vi chủ động thường được coi là tích cực, đặc biệt
là bởi vì nó cho phép tổ chức duy trì được lợi thế cạnh tranh trong
một môi trường đang thay đổi. Tuy nhiên, trở nên chủ động quá mức
có thể sẽ tốn kém và có thể khiến nhân viên bị phân tâm. Nhu cầu
về sự cân bằng thích hợp trong hành vi phản ứng và và hành vi chủ
động thường đạt được kết quả tối ưu.
Nói chung, tốt hơn là nên chủ động các dịch vụ CNTT một cách quản
lý, nhưng việc đạt được điều này không được lập kế hoạch hoặc đạt
được một cách dễ dàng. Đây là bởi vì việc xây dựng một tổ chức
CNTT chủ động phụ thuộc vào rất nhiều biến số, bao gồm:
 Sự trưởng thành của tổ chức. Tổ chức cung cấp được một tập
hợp các dịch vụ CNTT nhất quán càng lâu thì họ càng có nhiều
khả năng hiểu được mối quan hệ giữa CNTT với doanh nghiệp
và Cơ sở hạ tầng CNTT và các dịch vụ CNTT.
 Văn hóa của tổ chức. Một số tổ chức có nền văn hóa được tập
trung vào đổi mới và có nhiều khả năng chủ động hơn. Những
tổ chức khác có nhiều khả năng tập trung vào hiện trạng hơn
và như vậy, có khả năng chống lại sự thay đổi và tập trung vào
ứng phó hơn.
 Vai trò của CNTT trong doanh nghiệp và nhiệm vụ mà CNTT có
để gây ảnh hưởng đến chiến lược và chiến thuật của doanh
nghiệp. Ví dụ, một công ty mà CIO là thành viên h ội đồng quản
trị có khả năng có một tổ chức CNTT chủ động và phản ứng
nhanh nhạy hơn nhiều so với một công ty mà CNTT được coi là
chi phí quản lý.
 Mức độ tích hợp của các quy trình và công cụ quản lý. Mức độ
tích hợp cao hơn sẽ tạo điều kiện tốt hơn cho kiến thức về các
cơ hội.
 Sự trưởng thành và phạm vi của Quản lý Kiến thức trong tổ
chức, điều này đặc biệt được thấy ở các tổ chức có khả năng
lưu trữ và tổ chức dữ liệu lịch sử một cách hiệu quả - đặc biệt
là dữ liệu về Quản lý Tính sẵn sàng và Quản lý Vấn đề.
Nhìn từ góc độ trưởng thành, rõ ràng là các tổ chức mới hơn sẽ có

những ưu tiên và trải nghiệm khác so với một tổ chức lâu đời hơn –
những gì là thực tiễn tốt nhất cho một tổ chức trưởng thành có thể
sẽ không phù hợp với một tổ chức trẻ hơn. Do đó, sự mất cân bằng
có thể là kết quả của việc một tổ chức trở nên trưởng thành nhiều
hơn hoặc kém hơn. Hãy cùng xem xét những điều sau:
 Các tổ chức kém trưởng thành hơn (hoặc các tổ chức có dịch
vụ hoặc công nghệ CNTT mới hơn) nhìn chung sẽ phản ứng
nhanh hơn, đơn giản là vì họ không biết tất cả các biến liên
quan đến việc điều hành kinh doanh và cung cấp dịch vụ CNTT.
 Nhân viên CNTT trong các tổ chức mới hơn có khuynh hướng có
kiến thức rộng rãi hơn bởi vì sự không rõ ràng một cách chính
xác về những gì cần thiết để cung cấp các dịch vụ CNTT ổn
định cho doanh nghiệp.
 Các sự cố và vấn đề trong các tổ chức mới hơn là tương đối
không thể đoán trước được bở vì công nghệ là tương đối mới
và thay đổi một cách nhanh chóng.
 Các tổ chức trưởng thành hơn có khuynh hướng trở nên chủ
động hơn, chỉ đơn giản là bởi vì họ có nhiều dữ liệu và báo cáo
có sẵn hơn và biết được các hình mẫu phổ biến của các sự cố
và luồng công việc hơn. Do đó, họ dự báo các trường hợp ngoại
lệ dễ dàng hơn nhiều.
 Nhân viên đang làm việc trong các tổ chức trưởng thành nói
chung cũng có khuynh hướng có nhiều mối quan hệ đã được
xác lập giữa nhân viên CNTT và doanh nghi ệp và do đó, có thể
trở nên chủ động hơn về việc đáp ứng các yêu cầu kinh doanh
đang thay đổi – điều này đặc biệt đúng khi CNTT được xem là
một thành phần chiến lược của doanh nghiệp.
Hình 3.5 Đạt được sự cân bằng giữa quá chủ động và quá ứng phó
Bảng 3.4 mô tả một số ví dụ về những đặc trưng của những vị trí ở

các cực của dải phổ. Mục đích của bảng này là để hỗ trợ cho tổ chức
trong việc xác định họ đang gần cực nào hơn, không phải để xác
định vị trí thực tế mà tổ chức nên mong muốn.
Quá mức phản ứng Quá mức chủ động
Trọng tâm Phản ứng với các nhu cầu của doanh nghiệp và Tham gia vào các yêu cầu của doanh nghiệp
chính các sự cố chỉ sau khi chúng đã được báo cáo. trước khi chúng được báo cáo và các vấn đề
trước khi chúng xảy ra.
 Tiền bạc được tiêu tốn trước khi các yêu

Các vấn đề  Việc chuẩn bị để cung cấp các dịch vụ mới
cầu được tuyên bố. Trong một số trường
điển hình tốn nhiều thời gian vì từng dự án được xử
hợp, CNTT mua sắm các hạng mục mà sẽ
đã trải qua lý như thể nó là lần đầu tiên.
không bao giờ được sử dụng vì chúng liên
 Các sự cố tương tự xảy ra lặp đi lặp lại, vì
quan đến những yêu cầu sai hoặc vì các
không có cách nào để xác định khuynh
dự án bị ngừng.
hướng của chúng.
 Nhân viên CNTT có khuynh hướng ở lại tổ
 Tỷ lệ xoay vòng nhân viên cao và tinh
chức trong một thời gian dài và có khuynh
thần nói chung là thấp, vì nhân viên CNTT
hướng giả định rằng họ hiểu các yêu cầu
di chuyển từ dự án này sang dự án khác
của doanh nghiệp tốt hơn doanh nghiệp.
mà không đạt dược một bộ các dịch vụ

CNTT bền vững và ổn định.
Hoạch định Chờ đến khi xảy ra các vấn đề về công suất Tham gia vào các vấn đề về công suất và tiêu
Công suất và sau đó mua sắm thêm công suất thừa để tốn tiền bạc để ngăn chặn chúng – thậm chí
kéo dài cho đến khi vấn đề liên quan đến ngay cả khi tình huống không có khả năng
công suất kế tiếp xảy ra. xảy ra.
Hoạch định  Không tồn tại các kế hoạch cho đến sau Hoạch định-quá mức (và tiêu tốn-quá mức)
Liên tục khi xảy ra sự kiện hoặc thảm họa nghiêm cho các tùy chọn Khôi phục CNTT. Thông
Dịch vụ trọng. thường thì khôi phục tức thời được cung cấp
CNTT  Các kế hoạch CNTT tập trung vào việc cho hầu hết các dịch vụ CNTT, bất kể tác động
khôi phục các hệ thống then chốt mà và ưu tiên của chúng.
không đảm bảo rằng doanh nghiệp có thể
khôi phục các quy trình của mình.
Quản lý  Những thay đổi thường không được ghi Những thay đổi được yêu cầu và triển khai
Thay đổi nhận lại, hoặc được ghi nhận vào phút thậm chí ngay cả khi không có nhu cầu thực
cuối cùng như là Thay đổi Khẩn cấp. tế, nghĩa là một lượng đáng kể công việc được
 Không đủ thời gian cho đánh giá đúng đắn hoàn thành để khắc phục các hạng mục không
về chi phí và tác động. bị hư hỏng.
 Những thay đổi được kiểm nghiệm và kiểm
soát kém, dẫn đến một số lượng lớn các
sự cố.
Bảng 3.4 Các ví dụ về các hành vi quá mức chủ động và quá mức ứng phó
Mặc dù hành vi chủ động trong Vận hành Dịch vụ nói chung là tốt,
nhưng cũng có những thời điểm mà hành vi ứng phó là cần thiết. Do
đó, vai trò của Vận hành Dịch vụ là đạt được sự cân bằng giữa việc
trở nên chủ động và ứng phó. Điều này sẽ đòi hỏi:
 Các quy trình Quản lý Vấn đề và Quản lý Sự cố chính thức,

được tích hợp giữa Vận hành Dịch vụ và Liên tục Cải tiến Dịch
vụ.
 Khả năng có thể ưu tiên các lỗi kỹ thuật cũng như các nhu cầu
của doanh nghiệp. Nhu cầu này được hoàn thành trong quá
trình Vận hành Dịch vụ, nhưng các cơ chế cần được đưa vào
trong quá trình Chiến lược Dịch vụ và Thiết kế Dịch vụ. Những
cơ chế này có thể bao gồm các hệ thống phân loại sự cố, các
thủ tục leo thang và các công cụ để tạo điều kiện đánh giá tác
động đối với những thay đổi.
 Dữ liệu từ Quản lý Cấu hình và Quản lý Tài sản để cung cấp dữ
liệu khi cần thiết, tiết kiệm thời gian của dự án và đưa ra các
quyết định chính xác hơn.
 Sự tham gia liên tục của SLM trong Vận hành Dịch vụ.
3.3 Cung cấp dịch vụ

Tất cả nhân viên Vận hành Dịch vụ phải nhận thức đầy đủ rằng họ
tồn tại ở đó để ‘cung cấp dịch vụ’ cho doanh nghiệp. Họ phải cung
cấp một dịch vụ kịp thời (ứng phó nhanh chóng và cung cấp nhanh
chóng các yêu cầu), chuyên nghiệp và lịch sự để cho phép doanh
nghiệp tiến hành các hoạt động của riêng mình – để từ đó, các nhu
cầu của khách hàng thương mại được đáp ứng và việc kinh doanh
được thúc đẩy.
Điều quan trọng là nhân viên được đào tạo không chỉ về cách làm
thế nào để cung cấp và hỗ trợ cho các dịch vụ CNTT mà còn trong
cách thức mà theo đó, dịch vụ nên được cung cấp. Ví dụ, nhân viên
có năng lực và cung cấp dịch vụ một cách hiệu quả vẫn có thể gây
sự không hài lòng cho khách hàng n ếu họ vô cảm hoặc tùy tiện.
Ngược lại, việc đối xử tốt với khách hàng sẽ không giúp ích được gì
nếu dịch vụ không được cung cấp.
Một phần tử tối quan trọng của việc trở thành một nhà cung cấp
dịch vụ thành thạo là việc đặt trọng tâm vào việc tuyển dụng và đào
tạo nhân viên càng nhiều càng tốt để phát triển năng lực trong việc
xử lý và quản lý mối quan hệ và tương tác với khách hàng như được
thực hiện với những năng lực kỹ thuật để quản lý môi trường CNTT.
3.4 Nhân viên Vận hành tham gia vào Thiết kế Dịch vụ
và Chuyển tiếp Dịch vụ
Một điều cực kỳ quan trọng là nhân viên Vận hành Dịch vụ được
tham gia vào quá trình Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ và
có khả năng là Chiến lược Dịch vụ nếu thích hợp.
Chìa khóa để đạt được sự cân bằng trong Vận hành Dịch vụ là một
bộ các quy trình Thiết kế Dịch vụ hiệu quả. Những quy trình này sẽ
cung cấp cho Quản lý Vận hành CNTT:
 Định nghĩa rõ ràng về các mục tiêu của dịch vụ CNTT và các
tiêu chí về hiệu suất.
 Mối liên hệ của các thông số kỹ thuật của dịch vụ CNTT với
hiệu suất của Cơ sở hạ tầng CNTT.
 Định nghĩa về các yêu cầu hiệu suất vận hành.
 Ánh xạ giữa các dịch vụ và công nghệ.
 Khả năng lập mô hình về tác động của những thay đổi trong
công nghệ và những thay đổi đối với các yêu cầu của doanh
nghiệp.
 Các mô hình chi phí thích hợp (ví dụ, dựa trên khách hàng hoặc
dịch vụ) để đánh giá Lợi nhuận trên Khoản đầu tư (ROI) và các
chiến lược cắt giảm chi phí.
Bản chất của sự tham gia của Quản lý Vận hành CNTT nên được định
vị một cách cẩn trọng. Thiết kế Dịch vụ là một giai đoạn trong Vòng
đời Quản lý Dịch vụ sử dụng một bộ các quy trình chứ không phải là
một chức năng độc lập của Vận hành Dịch vụ. Và như vậy, rất nhiều
người được tham gia vào quá trình Thiết kế Dịch vụ sẽ đến từ Quản
lý Vận hành CNTT.
Việc này không chỉ nên được khuyến khích mà nhân viên Vận hành
Dịch vụ nên được đo lường về mức độ tham gia của họ vào các hoạt
động Thiết kế Dịch vụ - và những hoạt động như vậy nên được bao
gồm trong các mô tả công việc và vai trò, v.v… Điều này sẽ giúp
đảm bảo tính liên tục giữa các yêu cầu của doanh nghiệp và thiết kế
công nghệ và vận hành, và nó cũng sẽ giúp đảm bảo rằng những gì
đã được thiết kế cũng có thể được vận hành. Nhân viên Quản lý Vận
hành CNTT cũng nên được tham gia vào quá trình Chuy ển tiếp Dịch
vụ để đảm bảo tính nhất quán và để đảm bảo rằng các yêu cầu của
doanh nghiệp lẫn yêu cầu về khả năng quản lý đều được đáp ứng.
Tài nguyên phải sẵn sàng đáp ứng các hoạt động này, và thời gian
cần thiết nên được tính đến, nếu thích hợp.
3.5 Sức khỏe Vận hành
Rất nhiều tổ chức nhận thấy rằng sẽ rất hữu ích khi so sánh việc
giám sát và kiểm soát Vận hành Dịch vụ với việc giám sát và kiểm
soát sức khỏe.
Theo nghĩa này, Cơ sở hạ tầng CNTT giống như một cơ thể có những
dấu hiệu sống có thể được giám sát để kiểm tra xem liệu nó có đang
hoạt động một cách bình thường hay không. Điều này có nghĩa rằng
không nhất thiết phải giám sát một cách liên tục mọi thành phần của
mọi hệ thống CNTT để đảm bảo rằng nó vẫn đang hoạt động.
Sức khỏe Vận hành có thể được xác định bằng cách cô lập một vài
‘dấu hiệu sống còn’ trên những thiết bị hoặc dịch vụ đã được xác
định là rất quan trọng để thực thi thành công một Chức năng Nghiệp
vụ Sống còn (Vital Business Function). Đây có th ể là việc sử dụng
băng thông trên một phân đoạn mạng, hoặc sử dụng bộ nhớ trên
một máy chủ quan trọng. Nếu những dấu hiệu này nằm trong phạm
vi bình thường, hệ thống là đủ sức khỏe và không đòi hỏi phải được
chú ý thêm. Sự giảm thiểu nhu cầu đối với việc giám sát bao quát
này sẽ dẫn đến sự giảm thiểu chi phí và các nhóm và bộ phận vận
hành được tập trung vào những lĩnh vực thích hợp đối với sự thành
công của dịch vụ.
Tuy nhiên, cũng giống như những cơ thể, điều quan trọng là kiểm
tra các hệ thống một cách kỹ lưỡng hơn theo thời gian, để kiểm tra
những vấn đề không gây ảnh hưởng trực tiếp đên những dấu hiệu
sống còn. Ví dụ, một đĩa cứng có thể đang hoạt động một cách hoàn
hảo, nhưng nó vẫn có thể gần tới ngưỡng Thời gian Trung bình Giữa
các Lỗi (Mean Time Between Failures – MTBF). Trong trường hợp này
hệ thống nên được tách ra khỏi dịch vụ và được tiến hành kiểm tra
kỹ lưỡng hoặc ‘kiểm tra sức khỏe’. Đồng thời, cần nhấn mạnh rằng
kết quả cuối cùng nên là toàn bộ sức khỏe lành mạnh của dịch vụ.
Điều này có nghĩa là kiểm tra sức khỏe trên các thành phần nên
được cân bằng so với những kiểm tra dịch vụ ‘từ đầu-đến-cuối’. Định
nghĩa về những gì cần phải được giám sát và những gì lành mạnh so
với không lành mạnh được xác định trong quá trình Thiết kế Dịch vụ,
đặc biệt là Quản lý Tính sẵn sàng và SLM.
Sức khỏe Vận hành phụ thuộc vào khả năng ngăn chặn các sự cố và
vấn đề bằng cách đầu tư vào cơ sở hạ tầng đáng tin cậy và có khả
năng bảo trì. Điều này đạt được thông qua thiết kế tính sẵn sàng
thích hợp và Quản lý Vấn đề chủ động. Đồng thời, Sức khỏe Vận
hành cũng phụ thuộc vào khả năng xác định và khoanh vùng các lỗi
một cách hiệu quả để từ đó chúng có tác động tối thiểu đến dịch vụ.
Điều này đòi hỏi Quản lý Vấn đề và Quản lý Sự cố mạnh mẽ (tốt
nhất là tự động).
Ý tưởng về Sức khỏe Vận hành cũng đã dẫn đến một lĩnh vực chuyên
môn hóa được gọi là ‘Các Hệ thống Tự Khắc phục/Tự chữa bệnh (Self
Healing Systems)’. Đây là một sự ứng dụng của Quản lý Vấn đề và
Sự cố, Kiến thức, Công suất, Tính sẵn sàng, và đề cập đến một hệ
thống đã được thiết kế để được đứng vững trước hầu hết các điều
kiện vận hành nghiêm trọng và để phát hiện, chẩn đoán và khôi
phục từ hầu hết các sự cố và Lỗi Đã biết. Các Hệ thống Tự Khắc
phục còn được biết đến với nhiều tên gọi khác nhau, ví dụ, Hệ thống
Tự chủ, Hệ Thống thích nghi và Hệ thống Động. Những đặc trưng
của các Hệ thống Tự Khắc phục bao gồm:
 Khả năng phục hồi được thiết kế và tích hợp vào trong hệ
thống, ví dụ, nhiều đĩa dự phòng hoặc nhiều bộ vi xử lý. Điều
này bảo vệ hệ thống chống lại những lỗi phần cứng vì nó có
khả năng tiếp tục hoạt động bằng cách sử dụng các thành
phần phần cứng đã được nhân bản.
 Khả năng phục hồi của phần mềm, dữ liệu và hệ điều hành
cũng được thiết kế vào trong hệ thống, ví dụ, các sơ sở dữ
liệu được phản chiếu (khi một cơ sở dữ liệu được nhân bản
trên một thiết bị sao lưu) và công nghệ disk-striping/dải đĩa
(khi từng bit dữ liệu riêng lẻ của dữ liệu được phân bố trên
một mảng đĩa cứng – do đó, việc đĩa bị lỗi chỉ dẫn đến mất
mát một phần của dữ liệu, vốn có thể được khôi phục lại một
cách dễ dàng bằng cách sử dụng các thuật toán).
 Khả năng chuyển đổi việc xử lý từ một thiết bị vật lý sang
thiết bị khác mà không gây ra bất kỳ gián đoạn nào đối với
dịch vụ. Đây có thể là một biện pháp ứng phó với một lỗi hoặc
do thiết bị đạt tới mức sử dụng quá cao (một số các hệ thống
được thiết kế để phân tán tải trọng công việc xử lý một cách
liên tục, để tối ưu hóa việc sử dụng công suất đang có sẵn,
còn được biết đến như là sự ảo hóa).
 Các tiện ích giám sát được tích hợp hỗ trợ hệ thống phát hiện
ra các sự kiện và xác định xem liệu chúng có thể hiện cho sự
vận hành như bình thường hay không.
 Một công cụ tương quan (xem đoạn 4.1.5.6 về Quản lý Sự
kiện). Điều này sẽ cho phép hệ thống xác định tầm quan trọng
của từng sự kiện và đồng thời xác định xem liệu có bất kỳ
phản ứng nào được xác định trước cho sự kiện đó hay không.
 Một tập hợp các công cụ chẩn đoán, chẳng hạn như tập lệnh
kịch bản chẩn đoán, cây lỗi và cơ sở dữ liệu về các Lỗi Đã biết
và các phương án giải quyết thông thường. Chúng được sử
dụng ngay sau khi lỗi được phát hiện, để xác định biện pháp
ứng phó thích hợp.
 Khả năng tạo ra lời kêu gọi sự can thiệp của con người bằng
cách đưa ra cảnh báo hoặc tạo ra một sự cố.
Mặc dù khái niệm Sức khỏe Hoạt động không phải là khái niệm cốt
lõi của Vận hành Dịch vụ, nhưng nó thường là một phép ẩn dụ hữu
ích để hỗ trợ cho việc xác định những gì cần được theo dõi và tần
suất thực hiện bảo trì phòng ngừa.
Điều gì và khi nào cần phải giám sát đối với sức khỏe vận hành phải
được xác định trong Thiết kế Dịch vụ, được kiểm tra và tinh chỉnh
trong quá trình Chuyển tiếp Dịch vụ và được tối ưu hóa trong Liên
tục Cải tiến Dịch vụ, nếu cần thiết.
3.6 Truyền thông

Việc truyền thông rõ ràng là điều cần thiết với các nhóm và bộ phận
CNTT, với người dùng và khách hàng nội bộ, và giữa nhóm Vận hành
Dịch vụ và bản thân các bộ phận. Các vấn đề có thể thường được
ngăn chặn hoặc giảm nhẹ với các biện pháp truyền thông thích hợp.
Phần này được nhằm mục đích tóm tắt lại các biện pháp (phương
tiện) truyền thông nên có trong Vận hành Dịch vụ. Đây không phải
là một quy trình tách biệt, mà là một danh sách kiểm tra về kiểu
truền thông được yêu cầu để Vận hành Dịch vụ có hiệu quả.
Một nguyên tắc quan trọng là tất cả các giao tiếp đều phải có một
mục đích đã định hoặc một hành động có kết quả. Thông tin không
nên được truyền đạt đi trừ khi có một đối tượng rõ ràng. Ngoài ra,
đối tượng cũng nên được tham gia một cách chủ động vào việc xác
định nhu cầu cho giao tiếpđó và những gì họ sẽ thực hiện với thông
tin.
Một mô tả chi tiết về các kiểu truyền thông điển hình trong Vận
hành Dịch vụ được bao hàm trong Phụ lục B của ấn phẩm này, cùng
với một mô tả về đối tượng điển hình và các hoạt động được nhắm
dự định sẽ được tiến hành như một kết quả của từng giao tiếp.
Chúng bao gồm:
 Giao tiếp hoạt động thường xuyên,

 Giao tiếp giữa các ca (làm việc),
 Báo cáo hiệu suất,
 Giao tiếp trong các dự án,
 Giao tiếp có liên quan đến những thay đổi,
 Giao tiếp có liên quan đến những ngoại lệ,
 Giao tiếp có liên quan đến những tình huống khẩn cấp,
 Đào tạo về những quy trình mới hoặc đã được điều chỉnh và
các thiết kế dịch vụ,
 Giao tiếp về chiến lược và thiết kế cho các nhóm Vận hành Dịch
vụ.
Hãy lưu ý rằng không có phương tiện giao tiếp duy nhất nào, thậm
chí là không có vị trí hoặc tần suất cố định. Trong một số tổ chức,
giao tiếp bắt buộc phải diễn ra trong các cuộc họp. Các tổ chức khác
lại ưa thích việc sử dụng thư điện tử hoặc giao tiếp vốn có trong các
công cụ Quản lý Dịch vụ của họ.
Do đó, nên có một chính sách xoay quanh truy ền thông trong mỗi
nhóm hoặc bộ phận và cho từng quy trình. Mặc dù việc này nên
chính thức nhưng chính sách không nên rườm rà hoặc phức tạp. Ví
dụ, một nhà quản lý có thể yêu cầu rằng tất cả các giao tiếp liên
quan đến các thay đổi phải được gửi bằng e-mail. Miễn là điều này
được quy định trong SOP của bộ phận (dưới bất kỳ hình thức nào mà
chúng tồn tại) thì không cần thiết phải tạo ra một chính sách riêng
biệt cho bộ phận đó.
Mặc dù nội dung điển hình của giao tiếp là khá nhất quán khi các
quy trình đã được xác định, phương tiện giao tiếp vẫn đang thay đổi
với từng sự ra đời của công nghệ mới. Ngày nay, danh sách các giải
pháp thay thế vẫn đang tăng lên, bao gồm:
 Thư điện tử, cho những khách hàng truyền thống và thiết bị di
động,
 Tin nhắn văn bản (SMS),
 Máy fax,
 Tin nhắn tức thời và ‘chat’ trên nền web,
 Các tiện ích Âm thanh thoại qua Giao thức Internet (VoIP) để
có thể chuyển bất kỳ thiết bị được kết nối nào thành một
phương tiện giao tiếp rẻ tiền,
 Các tiện ích hội nghị qua điện thoại và cuộc họp ảo, đã cách
mạng hóa các cuộc họp vốn giờ đây được tổ chức ở những
khoảng cách rất xa,
 Các tiện ích chia sẻ tài liệu.
Phương tiện truyền thông, bản thân nó nằm ngoài phạm vi của ấn
phẩm này. Tuy nhiên, những điểm dưới đây nên được lưu ý:
 Giao tiếp là quan trọng và phương tiện giao tiếp phải đảm bảo
rằng chúng phục vụ cho mục đích này. Ví dụ, nhu cầu đối với
bảo mật truyền thông có thể loại bỏ tiềm năng của một vài
trong số các phương tiện nói trên. Nhu cầu về chất lượng có
thể loại bỏ một vài tùy chọn VoIP.
 Có thể sử dụng bất kỳ phương tiện truyền thông nào miến là
tất cả các bên liên quan hiểu được cách thức và thời điểm mà
giao tiếp được thực hiện.
3.6.1 Các cuộc họp

Các tổ chức khác nhau giao tiếp theo những cách thức khác nhau.
Khi các tổ chức là phân tán, họ sẽ có khuynh hướng dựa vào thư
điện tử và các phương tiện hội nghị qua điện thoại. Các tổ chức có
các quy trình và công cụ Quản lý Dịch vụ trưởng thành hơn sẽ có
khuynh hướng dựa vào các công cụ và quy trình dành cho giao ti ếp
(ví dụ, sử dụng một công cụ Quản lý Sự cố để leo thang và theo dõi
các sự cố, thay vì yêu cầu cập nhật qua thư điện tử hoặc điện
thoại).
Các tổ chức khác ưa thích giao tiếp thông qua các cuộc họp. Tuy
nhiên, điều quan trọng là không đi vào chế độ mà tại đó, chỉ có thời
gian công việc được thực hiện hoặc quản lý được tham gia là trong
cuộc họp. Ngoài ra, các cuộc họp mặt đối mặt có khuynh hướng làm
gia tăng chi phí (ví dụ, đi lại, thời gian tiêu tốn cho các cuộc thảo
luận không chính thức, nghỉ ngơi, v.v…), do đó việc tổ chức các
cuộc họp nên cân bằng giá trị của cuộc họp với số lượng và danh
tính của những người tham dự và thời gian mà họ sẽ tiêu tốn cho,
và đi đến, cuộc họp.
Mục đích của các cuộc họp là để truyền đạt một cách hiệu quả cho
một nhóm người về một bộ các mục tiêu hoặc các hoạt động chung.
Các cuộc họp nên được kiểm soát và tóm tắt, và trọng tâm nên đặt
vào việc tạo điều kiện cho hành động. Một quy tắc tuyệt vời là
không tổ chức cuộc họp nếu thông tin không thể được truyền đạt
một cách hiệu quả bởi các phương tiện đã được tự động hóa.
Một số các yếu tố là rất thiết yếu để các cuộc họp thành công. Mặc
dù những yếu tố này trông có vẻ như là lẽ thường, nhưng đôi khi
chúng đã bị bỏ quên:
 Thiết lập và truyền đạt một lịch trình nghị sự rõ ràng để cuộc
họp đạt được mục tiêu của nó và giúp cho người tổ chức (cuộc
họp) ngăn ngừa những người tham dự “chiếm đoạt” cuộc họp.
 Đảm bảo rằng các quy tắc tham gia được hiểu rõ. Các tổ chức
có khuynh hướng có một bộ quy tắc họp chính thức, từ tương
đối không chính thức đến rất trang trọng (ví dụ, Quy tắc Trật
tự Roberts).
 Tận dụng "bãi đậu xe" hoặc ghi chú để ghi lại những vấn đề
không liên quan trực tiếp đến mục đích của cuộc họp, nhưng có
thể được gọi đến nếu phát sinh nhu cầu thảo luận.
 Biên bản cuộc họp: các quy tắc nên được đặt ra về thời điểm
lập biên bản. Biên bản được sử dụng để nhắc nhở những người
được chỉ định hành động và theo dõi tiến trình của các hành
động đã được ủy quyền. Chúng cũng rất hữu ích trong việc đảm
bảo rằng các quyết định và hành động liên chức năng sẽ được
theo dõi và tuân thủ.
 Sử dụng các kỹ thuật để khuyến khích mức độ tham gia thích
hợp. Ví dụ, một kỹ thuật khi thảo luận về các biện pháp cải
tiến là kỹ thuật "giữ, dừng, bắt đầu". Những người tham gia
được khuyến khích liệt kê các mục mà họ muốn giữ lại, những
điều cần phải dừng lại và các sáng kiến hoặc hành động mà họ
muốn thấy bắt đầu.
Các ví dụ về những cuộc họp điển hình được đưa ra dưới đây.
3.6.1.1 Các cuộc họp Vận hành

Các cuộc họp vận hành thường được tổ chức giữa các nhà quản lý bộ
phận vận hành CNTT, các đội hoặc nhóm, tại thời điểm bắt đầu của
ngày hoặc tuần vận hành. Mục đích của kiểu họp hành này là để làm
cho nhân viên nhận thức được về bất kỳ vấn để nào liên quan đến
Vận hành (chẳng hạn như các lịch trình thay đổi, các sự kiện kinh
doanh, các lịch trình bảo trì, v.v…) và để cung cấp một cơ hội cho
nhân viên để nêu ra bất kỳ vấn đề nào về những gì mà họ nhận thức
được. Đây là một cơ hội để đảm bảo rằng mọi bộ phận trong một
trung tâm dữ liệu được đồng bộ với nhau.
Trong các tổ chức phân tán về mặt địa lý, sẽ không thể có một cuộc
họp Vận hành hàng ngày duy nhất. Trong những trường hợp đó, điều
quan trọng là điều phối lịch trình nghị sự của các cuộc họp và đảm
bảo rằng từng cuộc họp đều có 2 thành phần sau:
1. Phần đầu tiên của cuộc họp sẽ bao hàm các khía cạnh áp dụng
cho toàn thể tổ chức, ví dụ, các chính sách mới, những thay
đổi có ảnh hưởng đến mọi khu vực và các sự kiện kéo dài qua
mọi khu vực.
2. Phần thứ hai của cuộc họp sẽ bao hàm các khía cạnh áp dụng
cho khu vực cục bộ, ví dụ, các lịch trình vận hành cục bộ,
những thay đổi với thiết bị cục bộ, v.v…
Cuộc họp Vận hành thường được Nhà Quản lý Vận hành CNTT hoặc
Nhà quản lý Vận hành cấp cao chủ trì và được tất cả các nhà quản lý
và giám sát tham dự (ngoại trừ những ai đang có ca trực). Một điều
cũng rất hữu ích là có ít nhất một đại diện từ Bộ phận Hỗ trợ Dịch
vụ trong cuộc họp để họ nhận thức được bất kỳ tình huống nào có
thể làm phát sinh các sự cố.
Các cơ hội để cải tiến dịch vụ hoặc quy trình cũng nên được nắm
bắt, nếu phát sinh, và được chuyển tiếp cho nhóm chịu trách nhiệm
Liên tục Cải tiến Dịch vụ.
3.6.1.2 Các cuộc họp Phòng/Ban, đội hoặc nhóm

Những cuộc họp này là rất thiết yếu như các cuộc họp Vận hành,
nhưng được dự định chỉ trong phạm vi một bộ phận, đội hoặc nhóm
CNTT riêng lẻ. Từng nhà quản lý hoặc giám sát chuyển tiếp thông
tin từ cuộc họp Vận hành có liên quan đến nhóm của họ.
Ngoài ra, những cuộc họp này cũng sẽ bao hàm những điều dưới
đây:
 Một cuộc thảo luận chi tiết hơn về các sự cố, vấn đề và thay
đổi mà nhóm vẫn đang làm việc trên đó, với những thông tin
về:
o Tiến trình đến hiện tại,
o Sự xác nhận về những gì vẫn cần phải được hoàn thành,
o Thời gian hoàn thành được ước tính,
o Những yêu cầu đối với nguồn lực bổ sung, nếu cần thiết,
o Thảo luận về các vấn đề hoặc mối quan tâm tiềm ẩn.
 Sự xác nhận về tính sẵn sàng của nhân viên đối với bảng phân
công nhiệm vụ,
 Sự xác nhận về lịch trình nghỉ phép.
3.6.1.3 Các cuộc họp với khách hàng

Đôi khi, cần phải tổ chức các cuộc họp với khách hàng, ngoài các
cuộc họp Đánh giá Mức Dịch vụ thông thường. Những ví dụ bao gồm:
 Theo dõi sau các sự cố nghiêm trọng. Mục đích của các cuộc
họp này là để khắc phục mối quan hệ với khách hàng, nhưng
đồng thời cũng để đảm bảo rằng CNTT có tất cả thông tin cần
thiết để ngăn chặn sự tái diễn. Khách hàng cũng có cơ hội cung
cấp thông tin về các tác động kinh doanh không lường trước
được. Những cuộc họp này rất hữu ích trong việc thống nhất
các hành động đối với các loại sự cố tương tự có thể xảy ra
trong tương lai.
 Diễn đàn khách hàng, có thể được sử dụng cho rất nhiều mục
đích, bao gồm thử nghiệm các ý tưởng cho các dịch vụ hoặc
giải pháp mới, hoặc thu thập các yêu cầu cho các dịch vụ hoặc
thủ tục mới hoặc đã được sửa đổi. Diễn đàn khách hàng nói
chung là một cuộc họp thường xuyên với khách hàng để thảo
luận về các lĩnh vực cùng quan tâm.
3.7 Tài liệu

Quản lý Vận hành CNTT và tất cả các nhóm và bộ phận Quản lý Kỹ
thuật và Ứng dụng đều tham gia vào việc tạo ra và duy trì một loạt
các tài liệu. Những điều này được trình bày chi tiết trong các
Chương 4, 5 và 6 của ấn phẩm này và bao gồm những nội dung sau
đây:
 Sự tham gia vào định nghĩa và duy trì sổ tay hướng dẫn quy
trình cho mọi quy trình mà họ tham gia. Những quy trình này
sẽ bao gồm các quy trình trong các giai đo ạn khác của Vòng
đời Quản lý Dịch vụ CNTT (ví dụ, Quản lý Công suất, Quản lý
Thay đổi, Quản lý tính sẵn sàng) cũng như cho tất cả các quy
trình được bao gồm trong giai đoạn Vận hành Dịch vụ.
 Thiết lập sổ tay hướng dẫn thủ tục kỹ thuật của riêng họ.
Chúng phải được cập nhật và tài liệu mới phải được bổ sung
khi có liên quan, theo (quy trình) Kiểm soát Thay đổi. Nên nhớ
rằng các thủ tục của họ phải luôn được cấu trúc để đáp ứng
các mục tiêu và ràng buộc được xác định trong các quy trình
Quản lý dịch vụ cấp cao hơn, chẳng hạn như SLM. Ví dụ, một
quy trình kỹ thuật để việc quản lý máy chủ phải luôn đảm bảo
rằng quy trình đó nhằm mục đích đạt được mức độ sẵn sàng và
hiệu suất đã được thống nhất trong Thỏa thuận Mức Vận hành
và Thỏa thuận Mức Dịch vụ (SLA).
 Tham gia vào việc tạo và duy trì các tài liệu hoạch định, ví dụ,
các Kế hoạch Công suất và Kế hoạch Tính sẵn sàng và các Kế
hoạch Liên tục Dịch vụ CNTT.
 Tham gia vào việc tạo ra và duy trì Danh mục Dịch vụ. Việc này
sẽ bao gồm việc định lượng chi phí và thiết lập tính khả thi
trong hoạt động của từng dịch vụ được đề xuất.
 Tham gia vào việc xác định và duy trì các hướng dẫn công việc
cho công cụ Quản lý Dịch vụ để đáp ứng các yêu cầu về báo
cáo.
4 Các quy trình V ậ n hành D ị ch v ụ

Các quy trình được liệt kê trong đoạn 2.4.5 sẽ được thảo luận chi
tiết hơn trong phần này. Để tham khảo, cấu trúc tổng thể được mô
tả một cách ngắn gọn dưới đây và sau đó, từng quy trình sẽ được
mô tả chi tiết hơn trong phần sau đó. Hãy lưu ý rằng các vai trò đối
với từng quy trình và các công cụ được sử dụng cho từng quy trình
được mô tả trong Chương 6 và 7, tương ứng.
 Quản lý Sự kiện là quy trình để giám sát mọi sự kiện xảy ra
trong toàn bộ Cơ sở hạ tầng CNTT để hỗ trợ cho vận hành bình
thường và đồng thời phát hiện và leo thang các điều kiện ngoại
lệ.
 Quản lý Sự cố tập trung vào việc khôi phục dịch vụ cho người
dùng càng nhanh càng tốt, nhằm tối thiểu tác động đến doanh
nghiệp.
 Quản lý Vấn đề liên quan đến phân tích nguyên nhân gốc rễ để
xác định và giải quyết nguyên nhân của các sự kiện và sự cố,
các hoạt động chủ động để phát hiện và ngăn ngừa các vấn
đề/sự cố trong tương lai và một quy trình con Lỗi-Đã biết để
cho phép chẩn đoán và giải quyết nhanh hơn nếu như sự cố
tiếp theo xảy ra.
LƯU Ý: Nếu như không có sự phân biệt giữa sự cố và vấn đề, và lưu
giữ các Hồ sơ Sự cố và Vấn đề riêng biệt thì sẽ có nguy cơ:
 Các sự cố sẽ được đóng quá sớm trong chu trình hỗ trợ tổng
thể và sẽ không có hành động nào được đưa ra để ngăn
ngừa sự tái diễn – do đó sự cố tương tự sẽ phải được khắc
phục nhiều lần, hoặc
 Các sự cố sẽ được mở để từ đó phân tích nguyên nhân gốc
rễ có thể được hoàn thành và tính rõ ràng sẽ bị mất đi khi
dịch vụ của người dùng đã hoàn toàn được khôi phục – do
đó các đích nhắm mục tiêu SLA có thể không được đáp ứng
ngay cả khi dịch vụ đã được khôi phục trong phạm vi kỳ
vọng của người dùng. Việc này thường dẫn đến một lượng
lớn các sự cố mở, rất nhiều trong số chúng sẽ không bao giờ
được đóng trừ khi một ‘sự thanh lọc’ được tiến hành. Điều
này có thể rất mất động lực và có thể ngăn chặn tầm nhìn
hiệu quả của vấn đề hiện tại.
 Thực hiện Yêu cầu liên quan đến việc quản lý các yêu cầu của
khách hàng hoặc của người dùng đã không được tạo ra như
một sự cố từ sự chậm trễ hoặc gián đoạn dịch vụ không mong
muốn. Một số tổ chức có thể chọn xử lý các yêu cầu như vậy
như một 'thể loại' sự cố và quản lý thông tin thông qua hệ
thống Quản lý Sự cố - nhưng những tổ chức khác có thể chọn
(do khối lượng lớn hoặc mức độ ưu tiên kinh doanh của các yêu
cầu đó) để tạo điều kiện cho việc cung cấp những năng lực
Thực hiện Yêu cầu một cách riêng biệt thông qua quy trình
Thực hiện Yêu cầu. Việc sử dụng quy trình Thực hiện Yêu cầu
chính thức để quản lý các yêu cầu của khách hàng và người
dùng đối với tất cả các loại yêu cầu bao gồm cơ sở vật chất, di
chuyển và nguồn cung ứng cũng như những yêu cầu cụ thể đối
với các dịch vụ CNTT đã trở nên phổ biến. Các yêu cầu này
thường không bị ràng buộc với các thước đo SLA giống nhau và
việc tách biệt hồ sơ và luồng quy trình đang nổi lên như một
thực tiễn tốt nhất trong nhiều tổ chức.
 Quản lý Truy cập: đây là quy trình để cấp phép quyền cho
người dùng hợp pháp để sử dụng một dịch vụ, đồng thời hạn
chế quyền truy cập đối với người dùng trái phép. Điều này dựa
trên việc có thể xác định một cách chính xác người dùng đã
được ủy quyền và sau đó quản lý khả năng của họ để truy cập
các dịch vụ theo yêu cầu trong các giai đoạn khác nhau của
nguồn nhân lực (HR) hoặc vòng đời hợp đồng của họ. Quản lý
Truy cập còn được gọi là Quản lý Danh tính hoặc Quản lý
Quyền trong một số tổ chức.
Ngoài ra, còn có một số quy trình khác sẽ được thực thi hoặc hỗ trợ
trong quá trình Vận hành Dịch vụ, nhưng được thúc đẩy trong các
giai đoạn khác của Vòng đời Quản lý Dịch vụ. Các khía cạnh hoạt
động của những quy trình này sẽ được thảo luận trong phần cuối
cùng của chương này và bao gồm:
 Quản lý Thay đổi, một quy trình chính nên được liên kết chặt
chẽ với Quản lý Cấu hình và Quản lý Phát hành. Các chủ đề này
chủ yếu được đề cập trong Ấn phẩm Chuyển tiếp Dịch vụ.
 Quản lý Công suất và Quản lý Tính sẵn sàng, các khía cạnh
hoạt động được đề cập trong ấn phẩm này, nhưng được đề cập
chi tiết hơn trong ấn phẩm Thiết kế Dịch vụ.
 Quản lý Tài chính, được đề cập trong ấn phẩm Chiến lược Dịch
vụ.
 Quản lý Kiến thức, được đề cập trong ấn phẩm Chuyển tiếp
Dịch vụ.
 Tính liên tục của Dịch vụ CNTT, được đề cập trong ấn phẩm
Thiết kế Dịch vụ.
 Báo cáo Dịch vụ và Đo lường Dịch vụ, được đề cập trong ấn
phẩm Liên tục Cải tiến Dịch vụ.
4.1 Quản lý sự kiện

Một sự kiện có thể được xác định là bất kỳ sự kiện nào có thể phát
hiện được hoặc nhận thấy được là có ý nghĩa quan trọng đối với
quản lý cơ sở hạ tầng CNTT hoặc cung cấp dịch vụ CNTT và đánh giá
về tác động mà một sự sai lệch có thể gây ra cho các dịch vụ. Các
sự kiện thường là các thông báo được tạo ra bởi một dịch vụ CNTT,
Đơn vị Cấu hình (CI) hoặc công cụ giám sát.
Vận hành Dịch vụ hiệu quả phụ thuộc vào việc biết được trạng thái
của cơ sở hạ tầng và phát hiện ra được bất kỳ sai lệch nào so với
quá trình vận hành bình thường hoặc đã được dự kiến. Điều này
được cung cấp bởi các hệ thống kiểm soát và giám sát tốt, dựa trên
hai loại công cụ:
 các công cụ giám sát tích cực thăm dò các Đơn vị Cấu hình chủ
chốt để xác định trạng thái và tính sẵn sàng của chúng. Bất kỳ
ngoại lệ nào sẽ tạo ra một cảnh báo cần phải được truyền đạt
cho công cụ hoặc nhóm thích hợp để có hành động.
 các công cụ giám sát thụ động phát hiện và tương quan các
cảnh báo vận hành hoặc thông tin liên lạc được tạo ra bởi các
CI.
4.1.1 Mục đí ch/đíc h đ ến/ m ục ti êu

Năng lực phát hiện các sự kiện, hiểu rõ chúng và xác định hành
động kiểm soát thích hợp được cung cấp bởi Quản lý Sự kiện. Do đó,
Quản lý Sự kiện là cơ sở cho Kiểm soát và Giám sát Vận hành (Phụ
lục B).
Ngoài ra, nếu những sự kiện đó được lên chương trình để truyền đạt
những thông tin vận hành cũng như những cảnh báo và ngoại lệ,
chúng có thể được sử dụng như một cơ sở cho việc tự động hóa rất
nhiều hoạt động Quản lý Vận hành thường lệ, ví dụ, việc thực thi
các tập lệnh kịch bản trên các thiết bị từ xa, hoặc gửi công việc để
xử lý, hoặc thậm chí cân bằng động nhu cầu đối với một dịch vụ trên
nhiều thiết bị để nâng cao hiệu suất.
Do đó, Quản lý Sự kiện cung cấp điểm vào lệnh đối với việc thực thi
rất nhiều quy trình và hoạt động Vận hành Dịch vụ. Ngoài ra, nó
cung cấp một cách thức để so sánh hiệu suất và hành vi thực tế so
với các tiêu chuẩn thiết kế và các SLA. Như vậy, Quản lý Sự kiện
cũng cung cấp một cơ sở cho Đảm bảo và Báo cáo Dịch vụ, và Cải
tiến Dịch vụ. Điều này được đề cập chi tiết trong ấn phẩm Liên tục
Cải tiến Dịch vụ.
4.1.2 Phạ m vi
Quản lý Sự kiện có thể được áp dụng cho bất kỳ khía cạnh nào của
Quản lý Dịch vụ cần phải được kiểm soát và những gì có thể được tự
động hóa. Chúng bao gồm:
 Các Đơn vị Cấu hình:

o Một số Đơn vị Cấu hình sẽ được bao gồm vì chúng cần
phải giữ trạng thái bất biến (ví dụ, một bộ chuyển mạch
trên một mạng cần phải được bật và các công cụ Quản lý
Sự kiện xác nhận điều này bằng cách giám sát phản hồi
đối với câu lệnh ‘ping’).
o Một số Đơn vị Cấu hình sẽ được bao gồm vì trạng thái của
chúng cần phải thay đổi thường xuyên và Quản lý Sự kiện
có thể được sử dụng để tự động hóa việc này và cập nhật
CMS (ví dụ, việc cập nhật của một máy chủ lưu trữ tập
tin).
 Các điều kiện môi trường (ví dụ, phát hiện, báo cháy, báo
khói)).
 Giám sát việc sử dụng giấy phép phần mềm để đảm bảo việc sử
dụng và phân bổ giấy phép tối ưu và hợp pháp.
 Bảo mật (ví dụ, phát hiện xâm nhập).
 Các hoạt động bình thường (ví dụ, theo dõi việc sử dụng một
ứng dụng hoặc hiệu suất của một máy chủ).
Giá tr ị đối v ớ i doan h nghi ệp
Giá trị của Quản lý Sự kiện đổi với doanh nghiệp thường là gián
tiếp, tuy nhiên, vẫn có thể xác định cơ sở cho giá trị của nó như
dưới đây:
 Quản lý Sự kiện cung cấp các cơ chế để cảnh báo sớm về

những sự cố. Trong rất nhiều trường hợp, một điều khả dĩ là sự
cố sẽ được phát hiện và chỉ định cho một nhóm thích hợp để
hành động trước khi bất kỳ gián đoạn dịch vụ thực sự nào xảy
ra.
 Quản lý Sự kiện khiến cho một số loại hoạt động đã được tự
động hóa có thể được theo dõi ngoại lệ trở nên khả thi - do đó
loại bỏ nhu cầu giám sát thời gian thực tốn kém và tiêu tốn
nhiều tài nguyên, đồng thời giảm thời gian ngừng hoạt động.
 Khi được tích hợp vào các quy trình Quản lý Dịch vụ khác
(chẳng hạn như, ví dụ, Quản lý Tính sẵn sàng hoặc Quản lý
Công suất), Quản lý Sự kiện có thể báo hiệu những thay đổi
trạng thái hoặc những ngoại lệ cho phép cá nhân hoặc nhóm
thích hợp thực hiện biện pháp ứng phó sớm, từ đó cải thiện
được hiệu suất của quy trình. Đổi lại, điều này sẽ cho phép
doanh nghiệp hưởng lợi từ Quản lý Dịch vụ hiệu quả hơn và
hiệu suất hơn xét về tổng thể.
 Quản lý Sự kiện cung cấp cơ sở cho các hoạt động tự động
hóa, từ đó, gia tăng tính hiệu quả và cho phép nguồn nhân lực
đắt tiền được sử dụng cho những công việc mang tính sáng tạo
hơn, chẳng hạn như thiết kế chức năng mới hoặc được cải thiện
hoặc xác định những cách thức mới mà theo đó doanh nghiệp
có thể khai thác công nghệ cho những lợi thế cạnh tranh được
tăng cường.
4.1.3 Các chính sách/ng uyên t ắ c/ý tư ở ng c ơ b ả n

Có rất nhiều kiểu sự kiện khác nhau, ví dụ như:
 Các sự kiện biểu thị hoạt động thường xuyên:

o thông báo rằng một khối lượng công việc được lên lịch
trình đã hoàn tất,
o một người dùng đăng nhập vào để sử dụng một ứng dụng,
o một email đã được gửi đến cho người nhận dự định,
 Các sự kiện biểu thị một ngoại lệ:
o một người dùng đang cố gắng đăng nhập vào một ứng
dụng với mật khẩu sai,
o một tình huống bất tường dã xảy ra trong một quy trình
nghiệp vụ có thể chỉ ra một ngoại lệ đòi hỏi tìm hiểu thêm
về nghiệp vụ (ví dụ, một cảnh báo trang web có thể chi ra
rằng một trang ủy quyền thanh toán không sẵn sàng - ảnh
hưởng đến sự phê duyệt tài chính của các giao dịch kinh
doanh),
o một CPU của thiết bị vượt mức ngưỡng sử dụng có thể
chấp nhận được,
o một quá trình quét máy tính tiết lộ ra việc cài đặt những
phần mềm trái phép.
 Các sự kiện biểu thị hoạt động bất thường, nhưng không đặc
biệt. Đây là một dấu hiệu cho thấy rằng tình hình có thể cần
được theo dõi chặt chẽ hơn. Trong một số trường hợp, bản
thân điều kiện sẽ tự giải quyết, ví dụ như trong trường hợp có
sự kết hợp bất thường của các khối lượng công việc – một khi
chúng đã hoàn thành, hoạt động bình thường được khôi phục.
Trong các trường hợp khác, có thể sẽ cần đến sự can thiệp của
người vận hành nếu tình trạng này lặp lại hoặc nếu nó tiếp tục
quá lâu. Các quy tắc hoặc chính sách này được xác định trong
Mục tiêu Giám sát và Kiểm soát đối với thiết bị hoặc dịch vụ
đó. Các ví dụ về loại sự kiện này bao gồm:
o Việc sử dụng bộ nhớ của một máy chủ đạt mức trong vòng
5% so với mức hiệu suất cao nhất có thể chấp nhận được,
o Thời gian hoàn thành giao dịch lâu hơn 10% so với bình
thường.
Có hai điều quan trọng về những ví dụ nói trên:
 Chính xác thì điều gì đang tạo nên hoạt động bình thường so
với hoạt động bất thường, so với một ngoại lệ? Không có quy
tắc dứt khoát về điều này. Ví dụ, một nhà sản xuất có thể đưa
ra mức tiêu chuẩn sử dụng bộ nhớ 75% là tối ưu cho ứng dụng
X. Tuy nhiên, người ta phát hiện ra rằng, trong các điều kiện
cụ thể của tổ chức của chúng tôi, thời gian phản hồi bắt đầu
giảm trên mức sử dụng 70%. Phần tiếp theo sẽ khám phá cách
xác định các số liệu này.
 Mỗi loại sự kiện phụ thuộc vào việc gửi và nhận một số loại
thông điệp. Chúng thường được gọi là thông báo Sự kiện và
chúng không chỉ đơn thuần là xảy ra. Các đoạn tiếp theo sẽ
khám phá chính xác về cách mà các sự kiện được xác định, tạo
ra và nắm bắt như thế nào.
4.1.4 Các ho ạ t đ ộng, phư ơng ph áp và k ỹ thuậ t

quy trì nh
Hình 4.1 là một thuyết trình chung chung cao cấp của Quản lý Sự
kiện. Nó nên được sử dụng như một điểm tham chiếu và định nghĩa
thay vì một lưu đồ Quản lý Sự kiện thực tế. Từng hoạt động trong
quy trình này được mô tả như dưới đây.
4.1.4. 1 Sự k iệ n x ả y ra
Các sự kiện xảy ra một cách liên tục, nhưng không phải tất cả chúng
đều được phát hiện hoặc được đăng ký. Do đó, điều quan trọng là
mọi người tham gia vào việc thiết kế, phát triển, quản lý và hỗ trợ
các dịch vụ CNTT và cơ sở hạ tầng CNTT mà các dịch vụ đang hoạt
động trên đó hiểu được kiểu sự kiện nào cần phải được phát hiện.
Điều này được thảo luận thêm trong phần 4.1.10.1, “Công cụ đo
đạc”.
4.1.4. 2 Thông báo v ề s ự k iệ n
Hầu hết các Đơn vị Cấu hình được thiết kế để truyền đạt những
thông tin chắc chắn về bản thân chúng theo một trong hai cách sau
đây:
 Một thiết bị được thẩm tra bởi một công cụ quản lý, công cụ
này thu thập một số dữ liệu đã được nhắm mục tiêu. Điều này
thường được gọi là thăm dò ý kiến.
 Đơn vị Cấu hình tạo ra một thông báo khi các điều kiện nhất
định được đáp ứng. Khả năng tạo ra các thông báo này phải
được thiết kế và tích hợp vào Đơn vị Cấu hình, ví dụ như một
móc lập trình (programming hook) được chèn vào trong một
ứng dụng.
Hình 4.1 Quy trình Quản lý Sự kiện
Thông báo sự kiện có thể là độc quyền, và trong trường hợp đó, chỉ
có các công cụ quản lý của nhà sản xuất có thể được sử dụng để
phát hiện ra các sự kiện. Tuy nhiên, hầu hết các Đơn vị Cấu hình
đều tạo thông báo Sự kiện bằng một tiêu chuẩn mở như SNMP (Giao
thức Quản lý Mạng Đơn giản).
Rất nhiều Đơn vị Cấu hình được thiết lập cấu hình để tạo ra một tập
hợp các sự kiện tiêu chuẩn, dựa trên kinh nghiệm của người thiết kế
về những gì cần thiết để vận hành Đơn vị Cấu hình, với khả năng
tạo ra các loại sự kiện bổ sung bằng cách 'bật' cơ chế tạo sự kiện có
liên quan. Đối với các loại Đơn vị Cấu hình khác, một số dạng phần
mềm ‘tác nhân/agent’ sẽ phải được cài đặt để bắt đầu quá trình
giám sát. Thường thì tính năng giám sát này là mi ễn phí, nhưng đôi
khi sẽ có phí cấp phép cho công cụ.
Trong một thế giới lý tưởng, quy trình Thiết kế Dịch vụ nên xác định
những sự kiện nào cần được tọa ra và sau đó, chỉ định về cách thức
điều này có thể được hoàn thành như thế nào đối với từng Đơn vị
Cấu hình. Trong Chuyển tiếp Dịch vụ, các tùy chọn tạo ra sự kiện sẽ
được thiết lập và được kiểm tra.
Ở rất nhiều tổ chức, tuy nhiên, việc xác định những sự kiện nào
được tạo ra được hoàn thành bởi thử và lỗi. Các nhà quản lý hệ
thống sử dụng bộ các sự kiện tiêu chuẩn như là điểm khởi đầu và
sau đó, tinh chỉnh Đơn vị Cấu hình theo thời gian, để bao gồm hoặc
loại bỏ các sự kiện khi cần thiết. Vấn đề với phương pháp tiếp cận
này là rằng nó chỉ tính đến những nhu cầu tức thời của nhân viên
đang quản lý thiết bị và không tạo điều kiệncho hoạch định tốt hoặc
cho sự cải thiện. Ngoài ra, nó khiến cho việc giám sát và quản lý
dịch vụ trên mọi thiết bị và nhân viên trở nên khó khăn hơn. Một
phương pháp tiếp cận khác để chống lại vấn đề này là xem xét tập
hợp các sự kiện như là một phần của các hoạt động liên tục cải tiến.
Một nguyên tắc chung của thông báo Sự kiện là rằng dữ liệu mà nó
bao hàm càng có ý nghĩa và các đ ối tượng càng được nhắm mục tiêu
hơn thì càng dễ để đưa ra quyết định về sự kiện. Những người vận
hành thường phải đối mặt với các thông điệp lỗi được mã hóa và
không biết làm thế nào để ứng phó với chúng hoặc cần phải làm gì
với chúng. Dữ liệu thông báo có ý nghĩa và các vai trò và trách
nhiệm được xác định một cách rõ ràng cần phải được trình bày rõ
ràng và được lập thành tài liệu trong Thiết kế Dịch vụ và Chuyển
tiếp Dịch vụ (xem thêm phần 4.1.10.1 về “Công cụ đo đạc”). Nếu
như các vai trò và trách nhiệm không được xác định rõ ràng, trong
một cảnh báo rộng rãi, sẽ không ai biết được ai đang làm gì và điều
này có thể dẫn đến việc những nỗ lực bị bỏ sót hoặc trùng lặp.
4.1.4. 3 N hậ n di ện s ự k iện
Khi một thông báo Sự kiện đã được tạo ra, nó sẽ được phát hiện bởi
một tác nhân hoạt động trên cùng hệ thống, hoặc chuyển tiếp trực
tiếp cho một công cụ quản lý được thiết kế đặc biệt để đọ và diễn
dịch ý nghĩa của sự kiện.
4.1.4. 4 Lọc s ự k iện

Mục đích của việc lọc là để quyết định xem liệu có nên truyền đạt sự
kiện cho một công cụ quản lý hay bỏ qua nó. Nếu bị bỏ qua, sự kiện
thường sẽ được ghi nhận lại trong một tập tin nhật ký của thiết bị,
nhưng không có hành động nào khác sẽ được thực hiện.
Nguyên nhân để tiến hành lọc là không phải lúc nào cũng có thể tắt
thông báo Sự kiện, thậm chí một quyết định đã được đưa ra rằng
không nhất thiết phải tạo ra kiểu sự kiện đó. Cũng có thể quyết định
rằng chỉ có thông báo đầu tiên trong chuỗi thông báo Sự kiện được
lặp lại sẽ được truyền đi.
Trong quá trình lọc, mức độ tương quan đầu tiên được thực hiện,
nghĩa là xác định xem sự kiện chỉ là cung cấp thông tin, cảnh báo
hay ngoại lệ (xem bước tiếp theo). Mối tương quan này thường được
thực hiện bởi một tác nhân cư trú trên Đơn vị Cấu hình hoặc trên
máy chủ mà Đơn vị Cấu hình được kết nối.
Bước lọc không phải lúc nào cũng cần thiết. Đối với một số Đơn vị
Cấu hình, mọi sự kiện đều quan trọng và chuyển trực tiếp vào
phương tiện tương quan của công cụ quản lý, thậm chí ngay cả khi
nó bị trùng lặp. Ngoài ra, có thể đã tắt tất cả các thông báo Sự kiện
ngoài ý muốn.
4.1.4. 5 Tầ m q uan tr ọng c ủ a s ự k iện

Mọi tổ chức sẽ có sự phân loại tầm quan trọng của một sự kiện cho
riêng mình, nhưng chúng tôi đ ề nghị rằng, ít nhất 3 thể loại rộng rãi
sau nên được trình bày:
 Cung cấp thông tin: Đề cập đến một sự kiện không đòi hỏi
bất kỳ hành động nào và không thể hiện cho một ngoại lệ.
Chúng thường được lưu trữ trong các tập tin nhật ký hệ thống
hoặc nhật ký dịch vụ và được giữu trong một khoảng thời gian
đã được định trước. Các sự kiện cung cấp thông tin thường
được sử dụng để kiểm tra về trạng thái của một thiết bị hoặc
một dịch vụ, hoặc để xác nhận sự hoàn thành thành công của
một hành động. Các sự kiện cung cấp thông tin cũng có thể
được sử dụng để tạo ra những thống kê (chẳng hạn như số
lượng người dùng đã đăng nhập vào một ứng dụng trong một
khoảng thời gian nhất định) và làm đầu vào cho các cuộc điều
tra (chẳng hạn như những tác vụ nào đã hoàn thành thành
công trước khi hàng đợi xử lý giao dịch bị treo). Các ví dụ về
những sự kiện cung cấp thông tin bao gồm:
o Một người dùng đăng nhập vào một ứng dụng,
o Một tác vụ trong hàng đợi tập lệnh theo lô hoàn thành
thành công,
o Một thiết bị đã trực tuyến (trên hệ thống mạng),
o Một giao dịch được hoàn thành thành công.
 Cảnh báo: Một cảnh báo là một sự kiện được tạo ra khi một
dịch vụ hoặc thiết bị đang tiệm cận một ngưỡng. Các cảnh báo
được nhắm mục đích nhằm thông báo cho cá nhân, quy trình
hoặc công cụ thích hợp để tình huống có thể được kiểm tra và
hành động thích hợp được thực hiện để ngăn chặn một ngoại
lệ. Các cảnh báo thường không được đưa ra cho một lỗi thiết
bị. Tuy nhiên, vẫn có một số tranh cãi xung quanh việc liệu
rằng lỗi của một thiết bị dự phòng nên là một cảnh báo hay
ngoại lệ (vì dịch vụ vẫn đang sẵn sàng). Một quy tắc tốt là mọi
lỗi nên được xem là một ngoại lệ, vì nguy cơ xảy ra một sự cố
ảnh hưởng đến hoạt động kinh doanh là lớn hơn nhiều. Các ví
dụ về cảnh báo bao gồm:
o Mức sử dụng bộ nhớ trên một máy chủ hiện đang ở mức
65% và vẫn đang tăng. Nếu nó đạt mức 75%, thời gian
hồi đáp sẽ dài đến mức không thể chấp nhận được và OLA
cho bộ phận đó sẽ bi vi phạm.
o Tỷ lệ xung đột trên một mạng đã gia tăng 15% trong giờ
vừa qua.
 Ngoại lệ: Một ngoại lệ có nghĩa là một dịch vụ hoặc một thiết
bị hiện đang hoạt động một cách bất thường (tuy điều này đã
được xác định). Thông thường, điều này có nghĩa là một OLA
và SLA đã bị vi phạm và công việc kinh doanh đã bị tác động.
Các ngoại lệ có thể thể hiện cho một lỗi hoàn toàn, chức năng
bị suy giảm hoặc hiệu suất bị giảm sút. Tuy nhiên, hãy lưu ý
rằng một ngoại lệ không phải lúc nào cũng đại diện cho một sự
cố. Ví dụ, một ngoại lệ có thể được tạo ra khi một thiết bị trái
phép được phát hiện trên hệ thống mạng. Việc này có thể được
quản lý bằng cách sử dụng một Hồ sơ Sự cố hoặc một Yêu cầu
Thay đổi (hoặc cả hai), tùy thuộc vào các chính sách Quản lý
Thay đổi và Sự cố của tổ chức. Các ví dụ về các ngoại lệ bao
gồm:
o Một máy chủ bị tắt,
o Thời gian hồi đáp của một giao dịch tiêu chuẩn qua hệ
thống mang đã chậm hơn 15 giây,
o Hơn 150 người dùng đã đăng nhập vào một ứng dụng Sổ
cái Kế toán đồng thời,
o Một phân đoạn mạng không hồi đáp đối với các yêu cầu
thường lệ.
4.1.4. 6 Sự tươ ng qua n c ủa s ự k iệ n

Nếu một sự kiện là nghiêm trọng, một quyết định phải được đưa ra
xoay quanh tầm quan trọng chính xác và những hành động nào phải
được thực hiện để xử lý nó (sự kiện). Chính ở đây, ý nghĩa của sự
kiện được xác định.
Sự tương quan được thực hiện bởi một ‘Bộ máy Tương quan’, thường
là một phần của một công cụ quản lý để so sánh sự kiện với một tập
hợp các tiêu chí và quy tắc theo thứ tự đã được mô tả trước. Những
tiêu chí này thường được gọi là các Quy tắc Doanh nghiệp (Business
Rules), mặc dù chúng nói chung thiên về mặt kỹ thuật. Ý tưởng là
rằng sự kiện có thể đại diện cho một số tác động đến doanh nghiệp
và các quy tắc có thể được sử dụng để xác định mức độ và loại của
tác động kinh doanh.
Một Bộ máy Tương quan được lên chương trình tùy theo các tiêu
chuẩn hiệu suất đã được tạo ra trong giai đoạn Thiết kế Dịch vụ và
bất kỳ hướng dẫn bổ sung cụ thể nào đối với môi trường vận hành.
Các ví dụ về những gì mà Bộ máy Tương quan tính đến bao gồm:
 Số lượng các sự kiện tương tự (ví dụ, đây là lần thứ ba mà một
người dùng đã đăng nhập vào (hệ thống( với mật khẩu sai, một
ứng dụng nghiệp vụ báo cáo rằng đã có một hình mẫu bất
thường trong việc sử dụng một điện thoại di động mà có thể
chỉ ra rằng thiết bị đã bị mất hoặc bị trộm cắp),
 Số lượng các Đơn vị Cấu hình tạo ra các sự kiện tương tự,
 Liệu rằng một hành động cụ thể được liên kết với mã hoặc dữ
liệu trong sự kiện hay không,
 Sự kiện có đại diện cho một ngoại lệ hay không,
 So sánh thông tin sử dụng trong sự kiện với tiêu chuẩn tối đa
hoặc tối thiểu (ví dụ, thiết bị có vượt quá ngưỡng không?),
 Liệu rằng dữ liệu bổ sung có được yêu cầu để điều tra thêm về
sự kiện hay không, và thậm chí có thể là một bộ sưu tập dữ
liệu đó bằng cách thăm dò một hệ thống hoặc cơ sở dữ liệu
khác,
 Phân loại sự kiện,
 Chỉ định mức độ ưu tiên cho sự kiện.
4.1.4. 7 Điều ki ện kíc h ho ạ t

Nếu hoạt động tương quan công nhận một sự kiện, một biện pháp
ứng phó sẽ là cần thiết. Cơ chế được sử dụng để khởi đầu biện pháp
ứng phó đó được gọi là điều kiện kích hoạt.
Có rất nhiều kiểu điều kiện kích hoạt, mỗi kiểu được thiết kế đặc
biệt cho tác vụ mà nó phải khởi đầu. Một số ví dụ bao gồm:
 Các Điều kiện kích hoạt Sự cố tạo ra một bản ghi trong hệ
thống Quản lý Sự cố, do đó, khởi đầu quy trình Quản lý Sự cố,
 Các Điều kiện kích hoạt Thay đổi tạo ra một Yêu cầu Thay đổi
(RFC), do đó, khởi đầu quy trình Quản lý Thay đổi,
 Một điều kiện kích hoạt là kết quả từ một RFC đã được phê
duyệt được triển khai nhưng gây ra sự kiện, hoặc từ một thay
đổi trái phép đã được phát hiện – trong cả hai trường hợp, việc
này sẽ được chuyển đến Quản lý Thay đổi để điều tra thêm,
 Các tập lệnh kịch bản thực thi các hành động cụ thể, chẳng
hạn như việc đệ trình các công việc hàng loạt hoặc khởi động
lại một thiết bị,
 Các hệ thống phân trang sẽ thông báo cho cá nhân hoặc nhóm
về sự kiện qua điện thoại di động,
 Các điều kiện kích hoạt cơ sở dữ liệu hạn chế quyền truy cập
của một người dùng đến các bản ghi hoặc trường (dữ liệu) cụ
thể, hoặc tạo ra hoặc xóa các mục từ cơ sở dữ liệu.
4.1.4. 8 Lựa ch ọn ph ả n ứng
Tại thời điểm này trong quy trình, có một số tùy chọn ứng phó có
sẵn. Điều quan trọng cần phải lưu ý là các tùy chọn ứng phó có thể
được chọn theo bất kỳ sự kết hợp nào. Ví dụ, có thể cần phải bảo
quản mục nhập nhật ký để tham khảo trong tương lai, nhưng đồng
thời leo thang sự kiện cho nhân viên bộ phận Quản lý Vận hành để
thực hiện hành động.
Các tùy chọn trong lưu đồ là những ví dụ. Các tổ chức khác nhau sẽ
có các lựa chọn khác nhau và chúng chắc chắn sẽ chi tiết hơn. Ví
dụ, sẽ có một loạt các biện pháp ứng phó tự động cho từng công
nghệ khác nhau. Quá trình xác định biện pháp nào phù hợp và cách
thực hiện nó sẽ không được trình bày trong lưu đồ này. Một số tùy
chọn có sẵn là:
 Ghi nhật ký sự kiện: Bất kể hoạt động nào được thực hiện,
một ý tưởng tốt là bạn nên ghi lại sự kiện và mọi hành động
tiếp theo. Sự kiện có thể được ghi nhận lại dưới dạng Bản ghi
Sự kiện trong công cụ Quản lý Sự kiện hoặc đơn giản có thể
được để dưới dạng một mục nhập trong nhật ký hệ thống của
thiết bị hoặc ứng dụng đã tạo ra sự kiện. Tuy nhiên, nếu
trường hợp này xảy ra, cần phải có yêu cầu thường trực đối với
nhân viên Quản lý Vận hành thích hợp để kiểm tra nhật ký một
cách thường xuyên và hướng dẫn rõ ràng về cách sử dụng từng
nhật ký. Cũng nên nhớ rằng thông tin sự kiện trong các nhật ký
có thể không có ý nghĩa cho đến khi sự cố xảy ra, và nơi mà
nhân viên Quản lý Kỹ thuật sử dụng các nhật ký để điều tra
xem sự cố bắt nguồn từ đâu. Điều này có nghĩa là các thủ tục
Quản lý Sự kiện cho mỗi hệ thống hoặc nhóm cần xác định các
tiêu chuẩn về thời gian các sự kiện được lưu giữ trong nhật ký
lâu đến mức nào trước khi chúng được lưu giữ và xóa.
 Ứng phó tự động: Một số sự kiện được hiểu đủ rõ rằng biện
pháp ứng phó thích hợp đã được xác định và tự động hóa. Điều
này thường là kết quả của thiết kế tốt hoặc của kinh nghiệm
trước đó (thường là Quản lý Vấn đề). Điều kiện kích hoạt sẽ
bắt đầu hành động và sau đó đánh giá xem nó đã được hoàn
thành một cách thành công hay không. Nếu không, một Bản ghi
Sự cố hoặc Bản chi Vấn đề sẽ được tạo ra. Ví dụ về biện pháp
ứng phó tự động bao gồm:
 Khởi động lại thiết bị,
 Khởi động lại một dịch vụ,
 Đưa một tác vụ vào một tập lệnh hàng loạt,
 Thay đổi một tham số trên một thiết bị,
 Khóa một thiết bị hoặc ứng dụng để bảo vệ nó khỏi sự
truy cập trái phép.
Lưu ý: việc khóa một thiết bị có thể dẫn đến việc từ chối
dịch vụ đối với những người dùng hợp pháp, vốn có thể bị
khai thác bởi một kẻ tấn công có chủ đích – vì vậy, nên
cực kỳ thận trọng khi quyết định xem liệu đây có phải lả
một hành động tự động hóa thích hợp hay không.
 Cảnh báo và sự can thiệp của con người: Nếu các sự kiện
đòi hỏi sự can thiệp của con người thì nó sẽ cần phải được leo
thang. Mục đích của cảnh báo là để đảm bảo rằng cá nhân có
kỹ năng thích hợp để xử lý sự kiện được thông báo. Cảnh báo
sẽ chứa tất cả thông tin cần thiết để cá nhân đó xác định hành
động thích hợp - bao gồm tham chiếu đến bất kỳ tài liệu cần
thiết nào (ví dụ, hướng dẫn sử dụng). Điều quan trọng cần lưu
ý là điều này không nhất thiết giống như sự leo thang chức
năng của một sự cố, trong đó nhấn mạnh vào việc khôi phục lại
dịch vụ trong một thời gian đã thỏa thuận (có thể đòi hỏi nhiều
hoạt động khác nhau). Cảnh báo yêu cầu một người hoặc một
nhóm thực hiện một hành động cụ thể, có thể trên một thiết bị
cụ thể và có thể vào một thời điểm cụ thể, ví dụ, thay hộp mực
trong máy in khi mực gần hết.
 Sự cố, vấn đề hoặc thay đổi? Một số sự kiện sẽ đại diện cho
một tình huống mà biện pháp ứng phó thích hợp sẽ cần được
xử lý thông qua quy trình Quản lý Sự cố, Quản lý Vấn đề hoặc
Quản lý Thay đổi. Những điều này được thảo luận dưới đây,
nhưng điều quan trọng cần lưu ý là một sự cố duy nhất có thể
khởi đầu bất kỳ một hoặc một sự kết hợp nào của ba quy trình
này - ví dụ, một lỗi máy chủ không nghiêm trọng được ghi nhật
ký lại là một sự cố, nhưng không có cách giải quyết nào, một
Bản ghi Sự cố được tạo ra để xác định nguyên nhân gốc rễ và
cách giải quyết và một RFC được ghi nhận lại để chuyển khối
lượng công việc sang một máy chủ thay thế trong khi sự cố
được giải quyết.
 Mở RFC: Có hai nơi trong quy trình Qu ản lý Sự kiện mà một
RFC có thể được tạo ra:
 Khi một ngoại lệ diễn ra: Ví dụ, một quá trình quét một
phân đoạn mạng tiết lộ rằng có hai thiết bị mới đã được
thêm vào mà không cần cấp phép. Một cách để xử lý tình
huống này là mở một RFC, vốn có thể được sử dụng như
một phương tiện để quy trình Quản lý Thay đổi xử lý
ngoại lệ (như là một giải pháp thay thế theo phương pháp
tiếp cận thông thường hơn là mở một Sự cố mà sẽ được
chuyển sang Bộ phận Hỗ trợ Dịch vụ để Quản lý Thay
đổi). Ở đây, việc điều tra bởi Quản lý Thay đổi là thích
hợp vì những thay đổi trái phép ngụ ý rằng quy trình
Quản lý Thay đổi đã không có hiệu quả.
 Sự tương quan xác định rằng một thay đổi là cần
thiết: Trong trường hợp này, hoạt động tương quan sự
kiện xác định rằng biện pháp ứng phó thích hợp đối với
một sự kiện là để một điều gì đó sẽ phải được thay đổi. Ví
dụ, một ngưỡng hiệu suất đã bị đạt tới, và một tham số
trên một máy chủ chính cần phải được điều chỉnh. Hoạt
động tương quan xác định điều này như thế nào? Nó đã
được lập trình để thực hiện điều này trong quy trình Thiết
kế Dịch vụ hoặc bởi vì điều này đã xảy ra trước khi Quản
lý Vấn đề hay Quản lý Vận hành cập nhật Bộ máy Tương
quan để thực hiện hành động.
 Mở một Bản ghi Sự cố: Như với một RFC, một sự cố có thể
được tạo ra ngay tức khắc khi một ngoại lệ được phát hiện,
hoặc khi Bộ máy Tương quan xác định rằng một kiểu hoặc một
kết hợp cụ thể của các sự kiện thể hiện cho một sự cố. Khi một
Bản ghi Sự cố được mở, càng nhiều thông tin càng tốt nên
được bao gồm – cùng với liên kết đến các sự kiện có liên quan,
và nếu có thể, một kịch bản chẩn đoán hoàn chỉnh.
 Mở hoặc liên kết tới một Bản ghi Vấn đề: Hiếm khi một Bản
ghi Vấn đề được mở ra mà không có các sự cố liên quan (ví dụ,
như là một kết quả của một Phân tích Lỗi Dịch vụ (xem ấn
phẩm Thiết kế Dịch vụ) hoặc đánh giá mức độ trưởng thành,
hoặc bởi vì một lượng lớn các lỗi mạng lặp lại, thậm chí ngay
cả một lỗi vẫn chưa xảy ra). Trong hầu hết các trường hợp,
bước này đề cập đến việc liên kết một sự cố với một Bản ghi
Vấn đề đang hiện hữu. Việc này sẽ giúp cho các nhóm Quản lý
Vấn đề đánh giá lại mức độ nghiêm trọng và tác động của vấn
đề, và có thể dẫn đến một mức ưu tiên được thay đổi đối với
một vấn đề đang còn tồn đọng.
Tuy nhiên, với một vài công cụ tinh vi hơn, có thể đánh giá tác
động của các sự cố và đồng thời đưa ra một Bản ghi Vấn đề
một cách tự động, nếu điều này được đảm bảo, để cho phép
phân tích nguyên nhân gốc rễ bắt đầu ngay lập tức.
 Các kiểu sự cố đặc biệt: Trong một số trường hợp, một sự
kiện sẽ chỉ ra một ngoại lệ không tác động trực tiếp đến bất kỳ
dịch vụ CNTT nào, ví dụ, một máy điều hòa không khí dự phòng
bị lỗi, hoặc truy nhập trái phép vào một trung tâm dữ liệu.
Những hướng dẫn cho các trường hợp đó được mô tả như dưới
đây:
 Một sự cố nên được ghi nhận bằng cách sử dụng một Mô
hình Sự cố thích hợp với kiểu ngoại lệ đó, ví dụ, một Sự
cố Vận hành hoặc Sự cố Bảo mật (xem đoạn 4.2.4.2 để
biết thêm chi tiết về các Mô hình Sự cố).
 Sự cố nên được leo thang cho nhóm đang qu ản lý kiểu sự
cố đó.
 Nếu không có sự gián đoạn, Mô hình Sự cố nên phản ảnh
rằng đây là một sự cố vận hành thay vì một sự cố dịch vụ.
Những thống kê thường sẽ không được báo cáo cho khách
hàng hoặc người dùng, trừ khi chúng có thể được sử dụng
để chứng minh rằng khoản tiền đã đầu tư vào dự phòng là
một khoản đầu tư đáng giá.
 Những sự cố đó không nên được sử dụng để tính toán thời
gian ngừng hoạt động, và thực tế có thể được sử dụng để
chứng minh CNTT đã chủ động như thế nào trong việc
cung cấp các dịch vụ.
4.1.4. 9 Xem x ét các hành đ ộ ng
Với hàng ngàn sự kiện đang được tạo ra mỗi ngày, sẽ không thể xem
xét chính thức từng sự kiện một. Tuy nhiên, điều quan trọng là kiểm
tra rằng bất kỳ sự kiện hoặc ngoại lệ nghiêm trọng nào đều đã được
xử lý một cách thích hợp, hoặc theo dõi các khuynh hướng hoặc đếm
các kiểu sự kiện, v.v… Trong rất nhiều trường hợp, việc này có thể
được thực hiện một cách tự động, ví dụ, thăm dò một máy chủ đã
được khởi động lại bằng cách sử dụng một kịch bản tập lệnh được tự
động hóa để kiểm tra rằng nó (máy chủ) có đang hoạt động một
cách đúng đắn không.
Trong những trường hợp khi các sự kiện phải khởi đầu một sự cố,
vấn đề và/hoặc thay đổi, quá trình Xem xét Hành động không nên
trùng lặp với bất kỳ xem xét nào đã được thực hiện như một phần
của các quy trình đó. Thay vào đó, m ục đích là để đảm bảo rằng sự
bàn giao giữa quy trình Quản lý Sự kiện và các quy trình khác được
diễn ra như đã được thiết kế và rằng hành động đã được kỳ vọng đã
thực sự diễn ra. Điều này sẽ đảm bảo rằng các sự cố, vấn đề hoặc
thay đổi khởi nguồn trong phạm vi Quản lý Vận hành không bị thất
lạc giữa các nhóm hoặc các bộ phận.
Quá trình Xem xét cũng sẽ được sử dụng như đầu vào cho liên tục
cải tiến và đánh giá và kiểm toán quy trình Quản lý Sự kiện.
4.1.4. 10 Đóng s ự k iện

Một số sự kiện vẫn tiếp tục mở trừ khi một hành động nhất định
được thực hiện, ví dụ, một sự kiện được liên kết với một sự cố mở.
Tuy nhiên, hầu hết các sự kiện không “đã mở/opened” hoặc “đã
đóng/closed”.
Các sự kiện cung cấp thông tin chỉ đơn giản được ghi nhật ký và sau
đó được sử dụng như một đầu vào cho các quy trình khác, ch ẳng
hạn như Quản lý Sao lưu và Lưu trữ. Các sự kiện ứng phó-tự động
sẽ thường được đóng bởi việc tạo ra một sự kiện thứ hai. Ví dụ, một
thiết bị tạo ra một sự kiện và được khởi động lại thông qua biện
pháp ứng phó tự động – và ngay sau khi thiết bị đã khởi động lại
thành công, nó sẽ tạo ra một sự kiện để đóng vòng lặp một cách
hiệu quả và xóa bỏ sự kiện đầu tiên.
Đôi khi, rất khó để liên kết một sự kiện mở với các thông báo đóng
vì chúng có các định dạng khác nhau. Điều tối ưu là các thiết bị
trong cơ sở hạ tầng tạo ra các sự kiện “mở” và “đóng” theo cùng
định dạng và chỉ định sự thay đổi trạng thái. Điều này cho phép
bước tương quan trong quy trình dễ dàng khớp các thông báo mở và
đóng.
Trong trường hợp những sự kiện đã tạo ra một sự cố, vấn đề hoặc
thay đổi, chúng nên được đóng một cách chính thức cùng với một
liên kết tới bản ghi thích hợp từ các quy trình khác.
4.1.5 Các đi ều ki ệ n kích ho ạ t, đ ầ u vào và đ ầ u

ra/các tương tác qua l ạ i gi ữa c ác quy trình
Quản lý Sự kiện có thể được khởi đầu bởi bất kỳ kiểu diễn ra nào.
Điều then chốt là xác định những lần xuất hiện nào là quan trọng và
cần phải được xử lý. Các điều kiện kích hoạt bao gồm:
 Các ngoại lệ đối với bất kỳ mức hiệu suất CI nào đã được xác
định trong các thông số kỹ thuật thiết kế, các OLA hoặc SOP.
 Các ngoại lệ đối với một thủ tục hoặc quy trình tự động, ví dụ,
một thay đổi thường xuyên đã từng được chỉ định cho một
nhóm xây dựng nhưng không được hoàn thành kịp thời.
 Một ngoại lệ trong một quy trình nghiệp vụ đang được giám sát
bởi Quản lý Sự kiện.
 Sự hoàn thành của một nhiệm vụ hoặc công việc tự động.
 Một thay đổi trạng thái trong bản ghi thiết bị hoặc cơ sở dữ
liệu.
 Sự truy cập của một ứng dụng hoặc cơ sở dữ liệu bởi người
dùng hoặc thủ tục hoặc công việc tự động.
 Một tình huống mà trong đó thiết bị, cơ sở dữ liệu hoặc ứng
dụng, v.v… đã đạt đến ngưỡng hiệu suất được xác định trước.
Quản lý Sự kiện có thể tương tác với bất kỳ quy trình nào đòi hỏi sự
giám sát và kiểm soát, đặc biệt là những quy trình không yêu cầu
giám sát theo thời gian thực, nhưng đòi hỏi một số hình thức can
thiệp sau một sự kiện hoặc nhóm các sự kiện. Ví dụ về các tương tác
với các quy trình khác bao gồm:
 Tương tác với các ứng dụng nghiệp vụ và/hoặc các quy trình
nghiệp vụ để cho phép các sự kiện kinh doanh quan trọng tiềm
ẩn được phát hiện và xử lý (ví dụ, một ứng dụng nghiệp vụ báo
cáo hoạt động bất thường trên tài khoản của khách hàng có thể
cho thấy một số loại gian lận hoặc vi phạm bảo mật).
 Các mối quan hệ ITSM chính yếu là với Quản lý Sự cố, Quản lý
Vấn đề và Quản lý Thay đổi. Các tương tác này được mô tả chi
tiết trong đoạn 4.1.5.8.
 Quản lý Công suất và Quản lý Tính sẵn sàng là điều tối quan
trọng trong việc xác định những sự kiện nào là quan trọng,
ngưỡng thích hợp nên là gì và cách ứng phó với chúng như thế
nào. Đổi lại, Quản lý Sự kiện sẽ cải thiện hiệu suất và tính khả
dụng của các dịch vụ bằng cách ứng phó với các sự kiện khi
chúng xảy ra và bằng cách báo cáo về các sự kiện thực tế và
các hình mẫu sự kiện để xác định (bằng cách so sánh với các
mục tiêu SLA và KPI) liệu nếu có một số khía cạnh của thiết kế
cơ sở hạ tầng hoặc vận hành có thể được cải thiện.
 Quản lý Cấu hình có thể sử dụng các sự kiện để xác định trạng
thái hiện tại của bất kỳ Đơn vị Cấu hình nào trong cơ sở hạ
tầng. Việc so sánh các sự kiện với các đường cơ sở được ủy
quyền trong Hệ thống Quản lý Cấu hình (CMS) sẽ giúp xác định
xem liệu có hoạt động Thay đổi trái phép nào đang diễn ra
trong tổ chức hay không (xem ấn phẩm Chuyển tiếp Dịch vụ).
 Quản lý Tài sản (được đề cập chi tiết hơn trong các ấn phẩm
Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ) có thể sử dụng Quản
lý Sự kiện để xác định trạng thái vòng đời của tài sản. Ví dụ,
một sự kiện có thể được tạo ra để báo hiệu rằng một tài sản
mới đã được thiết lập cấu hình thành công và hiện đang hoạt
động.
 Sự kiện có thể là một nguồn thông tin phong phú có thể được
xử lý để đưa vào hệ thống Quản lý Kiến thức. Ví dụ, các hình
mẫu hiệu suất có thể tương quan với hoạt động kinh doanh và
được sử dụng làm đầu vào cho các quyết định về thiết kế và
chiến lược trong tương lai.
 Quản lý Sự kiện có thể đóng một vai trò quan trọng trong việc
đảm bảo rằng tác động tiềm ẩn đối với các SLA được phát hiện
sớm và bất kỳ lỗi nào được hiệu chỉnh càng sớm càng tốt để
tác động đến các đích nhắm mục tiêu dịch vụ được giảm thiểu.
4.1.6 Q uả n lý Thôn g tin
Những thông tin then chốt liên quan đến Quản lý Sự kiện bao gồm:
 Các thông điệp SNMP, vốn là một cách thức tiêu chuẩn để
truyền đạt thông tin về mặt kỹ thuật về trạng thái của các
thành phần của một cơ sở hạ tầng CNTT.
 Cơ sở Thông tin Quản lý (MIBs) của các thiết bị CNTT. Một MIB
là một cơ sở dữ liệu trên từng thiết bị chứa những thông tin về
thiết bị đó, bao gồm hệ điều hành, BIOS, phiên bản, cấu hình
tham số hệ thống của nó, v.v… Khả năng thẩm tra các MIB và
so sánh chúng với một chuẩn mực là điều tối quan trọng để có
khả năng tạo ra các sự kiện.
 Phần mềm tác nhân công cụ giám sát của nhà cung cấp.
 Các Bộ máy Tương quan chứa các quy tắc chi tiết để xác định
tầm quan trọng và biện pháp ứng phó thích hợp đối với các sự
kiện. Những chi tiết về điều này được cung cấp trong đoạn
4.1.5.6.
 Không có Bản ghi Sự kiện tiêu chuẩn cho mọi loại sự kiện. Nội
dung và định dạng chính xác của bản ghi phụ thuộc vào các
công cụ đang được sử dụng, những gì đang được giám sát (ví
dụ, một máy chủ và các công cụ Quản lý Thay đổi sẽ có dữ liệu
rất khác nhau và có khả năng sử dụng một định dạng khác).
Tuy nhiên, có một vài dữ liệu then chốt thường được yêu cầu
từ mỗi sự kiện sẽ rất hữu ích trong việc phân tích. Nó thường
nên bao gồm:
o Thiết bị,
o Thành phần,
o Kiểu của lỗi,
o Ngày/giờ,
o Các tham số ngoại lệ,
o Giá trị.
4.1.7 Các ch ỉ s ố
Đối với từng chu kỳ đo lường đang được tìm hiểu, các chỉ số để kiếm
tra về tính hiệu quả và hiệu suất của quy trình Quản lý Sự kiện nên
bao gồm những điều sau đây:
 Số lượng các sự kiện theo thể loại,

 Số lượng các sự kiện theo tầm quan trọng,
 Số lượng và tỷ lệ phần trăm của các sự kiện đòi hỏi sự tương
tác của con người và liệu điều này đã đã xảy ra hay chưa,
 Số lượng và tỷ lệ phần trăm của các sự kiện dẫn đến các sự cố
hoặc thay đổi,
 Số lượng và tỷ lệ phần trăm của các sự kiện gây ra bởi các vấn
đề hoặc Lỗi Đã biết hiện tại. Điều này có thể dẫn đến một thay
đổi trong ưu tiên của công việc trên vấn đề hoặc Lỗi Đã biết
đó,
 Số lượng và tỷ lệ phần trăm của các sự kiện lặp lại hoặc trùng
hợp. Điều này sẽ giúp điều chỉnh Bộ máy Tương quan để loại
bỏ việc tạo ra các sự kiện không cần thiết và cũng có thể được
sử dụng để hỗ trợ cho việc thiết kế chức năng tạo ra sự kiện
tốt hơn trong các dịch vụ mới.
 Số lượng và tỷ lệ phần trăm của các sự kiện đang chỉ ra các
vấn đề về hiệu suất (ví dụ, sự gia tăng trong số lần mà một
ứng dụng vượt quá ngưỡng giao dịch của nó trong vòng 6
tháng qua),
 Số lượng và tỷ lệ phần trăm của các sự kiện chỉ ra những vấn
đề tiềm ẩn về tính sẵn sàng (ví dụ, chuyển đổi dự phòng sang
các thiết bị thay thế, hoặc hoán đổi khối lượng công việc vượt
quá mức giới hạn),
 Số lượng và tỷ lệ phần trăm của từng kiểu sự kiện trên từng
nền tàng hoặc ứng dụng,
 Số lượng và tỷ lệ các sự kiện được so sánh với số lượng các sự
cố.
4.1.8 N hững thách th ức, Y ếu t ố Thành công Q uan

trọng và r ủi ro
4.1.8. 1 N hững thách th ức

Có một số thách thức có thể gặp phải như sau:
 Một thách thức ban đầu có thể là có được nguồn vốn tài trợ
cho các công cụ và nỗ lực cần thiết để cài đặt và khai thác các
lợi ích của các công cụ.
 Một trong những thách thức lớn nhất là việc thiết lập mức lọc
chính xác. Việc thiết lập mức lọc không chính xác có thể dẫn
đến việc bị ngập tràn trong các sự kiện tương đối không quan
trọng hoặc không thể phát hiện các sự kiện tương đối quan
trọng cho đến khi quá muộn.
 Ra mắt các tác nhân giám sát cần thiết trên toàn bộ cơ sở hạ
tầng CNTT có thể là một hoạt động khó khăn và tiêu tốn thời
gian, đòi hỏi một cam kết liên tục trong một khoảng thời gian
khá dài - có nguy cơ làm phát sinh các hoạt động khác có thể
làm chuyển hướng tài nguyên và trì hoãn việc triển khai.
 Việc có được các kỹ năng cần thiết có thể tiêu tốn nhiều thời
gian và chi phí.
4.1.8. 2 Các Y ếu t ố T hành công Q uan tr ọng
Để đạt được nguồn tài trợ vốn cần thiết, một Đề án Kinh doanh
thuyết phục nên được chuẩn bị để cho thấy cách mà những lợi ích
của Quản lý Sự kiện hiệu quả có thể vượt qua chi phí – mang lại lợi
nhuận trên khoản đầu tư tích cực.
Một trong những CSF quan trọng nhất là đạt được mức độ lọc chính
xác. Đây là một công việc phức tạp bởi thực tế là tầm quan trọng
của các sự kiện sẽ thay đổi. Ví dụ, một người dùng đang đăng nhập
vào một hệ thống hôm nay là bình thường nhưng nếu người dùng đó
rời khỏi tổ chức và cố gắng đăng nhập lại vào hệ thống đó là một vi
phạm bảo mật.
Có ba điều then chốt đối với mức độ lọc chính xác, như được trình
bày dưới đây:
 Tích hợp Quản lý Sự kiện vào mọi quy trình Quản lý Dịch vụ,
nếu khả thi. Điều này sẽ đảm bảo rằng chỉ có những sự kiện
quan trọng đối với các quy trình đó sẽ được báo cáo.
 Thiết kế các dịch vụ mới với sự lưu tâm về Quản lý Sự kiện
(điều này được thảo luận chi tiết trong đoạn 4.1.10).
 Thử nghiệm và sai. Bất kể Quản lý Sự kiện đã được chuẩn bị
một cách kỹ lưỡng như thế nào, sẽ luôn có các lớp sự kiện
không được lọc một cách đúng đắn. Do đó, Quản lý Sự kiện
phải bao gồm một quy trình chính thức để đánh giá tính hiệu
quả của việc lọc.
Việc hoạch định đúng đắn là điều cần thiết để triển khai phần mềm
tác nhân giám sát trong toàn b ộ cơ sở hạ tầng CNTT. Đây nên được
coi là một dự án với khung thời gian thực tế và nguồn lực đầy đủ
được phân bổ và bảo vệ trong toàn bộ thời lượng của dự án.
4.1.8. 3 R ủi ro
Rủi ro chủ yếu thực sự là những gì đã được đề cập ở trên: thất bại
trong việc có được nguồn tài trợ vốn đầy đủ, đảm bảo mức lọc chính
các, và thất bại trong việc duy trì động lực trong việc triển khai các
tác nhân giám sát cần thiết trong toàn bộ cơ sở hạ tầng CNTT. Nếu
bất kỳ rủi ro nào trong số này không được giải quyết, nó có thể sẽ
ảnh hưởng bất lợi đến sự thành công của Quản lý Sự kiện.
4.1.9 Thiết k ế đối v ớ i Q u ả n lý S ự k iện

Quản lý Sự kiện hiệu quả không được thiết kế chỉ khi một dịch vụ đã
được triển khai thành Vận hành. Vì Quản lý Sự kiện là cơ sở cho việc
giám sát hiệu suất và tính sẵn sàng của một dịch vụ, những đích
nhắm mục tiêu chính xác và các cơ chế giám sát nên được định rõ và
được thống nhất trong các quy trình Quản lý Công suất và Quản lý
Tính sẵn sàng (xem ấn phẩm Thiết kế Dịch vụ).
Tuy nhiên, điều này không có nghĩa là Qu ản lý Sự kiện được thiết kế

bởi một nhóm các nhà phát triển hệ thống từ xa và sau đó được phát
hành cho Quản lý Vận hành cùng với hệ thống phải được giám sát.
Hoặc nó không có nghĩa rằng, khi đã được thiết kế và thống nhất,
Quản lý Sự kiện trở nên tĩnh – hoạt động hàng ngày sẽ xác định các
sự kiện bổ sung, các mối ưu tiên, các cảnh báo và các cải tiến khác
sẽ cung cấp thông qua quy trình Liên t ục Cải tiến trở lại Chiến lược
Dịch vụ, Thiết kế Dịch vụ, v.v…
Các chức năng Vận hành Dịch vụ sẽ được kỳ vọng tham gia vào quá
trình thiết kế dịch vụ và cách thức nó được đo lường như thế nào
(xem phần 3.4).
Đối với Quản lý Sự kiện, các lĩnh vực thiết kế cụ thể bao gồm như
dưới đây.
4.1.9. 1 Công c ụ Đo đ ạ c
Công cụ đo đạc là định nghĩa về những gì có thể được giám sát về
các CI và cách thức mà theo đó, hành vi của chúng có thể bị ảnh
hưởng. Nói cách khác, công cụ đo đạc là về việc xác định và thiết kế
chính xác cách thức để giám sát và kiểm soát Cơ sở hạ tầng CNTT và
các dịch vụ CNTT như thế nào.
Công cụ đo đạc một phần là về một tập hợp các quyết định cần phải
được đưa ra và một phần là việc thiết kế các cơ chế để thực thi các
quyết định này.
Các quyết định cần được đưa ra bao gồm:
 Những gì cần được giám sát?

 Kiểu giám sát nào được yêu cầu (ví dụ, chủ động hay thụ động;
hiệu suất hoặc đầu ra)?
 Khi nào thì chúng ta cần tạo một sự kiện?
 Loại thông tin nào cần được truyền đạt trong sự kiện?
 Thông điệp dành cho ai?
Các cơ chế cần được thiết kế bao gồm:
 Các sự kiện sẽ được tạo ra như thế nào?

 CI đã có các cơ chế tạo sự kiện như một tính năng tiêu chuẩn
chưa và nếu có, thì cơ chế nào trong số này sẽ được sử dụng?
Chúng có đầy đủ không hay CI cần được tùy chỉnh để bao gồm
các cơ chế hoặc thông tin bổ sung?
 Dữ liệu nào sẽ được sử dụng để điền vào Bản ghi Sự kiện?
 Các sự kiện được tạo tự động hay CI phải được thẩm tra?
 Các sự kiện sẽ được ghi lại và lưu trữ ở đâu?
 Dữ liệu bổ sung sẽ được thu thập như thế nào?
Lưu ý: Một ương tác mạnh mẽ tồn tại ở đây cùng với thiết kế của
ứng dụng. Mọi ứng dụng phải được mã hóa theo cách sao cho các
thông báo/mã lỗi có ý nghĩa và chi tiết được tạo ra tại điểm chính
xác của lỗi - để từ đó chúng có thể được đưa vào sự kiện và cho
phép chẩn đoán và giải quyết nhanh chóng nguyên nhân cơ b ản. Sự
cần thiết phải bao gồm và kiểm tra thông báo lỗi như vậy được đề
cập chi tiết hơn trong ấn phẩm Chuyển đổi dịch vụ.
4.1.9. 2 Thông đi ệp lỗ i
Thông điệp lỗi là điều quan trọng đối với mọi thành phần (phần
cứng, phần mềm, mạng, v.v…), Một điều đặc biệt quan trọng là tất
cả các ứng dụng phần mềm được thiết kế để hỗ trợ cho Quản lý Sự
kiện. Điều này có thể bao gồm việc cung cấp các thông điệp và mã
lỗi có ý nghĩa để chỉ ra điểm lỗi một cách rõ ràng và nguyên nhân
khả dĩ nhất. Trong những trường hợp đó, việc kiểm nghiệm những
ứng dụng mới nên bao gồm các việc kiểm nghiệm việc tạo ra sự kiện
chính xác.
Những công nghệ mới hơn như Java Management Extension (JMX)
hoặc HawkNL™ cung cấp các công cụ để xây dựng các giải pháp
phân tán, dựa trên web, theo mô-đun và động để quản lý và giám
sát các thiết bị, ứng dụng và mạng định hướng-dịch vụ. Chúng có
thể được sử dụng để giảm thiểu hoặc loại bỏ nhu cầu đối với các lập
trình viên để bao gồm các thông điệp lỗi trong mã phần mềm – cho
phép mức độ chuẩn hóa và mã-độc lập có giá trị.
4.1.9. 3 N hậ n d ạ ng S ự k iện và các Cơ ch ế C ả nh báo
Một thiết kế Quản lý Sự kiện tốt cũng sẽ bao gồm thiết kế và tập
hợp các công cụ được sử dụng để lọc, tương quan và leo thang các
Sự kiện.
Bộ máy Tương quan đặc biệt sẽ cần phải được phổ biến với các quy
tắc và tiêu chí sẽ xác định tầm quan trọng và hành động tiếp theo
sau đối với từng kiểu sự kiện.
Việc thiết kế kỹ lưỡng các cơ chế nhận dạng và cảnh báo sự kiện đòi
hỏi những điều sau đây:
 Kiến thức nghiệp vụ trong mối quan hệ với bất kỳ quy trình
nghiệp vụ nào đang được quản lý thông qua Quản lý Sự kiện.
 Kiến thức chi tiết về các Yêu cầu Mức Dịch vụ của dịch vụ đang
được hỗ trợ bởi từng Đơn vị Cấu hình.
 Kiến thức về những ai sẽ hỗ trợ cho Đơn vị Cấu hình.
 Kiến thức về những gì cấu thành nên hoạt động bình thường và
bất bình thường của Đơn vị Cấu hình.
 Kiến thức về tầm quan trọng của nhiều sự kiện tương tự nhau
(trên cùng một Đơn vị Cấu hình hoặc nhiều Đơn vị Cấu hình
tương tự).
 Một hiểu biết về những gì họ cần biết để hỗ trợ cho Đơn vị Cấu
hình một cách hiệu quả.
 Thông tin có thể giúp chẩn đoán các vấn đề với Đơn vị Cấu
hình.
 Hiểu rõ các mã phân loại và mã ưu tiên sự cố để nếu cần thiết
phải tạo ra Hồ sơ Sự cố, các mã này có thể được cung cấp.
 Kiến thức về các Đơn vị Cấu hình khác có thể phụ thuộc vào
Đơn vị Cấu hình bị ảnh hưởng, hoặc những Đơn vị Cấu hình mà
nó phụ thuộc vào
 Tính sẵn sàng của Lỗi Đã biết từ các nhà cung cấp hoặc từ kinh
nghiệm trước đó.
4.1.9. 4 Xác đ ị nh các ngư ỡ ng

Bản thân các ngưỡng không được thiết lập và quản lý thông qua
Quản lý Sự kiện. Tuy nhiên, trừ khi chúng được thiết kế và truyền
đạt một cách đúng đắn trong các quy trình đo đạc, sẽ rất khó để xác
định mức độ nào của hiệu suất là thích hợp cho từng Đơn vị Cấu
hình.
Ngoài ra, hầu hết các ngưỡng đều không phải là hằng số. Chúng
thường bao gồm một lượng các biến số có liên quan. Ví dụ, số lượng
tối đa những người dùng đồng thời trước khi thời gian hồi đáp bị
chậm lại sẽ khác nhau tùy thuộc vào những tác vụ khác đang hoạt
động trên máy chủ. Kiến thức này thường chỉ có được bởi kinh
nghiệm, vốn có nghĩa rằng Bộ máy Tương quan sẽ phải được điều
chỉnh và cập nhật liên tục thông qua quy trình Liên t ục Cải tiến Dịch
vụ.
4.2 Quản lý sự cố
Theo thuật ngữ chuyên ngành của ITIL, một ‘sự cố’ được định nghĩa là:
Một sự gián đoạn không được lên kế hoạch đối với một dịch vụ CNTT hoặc sự sụt
giảm trong chất lượng của một dịch vụ CNTT. Lỗi của một đơn vị cấu hình vẫn
chưa gây ảnh hưởng đến dịch vụ cũng là một sự cố, ví dụ, lỗi của một đĩa từ một
bộ đĩa được phản chiếu.
Quản lý Sự cố là quy trình xử lý mọi sự cố, có thể bao gồm các lỗi, các nghi ngờ
hoặc truy truy vấn từ phía người dùng (thường qua một cuộc điện thoại gọi đến
Bộ phận Hỗ trợ Dịch vụ), bởi nhân viên kỹ thuật, hoặc được phát hiện và báo cáo
một cách tự động bởi các công cụ giám sát sự kiện.

Mục đích chủ yếu của quy trình Quản lý Sự cố là để khôi phục mức
hoạt động dịch vụ như bình thường càng sớm càng tốt đồng thời tối
thiểu tác động bất lợi lên hoạt động kinh doanh, từ đó, đảm bảo
rằng các mức khả dĩ tốt nhất của chất lượng và tính sẵn sàng dịch
vụ được duy trì. ‘Hoạt động dịch vụ như bình thường’ ở đây được
xác định là hoạt động dịch vụ trong phạm vi các giới hạn của SLA.
4.2.2 Phạ m vi
Quản lý Sự cố bao gồm bất kỳ sự kiện nào gây ra gián đoạn, hoặc có
thể gây ra gián đoạn cho một dịch vụ. Nó bao gồm các sự kiện được
truyền đạt trực tiếp bởi người dùng, hoặc thông qua Bộ phận Hỗ trợ
Dịch vụ hoặc thông qua một tương tác từ các công cụ Quản lý Sự
kiện đến Quản lý Sự cố.
Các sự cố cũng có thể được báo cáo và/hoặc ghi nhật ký bởi nhân
viên kỹ thuật (ví dụ, nếu họ nhận thấy điều gì đó không ổn với
phần cứng hoặc thành phần mạng, họ có thể báo cáo hoặc ghi nhật
ký lại sự cố và chuyển nó đến Bộ phận Dịch vụ). Điều này không có
nghĩa là tất cả các sự kiện đều là sự cố. Rất nhiều lớp sự kiện hoàn
toàn không liên quan đến gián đoạn, nhưng là các chỉ báo của hoạt
động bình thường hoặc chỉ đơn giản là cung cấp thêm thông tin
(xem phần 4.1).
Mặc dù cả sự cố và yêu cầu dịch vụ đều được báo cáo cho Bộ phận
Hỗ trợ Dịch vụ, nhưng điều này không có nghĩa là chúng sẽ giống
nhau. Yêu cầu dịch vụ không thể hiện sự gián đoạn đối với dịch vụ
đã được thỏa thuận, nhưng là cách để đáp ứng nhu cầu của khách
hàng và có thể giải quyết đích nhắm mục tiêu đã được thỏa thuận
trong SLA. Các yêu cầu dịch vụ được xử lý bằng quy trình Thực hiện
Yêu cầu (xem phần 4.3).
4.2.3 Giá tr ị đối v ớ i doan h nghi ệp

Giá trị của Quản lý Sự kiện bao gồm:
 Khả năng phát hiện và giải quyết các sự cố dẫn đến thời gian
ngừng hoạt động của doanh nghiệp thấp hơn, vốn có nghĩa là
tính sẵn sàng của dịch vụ cao hơn. Điều này có nghĩa là doanh
nghiệp có thể khai thác các chức năng của dịch vụ như đã được
thiết kế.
 Khả năng liên kết hoạt động CNTT với các ưu tiên kinh doanh
trong thời gian thực. Điều này là bởi vì Quản lý Sự cố bao gồm
năng lực xác định các ưu tiên kinh doanh và phân b ổ động các
nguồn lực khi cần thiết.
 Khả năng xác định những cải tiến tiềm năng đối với dịch vụ.
Điều này xảy ra do kết quả của việc hiểu được điều gì gây nên
sự cố và cũng do tiếp xúc với các hoạt động của nhân viên vận
hành nghiệp vụ.
 Bộ phận Hỗ trợ Dịch vụ có thể, trong quá trình xử lý các sự cố
của mình, xác định các yêu cầu dịch vụ hoặc yêu cầu đào tạo
bổ sung được phát hiện trong CNTT hoặc doanh nghiệp.
Quản lý Sự cố rất dễ thấy đối với doanh nghiệp và do đó, việc chứng
minh giá trị của nó dễ dàng hơn so với hầu hết các lĩnh vực khác
trong Vận hành Dịch vụ. Vì lý do này, Quản lý Sự cố thường là một
trong những quy trình đầu tiên được triển khai trong các dự án Quản
lý Dịch vụ. Lợi ích bổ sung của việc làm này là Quản lý Sự cố có thể
được sử dụng để làm nổi bật các lĩnh vực khác cần được chú ý - do
đó cung cấp sự biện minh của việc chi tiêu cho việc triển khai các
quy trình khác.

Có một số điều cơ bản cần được tính đến và được quyết định trong
khi cân nhắc về Quản lý Sự cố. Chúng sẽ được đề cập trong phần
này.
4.2.4. 1 Khung th ờ i g i a n
Khung thời gian phải được thỏa thuận cho mọi giai đoạn xử lý-sự cố
(incident handling) (chúng sẽ khác nhau tùy thuộc vào mức độ ưu
tiên của sự cố) – dựa trên các đích nhắm mục tiêu giải pháp và ứng
phó sự cố trong phạm vi các SLA – và được nắm bắt như là các đích
nhắm mục tiêu trong phạm vi các OLA và Hợp đồng Cơ sở
(Underpinning Contracts - UCs). Tất cả các nhóm hỗ trợ nên được
nhận thức hoàn toàn về các khung thời gian này. Các công cụ Quản
lý Dịch vụ nên được sử dụng để tự động hóa các khung thời gian và
leo thang sự cố khi cần thiết dựa trên các quy tắc đã được xác định
trước.
4.2.4. 2 Các mô hình S ự c ố

Rất nhiều sự cố không hề mới – chúng liên quan đến việc xử lý một
số điều đã thực sự xảy ra trước và cũng có thể sẽ tái diễn. Vì lý do
này, rất nhiều tổ chức sẽ thấy hữu ích khi xác định trước các Mô
hình Sự cố ‘tiêu chuẩn’ – và áp dụng chúng cho các sự cố thích hợp
khi các sự cố này xảy ra.
Một Mô hình Sự cố là một cách thức về việc xác định trước các bước
nên được thực hiện để xử lý một quy trình (trong trường hợp này, là
một quy trình xử lý một kiểu sự cố cụ thể) theo một cách đã được
thỏa thuận. Các công cụ hỗ trợ sau đó có thể được sử dụng để quản
lý quy trình cần thiết. Điều này sẽ đảm bảo rằng các sự cố ‘tiêu
chuẩn’ được xử lý theo một lộ tuyến và khung thời gian đã được xác
định trước.
Các sự cố đòi hỏi phải được xử lý chuyên biệt có thể được xử lý theo
cách này (ví dụ, các sự cố liên quan đến bảo mật có thể được
chuyển đến Quản lý Bảo mật Thông tin và các sự cố liên quan đến
công suất - hoặc hiệu suất – sẽ được chuyển đến Quản lý Công suất.
Mô hình Sự cố nên bao gồm:
 Các bước nên được thực hiện để xử lý sự cố,

 Trình tự thời gian của các bước này nên được thực hiện, với
bất kỳ phụ thuộc hoặc đồng xử lý nào nên được xác định,
 Trách nhiệm, ai nên làm gì,
 Khung thời gian và các ngưỡng hoàn thành các hành động,
 Các thủ tục leo thang, ai nên được liên hệ và khi nào,
 Bất kỳ hoạt động bảo quản-bằng chứng cần thiết nào (đặc biệt
là các sự cố liên quan đến bảo mật – và công suất.
Các mô hình nên được đưa vào trong các công cụ hỗ trợ xử lý sự cố
đang sử dụng và các công cụ nên tự động hóa xử lý, quản lý và leo
thang quy trình.
4.2.4. 3 Các s ự c ố ng hiêm tr ọ ng

Một thủ tục riêng biệt, với khung thời gian ngắn hơn và mức độ khẩn
cấp cao hơn phải được sử dụng cho các sự cố ‘nghiêm trọng’. Một
định nghĩa về những gì cấu thành nên sự cố nghiêm trọng phải được
thống nhất và lý tưởng nhất, được ánh xạ với hệ thống ưu tiên sự cố
tổng thể - như vậy, chúng sẽ được xử lý thông qua quy trình sự cố
nghiêm trọng.
Lưu ý: Đôi khi, mọi người sử dụng thuật ngữ lỏng lẻo và/hoặc nhầm
lẫn một sự cố lớn với một vấn đề. Trong thực tế, một sự cố vẫn mãi
mãi là một sự cố - nó có thể phát triển về mức độ ảnh hưởng hoặc
độ ưu tiên để trở thành một sự cố nghiêm trọng, nhưng một sự cố
không bao giờ 'trở thành' vấn đề. Một vấn đề là nguyên nhân cơ bản
của một hoặc nhiều sự cố và luôn luôn là một thực thể riêng biệt!
Một số sự cố có mức độ ưu tiên thấp hơn cũng có thể phải được xử

lý thông qua thủ tục này - do tác động kinh doanh tiềm ẩn - và một
số sự cố nghiêm trọng cũng có thể không cần phải được xử lý theo
cách này nếu nguyên nhân và cách giải quyết rõ ràng và quy trình
sự cố thông thường có thể dễ dàng đối phó trong thời gian giải
quyết được nhắm mục tiêu đã thỏa thuận - với điều kiện tác động
vẫn ở mức thấp!
Khi cần thiết, thủ tục sự cố nghiêm trọng nên bao gồm việc thiết lập
động một nhóm sự cố lớn riêng biệt dưới sự lãnh đạo trực tiếp của
Nhà quản lý Sự cố, được hình thành để tập trung vào một mình sự
cố này để đảm bảo rằng đầy đủ nguồn lực và sự tập trung được
cung cấp để tìm ra một giải pháp nhanh chóng. Nếu Nhà quản lý Bộ
phận Hỗ trợ Dịch vụ đồng thời đóng vai trò Nhà quản lý Sự cố (ví dụ
như trong một tổ chức nhỏ) thì một cá nhân riêng biệt có thể cần
phải được chỉ định để lãnh đạo nhóm điều tra sự cố lớn – để tránh
những xung đột về thời gian hoặc các ưu tiên khác – nhưng cuối
cùng nên báo cáo lại cho Nhà quản lý Sự cố.
Nếu như nguyên nhân của sự cố cần phải được điều tra thêm tại
cùng thời điểm thì Nhà quản lý Vấn đề sẽ tham gia nhưng Nhà quản
lý Sự cố phải đảm bảo rằng sự khôi phục dịch vụ và nguyên nhân cơ
bản được lưu giữ riêng biệt. Xuyên suốt, Bộ phận Hỗ trợ Dịch vụ sẽ
đảm bảo rằng tất cả mọi hoạt động được ghi nhận lại và người dùng
được thông báo về tiến trình.

quy trì nh
Quy trình cần phải được tuân theo trong quá trình qu ản lý một sự cố
được minh họa trong hình 4.2. Quy trình này bao g ồm những bước
sau đây:
Hình 4.2 – Quy trình Quản lý Sự cố
4.2.5. 1 N hậ n d ạ ng s ự c ố
Công việc giải quyết một sự cố không thể bắt đầu cho đến khi biết
rằng một sự cố đã xảy ra. Từ góc độ kinh doanh, việc chờ đợi cho
đến khi người dùng bị ảnh hưởng và liên hệ với Bộ phận Hỗ trợ Dịch
vụ thường là không thể chấp nhận được. Trong chừng mực có thể,
tất cả các thành phần then chốt cần phải được giám sát để phát hiện
sớm các lỗi hoặc các hư hỏng tiềm ẩn để quá trình Quản lý Sự cố có
thể được bắt đầu một cách nhanh chóng. Lý tưởng nhất, các sự cố
nên được giải quyết trước khi chúng có tác động đến người dùng!
Vui lòng xem phần 4.1 để biết thêm chi tiết.
4.2.5. 2 Ghi nh ậ t ký s ự c ố
Tất cả các sự cố phải được ghi nhật ký lại đầy đủ và đóng dấu
ngày/giờ, bất kể chúng được nêu ra thông qua một cuộc điện thoại
đến Bộ phận Hỗ trợ Dịch vụ hay được phát hiện một cách tự động
thông qua một cảnh báo sự kiện.
Lưu ý: Nếu Bộ phận Hỗ trợ Dịch vụ và/hoặc nhân viên hỗ trợ đến
thăm khách hàng để giải quyết một sự cố, họ có thể được yêu cầu
giải quyết các sự cố khác 'trong khi họ ở đó'. Điều quan trọng là nếu
điều này được thực hiện, một Hồ sơ Sự cố riêng biệt sẽ được ghi
nhận lại cho từng sự cố bổ sung được xử lý - để đảm bảo rằng một
hồ sơ lịch sử được lưu giữ và công nhận cho công việc đã thực hiện.
Mọi thông tin liên quan liên quan đ ến bản chất của sự cố phải được
ghi nhận lại để lưu giữ hồ sơ lịch sử đầy đủ - và để nếu sự cố phải
được chuyển đến (các) nhóm hỗ trợ khác, họ sẽ có tất cả những
thông tin liên quan để hỗ trợ cho họ.
Thông tin cần thiết cho từng sự cố có thể bao gồm:
 Mã số tham chiếu duy nhất,

 Phân loại sự cố (thường được chia thành từ hai đến bốn cấp
thể loại phụ),
 Tính khẩn cấp của sự cố,
 Tác động của sự cố,
 Độ ưu tiên của sự cố,
 Ngày/giờ mà sự cố được ghi lại,
 Tên/mã định danh (ID) của người và/hoặc nhóm ghi lại sự việc,
 Phương thức thông báo (điện thoại, tự động, e-mail, trực tiếp,
v.v...),
 Tên/phòng ban/điện thoại/vị trí của người dùng,
 Phương thức gọi lại (điện thoại, gửi thư, v.v…),
 Mô tả các triệu chứng,
 Trạng thái của sự cố (đang hoạt động, đang chờ, đã đóng,
v.v…),
 Đơn vị cấu hình liên quan,
 Nhóm/người hỗ trợ mà sự cố được phân bổ,
 Sự cố liên quan/Lỗi Đã biết,
 Các hoạt động đã được thực hiện để giải quyết sự cố,
 Ngày giờ giải quyết,
 Thể loại kết thúc,
 Ngày giờ kết thúc.
Lưu ý: Nếu Bộ phận Hỗ trợ Dịch vụ không hoạt động 24/7 và trách
nhiệm ghi nhận nhật ký và xử lý sự cố tuyến đầu tiên được chuyển
cho một nhóm khác, như Vận hành CNTT hoặc Hỗ trợ Mạng, nằm
ngoài Giờ Dịch vụ, những nhân viên thuộc các bộ phận này cũng cần
nghiêm túc tương tự trong việc ghi nhận nhật ký chi tiết của sự cố.
Đào tạo và nâng cao nhận thức đầy đủ cần được thực hiện cho
những nhân viên về vấn đề này.
4.2.5. 3 Phân l o ạ i s ự c ố
Một phần của việc ghi nhận nhật ký ban đầu phải là phân bổ mã
phân loại sự cố phù hợp để thể loại chính xác của cuộc gọi được ghi
lại. Điều này sẽ rất quan trọng sau này khi xem xét các kiểu/tần
suất của sự cố để xác lập các xu hướng sử dụng trong Quản lý Vấn
đề, Quản lý Nhà cung cấp và các hoạt động ITSM khác.
Hãy lưu ý rằng việc kiểm tra Yêu cầu Dịch vụ trong quy trình này
không có nghĩa rằng các Yêu cầu Dịch vụ là những sự cố. Điều này
chỉ đơn giản là thừa nhận một thực tế là các Yêu cầu Dịch vụ đôi khi
được ghi nhận một cách không chính xác dưới dạng sự cố (ví dụ,
một người dùng nhập sai yêu cầu là một sự cố từ giao diện web).
Việc kiểm tra này sẽ phát hiện bất kỳ yêu cầu nào như vậy và đảm
bảo rằng chúng được chuyển đến quy trình Thực hiện Yêu cầu.
Phân loại đa-cấp độ đều có sẵn trong hầu hết các công cụ - thường
là ba hoặc bốn cấp độ chi tiết. Ví dụ, một sự cố có thể được phân
loại như trong Hình 4.3.
Hình 4.3 – Phân loại sự cố đa cấp độ
Tất cả các tổ chức đều có nét độc đáo riêng và do đó, sẽ rất khó để
đưa ra một hướng dẫn chung về các thể loại mà một tổ chức nên sử
dụng, đặc biệt là ở các cấp độ thấp hơn. Tuy nhiên, có một kỹ thuật
có thể được sử dụng để giúp cho một tổ chức có được một tập hợp
các thể loại chính xác và hoàn chỉnh – nếu như họ bắt đầu từ vạch
xuất phát! Các bước này bao gồm:
1. Tổ chức một phiên động não giữa các nhóm hỗ trợ có liên
quan, với sự tham gia của Giám sát viên Thiết kế Dịch vụ và
các Nhà quản lý Vấn đề.
2. Sử dụng phiên [động não] này để quyết định ‘phỏng đoán tốt
nhất’ về danh mục thể loại cấp cao nhất – và bao gồm một thể
loại ‘khác’. Thiết lập các công cụ ghi nhật ký có liên quan để
sử dụng các thể loại này trong một khoảng thời gian thử
nghiệm.
3. Sử dụng các thể loại trong một khoảng thời gian thử nghiệm
ngắn (đủ dài để có thể có được vài trăm sự cố cho từng thể
loại, nhưng không quá dài để một phân tích sẽ tốn nhiều thời
gian để thực hiện).
4. Tiến hành một quá trình phân tích về các sự cố được ghi lại
trong khoản thời gian thử nghiệm. Số lượng sự cố được ghi lại
trong từng thể loại cấp cao hơn sẽ xác nhận xem các thể loại
đó có đáng có hay không - và một phân tích chi tiết hơn về
danh mục ‘khác’ sẽ cho phép xác định bất kỳ danh mục cấp cao
hơn bổ sung nào cần thiết.
5. Phân tích sự cố trong mỗi hạng mục cấp cao hơn nên được sử
dụng để quyết định các hạng mục cấp thấp hơn sẽ được yêu
cầu.
6. Xem xét và lặp lại các hoạt động này sau một khoảng thời gian
nữa - ví dụ, từ một đến ba tháng - và thường xuyên lặp lại để
đảm bảo rằng chúng vẫn phù hợp. Lưu ý rằng bất kỳ thay đổi
quan trọng nào đối với việc phân loại có thể gây ra một số khó
khăn cho xu hướng sự cố hoặc báo cáo quản lý - vì vậy chúng
phải được ổn định trừ khi thực sự cần có những thay đổi
Nếu như một lược đồ phân loại hiện hữu đang được sử dụng, nhưng
được cho là không hoạt động tốt, ý tưởng cơ bản của kỹ thuật cơ
bản được đề nghị ở trên có thể được sử dụng để xem xét và điều
chỉnh luợc đồ hiện hữu.
LƯU Ý: Đôi khi các chi tiết sẵn có tại thời điểm một sự cố được ghi
nhận có thể không hoàn chỉnh, sai lệch hoặc không chính xác. Do
đó, điều quan trọng là sự phân loại sự cố được kiểm tra và cập nhật
nếu cần thiết vào thời điểm đóng cuộc gọi (trong một trường phân
loại đóng riêng biệt, để không làm hư hỏng phân loại gốc) – vui lòng
xem đoạn 4.2.5.9.
4.2.5. 4 Thiết l ậ p độ ưu tiê n c ủa s ự c ố

Một khía cạnh quan trọng khác của việc ghi nhật ký mọi sự cố là để
thống nhất và phân bổ một mã ưu tiên thích hợp – vì điều này sẽ
giúp xác định cách thức mà các sự cố được xử lý như thế nào bởi cả
các công cụ hỗ trợ và nhân viên hỗ trợ.
Độ ưu tiên thường có thể được xác định bằng cách tính đến cả tính
khẩn cấp của sự cố (doanh nghiệp cần một giải pháp nhanh đến mức
nào) và mức độ tác động mà nó [sự cố] gây ra. Một chỉ báo của sự
tác động thường (nhưng không phải luôn luôn) là số lượng người
dùng bị ảnh hưởng. Trong một số trường hợp, và rất quan trọng,
mất dịch vụ đối với một người dùng duy nhất có thể có một tác động
kinh doanh nghiêm trọng – tất cả tùy thuộc vào việc ai đang cố gắng
thực hiện điều gì – do đó, chỉ một mình các con số là không đủ để
đánh giá độ ưu tiên tổng thể! Các yếu tố khác có thể đóng góp vào
các mức độ tác động là:
 Rủi ro đến tính mạng hoặc tay chân,

 Số lượng các dịch vụ bị ảnh hưởng – có thể là nhiều dịch vụ,
 Mức độ tổn thất về mặt tài chính,
 Ảnh hưởng đến danh tiếng của doanh nghiệp,
 Mức độ vi phạm pháp luật hoặc quy định.
Một cách hiệu quả để tính toán các phần tử này và có được mức ưu
tiên tổng thể của từng sự cố được đưa ra trong Bảng 4.1.
Tác động
Cao Trung bình Thấp
Cao 1 2 3
Độ khẩn cấp Trung bình 2 3 4
Thấp 3 4 5
Mã ưu tiên Mô tả Thời gian giải pháp nhắm mục tiêu
1 Nghiêm trọng 1 giờ
2 Cao 8 giờ
3 Trung bình 24 giờ
4 Thấp 48 giờ
5 Lập kế hoạch Đã được lập kế hoạch
Bảng 4.1 – Hệ thống mã ưu tiên đơn giản
Trong mọi trường hợp, sự hướng dẫn rõ ràng - với các ví dụ thực tế
- nên được cung cấp cho tất cả các nhân viên hỗ trợ để giúp họ xác
định chính xác mức độ khẩn cấp và tác động, do đó, mức độ ưu tiên
chính xác được phân bổ. Hướng dẫn như vậy nên được đưa ra trong
quá trình đàm phán về mức dịch vụ.
Tuy nhiên, cần phải lưu ý rằng sẽ có những trường hợp khi, vì lý do
kinh doanh đặc biệt hoặc bất cứ điều gì, mức độ ưu tiên thông
thường phải được ghi đè. Khi người dùng kiên quyết rằng mức độ ưu
tiên của sự cố phải vượt quá các nguyên tắc thông thường, Bộ phận
dịch vụ nên tuân thủ yêu cầu đó - và nếu sau đó yêu cầu đó không
chính xác, điều này có thể được giải quyết dưới dạng vấn đề ở cấp
quản lý ngoại tuyến (offline), thay vì tranh chấp xảy ra khi người
dùng đang sử dụng điện thoại (hàm ý chỉ sự tranh cãi khi người
dùng đang gọi điện để báo về sự cố).
Một số tổ chức cũng có thể công nhận các nhân vật quan trọng - VIP
(giám đốc điều hành cấp cao, sĩ quan, nhà ngoại giao, chính trị gia,
v.v...) mà sự cố của họ sẽ được xử lý ở mức độ ưu tiên cao hơn bình
thường - nhưng trong những trường hợp này, điều này được thực
hiện tốt nhất và được ghi lại theo hướng dẫn đã được cung cấp cho
nhân viên của Bộ phận Hỗ trợ Dịch vụ về cách thức áp dụng các mức
độ ưu tiên, vì vậy tất cả họ đều nhận thức về các quy tắc đã được
thỏa thuận dành cho khách VIP và nh ững ai thuộc đối tượng này.
Nên lưu ý rằng mức độ ưu tiên của sự cố có thể là động - nếu hoàn
cảnh thay đổi hoặc nếu một sự cố không được giải quyết trong phạm
vi đích nhắm thời gian SLA, thì mức độ ưu tiên phải được thay đổi
để phản ánh tình huống mới.
4.2.5. 5 C hẩ n đoán ban đ ầ u

Nếu sự cố đã được chuyển đến thông qua Bộ phận Hỗ trợ Dịch vụ,
Chuyên gia phân tích Hỗ trợ Dịch vụ phải tiến hành một chẩn đoán
ban đầu, thường là trong khi người dùng vẫn đang còn trong cuộc
gọi – nếu như cuộc gọi hỗ trợ phát sinh theo cách này – để cố gắng
khám phá những triệu chứng đầy đủ của sự cố và để xác định một
cách chính xác những gì bị sai và cách để khắc phục nó như thế nào.
Đây là giai đoạn mà tập lệnh chẩn đoán và thông tin về lỗi đã biết
có thể có giá trị nhất trong việc hỗ trợ chẩn đoán chính xác và sớm
hơn.
Nếu có thể, Chuyên gia phân tích Hỗ trợ Dịch vụ sẽ giải quyết sự cố
trong khi người dùng vẫn đang còn trong cuộc gọi – và đóng sự cố
nếu giải pháp thành công.
Nếu như Chuyên gia phân tích Hỗ trợ Dịch vụ không thể giải quyết
sự cố trong khi người dùng vẫn đang còn trong cuộc gọi nhưng có
triển vọng rằng Bộ phận Hỗ trợ Dịch vụ có thể có khả năng làm điều
đó trong giới hạn thời gian đã được thỏa thuận mà không cần sự trợ
giúp từ các nhóm hỗ trợ khác, Chuyên gia này nên thông báo cho
người dùng về dự định của họ, đưa mã tham chiếu sự cố cho người
dùng và cố gắng tìm kiếm giải pháp.
4.2.5. 6 Leo th ang s ự c ố

 Leo thang về mặt chức năng. Ngay sau khi rõ ràng là Bộ phận
Hỗ trợ Dịch vụ không có khả năng giải quyết bản thân sự cố
(hoặc khi đích nhắm mục tiêu về thời gian dành cho giải pháp
điểm-đầu tiên [first-point] đã bị vượt quá – bất kể điều kiện
nào đến trước!), sự cố phải được leo thang ngay lập tức để có
thêm sự hỗ trợ.
Nếu tổ chức có một nhóm hỗ trợ cấp độ-thứ hai và Bộ phận Hỗ
trợ Dịch vụ tin rằng sự cố có thể được giải quyết bởi nhóm này
thì họ nên chuyển sự cố sang cho nhóm này. Nếu rõ ràng là sự
cố sẽ cần những kiến thức kỹ thuật sâu hơn – hoặc khi nhóm
hỗ trợ-cấp hai đã không có khả năng giải quyết sự cố trong
phạm vi đích nhắm mục tiêu thời gian đã được thỏa thuận (bất
kể điều kiện nào đến trước!), sự cố phải được leo thang ngay
lập tức cho nhóm hỗ trợ-cấp ba thích hợp. Hãy lưu ý rằng các
nhóm hỗ trợ-cấp ba có thể là trong nội bộ - nhưng họ cũng có
thể là các bên thứ ba như nhà cung cấp phần mềm hoặc nhà
sản xuất hoặc nhà bảo trì phần cứng. Các quy tắc đối với việc
leo thang và xử lý các sự cố phải được thỏa thuận trong các
OLA và UC với các nhóm hỗ trợ nội bộ và bên ngoài tương ứng.
Lưu ý: Quyền sở hữu Sự cố vẫn thuộc về Bộ phận Hỗ trợ Dịch
vụ! Bất kể sự cố được đề cập đến ở đâu trong suốt vòng đời
của nó, quyền sở hữu sự cố vẫn thuộc về Bộ phận Hỗ trợ Dịch
vụ tại mọi thời điểm. Bộ phận Hỗ trợ Dịch vụ vẫn giữ trách
nhiệm theo dõi tiến trình, thông báo cho người dùng, và cuối
cùng là Đóng Sự cố.
 Leo thang theo cấp bậc. Nếu các sự cố là nghiêm trọng về mặt
bản chất (ví dụ, các sự cố Độ ưu tiên 1) thì các nhà quản lý
CNTT phải được thông báo một cách thích hợp, ít nhất là vì
mục đích cung cấp thông tin. Leo thang theo c ấp bậc cũng
được sử dụng nếu như các bước ‘Điều tra và Chẩn đoán’ và
‘Giải pháp và Khôi phục’ tốn quá nhiều thời gian hoặc tỏ ra quá
khó khăn. Leo thang theo cấp bậc nên tiếp tục lên trên chuỗi
quản lý để các nhà quản lý cấp cao nhận thức được và có thể
được chuẩn bị và để thực hiện bất kỳ hành động nào cần thiết,
chẳng hạn như phân bổ thêm nguồn lực bổ sung hoặc kêu gọi
các nhà cung cấp/bảo trì. Leo thang theo cấp bậc cũng được sử
dụng khi xảy ra sự tranh chấp về việc phân bổ sự cố nào cho
ai.
Leo thang theo cấp bậc có thể, dĩ nhiên, được khởi đầu bởi
những người dùng bị ảnh hưởng hoặc quản lý khách hàng, khi
họ thấy phù hợp – đó là lý do tại sao điều quan trọng là các
nhà quản lý CNTT phải được biết để họ có thể dự đoán và
chuẩn bị cho bất kỳ sự leo thang nào như vậy.
Những cấp độ và khung thời gian chính xác cho cả leo thang chức
năng lẫn leo thang theo cấp bậc cần phải được thống nhất, có tính
đến các đích nhắm mục tiêu SLA, và được nhúng vào các công cụ hỗ
trợ vốn sau đó có thể được sử dụng để khống chế và kiểm soát quá
trình trong phạm vi khung thời gian đã được thỏa thuận.
Bộ phận Hỗ trợ Dịch vụ nên giữ cho người dùng được thông báo về
bất kỳ sự leo thang có liên quan nào được thực hiện và đảm bảo Hồ
sơ Sự cố được cập nhật một cách tương xứng để giữ được một lịch
sử các hành động đầy đủ.
Lưu ý l iên q u an đ ến vi ệc p hân b ổ Sự c ố

Có thể có rất nhiều sự cố trong một hàng đợi với cùng mức độ ưu
tiên – vì vậy, công việc đầu tiên của nhân viên Bộ phận Hỗ trợ Dịch
vụ và/hoặc Quản lý Sự cố, kết hợp với các nhà quản lý của các nhóm
hỗ trợ khác nhau mà sự cố được leo thang, là quyết định thứ tự mà
theo đó các sự cố nên được tiếp nhận và giải quyết một cách tích
cực. Những nhà quản lý này phải đảm bảo rằng các sự cố được xử lý
theo đúng thứ tự ưu tiên kinh doanh thực sự và rằng nhân viên
không được phép ‘chọn lựa/cherry-pick’ các sự cố mà họ đã chọn!
4.2.5. 7 Điều tra và Ch ẩ n đoán

Trong trường hợp các sự cố khi mà người dùng chỉ tìm kiếm thông
tin, Bộ phận Hỗ trợ Dịch vụ nên có khả năng cung cấp thông tin một
cách tương đối nhanh chóng và giải quyết yêu cầu dịch vụ - nhưng
nếu là một lỗi đang được báo cáo, đây rõ ràng là một sự cố và có
khả năng đòi hỏi một số mức độ điều tra và chẩn đoán.
Mỗi nhóm hỗ trợ liên quan đến việc xử lý sự cố sẽ điều tra và chẩn
đoán về những gì đã xảy ra - và tất cả các hoạt động như vậy (bao
gồm chi tiết về bất kỳ hành động nào được thực hiện để cố gắng
giải quyết hoặc tái tạo sự cố) nên được ghi nhận lại đầy đủ trong hồ
sơ sự cố để từ đó một hồ sơ lịch sử đầy đủ về tất cả các hoạt động
luôn được duy trì tại mọi thời điểm.
Lưu ý: Thời gian có giá trị thường có thể bị lãng phí nếu hành động
điều tra và chẩn đoán (hoặc thực sự là hành động giải quyết hoặc
khôi phục) được thực hiện một cách tiếp nối. Nếu có thể, các hoạt
động đó nên được thực hiện song song để giảm khung thời gian tổng
thể - và các công cụ hỗ trợ nên được thiết kế và/hoặc lựa chọn để
hỗ trợ cho điều này. Tuy nhiên, nên cẩn trọng phối hợp các hoạt
động, đặc biệt là các hoạt động giải quyết hoặc khôi phục, vì nếu
không, các hành động của các nhóm khác nhau có th ể xung đột hoặc
làm phức tạp thêm giải pháp!
Cuộc điều tra này có thể bao gồm các hành động như:
 Xác lập chính xác những gì đã xảy ra sai hoặc đang được tìm
kiếm bởi người dùng,
 Hiểu về thứ tự thời gian của các sự kiện,
 Xác nhận toàn bộ tác động của sự cố, bao gồm số lượng và
phạm vi người dùng bị ảnh hưởng,
 Xác định bất kỳ sự kiện nào có thể gây ra sự cố (ví dụ, một
thay đổi gần đây, một số hành động của người dùng?),
 Tìm kiếm kiến thức tìm kiếm những lần xảy ra trước đó bằng
cách tìm kiếm Bản ghi Sự cố/Vấn đề trước đó và/hoặc Cơ sở dữ
liệu Lỗi Đã biết hoặc Nhật ký lỗi hoặc Cơ sở dữ liệu Kiến thức
của nhà sản xuất/nhà cung cấp.
4.2.5. 8 Giả i q uy ết và khôi ph ục
Khi một giải pháp tiềm năng đã được xác định, nó nên được áp dụng
và kiểm nghiệm. Những hành động cụ thể sẽ được thực hiện và
những người tham gia vào việc thực hiện các hành động khôi phục
có thể khác nhau, tùy thuộc vào bản chất của lỗi – nhưng có thể bao
gồm:
 Việc yêu cầu người dùng thực hiện các hoạt động được chỉ đạo
trên máy tính hoặc trên thiết bị từ xa của họ,
 Bộ phận Hỗ trợ Dịch vụ triển khai giải pháp tập trung (giả sử,
khởi động lại một máy chủ) hoặc sử dụng phần mềm từ xa để
điều khiển máy tính của người dùng để chẩn đoán và triển khai
giải pháp,
 Các nhóm hỗ trợ chuyên gia được yêu cầu để triển khai các
hành động khôi phục cụ thể (ví dụ, Hỗ trợ Mạng thiết lập cấu
hình lại một bộ định tuyến),
 Một nhà cung cấp hoặc nhà bảo trì bên thứ ba được yêu cầu để
khắc phục một lỗi.
Thậm chí ngay cả khi một giải pháp đã được phát hiện, việc kiểm
nghiệm đầy đủ phải được thực hiện để đảm bảo rằng hành động khôi
phục là hoàn chỉnh và rằng dịch vụ đã được khôi phục hoàn toàn đối
với (những) người dùng.
LƯU Ý: Trong một số trường hợp, có thể cần hai hoặc nhiều nhóm
thực hiện các hành động khôi phục riêng biệt, mặc dù có thể được
kết hợp, để giải pháp tổng thể được triển khai. Trong những trường
hợp đó, Quản lý Sự cố phải phối hợp các hoạt động và liên lạc với
tất cả các bên có liên quan.
Bất kể hành động nào đã được thực hiện, hoặc ai thực hiện chúng,
Hồ sơ Sự cố phải được cập nhật một cách tương xứng với tất cả
những thông tin và chi tiết liên quan để từ đó, một lịch sử đầy đủ
(về sự cố) được duy trì.
Nhóm giải quyết nên chuyển sự cố trở lại cho Bộ phận Hỗ trợ Dịch
vụ để tiến hành hành động đóng.
4.2.5. 9 Đóng S ự c ố
Bộ phận Hỗ trợ Dịch vụ nên kiểm tra rằng sự cố đã được khắc phục
hoàn toàn và rằng người dùng đã thỏa mãn và sẵn lòng thống nhất
rằng sự cố có thể được đóng lại. Bộ phận Hỗ trợ Dịch vụ cũng nên
kiểm tra những điều sau đây:
 Phân loại (hành động) đóng. Kiểm tra và xác nhận rằng
phân loại sự cố ban đầu là chính xác hoặc, nếu phân loại tiếp
sau đó là không chính xác, hãy cập nhật hồ sơ để từ đó một
phân loại đóng chính xác cho sự cố được ghi nhận lại - tìm
kiếm lời khuyên hoặc hướng dẫn từ (các) nhóm giải quyết khi
cần thiết.
 Khảo sát sự hài lòng của người dùng. Thực hiện một cuộc
gọi lại hoặc khảo sát qua e-mail về mức độ hài lòng của người
dùng để biết tỷ lệ sự cố đã được thống nhất.
 Lập tài liệu về sự cố. Theo dõi bất kỳ chi tiết nổi bật nào và
đảm bảo rằng Hồ sơ Sự cố đã được ghi nhận lại đầy đủ để hồ
sơ lịch sử đầy đủ ở mức độ chi tiết đầy đủ là hoàn chỉnh.
 Vấn đề đang diễn ra hoặc tái diễn? Xác định (kết hợp với
các nhóm giải quyết) xem liệu sự cố có thể tái diễn hay không
và quyết định xem có cần thiết phải thực hiện bất kỳ hành
động phòng ngừa nào để tránh điều này hay không. Cùng với
Quản lý Sự cố, hãy nêu ra Hồ sơ Sự cố trong tất cả các trường
hợp như vậy để hành động phòng ngừa được khởi đầu.
 Đóng. Chính thức đóng Hồ sơ Sự cố.
Lưu ý: Một số tổ chức có thể chọn sử dụng một khoảng thời gian
đóng tự động đối với các sự cố cụ thể hoặc thậm chí tất cả các sự
cố (ví dụ, sự cố sẽ tự động đóng sau hai ngày làm việc nếu người
dùng không liên hệ thêm). Khi phương pháp tiếp cận này được xem
xét, trước tiên nó phải được thảo luận và thống nhất với người dùng
- và được công bố một cách rộng rãi để tất cả người dùng và nhân
viên CNTT nhận thức được về điều này. Có thể là không thích hợp
khi sử dụng phương pháp này cho một số loại sự cố nhất định -
chẳng hạn như sự cố nghiêm trọng hoặc những sự cố liên quan đến
VIP, v.v…
Các quy t ắ c đ ể mở l ạ i các s ự c ố

Mặc dù đã được chăm sóc đầy đủ, nhưng sẽ có những trường hợp sự
cố tái diễn mặc dù chúng đã được chính thức đóng lại. Vì những
trường hợp như vậy, một điều khôn ngoan là nên có các quy t ắc xác
định trước về việc nếu và thời điểm mà một sự cố có thể được mở
lại. Ví dụ, có thể hợp lý khi đồng ý rằng nếu sự cố tái diễn trong
vòng một ngày làm việc thì có thể được mở lại - nhưng sau thời
điểm này, một sự cố mới phải được nêu ra, nhưng sẽ được liên kết
với (các) sự cố trước đó.
Ngưỡng thời gian/các quy tắc chính xác có thể khác nhau giữa các tổ
chức cá nhân - nhưng các quy tắc rõ ràng nên được thống nhất và
lập thành văn bản cũng như hướng dẫn cho tất cả nhân viên của Bộ
phận Hỗ trợ Dịch vụ để được áp dụng một cách thống nhất.
4.2.6 Các đi ều ki ệ n kích ho ạ t, đ ầ u vào và đầ u
ra/các tương tác qua l ạ i gi ữa c ác quy trình
Các sự cố có thể được kích hoạt theo rất nhiều cách. Lộ trình phổ
biến nhất là khi người dùng gọi đến Bộ phận Hỗ trợ Dịch vụ hoặc
hoàn tất một màn hình ghi nhận lại-sự cố dựa trên nền web, nhưng
ngày càng có nhiều sự cố được đưa ra một cách tự động thông qua
các công cụ Quản lý Sự kiện. Nhân viên kỹ thuật có thể nhận thấy
các lỗi tiềm ẩn và nêu ra sự cố hoặc yêu cầu Bộ phận Hỗ trợ Dịch vụ
làm như vậy để từ đó lỗi có thể được khắc phục. Một vài sự cố cũng
có thể phát sinh tại thời điểm khi khởi đầu các nhà cung cấp -
những người có thể gửi một số hình thức thông báo về một khó khăn
tiềm ẩn hoặc thực tế cần phải được chú ý.
Các tương tác với Quản lý Sự cố bao gồm:
 Quản lý vấn đề: Quản lý Sự cố hình thành nên một phần của
quy trình tổng thể để giải quyết các vấn đề trong tổ chức. Các
sự cố thường do các vấn đề cơ bản gây ra, cần phải giải quyết
để sự cố không tái diễn. Quản lý Sự cố cung cấp một điểm nơi
mà chúng được báo cáo.
 Quản lý Cấu hình cung cấp dữ liệu được sử dụng để xác định
và xử lý các sự cố. Một trong những công dụng của CMS
(Configuration Management System – Hệ thống Quản lý Cấu
hình) là xác định các thiết bị bị lỗi và đánh giá tác động của sự
cố. CMS cũng được sử dụng để xác định những người dùng bị
ảnh hưởng bởi các vấn đề tiềm ẩn. CMS cũng chứa thông tin về
loại sự cố nào nên được chỉ định cho nhóm hỗ trợ nào. Đổi lại,
Quản lý Sự cố có thể duy trì trạng thái của các Đơn vị Cấu hình
bị lỗi. Nó cũng có thể hỗ trợ Quản lý Cấu hình kiểm toán cơ sở
hạ tầng khi làm việc để giải quyết một sự cố.
 Quản lý thay đổi: Trong trường hợp thay đổi là cần thiết để
triển khai một biện pháp xử lý hoặc một giải pháp, điều này sẽ
cần phải được ghi lại dưới dạng RFC và được triển khai thông
qua Quản lý Thay đổi. Đổi lại, Quản lý Sự cố có thể phát hiện
và giải quyết các sự cố phát sinh từ các thay đổi bị thất bại.
 Quản lý Công suất: Quản lý Sự cố cung cấp một điều kiện kích
hoạt để giám sát hiệu suất khi xuất hiện vấn đề về hiệu suất.
Quản lý Công suất có thể phát triển các biện pháp giải quyết
các sự cố.
 Quản lý Tính sẵn sàng; sẽ sử dụng dữ liệu Quản lý Sự cố để
xác định tính sẵn sàng của các dịch vụ CNTT và tìm kiếm
những điểm nơi mà vòng đời sự cố có thể được cải thiện.
 SLM: khả năng xử lý các sự cố trong một khoảng thời gian cụ
thể là một phần then chốt của việc cung cấp mức dịch vụ đã
được thỏa thuận. Quản lý Sự cố hỗ trợ cho SLM xác định các
biện pháp ứng phó có thể đo lường được đối với những gián
đoạn dịch vụ. Đồng thời nó cũng cung cấp các báo cáo cho
phép SLM xem xét các SLA một cách khách quan và định kỳ.
Đặc biệt, Quản lý Sự cố có khả năng hỗ trợ trong việc xác định
nơi mà dịch vụ yếu nhất, để từ đó SLM có thể xác định các
hành động như là một phần của Chương trình Cải tiến Dịch vụ
(Service Improvement Programme - SIP) – xem ấn phẩm Liên
tục Cải tiến Dịch vụ để biết thêm chi tiết. SLM xác định các
mức dịch vụ có thể chấp nhận được trong phạm vi mà Quản lý
Sự cố hoạt động, bao gồm:
o Thời gian ứng phó với sự cố,
o Định nghĩa tác động,
o Thời gian khắc phục được nhắm mục tiêu,
o Các định nghĩa dịch vụ, được ánh xạ tới người dùng,
o Các quy tắc đối với việc yêu cầu dịch vụ,
o Những kỳ vọng đối với việc cung cấp phản hồi cho người
dùng.

Hầu hết thông tin được sử dụng trong Quản lý Sự cố đến từ các
nguồn dưới đây:
 Các công cụ Quản lý Sự cố, bao gồm những thông tin về:
o Lịch sử sự cố và vấn đề,
o Thể loại sự cố,
o Hành động đã thực hiện để giải quyết sự cố,
o Các kịch bản chẩn đoán có thể giúp cho các chuyên gia
phân tích tuyến đầu giải quyết sự cố, hoặc ít nhất thu
thập thông tin sẽ giúp cho các chuyên gia phân tích tuy ến
thứ hai hoặc thứ ba giải quyết sự cố nhanh hơn,
 Các Hồ sơ Sự cố, bao gồm những dữ liệu dưới đây:
o Mã tham chiếu định danh duy nhất,
o Phân loại sự cố,
o Ngày giờ ghi nhận (sự cố) và bất kỳ hoạt động nào tiếp
theo đó,
o Tên và nhân dạng của người ghi nhận và cập nhật Hồ sơ
Sự cố,
o Tên/tổ chức/chi tiết liên hệ cua (những) người dùng bị
ảnh hưởng,
o Mô tả về các dấu hiệu của sự cố,
o Chi tiết về bất kỳ hành động nào đã thực hiện để cố gắng
chẩn đoán, giải quyết hoặc tái tạo lại sự cố,
o Thể loại, tác động, tính khẩn cấp và tác động của sự cố,
o Mối quan hệ với các sự cố, vấn đề, thay đổi hoặc các Lỗi
Đã biết.
o Các chi tiết Đóng, bao gồm thời gian, thể loại, hành động
đã thực hiện và danh tính của người đóng hồ sơ.
Quản lý Sự cố cũng đòi hỏi truy cập vào CMS. Điều này sẽ giúp nó
xác định được các Đơn vị Cấu hình bị ảnh hưởng bởi sự cố và đồng
thời, ước lượng tác động của sự cố.
Cơ sở dữ liệu Lỗi Đã biết cung cấp những thông tin vô giá về các
giải pháp và biện pháp xử lý khả thi. Điều này được thảo luận chi
tiết trong phần 4.4.7.2.
Các chỉ số nên được giám sát và báo cáo để đánh giá tính hiệu quả
và hiệu suất của quy trình Quản lý Sự cố, và hoạt động của nó, sẽ
bao gồm:
 Tổng số lượng các sự cố (như là một thước đo kiểm soát),

 Phân tách của các sự cố tại từng giai đoạn (ví dụ, đã được ghi
nhận, đang tiến triển, đã đóng, v.v…),
 Quy mô của công việc tồn đọng sự cố hiện tại,
 Số lượng và tỷ lệ phần trăm của các sự cố nghiêm trọng,
 Thời gian đã trôi qua trung bình đ ể đạt được giải pháp hoặc
phá vỡ sự cố, được phân tách bởi mã tác động,
 Tỷ lệ phần trăm của các sự cố được xử lý trong phạm vi thời
gian ứng phó đã được thống nhất (các đích nhắm mục tiêu thời
gian ứng phó sự cố có thể được chỉ định trong các SLA, ví dụ,
bởi các mã tác động và tính khẩn cấp),
 Chi phí trung bình cho từng sự cố,
 Số lượng các sự cố được mở lại và tỷ lệ phần trăm trên tổng số
các sự cố,
 Số lượng và tỷ lệ phần trăm các sự cố được chỉ định sai,
 Số lượng và tỷ lệ phần trăm các sự cố được phân loại sai,
 Tỷ lệ phần trăm các Sự cố được đóng bởi Bộ phận Hỗ trợ Dịch
vụ mà không tham khảo các mức hỗ trợ khác (thường được
tham chiếu như là ‘điểm liên hệ đầu tiên”.
 Số lượng và tỷ lệ phần trăm các sự cố được được xử lý bởi tác
nhân Bộ phận Hỗ trợ Dịch vụ,
 Số lượng và tỷ lệ phần trăm các sự cố được xử lý từ xa, không
cần phải ghé thăm,
 Số lượng và tỷ lệ phần trăm các sự cố được xử lý bởi từng Mô
hình Sự cố,
 Phân tách các sự cố theo thời gian trong ngày, để giúp xác
định các đỉnh điểm và đảm bảo sự phù hợp của nguồn lực.
Các báo cán nên được đưa ra theo thẩm quyền của Nhà quản lý Sự
cố, người nên vẽ ra một lịch trình và danh sách phân ph ối, cộng tác
với Bộ phận Hỗ trợ Dịch vụ và các nhóm hỗ trợ đang xử lý sự cố.
Các danh sách phân phối ít nhất nên bao gồm Quản lý Dịch vụ CNTT
và các nhóm hỗ trợ chuyên môn. Đồng thời, cũng nên xem xét việc
cung cấp dữ liệu cho người dùng và khách hàng, ví dụ, thông qua
các báo cáo SLA.
4.2.9 N hững thách th ức, các Y ếu t ố T hành công
Q uan tr ọng v à r ủi r o

Dưới đây là những thách thức đối với sự thành công của Quản lý Sự
cố:
 Khả năng phát hiện các sự cố càng sớm càng tốt. Điều này sẽ
đòi hỏi việc giáo dục người dùng về việc báo cáo các sự cố, sử
dụng Super User (xem đoạn 6.2.4.5) và cấu hình của các công
cụ Quản lý Sự kiện.
 Thuyết phục tất cả nhân viên (các nhóm kỹ thuật cũng như
người dùng) rằng mọi sự cố phải được ghi nhận lại, và khuyến
khích việc sử dụng năng lực tự-hỗ trợ dựa trên nền web (vốn
có thể tăng tốc sự hỗ trợ và giảm thiểu các yêu cầu về nguồn
lực).
 Tính sẵn sàng của thông tin về các vấn đề và Lỗi Đã biết. Điều
này sẽ cho phép nhân viên Quản lý Sự cố học hỏi từ các sự cố
trước đó và đồng thời theo dõi trạng thái của giải pháp.
 Tích hợp vào CMS để xác định mối quan hệ giữa các Đơn vị Cấu
hình và để tham chiếu đến lịch sử của các Đơn vị Cấu hình khi
thực hiện hỗ trợ tuyến đầu.
 Tích hợp vào quy trình SLM. Điều này sẽ giúp Quản lý Sự cố
đánh giá một cách chính xác tác động và độ ưu tiên của sự cố
và hỗ trợ cho việc xác định và thực thi các thủ tục leo thang.
SLM cũng được hưởng lợi từ những thông tin đã được học hỏi
trong quá trình Quản lý Sự cố, ví dụ, trong việc xác định xem
liệu các đích nhắm mục tiêu mức dịch vụ có thực tế và có thể
đạt được hay không.
4.2.9. 2 Các y ếu t ố T hành công Q uan tr ọng
Các yếu tố dưới đây sẽ là những yếu tố tối quan trọng đối với sự
thành công của Quản lý Sự cố:
 Một Bộ phận Hỗ trợ Dịch vụ giỏi là chìa khóa để Quản lý Sự cố

thành công.
 Các đích nhắm mục tiêu được xác định một cách rõ ràng để làm
việc với chúng – như được xác định trong các SLA.
 Nhân viên hỗ trợ đào tạo kỹ thuật và được định hướng-khách
hàng đầy đủ với các cấp độ kỹ năng chính xác, ở mọi giai đoạn
của quy trình.
 Các công cụ hỗ trợ được tích hợp để định hướng và kiểm soát
quy trình.
 Các OLA và UC có khả năng ảnh hưởng và định hình chính xác
hành vi của tất cả các nhân viên hỗ trợ.
4.2.9. 3 R ủi ro
Những rủi ro để Quản lý Sự cố thành công thực sự giống như một số
thách thức và mặt trái của một số Yếu tố Thành công Quan trọng
được đề cập ở trên. Chúng bao gồm:
 Bị ngập trong các sự cố không thể xử lý trong phạm vi thời

gian có thể chấp nhận được do thiếu nguồn lực sẵn có hoặc đã
được đào tạo thích hợp.
 Sự cố bị sa lầy và không tiến triển như đã dự kiến do không đủ
công cụ hỗ trợ để đưa ra cảnh báo và xử lý nhanh chóng,
 Thiếu nguồn thông tin đầy đủ và/hoặc kịp thời do không đủ
công cụ hoặc thiếu sự tích hợp,
 Không phù hợp trong các mục tiêu hoặc hành động do các OLA
và/hoặc UC không được liên kết hoặc không tồn tại.
4.3 Th ực h i ện cá c yêu c ầ u
Thuật ngữ ‘Yêu cầu Dịch vụ’ được sử dụng như một mô tả khái quát
cho rất nhiều kiểu nhu cầu khác nhau được đặt ra cho Bộ phận CNTT
bởi người dùng. Rất nhiều trong số những yêu cầu này thực tế là
những thay đổi nhỏ - rủi ro thấp, thường xuyên diễn ra, chi phí
thấp, v.v… (ví dụ, một yêu cầu thay đổi mật khẩu, một yêu cầu cài
đặt một phần mềm ứng dụng bổ sung vào một máy trạm cụ thể, một
yêu cầu di dời một số mục của thiết bị máy tính để bàn) hoặc có thể
chỉ là một câu hỏi yêu cầu thông tin – nhưng quy mô và tần suất,
cũng như mức rủi ro thấp của chúng có nghĩa rằng chúng tốt hơn
nên được xử lý bởi một quy trình tách biệt thay vì được phép làm
tắc nghẽn và cản trở các quy trình Quản lý Sự cố và Quản lý Thay
đổi.

Thực hiện Yêu cầu là các quy trình xử lý các Yêu cầu Dịch vụ từ
người dùng. Mục tiêu của quy trình Thực hiện Yêu cầu bao gồm:
 Cung cấp một kênh để người dùng yêu cầu và nhận được các
dịch vụ tiêu chuẩn có quy trình phê duyệt và thẩm định xác
định trước.
 Cung cấp thông tin cho người dùng và khách hàng về tính sẵn
sàng của các dịch vụ và thủ tục để có được chúng.
 Là nguồn và cung cấp các thành phần của các dịch vụ tiêu
chuẩn đã được yêu cầu (ví dụ, giấy phép và phương tiện phần
mềm).
 Hỗ trợ về thông tin chung, khiếu nại và nhận xét.
4.3.2 Phạ m vi
Quy trình cần thiết để thực hiện một yêu cầu sẽ khác nhau tùy thuộc
vào chính xác những gì đang được yêu cầu - nhưng thường có thể
được chia nhỏ ra thành một tập hợp các hoạt động phải được thực
hiện. Một số tổ chức sẽ thoải mái để cho Yêu cầu Dịch vụ được xử lý
thông qua các quy trình (và công c ụ) Quản lý Sự cố của họ - với Yêu
cầu Dịch vụ được xử lý như một loại 'sự cố' cụ thể (sử dụng một hệ
thống phân loại cấp cao để xác định những 'sự cố' đó trên thực tế là
các Yêu cầu Dịch vụ).
Tuy nhiên, hãy lưu ý rằng có một sự khác biệt đáng kể ở đây - một
sự cố thường là một sự kiện nằm ngoài kế hoạch trong khi Yêu cầu
Dịch vụ thường là thứ có thể và nên được lập kế hoạch!
Do đó, trong một tổ chức, nơi một số lượng lớn Yêu cầu Dịch vụ phải
được xử lý, và khi các hành động cần được thực hiện để đáp ứng
những yêu cầu đó rất đa dạng hoặc chuyên biệt, có thể sẽ thích hợp
để xử lý Yêu cầu Dịch vụ như một luồng công việc hoàn toàn tách
biệt - và ghi nhận lại và quản lý chúng như một kiểu hồ sơ riêng
biệt.
Điều này có thể đặc biệt thích hợp nếu tổ chức đã lựa chọn mở rộng
phạm vi của Bộ phận Hỗ trợ Dịch vụ để mở rộng chỉ đối với các vấn
đề liên quan đến-CNTT và sử dụng bộ phận này làm đầu mối cho các
loại hoặc yêu cầu dịch vụ khác - ví dụ, yêu cầu cung cấp dịch vụ
máy photocopy hoặc thậm chí đi xa hơn bao gồm, ví dụ, các vấn đề
về quản lý tòa nhà, chẳng hạn như cần phải thay thế phụ kiện đèn
chiếu sáng hoặc sửa chữa rò rỉ trong hệ thống ống nước.
Lưu ý: Cuối cùng, sẽ tùy thuộc vào mỗi tổ chức để quyết định và ghi
nhận lại yêu cầu mà tổ chức đó sẽ xử lý thông qua quy trình Thực
hiện Yêu cầu và những tổ chức khác sẽ phải trải qua quy trình Quản
lý Thay đổi chính thức hơn. Sẽ luôn có những vùng xám ngăn cản
những hướng dẫn chung chung được chỉ định một cách hữu ích.

Giá trị của Thực hiện Yêu cầu là cung cấp quyền tiếp cậnh nhanh
chóng và hiệu quả đến các dịch vụ tiêu chuẩn mà nhân viên của
doanh nghiệp có thể sử dụng để cải thiện năng suất hoặc chất lượng
của các dịch vụ và sản phẩm của doanh nghiệp.
Thực hiện Yêu cầu giảm thiểu một cách hiệu quả sự quan liệu liên
quan đến việc yêu cầu và nhận được quyền tiếp cận đến những dịch
vụ hiện hữu hoặc dịch vụ mới, do đó, cũng làm giảm chi phí của việc
cung cấp những dịch vụ này. Việc tập trung hóa thực hiện (các yêu
cầu) cũng làm gia tăng mức độ kiểm soát đối với các dịch vụ này.
Đến lượt nó, điều này có thể giúp làm giảm chi phí thông qua đàm
phán tập trung với các nhà cung cấp, và cũng có thể giúp giảm chi
phí hỗ trợ.

Rất nhiều Yêu cầu Dịch vụ sẽ thường xuyên lặp lại, do đó, một luồng
quy trình được xác định trước (một mô hình) có thể được thiết lập
để bao gồm các giai đoạn cần thiết để thực hiện yêu cầu, các cá
nhân hoặc nhóm hỗ trợ tham gia, đích nhắm mục tiêu về khung thời
gian và lộ tuyến leo thang. Các Yêu cầu Dịch vụ sẽ thường được đáp
ứng bằng cách triển khai một Thay đổi Tiêu chuẩn (xem thêm ấn
phẩm Chuyển tiếp Dịch vụ để biết thêm chi tiết về những Thay đổi
Tiêu chuẩn). Quyền sở hữu của các Yêu cầu Dịch vụ thuộc về Bộ
phận Hỗ trợ Dịch vụ, và bộ phận này sẽ giám sát, leo thang, giải
quyết nhanh gọn và thực hiện yêu cầu của người dùng.
4.3.4. 1 Các Mô hình Y êu c ầ u

Một số Yêu cầu Dịch vụ sẽ diễn ra thường xuyên và sẽ đòi hỏi việc
xử lý theo một cách nhất quán nhằm đáp ứng các mức dịch vụ đã
được thống nhất. Để hỗ trợ cho điều này, rất nhiều tổ chức sẽ muốn
tạo ra các Mô hình Yêu cầu được xác định-trước (thường bao gồm
một số hình thức phê duyệt-trước bởi Quản lý Thay đổi.

quy trì nh
4.3.5. 1 Lựa c họn Me nu

Thực hiện Yêu cầu mang lại những cơ hội tuyệt vời cho những thực
tiễn tự-trợ giúp, nơi mà người dùng có thể tạo ra Yêu cầu Dịch vụ
bằng cách sử dụng công nghệ liên kết với các công cụ Quản lý Dịch
vụ. Tốt nhất, người dùng nên được cung cấp một lựa chọn kiểu
'menu' thông qua giao diện web, để họ có thể chọn và nhập thông
tin chi tiết về Yêu cầu dịch vụ từ một danh sách đã được xác định
trước – nơi kỳ vọng thích hợp có thể được đặt ra bằng cách đưa ra
đích nhắm mục tiêu cung cấp và/hoặc đích nhắm mục tiêu/ngày triển
khai (phù hợp với mục tiêu SLA). Khi các tổ chức đang cung cấp khả
năng hỗ trợ CNTT tự-trợ giúp cho người dùng, sẽ hợp lý nếu kết hợp
điều này với hệ thống Thực hiện Yêu cầu như đã được mô tả.
Các công cụ web chuyên biệt để cung cấp loại trải nghiệm kiểu 'giỏ
mua hàng' này có thể được sử dụng cùng với các tương tác trực tiếp
với các công cụ ITSM tích hợp ở phía sau (back-end) hoặc các công
cụ tự động hóa quy trình nghiệp vụ tổng quát hơn hoặc các công cụ
Hoạch định Nguồn lực Doanh nghiệp (ERP) có thể được sử dụng để
quản lý của các hoạt động Yêu cầu Thực hiện.
4.3.5. 2 Phê du y ệt tài chính

Một bước bổ sung quan trọng có khả năng sẽ được cần đến khi xử lý
một yêu cầu dịch vụ là phê duyệt tài chính.
Hầu hết các yêu cầu đều sẽ có một số hình thức liên quan đến tài
chính, bất kể loại thỏa thuận thương mại được sử dụng. Chi phí của
việc thực hiện yêu cầu trước tiên phải được xác lập. Có thể thỏa
thuận giá cố định cho các yêu cầu ‘tiêu chuẩn’ - và phê duyệt trước
cho các yêu cầu đó có thể được đưa ra như một phần của quản lý tài
chính hàng năm tổng thể của tổ chức. Trong tất cả các trường hợp
khác, một ước tính chi phí phải được lập ra và đệ trình cho người
dùng phê duyệt về mặt tài chính (người dùng có thể cần xin ý kiến
phê duyệt của cấp quản lý/chuỗi tài chính của họ). Nếu được chấp
thuận, ngoài việc thực hiện yêu cầu, quy trình cũng phải bao gồm
việc tính phí (thanh toán hoặc tính phí chéo) cho công việc đã thực
hiện - nếu việc tính phí được áp dụng.
4.3.5. 3 Các phê duy ệ t khác

Trong một số trường hợp, các phê duyệt bổ sung khác có thể sẽ
được cần đến – chẳng hạn như phê duyệt liên quan đến tuân thủ
hoặc phê duyệt nghiệp vụ rộng hơn. Thực hiện Yêu cầu phải có khả
năng xác định và kiểm tra những phê duyệt như vậy khi cần thiết.
4.3.5. 4 Thực h i ện
Hoạt động thực hiện trong thực tế sẽ tùy thuộc vào bản chất của
Yêu cầu Dịch vụ. Một số yêu cầu đơn giản hơn có thể được hoàn
thành bởi Bộ phận Hỗ trợ Dịch vụ, đóng vai trò như hỗ trợ tuyến
đầu, trong khi những yêu cầu khác phải được chuyển tiếp cho các
nhóm chuyên gia và/hoặc nhà cung cấp để thực hiện.
Một số tổ chức có thể có các nhóm thực hiện chuyên biệt (để ‘chọn,
đóng gói và gửi’ (pick, pack and dispatch) – hoặc có thể thuê ngoài
một số hoạt động thực hiện cho (các) nhà cung cấp bên thứ ba. Bộ
phận Hỗ trợ Dịch vụ nên giám sát và theo dõi ti ến độ và giữ cho
người dùng được thông báo về toàn bộ quá trình, bất kể nguồn thực
hiện trong thực tế.
4.3.5. 5 Đóng
Khi Bộ phận Hỗ trợ Dịch vụ đã thực sự thực hiện (yêu cầu) thì nó
phải được trả ngược về cho Bộ phận Hỗ trợ Dịch vụ để đóng lại. Bộ
phận Hỗ trợ Dịch vụ nên trải qua cùng một quy trình đóng như đã
được mô tả trong đoạn 4.2.5.9 – kiểm tra rằng người dùng hài lòng
với kết quả.
4.3.6 Điều ki ện kíc h ho ạ t, đ ầ u vào và đ ầ u ra/các

tương tác qua l ạ i g i ữa các quy trình
Hầu hết các yêu cầu sẽ được kích hoạt thông qua một cuộc gọi của
người dùng đến Bộ phận Hỗ trợ Dịch vụ hoặc người dùng hoàn thành
một số biểu mẫu màn hình nhập liệu tự-trợ giúp dựa trên nền-web
để đưa ra yêu cầu của họ. Kiểu tương tác thứ hai thường liên quan
đến việc lựa chọn từ một danh mục các kiểu yêu cầu có sẵn. Các
tương tác chính với Thực hiện Yêu cầu bao gồm:
 Bộ phận Hỗ trợ Dịch vụ/Quản lý Sự cố: Rất nhiều Yêu cầu

Dịch vụ có thể đến qua Bộ phận Hỗ trợ Dịch vụ và có thể được
xử lý ban đầu thông qua quy trình Quản lý Sự cố. Một số tổ
chức có thể chọn rằng tất cả các yêu cầu được xử lý thông qua
lộ tuyến này - nhưng những tổ chức khác có thể lựa chọn để có
một quy trình riêng biệt, vì những lý do đã được thảo luận
trước đó trong chương này.
 Cũng cần có một liên kết mạnh mẽ giữa Thực hiện Yêu cầu,
Phát hành, Quản lý Tài sản và Quản lý Cấu hình - vì một số
yêu cầu sẽ dành cho việc triển khai các thành phần mới hoặc
được nâng cấp để có thể được triển khai một cách tự động.
Trong những trường hợp như vậy, ‘bản phát hành’ có thể được
xác định trước, được xây dựng và thử nghiệm nhưng chỉ được
triển khai tùy theo yêu cầu của những người muốn có ‘bản phát
hành’. Sau khi triển khai, CMS sẽ phải được cập nhật để phản
ánh sự thay đổi. Khi thích hợp, kiểm tra/cập nhật giấy phép
phần mềm cũng sẽ cần thiết.
Khi thích hợp, sẽ cần thiết phải tương quan Yêu cầu Dịch vụ có liên
quan đến CNTT với bất kỳ sự cố hoặc vấn đề nào đã khởi phát yêu
cầu (như trường hợp đối với bất kỳ loại thay đổi nào khác).

Thực hiện Yêu cầu phụ thuộc vào thông tin từ những nguồn sau đây:
 Các Yêu cầu Dịch vụ sẽ chứa những thông tin về:

o Dịch vụ nào đang được yêu cầu,
o Ai đã yêu cầu và được cấp phép (truy cập) dịch vụ,
o Quy trình nào sẽ được sử dụng để thực hiện yêu cầu,
o Nó (yêu cầu) đã được chỉ định cho ai và hành động nào
đã được thực hiện,
o Ngày giờ khi yêu cầu đã được ghi nhận cũng như ngày giờ
mà mọi hành động đã được thực hiện,
o Các chi tiết đóng (yêu cầu).
 Yêu cầu Thay đổi: Trong một số trường hợp, quy trình Thực
hiện Yêu cầu sẽ được khởi nguồn bằng một RFC. Đây sẽ thường
là nơi mà Yêu cầu Dịch vụ liên quan đến một Đơn vị Cấu hình.
 Danh mục Dịch vụ, để cho phép phạm vi của Yêu cầu Dịch vụ
đã được thống nhất sẽ được xác định.
 Các Chính sách Bảo mật sẽ quy định bất kỳ biện pháp kiểm
soát nào sẽ được thực thi hoặc tuân thủ khi cung cấp dịch vụ,
ví dụ, đảm bảo rằng người yêu cầu đã được cấp phép để truy
cập vào dịch vụ, hoặc rằng phần mềm đã được cấp phép sử
dụng.
Các chỉ số cần thiết để đánh giá tính hiệu quả và hiệu suất của Thực
hiện Yêu cầu sẽ bao gồm những điều dưới đây (từng chỉ số sẽ cần
được chia nhỏ theo kiểu yêu cầu, trong một khoảng thời gian):
 Tổng số lượng Yêu cầu Dịch vụ (như là một thước đo kiểm

soát),
 Phân tách các yêu cầu dịch vụ ở từng giai đoạn (ví dụ, đã được
ghi nhận, WIP, đã đóng, v.v…),
 Quy mô của công việc tồn đọng hiện tại của các Yêu cầu Dịch
vụ chưa được giải quyết,
 Thời gian đã trôi qua trung bình đ ể xử lý từng kiểu Yêu cầu
Dịch vụ,
 Số lượng và tỷ lệ phần trăm của các Yêu cầu Dịch vụ đã hoàn
thành trong phạm vi đích nhắm mục tiêu về thời gian đã được
thống nhất,
 Chi phí trung bình cho mỗi kiểu Yêu cầu Dịch vụ,
 Mức độ hài lòng của khách hàng với việc xử lý Yêu cầu Dịch vụ
(được đo lường dưới một số hình thức khảo sát mức hài lòng).
4.3.9 N hững thách th ức, các Y ếu t ố T hành công


Dưới đây là những thách thức phải đối mặt khi giới thiệu Thực hiện
Yêu cầu:
 Việc xác định và lập thành tài liệu một cách rõ ràng về kiểu
của yêu cầu sẽ được xử lý trong phạm vi quy trình Thực hiện
Yêu cầu (và những yêu cầu sẽ chuyển qua Bộ phận Hỗ trợ Dịch
vụ và được xử lý như các sự cố hoặc những yêu cầu nào sẽ cần
phải trải qua quy trình Quản lý Thay đổi chính thức) – để từ đó
tất cả các bên hoàn toàn rõ ràng về phạm vi.
 Việc thiết lập năng lực tự-trợ giúp front-end để cho phép người
dùng tương tác thành công với quy trình Thực hiện Yêu cầu.
4.3.9. 2 Các Y ếu t ố T hành công Q uan tr ọng

Thực hiện Yêu cầu phụ thuộc vào những Yếu tố Thành công Quan
trọng sau đây:
 Thỏa thuận về những dịch vụ nào sẽ được chuẩn hóa và ai
được ủy quyền để yêu cầu chúng. Chi phí của những dịch vụ
này cũng phải được thống nhất. Việc này có thể được hoàn
thành như một phần của quy trình SLM. Bất kỳ biến đổi nào của
các dịch vụ cũng phải được xác định.
 Công bố dịch vụ đối với người dùng là một phần của Mục lục
Dịch vụ. Điều quan trọng là phần này của Mục lục Dịch vụ phải
được truy cập một cách dễ dàng, có lẽ từ Intranet, và nên
được công nhận là nguồn thông tin đầu tiên để người dùng tìm
kiếm quyền truy cập vào một dịch vụ.
 Định nghĩa về một thủ tục thực hiện tiêu chuẩn cho từng dịch
vụ đang được yêu cầu. Việc này bao gồm mọi chính sách mua
sắm và năng lực tạo ra các yêu cầu mua hàng và yêu cầu công
việc.
 Một điểm đơn liên hệ có thể được sử dụng để yêu cầu dịch vụ.
Điều này thường được cung cấp bởi Bộ phận Hỗ trợ Dịch vụ
hoặc thông qua một yêu cầu Intranet, nhưng cũng có th ể thông
qua một yêu cầu được tự động hóa trực tiếp vào Thực hiện
Yêu cầu hoặc hệ thống mua sắm.
 Các công cụ tự-phục vụ cần thiết để cung cấp một giao diện
front-end cho người dùng. Điều thiết yếu là những công cụ này
tích hợp với các công cụ thực hiện back-end, thường được quản
lý thông qua Quản lý Sự cố hoặc Quản lý Thay đổi.
4.3.9. 3 R ủi ro
Những rủi ro có thể gặp phải với Thực hiện Yêu cầu bao gồm:
 Phạm vi được xác định kém, khi mọi người không rõ về chính
xác những gì mà quy trình được kỳ vọng sẽ xử lý.
 Những giao diện người dùng được thiết kế hoặc triển khai kém
dẫn đến việc người dùng gặp khó khăn khi đưa ra các yêu cầu
mà họ cần.
 Các quy trình thực hiện back-end được thiết kế hoặc vận hành
kém không có khả năng xử lý một lượng lớn hoặc bản chất của
yêu cầu được đưa ra.
 Năng lực giám sát không đủ để từ đó các chỉ số chính xác
không thể được thu thập.
4.4 Quản lý Vấn đề

ITIL định nghĩa một ‘vấn đề’ như là nguyên nhân của một hoặc nhiều
sự cố.

Quản lý Vấn đề là quy trình chịu trách nhiệm cho việc quản lý vòng
đời của mọi vấn đề. Mục tiêu chủ yếu của Quản lý Vấn đề là để ngăn
ngừa các vấn đề và các sự cố kết quả sẽ xảy ra, để loại bỏ sự tái
diễn các sự cố và giảm thiểu tác động của các sự cố không thể ngăn
ngừa.
4.4.2 Phạ m vi
Quản lý Vấn đề bao gồm các hoạt động cần thiết để chẩn đoán
nguyên nhân gốc rễ của các vấn đề và để xác định giải pháp cho
những vấn đề đó. Trách nhiệm cho việc đảm bảo rằng giải pháp
được triển khai thông qua các thủ tục thích hợp, đặc biệt là Quản lý
Thay đổi và Quản lý Phát hành.
Quản lý Vấn đề cũng sẽ duy trì những thông tin về các vấn đề và các
biện pháp xử lý và các giải pháp thích hợp, để từ đó các tổ chức có
khả năng làm giảm số lượng và tác động của sự cố theo thời gian.
Về mặt này, Quản lý Vấn đề có một tương tác mạnh mẽ với Quản lý
Kiến thức, và các công cụ chẳng hạn như Cơ sở dữ liệu Lỗi Đã biết
sẽ được sử dụng cho cả hai.
Mặc dù Quản lý Sự cố và Quản lý Vấn đề là các quy trình tách biệt,

chúng có liên quan chặt chẽ với và thường sử dụng các công cụ
giống nhau, và có thể sử dụng phân loại, tác động và các hệ thông
mã ưu tiên tương tự. Điều này sẽ đảm bảo sự giao tiếp hiệu quả khi
xử lý các sự cố và vấn đề liên quan.

Quản lý Vấn đề hoạt động cùng với Quản lý Sự cố và Quản lý Thay
đổi để đảm bảo rằng tính sẵn sàng và chất lượng của dịch vụ CNTT
được gia tăng. Khi các sự cố đã được giải quyết, thông tin về giải
pháp được ghi nhận lại. Theo thời gian, những thông tin này được
sử dụng để tăng tốc thời gian của giải pháp và xác định những giải
pháp bền vững, giảm số lượng và thời gian giải pháp của các sự cố.
Điều này sẽ dẫn đến thời gian ngừng hoạt động ít hơn và ít gián
đoạn hơn đối với các hệ thống nghiệp vụ tối quan trọng.
Những giá trị bổ sung bắt nguồn từ những điều dưới đây:
 Tính sẵn sàng của các dịch vụ CNTT cao hơn,

 Năng suất của nhân viên CNTT và nhân viên khác c ủa doanh
nghiệp cao hơn,
 Các khoản chi tiêu cho các biện pháp xử lý hoặc khắc phục
không hoạt động được giảm thiểu,
 Sự giảm thiểu trong chi phí nỗ lực chữa cháy hoặc giải quyết
các sự cố lặp lại.
Có một số khái niệm quan trọng về Quản lý Vấn đề phải được tính
đến ngay từ đầu. Chúng bao gồm:
4.4.4. 1 Các Mô hình V ấ n đ ề

Rất nhiều vấn đề sẽ là duy nhất và sẽ đòi hỏi việc xử lý theo một
cách thức riêng lẻ - tuy nhiên, có thể hiểu được rằng một số sự cố
có thể tái diễn vì các vấn đề tiềm ẩn hoặc vấn đề cơ bản (ví dụ, khi
chi phí của một giải pháp bền vững sẽ cao và một quyết định đã
được đưa ra để không tiếp tục với một giải pháp tốn kém – mà là
‘sống chung’ với vấn đề).
Cũng giống như việc tạo ra một Hồ sơ Lỗi Đã biết trong Cơ sở dữ

liệu Lỗi Đã biết (xem đoạn 4.4.5.7) để đảm bảo chẩn đoán nhanh
hơn, việc tạo ra một Mô hình Vấn đề để xử lý những vấn đề như vậy
trong tương lai có thể sẽ hữu ích. Điều này rất giống ý tưởng về Mô
hình Sự cố đã được mô tả trong đoạn 4.2.4.2, nhưng được áp dụng
cho các vấn đề cũng như cho các sự cố.

quy trì nh
Quản lý Vấn đề cấu thành từ hai quy trình lớn:
 Quản lý Vấn đề Đối phó, vốn thường được thực thi như một
phần của Vận hành Dịch vụ - và do đó, được bao hàm trong ấn
phẩm này.
 Quản lý Vấn đề Chủ động, vốn được khởi nguồn trong Vận hành
Dịch vụ, nhưng thường được định hướng như một phần của
Quy trình Quản lý Vấn đề đối phó được minh họa trong Hình 4.4.
Đây là một biểu đồ được đơn giản hóa để minh họa luồng quy trình
bình thường, nhưng trong thực tế, một số trạng thái có thể lặp lại
hoặc các biến đổi có thể được thực hiện nhằm xử lý những tình
huống đặc biệt.
Hình 4.4 – Luồng quy trình Quản lý Vấn đề
4.4.5. 1 Phát hi ện v ấ n đ ề
Rất nhiều cách phát hiện ra các vấn đề có khả năng sẽ tồn tại trong
mọi tổ chức. Những cách này bao gồm:
 Sự nghi ngờ hoặc phát hiện ra nguyên nhân của một hoặc
nhiều sự cố bởi Bộ phận Hỗ trợ Dịch vụ, dẫn đến việc lập Hồ sơ
Sự cố - bộ phận hỗ trợ có thể đã giải quyết sự cố nhưng chưa
xác định được nguyên nhân đáng tin cậy và nghi ngờ rằng nó
có khả năng tái diễn, do đó sẽ đưa ra một Hồ sơ Sự cố để cho
phép nguyên nhân cơ bản được giải quyết. Ngoài ra, có thể rõ
ràng ngay tức thì rằng một sự cố, hoặc các sự cố, là do một
vấn đề nghiêm trọng gây ra, do đó, Hồ sơ Sự cố sẽ được đưa
ra ngay lập tức.
 Phân tích một sự cố bởi một nhóm hỗ trợ kỹ thuật cho thấy
rằng một vấn đề cơ bản đang tồn tại hoặc có khả năng tồn tại.
 Tự động phát hiện lỗi của cơ sở hạ tầng hoặc ứng dụng, sử
dụng các công cụ sự kiện/cảnh báo tự động để nêu ra một sự
cố có thể cho thấy sự cần thiết phải có Hồ sơ Sự cố.
 Một thông báo từ nhà cung cấp hoặc nhà thầu rằng một vấn đề
tồn tại cần được giải quyết.
 Phân tích các sự cố như là một phần của Quản lý Vấn đề chủ
động - dẫn đến việc phải đưa ra Bản ghi Sự cố để lỗi cơ bản có
thể được điều tra thêm.
Việc phân tích thường xuyên và định kỳ về dữ liệu sự cố và vấn đề

phải được thực hiện để xác định bất kỳ khuynh hướng nào khi chúng
trở nên rõ ràng. Điều này sẽ đòi hỏi sự phân loại chi tiết và có ý
nghĩa các sự cố/vấn đề và báo cáo thường xuyên về các hình mẫu và
khu vực xảy ra với tần suất cao. Báo cáo 'top ten', với khả năng đào
sâu chi tiết đối với các cấp thấp hơn, rất hữu ích trong việc xác định
xu hướng.
Các chi tiết khác về cách mà các xu hướng đã phát hiện được xử lý
như thết nào được đề cập trong ấn phẩm Liên tục Cải tiến Dịch vụ.
4.4.5. 2 Ghi nh ậ t ký v ấ n đ ề
Bất kể phương pháp nhận diện là gì, mọi chi tiết liên quan của vấn
đề phải được ghi nhận lại để từ đó một hồ sơ lịch sử đầy đủ tồn tại.
Việc này phải được đóng dấu ngày giờ để hỗ trợ việc kiểm soát và
báo cáo phù hợp.
Một tham chiếu-chéo phải được thực hiện đối với (các) sự cố đã khởi
tạo Hồ sơ Vấn đề - và mọi chi tiết liên quan phải được sao chép từ
(các) Hồ sơ Sự cố vào Hồ sơ Vấn đề. Rất khó để chính xác vì các
trường hợp có thể khác nhau nhưng thông thường, điều này sẽ bao
gồm các chi tiết như:
 Chi tiết người dùng,

 Chi tiết dịch vụ,
 Chi tiết thiết bị,
 Ngày/giờ ban đầu đã được ghi nhận,
 Chi tiết mức độ ưu tiên và phân loại,
 Mô tả sự cố,
 Chi tiết của mội chẩn đoán hoặc các hành động khôi phục đã cố
gắng thực hiện
4.4.5. 3 Phân l o ạ i v ấ n đ ề
Các vấn đề phải được phân loại theo cùng một cách với các sự cố
(và chúng tôi khuyến cáo nên sử dụng cùng một hệ thống mã) để từ
đó bản chất chính xác của vấn đề có thể được theo dõi và những
thông tin quản lý hữu ích có thể có được một cách dễ dàng.
4.4.5. 4 Thiết l ậ p độ ưu tiê n cho v ấ n đ ề

Các vấn đề phải được thiết lập mức độ ưu tiên theo cùng một cách
và vì cùng nguyên nhân với các sự cố - nhưng tần suất và tác động
của các sự cố có liên quan cũng phải được tính đến. Hệ thống mã đã
được mô tả trước đây trong Bảng 4.1 (kết hợp tác động với tính
khẩn cấp để đưa ra một mức ưu tiên tổng thể) có thể được sử dụng
để ưu tiên các vấn đề theo cùng một cách mà có thể được sử dụng
cho các sự cố, và các đích nhắm mục tiêu dịch vụ có liên quan ở
từng mức độ, rõ ràng phải được nghĩ ra một cách riêng biệt.
Việc thiết lập độ ưu tiên cho vấn đề cũng nên tính đến mức độ
nghiêm trọng của các vấn đề. Mức độ nghiêm trọng trong bối cảnh
này đề cập đến mức độ nghiêm trọng của vấn đề nhìn từ quan điểm
cơ sở hạ tầng, ví dụ,
 Hệ thống có thể được khôi phục không, hay nó cần phải được
thay thế?
 Nó có giá bao nhiêu (tốn bao nhiêu chi phí)?
 Bao nhiêu người, với những kỹ năng nào, sẽ được cần đến để
khắc phục vấn đề?
 Sẽ mất bao lâu để khắc phục vấn đề?
 Vấn đề có phạm vi rộng đến mức nào? (ví dụ, có bao nhiêu CI
bị ảnh hưởng)?
4.4.5. 5 Điều tra và Ch ẩ n đoán V ấ n đ ề
Một cuộc điều tra nên được thực hiện để cố gắng chẩn đoán nguyên
nhân gốc rễ của vấn đề - tốc độ và bản chất của cuộc điều tra này
sẽ khác nhau tùy thuộc vào tác động, mức độ nghiêm trọng và tính
khẩn cấp của vấn đề - tuy nhiên, mức tài nguyên và kiến thức
chuyên môn thích hợp nên được áp dụng để tìm ra giải pháp tương
xứng với mã ưu tiên đã phân bổ và đích nhắm mục tiêu đang có cho
mức ưu tiên đó.
Có một số kỹ thuật giải quyết vấn đề hữu ích có thể được sử dụng
để giúp chẩn đoán và giải quyết các vấn đề - và chúng nên được sử
dụng một cách thích hợp. Những kỹ thuật như vậy được mô tả chi
tiết hơn trong phần sau của phần này.
CMS phải được sử dụng để giúp xác định mức tác động và để hỗ trợ
việc định vị và chẩn đoán chính xác điểm bị lỗi. Cơ sở dữ liệu Lỗi Đã
biết (KEDB) cũng nên được tiếp cận và các kỹ thuật khớp-vấn đề
(chẳng hạn như tìm kiếm từ khóa) nên được sử dụng để xem liệu
vấn đề đã từng xảy ra trước đó hay không, và nếu có, để tìm ra giải
pháp.
Thường thì việc cố gắng tái tạo lại lỗi hỏng hóc rất có giá trị để từ
đó hiểu được điều gì đã xảy ra và sau đó cố gắng thử nhiều cách
khác nhau để tìm ra giải pháp phù hợp nhất và tiết kiệm chi phí nhất
cho vấn đề. Để làm điều này một cách hiệu quả mà không gây ra sự
gián đoạn thêm cho người dùng, một hệ thống kiểm nghiệm sẽ là
cần thiết để phản ánh môi trường sản xuất.
Có rất nhiều kỹ thuật phân tích, chẩn đoán và giải quyết vấn đề
đang có sẵn và cũng có nhiều nghiên cứu đã được thực hiện trong
lĩnh vực này. Một số kỹ thuật hữu ích nhất và được sử dụng thường
xuyên nhất bao gồm:
 Phân tích theo trình tự thời gian (Chronological Analysis): Khi

giải quyết một vấn đề khó khăn, thường có những báo cáo
xung đột nhau về chính xác những gì đã xảy ra và khi nào. Do
đó, việc ghi lại tất cả các sự kiện theo thứ tự thời gian một
cách ngắn gọn sẽ rất hữu ích - để cung cấp một dòng trình tự
thời gian của các sự kiện. Điều này thường khiến cho việc xem
xét sự kiện nào có thể đã được kích hoạt bởi những người khác
trở nên khả dĩ - hoặc trừ hao bất kỳ yêu cầu nào không được
hỗ trợ bởi chuỗi sự kiện.
 Phân tích Giá trị Đau (Pain Value Analysis): Đây là nơi đưa ra
một quan điểm rộng hơn về tác động của một sự cố hoặc vấn
đề, hoặc kiểu sự cố/vấn đề. Thay vì chỉ phân tích số lượng sự
cố/vấn đề của một loại hình cụ thể trong một giai đoạn cụ thể,
một phân tích chuyên sâu hơn đư ợc thực hiện để xác định
chính xác mức độ đau đớn đã gây ra cho tổ chức/doanh nghiệp
bởi những sự cố/vấn đề này. Có thể nghĩ ra một công thức để
tính mức độ đau này. Thông thường, điều này có thể bao gồm
việc tính đến những yếu tố sau đây:
o Số lượng người bị ảnh hưởng,
o Khoảng thời gian ngừng hoạt động gây ra bởi vấn đề/sự
cố,
o Chi phí đối với doanh nghiệp (nếu điều này có thể được
tính toán hoặc ước tính một cách dễ dàng).
Bằng cách tính đến tất cả các yếu tố này, một bức tranh chi
tiết hơn về các sự cố/vấn đề hoặc các kiểu sự cố/vấn đề đang
gây ra nhiều nỗi đau nhất có thể được xác định - cho phép tập
trung tốt hơn vào những điều thực sự quan trọng và đáng được
ưu tiên cao nhất trong việc giải quyết vấn đề/sự cố.
 Kepner và Tregoe: Charles Kepner và Benjamin Tregoe đã phát
triển một phương pháp hữu ích để phân tích vấn đề có thể
được sử dụng một cách chính thức để điều tra các vấn đề sâu
xa hơn. Họ xác định các giai đoạn như sau:
o xác định vấn đề,
o mô tả vấn đề về mặt danh tính, vị trí, thời gian và quy
mô,
o xác lập các nguyên nhân khả dĩ,
o kiểm tra nguyên nhân có thể xảy ra nhất,
o xác minh nguyên nhân thực sự.
Phương pháp này được mô tả chi tiết hơn trong Phụ lục C.
 Động não: Thường có thể rất có giá trị khi tập hợp những
người có liên quan lại với nhau, kể cả vật lý hay bằng phương
tiện điện tử, và ‘động não’ để giải quyết vấn đề - với việc mọi
người đưa ra ý kiến về nguyên nhân tiềm ẩn có thể là gì và
những hành động tiềm năng để giải quyết vấn đề. Các phiên
động não có thể rất xây dựng và sáng tạo nhưng một điều quan
trọng không kém là ai đó, có lẽ là Người quản lý Vấn đề, ghi lại
kết quả và mọi hành động đã thỏa thuận và giữ một mức độ
điều khiển trong (các) phiên.
 Sơ đồ Ishikawa: Kaoru Ishikawa (1915 – 1989), một nhà lãnh
đạo trong lĩnh vực kiểm soát chất lượng của Nhật Bản, đã phát
triển một phương pháp ghi lại nguyên nhân và ảnh hưởng có
thể hữu ích trong việc giúp xác định nơi nào có thể sai hoặc
cần cải thiện. Một sơ đồ như vậy thường là kết quả của một
phiên động não trong đó người giải quyết vấn đề có thể đưa ra
các đề xuất. Mục tiêu chính được biểu thị bằng đường trục của
sơ đồ và các yếu tố chính được biểu diễn dưới dạng các nhánh.
Các yếu tố thứ yếu sau đó được thêm vào dưới dạng thân cây,
v.v… Việc tạo ra sơ đồ kích thích sự thảo luận và thường dẫn
đến việc tăng cường sự hiểu biết về một vấn đề phức tạp. Một
sơ đồ ví dụ được đưa ra trong Phụ lục D.
 Phân tích Pareto: Đây là một kỹ thuật để tách các nguyên nhân
tiềm ẩn quan trọng khỏi các vấn đề tầm thường hơn. Các bước
sau nên được thực hiện:
1. Lập bảng liệt kê các nguyên nhân và tần suất của chúng
dưới dạng phần trăm.
2. Sắp xếp các hàng theo thứ tự giảm dần mức độ quan
trọng của các nguyên nhân, tức là nguyên nhân quan
trọng nhất nằm trước.
3. Thêm cột phần trăm tích lũy vào bảng. Ở bước này, biểu
đồ sẽ giống như Bảng 4.2, minh họa 10 nguyên nhân gây
ra lỗi mạng trong một tổ chức.
Lỗi mạng
Nguyên nhân Tỷ lệ phần trăm trên tổng Ước tính Tích lũy (%)
Bộ điều khiển mạng 35 0 + 35% 35
Tập tin bị gián đoạn 26 35% + 26% 61
Xung dột địa chỉ 19 61% +19% 80
Hệ điều hành máy chủ 6 80% + 6% 86
Lỗi kich bản 5 86% + 5% 91
Thay đổi chưa được kiểm 3 91% + 3% 94

nghiệm
Lỗi vận hành 2 94% + 2% 96
Lỗi sao lưu 2 96% + 2% 98
Cố gắng xâm nhập 1 98% + 1% 99
Lỗi đĩa 1 99% + 1% 100
Bảng 4.2 – Biểu đồ xếp hạng nguyên nhân Pareto

4. Tạo một biểu đồ thanh với các nguyên nhân theo tỷ lệ
phần trăm của tổng số nguyên nhân.
5. Đặt chồng lên một biểu đồ đường về tỷ lệ phần trăm tích
lũy. Đồ thị hoàn chỉnh được minh họa trong Hình 4.5.
6. Vẽ đường ở 80% trên trục y song song với trục x. Sau đó
gióng một đoạn thẳng tại điểm giao với đường cong trên
trục x. Điểm này trên trục x phân tách nguyên nhân quan
trọng và nguyên nhân tầm thường. Đường này được biểu
diễn dưới dạng đường chấm trong Hình 4.5.
Hình 4.5 – Nguyên nhân quan trọng so với nguyên nhân tầm thường
Từ biểu đồ này, rõ ràng có thể thấy rằng có ba nguyên nhân chủ yếu
gây ra lỗi mạng trong tổ chức. Do đó, chúng nên được nhắm đến
trước tiên.
4.4.5. 6 Cách gi ả i quy ết
Trong một số trường hợp, có khả năng tìm ra được một cách giải
quyết cho các sự cố gây ra bởi vấn đề - một cách tạm thời để vượt
qua khó khăn. Ví dụ, một sửa đổi thủ công có thể được thực hiện đối
với một tập tin đầu vào để cho phép một chương trình hoàn tất hoạt
động của nó thành công và cho phép một quy trình thanh toán hoàn
tất một cách mỹ mãn, tuy nhiên, điều quan trọng là công việc với
một giải pháp bền vững tiếp tục khi điều này được chứng minh –
trong ví dụ này, nguyên nhân khiến tập tin (đầu vào) trở nên bị hư
hỏng ngay từ đầu phải được tìm ra và khắc phục để ngăn chặn điều
này xảy ra một lần nữa.
Trong những trường hợp khi mà cách giải quyết đã được tìm ra, do
đó, điều quan trọng là hồ sơ vấn đề vẫn mở, và các chi tiết của cách
giải quyết phải luôn được ghi nhận lại trong Hồ sơ Vấn đề.
4.4.5. 7 Đưa ra m ột H ồ sơ L ỗ i Đã bi ết
Ngay khi việc chẩn đoán hoàn tất, và đặc biệt khi một cách giải
quyết đã được tìm ra (thậm chí ngay cả khi nó có thể chưa phải là
một giải pháp bền vững), một Hồ sơ Lỗi Đã biết phải được đưa ra và
đặt vào trong Cơ sở dữ liệu Lỗi Đã biết – để từ đó, nếu như các sự
cố hoặc vấn đề phát sinh thêm, chúng có th ể được xác định và dịch
vụ được khôi phục một cách nhanh chóng hơn.
Tuy nhiên, trong một số trường hợp, có thể sẽ có lợi khi đưa ra một
Hồ sơ Lỗi Đã biết thậm chí sớm hơn trong quy trình tổng thể - ví dụ,
chỉ cho mục đích thông tin – ngay cả khi chẩn đoán có thể chưa
hoàn tất hoặc chưa tìm được một cách giải quyết, vì vậy, sẽ là
không khôn ngoan để thiết lập một điểm thủ tục cụ thể một cách
chính xác khi một Hồ sơ Lỗi Đã biết phải được nêu ra. Nó nên được
thực hiện ngay khi nó trở nên hữu ích để làm như vậy!
Cơ sở dữ liệu Lỗi Đã biết và cách thức nó nên được sử dụng như thế
nào được mô tả chi tiết hơn trong đoạn 4.4.7.2.
4.4.5. 8 Cách gi ả i quy ết v ấ n đ ề

Lý tưởng nhất, ngay khi giải pháp đã được tìm thấy, nó nên được áp
dụng để giải quyết vấn đề - nhưng trong thực tế, biện pháp bảo vệ
có thể cần thiết để đảm bảo rằng điều này không gây thêm những
khó khăn. Nếu bất kỳ thay đổi nào trong chức năng được yêu cầu,
việc này sẽ đòi hỏi một RFC phải được đưa ra và được phê duyệt
trước khi giải pháp có thể được áp dụng. Nếu như vấn đề là rất
nghiêm trọng và một biện pháp sửa chữa khẩn cấp là cần thiết vì
những lý do kinh doanh thì một RFC Khẩn cấp nên được xử lý bởi Hội
đồng Tư vấn Thay đổi Khẩn cấp (ECAB). Nói cách khác, RFC nên
tuân thủ các quy trình Quản lý Thay đổi đã được thiết lập cho kiểu
thay đổi đó – và giải pháp nên được áp dụng chi khi nào thay đổi đã
được phê duyệt và lập lịch trình để phát hành. Trong lúc đó, KEDB
nên được sử dụng để giúp giải quyết một cách nhanh chóng bất kỳ
sự cố/vấn đề xảy ra tiếp theo.
Lưu ý: Có thể có một số vấn đề mà một Đề án kinh doanh không thể

được biện minh (ví dụ, khi tác động bị hạn chế nhưng chi phí giải
quyết sẽ cực kỳ cao). Trong những trường hợp như vậy, một quyết
định có thể được đưa ra để Hồ sơ Sự cố mở ra nhưng sử dụng một
mô tả về giải pháp thay thế trong Hồ sơ Lỗi Đã biết để phát hiện và
giải quyết mọi trường hợp tái diễn một cách nhanh chóng. Cần lưu ý
sử dụng mã thích hợp để gắn cờ cho Hồ sơ Sự cố đang mở để nó
không bị tính vào hiệu suất của nhóm đang thực hiện quy trình và
để không diễn ra quá trình làm lại trái phép.
4.4.5. 9 Đóng v ấ n đ ề
Khi bất kỳ thay đổi nào đã được hoàn tất (và được xem xét một cách
thành công) và giải pháp đã được áp dụng, Hồ sơ Sự cố nên được
đóng lại một cách chính thức - cũng như với bất kỳ Hồ sơ Sự cố liên
quan nào vẫn đang mở. Một kiểm tra nên được tiến hành tại thời
điểm này để đảm bảo rằng hồ sơ có chứa một mô tả lịch sử đầy đủ
về mọi sự kiện - và nếu không thì hồ sơ phải được cập nhật.
Trạng thái của bất kỳ Hồ sơ Lỗi Đã biết có liên quan nào phải được
cập nhật để chỉ ra rằng rằng giải pháp đã được áp dụng.
4.4.5. 10 Xem x ét V ấ n đ ề n g hiêm tr ọng

Sau mỗi vấn đề nghiêm trọng (như đã được xác định bởi hệ thống ưu
tiên của tổ chức), trong khi những kỷ ức vẫn còn mới mẻ, một quá
trình xem xét nên được tiến hành để rút ra bất kỳ bài học nào cho
tương lai. Cụ thể, việc xem xét nên kiểm tra:
 Những điều đã được thực hiện một cách chính xác,

 Những điều đã bị thực hiện sai,
 Những gì có thể được thực hiện tốt hơn trong tương lai,
 Làm thế nào để ngăn ngừa sự tái diễn,
 Liệu có bất kỳ trách nhiệm nào của bên thứ ba hay không và có
cần thực hiện các hành động tiếp theo hay không.
Những đánh giá như vậy có thể được sử dụng như một phần của các
hoạt động đào tạo và nâng cao nhận thức cho nhân viên hỗ trợ - và
bất kỳ bài học kinh nghiệm nào cũng nên được ghi lại trong các thủ
tục, hướng dẫn công việc, kịch bản chẩn đoán hoặc Hồ sơ Lỗi Đã
biết thích hợp. Người quản lý Vấn đề tạo điều kiện cho phiên họp và
ghi lại bất kỳ hành động đã thỏa thuận nào.
Những kiến thức học được từ quá trình xem xét nên được kết hợp
vào một cuộc họp đánh giá dịch vụ với khách hàng doanh nghiệp để
đảm bảo rằng khách hàng nhận thức được về các hành động đã được
thực hiện và về các kế hoạch để ngăn ngừa các sự cố nghiêm trọng
xảy ra trong tương lai. Điều này giúp cải thiện sự hài lòng của khách
hàng và đảm bảo với doanh nghiệp rằng Vận hành Dịch vụ đang xử
lý các sự cố nghiêm trọng một cách có trách nhiệm và làm việc một
cách tích cực để ngăn chặn sự cố tái diễn trong tương lai.
4.4.5. 11 Các l ỗi đư ợ c phát hi ện tr o ng mô i trư ờ n g

phát tri ển
Hiếm có ứng dụng, hệ thống hoặc bản phát hành phần mềm mới nào
mà hoàn toàn không có lỗi. Có nhiều khả năng rằng, trong quá trình
kiểm nghiệm các ứng dụng, hệ thống hoặc bản phát hành mới như
vậy, một hệ thống ưu tiên sẽ được sử dụng để loại bỏ các lỗi nghiêm
trọng hơn, nhưng có thể là các lỗi nhỏ không được sửa - thường là
bởi vì sự cân bằng được thực hiện giữa việc cung cấp chức năng mới
cho doanh nghiệp càng nhanh càng tốt và việc đảm bảo mã hoặc
thành phần hoàn toàn không có lỗi.
Khi một quyết định được đưa ra để phát hành một thứ gì đó vào môi
trường sản xuất mà có bao gồm những khiếm khuyết đã biết, những
khiếm khuyết này phải được ghi lại là Lỗi Đã biết trong KEDB, cùng
với chi tiết về các biện pháp xử lý hoặc các hoạt động giải quyết.
Nên có một bước chính thức trong quá trình chấp thuận thử nghiệm
để đảm bảo rằng quá trình chuyển giao này luôn luôn diễn ra (xem
ấn phẩm Chuyển tiếp Dịch vụ).
Kinh nghiệm cho thấy nếu điều này không xảy ra sẽ dẫn đến chi phí
hỗ trợ cao hơn rất nhiều khi người dùng bắt đầu gặp lỗi và phát sinh
nên các sự cố cần phải chẩn đoán lại và khắc phục lại toàn bộ!

tương tác qua l ạ i g i ữa các quy trình
Phần lớn các Hồ sơ Sự cố sẽ được kích hoạt để phản ứng với một
hoặc nhiều sự cố và rất nhiều Hồ sơ sẽ được nêu ra hoặc khởi đầu
thông qua nhân viên của Bộ phận Hỗ trợ Dịch vụ. Những Hồ sơ Sự cố
khác và Hồ sơ Lỗi Đã biết tương ứng, có thể được kích hoạt trong
quá trình kiểm nghiệm, đặc biệt là những giai đoạn sau của kiểm
nghiệm như Kiểm nghiệm/Thử nghiệm Chấp thuận Người dùng (User
Acceptance Testing - UAT), nếu một quyết định được đưa ra để tiếp
tục phát hành ngay cả khi một số lỗi đã được biết. Các nhà cung cấp
có thể kích hoạt nhu cầu đối với một số Hồ sơ Sự cố thông qua việc
thông báo về các lỗi tiềm ẩn hoặc các khiếm khuyết đã biết trong
sản phẩm hoặc dịch vụ của họ (ví dụ, cảnh báo có thể được đưa ra
liên quan đến việc sử dụng một Đơn vị Cấu hình cụ thể và một Hồ sơ
Sự cố có thể được đưa ra để tạo điều kiện cho việc điều tra bởi
nhân viên về tình trạng của các điều kiện của các Đơn vị Cấu hình
trong Cơ sở hạ tầng CNTT của tổ chức).
Mối quan hệ chủ yếu giữa Quản lý Sự cố và Quản lý Vấn đề đã được

thảo luận chi tiết trong các đoạn 4.2.6 và 4.4.5.1. Các tương tác
chính khác bao gồm:
 Chuyển tiếp Dịch vụ:
o Quản lý Thay đổi: Quản lý Vấn đề đảm bảo rằng mọi giải
pháp hoặc cách giải quyết đòi hỏi sự thay đổi đối với Đơn
vị Cấu hình đều được đệ trình thông qua Quản lý Thay đổi
thông qua một RFC. Quản lý Thay đổi sẽ giám sát tiến
trình của những thay đổi này và thông báo cho Quản lý
Vấn đề. Quản lý Vấn đề cũng tham gia vào việc khắc phục
tình trạng do các thay đổi không thành công gây ra.
o Quản lý Cấu hình: Quản lý Vấn đề sử dụng CMS để xác
định các Đơn vị Cấu hình bị lỗi và cũng để xác định tác
động của các vấn đề và giải pháp. CMS cũng có thể được
sử dụng để hình thành nên cơ sở cho KEDB và lưu giữ
hoặc tích hợp với Hồ sơ Vấn đề.
o Quản lý Phát hành và Triển khai: Chịu trách nhiệm đưa
các bản khắc phục lỗi của vấn đề vào môi trường thực tế
(live environment). Nó cũng hỗ trợ cho việc đảm bảo rằng
các lỗi đã biết tương ứng được chuyển từ Cơ sở dữ liệu
Lỗi Đã biết đang phát triển sang Cơ sở dữ liệu Lỗi Đã biết
thực tế. Quản lý Sự cố sẽ hỗ trợ trong việc giải quyết các
vấn đề do lỗi trong quá trình phát hành.
 Thiết kế dịch vụ
o Quản lý Tính sẵn sàng: Liên quan đến việc xác định cách
làm giảm thiểu thời gian chết và gia tăng thời gian hoạt
động. Do vậy, nó có mối quan hệ chặt chẽ với Quản lý
Vấn đề, đặc biệt là trong các lĩnh vực chủ động. Phần lớn
thông tin quản lý sẵn có trong Quản lý Vấn đề sẽ được
truyền đạt cho Quản lý Tính sẵn sàng.
o Quản lý Công suất: Một số vấn đề sẽ đòi hỏi sự điều tra
bởi các nhóm và các kỹ thuật Quản lý Công suất, ví dụ,
các vấn đề về hiệu suất. Quản lý Công suất cũng sẽ hỗ
trợ trong việc đánh giá các biện pháp chủ động. Quản lý
Vấn đề cung cấp thông tin quản lý liên quan đến chất
lượng của các quyết định được đưa ra trong quá trình Lập
kế hoạch Công suất.
o Tính liên tục của dịch vụ CNTT: Quản lý Sự cố đóng vai
trò như một điểm đi vào (entry point) của Quản lý Tính
liên tục Dịch vụ CNTT, nơi một vấn đề quan trọng vẫn
chưa được giải quyết trước khi nó bắt đầu có tác động lớn
đến doanh nghiệp.
 Tiếp tục cải thiện chất lượng dịch vụ
o Quản lý Mức Dịch vụ: Việc xảy ra các sự cố và vấn đề ảnh
hưởng đến mức cung cấp dịch vụ được đo lường bởi SLM.
Quản lý Vấn đề góp phần cải thiện các mức dịch vụ và
thông tin quản lý của nó được sử dụng làm cơ sở của một
số thành phần đánh giá SLA. SLM cũng cung cấp các
thông số trong đó Quản lý Vấn đề hoạt động, chẳng hạn
như thông tin tác động và ảnh hưởng đến các dịch vụ của
các giải pháp đã được đề xuất và các biện pháp chủ động.
 Chiến lược dịch vụ
o Quản lý Tài chính: Hỗ trợ cho việc đánh giá tác động của
các giải pháp hoặc biện pháp giải quyết đã được đề xuất,
cũng như Phân tích Giá trị Đau (Pain Value Analysis).
Quản lý Vấn đề cung cấp thông tin quản lý về chi phí việc
giải quyết và ngăn ngừa vấn đề, được sử dụng làm đầu
vào cho hệ thống ngân sách và kế toán cũng như tính
toán Tổng chi phí sở hữu.
4.4.7. 1 CMS
CMS sẽ nắm giữ các chi tiết của mọi thành phần của Cơ sở hạ tầng
CNTT cũng như mối quan hệ giữa các thành phần này. Nó sẽ đóng
vai trò như một nguồn vô giá để chẩn đoán vấn đề và để đánh giá
tác động của vấn đề (ví dụ, nếu đĩa cứng này bị lỗi, những dữ liệu
nào đang được lưu trên đĩa đó, dịch vụ nào sử dụng những dữ liệu
đó, người dùng nào đang sử dụng những dịch vụ đó?). Vì nó cũng
nắm giữ những chi tiết về các hoạt động trước đó, nó cũng có thể
được sử dụng như một nguồn dữ liệu lịch sử vô giá để giúp xác định
những khuynh hướng hoặc điểm yếu tiềm ẩn – một phần then chốt
của Quản lý Vấn đề Chủ động (xem ấn phẩm Liên tục Cải tiến Dịch
vụ).
4.4.7. 2 Cơ s ở dữ l iệ u L ỗi Đã bi ế t
Mục đích của Cơ sở dữ liệu Lỗi Đã biết là hỗ trợ việc lưu trữ kiến
thức trước đây về các sự cố và vấn đề - và cách mà chúng được
khắc phục - để cho phép chẩn đoán và giải quyết nhanh hơn nếu
chúng tái diễn.
Hồ sơ Lỗi Đã biết nên chứa những chi tiết chính xác về lỗi và các
triệu chứng đã xảy ra, cùng với chi tiết chính xác về bất kỳ biện
pháp giải quyết hoặc hành động giải quyết nào có thể được thực
hiện để khôi phục dịch vụ và/hoặc giải quyết sự cố. Một tổng số sự
cố cũng sẽ hữu ích để xác định tần suất mà sự cố có khả năng tái
diễn và ảnh hưởng đến các ưu tiên, v.v…
Nên lưu ý rằng một Đề án Kinh doanh đối với một giải pháp bền
vững cho một số vấn đề có thể sẽ không tồn tại. Ví dụ, nếu như một
vấn đề không gây ra gián đoạn nghiêm trọng và tồn tại một cách
giải quyết và/hoặc chi phí của việc giải quyết vấn đề lớn hơn nhiều
so với lợi ích của một giải pháp vĩnh viễn thì có thể đưa ra quyết
định để chấp nhận sự tồn tại của vấn đề. Tuy nhiên, đó vẫn là một
mong muốn để chẩn đoán và triển khai một giải pháp thay thế càng
nhanh càng tốt, vốn là nơi KEDB có thể hỗ trợ.
Điều thiết yếu là bất kỳ dữ liệu nào được đưa vào cơ sở dữ liệu đều
phải có thể được truy xuất một cách nhanh chóng và chính xác.
Người quản lý Vấn đề phải được đào tạo đầy đủ và quen thuộc với
các phương pháp/thuật toán tìm kiếm được sử dụng bởi cơ sở dữ
liệu đã được chọn và nên đảm bảo một cách cẩn trọng rằng khi các
hồ sơ mới được thêm vào, các tiêu chí chủ yếu để tìm kiếm có liên
quan được đưa vào một cách chính xác.
Nên cẩn trọng để tránh trùng lặp các hồ sơ (tức là cùng một vấn đề
nhưng được mô tả theo hai hoặc nhiều cách dưới dạng các hồ sơ
riêng biệt). Để tránh điều này, Người quản lý Sự cố phải là người
duy nhất có thể nhập một hồ sơ mới. Các nhóm hỗ trợ khác cũng
nên được chấp thuận, thực sự được khuyến khích, để đề xuất các hồ
sơ mới, nhưng những hồ sơ này phải được Người quản lý Vấn đề xem
xét trước khi được nhập vào KEDB. Trong các tổ chức lớn, nơi nhân
viên Quản lý Vấn đề tồn tại ở nhiều địa điểm nhưng chỉ một KEDB
duy nhất được sử dụng (khuyến nghị!), một thủ tục phải được thống
nhất giữa tất cả nhân viên Quản lý Vấn đề để đảm bảo rằng sự trùng
lặp như vậy không thể xảy ra. Điều này có thể liên quan đến việc chỉ
định một nhân viên làm Người quản lý KEDB trung tâm.
KEDB nên được sử dụng trong giai đoạn Chẩn đoán Sự cố và Vấn đề
để cố gắng đẩy nhanh quá trình giải quyết - và các hồ sơ mới phải
được bổ sung càng nhanh càng tốt khi một vấn đề mới đã được xác
định và được chẩn đoán.
Mọi nhân viên hỗ trợ nên được đào tạo đầy đủ và thông thạo về
những giá trị mà KEDB có thể mang lại và cách mà nó (KEDB) nên
được sử dụng như thế nào. Họ nên có khả năng truy xuất và sử dụng
dữ liệu một cách dễ dàng.
Lưu ý: Một số công cụ/triển khai có thể chọn phác họa các Lỗi Đã
biết chỉ đơn giản bằng cách thay đổi một trường trong Hồ sơ Vấn đề
ban đầu. Điều này có thể được chấp thuận với điều kiện có cùng
mức chức năng.
KEDB, giống như CMS, hình thành nên một Hệ thống Quản lý Kiến
thức Dịch vụ (SKMS) lớn hơn được minh họa trong Hình 4.6. Thông
tin thêm về SKMS có thể được tìm thấy trong ấn phẩm Chuyển tiếp
Dịch vụ.
Hình 4.6 – Hệ thống Quản lý Kiến thức Dịch vụ
Các chỉ số dưới đây nên được sử dụng để phán đoán về tính hiệu
quả và hiệu suất của quy trình Quản lý Vấn đề, hoặc hoạt động của
nó:
 Tổng số lượng các vấn đề đã được ghi nhận trong một khoảng
thời gian (là một thước đo kiểm soát),
 Tỷ lệ phần trăm các vấn đề đã được giải quyết trong phạm vi
đích nhắm mục tiêu SLA (và tỷ lệ phần trăm vấn đề không được
giải quyết!),
 Số lượng và tỷ lệ phần trăm các vấn đề vượt quá đích nhắm
mục tiêu của chúng về thời gian giải quyết,
 Công việc tồn đọng của các vấn đề chưa được giải quyết và
khuynh hướng (tĩnh, giảm hoặc tăng?),
 Chi phí trung bình để xử lý một vấn đề,
 Số lượng các vấn đề nghiêm trọng (đã mở và đã đóng và tồn
đọng),
 Tỷ lệ phần trăm các Đánh giá Vấn đề Nghiêm trọng thành công
đã tiến hành,
 Số lượng các Lỗi Đã biết được thêm vào KEDB,
 Tỷ lệ phần trăm chính xác của KEDB (từ các cuộc kiếm toán cơ
sở dữ liệu),
 Tỷ lệ phần trăm các Đánh giá Vấn đề Nghiêm trọng đã hoàn tất
thành công và đúng hạn.
Mọi chỉ số nên được chia nhỏ theo loại, tác động, mức độ nghiêm
trọng, tính khẩn cấp và độ ưu tiên và được so sánh với các chu kỳ
trước đó.
4.4.9 N hững Thách th ức, các Y ếu t ố T hành công
Một yếu tố phụ thuộc chính đối với Quản lý Sự cố là việc thiết lập
một quy trình và các công cụ Quản lý Sự cố có hiệu quả. Việc này sẽ
đảm bảo rằng các vấn đề được xác định sớm nhất có thể và càng
nhiều công việc sơ tuyển được thực hiện càng tốt. Tuy nhiên, điều
quan trọng là hai quy trình phải có các tương tác chính thức và các
phương thức làm việc chung. Điều này ngụ ý những điều sau đây:
 Việc liên kết các công cụ Quản lý Sự cố và Quản lý Vấn đề,

 Khả năng liên hệ các Hồ sơ Sự cố và Hồ sơ Vấn đề,
 Nhân viên tuyến thứ hai và thứ ba nên có mối quan hệ làm việc
tốt với nhân viên ở tuyến đầu tiên
 Đảm bảo rằng tác động kinh doanh đều được hiểu rõ bởi tất cả
các nhân viên làm việc trong lĩnh vực giải quyết vấn đề.
Ngoài ra, điều quan trọng là Quản lý Vấn đề có khả năng sử dụng
tất cả các tài nguyên Quản lý Cấu hình và Kiến thức có sẵn.
Một CSF khác là đào tạo liên tục các nhân viên kỹ thuật về cả khía
cạnh kỹ thuật của công việc của họ cũng như hàm ý kinh doanh của
các dịch vụ mà họ hỗ trợ và các quy trình mà họ sử dụng.
4.5 Quản lý Truy cập

Quản lý Truy cập là quy trình cấp quyền cho người dùng được ủy
quyền để sử dụng một dịch vụ, trong khi ngăn chặn truy cập đối với
những người dùng không được ủy quyền. Nó cũng còn được gọi là
Quản lý Quyền (Rights Management) hoặc Quản lý Danh tính
(Identity Management) trong các t ổ chức khác.
Quản lý Truy cập cung cấp quyền cho người dùng để có khả năng sử
dụng một dịch vụ hoặc một nhóm các dịch vụ. Do đó, đây là sự thực
thi các chính sách và các hành động đã xác định trong Quản lý Bảo
mật và Quản lý Tính sẵn sàng.
4.5.2 Phạ m vi
Quản lý truy cập là việc thực thi một cách hiệu quả cả Quản lý Tính
sẵn sàng lẫn Quản lý Bảo mật Thông tin, trong đó nó cho phép tổ
chức quản lý tính bảo mật, tính sẵn sàng và tính toàn vẹn của dữ
liệu và tài sản trí tuệ của tổ chức.
Quản lý Truy cập đảm bảo rằng người dùng được cấp quyền sử dụng
một dịch vụ, nhưng nó không đảm bảo rằng quyền truy cập này luôn
sẵn sàng vào mọi thời điểm đã thỏa thuận - điều này được cung cấp
bởi Quản lý Tính sẵn sàng.
Quản lý Truy cập là một quá trình được thực thi bởi mọi chức năng
Quản lý Kỹ thuật và Quản lý Ứng dụng và thường không phải là một
chức năng tách biệt. Tuy nhiên, có khả năng là sẽ có một điểm phối
hợp kiểm soát duy nhất, thường là trong Quản lý Vận hành CNTT
hoặc trên Bộ phận Hỗ trợ Dịch vụ.
Quản lý Truy cập có thể được khởi đầu bằng Yêu cầu Dịch vụ thông
qua Bộ phận Dịch vụ.

Quản lý Truy cập cung cấp những giá trị sau đây:
 Truy cập tới các dịch vụ được kiểm soát đảm bảo rằng tổ chức
có khả năng duy trì tính bảo mật thông tin của mình một cách
hiệu quả hơn,
 Nhân viên có được đúng mức truy cập để thực thi công việc
của họ một cách hiệu quả,
 Ít có khả năng xảy ra lỗi khi nhập dữ liệu hoặc khi sử dụng một
dịch vụ quan trọng bởi một người dùng chưa có đủ kỹ năng (ví
dụ, các hệ thống kiểm soát sản xuất),
 Khả năng kiểm toán việc sử dụng các dịch vụ và theo dõi việc
lạm dụng các dịch vụ,
 Khả năng thu hồi quyền truy cập dễ dàng hơn khi cần thiết –
một cân nhắc bảo mật quan trọng,
 Có thể cần thiết để tuân thủ quy định (ví dụ, SOX, HIPAA,
COBIT).

Quản lý Truy cập là quy trình cho phép người dùng sử dụng các dịch
vụ được lập thành tài liệu trong Mục lục Dịch vụ. Nó bao gồm những
khái niệm cơ bản dưới đây:
 Quyền truy cập đề cập đến cấp độ và mức độ của một chức
năng hoặc dữ liệu của dịch vụ mà một người dùng được cấp
quyền để sử dụng.
 Danh tính đề cập đến thông tin về họ (người dùng) để phân
biệt họ như là một cá nhân và những gì xác nhận tình trạng
của họ trong tổ chức. Theo định nghĩa, Danh tính của một
người dùng là duy nhất đối với người dùng đó. (Điều này được
đề cập chi tiết hơn trong đoạn 4.5.7.1).
 Quyền (cũng còn được gọi là đặc quyền – privileges) đề cập
đến thiết lập thực tế mà theo đó, một người dùng được cung
cấp quyền truy cập đến một dịch vụ hoặc một nhóm các dịch
vụ. Thông thường, quyền hoặc các mức độ truy cập, bao gồm
đọc, ghi, thực thi, thay đổi, xóa.
 Các dịch vụ hoặc các nhóm dịch vụ. Hầu hết người dùng
không sử dụng chỉ một dịch vụ, và người dùng thực hiện một
tập hợp các hành động tương tự sẽ sử dụng một tập hợp các
dịch vụ tương tự. Thay vì cung cấp quyền truy cập cho từng
dịch vụ cho từng người dùng một cách tách biệt, sẽ có hiệu
quả hơn khi có khả năng cấp cho từng người dùng – hoặc nhóm
người dùng – quyền truy cập tới toàn thể tập hợp các dịch vụ
mà họ đã được cấp quyền sử dụng tại cùng một thời điểm.
(Điều này được đề cập chi tiết hơn trong đoạn 4.5.7.2).
 Các Dịch vụ Danh bạ đề cập đến một kiểu công cụ cụ thể
được sử dụng để quản lý các quyền và quyền truy cập. Chúng
được thảo luận trong phần 5.8.

quy trì nh
4.5.5. 1 Y êu c ầ u quy ề n truy c ậ p

Quyền truy cập (hoặc hạn chế) có thể được yêu cầu bằng cách sử
dụng một trong bất kỳ các cơ chế nào sau đây, bao gồm:
 Một yêu cầu tiêu chuẩn được tạo ra bởi hệ thống Nhân sự
(Human Resource system). Việc này thường được thực hiện bất
kể khi nào một người được tuyển, thăng chức, điều chuyển
hoặc khi họ rời khỏi công ty.
 Một Yêu cầu Thay đổi.
 Một Yêu cầu Dịch vụ được đệ trình thông qua hệ thống Thực
hiện Yêu cầu.
 Bằng cách thực thi một tập lệnh kịch bản hoặc một lựa chọn
được cấp phép trước (ví dụ, tải về một ứng dụng từ một dàn
máy chủ khi cần thiết).
Các quy tắc đối với việc yêu cầu quyền truy cập thường được ghi
nhận lại như một phần của Mục lục Dịch vụ.
4.5.5. 2 Xác mi nh
Quản lý Truy cập cần phải xác minh mọi yêu cầu truy cập tới một
dịch vụ CNTT từ hai khía cạnh sau:
 Rằng người dùng đang yêu cầu quyền truy cập chính là người
mà họ nói rằng họ là người đó (nghĩa là Nguyễn Văn A chính là
Nguyễn Văn A),
 Rằng họ có một yêu cầu hợp lệ cho dịch vụ đó.
Loại đầu tiên thường đạt được bởi việc người dùng cung cấp tên
người dùng và mật khẩu của họ. Tùy thuộc vào chính sách bảo mật
của tổ chức, việc sử dụng tên người dùng và mật khẩu thường được
chấp thuận để làm bằng chứng rằng người đó là một người dùng hợp
pháp. Tuy nhiên, đối với các dịch vụ nhạy cảm hơn có thể cần thêm
nhận dạng bổ sung (sinh trắc học, sử dụng khóa truy cập điện tử
hoặc thiết bị mã hóa, v.v...).
Loại thứ hai sẽ đòi hỏi một số xác minh độc lập, khác với yêu cầu
của người dùng. Ví dụ,
 Thông báo từ Bộ phận Nhân sự rằng người đó là một nhân viên
mới và yêu cầu cả tên người dùng lẫn quyền truy cập vào một
bộ dịch vụ tiêu chuẩn.
 Thông báo từ Bộ phận Nhân sự rằng người dùng đã được thăng
chức và yêu cầu quyền truy cập vào các nguồn bổ sung.
 Sự ủy quyền từ một người quản lý thích hợp (đã được xác định
trong quy trình).
 Đệ trình một Yêu cầu Dịch vụ (với bằng chứng hỗ trợ) thông
qua Bộ phận Hỗ trợ Dịch vụ.
 Đệ trình một RFC (với bằng chứng hỗ trợ) thông qua Quản lý
Thay đổi, hoặc thực hiện một Thay đổi tiêu chuẩn đã được xác
định trước.
 Một chính sách nêu rõ rằng người dùng có thể có quyền truy
cập vào một dịch vụ tùy chọn nếu họ cần nó.
Đối với các dịch vụ mới, Hồ sơ Thay đổi nên chỉ định người dùng
hoặc nhóm người dùng nào sẽ có quyền truy cập vào Dịch vụ. Quản
lý Truy cập sau đó sẽ kiểm tra xem mọi người dùng vẫn hợp lệ và tự
động cung cấp quyền truy cập như đã được chỉ định trong RFC.
4.5.5. 3 Cung c ấ p quy ền ( truy c ậ p)

Quản lý Truy cập không quyết định ai có quyền truy cập vào những
dịch vụ CNTT nào. Thay vào đó, Quản lý Truy cập thực thi các chính
sách và quy định đã được xác định trong Chiến lược Dịch vụ và Thiết
kế Dịch vụ. Quản lý Truy cập thực thi các quyết định để hạn chế
hoặc cung cấp quyền truy cập, thay vì đưa ra quyết định.
Ngay sau khi người dùng đã được xác minh, Quản lý Truy cập sẽ
cung cấp cho người dùng đó các quyền để sử dụng dịch vụ được yêu
cầu. Trong hầu hết các trường hợp, điều này sẽ dẫn đến việc yêu
cầu cho mọi nhóm hoặc bộ phận liên quan đến việc hỗ trợ dịch vụ đó
để thực hiện hành động cần thiết. Nếu có thể, các tác vụ này nên
được tự động hóa.
Càng có nhiều vai trò và nhóm tồn tại thì càng có nhiều khả năng
Xung đột Vai trò sẽ nảy sinh. Xung đột Vai trò trong ngữ cảnh này
đề cập đến một tình huống trong đó hai vai trò hoặc hai nhóm cụ
thể, nếu được chỉ định cho một người dùng, sẽ tạo ra các vấn đề về
sự phân tách nhiệm vụ hoặc xung đột về lợi ích. Các ví dụ về điều
này bao gồm:
 Một vai trò yêu cầu quyền truy cập chi tiết, trong khi vai trò
khác ngăn chặn quyền truy cập đó.
 Hai vai trò cho phép một người dùng thực hiện hai nhiệm vụ
không nên được kết hợp (ví dụ, một nhà thầu có thể ghi lại
thời gian biểu của họ cho một dự án và sau đó phê duyệt mọi
khoản thanh toán cho công việc cho cùng một dự án).
Xung đột Vai trò có thể tránh được bằng cách tạo ra các vai trò và
nhóm một cách cẩn thận, nhưng thường thì chúng do các chính sách
và quyết định được đưa ra bên ngoài phạm vi Vận hành Dịch vụ -
hoặc do doanh nghiệp hoặc do các nhóm dự án khác nhau làm việc
trong quá trình Thiết kế Dịch vụ gây ra. Trong mỗi trường hợp, sự
xung đột phải được lập thành văn bản và được chuyển đến các bên
liên quan để giải quyết.
Bất cứ khi nào vai trò và nhóm đã được xác định, có khả năng là
chúng đã được xác định quá rộng hoặc quá hẹp. Sẽ luôn có những
người dùng cần một thứ gì đó hơi khác so với những vai trò đã được
xác định trước. Trong những trường hợp này, có thể sử dụng các vai
trò tiêu chuẩn và sau đó thêm hoặc bớt các quyền cụ thể theo yêu
cầu - tương tự như khái niệm các Đường cơ sở và Biến thể trong
Quản lý Cấu hình (xem ấn phẩm Chuyển tiếp Dịch vụ). Tuy nhiên,
quyết định thực hiện điều này không nằm trong tay cá nhân nhân
viên vận hành. Mỗi ngoại lệ phải được điều phối bởi Quản lý Truy
cập và được phê duyệt thông qua quy trình ban đầu.
Quản lý Truy cập nên thực hiện một đánh giá thường xuyên về các
vai trò và nhóm mà nó đã tạo ra và quản lý để đảm bảo rằng chúng
phù hợp với các dịch vụ mà CNTT cung cấp và hỗ trợ - và các vai
trò/nhóm lỗi thời hoặc không mong muốn nên được loại bỏ.
4.5.5. 4 Giám s át tình tr ạ ng c ủa nhân d ạ ng

Khi người dùng làm việc trong tổ chức, những vai trò của họ thay
đổi và kéo theo là nhu cầu của họ trong việc truy cập vào các dịch
vụ. Các ví dụ về những thay đổi bao gồm:
 Thay đổi công việc. Trong trường hợp này, người dùng sẽ có
khả năng cần truy cập vào các dịch vụ khác hoặc các dịch vụ
bổ sung.
 Thăng hoặc giáng chức. Người dùng sẽ có khả năng sử dụng
cùng một bộ các dịch vụ, tuy nhiên sẽ cần truy cập đến các
mức khác nhau của chức năng hoặc dữ liệu.
 Chuyển đổi. Trong tình huống này, người dùng có thể cần truy
cập một cách chính xác đến cùng một bộ các dịch vụ, tuy
nhiên, ở một khu vực khác với những thực tiễn công việc khác
nhau và bộ dữ liệu khác nhau.
 Nghỉ việc hoặc tử vong. Quyền truy cập cần được hoàn toàn
loại bỏ để ngăn chặn tên người dùng được sử dụng như là một
lỗ hổng bảo mật.
 Nghỉ hưu. Trong rất nhiều tổ chức, một nhân viên nghỉ hưu
vẫn có thể có quyền truy cập vào một bộ các dịch vụ bị giới
hạn, bao gồm các hệ thống phúc lợi hoặc các hệ thống cho
phép họ mua lại các sản phẩm của công ty với mức giá được
giảm.
 Hành động kỷ luật. Trong một số trường hợp, tổ chức sẽ đòi
hỏi một sự hạn chế tạm thời để ngăn chặn người dùng truy cập
vào một số hoặc toàn bộ các dịch vụ mà họ thường được truy
cập vào. Nên có một tính năng trong quy trình và các công c ụ
để thực hiện việc này, thay vì phải xóa và tạo lại quyền truy
cập của người dùng.
 Sa thải. Khi một nhân viên hoặc nhà thầu bị sa thải hoặc khi
hành động pháp lý dc thực hiện để chống lại khách hàng (ví
dụ, vỡ nợ thanh toán cho các sản phẩm được mua trên
Internet), quyền truy cập phải được thu hồi ngay lập tức.
Ngoài ra, Quản lý Truy cập, phối hợp với Quản lý Bảo mật
Thông tin, nên thực hiện các biện pháp tích cực để ngăn chặn
và phát hiện hành động độc hại chống lại tổ chức từ người
dùng đó.
Quản lý Truy cập nên tìm hiểu và ghi nhận lại Vòng đời Người dùng
điển hình cho từng kiểu người dùng và sử dụng nó để tự động hóa
quy trình. Các công cụ Quản lý Truy cập nên cung cấp những tính
năng cho phép một người dùng được chuyển từ một trạng thái sang
trạng thái khác, hoặc từ nhóm này sang nhóm khác, một cách dễ
dàng và với một dấu vết kiểm toán.
4.5.5. 5 Ghi nh ậ t ký và theo dõi q uy ền t ruy c ậ p
Quản lý Truy cập không chỉ nên ứng phó với các yêu cầu. Nó cũng
nên chịu trách nhiệm cho việc đảm bảo rằng những quyền mà họ có
đang được sử dụng một cách đúng đắn.
Về mặt này, Giám sát và Kiểm soát Truy cập phải được bao gồm
trong các hoạt động giám sát của mọi chức năng Quản lý Kỹ thuật và
Quản lý Ứng dụng cũng như tất cả các quy trình Vận hành Dịch vụ.
Các trường hợp ngoại lệ nên được xử lý bởi Quản lý Sự cố, có thể sử
dụng các Mô hình Sự cố được thiết kế đặc biệt để ứng phó với việc
lạm dụng quyền truy cập. Nên lưu ý rằng khả năng hiển thị của các
hành động như vậy nên được hạn chế. Việc cung cấp thông tin này
cho tất cả những người có quyền truy cập vào hệ thống Quản lý Sự
cố sẽ làm lộ ra các lỗ hổng.
Quản lý Bảo mật Thông tin đóng một vai trò quan trọng trong việc
phát hiện ra những truy cập trái phép và so sánh nó với các quyền
đã được cung cấp bởi Quản lý Truy cập. Điều này sẽ đòi hỏi sự tham
gia của Quản lý truy cập trong việc xác định các tham số để sử dụng
trong các công cụ Phát hiện Xâm nhập.
Quản lý Truy cập cũng có thể được yêu cầu cung cấp một hồ sơ về
quyền truy cập cho các Dịch vụ cụ thể trong quá trình điều tra pháp
y. Nếu người dùng bị nghi ngờ là vi phạm chính sách, sử dụng tài
nguyên không phù hợp hoặc sử dụng gian lận dữ liệu, Quản lý Truy
cập có thể được yêu cầu cung cấp bằng chứng về ngày, giờ và thậm
chí cả nội dung về quyền truy cập của người dùng đó vào Dịch vụ cụ
thể. Điều này thường được cung cấp bởi nhân viên Vận hành của
dịch vụ đó, nhưng hoạt động như một phần của quy trình Quản lý
Truy cập.
4.5.5. 6 Loạ i b ỏ hoặ c h ạ n ch ế quy ền ( truy c ậ p)
Cũng giống như Quản lý Truy cập cung cấp quyền sử dụng một Dịch
vụ, nó cũng chịu trách nhiệm thu hồi các quyền đó. Một lần nữa, đây
không phải là một quyết định mà nó tự đưa ra. Thay vào đó, nó sẽ
thực thi các quyết định và chính sách được đưa ra trong Chiến lược
Dịch vụ và Thiết kế Dịch vụ cũng như các quyết định của các nhà
quản lý trong tổ chức.
Việc xóa bỏ quyền truy cập thường được thực hiện trong các trường
hợp sau:
 Tử vong,
 Thôi việc,
 Sa thải,
 Khi người dùng đã thay đổi vai trò và không còn yêu cầu quyền
truy cập vào dịch vụ,
 Di chuyển hoặc đi đến một khu vực áp dụng quyền truy cập khu
vực khác.
Trong các trường hợp khác, không nhất thiết phải xóa quyền truy
cập mà chỉ cần cung cấp những hạn chế chặt chẽ hơn. Những điều
này có thể bao gồm việc giảm mức độ, thời gian hoặc thời lượng
truy cập. Các tình huống mà quyền truy cập nên bị hạn chế bao
gồm:
 Khi người dùng đã thay đổi vai trò hoặc bị giáng cấp và không
còn yêu cầu mức độ truy cập như cũ,
 Khi người dùng đang được điều tra, nhưng vẫn yêu cầu quyền
truy cập vào các dịch vụ cơ bản, chẳng hạn như e-mail. Trong
trường hợp này, e-mail của họ có thể được quét thêm (nhưng
việc này sẽ cần được xử lý một cách rất cẩn thận và phải hoàn
toàn phù hợp với chính sách bảo mật của tổ chức),
 Khi người dùng rời khỏi tổ chức theo nhiệm vụ tạm thời và sẽ
không yêu cầu quyền truy cập vào dịch vụ đó trong một thời
gian.

tương tác gi ữa các quy tr ình
Quản lý Truy cập được kích hoạt bởi một yêu cầu để một người dùng
hoặc các người dùng truy cập vào một dịch vụ hoặc một nhóm các
dịch vụ. Việc này có thể khởi nguồn từ bất cứ điều nào sau đây:
 Một RFC. Điều này thường được sử dụng nhất cho các buổi giới
thiệu hoặc nâng cấp dịch vụ với quy mô lớn trong đó các quyền
của một số lượng lớn người dùng cần được cập nhật như một
phần của dự án.
 Một Yêu cầu Dịch vụ. Điều này thường được khởi nguồn thông
qua Bộ phận Hỗ trợ Dịch vụ hoặc trực tiếp vào hệ thống Thực
hiện Yêu cầu và được thực thi bởi các nhóm Quản lý Ứng dụng
hoặc Quản lý Kỹ thuật có liên quan.
 Một yêu cầu từ nhân viên Quản lý Nguồn Nhân lực thích hợp
(vốn nên được chuyển qua Bộ phận Hỗ trợ Dịch vụ). Điều này
thường được tạo ra như một phần của quy trình tuyển dụng,
thăng chức, chuyển vị trí và chấm dứt hoặc nghỉ hưu.
 Một yêu cầu từ người quản lý của một bộ phận, người có thể
đang thực hiện một vai trò nhân sự, hoặc là người có thể đưa
ra quyết định bắt đầu sử dụng một dịch vụ cho lần đầu tiên.
Quản lý Truy cập phải được liên kết với các quy trình Nguồn Nhân
lực để xác minh danh tính của người dùng cũng như để đảm bảo
rằng họ được cấp quyền sử dụng các dịch vụ được yêu cầu.
Quản lý Bảo mật Thông tin là một động cơ chính cho Quản lý Truy
cập vì nó sẽ cung cấp các chính sách bảo mật và bảo vệ dữ liệu
cũng như các công cụ cần thiết để thực thi Quản lý Truy cập.
Quản lý Thay đổi đóng một vai trò quan trọng như là phương tiện để
kiểm soát các yêu cầu truy cập thực tế. Đây là vì bất kỳ yêu cầu
truy cập nào vào một dịch vụ đều là một thay đổi, mặc dù nó thường
được xử lý dưới dạng một Thay đổi Tiêu chuẩn hoặc một Yêu cầu
Dịch vụ (có thể sử dụng một mô hình) một khi các tiêu chí truy cập
đã được thống nhất thông qua SLM.
SLM duy trì các thỏa thuận về quyền truy cập cho từng dịch vụ. Điều
này sẽ bao gồm các tiêu chí về người nào được quyền truy cập vào
từng dịch vụ, chi phí của quyền truy cập đó sẽ là bao nhiêu, nếu
phù hợp và cấp độ truy cập nào sẽ được cấp cho các kiểu người
dùng khác nhau (ví dụ, nhà quản lý hoặc nhân viên).
Cũng có một mối quan hệ chặt chẽ giữa Quản lý Truy cập và Quản lý
Cấu hình. CMS có thể được sử dụng để lưu trữ dữ liệu và được thẩm
tra để xác định chi tiết truy cập hiện tại.
4.5.7. 1 Nhân d ạ ng
Danh tính của người dùng là thông tin về cá nhân họ để phân biệt
họ với tư cách là một cá nhân và những gì xác minh trạng thái của
họ trong tổ chức. Theo định nghĩa, danh tính của người dùng là độc
nhất đối với người dùng đó. Vì sẽ có những trường hợp hai người
dùng chia sẻ cùng một phần thông tin chung (ví dụ, họ có cùng tên),
danh tính thường được thiết lập bằng cách sử dụng nhiều hơn một
phần thông tin, ví dụ,
 Tên,
 Địa chỉ nhà,
 Chi tiết liên hệ, ví dụ, điện thoại, địa chỉ e-mail, v.v…,
 Tài liệu vật lý, ví dụ, bằng lái xe, hộ chiếu, giấy đăng ký kết
hôn, v.v…
 Các số tham chiếu đến một tài liệu hoặc một mục nhập trong
cơ sở dữ liệu, ví dụ, mã số nhân viên, mã số thuế, mã số nhận
dạng chính phủ, số bằng lái xe, v.v…,
 Thông tin sinh trắc học, ví dụ, dấu vân tay, hình ảnh võng
mạc, mẫu nhận dạng giọng nói, DNA, v.v...,
 Ngày hết hạn (nếu có liên quan).
Một nhân dạng người dùng được cung cấp cho bất kỳ ai với một yêu
cầu hợp pháp để truy cập và các dịch vụ CNTT hoặc thông tin của tổ
chức. Chúng nên bao gồm:
 Nhân viên,
 Nhà thầu,
 Nhân viên của nhà thầu (ví dụ, các nhân viên kinh doanh, cá
nhân hỗ trợ, v.v…),
 Khách hàng (đặc biệt khi mua sản phẩm hoặc dịch vụ trên
Internet).
Hầu hết các tổ chức sẽ xác minh danh tính của một người dùng
trước khi họ kết nối vào tổ chức bằng cách yêu cầu một tập hợp con
của những thông tin nói trên. Tổ chức càng bảo mật thì các nhiều
thông tin được yêu cầu và chúng càng được kiểm tra một cách cẩn
thận.
Rất nhiều tổ chức sẽ phải đối mặt với nhu cầu cung cấp quyền truy
cập cho các nhân viên thời vụ hoặc tạm thời hoặc các nhà thầu/nhà
cung cấp. Việc quản lý quyền truy cập đối với những người này
thường được chứng minh là có vấn đề - việc đóng quyền truy cập
sau khi sử dụng thường khó quản lý, hoặc thậm chí, khó hơn việc
cung cấp truy cập ban đầu. Các thủ tục được xác định rõ ràng giữa
bộ phận CNTT và Nhân sự nên được thiết lập để bao gồm các kiểm
tra biện pháp an toàn dự phòng để đảm bảo rằng các quyền truy cập
được xóa bỏ ngay lập tức nếu chúng không còn hợp lý hoặc cần
thiết.
Khi một người dùng được cấp quyền truy cập đến một ứng dụng, nó
nên thực sự được xác lập bởi tổ chức (thường là Bộ phận Nhân sự
hoặc Bộ phận Bảo mật) rằng người dùng chính là người mà họ tuyên
bố.
Tại thời điểm này, mọi thông tin đó được điền đầy dủ và tập tin là
tương ứng với danh tính của một công ty, thường là một nhân viên
hoặc mã số nhà thầu và một danh tính để có thể được sử dụng để
truy cập vào nguồn tài nguyên và thông tin của công ty, thường là
một danh tính người dùng hoặc ‘tên người dùng/user name’ và mật
khẩu tương ứng.
4.5.7. 2 Ngư ờ i dùng, các nhóm, vai trò v à các nhóm
dịch v ụ
Mặc dù mỗi người dùng đều có một danh tính cá nhân, và từng dịch
vụ CNTT có thể được xem là một thực thể theo đúng nghĩa của nó,
thường sẽ rất hữu ích để nhóm chúng lại với nhau để từ đó chúng có
thể được quản lý một cách dễ dàng hơn. Thỉnh thoảng, thuật ngữ
‘biên dạng/hồ sơ người dùng [user profile]’ hoặc ‘biểu mẫu người
dùng [user template]’ hoặc ‘vai trò người dùng [user role]’ được sử
dụng để mô tả kiểu phân nhóm này.
Hầu hết các tổ chức đều có một bộ các dịch vụ tiêu chuẩn cho tất cả
những người dùng cá nhân, bất kể vị trí hoặc công việc của họ
(ngoại trừ khách hàng – những người không có bất kỳ khả năng hiển
thị nào đối với các dịch vụ hoặc quy trình nội bộ). Chúng thường
bao gồm các dịch vụ chẳng hạn như nhắn tin, tự động hóa công việc
văn phòng, Hỗ trợ Máy tính để bàn, điện thoại, v.v… Những người
dùng mới được tự động cung cấp những quyền để sử dụng các dịch
vụ này.
Tuy nhiên, hầu hết người dùng đều có một số vai trò chuyên biệt mà
họ thực hiện. Ví dụ, ngoài những dịch vụ tiêu chuẩn, người dùng
cũng thực hiện một vai trò Quản lý Tiếp thị (Marketing
Management), vốn đòi hỏi rằng họ phải có quyền truy cập đến một
số các công cụ và dữ liệu mô hình hóa tiếp thị và tài chính chuyên
biệt.
Một số các nhóm có thể có những yêu cầu đặc biệt – chẳng hạn như
những nhân viên thực địa hoặc làm việc tại nhà có thể phải quay số
hoặc sử dụng các kết nối Mạng Riêng Ảo (Virtual Private Network –
VPN), với các tác động bảo mật cần phải được quản lý một cách chặt
chẽ hơn.
Để khiến cho Quản lý Truy cập dễ dàng hơn trong việc cung cấp các
quyền thích hợp, nó (Quản lý Truy cập) sử dụng một mục lục tất cả
các vai trò trong tổ chức và những dịch vụ nào hỗ trợ cho từng vai
trò. Bản mục lục các vai trò này nên được biên dịch và duy trì bởi
Quản lý Truy cập kết hợp với bộ phận Nhân sự và thường được tự
động hóa trong các công cụ Dịch vụ Danh bạ (Directory Services)
(xem phần 5.8).
Ngoài việc đóng các vai trò khác nhau, ngư ời dùng cũng có thể
thuộc về các nhóm khác nhau. Ví dụ, mọi nhà thầu được yêu cầu
phải ghi lại thời gian biểu của họ trong một Hệ thống Thẻ Thời gian
(Time Card System) chuyên biệt, vốn không được người dùng sử
dụng. Quản lý Truy cập sẽ truy cập đến mọi vai trò mà một người
dùng sẽ đảm nhiệm cũng như các nhóm mà họ thuộc về và đảm bảo
rằng họ cung cấp quyền để sử dụng tất cả các dịch vụ tương xứng.
Lưu ý: Mọi dữ liệu được xử lý bởi người dùng sẽ là đối tượng của
luật bảo vệ dữ liệu (điều này hiện hữu trong hầu hết các khu vực địa
lý dưới hình thức này hoặc hình thức khác) vì vậy cần được xử lý và
bảo vệ như một phần của các thủ tục bảo mật của tổ chức.
Các chỉ số có thể được sử dụng để đo lường tính hiệu quả và hiệu
suất của Quản lý Truy cập bao gồm:
 Số lượng các yêu cầu truy cập (Yêu cầu Dịch vụ, RFC, v.v…),
 Các trường hợp truy cập đã được cấp, theo dịch vụ, người
dùng, bộ phận, v.v…
 Các trường hợp truy cập đã được cấp theo bộ phận hoặc cá
nhân đang cấp quyền,
 Số lượng các sự cố đòi hỏi phải thiết lập lại quyền truy cập,
 Số lượng các sự cố gây ra bởi việc thiết lập sai quyền truy cập.
4.5.9 N hững Thách th ức , các Y ếu t ố T hành công

Những điều kiện để Quản lý Truy cập thành công bao gồm:
 Khả năng xác minh danh tính của một người dùng (rằng một cá
nhân chính là người mà họ nói họ là người đó),
 Khả năng xác minh danh tính của một cá nhân hoặc cơ quan
phê duyệt,
 Khả năng xác minh rằng một người dùng đủ điều kiện để truy
cập đến một dịch vụ cụ thể,
 Khả năng liên kết nhiều quyền truy cập với một người dùng
riêng lẻ,
 Khả năng xác định trạng thái của một người dùng tại bất kỳ
thời điểm nào (ví dụ, xác định xem liệu họ có còn là nhân viên
của tổ chức hay không khi họ đăng nhập vào tổ chức),
 Khả năng quản lý những thay đổi đối với yêu cầu truy cập của
một người dùng,
 Khả năng hạn chế quyền truy cập đối với người dùng trái phép,
 Một cơ sở dữ liệu về mọi người dùng và quyền (truy cập) mà họ
đã từng được cấp.
4.6 Các hoạt động vận hành của các quy trình được
bao gồm trong các giai đoạn vòng đời khác
4.6.1 Q uả n lý Thay đ ổi
Quản lý Thay đổi chủ yếu được đề cập đến trong ấn phẩm Chuyển
tiếp Dịch vụ, tuy nhiên, có một số khía cạnh của Quản lý Thay đổi
mà nhân viên Vận hành Dịch vụ sẽ phải tham gia vào trên cơ sở
hàng ngày. Những khía cạnh này bao gồm:
 Việc đưa ra và đệ trình các RFC khi cần thiết để xử lý các sự cố

Vận hành Dịch vụ,
 Việc tham gia vào các cuộc họp CAB hoặc CAB/EC để đảm bảo
rằng những rủi ro, sự cố và quan điểm Vận hành Dịch vụ được
tính đến,
 Việc triển khai những thay đổi khi được thúc đẩy bởi Quản lý
Thay đổi khi chúng liên quan đến thành phần Vận hành Dịch vụ
hoặc các dịch vụ,
 Việc quay ngược những thay đổi khi được thúc đẩy bởi Quản lý
Thay đổi khi chúng liên quan đến thành phần Vận hành Dịch vụ
hoặc các dịch vụ,
 Việc giúp xác định và duy trì các mô hình thay đ ổi liên quan để
các thành phần Vận hành Dịch vụ hoặc các dịch vụ,
 Việc nhận được những lịch trình thay đổi và việc đảm bảo rằng
mọi nhân viên Vận hành Dịch vụ nhận thức được và được chuẩn
bị cho mọi thay đổi có liên quan,
 Việc sử dụng quy trình Quản lý Thay đổi đối với những thay đổi
tiêu chuẩn, thay đổi kiểu-vận hành.
4.6.2 Q uả n lý C ấ u hình
Quản lý Cấu hình chủ yếu được đề cập trong ấn phẩm Chuyển tiếp
Dịch vụ, tuy nhiên, có một số khía cạnh của Quản lý Cấu hình mà
nhân viên Vận hành Dịch vụ sẽ phải tham gia vào trên cơ sở hàng
ngày. Những khía cạnh này bao gồm:
 Việc thông báo cho Quản lý Cấu hình về bất kỳ sự khác biệt
nào giữa bất kỳ Đơn vị Cấu hình nào và CMS,
 Việc thực hiện bất kỳ điều chỉnh cần thiết nào để khắc phục
bất kỳ sự khác biệt, theo ủy quyền của Quản lý Cấu hình, khi
chúng liên quan đến bất kỳ thành phần Vận hành Dịch vụ hoặc
dịch vụ nào.
Trách nhiệm cho việc cập nhật CMS là của Quản lý Cấu hình, nhưng
trong một số trường hợp, nhân viên Vận hành có thể được yêu cầu,
theo chỉ đạo của Quản lý Cấu hình, để cập nhật các mối quan hệ,
hoặc thậm chí, để bổ sung các Đơn vị Cấu hình mới hoặc đánh dấu
các Đơn vị Cấu hình là ‘đã loại bỏ’ trong CMS, nếu những cập nhật
này có liên quan đế các hoạt động vận hành được thực hiện trong
thực tế bởi nhân viên Vận hành.
4.6.3 Q uả n lý Phát hành và Tri ển khai

Quản lý Phát hành và Triển khai chủ yếu được đề cập trong ấn phẩm
Chuyển tiếp Dịch vụ, tuy nhiên, có một số khía cạnh của quy trình
này mà nhân viên Vận hành Dịch vụ sẽ phải tham gia vào trên cơ sở
hàng ngày. Những khía cạnh này bao gồm:
 Các hành động triển khai thực tế liên quan đến triển khai các
bản phát hành mới, theo chỉ đạo của Quản lý Phát hành và
Triển khai, khi chúng liên quan đ ến các thành phần Vận hành
Dịch vụ hoặc các dịch vụ,
 Sự tham gia vào các giai đoạn lập kế hoạch của các bản phát
hành lớn để khuyến cáo về các sự cố Vận hành Dịch vụ,
 Việc xử lý vật lý các Đơn vị Cấu hình đến/từ DML khi được yêu
cầu để thực hiện những vai trò vận hành của họ - trong khi vẫn
tuân thủ các thủ tục Quản lý Phát hành và Triển khai có liên
quan, chẳng hạn như đảm bảo rằng tất cả các hạng mục đã
được lấy ra và trả lại (book out and back in).
4.6.4 Q uả n lý Công su ấ t
Quản lý Công suất nên hoạt động ở ba cấp độ: Quản lý Công suất
Doanh nghiệp, Quản lý Công suất Dịch vụ và Quản lý Công suất Tài
nguyên.
 Quản lý Công suất Doanh nghiệp liên quan đến việc làm việc
với doanh nghiệp để lập kế hoạch và dự đoán những vấn đề
chiến lược dài hạn hơn và các sáng kiến chiến thuật ngắn hạn
hơn có khả năng có một tác động lên công suất của CNTT,
 Quản lý Công suất Dịch vụ là về việc tìm hiểu những đặc
trưng của từng dịch vụ CNTT, và sau đó là những nhu cầu mà
các kiểu người dùng hoặc giao dịch khác nhau sẽ có đối với cơ
sở hạ tầng cơ bản – và những điều này thay đổi như thế nào
theo thời gian và có thể bị tác động như thế nào bởi những
thay đổi trong kinh doanh,
 Quản lý Công suất Tài nguyên liên quan đến việc tìm hiểu về
những đặc trưng hiệu suất và những năng lực và các mức độ sử
dụng hiện hành của mọi thành phần kỹ thuật (các Đơn vị Cấu
hình) tạo thành nên Cơ sở hạ tầng CNTT và việc dự báo tác
động của bất kỳ thay đổi hoặc khuynh hướng nào.
Rất nhiều trong số những hoạt động này có bản chất là chiến lược
hoặc hoạch định dài hạn hơn và được đề cập trong các ấn phẩm
Chiến lược Dịch vụ, Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ. Tuy
nhiên, có một số hoạt động Quản lý Công suất vận hành phải được
thực hiện trên cơ sở định kỳ liên tục như là một phần của Vận hành
Dịch vụ. Chúng bao gồm những điều dưới đây.
4.6.4. 1 Giám s át Công su ấ t và Hi ệu su ấ t

Mọi thành phần của Cơ sở hạ tầng CNTT nên được giám sát một cách
liên tục (kết hợp với Quản lý Sự kiện) để từ đó bất kỳ vấn đề tiềm
ẩn hoặc khuynh hướng nào có thể được xác định trước khi các lỗi
hoặc sự sụt giảm hiệu suất xảy ra. Lý tưởng nhất, việc giám sát như
vậy nên được tự động hóa và các ngưỡng nên được thiết lập để từ
đó việc thực thi các cảnh báo được đưa ra trong thời điểm thích hợp
để cho phép hoạt động tránh hoặc khôi phục phù hợp được thực hiện
trước khi tác động tiêu cực xảy ra.
Các thành phần và phần từ sẽ được giám sát sẽ khác nhau tùy thuộc
vào cơ sở hạ tầng đang sử dụng, nhưng thường sẽ bao gồm:
 Việc sử dụng CPU (tổng thể và được chia nhỏ theo sử dụng hệ
thống/dịch vụ ),
 Sử dụng bộ nhớ,
 Tỷ lệ Nhập Xuất (IO) (vật lý và bộ nhớ đệm) và sử dụng thiết
bị,
 Độ dài hàng đợi (tối đa và trung bình),
 Sử dụng lưu trữ tập tin (các ổ đĩa, phân vùng, phân đoạn),
 Các ứng dụng (tỷ lệ thông lượng, tỷ lệ lỗi),
 Các cơ sở dữ liệu (sử dụng, khóa bản ghi, lập chỉ mục, tranh
chấp),
 Tỷ lệ, lỗi và tỷ lệ cố gắng thử lại các giao dịch mạng,
 Thời gian hồi đáp giao dịch,
 Hồ sơ thời lượng tập lệnh hàng loạt,
 Tỷ lệ truy cập trang Internet/intranet,
 Thời gian hồi đáp Internet (bên trong và bên ngoài đ ối với
Firewall),
 Số lượng các đăng nhập và người dùng đồng thời vào hệ
thống/ứng dụng,
 Số lượng các nốt mạng đang sử dụng, và mức độ sử dụng.
Có các loại công cụ giám sát khác nhau cần thiết để thu thập và
diễn giải dữ liệu ở từng cấp độ. Ví dụ, một số công cụ sẽ cho phép
hiệu suất của các giao dịch kinh doanh sẽ được giám sát, trong khi
các công cụ khác sẽ giám sát hành vi của các Đơn vị Cấu hình.
Quản lý Công suất phải xác lập và hiệu chỉnh các ngưỡng cảnh báo
(kết hợp với Quản lý Sự kiện khi cần thiết, vì nó thường là các công
cụ Giám sát Sự kiện có thể được sử dụng) để từ đó các mức độ cảnh
báo chính xác được thiết lập và rằng bất kỳ bộ lọc nào được thiết
lập khi cần thiết để chi có những sự kiện có ý nghĩa được nêu ra.
Nếu không có những bộ lọc như vậy thì có khả năng là những cảnh
báo ‘chỉ có thông tin’ có thể che khuất những cảnh báo có ý nghĩa
hơn đòi hỏi sự chú ý ngay tức khắc. Ngoài ra, có khả năng các lỗi
nghiêm trọng gây ra những ‘cơn bão cảnh báo’ do lượng rất lớn các
cảnh báo lặp lại, vốn cần phải được lọc lại để từ đó chỉ có những
thông điệp có ý nghĩa nhất không bị ẩn giấu đi.
Có thể việc sử dụng những năng lực giám sát bên thứ ba bên ngoài
là thích hợp đối với một số Đơn vị Cấu hình hoặc một số thành phần
của Cơ sở hạ tầng CNTT (ví dụ, các trang web chính). Quản lý Công
suất nên tham gia vào việc giúp xác định và lựa chọn bất kỳ năng
lực giám sát nào như vậy và vào việc tích hợp những kết quả hoặc
bất kỳ cảnh báo nào với các hệ thống giám sát và xử lý khác.
Quản lý Công suất phải làm việc với mọi nhóm hỗ trợ thích hợp để
đưa ra quyết định về nơi các cảnh báo được hướng đến và về các lộ
tuyến leo thang và khung thời gian. Các cảnh báo nên đưuọc ghi
nhật ký cho Bộ phận Hỗ trợ Dịch vụ cũng như những nhân viên hỗ
trợ thích hợp, để từ đó các Hồ sơ Sự cố có thể được nêu ra, từ đó
tồn tại một hồ sơ vĩnh viễn về sự kiện – và nhân viên Bộ phận Hỗ
trợ Dịch vụ có thể xem xét (các) nhóm hỗ trợ đang xử lý lỗi tốt như
thế nào và có thể can thiệp nếu cần thiết.
Những năng lực hiệu suất đã được xác nhận của nhà sản xuất và các
đích nhắm mục tiêu mức dịch vụ đã thỏa thuận cùng với dữ liệu hiệu
suất và công suất đã được giám sát thực tế trước đây, nên được sử
dụng để đặt mức cảnh báo. Đây có thể cần phải là một quá trình lặp
đi lặp lại ban đầu, thực hiện một số điều chỉnh thử-và-sai cho đến
khi đạt được mức độ thích hợp.
Lưu ý: Quản lý Công suất có thể phải tham gia vào các yêu cầu công
suất và năng lực của Quản lý dịch vụ CNTT. Dù cho tổ chức có đủ
nhân viên Bộ phận Hỗ trợ Dịch vụ để xử lý tỷ lệ sự cố hay không;
liệu cấu trúc CAB có thể xử lý số lượng thay đổi mà nó đang được
yêu cầu xem xét và phê duyệt hay không; liệu các công cụ hỗ trợ có
thể xử lý khối lượng dữ liệu đang được thu thập có là các vấn đề
Quản lý Công suất hay không, nhóm Quản lý Công sất đều có thể
được yêu cầu để giúp điều tra và giải đáp.
4.6.4. 2 Xử lý c ác s ự c ố li ên quan đ ến cô ng su ấ t –
hoặ c hi ệu su ấ t
Nếu một cảnh báo được kích hoạt, hoặc một sự cố được nêu ra tại
Bộ phận Hỗ trợ Dịch vụ, gây ra do Quản lý Hiệu suất hoặc Quản lý
Công suất hiện tại hoặc đang tiếp diễn, Quản lý Công suất phải tham
gia để xác định nguyên nhân và tìm ra một giải pháp. Làm việc cùng
với các nhóm hỗ trợ kỹ thuật, và bên cạnh Quản lý Vấn đề, tất cả
những cuộc điều tra cần thiết phải được thực hiện để phát hiện một
cách chính xác những gì đã sai và những gì cần thiết để khắc phục
tình huống.
Có thể cần phải chuyển sang giám sát chi tiết hơn trong giai đoạn
điều tra để xác định được chính xác nguyên nhân. Việc giám sát
thường được thiết lập ở mức ‘chạy nền [background]’ trong những
tình huống bình thường do một lượng lớn dữ liệu có thể được tạo ra
và tranh việc đặt một gánh nặng quá lớn lên Cơ sở hạ tầng CNTT –
tuy nhiên khi những khó khăn cụ thể đang được điều tra chi tiết
hơn, việc giám sát có thể phải xác định nguyên nhân chính xác.
Khi một giải pháp, hoặc giải pháp tiềm năng, đã được tìm thấy, bất
kỳ thay đổi cần thiết nào để giải quyết vấn đề phải được phê duyệt
thông qua quy trình Quản lý Thay đổi chính thức trước khi triển
khai. Nếu như lỗi đang gây ra sự gián đoạn nghiêm trọng và một
giải pháp khẩn cấp là cần thiết, quy trình thay đổi khẩn cấp nên
được sử dụng. Điều cực kỳ quan trọng là không có ‘sự tinh chỉnh’
nào được đưa ra mà không đệ trình thông qua Quản lý Thay đổi, vì
thậm chí những điều chỉnh nhỏ cũng thường có những ảnh hưởng
tích lũy rất lớn – thỉnh thoảng trên toàn bộ Cơ sở hạ tầng CNTT.
4.6.4. 3 Xu hư ớ ng công su ấ t và hi ệu s u ấ t
Quản lý Công suất có một vai trò trong việc xác định bất kỳ khuynh
hướng hiệu suất hoặc công suất nào khi chúng trở nên có thể được
nhận thấy rõ ràng. Những chi tiết khác về những hành động cần
thiết để xác định những khuynh hướng đó được đề cập trong ấn
phẩm Liên tục Cải tiến Dịch vụ.
4.6.4. 4 Dữ l iệ u Q u ản lý Cô ng su ấ t và Lưu tr ữ
Một lượng lớn dữ liệu thường được tạo ra thông qua việc giám sát
công suất và hiệu suất. Việc giám sát các đồng hồ đo và các bảng
biểu với dung lượng chỉ vài Kbyte mỗi cái có thể nhanh chóng trở
thành một tập tin khổng lồ nếu như rất nhiều thành phần được giám
sát tại một thời điểm tương đối ngắn. Một vấn đề khác với việc giám
sát trong thời gian ngắn là rằng không thể thu thập thông tin có ý
nghĩa mà không xem xét trong m ột khoảng thời gian dài hơn. Ví dụ,
một ảnh chụp nhanh (snapshot) duy nhất của một CPU sẽ cho thấy
thiết bị hoặc đang bận (busy) hoặc đang nhàn rỗi (idle) – những một
tóm tắt trong khoảng thời gian 5 phút cho thấy mức sử dụng trung
bình trong khoảng thời gian đó, vốn là một thước đo có ý nghĩa hơn
về việc liệu thiết bị có khả năng hoạt động một cách trơn tru hay
không, hoặc liệu các vấn đề hiệu suất tiềm ẩn có khả năng xảy ra
không.
Trong rất nhiều tổ chức, có khả năng rằng các công cụ giám sát đã
được sử dụng sẽ rất khác nhau – với một sự kết hợp của các công cụ
hệ thống-cụ thể, rất nhiều trong số chúng là những phần của hệ
điều hành, và các công cụ giám sát đặc biệt đang được sử dụng.
Nhằm phối hợp những dữ liệu được tạo ra và cho phép lưu giữ
những dữ liệu có ý nghĩa để phân tích và cho mục đích tạo khuynh
hướng, một số hình thức kho lưu trữ tập trung để giữ những dữ liệu
tổng hợp này là cần thiết: một Hệ thống Thông tin Quản lý Công
suất (Capacity Management Information System – CMIS).
Định dạng, vị trí, và thiết kế của một cơ sở dữ liệu như vậy nên
được lên kế hoạch và triển khai trước – xem ấn phẩm Thiết kế Dịch
vụ để biết thêm chi tiết – nhưng sẽ có một vài khía cạnh vận hành
cần được xử lý, chẳng hạn như quản lý cơ sở dữ liệu và sao lưu.
4.6.4. 5 Q uả n lý Nhu c ầ u
Quản lý Nhu cầu là tên gọi được đặt cho một số các kỹ thuật có thể
được sử dụng để điều chỉnh nhu cầu đối với một tài nguyên hoặc
dịch vụ cụ thể. Một số kỹ thuật đối với Quản lý Nhu cầu có thể được
lập kế hoạch trước – và chúng được đề cập chi tiết trong ấn phẩm
Thiết kế Dịch vụ. Tuy nhiên, có một số khía cạnh khác của Quản lý
Nhu cầu mang bản chất vận hành nhiều hơn, đòi hỏi những hành
động ngắn hạn hơn.
Ví dụ, nếu như hiệu suất của một dịch vụ cụ thể đang gây ra một
mối quan tâm, và những hạn chế trong ngắn hạn về tính đồng thời
của người dùng là cần thiết để cho phép cải thiện hiệu suất chỉ cho
một nhóm nhỏ bị hạn chế thì các chức năng Vận hành Dịch vụ sẽ
phải thực hiện hành động để triển khai những hạn chế đó – thường
đi kèm với hành động đồng thời để triển khai việc đăng xuất người
dùng không hoạt động cho một khoảng thời gian đã được thống nhất
để giải phóng tài nguyên cho những người dùng khác.
4.6.4. 6 Q uả n lý kh ối lư ợ ng công vi ệc
Có thể có những trường hợp khi việc tối ưu hóa tài nguyên cơ sở hạ
tầng là điều cần thiết để duy trì hoặc cải thiện hiệu suất hoặc thông
lượng. Việc này có thể được hoàn thành thông qua Qu ản lý Khối
lượng công việc, vốn là một thuật ngữ phổ quát để chỉ những hành
động dưới đây:
 Việc lập lại lịch biểu một dịch vụ hoặc khối lượng công việc cụ
thể để chạy tại một thời điểm khác trong ngày, hoặc ngày
trong tuần, v.v… (thường cách xa các cửa sổ cao điểm hoặc
thấp điểm) – vốn sẽ thường có nghĩa là phải thực hiện điều
chỉnh đối với phần mềm lập lịch biểu-công việc.
 Việc chuyển một dịch vụ hoặc khối lượng công việc từ vị trí này
hoặc một bộ các Đơn vị Cấu hình sang vị trí/Đơn vị Cấu hình
khác – thường là để cân bằng mức độ sử dụng hoặc lưu lượng.
 Ảo hóa về Công nghệ: việc thiết lập và sử dụng các hệ thống
ảo hóa để hỗ trợ việc di chuyển quá trình xử lý xoay quanh cơ
sở hạ tầng để mang lại hiệu suất/khả năng phục hồi tốt hơn
theo phương thức năng động.
 Việc giới hạn hoặc chuyển nhu cầu đối với tài nguyên thông
qua các kỹ thuật Quản lý Nhu cầu (xem đoạn trên và ấn phẩm
Thiết kế Dịch vụ).
Sẽ chỉ có thể quản lý khối lượng công việc một cách hiệu quả nếu
tồn tại một hiểu biết rõ ràng về những khối lượng công việc nào sẽ
hoạt động tại thời điểm nào và mức sử dụng tài nguyên của từng
khối lượng công việc trên Cơ sở hạ tầng CNTT như thế nào. Do đó,
việc giám sát và phân tích khối lượng công việc một cách chuyên
chú là điều cần thiết trên cơ sở hoạt động liên tục.
4.6.4. 7 Mô hìn h hóa và đ ịnh c ỡ ứng d ụn g

Việc mô hình hóa và/hoặc định cỡ các dịch vụ và/hoặc ứng dụng mới
phải, khi có thể, được thực hiện trong các giai đoạn hoạch định và
chuyển tiếp – xem các ấn phẩm Thiết kế Dịch vụ và Chuyển tiếp Dịch
vụ. Tuy nhiên, các chức năng Vận hành Dịch vụ có một vai trò trong
việc đánh giá tính chính xác của các dự báo và phản hồi về bất kỳ
vấn đề hoặc sự khác biệt nào.
4.6.4. 8 Hoạ ch đ ịnh c ông su ấ t

Trong các giai đoạn Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ, các
yêu cầu về công suất của các dịch vụ CNTT được tính toán. Một kế
hoạch công suất tiên tiến nên được duy trì và được cập nhật thường
xuyên và Vận hành Dịch vụ sẽ phải đóng một vai trò trong việc này.
Một kế hoạch như vậy nên kéo dài đến 2 năm hoặc hơn, nhưng nên
được đánh giá định kỳ mỗi 3 đến 12 tháng, tùy thuộc vào sự biến
động và nguồn tài nguyên sẵn có.
Kế hoạch này nên được liên kết với chu kỳ hoạch định tài chính của
tổ chức, để từ đó, bất kỳ khoản chi tiêu cần thiest nào đối với việc
nâng cấp, cải thiện hoặc bổ sung cơ sở hạ tầng có thể được bao gồm
trong các ước tính ngân sách và được phê duyệt trước.
Kế hoạch nên dự đoán về tương lại nhưng cũng phải kiểm tra và báo
vào về các dự báo trước đó, đặc biệt để mang lại sự tự tin trong các
dự đoán tiếp sau.
Khi gặp phải bất kỳ sự khác biệt nào, chúng nên được giải trình và
nhũng hành động khắc phục trong tương lai được mô tả.
Kế hoạch Công suất có thể thường bao gồm:
 Hiệu suất và mức sử dụng hiện hành, với những khuynh hướng
gần đây đối với mọi Đơn vị Cấu hình chính, bao gồm:
o Các hệ thống mạng trục xương sống,
o Các mạng LAN,
o Các máy chủ lớn (nếu vẫn còn sử dụng),
o Các máy chủ chính,
o Các thiết bị lưu trữ dữ liệu chính,
o Các thiết bị máy tính để bàn và máy tính xách tay được
chọn (đại diện),
o Các trang web chính,
o Các cơ sở dữ liệu chính,
o Các ứng dụng chính,
o Công suất vận hành – điện, không gian sàn, công suất
môi trường (điều hòa không khí), trọng lượng sàn, phát
nhiệt và đầu ra, nhu cầu và cung cấp điện nước, v.v…
o Phương tiện từ tính.
 Hiệu suất và mức sử dụng được ước tính đối với mọi Đơn vị
Cấu hình như vậy trong chu kỳ hoạch định (ví dụ, trong 3
tháng tới),
 Dữ liệu so sánh với các ước tính trước đó – để hỗ trợ sự tự tin
trong các ước tính tương lai sẽ được đánh giá,
 Các báo cáo về bất kỳ những khó khăn nào về công suất cụ
thể gặp phải trong chu kỳ quá khứ, với các chi tiết về những
hành động khôi phục và ngăn ngừa được thực hiện cho tương
lai,
 Các chi tiết về bất kỳ nâng cấp hoặc mua sắm bắt buộc nào
cần thiết và được lên kế hoạch cho tương lai, cùng với chi phí
và khung thời gian cụ thể,
Bất kỳ rủi ro công suất tiềm ẩn nào có khả năng xảy ra – cùng với
các biện pháp ứng phó được đề xuất nếu chúng phát sinh.
4.6.5 Q uả n lý tính S ẵ n sàng

Trong giai đoạn Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ, các dịch vụ
CNTT được thiết kế đối với tính sẵn sàng và khôi phục. Vận hành
Dịch vụ chịu trách nhiệm về việc khiến cho dịch vụ CNTT trở nên sẵn
sàng trong thực tế đối với những người dùng đã được chỉ định tại
những thời điểm được yêu cầu và với mức (dịch vụ) đã được thống
nhất.
Trong quá trình Vận hành Dịch vụ, các nhóm CNTT và người dùng ở
vị thế tốt nhất để phát hiện xem liệu các dịch vụ thực tế có đáp ứng
được các yêu cầu đã được thống nhất hay không và liệu thiết kế của
những dịch vụ này có hiệu quả không.
Những gì trông có vẻ như là những ý tưởng tốt trong giai đoạn Thiết
kết có thể không thực tế hoặc không tối ưu. Trải nghiệm của người
dùng và những chức năng vận hành biến chúng thành đầu vào chủ
yếu cho việc liên tục cải tiến những dịch vụ và thiết kế hiện hữu. ‘
Tuy nhiên, vẫn có một số thách thức với việc có được quyền tiếp cận
với những kiến thức này:
 Hầu hết những trải nghiệm của các nhóm vận hành và người
dùng hoặc là không chính thức hoặc là trải rộng qua nhiều
nguồn,
 Quá trình thu thập và sắp xếp dữ liệu này cần phải được chính
thức hóa,
 Người dùng và nhân viên vận hành thường bận rộn với các hoạt
động và nhiệm vụ thường xuyên của họ và rất khó để họ tham
gia vào các hoạt động hoạch định và thiết kế định kỳ. Một luận
cứ thường được đưa ra ở đây là nếu thiết kế đã được cải thiện,
các nhóm vận hành sẽ bớt bận rộn hơn để giải quyết các vấn
đề và do đó, sẽ có nhiều thời gian hơn để tham gia vào các
hoạt động thiết kế. Tuy nhiên, thực tế cho thấy rằng ngay khi
nhân viên được giải phóng, họ thường trở thành đích nhắm cho
việc cắt giảm lực lượng lao động.
Phải nói rằng, có 3 cơ hội chính cho nhân viên vận hành để tham gia
vào việc Cải thiện Tính sẵn sàng, vì chúng thường được coi là một
phần của trách nhiệm liên tục của họ (nhân viên vận hành):
 Xem xét các hoạt động bảo trì. Thiết kế Dịch vụ sẽ xác định
các lịch trình và hoạt động bảo trì chi tiết, vối được yêu cầu để
giữ cho các dịch vụ CNTT hoạt động ở mức hiệu suất và tính
sẵn sàng cần thiết. Sự so sánh định kỳ về các hoạt động và
thời gian bảo trì thực tế với các kế hoạch sẽ làm nổi bật những
lĩnh vực cải thiện tiềm năng. Một trong những nguồn của thông
tin này là việc xem xét xem liệu các Mục tiêu Bảo trì Dịch vụ có
được đáp ứng hay không, và nếu không, tại sao.
 Xem xét các vấn đề lớn. Các vấn đề có thể là kết quả của bất
kỳ yếu tố nào, một trong số đó là thiết kế tồi. Do đó, những
quá trình xem xét các vấn đề có thể bao gồm những cơ hội để
xác định các biện pháp cải thiện đối với thiết kế của các dịch
vụ CNTT, vốn sẽ bao gồm cải thiện tính sẵn sàng và cải thiện
công suất.
 Sự tham gia vào các hoạt động cụ thể sử dụng các kỹ thuật
như Phân tích Lỗi Dịch vụ (Service Failure Analysis – SFA),
Phân tích Tác động của Lỗi Thành phần (Component Failure
Impact Analysis – CFIA), hoặc Phân tích Cây Lỗi (Fault Tree
Analysis – FTA) hoặc với tư cách là thành viên của các hoạt
động Quan sát Kỹ thuật (Technical Observation – TO) – như
một phần của quá trình theo dõi các vấn đề lớn hoặc là một
phần của một chương trình cải tiến dịch vụ liên tục, kết hợp
với nhân viên Quản lý Tính sẵn sàng chuyên biệt. Những kỹ
thuật Quản lý Tính sẵn sàng này được giải thích chi tiết hơn
trong ấn phẩm Thiết kế Dịch vụ.
Có thể có những trường hợp khi bản thân Nhân viên Vận hành cần
phải ngừng hoạt động của một hoặc nhiều dịch vụ để cho phép họ
tiến hành các hoạt động vận hành hoặc bảo trì của họ - vốn có thể
tác động đến tính sẵn sàng nếu không được lập lịch trình và quản lý
một cách đúng đắn. Trong những trường hợp đó, họ phải liên lạc với
nhân viên SLM và Quản lý Tính sẵn sàng – những người sẽ thương
lượng với doanh nghiệp/người dùng, thường sử dụng Bộ phận Hỗ trợ
Dịch vụ để thực hiện vai trò này, để thống nhất và lập lịch trình cho
những hoạt động này.
4.6.6 Q uả n lý Ki ến th ức
Một điều cực kỳ quan trọng là mọi dữ liệu và thông tin có thể hữu
ích cho các hoạt động Vận hành Dịch vụ trong tương lai cần được
thu thập, lưu trữ và truy cập một cách đúng đắn. Những dữ liệu, chỉ
số và thông tin có liên quan nên đư ợc chuyển vào chuỗi quản lý và
và giai đoạn Vòng đời Dịch vụ khác để từ đó nó có thể được nuôi
dưỡng trở thành các lớp kiến thức và sự uyên bác của Hệ thống
Quản lý Kiến thức Dịch vụ của tổ chức, những cơ cấu của những gì
phải được xác định trong Chiến lược Dịch vụ và Thiết kế Dịch vụ và
được tinh chỉnh trong Liên tục Cải tiến Dịch vụ (xem thêm các ấn
phẩm ITIL khác trong loạt ấn phẩm này).
Các kho lưu trữ chính của Vận hành Dịch vụ, vốn thường xuyên được
đề cập đến ở đâu đó, là CMS và KEDB, nhưng điều này phải được mở
rộng để bao gồm tất cả mọi tài liệu của các nhóm và bộ phận Vận
hành Dịch vụ, chẳng hạn như các hướng dẫn vận hành, các hướng
dẫn thủ tục, hướng dẫn công việc, v.v…
4.6.7 Q uả n lý Tài chính đ ố i v ớ i các d ịch v ụ CNTT

Nhân viên Vận hành Dịch vụ phải tham gia vào và hỗ trợ cho hệ
thống kế toán và lập ngân sách CNTT tổng thể - và có thể tham gia
một cách chủ động vào hệ thống tính phí nào có thể đang có.
Việc hoạch định đúng đắn là điều cần thiết để từ đó các ước tính
ngân sách chi tiêu vốn (Capex) và chi tiêu vận hành (Opex) có thể
được chuẩn bị và thống nhất trong những thời điểm tốt để đáp ứng
các chu kỳ ngân sách.
Nhà quản lý Vận hành Dịch vụ cũng phải tham gia định kỳ, ít nhất
hàng tháng, vào việc xem xét các khoản chi tiêu so với ngân sách –
một phần của quy trình kế toán và ngân sách CNTT liên t ục. Bất kỳ
sự khác biệt nào phải được xác định và những điều chỉnh cần thiết
được đưa ra. Mọi khoản chi tiêu đã được cam kết phải đi qua hệ
thống đặt hàng mua sắm của tổ chức để từ đó các cam kết có thể
được tích lũy và các kiểm tra thích hợp phải được thực hiện đối với
mọi hàng hóa đã nhận được, vì vậy, các hóa đơn và các khoản thanh
toán có thể được ủy quyền một cách đúng đắn – hoặc những khác
biệt được điều tra và được hiệu chỉnh.
Nên lưu ý rằng một số khoản cắt giảm chi phí đã được đề xuất bởi
doanh nghiệp có thể làm gia tăng chi phí CNTT, hoặc ít nhất, chi phí
đơn vị. Do đó, nên cẩn trọng để đảm bảo rằng CNTT được tham gia
vào quá trình thảo luận về mọi biện pháp tiết kiệm chi phí và đóng
góp vào những quyết định tổng thể. Quản lý Tài chính được đề cập
chi tiết trong ấn phẩm Chiến lược Dịch vụ.
4.6.8 Q uả n lý Liên t ục D ị ch v ụ CNTT

Các chức năng Vận hành Dịch vụ chịu trách nhiệm cho việc kiểm
nghiệm và thực thi các kế hoạch khôi phục hệ thống và dịch vụ như
đã được xác định trong các Kế hoạch Liên tục Dịch vụ CNTT cho tổ
chức. Ngoài ra, các nhà quản lý của mọi chức năng Vận hành Dịch
vụ phải là thành viên của nhóm Điều phối Trung tâm Liên tục Kinh
doanh (Business Continuity Centra l Coordination).
Điều này đã được thảo luận chi tiết trong Chiến lược Dịch vụ và
Thiết kế Dịch vụ và sẽ không được lặp lại ở đây, ngoại trừ để chỉ ra
rằng các chức năng Vận hành Dịch vụ phải được tham gia vào những
lĩnh vực sau đây:
 Đánh giá rủi ro, sủ dụng kiến thức của mình về cơ sở hạ tầng
và những kỹ thuật như CFIA và quyền tiếp cận tới những thông
tin trong CMS để xác định điểm đơn lỗi hoặc các tình huống rủi
ro cao khác.
 Thực thi bất kỳ biện pháp Quản lý Rủi ro nào đã được thống
nhất, ví dụ, triển khai các biện pháp đối phó, hoặc gia tăng
khả năng phục hồi đối với các thành phần của cơ sở hạ tầng,
v.v…
 Hỗ trợ việc soạn thảo các kế hoạch khôi phục thực tế cho các
hệ thống và dịch vụ do họ kiểm soát.
 Tham gia vào việc kiểm nghiệm các kế hoạch (chẳng hạn như
tham gia vào kiểm nghiệm tại chỗ, mô phỏng, v.v…) trên cơ sở
liên tục theo định hướng của Nhà quản lý Liên tục Dịch vụ
CNTT (ITSCM),
 Việc liên tục duy trì các kế hoạch dưới sự kiểm soát của ITSCM
và Quản lý Thay đổi,
 Tham gia vào các chiến dịch đào tạo và nâng cao nhận thức để
đảm bảo rằng họ có khả năng thực thi các kế hoạch và hiểu rõ
vai trò của họ khi xảy ra thảm họa,
 Bộ phận Hỗ trợ Dịch vụ sẽ đóng một vai trò then chốt trong
việc truyền đạt cho nhân viên, khách hàng và người dùng trong
một thảm họa thực tế.
5 Các ho ạ t đ ộng V ậ n hành D ịch v ụ ph ổ biến

Chương 4 đề cập đến các quy trình bắt buộc để Vận hành Dịch vụ
hiệu quả và Chương 6 đề cập đến những khía cạnh mang tính tổ
chức. Chương này sẽ tập trung vào một số các hoạt động vận hành
để đảm bảo rằng công nghệ được liên kết với các mục tiêu Quy trình
và Dịch vụ tổng thể. Những hoạt động này thỉnh thoảng được mô tả
như là các quy trình, nhưng trong th ực tế chúng là những tập hợp
các hoạt động kỹ thuật chuyên biệt hóa, tất cả nhằm mục đích đảm
bảo rằng công nghệ cần thiết để cung cấp và hỗ trợ cho các dịch vụ
đang được vận hành một cách hiệu suất và hiệu quả.
Những hoạt động này thường có bản chất kỹ thuật – mặc dù chính
xác công nghệ nào sẽ khác nhau tùy thuộc vào kiểu dịch vụ đang
được cung cấp. Ấn phẩm này sẽ tập trung vào các hoạt động cần
thiết để quản lý CNTT.
Hình 5.1 – Đạt được sự trưởng thành trong Quản lý Công nghệ
Hình 5.1 minh họa cho các bước liên quan đến việc trưởng thành từ
một tổ chức lấy công nghệ làm trung tâm thành một tổ chức khai
thác công nghệ như một phần chiến lược kinh doanh của mình. Hình
5.1 phác thảo thêm vai trò của các Nhà quản lý Công nghệ trong các
tổ chức có mức độ trưởng thành khác nhau. Sơ đồ này không phải là
một sơ đồ toàn diện, nhưng nó cung cấp các ví dụ về cách thức mà
theo đó công nghệ được quản lý theo từng kiểu tổ chức. Những tiêu
đề in đậm chỉ ra những vai trò chính của CNTT trong việc quản lý
công nghệ. Văn bản trong các dòng mô tả về những đặc trưng của
một bộ phận CNTT ở từng cấp độ.
Mục đích của sơ đồ này trong chương này là:
 Chương này tập trung vào các hoạt động Quản lý Kỹ thuật,
nhưng không chỉ có một cách thức đơn lẻ để trình bày chúng.
Một tổ chức ít trưởng thành hơn sẽ có khuynh hướng xem
những hoạt động này là sự kết thúc trong chính bản thân
chúng, không phải là một phương tiện đi đến một kết thúc. Một
tổ chức trưởng thành hơn có khuynh hướng sẽ dịch chuyển từ
một bộ phận bị cách ly, tập trung hoàn toàn vào việc quản lý
các máy chủ sang một nhóm hoạt động một cách chặt chẽ với
các Nhà quản lý Công nghệ khác để tìm ra những cách thức gia
tăng giá trị của chúng cho doanh nghiệp.
 Để đưa ra và củng cố quan điểm rằng không có cách thức
‘đúng đắn’ để nhóm và tổ chức các bộ phận để thực hiện những
dịch vụ này. Một số độc giả có thể diễn dịch các tiêu đề trong
chương này thành các tên gọi của các bộ phận, nhưng điều này
không đúng. Mục đích của chương này là để xác định các hoạt
động kỹ thuật điển hình liên quan đến Vận hành Dịch vụ. Các
khía cạnh mang tính tổ chức được thảo luận trong Chương 6.
 Các hoạt động Vận hành Dịch vụ được mô tả trong phần còn lại
của chương này không phải là điển hình về bất kỳ mức độ
trưởng thành nào. Thay vào đó, các hoạt động thường hiện
diện dưới một số hình thức ở mọi cấp độ. Chúng chỉ được tổ
chức và quản lý một cách khác biệt ở từng cấp độ.
Trong một số trường hợp, một nhóm chuyên biệt có thể xử lý mọi
thứ của một quy trình hoặc một hoạt động trong khi với trường hợp
khác, các quy trình hoặc hoạt động có thể được chia sẻ hoặc tách
biệt giữa các nhóm. Tuy nhiên, theo cách hướng dẫn rộng rãi, những
phần dưới đây liệt kê các hoạt động bắt buộc thuộc các nhóm chức
năng có nhiều khả năng tham gia vào hoạt động của họ nhất. Điều
này không có nghĩa rằng mọi tổ chức phải sử dụng các bộ phận này.
Các tổ chức nhỏ hơn sẽ có khuynh hướng chỉ định các nhóm hoạt
động này (nếu chúng thực sự cần thiết) cho các bộ phận đơn lẻ,
hoặc thậm chí cho các cá nhân.
Cuối cùng, mục đích của chương này không phải để cung cấp một
phân tích chi tiết về mọi hoạt động. Chúng chuyên biệt, và hướng
dẫn chi tiết sẵn có từ các nhà cung cấp nền tảng và các khuôn khổ
khác mang tính kỹ thuật hơn, những thể loại mới sẽ được bổ sung
liên tục khi công nghệ phát triển. Chương này chỉ đơn giản giúp làm
nổi bật tầm quan trọng và bản chất của việc quản lý công nghệ đối
với Quản lý Dịch vụ trong bối cảnh CNTT.
5.1 Giám sát và Kiểm soát

Thước đo và biện pháp kiểm soát các dịch vụ được căn cứ vào một
chu trình giám sát, báo cáo liên t ục và hành động tiếp theo sau đó.
Chu trình này được thảo luận chi tiết hơn trong phần này bởi vì nó
là nền tảng cho việc cung cấp, hỗ trợ và cải thiện các dịch vụ.
Một điều quan trọng cần lưu ý rằng, mặc dù chu trình này hiện diện
trong quá tình Vận hành Dịch vụ, nó cung cấp một cơ sở cho việc
thiết lập chiến lược, thiết kế và kiểm nghiệm các dịch vụ và đạt
được những cải tiến có ý nghĩa. Nó cũng đồng thời là cơ sở cho các
thước đo SLM. Do đó, mặc dù việc giám sát đưuọc thực hiện bởi các
chức năng Vận hành Dịch vụ, nó không nên bị xem là một vấn đề
mang tính vận hành thuần túy. Mọi giai đoạn của Vòng đời Dịch vụ
nên đảm bảo rằng các thước đo và biện pháp kiểm soát được xác
định một cách rõ ràng, được thực hiện và hành động theo.
5.1.1 Các đ ịnh ngh ĩa
Giám sát đề cập đến hoạt động quan sát một tình huống để phát hiện ra những
thay đổi xảy ra theo thời gian.
Trong bối cảnh của Vận hành Dịch vụ, điều này có hàm ý rằng:
 Sử dụng các công cụ để giám sát trạng thái của các Đơn vị Cấu
hình chính yếu và các hoạt động vận hành then chốt,
 Đảm bảo rằng những điều kiện cụ thể được đáp ứng (hoặc
không) và, nếu không, để đưa ra một cảnh báo cho nhóm thích
hợp (ví dụ, tính sẵn sàng của các thiết bị mạng chính),
 Đảm bảo rằng hiệu suát hoặc mức sử dụng của một thành phần
hoặc hệ thống nằm trong phạm vi đã được chỉ định (ví dụ,
không gian đĩa hoặc sử dụng bộ nhớ),
 Phát hiện những kiểu hoặc mức hoạt động bất thường trong cơ
sở hạ tầng (ví dụ, các mối đe dọa bảo mật tiềm tàng),
 Phát hiện những thay đổi trái phép (ví dụ, giới thiệu phần
mềm),
 Đảm bảo tuân thủ các chính sách của tổ chức (ví dụ, việc sử
dụng email không phù hợp),
 Theo dõi kết quả đầu ra đối với doanh nghiệp và đảm bảo rằng
chúng đáp ứng các yêu cầu chất lượng và yêu cầu hiệu suất,
 Theo dõi bất kỳ thông tin nào được sử dụng để đo lường các
Chỉ số Hiệu suất Chính yếu (KPI).
Việc báo cáo đề cập đến phân tích, đưa ra và phân phối kết quả đầu ra về các
hoạt động giám sát.
Trong bối cảnh Vận hành Dịch vụ, điều này hàm ý rằng:
 Việc sử dụng các công cụ để đối chiếu kết quả đầu ra của
thông tin giám sát có thể được phổ biến cho các nhóm, chức
năng hoặc quy trình khác nhau,
 Việc diễn giải ý nghĩa của những thông tin đó,
 Việc xác định nơi mà những thông tin đó sẽ được sử dụng tốt
nhất,
 Việc đảm bảo rằng những người ra quyết định có quyền truy
cập vào những thông tin cho phép họ đưa ra các quyết định,
 Việc định tuyến những thông tin đã được báo cáo cho những
người, nhóm hoặc công cụ thích hợp.
Biện pháp kiểm soát để cập đến quy trình quản lý việc sử dụng hoặc hành vi của
một thiết bị, hệ thống hoặc dịch vụ. Tuy vậy, điều quan trọng cần lưu ý rằng
thao tác đơn giản một thiết bị không giống với việc kiểm soát nó. Kiểm soát đòi
hỏi 3 điều kiện:
 Hành động phải đảm bảo rằng hành vi tuân theo một tiêu chuẩn hoặc chuẩn
mực đã được xác định,
 Các điều kiện thúc đẩy hành động phải được xác định, hiểu rõ và xác nhận,
 Hành động phải được xác định, phê duyệt và thích hợp với những điều kiện
đó.
Trong bối cảnh Vận hành Dịch vụ, biện pháp kiểm soát có hàm ý:
 Sử dụng các công cụ để xác định những điều kiện nào thể hiện
cho những hoạt động bình thường hoặc những hoạt động bất
thường,
 Điều chỉnh hiệu suất của các thiết bị, hệ thống hoặc dịch vụ,
 Đo lường tính sẵn sàng,
 Khởi đầu hành động khắc phục, vốn có thể được tự động hóa
(ví dụ, khởi động lại một thiết bị từ xa hoặc chạy một tập lệnh
kịch bản), hoặc thủ công (ví dụ, thông báo cho nhân viên vận
hành về trạng thái [của thiết bị, hệ thống hoặc dịch vụ].
5.1.2 Vòng l ặ p Ki ể m soát Giám sát

Mô hình phổ biến nhất để xác định biện pháp kiểm soát là Vòng lặp
Kiểm soát Giám sát. Mặc dù nó chỉ là một mô hình đơn giản nhưng
nó có nhiều cách ứng dụng phức tạp trong phạm vi Quản lý Dịch vụ
CNTT. Phần này sẽ xác định những khái niệm cơ bản của Mô hình
Vòng lặp Kiểm soát Giám sát và những phần tiếp theo sau sẽ cho
thấy tầm quan trọng của những khái niệm này đối với Vòng đời Quản
lý Dịch vụ.
Hình 5.2 – Vòng lặp Kiểm soát Giám sát
Hình 5.2 phác tháo những nguyên tắc cơ bản của kiểm soát. Một
hoạt động đơn lẻ và kết quả đầu ra của nó được đo lường bằng cách
sử dụng một chuẩn mực, hoặc tiêu chuẩn, đã được xác định trước,
để xác định xem liệu nó có nằm trong một phạm vi hiệu suất hoặc
chất lượng có thể chấp nận được hay không. Nếu không, các hành
động được thực hiện để điều chỉnh tình huống hoặc để khôi phục lại
hiệu suất như bình thường.
Thông thường, có hai kiểu Vòng lặp Kiểm soát Giám sát:
 Các Hệ thống Vòng lặp Mở được thiết kế để thực hiện một
hoạt động cụ thể bất kể các điều kiện môi trường. Ví dụ, một
quá trình sao lưu có thể được khởi chạy tại một thời điểm nhất
định và với một tần suất nhất định – và sẽ chạy bất kể các
điều kiện khác.
 Các Hệ thống Vòng lặp Đóng giám sát một môi trường và
ứng phó với những thay đổi trong môi trường đó. Ví dụ, trong
lĩnh vực cân bằng tải mạng một quá trình giám sát sẽ đánh giá
lưu lượng trên một mạch. Nếu lưu lượng mạng vượt quá một
phạm vi nhất định, hệ thống kiểm soát sẽ bắt đầu định tuyến
lưu lượng qua mạch dự phòng. Màn hình sẽ tiếp tục cung cấp
phản hồi cho hệ thống kiểm soát, vốn sẽ tiếp tục điều chỉnh lự
lượng mạng giữa hai mạch này.
Để giúp làm rõ sự khác biệt, việc giải quyết Quản lý Công suất thông
qua cung cấp quá mức (over-provisioning) là một vòng lặp mở, một
bộ cân bằng tải để phát hiện tắc nghẽn/lỗi là một vòng lặp đóng.
5.1.2. 1 Vòng l ặ p Ki ể m soát Giám sát ph ức t ạ p

Vòng lặp Kiểm soát Giám sát trong Hình 5.2 là m ột cơ sở tốt cho
việc xác định cách thức mà Quản lý Vận hành hoạt động như thế
nào, nhưng trong phạm vi của ITSM, tình huống phức tạp hơn nhiều.
Hình 5.3 minh họa cho một quy trình được tạo thành từ 3 hoạt động
chính. Từng hoạt động đều có một đầu vào và một đầu ra, và đầu ra
lại trờ thành một đầu vào cho hành động tiếp theo.
Trong sơ đồ này, từng hoạt động được kiểm soát bởi Vòng lặp Kiểm
soát Giám sát của riêng nó, sử dụng một bộ các chuẩn mực cho
những hành động cụ thể này. Toàn bộ quy trình có Vòng lặp Kiểm
soát Giám sát của riêng nó, vốn trải dài qua mọi hành động và đảm
bảo rằng mọi chuẩn mực là thích hợp và đang được tuân thủ.
Hình 5.2 – Vòng lặp Kiếm soát Giám sát Phức tạp
Có hai vòng lặp trong Hình 5.3. Một vòng lặp thuần túy tập trung
vào việc thực thi một tiêu chuẩn đã được xác định, và vòng lặp thứ
hai đánh giá hiệu suất của quy trình và các tiêu chuẩn mà theo đó
quy trình được thực thi. Một ví dụ về điều này sẽ là nếu tập hợp các
vòng lặp phản hồi ở phía dưới của sơ đồ đại diện cho các trạm riêng
lẻ của một dây chuyền lắp ráp và vòng lặp ở cấp cao hơn đại diện
cho Đảm bảo Chất lượng.
Vòng lặp Kiểm soát Giám sát Phức tạp là một công cụ học tập mang
tính tổ chức tuyệt vời (như đã được định nghĩa bởi Chris Argyris,
(1976) Gia tăng Tính hiệu quả Lãnh đạo [Increasing Leadership
Effectiveness] New York: Wiley). Mức độ phản hồi đầu tiên ở cấp độ
hoạt động cá nhân liên quan đến việc giám sát và phản hồi dữ liệu
(sự kiện đơn lẻ, các đoạn mã hoặc các mẩu thông tin). Cấp độ thứ
hai liên quan đến việc giám sát và phản hồi thông tin (một tập hợp
về một số sự kiện để đưa ra kết luận). Tham khảo ấn phẩm Chuyển
tiếp Dịch vụ để biết thêm thảo luận đầy đủ về Dữ liệu, Thông tin,
Kiến thức và Trí tuệ.
Tất cả những điều này đều là những học thuyết thú vị, nhưng không
giải thích được cách mà khái niệm Vòng lặp Kiểm soát Giám sát có
thể được sử dụng như thế nào để vận hành các dịch vụ CNTT. Và
đặc biệt - ai là người xác định chuẩn mực? Dựa trên những gì đã
được mô tả cho đến nay, Vòng lặp Kiểm soát Giám sát có thể được
sử dụng để quản lý:
 Hiệu suất của các hoạt động trong một quy trình hoặc thủ tục.
Từng hoạt động và các kết quả đầu ra liên quan của nó có thể
có khả năng được đo lường để đảm bảo rằng các vấn đề với
quy trình được xác định trước khi toàn bộ quy trình được hoàn
tất. Ví dụ, trong Quản lý Sự cố, Bộ phận Hỗ trợ Dịch vụ giám
sát xem liệu rằng một nhóm kỹ thuật viên có chấp thuận một
sự cố trong một thời điểm được chỉ định hay không. Nếu
không, sự cố sẽ được leo thang. Việc này được hoàn thành
ngay trước đích nhắm mục tiêu về thời gian giải quyết cho sự
cố đó bởi vì mục đích của việc leo thang cho hoạt động đó là
để đảm bảo rằng toàn bộ quy trình được hoàn tất đúng hạn.
 Tính hiệu quả của một quy trình hoặc thủ tục nói chung. Trong
trường hợp này, hộp ‘hoạt động’ đại diện cho toàn bộ quy trình
như một thực thể duy nhất. Ví dụ, Quản lý Thay đổi sẽ đo
lường sự thành công của quy trình bằng cách kiểm tra xem liệu
một thay đổi đã được triển khai đúng hạn hay chưa, theo đúng
đặc tả kỹ thuật và trong phạm vi ngân sách.
 Hiệu suất của một thiết bị. Ví dụ, hộp ‘hoạt động’ có thể đại
diện cho thời gian hồi đáp của một máy chủ với khối lượng
công việc nhất định.
 Hiệu suất của một loạt các thiết bị. Ví dụ, thời gian hồi đáp
cho người dùng đầu cuối cúa một ứng dụng trên toàn bộ hệ
thống mạng.
Để xác định cách thức sử dụng khái niệm các Vòng lặp Kiểm soát
Giám sát như thế nào trong Quản lý Dịch vụ, những câu hỏi dưới đây
cần phải được trả lời:
 Chúng ta xác định những gì cần phải được giám sát như thế
nào?
 Những ngưỡng phù hợp cho những gì được giám sát là gì?
 Việc giám sát sẽ được thực hiện như thế nào (thủ công hay tự
động hóa)?
 Những gì đại diện cho hoạt động bình thường?
 Những gì phục thuộc vào hoạt động bình thường?
 Những gì xảy ra khi chúng tôi nhận được thông tin đầu vào?
 Việc thực hiện đo lường nên được diễn ra với tần suất như thế
nào?
 Chúng ta có cần thực hiện việc đo lường chủ động để kiểm tra
xem liệu một mục có nằm trong phạm vi chuẩn mực không hoặc
chúng ta cần đợi đến khi một ngoại lệ được báo cáo (đo lường
thụ động)?
 Quản lý Vận hành có phải là chức năng duy nhất thực hiện việc
giám sát không?
 Nếu không, các trường hợp giám sát khác liên quan đến Quản
lý Vận hành như thế nào?
 Nếu có nhiều vòng lặp, những quy trình nào chịu trách nhiệm
cho từng vòng lặp?
Những phần sau đây sẽ mở rộng khái niệm về các Vòng lặp Kiểm
soát Giám sát và minh chứng cách mà những câu hỏi này được trả
lời như thế nào.
5.1.2. 2 Vòng l ặ p Kiể m soát Giám sát ITSM

Trong ITSM, Vòng lặp Kiểm soát Giám sát phức tạp có thể được trình
bày như được minh họa trong Hình 5.4.
Hình 5.4 – Vòng lặp Kiểm soát Giám sát ITSM
Hình 5.4 có thể được sử dụng để minh họa cho việc kiểm soát một
quy trình hoặc một thành phần được sử dụng để cung cấp một dịch
vụ. Trong sơ đồ này, từ ‘hoạt động’ có hàm ý rằng nó đề cập đến
một quy trình. Để áp dụng nó cho một dịch vụ, một ‘hoạt động’ cũng
có thể là một ‘Đơn vị Cấu hình’. Có một số tính năng đáng kể trong
Hình 5.4:
 Mỗi hoạt động trong một quy trình Quản lý Dịch vụ (hoặc từng
thành phần được sử dụng để cung cấp một dịch vụ) được giám
sát như là một phần của các quy trình Vận hành Dịch vụ. Nhóm
hoặc bộ phận vận hành chịu trách nhiệm cho từng hoặt động
hoặc thành phần sẽ áp dụng Vòng lặp Kiểm soát Giám sát như
đã xác định trong quy trình, và sử dụng các chuẩn mực đã
được định nghĩa trong các quy trình Thi ết kế Dịch vụ. Vai trò
của Kiểm soát và Giám sát Vận hành là để đảm bảo rằng quy
trình hoặc dịch vụ hoạt động một cách chính xác như đã được
chỉ định, đó là lý do tại sao họ chủ yếu quan tâm đến việc duy
trì hiện trạng.
 Các chuẩn mực và cơ chế Kiểm soát và Giám sát được xác định
trong Thiết kế Dịch vụ, tuy nhiên, chúng dựa trên các tiêu
chuẩn và kiến trúc được xác định trong giai đoạn Chiến lược
Dịch vụ. Bất kỳ thay đổi nào đối với Chiến lược Dịch vụ, kiến
trúc, danh mục dịch vụ hoặc các Yêu cầu Mức Dịch vụ của tổ
chức sẽ dẫn đến những thay đổi đối với những gì được giám
sát và với cách thức mà nó được kiểm soát.
 Các Vòng lặp Kiểm soát Giám sát được đặt trong bối cảnh của
tổ chức. Điều này có nghĩa rằng Chiến lược Dịch vụ sẽ chủ yếu
được thực thi bởi các nhà Điều hành Doanh nghiệp và Điều
hành CNTT với sự hỗ trợ từ các đại diện kinh doanh của nhà
thầu. Thiết kế Dịch vụ hoạt động như là một cầu nối giữa Chiến
lược Dịch vụ và Vận hành Dịch vụ và thường sẽ thu hút các đại
diện từ mọi nhóm. Các hoạt động và biện pháp kiểm soát nói
chung sẽ được thực thi bởi nhân viên CNTT (thỉnh thoảng có
liên quan đến người dùng) và được hỗ trợ bởi các Nhà quản lý
CNTT và các nhà thầu. Cải tiến Dịch vụ trải rộng qua mọi lĩnh
vực, nhưng chủ yếu dại diện ch lợi ích của doanh nghiệp và cho
người dùng của doanh nghiệp.
 Hãy lưu ý rằng mức giám sát thứ hai trong Vòng lặp Kiểm soát
Giám sát này được thực hiện bởi các quy trình Liên tục Cải tiến
Dịch vụ thông qua Chiến lược Dịch vụ và Thiết kế Dịch vụ.
Những mối quan hệ này được thể hiện bởi các mũi tên được
đánh số trong Hình 5.4 như sau:
o Mũi tên 1: Trong trường hợp này, Liên tục Cải tiến Dịch
vụ thừa nhận rằng dịch vụ sẽ được cải tiến bằng cách
thực hiện một thay đổi đối với Chiến lược Dịch vụ. Đây có
thể là kết quả của việc doanh nghiệp cần một thay đổi đối
với Danh mục Dịch vụ, hoặc rằng kiến trúc không cung
cấp những gì đã được kỳ vọng.
o Mũi tên 2: Trong trường hợp này, các Yêu cầu Mức Dịch
vụ cần phải được điều chỉnh. Có thể là dịch vụ quá đắt,
hoặc rằng cấu hình của cơ sở hạ tầng cần phải được thay
đổi để tăng cường hiệu suất, hoặc bởi vì Quản lý Vận
hành không có khả năng duy trì chất lượng dịch vụ trong
kiến trúc hiện hành.
o Mũi tên 3: Trong trường hợp này, các chuẩn mực được
chỉ định trong Thiết kế Dịch vụ không được tuân theo. Có
thể là bởi vì chúng không thích hợp hoặc không thể thực
hiện được, hoặc bởi vì thiếu giáo dục hoặc thiếu truyền
thông. Các chuẩn mực và sự thiếu tuân thủ cần phải được
điều tra và hành động được thực hiện để điều chỉnh tình
huống.
Chuyển tiếp Dịch vụ cung cấp một bộ các biện pháp kiểm tra và cân
bằng chính trong những quy trình này. Nó thực hiện điều đó như
sau:
 Đối với các dịch vụ mới, Chuyển tiếp Dịch vụ sẽ đảm bảo rằng
những kiến trúc kỹ thuật là thích hợp, và rằng các Tiêu chuẩn
Hiệu suất Vận hành có thể được thực hiện. Đến lượt nó, điều
này sẽ đảm bảo rằng các nhóm hoặc bộ phận Vận hành Dịch vụ
có khả năng đáp ứng các Yêu cầu Mức Dịch vụ.
 Đối với các dịch vụ hiện hữu, Quản lý Thay đổi sẽ quản lý bất
kỳ thay đổi nào được yêu cầu như là một phần của một biện
pháp kiểm soát (ví dụ, tinh chỉnh) cũng như là bất kỳ thay đổi
nào được trình bày bằng các mũi tên được dán nhãn 1, 2 và 3.
Mặc dù Chuyển tiếp Dịch vụ tự thân nó không xác định chiến
lược và thiết kế các dịch vụ nhưng nó cung cấp sự điều phối và
bảo đảm rằng các dịch vụ đang hoạt động, và sẽ tiếp tục hoạt
động, như đã được lập kế hoạch.
5.1.2. 3 Xác đ ị nh nh ững g ì c ầ n đư ợ c gi ám sát
Định nghĩa về những gì cần phải được giám sát dựa trên hiểu biết về
kết quả mong muốn của một quy trình, thiết bị hoặc hệ thống. CNTT
nên tập trung vào dịch vụ và tác động của nó đến doanh nghiệp thay
vì chỉ tập trung vào các thành phần riêng lẻ của công nghệ. Câu hỏi
đầu tiên cần được hỏi là ‘Chúng ta đang cố gắng đạt được điều gì?’.
5.1.2. 4 Kiểm soát và Giám sát N ội b ộ v à B ên ngoài

Ngay từ ban đầu, rõ ràng là có hai mức độ giám sát:
 Kiểm soát và Giám sát Nội bộ: Hầu hết các nhóm hoặc bộ
phận đều quan tâm đến việc có khả năng thực hiện một cách
có hiệu quả và hiệu suất những nhiệm vụ đã được chỉ định cho
họ. Do đó, họ sẽ giám sát những mục và những hoạt động nằm
dưới sự kiểm soát trực tiếp của họ. Kiểu kiểm soát và giám sát
này tập trung vào các hoạt động được tự đóng gói trong phạm
vi của nhóm hoặc bộ phận. Ví dụ, Nhà quản lý Bộ phận Hỗ trợ
Dịch vụ sẽ giám sát khối lượng các cuộc gọi để xác định xem
bao nhiêu nhân viên hỗ trợ cần phải sẵn sàng để trả lời điện
thoại.
 Kiểm soát và Giám sát Bên ngoài: Mặc dù từng nhóm hoặc
bộ phận chịu trách nhiệm cho việc giám sát lĩnh vực của riêng
mình nhưng họ không hoạt động một cách độc lập. Mọi nhiệm
vụ mà họ hoàn thành, hoặc thiết bị mà họ quản lý, đều có một
tác động đến sự thành công của toàn thể tổ chức. Từng nhóm
hoặc bộ phận cũng sẽ kiểm soát các mục và các hoạt động dưới
danh nghĩa của các nhóm, quy trình hoặc chức năng khác. Ví
dụ, nhóm Quản lý Máy chủ sẽ giám sát hiệu suất CPU trên các
máy chủ chính và tiến hành cân bằng tải trọng công việc để từ
đó một ứng dụng tối quan trọng có khả năng vẫn nằm trong
phạm vi ngưỡng hiệu suất được thiết lập bởi Quản lý Ứng dụng.
Sự tương phản giữa Giám sát Nội bộ và Giám sát Bên ngoài là một
điều rất quan trọng. Nếu Vận hành Dịch vụ chỉ tập trung vào Giám
sát Nội bộ, nó sẽ có một cơ sở hạ tầng được quản lý tốt nhưng sẽ
không có cách tìm hiểu hoặc ảnh hưởng đến chất lượng của dịch vụ.
Nếu nó chỉ tập trung vào Giám sát Bên ngoài, nó s ẽ hiểu chất lượng
dịch vụ kém đến mức nào nhưng sẽ không có ý tưởng gì về những gì
đã gây ra sự kém cỏi trong chất lượng dịch vụ hoặc về cách thức để
thay đổi nó như thế nào.
Trong thực tế, hầu hết các tổ chức đều kết hợp Giám sát Nội bộ và
Giám sát Bên ngoài, tuy nhiên, trong r ất nhiều trường hợp, hai yếu
tố này đã không được liên kết với nhau. Ví dụ, nhóm Quản lý Máy
chủ biết chính xác rằng các máy chủ đang hoạt động tốt đến mức
nào và Nhà quản lý Mức Dịch vụ biết chính xác người dùng đang
nhận được những dịch vụ được cung cấp bởi những máy chủ này với
mức chất lượng như thế nào. Tuy nhiên, không ai trong s ố họ (Quản
lý Máy chủ và Nhà quản lý Mức Dịch vụ) biết được cách thức để liên
kết các chỉ số này với nhau để xác định mức hiệu suất nào của máy
chủ đang thể hiện cho một dịch vụ có chất lượng tốt. Điều này thậm
chí trở nên lộn xộn hơn khi hiệu suất máy chủ là có thể chấp nhận
được vào giữa tháng nhưng lại không thể chấp nhận được tại thời
điểm cuối tháng.
5.1.2. 5 Xác đ ị nh m ụ c tiêu đ ố i v ớ i Giám sát và Ki ểm

soát
Rất nhiều tổ chức khởi đầu bằng cách hỏi rằng ‘Chúng ta đang quản
lý những gì?’. Điều này sẽ luôn luôn dẫn đến một Hệ thống Giám sát
Nội bộ mạnh mẽ, với rất ít mối liên kết với những kết quả hoặc dịch
vụ thực tế được yêu cầu bởi doanh nghiệp.
Câu hỏi thích hợp hơn sẽ là ‘Kết quả sau cùng của các hoạt động và
thiết bị mà nhóm của tôi đang quản lý là gì?’. Do đó, vị trí tốt nhất
khởi đầu, khi xác định những gì cần giám sát, chính là xác định
những kết quả mong muốn.
Lý tưởng nhất, định nghĩa về các mục tiêu Kiểm soát và Giám sát
nên bắt đầu bằng định nghĩa về những tài liệu về các Yêu cầu Mức
Dịch vụ (xem ấn phẩm Thiết kế Dịch vụ). Chúng sẽ chỉ định cách
thức mà khách hàng và người dùng đo lường hiệu suất của dịch vụ,
và được sử dụng như là đầu vào của các quy trình Thiết kế Dịch vụ.
Trong giai đoạn Thiết kế Dịch vụ, các quy trình khác nhau sẽ xác
định cách thức mà dịch vụ sẽ được cung cấp và quản lý như thế nào.
Ví dụ, Quản lý Công suất sẽ xác định cách thức phù hợp và hiệu quả
chi phí nhất để cung cấp mức hiệu suất được yêu cầu. Quản lý Tính
sẵn sàng sẽ xác định cách thức mà cơ sở hạ tầng có thể được thiết
lập cấu hình để gây ra ít điểm đơn lỗi nhất.
Nếu có bất kỳ nghi ngờ nào về tính xác thực hoặc hoàn chỉnh của
các mục tiêu, khuôn khổ COBIT sẽ cung cấp một bộ các mục tiêu cấp
cao và toàn diện như là một danh sách kiểm tra. Thông tin thêm về
COBIT được cung cấp trong Phụ lục A của ấn phẩm này.
Quy trình Thiết kế Dịch vụ sẽ giúp xác định các bộ đầu vào dưới đây
để định nghĩa những chuẩn mực và cơ chế Kiểm soát và Giám sát
Vận hành:
 Họ sẽ làm việc với khách hàng và người dùng để xác định cách
mà kết quả đầu ra của dịch vụ được đo lường như thế nào.
Điều này sẽ bao gồm các cơ chế, tần suất và lấy mẫu đo lường.
Phần này của Thiết kế Dịch vụ sẽ đặc biệt tập trung vào các
Yêu cầu Chức năng.
 Họ sẽ xác định các Đơn vị Cấu hình chính yếu, cách mà chúng
nên được thiết lập cấu hình như thế nào, và mức hiệu suất và
tính sẵn sàng nào là bắt buộc để đáp ứng các Mức Dịch vụ đã
được thống nhất.
 Họ sẽ làm việc với các nhà phát triển và các nhà thầu của các
Đơn vị Cấu hình tạo thành nên từng dịch vụ để xác định bất kỳ
ràng buộc hoặc giới hạn nào trong các thành phần đó.
 Mọi nhóm và bộ phận hỗ trợ và cung cấp sẽ cần xác định
những thông tin nào sẽ giúp họ thực hiện vai trò của họ một
cách hiệu quả. Một bộ phận của Thiết kế Dịch vụ và phát triển
sẽ đo đạc từng dịch vụ để từ đó nó có thể được giám sát để
cung cấp nhũng thông tin này, hoặc từ đó, nó có thể tạo ra
những sự kiện có ý nghĩa.
Tất cả những điều này có nghĩa là một phần cực kỳ quan trọng của
việc xác định Vận hành Dịch vụ giám sát những gì và cách thức mà
Vận hành Dịch vụ thực thi các biện pháp kiểm soát là để xác định
các bên liên quan của từng dịch vụ.
Các bên liên quan có thể được xác định là bất kỳ ai có được lợi ích
trong việc cung cấp thành công và nhận được các dịch vụ CNTT.
Từng bên liên quan sẽ có quan điểm khác nhau về những gì họ cần
để cung cấp hoặc nhận được một dịch vụ CNTT. Vận hành Dịch vụ sẽ
cần phải hiểu về từng quan điểm này nhằm xác định được chính xác
những gì cần phải được giám sát và cần phải làm gì với những đầu
vào này.
Do đó, Vận hành Dịch vụ sẽ dựa vào Quản lý Mức Dịch vụ để xác
định một cách chính xác về những bên liên quan là ai và cá ch thức
mà họ đóng góp cho hoặc sử dụng dịch vụ như thế nào. Điều này sẽ
được thảo luận đầy đủ hơn trong các ấn phẩm Thiết kế Dịch vụ và
Lưu ý về các Mục tiêu Giám sát Nội bộ và Bên ngoài
Kết quả mong muốn có thể là nội bộ hoặc bên ngoài đối với các chức năng Vận
hành Dịch vụ, mặc dù nên luôn luôn lưu ý rằng một hành động nội bộ sẽ thường
có một kết quả bên ngoài. Ví dụ, việc hợp nhất các mày chủ để khiến cho chúng
dễ dàng quản lý hơn có thể dẫn đến việc tiết kiệm chi phí, vốn sẽ nhr hưởng đến
việc thương lượng Quản lý Mức Dịch vụ và chu kỳ đánh giá cũng như các quy
trình Quản lý Tài chính.
5.1.2. 6 Các ki ểu giá m sát

Có rất nhiều kiểu công cụ giám sát khác nhau và những tình huống
khác nhau mà trong đó, từng công cụ này sẽ được sử dụng. Phần
này tập trung vào một số kiểu giám sát khác nhau có thể được thực
hiện và khi nào thì chúng sẽ phù hợp.
Giám sát Chủ động so với Thụ động
 Giám sát Chủ động đề cập đến việc ‘thẩm tra’ liên tục một thiết
bị hoặc hệ thống để xác định trạng thái của nó. Kiểu giám sát
này có thể tố nhiều tài nguyên và thường được dành riêng để
giám sát một cách chủ động tín sẵn sàng của các thiết bị hoặc
hệ thống tối quan trọng, hoặc như một bước chẩn đoán khi cố
gắng giải quyết một Sự cố hoặc chẩn đoán một vấn đề.
 Giám sát Thụ động phổ biến hơn và đề cập đến việc tạo ra và
chuyển tiếp các sự kiện cho một ‘thiết bị nghe’ hoặc một tác
nhân giám sát. Giám sát Thụ động phụ thuộc vào việc định
nghĩa thành công các sự kiện và thiết bị đo đạc của hệ thống
đang được giám sát (xem phần 4.1).
Chủ động so với Ứng phó

 Giám sát Ứng phó được thiết kế để yêu cầu hoặc kích hoạt
hành động theo sau một kiểu sự kiện hoặc lỗi nhất định. Ví dụ,
sự sụt giảm trong hiệu suất của máy chủ có thể kích hoạt một
quá trình khởi động lại, hoặc một lỗi hệ thống sẽ tạo ra một sự
cố. Việc giám sát ứng phó không chỉ được sử dụng cho các
ngoại lệ. Nó cũng có thể được sử dụng như một phần của các
thủ tục vận hành bình thường, vốn thúc đẩy việc lập lịch trình
hệ thống để đệ trình công việc theo lô kế tiếp.
 Giám sát Chủ động được sử dụng để phát hiện các hình mẫu sự
hiện mà sẽ chỉ ra rằng một hệ thống hoặc dịch vụ có thể sắp
sửa bị lỗi. Giám sát chủ động nói chúng được sử dụng trong
những môi trường trưởng thành hơn, nơi mà những hình mẫu
đó đã từng được phát hiện trước đây, thường là một vài lần.
Do đó, các công cụ Giám sát Chủ động là một phương tiện để
tự động hóa trải nghiệm của những nhân viên CNTT dày dạn
kinh nghiệm và thường được tạo ra thông qua quy trình Quản
lý Vấn đề Chủ động (xem ấn phẩm Liên tục Cải tiến Dịch vụ).
Hãy lưu ý rằng Giám sát Ứng phó và Giám sát Chủ động có thể là
chủ động hoặc thụ động (active/passive) như trong B ảng 5.1:
Chủ động Thụ động
Ứng phó Được sử dụng để chẩn đoán thiết bị Phát hiện và tương quan các hồ sơ
nào đang gây ra lỗi và dưới điều kiện sự kiện để xác định ý nghĩa của
nào (ví dụ, ‘ping’ một thiết bị, hoặc các sự kiện và các hành động thích
chạy và theo dõi một giao dịch mẫu hợp (ví dụ, một người dùng đăng
thông qua một loạt các thiết bị). nhập 3 lần với mật khẩu sai, vốn
sẻ tạo ra những biểu hiện cho một
Đòi hỏi những kiến thức về sơ đồ địa
ngoại lệ bảo mật và được leo thang
hình cơ sở hạ tầng và việc ánh xạ các
thông qua các thủ tục Quản lý Bảo
dịch vụ với các Đơn vị Cấu hình.
mật Thông tin).
Đòi hỏi những kiến thức về hoạt

động bình thường của cơ sở hạ
tầng và các dịch vụ.
Chủ động Được sử dụng để xác định trạng thái Các hồ sơ sự kiện được tương quan
theo thời gian thực của một thiết bị, theo thời gian để xây dựng những
hệ thống hoặc dịch vụ - thường là đối khuynh hướng cho Quản lý Vấn đề
với các thành phần tối quan trọng hoặc Thụ động.
sau một quá trình khôi phục một thiết
Các hình mẫu hoặc sự kiện được
bị bị lỗi để đảm bảo rằng nó đã được
xác định và lập trình trong các
khôi phục hoàn toàn (nghĩa là sẽ
công cụ tương quan để nhận biết
không gây ra thêm sự cố).
trong tương lai.
Đo lường Liên tục so với Đo lường Dựa trên-Ngoại lệ
 Đo lường Liên tục tập trung vào việc giám sát một hệ thống
trong thời gian thực để đảm bảo rằng nó tuân thủ một chuẩn
mực hiệu suất (ví dụ, một máy chủ ứng dụng sẵn sàng trong
99.9% của giờ dịch vụ đã được thống nhất). Sự khác biệt giữa
Đo lường Liên tục và Giám sát Chủ động (Active Monitoring) là
rằng Giám sát Chủ động không nhất thiết phải liên tục. Tuy
nhiên, cũng giống như Giám sát Chủ động, Đo lường Liên tục
sẽ tiêu tốn tài nguyên và thường được dành riêng cho những
thành phần hoặc dịch vụ tối quan trọng. Trong hầu hết các
trường hợp, chi phí của băng thông và năng lực xử lý bổ sung
sẽ ảnh hưởng nhiều đến lợi ích của đo lường liên tục. Trong
những trường hợp đó, việc giám sát sẽ thường dựa vào việc lấy
mẫu và phân tích thống kê (ví dụ, hiệu suất hệ thống được báo
cáo mỗi 30 giây và được ngoại suy để thể hiện hiệu suất tổng
thể). Phương pháp đo lường sẽ phải được lập thành tài liệu và
được thống nhất trong các OLA để đảm bảo rằng nó đủ để hỗ
trợ cho các Yêu cầu Báo cáo Dịch vụ (xem ấn phẩm Liên tục Cải
tiến Dịch vụ).
 Đo lường Dựa trên-Ngoại lệ không đo lường hiệu suất của một
dịch vụ hoặc hệ thống theo thời gian thực những phát hiện và
báo cáo các trường hợp ngoại lệ. Ví dụ, một sự kiện được tạo
ra nếu như một giao dịch không hoàn tất, hoặc nếu đạt đưuọc
một ngưỡng hiệu suất. Đây là biện pháp hiệu quả chi phí nhất
và dễ đo lường hơn, nhưng có thể dẫn đến thời gian ngừng
dịch vụ lâu hơn. Đo lường Dựa trên-Ngoại lệ được sử dụng cho
các dịch vụ ít quan trọng hơn hoặc trên các hệ thống nơi chi
phí là một vấn đề quan trọng. Nó cũng được sử dụng ở nơi mà
các công cụ CNTT không có khả năng xác định được trạng thái
hoặc chất lượng của một dịch vụ (ví dụ, nếu chất lượng in ấn
là một phần của đặc tả kỹ thuật dịch vụ, cách duy nhất để đo
lường điều này là điều tra về mặt vật lý – thường được thực
hiện bởi người dùng thay vì bởi nhân viên CNTT). Khi Đo lường
Dựa trên-Ngoại lệ được sử dụng, điều quan trọng là cả OLA lẫn
SLA cho dịch vụ đó phải phản ảnh được điều này, vì sự gián
đoạn dịch vụ có khả năng xảy ra, và người dùng thường đòi hỏi
phải được báo cáo về ngoại lệ.
Hiệu suất so với kết quả đầu ra

Có một sự khác biệt quan trọng giữa việc báo cáo được sử
dụng để theo dõi hiệu suất của các thành phần hoặc các nhóm
hoặc bộ phận được sử dụng để cung cấp một dịch vụ và việc
báo cáo được sử dụng để chứng minh thành tựu của các mục
tiêu chất lượng dịch vụ.
Các nhà quản lý CNTT thường nhầm lẫn giữa những điều này
bằng cách báo cáo cho doanh nghi ệp về hiệu suất của đội
nhóm hoặc bộ phận của họ (ví dụ, số lượng các cuộc gọi đã
được nhận bởi Chuyên gia phân tích Hỗ trợ Dịch vụ), như thể
đó là điều tương tự với chất lượng của dịch vụ (ví dụ, các sự
cố đã được giải quyết trong phạm vi thời gian đã được thống
nhất).
Giám sát Hiệu suất và các chỉ số nên được sử dụng trong nội
bộ bởi Quản lý Dịch vụ để xác định xem liệu con người, quy
trình và công nghệ đang hoạt động một cách đúng đắn và theo
đúng tiêu chuẩn.
Thay vào đó, người dùng và khách hàng sẽ xem báo cáo liên
quan đến chất lượng và hiệu suất của dịch vụ.
Mặc dù Vận hành Dịch vụ quan tâm đến cả hai loại báo cáo
nhưng mối quan tâm chủ yếu của ấn phẩm này là Giám sát Hiệu
suất, theo đó, việc giám sát Chất lượng Dịch vụ (hoặc Giám sát
Dựa trên-Đầu ra) sẽ được thảo luận chi tiết trong ấn phẩm Liên
tục Cải tiến Dịch vụ.
5.1.2. 7 Giám s át tro ng nh ững M ôi tr ư ờ ng Ki ểm
nghi ệ m
Như với Cơ sở hạ tầng CNTT, một Môi trường Kiểm nghiệm sẽ cần
phải xác định cách thức nó sử dụng giám sát và kiểm soát như thế
nào. Những biện pháp kiểm soát này được thảo luận đầy đủ hơn
trong ấn phẩm Chuyển tiếp Dịch vụ.
 Giám sát bản thân Môi trường Kiểm nghiệm: Một Môi
trường Kiểm nghiệm cấu thành từ cơ sở hạ tầng, các ứng
dụng và quy trình cần phải được quản lý và kiểm soát như
đối với bất kỳ môi trường nào khác. Thật hấp dẫn khi nghĩ
rằng Môi trường Kiểm nghiệm không cần giám sát và kiểm
soát nghiêm ngặt vì nó không phải là môi trường thực tế.
Tuy nhiên, luận cứ này không hợp lý. Nếu một Môi trường
Kiểm nghiệm không được giám sát và kiểm soát một cách
đúng đắn, sẽ rất nguy hiểm khi thực hiện các kiểm
nghiệm trên các thiết bị sai lệch khỏi các tiêu chuẩn đã
được xác định trong Thiết kế Dịch vụ.
 Giám sát các đơn vị đang được kiểm nghiệm: Kết quả của
kiểm nghiệm phải được theo dõi và kiểm tra một cách xác
đáng. Một điều cũng rất quan trọng là bất kỳ công cụ
giám sát nào đã được tích hợp vào các dịch vụ mới hoặc
đã được thay đổi cũng phải được kiểm nghiệm
5.1.2. 8 B áo cáo và hành đ ộng

‘Một mình báo cáo chỉ tạo ra sự nhận thức nhưng một báo cáo với
một kế hoạch hành động sẽ đạt được các kết quả’.
Việc giám sát mà không kiểm soát là không thích đáng và không
hiệu quả. Giám sát luôn luôn nên có mục đích đảm bảo rằng các mục
tiêu vận hành và mục tiêu dịch vụ đang được đáp ứng. Điều này có
nghĩa là trừ khi có một mục đích rõ ràng cho việc giám sát một hệ
thống hoặc dịch vụ, nó không nên được giám sát.
Điều này cũng có nghĩa là khi giám sát đã đư ợc xác định, bất kỳ
hành động bắt buộc nào cũng nên được thực hiện. Ví dụ, chỉ có khả
năng phát hiện ra một ứng dụng chính đã bị lỗi là không đủ. Nhóm
Quản lý Ứng dụng liên quan cũng nên phải xác định chính xác các
bước sẽ được thực hiện khi ứng dụng bị lỗi.
Ngoài ra, cũng nên công nhận rằng hành động có thể cần phải được
thực hiện bởi những người khác nhau, ví dụ, một sự kiện đơn lẻ
(chẳng hạn như lỗi ứng dụng) có thể kích hoạt hành động được thực
hiện bởi nhóm Quản lý Ứng dụng (để khôi phục dịch vụ), người dùng
(để khởi đầu việc xử lý thủ công) và cấp quản lý (để xác định sự
kiện này có thể được ngăn chặn trong tương lai như thế nào).
Những hàm ý của nguyên tắc này được phác thảo chi tiết hơn trong
mối tương quan với Quản lý Sự kiện (xem phần 4.1).
5.1.2. 9 Các cu ộc ki ể m toán V ậ n hành D ịch v ụ

Các cuộc kiểm toán định kỳ nên được thực hiện đối với các quy trình
và hoạt động Vận hành Dịch vụ để đảm bảo:
 Chúng đang được thực hiện như đã dự định,

 Không có gian lận,
 Chúng vẫn phù hợp với mục đích, hoặc để xác định bất kỳ thay
đổi hoặc cải tiến cần thiết nào.
Các Nhà quản lý Vận hành Dịch vụ có thể chọn tự mình tiến hành
những cuộc kiểm toán này, tuy nhiên, lý tưởng nhất là một số hình
thức yếu tố độc lập đối với các cuộc kiểm toán.
Nhóm hoặc bộ phận kiểm toán nội bộ của tổ chức có thể được yêu
cầu để được tham gia hoặc một số tổ chức có thể chọn thu hút các
công ty tư vấn/kiểm toán bên thứ ba để từ đó có được một quan
điểm chuyên môn hoàn toàn độc lập.
Các cuộc kiểm toán Vận hành Dịch vụ là một phần của việc đo lường
liên tục được thực hiện như một phần của Liên tục Cải tiến Dịch vụ
và được thảo luận chi tiết hơn trong ấn phẩm đó.
5.1.2. 10 Đo l ư ờ ng, các ch ỉ s ố và KPI
Phần này chủ yếu tập trung vào việc giám sát và kiểm soát là một cơ
sở cho Vận hành Dịch vụ. Những phần khác của ấn phẩm này đã đề
cập đến một số chỉ số cơ bản có thể được sử dụng để đo lường tính
hiệu quả và hiệu suất của một quy trình.
Mặc dù ấn phẩm này chủ yếu không phải là về đo lường và các chỉ
số, điều quan trọng là các tổ chức đang sử dụng những hướng dẫn
này có được những thước đo và chỉ số mạnh mẽ để hỗ trợ cho các
mục tiêu của sự tổ chức của chúng. Phần này là một tóm lược của
các khái niệm đó.
Đo l ư ờ ng
Đo lường chỉ trở nên có ý nghĩa khi nó có khả năng đo được kết quả
đầu ra hoặc quy mô thực tế của một hệ thống, chức năng hoặc quy
trình so với một mức tiêu chuẩn hoặc mức độ được mong muốn, ví
dụ, máy chủ phải có năng lực xử lý một lượng tối thiểu 100 giao
dịch tiêu chuẩn trong 1 phút. Điều này cần được xác định trong
Thiết kế Dịch vụ, và được tinh chỉnh theo thời gian thông qua Liên
tục Cải tiến Dịch vụ, tuy nhiên, bản thân việc đo lường diễn ra trong
giai đoạn Vận hành Dịch vụ.
Các ch ỉ s ố
Các chỉ số đề cập đến đánh giá định lượng và định kỳ về một quy trình, hệ thống
hoặc chức năng, cùng với các thủ tục và công cụ sẽ được sử dụng để thực hiện
những đánh giá này và các thủ tục để diễn giải chúng.
Định nghĩa này là rất quan trọng vì nó không chỉ chỉ định những gì
cần phải được đo lường, mà còn cách thức đo lường nó, phạm vi
hiệu suất có thể chấp nhận được là gì và những hành động nào sẽ
được thực hiện như là kết quả của hiệu suất bình thường hoặc một
ngoại lệ. Từ đó, rõ ràng là bất kỳ chỉ số nào được đưa ra trong phần
trước của ấn phẩm này là một chỉ số cơ bản và sẽ cần được áp dụng
và mở rộng trong phạm vi bối cảnh của từng tổ chức trước khi nó có
thể trở nên có hiệu quả.
C ác Ch ỉ s ố Hi ệu su ấ t Then ch ốt
Các chỉ số đề cập đến đánh giá định lượng và định kỳ về một quy trình, hệ thống
hoặc chức năng, cùng với các thủ tục và công cụ sẽ được sử dụng để thực hiện
những đánh giá này và các thủ tục để diễn giải chúng.
Các KPI là độc đáo đối với từng tổ chức và phải liên quan đến các
đầu vào, kết quả đầu ra và hoạt động cụ thể. Chúng không chung
chung hoặc phổ quát và do đó, không được bao gồm trong ấn phẩm
này.
Một lý do khác nữa để không bao gồm chúng là thực tế rằng, các chỉ
số tương tự có thể được sử dụng để đạt được các KPI rất khác nhau.
Ví dụ, một tổ chức sử dụng chỉ số ‘Tỷ lệ phần trăm các sự cố được
giải quyết bởi Bộ phận Hỗ trợ Dịch vụ’ để đánh giá hiệu suất của Bộ
phận Hỗ trợ Dịch vụ. Điều này đã hoạt động một cách hiệu quả
trong khoảng 2 năm, sau đó, nhà quản lý CNTT bắt đầu nhận ra rằng
KPI này đã được sử dụng để ngăn cản Quản lý Vấn đề hiệu quả,
nghĩa là, nếu như sau 2 năm, 80% của mọi sự cố là đủ dễ để được
xử lý trong vòng 10 phút theo cuộc gọi đầu tiên, tại sao chúng ta
không đưa ra một giải pháp nào cho chúng? Trong th ực tế, giờ đây
KPI đã trở thành một thước đo về mức độ kém hiệu quả của các
nhóm Quản lý Vấn đề.
5.1.2. 11 Các tương tác v ớ i nh ững t h ực ti ễn Vòn g

đờ i D ị ch v ụ khác
Giám s át V ậ n hành và Liên t ụ c C ả i tiế n D ịch v ụ

Phần này tập trung vào Báo cáo và Giám sát V ận hành, tuy nhiên
việc giám sát cũng hình thành nên đi ểm khởi đầu cho Liên tục Cải
tiến Dịch vụ. Điều này được đề cập trong ấn phẩm Liên tục Cải tiến
Dịch vụ, nhưng những điểm khác biệt chính được phác thảo ở đây.
Chất lượng là mục tiêu chính yếu của việc giám sát để Liên tục Cải
tiến Dịch vụ. Do đó, giám sát sẽ tập trung vào tính hiệu quả của một
dịch vụ, quy trình, công cụ, tổ chức hoặc một Đơn vị Cấu hình.
Trọng tâm không được đặt vào việc đảm bảo hiệu suất dịch vụ theo
thời gian thực mà thay vào đó, đặt vào việc xác định nơi mà các cải
tiến có thể được đưa ra đối với mức dịch vụ hoặc hiệu suất CNTT
hiện hữu.
Do đó, việc giám sát đối với Liên tục Cải tiến Dịch vụ có khuynh
hướng tập trung vào việc phát hiện ra các ngoại lệ và tìm ra các giải
pháp. Ví dụ, Liên tục Cải tiến Dịch vụ không quan tâm đến việc liệu
một sự cố đã được giải quyết hay chưa, mà là liệu nó đã được giải
quyết trong phạm vi thời gian đã được thống nhất hay chưa và liệu
các sự cố trong tương lai có thể được ngăn chặn hay không.
Tuy nhiên, Liên tục Cải tiến Dịch vụ không chỉ quan tâm đến các
ngoại lệ. Nếu một SLA được đáp ứng một cách nhất quán theo thời
gian, Liên tục Cải tiến Dịch vụ cũng sẽ quan tâm đến việc xác định
xem liệu rằng mức hiệu suất đó có thể được duy trì với một mức chi
phí thấp hơn hay không hoặc liệu nó có cần phải được nâng cấp
thành, thậm chí, một mức hiệu suất tốt hơn không. Do đó, Liên tục
Cải tiến Dịch vụ có thể cũng cần phải truy cập đến các báo cáo hiệu
suất định kỳ.
Tuy vậy, vì Liên tục Cải tiến Dịch vụ không có khả năng cần đến,
hoặc có khả năng đối phó với, khối lượng dữ liệu khổng lồ được tạo
ra bởi mọi hoạt động giám sát, chúng có khả năng sẽ tập trung nhất
vào một tập hợp con giám sát cụ thể tại một bất kỳ thời điểm nhất
định nào. Điều này có thể được xác định bởi đầu vào từ doanh
nghiệp hoặc những cải tiến đối với công nghệ.
Điều này có 2 hàm ý chính như sau:
 Việc giám sát đối với Liên tục Cải tiến Dịch vụ sẽ thay đổi theo
thời gian. Chúng có thể quan tâm đến việc giám sát dịch vụ
email trong một quý và sau đó chuyển sang các hệ thống Nhân
sự trong quý tiếp theo.
 Điều này có nghĩa rằng Vận hành Dịch vụ và Liên tục Cải tiến
Dịch vụ cần phải xây dựng một quy trình mà sẽ giúp chúng
thống nhất về những lĩnh vực nào cần phải được giám sát và
cho mục đích gì.
5.2 Vận hành CNTT

5.2.1 Q uả n lý B ả ng đi ều khi ển ( consol e) /C ầ u n ối
Hoạ t đ ộng
Những điều này cung cấp một điểm điều phối trung tâm cho việc
quản lý các lớp sự kiện khác nhau, phát hiện các sự cố, quản lý các
hoạt động vận hành thường lệ và báo cáo về tình trạng hoặc hiệu
suát của các thành phần công nghệ.
Quan sát và giám sát Cơ sở hạ tầng CNTT có thể diễn ra từ một

bảng điều khiển tập trung – nơi mà mọi sự kiện hệ thống được định
tuyến đến đó. Về mặt lịch sử, điều này liên quan đến việc giám sát
bảng điều khiển hoạt động chính của một hoặc nhiều máy chủ lớn
(mainframe) – tuy nhiên, ngày nay có nhiều khả năng liên quan đến
việc giám sát (các) cụm máy chủ, các thiết bị lưu trữ, các thành
phần mạng, ứng dụng, cơ sở dữ liệu và bất kỳ Đơn vị Cấu hình nào
khác, bao gồm bất kỳ (các) máy chủ lớn còn lại nào, từ một vị trí
duy nhất, còn được gọi là Cầu nối Vận hành.
Có hai giả thuyết nói về cách mà người ta đặt tên cho Cầu nối Vận
hành. Một là nó tương tự một cầu nối của một con tàu lớn và được
tự động hóa (chẳng hạn như các con tàu không gian thư ờng thấy
con các bộ phim khoa học viễn tưởng). Giả thuyết còn lại cho rằng
Cầu nối Vận hành đại diện cho một liên kết giữa các nhóm Vận hành
CNTT và Bộ phận Hỗ trợ Dịch vụ truyền thống. Trong một số tổ
chức, điều này có nghĩa là các chức năng của Kiểm soát Vận hành và
Bộ phận Hỗ trợ Dịch vụ được sáp nhập lại thành Bộ phận Hỗ trợ Dịch
vụ vốn thực hiện cả hai nhiệm vụ trong một vị trí vật lý duy nhất.
Bất kể nó đã được đặt tên là gì, một Cầu nối Vận hành sẽ kết hợp
các điểm quan sát quan trọng với nhau trong phạm vi Cơ sở hạ tầng
CNTT để từ đó chúng có thể được giám sát và quản lý từ một vị trí
trung tập với nỗ lực tối thiểu. Các thiết bị đang được giám sát có
khả năng phân tán về mặt vật lý và có thể được đặt trong các bộ cài
đặt máy tính tập trung hoặc phân tán trong cộng đồng người dùng,
hoặc cả hai.
Cầu nối Vận hành sẽ kết hợp rất nhiều hoạt động, vốn có thể bao
gồm Quản lý Bảng điều khiển, xử lý sự kiện, quản lý mạng tuyến
đầu, Lập lịch trình Công việc và hỗ trợ ngoài giờ (bao hàm Thiết kế
Dịch vụ và các nhóm hỗ trợ tuyến hai nếu họ không hoạt động
24/7). Trong một vài tổ chức, Bộ phận Hỗ trợ Dịch vụ là một phần
của Cầu nối Vận hành.
Vị trí vật lý và sơ đồ bố trí của Cầu nối Vận hành cần phải được
thiết kế một cách cẩn trọng để cung cấp khả năng tiếp cận và hiển
thị chính xác của tất cả các màn hình và thiết bị có liên quan cho
những cá nhân đã được cấp phép. Tuy nhiên, điều này sẽ trở thành
một lĩnh vực rất nhạy cảm khi truy cập được kiểm soát và an ninh
chặt chẽ sẽ là điều thiết yếu.
Các tổ chức nhỏ hơn có thể không có một Cầu nối Vận hành vật lý,
nhưng chắc chắn sẽ có nhu cầu đối với Quản lý Bảng điều khiển,
thường được kết hợp với các vai trò kỹ thuật khác. Ví dụ, một nhóm
đơn lẻ bao gồm các nhân viên kỹ thuật sẽ quản lý hệ thống mạng,
các máy chủ và ứng dụng. Một phần của vai trò của họ sẽ là giám
sát các bảng điều khiển của những hệ thống này – thường sử dụng
các bảng điều khiển ảo để từ đó họ có thể thực hiện các hoạt động
từ bất kỳ vị trí nào. Tuy nhiên, nên lưu ý r ằng những bảng điều
khiển ảo này là những công cụ mạnh mẽ và, nếu được sử dụng trong
những vị trí không được bảo vệ, hoặc qua các kết nối không an
toàn, có thể đại diện cho một mối đe dọa bảo mật đáng kể.
5.2.2 Lậ p lịc h trình Công vi ệc

Vận hành CNTT sẽ tiến hành các công việc thường nhật, các truy vấn
tiêu chuẩn hoặc các báo cáo đã được ủy thác cho nó như một phần
của việc cung cấp các dịch vụ, hoặc như một phần của công việc
quản gia thường nhật được ủy thác bởi các nhóm Quản lý Ứng dụng
và Kỹ thuật.
Lập lịch trình Công việc liên quan đến việc xác định và khởi đầu các
gói phần mềm lập lịch trình công việc để chạy các công việc hàng
loạt và theo thời gian thực. Việc này thường liên quan đến những
lịch trình hàng ngày, hàng tuần, hàng tháng, hàng năm và đ ột xuất
để đáp ứng các nhu cầu của doanh nghiệp.
Ngoài thiết kế ban đầu, hoặc tái thiết kế định kỳ, của các lịch trình,
có khả năng sẽ có những sửa đổi hoặc điều chỉnh thường xuyên
được thực hiện trong suốt thời gian đó để những công việc phụ
thuộc được xác định và điều chỉnh. Cũng có thể sẽ có một vai trò
trong việc xác định các cảnh báo và Báo cáo Ngoại lệ sẽ được sử
dụng cho việc giám sát/kiểm tra các lịch trình công việc. Quản lý
Thay đổi đóng một vai trò quan trọng trong việc đánh giá và xác
minh những thay đổi lớn đối với lịch trình, cũng như là trong việc
tạo ra các thủ tục Thay đổi Tiêu chuẩn đối với những thay đổi
thường lệ hơn.
Các tham số thời gian-chạy (run-time) và/hoặc các tập tin phải nhận
được (hoặc được xúc tiến nếu bị trì hoãn) và đầu vào – và mọi nhật
ký thời gian-chạy phải được kiểm tra và bất kỳ lỗi nào phải được xác
định.
Nếu xảy ra lỗi, việc chạy lại phải được khởi động, theo hướng dẫn
của các đơn vị kinh doanh thích hợp, thường là với các tham số khác
hoặc các phiên bản dữ liệu/tập tin đã được điều chỉnh. Điều này sẽ
đòi hỏi việc truyền thông cẩn trọng để đảm bảo các tham số và tập
tin chính xác được sử dụng.
Rất nhiều tổ chức phải đối mặt với sự gia tăng của các lịch trình
công việc hàng loạt qua đêm, vốn có thể, nếu chúng hoạt động vượt
quá thời điểm công việc hàng loạt qua đêm, gây ảnh hưởng xấu đến
các dịch vụ ban ngày trực tuyến – vì vậy, họ (các tổ chức) đang tìm
cách sử dụng tối đa công suất và hiệu suất ban đêm, kết hợp với
Quản lý Công suất. Đây là nơi mà các kỹ thuật Quản lý Khối lượng
công việc có thể sẽ rất hữu ích, chẳng hạn như:
 Việc lập lại lịch trình công việc để tránh sự ganh đua của các
thiết bị cụ thể hoặc tại những thời điểm cụ thể và cải thiện
được thông lượng tổng thể.
 Chuyển đổi khối lượng công việc cho các nền tảng/môi trường
thay thế để đạt được hiệu suất và/hoặc thông lượng đã được
cải thiện (những năng lực ảo hóa khiến cho điều này trở nên
khả thi hơn nhiều bằng cách cho phép sự chuyển đổi động và
được tự động hóa).
 Định thời gian và ‘xen kẽ’ các công việc một cách cẩn thận để
có được mức sử dụng tối đa của các tài nguyên sẵn có.
Lập lịch trình Công việc đã trở thành hoạt động cực kỳ phức tạp,
bao gồm bất kỳ số lượng các biến số nào – chẳng hạn như độ nhạy
cảm với-thời gian, các phụ thuộc quan trọng và không quan trọng,
cân bằng khối lượng công việc, lỗi và đệ trình lại, v.v… Kết quả là,
phần lớn hoạt động dựa trên các công cụ Lập lịch trình Công việc để
hỗ trợ Vận hành CNTT lập lịch trình công việc đối với việc tối ưu hóa
việc sử dụng công nghệ để đạt được các Mục tiêu Mức Dịch vụ.
Thế hệ mới nhất của các công cụ lập lịch trình cho phép một bộ
công cụ duy nhất để lập lịch trình và tự động hóa các hoạt động kỹ
thuât và các hoạt động quy trình Quản lý Dịch vụ (chẳng hạn như
Lập lịch trình Thay đổi). Mặc dù đây là một cơ hội tốt để cải thiện
hiệu suất nhưng nó cũng đại diện cho một điểm đơn lỗi lớn hơn. Do
đó, các tổ chức đang sử dụng kiểu công cụ này vẫn sử dụng các giải
pháp trọng điểm như các tác nhân và là một bản sao lưu trong
trường hợp bộ công cụ chính bị lỗi.
5.2.3 Sao lư u và Khôi ph ục

Sao lưu và Khôi phục là một thành phần thiết yếu của Hoạch định
Liên tục Dịch vụ CNTT tốt. Vậy nên, Thiết kế Dịch vụ nên đảm bảo
rằng có một chiến lược sao lưu vững chắc cho từng dịch vụ và
Chuyển tiếp Dịch vụ nên đảm bảo rằng chúng đã được kiểm nghiệm
một cách đúng đắn.
Ngoài ra, các yêu cầu quy định chỉ định rằng các kiểu tổ chức nhất
định (chẳng hạn như Dịch vụ Tài chính hoặc các công ty niêm yết)
phải có sẵn một chiến lược Sao lưu và Khôi phục và rằng chiến lược
này được thực thi và được kiểm toán. Điều này nên được xác định
trong giai đoạn Thiết kế Dịch vụ và được tích hợp trong chức năng
và tài liệu của dịch vụ.
Điểm duy nhất của việc sao lưu là chúng có thể cần phải được khôi
phục tại một số điểm. Vì lý do này, việc xác định cách thức sao lưu
một hệ thống không quan trọng bằng việc xác định những thành
phần nào gặp rủi ro và cách để giảm thiểu những rủi ro đó một cách
hiệu quả.
Có một số các công cụ có sẵn để Sao lưu và Khôi phục, nhưng một
điều đáng để lưu ý rằng các tính năng của những công nghệ lưu trữ
được sử dụng cho dữ liệu kinh doanh đang được sử dụng để sao
lưu/khôi phục (ví dụ, chụp ảnh nhanh). Do đó, ngày càng có nhiều
mức tích hợp giữa các hoạt động Sao lưu và Khôi phục với các hoạt
động Lưu trữ và Lưu giữ (xem phần 5.6).
5.2.3. 1 Sao lư u
Dữ liệu của tổ chức phải được bảo vệ và điều này bao gồm việc sao
lưu (sao chép) và lưu trữ dữ liệu trong một vị trí ngoại biên, nơi mà
nó có thể được bảo vệ - và được sử dụng nếu nó phải được khôi
phục do mất mát, sai lệch hoặc triển khai các Kế hoạch Liên tục Dịch
vụ CNTT.
Một chiến lược sao lưu tổng thể phải được thống nhất với doanh
nghiệp, bao gồm:
 Những dữ liệu nào phải được sao lưu và tần suất và khoảng
thời gian sẽ được sử dụng.
 Bao nhiêu phiên bản của dữ liệu phải được giữ lại – điều này
có thể khác nhau tùy theo kiểu dữ liệu sẽ được sao lưu, hoặc
kiểu của tập tin (ví dụ, tập tin dữ liệu hoặc ứng dụng có thể
thực thi được).
 Kiểu sao lưu (đầy đủ, một phần, gia tăng) và các điểm kiểm tra
được sử dụng.
 Vị trí sẽ được sử dụng để lưu trữ (có khả năng bao gồm các địa
điểm khôi phục sau thảm họa) và các lịch trình khôi phục.
 Phương pháp truyền tải (ví dụ, truyền tập tin qua mạng, vận
chuyển vật lý các phương tiện từ tính).
 Kiểm nghiệm/kiểm tra sẽ được thực hiện, chẳng hạn như kiểm
tra-đọc, kiểm tra khôi phục, kiểm tra tổng, v.v…
 Mục tiêu Điểm Khôi phục (Recovery Point Objective). M ục tiêu
này mô tả điểm mà tại đó, dữ liệu sẽ được khôi phục sau khi
khôi phục một dịch vụ CNTT. Cũng có thể liên quan đến việc
mất dữ liệu. Ví dụ, một Mục tiêu Điểm Khôi phục là 1 ngày có
thể được hỗ trợ bởi các bản sao lưu hàng ngày, và lượng dữ
liệu bị mất có thể lên đến 24 giờ. Các Mục tiêu Điểm Khôi phục
cho từng dịch vụ nên được thương lượng, thống nhất và ghi
nhận trong các OLA, SLA và UC.
 Mục tiêu Thời gian Khôi phục (Recovery Time Objective). Mục
tiêu này mô tả thời gian tối đa có được phép để khôi phục một
dịch vụ CNTT sau một sự gián đoạn. Mức Dịch vụ được cung
cấp có thể thấp hơn Đích nhắm mục tiêu Mức Dịch vụ bình
thường. Các Mục tiêu Thời gian Khôi phục cho từng dịch vụ nên
được thương lượng, thống nhất và ghi nhận trong các OLA, SLA
và UC.
 Các xác minh rằng các bản sao lưu sẽ hoạt động nếu chúng cần
phải được khôi phục. Thậm chí ngay cả khi nếu không có mã lỗi
nào được tạo ra, có thể có một vài nguyên nhân mà bản sao
lưu không thể được khôi phục. Một chiến lược sao lưu tốt và
các thủ tục vận hành sẽ tối thiểu rủi ro của việc xảy ra điều
này. Các thủ tục sao lưu nên bao gồm một bước xác minh để
đảm bảo rằng các bản sao lưu là hoàn chỉnh và rằng chúng sẽ
hoạt động nếu một yêu cầu khôi phục là cần thiết. Khi bất kỳ
lỗi sao lưu nào được phát hiện, các hành động khôi phục phải
được khởi đầu.
Cũng có một nhu cầu mua sắm và quản lý phương tiện cần thiết (ổ
đĩa, băng từ, đĩa CD, v.v…) sẽ được sử dụng để sao lưu, để từ đó
không bị thiếu hoặc gián đoạn nguồn cung.
Khi các thiết bị tự động hóa được sử dụng, việc tải lên trước các
phương tiện lưu trữ cần thiết sẽ được cần đến trước. Khi tải lên và
làm sạch các phương tiện được trả lại từ lưu trữ ngoại biên, điều
quan trọng là phải có một thủ tục xác minh rằng đây chính là những
phương tiện lưu trữ đúng. Điều này sẽ ngăn ngừa bản sao lưu gần
nhất không bị ghi đè bởi dữ liệu sai, và sau đó sẽ không có được dữ
liệu hợp lệ để khôi phục. Sau khi sao lưu thành công, phương ti ện
lưu trữ phải được lấy khỏi bộ lưu trữ.
Khởi đầu thực tế của việc sao lưu có thể được tự động hóa, hoặc
được tiến hành từ Cầu nối Vận hành.
Một số tổ chức có thể sử dụng nhân viên Vận hành để thực hiện việc
vận tải về mặt vật lý và lưu trữ các bản sao lưu dự phòng đến/từ
các vị trí ở xa, trong khi trong những trường hợp khác, việc này có
thể được bàn giao cho các nhóm khác như là nhân viên b ảo mật nội
bộ hoặc các nhà thầu bên ngoài.
Nếu sao lưu được tự động hóa hoặc được thực hiện từ xa, sau đó
năng lực Quản lý Sự kiện nên được xem xét để từ đó, bất kỳ lỗi nào
có thể được phát hiện sớm và được điều chỉnh trước khi chúng gây
ra những vấn đề. Trong những trường hợp đó, Vận hành CNTT đóng
một vai trò quan trọng trong việc xác định các cảnh báo và các lộ
trình leo thang.
Trong mọi trường hợp, nhân viên Vận hành CNTT phải được đào tạo
về các thủ tục sao lưu (và khôi phục) – vốn phải được ghi nhận rõ
ràng trong Hướng dẫn Thủ tục Vận hành CNTT. Bất kỳ yêu cầu hoặc
đích nhắm mục tiêu cụ thể nào nên được tham chiếu trong các OLA
và UC nếu thích hợp, trong khi bất kỳ yêu cầu nào của người dùng
hoặc khách hàng hoặc hoạt động nên được chỉ định trong SLA phù
hợp.
5.2.3. 2 Khôi p h ụ c
Một quá trình khôi phục có thể được khởi đầu từ một số nguồn, có
phạm vi từ một sự kiện báo hiệu dữ liệu bị hỏng, thông qua một Yêu
cầu Dịch vụ từ một người dùng hoặc khách hàng đã được ghi nhận
tại Bộ phận Hỗ trợ Dịch vụ. Một quá trình khôi phục có thể được cần
đến trong trường hợp:
 Dữ liệu bị hư hỏng,
 Mất dữ liệu,
 Tình huống khôi phục sau thảm họa/Liên tục Dịch vụ CNTT,
 Dữ liệu lịch sử bắt buộc cho cuộc điều tra pháp y.
Các bước sẽ được thực hiện bao gồm:
 Vị trí của dữ liệu/phương tiện lưu trữ thích hợp,

 Vận chuyển hoặc truyền tải trở lại cho vị trí khôi phục vật lý,
 Thỏa thuận về điểm kiểm tra điểm khôi phục và vị trí cụ thể
dành cho dữ liệu đã được khôi phục (đĩa, danh bạ, thư mục,
v.v…),
 Việc khôi phục thực tế của tập tin/dữ liệu (sao chép-ngược và
bất kỳ roll-back/roll-forward cần thiết để đi đến điểm kiểm tra
đã thống nhất),
 Việc kiểm tra để đảm bảo sự hoàn thành thành công của khôi
phục – với các hành động khôi phục thêm nếu cần thiết cho
đến khi đạt được sự thành công,
 Ký xác nhận của người dùng/khách hàng.
5.2.4 In ấ n và Đ ầ u ra
Rất nhiều dịch vụ bao gồm việc tạo ra và cung cấp những thông tin
dưới dạng được in ấn hoặc điện tử. Việc đảm bảo đúng thông tin đến
được đúng người, với đầy đủ tính toàn vẹn đòi hỏi các biện pháp
kiểm soát và quản lý chính thức.
Các cơ sở vật chất và dịch vụ In ấn (vật lý) và Đầu ra (điện tử) cần
phải được quản lý một cách chính thức bởi vì:
 Chúng thường đại diện cho đầu ra hữu hình của một dịch vụ.
Do đó, khả năng để đo lường rằng kết quả đầu ra này đã đến
được đích đến thích hợp là rất quan trọng (ví dụ, việc kiểm tra
xem liệu các tập tin với dữ liệu giao dịch tài chính phải thực tế
đến được một ngân hàng thông qua một dịch vụ FTP),
 Kết quả đầu ra vật lý và điện tử thường chứa những thông tin
nhạy cảm hoặc bí mật. Một điều cực kỳ quan trọng là các mức
bảo mật thích hợp được áp dụng cho cả việc tạo ra và cung cấp
kết quả đầu ra này.
Rất nhiều tổ chức sẽ có các yêu cầu in ấn hàng loạt được tập trung
hóa mà Vận hành CNTT phải xử lý.
Bên cạnh việc nạp và nạp lại khay giấy, và vận hành và chăm sóc
máy in, các hoạt động khác có thể cần thiết, chẳng hạn như:
 Thỏa thuận và thiết lập thông báo trước và cảnh báo khi chạy
các lệnh in ấn lớn để ngăn việc in ấn quá mức bởi các lệnh in
giả mạo,
 Các biện pháp kiểm soát vật lý những văn phòng phẩm có giá
trị cao như séc hoặc chứng nhận của công ty, v.v…
 Việc quản lý các bộ lưu trữ vật lý và điện tử cần thiết để tạo ra
kết quả đầu ra. Trong rất nhiều trường hợp, CNTT sẽ được kỳ
vọng cung cấp kho lưu trữ cho các tài liệu đã được in và tài
liệu điện tử,
 Biện pháp kiểm soát mọi tài liệu đã được in ấn để tuân thủ các
đạo luật và quy định bảo vệ dữ liệu, ví dụ như HIPAA (Đạo luật
Trách nhiệm giải trình và Khả năng cung cấp Bảo hiểm Sức
khỏe – Health Insurance Portability and Accountability Act) t ại
Hoa Kỳ, hoặc FSA (Cơ quan Dịch vụ Tài chính – Financial
Services Authority) tại Vương quốc Anh.
Khi các dịch vụ in ấn và đầu ra được cung cấp trực tiếp cho người
dùng, điều quan trọng là trách nhiệm cho việc quản lý các máy in
hoặc thiết bị lưu trữ được xác định một cách rõ ràng. Ví dụ, phần
lớn người dùng đều giả định rằng việc vệ sinh và bảo trì các máy in
phải được thực hiện bởi CNTT. Nếu điều này không đúng như vậy, nó
phải được tuyên bố một cách rõ ràng trong SLA.
5.3 Quản lý Máy tính lớn (Mainframe)

Các máy tính lớn vẫn đang được sử dụng rộng rãi và có những thực
tiễn trưởng thành và đã được thiết lập tốt. Các máy tính lớn định
hình nên thành phần trung tâm của rất nhiều dịch vụ và do đó, hiệu
suất của nó sẽ thiết lập nên một đường cơ sở cho hiệu suất dịch vụ
và kỳ vọng của khách hàng hoặc người dùng, mặc dù họ có thể
không bao giờ biết rằng họ đang sử dụng một máy tính lớn.
Những cách thức mà theo đó, các nhóm quản lý máy tính lớn được tổ
chức tương đối đa dạng. Trong một số tổ chức, Quản lý Máy tính lớn
là một nhóm đơn lẻ, và được chuyên môn hóa cao để quản lý mọi
khía cạnh từ vận hành hàng ngày đến kỹ thuật hệ thống. Trong các
tổ chức khác, các hoạt động được thực hiện bởi một vài nhóm hoặc
bộ phận, cùng với kỹ thuật và hỗ trợ cấp độ-thứ ba đang được cung
cấp bởi một nhóm và hoạt động hàng ngày được kết hợp với phần
còn lại của Vận hành CNTT (và rất có khả năng được quản lý thông
qua Cầu nối Vận hành).
Thông thường, những hoạt động dưới đây có nhiều khả năng được
thực hiện:
 Bảo trì và hỗ trợ hệ điều hành máy tính lớn,

 Hỗ trợ cấp độ-thứ ba cho bất kỳ sự cố/vấn đề liên quan đến
máy tính lớn,
 Viết các tập lệnh kịch bản công việc,
 Lập trình hệ thống,
 Tương tác với hỗ trợ phần cứng (H/W), sắp xếp bảo trì, thỏa
thuận các vị trí, xác định lỗi phần cứng, liên lạc với kỹ sư phần
cứng,
 Cung cấp thông tin và sự hỗ trợ cho Quản lý Công suất để giúp
đạt được thông lượng, mức sử dụng và hiệu suất tối ưu từ máy
tính lớn.
5.4 Quản lý và Hỗ trợ Máy chủ

Các máy chủ được sử dụng trong hầu hết các tổ chức để cung cấp
các dịch vụ linh hoạt và có thể tiếp cận được từ việc lưu trữ các ứng
dụng hoặc cơ sở dữ liệu, chạy các dịch vụ máy chủ/máy khách, Lưu
trữ, Quản lý In ấn và Tập tin. Do đó, việc quản lý thành công các
máy chủ là điều thiết yếu đối với sự thành công của Vận hành Dịch
vụ.
Các thủ tục và hoạt động phải được thực hiện bởi (các) Nhóm hoặc
(các) bộ phận Máy chủ - các nhóm tách biệt có thể được cần đến khi
các kiểu máy chủ khác nhau được sử dụng (UNIX, Wintel, v.v…), bao
gồm:
 Hỗ trợ hệ điều hành: Hỗ trợ và bảo trì (các) hệ điều hành

tương xứng và các phần mềm tiện ích liên quan (ví dụ, phần
mềm chuyển đổi dự phòng) bao gồm quản lý bản vá và tham
gia vào việc xác định các chính sách sao lưu và khôi ph ục.
 Quản lý giấy phép sử dụng cho mọi đơn vị cấu hình máy chủ,
đặc biệt là các hệ điều hành, tiện ích và bất kỳ phần mềm ứng
dụng nào không được quản lý bởi các nhóm Quản lý Ứng dụng.
 Hỗ trợ cấp độ-thứ ba: Hỗ trợ cấp độ thứ ba cho mọi máy chủ
và/hoặc các sự cố liên quan đến hệ điều hành máy chủ, bao
gồm các hoạt động chẩn đoán và khôi phục. Điều này cũng sẽ
bao gồm việc liên lạc với các nhà thầu hỗ trợ phần cứng bên
thứ ba và/hoặc nhà sản xuất khi cần thiết để leo thang các sự
cố liên quan đến phần cứng.
 Tư vấn mua sắm: Tư vấn và hướng dẫn cho doanh nghiệp về
việc lựa chọn, định cỡ, mua sắm và sử dụng các máy chủ và
phần mềm tiện ích để đáp ứng các nhu cầu của doanh nghiệp.
 Bảo mật hệ thống: Kiểm soát và duy trì các biện pháp kiểm
soát và quyền truy cập trong phạm vi (những) môi trường liên
quan đến máy chủ cũng như các biện pháp bảo mật vật lý và
bảo mật hệ thống thích hợp. Những điều này bao gồm việc xác
định và áp dụng các bản vá lỗi, Quản lý Truy cập (xem phần
4.5) và phát hiện xâm nhập.
 Định nghĩa và quản lý máy chủ ảo. Điều này hàm ý rằng bất
kỳ máy chủ nào đã được thiết kế và xây dựng xoay quanh một
tiêu chuẩn phổ biến có thể được sử dụng để xử lý khối lượng
công việc từ một loạt các ứng dụng hoặc người dùng. Quản lý
Máy chủ sẽ được yêu cầu thiết lập những tiêu chuẩn này và sau
đó, đảm bảo rằng khối lượng công việc được cân bằng và phân
phối một cách thích hợp. Họ còn chịu trách nhiệm cho việc có
khả năng theo dõi khối lượng công việc nào đang được xử lý
bởi máy chủ nào để từ đó, họ có khả năng xử lý sự cố một cách
hiệu quả.
 Công suất và Hiệu suất: Cung cấp thông tin và sự hỗ trợ cho
Quản lý Công suất để giúp đạt được thông lượng, mức sử dụng
và hiệu suất tối ưu từ những máy chủ đang sẵn có. Việc này
được thảo luận chi tiết hơn trong Thiết kế Dịch vụ, nhưng bao
gồm việc hướng dẫn về, cài đặt và vận hành của, phần mềm ảo
hoá như vậy để đạt được giá trị về tiền bạc bằng cách đạt được
mức hiệu suất và sử dụng cao nhất từ số lượng tối thiểu các
máy chủ.
 Các hoạt động thường lệ khác, bao gồm:
o Xác định các tiêu chuẩn xây dựng đối với các máy chủ
như một phần của quy trình cung cấp. Điều này được đề
cập chi tiết hơn trong ấn phẩm Thiết kế Dịch vụ và
Chuyển tiếp Dịch vụ.
o Xây dựng và cài đặt các máy chủ mới như một phần của
việc bảo trì liên tục hoặc để cung cấp các dịch vụ mới.
Điều này được đề cập chi tiết hơn trong ấn phẩm Chuyển
tiếp Dịch vụ.
o Thiết lập và quản lý các cụm, nhằm mục đích xây dựng
khả năng dự phòng, cải thiện hiệu suất dịch vụ và khiến
cho việc quản lý cơ sở hạ tầng trở nên dễ dàng hơn.
 Bảo trì liên tục. Điều này thường bao gồm việc thay thế các
máy chủ hoặc các ‘phiến/blade’ theo một lịch trình cuốn chiếu
để đảm bảo rằng các thiết bị được thay thế trước khi bị hỏng
hoặc trở nên lỗi thời. Điều này dẫn đến việc các máy chủ không
chỉ vận hành đầy đủ chức năng mà còn có khả năng hỗ trợ các
dịch vụ đang phát triển.
 Sắp xếp hoặc hủy bỏ các thiết bị máy chủ cũ. Điều này
thường được thực hiện kết hợp với các chính sách môi trường
của tổ chức về việc hủy bỏ.
5.5 Quản lý Mạng

Hầu hết các dịch vụ CNTT đều phụ thuộc vào kết nối, do đó, Quản lý
Mạng sẽ là điều thiết yếu để cung cấp các dịch vụ, đồng thời cũng
cho phép nhân viên Vận hành Dịch vụ truy cập và quản lý các thành
phần dịch vụ then chốt.
Quản lý Mạng sẽ chịu trách nhiệm tổng thể cho mọi Mạng Khu vực
Cục bộ (Local Area Network - LANs), Mạng Khu vực Đô thị
(Metropolitan Area Network – MANs) và Mạng Diện Rộng (Wide Area
Network – WANs) – và cũng sẽ chịu trách nhiệm cho việc liên lạc với
các nhà cung cấp mạng bên thứ ba.
Vai trò của họ sẽ bao gồm những hoạt động dưới đây:
 Hoạch định ban đầu và cài đặt những mạng/thành phần mạng
mới, bảo trì và nâng cấp cơ sở hạ tầng mạng vật lý. Việc này
được thực hiện thông qua Thiết kế Dịch vụ và Chuyển tiếp Dịch
vụ.
 Hỗ trợ cấp độ-thứ ba cho mọi hoạt động liên quan đến mạng,
bao gồm việc điều tra các sự cố mạng (ví dụ, ‘ping’ hoặc ‘trace
route’ hoặc sử dụng các công cụ phần mềm quản lý mạng –
mặc dù nên lưu ý rằng việc ‘ping’ một máy chủ không nhất
thiết phải có nghĩa là dịch vụ đó đang sẵn sàng!) và liên lạc
với các bên thứ ba, khi cần thiết. Điều này bao gồm việc cài
đặt và sử dụng các công cụ ‘sniffer’ để phân tích lưu lượng
mạng, để hỗ trợ cho giải pháp cho sự cố và vấn đề.
 Bảo trì và hỗ trợ hệ điều hành mạng và phần mềm trung gian,
bao gồm cập nhật, quản lý bản vá lỗi, v.v…
 Giám sát lưu lượng mạng để xác định các lỗi hoặc để phát hiện
các vấn đề về hiệu suất hoặc tắc nghẽn.
 Thiết lập lại hoặc định tuyến lại lưu lượng để đạt được mức
thông lượng được cải thiện hoặc sự cân bằng liên tục – định
nghĩa các quy tắc để định tuyến/cân bằng động.
 Bảo mật mạng (liên lạc với Quản lý Bảo mật Thông tin của tổ
chức) bao gồm quản lý tường lửa, quyền truy cập, bảo vệ mật
khẩu, v.v…
 Cấp phát và quản lý các địa chỉ IP, các hệ thống Tên miền
(DNS) và Giao thức Cấu hình Máy chủ Động (DHCP), vốn cho
phép truy cập và sử dụng DNS.
 Quản lý các Nhà cung cấp Dịch vụ Internet (ISP).
 Triển khai, giám sát và bảo trì các Hệ thống Phát hiện Xâm
nhập (IDS) dưới danh nghĩa Quản lý Bảo mật Thông tin. Họ
cũng chịu trách nhiệm cho việc đảm bảo rằng không xảy ra từ
chối dịch vụ đối với những người dùng hợp pháp của hệ thống
mạng.
 Cập nhât Quản lý Cấu hình khi cần thiết bằng cách ghi nhận lại
các Đơn vị Cấu hình, trạng thái, mối quan hệ, v.v…
Quản lý Mạng cũng chịu thường trách nhiệm, kết hợp với Hỗ trợ Máy
tính để bàn, cho các vấn đề kết nối từ xa chẳng hạn như quay số
(dial-in), gọi lại (dial-back) và các cơ sở VPN được cung cấp cho
những ai làm việc từ nhà, người làm việc từ xa hoặc nhà cung cấp.
Một số nhóm hoặc bộ phận Quản lý Mạng cũng sẽ chịu trách nhiệm
cho hệ thống điện thoại/âm thanh, bao gồm cung cấp và hỗ trợ tổng
đài, đường điện thoại, ACD, các gói phần mềm thống kê, v.v… và
cho các hệ thống Giám sát Từ xa (RMon) và Giao thức Thoại qua
Internet.
Tại cùng thời điểm, rất nhiều tổ chức xem VoIP và điện thoại là
những lĩnh vực chuyên môn hóa và cần có các nhóm chuyên biệt để
quản lý công nghệ này. Những Hoạt động của họ sẽ tương tự như
những gì đã được mô tả ở trên.
5.6 Lưu trữ và Cất giữ
Rất nhiều dịch vụ đòi hỏi lưu trữ dữ liệu cho một khoảng thời gian
cụ thể và đồng thời để những dữ liệu đó sẵn sàng ngoại tuyến trong
một khoảng thời gian nhất định sau khi nó không còn được sử dụng.
Điều này thường là do các yêu cầu quy định hoặc yêu cầu pháp lý,
nhưng cũng vì dữ liệu lịch sử và dữ liệu kiểm toán là vô giá cho một
số mục đích khác nhau, bao gồm tiếp thị, phát triển sản phẩm, điều
tra pháp y, v.v…
Một nhóm hoặc bộ phận riêng biệt có thể được cần đến để quản lý
công nghệ lưu trữ dữ liệu của tổ chức, chẳng hạn như:
 Các thiết bị lưu trữ, như đĩa cứng, bộ điều khiển, băng từ,
v.v…
 Lưu trữ Được gắn vào Mạng (Network Attached Storage – NAS),
vốn là thiết bị lưu trữ được gắn vào một mạng và có thể truy
cập được bởi một số khách hàng.
 Mạng Khu vực Lưu trữ (Storage Area Networks – SANs) được
thiết kế để gắn kèm các thiết bị lưu trữ máy tính như bộ điều
khiển mảng các ổ đĩa và các thư viện băng từ. Ngoài các thiết
bị lưu trữ, một SAN cũng sẽ đòi hỏi việc quản lý một vài thành
phần mạng như các hub, cáp, v.v…
 Lưu trữ Được gắn Trực tiếp (Direct Attached Storage – DAS),
vốn là một thiết bị lưu trữ được cắm trực tiếp vào một máy
chủ.
 Lưu trữ Có thể xác định Nội dung (Content Addressable Storage
– CAS) là một thiết bị lưu trữ dựa trên việc truy xuất thông tin
dựa trên nội dung thay vì vị trí của nó. Trọng tâm của kiểu hệ
thống này được đặt vào việc hiểu về bản chất của dữ liệu và
thông tin đã lưu trữ, thay vì đặt vào việc cung cấp các vị trí
lưu trữ cụ thể.
Bất kể kiểu hệ thống lưu trữ đang được sử dụng là gì, Lưu trữ và
Cất giữ sẽ đòi hỏi việc quản lý các thành phần cơ sở hạ tầng cũng
như là các chính sách liên quan đ ến nơi dữ liệu được lưu trữ, trong
thời gian bao lâu, dưới hình thức (định dạng) nào và ai có thể truy
cập nó. Những trách nhiệm cụ thể sẽ bao gồm:
 Định nghĩa các chính sách và thủ tục lưu trữ dữ liệu,
 Các quy tắc đặt tên tập tin lưu trữ, sơ đồ phân cấp và quyết
định bố trí,
 Thiết kế, định cỡ, lựa chọn, mua sắm, thiết lập cấu hình và vận
hành mọi cơ sở hạ tầng lưu trữ dữ liệu,
 Bảo trì và hỗ trợ mọi tiện ích và phần mềm trung gian lưu trữ
dữ liệu,
 Liên lạc với (các) nhóm Quản lý Vòng đời Thông tin hoặc các
nhóm Quản trị để đảm bảo tuân thủ các quy định về quyền tự
do thông tin, bảo vệ dữ liệu và quản trị CNTT,
 Tham gia vào việc xác định và thống nhất chính sách lưu giữ,
 Quản lý tất cả cơ sở vật chất lưu trữ dữ liệu,
 Cất giữ dữ liệu theo các quy tắc và lịch trình đã được xác định
trong Thiết kế Dịch vụ. Các nhóm hoặc bộ phận Lưu trữ cũng
sẽ cung cấp đầu vào cho việc xác định những quy tắc đó, và sẽ
cung cấp các báo cáo về tính hiệu quả của chúng như đầu vào
của thiết kế tương lai.
 Truy xuất hoặc lưu giữ dữ liệu khi cần thiết (ví dụ, cho mục
đích kiểm toán, bằng chứng pháp ý, hoặc để đáp ứng các yêu
cầu kinh doanh khác),
 Hỗ trợ tuyến thứ ba đối với các sự cố liên quan đến lưu trữ và
cất giữ.
5.7 Quản lý Cơ sở dữ liệu

Quản lý Cơ sở dữ liệu phải hợp tác chặt chẽ với các nhóm hoặc bộ
phận Quản lý Ứng dụng chính yếu – và trong một số tổ chức, có thể
được kết hợp hoặc liên kết dưới một cơ cấu quản lý duy nhất. Các
tùy chọn mang tính tổ chức bao gồm:
 Quản lý Cơ sở dữ liệu đang được thực hiện bởi từng nhóm Quản
lý Ứng dụng đối với mọi ứng dụng đang nằm dưới sự quản lý
của họ.
 Một bộ phận chuyên biệt, vốn quản lý mọi cơ sở dữ liệu, bất kể
kiểu (cơ sở dữ liệu) hoặc ứng dụng.
 Một vài bộ phận, trong đó từng bộ phận quản lý một kiểu cơ sở
dữ liệu, bất kể chúng là một phần của ứng dụng nào.
Quản lý Cơ sở dữ liệu hoạt động để đảm bảo mức hiệu suất, bảo mật
và chức năng tối ưu của các cơ sở dữ liệu mà họ quản lý. Quản lý Cơ
sở dữ liệu thường có những trách nhiệm sau đây:
 Tạo và duy trì các tiêu chuẩn và chính sách cho cơ sở dữ liệu,
 Khởi đầu việc thiết kế, tạo ra và kiểm nghiệm cơ sở dữ liệu,
 Quản lý tính sẵn sàng và hiệu suất của cơ sở dữ liệu, khả năng
phục hồi, định cỡ, công suất thể tích, v.v…
 Khả năng phục hồi có thể yêu cầu nhân bản cơ sở dữ liệu, vốn
sẽ là trách nhiệm của Quản lý Cơ sở dữ liệu,
 Quản lý liên tục các đối tượng cơ sở dữ liệu: các chỉ mục, bảng
biểu, các bảng kết quả, ràng buộc, ảnh chụp nhanh chuỗi trình
tự, các thủ tục lưu trữ, khóa trang – để đạt được mức sử dụng
tối ưu,
 Định nghĩa các điều kiện kích hoạt sẽ tạo ra các sự kiện, từ đó
sẽ cảnh báo quản trị viên về các vấn đề hiệu suất hoặc tính
toàn vẹn tiềm ẩn với cơ sở dữ liệu,
 Thự hiện quản lý cơ sở dữ liệu – những tác vụ thường lệ để
đảm bảo rằng các cơ sở dữ liệu đang hoạt động bình thường và
an toàn, ví dụ, tinh chỉnh, đánh chỉ mục, v.v…
 Giám sát việc sử dụng, khối lượng giao dịch, thời gian hồi đáp,
mức độ đồng thời, v.v…
 Tạo ra các báo cáo. Chúng có thể là các báo cáo dựa trên dữ
liệu trong cơ sở dữ liệu, hoặc các báo cáo liên quan đến hiệu
suất và tính toàn vẹn của cơ sở dữ liệu,
 Xác định, báo cáo và quản lý các vấn đề về bảo mật cơ sở dữ
liệu, dấu vết kiểm toán và pháp y,
 Hỗ trợ việc thiết kế chiến lược sao lưu, cất giữ và lưu trữ cơ sở
dữ liệu,
 Hỗ trợ việc thiết kế các cảnh báo và quản lý sự kiện với cơ sở
dữ liệu,
 Cung cấp hỗ trợ cấp độ thứ ba cho mọi sự cố liên quan đến cơ
sở dữ liệu.
5.8 Quản lý các Dịch vụ Danh bạ (Directory)
Một Dịch vụ Danh bạ là một ứng dụng phần mềm đặc biệt để quản lý
thông tin về nguồn tài nguyên sẵn có trên một mạng và những người
dùng nào có quyền truy cập đến. Đây là điều cơ bản để cung cấp
quyền truy cập đến những nguồn tài nguyên đó và để đảm bảo rằng
những truy cập trái phép được phát hiện và ngăn chặn (xem phần
4.5 để có thêm thông tin chi tiết về Quản lý Truy cập).
Các Dịch vụ Danh bạ coi từng nguồn tài nguyên như là một đối
tượng của Máy chủ Danh bạ và đặt tên cho nó. Từng tên gọi được
liên kết với địa chỉ mạng của tài nguyên, để từ đó người dùng không
cần phải ghi nhớ các địa chỉ khó hiểu và phức tạp.
Các Dịch vụ Danh bạ dựa trên các tiêu chuẩn X.500 của OSI và sử
dụng các giao thức phổ biến như Giao thức Truy cập Danh bạ
(Directory Access Protocol – DAP) hoặc Giao thức Truy cập Danh bạ
Hạng nhẹ (Lightweight Directory Access Protocol – LDAP). LDAP
được sử dụng để hỗ trợ thông tin người dùng để đăng nhập vào ứng
dụng và thường bao gồm dữ liệu người dùng/khách hàng nội bộ và
bên ngoài đặc biệt hữu ích cho việc ghi lại nhật ký cuộc gọi mạng
bên ngoài (extranet). Vì LDAP là một công cụ vận hành tối quan
trọng, và thường được giữ cập nhật nên nó là một nguồn rất tốt của
dữ liệu và xác minh cho CMS.
Quản lý Dịch vụ Danh bạ đề cập đến quy trình được sử dụng để quản
lý các Dịch vụ Danh bạ. Những hoạt động của nó bao gồm:
 Hoạt động như một phần của Thiết kế Dịch vụ và Chuyển tiếp
Dịch vụ để đảm bảo rằng các dịch vụ mới là có thể truy cập
được và kiểm soát được khi chúng đã được triển khai,
 Định vị nguồn tài nguyên trên một mạng (nếu chúng chưa từng
được xác định trong giai đoạn Thiết kế Dịch vụ),
 Theo dõi trạng thái của những tài nguyên đó và cung cấp khả
năng để quản lý các nguồn tài nguyên này từ xa,
 Quản lý quyền cho những người dùng hoặc nhóm người dùng cụ
thể để truy cập vào những nguồn tài nguyên trên mạng,
 Xác định và duy trì các quy tắc đặt tên được sử dụng đối với
những nguồn tài nguyên trên mạng,
 Đảm bảo tính nhất quán của tên gọi và kiểm soát truy cập trên
các mạng khác nhau trong tổ chức,
 Liên kết các Dịch vụ Danh bạ khác nhau trong toàn bộ tổ chức
để hình thành một Dịch vụ Danh bạ phân tán, nghĩa là người
dùng sẽ chỉ nhìn thấy một bộ tài nguyên mạng logic. Đây được
gọi là Phân phối các Dịch vụ Danh bạ,
 Giám sát các Sự kiện trên các Dịch vụ Danh bạ, chẳng hạn như
nỗ lực không thành công để truy cập vào một tài nguyên, và
thực hiện hành động thích hợp khi được yêu cầu,
 Duy trì và cập nhật các công cụ được sử dụng để quản lý các
Dịch vụ Danh bạ.
5.9 Hỗ trợ Máy tính bàn
Vì hầu hết người dùng đều truy cập vào các dịch vụ CNTT thông qua
máy tính để bàn hoặc máy tính xách tay, do đó, điều then chốt là
chúng (các máy tính) được hỗ trợ để đảm bảo mức sẵn sàng và hiệu
suất dịch vụ đã được thống nhất.
Hỗ trợ Máy tính bàn sẽ có trách nhiệm tổng thể cho mọi phần cứng,
phần mềm và thiết bị ngoại vi của máy tính của tổ chức. Những
trách nhiệm cụ thể bao gồm:
 Các chính sách và thủ tục (sử dụng) máy tính bàn, ví dụ, các
chính sách cấp phép sử dụng, sử dụng máy tính xách tay hoặc
máy tính để bàn cho mục đích cá nhân, khóa USB, v.v…
 Thiết kế và thỏa thuận các hình ảnh màn hình tiêu chuẩn,
 Bảo trì dịch vụ máy tính bàn bao gồm triển khai các bản phát
hành, nâng cấp, vá lỗi và sửa lỗi khẩn cấp (kết hợp với Quản lý
Phát hành (xem ấn phẩm Chuyển tiếp Dịch vụ để biết thêm chi
tiết),
 Thiết kế và triển khai chính sách cất giữ/tái xây dựng máy tính
(bao gồm chính sách liên quan đến các cookies, favorites, các
biểu mẫu, dữ liệu cá nhân, v.v…),
 Hỗ trợ cấp độ-thứ ba cho các sự cố liên quan đến máy tính,
bao gồm cả các chuyến viếng thăm bên bàn (hỗ trợ trực tiếp)
khi cần thiết,
 Hỗ trợ các vấn đề về kết nối (kết hợp với Quản lý Mạng) cho
những người làm việc tại nhà, người dùng di động, v.v…,
 Kiểm soát và kiểm toán cấu hình cho mọi thiết bị máy tính (kết
hợp với Quản lý Cấu hình và Kiểm toán CNTT).
5.10 Quản lý Phần mềm trung gian
Phần mềm trung gian là phần mềm kết nối hoặc tích hợp các thành
phần phần mềm trên các ứng dụng và hệ thống phân tán hoặc riêng
biệt. Phần mềm trung gian cho phép truyền dữ liệu hiệu quả giữa
các ứng dụng và do đó, là chìa khóa cho các dịch vụ phụ thuộc vào
nhiều ứng dụng hoặc nhiều nguồn dữ liệu.
Nhiều công nghệ hiện đang được sử dụng để hỗ trợ giao tiếp chương
trình-với-chương trình (program-to-program), chẳng hạn như môi
giới yêu cầu đối tượng, phần mềm trung gian hướng-thông điệp, các
cuộc gọi thủ tục từ xa và các dịch vụ web điểm-đến-điểm. Những
công nghệ mới hơn luôn xuất hiện, chẳng hạn như Enterprise Service
Bus (ESB), cho phép các chương trình, h ệ thống và dịch vụ giao tiếp
với nhau bất kể kiến trúc và nguồn gốc của các ứng dụng. Điều này
đặc biệt được sử dụng trong bối cảnh triển khai Kiến trúc Hướng
Dịch vụ (Service Oriented Architectures - SOA).
Quản lý phần mềm trung gian có thể được thực hiện như một phần
của chức năng Quản lý Ứng dụng (nơi nó dành riêng cho một ứng
dụng cụ thể) hoặc như một phần của chức năng Quản lý Kỹ thuật
(nơi nó được xem như một phần mở rộng cho Hệ điều hành của một
nền tảng cụ thể).
Các chức năng được cung cấp bởi phần mềm trung gian bao gồm:
 Cung cấp các cơ chế truyền tải dữ liệu từ nhiều ứng dụng hoặc
nguồn dữ liệu khác nhau,
 Gửi công việc đến một ứng dụng hoặc thủ tục khác để xử lý,
 Truyền dữ liệu hoặc thông tin đến các hệ thống khác, chẳng
hạn như tìm nguồn cung cấp dữ liệu để công bố trên các trang
web (ví dụ, công bố thông tin trạng thái của Sự cố),
 Phát hành các mô-đun phần mềm được cập nhật trên các môi
trường phân tán,
 Đối chiếu và phân phối các thông điệp và hướng dẫn hệ thống,
ví dụ, các Sự kiện hoặc các tập lệnh hoạt động cần được chạy
trên các thiết bị từ xa,
 Thiết lập đa hướng với các mạng. Đa hướng là việc cung cấp
thông tin cho một nhóm các đích đến đồng thời bằng cách sử
dụng tuyến đường cung cấp hiệu quả nhất,
 Quản lý kích thước hàng đợi.
Quản lý Phần mềm trung gian là tập hợp các hoạt động được sử
dụng để quản lý phần mềm trung gian. Chúng bao gồm:
 Làm việc như một phần của Thiết kế Dịch vụ và Chuyển tiếp
Dịch vụ để đảm bảo rằng các giải pháp phần mềm trung gian
thích hợp được chọn và chúng có thể hoạt động tối ưu khi
chúng được triển khai,
 Đảm bảo hoạt động chính xác của phần mềm trung gian thông
qua việc giám sát và kiểm soát,
 Phát hiện và giải quyết các sự cố liên quan đến phần mềm
trung gian
 Duy trì và cập nhật phần mềm trung gian, bao gồm việc cấp
phép và cài đặt các phiên bản mới,
 Xác định và duy trì thông tin về cách mà các ứng dụng được
liên kết như thế nào thông qua Phần mềm trung gian. Đây nên
là một phần của CMS (xem ấn phẩm Chuyển tiếp Dịch vụ).
5.11 Quản lý Internet/Web

Rất nhiều tổ chức tiến hành nhiều công việc kinh doanh của họ
thông tin Internet và do đó, phụ thuộc rất nhiều vào tính sẵn sàng
và hiệu suất của các trang web của họ. Trong những trường hợp đó,
một nhóm hoặc bộ phận Hỗ trợ Internet/Trang Web sẽ được mong
muốn và chính đáng.
Trách nhiệm của một nhóm hoặc bộ phận như vậy kết hợp cả
Intranet và Internet và có kh ả năng bao gồm:
 Xác định những cấu trúc dành cho các dịch vụ Internet và web,
 Đặc tả kỹ thuật của các tiêu chuẩn dành cho phát triển và quản
lý các ứng dụng dựa trên-nền web, nội dung, các trang web.
Điều này thường sẽ được thực hiện trong quá trình Thiết kế
Dịch vụ,
 Thiết kế, kiểm nghiệm, triển khai và bảo trì các trang web.
Điều này sẽ bao gồm kiến trúc của các trang web và lập bản đồ
nội dung sẽ được cung cấp,
 Trong rất nhiều tổ chức, quản lý trang web sẽ bao gồm việc
soạn thảo nội dung sẽ được đăng trên trang web,
 Bảo trì mọi ứng dụng quản lý và phát triển web,
 Liên lạc và tư vấn cho nhóm nội dung-web trong doanh nghiệp.
Nội dung có thể lưu trú trong các ứng dụng hoặc thiết bị lưu
trữ, vốn ngụ ý có liên hệ chặt chẽ với các nhóm Quản lý Ứng
dụng và Quản lý Kỹ thuật khác,
 Liên lạc với và quản lý nhà cung cấp của các ISP, các host,
giám sát bên thứ ba hoặc các tổ chức ảo hóa, v.v… Trong rất
nhiều tổ chức, các ISP được quản lý như một phần của Quản lý
Mạng,
 Hỗ trợ cấp độ-thứ ba đối với các sự cố liên quan đến
Internet/web,
 Hỗ trợ cho các tương tác với các hệ thống back-end và các hệ
thống kế thừa. Điều này sẽ thường có nghĩa là làm việc với các
thành viên của các nhóm Quản lý và Phát triển Ứng dụng để
đảm bảo việc truy cập an toàn và tính nhất quán của chức
năng,
 Giám sát và quản lý hiệu suất trang web và bao gồm: kiểm tra
‘nhịp tim’, mô phỏng trải nghiệm người dùng, so sánh điểm
chuẩn, cân bằng tải theo nhu cầu, ảo hóa,
 Tính sẵn sàng, khả năng phục hồi và bảo mật của trang web.
Điều này sẽ định hình một phần của Quản lý Bảo mật Thông tin
tổng thể của tổ chức.
5.12 Quản lý Trung tâm Dữ liệu và Cơ sở vật chất
Quản lý Cơ sở vật chất đề cập đến việc quản lý môi trường vật lý
của Vận hành CNTT, thường được đặt tại các Trung tâm Dữ liệu hoặc
các phòng máy tính. Đây là một lĩnh vực rất rộng lớn và phức tạp,
và ấn phẩm này sẽ cung cấp một cái nhìn tổng quan về vai trò và
các hoạt động chính yếu của nó. Một cái nhìn tổng quan chi tiết hơn
được bao gồm trong Phụ lục E.
Theo nhiều khía cạnh, Quản lý Cơ sở vật chất có thể được xem như
là một chức năng theo đúng nghĩa của nó. Tuy nhiên, vì ấn phẩm
này tập trung vào nơi diễn ra các Hoạt động CNTT, nó sẽ đề cập cụ
thể đến Quản lý Cơ sở vật chất vì nó liên quan đến việc quản lý
Trung tâm Dữ liệu và như một tập hợp con của chức năng Quản lý
Vận hành CNTT.
Các thành phần chính của Quản lý Cơ sở vật chất như sau:
 Quản lý Tòa nhà, đề cập đến việc bảo trì và duy trì các tòa
nhà có nhân viên CNTT và Trung tâm d ữ liệu. Các hoạt động
điển hình bao gồm dọn dẹp, xử lý chất thải, quản lý bãi đậu xe
và kiểm soát ra vào,
 Lưu trữ Thiết bị, vốn đảm bảo rằng mọi yêu cầu đặc biệt
được cung cấp cho vị trí lưu trữ thực tế của thiết bị và các
nhóm hỗ trợ chúng,
 Quản lý Nguồn điện, đề cập đến việc quản lý việc tìm nguồn
cung ứng và sử dụng các nguồn cấp điện được sử dụng để duy
trì hoạt động của cơ sở. Định nghĩa về Quản lý Nguồn điện này
có một số hàm ý, vốn sẽ được thảo luận trong Phụ lục E. Hãy
lưu ý rằng thông tin về việc sử dụng điện năng là rất quan
trọng đối với việc lập kế hoạch công suất của cả các dịch vụ
mới và các tòa nhà mới.
 Hệ thống Cảnh báo và Điều hòa Môi trường, bao gồm đặc
tả kỹ thuật, bảo trì và giám sát các hệ thống chẳng hạn như
phát hiện khói và dập lửa, hệ thống nước, hệ thống sưởi và
làm mát, v.v...
 An toàn liên quan đến việc tuân thủ mọi luật, tiêu chuẩn và
chính sách liên quan đến sự an toàn của nhân viên,
 Kiểm soát Truy cập Vật lý đề cập đến việc đảm bảo rằng cơ
sở chỉ được truy cập bởi nhân viên có thẩm quyền và rằng mọi
truy cập trái phép đều phải được phát hiện và quản lý. Điều
này sẽ được thảo luận chi tiết hơn trong Phụ lục F
 Vận chuyển và Nhận hàng đề cập đến việc quản lý tất cả các
thiết bị, đồ đạc nội thất, thư từ, v.v... vào hoặc ra khỏi tòa
nhà. Nó đảm bảo rằng chỉ các mặt hàng thích hợp mới được
vào hoặc ra khỏi tòa nhà và chúng được chuyển đến đúng bên,
 Tham gia vào Quản lý Hợp đồng của các nhà cung cấp khác
nhau và các nhà cung cấp dịch vụ liên quan đến cơ sở,
 Bảo trì đề cập đến việc bảo trì thường xuyên và được lập lịch
trình của cơ sở, cũng như phát hiện và giải quyết các vấn đề
với cơ sở.
5.12.1 N hững chi ến lư ợ c T rung t âm D ữ li ệu
Việc quản lý một Trung tâm Dữ liệu còn hơn là việc lưu giữ một
không gian mở, nơi mà các nhóm kỹ thuật cài đặt và quản lý các
thiết bị, sử dụng những phương pháp tiếp cận và thủ tục của riêng
họ. Nó đòi hỏi một bộ tích hợp các quy trình và thủ tục liên quan
đến mọi nhóm CNTT tại từng giai đoạn của Vòng đời ITSM. Vận hành
Trung tâm Dữ liệu bị chi phối bởi các quyết định chiến lược và thiết
kế đối với việc quản lý và kiểm soát và được thực thi bởi các nhân
viên vận hành. Điều này đòi hỏi một số yếu tố then chốt được đưa
ra:
 Tự động hóa Trung tâm Dữ liệu. Các hệ thống tự động hóa

chuyên biệt để giảm thiểu nhu cầu vận hành thủ công và giám
sát và theo dõi trạng thái của cơ sở vật chất và mọi Vận hành
CNTT tại mọi thời điểm,
 Quản lý dựa trên-chính sách, khi các quy tắc tự động hóa
và phân bổ nguồn lực được quản lý bằng chính sách thay vì
phải thông qua các thủ tục thay đổi phức tạp mỗi lần quá
trình xử lý được chuyển từ tài nguyên này sang tài nguyên
khác,
 Các dịch vụ thời gian thực, 24 giờ mỗi ngày, 7 ngày một
trong tuần,
 Tiêu chuẩn hóa thiết bị, Điều này giúp dễ dàng quản lý hơn,
mức hiệu suất nhất quán hơn và một phương tiện cung cấp
nhiều dịch vụ trên công nghệ tương tự. Tiêu chuẩn hóa cũng
đồng thời làm giảm sự đa dạng của chuyên môn kỹ thuật cần
thiết để quản lý thiết bị trong Trung tâm Dữ liệu và cung cấp
các dịch vụ,
 SOA, nơi các thành phần dịch vụ có thể được tái sử dụng,
hoán đổi và thay thế một cách rất nhanh chóng và không ảnh
hưởng đến doanh nghiệp. Điều này sẽ giúp Trung tâm Dữ liệu
có khả năng ứng phó cao trong việc đáp ứng các nhu cầu kinh
doanh đang thay đổi mà không phải trải qua quá trình kéo dài
và liên quan đến việc tái cấu trúc và tái kiến trúc,
 Ảo hóa. Điều này có nghĩa là các dịch vụ CNTT được cung cấp
bằng cách sử dụng một tập hợp các thiết bị luôn thay đổi
nhằm đáp ứng nhu cầu hiện tại. Ví dụ, một ứng dung có thể
chạy trên một thiết bị chuyên biệt cùng với cơ sở dữ liệu trong
những thời điểm nhu cầu cao nhưng sẽ được chuyển sang một
thiết bị được chia sẻ với cơ sở dữ liệu của nó trên một thiết bị
từ xa trong những thời điểm nhu cầu thấp – tất cả là tự động
và được tự động hóa. Điều này sẽ có nghĩa rằng chi phí được
tiết kiệm hơn nữa vì bất kỳ thiết bị nào cũng đều có thể được
sử dụng tại bất kỳ thời điểm nào mà không cần sự can thiệp
của con người, ngoại trừ để thực hiện công việc bảo trì và
thay thế các thiết bị hư hỏng. Cơ sở hạ tầng CNTT có khả
năng phục hồi cao hơn vì bất kỳ thành phần nào cũng đều
được dự pòng bởi bất kỳ số lượng thành phần khác tương tự,
bất kỳ thiết bị nào trong số chúng đều có thể xử lý khối lượng
công việc của các thành phần bị lỗi một cách tự động.
Việc giám sát, kiểm soát và quản lý từ xa các thiết bị và các
hệ thống sẽ là điều thiết yếu để quản lý một môi trường được
ảo hóa, vì rất nhiều dịch vụ sẽ không được liên kết tới bất kỳ
một phần cụ thể nào của thiết bị.
 Các hệ thống quản lý được Hợp nhất trở nên quan trọng hơn
bởi vì các dịch vụ hoạt động trên nhiều vị trí và công nghệ
khác nhau. Ngày nay, điều quan trọng là xác định những hành
động nào cần phải được thực hiện và những hệ thống nào sẽ
thực hiện những hành động đó. Điều này có nghĩa việc đầu tư
vào các giải pháp mà sẽ hỗ trợ cho các nhà quản lý Cơ sở hạ
tầng đơn giản là chỉ cần chỉ định những kết quả nào được
mong muốn, và cho phép hệ thống quản lý tính toán sự kết
hợp tốt nhất của các công cụ và hành động để đạt được kết
quả đó.
5.13 Quản lý Bảo mật Thông tin và Vận hành Dịch

vụ
Quy trình Quản lý Bảo mật Thông tin được đề cập trong ấn phẩm
Thiết kế Dịch vụ của ITIL. Quản lý Bảo mật Thông tin chịu trách
nhiệm tổng thể cho việc thiết lập các chính sách, tiêu chuẩn và thủ
tục để đảm bảo việc bảo vệ tài sản, dữ liệu, thông tin và các dịch vụ
CNTT của tổ chức. Các nhóm Vận hành Dịch vụ đóng vai trò thực thi
các chính sách, tiêu chuẩn và thủ tục này và sẽ hợp tác chặt chẽ với
các nhóm hoặc bộ phận chịu trách nhiệm về Quản lý An toàn Thông
tin.
Nhóm Vận hành Dịch vụ không thể nắm quyền sở hữu Quản lý Bảo
mật Thông tin, vì điều này sẽ dẫn đến xung đột. Cần phải có sự tách
biệt về vai trò giữa các nhóm xác định và quản lý quy trình và các
nhóm thực hiện các hoạt động cụ thể như một phần của vận hành
liên tục. Điều này sẽ giúp bảo vệ chống lại sự vi phạm các biện pháp
bảo mật, vì không một cá nhân nào được kiểm soát hai hoặc nhiều
giai đoạn của một giao dịch hoặc một hoạt động. Quản lý Bảo mật
Thông tin nên chỉ định trách nhiệm để đảm bảo một kiểm tra chéo
các nhiệm vụ được thực hiện.
Vai trò của các nhóm Vận hành Dịch vụ sẽ được trình bày tiếp theo
dưới đây.
5.13.1 Lậ p chính sách và B áo cáo
Việc này sẽ liên quan đến nhân viên Vận hành đang thực hiện các
hoạt động lập chính sách cụ thể chẳng hạn như kiểm tra các biên
bản hệ thống, các nhật ký, các cảnh báo sự kiện/giám sát, v.v…,
phát hiện xâm nhập và/hoặc báo cáo về các vi phạm bảo mật tiềm
ẩn hoặc vi phạm bảo mật thực tế. Điều này được thực hiện kết hợp
với Quản lý Bảo mật Thông tin để cung cấp một điểm hệ thống kiểm
tra và cân bằng để đảm bảo việc phát hiện và quản lý hiệu quả
nhũng vấn đề về bảo mật.
Nhân viên Vận hành Dịch vụ thường là người đầu tiên phát hiện ra
các sự kiện bảo mật và ở vị thế tốt nhất để có khả năng tắt và/hoặc
loại bỏ quyền truy cập đến các hệ thống bị xâm phạm.
Sự chú ý đặc biệt sẽ được cần đến trong trường hợp các tổ chức bên
thứ ba yêu cầu quyền truy cập vào tổ chức. Nhân viên Vận hành
Dịch vụ có thể được yêu cầu để hộ tống khách viếng thăm trong
những khu vực nhạy cảm và/hoặc kiểm soát sự truy cập của họ.
Họ cũng có thể phải đóng một vai trò trong việc kiểm soát truy cập
mạng đối với các bên thứ ba, chẳng hạn như những người bảo trì
phần cứng gọi vào (dial-in) cho mục đích chẩn đoán, v.v…
5.13.2 Trợ gi úp k ỹ thuậ t

Một số loại hỗ trợ kỹ thuật có thể cần phải được cung cấp cho nhân
viên Bảo mật CNTT để hỗ trợ điều tra các sự cố bảo mật và giúp đưa
ra các báo cáo hoặc trong việc thu thập các bằng chứng pháp y để
sử dụng trong một hành động kỷ luật hoặc truy tố hình sự.
Tư vấn và hỗ trợ kỹ thuật cũng có thể được cần đến liên quan đến
các cải thiện bảo mật tiềm năng (ví dụ, thiết lập các tường lửa hoặc
các biện pháp kiểm soát truy cập/mật khẩu).
Việc sử dụng những thông tin quản lý sự kiện, sự cố, vấn đề có thể
được dựa vào để cung cấp những trình tự thời gian chính xác của
các cuộc điều tra có liên quan đến bảo mật.
5.13.3 Kiểm soát b ả o mậ t v ậ n hành

Vì lý do vận hành, nhân viên kỹ thuật thường cần có đặc quyền truy
cập đến những khu vực kỹ thuật chủ chốt (ví dụ, mật khẩu root của
hệ thống, truy cập vật lý vào Trung tâm Dữ liệu hoặc phòng truyền
thông, v.v…). Do đó, điều thiết yếu là các biện pháp kiểm soát phải
đầy đủ và dấu vết kiểm toán được giữ lại đối với những hoạt động
đặc quyền như vậy để xác định và phát hiện bất kỳ sự kiện bảo mật
nào.
Kiểm soát vật lý cần được đưa ra cho mọi khu vực bảo mật với việc
ghi nhật ký vào-ra của mọi nhân viên. Khi nhân viên của bên thứ ba
hoặc khách viếng thăm cần phải truy cập, nhân viên Vận hành Dịch
vụ có thể phải chịu trách nhiệm cho việc hộ tống và quản lý sự di
chuyển của những cá nhân này.
Trong trường hợp truy cập hệ thống với đặc quyền, việc này cần
được hạn chế chỉ cho những người cần phải truy cập hệ thống và đã
được xác minh – và được rút lại ngay lập tức khi nhu cầu truy cập
không còn nữa. Một dấu vết kiểm toán phải được duy trì về những ai
đã truy cập và khi nào, và về mọi hoạt động đã được thực hiện với
mức độ truy cập đó.
5.13.4 Sàng l ọc và xem x ét lý l ị c h

Mọi nhân viên Vận hành Dịch vụ nên được sàng lọc và xem xét lý
lịch với mức độ bảo mật thích hợp với tổ chức đang được đề cập.
Các nhà cung cấp và các nhà thầu bên thứ ba cũng nên được sàng
lọc và kiểm tra – cả tổ chức lẫn những nhân sự cụ thể có liên quan.
Rất nhiều tổ chức đã bắt đầu sử dụng việc kiểm tra lý lịch của cơ
quan cảnh sát hoặc các cơ quan chính phủ, đặc biệt khi các nhà thầu
làm việc với các hệ thống đã được phân loại. Khi cần thiết, các thỏa
thuận không tiết lộ và bảo mật cần thiết phải được thống nhất.
5.13.5 Đào t ạ o và nâng cao nh ậ n th ức
Mọi nhân viên Vận hành Dịch vụ nên được đào tạo và nâng cao nhận
thức định kỳ và liên tục về chính sách và các thủ tục bảo mật của tổ
chức. Điều này nên bao gồm chi tiết về các biện pháp kỷ luật đang
được áp dụng. Ngoài ra, bất kỳ yêu cầu bảo mật nào nên được chỉ
định trong hợp đồng nhân viên hoặc công việc.
5.13.6 Các chính sách và th ủ tục đư ợ c l ậ p thành

văn b ản
Các thủ tục đã được lập thành văn bản về Vận hành Dịch vụ phải
bao gồm mọi thông tin liên quan có liên quan đ ến các vấn đề bảo
mật – được trích xuất từ các tài liêu chính sách bảo mật tổng thể
của tổ chức. Nên đưa ra cân nhắc về việc sử dụng sổ tay để giúp
cho việc truyền đạt các thông điệp bảo mật cho tất cả các nhân viên
có liên quan.
5.14 Cải thiện các hoạt động vận hành
Mọi nhân viên Vận hành Dịch vụ nên liên tục tìm kiếm những lĩnh
vực mà trong đó, quy trình cải thiện có thể được thực hiện để mạng
lại chất lượng dịch vụ CNTT cao hơn và/hoặc được thực hiện theo
một cách hiệu quả chi phí hơn. Điều này có thể bao gồm một số hoạt
động dưới đây.
5.14.1 Tự độ ng hóa các tác v ụ thủ công
Bất kỳ tác vụ nào phải được thực hiện một cách thủ công, đặc biệt
là những tác vụ phải lặp lại thường xuyên, có khả năng sẽ tiêu tốn
nhiều thời gian, chi phí và dễ xảy ra lỗi hơn những tác vụ có thể
được hệ thống hóa và tự động hóa. Mọi tác vụ nên được kiểm tra về
tiềm năng tự động hóa để giảm thiểu những nỗ lực và chi phí và tối
thiểu hóa các lỗi tiềm ẩn.
Một phán đoán phải được đưa ra về chi phí của việc tự động hóa và
khả năng những lợi ích có thể xảy ra.
5.14.2 Đánh giá các ho ạ t đ ộ ng h o ặ c th ủ tục t ạ m

th ờ i
Vì bản chất thực tế của Vận hành Dịch vụ, thỉnh thoảng có thể phát
sinh rằng các hoạt động hoặc quy trình tạm thời được đưa ra để giải
quyết các vấn đề còn thiếu sót trong hoạt động ngắn hạn. Có một
nguy cơ là những thực tiễn như vậy có thể vẫn được tiếp tục và trở
thành 'chuẩn mực' - dẫn đến sự kém hiệu quả liên tục. Trong trường
hợp bất kỳ hoạt động hoặc thủ tục tạm thời nào bắt buộc phải được
đưa ra, điều quan trọng là chúng phải được xem xét ngay sau khi
hiệu quả tức thời bị ảnh hưởng - và được phân bổ hoặc thay thế
bằng các quy trình đã được thỏa thuận hiệu quả trong thời gian dài
hơn.
5.14.3 Các cu ộc ki ể m toán v ậ n hành
Các cuộc kiểm toán định kỳ nên được tiến hành đối với mọi quy trình
Vận hành Dịch vụ để đảm bảo rằng chúng đang hoạt động một cách
thỏa đáng.
5.14.4 V iệc s ử dụn g Q u ả n lý S ự c ố v à V ấ n đ ề
Quản lý Sự cố và Quản lý Vấn đề cung cấp một nguồn phong phú cho
những cơ hội cải thiện hoạt động. Những quy trình này đã được thảo
luận chi tiết hơn trong Chương 4 của ấn phẩm này.
5.14.5 Truy ề n thông
Hiển nhiên là truyền thông liên lạc tốt về các yêu cầu, công nghệ và
quy trình thay đổi sẽ dẫn đến những cải thiện trong Vận hành Dịch
vụ. Tuy nhiên, truyền thông giao tiếp thường bị bỏ qua. Các cải tiến
Vận hành Dịch vụ phụ thuộc vào giao tiếp chính thức và thường
xuyên giữa các nhóm chịu trách nhiệm thiết kế, hỗ trợ và vận hành
các dịch vụ.
5.14.6 Giáo d ụ c và Đào t ạ o
Nhóm Vận hành Dịch vụ nên hiểu về tầm quan trọng của những việc
mà họ thực hiện hàng ngày. Giáo dục là cần thiết để đảm bảo rằng
nhân viên hiểu được những chức năng nghiệp vụ hoặc dịch vụ nào
được hỗ trợ bởi các hoạt động của họ. Điều này sẽ khuyến khích sự
quan tâm và chú ý nhiều hơn đến từng chi tiết và cũng sẽ giúp các
nhóm Vận hành Dịch vụ xác định tốt hơn các ưu tiên kinh doanh.
Các chương trình đào tạo nên đảm bảo rằng tất cả nhân viên đều có
các kỹ năng thích hợp đối với công nghệ hoặc ứng dụng mà họ đang
quản lý. Việc đào tạo phải luôn được cung cấp khi công nghệ mới
được giới thiệu hoặc khi công nghệ hiện có được thay đổi.
6 V iệc t ổ c h ức V ậ n hành D ị ch v ụ
6.1 Các chức năng
Một chức năng là một khái niệm logic đề cập đến con người và các
biện pháp được tự động hóa để thực thi một quy trình, một hoạt
động đã được xác định, hoặc một kết hợp các quy trình hoặc các
hoạt động. Trong những tổ chức lớn hơn, một chức năng có thể
được chia nhỏ và được thực hiện bởi một số bộ phận, nhóm hoặc
đội, hoặc có thể được hợp nhất trong một đơn vị tổ chức duy nhất.
Hình 6.1 – Các chức năng Vận hành Dịch vụ
Các chức năng Vận hành Dịch vụ được đưa ra trong Hình 6.1 là cần
thiết để quản lý môi trường CNTT vận hành ở ‘trạng thái ổn định’.
Đây là những chức năng hợp lý và không nhất thiết phải được thực
hiện bởi một cơ cấu tổ chức tương đương. Điều này có nghĩa là Quản
lý Kỹ thuật và Quản lý Ứng dụng có thể được tổ chức theo bất kỳ sự
kết hợp nào và với bất kỳ số lượng phòng ban, bộ phận nào. Các
nhóm cấp độ thứ hai trong Hình 6.1 là những ví dụ về các nhóm
hoạt động điển hình được thực hiện bởi Quản lý Kỹ thuật (xem
Chương 5) và không phải là một cấu trúc tổ chức được đề xuất.
Dưới đây là tổng quan về các chức năng Vận hành Dịch vụ trong
Hình 6.1:
 Bộ phận Hỗ trợ Dịch vụ là đầu mối liên hệ chính của người

dùng khi xảy ra sự cố gián đoạn dịch vụ, đối với các yêu cầu
dịch vụ hoặc thậm chí đối với một số mục Yêu cầu Thay đổi. Bộ
phận Hỗ trợ Dịch vụ cung cấp một điểm giao tiếp với người
dùng và một điểm điều phối đối với một số nhóm và quy trình
CNTT. Để hỗ trợ họ thực hiện những hành động này một cách
hiệu quả, Bộ phận Hỗ trợ Dịch vụ thường tách biệt với các chức
năng Vận hành Dịch vụ khác. Ví dụ, trong một số trường hợp,
khi hỗ trợ kỹ thuật chi tiết được cung cấp cho người dùng ngay
trong cuộc gọi đầu tiên, nhân viên Quản lý Kỹ thuật hoặc Quản
lý Ứng dụng có thể cần phải có mặt tại Bộ phận Hỗ trợ Dịch vụ.
Điều này không có nghĩa là Bộ phận Hỗ trợ Dịch vụ trở thành
một phần của chức năng Quản lý kỹ thuật. Trên thực tế, khi ở
trên Bộ phận Hỗ trợ Dịch vụ, họ không còn là một phần của
chức năng Quản lý Kỹ thuật hoặc Quản lý Ứng dụng và trở
thành một phần của Bộ phận Hỗ trợ Dịch vụ, ngay cả khi chỉ là
tạm thời.
 Quản lý Kỹ thuật cung cấp các kỹ năng kỹ thuật chi tiết và các
nguồn lực cần thiết để hỗ trợ cho hoạt động liên tục của Cơ sở
hạ tầng CNTT. Quản lý Kỹ thuật cũng đóng một vai trò quan
trọng trong việc thiết kế, thử nghiệm, phát hành và cải tiến
các dịch vụ CNTT. Trong các tổ chức nhỏ, có thể quản lý
chuyên môn này trong một bộ phận duy nhất, nhưng các tổ
chức lớn hơn thường được chia thành một số bộ phận chuyên
sâu về kỹ thuật (xem phần sau của chương này). Trong rất
nhiều tổ chức, các bộ phận Quản lý Kỹ thuật cũng đồng thời
chịu trách nhiệm về hoạt động hàng ngày của một tập hợp con
của Cơ sở hạ tầng CNTT. Hình 6.1 cho thấy, mặc dù họ là một
phần của bộ phận Quản lý Kỹ thuật, nhưng về mặt logic, nhân
viên thực hiện những hoạt động này là một phần của chức năng
Quản lý Vận hành CNTT.
 Quản lý Vận hành CNTT là chức năng chịu trách nhiệm về các
hoạt động vận hành hàng ngày cần thiết để quản lý Cơ sở hạ
tầng CNTT. Điều này được thực hiện theo các Tiêu chuẩn Hiệu
suất đã được xác định trong quá trình Thiết kế Dịch vụ. Trong
một số tổ chức, đây là một bộ phận đơn lẻ và tập trung, trong
khi ở một số tổ chức khác, một số hoạt động và nhân viên được
tập trung và một số được cung cấp bởi các bộ phận được phân
tán hoặc chuyên môn hóa. Điều này được minh họa trong Hình
6.1 bởi sự chồng chéo từ các chức năng Quản lý Kỹ thuật và
Quản lý Ứng dụng. Quản lý Vận hành CNTT có hai chức năng
duy nhất và thường là các cơ cấu tổ chức chính thức. Đó là:
 Kiểm soát Vận hành CNTT, thường được cơ cấu nhân sự
theo ca hoặc nhân viên vận hành và đảm bảo rằng các tác
vụ vận hành thường lệ được thực hiện. Kiểm soát Vận
hành Dịch vụ cũng sẽ cung cấp các hoạt động kiểm soát
và giám sát được tập trung hóa, thường sử dụng một Cầu
nối Vận hành hoặc Trung tâm Vận hành Mạng.
 Quản lý Cơ sở vật chất đề cập đến việc quản lý môi
trường CNTT vật lý, thường là các Trung tâm Dữ liệu hoặc
các phòng máy tính. Trong rất nhiều tổ chức, Quản lý Kỹ
thuật và Quản lý Ứng dụng được đồng định vị với Vận
hành CNTT trong các Trung tâm D ữ liệu lớn. Trong một số
tổ chức, rất nhiều thành phần vật lý của Cơ sở hạ tầng
CNTT được thuê ngoài và Quản lý Cơ sở vật chất có thể
bao gồm việc quản lý các hợp đồng thuê ngoài.
 Quản lý Ứng dụng chịu trách nhiệm cho việc quản lý các ứng
dụng trong toàn bộ vòng đời của chúng. Chức năng Quản lý
Ứng dụng hỗ trợ và duy trì các ứng dụng vận hành đồng thời
đóng một vai trò quan trọng trong thiết kế, kiểm nghiệm và cải
thiện các ứng dụng hình thành nên một phần của các dịch vụ
CNTT. Quản lý Ứng dụng thường được chia thành các bộ phận
dựa trên danh mục ứng dụng của tổ chức (xem các ví dụ trong
Hình 6.1), từ đó, việc cho phép chuyên môn hóa tr ở nên dễ
dàng hơn và tập trung vào hỗ trợ hơn. Trong rất nhiều tổ chức,
các bộ phận Quản lý Ứng dụng có những nhân viên, những
người thực hiện công việc vận hành hàng ngày đối với những
ứng dụng này. Như với Quản lý Kỹ thuật, những nhân viên này
hình thành nên một phần của chức năng Quản lý Vận hành
CNTT một cách hợp lý.
Lưu ý đặc biệt về Quản lý Bảo mật Thông tin
Mặc dù hầu hết đều sẽ đồng ý rằng Quản lý Bảo mật Thông tin là một chức năng,
tuy nhiên nó được chuyên môn hóa cao và mở rộng qua vài giai đoạn của vòng
đời. Nó cũng chịu trách nhiệm cho việc giám sát rất nhiều hoạt động trong mọi
chức năng Vận hành Dịch vụ. Để biết thêm mô tả chi tiết sâu hơn về Quản lý Bảo
mật Thông tin, vui lòng tham kh ảo ấn phẩm Thiết kế Dịch vụ và phần 5.13 của ấn
phẩm này.
6.1.1 Các ch ức năng và ho ạ t đ ộ ng
Chương 5 của ấn phẩm này giới thiệu một số các hoạt động Vận
hành Dịch vụ phổ biến. Do bản chất kỹ thuật và sự chuyên môn hóa
của những hoạt động này, các nhóm, các đội hoặc các bộ phận đang
thực hiện chúng thường được đặt tên tương ứng với các hoạt động
cụ thể. Ví dụ, Quản lý Mạng có thể được hoàn thành bởi ‘Bộ phận
Quản lý Mạng’. Điều này, tuy nhiên, không có nghĩa là m ột quy tắc.
Có một số tùy chọn sẵn có để ánh xạ các hoạt động tới một nhóm
hoặc một bộ phận, ví dụ như:
 Một hoạt động có thể được thực hiện bởi một vài nhóm hoặc bộ
phận, ví dụ, nếu một tổ chức có 5 bộ phận Hỗ trợ Ứng dụng
chính, từng bộ phận hỗ trợ cho một bộ các ứng dụng khác
nhau, và mỗi một trong số các bộ phận này đều có thể thực
hiện Quản trị Cơ sở dữ liệu cho các ứng dụng ‘của họ’.
 Một bộ phận có thể thực hiện một số hoạt động, ví dụ, Bộ phận
Quản lý mạng có thể chịu trách nhiệm cho việc quản lý mạng,
Quản lý các Dịch vụ Danh bạ và Quản lý Máy chủ.
 Một hoạt động có thể được hoàn thành bởi nhiều nhóm, chẳng
hạn như Quản lý Bảo mật có thể được hoàn thành bởi bất kỳ cá
nhân nào chịu trách nhiệm cho việc quản lý một ứng dụng, máy
chủ, phần mềm trung gian hoặc máy tính để bàn.
Những quyết định này của tổ chức chịu ảnh hưởng bởi một số các
yếu tố, chẳng hạn như:
 Quy mô và vị trí của tổ chức. Các tổ chức nhỏ hơn và ít phân

tán hơn sẽ có khuynh hướng kết hợp các chức năng này, trong
khi các tổ chức lớn và phân tán có thể có một vài nhóm hoặc
bộ phận thực hiện các hoạt động giống nhau (ví dụ, theo khu
vực).
 Mức độ phức tạp của công nghệ được sử dụng trong tổ chức.
Số lượng các công nghệ khác nhau được sử dụng càng lớn thi
càng có khả năng sẽ có vài nhóm khác nhau, mỗi nhóm cùng
thực hiện một số điều tương tự nhau, nhưng trong bối cảnh
khác nhau (ví dụ, Quản lý Máy chủ UNIX và Quản lý Máy chủ
Windows).
 Mức độ kỹ năng sẵn có. Khi các kỹ năng kỹ thuật là điều khan
hiếm, các tổ chức thường sử dụng những người có kiến thức
tổng quát để thực hiện nhiều nhóm hoạt động - mặc dù, trong
một số trường hợp, các cân nhắc bảo mật khiến việc này trở
nên rất khó khăn. Ví dụ, một tổ chức hoạt động trong các dự
án đã được phân loại hoặc bí mật có thể phải thuê các nguồn
lực chuyên biệt và đắt tiền ngay cả khi điều đó có nghĩa là
phải tái định vị chúng (các dự án – người dịch) hoặc ký hợp
đồng với các nhà cung cấp đã được bảo mật.
 Văn hóa của tổ chức. Một số tổ chức ưa thích làm việc trong
môi trường chuyên môn hóa cao, trong khi nh ững tổ chức khác
có xu hướng thích sự linh hoạt của đội ngũ nhân viên có kiến
thức tổng quát.
 Tình hình tài chính của tổ chức sẽ xác định có bao nhiêu người,
với loại kỹ năng nào có thể được tuyển dụng và cách thức họ
được tổ chức như thế nào.
Vì những yếu tố này, sẽ là không khả thi đối với ấn phẩm này để quy
định một cơ cấu tổ chức thích hợp sẽ có thể phù hợp với mọi tình
huống, tuy nhiên, những phần dưới đây liệt kê các hoạt động bắt
buộc theo các nhóm chức năng có nhiều khả năng tham gia vào hoạt
động của họ. Hãy lưu ý rằng điều này không có nghĩa là mọi tổ chức
phải sử dụng các bộ phận này. Các tổ chức nhỏ hơn sẽ có xu hướng
kết hợp các hoạt động này thành các bộ phận đơn lẻ, hoặc thậm chí
các cá nhân - nếu chúng thậm chí còn cần thiết.
Lưu ý đặc biệt về thuê ngoài
Những cân nhắc mang tính tổ chức này có khả năng liên quan nhất đến các tổ
chức CNTT nội bộ. Tình huống trở nên phức tạp hơn khi một số hoặc tất cả hoạt
động hoặc chức năng tương tự được thuê ngoài. Cơ hội hoàn hảo để thuê ngoài là
các bộ phận Hỗ trợ Dịch vụ và Vận hành Mạng. Điều này sẽ được đề cập chi tiết
hơn trong Hướng dẫn ITIL Bổ sung, tuy nhiên một số điểm then chốt cần ghi nhớ
là:
 Bất kể ai đang thực hiện hoạt động, công ty ký hợp đồng với bên cho thuê
ngoài vẫn sẽ chịu trách nhiệm cho việc đảm bảo rằng nó được thực hiện
theo một tiêu chuẩn mà sẽ hỗ trợ cho việc cung cấp các dịch vụ cho khách
hàng và người dùng của họ.
 Việc thuê ngoài để giải quyết các vấn đề của một tổ chức hoặc như là một
giải pháp thay thế cho các quy trình Quản lý Dịch vụ tốt hiếm khi hoạt động.
Kết quả tốt nhất sẽ đạt được nếu chúng được thực hiện trước khi thuê
ngoài.
 Việc thuê ngoài hoạt động tốt nhất khi có sự tham gia tích cực của cả hai tổ
chức (bên thuê ngoài và bên cho thuê ngoài – người dịch). Nếu nhân viên và
các nhà quản lý của tổ chức khách hàng được tự do, bên cho thuê ngoài khó
có khả năng thành công, đơn giản là bởi vì không ai hiểu về tổ chức tốt hơn
những người đang làm việc ở đó.
 Bên cho thuê ngoài không nên xác đ ịnh các kết quả đầu ra của họ hoặc cách
thức mà chúng được đo lường như thế nào. Những điều này được xác định
bằng cách hiểu về các yêu cầu nghiệp vụ của người dùng và khách hàng và
đảm bảo rằng chúng (các yêu cầu) có thể được đáp ứng bởi những năng lực
của bên cho thuê ngoài.
 Mặc dù các dịch vụ của bên cho thuê ngoài trở thành một phần không thể
thiếu của tổ chức, họ vẫn là một bên thứ ba, với một bộ các mục tiêu kinh
doanh, chính sách và thực tiễn khác. Các tiêu chuẩn bảo mật phải được giữ
gìn và cả hai bên phải hiểu một cách rõ ràng về những vai trò và đóng góp
tương ứng của họ.
6.2 Bộ phận Hỗ trợ Dịch vụ
Bộ phận Hỗ trợ Dịch vụ là một đơn vị chức năng bao gồm một số
nhân viên chuyên trách chịu trách nhiệm cho việc giải quyết nhiều
sự kiện dịch vụ khác nhau, thường được thực hiện qua các cuộc gọi
điện thoại, giao diện web hoặc các sự kiện cơ sở hạ tầng được báo
cáo một cách tự động.
Bộ phận Hỗ trợ Dịch vụ là một bộ phận cực kỳ quan trọng của Bộ

phận CNTT của tổ chức và nên là đầu mối liên hệ duy nhất của
người dùng CNTT hàng ngày - và sẽ xử lý mọi sự cố và yêu cầu dịch
vụ, thường sử dụng các công cụ phần mềm chuyên dụng để ghi nhật
ký và quản lý tất cả các sự kiện như vậy.
Giá trị của một Bộ phận Hỗ trợ Dịch vụ hiệu quả không nên bị đánh
giá quá thấp - một Bộ phận Hỗ trợ Dịch vụ tốt thường có thể bù đắp
cho những thiếu sót ở những nơi khác trong tổ chức CNTT; nhưng
một Bộ phận Hỗ trợ Dịch vụ kém (hoặc thiếu Bộ phận Hỗ trợ Dịch
vụ) có thể gây ấn tượng không tốt về một tổ chức CNTT rất hiệu
quả!
Do đó, một điều cực kỳ quan trọng là nhân viên được sử dụng tại Bộ
phận Hỗ trợ Dịch vụ phải đúng tầm cỡ và rằng các Nhà quản lý CNTT
cố gắng hết sức để biến Bộ phận Hỗ trợ Dịch vụ trở thành một nơi
hấp dẫn để làm việc nhằm cải thiện khả năng giữ chân nhân viên.
Bản chất, loại, quy mô và vị trí chính xác của Bộ phận Hỗ trợ Dịch
vụ sẽ khác nhau, tùy thuộc vào loại hình kinh doanh, số lượng người
dùng, vị trí địa lý, mức độ phức tạp của cuộc gọi, phạm vi dịch vụ
và rất nhiều yếu tố khác.
Để liên kết với yêu cầu của khách hàng và doanh nghiệp, các nhà
quản lý cấp cao của tổ chức CNTT nên quyết định bản chất chính xác
của Bộ phận Hỗ trợ Dịch vụ cần thiết của họ (và liệu nó nên là nội
bộ hay thuê ngoài cho bên thứ ba) như một phần của chiến lược
ITSM tổng thể (xem ấn phẩm Chiến lược Dịch vụ) - và kế hoạch tiếp
theo sau đó phải được thực hiện để chuẩn bị và sau đó triển khai
chức năng Bộ phận Hỗ trợ Dịch vụ thích hợp (hoặc khi triển khai một
chức năng mới, hoặc nhiều khả năng hơn vào những ngày này khi
thực hiện các sửa đổi cần thiết cho một chức năng hiện có - xem ấn
phẩm Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ).
6.2.1 B iện m inh và vai trò c ủa Bộ ph ậ n H ỗ tr ợ
Dịch v ụ
Ngày nay cần có rất ít biện minh cho một Bộ phận Hỗ trợ Dịch vụ, vì
rất nhiều tổ chức đã được thuyết phục rằng đây là phương pháp tiếp
cận tốt nhất cho đến nay để giải quyết các vấn đề hỗ trợ CNTT
tuyến đầu tiên. Chỉ cần đặt câu hỏi ‘Giải pháp thay thế là gì?’ để
đưa ra một trường hợp thuyết phục cho khái niệm Bộ phận Hỗ trợ
Dịch vụ. Khi cần biện minh thêm, những lợi ích dưới đây nên được
cân nhắc:
 Dịch vụ, nhận thức và sự hài lòng của khách hàng được cải
thiện,
 Khả năng tiếp cận được gia tăng thông qua một điểm đơn liên
hệ, giao tiếp và truyền thông,
 Chất lượng tốt hơn và các yêu cầu của khách hàng quay vòng
nhanh hơn,
 Truyền thông và làm việc nhóm được cải thiện,
 Sự tập trung được tăng cường và một phương pháp tiếp cận
chủ động đối với việc cung cấp dịch vụ,
 Tác động kinh doanh tiêu cực được giảm thiểu,
 Cơ sở hạ tầng và biện pháp kiểm soát được quản lý tốt hơn,
 Mức sử dụng tài nguyên Hỗ trợ CNTT được cải thiện và năng
suất của nhân viên của doanh nghiệp được gia tăng,
 Thông tin quản lý có ý nghĩa hơn để hỗ trợ việc đưa ra quyết
định,
 Một thực tế phổ biến là Bộ phận Hỗ trợ Dịch vụ cung cấp các vị
trí ‘mới bắt đầu’ cho nhân viên ITSM. Làm việc tại Bộ phận Hỗ
trợ Dịch vụ là một ‘nền tảng’ tuyệt vời cho bất kỳ ai muốn theo
đuổi sự nghiệp trong lĩnh vực Quản lý Dịch vụ. Tuy nhiên, điều
này cũng có thể gây ra những thách thức đối với những người
không am hiểu về kinh doanh hoặc công nghệ. Người dùng gọi
đến Bộ phận Hỗ trợ Dịch vụ có khả năng sẽ nói chuyện với một
người có khả năng giải quyết nhu cầu của họ và các Nhà phân
tích Bộ phận Hỗ trợ Dịch vụ sẽ không nên bị loại bỏ trong vòng
chưa đầy một năm vì căng thẳng quá mức (hơi khó hiểu –
người dịch). Cần cẩn trọng khi lựa chọn những cá nhân có kỹ
năng phù hợp, có hiểu biết tốt về doanh nghiệp và cung cấp
đào tạo đầy đủ - từ đó, ngăn ngừa việc giảm thiểu trong mức
độ hỗ trợ do thiếu kiến thức ở tuyến đầu.
6.2.2 Mục ti êu c ủa B ộ ph ậ n H ỗ trợ Dịc h v ụ
Mục đích chính của Bộ phận Hỗ trợ Dịch vụ là khôi phục ‘dịch vụ
bình thường’ đối với người dùng càng nhanh càng tốt. Trong bối
cảnh này, ‘sự khôi phục của dịch vụ’ được hiểu theo nghĩa rộng nhất
có thể. Mặc dù điều này có thể liên quan đến việc sửa chữa một lỗi
kỹ thuật nhưng nó cũng có thể liên quan đến việc thực hiện một yêu
cầu dịch vụ hoặc trả lời một truy vấn - bất kỳ điều gì cần thiết để
cho phép người dùng trở lại làm việc một cách hài lòng.
Các trách nhiệm cụ thể sẽ bao gồm:
 Ghi nhật ký mọi chi tiết về sự cố/yêu cầu dịch vụ có liên quan,
phân bổ mã phân loại và mã ưu tiên,
 Cung cấp điều tra và chẩn đoán tuyến đầu tiên,
 Giải quyết những sự cố/yêu cầu dịch vụ mà họ có thể giải
quyết,
 Leo thang các sự cố/yêu cầu dịch vụ mà họ không thể giải
quyết trong khoảng thời gian đã được thống nhất,
 Giữ cho người dùng được thông báo về tiến độ,
 Đóng tất cả các sự cố, yêu cầu và các cuộc gọi khác đã được
giải quyết,
 Thực hiện các cuộc gọi lại/khảo sát về mức độ hài lòng của
khách hàng / người dùng theo thỏa thuận
 Giao tiếp với người dùng - thông báo cho họ về tiến trình sự
cố, thông báo cho họ về những thay đổi sắp xảy ra hoặc những
gián đoạn đã được thống nhất, v.v…
 Cập nhật CMS dưới sự chỉ đạo và phê duyệt của Quản lý Cấu
hình nếu được đồng ý.
Lưu ý: những hoạt động này được giải thích và đặt trong bối cảnh
với quy trình Quản lý Sự cố và Thực hiện Yêu cầu đầy đủ hơn trong
phần 4.2 và 4.2 một cách tương ứng.
6.2.3 C ấ u trúc t ổ c h ức c ủa B ộ ph ậ n H ỗ trợ Dịch

vụ
Có rất nhiều cách để cấu trúc Bộ phận Hỗ trợ Dịch vụ và định vị

chúng – và giải pháp đúng đắn sẽ khác nhau đối với các tổ chức
khác nhau. Các tùy chọn chủ yếu được trình bày chi tiết dưới đây,
tuy nhiên trong thực tế, một tổ chức có thể cần phải triển khai một
cơ cấu kết hợp một số tùy chọn để đáp ứng đầy đủ những nhu cầu
của doanh nghiệp.
6.2.3. 1 B ộ ph ậ n H ỗ t rợ Dịc h v ụ đị a phư ơng
Đây là nơi Bộ phận Hỗ trợ Dịch vụ được đồng-định vị trong phạm vi

hoặc gần gũi về mặt địa lý với cộng đồng người dùng mà nó phục
vụ. Điều này thường hỗ trợ giao tiếp và mang lại một sự hiện diện
rõ ràng mà một số người dùng ưa thích, nhưng thường có thể không
hiệu quả và tốn kém tài nguyên do nhân viên bị ràng buộc phải chờ
để giải quyết các sự cố khi mà khối lượng và tỷ lệ đến của các cuộc
gọi có thể không giải thích được điều này.
Tuy nhiên, có thể vẫn có một số lý do hợp lý để duy trì Bộ phận Hỗ

trợ Dịch vụ cục bộ, ngay cả khi chỉ riêng khối lượng cuộc gọi không
giải thích cho điều này. Các lý do có thể bao gồm:
 Sự khác biệt về ngôn ngữ và văn hóa hoặc chính trị,

 Múi giờ khác nhau,
 Những nhóm người dùng được chuyên môn hóa,
 Sự tồn tại của các dịch vụ được tùy chỉnh hoặc chuyên biệt đòi
hỏi những kiến thức chuyên môn,
 Tình trạng VIP/tầm quan trọng của người dùng.
Hình 6.2 – Bộ phận Hỗ trợ Dịch vụ địa phương
6.2.3. 2 B ộ ph ậ n H ỗ t rợ Dịc h v ụ đượ c t ậ p trun g hóa
Có thể giảm số lượng Bộ phận Hỗ trợ Dịch vụ bằng cách hợp nhất
chúng thành một vị trí duy nhất (hoặc thành một số vị trí nhỏ hơn)
bằng cách thu hút nhân viên vào m ột hoặc nhiều cấu trúc Bộ phận
Hỗ trợ Dịch vụ tập trung. Điều này có thể hiệu quả hơn và tiết kiệm
chi phí hơn, cho phép ít nhân viên t ổng thể hơn để giải quyết khối
lượng cuộc gọi cao hơn và cũng có thể dẫn đến cấp độ kỹ năng cao
hơn thông qua sự quen thuộc thông qua các sự kiện xảy ra thường
xuyên hơn. Có thể cũng vẫn cần duy trì một số hình thức 'hiện diện
tại địa phương' để xử lý các yêu cầu hỗ trợ vật lý, nhưng những
nhân viên như vậy có thể được kiểm soát và triển khai từ Bộ phận
Hỗ trợ Dịch vụ làm việc trung tâm.
Hình 6.3 – Bộ phận Hỗ trợ Dịch vụ Tập trung
6.2.3. 3 B ộ ph ậ n H ỗ t rợ Dịc h v ụ đượ c ả o hóa
Thông qua việc sử dụng công nghệ, đặc biệt là Internet, và việc sử
dụng các công cụ hỗ trợ doanh nghiệp, có thể đưa ra ấn tượng về
một Bộ phận Hỗ trợ Dịch vụ tập trung và duy nhất trong khi trên
thực tế, nhân sự có thể được dàn trải hoặc bố trí với bất kỳ số
lượng hoặc loại vị trí địa lý hoặc cấu trúc nào. Điều này mang lại tùy
chọn 'làm việc tại nhà', nhóm hỗ trợ thứ cấp, xa bờ (off-shoring)
hoặc thuê ngoài - hoặc bất kỳ sự kết hợp nào cần thiết để đáp ứng
cho nhu cầu của người dùng. Tuy nhiên, một điều quan trọng cần
phải lưu ý là, các biện pháp bảo vệ cần phải có mặt trong tất cả các
trường hợp này để đảm bảo tính nhất quán và đồng nhất về chất
lượng dịch vụ và các điều khoản văn hóa.
Hình 6.4 – Bộ phận Hỗ trợ Dịch vụ Ảo
6.2.3. 4 ( Hỗ trợ ) Theo múi gi ờ ( F ollo w the Su n)
Một số tổ chức toàn cầu có thể muốn kết hợp hai hoặc nhiều Bộ
phận Hỗ trợ Dịch vụ phân tán về mặt địa lý của họ để cung cấp một
dịch vụ 24 giờ theo múi giờ. Ví dụ, một Bộ phận Hỗ trợ Dịch vụ ở
khu vực Châu Á-Thái Bình Dương có thể xử lý các cuộc gọi trong giờ
làm việc tiêu chuẩn của họ và tại thời điểm cuối chu kỳ này, nó có
thể bàn giao trách nhiệm về bất kỳ sự cố đang mở nào cho Bộ phận
Hỗ trợ Dịch vụ có cơ sở tại Châu Âu. Bộ phận Hỗ trợ Dịch vụ này sẽ
tiếp tục xử lý các cuộc gọi này cùng với các sự cố của riêng họ trong
ngày làm việc tiêu chuẩn của họ và sau đó, bàn giao cho một Bộ
phận Hỗ trợ Dịch vụ có cơ sở tại Hoa Kỳ - vốn cuối cùng bàn giao
trách nhiệm lại cho Bộ phận Hỗ trợ Dịch vụ Châu Á-Thái Bình Dương
để hoàn tất chu trình.
Việc này có thể đưa ra một độ phủ 24-giờ với mức chi phí tương đối
thấp, vì không có Bộ phận Hỗ trợ Dịch vụ nào phải làm việc trong
nhiều hơn một ca đơn lẻ. Tuy nhiên, các biện pháp bảo vệ tương tự
đối với các quy trình, công cụ, cơ sở dữ liệu được chia sẻ về thông
tin và văn hóa cũng phải được giải quyết để phương pháp tiếp cận
này được tiến hành – và các quy trình bàn giao và leo thang được
kiểm soát tốt là cần thiết.
6.2.3. 5 Các nhóm Hỗ trợ Dị ch v ụ đượ c chuyên môn

hóa
Đối với một số tổ chức, có thể sẽ có lợi khi tạo ra ‘nhóm chuyên gia’
trong cơ cấu Bộ phận Hỗ trợ Dịch vụ tổng thể, để từ đó, các sự cố
liên quan đến một dịch vụ CNTT cụ thể có thể được chuyển trực tiếp
(thường thông qua lựa chọn điện thoại hoặc giao diện dựa trên nền
web) cho nhóm chuyên gia. Điều này có thể cho phép giải quyết
những sự cố này nhanh hơn, thông qua việc quen thuộc hơn và đào
tạo chuyên gia.
Lựa chọn sẽ được đưa ra bằng cách sử dụng một tập lệnh kịch bản
có dòng chữ ‘Nếu cuộc gọi của bạn là về Dịch vụ X, vui lòng nhấn
phím 1, nếu không, vui lòng giữ máy và đợi chuyên viên phân tích
của Bộ phận Hỗ trợ Dịch vụ’.
Sự cẩn trọng là điều cần thiết để không khiến cho việc lựa chọn trở
nên quá phức tạp, do đó, các nhóm chuyên gia ch ỉ nên được cân
nhắc cho một số lượng rất nhỏ các dịch vụ then chốt khi những dịch
vụ này tồn tại và khi tỷ lệ cuộc gọi về dịch vụ đó phù hợp với một
nhóm chuyên gia riêng biệt.
6.2.3. 6 Môi tr ư ờ ng
Môi trường nơi mà Bộ phận Hỗ trợ Dịch vụ được định vị nên được
lựa chọn một cách cẩn trọng. Nếu có thể, những cơ sở vật chất dưới
đây nên được cung cấp:
 Một vị trí nơi mà toàn bộ chức năng có thể được bố trí với đầy
đủ ánh sáng tự nhiên và không gian tổng thể - để cho phép đủ
không gian lưu trữ và bàn ghế, và phòng ốc để di chuyển xung
quanh nếu cần thiết,
 Một môi trường yên tĩnh với hệ thống kiểm soát âm thanh thích
hợp để một cuộc đàm thoại qua điện thoại không bị gián đoạn
bởi cuộc trò chuyện khác,
 Môi trường xung quanh dễ chịu và đồ nội thất thoải mái để
giúp cho tâm trạng nhẹ nhàng hơn (Bộ phận Hỗ trợ Dịch vụ có
thể là một nơi rất căng thẳng để làm việc, vì vậy mọi thứ đều
sẽ hữu ích!),
 Một khu vực giải khát và phòng nghỉ ngơi riêng biệt gần đó để
nhân viên có thể nghỉ ngơi ngắn khi cần thiết mà không phải
vắng mặt quá lâu.
Giai thoại
Một công ty đã nhận thấy rằng đã có một văn hóa ‘chúng tôi và họ’ đang tồn tại
giữa Bộ phận Hỗ trợ Dịch vụ và các nhóm hỗ trợ khác. Các nhóm tuyến thứ ba
thường tự tin rằng họ giỏi hơn Bộ phận Hỗ trợ Dịch vụ. Việc giấu Bộ phận Hỗ trợ
Dịch vụ trong một căn phòng bị cô lập đã giúp củng cố thêm văn hóa này. Công
ty đã nhận ra rằng việc tạo ra một văn phòng không gian mở với Bộ phận Hỗ trợ
Dịch vụ nằm ở giữa phòng đã khuyến khích việc cộng tác chặt chẽ hơn và đã giúp
phá vỡ những rào cản này.
6.2.3. 7 Lưu ý v ề v iệ c xây d ự ng đi ể m l i ên h ệ đơn l ẻ
Bất kể sự kết hợp các tùy chọn đã được chọn để thực hiện một cơ
cấu Bộ phận Hỗ trợ Dịch vụ tổng thể là gì, những người dùng riêng
lẻ nên chắc chắn về việc họ sẽ liên hệ với ai khi cần sự trợ giúp.
Một số điện thoại duy nhất (hoặc một số duy nhất cho từng nhóm
nếu các bàn tách biệt được chọn) nên được cung cấp và công bố rõ
ràng – cũng như là một địa chỉ e-mail duy nhất và một trang liên hệ
Bộ phận Hỗ trợ Dịch vụ trên web duy nhất.
Các ý tưởng có thể được sử dụng một cách thành công để giúp công
khai số điện thoại và địa chỉ e-mail của Bộ phận Hỗ trợ Dịch vụ, và
khiến cho nó trở nên gần với tầm tay khi người dùng có khả năng
cần chúng, chính là:
 Bao gồm số điện thoại của Bộ phận Hỗ trợ Dịch vụ trên nhãn
Đơn vị Cấu hình phần cứng, được đính kèm với các thành phần
mà người dùng có thể sẽ gọi đến để báo thông tin về chúng,
 Chi tiết liên hệ của Bộ phận Dịch vụ In ấn trên điện thoại,
 Đối với máy tính cá nhân và máy tính xách tay, sử dụng một
hình nền hoặc màn hình máy tính để bàn đã được tùy chỉnh với
chi tiết liên hệ của Bộ phận Hỗ trợ Dịch vụ, cùng với thông tin
được đọc từ hệ thống sẽ cần khi gọi (chẳng hạn như địa chỉ IP,
phiên bản của hệ điều hành, v.v…) nằm ở một góc,
 In số của Bộ phận Hỗ trợ Dịch vụ trên ‘đồ dùng miễn phí’ (bút,
bút chì, cốc, thảm lót chuột, v.v…),
 Đặt những thông tin chi tiết này một cách nổi bật trên các
trang web Internet/mạng nội bộ của Bộ phận Hỗ trợ Dịch vụ,
 Đưa chúng vào bất kỳ thẻ gọi điện thoại hoặc phiếu khảo sát
mức độ hài lòng nào để lại cho người dùng khi cần thiết phải
ghé thăm bàn làm việc,
 Lặp lại các chi tiết trên tất cả các thư từ được gửi cho người
dùng (cùng với các số tham chiếu cuộc gọi),
 Đặt các thông tin chi tiết trên bảng thông báo hoặc các vị trí
thực tế mà người dùng có thể thường xuyên lui tới (lối ra vào,
căng tin, khu giải khát, v.v…).
6.2.4 B ố trí nhân s ự B ộ p h ậ n H ỗ trợ Dịch v ụ
Các vấn đề có liên quan, và tiêu chí cho vi ệc thiết lập mô hình và
các cấp độ nhân sự thích hợp được thảo luận trong phần này. Những
chi tiết về các vai trò và trách nhiệm Bộ phận Hỗ trợ Dịch vụ điển
hình có thể được tìm thấy trong đoạn 6.6.1 dưới đây. Chúng bao
gồm Nhà quản lý Bộ phận Hỗ trợ Dịch vụ, Giám sát viên, Chuyên
viên phân tích và, trong một số tổ chức, những vai trò này được bổ
sung bởi người dùng doanh nghiệp (‘Người dùng Cấp cao’), những
người cung cấp sự hỗ trợ tuyến đầu.
6.2.4. 1 Các m ức đ ộ bố trí nhân s ự
Một tổ chức phải đảm bảo rằng số lượng nhân sự phù hợp sẵn sàng
tại bất kỳ thời điểm nhất định nào để khới với nhu cầu đang được
đặt ra cho Bộ phận Hỗ trợ Dịch vụ bởi doanh nghiệp. Tỷ lệ cuộc vọi
có thể rất biến động và thường trong cùng một ngày, tỷ lệ cuộc gọi
đến có thể đi từ rất cao đến rất thấp và lặp lại. Một tổ chức đang
hoạch định một bàn hỗ trợ mới nên cố gắng dự báo tỷ lệ cuộc gọi
đến và hồ sơ – và bố trí nhân sự một cách tương xứng. Những phân
tích mang tính thống kê về tỷ lệ các cuộc gọi đến theo những thỏa
thuận hỗ trợ hiện hành phải được tiến hành và sau đó được giám sát
một cách chặt chẽ và được điều chỉnh khi cần thiết.
Rất nhiều tổ chức sẽ nhận thấy rằng tỷ lệ cuộc gọi đạt đến đỉnh
điểm vào đầu ngày làm việc và sau đó sụt giảm một cách nhanh
chóng, có lẽ với một đợt bùng nổ khác vào đầu giờ chiều - điều này
rõ ràng là khác nhau tùy thu ộc vào hoạt động kinh doanh của tổ
chức nhưng là một mô hình thường xảy ra đối với nhiều tổ chức.
Trong những trường hợp như vậy, có thể sử dụng nhân viên bán thời
gian, nhân viên làm việc tại nhà, nhân viên hỗ trợ tuyến hai hoặc
bên thứ ba để xử lý trong những giờ cao điểm.
Các yếu tố sau đây nên được cân nhắc khi quyết định về các cấp độ
nhân sự:
 Những kỳ vọng của khách hàng dịch vụ,

 Các yêu cầu của doanh nghiệp, chẳng hạn như ngân sách, thời
gian phản hồi cuộc gọi, v.v…
 Quy mô, độ tuổi tương đối, thiết kế và độ phức tạp của Cơ sở
hạ tầng CNTT và Mục lục Dịch vụ - ví dụ, số lượng và kiểu sự
cố, mức độ giữa phần mềm thương mại tiêu chuẩn so với tùy
chỉnh đã triển khai, v.v…
 Số lượng khách hàng và người dùng cần hỗ trợ, và các yếu tố
liên quan như:
o Số lượng khách hàng và người dùng nói cùng một ngôn
ngữ khác nhau,
o Mức độ kỹ năng,
 Các kiểu Sự cố và Yêu cầu Dịch vụ (và các kiểu RFC nếu thích
hợp):
o Khoảng thời gian cần thiết cho các kiểu cuộc gọi (ví dụ,
các truy vấn đơn giản, các truy vấn ứng dụng chuyên
môn, phần cứng, v.v...),
o Yêu cầu chuyên môn địa phương hoặc bên ngoài,
o Khối lượng và các kiểu sự cố và Yêu cầu dịch vụ,
 Thời gian bảo đảm hỗ trợ cần thiết, dựa trên:
o Số giờ được bảo đảm,
o Yêu cầu hỗ trợ ngoài giờ,
o Múi giờ được bảo đảm,
o Các địa điểm được hỗ trợ (đặc biệt nếu nhân viên của Bộ
phận Hỗ trợ Dịch vụ cũng tiến hành hỗ trợ tại bàn làm
việc),
o Thời gian di chuyển giữa các địa điểm
o Hình mẫu khối lượng công việc của các yêu cầu (ví dụ,
hàng ngày, cuối tháng, v.v…),
o Các đích nhắm mục tiêu về cấp độ dịch vụ đang có (các
cấp độ đáp ứng, v.v…),
 Loại phản hồi bắt buộc:
o Điện thoại,
o E-mail/fax/hộp thư thoại/video,
o Tham gia thực tế,
o Kiểm soát/truy cập trực tuyến,
 Mức độ đào tạo cần thiết,
 Các công nghệ hỗ trợ đang có sẵn (ví dụ, hệ thống điện thoại,
các công cụ hỗ trợ từ xa, v.v…),
 Trình độ kỹ năng hiện có của nhân viên,
 Các quy trình và thủ tục được sử dụng.
Tất cả những hạng mục này cần được xem xét một cách cẩn trọng
trước khi đưa ra bất kỳ quyết định nào về cấp độ nhân sự. Điều này
cũng cần được phản ánh trong các cấp độ tài liệu được yêu cầu. Hãy
nhớ rằng dịch vụ càng tốt thì doanh nghiệp càng sử dụng nhiều.
Một số các công cụ sẵn có để giúp xác định số lượng nhân viên thích
hợp cho Bộ phận Hỗ trợ Dịch vụ. Các công cụ mô hình hóa khối
lượng công việc này phụ thuộc vào ‘kiến thức cục bộ’ chi tiết của tổ
chức chẳng hạn như khối lượng và hình mẫu của các cuộc gọi, dịch
vụ và biên dạng người dùng, v.v…
6.2.4. 2 Các c ấp độ k ỹ năng
Một tổ chức phải quyết định về mức độ và phạm vi kỹ năng mà tổ

chức yêu cầu đối với nhân viên Bộ phận Hỗ trợ Dịch vụ của mình -
và sau đó đảm bảo rằng những kỹ năng này luôn sẵn sàng vào
những thời điểm thích hợp.
Có thể có nhiều lựa chọn kỹ năng khác nhau, chỉ bắt đầu từ một
dịch vụ ‘ghi nhật ký cuộc gọi’ - nơi nhân viên chỉ cần các kỹ năng kỹ
thuật rất cơ bản - đến ngay Bộ phận Hỗ trợ Dịch vụ ‘kỹ thuật’ nơi
hầu hết những nhân viên có kỹ thuật tốt nhất của tổ chức được sử
dụng. Trong trường hợp trước, sẽ có tỷ lệ xử lý cao nhưng tỷ lệ giải
quyết thấp, trong khi trong trường hợp sau, điều này sẽ được đảo
ngược lại.
Quyết định về cấp độ kỹ năng cần thiết thường sẽ được định hướng
bởi thời gian giải quyết được nhắm mục tiêu (đã được thống nhất
với doanh nghiệp và được nắm bắt trong các mục tiêu mức dịch vụ),
mức độ phức tạp của các hệ thống được hỗ trợ và ‘số tiền doanh
nghiệp đang chuẩn bị chi trả’.
Có một mối tương quan chặt chẽ giữa các mục tiêu và chi phí ứng
phó và giải quyết - nói chung, thời gian đích nhắm mục tiêu càng
ngắn, chi phí càng cao vì cần nhiều nguồn lực hơn.
Mặc dù có thể có những trường hợp khi sự phụ thuộc hoặc tầm quan
trọng của doanh nghiệp khiến một bộ phận có kỹ thuật cao trở thành
điều bắt buộc nhưng phương pháp tiếp cận tối ưu và hiệu quả nhất
về chi phí nói chung là có một đường dây hỗ trợ đầu tiên 'ghi nhật
ký cuộc gọi' thông qua Bộ phận Hỗ trợ Dịch vụ, cùng với sự leo
thang nhanh chóng và hiệu quả chuyển đến cho các nhóm giải quyết
tuyến thứ hai và tuyến thứ ba có kỹ năng hơn, nơi các nhân viên có
kỹ năng có thể được tập trung và sử dụng một cách hiệu quả hơn
(xem Quản lý Sự cố, phần 4.2, để biết thêm chi tiết và hướng dẫn về
các cơ cấu hỗ trợ đầu cuối). Tuy nhiên, điểm xuất phát cơ bản này
có thể được cải thiện theo thời gian bằng cách cung cấp cho nhân
viên tuyến đầu một nền tảng kiến thức hiệu quả, các tập lệnh kịch
bản chẩn đoán và các công cụ hỗ trợ đuợc tích hợp (bao gồm cả
CMS), cũng như đào tạo và nhận thức liên tục, để tỷ lệ giải quyết ở
tuyến đầu có thể dần dần được tăng lên.
Điều này cũng có thể đạt được bằng cách bố trí nhân viên tuyến hai
tại Bộ phận Hỗ trợ Dịch vụ, tạo ra một cấu trúc hai-cấp (two-tier)
một cách hiệu quả. Điều này có lợi thế là khiến cho nhân viên cấp
hai sẵn sàng để giúp giải quyết các khoảng thời gian cao điểm của
các cuộc gọi và đào tạo thêm nhân viên cấp dưới, và nó thường sẽ
tăng tỷ lệ giải quyết ngay tại cuộc gọi đầu tiên. Tuy nhiên, nhân
viên tuyến hai thường có nhiệm vụ nằm bên ngoài Bộ phận Hỗ trợ
Dịch vụ - dẫn đến việc các danh sách phân công phải được quản lý
hoặc các vị trí nhân viên tuyến hai bị trùng lặp. Ngoài ra, việc phải
đối phó với các cuộc gọi thông thường có thể làm giảm động lực của
những nhân viên có kinh nghiệm hơn. Một nhược điểm tiềm ẩn nữa
là Bộ phận Hỗ trợ Dịch vụ trở nên thực sự tốt trong việc giải quyết
các cuộc gọi, trong khi thay vào đó, nhân viên tuyến hai nên tập
trung vào việc loại bỏ nguyên nhân gốc rễ.
Một yếu tố khác cần xem xét khi quyết định các yêu cầu về kỹ năng
cho nhân viên Bộ phận Hỗ trợ Dịch vụ là mức độ tùy chỉnh hoặc
chuyên môn hóa của các dịch vụ được hỗ trợ. Các dịch vụ đã được
tiêu chuẩn hóa đòi hỏi ít kiến thức cụ thể hơn để cung cấp sự hỗ trợ
có chất lượng cho khách hàng. Dịch vụ càng chuyên biệt thì càng có
nhiều khả năng những kiến thức chuyên môn sẽ được yêu cầu trong
lần gọi đầu tiên.
Hãy lưu ý rằng tỷ lệ giải quyết tại tuyến đầu có thể được giảm thiểu
bằng Quản lý Sự cố hiệu quả, điều này vốn sẽ giảm một số sự cố lặp
lại và đơn giản hơn. Trong những trường hợp như vậy, mặc dù tỷ lệ
giải quyết có vẻ đang giảm xuống, nhưng chất lượng dịch vụ tổng
thể sẽ được cải thiện bằng cách hoàn toàn loại bỏ nhiều sự cố. Mặc
dù điều này là tốt, nhưng nếu nhân viên của Bộ phận Hỗ trợ Dịch vụ
được trả tiền khuyến khích đãi ngộ hoặc tiền thưởng cho việc giải
quyết cuộc gọi đầu tiên, thì điều đó có thể gây tai hại cho tinh thần
(của nhân viên – người dịch) và hiệu quả của quy trình, trừ khi
ngưỡng tiền thưởng được xem xét.
Những cải thiện trong thời gian/tỷ lệ giải quyết không nên diễn ra
một cách tình cờ, mà thay vào đó nên là một phần của Chương trình
Cải tiến Dịch vụ tiếp diễn (xem ấn phẩm Liên tục Cải tiến Dịch vụ để
biết thêm chi tiết).
Khi các cấp độ kỹ năng cần thiết đã được xác định, có một nhiệm vụ
liên tục để đảm bảo rằng Bộ phận Hỗ trợ Dịch vụ được vận hành
theo cách mà các nhân viên cần thiết có được và duy trì các kỹ năng
cần thiết - và rằng nhân viên với sự cân bằng kỹ năng phù hợp đang
làm nhiệm vụ tại thời điểm thích hợp để tính nhất quán được duy trì.
Điều này sẽ liên quan đến một chương trình đào tạo và nâng cao
nhận thức liên tục bao gồm:
 Kỹ năng giao tiếp giữa các cá nhân, chẳng hạn như kỹ năng
điện thoại, kỹ năng giao tiếp, lắng nghe tích cực và đào tạo
chăm sóc khách hàng.
 Nhận thức về doanh nghiệp: kiến thức cụ thể về các lĩnh vực
kinh doanh của tổ chức, các động cơ (kinh doanh), cấu trúc,
các ưu tiên, v.v…
 Nhận thức về dịch vụ về tất cả các dịch vụ CNTT then chốt của
tổ chức đang được hỗ trợ.
 Nhận thức kỹ thuật (và đào tạo kỹ thuật sâu hơn ở mức độ
thích hợp, tùy thuộc vào tỷ lệ giải quyết được tìm kiếm).
 Tùy thuộc vào mức độ hỗ trợ được cung cấp, một số kỹ năng
chẩn đoán (ví dụ, Kepner và Tregoe).
 Các công cụ và kỹ thuật hỗ trợ.
 Đào tạo nâng cao nhận thức và hướng dẫn về các hệ thống và
công nghệ mới, trước khi chúng được giới thiệu.
 Các quy trình và thủ tục (đặc biệt nhất là Quản lý Sự cố, Quản
lý Thay đổi và Quản lý Cấu hình - và một cái nhìn tổng quan về
tất cả các quy trình và thủ tục ITSM).
 Các kỹ năng thông thường để đảm bảo nhập các sự cố hoặc chi
tiết Yêu cầu Dịch vụ một cách nhanh chóng và chính xác.
Để những chương trình như vậy đạt được hiệu quả, các yêu cầu và
mức độ kỹ năng nên được đánh giá một cách định kỳ và các hồ sơ
đào tạo được duy trì.
Việc xây dựng cẩn thận các lịch trình hoặc luân chuyển nhân sự nên
được duy trì để từ đó một sự cân bằng nhất quán về kinh nghiệm
của nhân viên và các mức kỹ năng thích hợp được thể hiện trong
mọi giai đoạn hoạt động quan trọng. Sẽ không đủ nếu chỉ có đúng
số lượng nhân viên đang túc trực – cũng cần phải có sự kết hợp
chính xác của các kỹ năng.
6.2.4. 3 Đào t ạ o
Một điều cực kỳ quan trọng là tất cả nhân viên của Bộ phận Hỗ trợ
Dịch vụ phải được đào tạo đầy đủ trước khi họ được triệu tập trở
thành nhân viên của Bộ phận Hỗ trợ Dịch vụ. Một chương trình giới
thiệu chính thức nên được thực hiện bởi mọi nhân viên mới, nội
dung chính xác của chương trình này sẽ thay đổi tùy thuộc vào cấp
độ kỹ năng hiện có và kinh nghiệm của người mới được tuyển dụng,
nhưng có khả năng bao gồm nhiều kỹ năng cần thiết như đã được
mô tả ở trên.
Khi có thể, một chương trình nâng cao nhận thức về kinh doanh, bao
gồm cả những thời gian ngắn biệt phái vào các lĩnh vực kinh doanh
then chốt nên được cung cấp cho những nhân viên mới chưa có đủ
mức độ nhận thức về lĩnh vực kinh doanh này.
Khi bắt đầu làm việc tại Bộ phận Hỗ trợ Dịch vụ, ban đầu nhân viên
mới nên ‘theo sát’ nhân viên có kinh nghiệm - ngồi với họ và lắng
nghe các cuộc gọi - trước khi bắt đầu tự nhận cuộc gọi với một
người cố vấn lắng nghe và có thể can thiệp và cung cấp sự hỗ trợ
khi cần thiết. Người cố vấn ban đầu nên xem xét từng cuộc gọi với
học viên sau khi cuộc gọi kết thúc để rút ra bất kỳ bài học nào. Tần
suất đánh giá như vậy nên giảm dần khi kinh nghiệm và sự tự tin
tăng lên nhưng người cố vấn vẫn phải sẵn sàng hỗ trợ liên tục ngay
cả khi thực tập sinh đã đến giai đoạn tự mình thực hiện công việc.
Người cố vấn có thể cần được đào tạo về cách cố vấn. Kinh nghiệm
và kỹ năng kỹ thuật của Bộ phận Hỗ trợ Dịch vụ không phải là yêu
cầu duy nhất cho việc cố vấn. Kỹ năng chuyển giao kiến thức hiệu
quả và khả năng giảng dạy mà không trịch thượng hay đe dọa đều
có tầm quan trọng như nhau.
Một chương trình sẽ là cần thiết để giữ cho kiến thức của nhân viên
Bộ phận Dịch vụ luôn được cập nhật - và giúp họ hiểu biết về những
phát triển, dịch vụ và công nghệ mới. Thời lượng của các sự kiện
như vậy là rất quan trọng để không ảnh hưởng đến các nhiệm vụ
thông thường. Rất nhiều Bộ phận Hỗ trợ Dịch vụ nhận thấy rằng tốt
nhất nên tổ chức các ‘hướng dẫn’ ngắn trong những thời điểm yên
tĩnh khi nhân viên ít có kh ả năng được cần đến để xử lý cuộc gọi.
Lưu ý: Cũng cần đầu tư vào việc phát triển chuyên môn nghiệp vụ
của nhân viên Bộ phận Hỗ trợ Dịch vụ. Việc cố vấn nội bộ và bám
sát nhân viên hỗ trợ tuyến hai và tuyến ba là một khởi đầu tốt,
nhưng Bộ phận Hỗ trợ Dịch vụ được hưởng lợi tốt nhất từ một
chương trình phát triển nhân viên chính thức. Cam kết của tổ chức
đối với việc phát triển nghề nghiệp giúp lan tỏa cảm giác hoàn thành
và cơ hội cho nhân viên. Điều này thường dẫn đến sự đổi mới trong
hoạt động của Bộ phận Hỗ trợ Dịch vụ (chẳng hạn như các dịch vụ
chuyên biệt), đến lượt mình sẽ thúc đẩy hiệu quả hoạt động ở mọi
cấp độ hỗ trợ. Nó giúp xây dựng các kỹ năng có thể được sử dụng
trong vai trò hiện tại của họ cũng như một bước khởi đầu trongquá
trình đào tạo cho một vai trò mới. Mặc dù việc phát triển năng lực
cốt lõi của họ trong vai trò hiện tại là rất quan trọng nhưng việc có
một lộ trình nghề nghiệp rõ ràng và công nhận các yêu cầu và nhu
cầu phát triển trong tương lai cũng là điều rất quan trọng.
6.2.4. 4 Xoay vòng nh ân s ự
Một điều cũng rất quan trọng là tất cả các Nhà quản lý CNTT phải
nhận ra tầm quan trọng của Bộ phận Hỗ trợ Dịch vụ và các nhân
viên làm việc tại đó, và dành sự quan tâm đặc biệt cho bộ phận này.
Bất kỳ sự mất mát đáng kể nào về nhân viên đều có thể gây xáo
trộn và dẫn đến sự không nhất quán của dịch vụ - vì vậy cần phải
thực hiện những nỗ lực để khiến cho Bộ phận Hỗ trợ Dịch vụ trở
thành một nơi hấp dẫn để làm việc.
Những cách thức có thể được thực hiện bao gồm sự công nhận đúng
đắn về vai trò với các gói phần thưởng để ghi nhận điều này, các bài
tập xây dựng nhóm, luân chuyển nhân viên sang các hoạt động khác
(dự án, hỗ trợ tuyến hai, v.v...).
Bộ phận Hỗ trợ Dịch vụ thường có thể được sử dụng như một bước
đệm cho các vai trò kỹ thuật hoặc giám sát/quản lý khác. Nếu điều
này được thực hiện, cần phải cẩn trọng để đảm bảo rằng việc lập kế
hoạch kế nhiệm phù hợp được thực hiện để Bộ phận Hỗ trợ Dịch vụ
không mất tất cả kiến thức chuyên môn chính của mình trong bất kỳ
lĩnh vực trong cùng một thời điểm. Ngoài ra, những tài liệu tốt và
đào tạo chéo cũng có thể làm giảm thiểu rủi ro này.
6.2.4. 5 Ngư ờ i dùng S iêu c ấ p

Rất nhiều tổ chức thấy hữu ích khi bổ nhiệm hoặc chỉ định một số
‘Người dùng Siêu cấp’ trong toàn bộ cộng đồng người dùng, để đóng
vai trò như những điểm liên lạc với CNTT nói chung và đặc biệt là
Bộ phận Hỗ trợ Dịch vụ.
Những Người dùng Siêu cấp có thể được đào tạo và nâng cao nhận
thức bổ sung và được sử dụng như một ống dẫn cho luồng thông tin
giao tiếp theo cả hai chiều. Họ có thể được yêu cầu lọc các yêu cầu
và các vấn đề do cộng đồng người dùng đưa ra (thậm chí, trong một
số trường hợp, cũng có thể có các yêu cầu hoặc sự cố do Người
dùng Siêu cấp đưa ra) – điều này có thể giúp ngăn chặn ‘cơn bão
các vấn đề’ khi một dịch vụ hoặc thành phần then chốt bị lỗi, gây
ảnh hưởng đến rất nhiều người dùng khác.
Họ cũng có thể được sử dụng để phân tầng những thông tin từ Bộ

phận Hỗ trợ Dịch vụ gửi ra bên ngoài đến cộng đồng người dùng cụ
bộ của họ, vốn có thể rất hữu ích trong việc phổ biến các chi tiết
dịch vụ cho mọi người dùng một cách nhanh chóng.
Một điều quan trọng cần lưu ý là những Người dùng Siêu cấp nên ghi
nhật ký mọi cuộc gọi mà họ đã xử lý, không chỉ những cuộc gọi mà
họ đã chuyển sang cho CNTT. Điều này sẽ có nghĩa là truy cập đến,
và việc đào tạo về cách sử dụng, các công cụ ghi nhật ký Sự cố.
Việc này sẽ giúp đo lường hoạt động của Người dùng Siêu cấp và
đồng thời đảm bảo rằng vị trí của họ không bị lạm dụng. Ngoài ra,
nó cũng sẽ đảm bảo rằng lịch sử vô giá liên quan đến các sự cố và
chất lượng dịch vụ không bị mất đi.
Người dùng Siêu cấp cũng có khả năng được tham gia vào:
 Đào tạo nhân viên cho những người dùng trong khu vực của
họ,
 Cung cấp sự hỗ trợ cho những sự cố nhỏ hoặc thực hiện các
yêu cầu đơn giản,
 Liên quan đến các bản phát hành và ra mắt mới.
Người dùng Siêu cấp không nhất thiết phải cung cấp sự hỗ trợ cho
toàn bộ CNTT. Trong nhiều trường hợp, Người dùng Siêu cấp sẽ chỉ
cung cấp sự hỗ trợ cho một ứng dụng, một mô-đun hoặc khu vực
đơn vị kinh doanh cụ thể. Với tư cách là người dùng doanh nghiệp,
Người dùng Siêu cấp thường có kiến thức chuyên sâu về cách thức
mà các quy trình nghiệp vụ then chốt vận hành và cách mà các dịch
vụ hoạt động trong thực tế như thế nào. Đây là kiến thức rất hữu
ích cần được chia sẻ với Bộ phận Hỗ trợ Dịch vụ để có thể cung cấp
các dịch vụ chất lượng cao hơn trong tương lai.
Nên lưu ý rằng một sự cam kết chắc chắn cần phải có từ phía Người
dùng Siêu cấp tiềm năng và cụ thể là cấp quản lý của họ, rằng họ sẽ
dành thời gian và sự quan tâm để thực hiện vai trò này trước khi bắt
đầu tuyển chọn và đào tạo.
Một Người dùng Siêu cấp, mặc dù là một tương tác có giá trị đối với
doanh nghiệp và Bộ phận Hỗ trợ Dịch vụ, cần phải được đào tạo
thích hợp, có trách nhiệm và tiêu chuẩn đạo đức. Người dùng Siêu
cấp có thể dễ bị lạm dụng nếu vai trò, trách nhiệm của họ và quy
trình quản lý những điều này không được thông báo rõ ràng cho
người dùng. Một điều bắt buộc là Người dùng Siêu cấp không được
coi là người thay thế hoặc là một phương tiện để vượt qua Bộ phận
Hỗ trợ Dịch vụ.
6.2.5 Các ch ỉ s ố c ủ a B ộ ph ậ n H ỗ trợ Dịch v ụ

Các chỉ số nên được thiết lập để hiệu suất của Bộ phận Hỗ trợ Dịch
vụ có thể được đánh giá theo định kỳ. Đây là điều rất quan trọng để
đánh giá sức khỏe, sự trưởng thành, tính hiệu quả, hiệu suất và bất
kỳ cơ hội nào để cải thiện hoạt động của Bộ phận Hõ trợ Dịch vụ.
Các chỉ số đối với hiệu suất của Bộ phận Hỗ trợ Dịch vụ phải thực tế
và được lựa chọn một cách cẩn thận. Điều phổ biến là người ta
thường chọn những chỉ số dễ dàng sẵn có và đó dường như là một
dấu hiệu khả thi về hiệu suất, tuy nhiên, điều này có thể gây sự
hiểu lầm. Ví dụ, tổng số cuộc gọi mà Bộ phận Hỗ trợ Dịch vụ nhận
được tự bản thân nó không phải là dấu hiệu cho thấy hiệu suất tốt
hay kém và trên thực tế có thể do các sự kiện hoàn toàn nằm ngoài
tầm kiểm soát của Bộ phận dịch vụ gây ra - ví dụ, một khoảng thời
gian đặc biệt bận rộn đối với tổ chức, hoặc việc phát hành phiên bản
mới của hệ thống công ty lớn.
Một sự gia tăng trong số lượng các cuộc gọi đến Bộ phận Hỗ trợ
Dịch vụ có thể chỉ ra các dịch vụ có độ tin cậy kém hơn trong
khoảng thời gian đó, nhưng cũng có thể chỉ ra sự tin tưởng của
người dùng vào Bộ phận Hỗ trợ Dịch vụ đang dần hoàn thiện đã gia
tăng, dẫn đến khả năng cao hơn là người dùng sẽ tìm kiếm sự hỗ trợ
thay vì cố gắng ứng phó một mình. Để loại chỉ số này trở nên đáng
tin cậy hơn để đưa ra kết luận, việc so sánh thêm với các giai đoạn
trước đó đối với bất kỳ cải tiến của Bộ phận Hỗ trợ Dịch vụ nào đã
được triển khai kể từ đường cơ sở đo lường cuối cùng hoặc những
thay đổi về độ tin cậy của dịch vụ, các vấn đề, v.v… để xác định
nguyên nhân thực sự của sự gia tăng, là điều cần thiết.
Do đó, việc phân tích sâu hơn và các số liệu chi tiết hơn là cần
thiết, và phải được kiểm tra trong một khoảng thời gian. Chúng sẽ
bao gồm số liệu thống kê xử lý cuộc gọi đã được đề cập trước đây
trong điện thoại, và ngoài ra:
 Tỷ lệ giải quyết tại tuyến đầu: tỷ lệ phần trăm cuộc gọi đã

được giải quyết tại tuyến đầu mà không cần chuyển đến các
nhóm hỗ trợ khác. Đây là con số thường được trích dẫn bởi các
tổ chức như là thước đo chủ yếu về hiệu suất của Bộ phận Hỗ
trợ Dịch vụ - và được sử dụng cho mục đích so sánh với hiệu
suất của các Bộ phận Hỗ trợ Dịch vụ khác - nhưng cần thận
trọng khi đưa ra bất kỳ so sánh nào. Để có độ chính xác cao
hơn và các so sánh hợp lệ hơn, chỉ số này có thể được chia nhỏ
hơn như sau:
o Tỷ lệ phần trăm cuộc gọi được giải quyết trong lần liên hệ
đầu tiên với Bộ phận Hỗ trợ Dịch vụ, nghĩa là trong khi
người dùng vẫn đang trong cuộc gọi để báo cáo cuộc gọi,
o Tỷ lệ phần trăm các cuộc gọi đã được tự giải quyết bởi
nhân viên Bộ phận Hỗ trợ Dịch vụ mà không cần phải tìm
kiếm sự hỗ trợ sâu hơn từ các nhóm khác. Lưu ý: một số
bàn sẽ chọn đồng-định vị hoặc nhúng nhân viên tuyến hai
có kỹ thuật cao hơn với Bộ phận Hỗ trợ Dịch vụ (xem
Quản lý Sự cố để biết thêm chi tiết). Trong những trường
hợp như vậy, điều quan trọng là khi so sánh cũng phải
tách ra (i) Tỷ lệ phần trăm được giải quyết bởi bản thân
nhân viên Bộ phận Hỗ trợ Dịch vụ; và (ii) Tỷ lệ phần trăm
được giải quyết bởi nhân viên Bộ phận Dịch vụ tuyến đầu
và nhân viên hỗ trợ tuyến hai cộng lại,
 Thời gian trung bình để giải quyết một sự cố (khi được giải
quyết ở tuyến đầu),
 Thời gian trung bình để leo thang một sự cố (khi việc giải
quyết tại tuyến đầu là không khả thi),
 Chi phí Bộ phận Hỗ trợ Dịch vụ trung bình để xử lý một sự cố.
Có hai chỉ số nên được xem xét ở đây:
o Tổng chi phí của Bộ phận Hỗ trợ Dịch vụ chia cho số
lượng các cuộc gọi. Điều này sẽ cung cấp một con số
trung bình hữu ích như một chỉ số và cho mục đích lập kế
hoạch nhưng không thể hiện một cách chính xác chi phí
tương đối của các loại cuộc gọi khác nhau,
o Bằng cách tính toán tỷ lệ phần trăm thời lượng cuộc gọi
trên bàn làm việc tổng thể và tính ra chi phí cho mỗi phút
(tổng chi phí trong khoảng thời gian chia cho tổng số
phút thời lượng của cuộc gọi), điều này có thể được sử
dụng để tính toán chi phí cho các cu ộc gọi riêng lẻ và đưa
ra một giá trị chính xác hơn.
Bằng cách đánh giá kiểu sự cố cùng với thời lượng của các
cuộc gọi, một bức tranh chi tiết về chi phí cho mỗi cuộc gọi
theo kiểu phát sinh và đưa ra ch ỉ báo về những kiểu sự cố có
khuynh hướng tiêu tốn chi phí hơn để giải quyết và những mục
tiêu tiềm năng để cải thiện.
 Tỷ lệ phần trăm các bản cập nhật cho khách hàng hoặc người
dùng đã được tiến hành trong phạm vi đích nhắm mục tiêu về
thời gian, như được xác định trong các đích nhắm mục tiêu
SLA,
 Thời gian trung bình để xem xét và đóng một cuộc gọi đã được
giải quyết,
 Số lượng các cuộc gọi được chia theo thời gian trong ngày và
ngày trong tuần, được kết hợp với chỉ số thời gian cuộc gọi
trung bình, là tối quan trọng trong việc xác định số lượng nhân
viên cần thiết.
Thông tin chi tiết tổng quát hơn về các chỉ số và cách thức mà
chúng nên được sử dụng như thế nào để thúc đẩy chất lượng dịch vụ
được đề cập trong ấn phẩm Liên tục Cải tiến Dịch vụ.
6.2.5. 1 Các kh ả o sát m ức đ ộ hài l òng c ủ a khách

hàng/ngư ờ i dùng
Ngoài việc theo dõi các thước đo 'cứng' về hiệu suất của Bộ phận Hỗ
trợ Dịch vụ (thông qua các chỉ số đã được mô tả ở trên), một điều
cũng rất quan trọng là đánh giá các thước đo 'mềm' - chẳng hạn như
mức độ cảm nhận của khách hàng và người dùng khi cuộc gọi của họ
đã được trả lời, cho dù họ cảm thấy người điều hành Bộ phận Hỗ trợ
Dịch vụ lịch sự và chuyên nghiệp hay không, liệu họ có tạo được
niềm tin cho người dùng hay không.
Loại thước đo này tốt nhất nên được lấy từ chính bản thân người
dùng. Việc này có thể được thực hiện như một phần của cuộc khảo
sát sự hài lòng của khách hàng/người dùng rộng rãi hơn bao gồm
toàn bộ CNTT hoặc có thể được nhắm mục tiêu một cách cụ thể vào
các vấn đề của Bộ phận Hỗ trợ Dịch vụ.
Một cách hiệu quả để đạt được điều này là thông qua một cuộc khảo
sát qua điện thoại, trong đó một Người vận hành Bộ phận Hỗ trợ
Dịch vụ độc lập hoặc Người giám sát gọi lại cho một tỷ lệ nhỏ người
dùng ngay sau khi sự cố của họ được giải quyết, để hỏi những câu
hỏi cụ thể cần thiết.
Cần chú ý để giữ số lượng câu hỏi ở mức tối thiểu (tối đa là năm
đến sáu câu hỏi) để người dùng sẽ có thời gian hợp tác. Ngoài ra,
các câu hỏi khảo sát nên được thiết kế để người dùng hoặc khách
hàng biết được những lĩnh vực hoặc chủ đề nào của câu hỏi đang
được đề cập và sự cố hoặc dịch vụ nào đang được đề cập đến. Bộ
phận Hỗ trợ Dịch vụ phải hành động dựa trên mức độ hài lòng thấp
và bất kỳ phản hồi nào nhận được.
Để cho phép những so sánh đầy đủ, cùng một tỷ lệ cuộc gọi giống
nhau nên được chọn trong mỗi khoảng thời gian và chúng phải được
thực hiện một cách chặt chẽ bất chấp bất kỳ áp lực thời gian nào
khác.
Các khảo sát là một lĩnh vực phức tạp và chuyên biệt, đòi hỏi một
hiểu biết sâu sắc về các kỹ thuật thống kê và khảo sát. Ấn phẩm này
sẽ không cố gắng cung cấp một cái nhìn tổng quan về tất cả chúng,
tuy nhiên, một tóm lược về một vài trong số những kỹ thuật đã được
sử dụng một cách rộng rãi được liệt kê trong Bảng 6.1.
Kỹ thuật/Công cụ Ưu điểm Khuyết điểm
 Mọi người có thể cảm thấy bị áp
Khảo sát sau-cuộc gọi  Tỷ lệ hồi đáp cao vì người gọi đang sẵn
lực khi tiến hành khảo sát, dẫn
sàng trên điện thoại.
Người gọi được yêu cầu giữ điện
đến trải nghiệm dịch vụ tiêu
 Người gọi được khảo sát ngay tức khắc sau
thọa sau cuộc gọi và được yêu
cực.
cuộc gọi, do đó những trải nghiệm của họ
cầu xếp hạng dịch vụ mà họ đã
 Người khảo sát được cọi là một
vẫn còn mới.
được cung cấp.
phần của Bộ phận Hỗ trợ Dịch
vụ được khảo sát, vốn có thể
không khuyến khích các câu trả
lời cởi mở.
Khảo sát điện thoại đi ra  Tỷ lệ hồi đáp cao hơn vì người gọi được  Phương pháp này có thể bị xem
phỏng vấn trực tiếp. là xâm phạm, nếu như cuộc gọi
Khách hàng và người dùng đã
 Các thể loại khách hàng hoặc người dùng cụ làm gián đoạn công việc của
từng sử dụng Bộ phận Hỗ trợ Dịch
thể có thể được nhắm mục tiêu để phản hồi người dùng và khách hàng.
vụ trước đây được liên hệ một
(ví dụ, người đã yêu cầu một dịch vụ cụ
khoảng thời gian sau khi họ trải  Khảo sát được tiến hành một
thể, hoặc người đã trải qua một sự gián
nghiệm với Bộ phận Hỗ trợ Dịch khoảng thời gian sau khi người
đoạn đối với một dịch vụ đặc biệt.
vụ. dùng hoặc khách hàng sử dụng
Bộ phận Hỗ trợ Dịch vụ, do đó
nhận thức của họ có thể đã thay
đổi.
 Các cuộc phỏng vấn sẽ tiêu tốn
Các cuộc phỏng vấn cá nhân  Người phỏng vấn có khả năng quan sát
thời gian của cả người phỏng
được những dấu hiệu phi ngôn ngữ cũng
Khách hàng và người dùng được
vấn lẫn ngươi trả lời.
như nghe được những gì mà người dùng
phỏng vấn một cách cá nhân bởi
 Người dùng và khách hàng có
người thực hiện khảo sát. Điều hoặc khách hàng đang nói. thể chuyển hướng các cuộc
này đặc biệt hiệu quả đối với  Người dùng và khách hàng cảm thấy mức phỏng vấn thành những phiên
người dùng hoặc khách hàng sử chú ý cá nhân lớn hơn và cảm giác rằng các phàn nàn.
dụng Bộ phận Hỗ trợ Dịch vụ một câu trả lời của họ đang được thực hiện một
cách toàn diện hoặc những người cách nghiêm túc.
đã có một trải nghiệm rất tiêu
cực.
 Mọi người có thể không thể hiện
Các cuộc phỏng vấn nhóm  Một lượng lớn người dùng và khách hàng có
bản thân một cách thoải mái
thể được phỏng vấn (đồng thời).
Khách hàng và người dùng được
trước mặt đồng nghiệp hoặc
 Các câu hỏi mang tính phổ quát hơn và do
phỏng vấn theo những nhóm nhỏ.
quản lý của họ.
đó, nhất quán hơn giữa các cuộc phỏng
Điều này rất rốt cho việc thu thập
 Ý kiến của mọi người có thể dễ
vấn.
những ấn tượng chung và cho
dàng thay đổi bởi những nguời
việc xác định xem liệu có một nhu
khác trng cuộc phỏng vấn.
cầu thay đổi những khía cạnh
nhất định của Bộ phận Hỗ trợ
Dịch vụ hay không, ví dụ, giờ
dịch vụ hoặc vị trí.
 Các cuộc khảo sát qua đường
Khảo sát qua bưu điện/email  Toàn bộ hoặc những khách hàng hoặc người
bưu điện gây tốn kém nguồn
dùng cụ thể có thể được nhắm mục tiêu.
Các câu hỏi khảo sát được gửi
nhân lực để xử lý.
 Các khảo sát qua bưu điện có thể ẩn danh,
qua thư cho một tập hợp người
 Tỷ lệ phần trăm những người
cho phép mọi người thể hiện bản thân một
dùng hoặc khách hàng được nhắm
phản hồi đối với các cuộc khảo
cách thoải mái hơn.
mục t iêu. Họ được yêu cầu trả
sát qua đường bưu điện có
 Các khảo sát qua email không ẩn danh,
lời phản hòi của họ bằng email.
khuynh hướng thấp.
nhưng có thể được tạo ra bằng cách sử
dụng các hình thức tự động hóa để tạo ra  Diễn giải sai câu hỏi có thể tác
sự thoải mái và dễ dàng cho người dùng để động đến kết quả.
họ trả lời và gia tăng khả năng nó (cuộc
khảo sát) sẽ được hoàn tất.
 Tỷ lệ người tham gia khảo sát là
Khảo sát trực tuyến  Đối tượng tiềm năng của những khảo sát
không thể dự đoán trước được.
loại này là khá lớn.
Các câu hỏi được đăng trên một
 Những người tham gia khảo sát có thể hoàn
trang web và người dùng và
thành câu hỏi theo thời gian của họ.
khách hàng được khuyến khích
 Các liên kết trên những trang web nổi tiếng
thông qua email hoặc các đường
là người nhắc nhở tuyệt vời mà không gây
liên kết từ một trang web nổi
ra sự xâm phạm.
tiếng để tham gia một cuộc khảo
sát.
Bảng 6.1 – Các kỹ thuật và công cụ khảo sát
6.2.6 Thuê n goài B ộ ph ậ n H ỗ tr ợ Dịc h v ụ
Quyết định thuê ngoài là một vấn đề mang tính chiến lược đối với
các nhà quản lý cấp cao – và được xác định chi tiết trong các ấn
phẩm Chiến lược Dịch vụ và Thiết kế Dịch vụ. Rất nhiều hướng dẫn
trong phần này không phải là độc đáo đối với Bộ phận Hỗ trợ Dịch
vụ và có thể được áp dụng cho bất kỳ chức năng, lĩnh vực hỗ trợ
hoặc dịch vụ được thuê ngoài nào (hoặc nằm ngoài nhiệm vụ).
Bất kể lý do là gì, hoặc mức độ của, hợp đồng thuê ngoài, điều cực
kỳ quan trọng là tổ chức vẫn chịu trách nhiệm đối với các hoạt động
và các dịch vụ đã được cung cấp bởi Bộ phận Hỗ trợ Dịch vụ. Cuối
cùng, tổ chức chịu trách nhiệm cho những kết quả từ quyết định
(thuê ngoài) và phải xác định những dịch vụ nào mà nhà cho thuê
ngoài đang cung cấp, chứ không phải ngược lại.
Nếu lộ tuyến thuê ngoài được lựa chọn, có một số biện pháp bảo vệ
được cần đến để đảm bảo rằng Bộ phận Hỗ trợ Dịch vụ được thuê
ngoài cộng tác một cách hiệu quả và hiệu suất với các nhóm và bộ
phận CNTT khác của tổ chức và rằng kiểm soát Quản lý Dịch vụ từ
đầu-đến-cuối được duy trì (điều này đặc biệt quan trọng cho những
tổ chức đang tìm chứng chỉ ISO/IEC 20000 vì biện pháp kiểm soát
quản lý tổng thể phải được chứng minh). Một số trong những biện
pháp bảo vệ này được nêu ra dưới đây.
6.2.6. 1 Các công c ụ và th ủ t ục p h ổ biế n

Bộ phận Hỗ trợ Dịch vụ không chịu trách nhiệm về tất cả các quy
trình và thủ tục mà nó khởi đầu. Ví dụ, một Yêu cầu Dịch vụ được Bộ
phận Hỗ trợ Dịch vụ nhận được nhưng yêu cầu được thực hiện bởi
nhóm Vận hành CNTT nội bộ.
Nếu Bộ phận Hỗ trợ Dịch vụ được thuê bên ngoài, cần phải cẩn trọng
để đảm bảo rằng các công cụ này nhất quán với những công cụ vẫn
đang được sử dụng trong tổ chức khách hàng. Thuê ngoài thường
được coi là một cơ hội để thay thế các công cụ lỗi thời hoặc không
phù hợp, chỉ khi nhận thấy rằng có những vấn đề về tích hợp nghiêm
trọng giữa công cụ mới với các công cụ và quy trình cũ.
Vì lý do này, điều quan trọng là phải đảm bảo rằng các vấn đề này
được nghiên cứu một cách đúng đắn và các yêu cầu của khách hàng
được định rõ và xác định phạm vi đầy đủ trước khi ký kết hợp đồng
thuê ngoài. Các công cụ Bộ phận Hỗ trợ Dịch vụ không chỉ phải hỗ
trợ Bộ phận Hỗ trợ Dịch vụ thuê ngoài mà còn phải hỗ trợ cho các
quy trình và yêu cầu nghiệp vụ của tổ chức khách hàng.
Lý tưởng nhất là bộ phận thuê ngoài nên sử dụng cùng các công cụ
và quy trình (hoặc tối thiểu là các công cụ và quy trình giao tiếp) để
cho phép quy trình trôi ch ảy giữa Bộ phận Hỗ trợ Dịch vụ và các
nhóm hỗ trợ tuyến thứ hai và thứ ba.
Ngoài ra, Bộ phận Hỗ trợ Dịch vụ được thuê ngoài phải có quyền
truy cập vào:
 Tất cả mọi hồ sơ và thông tin sự cố,

 Hồ sơ Vấn đề và thông tin,
 Dữ liệu Lỗi Đã biết
 Lịch trình Thay đổi,
 Nguồn kiến thức nội bộ (đặc biệt là các chuyên gia kỹ thuật
hoặc chuyên gia ứng dụng),
 SKMS,
 CMS,
 Cảnh báo từ các công cụ giám sát.
Đây thường là một thách thức khi tích hợp các quy trình và công cụ
của một tổ chức chưa trưởng thành với những quy trình và công cụ
trong một tổ chức trưởng thành hơn. Một giả định sai lầm nhưng phổ
biến là sự trưởng thành của một tổ chức, bằng cách nào đó, sẽ dẫn
đến sự trưởng thành cao hơn ở tổ chức kia. Sự tham gia tích cực để
đảm bảo mối liên kết của các công cụ và quy trình là điều thiết yếu
đối với một quá trình chuyển tiếp suôn sẻ và quản lý liên tục các
dịch vụ giữa các tổ chức nội bộ và bên ngoài. Trong thực tế, nếu
điều này không được giải quyết trực tiếp, nó có thể gây ra sự thất
bại của hợp đồng.
Người ta cũng thường giả định một cách không chính xác rằng bằng
chứng về chất lượng và sự trưởng thành của Quản lý Dịch vụ trong
một đối tác thuê ngoài bên ngoài có th ể được đảm bảo bằng cách
nêu ra các yêu cầu trong quy trình mua sắm đối với ‘sự tuân thủ
ITIL’ và/hoặc ‘chứng nhận ISO/IEC 20000’. Những tuyên bố này có
thể chỉ ra rằng một nhà cung cấp tiềm năng sử dụng Khuôn khổ ITIL
trong việc cung cấp dịch vụ cho khách hàng của họ hoặc rằng họ đã
đạt được chứng nhận tiêu chuẩn cho các hoạt động nội bộ của họ,
nhưng điều quan trọng không kém là phải có công nghệ hỗ trợ tại
chỗ và được sử dụng để chứng minh năng lực của nhà cung cấp dịch
vụ để quản lý các dịch vụ và tương tác với các hoạt động nội bộ một
cách hài hòa. Không có tiêu chuẩn về sự tuân thủ nào đảm bảo cho
điều này và do đó các nỗ lực mua sắm nên bao gồm các truy vấn cụ
thể để đáp ứng yêu cầu này. Thông tin thêm về việc mua lại nhà
cung cấp dịch vụ thuê ngoài có thể được tìm thấy trong ấn phẩm
Thiết kế Dịch vụ.
6.2.6. 2 Các đích nh ắ m mục tiêu c ủa SLA

Các đích nhắm mục tiêu SLA đối với việc xử lý-sự cố tổng thể và
thời gian hồi đáp cần phải được thống nhất với khách hàng và giữa
mọi nhóm và bộ phận – và các đích nhắm mục tiêu OLA/UC cần phải
được phối hợp và thống nhất với các nhóm hỗ trợ riêng lẻ để từ đó
chúng có thể làm nền tảng và hỗ trợ cho các đích nhắm mục tiêu
SLA.
Các ví dụ về những điều này có thể được tìm thấy trong phần trình
bày về các chỉ số nói trên (phần 6.2.5).
6.2.6. 3 Truy ề n thông rõ rà ng

Các đường dây liên lạc giữa Bộ phận Hỗ trợ Dịch vụ được thuê ngoài
và các nhóm hỗ trợ khác cần phải hoạt động một cách hiệu quả. Việc
này có thể được trợ giúp bởi một số hoặc toàn bộ các bước dưới
đây:
 Đồng-định vị gần gũi về mặt thực tế,

 Các cuộc họp đánh giá/liên lạc định kỳ,
 Các buổi hướng dẫn đào tạo chéo giữa các nhóm và các bộ
phận,
 Những thỏa thuận ‘đối tác’ khi nhân viên của cả hai tổ chức
được kết hợp để cùng làm việc tại Bộ phận Hỗ trợ Dịch vụ,
 Các Kế hoạch Truyền thông và các đích nhắm mục tiêu hiệu
suất được ghi nhận theo một cách nhất quán trong các SLA và
UC.
Trong những trường hợp khi Bộ phận Hỗ trợ Dịch vụ được đặt ngoài
biên giới quốc gia (off-shore), không phải tất cả những biện pháp
nói trên đều khả thi. Tuy nhiên, nhu cầu về đào tạo và truyền thông
của nhân viên Bộ phận Hỗ trợ Dịch vụ vẫn là điều quan trọng, thậm
chí còn nhiều hơn nữa trong những trường hợp khi có những sự khác
biệt về ngôn ngữ và văn hóa.
Điều này sẽ được đề cập chi tiết hơn trong các ấn phẩm bổ sung của
ITIL, tuy nhiên theo quy định, các công ty cho thuê ngoài cung cấp
giải pháp Bộ phận Hỗ trợ Dịch vụ bên ngoài (off-shore) nên tính đến
những điều sau:
 Các chương trình đào tạo tập trung vào việc tìm hiểu văn hóa
của thị trường khách hàng,
 Kỹ năng ngôn ngữ - đặc biệt là sự hiểu biết về cách sử dụng
thành ngữ của ngôn ngữ trong thị trường khách hàng. Điều này
không phải để âm thanh nhân viên của Bộ phận Hỗ trợ Dịch vụ
nghe giống như người bản xứ của quốc gia của khách hàng
(kiểu thiếu chân thành đó rất nhanh chóng bị khách hàng phát
hiện), mà là để tạo điều kiện hiểu rõ hơn về khách hàng và
đánh giá tốt hơn các ưu tiên của họ,
 Các chuyến viếng thăm thường xuyên của đại diện của tổ chức
khách hàng để cung cấp ự đào tạo và phản hồi thích hợp một
cách trực tiếp cho quản lý và nhân viên của Bộ phận Hỗ trợ
Dịch vụ,
Đào tạo về cách sử dụng các công cụ và phương pháp làm việc của
tổ chức khách hàng. Điều này đặc biệt hiệu quả nếu các tài liệu đào
tạo tương tự được trình bày bởi các giảng viên giống như những tài
liệu đang được tổ chức khách hàng sử dụng.
6.2.6. 4 C hủ s ở hữu d ữ li ệu
Quyền sở hữu rõ ràng của dữ liệu do Bộ phận Hỗ trợ Dịch vụ được
thuê ngoài thu thập phải được thiết lập. Quyền sở hữu tất cả mọi dữ
liệu liên quan đến người dùng, khách hàng, Đơn vị Cấu hình bị ảnh
hưởng, dịch vụ, sự cố, Yêu cầu Dịch vụ, thay đổi, v.v... phải thuộc
về tổ chức đang đi thuê ngoài hoạt động - nhưng cả hai tổ chức sẽ
đều yêu cầu quyền truy cập vào nó.
Dữ liệu liên quan một cách cụ thể đến hiệu suất của nhân viên của
công ty thuê ngoài sẽ vẫn là tài sản của công ty đó, vốn thường bị
pháp luật ngăn cản việc chia sẻ dữ liệu với tổ chức khách hàng. Điều
này cũng có thể đúng với các dữ liệu khác được sử dụng một cách
thuần túy cho việc quản lý nội bộ của Bộ phận Hỗ trợ Dịch vụ, chẳng
hạn như số lượng nhân viên, các hoạt động tối ưu hóa, thông tin chi
phí của Bộ phận Hỗ trợ Dịch vụ, v.v…
Tất cả các yêu cầu báo cáo và các vấn đề xoay quanh quyền sở hữu
dữ liệu phải được chỉ định trong hợp đồng khung với công ty cung
cấp dịch vụ thuê ngoài.
6.3 Quản lý Kỹ thuật

Quản lý Kỹ thuật đề cập đến các nhóm, bộ phận hoặc các đội cung
cấp kiến thức chuyên môn kỹ thuật và quản lý tổng thể Cơ sở hạ
tầng CNTT.
6.3.1 Vai trò Q u ả n lý K ỹ t hu ậ t

Quản lý Kỹ thuật đóng một vai trò kép như sau:
 Là người bảo quản kiến thức và chuyên môn kỹ thuật có lên

quan đến việc quản lý Cơ sở hạ tầng CNTT. Trong vai trò này
Quản lý Kỹ thuật đảm bảo rằng những kiến thức cần thiết để
thiết kế, kiểm nghiệm, quản lý và cải thiện các dịch vụ CNTT
được xác định, phát triển và tinh chỉnh.
 Cung cấp nguồn lực thực tế để hỗ trợ cho Vòng đời ITSM.
Trong vai trò này, TT đảm bảo rằng nguồn lực được đào tạo và
triển khai một cách hiệu quả để thiết kế, xây dựng, chuyển
tiếp, vận hành và cải tiến những công nghệ cần thiết để cung
cấp và hỗ trợ cho các dịch vụ CNTT.
Bằng cách thực hiện hai vai trò này, Quản lý Kỹ thuật có thể đảm
bảo rằng tổ chức có khả năng tiếp cận đến đúng loại và trình độ
nguồn nhân lực để quản lý công nghệ và do đó, đáp ứng các mục
tiêu của doanh nghiệp. Việc xác định các yêu cầu cho những vai trò
này khởi đầu trong Chiến lược Dịch vụ và được mở rộng trong Thiết
kế Dịch vụ, được xác thực trong Chuyển tiếp Dịch vụ và được tinh
chỉnh trong Liên tục Cải tiến Dịch vụ (xem các ấn phẩm ITIL khác
trong loạt ấn phẩm này).
Một phần của vai trò này cũng là để đảm bảo sự cân bằng giữa trình
độ kỹ năng, khả năng sử dụng và chi phí của những nguồn lực này.
Ví dụ, việc thuê một nguồn lực cấp cao nhất ở cuối thang bảng
lương và sau đó chỉ sử dụng kỹ năng đó trong 10% của tổng thời
gian là không hiệu quả. Một Chiến lược Quản lý Kỹ thuật tốt hơn sẽ
là xác định những thời điểm cần có kỹ năng và sau đó chỉ thuê một
nhà thầu cho những tác vụ đó.
Một chiến lược khác trong các tổ chức lớn hơn là tận dụng nhân viên
chuyên gia nằm ngoài nhóm ‘trung tâm’ để các chuyên gia có thể
được sử dụng tốt và mang lại tính kinh tế của quy mô cho tổ chức
và giảm thiểu nhu cầu thuê nhà thầu. Các kỹ năng chuyên biệt cần
được xác định trong số các nguồn lực trong tổ chức CNTT, sau đó
được tận dụng cho các nhu cầu cụ thể khi chúng phát sinh, tương tự
như một đơn vị chiến thuật đặc biệt, nơi mà các thành viên cũng
thực hiện nhiệm vụ thường xuyên nhưng được giao các nhiệm vụ
khác cần đến kỹ năng chuyên biệt của họ. Kiểu sử dụng tài nguyên
này đặc biệt hữu ích cho cả nhóm dự án và giải quyết vấn đề.
Một vai trò bổ sung, nhưng cực kỳ quan trọng, của Quản lý Kỹ thuật
là cung cấp hướng dẫn cho Vận hành CNTT về cách thức tốt nhất để
thực hiện việc quản lý hoạt động liên tục của công nghệ. Vai trò này
được thực hiện một phần trong quá trình Thiết kế dịch vụ, nhưng nó
cũng là một phần của giao tiếp hàng ngày với Quản lý Vận hành
CNTT khi họ tìm cách đạt được sự ổn định và hiệu suất tối ưu.
Những mục tiêu, hoạt động và các cơ cấu hỗ trợ cho Quản lý Kỹ
thuật hoàn thành các vai trò này m ột cách hiệu quả được thảo luận
như dưới đây.
6.3.2 Các m ục tiê u c ủa Q u ả n lý K ỹ thuậ t

Những mục tiêu của Quản lý Kỹ thuật là giúp lập kế hoạch, triển
khai và duy trì một cơ sở hạ tầng kỹ thuật ổn định để hỗ trợ cho
các quy trình nghiệp vụ của tổ chức thông qua:
 Cấu trúc liên kết về mặt kỹ thuật được thiết kế tốt, có khả
năng phục hồi cao và hiệu quả về chi phí,
 Sử dụng đầy đủ các kỹ năng kỹ thuật để duy trì cơ sở hạ tầng
kỹ thuật trong điều kiện tối ưu,
 Nhanh chóng sử dụng các kỹ năng kỹ thuật để chẩn đoán
nhanh và giải quyết bất kỳ lỗi kỹ thuật nào xảy ra.
6.3.3 Các ho ạ t đ ộng ph ổ biến c ủa Q uả n lý K ỹ
thu ậ t
Quản lý Kỹ thuật liên quan đến hai kiểu hoạt động như sau:
 Các hoạt động phổ biến đối với chức năng Quản lý Kỹ thuật nói
chung được thảo luận trong phần này vì chúng hỗ trợ Quản lý
Kỹ thuật như một chức năng để thực hiện vai trò của nó,
 Một tập hợp các hoạt động và quy trình rời rạc được thực hiện
bởi cả ba chức năng Quản lý Kỹ thuật, Quản lý Ứng dụng và
Quản lý Vận hành CNTT được đề cập trong Chương 5.
Các hoạt động phổ biến của Quản lý Kỹ thuật được nêu bật như dưới
đây:
 Xác định kiến thức và chuyên môn cần thiết để quản lý và vận
hành Cơ sở hạ tầng CNTT và đê cung cấp các dịch vụ CNTT.
Quy trình này khởi đầu trong giai đoạn Chiến lược Dịch vụ,
được mở rộng chi tiết trong Thiết kế Dịch vụ và được thực thi
trong Vận hành Dịch vụ. Việc đánh giá và cập nhật liên tục của
những kỹ năng này được thực hiện trong Liên tục Cải tiến Dịch
vụ,
 Lập tài liệu về những kỹ năng đang tồn tại trong tổ chức, cũng
như những kỹ năng cần phải được phát triển. Việc này sẽ bao
gồm sự phát triển các Kỹ năng Kiểm kê và hiệu suất của Phân
tích Nhu cầu Đào tạo,
 Khởi đầu các chương trình đào tạo để phát triển và tinh chỉnh
các kỹ năng trong những nguồn lực kỹ thuật thích hợp và duy
trì các hồ sơ đào tạo đối với mọi nguồn lực kỹ thuật,
 Thiết kế và cung cấp đào tạo cho người dùng, Bộ phận Hỗ trợ
Dịch vụ và những nhóm khác. Mặc dù các yêu cầu đào tạo phải
được xác định trong Thiết kế Dịch vụ nhưng chúng được thực
hiện trong Vận hành Dịch vụ. Khi Quản lý Kỹ thuật không cung
cấp được sự đào tạo thì họ phải chịu trách nhiệm cho việc xác
định những tổ chức có thể cung cấp việc đào tạo này,
 Tuyển dụng hoặc ký hợp đồng với các nguồn lực có kỹ năng
không thể được phát triển trong nội bộ hoặc không có đủ nhân
sự để thực hiện các hoạt động Quản lý Kỹ thuật cần thiết,
 Thu được những kỹ năng cho các hoạt động cụ thể khi mà các
kỹ năng cần thiết không sẵn có trong nội bộ hoặc trên thị
trường mở, hoặc nơi hiệu quả hơn về chi phí để thực hiện điều
đó,
 Xác định các tiêu chuẩn được sử dụng trong việc thiết kế các
kiến trúc mới và tham gia vào việc định nghĩa các kiến trúc
công nghệ trong các giai đoạn Thiết kế Dịch vụ và Chiến lược
Dịch vụ.
 Nghiên cứu và phát triển các giải pháp có thể giúp mở rộng
Danh mục Dịch vụ hoặc có thể được sử dụng để đơn giản hóa
hoặc tự động hóa Vận hành CNTT, giảm chi phí hoặc gia tăng
mức dịch vụ CNTT.
 Tham gia vào việc thiết kế và xây dựng các dịch vụ mới. Quản
lý Kỹ thuật sẽ đóng góp vào việc thiết kế các tiêu chuẩn Hiệu
suất và Kiến trúc Kỹ thuật cho các dịch vụ CNTT. Ngoài ra, nó
cũng sẽ chịu trách nhiệm cho việc xác định các hoạt động vận
hành cần thiết để quản lý Cơ sở hạ tầng CNTT một cách liên
tục,
 Tham gia vào các dự án, không chỉ trong Thiết kế Dịch vụ và
Chuyển tiếp Dịch vụ, mà còn cho Liên tục Cải tiến Dịch vụ hoặc
các dự án vận hành, chẳng hạn như nâng cấp Hệ điều hành,
các dự án hợp nhất hoặc di chuyển vật lý máy chủ,
 Quản lý Tính sẵn sàng và Quản lý Công suất phụ thuộc vào
Quản lý Kỹ thuật để cơ cấu các dịch vụ CNTT để đáp ứng các
mức dịch vụ theo yêu cầu của doanh nghiệp. Điều này có nghĩa
rằng việc mô hình hóa và dự báo khối lượng công việc thường
được thực hiện với các nguồn lực Quản lý Kỹ thuật,
 Hỗ trợ cho việc đánh giá rủi ro, xác định các dịch vụ quan
trọng và những phụ thuộc vào hệ thống, đồng thời xác định và
triển khai các biện pháp đối phó,
 Thiết kế và thực hiện các bài kiểm tra chức năng, hiệu suất và
khả năng quản lý của các dịch vụ CNTT,
 Quản lý các nhà cung cấp. Rất nhiều bộ phận hoặc nhóm Quản
lý Kỹ thuật là những người duy nhất biết chính xác yêu cầu của
nhà cung cấp và cách đo lường và quản lý họ. Vì lý do này,
nhiều tổ chức đã dựa vào bộ phận Quản lý Kỹ thuật để quản lý
các hợp đồng với các nhà cung cấp của các Đơn vị Cấu hình cụ
thể. Nếu đúng như vậy, điều quan trọng là phải đảm bảo rằng
các mối quan hệ này được quản lý như một phần của quy trình
SLM,
 Định nghĩa và quản lý các tiêu chuẩn và công cụ Quản lý Sự
kiện. Quản lý Kỹ thuật cũng sẽ theo dõi và phản hồi cho nhiều
thể loại sự kiện,
 Các bộ phận hoặc nhóm Quản lý Kỹ thuật là một phần không
thể thiếu đối với hiệu suất Quản lý Sự cố. Họ tiếp nhận các sự
cố thông qua leo thang Chức năng và cung cấp hỗ trợ cấp độ
thứ hai và cao hơn. Họ cũng tham gia vào việc duy trì các thể
loại và xác định các thủ tục leo thang được thực hiện trong
Quản lý Sự cố,
 Quản lý Kỹ thuật là một chức năng cung cấp nguồn lực để thực
thi quy trình Quản lý Vấn đề. Đó là kiến thức chuyên môn kỹ
thuật và kiến thức của họ được sử dụng để chẩn đoán và giải
quyết vấn đề. Đó cũng là mối quan hệ với các nhà thầu được
sử dụng để leo thang và theo dõi cùng với các nhóm hỗ trợ của
nhà thầu,
 Các nguồn lực của Quản lý Kỹ thuật sẽ tham gia vào việc xác
định các hệ thống tạo mã được sử dụng trong Quản lý Sự cố và
Quản lý Vấn đề (ví dụ, Thể loại Sự cố),
 Các nguồn lực của Quản lý Kỹ thuật được sử dụng để hỗ trợ
Quản lý Vấn đề trong việc xác thực và duy trì KEDB,
 Quản lý Thay đổi dựa vào kiến thức kỹ thuật và chuyên môn để
đánh giá các thay đổi, và nhiều thay đổi sẽ được xây dựng bởi
Quản lý Kỹ thuật,
 Các bản phát hành thường xuyên được triển khai bằng cách sử
dụng các nguồn lực Quản lý Kỹ thuật,
 Quản lý Kỹ thuật sẽ cung cấp thông tin cho, và duy trì hoạt
động, hệ thống Quản lý Cấu hình và dữ liệu của nó. Điều này
sẽ được thực hiện với sự hợp tác của Quản lý Ứng dụng để đảm
bảo rằng các thuộc tính và mối quan hệ Đơn vị Cấu hình chính
xác được tạo ra từ việc triển khai các dịch vụ và bảo trì liên
tục trong suốt vòng đời của Đơn vị Cấu hình,
 Quản lý Kỹ thuật tham gia vào các quy trình Liên tục Cải tiến
Dịch vụ, đặc biệt trong việc xác định các cơ hội để cải tiến và
sau đó giúp đánh giá các giải pháp thay thế,
 Là người bảo quản những kiến thức và chuyên môn kỹ thuật,
Quản lý Kỹ thuật đảm bảo rằng mọi hệ thống và tài liệu vận
hành đều được cập nhật và sử dụng một cách đúng đắn. Việc
này bao gồm việc đảm bảo rằng tất cả các hướng dẫn quản lý,
quản trị và sử dụng đều được cập nhật và hoàn chỉnh và nhân
viên kỹ thuật đã quen thuộc với nội dung của họ,
 Cập nhật và duy trì dữ liệu được sử dụng để báo cáo về năng
lực kỹ thuật và dịch vụ, ví dụ, Quản lý Công suất và Quản lý
Hiệu suất, Quản lý Tính sẵn sàng, Quản lý Vấn đề, v.v…
 Hỗ trợ Quản lý Tài chính CNTT để xác định chi phí cho công
nghệ và nguồn nhân lực CNTT đã được sử dụng để quản lý các
dịch vụ CNTT,
 Tham gia vào việc xác định các hoạt động vận hành được thực
hiện như một phần của Quản lý Vận hành CNTT. Nhiều bộ phận,
nhóm hoặc đội Quản lý Kỹ thuật cũng thực hiện các hoạt động
vận hành như một phần của chức năng Quản lý Vận hành CNTT
của tổ chức.
6.3.4 Sự tổ c h ức Q u ả n lý K ỹ thuậ t
Quản lý Kỹ thuật không chỉ đơn thuần được cung cấp bởi một bộ
phận hoặc một nhóm duy nhất. Một hoặc nhiều nhóm hoặc bộ phận
Hỗ trợ Kỹ thuật sẽ được cần đến để cung cấp quản lý kỹ thuật và hỗ
trợ cho Cơ sở hạ tầng CNTT. Trong mọi tổ chức, ngoại trừ những tổ
chức nhỏ nhất, nơi mà một nhóm hoặc bộ phận được kết hợp duy
nhất là đủ, các nhóm hoặc bộ phận riêng biệt sẽ được cần đến cho
mỗi loại cơ sở hạ tầng đang được sử dụng.
Quản lý Vận hành CNTT cấu thành từ một số lĩnh vực thuộc về công
nghệ. Mỗi một trong những lĩnh vực này đòi hỏi một bộ kỹ năng cụ
thể để quản lý và vận hành nó. Một số bộ kỹ năng có liên quan và
có thể được thực hiện bởi những người có kiến thức phổ thông,
trong khi những bộ kỹ năng khác được chỉ định cho một thành phần,
hệ thống, hoặc nền tảng.
Tiêu chí chính của cơ cấu về mặt tổ chức của Quản lý kỹ thuật là
chuyên môn hóa hoặc phân công lao động. Nguyên tắc ở đây là mọi
người được phân nhóm theo các bộ kỹ năng kỹ thuật của họ và các
bộ kỹ năng này được xác định bởi công nghệ cần phải được quản lý.
Phần 6.6 và 6.7 trình bày chi ti ết các khía cạnh mang tính tổ chức
của Quản lý Kỹ thuật, nhưng danh sách dưới đây cung cấp một số ví
dụ về các nhóm hoặc bộ phận Quản lý Kỹ thuật điển hình:
 Nhóm hoặc bộ phận máy chủ lớn - nếu một hoặc nhiều loại máy
tính lớn vẫn đang được tổ chức sử dụng,
 Nhóm hoặc bộ phận máy chủ - thường được phân chia lại theo
loại công nghệ (ví dụ, máy chủ Unix, máy chủ Wintel),
 Nhóm hoặc bộ phận lưu trữ, chịu trách nhiệm quản lý tất cả
các thiết bị và phương tiện lưu trữ dữ liệu,
 Nhóm hoặc bộ phận Hỗ trợ Mạng, chăm sóc các mạng WAN/LAN
nội bộ của tổ chức và quản lý bất kỳ nhà cung cấp mạng bên
ngoài nào khác,
 Nhóm hoặc bộ phận máy tính để bàn, chịu trách nhiệm về tất
cả các thiết bị máy tính để bàn đã được lắp đặt,
 Nhóm hoặc bộ phận cơ sở dữ liệu, chịu trách nhiệm về việc
tạo, duy trì và hỗ trợ cơ sở dữ liệu của tổ chức,
 Nhóm hoặc bộ phận phần mềm trung gian, chịu trách nhiệm
tích hợp, thử nghiệm và bảo trì tất cả phần mềm trung gian
đang được sử dụng trong tổ chức,
 Nhóm hoặc bộ phận Dịch vụ Danh mục, chịu trách nhiệm duy trì
quyền truy cập và quyền đối với các phần tử dịch vụ trong cơ
sở hạ tầng,
 Nhóm hoặc bộ phận Internet hoặc Web, chịu trách nhiệm quản
lý tính khả dụng và bảo mật của quyền truy cập vào máy chủ
và nội dung của khách hàng, người dùng và đối tác bên ngoài,
 Nhóm hoặc bộ phận thông điệp, chịu trách nhiệm về các dịch
vụ e-mail,
 Nhóm hoặc bộ phận Điện thoại dựa trên IP (ví dụ, VoIP).
6.3.5 Thiết k ế Kỹ thuậ t và Duy trì và H ỗ trợ K ỹ

thu ậ t
Quản lý Kỹ thuật bao gồm các kiến trúc sư kỹ thuật và các nhà thiết
kế chuyên nghiệp (những người chủ yếu tham gia vào quá trình
Thiết kế Dịch vụ) và nhân viên hỗ trợ và bảo trì chuyên nghiệp
(những người chủ yếu tham gia vào Vận hành Dịch vụ).
Trong ấn phẩm này, họ được xem như là một bộ phận của cùng một
chức năng, nhưng nhiều tổ chức lại coi họ là hai nhóm, thậm chí là
hai bộ phận riêng biệt. Vấn đề với phương pháp tiếp cận này là rằng
những thiết kế tốt cần đầu vào từ những người được yêu cầu quản lý
giải pháp – và hoạt động tốt cần có sự tham gia từ phía những
người đã thiết kế nên giải pháp.
Những vấn đề cần được khắc phục tương tự như những vấn đề phải
đối mặt trong việc quản lý Vòng đời Ứng dụng (xem phần 6.5 để biết
thêm chi tiết). Giải pháp sẽ bao gồm những phần tử sau:
 Nhân viên hỗ trợ nên được tham gia vào quá trình thiết kế
hoặc kiến trúc của một giải pháp. Nhân viên thiết kế cũng nên
được tham gia vào việc thiết lập các mục tiêu bảo trì và giải
quyết các vấn đề hỗ trợ,
 Một sự thay đổi trong cách mà cả nhân viên Thiết kế và Hỗ trợ
được đo lường. Các nhà thiết kế nên chịu trách nhiệm một
phần về những sai sót trong thiết kế gây ra tình trạng gián
đoạn vận hành. Nhân viên hỗ trợ phải chịu trách nhiệm một
phần về đóng góp cho kiến trúc kỹ thuật.
6.3.6 Các ch ỉ s ố c ủ a Q u ản lý K ỹ thuậ t

Các chỉ số dành cho TT sẽ phụ thuộc rất nhiều vào những công nghệ
đang được quản lý, nhưng một số chỉ số phổ biến bao gồm:
 Đo lường kết quả đầu ra đã được thống nhất. Chúng bao

gồm:
o Đóng góp cho thành tựu của các dịch vụ đối với doanh
nghiệp. Mặc dù nhiều nhóm Quản lý kỹ thuật sẽ không
trực tiếp liên hệ với doanh nghiệp nhưng công nghệ mà
họ quản lý sẽ ảnh hưởng đến doanh nghiệp. Các chỉ số
phải phản ánh cả đóng góp tiêu cực (các sự cố được theo
dõi từ nhóm của họ) và tích cực (hiệu suất và tính sẵn
sàng của hệ thống),
o Tỷ lệ giao dịch và tính sẵn sàng đối với các giao dịch kinh
doanh quan trọng,
o Đào tạo Bộ phận Hỗ trợ Dịch vụ,
o Ghi lại các giải pháp chovấn đề vào KEDB,
o Người dùng đo lường chất lượng đầu ra như đã được xác
định trong SLA,
o Cài đặt và cấu hình các thành phần dưới sự kiểm soát của
họ,
 Số liệu quy trình. Nhóm Quản lý Kỹ thuật thực hiện nhiều
hoạt động Quản lý Quy trình. Khả năng của họ để làm vậy sẽ
được đo lường như một phần của chỉ số quy trình nếu thích
hợp (xem phần trên về từng quy trình để biết thêm chi tiết).
Những ví dụ bao gồm:
o Thời gian hồi đáp các sự kiện và tỷ lệ hoàn thành sự kiện,
o Thời gian giải quyết sự cố đối với hỗ trợ tuyến thứ hai và
thứ ba,
o Thống kê về giải quyết vấn đề,
o Số lần leo thang và lý do cho nh ững lần leo thang đó,
o Số lượng thay đổi được thực hiện và được đảo ngược,
o Số lượng thay đổi trái phép được phát hiện,
o Số lượng bản phát hành được triển khai, tổng số và thành
công,
o Các vấn đề về bảo mật đã được phát hiện và giải quyết,
o Mức sử dụng hệ thống thực tế so với các dự báo của Kế
hoạch Công suất (theo đó, đó nhóm đã đóng góp vào sự
phát triển của kế hoạch),
o Theo dõi so với các SIP,
o Chi tiêu so với ngân sách.
 Hiệu suất công nghệ. Các chỉ số này dựa trên các thông số
kỹ thuật của Thiết kế Dịch vụ và các tiêu chuẩn hiệu suất kỹ
thuật do nhà cung cấp đặt ra và thường sẽ được bao gồm trong
OLA hoặc Quy trình Vận hành Tiêu chuẩn. Các chỉ số thực tế sẽ
khác nhau tùy theo công nghệ, nhưng có khả năng bao gồm:
o Tỷ lệ sử dụng (ví dụ, bộ nhớ hoặc bộ xử lý cho máy chủ,
băng thông cho mạng, v.v...),
o Tính sẵn sàng (của hệ thống, mạng, thiết bị, v.v...), vốn
rất hữu ích cho việc đo lường hiệu suất của nhóm hoặc
của hệ thống, nhưng không được nhầm lẫn với Tính sẵn
sàng của dịch vụ - đòi hỏi khả năng đo lường tính sẵn
sàng tổng thể của dịch vụ và có thể sử dụng số liệu về
tính sẵn sàng của một số hệ thống hoặc thành phần riêng
lẻ,
o Hiệu suất (ví dụ, thời gian hồi đáp, tỷ lệ xếp hàng,
v.v...),
 Thời gian trung bình Giữa các lần Hỏng hóc (MTBF) của
thiết bị được chỉ định. Số liệu này được sử dụng để đảm bảo
rằng các quyết định mua sắm tốt đang được đưa ra và khi so
sánh với các lịch trình bảo trì, rằng liệu thiết bị có được bảo trì
đúng một cách đúng đắn hay không,
 Đo lường hoạt động bảo trì, bao gồm:
o Bảo trì đã được thực hiện theo lịch trình,
o Số lượng cửa sổ bảo trì bị vượt quá,
o Các mục tiêu bảo trì đạt được (số lượng và tỷ lệ phần
trăm),
 Đào tạo và phát triển kỹ năng. Các chỉ số này đảm bảo rằng
nhân viên có các kỹ năng và được đào tạo để quản lý công
nghệ nằm trong tầm kiểm soát của họ, đồng thời cũng sẽ xác
định các lĩnh vực vẫn cần đào tạo.
6.3.7 Tài li ệ u Q u ản lý K ỹ thu ậ t

Quản lý Kỹ thuật tham gia vào việc soạn thảo và duy trì một số tài
liệu như một phần của các quy trình khác (ví dụ, Hoạch định Công
suất, Quản lý Thay đổi, Quản lý Vấn đề, v.v…). Những tài liệu này
được thảo luận một số chi tiết hơn trong các mô tả quy trình có liên
quan.
Tuy nhiên, có một số tài liệu dành riêng cho các nhóm ho ặc đội
Quản lý Kỹ thuật, những người sẽ lập hồ sơ quản lý và kiểm soát các
tài liệu có liên quan đến những công nghệ mà họ đang kiểm soát.
Những tài liệu Quản lý Kỹ thuật bao gồm những loại sau đây.
6.3.7. 1 Tài li ệ u K ỹ thuậ t

Nguồn cung và việc bảo trì các tài liệu kỹ thuật cho mọi Đơn vị Cấu
hình là trách nhiệm của Quản lý Kỹ thuật. Chúng bao gồm:
 Những hướng dẫn kỹ thuật,

 Những hướng dẫn quản lý và quản trị,
 Những hướng dẫn sử dụng dành cho các Đơn vị Cấu hình.
Chúng sẽ thường loại trừ các hướng dẫn sử dụng ứng dụng,
vốn được duy trì bởi Quản lý Ứng dụng.
6.3.7. 2 Các l ịch trình b ả o tr ì

Những lịch trình này được soạn thảo và thống nhất trong giai đoạn
Thiết kế Dịch vụ có liên quan đến Quản lý Tính sẵn sàng và Quản lý
Công suất, nhưng về cơ bản, chúng là tài sản của các bộ phận, đội,
nhóm Quản lý Kỹ thuật khác nhau. Điều này là do họ có chuyên môn
kỹ thuật đối với những công nghệ cụ thể và có nhiều khả năng biết
về những gì cần thiết để duy trì công việc của họ.
Để biết thêm chi tiết về định nghĩa về các Lịch trình Bảo trì và các
Mục tiêu Quản lý Kỹ thuật, vui lòng tham khảo ấn phẩm Thiết kế
Dịch vụ của ITIL.
6.3.7. 3 Kho k ỹ năng

Một Kho Kỹ năng là một hệ thống hoặc công cụ để xác định những
kỹ năng cần thiết để cung cấp và hỗ trợ cho các dịch vụ CNTT và
đồng thời là những cá nhân sở hữu những kỹ năng đó. Kho Kỹ năng
có hiệu quả nhất khi chúng được liên kết với các quy trình, kiến trúc
hoặc tiêu chuẩn hiệu suất.
Ngoài ra, các Kho Kỹ năng nên xác định các khóa đào tạo sẵn có để
trau dồi từng kỹ năng trong trường hợp nhân viên hiện tại rời khỏi
tổ chức.
Các Kho Kỹ năng cũng có thể được sử dụng như một phần của Danh
mục Dịch vụ để đánh giá xem liệu một dịch vụ mới có thể được cung
cấp với nhân viên và bộ kỹ năng hiện tại hay không, hoặc liệu một
khoản đầu tư có cần được đưa ra cho nhân viên mới hoặc cho đào
tạo hay không. Do đó, các Kho Kỹ năng có thể đóng góp đáng kể cho
Hoạch định Công suất.
Việc xác định và duy trì các Kho Kỹ năng đòi hỏi một tương tác tốt
với các quy trình và công cụ Nhân sự trong tổ chức.
6.4 Quản lý Vận hành CNTT

Trong kinh doanh, thuật ngữ ‘Quản lý Vận hành’ được sử dụng để
chỉ bộ phận, đội hoặc nhóm người chịu trách nhiệm cho việc thực
hiện các hoạt động vận hành hàng ngày của tổ chức – chẳng hạn
như chạy một dây chuyền sản xuất trong một môi trường nhà máy
hoặc quản lý các trung tâm phân phối và sự di chuyển của đoàn tàu
xe trong một tổ chức hậu cần.
Nói chung, Quản lý Vận hành có những đặc trưng dưới đây:
 Có hoạt động để đảm bảo rằng một thiết bị, hệ thống hoặc quy
trình thực sự đang chạy hoặc đang hoạt động (trái ngược với
chiến lược hoặc kế hoạch),
 Đây là nơi các kế hoạch được biến thành những hành động,
 Trọng tâm là các hoạt động hàng ngày hoặc ngắn hạn, mặc dù
nên lưu ý rằng các hoạt động này nói chung sẽ được thực hiện
và lặp lại trong một thời gian tương đối dài (trái ngược với các
hoạt động một lần kiểu dự án),
 Các hoạt động này được thực hiện bởi các nhân viên kỹ thuật
có trình độ chuyên môn, những người thường phải trải qua đào
tạo kỹ thuật để học cách thực hiện từng hoạt động,
 Tập trung vào việc xây dựng các hành động nhất quán, có thể
lặp lại - nếu được lặp lại đủ thường xuyên ở mức chất lượng
phù hợp - sẽ đảm bảo sự thành công của vận hành,
 Đây là nơi giá trị thực tế của tổ chức được phân phối và đo
lường,
 Phụ thuộc vào đầu tư vào trang thiết bị hoặc nguồn nhân lực
hoặc cả hai,
 Giá trị được tạo ra phải vượt quá chi phí đầu tư và tất cả các
chi phí quản lý khác của tổ chức (chẳng hạn như chi phí quản
lý và tiếp thị) nếu doanh nghiệp thành công.
Theo cách tương tự, Quản lý Vận hành CNTT có thể được định nghĩa
là chức năng chịu trách nhiệm quản lý và duy trì liên tục Cơ sở hạ
tầng CNTT của một tổ chức để đảm bảo cung cấp mức dịch vụ CNTT
đã được thống nhất cho doanh nghiệp.
Vận hành CNTT có thể được định nghĩa là tập hợp các hoạt động liên
quan đến việc vận hành hàng ngày của Cơ sở hạ tầng CNTT nhằm
mục đích cung cấp các dịch vụ CNTT ở các mức đã thỏa thuận để
đáp ứng các mục tiêu kinh doanh đã được nêu.
6.4.1 Vai trò Q uả n lý V ậ n hành CNTT
Vai trò của Quản lý Vận hành là để thực thi các hoạt động và các
thủ tục liên tục cần thiết để quản lý và duy trì Cơ sở hạ tầng CNTT,
để từ đó cung cấp và hỗ trợ các Dịch vụ CNTT ở các mức đã được
thống nhất. Chúng thực sự đã được thảo luận trong phần 5, nhưng
sẽ được tóm tắt ở đây cho đầy đủ hơn:
 Kiểm soát Vận hành, để giám sát việc thực thi và giám sát các
hoạt động và sự kiện vận hành trong Cơ sở hạ tầng CNTT. Điều
này có thể được thực hiện với sự hỗ trợ của Cầu nối Vận hành
hoặc Trung tâm Vận hành Mạng. Ngoài việc thực thi các nhiệm
vụ thường lệ từ tất cả các lĩnh vực kỹ thuật, Kiểm soát Vận
hành cũng thực hiện các nhiệm vụ cụ thể sau đây:
o Quản lý Bảng điều khiển, đề cập đến việc xác định năng
lực quan sát và giám sát trung tâm và sau đó sử dụng các
bảng điều khiển đó để thực hiện các hoạt động giám sát
và kiểm soát,
o Lập lịch trình Công việc, hoặc quản lý các công việc hàng
loạt hoặc các tập lệnh kịch bản thông thường,
o Sao lưu và khôi phục dưới danh nghĩa tất cả các nhóm và
bộ phận Quản lý Kỹ thuật và Quản lý Ứng dụng và thường
đại diện cho người dùng,
o Quản lý In ấn và Quản lý Đầu ra để đối chiếu và phân
phối tất cả các đầu ra in ấn hoặc điện tử tập trung,
o Thực hiện các hoạt động bảo trì thay mặt cho các nhóm
hoặc bộ phận Quản lý Kỹ thuật hoặc Quản lý Ứng dụng,
 Quản lý Cơ sở vật chất, đề cập đến việc quản lý môi trường
CNTT vật lý, điển hình là một Trung tâm Dữ liệu hoặc các
phòng máy tính và địa điểm khôi phục cùng với tất cả các thiết
bị cấp nguồn và làm mát. Quản lý Cơ sở vật chất cũng bao gồm
việc điều phối các dự án hợp nhất quy mô lớn, ví dụ, Các dự án
hợp nhất Trung tâm dữ liệu hoặc hợp nhất máy chủ. Trong một
số trường hợp, việc quản lý một trung tâm dữ liệu được thuê
ngoài, trong trường hợp đó, Quản lý Cơ sở vật chất đề cập đến
việc quản lý hợp đồng thuê ngoài.
Như nhiều quy trình và chức năng Quản lý Dịch vụ CNTT, Quản lý
Vận hành CNTT cũng đóng một vai trò kép.
 Quản lý Vận hành CNTT chịu trách nhiệm cho việc thực thi các
hoạt động và tiêu chuẩn hiệu suất đã được xác định trong quá
trình Thiết kế Dịch vụ và được kiểm nghiệm trong quá trình
Chuyển tiếp Dịch vụ. Theo nghĩa này, vai trò của Vận hành
CNTT chủ yếu là duy trì hiện trạng. Tính ổn định của Cơ sở hạ
tầng CNTT và sự nhất quán của các dịch vụ CNTT là mối quan
tâm hàng đầu của Vận hành CNTT. Ngay cả những cải tiến về
hoạt động cũng nhằm mục đích tìm ra những cách đơn giản hơn
và tốt hơn để thực hiện những điều tương tự.
 Đồng thời, Vận hành CNTT là một phần của quá trình gia tăng
giá trị cho các ngành kinh doanh khác nhau và h ỗ trợ cho mạng
lưới giá trị (xem ấn phẩm Chiến lược Dịch vụ của ITIL). Khả
năng của doanh nghiệp trong việc đáp ứng các mục tiêu và duy
trì khả năng cạnh tranh của họ phụ thuộc vào kết quả đầu ra
và độ tin cậy của hoạt động hàng ngày của CNTT. Như vậy,
Quản lý Vận hành CNTT phải có khả năng liên tục thích ứng với
các yêu cầu và nhu cầu kinh doanh. Doanh nghiệp không quan
tâm rằng Vận hành CNTT có tuân thủ quy trình tiêu chuẩn hay
máy chủ hoạt động tối ưu hay không. Khi nhu cầu và yêu cầu
kinh doanh thay đổi, Quản lý Vận hành CNTT phải có khả năng
bắt kịp với chúng, thường là thách thức đối với giữ nguyên
hiện trạng.
Vận hành CNTT phải đạt được sự cân bằng giữa những vai trò này,
vốn sẽ đòi hỏi những điều sau đây:
 Một hiểu biết về cách thức mà công nghệ được sử dụng để

cung cấp các dịch vụ CNTT như thế nào,
 Một hiểu biết về tầm quan trọng và tác động tương đổi của
những dịch vụ đó đối với doanh nghiệp,
 Các thủ tục và hướng dẫn phác thảo vai trò của Vận hành CNTT
trong cả quản lý công nghệ lẫn cung cấp các dịch vụ CNTT,
 Một bộ các chỉ số khác biệt rõ ràng để báo cáo cho doanh
nghiệp về thành tựu của các mục tiêu của Dịch vụ, và để báo
cáo cho các nhà quản lý CNTT về tính hiệu quả và hiệu suất
của Vận hành CNTT,
 Mọi nhân viên Vận hành CNTT hiểu một cách chính xác về cách
mà hiệu suất của công nghệ ảnh hưởng như thế nào đến việc
cung cấp các dịch vụ CNTT,
 Một chiến lược chi phí nhằm mục đích cân bằng các yêu cầu
của các đơn vị kinh doanh khác nhau với chi phí tiết kiệm sẵn
có thông qua việc tối ưu hóa công nghệ hiện hữu hoặc đầu tư
vào công nghệ mới,
 Một chiến lược Lợi nhuận trên Khoản đầu tư dựa trên giá trị,
thay vì dựa trên chi phí.
6.4.2 Các m ục tiê u c ủa Q u ả n lý V ậ n hành CNTT

Các mục tiêu của Vận hành CNTT bao gồm:
 Duy trì hiện trạng để đạt được tính ổn định của các quy trình
và hoạt động hàng ngày của tổ chức,
 Thường xuyên xem xét kỹ lưỡng và cải thiện để đạt được các
dịch vụ được cải tiến với mức chi phí giám, trong khi vẫn duy
trì được tính ổn định,
 Áp dụng nhanh các kỹ năng vận hành để chẩn đoán và giải
quyết bất kỳ lỗi vận hành CNTT nào xảy ra.
6.4.3 Sự tổ c h ức Q uả n lý V ậ n hành CNTT

Hình 6.1 trong phần giới thiệu của Chương 6 đã minh họa rằng Quản
lý Vận hành CNTT được xem như một chức năng theo đúng nghĩa của
nó nhưng trong nhiều trường hợp, nhân viên từ các nhóm Quản lý Kỹ
thuật và Ứng dụng cũng hình thành nên một phần của chức năng
này.
Điều này có nghĩa là một số bộ phận hoặc nhóm Quản lý Kỹ thuật và

Quản lý Ứng dụng sẽ quản lý và thực hiện các hoạt động vận hành
của riêng họ. Những người khác sẽ ủy thác các hoạt động này cho
một bộ phận Vận hành CNTT chuyên dụng.
Không có một phương pháp duy nhất để chỉ định các hoạt động, vì
nó phụ thuộc vào sự trưởng thành và ổn định của cơ sở hạ tầng
đang được quản lý. Ví dụ, các lĩnh vực Quản lý Kỹ thuật và Quản lý
Ứng dụng đang còn khá mới và không ổn định sẽ có khuynh hướng
tự quản lý các hoạt động của họ. Các nhóm mà công nghệ hoặc ứng
dụng ổn định, trưởng thành và được hiểu rõ có khuynh hướng chuẩn
hóa các hoạt động của họ hơn và do đó sẽ cảm thấy thoải mái hơn
khi ủy thác các hoạt động này.
Một số tùy chọn về cách để cấu trúc Vận hành CNTT được thảo luận
chi tiết hơn trong phần 6.7 của ấn phẩm này.
6.4.4 Các ch ỉ s ố c ủ a Q uản lý V ậ n hành CNTT

Quản lý Vận hành CNTT được đo lường về mặt thực thi hiệu quả các
hoạt động và thủ tục cụ thể, cũng như việc thực t hi các hoạt động
quy trình. Các ví dụ bao gồm:
 Hoàn thành thành công các công việc đã được lên lịch trình,
 Số lượng các ngoại lệ đối với các hoạt động và công việc đã
được lên lịch trình,
 Số lượng dữ liệu hoặc hệ thống khôi phục cần thiết,
 Thống kê cài đặt thiết bị, bao gồm số lượng các hạng mục đã
cài đặt theo kiểu, trạng thái cài đặt thành công, v.v…
 Các chỉ số quy trình. Quản lý Vận hành CNTT thực thi rất nhiều
hoạt động quy trình Quản lý Dịch vụ. Khả năng của chúng
trong việc thực hiện việc này được đo lường như một phần của
các chỉ số quy trình, nếu thích hợp (xem phần trình bày về
từng quy trình để biết thêm chi tiết). Các ví dụ bao gồm:
o Thời gian hồi đáp các sự kiện,
o Thời gian giải quyết sự cố đối với các sự cố,
o Số lượng các sự cố có liên quan đến bảo mật,
o Số lượng các lần leo thang và nguyên nhân của những lần
leo thang đó,
o Số lượng những thay đổi đã được triển khai và đảo ngược,
o Số lượng những thay đổi trái phép đã được phát hiện,
o Số lượng các bản phát hành đã triển khai, tổng cộng và
thành công,
o Theo dõi so với SIP,
o Chi tiêu so với ngân sách,
 Nếu hoạt động bảo trì được ủy thác thì các chỉ số liên quan
đến những hoạt động này cũng sẽ phù hợp:
o Bảo trì đã thực hiện so với lịch trình,
o Số lượng các cửa sổ bảo trì bị vượt quá,
o Các mục tiêu bảo trì đã đạt được (số lượng và tỷ lệ phần
trăm),
 Các chỉ số liên quan đến Quản lý Cơ sở vật chất khá bao quát
nhưng thường bao gồm:
o Chi phí so với ngân sách liên quan đến bảo trì, xây dựng,
bảo mật, vận chuyển, v.v…
o Các sự cố liên quan đến việc xây dựng, ví dụ, các sửa
chữa cần thiết đối với cơ sở vật chất,
o Các báo cáo về sự truy cập vào cơ sở vật chất,
o Số lượng các sự kiện bảo mật và Sự cố bảo mật và giải
pháp của chúng,
o Thống kê sử dụng năng lượng, đặc biệt khi có liên quan
đến những thay đổi trong chiến lược bố trí và điều kiện
môi trường,
o Các sự kiện hoặc sự cố liên quan đến vận chuyển và phân
phối.
6.4.5 Tài li ệ u Q uản lý V ậ n hành CNTT

Một số các tài liệu được đưa ra và sử dụng trong quá trình Quản lý
Vận hành CNTT. Danh sách này là một bản tóm tắt về một số tài liệu
quan trọng nhất và không bao gồm các báo cáo được đưa ra bởi
Quản lý Vận hành CNTT dưới danh nghĩa các quy trình hoặc chức
năng khác.
6.4.5. 1 Thủ tục V ậ n hành Tiêu ch u ẩ n
Các Thủ tục Vận hành Tiêu chuẩn (SOP) là một bộ các tài liệu có
chứa những hướng dẫn chi tiết và các lịch trình hoạt động cho mọi
nhóm, bộ phận hoặc đội Quản lý Vận hành CNTT.
Những tài liệu này đại diện cho những công việc thường lệ phải được
hoàn thành đối với mọi thiết bị, hệ thống hoặc thủ tục. Chúng cũng
phác thảo nên các thủ tục phải được tuân theo nếu một ngoại lệ
được phát hiện hoặc nếu một thay đổi là cần thiết.
Các tài liệu SOP cũng có thể được sử dụng để xác định các mức tiêu
chuẩn của hiệu suất đối với các thiết bị hoặc thủ tục. Trong một số
tổ chức, các tài liệu SOP được tham chiếu đến trong OLA. Thay vì
liệt kê chi tiết các thước đo hiệu suất trong OLA, một điều khoản
được chèn vào để tham chiếu tới các tiêu chuẩn hiệu suất trong SOP
và cách thức mà chúng sẽ được đo lường và báo cáo như thế nào.
6.4.5. 2 N hậ t ký V ậ n hành
Bất kỳ hoạt động nào được tiến hành như một phần của Vận hành
CNTT nên được ghi nhận lại vì một số lý do, bao gồm:
 Chúng có thể được sử dụng để xác nhận sự hoàn thành thành

công các công việc hoặc hoạt động cụ thể,
 Chúng có thể được sử dụng để xác nhận rằng một dịch vụ CNTT
đã được cung cấp như đã thống nhất,
 Chúng có thể được sử dụng bởi Quản lý Vấn đề để nghiên cứu
nguyên nhân gốc rễ của sự cố,
 Chúng là cơ sở để báo cáo về hiệu suất của các nhóm và bộ
phận Quản lý Vận hành CNTT.
Định dạng của các nhật ký này là khác nhau do số lượng các hệ
thống và nhóm hoặc bộ phận Quản lý Vận hành CNTT. Các ví dụ của
Nhật ký Vận hành bao gồm:
 Các Nhật ký Hệ điều hành được lưu trữ trên từng thiết bị,
 Các Nhật ký Hoạt động Ứng dụng được lưu trữ trong một tập
tin trên máy chủ ứng dụng,
 Các Nhật ký Sự kiện được lưu trữ trên máy chủ công cụ giám
sát,
 Các Nhật ký Sử dụng đối với các thiết bị chính,
 Các nhật ký truy cập vật lý ghi nhận ai đã truy cập vào các tòa
nhà an ninh và vào khi nào,
 Nhật ký viết tay của các hành động được thực hiện bởi nhân
viên vận hành. Việc ngày phải được chính thức ghi lại trong sổ
nhật ký hoặc sổ tay, được đánh số và lưu trữ trong một môi
trường an toàn. Kiểm tra phải đảm bảo rằng các trang đã
không bị xóa.
6.4.5. 3 Các L ịch trìn h và Báo cáo Công vi ệc

Các Lịch trình Công việc là những tài liệu phác thảo chính xác những
hoạt động cần phải được tiến hành trong một ca làm việc. Chúng
cũng liệt kê ra tất cả những phụ thuộc và trình tự hoạt động. Có khả
năng sẽ có nhiều hơn một Lịch trình Công việc, trong đó từng nhóm
sẽ có một phiên bản cho các hệ thống của riêng mình. Điều quan
trọng là mọi lịch trình được phối hợp trước khi bắt đầu ca làm việc.
Việc này thường được thực hiện bởi một cá nhân, người chuyên biệt
cho việc Lập lịch trình Công việc, với sự trợ giúp của các công cụ lập
lịch trình.
Một Lịch trình Công việc có thể cấu thành từ một số các hạng mục
thường lệ được bao gồm trong SOP. Trong trường hợp này, các hạng
mục có thể đơn giản chỉ được liệt kê tóm tắt với một tham chiếu đến
phần hoặc một trang trong SOP.
Hầu hết các Lịch trình Công việc đều có hình thức một danh sách
kiểm tra, nơi mà nhân viên vận hành có thể đánh dấu kiểm tra các
hạng mục khi nó đã được hoàn thành, cùng với thời gian hoàn
thành. Điều này khiến cho việc quan sát tiến trình hoạt động trở nên
dễ dàng hơn và cũng giúp xác định bất kỳ vấn đề tiềm ẩn nào khi
các công việc được thực hiện quá lâu.
Các Báo cáo Công việc là một hình thức của Nhật ký Vận hành,
nhưng có thêm các chức năng bổ sung như sau:
 Để ghi nhận các sự kiện và hoạt động lớn xảy ra trong ca làm
việc,
 Để hình thành một phần của sự bàn giao giữa các trưởng ca
làm việc,
 Để báo cáo bất kỳ ngoại lệ nào đối với các Mục tiêu Bảo trì
Dịch vụ,
 Để xác định bất kỳ hoạt động chưa hoàn thành nào có th ể dẫn
đến sự sụt giảm hiệu suất của bất kỳ dịch vụ nào trong những
giờ dịch vụ tiếp theo.
6.4.5. 4 Lịch tr ình V ậ n hành

Lịch trình Vận hành tương tự như Lịch trình Công việc nhưng bao
gồm tất cả các khía cạnh của Vận hành CNTT ở cấp cao. Lịch trình
này sẽ bao gồm một cái nhìn tổng quan về tất cả các thay đổi đã
được lên kế hoạch, bảo trì, công việc thường lệ và công việc bổ
sung, cùng với thông tin về các sự kiện sắp tới của doanh nghiệp
hoặc nhà cung cấp. Lịch trình Vận hành được sử dụng như là một cơ
sở cho Cuộc họp Vận hành Hàng ngày và là tài liệu tham khảo chính
cho tất cả các nhà Quản lý Vận hành CNTT để theo dõi tiến độ và
phát hiện ra các trường hợp ngoại lệ.
6.5 Quản lý Ứng dụng

Quản lý Ứng dụng chịu trách nhiệm cho việc quản lý các ứng dụng
trong toàn bộ vòng đời của chúng. Chức năng Quản lý Ứng dụng
được thực hiện bởi bất kỳ bộ phận, đội hoặc nhóm nào liên quan đến
việc quản lý và hỗ trợ vận hành các ứng dụng. Quản lý Ứng dụng
cũng đóng một vai trò quan trọng trong việc thiết kế, kiểm nghiệm
và cải thiện những ứng dụng hình thành nên một phần của các dịch
vụ CNTT. Do vậy, nó có thể liên quan đến các dự án phát triển,
nhưng không thường thì không giống với các nhóm Phát triển Ứng
dụng.
6.5.1 Vai trò Q u ả n lý Ứng d ụng

Quản lý Ứng dụng là ứng dụng những gì là Quản lý Kỹ thuật vào Cơ
sở hạ tầng CNTT. Quản lý Ứng dụng đóng một vai trò trong mọi ứng
dụng, cho dù được mua hay phát triển trong nội bộ. Một trong
những quyết định quan trọng mà họ đóng góp là quyết định mua ứng
dụng hay xây dựng nó (điều này đã được thảo luận chi tiết trong ấn
phẩm Thiết kế Dịch vụ). Một khi quyết định đó được đưa ra, Quản lý
Ứng dụng sẽ đóng một vai trò kép như dưới đây:
 Là người bảo quản kiến thức kỹ thuật và chuyên môn liên quan
đến việc quản lý các ứng dụng. Trong vai trò này, Quản lý Ứng
dụng, cộng tác với Quản lý Kỹ thuật, đảm bảo rằng kiến thức
cần thiết để thiết kế, kiểm nghiệm, quản lý và cải tiến các dịch
vụ CNTT được xác định, phát triển và tinh chỉnh.
 Cung cấp các tài nguyên thực tế để hỗ trợ cho Vòng đời ITSM.
Trong vai trò này, Quản lý Ứng dụng đảm bảo rằng các nguồn
lực được đào tạo và triển khai một cách hiệu quả để thiết kế,
xây dựng, chuyển tiếp, vận hành và cải tiến công nghệ cần
thiết để cung cấp và hỗ trợ các dịch vụ CNTT.
Bằng cách thực hiện hai vai trò này, Quản lý Ứng dụng có khả năng
đảm bảo rằng tổ chức có quyền truy cập vào đúng loại và cấp độ
nguồn nhân lực để quản lý các ứng dụng và do đó đáp ứng các mục
tiêu kinh doanh. Điều này khởi đầu trong Chiến lược Dịch vụ và được
mở rộng trong Thiết kế Dịch vụ, được kiểm nghiệm trong Chuyển
tiếp Dịch vụ và được cải tiến trong Liên tục Cải tiến Dịch vụ (xem
các ấn phẩm ITIL khác trong loạt ấn phẩm này).
Một phần của vai trò này là đảm bảo sự cân bằng giữa trình độ kỹ
năng và chi phí của những nguồn lực này.
Ngoài hai vai trò cấp cao này, Quản lý Ứng dụng còn thực hiện hai
vai trò cụ thể sau:
 Cung cấp hướng dẫn cho Vận hành CNTT về cách tốt nhất để
thực hiện quản lý vận hành liên tục các ứng dụng. Vai trò này
được tiến hành một phần trong quá trình Thiết kế Dịch vụ,
nhưng nó cũng là một phần của giao tiếp hàng ngày với Quản
lý Vận hành CNTT khi họ tìm cách để đạt được hiệu suất ổn
định và tối ưu.
 Sự tích hợp của Vòng đời Quản lý Ứng dụng trong Vòng đời
ITSM. Điều này được thảo luận như dưới đây.
Các mục tiêu, hoạt động và cơ cấu hỗ trợ Quản lý Ứng dụng để đóng
những vai trò này một cách hiệu quả cũng được thảo luận dưới đây.
6.5.2 Các m ục tiê u c ủa Q u ả n lý Ứ ng d ụng

Mục tiêu của Quản lý Ứng dụng là để hỗ trợ cho các quy trình
nghiệp vụ của tổ chức bằng cách giúp xác định các yêu cầu chức
năng và khả năng quản lý đối với phần mềm ứng dụng, và sau đó,
hỗ trợ việc thiết kế và triển khai và liên tục hỗ trợ và cải thiện
những ứng dụng đó.
Những mục tiêu này đạt được thông qua:
 Những ứng dụng đưuọc thiết kế tốt, khả năng phục hồi cao và
hiệu quả về chi phí,
 Đảm bảo rằng các chức năng cần thiết sẵn sàng để đạt được
các kết quả kinh doanh được yêu cầu,
 Tổ chức đầy đủ những kỹ kăng kỹ thuật để duy trì vận hành
ứng dụng trong những điều kiện tối ưu,
 Nhanh chóng sử dụng các kỹ năng kỹ thuật để chẩn đoán và
giải quyết một cách nhanh gọn bất kỳ lỗi kỹ thuật nào xảy ra.
6.5.3 Các nguyên t ắ c Q u ản lý Ứ ng d ụn g

6.5.3. 1 Xây d ựng h ay Mua?
Một trong những quyết định then chốt trong Quản lý Ứng dụng là
liệu có nên mua một ứng dụng để hỗ trợ cho chức năng được yêu
cầu hoặc xây dựng ứng dụng đặc biệt cho yêu cầu của tổ chức.
Những quyết định này thường được đưa ra bởi Trưởng Bộ phận Kỹ
thuật (Chief Technical Officer – CTO) hoặc Ủy ban Chỉ đao, nhưng
chúng thường phụ thuộc vào thông tin từ một số nguồn. Chúng đã
được thảo luận chi tiết trong Thiết kế Dịch vụ nhưng được tóm tắt ở
đây theo quan điểm chức năng Quản lý Ứng dụng.
Quản lý Ứng dụng sẽ hỗ trợ cho quyết định này trong quá trình Thiết
kế Dịch vụ như sau:
 Định cỡ ứng dụng và dự báo khối lượng công việc (xem phần
4.6.4),
 Những đặc tả kỹ thuật về các yêu cầu về khả năng quản lý,
 Xác định chi phí vận hành liên tục,
 Các yêu cầu truy cập dữ liệu đối với việc báo cáo hoặc tính hợp
trong các ứng dụng khác,
 Điều tra xem ở mức độ nào thì chức năng cần thiết có thể được
đáp ứng bằng các công cụ hiện tại – và việc tùy chỉnh đến mức
nào sẽ cần thiết để đạt được điều này,
 Ước tính chi phí cho việc tùy chỉnh,
 Xác định những kỹ năng nào sẽ được cần đến để hỗ trợ cho
giải pháp (ví dụ, nếu một ứng dụng được mua, nó sẽ đòi hỏi
một tập hợp nhân viên mới không hay những nhân viên hiện tại
có thể được đào tạo để hỗ trợ cho nó?),
 Các yêu cầu quản trị,
 Các yêu cầu bảo mật.
Nếu quyết định là xây dựng ứng dụng, một quyết định bổ sung cần
được đưa ra về việc liệu việc phát triển sẽ được thuê ngoài hoặc
được xây dựng bằng cách sử dụng nhân viên (trong nội bộ tổ chức).
Việc này được mô tả chi tiết trong các ấn phẩm Chiến lược Dịch vụ
và Thiết kế Dịch vụ, nhưng có một số điểm cân nhắc quan trọng ảnh
hưởng đến Vận hành Dịch vụ, ví dụ như:
 Các yêu cầu về khả năng quản lý sẽ được chỉ định và thống
nhất như thế nào (ví dụ, việc thiết kế ứng dụng và giám sát
giao dịch)? Những điều này đôi khi bị lãng quên khi các nhóm
hoặc bộ phận vận hành không hiện diện trong dự án,
 Tiêu chí Chấp thuận đối với hiệu suất vận hành là gì, giải pháp
sẽ được kiểm nghiệm như thế nào và tại thời điểm nào, ai sẽ là
người thực hiện các kiểm nghiệm?
 Ai sẽ sở hữu và quản lý Thư viện Sau cùng cho ứng dụng đó?
 Ai sẽ thiết kế và duy trì các tập lệnh kịch bản quản trị và quản
lý vận hành đối với những ứng dụng đó?
 Ai chịu trách nhiệm cho việc thiết lập nên môi trường và sở
hữu và duy trì các thành phần cơ sở hạ tầng khác?
 Giải pháp sẽ được đo lường như thế nào để từ đó, nó có khả
năng tạo ra các sự kiện được yêu cầu?
6.5.3. 2 Các mô hình V ậ n hành

Một Mô hình Vận hành là đặc tả kỹ thuật về môi trường vận hành mà
trong đó, cuối cùng ứng dụng sẽ hoạt động khi nó được chạy thực
tế. Điều này sẽ được sử dụng trong các giai đoạn kiểm nghiệm và
chuyển tiếp để mô phỏng và đánh giá môi trường thực. Đây là một
cách để đảm bảo rằng ứng dụng có thể được định cỡ một cách chính
xác và các điều kiện môi trường bắt buộc có thể được ghi nhận và
được hiểu bởi tất cả mọi người. Mô hình Vận hành nên được xác định
và sử dụng trong kiểm nghiệm trong suốt các giai đoạn Thiết kế
Dịch vụ và Chuyển tiếp Dịch vụ một cách tương ứng (xem thêm các
ấn phẩm Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ).
6.5.4 Vòng đ ờ i Q uả n lý Ứ ng d ụn g
Vòng đời tiếp theo để phát triển và quản lý các ứng dụng đã được
đề cập đến với rất nhiều tên gọi, bao gồm Vòng đời Phần mềm
(Software Lifecycle- SLC) và Vòng đời Phát triển Phần mềm
(Software Development Lifecycle – SDLC). Chúng thường được sử
dụng bởi các nhóm Phát triển Ứng dụng và các nhà Quản lý Dự án
của chúng để xác định sự liên quan của chúng trong việc thiết kế,
xây dựng, kiểm nghiệm, triển khai và hỗ trợ cho các ứng dụng. Các
ví dụ về những phương pháp tiếp cận này là Phương pháp Thiết kế
và Phân tích các Hệ thống có Cấu trúc (Structured Systems Analysis
and Design Methodology - SSADM), Phương pháp Phát triển Hệ thống
Động (Dynamic Systems Development Method – DSDM), Phát triển
Ứng dụng Nhanh (Rapid Application Development – RAD), v.v…
ITIL chủ yếu quan tâm đến việc quản lý tổng thể các ứng dụng như
một phần của dịch vụ CNTT, cho dù chúng được phát triển nội bộ
hay được mua từ một bên thứ ba. Vì lý do này, thuật ngữ Vòng đời
Quản lý Ứng dụng đã được sử dụng, vì nó ngụ ý một cái nhìn tổng
thể hơn.
Điều này không nên thay thế SDLC, vì đây vẫn là cách tiếp cận hợp
lệ được sử dụng bởi các nhà phát triển, đặc biệt là các công ty phần
mềm bên thứ ba. Tuy nhiên, nó có nghĩa là nên có sự liên kết nhiều
hơn giữa quan điểm phát triển của các ứng dụng và quản lý ‘trực
tiếp’ các ứng dụng đó.
Điều này sẽ khó khăn hơn với các ứng dụng được mua quy mô lớn,
chẳng hạn như e-mail, vì các nhà phát triển thường không tương tác
một cách riêng lẻ với người dùng ứng dụng của họ. Tuy nhiên, vòng
đời cơ bản vẫn đúng ở chỗ ứng dụng cần các yêu cầu, thiết kế, tùy
chỉnh, vận hành và triển khai. Sự tối ưu hóa đạt được thông qua
quản lý tốt hơn, cải tiến đối với các tùy chỉnh và nâng cấp.
Vòng đời Quản lý Ứng dụng được minh họa như sau:
Hình 6.5 – Vòng đời Quản lý Ứng dụng
Các quy trình ITSM và Phát tri ển Ứng dụng phải được liên kết với
nhau như một phần của chiến lược tổng thể của việc cung cấp các
dịch vụ CNTT để hỗ trợ cho doanh nghiệp.
Phát triển Ứng dụng và Vận hành Ứng dụng là những bộ phận của
cùng một vòng đời tổng thể và đều nên được tham gia trong mọi giai
đoạn, mặc dù mức độ tham gia của chúng sẽ khác nhau tùy theo giai
đoạn của vòng đời.
Mối quan hệ giữa Vòng đời Quản lý Ứng dụng và Vòng đời Quản lý Dịch vụ
Vòng đời Quản lý Ứng dụng không nên được coi là giải pháp thay thế cho Vòng đời
Quản lý Dịch vụ. Các ứng dụng là một phần của các dịch vụ và do vậy, cũng phải
được quản lý. Tuy nhiên, các ứng dụng là một sự pha trộn độc đáo giữa công nghệ
và chức năng và điều này đòi hỏi một trọng tâm được chuyên môn hóa tại từng
giai đoạn của Vòng đời Quản lý Dịch vụ.
Từng giai đoạn của Vòng đời Quản lý Ứng dụng có một tập hợp các mục tiêu, hoạt
động, sản phẩm và các nhóm chuyên biệt của riêng mình. Từng giai đoạn cũng sẽ
có một trách nhiệm rõ ràng để đảm bảo rằng những kết quả đầu ra của chúng
khớp với các mục tiêu cụ thể của Vòng đời Quản lý Dịch vụ. Những khía cạnh khác
của Quản lý Ứng dụng được đề cập chi tiết trong từng ấn phẩm ITIL như dưới đây:
 Chiến lược Dịch vụ: Xác định kiến trúc tổng thể của các ứng dụng và cơ sở
hạ tầng. Điều này sẽ bao gồm việc xác định tiêu chí đối với việc phát triển
nội bộ, thuê ngoài việc phát triển, hoặc mua và tùy chính các ứng dụng.
Chiến lược Dịch vụ cũng sẽ hỗ trợ việc xác định Danh mục Dịch vụ (bao gồm
các ứng dụng) vốn cũng sẽ bao gồm những thông tin về Lợi nhuận trên
Khoản đầu tư của các ứng dụng và các dịch vụ mà chúng (các ứng dụng) hỗ
trợ. Do đó, các yêu cầu cấp cao được thiết lập trong giai đoạn này.
 Thiết kế Dịch vụ: Giúp thiết lập các yêu cầu đối với chức năng và khả năng
quản lý của các ứng dụng và cộng tác với các nhóm Phát triển để đảm bảo
rằng chúng đáp ứng được những mục tiêu này. Thiết kế Dịch vụ bao hàm
phần lớn giai đoạn Yêu cầu và được tham gia vào trong giai đoạn Xây dựng
của Vòng đời Quản lý Ứng dụng.
 Chuyển tiếp Dịch vụ: Các nhóm Quản lý và Phát triển Ứng dụng được tham
gia vào việc kiểm nghiệm và xác minh xem những gì đã được xây dựng và
triển khai nó một cách hoạt động được.
 Vận hành Dịch vụ: Bao hàm giai đoạn Vận hành của Vòng đời Quản lý Ứng
dụng. Những quy trình và cấu trúc này được thảo luận chi tiết hơn trong ấn
phẩm này.
 Liên tục Cải tiến Dịch vụ: Bao hàm giai đoạn Tối ưu hóa của Vòng đời Quản
lý Ứng dụng. Liên tục Cải tiến Dịch vụ đo lường chất lượng và sự liên quan
của các ứng dụng trong vận hành và cung cấp các khuyến nghị về cách làm
thế nào để cải tiến các ứng dụng nếu có một Lợi nhuận trên Khoản đầu tư rõ
ràng để làm thế.
6.5.4. 1 Các yêu c ầ u

Đây là giai đoạn mà trong đó, các yêu cầu đối với một ứng dụng mới
được thu thập, dựa trên các nhu cầu kinh doanh của tổ chức. Giai
đoạn này chủ yếu hoạt động trong giai đoạn Thiết kế Dịch vụ của
Vòng đời ITSM.
Có 6 kiểu yêu cầu cho bất kỳ một ứng dụng nào, dù cho được phát
triển nội bộ, được thuê ngoài hoặc được mua:
 Các yêu cầu chức năng là những yêu cầu đặc biệt cần thiết để
hỗ trợ cho một chức năng nghiệp vụ cụ thể.
 Các yêu cầu về khả năng quản lý, được xem xét từ quan điểm
Quản lý Dịch vụ, xác định nhu cầu đối với một dịch vụ dễ điều
khiển, sẵn sàng và bảo mật, và xử lý những vấn đề như triển
khai, vận hành, quản lý hệ thống và bảo mật.
 Các yêu cầu về tính tiện dụng là những yêu cầu xác định nhu
cầu của người dùng đầu cuối, và kết quả là các tính năng của
hệ thống tạo điều kiện cho việc dễ dàng sử dụng của họ.
 Các yêu cầu kiến trúc, đặc biệt nếu yêu cầu này đòi hỏi một
thay đổi đối với các tiêu chuẩn kiến trúc hiện hành.
 Các yêu cầu về giao diện, nơi có các phụ thuộc giữa các ứng
dụng hoặc công cụ hiện hữu với ứng dụng mới.
 Các Yêu cầu Mức Dịch vụ, chỉ định cách mà dịch vụ nên thực
hiện như thế nào, chất lượng của kết quả đầu ra của nó, và bất
kỳ khía cạnh định tính nào được đo lường bởi người dùng hoặc
khách hàng.
6.5.4. 2 Thiết k ế
Đây là giai đoạn mà các yêu cầu được diễn dịch thành các đặc tả
thông số kỹ thuật. Thiết kế bao gồm thiết kế của chính bản thân ứng
dụng và thiết kế của môi trường hoặc mô hình hoạt động mà ứng
dụng phải hoạt động trên đó. Những cân nhắc về kiến trúc là khía
cạnh quan trọng nhất của giai đoạn này, vì chúng có thể tác động
đến cấu trúc và nội dung của cả ứng dụng và mô hình hoạt động.
Các cân nhắc về kiến trúc đối với ứng dụng (thiết kế kiến trúc ứng
dụng) và các cân nhắc về kiến trúc đối với mô hình hoạt động (thiết
kế của kiến trúc hệ thống) có liên quan chặt chẽ một cách và cần
phải được liên kết với nhau.
Trong trường hợp phần mềm được mua, hầu hết các tổ chức sẽ
không được phép nhập trực tiếp vào thiết kế của phần mềm (vốn đã
được xây dựng). Tuy nhiên, điều quan trọng là Quản lý Ứng dụng có
thể cung cấp phản hồi cho nhà cung cấp phần mềm về chức năng,
khả năng quản lý và hiệu suất của phần mềm. Đến lượt nó, điều này
sẽ được nhà cung cấp phần mềm tiếp nhận như một phần của quá
trình liên tục cải tiến phần mềm.
Một phần của quá trình đánh giá đối với phần mềm đã được mua nên
bao gồm việc đánh giá xem liệu nhà cung cấp có hồi đáp những
phản hồi đó hay không. Đồng thời, họ nên đảm bảo rằng có một sự
cân bằng giữa việc đáp ứng và thay đổi phần mềm của họ quá nhiều
đến mức nó gây ra sự gián đoạn hoặc thay đổi một số chức năng cơ
bản.
Thiết kế cho phần mềm đã được mua cũng sẽ bao gồm thiết kế bất
kỳ tùy chỉnh cần thiế nào. Điều đặc biệt quan trọng ở đây là đánh
giá xem liệu phiên bản tương lai của phần mềm có hỗ trợ việc tùy
chỉnh hay không.
6.5.4. 3 Xây d ựng

Trong giai đoạn Xây dựng, cả ứng dụng lẫn mô hình vận hành thực
sự sẵn sàng để triển khai. Các thành phần ứng dụng được viết mã
hoặc được mua, tích hợp và kiểm nghiệm.
Hãy lưu ý rằng Kiểm nghiệm không phải là một phân đoạn tách biệt
trong vòng đời, mặc dù nó là một hoạt động rời rạc, và thậm chí các
kiểm nghiệm được tiến hành một cách độc lập với cả các hoạt động
phát triển lẫn vận hành. Nếu không có các giai đoạn Xây dựng và
Triển khai, sẽ không có gì để được kiểm nghiệm và, không có kiểm
nghiệm nghĩa là sẽ không có biện pháp kiểm soát những gì đã được
phát triển và triển khai.
Việc kiểm nghiệm là một thành phần không thể thiếu của cả giai
đoạn Xây dựng lẫn Vận hành như một sự xác minh về hoạt động và
kết quả đầu ra của các giai đoạn đó - ngay cả khi nếu nó sử dụng
các môi trường và nhân viên khác nhau. Việc kiểm nghiệm trong giai
đoạn Xây dựng tập trung vào việc liệu ứng dụng có đáp ứng các đặc
tả thông số kỹ thuật về chức năng và khả năng quản lý hay không.
Thông thường, sự phân biệt được đưa ra giữa môi trường phát triển
và kiểm nghiệm. Môi trường kiểm nghiệm cho phép kiểm nghiệm sự
kết hợp giữa ứng dụng và mô hình hoạt động. Kiểm nghiệm được đề
cập trong ấn phẩm Chuyển tiếp Dịch vụ ITIL.
Đối với phần mềm đã được mua, điều này sẽ liên quan đến việc mua
sắm trong thực tế ứng dụng, bất kỳ phần mềm trung gian bắt buộc
nào cũng như phần cứng và thiết bị mạng liên quan. Bất kỳ tùy
chỉnh nào được yêu cầu sẽ cần phải được thực hiện ở đây, cũng như
việc tạo ra các bảng biểu, danh mục, v.v... sẽ được sử dụng. Điều
này thường được thực hiện dưới dạng triển khai thí điểm bởi nhóm
hoặc bộ phận Quản lý Ứng dụng có liên quan.
6.5.4. 4 Triển khai

Trong giai đoạn này, cả mô hình vận hành và ứng dụng đều được
triển khai. Mô hình vận hành được kết hợp trong môi trường CNTT
hiện có và ứng dụng được cài đặt bên trên đỉnh của mô hình vận
hành, sử dụng quy trình Quản lý triển khai và phát hành đã được mô
tả trong ấn phẩm Chuyển đổi dịch vụ ITIL.
Việc kiểm nghiệm cũng diễn ra trong giai đoạn này, mặc dù ở đây,
trọng tâm là để đảm bảo rằng quá trình và cơ chế triển khai hoạt
động một cách hiệu quả, ví dụ, kiểm tra xem ứng dụng có còn hoạt
động theo đặc tả thông số kỹ thuật sau khi đã được tải xuống và cài
đặt hay không. Điều này được gọi là Hỗ trợ Đầu đời và bao gồm một
khoảng thời gian đảm bảo được xác định trước rằng việc kiểm tra,
xác nhận và giám sát một ứng dụng hoặc dịch vụ mới trong khoảng
thời gian đó sẽ xảy ra. Hỗ trợ Đầu đời được đề cập chi tiết trong ấn
phẩm Chuyển tiếp Dịch vụ.
6.5.4. 5 V ậ n hành
Trong giai đoạn Vận hành, tổ chức các dịch vụ CNTT vận hành ứng
dụng như một phần của việc cung cấp một dịch vụ được yêu cầu bởi
doanh nghiệp. Hiệu suất của ứng dụng liên quan đến dịch vụ tổng
thể được đo lường một cách liên tục so với các Mức Dịch vụ và
những động cơ kinh doanh chủ yếu. Điều quan trọng là phân biệt
rằng bản thân các ứng dụng không ngang bằng với một dịch vụ. Một
điều phổ biến trong các tổ chức là đề cập đến các ứng dụng như là
‘các dịch vụ’, tuy nhiên, các ứng dụng chỉ là một trong rất nhiều
thành phần cần thiết để cung cấp một dịch vụ nghiệp vụ.
Giai đoạn Vận hành không chỉ dành riêng cho các ứng dụng và được
thảo luận trong toàn bộ ấn phẩm này, với một danh sách các hoạt
động chi tiết hơn được đưa ra trong phần 6.5.5 duới đây.
6.5.4. 6 Tối ưu hó a
Trong giai đoạn Tối ưu hóa, kết quả của các phép đo hiệu suất Mức
Dịch vụ được đo lường, được phân tích và thực hiện. Các cải tiến
khả thi được thảo luận và bắt đầu phát triển nếu cần thiết. Hai
chiến lược chính trong giai đoạn này là duy trì và/hoặc cải thiện Mức
Dịch vụ và chi phí thấp hơn. Điều này có thể dẫn đến sự lặp lại
trong vòng đời hoặc dẫn đến ngừng hoạt động một dịch vụ.
Một điều quan trọng cần phải nhớ về Vòng đời Quản lý Ứng dụng là,
bởi vì nó là vòng tròn nên cùng một ứng dụng có thể nằm trong các
giai đoạn khác nhau của vòng đời tại cùng một thời điểm. Ví dụ, khi
phiên bản tiếp theo của ứng dụng đang được thiết kế, và phiên bản
hiện tại vẫn đang được triển khai, phiên bản trước đó có thể vẫn
đang hoạt động trong các bộ phận của tổ chức. Điều này rõ ràng yêu
cầu biện pháp kiểm soát phiên bản, kiểm soát cấu hình và kiểm soát
phát hành mạnh mẽ.
Các giai đoạn cụ thể có thể mất nhiều thời gian hơn hoặc trông có
vẻ quan trọng hơn những giai đoạn khác, nhưng tất cả chúng đều
rất quan trọng. Mọi ứng dụng đều phải trải qua tất cả chúng ít nhất
một lần và do tính chất vòng tròn của vòng đời, sẽ trải qua một số
lần.
Phương pháp tiếp cận này cũng hỗ trợ các phương pháp tiếp cận
phát triển lặp đi lặp lại, trong đó phần mềm liên tục được phát triển
theo các bước gia tăng dần. Từng bước tuân theo vòng đời và ứng
dụng được xây dựng gia tăng dần, sử dụng các ưu tiên kinh doanh
làm động cơ thúc đẩy.
Giao tiếp tốt là chìa khóa khi một ứng dụng hoạt động theo cách của
nó qua các giai đoạn của vòng đời. Điều tối quan trọng là thông tin
chất lượng cao được chuyển đi bởi những người xử lý ứng dụng
trong một giai đoạn tồn tại của nó cho những người xử lý ứng dụng
đó trong giai đoạn tiếp theo. Một điều cũng rất quan trọng nữa là tổ
chức phải giám sát chất lượng của Vòng đời Quản lý Ứng dụng.
Những thay đổi trong vòng đời, ví dụ như trong cách thức mà một tổ
chức chuyển thông tin giữa các giai đoạn khác nhau, sẽ ảnh hưởng
đến chất lượng của nó. Việc hiểu được các đặc điểm của mọi giai
đoạn trong Vòng đời Quản lý Ứng dụng là rất quan trọng để cải
thiện chất lượng của toàn thể. Các phương pháp và công cụ được sử
dụng trong một giai đoạn có thể có một tác động đến các giai đoạn
khác, trong khi tối ưu hóa một giai đoạn có thể tối ưu hóa phụ thêm
cho toàn bộ.
6.5.5 Các ho ạ t đ ộng Q u ả n lý Ứ ng d ụn g nói chung
Trong khi hầu hết các nhóm hoặc bộ phận Quản lý Ứng dụng được
chuyên biệt hóa cho các ứng dụng hoặc bộ các ứng dụng cụ thể, vẫn
có một số các hoạt động là phổ biến giữa họ. Các hoạt động này bao
gồm:
 Xác định kiến thức và chuyên môn cần thiết để quản lý và vận
hành các ứng dụng liên quan đến việc cung cấp các dịch vụ
CNTT. Quy trình này khởi đầu trong giai đoạn Chiến lược Dịch
vụ, được mở rộng chi tiết trong Thiết kế Dịch vụ và được thực
thi trong Vận hành Dịch vụ. Liên tục đánh giá và cập nhật các
kỹ năng này được thực hiện trong quá trình Liên tục Cải tiến
Dịch vụ,
 Khởi đầu các chương trình đào tạo để phát triển và hoàn thiện
các kỹ năng trong các nguồn lực Quản lý Ứng dụng thích hợp
và duy trì hồ sơ đào tạo cho những tài nguyên này,
 Tuyển dụng hoặc ký hợp đồng các nguồn lực có kỹ năng không
thể được phát triển trong nội bộ hoặc không có đủ nhân sự để
thực hiện các hoạt động Quản lý Ứng dụng cần thiết,
 Thiết kế và cung cấp đào tạo cho người dùng đầu cuối. Việc
đào tạo có thể được phát triển và cung cấp bởi các nhóm Phát
triển Ứng dụng hoặc Quản lý Ứng dụng hoặc bởi một bên thứ
ba, nhưng Quản lý Ứng dụng chịu trách nhiệm cho việc đảm
bảo rằng việc đào tạo được tiến hành khi thích hợp,
 Nguồn cung cấp nội bộ cho các hoạt động cụ thể mà các kỹ
năng cần thiết không có sẵn trong nội bộ hoặc trên thị trường
mở, hoặc nơi có hiệu quả hơn về chi phí để thực hiện điều này,
 Định nghĩa các tiêu chuẩn được sử dụng trong việc thiết kế
những kiến trúc mới và tham gia vào việc định nghĩa các kiến
trúc ứng dụng trong quá trình Chiến lược Dịch vụ,
 Nghiên cứu và phát triển các giải pháp có thể giúp mở rộng
Danh mục Dịch vụ hoặc có thể được sử dụng để đơn giản hóa
hoặc tự động hóa Vận hành CNTT, giảm chi phí hoặc gia tăng
mức dịch vụ CNTT,
 Tham gia vào việc thiết kế và xây dựng các dịch vụ mới. Tất cả
các nhóm hoặc bộ phận Quản lý Ứng dụng sẽ đóng góp vào
việc thiết kế các tiêu chuẩn Hiệu suất và Kiến trúc Kỹ thuật đối
với Dịch vụ CNTT. Ngoài ra, họ cũng sẽ chịu trách nhiệm cho
việc xác định các hoạt động vận hành cần thiết để quản lý các
ứng dụng một cách liên tục,
 Tham gia vào các dự án, không chỉ trong quá trình Thiết kế
Dịch vụ, mà còn cho Liên tục Cải tiến Dịch vụ hoặc các dự án
vận hành, chẳng hạn như nâng cấp Hệ điều hành, dự án hợp
nhất hoặc di chuyển vật lý máy chủ,
 Thiết kế và thực hiện các bài kiểm tra về chức năng, hiệu suất
và khả năng quản lý của Dịch vụ CNTT (lưu ý rằng việc kiểm
tra phải được kiểm soát và thực hiện bởi một người kiểm tra
độc lập - xem ấn phẩm Chuyển đổi Dịch vụ),
 Quản lý Tính sẵn sàng và Quản lý Công suất phụ thuộc vào
Quản lý Ứng dụng vì đã đóng góp vào việc thiết kế các ứng
dụng để đáp ứng các mức dịch vụ theo yêu cầu của doanh
nghiệp. Điều này có nghĩa rằng việc mô hình hóa và dự báo
khối lượng công việc thường được thực hiện cùng với các
nguồn lực Quản lý Kỹ thuật và Quản lý Ứng dụng,
 Hỗ trợ việc đánh giá rủi ro, xác định các dịch vụ tối quan trọng
và phụ thuộc vào hệ thống, đồng thời xác định và triển khai
các biện pháp ứng phó,
 Quản lý các nhà cung cấp. Nhiều bộ phận hoặc nhóm Quản lý
Ứng dụng là những người duy nhất biết chính xác yêu cầu của
nhà cung cấp cũng như cách thức đo lường và quản lý chúng.
Vì lý do này, rất nhiều tổ chức dựa vào Quản lý Ứng dụng để
quản lý hợp đồng với các nhà cung cấp ứng dụng cụ thể. Nếu
đúng như vậy, điều quan trọng là phải đảm bảo rằng các mối
quan hệ này được quản lý như một phần của quy trình SLM,
 Tham gia vào việc xác định các tiêu chuẩn Quản lý Sự kiện và
đặc biệt là trong việc đo lường các ứng dụng để tạo ra các sự
kiện có ý nghĩa,
 Quản lý ứng dụng như một chức năng cung cấp các ngồn lực
thực thi quy trình Quản lý Sự cố. Đó là kiến thức và chuyên
môn kỹ thuật của họ được sử dụng để chẩn đoán và giải quyết
các vấn đề. Đó cũng là mối quan hệ của họ với các nhà cung
cấp được sử dụng để leo thang và theo dõi với các nhóm hoặc
bộ phận hỗ trợ của nhà cung cấp,
 Các nguồn lực của Quản lý Ứng dụng sẽ tham gia vào việc xác
định các hệ thống mã hóa được sử dụng trong Quản lý Sự cố và
Sự cố (ví dụ, Danh mục Sự cố),
 Tài nguyên Quản lý Ứng dụng được sử dụng để hỗ trợ cho Quản
lý Vấn đề trong việc xác minh và duy trì KEDB cùng với các
nhóm Phát triển Ứng dụng,
 Quản lý Thay đổi dựa trên kiến thức kỹ thuật và chuyên môn
để đánh giá các thay đổi và rất nhiều thay đổi sẽ được xây
dựng bởi các nhóm Quản lý Ứng dụng,
 Thành công của Quản lý Phát hành phụ thuộc vào sự tham gia
từ nhân viên Quản lý Ứng dụng. Trên thực tế, họ (nhân viên
Quản lý Ứng dụng) thường là động cơ thúc đẩy của quy trình
Quản lý Phát hành cho các ứng dụng của họ,
 Quản lý Ứng dụng sẽ xác định, quản lý và duy trì các thuộc
tính và mối quan hệ của các Đơn vị Cấu hình ứng dụng trong
CMS,
 Quản lý Ứng dụng tham gia vào các quy trình Liên t ục Cải tiến
Dịch vụ, đặc biệt trong việc xác định các cơ hội cải tiến và sau
đó giúp đánh giá các giải pháp thay thế,
 Quản lý Ứng dụng đảm bảo rằng mọi hệ thống và tài liệu vận
hành đều được cập nhật và sử dụng đúng cách. Điều này bao
gồm việc đảm bảo rằng tất cả các tài liệu hướng dẫn thiết kế,
quản lý và sử dụng đều được cập nhật và hoàn chỉnh và rằng
nhân viên Quản lý Ứng dụng và người dùng đã quen thuộc với
nội dung của chúng (các tài liệu),
 Phối hợp với Quản lý Kỹ thuật để thực hiện Phân tích Nhu cầu
Đào tạo và duy trì Kho Kỹ năng,
 Hỗ trợ Quản lý Tài chính CNTT để xác định chi phí của việc
quản lý liên tục các ứng dụng,
 Tham gia vào việc xác định các hoạt động vận hành được thực
hiện như một phần của Quản lý Vận hành CNTT. Nhiều bộ phận,
nhóm hoặc đội Quản lý Ứng dụng cũng thực hiện các hoạt động
tác nghiệp như một phần của chức năng Quản lý Vận hành
CNTT của tổ chức,
 Nhập vào và duy trì các chính sách cấu hình phần mềm,
 Cùng với các nhóm Phát triển phần mềm, định nghĩa và duy trì
tài liệu liên quan đến các ứng dụng. Chúng sẽ bao gồm hướng
dẫn sử dụng, hướng dẫn quản trị và quản lý, cũng như bất kỳ
SOP nào cần thiết để quản lý các khía cạnh vận hành của ứng
dụng.
Các nhóm hoặc bộ phận Quản lý Ứng dụng sẽ được cần đến cho mọi
ứng dụng then chốt. Bản chất chính xác của vai trò sẽ khác nhau tùy
thuộc vào các ứng dụng đang được hỗ trợ, nhưng những trách nhiệm
chung có khả năng bao gồm:
 Hỗ trợ cấp độ-thứ ba cho các sự cố liên quan đến (các) ứng
dụng được bảo đảm bởi nhóm hoặc bộ phận đó,
 Tham gia vào vận hành các kế hoạch kiểm nghiệm và các vấn
đề trong triển khai,
 Theo dõi các lỗi ứng dụng và quản lý bản vá (sửa mã phần
mềm đối với mã phần mềm [được phát triển] trong nội bộ,
truyền tải/bản vá lỗi cho mã phần mềm của bên thứ ba),
 Tham gia vào việc áp dụng các vấn đề có tính chất vận hành và
hỗ trợ chẳng hạn như thiết kế mã lỗi, thông điệp lỗi, các móc
quản lý sự kiện,
 Định cỡ và hiệu suất ứng dụng, các chỉ số khối lượng và tải
kiểm nghiệm, v.v… Điều này hỗ trợ cho các quy trình Quản lý
Công suất và Quản lý Tính sẵn sàng,
 Tham gia vào việc phát triển các Chính sách Phát hành,
 Xác định những điểm tăng cường đối với phần mềm hiện tại, từ
cả quan điểm chức năng lẫn khả năng quản lý.
6.5.6 Sự tổ c h ức Q u ả n lý Ứ ng d ụng
Mặc dù mọi bộ phận, đội hoặc nhóm Quản lý Ứng dụng đều thực hiện
các hoạt động tương tự nhau nhưng từng ứng dụng hoặc bộ các ứng
dụng có một bộ các yêu cầu vận hành và quản lý khác nhau. Các ví
dụ về những khác biệt này bao gồm:
 Mục đích của ứng dụng. Mỗi ứng dụng được phát triển để
đáp ứng một bộ các mục tiêu cụ thể, thường là các mục tiêu
kinh doanh. Để hỗ trợ và cải tiến có hiệu quả, nhóm đang quản
lý ứng ụng đó cần phải có một hiểu biết toàn diện về bối cảnh
của doanh nghiệp và cách thức mà ứng dụng được sử dụng để
đáp ứng các mục tiêu của doanh nghiệp như thế nào. Thường
có thể đạt được điều này bởi các Chuyên gia phân tích Nghi ệp
vụ, người gần gũi với doanh nghiệp và chịu trách nhiệm cho
việc đảm bảo rằng các yêu cầu nghiệp vụ đã được diễn giải một
cách hiệu quả thành những đặc tả kỹ thuật của ứng dụng.
Chuyên gia phân tích Nghiệp vụ nên công nhận rằng các yêu
cầu nghiệp vụ phải được diễn giải thành những đặc tả kỹ thuật
về cả chức năng lẫn khả năng quản lý.
 Chức năng của ứng dụng. Mỗi ứng dụng được thiết kế để
hoạt động theo những cách khác nhau và để thực hiện những
chức năng khác nhau tại những thời điểm khác nhau.
 Nền tảng mà ứng dụng đang chạy trên đó. Mặc dù nền tảng
thường được quản lý bởi một nhóm hoặc bộ phận Quản lý Kỹ
thuật nhưng mỗi một trong số chúng có ảnh hưởng đến cách
thức mà theo đó, một ứng dụng cần phải được quản lý và vận
hành.
 Kiểu hoặc nhãn hiệu của công nghệ được sử dụng. Ngay cả
những ứng dụng có các chức năng tương tự cũng vận hành
khác nhau trên những cơ sở dữ liệu hoặc nền tảng khác nhau.
Những khác biệt này phải được hiểu rõ nhằm quản lý ứng dụng
một cách hiệu quả.
Ngay cả khi các hoạt động để quản lý những ứng dụng đó là chung
chung, lịch trình cụ thể của các hoạt động và cách thức mà chúng
được thực hiện cũng sẽ khác nhau. Vì lý do này, các nhóm và b ộ
phận Quản lý Ứng dụng có khuynh huớng được tổ chức theo thể loại
của các ứng dụng mà họ hỗ trợ. Các ví dụ điển hình của tổ chức
Quản lý Ứng dụng bao gồm:
 Các ứng dụng Tài chính. Trong những tổ chức lớn hơn, nơi mà
một số các ứng dụng khác nhau được sử dụng cho các khía
cạnh khác nhau của Quản lý Tài chính, có thể có một số bộ
phận, nhóm hoặc đội quản lý những ứng dụng đó, ví dụ, Debtor
và Creditor, Phân tích Độ tuổi, Sổ cái kế toán, v.v…
 Các ứng dụng thông điệp và cộng tác,
 Các ứng dụng Nhân sự,
 Các ứng dụng hỗ trợ sản xuất,
 Tự động hóa lực lượng bán hàng,
 Các ứng dụng xử lý đơn hàng,
 Các ứng dụng trung tâm cuộc gọi và tiếp thị,
 Các ứng dụng nghiệp vụ cụ thể (ví dụ, chăm sóc sức khỏe, bảo
hiểm, ngân hàng, v.v…),
 Các ứng dụng CNTT, chẳng hạn như Bộ phận Hỗ trợ Dịch vụ,
Quản lý Hệ thống Doanh nghiệp, v.v…
 Các cổng thông tin web,
 Mua sắm trực tuyến.
6.5.6. 1 Vai trò t ổ c h ức

Theo truyền thống, các nhóm và bộ phận Quản lý và Phát triển Ứng
dụng là các đơn vị tự quản. Mỗi nhóm hoặc bộ phận quản lý môi
trường của riêng mình theo cách thức của riêng mình và có các
tương tác riêng biệt với doanh nghiệp. Điều này được minh họa
trong Bảng 6.2.
Phát triển Ứng dụng Quản lý Ứng dụng
Trọng tâm chính Xây dựng chức năng cho khách hàng của họ. Tập trung vào việc chức năng là gì cũng như
Những gì ứng dụng thực hiện là quan trọng là cách thức cung cấp nó như thế nào.
hơn với họ so với cách mà nó được vận hành Các khía cạnh có khả năng quản lý của ứng
như thế nào. dụng, nghĩa là cách làm thế nào để đảm bảo
tính ổn định và hiệu suất của ứng dụng.
Chế độ quản lý Hầu hết công việc phát triển được thực hiện Hầu hết công việc được thực hiện như một
trong các dự án, nơi mà trọng tâm được đặt phần của các quy trình liên tục và lặp đi lặp
vào việc cung cấp những đơn vị công việc cụ lại. Một lượng tương đối ít nhân sự hoạt động
thể theo đặc tả kỹ thuật, đúng giờ và hợp trong các dự án.
ngân sách.
Điều này có nghĩa rằng thường sẽ khó khăn Điều này có nghĩa rằng rất khó đối với nhân
đối với các nhà phát triển để hiểu và xây viên vận hành để tham gia vào các dự án phát
dựng các hoạt động liên tục, đặc biệt khi họ triển, vì điều đó khiến họ bị tách ra khỏi
không sẵn sàng để hỗ trợ cho ứng dụng khi ‘công việc thực tế’ của họ.
họ phải chuyển sang dự án tiếp theo.
Đo lường Nhân viên được tưởng thưởng vì sự sáng tạo Nhân viên được tưởng thưởng cho tính nhất
và cho sự hoàn thành một dự án để từ đó họ quán và cho việc ngăn ngừa những sự kiện
có thể chuyển sang dự án kế tiếp. không mong muốn và các tính năng trái phép
(ví dụ ‘chuông và còi” đã được thêm bởi các
nhà phát triển).
Chi phí Các dự án phát triển tương đối dễ định Chi phí quản lý liên tục thường được trộn lẫn
lượng do những nguồn lực đã được biết và với chi phí của các dịch vụ CNTT khác vì
dễ dàng liên kết các khoản chi tiêu của họ những nguồn lực thường được chia sẻ qua
với một ứng dụng hoặc dịch vụ CNTT cụ thể. nhiều dịch vụ và ứng dụng CNTT.
Vòng đời Nhân viên phát triển tập trung vào các Vòng Nhân viên tham gia vào quản lý liên tục
đời Phát triển Phần mềm, làm nổi bật các thường chỉ kiểm soát một hoặc hai giai đoạn
phụ thuộc đối với vận hành thành công, của những vòng đời này – Vận hành và Cải
nhưng không chỉ định trách nhiệm giải trình thiện.
cho những phụ thuộc này.
Bảng 6.2 Các vai trò tổ chức
Trong vài năm vừa qua, hai thế giới nay đang được kết hợp cùng
nhau bởi những động thái gần đây đối với những phương pháp tiếp
cận Định hướng Đối tượng và SOA, cùng với sức ép ngày càng tăng
từ Doanh nghiệp để ứng phó và làm việc dễ dàng hơn.
Điều này có nghĩa rằng Phát triển Ứng dụng sẽ có trách nhiệm giải
trình lớn hơn đối với sự thành công của việc vận hành các ứng dụng
mà họ thiết kế, trong khi Quản lý Ứng dụng sẽ tham gia nhiều hơn
vào việc phát triển các ứng dụng.
Điều này không làm thay đổi vai trò nền tảng cơ bản của từng nhóm,
nhưng nó sẽ đòi hỏi một phương pháp tiếp cận được tích hợp hơn
đối với SLC. Nó cũng sẽ có nghĩa là kết quả đầu ra của Phát triển
Ứng dụng sẽ sẽ được thương mại hóa nhiều hơn, và Quản lý Ứng
dụng sẽ tham gia nhiều hơn vào các dự án Phát triển.
Điều này sẽ đòi hỏi những thay đổi dưới đây:
 Một giao diện đơn lẻ đối với doanh nghiệp cho mọi giai đoạn
của vòng đời và các yêu cầu phổ biến và đặc tả kỹ thuật-thiết
lập quy trình,
 Một thay đổi trong cách thức mà cả nhân viên Phát triển và
Quản lý [Ứng dụng] được đo lường. Các nhóm Phát triển nên
chịu một phần trách nhiệm cho các lỗi thiết kế gây ra tình
trạng gián đoạn hoạt động. Nhân viên Quản lý nên chịu một
phần trách nhiệm về việc đóng góp vào kiến trúc kỹ thuật và
thiết kế khả năng quản lý của các ứng dụng,
 Một quy trình Quản lý Thay đổi duy nhất cho cả hai nhóm, với
Kiểm soát Thay đổi cho từng nhóm là cấp dưới đối với thẩm
quyền Quản lý Thay đổi tổng thể (xem ấn phẩm Chuyển tiếp
Dịch vụ),
 Một bản đồ rõ ràng về các hoạt động Phát triển và Quản lý
trong vòng đời, vốn được minh họa tại cấp độ cao trong Hình
6.5. Các hoạt động chính xác và cách mà chúng tương tác như
thế nào nên được xác định trong từng tổ chức, mặc dù một số
hướng dẫn phổ quát được đưa ra trong từng ấn phẩm ITIL,
 Tập trung nhiều hơn vào việc tích hợp các yêu cầu chức năng
và khả năng quản lý vào dự án ngay từ đầu.
Hình 6.6 minh họa cho một Vòng đời Quản lý Ứng dụng phổ biến
cùng với sự tham gia từ cả hai nhóm. Trong sơ đồ này, rõ ràng là
Phát triển Ứng dụng sẽ định hướng một số giai đoạn với đầu vào từ
Quản lý Ứng dụng. Ttong những trường hợp khác, Quản lý Ứng dụng
sẽ thúc đẩy giai đoạn này với đầu vào và sự hỗ trợ từ Phát triển Ứng
dụng. Cả hai nhóm đều phụ thuộc vào Chiến lược CNTT của tổ chức
và những nỗ lực của họ được kết hợp trong các quy trình và cơ chế
Chuển tiếp Dịch vụ.
Hình 6.6 – Vai trò của các nhóm trong Vòng đời Quản lý Ứng dụng
6.5.7 Vai trò và trách nhi ệm c ủ a Q u ản lý Ứ ng

dụng
6.5.7. 1 Các Nhà qu ả n lý/T rư ở ng nhóm Ứng d ụng

Một nhà Quản lý Ứng dụng hoặc Trưởng nhóm (tùy thuộc vào quy mô
và/hoặc tầm quan trọng của nhóm hoặc bộ phận và ứng dụng mà họ
hỗ trợ, và cấu trúc và văn hóa của tổ chức) sẽ được cần đến cho
từng nhóm hoặc bộ phận ứng dụng. Vai trò này sẽ:
 Chịu trách nhiệm tổng thể đối với sự lãnh đạo, kiểm soát và
đưa ra quyết định cho nhóm hoặc bộ phận ứng dụng,
 Cung cấp kiến thức kỹ thuật và sự lãnh đạo trong các hoạt
động hỗ trợ ứng dụng cụ thể được bao hàm bởi nhóm hoặc
bộ phận,
 Đảm bảo việc đào tạo kỹ thuật cần thiết, các mức nhận thức
và trải nghiệm được duy trì trong phạm vi nhóm hoặc bộ
phận có liên quan đến ứng dụng đang được hỗ trợ và các
quy trình đang được sử dụng,
 Tham gia vào giao tiếp liên tục với người dùng và khách
hàng bất kể hiệu suất của ứng dụng và tiến triển các yêu
cầu nghiệp vụ,
 Báo cáo cho quản lý cấp cao về mọi vấn đề liên quan đến
các ứng dụng đang được hỗ trợ,
 Hoàn thành quản lý theo tuyến đối với mọi thành viên của
nhóm hoặc bộ phận.
6.5.7. 2 Chuyên viên phâ n tích/Ki ến trú c sư Ứng

dụng
Chuyên viên phân tích và Kiến trúc sư Ứng dụng chịu trách nhiệm
cho việc khớp các yêu cầu đối với các đặc tả kỹ thuật ứng dụng.
Những hoạt động cụ thể bao gồm:
 Làm việc với người dùng, nhà bảo trợ và tất cả các bên liên
quan khác để xác định những nhu cầu đang tiến triển của
họ,
 Làm việc với Quản lý Kỹ thuật để xác định mức yêu cầu dịch
vụ cao nhất cần thiết để đáp ứng các yêu cầu doanh nghiệp
trong phạm vi những ràng buộc về ngân sách và công nghệ,
 Thực hiện phân tích lợi ích-chi phí để xác định phương tiện
thích hợp nhất để đáp ứng các yêu cầu đã được nêu ra,
 Phát triển các Mô hình Vận hành sẽ đảm bảo việc sử dụng
tối ưu những nguồn lực và mức hiệu suất tương xứng,
 Đảm bảo rằng các ứng dụng được thiết kế để được quản lý
một cách hiệu quả với kiến trúc công nghệ, các kỹ năng và
công cụ sẵn có của tổ chức,
 Phát triển và duy trì các tiêu chuẩn dành cho định cỡ ứng
dụng, mô hình hóa hiệu suất, v.v…
 Tạo ra một bộ các yêu cầu kiểm nghiệm chấp thuận, cùng
với các nhà thiết kế, kỹ sư kiểm nghiệm và người dùng, để
xác định rằng mọi yêu cầu cấp cao đã được đáp ứng cả về
mặt chức năng lẫn khả năng quản lý,
 Đầu vào của thiết kế của dữ liệu cấu hình cần thiết để quản
lý và theo dõi ứng dụng một cách hiệu quả.
Một lượng Chuyên gia phân tích Ứng dụng thích hợp sẽ được cần đến
cho từng nhóm hoặc bộ phận Quản lý Ứng dụng để thực hiện những
hoạt động chung chung đã được mô tả trong đoạn 6.5.5.
Những cách thức mà theo đó, các nhóm Quản lý Ứng dụng có thể
được tổ chức, và các tùy chọn sẵn có, được thảo luận chi tiết hơn
trong phần 6.7 dưới đây.
6.5.8 Các ch ỉ s ố Q uả n lý Ứ ng d ụng
Các chỉ số dành cho Quản lý Ứng dụng sẽ phụ thuộc phần lớn vào
những ứng dụng nào đang được quản lý, nhưng một số chỉ số phổ
quát bao gồm:
 Thước đo kết quả đầu ra đã được thống nhất. Chúng có

thể bao gồm:
o Khả năng người dùng có thể truy cập vào ứng dụng và
các chức năng của nó,
o Các báo cáo và các tập tin được truyền tải cho người
dùng,
o Tỷ lệ giao dịch và tính sẵn sàng đối với các giao dịch
nghiệp vụ tối quan trọng,
o Ghi nhận các giải pháp cho vấn đề vào KEDB,
o Người dùng đo lường chất lượng của những kết quả đầu
ra như đã được xác định trong KEDB,
 Các chỉ số quy trình. Các nhóm Quản lý Kỹ thuật thực thi
rất nhiều hoạt động quy trình Quản lý Dịch vụ. Khả năng của
họ để thực hiện điều này sẽ được đo lường như một phần
của các chỉ số quy trình khi thích hợp (xem phần mô tả về
từng quy trình để biết thêm chi tiết). Các ví dụ bao gồm:
o Thời gian hồi đáp đối với từng sự kiện và tỷ lệ sự kiện
hoàn thành,
o Thời gian giải quyết sự cố đối với hỗ trợ tuyến-hai và
tuyến-ba,
o Thống kê giải quyết vấn đề,
o Số lượng các lần leo thang và nguyên nhân của các lần
leo thang đó,
o Số lượng các thay đổi đã được triển khai và đảo ngược,
o Số lượng các thay đổi trái phép đã được phát hiện,
o Số lượng các bản phát hành đã triển khai, tổng số và
thành công, bao gồm việc đảm bảo sự tuân thủ các
Chính sách Phát hành của tổ chức,
o Các vấn đề bảo mật đã được phát hiện và giải quyết,
o Mức sử dụng hệ thống thực tế so với dự báo Kế hoạch
Công suất (khi nhóm đã đóng góp vào việc phát triển
kế hoạch),
o Theo dõi so với SIP,
o Chi tiêu so với ngân sách.
 Hiệu suất ứng dụng. Những chỉ số này dựa trên đặc tả kỹ
thuật Thiết kế Dịch vụ và các tiêu chuẩn hiệu suất kỹ thuật
đã được thiết lập bởi nhà thầu và thường được đóng gói
trong cá OLS và SOP. Các chỉ số thực tế sẽ khác nhau theo
ứng dụng nhưng có khả năng bao gồm:
o Thời gian hồi đáp,
o Tính sẵn sàng của ứng dụng, vốn rất hữu ích để đo
lường hiệu suất của nhóm hoặc của ứng dụng nhưng
không nên bị nhầm lẫn với Tính sẵn sàng Dịch vụ - đòi
hỏi khả năng đo lường tính sẵn sàng tổng thể của dịch
vụ, và có thể sử dụng các số lượng về tính sẵn sàng
dành cho số lượng các hệ thống hoặc thành phần riêng
lẻ,
o Tính toàn vẹn của dữ liệu và báo cáo,
 Thước đo hoạt động bảo trì, bao gồm:
o Số lần bảo trì đã thực hiện so với lịch trình,
o Số lượng cửa sổ bảo trì đã bị vượt quá,
o Các mục tiêu bảo trì đã đạt được (số lượng và tỷ lệ
phần trăm),
 Các nhóm Quản lý Ứng dụng có khả năng phối hợp chặt chẽ
với các nhóm Phát triển Ứng dụng trên các dự án, và các chỉ
số thích hợp nên được sử dụng để đo lường điều này, bao
gồm:
o Thời gian tiêu tốn cho các dự án,
o Mức độ hài lòng của người dùng và khách hàng với kết
quả đầu ra của dự án,
o Chi phí liên quan đến dự án,
 Đào tạo và phát triển các kỹ năng. Những chỉ số này đảm
bảo rằng nhân viên có các kỹ năng và được đào tạo dể quản
lý những công nghệ đang nằm dưới sự quản lý của họ, và
đồng thời, xác định những lĩnh vực nơi mà việc đào tạo vẫn
còn cần thiết.
6.5.9 Tài li ệ u Q u ản lý Ứ ng d ụn g
Một số các tài liệu được đưa ra và sử dụng trong quá trình Quản lý
Ứng dụng. Danh sách này là một bản tóm tắt một số tài liệu quan
trọng nhất và không bao gồm các báo cáo hoặc những tài liệu được
đưa ra bởi Quản lý Ứng dụng dưới danh nghĩa của quy trình hoặc
chức năng khác (ví dụ, RFC, tài liệu Lỗi Đã biết, Hồ sơ Phát hành,
v.v…). Hãy lưu ýrằng những tài liệu đó nên được kiểm soát như là
các Đơn vị Cấu hình và liên quan đến các ứng dụng hoặc các nhóm
Quản lý Ứng dụng có liên quan.
6.5.9. 1 Danh m ụ c Ứng d ụn g

Danh mục Ứng dụng chủ yếu được sử dụng như một phần của Chiến
lược Dịch vụ, tuy nhiên, được tham chiếu ở đây vì sự hoàn chỉnh.
Danh mục Ứng dụng là một danh sách (chính xác hơn là m ột hệ
thống hoặc một cơ sở dữ liệu) về mọi ứng dụng đang được sử dụng
trong phạm vi tổ chức, cùng với những thông tin sau:
Thuộc tính chính của ứng dụng:
 Khách hàng và người dùng,

 Mục đích kinh doanh,
 Mức độ quan trọng đối với doanh nghiệp,
 Kiến trúc (bao gồm những phụ thuộc vào Cơ sở hạ tầng CNTT),
 Các nhà phát triển, các nhóm hỗ trợ, nhà cung cấp hoặc nhà
thầu,
 Khoản đầu tư được thực hiện vào ứng dụng cho đến hôm nay.
Về mặt này, Danh mục Ứng dụng có thể được sử dụng như một
bản đăng ký tài sản đối với các ứng dụng.
Mục đích của Danh mục Ứng dụng là để phân tích nhu cầu đối với và
việc sử dụng các ứng dụng trong tổ chức. Nó có thể được sử dụng
để liên kết tính năng và khoản đầu tư cho hoạt động kinh doanh và
do đó, là một phần quan trọng của việc hoạch định và kiểm soát
CNTT liên tục. Một lợi ích khác nữa của Danh mục Ứng dụng là rằng
nó có thể được sử dụng để xác định việc cấp phép ứng dụng trùng
lặp và quá mức dư thừa.
Danh mục Ứng dụng định hình nên một phần của Danh mục dịch vụ
CNTT tổng thể, vốn đã được thảo luận chi tiết trong ấn phẩm Chiến
lược Dịch vụ.
Danh mục Ứng dụng và Mục lục Dịch vụ
Danh mục Ứng dụng không nên bị nhầm lẫn với Mục lục Dịch vụ và không nên
được quảng bá cho khách hàng hoặc người dùng như là một danh sách các dịch
vụ. Các ứng dụng là một trong những thành phần được sử dụng để cung cấp các
dịch vụ CNTT, thường không phải là chính bản thân các dịch vụ.
Do đó, Danh mục Ứng dụng nên được sử dụng như là một tài liệu hoạch định chỉ
bởi các nhà quản lý và nhân viên, những người liên quan vào việc phát triển và
quản lý Chiến lược CNTT của tổ chức, cũng như là các nhân viên CNTT, những
người được giao nhiệm vụ quản lý các ứng dụng hoặc nền tảng mà các ứng dụng
đang chạy trên đó.
Mục lục Dịch vụ nên tập trung vào việc liệt kê các dịch vụ đang sẵn có, thay vì
chỉ đơn giản là liệt kê những ứng dụng và giả định rằng người dùng và khách
hàng có thể tạo ra được sự kết nối. Phải nói rằng, có những thời điểm khi ứng
dụng đồng nghĩa với dịch vụ, ví dụ, các ứng dụng xử lý từ ngữ thường được biết
đến dưới tên gọi của nó, một ứng dụng lưu trữ dịch vụ sẽ đề cập đến tên gọi của
ứng dụng được lưu trữ, v.v…
6.5.9. 2 Các yêu c ầ u Ứng d ụng

Có hai bộ tài liệu có chứa những yêu cầu đối với các ứng dụng:
 Yêu cầu Nghiệp vụ phác thảo nên Đề án Kinh doanh đối với
ứng dụng được yêu cầu, nói cách khác, là những gì mà doanh
nghiệp sẽ thực hiện với ứng dụng đó. Điều này sẽ bao gồm Lợi
nhuận trên Khoản đầu tư cho ứng dụng cũng như các cải thiện
có liên quan đối với doanh nghiệp. Các yêu cầu nghiệp vụ cũng
sẽ bao gồm các Yêu cầu Mức Dịch vụ như đã được xác định bởi
khách hàng và người dùng của dịch vụ.
 Các tài liệu Các Yêu cầu ứng dụng dựa trên các Yêu cầu
Nghiệp vụ và chỉ định chính xác cách thức mà ứng dụng sẽ đáp
ứng những yêu cầu này như thế nào. Nói một cách ngắn gọn,
những tài liệu Yêu cầu Ứng dụng thu thập thông tin sẽ được sử
dụng để thực hiện các ứng dụng mới hoặc thay đổi những ứng
dụng hiện hữu, ví dụ,
o Để thiết kế kiến trúc của ứng dụng (đặc tả kỹ thuật của
các thành phần khác của hệ thống, cách thức chúng liên
quan đến các thành phần khác và cách chúng sẽ được
quản lý như thế nào),
o Để chỉ định một Yêu cầu Đề xuất giải pháp (Request for
Proposal – RFP) đối với một phần mềm thương mại sẵn có
(Commercial Off the Shelf – COTS),
o Để khởi đầu việc thiết kế và xây dựng một ứng dụng
trong nội bộ.
Các tài liệu về các yêu cầu thường được sở hữu bởi lãnh đạo dự án,
thâm chí là của một nhóm dự án phát triển, hoặc một nhóm đang
phác thảo các đặc tả kỹ thuật cho một RFP. Các tài liệu về các yêu
cầu phải chịu sự kiểm soát tài liệu đối với dự án vì chúng hình thành
một phần của phạm vi tổng thể của dự án.
Bốn loại Yêu cầu Ứng dụng khác nhau cần phải được xác định (để
biết thêm thông tin chi tiết, vui lòng tham khảo các ấn phẩm Thiết
kế Dịch vụ và Chuyển tiếp Dịch vụ của ITIL):
 Các Yêu cầu Chức năng (Functional Requirements) mô tả

những gì mà ứng dụng dự định thực hiện, và có thể được thể
hiện dưới dạng các dịch vụ, nhiệm vụ hoặc chức năng mà ứng
dụng được yêu cầu thực hiện,
 Các Yêu cầu về Khả năng quản lý (Manageability
Requirements) được sử dụng để xác định những gì cần thiết
để quản lý ứng dụng hoặc để đảm bảo rằng nó đang thực hiện
các chức năng cần thiết một cách nhất quán và đúng mức. Các
yêu cầu về khả năng quản lý cũng xác định những ràng buộc
đối với hệ thống CNTT. Những yêu cầu này là cơ sở để định cỡ
hệ thống từ đầu và ước tính chi phí, đồng thời có thể hỗ trợ
cho việc đánh giá khả năng tồn tại của hệ thống CNTT đã được
đề xuất. Quan trọng nhất, chúng thúc đẩy thiết kế các mô hình
hoạt động và các tiêu chuẩn hiệu suất được sử dụng trong
Quản lý Vận hành CNTT,
 Các Yêu cầu về Khả năng sử dụng (Usability
Requirements) thường được chỉ định bởi người dùng ứng
dụng và đề cập đến tính dễ sử dụng của nó. Bất kỳ yêu cầu đặc
biệt nào đối với người dùng khuyết tật cũng cần được nêu rõ
tại đây,
 Yêu cầu Kiểm nghiệm (Test Requirements) chỉ rõ những gì
được yêu cầu để đảm bảo rằng môi trường kiểm nghiệm là đại
diện cho môi trường hoạt động và kiểm nghiệm là hợp lệ (nghĩa
là nó thực sự kiểm nghiệm những gì nó được cho là phải kiểm
nghiệm).
6.5.9. 3 Các trư ờ ng h ợ p S ử d ụn g và Thay đ ổi

Các Trường hợp Sử dụng và Thay đổi được quản lý như một phần
của các quy trình Thiết kế Dịch vụ và Liên tục Cải tiến Dịch vụ,
nhưng được duy trì bởi Quản lý Ứng dụng. Đối với các phần mềm
được mua, thông thường thì nhóm phát triển các đặc tả kỹ thuật
chức năng để duy trì Trường hợp Sử dụng cho ứng dụng đó.
 Tài liệu Trường hợp Sử dụng (Use Cases) ghi lại dự định sử
dụng ứng dụng với các tình huống theo thời gian thực để
chứng minh các ranh giới giữa và chức năng đầy đủ của nó.
Các Trường hợp Sử dụng cũng có thể được sử dụng như là các
kịch bản mô hình hóa và định cỡ và để tạo điều kiện giao tiếp
giữa người dùng, Nhà phát triển và nhân viên Quản lý Ứng
dụng,
 Trường hợp Thay đổi sử dụng các kịch bản để dự báo tác
động của những thay đổi tiềm tàng đối với việc sử dụng, kiến
trúc hoặc chức năng, và dự đoán tác động của những kịch bản
thay đổi cụ thể. Các Trường hợp Thay đổi được sử dụng để làm
rõ phạm vi và định hướng với nhà bảo trợ. Công việc thiết kế
và kiến trúc bổ sung sẽ được cần đến vào thời điểm này để
đảm bảo các Trường hợp Thay đổi có thể được đáp ứng trong
tương lai với chi phí hợp lý. Nhà bảo trợ phải được chuẩn bị để
trả thêm chi phí bổ sung. Nếu không, các Trường hợp Thay đổi
nên được giảm xuống mức (chi phí) mà nhà tài trợ sẵn sàng chi
trả. Các Trường hợp Thay đổi cũng được sử dụng để đánh giá
kiến trúc. Chúng ảnh hưởng đến quá trình phát triển cho phép
thiết kế các tính năng kiến trúc phù hợp để giảm thiểu tác
động của những thay đổi trong tương lai.
Để biết thêm thông tin, vui lòng tham kh ảo các ấn phẩm Thiết kế
Dịch vụ và Liên tục Cải tiến Dịch vụ của ITIL.
6.5.9. 4 Tài li ệ u thi ết k ế

Đây không phải là một tài liệu cụ thể, mà đề cập đến bất kỳ tài liệu
nào được tạo ra bởi nhân viên Quản lý Ứng dụng hoặc Phát triển
Ứng dụng để chỉ rõ cách thức mà một ứng dụng sẽ được xây dựng
như thế nào. Vì những tài liệu này thường được sở hữu và quản lý
bởi các nhóm Phát triển nên ấn phẩm này sẽ không trình bày chi tiết
về chúng. Tuy nhiên, để đảm bảo vận hành thành công, Quản lý Ứng
dụng phải đảm bảo rằng tài liệu thiết kế bao gồm:
 Thông số kỹ thuật định cỡ [ứng dụng],

 Hồ sơ khối lượng công việc và dự báo việc sử dụng,
 Kiến trúc Kỹ thuật,
 Mô hình dữ liệu,
 Tiêu chuẩn mã hóa,
 Tiêu chuẩn hiệu suất,
 Định nghĩa Quản lý Cấu hình Phần mềm,
 Các định nghĩa về môi trường và các cân nhắc xây dựng (nếu
thích hợp).
Đối với các ứng dụng thương mại sẵn có (COTS), các tài liệu này sẽ
có dạng Đặc tả kỹ thuật Ứng dụng được sử dụng làm đầu vào cho
việc viết ra các RFP. Trong những trường hợp này, các tài liệu được
sở hữu và quản lý bởi Quản lý Ứng dụng.
Để biết thêm thông tin về Tài liệu Thiết kế, vui lòng tham khảo ấn
phẩm Thiết kế Dịch vụ ITIL.
6.5.9. 5 Hướ ng d ẫ n s ử dụn g

Quản lý Ứng dụng chịu trách nhiệm quản lý các hướng dẫn sử dụng
cho tất cả các ứng dụng. Mặc dù chúng (các hướng dẫn sử dụng)
thường được phát triển bởi nhóm Phát triển Ứng dụng hoặc nhà cung
cấp bên thứ ba, Quản lý Ứng dụng chịu trách nhiệm cho việc đảm
bảo rằng các hướng dẫn sử dụng có liên quan đến các phiên bản
hoạt động của ứng dụng.
Ba loại hướng dẫn thường được Quản lý ứng dụng duy trì:
 Hướng dẫn thiết kế chứa thông tin về cấu trúc và kiến trúc
của ứng dụng. Những điều này rất hữu ích cho việc ra tạo các
báo cáo hoặc xác định quy tắc tương quan sự kiện. Chúng cũng
có thể giúp chẩn đoán các vấn đề.
 Hướng dẫn quản trị hoặc quản lý mô tả các hoạt động cần
thiết để duy trì và vận hành ứng dụng ở các mức hiệu suất đã
được chỉ định trong giai đoạn Thiết kế. Các tài liệu hướng dẫn
này cũng sẽ cung cấp cách khắc phục sự cố chi tiết, các mô tả
Lỗi và Lỗi Đã biết cũng như hướng dẫn từng bước cho các tác
vụ bảo trì thông thường.
 Hướng dẫn người dùng mô tả tính năng của ứng dụng khi nó
được sử dụng bởi người dùng. Những hướng dẫn sử dụng này
bao gồm các hướng dẫn từng bước về cách làm thế nào để sử
dụng ứng dụng, cũng như các mô tả về những gì nên thường
được nhập vào các trường nhất định nào, hoặc cần làm những
gì khi có một lỗi.
Hướng dẫn sử dụng và Thủ tục Vận hành Tiêu chuẩn
Các hướng dẫn sử dụng không nên được coi là tài liệu thay thế cho các SOP mà là đầu
vào cho các SOP.
Các SOP nên bao gồm mọi khía cạnh của các ứng dụng cần phải được quản lý nhu một
phần của việc vận hành tiêu chuẩn. Nếu như chúng không được trích xuất từ các hướng
dân sử dụng, sẽ có khả năng cao là chúng sẽ bị bỏ qua hoặc được thực hiện theo cách
không tiêu chuẩn. Quản lý Ứng dụng nên đảm bảo rằng bất kỳ hướng dẫn nào như vậy
được trích xuất từ các hướng dẫn sử dụng và được chèn vào trong các tài liệu SOP tách
biệt cho Vận hành. Nó cũng chịu trách nhiệm cho việc đảm bảo rằng những hướng dẫn
đó được cập nhật với mọi thay đổi hoặc bản phát hành mới của phần mềm.
6.6 Các vai trò và trách nhiệm Vận hành Dịch vụ
Chìa khóa để ITSM có hiệu quả là việc đảm bảo rằng có những vai
trò và trách nhiệm giải trình rõ ràng được xác định để thực hiện
thông lệ Vận hành Dịch vụ. Một vai trò thường được gắn liền với một
mô tả công việc hoặc một mô tả một nhóm công việc nhưng không
nhất thiết phải được hoàn thành bởi một cá nhân. Kích cỡ của một
ứng dụng, cách mà nó được cấu trúc như thế nào, sự hiện diện của
các đối tác bên ngoài, và các yếu tố khác sẽ có ảnh hưởng đến cách
mà các vai trò được chỉ định. Bất kê một vai trò cụ thể được hoàn
thành bởi một cá nhân đơn lẻ hoặc được chia sẻ giữa hai hoặc nhiều
cá nhân, điều quan trọng là tính nhất quán của trách nhiệm giải
trình và việc thực thi, cùng với sự tương tác với các vai trò khác
trong tổ chức.
6.6.1 C á c Vai trò B ộ ph ậ n H ỗ tr ợ Dịch v ụ

Những vai trò dưới đây là cần thiết đối với Bộ phận Hỗ trợ Dịch vụ.
6.6.1. 1 Nhà Qu ả n lý B ộ ph ậ n H ỗ t rợ Dịc h v ụ

Trong các tổ chức lớn hơn, nơi Bộ phận Hỗ trợ Dịch vụ có quy mô
đáng kể, vai trò Người quản lý Bộ phận Hỗ trợ Dịch vụ có thể phù
hợp với (các) Giám sát viên Bộ phận Hỗ trợ Dịch vụ báo cáo cho
người đó. Trong những trường hợp như vậy, vai trò này có thể chịu
trách nhiệm về một số hoạt động được liệt kê ở trên và có thể thực
hiện thêm các hoạt động bổ sung như sau:
 Quản lý các hoạt động tổng thể tại bộ phận hỗ trợ dịch vụ,
bao gồm cả các giám sát viên,
 Hoạt động như một điểm leo thang tiếp tục cho (các) giám
sát viên,
 Đảm nhận vai trò dịch vụ khách hàng rộng lớn hơn,
 Báo cáo cho quản lý cấp cao về bất kỳ vấn đề nào có thể
ảnh hưởng đáng kể đến hoạt động kinh doanh,
 Tham dự các cuộc họp của Hội đồng Cố vấn Thay đổi,
 Chịu trách nhiệm tổng thể về sự cố và xử lý Yêu cầu Dịch vụ
trên Bộ phận Hỗ trợ Dịch vụ. Điều này cũng có thể được mở
rộng sang bất kỳ hoạt động nào khác do Bộ phận Hỗ trợ Dịch
vụ thực hiện - ví dụ, giám sát các lớp sự kiện nhất định.
Lưu ý: Trong mọi trường hợp, các mô tả công việc rõ ràng nên được
soạn thảo và thống nhất để những trách nhiệm cụ thể được hiểu rõ.
6.6.1. 2 Giám s át viên B ộ p h ậ n H ỗ trợ Dịch v ụ

Trong những bộ phận dịch vụ rất nhỏ, có khả năng là các Chuyên gia
Bộ phận Hỗ trợ Dịch vụ cao cấp cũng sẽ đóng vai trò như Giám sát
viên – nhưng trong những bộ phận dịch vụ lớn hơn, có khả năng là
một vai trò Giám sát viên Bộ phận Hỗ trợ Dịch vụ chuyên biệt sẽ
được cần đến. Trong trường hợp giờ làm việc quy định nó, có thể có
hai hoặc nhiều người giữ trách nhiệm chính, người thực hiện vai trò,
thường là dựa trên cơ sở chồng chéo. Vai trò của Giám sát viên có
thể bao gồm:
 Đảm bảo rằng việc bố trí nhân sự và các mức kỹ năng được
duy trì trong toàn bộ giờ hoạt động bằng cách quản lý lịch
trình nhân sự theo ca, v.v…
 Thực hiện các hoạt động Nhân sự khi cần thiết,
 Đóng vai trò như một điểm leo thang khi nhận được những
cuộc gọi khó khăn hoặc gây tranh cãi,
 Đưa ra các báo cáo thống kê và báo cáo quản lý,
 Đại diện cho Bộ phận Hỗ trợ Dịch vụ tại các cuộc họp,
 Sắp xếp các phiên đào tạo và nâng cao nhận thức nhân viên,
 Liên lạc với các quản lý cấp cao,
 Liên lạc với Quản lý Thay đổi,
 Thực hiện việc tóm tắt cho nhân viên của Bộ phận Hỗ trợ
Dịch vụ về những thay đổi hoặc triển khai có thể gây ảnh
hưởng đến khối lượng tại Bộ phận Hỗ trợ Dịch vụ,
 Hỗ trợ các chuyên gia phân tích trong vi ệc cung cấp hỗ trợ
tuyến đầu khi khối lượng công việc tăng cao hoặc khi những
kinh nghiệm bổ sung là cần thiết.
6.6.1. 3 Nhà phân tích B ộ ph ậ n H ỗ trợ Dịch v ụ

Vai trò chủ yếu của Chuyên viên phân tích Bộ phận Hỗ trợ Dịch vụ là
cung cấp hỗ trợ tuyến đầu thông qua việc nhận các cuộc gọi và xử lý
các sự cố phát sinh hoặc các Yêu cầu Dịch vụ bằng cách sử dụng các
quy trình Báo cáo Sự cố và Thực hiện Yêu cầu, kết hợp với các mục
tiêu đã được mô tả trước đây. Số lượng chính xác nhân viên cần
thiết được thảo luận trong đoạn 6.2.4.1.
6.6.1. 4 Ngư ờ i dùng S iêu c ấ p

Người dùng Siêu cấp đã được thảo luận chi tiết trong phần về bố trí
nhân sự Bộ phận Hỗ trợ Dịch vụ trong đoạn 6.2.4. Nói tóm lại, vai
trò này sẽ bao gồm những người dùng của doanh nghiệp đóng vai
trò như các điểm liên lạc với CNTT nói chung và cụ thể là Bộ phận
Hỗ trợ Dịch vụ. Vai trò Người dùng Siêu cấp có thể được tóm tắt như
sau:
 Tạo điều kiện giao tiếp giữa CNTT và doanh nghiệp ở cấp độ
vận hành,
 Củng cố những kỳ vọng của người dùng liên quan đến những
Mức Dịch vụ đã được thống nhất,
 Đào tạo nhân viên đối với người dùng trong lĩnh vực của họ,
 Cung cấp sự hỗ trợ cho các sự cố nhỏ hoặc thực hiện các
yêu cầu đơn giản,
 Tham gia vào các bản phát hành và ra mắt mới.
6.6.2 Các Vai trò Q u ả n lý K ỹ thuậ t

Những vai trò dưới đây là cần thiết trong lĩnh vực Quản lý Kỹ thuật.
6.6.2. 1 Nhà Qu ả n lý/Trư ở ng nhó m K ỹ t hu ậ t

Một Nhà quản lý hoặc Trưởng nhóm Kỹ thuật (tùy thuộc vào quy mô
và/hoặc tầm quan trọng của nhóm và cơ cấu và văn hóa của tổ chức)
có thể được cần đến cho từng nhóm hoặc bộ phận kỹ thuật. Vai trò
này sẽ:
 Chịu trách nhiệm tổng thể cho sự lãnh đạo, kiểm soát và
đưa ra quyết định đối với nhóm hoặc bộ phận kỹ thuật,
 Cung cấp kiến thức chuyên môn về kỹ thuật và sự lãnh đạo
trng những lĩnh vực kỹ thuật cụ thể được bao hàm bởi nhóm
hoặc bộ phận,
 Đảm bảo đào tạo kỹ thuật, nâng cao nhận thức và mức kinh
nghiệp cần thiết được duy trì trong phạm vi nhóm hoặc bộ
phận,
 Báo cáo cho các quản lý cấp cao về mọi vấn đề về kỹ thuật
có liên quan đến lĩnh vực trách nhiệm của họ,
 Thực hiện quản lý-tuyến đối với mọi thành viên của nhóm
hoặc bộ phận.
6.6.2. 2 Chuyên viên phân tích/Ki ến trú c sư K ỹ
thu ậ t
Thuật ngữ này đề cập đến bất kỳ nhân viên nào trong Quản lý Kỹ
thuật, người thực hiện các hoạt động đã được liệt kê trong đoạn
6.3.3, ngoại trừ các hoạt động vận hành hàng ngày, vốn được thực
hiện bởi Nhân viên vận hành trong Quản lý Kỹ thuật hoặc Quản lý
Vận hành CNTT. Dựa trên danh sách các hoạt động phổ quát trong
đoạn 6.3.3, vai trò Chuyên viên phân tích và Kiến trúc sư Kỹ thuật
bao gồm:
 Làm việc với người dùng, nhà bảo trợ, Quản lý Ứng dụng và tất
cả các bên liên quan khác để xác định nhu cầu phát triển của
họ,
 Làm việc với Quản lý Ứng dụng và các lĩnh vực khác trong
Quản lý Kỹ thuật để xác định mức cao nhất của các yêu cầu hệ
thống cần thiết để đáp ứng các yêu cầu trong phạm vi những
ràng buộc về ngân sách và công nghệ,
 Xác định và duy trì kiến thức về cách thức các hệ thống liên
quan với nhau và đảm bảo rằng các phụ thuộc được hiểu rõ và
được quản lý một cách tương xứng,
 Tiến hành phân tích chi phí-lợi ích để xác định các phương tiện
thích hợp nhất để đáp ứng các yêu cầu đã được nêu ra,
 Phát triển các Mô hình Vận hành mà sẽ đảm bảo việc sử dụng
tối ưu các nguồn lực và mức hiệu suất phù hợp,
 Đảm bảo rằng cơ sở hạ tầng được thiết lập cấu hình để được
quản lý một cách hiệu quả dựa trên kiến trúc công nghệ của tổ
chức, các kỹ năng và công cụ sẵn có,
 Đảm bảo hiệu suất nhất quán và đáng tin cậy của cơ sở hạ
tầng để cung cấp mức độ dịch vụ cần thiết cho doanh nghiệp,
 Xác định tất cả các nhiệm vụ cần thiết để quản lý cơ sở hạ
tầng và đảm bảo rằng các nhiệm vụ này được thực hiện một
cách thích hợp,
 Đầu vào để thiết kế dữ liệu cấu hình cần thiết để quản lý và
theo dõi ứng dụng một cách hiệu quả.
Những cách thức mà theo đó Quản lý Kỹ thuật có thể được tổ chức

và các tùy chọn khả dụng sẽ được thảo luận chi tiết trong phần 6.7.
6.6.2. 3 N hân viên v ậ n hành K ỹ thuậ t

Thuật ngữ này được sử dụng để đề cập đến bất kỳ nhân viên nào,
những người tiến hành các tác vụ vận hành hàng ngày trong Quản lý
Kỹ thuật. Thông thường, những tác vụ này được ủy thác cho một
nhóm Vận hành CNTT chuyên biệt, và do đó, vai trò này đã được
thảo luận trong đoạn 6.6.3.4 về Nhân viên vận hành CNTT.
6.6.3 Các Vai trò Q uả n lý V ậ n hành CNTT

Những vai trò dưới đây được cần đến trong lĩnh vực Quản lý Vận
hành CNTT:
6.6.3. 1 Nhà Quả n lý V ậ n hành CNTT

Một Nhà Quản lý Vận hành CNTT sẽ được cần dến để chịu trách
nhiệm tổng thể về tất cả các hoạt động Quản lý Vận hành CNTT, bao
gồm:
 Kiểm soát Hoạt động, giám sát việc thực thi và giám sát các
hoạt động vận hành trong Cơ sở hạ tầng CNTT. Điều này có thể
được thực hiện với sự trợ giúp của một Cầu nối Vận hành hoặc
Trung tâm Vận hành mạng. Ngoài việc thực hiện các nhiệm vụ
thường lệ từ tất cả các lĩnh vực kỹ thuật, Kiểm soát hoạt động
cũng thực hiện các nhiệm vụ cụ thể sau:
o Quản lý Bảng điều khiển, đề cập đến việc xác định
năng lực quan sát và giám sát trung tâm và sau đó s ử
dụng các bảng điều khiển đó để thực hiện các hoạt động
giám sát và kiểm soát,
o Lập lịch trình Công việc, hoặc quản lý các công việc
hàng loạt hoặc tập lệnh kịch bản thường lệ,
o Sao lưu và Khôi phục dưới danh nghĩa của tất cả các
nhóm hoặc bộ phận Quản lý ứng dụng và kỹ thuật và
thường dưới danh nghĩa người dùng,
o Quản lý in và kết quả đầu ra để đối chiếu và phân phối
tất cả các bản in hoặc điện tử đầu ra tập trung,
 Quản lý Cơ sở vật chất, đề cập đến việc quản lý môi trường
CNTT vật lý, điển hình là một Trung tâm Dữ liệu hoặc các
phòng máy tính và địa điểm khôi phục cùng với tất cả các thiết
bị cấp nguồn và làm mát. Quản lý Cơ sở vật chất cũng bao gồm
việc điều phối các dự án hợp nhất quy mô lớn, ví dụ, các dự án
hợp nhất trung tâm dữ liệu hoặc hợp nhất máy chủ. Trong một
số trường hợp, việc quản lý Trung tâm Dữ liệu được thuê
ngoài, trong trường hợp đó, Quản lý Cơ sở vật chất đề cập đến
việc quản lý hợp đồng thuê ngoài.
Vai trò của Nhà Quản lý Vận hành CNTT là:

 Cung cấp khả năng lãnh đạo, kiểm soát và ra quyết định tổng
thể và chịu trách nhiệm cho các nhóm và bộ phận Quản lý Vận
hành CNTT,
 Báo cáo cho các quản lý cấp cao về tất cả các vấn đề với Hoạt
động CNTT,
 Thực hiện quản lý theo tuyến đối với các nhà quản lý/giám sát
bộ phận của tất cả nhóm hoặc bộ phận Vận hành CNTT.
6.6.3. 2 Trư ở n g nhó m

Rất nhiều lĩnh vực Hoạt động CNTT phải làm thêm ngoài giờ - trên
cơ sở hai hoặc ba ca. Trong những trường hợp đó, một trưởng ca sẽ
được cần đến cho từng ca, để thực hiện những hoạt động sau đây:
 Chịu trách nhiệm tổng thể cho sự lãnh đạo, kiểm soát và đưa
ra quyết định trong ca làm việc,
 Đảm bảo rằng mọi hoạt động vận hành được thực hiện một
cách thỏa đáng trong phạm vi khung thời gian đã được thống
nhất và thích hợp với các chính sách và thủ tục của công ty,
 Liên lạc với (các) trưởng ca khác để đảm bảo sự bàn giao, liên
tục và nhất quán giữa các ca,
 Đóng vai trò như một nhà quản lý theo tuyến đối với mọi
Chuyên viên phân tích Hoạt động trong ca làm việc của mình,
 Đảm nhiệm trách nhiệm bảo mật, sức khỏe và an toàn tổng thể
cho ca làm việc (trừ khi được chỉ định đặc biệt có các thành
viên khác).
6.6.3. 3 Chuyên viên phân tích Ho ạ t đ ộng CNTT

Chuyên viên phân tích Hoạt động CNTT là một nhân viên Vận hành
CNTT cấp cao, người có khả năng xác định cách thức hiệu quả và có
hiệu suất nhất để tiến hành một loạt các hoạt động, thường trong
các môi trường đa dạng và khối lượng lớn.
Vai trò này thường được thực hiện như một phần của Quản lý Kỹ
thuật, nhưng các tổ chức lớn có thể nhận thấy rằng khối lượng và sự
đa dạng của các hoạt động vận hành đòi hỏi một số công việc hoạch
định và thực thi sâu sắc hơn. Các ví dụ bao gồm Lập lịch trình Công
việc và xác định chiến lược và lịch trình Sao lưu.
6.6.3. 4 Nhân viên v ậ n hành CNTT

Nhân viên Vận hành CNTT là những nhân viên thực hiện các hoạt
động vận hành hàng ngày như đã được xác định trong Quản lý Kỹ
thuật hoặc Quản lý Ứng dụng và, trong một số trường hợp, Chuyên
viên phân tích Hoạt động CNTT. Những vai trò Nhân viên vận hành
điển hình bao gồm:
 Thực hiện sao lưu,

 Vận hành bảng điều khiển, nghĩa là giám sát trạng thái của các
hệ thống, hàng đợi công việc, v.v… cụ thể, và cung cấp sự can
thiệp tuyến đầu khi cần thiết,
 Quản lý các thiết bị in ấn, tái nhập kho giấy, mực in, v.v…
 Đảm bảo rằng các công việc hàng loạit, lưu giữ, v.v… được
thực hiện,
 Chạy các công việc dọn dẹp theo lịch trình, chẳng hạn như bảo
trì cơ sở dữ liệu, làm sạch tập tin, v.v…
 Ghi hình ảnh để phân phối và cài đặt các máy chủ, máy tính để
bàn hoặc máy tính xách tay mới,
 Lắp đặt về mặt vật lý các thiết bị tiêu chuẩn trong Trung tâm
Dữ liệu.
6.6.4 Các Vai trò Q u ả n lý Ứ ng d ụng
6.6.4. 1 Nhà Qu ả n lý/Trư ở ng nhó m Ứng d ụng

Một Nhà quản lý hoặc Trưởng nhóm Ứng dụng nên được cân nhắc
cho từng nhóm hoặc bộ phận ứng dụng. Vai trò này sẽ:
 Chịu trách nhiệm tổng thể về sự lãnh đạo, kiểm soát và đưa ra
quyết định cho nhóm hoặc bộ phận ứng dụng,
 Cung cấp kiến thức kỹ thuật và khả năng lãnh đạo trong các
hoạt động hỗ trợ ứng dụng cụ thể do nhóm hoặc bộ phận phụ
trách,
 Đảm bảo đào tạo kỹ thuật, nâng cao nhận thức và mức độ kinh
nghiệm cần thiết được duy trì trong nhóm hoặc bộ phận liên
quan đến các ứng dụng đang được hỗ trợ và các quy trình đang
được sử dụng,
 Tham gia vào giao tiếp liên tục với người dùng và khách hàng
về hiệu suất ứng dụng và các yêu cầu phát triển của doanh
nghiệp,
 Báo cáo cho quản lý cấp cao về tất cả các vấn đề có liên quan
đến các ứng dụng đang được hỗ trợ,
 Thực hiện quản lý theo tuyến cho mọi thành viên trong nhóm
hoặc bộ phận.
6.6.4. 2 Chuyên viên phân tích/Ki ến trú c sư Ứng

dụng
Các Chuyên viên phân tích và Kiến trúc sư Ứng dụng chịu trách
nhiệm cho việc khớp nối các yêu cầu với đặc tả kỹ thuật của ứng
dụng. Các hoạt động cụ thể bao gồm:
 Làm việc với người dùng, nhà bảo trợ và tất cả các bên liên
quan khác để xác định nhu cầu phát triển của họ,
 Kết hợp với Quản lý Kỹ thuật để xác định mức yêu cầu hệ
thống cao nhất cần thiết để đáp ứng các yêu cầu trong phạm vi
ràng buộc về ngân sách và công nghệ,
 Thực hiện phân tích chi phí-lợi ích để xác định phương tiện
thích hợp nhất để đáp ứng yêu cầu đã được nêu ra,
 Phát triển các Mô hình Vận hành mà sẽ đảm bảo sử dụng tối ưu
các nguồn lực và mức hiệu suất phù hợp,
 Đảm bảo rằng các ứng dụng đã được thiết kế để được quản lý
một cách hiệu quả dựa trên kiến trúc công nghệ, các kỹ năng
và công cụ sẵn có của tổ chức,
 Phát triển và duy trì các tiêu chuẩn về định cỡ ứng dụng, mô
hình hóa hiệu suất, v.v…
 Tạo ra một tập hợp các yêu cầu kiểm nghiệm chấp thuận, cùng
với các nhà thiết kế, kỹ sư kiểm nghiệm và người dùng, xác
định rằng mọi yêu cầu cấp cao đã được đáp ứng, cả về chức
năng lẫn khả năng quản lý,
 Đầu vào cho thiết kế dữ liệu cấu hình cần thiết để quản lý và
theo dõi ứng dụng một cách hiệu quả.
Một số lượng Nhà phân tích ứng dụng thích hợp sẽ được cần đến cho
mỗi nhóm hoặc bộ phận Quản lý Ứng dụng để thực hiện các hoạt
động đã được mô tả ở đâu đó khác trong ấn phẩm này, chủ yếu
trong đoạn 6.5.5.
Những cách thức mà theo đó, các nhóm Quản lý Ứng dụng có thể
được tổ chức, và các tùy chọn có sẵn sẽ được thảo luận chi tiết
trong phần 6.7.
6.6.5 Các Vai trò Q u ả n lý S ự k iệ n

Việc tổ chức bổ nhiệm một ‘Nhà quản lý Sự kiện’ là một điều bất
thường vì các sự kiện có khuynh hướng xảy ra trong nhiều bối cảnh
và vì nhiều lý do khác nhau. Tuy nhien, điều quan trọng là các thủ
tục Quản lý Sự kiện được phối hợp để ngăn chặn những nỗ lực hoặc
công cụ bị trùng lặp. Vai trò của chức năng Vận hành Dịch vụ trong
Quản lý Sự kiện như sau:
6.6.5. 1 Vai trò c ủa Bộ ph ậ n H ỗ tr ợ Kỹ thuậ t

Bộ phận Hỗ trợ Dịch vụ thường không tham gia vào Quản lý Sự kiện
như vậy, trừ khi một sự kiện đòi hỏi một số phản hồi nằm trong
phạm vi hoạt động đã được xác định của Bộ phận Hỗ trợ Dịch vụ,
chẳng hạn như thông báo cho người dùng rằng một báo cáo đã sẵn
sàng. Tuy nhiên, nói chung, loại hoạt động này được thực hiện bởi
Cầu nối Vận hành, trừ khi Bộ phận Hỗ trợ Dịch vụ và Cầu nối Vận
hành đã được kết hợp.
Ban đầu, việc điều tra và giải quyết các sự kiện đã được xác định là
Sự cố sẽ do Bộ phận Hỗ trợ Dịch vụ thực hiện và sau đó được
chuyển đến (các) nhóm Vận hành Dịch vụ thích hợp
Bộ phận Hỗ trợ Dịch vụ cũng chịu trách nhiệm truyền đạt thông tin
về loại sự cố này cho nhóm Quản lý Ứng dụng hoặc Quản lý Kỹ thuật
có liên quan và cho người dùng, nếu thích hợp.
6.6.5. 2 Vai trò c ủa Qu ả n lý K ỹ thuậ t và Q u ả n lý Ứng

dụng
Quản lý Kỹ thuật và Quản lý Ứng dụng đóng một số vai trò quan
trọng như sau:
 Trong quá trình Thiết kế Dịch vụ, họ sẽ tham gia vào việc đo
đạc dịch vụ, phân loại các sự kiện, cập nhật các công cụ tương
quan và đảm bảo rằng bất kỳ phản hồi tự động nào đều đã
được xác định,
 Trong quá trình Chuyển tiếp Dịch vụ, họ sẽ kiểm tra dịch vụ
để đảm bảo rằng các sự kiện được tạo ra một cách đúng đắn và
các phản hồi đã xác định là phù hợp,
 Trong quá trình Vận hành Dịch vụ, các nhóm này thường sẽ
thực hiện Quản lý Sự kiện đối với các hệ thống nằm dưới quyền
kiểm soát của họ. Việc các nhóm có một người chuyên trách để
quản lý Quản lý sự kiện là điều bất thường, nhưng mỗi nhà
quản lý hoặc trưởng nhóm sẽ đảm bảo rằng các thủ tục thích
hợp được xác định và được thực hiện theo các yêu cầu về quy
trình và chính sách,
 Quản lý Kỹ thuật và Quản lý Ứng dụng cũng sẽ tham gia
giải quyết các sự cố và vấn đề liên quan đến các sự kiện,
 Nếu các hoạt động Quản lý sự kiện được ủy quyền cho Bộ
phận Hỗ trợ Dịch vụ hoặc Quản lý Vận hành CNTT, Quản lý Kỹ
thuật và Ứng dụng phải đảm bảo rằng nhân viên được đào tạo
đầy đủ và họ có quyền truy cập vào các công cụ thích hợp để
cho phép họ thực hiện các nhiệm vụ này.
6.6.5. 3 Vai trò c ủa Quả n lý V ậ n hành CNTT

Trong trường hợp Vận hành CNTT được tách biệt khỏi Quản lý Kỹ
thuật hoặc Quản lý Ứng dụng, thông thường Giám sát Sự kiện và
phản hồi tuyến đầu sẽ được ủy quyền cho Quản lý Vận hành CNTT.
Nhân viên vận hành cho mỗi lĩnh vực sẽ được giao nhiệm vụ giám
sát các sự kiện, phản hồi khi được yêu cầu hoặc đảm bảo rằng các
Sự cố được tạo ra khi thích hợp. Các hướng dẫn về cách thức để
thực hiện điều đó phải được bao gồm trong SOP cho các nhóm đó.
Giám sát Sự kiện thường được ủy thác cho Cầu nối Vận hành nếu nó
tồn tại. Cầu nối Vận hành có thể khởi tạo và điều phối, hoặc thậm
chí thực hiện, các biện pháp ứng phó được yêu cầu bởi dịch vụ hoặc
cung cấp hỗ trợ cấp một cho những sự kiện làm phát sinh sự cố.
6.6.6 Các Vai trò Q u ả n lý S ự c ố

Những vai trò dưới đây là cần thiết đối với các quy trình Quản lý Sự
cố.
6.6.6. 1 Nhà Qu ả n lý S ự c ố
Một Nhà quản lý Sự cố sẽ chịu trách nhiệm cho:
 Thúc đẩy hiệu quả và hiệu suất của quy trình Quản lý sự cố
 Đưa ra những thông tin quản lý,
 Quản lý công việc của nhân viên hỗ trợ sự cố (tuyến một và
tuyến hai).,
 Giám sát hiệu quả của Quản lý Sự cố và đưa ra các khuyến
nghị để cải tiến
 Phát triển và duy trì hệ thống Quản lý Sự cố,
 Quản lý các Sự cố Lớn,
 Phát triển và duy trì các quy trình và thủ tục Quản lý Sự cố.
Trong nhiều tổ chức, vai trò Nhà quản lý Sự cố được giao cho Giám
sát viên Bộ phận Hỗ trợ Dịch vụ - mặc dù trong các tổ chức lớn hơn
với khối lượng lớn, có thể cần một vai trò riêng biệt. Trong cả hai
trường hợp, điều quan trọng là Nhà quản lý Sự cố được trao quyền
để quản lý các sự cố một cách hiệu quả thông qua tuyến thứ nhất,
thứ hai và thứ ba.
6.6.6. 2 Tuyến đ ầ u ( h ỗ trợ )

Điều này được đề cập trong phần Bộ phận Hỗ trợ Dịch vụ (phần 6.1)
và sẽ không được lặp lại ở đây.
6.6.6. 3 Tuyến th ứ hai
Rất nhiều tổ chức sẽ chọn có một nhóm hỗ trợ tuyến hai, được tổ
chức từ các nhân viên có các kỹ năng kỹ thuật cao hơn (mặc dù vẫn
còn chung chung) hơn là Bộ phận Hỗ trợ Dịch vụ - và có thêm thời
gian để dành cho việc chẩn đoán và giải quyết mà không bị quấy
nhiễu do gián đoạn từ các cuộc điện thoại.
Một nhóm như vậy có thể xử lý nhiều sự cố ít phức tạp hơn, để lại
nhiều nhóm hỗ trợ chuyên gia hơn (tuyến thứ ba) để tập trung giải
quyết các sự cố sâu hơn và/hoặc các phát triển mới, v.v…
Trong trường hợp nhóm tuyến hai được sử dụng, thường có những
lợi thế từ việc đặt nhóm này gần Bộ phận Hỗ trợ Dịch vụ để hỗ trợ
truyền thông liên lạc tốt và để dễ dàng luân chuyển nhân viên giữa
các nhóm, điều này có thể hữu ích cho việc đào tạo/nâng cao nhận
thức và trong thời gian bận rộn hoặc tình trạng thiếu nhân viên. Một
nhà quản lý hỗ trợ tuyến hai (hoặc giám sát viên, nếu chỉ là một
nhóm nhỏ) thường sẽ đứng đầu nhóm này.
Có thể hình dung rằng nhóm này sẽ có thể được thuê ngoài - và điều
này có khả năng xảy ra và thực tế hơn nếu bản thân Bộ phận Hỗ trợ
Dịch vụ đã được thuê ngoài.
6.6.6. 4 Tuyến th ứ ba
Hỗ trợ tuyến ba sẽ được cung cấp bởi một số nhóm kỹ thuật nội bộ
và/hoặc các nhà cung cấp/bảo trì bên thứ ba. Danh sách này sẽ khác
nhau giữa các tổ chức nhưng có khả năng sẽ bao gồm:
 Hỗ trợ Mạng,
 Hỗ trợ Giọng nói (nếu tách biệt),
 Hỗ trợ Máy chủ,
 Hỗ trợ Máy tính để bàn,
 Quản lý Ứng dụng - có khả năng có thể có các nhóm riêng biệt
cho các ứng dụng hoặc các loại ứng dụng khác nhau - một số
nhóm có thể là nhà cung cấp/bảo trì bên ngoài. Trong nhiều
trường hợp, cùng một nhóm sẽ chịu trách nhiệm cho Phát triển
Ứng dụng cũng như hỗ trợ [ứng dụng] - và do đó, điều quan
trọng là các nguồn lực phải được ưu tiên để hỗ trợ có được sự
nổi bật phù hợp,
 Hỗ trợ Cơ sở dữ liệu,
 Kỹ sư Bảo trì Phần cứng,
 Nhà cung cấp/Bảo trì Thiết bị Môi trường.
Lưu ý: Tùy thuộc vào nơi một tổ chức quyết định cung cấp các dịch
vụ hỗ trợ của mình, bất kỳ nhóm nào ở trên đều có thể là nhóm nội
bộ hoặc nhóm bên ngoài.
6.6.7 Các Vai trò T h ực hi ện Y êu c ầ u

Việc xử lý ban đầu của Thực hiện Yêu cầu sẽ được thực hiện bởi
nhân viên của Bộ phận Hỗ trợ Dịch vụ và Quản lý Sự cố.
Việc thực hiện yêu cầu cuối cùng sẽ được thực hiện bởi (các) nhóm
hoặc các bộ phận Vận hành Dịch vụ thích hợp và/hoặc bởi các nhà
cung cấp bên ngoài, nếu thích hợp. Thông thường, Quản lý Cơ sở vật
chất, Mua sắm và các lĩnh vực kinh doanh khác cũng hỗ trợ trong
việc thực hiện Yêu cầu Dịch vụ. Trong hầu hết các trường hợp, việc
tạo thêm vai trò hoặc bài viết sẽ là không cần thiết.
Trong những trường hợp đặc biệt, khi số lượng Yêu cầu Dịch vụ
được xử lý là rất cao, hoặc khi các yêu cầu đó có tầm quan trọng
thiết yếu đối với tổ chức, có thể thích hợp để có một hoặc nhiều
nhóm Quản lý Sự cố chuyên biệt để xử lý và quản lý các Yêu cầu
Dịch vụ.
6.6.8 Các Vai trò Q u ả n lý V ấ n đ ề

Những vai trò dưới đây là cần thiết đối với quy trình Quản lý Vấn
đề.
6.6.8. 1 Nhà Qu ả n lý V ấ n đ ề
Cần có một cá nhân được chỉ định (hoặc trong các tổ chức lớn hơn
là một nhóm) chịu trách nhiệm về Quản lý Vấn đề. Các tổ chức nhỏ
hơn có thể không có khả năng sử dụng nguồn lực toàn thời gian cho
vai trò này và nó có thể được kết hợp với các vai trò khác trong
những trường hợp như vậy, nhưng điều thiết yếu là nó không chỉ để
nguồn lực kỹ thuật thực hiện. Cần phải có một điểm phối hợp đơn lẻ
và là chủ sở hữu của quá trình Quản lý Vấn đề. Vai trò này sẽ điều
phối tất cả các hoạt động Quản lý Vấn đề và sẽ có trách nhiệm cụ
thể đối với:
 Liên hệ với tất cả các nhóm giải quyết vấn đề để đảm bảo giải
quyết nhanh chóng các vấn đề trong phạm vi các đích nhắm
mục tiêu SLA,
 Quyền sở hữu và việc bảo vệ KEDB,
 Người gác cổng để bao gồm tất cả các Lỗi Đã biết và quản lý
các thuật toán tìm kiếm,
 Chính thức đóng tất cả các Hồ sơ Vấn đề,
 Liên hệ với các nhà cung cấp, nhà thầu, v.v… để đảm bảo rằng
các bên thứ ba hoàn thành nghĩa vụ hợp đồng của họ, đặc biệt
là khi liên quan đến việc giải quyết vấn đề và cung cấp thông
tin và dữ liệu liên quan đến vấn đề,
 Sắp xếp, điều hành, lập hồ sơ và tất cả các hoạt động tiếp
theo liên quan đến các Đánh giá Vấn đề Nghiêm trọng.
6.6.8. 2 Các Nhóm G i ả i quy ết - V ấ n đ ề

Việc giải quyết thực tế các vấn đề có khả năng được thực hiện bởi
một hoặc nhiều nhóm hỗ trợ kỹ thuật và/hoặc nhà cung cấp hoặc
nhà thầu hỗ trợ - dưới sự điều phối của Quản lý Vấn đề.
Khi một vấn đề riêng lẻ đủ nghiêm trọng để bảo đảm cho nó, một
nhóm quản lý vấn đề chuyên biệt nên được thành lập để làm việc
cùng nhau trong việc khắc phục vấn đề cụ thể đó. Nhà quản lý Vấn
đề đóng một vai trò trong việc đảm bảo rằng số lượng và mức độ
chính xác các nguồn tài nguyên sẵn sàng trong nhóm và để leo
thang và truyền đạt lên trên cho chuỗi quản lý của tất cả các tổ
chức có liên quan.
6.6.9 Các Vai trò Q u ả n lý Truy c ậ p

Vì Quản lý Truy cập là một sự thực thi của Quản lý Bảo mật và Quản
lý Tính sẵn sàng, hai lĩnh vực này sẽ chịu trách nhiệm cho việc xác
định các vai trò thích hợp. Việc một tổ chức chỉ định ‘Người quản lý
Truy cập’ là điều bất thường, mặc dù điều quan trọng là phải có một
quy trình Quản lý Truy cập duy nhất và một bộ chính sách duy nhất
liên quan đến quản lý quyền và quyền truy cập. Quá trình này và các
chính sách có liên quan có thể được xác định và duy trì bởi Quản lý
Bảo mật Thông tin và được thực thi bởi các chức năng Vận hành
Dịch vụ khác nhau. Các hoạt động của họ có thể được tóm tắt như
sau.
6.6.9. 1 Vai trò c ủa Bộ ph ậ n H ỗ tr ợ Dịch v ụ
Bộ phận Hỗ trợ Dịch vụ thường được sử dụng như một phương tiện
để yêu cầu quyền truy cập vào một dịch vụ. Điều này thường được
thực hiện bằng cách sử dụng Yêu cầu Dịch vụ. Bộ phận Hỗ trợ Dịch
vụ sẽ xác minh yêu cầu bằng cách kiểm tra xem yêu cầu đã được
phê duyệt ở cấp có thẩm quyền thích hợp hay chưa, rằng người dùng
có phải là nhân viên, nhà thầu hoặc khách hàng hợp pháp và họ đủ
điều kiện để truy cập hay không.
Khi đã thực hiện các kiểm tra này (thông thường bằng cách truy cập
vào cơ sở dữ liệu có liên quan và tài liệu Quản lý Mức Dịch vụ), nó
sẽ chuyển yêu cầu đến nhóm thích hợp để cung cấp quyền truy cập.
Việc Bộ phận Hỗ trợ Dịch vụ được giao trách nhiệm cung cấp quyền
truy cập cho các dịch vụ đơn giản trong cuộc gọi là một điều khá
phổ biến.
Bộ phận Hỗ trợ Dịch vụ cũng sẽ chịu trách nhiệm cho việc liên lạc
với người dùng để đảm bảo rằng họ biết được khi nào quyền truy
cập đã được cấp và để đảm bảo rằng họ nhận được bất kỳ hỗ trợ cần
thiết nào khác.
Bộ phận Hỗ trợ Dịch vụ cũng có vị thế tốt để phát hiện và báo cáo
các sự cố có liên quan đến quyền truy cập. Ví dụ, người dùng cố
gắng truy cập các dịch vụ mà không được cấp quyền; hoặc người
dùng báo cáo sự cố cho thấy rằng một hệ thống hoặc dịch vụ đã
được sử dụng một cách không phù hợp, nghĩa là [truy cập] bởi một
nhân viên cũ đã sử dụng tên người dùng cũ để có được quyền truy
cập và thực hiện các thay đổi trái phép.
6.6.9. 2 Vai trò c ủa Qu ả n lý K ỹ thuậ t và Q u ả n lý Ứng
dụng
Quản lý Kỹ thuật và Quản lý Ứng dụng đóng một số vai trò quan
trọng như sau:
 Trong giai đoạn Thiết kế Dịch vụ, họ sẽ đảm bảo rằng các cơ
chế được tạo ra để đơn giản hóa và để kiểm soát Quản lý Truy
cập trên từng dịch vụ được thiết kế. Họ cũng sẽ chỉ định cách
thức mà theo đó, việc lạm dụng quyền truy cập có thể được
phát hiện và được ngăn chặn,
 Trong giai đoạn Chuyển tiếp Dịch vụ, họ sẽ kiểm tra dịch vụ để
đảm bảo rằng quyền truy cập có thể được cấp, được kiểm soát
và ngăn chặn như đã thiết kế,
 Trong giai đoạn Vận hành Dịch vụ, các nhóm này thường sẽ
thực hiện việc Quản lý Truy cập đối với các hệ thống nằm dưới
sự kiểm soát của họ. Việc các nhóm có một người chuyên trách
để quản lý Quản lý Truy cập là điều bất thường, nhưng mỗi nhà
quản lý hoặc trưởng nhóm sẽ đảm bảo rằng các thủ tục thích
hợp được xác định và thực hiện theo các yêu cầu về quy trình
và chính sách,
 Quản lý Ứng dụng và Quản lý Kỹ thuật cũng sẽ tham gia giải
quyết các Sự cố và Vấn đề liên quan đến Quản lý Truy cập,
 Nếu các hoạt động Quản lý Truy cập được ủy thác cho Bộ phận
Hỗ trợ Dịch vụ hoặc Quản lý Vận hành CNTT, Quản lý Kỹ thuật
và Quản lý Ứng dụng phải đảm bảo rằng nhân viên đã được đào
tạo đầy đủ và họ có quyền truy cập vào các công cụ thích hợp
để cho phép họ thực hiện các nhiệm vụ này.
6.6.9. 3 Vai trò c ủa Quả n lý V ậ n hành CNTT
Khi Vận hành CNTT được tách biệt với Quản lý Kỹ thuật hoặc Quản lý
Ứng dụng, thông thường các nhiệm vụ Quản lý Truy cập hoạt động
sẽ được ủy thác cho Quản lý Vận hành CNTT. Các nhân viên vận
hành cho mỗi khu vực sẽ được giao nhiệm vụ cung cấp hoặc thu hồi
quyền truy cập vào các hệ thống hoặc tài nguyên chính yếu. Các
trường hợp mà họ có thể, và hướng dẫn về cách thức thực hiện điều
đó phải được đưa vào SOP cho các nhóm đó.
Cầu nối Vận hành, nếu tồn tại, có thể được sử dụng để giám sát các
sự kiện có liên quan đến Quản lý Truy cập và thậm chí có thể cung
cấp hỗ trợ tuyến đầu và phối hợp trong việc giải quyết các sự kiện
đó khi thích hợp.
6.7 Các Cấu trúc Tổ chức Vận hành Dịch vụ

Một số thông tin chung chung đã được cung cấp về những cân nhắc
mang tính tổ chức đối với từng chức năng (xem đoạn 6.2.3, 6.3.4 và
6.5.6). Phần này sẽ xem xét một số cơ cấu tổ chức cụ thể cho tất cả
các chức năng. Có một số cách thức để tổ chức các chức năng Vận
hành Dịch vụ và mỗi tổ chức sẽ phải đưa ra quyết định của riêng
mình, dựa trên quy mô, địa lý, văn hóa và môi trường kinh doanh
của mình. Một số tùy chọn sẽ được thảo luận trong phần còn lại của
phần này.
6.7.1 Tổ c h ứ c theo chuyên môn k ỹ thuậ t

Theo kiểu tổ chức này, các bộ phận được tạo ra theo công nghệ và
các kỹ năng và hoạt động cần thiết để quản lý công nghệ đó. Vận
hành CNTT sẽ tuân theo cấu trúc của bộ phận Quản lý Ứng dụng và
Quản lý Kỹ thuật. Ý nghĩa của điều này là Vận hành CNTT hướng tới
các chương trình nghị sự của bộ phận Quản lý Ứng dụng và Quản lý
Kỹ thuật.
Cấu trúc này có thể hoạt động tốt, miễn là các nhóm này được hiện
diện đầy đủ trong các quy trình Thiết kế, Kiểm nghiệm và Cải tiến
Dịch vụ, điều này vốn sẽ đảm bảo rằng chương trình nghị sự của họ
được liên kết với các yêu cầu của doanh nghiệp.
Cấu trúc này cũng giả định rằng mọi bộ phận Quản lý Kỹ thuật và
Quản lý Ứng dụng đã phân biệt một cách rõ ràng giữa hoạt động
Quản lý và hoạt động vận hành của họ. Nó cũng yêu cầu họ phải
chuẩn hóa các hoạt động vận hành này để có thể được Quản lý Vận
hành CNTT quản lý một cách hiệu quả mà không cần phải có sự can
thiệp quá mức từ các nhóm hoặc bộ phận Quản lý Kỹ thuật và Quản
lý Ứng dụng.
Ví dụ về cơ cấu tổ chức Vận hành CNTT dựa trên chuyên môn kỹ

thuật được đưa ra trong Hình 6.7.
Hình 6.7 – Vận hành CNTT được tổ chức theo chuyên môn kỹ thuật
(mẫu)
Ưu điểm của kiểu cơ cấu tổ chức này bao gồm:
 Việc thiết lập các mục tiêu hiệu suất nội bộ trở nên dễ dàng
hơn vì mọi nhân viên đều nằm trong một bộ phận duy nhất đều
có chung một bộ các nhiệm vụ tương tự nhau theo công nghệ
tương tự,
 Các thiết bị, hệ thống hoặc nền tảng riêng lẻ có thể được quản
lý một cách hiệu quả hơn vì những người có kỹ năng thích hợp
được dành riêng để quản lý những thiết bị, hệ thống hoặc nền
tảng này và được đo lường theo hiệu suất của họ,
 Quản lý các chương trình đào tạo trở nên dễ dàng hơn vì các
bộ kỹ năng được xác định một cách rõ ràng và được tách thành
các nhóm cụ thể.
Những nhược điểm của loại cơ cấu tổ chức này bao gồm.
 Khi mọi người được chia thành các bộ phận riêng biệt, các ưu
tiên của nhóm họ có xu hướng đè lên các ưu tiên của các bộ
phận khác. Một ví dụ về điều này là khi các bộ phận từ chối
chấp nhận quyền sở hữu một sự cố, mỗi bộ phận đổ lỗi cho bộ
phận kia trong khi công việc kinh doanh vẫn tiếp tục bị gián
đoạn,
 Kiến thức về cơ sở hạ tầng và mối quan hệ giữa các thành phần
rất khó thu thập và bị phân tán. Các nhóm riêng lẻ có khuynh
hướng chỉ thu thập và duy trì dữ liệu cần thiết để hỗ trợ chức
năng của riêng họ và không cung cấp quyền truy cập vào dữ
liệu đó một cách dễ dàng,
 Mỗi công nghệ do một nhóm quản lý được coi như một thực thể
riêng biệt. Điều này trở thành một vấn đề trên các hệ thống
bao gồm nhiều thành phần được quản lý bởi các nhóm khác
nhau, ví dụ, một ứng dụng, do nhóm Quản lý Ứng dụng quản
lý, hoạt động trên máy chủ do bộ phận Quản lý Máy chủ quản
lý, sử dụng phân đoạn mạng do bộ phận Mạng Khu vực Cục bộ
(LAN) quản lý. Nếu một thay đổi được thực hiện bởi một nhóm
hoặc bộ phận mà không tham khảo ý kiến của những bộ phận
khác thì điều này có thể gây thảm họa cho dịch vụ,
 Tác động của hiệu suất kém của một bộ phận đối với dịch vụ
CNTT trở nên khó hiểu hơn vì có nhiều nhóm khác nhau đóng
góp vào cùng một dịch vụ, mỗi nhóm có một bộ mục tiêu hiệu
suất riêng
 Việc theo dõi hiệu suất Dịch vụ CNTT tổng thể trở nên khó
khăn hơn vì mỗi nhóm đang được đo lường trên cơ sở cá nhân,
 Việc điều phối các Đánh giá Thay đổi và Lịch trình Thay đổi trở
nên khó khăn hơn vì nhiều bộ phận khác nhau phải cung cấp
đầu vào cho mỗi thay đổi,
 Công việc đòi hỏi kiến thức về nhiều công nghệ là khó khăn vì
hầu hết các nguồn lực chỉ được đào tạo và quan tâm đến việc
quản lý một công nghệ duy nhất. Do đó, các dự án phải bao
gồm đào tạo chéo, vốn gây ra sự tốn kém thời gian và chi phí.
6.7.2 Tổ c h ứ c theo ho ạ t đ ộ ng
Loại cơ cấu tổ chức này tập trung vào một thực tế là các hoạt động
tương tự phải được thực hiện trên tất cả các công nghệ trong tổ
chức. Điều này có nghĩa là những người thực hiện các hoạt động
tương tự, bất kể công nghệ, nên được nhóm lại với nhau, mặc dù
trong mỗi bộ phận có thể có các nhóm tập trung vào một công nghệ,
ứng dụng cụ thể, v.v…
Theo loại hình tổ chức này, không có sự khác biệt rõ ràng giữa các
lĩnh vực Quản lý Kỹ thuật và Quản lý Ứng dụng khác nhau. Các hoạt
động tương tự từ rất nhiều lĩnh vực khác nhau có thể được nhóm lại
thành một bộ phận duy nhất.
Các ví dụ về các phòng ban đã được thiết lập để thực hiện một nhóm
hoạt động cụ thể trên nhiều công nghệ bao gồm:
 Bảo trì (điều này ngụ ý rằng một nhóm sẽ điều phối và thực
hiện tất cả các hoạt động bảo trì trên tất cả các công nghệ),
 Quản lý Hợp đồng hoặc Quản lý Bên Thứ ba,
 Giám sát và Kiểm soát,
 Cầu nối Vận hành,
 Trung tâm Vận hành Mạng
 Chiến lược Vận hành và Hoạch định Vận hành (là một phần của
quy trình Thiết kế Dịch vụ, thường xác định các tiêu chuẩn
được sử dụng trong Hoạt động CNTT) - bộ phận này có thể
thiết lập chiến lược hoặc tiêu chuẩn cho mọi loại hình lĩnh vực
Quản lý Kỹ thuật và Quản lý Ứng dụng.
Bộ phận Kế hoạch và Chiến lược Vận hành được sử dụng để minh

họa kiểu cấu trúc này trong Hình 6.8.
Hình 6.8 – Một bộ phận dựa trên việc thực thi một bộ các hoạt
động
Ưu điểm của loại hình cơ cấu tổ chức này bao gồm:
 Việc quản lý các nhóm hoạt động liên quan sẽ trở nên dễ dàng
hơn vì tất cả những người tham gia vào các hoạt động này đều
báo cáo cho cùng một người quản lý,
 Việc đo lường các nhóm hoặc bộ phận dựa trên kết quả đầu ra
nhiều hơn là dựa vào các hoạt động riêng lẻ. Điều này giúp xây
dựng mức độ đảm bảo cao hơn rằng một dịch vụ có thể được
cung cấp.
Những nhược điểm của loại cơ cấu tổ chức này bao gồm những điều
sau đây:
 Các nguồn lực có kỹ năng tương tự có thể bị trùng lặp trên các
chức năng khác nhau, dẫn đến chi phí cao hơn,
 Mặc dù đo lường dựa trên kết quả đầu ra nhiều hơn nhưng nó
vẫn tập trung vào hiệu suất của các hoạt động nội bộ hơn là
dựa trên trải nghiệm của khách hàng hoặc người dùng đầu
cuối.
6.7.3 Tổ c h ứ c đ ể q u ả n lý các quy trình

Cấu trúc toàn bộ tổ chức theo các quy trình không ph ải là một ý
tưởng hay. Các quy trình được sử dụng để khắc phục ‘hiệu ứng hầm
ngầm [silo]’ của các phòng ban chứ không phải để tạo ra hầm ngầm.
Tuy nhiên, có một số quy trình sẽ cần một cơ cấu tổ chức chuyên
dụng để hỗ trợ và quản lý nó. Ví dụ, sẽ rất khó để Quản lý Tài chính
thành công nếu không có một bộ phận Tài chính chuyên trách - ngay
cả khi bộ phận đó chỉ bao gồm một số lượng nhỏ nhân viên.
Trong các tổ chức dựa trên-quy trình, mọi người được tổ chức thành
các nhóm hoặc bộ phận để thực hiện hoặc quản lý một quy trình cụ
thể. Điều này tương tự với cấu trúc dựa trên vận hành, ngoại trừ
việc các bộ phận của nó tập trung vào các nhóm hoạt động từ đầu –
đến-cuối hơn là vào một loại hoạt động riêng lẻ.
Nên lưu ý rằng kiểu cấu trúc tổ chức này chỉ nên được sử dụng nếu
Quản lý Vận hành CNTT chịu trách nhiệm về nhiều hoạt động hơn là
chỉ hoạt động Vận hành CNTT. Ví dụ, trong một số tổ chức, Hoạt
động CNTT chịu trách nhiệm cho việc xác định SLA và đàm phán UC.
Ngoài ra, các quy trình đặc biệt tồn tại để liên kết các hoạt động
của các nhóm khác nhau nhằm đạt được một kết quả cụ thể. Việc sử
dụng quy trình làm cơ sở để tạo ra các bộ phận có thể đánh bại mục
đích của việc có quy trình ngay từ đầu. Các bộ phận dựa trên-quy
trình chỉ thực sự hiệu quả khi họ có khả năng phối hợp thực hiện
quy trình thông qua toàn bộ tổ chức.
Điều này có nghĩa là các bộ phận dựa trên-quy trình chỉ nên được
xem xét nếu Quản lý Vận hành CNTT đóng vai trò Chủ sở hữu Quy
trình cho một quy trình cụ thể.
Ví dụ về các nhóm hoặc phòng ban dựa trên quy trình bao gồm:
 Vận hành Công suất,

 Giám sát và Kiểm soát Tính sẵn sàng,
 Quản lý Tài chính CNTT,
 Quản trị Bảo mật,
 Quản lý Tài sản và Cấu hình (bao gồm việc cài đặt và triển khai
thiết bị).
 Các quy trình dễ xác định hơn,

 Ít có xung đột vai trò hơn vì mô tả công việc và mô tả vai trò
quy trình là giống nhau. Trong các cấu trúc khác, một bản mô
tả công việc đơn lẻ thường sẽ bao gồm các hoạt động cho một
số vai trò,
 Các số liệu về hiệu suất của nhóm hoặc của bộ phận và hiệu
suất của quy trình giống nhau, liên kết một cách hiệu quả các
chỉ số "bên trong" và "bên ngoài".
Những nhược điểm của loại cơ cấu tổ chức này bao gồm những điều
sau đây:
 Một nguyên tắc cơ bản của các quy trình là chúng là phương
tiện để liên kết các hoạt động của các bộ phận và nhóm khác
nhau. Bằng cách sử dụng các quy trình làm cơ sở cho thiết kế
tổ chức, các quy trình bổ sung cần được xác định để đảm bảo
rằng các bộ phận sẽ làm việc cùng nhau,
 Ngay cả khi một bộ phận chịu trách nhiệm cho việc thực thi
một quy trình, vẫn sẽ có những phụ thuộc bên ngoài. Các nhóm
có thể không xem các hoạt động của quy trình nằm ngoài quy
trình của chính họ là quan trọng, dẫn đến các quy trình không
thể được thực thi đầy đủ vì không thể đáp ứng các yếu tố phụ
thuộc,
 Mặc dù một số khía cạnh của quy trình có thể được tập trung
hóa nhưng sẽ luôn có một số hoạt động sẽ phải được thực hiện
bởi các nhóm khác. Mối quan hệ giữa nhóm hoặc bộ phận
chuyên trách và những người thực hiện các hoạt động phi tập
trung thường khó xác định và quản lý.
6.7.4 Tổ c h ứ c V ậ n hành CNTT theo khu v ực đ ị a lý

Vận hành CNTT có thể được phân tán về mặt vật lý và trong một số
trường hợp, mỗi vị trí cần được tổ chức theo bối cảnh cụ thể của
riêng nó.
Cấu trúc này thường được sử dụng trong các trường hợp sau:
 Trung tâm dữ liệu bị phân tán về mặt địa lý,

 Các khu vực hoặc quốc gia khác nhau có các công ngh ệ khác
nhau hoặc cung cấp một nhóm dịch vụ khác nhau,
 Có các mô hình kinh doanh hoặc cơ cấu tổ chức khác nhau ở
các khu vực khác nhau, nghĩa là doanh nghiệp được phân cấp
theo vùng địa lý và mỗi Đơn vị Kinh doanh là tương đối tự chủ,
 Các luật lệ khác nhau áp dụng cho các quốc gia hoặc khu vực
khác nhau (ví dụ, các quy định về an toàn),
 Các tiêu chuẩn khác nhau áp dụng cho các quốc gia hoặc khu
vực khác nhau,
 Sự khác biệt về văn hóa hoặc ngôn ngữ tồn tại giữa các nhân
viên quản lý CNTT.
Ví dụ về kiểu cấu trúc này được đưa ra trong Hình 6.9. Hãy l ưu ý
rằng trong ví dụ này, mỗi bộ phận địa lý được cấu trúc nội bộ bằng
cách sử dụng Chuyên môn Kỹ thuật. Điều này có thể khác nhau theo
mỗi khu vực. Ví dụ, một vùng có thể được cấu trúc theo cách này,
trong khi vùng khác sử dụng cấu trúc dựa trên quy trình hoặc hoạt
động.
Hình 6.9 – Vận hành CNTT được tổ chức theo khu vực địa lý
Hình 6.9 cũng cho thấy rằng một khu vực có thể thực hiện các hoạt
động được tập trung hóa cho mọi vùng nếu các vùng đủ giống nhau.
Trong ví dụ này, Bộ phận Vận hành Máy chủ Hoa Kỳ quản lý một
hoạt động mày chủ trong mọi khu vực, Brussels quản lý mọi hoạt
động cơ sở dữ liệu và Singapore quản lý mọi hoạt động lưu trữ.
 Cơ cấu tổ chức có thể được tùy chỉnh để đáp ứng các điều kiện
địa phương,
 Vận hành CNTT có thể được tùy chỉnh để đáp ứng các mức khác
nhau của dịch vụ CNTT theo từng khu vực.
Những nhược điểm của loại hình cơ cấu tổ chức này bao gồm:
 Các tuyến báo cáo và cấu trúc quyền hạn có thể gây ra sự
nhầm lẫn. Ví dụ: Vận hành Mạng báo cáo cho Nhà quản lý
Trung tâm Dữ liệu cục bộ hay cho Nhà quản lý Vận hành Mạng
tập trung?
 Các tiêu chuẩn vận hành khó áp đặt, dẫn đến các hoạt động và
công cụ không nhất quán và trùng lặp, kéo theo sự sụt giảm
hiệu quả kinh tế của quy mô, do đó làm tăng chi phí ho ạt động
chung,
 Sự nhân bản các vai trò, hoạt động, công cụ và cơ sở vật chất
trên nhiều địa điểm có thể rất tốn kém,
 Các dịch vụ dùng chung, chẳng hạn như e-mail, khó cung cấp
hơn vì mỗi khu vực tổ chức hoạt động một cách khác nhau.
 Giao tiếp với khách hàng và bên trong nội bộ CNTT sẽ khó khăn
hơn vì họ không ở cùng vị trí và nhân viên ở một địa điểm có
thể khó hiểu được các ưu tiên của khách hàng hoặc nhân viên
ở địa điểm khác.
6.7.5 Các c ấu trúc t ổ c h ứ c h ỗn h ợ p

Không có khả năng rằng Quản lý Vận hành CNTT sẽ được cơ cấu chỉ
sử dụng một loại hình cơ cấu tổ chức. Hầu hết các tổ chức đều sử
dụng một chuyên môn kỹ thuật, cùng với một số hoạt động bổ sung
– hoặc các bộ phận dựa trên-quy trình.
Loại hình cơ cấu được sử dụng và sự kết hợp chính xác của các bộ
phận chuyên môn kỹ thuật, dựa trên-hoạt động và dựa trên-quy
trình sẽ phụ thuộc vào một số các biến số tổ chức.
Các biến số cơ cấu tổ chức
Các tiêu chí chính xác được chọn và các cơ cấu tổ chức kéo theo đó sẽ phụ thuộc
vào một số các biến số, vốn có thể bao gồm:
 Bản chất của việc kinh doanh,

 Các yêu cầu nghiệp vụ và những kỳ vọng,
 Kiến trúc công nghệ và kỹ thuật,
 Tính ổn định của Cơ sở hạ tầng CNTT hiện tại và tính sẵn sàng của các kỹ
năng để quản lý nó,
 Sự quản trị của tổ chức (nghĩa là, cách thức mà theo đó thẩm quyền đưuọc
chỉ định và quyết định được đưa ra – cũng như với bất kỳ khuôn khổ quản trị
chính thức nào được sử dụng, chẳng hạn như COBIT hoặc SOX),
 Môi trường lập pháp, chính trị và kinh tế của tổ chức,
 Loại hình và mức độ kỹ năng sẵn có đối với tổ chức,
 Quy mô, độ tuổi và sự trưởng thành của tổ chức,
 Phong cách quản lý của tổ chức,
 Sự phụ thuộc vào CNTT đối với các hoạt động, quy trình và chức năng nghiệp
vụ tối quan trọng,
 Cách thức mà theo đó, CNTT tham gia vào m ạng lưới giá trị (nghĩa là, cách
thức mà theo đó, CNTT tương tác với doanh nghiệp và các đối tác, nhà cung
cấp và khách hàng của nó),
 Mối quan hệ giữa CNTT và các nhà thầu của nó.
Để có một mô tả hoàn chỉnh hơn về cách mà những yếu tố này ảnh hưởng đến
thiết kế tổ chức, vui lòng tham khảo phần ‘Phát triển Tổ chức’ của ấn phẩm Chiến
lược Dịch vụ.
6.7.5. 1 Các ch ức năng đư ợ c k ết h ợ p
Một loại hình tổ chức nên được thảo luận. Cơ cấu này kết hợp các bộ
phận Vận hành CNTT, Quản lý Kỹ thuật và Quản lý Ứng dụng thành
một cơ cấu duy nhất. Đây là trường hợp đôi khi mọi nhóm được định
vị trong một trung tâm dữ liệu duy nhất. Tại đây, Nhà quản lý Trung
tâm Dữ liệu chịu trách nhiệm cho tất cả Quản lý Kỹ thuật, Quản lý
Ứng dụng, và Quản lý Vận hành CNTT.
Loại hình cơ cấu tổ chức này được minh hoạt trong Hình 6.10.
Hình 6.10 – Cơ cấu Quản lý Ứng dụng, Quản lý Kỹ thuật và Quản lý

Vận hành CNTT tập trung hóa
Trong cấu trúc này, Quản lý Vận hành CNTT chịu trách nhiệm cho
các chức năng Quản lý Ứng dụng và Quản lý Kỹ thuật, vốn đến lượt
mình, chịu trách nhiệm cho việc quản lý các hoạt động vận hành của
riêng mình. Từng bộ phận có khả năng ủy thác một vài trong số
những hoạt động này cho bộ phận Kiểm soát Vận hành.
Ưu điểm của cơ cấu tổ chức này là:
 Có sự nhất quán và kiểm soát nhiều hơn giữa các hoạt động
Quản lý Kỹ thuật mang tính chiến thuật và chiến lược nhiều
hơn,
 Dễ dàng thực thi các tiêu chuẩn hiệu suất và các kiến trúc kỹ
thuật đã được tạo ra trong Thiết kế Dịch vụ, vì những ai đã
tham gia vào quá trình thiết kế đang quản lý những hoạt động
của những ai đang thực thi các hoạt động đó,
 Vì không có sự trùng lặp giữa địa điểm hoặc hoạt động, cơ cấu
này thường hiệu quả hơn về mặt chi phí.
Nhuợc điểm của cơ cấu tổ chức này là:
 Phạm vi của cơ cấu này khiến cho nó trở nên rất khó để quản
lý một cách hiệu quả trong các tổ chức lớn hoặc trong các tổ
chức với nhiều Trung tâm Dữ liệu.
6.7.5. 2 Tổ c h ứ c Q u ả n lý K ỹ thu ậ t và Q u ản lý Ứ ng
dụng
Các tổ chức Quản lý Kỹ thuật và Quản lý Ứng dụng có khuynh hướng
tương đối đơn giản. Như đã được nêu ra trong đoạn 6.3.4 và 6.5.6,
các bộ phận Quản lý Kỹ thuật thường dựa vào công nghệ mà họ đang
quản lý và các bộ phận Quản lý Ứng dụng dựa vào các ứng dụng và
các bộ ứng dụng mà họ quản lý.
Tuy nhiên, có một số cơ cấu tổ chức và biến thể thay thế, sẽ được
thảo luận trong phần này.
6.7.5. 3 Khu v ực đ ịa lý
Trong các tổ chức có nhiều địa điểm, thông thường thì các bộ phận
Quản lý Ứng dụng và Quản lý Kỹ thuật được hiện diện ở mỗi địa
điểm thực tế. Tuy nhiên, điều này không có nghĩa là mỗi vị trí sẽ có
tất cả các bộ phận giống nhau hoặc tất cả họ đều chịu trách nhiệm
cho các hành động giống nhau.
Khi các công cụ hỗ trợ và quản lý ngày càng hoàn thiện, ngày càng
có nhiều Cơ sở hạ tầng CNTT và Đơn vị Cấu hình ứng dụng có thể
được quản lý từ xa. Điều này có nghĩa là mỗi bộ phận sẽ có một
nhóm Quản lý Ứng dụng hoặc Quản lý Kỹ thuật mạnh và được tập
trung, với các thành viên địa phương để cung cấp các hoạt động
hoặc sự hỗ trợ chuyên biệt và tại chỗ.
Ví dụ, trong Quản lý máy chủ, nhóm trung tâm sẽ giúp tạo ra các
tiêu chuẩn cho cấu hình máy chủ, họ sẽ giám sát và kiểm soát các
thiết bị từ xa, thực hiện sao lưu, thực hiện nâng cấp Hệ điều hành,
v.v… Các nhóm cục bộ sẽ cung cấp hỗ trợ cơ bản tại chỗ, bảo trì
phần cứng và sửa chữa, thiết lập cấu hình và cài đặt các máy chủ
mới.
Trong Quản lý Ứng dụng, nhóm trung tâm có thể tham gia vào quá
trình thiết kế và kiểm nghiệm liên tục ứng dụng, giám sát và kiểm
soát; thực hiện sao lưu, kiểm tra tính toàn vẹn của dữ liệu, v.v…
Nhóm địa phương có thể cung cấp hỗ trợ và giáo dục tại chỗ cho
người dùng đầu cuối và làm việc với nhóm Quản lý Kỹ thuật địa
phương để giải quyết các vấn đề phức tạp hơn có liên quan đến các
thiết bị địa phương.
Tuy nhiên, có một vấn đề tiềm ẩn cần phải được giải quyết, đó là
người mà nhóm địa phương báo cáo. Trong một số tổ chức, họ báo
cáo cho nhà quản lý của nhóm tập trung. Điều này sẽ bổ sung thêm
lợi thế về hiệu suất và sự quản lý nhất quán trên toàn bộ doanh
nghiệp.
Trong các tổ chức khác, các nhóm địa phương báo cáo cho Nhà quản
lý CNTT cấp cao nhất tại địa điểm đó. Điều này bổ sung thêm lợi thế
là Dịch vụ CNTT có thể được tùy chỉnh để đáp ứng các điều kiện địa
phương, nhưng nó tạo ra nhiều bối rối về việc các nhóm địa phương
nên nhận được sự chỉ đạo từ ai.
Những ưu điểm của loại hình cơ cấu tổ chức này bao gồm những
điều dưới đây.
 Cơ cấu tổ chức có thể được tùy chỉnh để đáp ứng các điều kiện
địa phương,
 Quản lý Kỹ thuật và Quản lý Ứng dụng có thể được tùy chỉnh
để đáp ứng các mức độ dịch vụ CNTT khác nhau giữa các vùng.
Những nhược điểm của loại hình cơ cấu tổ chức này bao gồm những
 Các luồng báo cáo và cấu trúc quyền hạn có thể gây ra sự
nhầm lẫn,
 Các tiêu chuẩn rất khó để áp đặt, dẫn đến các hoạt động và
công cụ không nhất quán và bị trùng lặp, dẫn đến giảm hiệu
quả kinh tế của quy mô, do đó làm tăng chi phí ho ạt động tổng
thể,
 Sự trùng lặp của các vai trò, hoạt động, công cụ và phương
tiện trên nhiều địa điểm có thể rất tốn kém.
6.7.5. 4 C ấ u trúc Q u ản lý K ỹ thuậ t và Q u ản lý Ứ ng

dụng h ỗn h ợ p
Một số tổ chức lại tổ chức các chức năng Quản lý Kỹ thuật và Quản
lý Ứng dụng của mình theo các hệ thống. Điều này có nghĩa rằng
từng bộ phận sẽ được cấu thành từ các chuyên gia ứng dụng và các
chuyên gia kỹ thuật Cơ sở hạ tầng CNTT, tất cả đều hướng tới việc
quản lý các dịch vụ dựa trên tập hợp các hệ thống đó. Các thành
phần được chia sẻ trên toàn bộ các hệ thống này, chẳng hạn như
mạng, sẽ được quản lý bởi bộ phận Quản lý Kỹ thuật chuyên biệt.
Ưu điểm của cơ cấu tổ chức này là:
 Việc tạo ra kết quả đầu ra có chất lượng cao cho người dùng
đầu cuối là dễ dàng hơn bởi vì mọi thành viên của các bộ phận
đều được tập trung vào sự thành công của toàn thể hệ thống
thay vì là hiệu suất của một thành phần công nghệ hoặc ứng
dụng riêng lẻ.
Nhược điểm của cơ cấu tổ chức này là:
 Sự trùng lặp của các kỹ năng và nguồn lực trên một số bộ phận
sẽ làm gia tăng chi phí của tổ chức. Ví dụ, mỗi nhóm có khả
năng có một cá nhân hoặc nhóm chuyên biệt để quản lý các
máy chủ - mỗi một trong số họ sẽ thực hiện các tác vụ tương
tự nhau,
 Giao tiếp giữa các nhân viên đang quản lý những công nghệ
tương tự nhau sẽ bị giảm thiểu. Điều này cũng làm giảm lượng
học tập qua kinh nghiệm và gia tăng sự phụ thuộc vào các
công cụ quản lý kiến thức cộng tác,
 Khi những người có kỹ năng tương tự ở trong cùng một bộ
phận, bộ phận sẽ bù đắp cho những thành viên có trình độ kỹ
năng và năng lực thấp hơn. Khi chỉ có một người có kỹ năng
Quản lý Máy chủ trong một bộ phận dựa trên hệ thống, và năng
lực của họ là tối thiểu, điều đó sẽ ảnh hưởng đến hiệu quả
hoạt động của toàn thể bộ phận.
7 N h ững cân nh ắ c v ề công ngh ệ

Mỗi chức năng và quy trình được xác định trong các phần có liên
quan trong Chương 4 và Chương 6. Chương này s ẽ kết hợp mọi yêu
cầu công nghệ lại với nhau để xác định yêu cầu tổng thể của một bộ
công nghệ Quản lý Dịch vụ được tích hợp cho Vận hành Dịch vụ.
Công nghệ tương tự nhau, với một số bổ sung khả dĩ, nên được sử
dụng cho các giai đoạn khác của ITSM – Chiến lược Dịch vụ, Thiết kế
Dịch vụ, Chuyển tiếp Dịch vụ và Liên tục Cải tiến Dịch vụ - để mang
lại tính nhất quán và cho phép một Vòng đời ITSM hiệu quả được
quản lý một cách đúng đắn.
Những yêu cầu chính đối với Vận hành Dịch vụ được nêu ra trong
chương này.
7.1 Các yêu cầu chung

Một công nghệ ITSM được tích hợp (hoặc bộ công cụ, khi một số nhà
cung cấp bán công nghệ của họ theo ‘mô-đun’ trong khi một số tổ
chức có thể chọn tích hợp các sản phẩm từ các nhà cung cấp thay
thế) là cần thiết để bao gồm những chức năng cốt lõi dưới đây.
7.1.1 Tự- Hỗ trợ

Rất nhiều tổ chức nhận thấy họ được hưởng lợi khi cung cấp năng
lực ‘Tự-Hỗ trợ’ cho người dùng của họ. Do đó, công nghệ nên hỗ trợ
cho năng lực này với một số hình thức web front-end cho phép các
trang web cung cấp một loạt đề xuất Tự-Hỗ trợ và Yêu cầu Dịch vụ
theo hướng menu – với một tương tác trực tiếp và phần mềm xử lý-
quy trình back-end.
7.1.2 Động c ơ lu ồn g công vi ệc h o ặ c quy trình

Một động cơ kiểm soát quy trình hoặc luồng công việc là cần thiết
để cho phép định nghĩa trước và kiểm soát các quy trình đã được
xác định chẳng hạn nhu một Vòng đời Sự cố, Vòng đời Thực hiện
Yêu cầu, Vòng đời Vấn đề, Mô hình Thay đổi, v.v…
Điều này nên cho phép trách nhiệm, các hoạt động, khung thời gian,
lộ tuyến leo thang và cảnh báo được xác định trước và sau đó được
quản lý một cách tự động.
7.1.3 CMS đ ư ợ c tích h ợ p

Công cụ nên có một CMS được tích hợp để cho phép những tài sản,
thành phần Cơ sở hạ tầng CNTT, các dịch vụ và bất kỳ Đơn vị Cấu
hình phụ thuộc nào của tổ chức (chẳng hạn như các hợp đồng, địa
điểm, giấy phép sử dụng, nhà cung cấp, v.v… - bất kỳ thứ gì mà tổ
chức CNTT muốn kiểm soát) được xử lý, cùng với mọi thuộc tính có
liên quan, trong một địa điểm tập trung – và để hỗ trợ cho các mối
quan hệ giữa mỗi thành phần được lưu giữ và duy trì, và được liên
kết tới các Hồ sơ Sự cố, Vấn đề, Lỗi Đã biết và Hồ sơ Thay đổi nếu
thích hợp.
7.1.4 Công n gh ệ Kh ám ph á/Tri ể n khai/C ấ p p hép

Để điền vào hoặc xác minh dữ liệu CMS và để hỗ trợ Quản lý Giấy
phép, công cụ khám phá hoặc kiểm tra tự động hóa sẽ là điều bắt
buộc. Các công cụ này phải có khả năng chạy từ bất kỳ vị trí nào
trên mạng và cho phép thẩm tra và khôi phục thông tin liên quan
đến tất cả các thành phần tạo nên hoặc được kết nối tới Cơ sở hạ
tầng CNTT.
Những công nghệ như vậy sẽ cho phép ‘lọc’ để dữ liệu đang được
chuyển tiếp có thể được kiểm tra và chỉ những dữ liệu cần thiết mới
được trích xuất. Nó cũng rất hữu ích nếu ‘chỉ thay đổi’ vì lần kiểm
tra cuối cùng có thể được trích xuất và báo cáo.
Công nghệ tương tự thường có thể được sử dụng để triển khai phần
mềm mới tới các vị trí được nhắm mục tiêu - đây là một yêu cầu
thiết yếu đối với tất cả các nhóm hoặc bộ phận Vận hành Dịch vụ,
để cho phép các bản vá lỗi, truyền tải, v.v… được phân phối đến
đúng người dùng.
Một tương tác tới năng lực ‘Tự-Hỗ trợ’ là thỏa đáng để hỗ trợ cho
các bản tải xuống của phần mềm đã được phê duyệt được yêu cầu
theo cách này nhưng được xử lý một cách tự động bởi phần mềm
triển khai.
Các công cụ cho phép tự động so sánh chi tiết của giấy phép phần
mềm được nắm giữ (lý tưởng là trong CMS) và số giấy phép thực tế
đã được triển khai - với báo cáo về bất kỳ sự khác biệt nào - là điều
cực kỳ thích đáng.
7.1.5 Kiểm soát t ừ xa
Thường sẽ rất hữu ích đối với các Chuyên gia phân tích B ộ phận Hỗ
trợ Dịch vụ và các nhóm hỗ trợ khác khi có khả năng kiểm soát màn
hình máy tính của người dùng (theo các điều kiện bảo mật đã được
một cách thích hợp) để cho phép họ tiến hành các cuộc điều tra
hoặc sửa chữa cấu hình, v.v… Việc tạo điều kiện cho mức độ kiểm
soát từ xa này sẽ là điều cần thiết.
7.1.6 Các ti ện ích ch ẩ n đoán

Sẽ cực kỳ hữu ích đối với Bộ phận Hỗ trợ Dịch vụ và các nhóm hỗ
trợ khác nếu công nghệ được kết hợp với năng lực để tạo ra và sử
dụng các tập lệnh kịch bản chẩn đoán và các tiện ích chẩn đoán
khác (chẳng hạn như, ví dụ, các công cụ lập luận dựa trên tình
huống) để hỗ trợ việc chẩn đoán sự cố sớm hơn. Lý tưởng nhất,
chúng nên ‘nhạy cảm với ngữ cảnh’ và việc trình bày các tập lệnh
kịch bản đã được tự động hóa hết mức có thể.
7.1.7 B áo cáo
Việc lưu trữ dữ liệu sẽ không được sử dụng trừ khi nó có thể được
trích xuất một cách dễ dàng và được sử dụng để đáp ứng những mục
đích của tổ chức. Do đó, công nghệ nên kết hợp các năng lực báo
cáo phù hợp, cũng như cho phép các giao di ện tiêu chuẩn vốn có
thể được sử dụng để nhập dữ liệu vào các gói báo cáo theo tiêu
chuẩn ngành, các trang thông tin t ổng quan, v.v… Lý tưởng nhất là
báo cáo tức thì, trên màn hình (hàm ý chỉ các báo cáo dưới định
dạng điện tử - người dịch) cũng như các báo cáo đã được in ra có
thể được cung cấp thông qua việc sử dụng các báo cáo ‘hàng đầu’
nhạy cảm với ngữ cảnh.
7.1.8 B ả ng thông t in t ổn g quan
Công nghệ kiểu bảng thông tin tổng quan là rất hữu ích để cho phép
khả năng hiển thị ‘trong nháy mắt’ về hiệu suất dịch vụ CNTT và
mức độ khả dụng tổng thể. Những hiển thị như vậy có thể được đưa
vào các báo cáo cấp quản lý cho người dùng và khách hàng - nhưng
cũng có thể cung cấp thông tin theo thời gian thực để đưa vào các
trang web CNTT nhằm cung cấp báo cáo động và có thể được sử
dụng cho mục đích hỗ trợ và điều tra. Khả năng hỗ trợ các chế độ
xem thông tin được tùy chỉnh để đáp ứng các mức độ quan tâm cụ
thể có thể hữu ích một cách rõ ràng.
Tuy nhiên, đôi khi chúng th ể hiện một quan điểm kỹ thuật thay vì
quan điểm dịch vụ về cơ sở hạ tầng và trong những trường hợp đó,
chúng có thể ít hữu ích hơn đối với khách hàng và người dùng.
7.1.9 Tích h ợ p v ớ i Q u ả n lý D ịch v ụ Nghi ệp v ụ

Có một khuynh hướng trong ngành CNTT khi cố gắng kết hợp việc
kinh doanh có liên quan đến CNTT với các quy trình và nguyên tắc
của Quản lý Dịch vụ CNTT – một số người gọi là Quản lý Dịch vụ
Nghiệp vụ. Để tạo điều kiện thuận lợi cho việc này các ứng dụng và
công cụ nghiệp vụ cần phải được tương tác với các công cụ hỗ trợ
ITSM để cung cấp các chức năng cần thiết. Điều này có thể được
minh họa bởi ví dụ sau đây:
Một công ty viễn thông Đông Âu đã có thể kết nối hệ thống thanh toán và giám
sát mạng điện thoại di động của mình vói các quy trình Quản lý Sự kiện, Quản lý
Sự cố và Quản lý Cấu hình của mình. Theo cách này họ đã có khả năng phát hiện
ra bất kỳ hình thái sử dụng/thanh toán bất thường nào và diễn giải những điều
này để họ có thể xác định, với mức độ chắc chắn cao, rằng một điện thoại đã bị
đánh cắp và đang được sử dụng để thực hiện các cuộc gọi bất hợp pháp.
Họ đã có thể đưa ra các sự kiện đối với các hình mẫu nói trên và các hành động
tự động để đình chỉ việc sử dụng các thiết bị điện thoại di động, và song song với
điều này, xác định chính xác vị trí của người dùng bất hợp pháp (bằng cách sử
dụng công nghệ GPRS0 và nêu ra các sự cố để cảnh sát có khả năng tìm kiếm kẻ
trộm bị nghi ngờ và khôi phục lại thiết bị.
Những năng lực tích hợp công cụ được nâng cao hơn nữa là điều cần
thiết để cho phép khai thác tốt hơn loại hình kinh doanh và tích hợp
CNTT này.
7.2 Quản lý Sự kiện
Các tính năng dưới đây là đáng để mong muốn đối với bất kỳ công
nghệ Quản lý Sự kiện nào:
 Đa-môi trường, giao diện mở để cho phép việc giám sát và

cảnh báo trên các dịch vụ không đồng nhất và toàn bộ Cơ sở
hạ tầng CNTT của một tổ chức,
 Dễ dàng triển khai, với chi phí thiết lập tối thiểu,
 Tác nhân ‘tiêu chuẩn’ để giám sát hầu hết các môi
trường/thành phần/hệ thống phổ biến,
 Giao diện mở để chấp nhận bất kỳ đầu vào sự kiện tiêu chuẩn
nào (ví dụ, SNMP) và tạo ra nhiều cảnh báo,
 Định tuyến tập trung mọi sự kiện đến một vị trí duy nhất, có
thể lập trình để cho phép (các) vị trí khác nhau tại nhiều thời
điểm,
 Hỗ trợ các giai đoạn thiết kế/thử nghiệm - để từ đó, các ứng
dụng/dịch vụ mới có thể được giám sát trong giai đoạn thiết
kế/thử nghiệm và kết quả được phản hồi lại cho quá trình thiết
kế và chuyển tiếp,
 Có thể lập trình việc đánh giá và xử lý các cảnh báo tùy thuộc
vào các triệu chứng và tác động,
 Khả năng cho phép một nhân viên vận hành xác nhận một cảnh
báo và nếu không có phản hồi nào được nhập trong một khung
thời gian xác định, để leo thang cảnh báo,
 Chức năng báo cáo thích hợp để cho phép phản hồi lại cho các
giai đoạn thiết kế và chuyển tiếp cũng như cung cấp thông tin
quản lý có ý nghĩa và ‘bảng thông tin tổng quan’ của người
dùng doanh nghiệp.
Công nghệ như vậy sẽ cho phép một tương tác trực tiếp vào các quy
trình Quản lý Sự cố của tổ chức (thông qua mục nhập vào Nhật ký
Sự cố), cũng như khả năng leo thang sang nhân viên hỗ trợ, nhà
cung cấp bên thứ ba, các kỹ sư, v.v… qua e-mail, tin nhắn SMS,
v.v…
Những cơ sở vật chất chuyên dụng, hoặc có thể là các công cụ

chuyên dụng riêng biệt, sẽ được yêu cầu để giám sát trang web.
Những cơ sở như vậy phải có khả năng mô phỏng lưu lượng truy cập
của khách hàng vào trang web và báo cáo v ề tính sẵn sàng và hiệu
suất liên quan đến ‘trải nghiệm khách hàng’.
7.3 Quản lý Sự cố
7.3.1 Công n gh ệ IT SM đư ợ c tích h ợ p

Công nghệ ITSM được tích hợp là bắt buộc có chức năng sau:
 Một CMS đầy đủ để cho phép các mối quan hệ đã được tự động
hóa được thực hiện và duy trì giữa các sự cố, yêu cầu dịch vụ,
vấn đề, Lỗi Đã biết và tất cả các đơn vị cấu hình khác,
 CMS có thể được sử dụng để hỗ trợ việc xác định mức độ ưu
tiên và hỗ trợ điều tra và chẩn đoán,
 Một động cơ luồng quy trình để cho phép các quy trình được
xác định trước (bao gồm các mô hình sự cố đã được xác định
trước, xem đoạn 3.2.1.5) và được kiểm soát một cách tự động -
với định tuyến nội bộ linh hoạt đến tất cả các nhóm hỗ trợ có
liên quan và giao diện e-mail/SMS bên ngoài,
 Khả năng cảnh báo và báo cáo tự động để ngăn chặn việc một
sự cố bị bỏ qua hoặc trì hoãn,
 Giao diện mở đối với các công cụ Quản lý Sự kiện, do đó bất kỳ
lỗi nào có thể tự động được đưa ra thành sự cố,
 Một giao diện web cho phép các yêu cầu tự trợ giúp và yêu cầu
dịch vụ được nhập vào thông qua màn hình Internet/Intranet,
 Một KEDB được tích hợp để các sự cố/vấn đề đã được chẩn
đoán và/hoặc đã được giải quyết có thể được ghi lại và tìm
kiếm để giúp tăng tốc độ giải quyết sự cố trong tương lai,
 Các phương tiện báo cáo dễ sử dụng để cho phép các chỉ số sự
cố được tạo ra và tạo điều kiện thuận lợi cho việc phân tích sự
cố vì các mục đích Quản lý Sự cố và Quản lý Tính sẵn sàng,
 Các công cụ chẩn đoán (được tích hợp hoặc giao diện cho các
sản phẩm riêng biệt), như đã được đề cập trong Bộ phận Hỗ
trợ Dịch vụ.
7.3.2 Q uy trình cô ng vi ệ c và leo thang đư ợ c t ự

động h óa
Đích nhắm mục tiêu về thời gian nên được đưa vào các công cụ hỗ
trợ, những công cụ này nên được sử dụng để tự động hóa việc kiểm
soát quy trình làm việc và lộ tuyến leo thang.
Ví dụ: nếu nhóm hỗ trợ tuyến thứ hai không giải quyết được sự cố
trong vòng đích nhắm mục tiêu 60 phút đã được thỏa thuận thì sự cố
phải được tự động chuyển đến nhóm hỗ trợ tuyến thứ ba thích hợp
(đã được xác định bằng cách phân loại sự cố) - và bất kỳ sự leo
thang phân cấp cần thiết nào cũng nên được thực hiện một cách tự
động (ví dụ: tin nhắn SMS tới Nhà quản lý Bộ phận Hỗ trợ Dịch vụ,
Nhà quản lý Sự cố và/hoặc Nhà quản lý Dịch vụ CNTT và có thể cho
người dùng, nếu thích hợp). Nhóm hỗ trợ tuyến thứ hai phải được
thông báo về hành động leo thang như một phần của quy trình đã
được tự động hóa.
7.4 Thực hiện yêu cầu

Công nghệ ITSM đã được tích hợp là cần thiết để từ đó các Yêu cầu
Dịch vụ có thể được liên kết tới các sự cố hoặc sự kiện đã khởi đầu
chúng (và được lưu trữ trong cùng CMS, vốn có thể được thẩm tra
để báo cáo so với các SLA). Một số tổ chức sẽ hài lòng khi sử dụng
yếu tố Quản lý sự cố của các công cụ đó và coi Yêu cầu Dịch vụ như
một tập hợp con và danh mục sự cố đã được xác định. Khi một tổ
chức chọn đưa ra các Yêu cầu Dịch vụ tách biệt, tổ chức đó sẽ cần
một công cụ cho phép khả năng này.
Khả năng Tự trợ giúp của Front-end sẽ cần thiết để cho phép người
dùng gửi các yêu cầu thông qua một số hình thức của quy trình lựa
chọn hướng menu và dựa trên web.
Về tất cả các khía cạnh khác, các phương tiện cần thiết để quản lý
các Yêu cầu Dịch vụ rất giống với các phương tiện để quản lý sự cố:
kiểm soát quy trình làm việc đã được xác định trước của các Mô hình
Yêu cầu, các mức độ ưu tiên, leo thang được tự động hóa, báo cáo
hiệu quả, v.v…
7.5 Quản lý Vấn đề
7.5.1 Công n gh ệ Q uả n lý D ịch v ụ đượ c Tích h ợ p

Một công cụ ITSM đã được tích hợp là cần thiết để phân biệt các sự
cố và các vấn đề - đề từ đó, các Hồ sơ Vấn đề tách biệt có thể được
đưa ra để xử lý những nguyên nhân nền tảng của các sự cố, nhưng
được liên kết tới các sự cố có liên quan. Chức năng của các Hồ sơ
Vấn đề nên tương tự như những chức năng cần thiết đối với Hồ sơ
Sự cố và đồng thời cho phép đối sánh nhiều sự cố với Hồ sơ Vấn đề.
7.5.2 Q uả n lý Thay đ ổi
Sự tích hợp với Quản lý Thay đổi là điều rất quan trọng, để từ đó
các Hồ sơ Yêu cầu, Sự kiện, Sự cố và Vấn đề có thể tương quan với
các RFC đã gây ra sự cố. Điều này nhằm đánh giá sự thành công của
quy trình Quản lý Thay đổi - cũng như Hồ sơ Sự cố và Hồ sơ Lỗi đã
biết - và để các RFC có thể được đưa ra một cách dễ dàng để kiểm
soát các hoạt động cần thiết để khắc phục các vấn đề đã được xác
định thông qua Phân tích Nguyên nhân g ốc rễ hoặc Chủ động Phân
tích Khuynh hướng.
7.5.3 CMS đ ư ợ c Tí ch h ợ p
Một điều cũng rất quan trọng nữa là phải có một CMS được tích hợp
cho phép các Hồ sơ Sự cố được liên kết với các thành phần bị ảnh
hưởng và các dịch vụ bị tác động - và với bất kỳ Đơn vị Cấu hình có
liên quan nào khác.
Quản lý Cấu hình hình thành nên một phần của SKMS lớn hơn bao
gồm các liên kết đến nhiều kho dữ liệu được sử dụng trong Vận hành
Dịch vụ. Quy trình và thực tiễn của Quản lý Cấu hình và các yêu cầu
công nghệ cơ bản của nó được bao gồm trong ấn phẩm Chuyển tiếp
Dịch vụ.
7.5.4 Cơ s ở dữ l iệ u L ỗi đ ã bi ết
Một KEDB hiệu quả sẽ là yêu cầu thiết yếu, cho phép dễ dàng lưu
trữ và truy xuất dữ liệu Lỗi Đã biết.
Các phương tiện báo cáo phù hợp là cần thiết để dễ dàng tạo ra các
báo cáo quản lý, cho phép kết hợp dữ liệu một cách tự động mà
không cần nhập lại dữ liệu - và cho phép khả năng Phân tích Sự cố
và Phân tích Vấn đề sâu hơn.
Lưu ý: Trong một số trường hợp, các thành phần hoặc hệ thống
đang được điều tra bởi Quản lý Sự cố có thể được cung cấp bởi các
nhà cung cấp hoặc nhà sản xuất bên thứ ba. Để giải quyết vấn đề
này, cũng có thể cần phải sử dụng các công cụ hỗ trợ và/hoặc KEDB
của nhà cung cấp.
7.6 Quản lý Truy cập
Quản lý Truy cập sử dụng nhiều công nghệ khác nhau, chủ yếu:
 Công nghệ Quản lý Nguồn Nhân lực, để xác minh danh tính của
người dùng và theo dõi trạng thái của họ,
 Công nghệ Dịch vụ Danh bạ (xem phần 5.8 để biết mô tả về
Dịch vụ Danh bạ). Công nghệ này cho phép các nhà quản lý
công nghệ chỉ định tên gọi cho các tài nguyên trên một mạng,
và sau đó cung cấp quyền truy cập đến những tài nguyên đó
dựa trên hồ sơ của người dùng. Các công cụ Dịch vụ Danh bạ
cũng cho phép Quản lý Truy cập tạo ra những vai trò và các
nhóm để liên kết chúng với cả người dùng lẫn tài nguyên,
 Các tính năng Quản lý Truy cập trong các Ứng dụng, Phần mềm
trung gian, Hệ điều hành và Hệ điều hành Mạng,
 Các hệ thống Quản lý Thay đổi,
 Công nghệ Thực hiện Yêu cầu (xem phần 7.4).
7.7 Bộ phận Hỗ trợ Dịch vụ

Cần cung cấp đầy đủ các công cụ và công nghệ hỗ trợ để cho phép
nhân viên Bộ phận Hỗ trợ Dịch vụ thực hiện vai trò của họ một cách
càng hiệu quả và hiệu suất càng tốt. Điều này sẽ bao gồm những
7.7.1 Hệ th ố ng đi ệ n tho ạ i
Bởi vì một tỷ lệ cao các sự cố có thể được đưa ra từ các cuộc điện
thoại từ người dùng, nên Bộ phận Hỗ trợ Dịch vụ cần được cung cấp
các dịch vụ điện thoại tốt và hiện đại. Điều này nên bao gồm:
 Một hệ thống phân phối cuộc gọi tự động (Automated Call

Distribution - ACD) cho phép một số điện thoại duy nhất (hoặc
một nhóm các số nếu Bộ phận Hỗ trợ Dịch vụ phân tán hoặc
phân đoạn là tùy chọn ưu tiên) và khả năng nhận cuộc gọi theo
nhóm (pick-up). Cảnh báo: Nếu các tùy chọn được cung cấp
qua ACD, qua bàn phím hoặc lựa chọn Nhận dạng Giọng nói
Tương tác (Interactive Voice Recognition - IVR), đừng sử dụng
quá nhiều mức tùy chọn hoặc đưa ra các tùy chọn không rõ
ràng. Ngoài ra, không bao gồm bất kỳ tùy chọn hoặc ‘bế tắc’
nào, một khi đã được chọn, sẽ không cho phép người gọi quay
lại các menu trước đó,
 Phần mềm Giao diện Điện thoại Máy tính (Computer Telephony
Interface - CTI) cho phép nhận dạng người gọi (thông qua ACD
được liên kết) và tự động tập hợp các chi tiết của người dùng
vào hồ sơ sự cố từ CMS,
 VoIP – việc sử dụng công nghệ này có thể làm giảm đáng kể
chi phí điện thoại khi giao dịch với người dùng từ xa và người
dùng quốc tế,
 Phần mềm thống kê cho phép thu thập số liệu thống kê về điện
thoại và dễ dàng thẩm tra/in ra để phân tích - điều này sẽ cho
phép thu được những thông tin sau đây cho bất kỳ khoảng thời
gian đã chọn nào:
o Số cuộc gọi đã nhận, tổng số và được chia nhỏ theo bất
kỳ ‘phần tách’ nào - trong đó bất kỳ định tuyến cuộc gọi
nào đã được chọn và được cung cấp bởi hệ thống IVR/bàn
phím phản hồi,
o Hồ sơ cuộc gọi đến và thời gian trả lời,
o Tỷ lệ bỏ cuộc gọi,
o Tỷ lệ xử lý cuộc gọi theo từng người xử lý cuộc gọi của
Bộ phận Hỗ trợ Dịch vụ,
o Thời lượng cuộc gọi trung bình,
o Tai nghe rảnh tay, với khả năng truy cập người dùng kép
(trên ít nhất một số tai nghe) để sử dụng trong quá trình
đào tạo nhân viên mới, v.v…
7.7.2 Các công c ụ hỗ trợ

Có một loạt các công cụ hỗ trợ Bộ phận Hỗ trợ Dịch vụ sẵn có trên
thị trường - và một số tổ chức có thể chọn sản xuất các hệ thống
quản lý/ghi nhật ký sự cố đơn giản của riêng họ. Nếu một tổ chức có
ý định triển khai ITSM một cách nghiêm túc thì bộ công cụ ITSM tích
hợp đầy đủ sẽ là bắt buộc để có một CMS ở trung tâm và cung cấp
sự hỗ trợ được tích hợp cho tất cả các quy trình do ITIL xác định.
Các phần tử cụ thể của những công cụ như vậy sẽ đặc biệt có lợi đối
với Bộ phận Hỗ trợ Dịch vụ, bao gồm những điều sau.
7.7.2. 1 Cơ s ở dữ l iệ u L ỗi đ ã bi ết
Một KEDB (Cơ sở dữ liệu Lỗi Đã biết) được tích hợp nên được sử
dụng để lưu trữ thông tin chi tiết về các sự cố/vấn đề trước đây
cùng với giải pháp của chúng - để từ đó, mọi sự cố tái diễn có thể
được chẩn đoán và khắc phục một cách nhanh chóng hơn.
Để tạo điều kiện thuận lợi cho việc này, cần có chức năng phân loại
và truy xuất một cách nhanh chóng các Lỗi Đã biết trước đó, sử
dụng việc đối sánh mẫu và tìm kiếm từ khóa để so với các triệu
chứng. Quản lý KEDB là trách nhiệm của Quản lý sự cố, nhưng Bộ
phận Hỗ trợ Dịch vụ cũng sẽ sử dụng để giúp tăng tốc xử lý sự cố.
7.7.2. 2 Các t ập lện h ch ẩ n đoán

Các kịch bản chẩn đoán đa cấp nên được phát triển, lưu trữ và quản
lý để cho phép nhân viên Bộ phận Hỗ trợ Dịch vụ xác định chính xác
nguyên nhân của các lỗi. Các nhóm hỗ trợ chuyên gia và nhà cung
cấp nên được yêu cầu cung cấp thông tin chi tiết về các lỗi có thể
xảy ra và các câu hỏi then chốt cần được hỏi để xác định chính xác
những gì đã sai - và để biết chi tiết về các hành động giải quyết sẽ
được thực hiện.
Sau đó, những chi tiết này nên được đưa vào các tập lệnh kịch bạn
phù hợp với ngữ cảnh sẽ xuất hiện trên màn hình, phụ thuộc vào sự
phân loại nhiều cấp của sự cố và phải được định hướng bởi câu trả
lời của người dùng cho các câu hỏi chẩn đoán.
7.7.2. 3 Giao d i ện we b Tự- Hỗ trợ

Việc cung cấp một số hình thức chức năng 'Tự-Hỗ trợ’ được tự động
hóa thường có hiệu quả về chi phí và hiệu suất, vì vậy người dùng
có thể tìm kiếm và nhận được sự hỗ trợ để cho phép họ tự giải
quyết những khó khăn của mình. Lý tưởng nhất là điều này phải
thông qua một giao diện web 24/7 được định hướng bởi lựa chọn
menu và có thể bao gồm, nếu thích hợp:
 Các câu hỏi thường gặp (FAQ) và các giải pháp,

 Khả năng tìm kiếm ‘Cách thực hiện như thế nào’ – để hướng
dẫn người dùng thông qua danh sách các nhi ệm vụ hoặc hoạt
động tùy theo ngữ cảnh,
 Một dịch vụ dạng-bản tin chứa thông tin chi tiết về các vấn
đề/sự cố dịch vụ còn tồn tại cùng với thời gian khôi phục dự
kiến,
 Khả năng thay đổi mật khẩu - sử dụng phần mềm bảo vệ mật
khẩu an toàn để kiểm tra danh tính, thực hiện việc ủy quyền
cấp phép và thay đổi mật khẩu mà không cần sự can thiệp của
Bộ phận Hỗ trợ Dịch vụ,
 Tải xuống bản sửa lỗi phần mềm (bản vá, gói dịch vụ, bản sửa
lỗi, v.v… trong đó xác định rằng người dùng có phiên bản sai
hoặc một bản sửa lỗi là cần thiết) - các công cụ sẵn có để tự
động hóa quá trình kiểm tra, để so sánh hình ảnh máy tính
thực tế với bản xây dựng 'tiêu chuẩn' đã được thống nhất và
cho phép các bản nâng cấp được cung cấp và chấp nhận khi
cần thiết,
 Sửa chữa phần mềm - nơi phát hiện ra rằng có thể đã xảy ra
lỗi, để cho phép sửa chữa, gỡ bỏ và/hoặc cài đặt lại phần
mềm,
 Yêu cầu gỡ bỏ phần mềm – được hoàn thành một cách tự động
với bất kỳ giấy phép nào được trả lại cho nhóm [giấy phép sử
dụng],
 Tải xuống các gói phần mềm bổ sung - các công cụ có sẵn để
kiểm tra một chính sách phần mềm đã được xác định trước và
cho phép tải xuống các gói phần mềm bổ sung, nếu được đề
cập trong chính sách. Việc này có thể bao gồm kiểm tra giấy
phép phần mềm được tự động hóa và phê duyệt tài chính cũng
như cập nhật CMS,
 Thông báo trước về bất kỳ thời gian ngừng hoạt động hoặc dịch
vụ ngừng hoạt động hoặc suy thoái theo kế hoạch nào.
Giải pháp tự trợ giúp nên bao gồm khả năng để người dùng tự ghi
nhật ký sự cố, có thể được sử dụng trong thời gian Bộ phận Hỗ trợ
Dịch vụ đóng cửa (nếu không hoạt động 24/7) và có sự tham gia của
nhân viên Bộ phận Hỗ trợ Dịch vụ khi bắt đầu ca làm việc tiếp theo .
Một số biện pháp thận trọng cần phải được thực hiện để đảm bảo
rằng các hoạt động Tự-Hỗ trợ được chọn để đưa vào không quá mức
nâng cao đối với người dùng bình thường và các biện pháp bảo vệ
được bao gồm để ngăn chặn việc 'một chút kiến thức nhỏ lại trở
thành một điều nguy hiểm'! Cũng có thể cung cấp các phương tiện
Tự-Hỗ trợ được nâng cao hơn một chút cho ‘Người dùng Siêu cấp’,
những người đã được đào tạo thêm. Cũng cần phải hết sức cẩn thận
về các giả định được đưa ra khi sắp xếp nhân sự Bộ phận Hỗ trợ
Dịch vụ về mức độ sử dụng mà người dùng sẽ sử dụng các phương
tiện Tự-Hỗ trợ.
Lưu ý: Như đã được đề cập trong danh sách ở trên, có thể kết hợp
một số hoạt động Thực hiện Yêu cầu đơn giản hơn như một phần của
hệ thống Tự-Hỗ trợ tổng thể - điều này cũng có thể mang lại lợi ích
đáng kể trong việc giảm bớt các cuộc gọi đến Bộ phận Dịch vụ (xem
đoạn 7.1.1 để biết thêm chi tiết).
7.7.2. 4 Kiểm soát t ừ xa

Như đã được nêu ra, nhưng được lặp lại ở đây để hoàn chỉnh,
thường sẽ rất hữu ích để Bộ phận Hỗ trợ Dịch vụ có khả năng kiểm
soát máy tính để bàn của người dùng, từ đó cho phép họ (nhân viên
Bộ phận Hỗ trợ Dịch vụ) tiến hành các cuộc điều tra hoặc sửa chữa
cấu hình, v.v… Cơ sở vật chất cho phép mức độ kiếm soát từ xa này
cũng sẽ được cần đến.
7.7.3 Hoạ ch đ ịnh Li ên t ục D ịch v ụ đối v ớ i các

công c ụ hỗ tr ợ ITSM
Các tổ chức có khả năng nhanh chóng trở nên phụ thuộc vào các
công cụ ITSM của họ và nhận thấy rằng sẽ khó làm việc nếu không
có chúng. Một Phân tích Tác động Kinh doanh và Phân tích Rủi ro
nên được tiến hành và các kế hoạch sau đó được phát triển để đảm
bảo Tính liên tục dịch vụ và khả năng phục hồi thích hợp.
8 N h ững cân nh ắ c v ề triển khai
Nên lưu ý rằng Vận hành Dịch vụ là một giai đoạn trong vòng đời và
không phải là một thực thể theo đúng nghĩa của nó. Vào thời điểm
một dịch vụ, quy trình, cấu trúc tổ chức hoặc công nghệ đang vận
hành, nó thực sự đã được triển khai. Tuy nhiên, có một số quy trình
và chức năng được mô tả trong ấn phẩm này, và do đó, điều quan
trọng là phải xác định các cân nhắc về triển khai mà lẽ ra phải được
giải quyết vào thời điểm chúng đi vào hoạt động.
Một số trong số này đã được đề cập trong phần liên quan - ví dụ,
hướng dẫn về cơ cấu tổ chức và vai trò trong Chương 6. Đi ều này sẽ
không được lặp lại ở đây. Thay vào đó, phần này sẽ tập trung vào
một số hướng dẫn triển khai phổ quát cho Vận hành Dịch vụ nói
chung.
8.1 Quản lý sự thay đổi trong Vận hành Dịch vụ

Vận hành Dịch vụ nên cố gắng đạt được tính ổn định – nhưng không
bị đình trệ! Có rất nhiều lý do hợp lệ và hữu ích về việc nguyên
nhân tại sao ‘thay đổi lại là một điều hữu ích’ – nhưng nhân viên
Vận hành Dịch vụ phải đảm bảo rằng bất kỳ thay đổi nào đều được
hấp thụ mà không gây tác động bất lợi đến sự ổn định của các dịch
vụ CNTT đang được cung cấp.
8.1.1 Các đi ều ki ệ n kích ho ạ t s ự thay đ ổi

Có rất nhiều điều có thể kích hoạt một thay đổi trong môi trường
Vận hành Dịch vụ. Chúng bao gồm:
 Các thành phần phần cứng hoặc mạng mới hoặc được nâng cấp,
 Phần mềm ứng dụng mới hoặc được nâng cấp,
 Phần mềm hệ thống mới hoặc được nâng cấp (hệ điều hành,
tiện ích, phần mềm trung gian, v.v… bao gồm các bản vá và
sửa lỗi),
 Những thay đổi pháp lý, tuân thủ và quản trị,
 Lỗi thời - một số thành phần có thể trở nên lỗi thời và đòi hỏi
sự thay thế hoặc ngừng hỗ trợ bởi nhà cung cấp/nhà bảo trì,
 Yêu cầu bắt buộc kinh doanh - bạn phải linh hoạt để làm việc
với ITSM, đặc biệt là trong quá trình Vận hành Dịch vụ, và sẽ
có nhiều trường hợp doanh nghiệp cần thay đổi CNTT để đáp
ứng các yêu cầu kinh doanh năng động,
 Những cải tiến đối với các quy trình, thủ tục và/hoặc các công
cụ nền tảng để cải thiện việc cung cấp CNTT hoặc giảm chi phí
tài chính,
 Những thay đổi về mặt quản lý hoặc nhân sự (từ mất mát hoặc
chuyển giao quyền của các cá nhân cho đến các thương vụ tiếp
quản hoặc mua lại lớn),
 Thay đổi trong mức dịch vụ hoặc trong việc cung cấp dịch vụ -
thuê ngoài, tìm nguồn cung ứng, quan hệ đối tác, v.v…
8.1.2 Đánh giá th ay đ ổi

Nhân viên Vận hành Dịch vụ phải được tham gia vào quá trình đánh
giá mọi thay đổi để đảm bảo rằng các vấn đề về mặt vận hành được
tính đến đầy đủ. Sự tham gia này nên khởi đầu càng sớm càng tốt
(xem đoạn 4.6.1) chứ không chỉ ở những giai đoạn sau của thay đổi
– nghĩa là tư cách thành viên của CAB và ECAB – vào thời điểm đó,
nhiều quyết định cơ bản sẽ phải được đưa ra và ảnh hưởng có khả
năng sẽ rất hạn chế. Nhà quản lý Thay đổi nên thông báo cho tất cả
các bên bị ảnh hưởng về sự thay đổi đang được đánh giá để đầu vào
có thể được chuẩn bị và sẵn sàng trước khi các cuộc họp CAB diễn
ra.
Tuy nhiên, điều quan trọng là nhân viên Vận hành Dịch vụ được
tham gia vào các giai đoạn sau vì họ có thể tham gia vào việc triển
khai thực tế và họ sẽ muốn đảm bảo rằng việc lập lịch trình cẩn
thận diễn ra để tránh những bất đồng tiềm ẩn hoặc những giai đoạn
đặc biệt nhạy cảm.
8.1.3 Đo l ư ờ ng s ự thành công c ủa thay đ ổi

Thước đo tối hậu của sự thành công liên quan đến những thay đổi
đã được thực hiện với Vận hành Dịch vụ là rằng khách hàng và người
dùng không trải qua bất kỳ sự biến đổi hoặc gián đoạn dịch vụ nào.
Cho đến nay, tác động của những thay đổi nên vô hình, ngoại trừ
bất kỳ chức năng, chất lượng hoặc tiết kiệm tài chín đã được tăng
cường nào do thay đổi mang lại.
8.2 Vận hành Dịch vụ và Quản lý Dự án

Vì Vận hành Dịch vụ thường được xem là ‘hoạt động kinh doanh như
bình thường’ và thường tập trung vào việc thực hiện các thủ tục đã
được xác định theo một cách thức tiêu chuẩn nên có một xu hướng
không sử dụng các quy trình Quản lý Dự án khi chúng thực sự phù
hợp. Ví dụ, nâng cấp cơ sở hạ tầng quan trọng hoặc triển khai các
thủ tục mới hoặc đã được thay đổi là những nhiệm vụ quan trọng mà
Quản lý Dự án chính thức có thể được sử dụng để cải thiện việc
kiểm soát và quản lý chi phí/nguồn lực.
Việc sử dụng Quản lý dự án để quản lý các loại hoạt động này sẽ có

những lợi ích sau đây:
 Các lợi ích của dự án được công bố và thống nhất một cách rõ
ràng,
 Có nhiều khả năng minh bạch hơn về những gì đang được thực
hiện và cách nó đang được quản lý như thế nào, điều này giúp
các nhóm CNTT khác cũng như doanh nghiệp dễ dàng định
lượng được đóng góp của các nhóm vận hành,
 Điều này đến lượt nó giúp cho việc tìm kiếm nguồn vốn tài trợ
cho các dự án trở nên dễ dàng hơn, mà theo truyền thống là
khó khăn trong việc điều chỉnh chi phí,
 Tính nhất quán cao hơn và chất lượng được cải thiện,
 Việc đạt được các mục tiêu dẫn đến sự tín nhiệm cao hơn cho
các nhóm vận hành.
8.3 Đánh giá và quản lý rủi ro trong Vận hành Dịch vụ

Sẽ có một số trường hợp bắt buộc rằng việc đánh giá rủi ro đối với
Vận hành Dịch vụ phải được thực hiện và tiến hành một cách nhanh
chóng.
Lĩnh vực được quan sát rõ ràng nhất là đánh giá rủi ro của những
thay đổi tiềm ẩn hoặc Lỗi Đã biết (đã được đề cập ở đâu đó khác)
nhưng ngoài ra, nhân viên Vận hành dịch vụ có thể cần phải tham
gia vào việc đánh giá rủi ro và tác động của:
 Các lỗi, hoặc các lỗi tiềm ẩn - do Quản lý Sự kiện hoặc Quản lý
Sự cố/Quản lý Vấn đề báo cáo, hoặc các cảnh báo do nhà sản
xuất, nhà cung cấp hoặc nhà thầu đưa ra,
 Các dự án mới mà cuối cùng sẽ dẫn đến việc đưa vào môi
trường thực tế,
 Những rủi ro môi trường (bao gồm rủi ro kiểu Tính liên tục dịch
vụ CNTT đối với môi trường vật lý và địa phương cũng như các
rủi ro liên quan đến chính trị, thương mại hoặc quan hệ có liên
quan đến ngành),
 Các nhà cung cấp, đặc biệt khi các nhà cung cấp mới có liên
quan hoặc các thành phần dịch vụ then chốt nằm dưới sự kiểm
soát của các bên thứ ba,
 Rủi ro bảo mật - cả về lý thuyết hoặc thực tế phát sinh từ các
sự cố hoặc sự kiện liên quan đến bảo mật,
 Khách hàng/dịch vụ mới được hỗ trợ.
8.4 Nhân viên vận hành trong quá trình Thi ết kế Dịch
vụ và Chuyển tiếp Dịch vụ
Tất cả các nhóm CNTT sẽ tham gia vào quá trình Thiết kế Dịch vụ và
Chuyển tiếp Dịch vụ để đảm bảo rằng các thành phần hoặc dịch vụ
mới được thiết kế, kiểm nghiệm và triển khai để cung cấp các mức
chính xác về chức năng, khả năng sử dụng, tính khả dụng, công
suất, v.v…
Ngoài ra, nhân viên Vận hành Dịch vụ phải được tham gia vào giai
đoạn đầu của Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ để đảm bảo
rằng khi các dịch vụ mới tiếp cận với môi trường thực tế, chúng sẽ
phù hợp với mục đích, xét từ quan điểm Vận hành Dịch vụ và ‘có thể
hỗ trợ’ trong tương lai.
Trong ngữ cảnh này, 'có thể hỗ trợ' có nghĩa là:
 Có khả năng được hỗ trợ từ quan điểm kỹ thuật và vận hành từ

bên trong phạm vi các nguồn lực và trình độ kỹ năng bổ sung
hiện có hoặc được thỏa thuận trước,
 Không có tác động tiêu cực đến các phương thức làm việc, quy
trình hoặc lịch trình kỹ thuật hoặc vận hành khác hiện có,
 Không có bất kỳ chi phí vận hành không mong muốn nào hoặc
chi phí hỗ trợ liên tục hoặc leo thang,
 Không có bất kỳ rắc rối hợp đồng hoặc pháp lý không mong
muốn nào,
 Không có đường dẫn hỗ trợ phức tạp giữa nhiều bộ phận hỗ trợ
của các tổ chức bên thứ ba.
Lưu ý: Thay đổi không chỉ là về công nghệ. Nó cũng đòi hỏi việc đào
tạo, nâng cao nhận thức, thay đổi văn hóa, các vấn đề tạo động lực
và hơn thế nữa. Các chi tiết khác liên quan đến việc quản lý thay
đổi rộng rãi hơn được đề cập trong ấn phẩm Chuyển đổi Dịch vụ.
8.5 Hoạch định và Triển khai những công nghệ Quản lý

Dịch vụ
Có một số các yếu tố mà tổ chức cần phải lập kế hoạch để sẵn sàng
và trong quá trình triển khai và thực hiện, các công cụ hỗ trợ ITSM.
Chúng bao gồm những điều dưới đây.
8.5.1 Giấ y p hép s ử dụng

Chi phí tổng thể cho các công cụ ITSM, đặc biệt là công cụ được tích
hợp mà sẽ hình thành nên trung tâm của bộ công cụ cần thiết,
thường được xác định bằng con số và loại giấy phép người dùng mà
tổ chức cần.
Những công cụ như vậy thường được bán dưới dạng mô-đun, do đó,
tính năng chính xác của từng mô-đun cần phải được hiểu rõ và một
số định cỡ ban đầu phải được tiến hành để xác định bao nhiêu – và
loại nào – người dùng sẽ cần truy cập vào từng mô-đun.
Giấy phép sử dụng thường có sẵn dưới những dạng sau (thuật ngữ
chính xác có thể sẽ khác tùy thuộc vào nhà cung cấp phần mềm).
8.5.1. 1 Giấ y p hép ch uyên b i ệt

Được sử dụng bởi những nhân viên yêu cầu sử dụng thường xuyên
và lâu dài (ví dụ, nhân viên Bộ phận Hỗ trợ Dịch vụ sẽ cần một giấy
phép chuyên dụng để sử dụng một mô-đun Quản lý Sự cố).
8.5.1. 2 Giấ y p hép đ ư ợ c chia s ẻ

Dành cho những nhân viên sử dụng mô-đun khá thường xuyên nhưng
có khoảng thời gian thời gian đáng kể giữa các khoảng sử dụng, do
đó, thường có thể quản lý bằng giấy phép được chia sẻ (ví dụ: nhân
viên hỗ trợ tuyến ba có thể cần truy cập thường xuyên vào mô-đun
Quản lý Sự cố - nhưng chỉ vào những lúc họ cập nhật hồ sơ sự cố
một cách tích cực). Tỷ lệ giấy phép bắt buộc cho người dùng cần
phải được ước tính, do đó, số lượng giấy phép chính xác có thể được
mua - điều này sẽ phụ thuộc vào số lượng người dùng tiềm năng,
thời gian sử dụng và tần suất dự kiến giữa các lần sử dụng để đưa
ra mức ước tính đồng thời.
Chi phí của một giấy phép chia sẻ thường đắt hơn so với các giấy
phép chuyên dụng - nhưng tổng chi phí thấp hơn khi người dùng
đang chia sẻ [giấy phép] và do đó, sẽ cần ít giấy phép hơn.
8.5.1. 3 Giấ y p hép t ừ trang web

Thường cho phép một số hình thức 'giao diện hạng nhẹ' thông qua
truy cập web vào các khả năng của công cụ, điều này thường phù
hợp với nhân viên yêu cầu truy cập từ xa, chỉ truy cập không thường
xuyên hoặc chỉ sử dụng một tập hợp con nhỏ của chức năng (ví dụ:
nhân viên kỹ thuật muốn ghi lại nhật ký chi tiết của hành động được
thực hiện đối với sự cố hoặc người dùng chỉ muốn ghi lại nhật ký sự
cố một cách trực tiếp). Giấy phép web thường có chi phí thấp hơn
nhiều so với các giấy phép khác (thậm chí có thể miễn phí so với các
giấy phép khác!) Và tỷ lệ sử dụng cũng thường thấp hơn - do đó chi
phí tổng thể còn được giảm hơn nữa.
Hãy lưu ý rằng một số nhân viên có thể yêu cầu quyền truy cập vào
nhiều loại giấy phép (ví dụ: nhân viên hỗ trợ có thể yêu cầu giấy
phép chuyên dụng hoặc chia sẻ khi ở văn phòng vào ban ngày,
nhưng có thể yêu cầu giấy phép web khi cung cấp hỗ trợ ngoài giờ
tại nhà). Hãy nhớ rằng có thể cần phải có giấy phép đối với khách
hàng/người dùng/nhà cung cấp sử dụng cùng một công cụ để nhập,
xem hoặc cập nhật các hồ sơ hoặc báo cáo.
Lưu ý: Một số thỏa thuận cấp phép (thuộc bất kỳ loại nào được đề
cập ở trên) có thể hạn chế việc sử dụng phần mềm cho một thiết bị
hoặc CPU riêng lẻ!
8.5.1. 4 Dịch v ụ theo nhu c ầ u

Đã có một khuynh hướng trong phạm vi ngành CNTT là các nhà cung
cấp cung cấp các ứng dụng CNTT 'theo nhu cầu', trong đó quyền
truy cập được cấp cho ứng dụng trong một khoảng thời gian theo
yêu cầu và sau đó bị cắt khi không còn cần thiết nữa - và được tính
phí trên cơ sở thời gian đã sử dụng ứng dụng. Kiểu đề xuất này có
thể được cung cấp bởi một số nhà cung cấp công cụ ITSM - điều này
vốn có thể hấp dẫn đối với các tổ chức nhỏ hơn hoặc nếu các công
cụ được đề cập rất chuyên biệt và được sử dụng một cách tương đối
thường xuyên.
Một giải pháp thay thế cho vấn đề này là khi việc sử dụng một công
cụ được đề xuất như một phần của nhiệm vụ tư vấn cụ thể (ví dụ:
chuyên gia tư vấn Quản lý Công suất, người có thể đưa ra gói tư vấn
Hoạch định Công suất định kỳ nhưng tương đối không thường xuyên
và cung cấp việc sử dụng các công cụ cho thời hạn của nhiệm vụ).
Trong những trường hợp này, phí cho giấy phép có thể được bao
gồm như một phần của, hoặc, một phụ lục của phí tư vấn.
Một biến thể khác là phần mềm được cấp phép và tính phí trên cơ sở
tác nhân/hoạt động. Một ví dụ về điều này là phần mềm thẩm
tra/giám sát và/hoặc mô phỏng (ví dụ: phần mềm tác nhân có thể
mô phỏng đường dẫn khách hàng đã được xác định trước thông qua
trang web của tổ chức, để đánh giá và báo cáo dựa trên hiệu suất
và tính sẵn sàng). Phần mềm như vậy thường được tính phí dựa trên
số lượng tác nhân, vị trí của chúng và/hoặc tổng số lượng hoạt động
được tạo ra.
Trong mọi trường hợp, các cuộc điều tra đầy đủ về cấu trúc cấp
phép phải được điều tra và hiểu rõ trong quá trình điều tra về quá
trình mua sắm và trước khi các công cụ được triển khai - để chi phí
cuối cùng không đến mức quá bất ngờ.
8.5.2 Triển khai

Rất nhiều công cụ ITSM, đặc biệt là các công cụ Khám phá và Giám
sát Sự kiện, sẽ đòi hỏi một việc triển khai một số phần mềm tác
nhân/phần mềm máy khách đến tất cả các vị trí được nhắm mục tiêu
trước khi chúng có thể được sử dụng. Điều này sẽ đòi hỏi việc hoạch
định và thực thi cẩn trọng – và nên được xử lý thông qua Quản lý
Triển khai và Phát hành chính thức (xem ấn phẩm Chuyển tiếp Dịch
vụ).
Ngay cả khi việc triển khai mạng là khả thi thì việc này vẫn cần
được lập lịch trình và kiểm tra cẩn thận - và hồ sơ phải được duy trì
trong suốt quá trình triển khai để nhân viên hỗ trợ có kiến thức về
việc ai đã được và chưa được nâng cấp. Một số hình thức Quản lý
Thay đổi tạm thời có thể cần thiết và CMS phải được cập nhật khi
quá trình triển khai tiến triển.
Việc khởi động lại thiết bị thường là cần thiết để phần mềm máy
khách được nhận dạng - và việc này cần phải được thu xếp trước,
nếu không, có thể sẽ xảy ra sự chậm trễ kéo dài nếu nhân viên
thường không tắt máy tính để bàn của họ qua đêm.
Có thể có một số vấn đề cụ thể khi triển khai cho máy tính xách tay
và các thiết bị di động khác và có thể cần sắp xếp đặc biệt để nhân
viên đăng nhập và nhận phần mềm mới.
8.5.3 Kiểm tra công su ấ t

Một số Quản lý Công suất có thể được cần trước để đảm bảo rằng
mọi vị trí được nhắm mục tiêu có đủ công suất lưu trữ và xử lý để
lưu trữ và chạy phần mềm mới - bất kỳ điều gì không thể sẽ cần
được nâng cấp hoặc thay thế và thời gian thực hiện các hành động
này cần được đưa vào kế hoạch.
Dung lượng của mạng cũng cần phải được kiểm tra để xác định xem
liệu nó có thể xử lý việc truyền dẫn thông tin quản lý, truyền tải tập
tin nhật ký và phân phối của máy khách, cũng như có thể cả phần
mềm và tập tin cấu hình hay không.
8.5.4 Thờ i đ i ểm t ri ển khai công ngh ệ
Sự thận trọng là cần thiết để đảm bảo rằng các công cụ được triển
khai vào thời điểm thích hợp liên quan đến mức độ tinh vi và kiến
thức ITSM của tổ chức. Nếu các công cụ được triển khai quá sớm,
chúng có thể được coi là liều thuốc chữa bách bệnh tức thì và bất kỳ
hành động cần thiết nào để thay đổi quy trình, phương thức làm việc
hoặc thái độ có thể bị cản trở hoặc bỏ qua.
Chỉ có một công cụ thường không đủ để làm cho mọi thứ hoạt động
tốt hơn. Có một câu ngạn ngữ cổ rằng: ‘Một kẻ ngốc có công cụ vẫn
là kẻ ngốc!’
Trước tiên, tổ chức phải kiểm tra các quy trình mà công cụ đang tìm
cách giải quyết và cũng đảm bảo rằng nhân viên đã ‘tín nhiệm’ các
quy trình và cách thức làm việc mới và có một ‘văn hóa dịch vụ’
được áp dụng.
Tuy nhiên, các công cụ có thể và thường xuyên biến mọi thứ trở
thành hiện thực đối với rất nhiều người - chúng là những thứ hữu
hình và nhân viên kỹ thuật có thể ngay lập tức thấy cách thức mà
các quy trình mới có thể hoạt động và cách họ có thể cải thiện cách
làm việc của mình như thế nào.
Một số quy trình không thể thực hiện được nếu không được cấp đủ
công cụ, vì vậy cần có sự cân bằng cẩn trọng để đảm bảo các công
cụ được đưa vào sử dụng khi cần - nhưng không phải trước đó!
Tương tự, sự cẩn trọng là cần thiết để đảm bảo rằng việc đào tạo về
bất kỳ công cụ nào sẽ được cung cấp đúng thời điểm - không quá
sớm hoặc kiến thức sẽ sụt giảm hoặc mất đi, nhưng đủ sớm để nhân
viên có thể được đào tạo chính thức và hoàn toàn làm quen với việc
vận hành các công cụ trước khi triển khai trực tiếp. Việc đào tạo bổ
sung nên được lên kế hoạch cho một khoảng thời gian bổ sung khi
các công cụ đi vào hoạt động và trong tương lai, nếu cần thiết.
8.5.5 Kiểu g i ớ i thi ệu

Một quyết định là cần thiết về kiểu giới thiệu nào được cần đến - có
nên sử dụng phần giới thiệu ‘Big Bang’ hay phương pháp tiếp cận
theo giai đoạn nào đó. Vì hầu hết các tổ chức sẽ không bắt đầu từ
tình huống ‘cánh đồng xanh’ (ngụ ý chỉ một tình huống nơi mọi thứ
chưa bắt đầu) và sẽ có các dịch vụ thực tế để tiếp tục hoạt động
trong quá trình giới thiệu, nên một phương pháp tiếp cận theo từng
giai đoạn có nhiều khả năng sẽ là cần thiết.
Trong nhiều trường hợp, một công cụ mới sẽ thay thế cho một công
cụ cũ hơn, có lẽ ít phức tạp hơn và việc chuyển đổi giữa hai công cụ
này là một yếu tố khác cần phải được lên kế hoạch.
Điều này thường liên quan đến việc quyết định dữ liệu nào cần được
chuyển tiếp từ công cụ cũ sang công cụ mới - và điều này có thể đòi
hỏi việc định dạng lại đáng kể để đạt được kết quả cần thiết. Lý
tưởng nhất là việc chuyển giao này nên được thực hiện dưới dạng
điện tử - nhưng trong một số trường hợp, có thể không tránh khỏi
một lượng nhỏ dữ liệu trực tiếp phải nhập lại và cần được đưa vào
kế hoạch.
Cảnh báo: nói chung, các công cụ cũ hơn thường dựa vào việc nhập
và bảo trì dữ liệu theo cách thủ công hơn, vì vậy nếu việc chuyển
đổi dữ liệu điện tử đang được sử dụng, một đánh giá cần được thự
hiện để xác minh chất lượng của dữ liệu.
Trong trường hợp quá trình truyền dữ liệu quá phức tạp hoặc tốn
nhiều thời gian để đạt được, một giải pháp thay thế có thể là cho
phép một khoảng thời gian chạy song song - với công cụ cũ có sẵn
trong khoảng thời gian ban đầu cùng với công cụ mới, để dữ liệu
lịch sử có thể được tham chiếu nếu cần. Trong những trường hợp
như vậy, sẽ là khôn ngoan khi khiến cho công cụ cũ ở chế độ ‘chỉ
đọc’ để không thể mắc lỗi bằng cách ghi dữ liệu mới vào công cụ cũ.
Có thể tìm thấy thông tin chi tiết đầy đủ về quy trình Quản lý Triển
khai và Quản lý Phát hành trong ấn phẩm Chuyển tiếp Dịch vụ.
9 N h ững thách th ức, Các y ếu t ố T hành công Q uan

trọng và r ủi ro
9.1 Những thách thức

Có một số thách thức phải đối mặt trong phạm vi Vận hành Dịch vụ
cần phải được vượt qua. Những thách thức này bao gồm những điều
được nêu ra trong phần này.
9.1.1 Thiếu g ắ n k ết v ớ i nhân viên d ự án và phát

triển
Theo truyền thống, sẽ có một sự tách biệt giữa nhân viên Vận hành
Dịch vụ và những nhân viên tham gia phát tri ển các ứng dụng mới
hoặc chạy các dự án mà cuối cùng sẽ bổ sung thêm chức năng mới
vào môi trường thực tế.
Sự tách biệt này ban đầu là có chủ ý và được thúc đẩy bởi mong
muốn ngăn chặn sự thông đồng và tránh các rủi ro bảo mật tiềm ẩn
(trong một số tổ chức, nó vẫn là một yêu cầu lập pháp). Tuy nhiên,
thay vì sử dụng sự phân tách nhiệm vụ này để tạo ra những đóng
góp tích cực, trong nhiều tổ chức, nó lại là nguồn gốc của sự cạnh
tranh và thao túng về mặt chính trị.
Rất thường xuyên, ITSM được xem như một thứ gì đó đã được khởi
xướng trong các lĩnh vực vận hành và không liên quan gì đến phát
triển hoặc các dự án.
Quan điểm này rất nguy hiểm vì thời điểm thích hợp để suy nghĩ về
các vấn đề Vận hành Dịch vụ là khi bắt đầu phát triển mới hoặc dự
án mới - khi vẫn còn đủ thời gian để đưa những yếu tố này vào giai
đoạn lập kế hoạch.
Các ấn phẩm về Thiết kế Dịch vụ và Chuyển tiếp Dịch vụ mô tả các

bước cần thiết để đảm bảo rằng các vấn đề Vận hành CNTT được
xem xét ngay từ đầu của các dự án mới và phát triển mới.
Giai thoại
Một tổ chức sử dụng ‘Chính sách Chuyển tiếp Vận hành’ để đảm bảo rằng các dịch
vụ đang được triển khai có mức đầu vào thích hợp từ các nhóm vận hành. Về cơ
bản, đây là một chính sách cho thấy rõ ràng ứng dụng đã ‘sẵn sàng’ chuyển sang
Vận hành trong những trường hợp nào. Điều này giúp liên lạc với các nhóm phát
triển và dự án, đồng thời cung cấp một bộ hướng dẫn rõ ràng về cách làm việc với
các nhóm vận hành.
Một tổ chức khác sử dụng Trường hợp Sử dụng Vận hành để yêu cầu các nhóm
phát triển bao gồm các yêu cầu phải được đáp ứng bởi ứng dụng để chạy trong
môi trường sản xuất dưới sự kiểm soát của nhân viên Vận hành.
9.1.2 C hứng minh đ ể g ọi v ốn tài tr ợ
Thường rất khó để biện minh cho việc chi tiêu trong lĩnh vực Vận
hành Dịch vụ, vì tiền đã chi tiêu trong lĩnh vực này thường được coi
là ‘chi phí cơ sở hạ tầng’ - không có gì mới để minh chứng cho
khoản đầu tư.
Ấn phẩm Chiến lược Dịch vụ thảo luận về cách đảm bảo Lợi nhuận
trên Khoản đầu tư và loại bỏ nhận thức về đầu tư như một ‘chi phí’
thuần túy về Cơ sở hạ tầng. Hướng dẫn tốt được cung cấp về cách
hợp lý hóa đầu tư như thế nào.
Trên thực tế, nhiều khoản đầu tư vào ITSM, đặc biệt trong các lĩnh
vực Vận hành Dịch vụ, có thể tiết kiệm tiền và cho thấy một Lợi
nhuận trên Khoản đầu tư tích cực - cũng như dẫn đến cải thiện
trong chất lượng dịch vụ. Một số ví dụ về các lĩnh vực tiết kiệm tiềm
năng bao gồm:
 Chi phí cấp phép phần mềm được tiết giảm thông qua việc quản
lý tốt hơn các giấy phép và các bản sao được triển khai,
 Chi phí hỗ trợ được giảm thiểu do ít sự cố và vấn đề hơn và
thời gian giải quyết cũng được giảm thiểu,
 Số lượng nhân viên được cắt giảm thông qua việc hợp lý hóa
lực lượng lao động, vai trò hỗ trợ và cơ cấu trách nhiệm giải
trình,
 Ít bị ‘tổn thất kinh doanh’ do chất lượng dịch vụ CNTT kém,
 Sử dụng tốt hơn các thiết bị cơ sở hạ tầng hiện có và trì hoãn
chi tiêu thêm do Quản lý Công suất tốt hơn,
 Các quy trình được liên kết tốt hơn, dẫn đến các hoạt động ít
bị trùng lặp hơn và sử dụng tốt hơn các nguồn lực hiện có.
9.1.3 N hững thách th ức đ ố i v ớ i các Nhà qu ả n lý
V ậ n hành D ịc h v ụ
Dưới đây là một danh sách về một số các thách thức mà các Nhà
quản lý trong lĩnh vực Vận hành Dịch vụ sẽ phải đối mặt. Không có
giải pháp dễ dàng cho những thách thức này, chủ yếu bởi vì chúng
là sản phẩm của văn hóa tổ chức và những quyết định được đưa ra
trong quá trình quyết định về cơ cấu tổ chức. Mục đích của việc bao
gồm danh sách này là để đảm bảo rằng các Nhà quản lý Vận hành
Dịch vụ có ý thức về chúng [những thách thức] và có thể tạo ra một
kế hoạch xử lý chúng.
Sự khác biệt giữa các hoạt động Thiết kế và các hoạt động Vận hành
sẽ tiếp tục thể hiện cho những thách thức. Điều này là do một số
nguyên nhân, bao gồm:
 Thiết kế Dịch vụ có thể có khuynh hướng tập trung vào một

dịch vụ riêng lẻ tại một thời điểm, trong khi Vận hành Dịch vụ
có khuynh hướng tập trung vào việc cung cấp và hỗ trợ tất cả
các dịch vụ trong cùng một thời điểm. Nhà quản lý Vận hành
nên hợp tác chặt chẽ với Thiết kế Dịch vụ và Chuyển tiếp Dịch
vụ để đưa ra quan điểm Vận hành nhằm đảm bảo rằng các kết
quả thiết kế và chuyển tiếp hỗ trợ cho nhu cầu vận hành tổng
thể,
 Thiết kế Dịch vụ thường sẽ được tiến hành trong các dự án,
trong khi Vận hành Dịch vụ tập trung vào các quá trình và các
hoạt động quản lý liên tục và có thể lặp lại được. Kết quả của
việc này là các nhân viên vận hành thường không sẵn sàng để
tham gia vào các hoạt động của dự án Thiết kế Dịch vụ, do đó
dẫn đến việc các dịch vụ CNTT khó vận hành hoặc không bao
gồm đầy đủ các yếu tố thiết kế có khả năng quản lý. Ngoài ra,
khi nhân viên dự án đã hoàn thành việc thiết kế một Dịch vụ
CNTT, họ có thể chuyển sang dự án tiếp theo và không sẵn
sàng để hỗ trợ cho những khó khăn trong môi trường vận hành.
Việc vượt qua thách thức này đòi hỏi Vận hành Dịch vụ phải lập
kế hoạch để nhân viên của mình tham gia một cách tích cực
vào các dự án thiết kế, cung cấp nguồn lực cho các hoạt động
chuyển tiếp và tham gia Hỗ trợ Đầu đời của các dịch vụ được
giới thiệu vào trong môi trường vận hành,
 Hai giai đoạn trong vòng đời có các chỉ số khác nhau, điều này
khuyến khích Thiết kế Dịch vụ hoàn thành dự án đúng thời hạn,
theo đặc điểm kỹ thuật và trong phạm vi ngân sách. Trong rất
nhiều trường hợp, rất khó để dự đoán dịch vụ trông sẽ như thế
nào và có giá bao nhiêu sau khi nó đã được triển khai và hoạt
động trong một thời gian. Khi nó không hoạt động như mong
đợi, Quản lý Vận hành CNTT sẽ chịu trách nhiệm. Mặc dù thách
thức này sẽ luôn là hiện thực trong Quản lý Dịch vụ, nhưng
điều này có thể được giải quyết bằng cách tích cực tham gia
vào giai đoạn Chuyển tiếp Dịch vụ của vòng đời. Mục tiêu của
Chuyển tiếp Dịch vụ là đảm bảo rằng các dịch vụ đã được thiết
kế sẽ hoạt động như mong đợi và Nhà quản lý Vận hành có thể
cung cấp kiến thức cần thiết cho Chuyển tiếp Dịch vụ để đánh
giá, và khắc phục, các vấn đề trước khi chúng trở thành vấn đề
trong môi trường vận hành,
 Chuyển tiếp Dịch vụ không được sử dụng một cách hiệu quả để
quản lý quá trình chuyển đổi giữa các giai đoạn Thiết kế và
Vận hành. Ví dụ: một số tổ chức có thể chỉ sử dụng Quản lý
Thay đổi để lập lịch trình triển khai các thay đổi đã được đưa
ra - thay vì thử nghiệm để xem liệu thay đổi có thực hiện
thành công việc chuyển đổi giữa Thiết kế và Vận hành hay
không. Điều bắt buộc là các thông lệ về Chuyển tiếp Dịch vụ
phải được tuân theo và áp dụng các chính sách của tổ chức để
ngăn chặn các thực tiễn Thay đổi được quản lý kém đang được
sử dụng. Các Nhà quản lý Vận hành, Quản lý Thay đổi và Quản
lý Chuyển tiếp phải có thẩm quyền từ chối bất kỳ thay đổi nào
trong môi trường vận hành, không có ngoại lệ, mà không được
kiểm tra một cách kỹ lưỡng.
Những thách thức này chỉ có thể được giải quyết nếu nhân viên Vận
hành Dịch vụ tham gia vào quá trình Thiết kế và Chuyển tiếp Dịch
vụ, và điều này sẽ yêu cầu họ được giao nhiệm vụ và đo lường để
thực hiện điều này một cách chính thức. Các vai trò đã được xác
định trong quy trình Thiết kế Dịch vụ nên được đưa vào mô tả công
việc của nhân viên Quản lý Ứng dụng CNTT và Quản lý Kỹ thuật và
thời gian của họ được phân bổ trên cơ sở từng dự án.
Một loạt thách thức khác lại có liên quan đến đo lường. Mỗi cấu trúc
thay thế sẽ giới thiệu các kết hợp khác nhau của các mục dễ hoặc
khó đo lường. Ví dụ, việc đo lường hiệu suất của một thiết bị hoặc
nhóm có thể tương đối dễ dàng, nhưng việc xác định xem hiệu suất
đó tốt hay xấu đối với dịch vụ CNTT tổng thể lại là một vấn đề hoàn
toàn khác. Một quy trình Quản lý Mức Dịch vụ tốt sẽ giúp giải quyết
vấn đề này, nhưng điều đó có nghĩa là các nhóm Vận hành Dịch vụ
phải là một phần không thể thiếu của quy trình đó (xem ấn phẩm
Liên tục Cải tiến Dịch vụ).
Tập hợp những thách thức thứ ba có liên quan đến việc sử dụng các
Nhóm Ảo. Cơ cấu quản lý phân cấp và theo truyền thống đang trở
nên bất cập vì sự phức tạp và đa dạng của hầu hết các tổ chức. Một
Mô hình quản lý (Ma trận Quản lý - Matrix Management) đã xuất
hiện, trong đó nhân viên báo cáo cho các nguồn khác nhau về các
nhiệm vụ khác nhau. Điều này đã dẫn đến một mạng lưới trách
nhiệm giải trình phức tạp và làm gia tăng nguy cơ các hoạt động
lách qua các khe nứt. Mặt khác, nó cũng cho phép tổ chức cung cấp
các kỹ năng và kiến thức ở những nơi cần thiết nhất để hỗ trợ cho
hoạt động kinh doanh. Quản lý Kiến thức và việc lập sơ đồ cấu trúc
quyền hạn sẽ ngày càng trở nên quan trọng khi các tổ chức mở rộng
và đa dạng hóa. Điều này đã được thảo luận trong ấn phẩm Chiến
lược Dịch vụ ITIL.
Một trong những thách thức quan trọng nhất mà các Nhà quản lý
Vận hành Dịch vụ phải đối mặt là việc cân bằng nhiều mối quan hệ
bên trong và bên ngoài. Hầu hết các tổ chức CNTT ngày nay đều
phức tạp và khi các dịch vụ trở nên thương mại hóa hơn thì việc sử
dụng các mạng giá trị, quan hệ đối tác và các mô hình dịch vụ chia
sẻ ngày càng gia tăng. Mặc dù là một lợi thế đáng kể đối với nhu
cầu kinh doanh đang phát triển năng động, nhưng điều này cũng làm
gia tăng mức độ phức tạp của việc quản lý dịch vụ một cách gắn
kết, hiệu quả và cung cấp đường nối vô hình giữa khách hàng và
mạng lưới phức tạp về cách dịch vụ thực sự được phân phối. Một
Nhà quản lý Vận hành Dịch vụ nên đầu tư vào kiến thức và kỹ năng
quản lý mối quan hệ để giúp đối phó với sự phức tạp của thách thức
này.
9.2 Các Yếu tố Thành công quan trọng
9.2.1 Sự hỗ trợ c ủ a C ấ p Q u ả n lý
Sự hỗ trợ của Quản lý Cấp cao và Cấp trung là cần thiết cho tất cả
mọihoạt động và quy trình ITSM, đặc biệt là trong Vận hành Dịch vụ.
Sự hỗ trợ của Quản lý Cấp cao là rất quan trọng để có được và duy
trì nguồn vốn và nguồn cung ứng đầy đủ. Thay vì coi Hoạt động Dịch
vụ là một 'lỗ đen' để đầu tư, các nhà Quản lý Cấp cao nên định
lượng và bảo vệ lợi ích của Vận hành Dịch vụ tốt. Họ cũng phải được
thông báo đầy đủ về các kết quả thảm khốc có thể xảy ra do Vận
hành Dịch vụ kém.
Quản lý Cấp cao phải cung cấp sự hỗ trợ rõ ràng trong quá trình
khởi động các sáng kiến Vận hành Dịch vụ mới (chẳng hạn như
thông qua việc xuất hiện tại các cuộc hội thảo, các bên ký kết các
bản ghi nhớ và thông báo, v.v…) và sự hỗ trợ liên tục của họ phải
được thể hiện rõ ràng như nhau. Hoàn toàn có th ể đưa ra thông điệp
sai nếu một nhà quản lý cấp cao không đến dự một cuộc họp quan
trọng của dự án hoặc hội thảo khởi động. Tệ hơn nữa là các nhà
quản lý cấp cao ủng hộ sáng kiến bằng lời nói, nhưng lại lạm dụng
quyền hạn của họ để khuyến khích việc phá vỡ quy trình Vận hành
Dịch vụ.
Các nhà Quản lý Cấp cao cũng nên trao quyền cho các Quản lý Cấp
trung, những người sẽ chịu trách nhiệm trực tiếp về Vận hành Dịch
vụ. Việc ủng hộ sáng kiến một cách công khai, nhưng sau đó vư ợt
quá các yêu cầu ngân sách hoặc những thay đổi cần thiết, sẽ gây
hại cho cả việc triển khai và sáng kiến Hoạt động Dịch vụ liên tục.
Các Nhà quản lý Cấp trung cũng phải cung cấp sự hỗ trợ cần thiết -
và đặc biệt điều này nên được thể hiện bằng hành động của họ. Nếu
một nhà quản lý cấp trung bị coi là phá vỡ hoặc ghi đè lên một thủ
tục đã được thỏa thuận (ví dụ, thực hiện một thay đổi mà không
thông qua quy trình Quản lý Thay đổi) thì điều này đưa ra thông
điệp rõ ràng rằng những người khác cũng có thể làm như vậy - và
thủ tục đó là vô giá trị và có thể bị bỏ qua bởi tất cả mọi người. Các
nhà quản lý cấp trung nên cố gắng khiến cho sự ủng hộ của họ được
biết đến, không chỉ bằng lời nói mà còn bằng hành động và sự tuân
thủ các quy trình và thủ tục đã được thống nhất của tổ chức.
Các Nhà quản lý Cấp trung cũng nên hỗ trợ hết mình cho việc thuê
nhân viên để hỗ trợ cho quy trình, thay vì chấp nhận nhu cầu Vận
hành Dịch vụ đã được chính thức hóa và sau đó chỉ cần tăng khối
lượng công việc của nhân viên hiện có để công việc được hoàn
thành.
9.2.2 Sự hỗ trợ c ủ a doanh nghi ệp

Điều quan trọng là các Đơn vị Kinh doanh cũng phải hỗ trợ cho Vận
hành Dịch vụ. Cấp độ hỗ trợ này có thể đạt được tốt hơn nếu như
nhân viên Vận hành Dịch vụ tham gia vào việc kinh doanh trong mọi
hoạt động của họ và cởi mở trong báo cáo của họ về cả thành công
lẫn thất bại – và nỗ lực cải thiện của họ.
Một điều cũng quan trọng không kém là các Đơn vị Kinh doanh hiểu,
chấp thuận và thực hiện vai trò mà họ đảm nhận trong Vận hành
Dịch vụ. Dịch vụ tốt đòi hỏi những khách hàng tốt! Việc tuân thủ các
chính sách, quy trình và th ủ tục, chẳng hạn như sử dụng Bộ phận Hỗ
trợ Dịch vụ để ghi nhật ký mọi yêu cầu, là một trách nhiệm trực tiếp
của khách hàng để hỗ trợ và khuyến khích trong phạm vi doanh
nghiệp.
Các giao tiếp thường xuyên với doanh nghiệp để tìm hiểu những mối
quan tâm và khát vọng của họ và để đưa ra phản hồi về những nỗ
lực để đáp ứng nhu cầu của họ là điều thiết yếu trong việc xây dựng
những mối quan hệ đúng đắn và đảm bảo sự hỗ trợ liên tục.
Ngoài ra, doanh nghiệp nên thống nhất về chi phí cho việc triển khai
Vận hành Dịch vụ và hiểu về lợi nhuận trên khoản đầu tư, trừ khi
điều này thực sự đã được thỏa thuận như một phần của quy trình
Thiết kế.
9.2.3 Nhà vô đ ịc h
Các dự án ITSM và những kết quả là quá trình thực hành liên tục
(được thực hiện bởi nhân viên Vận hành Dịch vụ) thường thành công
hơn nếu một hoặc nhiều ‘nhà vô địch’ sẵn sàng giúp đó, người có
thể dẫn dắt những người khác thông qua sự nhiệt tình và cam kết
của họ đối với ITSM.
Trong một số trường hợp, những nhà vô địch này có thể là những
nhà quản lý cấp cao đang lãnh đạo từ trên xuống. Nhưng các nhà vô
địch cũng có thể thành công nếu họ đến từ các cấp khác của tổ
chức. Một hoặc hai nhân viên cấp dưới vẫn có thể có một ảnh hưởng
có lợi đáng kể đến một phần kết thành công.
Các nhà vô địch thường được tạo ra hoặc chịu ảnh hưởng lớn thông
qua đào tạo Quản lý Dịch vụ chính thức, đặc biệt là ở các cấp độ
được nâng cao hơn, nơi các lợi ích tiềm năng cho tổ chức và cho các
cá nhân, những người đưa ra lộ trình sự nghiệp trong Quản lý Dịch
vụ, có thể được khám phá một cách đầy đủ.
Nên lưu ý rằng các nhà vô địch xuất hiện theo thời gian. Họ không
thể được tạo ra hoặc được chỉ định. Thông thường, chính người
dùng hoặc khách hàng là những người giúp đỡ nhiều nhất trong việc
tạo ra các quy trình Quản lý Dịch vụ thích hợp vì họ nhận thức sâu
sắc về những cải tiến cần thiết xét từ góc độ kinh doanh. Điều quan
trọng là phải nhận ra rằng đây thường là những nhân viên có động
lực cao, những người thường tự nguyện đảm nhận khối lượng công
việc lớn nhất. Nếu đầu vào của họ là hiệu quả nhất, họ phải được
cấp đủ thời gian để thực sự làm việc như một nhà vô địch.
9.2.4 Phân b ổ nhân s ự và duy trì

Việc có được số lượng nhân viên thích hợp cùng với những kỹ năng
phù hợp là điều tối quan trọng đối với sự thành công của Vận hành
Dịch vụ. Một số những thách thức cần phải vượt qua bao gồm những
điều sau đây.
 Các dự án cho các dịch vụ mới thường khá tốt trong việc xác
định những kỹ năng mới cần thiết, nhưng thường đánh giá thấp
số lượng nhân viên cần thiết và cách để duy trì được các kỹ
năng mới. Hãy xem đoạn 9.2.1 để biết thêm một số ý tưởng về
cách làm thế nào để tạo điều kiện trao đổi thông tin tốt hơn về
các yêu cầu,
 Sự khan hiếm nguồn lực có những hiểu biết tốt về Quản lý Dịch
vụ. Việc có được những người giỏi về kỹ thuật là cần thiết,
nhưng cũng cần phải có một số cá nhân chủ chốt, những người
có khả năng luân chuyển giữa các vấn đề công nghệ và vấn đề
dịch vụ,
 Vì những nguồn lực này khá khan hiếm nên việc phải đào tạo
họ là điều khá phổ biến, chỉ khiến họ từ chức và gia nhập một
công ty khác với mức lương cao hơn (đoạn này khá khó hiểu –
người dịch. Có thể hàm ý là phải kết hợp giữa đãi ngộ, đào tạo
và lộ trình thăng tiến trong sự nghiệp để có được cam kết phục
vụ lâu dài của họ). Con đường sự nghiệp rõ ràng và những đãi
ngộ tốt nên là một phần của mọi sáng kiến Quản lý Dịch vụ,
 Cố gắng giao [công việc] quá nhiều và quá sớm, cho nhân viên
hiện có. Việc đạt được Vận hành Dịch vụ hiệu quả sẽ mất nhiều
thời gian, nhưng nếu được tiếp cận một cách đúng đắn thì cuối
cùng cũng sẽ đạt được. Thật không may, một số nhà quản lý cố
gắng đẩy nhanh việc tiết kiệm bằng cách chỉ định công việc
tạm thời là triển khai các quy trình và công cụ mới cho các
nhân viên hiện có và đang rất bận rộn. Luôn luôn vẫn vậy,
hoặc là dự án sẽ không thành công, hoặc là dịch vụ sẽ gặp khó
khăn và đôi khi nhân viên có giá tr ị sẽ rời đi. Các dự án Quản
lý Dịch vụ thành công thường đòi hỏi một khoản đầu tư ngắn
hạn vào nhân viên tạm thời hoặc nhà thầu, và điều này không
nên bị đánh giá quá thấp.
9.2.5 Đào t ạ o Q u ả n lý D ị ch v ụ
Việc đào tạo và nâng cao nhận thức đầy đủ có thể mang lại những
lợi ích tổng thể rộng lớn hơn nhiều. Cũng như việc tạo ra các nhà vô
địch của một số ít, nó có thể được sử dụng để thu phục 'trái tim và
khối óc' của nhiều người. Tất cả các nhân viên Vận hành Dịch vụ đều
phải nhận thức được hệ quả của các hành động của họ, cả tốt lẫn
xấu, đối với tổ chức - và tất cả đều phải thấm nhuần ‘văn hóa Quản
lý Dịch vụ’.
Có thể có các công cụ và thực tiễn Vận hành Dịch vụ tốt nhất trên
thế giới - nhưng Quản lý Dịch vụ sẽ không thành công trừ khi mọi
người cũng hài lòng với các mục tiêu Quản lý Dịch vụ tổng thể. Do
đó, sự tín nhiệm và hỗ trợ của tất cả nhân viên là một điều rất quan
trọng - và vai trò của đào tạo và nâng cao nhận thức, thậm chí cả
bằng cấp chính thức mang lại lợi ích cho cá nhân, không nên bị đánh
giá quá thấp.
Đào tạo cần thiết để Quản lý Dịch vụ thành công bao gồm:
 Đào tạo nhân viên CNTT về các quy trình đã được triển khai.
Điều này sẽ bao gồm đào tạo chung để họ hiểu đầy đủ về các
khái niệm, cũng như đào tạo được nhắm mục tiêu đặc biệt vào
các quy trình riêng của tổ chức,
 Đào tạo về các kỹ năng 'mềm' hoặc kỹ năng 'con người', đặc
biệt cho những nhân viên ở vị trí giao tiếp với khách hàng,
 Đào tạo về hiểu biết về việc kinh doanh và tầm quan trọng của
việc đạt được văn hóa dịch vụ,
 Khi các công cụ đã được triển khai, đào tạo về cách làm thế
nào để sử dụng và quản lý những công cụ đó,
 Ngoài ra, khách hàng và người dùng cần được đào tạo thích
hợp về cách thức làm thế nào để hợp tác với CNTT – truy cập
vào các dịch vụ, yêu cầu thay đổi, đệ trình các yêu cầu, sử
dụng các công cụ, v.v…
9.2.6 Các công c ụ phù h ợ p

Rất nhiều quy trình và hoạt động Vận hành Dịch vụ không thể được
thực hiện một cách hiệu quả mà không có đủ các công cụ hỗ trợ
(như đã được phác thảo trong Chương 7). Các nhà qu ản lý cấp cao
phải đảm bảo rằng nguồn cấp vốn cho những công cụ như vậy đã
được đưa vào ngân sách liên tục và hỗ trợ cho việc mua sắm, triển
khai và bảo trì liên tục những công cụ đó.
9.2.7 Tính h i ệu lực c ủa ki ểm ng hi ệm

Chất lượng của các dịch vụ CNTT có thể được cung cấp trong Vận
hành Dịch vụ phụ thuộc vào chất lượng của các hệ thống và thành
phần được đưa vào môi trường vận hành.
Mức chất lượng sẽ được tăng cường một cách đáng kể nếu việc kiểm
nghiệm đầy đủ và hoàn chỉnh các thành phần và bản phát hành mới
được tiến hành trong những thời điểm thích hợp. Các tài liệu cũng
cần được kiểm tra về tính đầy đủ và chất lượng của chúng.
Điều này đòi hỏi phải có một môi trường kiểm nghiệm thực tế và
toàn diện cho mọi hệ thống/thành phần - phản ánh môi trường vận
hành về khối lượng cũng như các đặc tính. Nên có những chuyên
viên kiểm nghiệm độc lập nếu có thể. Việc tài trợ nguồn vốn cho các
môi trường kiểm nghiệm như vậy là cần thiết nếu muốn đạt được các
dịch vụ có chất lượng cao.
Ngoài ra, cần có đủ thời gian và nỗ lực để đảm bảo rằng việc kiểm
nghiệm đã được lên kế hoạch và thiết kế một cách đúng đắn - cũng
như dành đủ thời gian để kiểm tra, và kiểm tra lại nếu một số bộ
phận bị lỗi! Cách tốt nhất để đảm bảo điều này là làm theo hướng
dẫn trong ấn phẩm Chuyển tiếp Dịch vụ.
9.2.8 Đo l ư ờ ng và báo cáo

Một định nghĩa rõ ràng về cách mọi thứ được đo lường và báo cáo
như thế nào là điều cần thiết (như được phác thảo trong Phụ lục B)
để từ đó, mọi nhân viên đều có các đích nhắm mục tiêu rõ ràng để
hướng đến và CNTT và các Nhà quản lý Doanh nghiệp có khả năng
đánh giá một cách nhanh chóng và dễ dàng về tiến trình và xác định
bất kỳ lĩnh vực nào cần phải được quan tâm.
9.3 N hững r ủ i ro
Thất bại trong việc đáp ứng được những thách thức đã được mô tả
trong phần 9.1 hoặc xác định những Yếu tố Thành công Quan trọng
được phác thảo trong phần 9.2 là những rủi ro hiển nhiên – nhưng
những rủi ro khác được mô tả như được trình bày dưới đây.
9.3.1 Tổn th ấ t d ịch v ụ

Rủi ro tối hậu đối với doanh nghiệp về những điểm yếu trong Vận
hành Dịch vụ là tổn thất của những dịch vụ CNTT tối quan trọng với
những tác động bất lợi tiếp theo đó lên nhân viên, khách hàng và tài
chính. Trong những trường hợp nghiêm trọng, có thể có những thiệt
hại tiềm ẩn về tính mạng và chân tay khi các dịch vụ CNTT bị ảnh
hưởng được sử dụng cho những mục đích an toàn hoặc sức khỏe
quan trọng – ví dụ nhu việc triển khai phương tiện khẩn cấp hoặc
quét sức khỏe (nguyên văn là health scanning – người dịch), v.v…
9.3.2 R ủi ro đ ối v ớ i V ậ n hành D ị ch v ụ thành công

Những rủi ro để đạt được thành công trong Vận hành Dịch vụ là rất
nhiều - và trong nhiều trường hợp là ngược lại với các Yếu tố Thành
công Quan trọng như đã mô tả trước đó - nhưng cũng bao gồm:
 Không đủ kinh phí và nguồn lực: Nguồn vốn phải được điều
chỉnh, phân bổ và dự trữ cho mục đích ban đầu của nó,
 Mất động lực: Khi nhân viên coi Quản lý dịch vụ như là
'hương vị của tháng' thay vì thay đổi vĩnh viễn cách họ làm
việc cho tương lai, kết quả sẽ là bất kỳ động lực nào cũng mất
đi: phải làm rõ ngay từ ban đầu rằng một cách làm việc mới là
bắt buộc. Ngoài ra, các cơ chế nên được đưa ra để đảm bảo
rằng sáng kiến vẫn tồn tại sau những thay đổi của tổ chức,
 Mất nhân sự chủ chốt: Đôi khi việc mất một hoặc hai nhân sự
chủ chốt có thể có tác động nghiêm trọng: để cố gắng giảm
thiểu ảnh hưởng này, các tổ chức nên tìm cách đào tạo chéo
cho nhân viên và giảm bớt sự phụ thuộc vào các cá nhân. Điều
này đặc biệt đúng trong các tổ chức chưa trưởng thành, nơi mà
kiến thức vẫn chưa được chính thức hóa thành các quy trình,
tài liệu và công cụ. Các tổ chức này có khuynh hướng phụ
thuộc vào những nỗ lực ‘anh hùng’ của một số ít người hiểu
biết, và bị tàn phá khi họ rời đi,
 Chống lại sự thay đổi: Đôi khi mọi người phản đối những
điều mới và miễn cưỡng đưa chúng vào cuộc. Giáo dục, đào
tạo, giao tiếp và nêu bật các lợi ích sẽ hữu ích.
 Thiếu sự hỗ trợ của cấp quản lý: Điều này thường xảy ra với
các Nhà quản lý cấp trung, những người có thể không nhìn thấy
tầm nhìn tổng thể hoặc không đạt được những lợi ích thực tế
mà nhiều nhân viên cấp dưới có thể đạt được. Xem đoạn 9.2.1
để biết thêm thông tin về điều này, tuy nhiên, các nhà quản lý
cần hỗ trợ cho Quản lý Dịch vụ và tham gia vào các giai đoạn
và quy trình thích hợp của Thiết kế, Chuyển tiếp và Vận hành
Dịch vụ để cung cấp sự hỗ trợ hữu hình,
 Nếu thiết kế ban đầu bị lỗi, việc triển khai thành công sẽ
không bao giờ mang lại kết quả cần thiết - và cuối cùng thì
việc thiết kế lại sẽ là cần thiết,
 Trong một số tổ chức Quản lý dịch vụ có thể bị cả CNTT và
doanh nghiệp nhìn với ánh mắt nghi ngờ. Nhân viên CNTT coi
đó là một nỗ lực để kiểm soát họ, trong khi doanh nghiệp coi
đó là một nỗ lực của CNTT để kiếm thêm nguồn vốn tài trợ mà
không thực sự cải thiện bất cứ điều gì. Những lợi ích của Quản
lý Dịch vụ cần được trình bày một cách rõ ràng cho tất cả các
bên liên quan,
 Khác biệt với kỳ vọng của khách hàng. Trong khi nhân viên
vận hành được khuyến khích thực hiện theo các tiêu chuẩn thì
những kỳ vọng của khách hàng và người dùng đôi khi lại khác.
Trong các trường hợp khác, một khách hàng có thể đã trả
nhiều tiền hơn cho một dịch vụ cao cấp, nhưng khi một người
dùng từ một khu vực khác nhìn thấy dịch vụ cao cấp, họ cảm
thấy đã bị lừa. Vấn đề này nên được giải quyết thông qua SLM
rõ ràng và giao tiếp cẩn trọng trong quá trình Thiết kế Dịch vụ.
Các khiếu nại về bản chất này nên được giải quyết thông qua
các quy trình Liên tục Cải tiến Dịch vụ và không nên chỉ liên
quan đến Vận hành Dịch vụ gia tăng dịch vụ theo yêu cầu một
cách tự động.
Lờ i b ạ t
Một sự thật đơn giản phải định hướng cho tất cả chúng ta trong Vận
hành Dịch vụ. Kinh doanh và công nghệ sẽ tiếp tục phát triển trong
tương lai. Những gì đã được đổi mới trong năm ngoái là phổ biến
trong năm nay. Những gì là thực tiễn tốt nhất ngày hôm nay sẽ là
phổ biến vào ngày mai. Việc đạt được sự xuất sắc trong Vận hành
Dịch vụ đòi hỏi sự linh hoạt, cân bằng và khả năng phán đoán tốt
trong việc sử dụng những thực tiễn ITIL. Hướng dẫn trong ấn phẩm
này là chìa khóa để có được kiến thức, trí tuệ, tầm nhìn tương lai và
đạt được khả năng cân bằng nhu cầu kinh doanh của ngày hôm nay
và nhu cầu của ngày mai.
Tất cả các thông lệ phổ biến, tốt, tốt nhất và trong tương lai đều
góp phần vào mục tiêu dịch vụ xuất sắc. ITIL cung cấp những điều
này làm cơ sở để hướng dẫn bạn hướng tới mục tiêu này.
Sự ổn định trong một thế giới đang thay đổi là thực tế đối với các
Nhà cung cấp Dịch vụ. Những người xuất sắc, và vẫn tiếp tục là
người giỏi nhất, hiểu điều này và biết rằng cách để đạt được điều
này chính là thích nghi, học hỏi, đổi mới và dẫn đầu.
Ấn phẩm Vận hành Dịch vụ là một phần không thể thiếu của thực
tiễn Vòng đời ITSM tổng thể. Được sử dụng cùng với nhau, Thực tiến
ITIL về Quản lý Dịch vụ tạo nên một công cụ mạnh mẽ trong tay của
bất kỳ Nhà cung cấp Dịch vụ nào.
Phụ lụ c A: Hư ớ ng d ẫ n b ổ sung trong ngành
Khi ITIL lần đầu tiên được giới thiệu vào những năm thập niên 1980,
có rất ít những hướng dẫn không độc quyền về thực tiễn tốt nhất
ITSM.
Ngày nay, có những khuôn khổ hoặc phương pháp luận khác có
những đóng góp có giá trị trong lĩnh vực này, bổ sung và có sức
mạnh tổng hợp với ITIL và có thể hỗ trợ cho Vận hành Dịch vụ.
A1 COBIT
Khuôn khổ COBIT, được tạo ra bởi Hiệp hội Kiểm toán và Kiểm soát
Hệ thống Thông tin (ISACA) và được quản lý bởi Viện Quản trị CNTT
(IT Governance Institute), cung cấp một khuôn khổ hướng dẫn rất
hữu ích cho nhân viên kiểm toán và bảo mật CNTT.
Phiên bản hiện tại của COBIT, ấn bản 4, bao gồm 34 Mục tiêu Kiểm
soát Cấp cao, 13 trong số đó được nhóm lại theo ‘Lĩnh vực Phân phối
và Hỗ trợ (Deliver and Support Domain) ’, vốn ánh xạ một cách khá
chặt chẽ đến giai đoạn Vận hành Dịch vụ của ITIL. Những lĩnh vực
này có tiêu đề:
 DS1 Xác định và quản lý các mức dịch vụ.

 DS2 Quản lý các dịch vụ của bên thứ ba.
 DS3 Quản lý hiệu suất và công suất.
 DS4 Đảm bảo liên tục dịch vụ.
 DS5 Đảm bảo bảo mật hệ thống.
 DS6 Xác định và phân bổ chi phí.
 DS7 Giáo dục và đào tạo người dùng.
 DS8 Quản lý Bộ phận Hỗ trợ Dịch vụ và sự cố.
 DS9 Quản lý cấu hình.
 DS10 Quản lý các vấn đề.
 DS11 Quản lý dữ liệu.
 DS12 Quản lý môi trường vật lý.
 DS13 Quản lý vận hành.
Một số khía cạnh của Vận hành Dịch vụ cũng được đề cập đến trong
một số mục tiêu kiểm soát trong các lĩnh vực khác - nhưng phần lớn
những gì COBIT đã truyền đạt là về giai đoạn 'vận hành thực tế [live
operations]' của CNTT đều nằm trong các mục tiêu kiểm soát nói
trên.
COBIT chủ yếu nhắm đến các kiểm toán viên, vì vậy, COBIT nhẫn
mạnh vào những gì nên được đánh giá và cách thức (đánh giá), thay
vì bao gồm những hướng dẫn chi tiết cho những ai đang vận hành
các quy trình sẽ được đánh giá - nhưng nó có rất nhiều tài liệu hợp
lệ mà các tổ chức có thể thấy hữu ích.
Nên lưu ý rằng COBIT và ITIL không phải là ‘cạnh tranh’ và cũng
không loại trừ lẫn nhau - ngược lại, chúng có thể được sử dụng kết
hợp như một phần của khuôn khổ quản trị và quản lý tổng thể của tổ
chức. ITIL cung cấp cho tổ chức hướng dẫn thực tiễn tốt nhất về
cách làm thế nào để quản lý và cải tiến quy trình của tổ chức để
cung cấp các dịch vụ CNTT có chất lượng cao và hiệu quả về chi phí.
COBIT cung cấp hướng dẫn về cách thức các quá trình này nên được
kiểm toán và đánh giá như thế nào để xác định xem chúng có đang
hoạt động như dự kiến và mang lại lợi ích tối ưu cho tổ chức hay
không.
Để có một bức tranh tổng thể hoàn chỉnh hơn, các tổ chức có thể
muốn đọc và trở nên quen thuộc với những gì COBIT đã truyền đạt
cùng với việc đọc và hiểu về ITIL của họ. Thông tin chi tiết hơn về
tiêu chuẩn có thể được tìm thấy trên trang web của ISACA tại địa chỉ
www.isaca.org.
A2 ISO/IEC 20000
Vào tháng Mười hai năm 2005, Tổ chức Tiêu chuẩn Quốc tế ra mắt
một tiêu chuẩn quốc tế chính thức, ISO/ISE 20000, đối với các tổ
chức có thể đang tìm kiếm sự công nhận độc lập cho ITSM. Tiền
thân là Tiêu chuẩn của Anh, BS15000, ban đầu được giới thiệu vào
năm 2000 và theo đó, một số tổ chức đã được công nhận, tuy nhiên
đã được thay thế bằng ISO/ISE 20000 và việc công nhận vẫn đã
được tiếp tục.
Trong khi ISO/IEC 20000 ban đầu được ánh xạ tới ấn phẩm Hỗ trợ
Dịch vụ và Cung cấp Dịch vụ trước đây của ITIL, tiêu chuẩn này vẫn
tiếp tục ánh xạ tốt đến ITIL hiện tại và cũng bao gồm Bảo mật
CNTT, Quản lý Quan hệ Kinh doanh và Quản lý Nhà cung cấp.
Đối với các tổ chức đang tìm kiếm sự công nhận chính thức đối với
ISO/IEC 20000, để có được sự công nhận từ bên ngoài và quốc tế về
sự thành công của các quy trình ITSM của họ, sẽ phải có sự tham
gia một cách đáng kể của nhân viên Vận hành Dịch vụ trong việc
chuẩn bị và trải qua giám sát chính thức cần thiết để đạt được tiêu
chuẩn.
Thông tin chi tiết thêm về tiêu chuẩn có thể được tìm thấy thông
qua diễn đàn itSMF tại www.itsmf.com hoặc ISO tại www.iso.org.
A3 CMMI
Mô hình Trưởng thành Năng lực Tích hợp (Capability Maturity Model®
Inegration - CMMI) là một phương pháp cải tiến quy trình được phát
triển bởi Viện Kỹ thuật Phần mềm (Software Engineering Institue -
SEI) thuộc Đại học Carnegie Mellon. CMMI cung cấp cho các tổ chức
các yếu tố thiết yếu của các quy trình hiệu quả. Nó có thể được sử
dụng để hướng dẫn cho việc cải tiến quy trình trong một dự án, một
bộ phận hoặc toàn bộ tổ chức. CMMI giúp tích hợp các chức năng tổ
chức riêng biệt theo truyền thống, thiết lập các mục tiêu và ưu tiên
cải tiến quy trình, cung cấp hướng dẫn cho các quy trình chất lượng
và cung cấp một điểm tham chiếu để đánh giá các quy trình hiện tại.
Để biết thêm thông tin, hãy xem http://www.sei.cmu.edu/cmmi/.
Một số tổ chức tư vấn CNTT đã tích hợp mô hình trưởng thành vào
trong các dịch vụ đánh giá ITSM của họ như một cách hỗ trợ các tổ
chức chuẩn bị và đánh giá các cải tiến quy trình - bao gồm cả những
cải tiến trong lĩnh vực Vận hành Dịch vụ. Các tổ chức có thể muốn
sử dụng một số hình thức của mô hình để giúp định hướng lộ trình
của họ tới việc công nhận ISO/ISE 20000 độc lập.
A4 Thẻ điểm Cân bằng

Một phương pháp tiếp cận mới để quản lý chiến lược đã được phát
triển vào đầu những năm thập niên 1990 bởi Tiến sĩ. Robert Kaplan
(Trường Kinh doanh Harvard) và David Norton. H ọ đã đặt tên cho hệ
thống này là ‘Thẻ điểm Cân bằng’. Từ việc nhận ra được một số
điểm yếu và sự mơ hồ của các phương pháp quản lý trước đây,
phương pháp thẻ điểm cân bằng cung cấp một chỉ định rõ ràng về
những gì các công ty nên đo lường để ‘cân bằng’ quan điểm tài
chính. Thẻ điểm cân bằng gợi ý rằng tổ chức được nhìn nhận từ bốn
khía cạnh và rất có giá trị khi phát triển các chỉ số, thu thập dữ liệu
và phân tích nó liên quan đến từng góc độ sau:
 Khía cạnh học tập và phát triển,

 Khía cạnh Quy trình Nghiệp vụ,
 Khía cạnh Khách hàng,
 Khía cạnh Tài chính.
Một số tổ chức có thể chọn sử dụng phương pháp Thẻ điểm Cân
bằng như một cách để đánh giá và báo cáo về hiệu suất chất lượng
CNTT nói chung và hiệu suất Vận hành Dịch vụ của họ nói riêng.
Thông tin chi tiết có sẵn thông qua Cộng đồng Người dùng Thẻ điểm
Cân bằng (Balanced Scorecard User Community) tại
www.scorecardsupport.com.
A5 Quản lý Chất lượng

Có những lợi thế khác biệt khi gắn các quy trình ITSM của một tổ
chức và đặc biệt là các quy trình Vận hành Dịch vụ vào hệ thống
quản lý chất lượng của tổ chức đó. Nếu một tổ chức có hệ thống
quản lý chất lượng chính thức như ISO9000, Six Sigma, TQM, v.v …
thì hệ thống này có thể được sử dụng để đánh giá tiến độ một cách
thường xuyên và thúc đẩy các sáng kiến cải tiến dịch vụ đã được
thống nhất thông qua những quá trình đánh giá và báo cáo thường
xuyên.
Nhiều tổ chức đã sử dụng một cuộc kiểm toán thường xuyên hàng
năm hoặc đánh giá bên ngoài như một cách để xác định các cải tiến
cần thiết - và sau đó là hệ thống Quản lý Chất lượng của họ để thúc
đẩy thông qua các chương trình công vi ệc cụ thể.
A6 ITIL và Khuôn khổ OSI

Vào khoảng thời gian mà ITIL v1 đang được viết, Tổ chức Tiêu
chuẩn Quốc tế đã đưa ra một sáng kiến dẫn đến khuôn khổ Kết nối
Hệ thống Mở (OSI). Vì sáng kiến này đề cập đến nhiều lĩnh vực
tương tự như nhóm ITIL, nên không có gì ng ạc nhiên khi chúng đề
cập đến nhiều lĩnh vực giống nhau.
Tuy nhiên, cũng không có gì đáng ng ạc nhiên khi họ đã phân loại

các quy trình của mình theo cách thức khác nhau, đã sử dụng các
thuật ngữ khác nhau hoặc đã sử dụng cùng một thuật ngữ theo
những cách khác nhau. Để làm cho các vấn đề trở nên khó hiểu hơn,
các nhóm khác nhau trong một tổ chức thường sử dụng thuật ngữ từ
cả ITIL lẫn khuôn khổ OSI.
Mặc dù phạm vi của ấn phẩm này không phải là nhằm khám phá
khuôn khổ OSI, nhưng nó cũng đã có những đóng góp đáng kể vào
việc định nghĩa và thực thi các chương trình và dự án ITSM trên
toàn thế giới. Nó cũng đã gây ra rất nhiều cuộc tranh luận giữa các
đội không nhận thức được nguồn gốc của thuật ngữ mà họ đang sử
dụng.
Ví dụ: một số tổ chức có hai bộ phận Quản lý Thay đổi - một bộ

phận tuân theo quy trình Quản lý Thay đổi ITIL và bộ phận kia sử
dụng mô hình Cài đặt, Di chuyển, Bổ sung và Thay đổi (Installation,
Moves, Additions and Changes - IMAC) của OSI. Mỗi bộ phận được
thuyết phục rằng bộ phận này hoàn toàn khác với bộ phận kia, và họ
thực hiện các vai trò khác nhau. Việc kiểm tra kỹ hơn sẽ thấy rằng
có một số lĩnh vực giống nhau.
Trong Vận hành Dịch vụ, việc quản lý các Lỗi Đã biết có thể được
ánh xạ tới Quản lý Lỗi. Ngoài ra còn có một phần liên quan đến
Quản lý Công suất Vận hành, có thể liên quan đến khái niệm Quản lý
Hiệu suất của OSI.
Phụ lụ c B : Truy ền t hông t rong q uá trìn h V ậ n hành
Dịch v ụ
B1 Truyền thông vận hành thường lệ

Hầu hết các liên lạc giao tiếp trong Vận hành Dịch vụ phải được thực
hiện với sự bảo đảm rằng tất cả các nhóm và bộ phận có khả năng
thực thi các hoạt động tiêu chuẩn liên quan đến việc cung cấp các
dịch vụ CNTT và quản lý cơ sở hạ tầng CNTT.
Những cân nhắc nghiêm túc nên được đưa ra trong quá trình Thiết
kế Dịch vụ để xác định nội dung, kiểu và hình thức truyền thông cần
thiết để vận hành các dịch vụ CNTT.
Mục đích - Để điều phối các hoạt động thường lệ của Vận hành Dịch vụ ở mọi
cấp độ,
- Để đảm bảo rằng mọi nhân viên nhận thức được về hoạt động đã
được lập lịch trình tại mọi thời điểm và rằng họ nhận thức được về
bất kỳ thay đổi hoặc sáng kiến nào có thể ảnh hưởng đến vận hành
bình thường của môi trường CNTT.
Tần suất - Kiểu giao tiếp này diễn ra theo định kỳ và được truyền đạt theo chu
kỳ hàng ngày, hàng tuần hoặc hàng tháng.
Người có vai - Mọi nhà quản lý và nhân viên tham gia vào Vận hành Dịch vụ,
trò - Mọi nhà quản lý quy trình đối với các quy trình được thực thi bởi
nhân viên Vận hành Dịch vụ, đặc biệt là Quản lý Thay đổi, Quản lý
Sự cố và Quản lý Vấn đề.
Nội dung - Tóm tắt các sự kiện kể từ lần giao tiếp trước đó để đảm bảo rằng
mọi người đều nhận thức được về bất kỳ hoạt động tiếp theo nào
cần phải được diễn ra. Đồng thời để đảm bảo rằng tất cả các công
việc hàng loạt theo lô đã hoàn thành và các nhóm hoặc bộ phận đã
sẵn sàng cho hoạt động vận hành tiêu chuẩn,
- Một báo cáo về tình trạng của các hệ thống chính,
- Thông báo cho nhân viên Quản lý Vận hành về bất kỳ tin tức hoặc
sự kiện nào có thể ảnh hưởng đến vận hành trong giai đoạn đó,
- Thảo luận về bất kỳ vấn đề hoặc sự cố còn tồn đọng nào và đảm
bảo rằng một kế hoạch hành động được đưa ra cho từng vấn đề
hoặc sự cố,
- Thảo luận về lịch trình các thay đổi dự kiến sẽ được thực hiện
trong ngày, cùng với một bản tóm tắt về các sự cố tiềm ẩn có thể
xảy ra như kết quả của việc này và hành động thích hợp sẽ được
thực hiện. Điều này không nên bị nhầm lẫn với cuộc họp CAB. Đây
là một cơ hội để kiểm tra xem các thay đổi đã được CAB thống nhất
và lên lịch trình, hoặc thông qua Mô hình Thay đổi, vẫn đang đi
đúng hướng,
- Bất kỳ bảo trì theo kế hoạch hoặc các sự gián đoạn khác đã được
lập lịch trình cho chu kỳ vận hành tiếp theo,
- Thông báo về kết quả của bất kỳ cuộc họp Post Mortem hoặc cuộc
họp Khủng hoảng đã được tổ chức kể từ lần giao tiếp trước,
- Thông báo hoặc nhắc nhở về việc đào tạo có thể có trong tuần hoặc
tháng tới để cho nhân viên và người giám sát của họ thời gian để
lên lịch tringh đào tạo vào Lịch trình Vận hành.
Bối - Các Nhật ký Vận hành,

cảnh/Nguồn - Các Báo cáo Sự cố,
- Các Báo cáo Vấn đề,
- Các Lịch trình Bảo trì,
- Lịch trình Thay đổi.
Bảng B.1 – Các yêu cầu truyền thông trong các dịch vụ CNTT
B2 Truyền thông giữa các ca làm việc
Không phải mọi tổ chức đều làm việc theo ca, nhưng đối với những
tổ chức đang thực hiện điều này, Bảng B.2 sẽ tóm tắt những giao
tiếp cần phải được thực hiện giữa các ca làm việc.
Mục đích - Giao tiếp này đảm bảo rằng quá trình bàn giao giữa các ca trước và
sau diễn ra suôn sẻ và đồng thời khiến cho ca làm việc mới nhận
thức được về bất kỳ khó khăn tiềm ẩn nào. Chúng cũng đảm bảo
rằng ca làm việc mới nhận thức được về bất kỳ nhiệm vụ nào cần
phải được hoàn thành.
Tần suất - Tại thời điểm bàn giao giữa các ca.
Người có vai - Các Trưởng ca của mỗi ca,

trò - Nhân viên của các ca làm việc, những người đang thực hiện các
nhiệm vụ tương tự nhau.
Nội dung - Một báo cáo tóm tắt về các hoạt động vận hành đã được thực hiện
trong ca làm việc trước đó,
- Một bản tóm tắt về tất cả các ngoại lệ và cảnh báo đã được giải
quyết trong ca làm việc,
- Chi tiết về mọi trường hợp ngoại lệ và cảnh báo còn tồn đọng, cùng
với thông tin về tất cả các hành động đã được thực hiện cho đến
thời điểm hiện tại và bất kỳ thông tin nào về các hành động được
dự đoán trong tương lai (ví dụ, một nhà cung cấp được dự kiến sẽ
có mặt để hỗ trợ trong bốn giờ tới).
Bối Giao tiếp giữa các ca thường sẽ dựa trên những nguồn sau đây:
cảnh/Nguồn
- Nhật ký ca làm việc,
- Báo cáo của Trưởng Ca,
- Giao tiếp bằng lời nói hoặc ‘chat’ điện tử giữa các cá nhân khi các
nhân viên thay ca ở các cơ sở khác nhau.
Bảng 6.2 Các yêu cầu truyền thông giữa các ca [làm việc]
B3 Báo cáo Hiệu suất

Báo cáo Hiệu suất trong bối cảnh truyền thông giao tiếp đề cập đến
3 lĩnh vực chính, như được trình bày dưới đây. Ngoài ra, Bảng B.3 –
B.5 minh họa cho phương pháp tiếp cận này một cách tương ứng.
Hiệu suất Dịch vụ CNTT

Thể loại Báo cáo Hiệu suất này thường được thực hiện như một phần
của SLM và được đề cập trong ấn phẩm Liên tục Cải tiến Dịch vụ.
Tuy nhiên, có một khía cạnh cực kỳ quan trọng của Báo cáo Dịch vụ
liên quan đến Vận hành Dịch vụ, cụ thể là các nhóm hoặc bộ phận
Vận hành Dịch vụ được yêu cầu ghi lại và truyền đạt những thông
tin đã đưa vào các báo cáo này.
Tuy nhiên, nhân viên Vận hành Dịch vụ không ở vị thế tốt nhất để
quyết định về nội dung, hình thức và tần suất của Báo cáo Hiệu suất
Dịch vụ. Các yêu cầu đối với loại giao tiếp này phải được xác định
một cách rõ ràng trong quá trình Thiết kế Dịch vụ và được tinh
chỉnh trong quá trình Liên tục Cải tiến Dịch vụ.
Mục đích - Cung cấp thông tin cho các nhóm chịu trách nhiệm về việc báo cáo
Dịch vụ CNTT cho khách hàng và người dùng, có thể được sử dụng
để chứng minh cho thành tựu của các đích nhắm mục tiêu dịch vụ
và như là đầu vào cho các cuộc họp Đánh giá Mức Dịch vụ. Thông
tin cũng có thể được sử dụng như là cơ sở cho việc thay đổi đối với
các dịch vụ CNT.
Tần suất - Như đã được xác định trong các SLA và OLA. Thông tin này thư ờng
được truyền đạt một cách định kỳ trên cơ sở hàng ngày, hàng
tháng và hàng quý.
Người có vai - Các nhóm và bộ phận Vận hành Dịch vụ, thường là nhân viên Vận
trò hành CNTT,
- Nhân viên SLM,
- Nhóm Thiết kế Dịch vụ (những người giúp xác định các tiêu chuẩn
hiệu suất và tinh chỉnh các tiêu chuẩn này thông qua Liên tục Cải
tiến Dịch vụ)
- Các nhóm Liên tục Cải tiến Dịch vụ, đặc biệt là những nhóm được
giao nhiệm vụ Báo cáo dịch vụ.
Nội dung Các ví dụ về loại thông tin Hiệu suất Dịch vụ cần được truyền đạt để hỗ
trợ báo cáo Hiệu suất Dịch vụ là:
- Đạt được các hoạt động cụ thể như đã được định nghĩa trong OLA,
- Đạt được các đích nhắm mục tiêu để cung cấp những đầu ra cụ thể,
- Thành tựu về tính sẵn sàng của dịch vụ hoặc hệ thống,
- Khả năng đáp ứng các Mục tiêu Bảo trì Dịch vụ trong phạm vi thời
gian và mức độ tác động đã được nhắm mục tiêu.
Bối - Các công cụ báo cáo và giám sát,

cảnh/Nguồn - Các Nhật ký Sự kiện,
- Các Nhật ký Ca làm việc.
Bảng B.3 Các yêu cầu Báo cáo Hiệu suất: Các dịch vụ CNTT
Hiệu suất nhóm hoặc bộ phận Vận hành Dịch vụ

Đây là một giao tiếp ‘nội bộ’ mà theo đó, nó diễn ra giữa các thành
viên của nhóm hoặc bộ phận với người quản lý của họ hoặc giữa
người quản lý quy trình và nhóm thực hiện quy trình đó. Những cá
nhân bên ngoài các nhóm hoặc bộ phận này không nên tham gia vào
kiểu giao tiếp này vì nó nhằm mục đích quản lý con người hơn là đo
lường chất lượng của dịch vụ.
Tuy nhiên, một sai lầm phổ biến đối với các bộ phận CNTT khi
truyền đạt loại thông tin này cho khách hàng gi ống như việc báo cáo
về Chất lượng Dịch vụ. Ví dụ, một nhà quản lý có thể báo cáo rằng
bộ phận của họ giải quyết được 80% tất cả các vấn đề. Tuy nhiên,
đối với người dùng bình thường, thông tin này là không liên quan.
Họ quan tâm hơn đến việc liệu Dịch vụ CNTT của họ có hoạt động
như đã được thỏa thuận hay không. Ngoài ra, việc tiết lộ thông tin
nội bộ cho khách hàng và người dùng có thể gây lúng túng cho các
bộ phận và nhóm Vận hành Dịch vụ và có thể dẫn đến việc doanh
nghiệp can thiệp ở mức độ cao để ‘sửa chữa’ các vấn đề đã được
nhận thức.
Mục đích Có ba mục đích chính của truyền thông về Hiệu suất nhóm hoặc bộ
phận Vận hành Dịch vụ:
- Một cách chủ động, đảm bảo rằng nhân viên Vận hành Dịch vụ đang
thực hiện các hoạt động cần thiết để cung cấp các dịch vụ CNTT và
hỗ trợ cho Cơ sở hạ tầng CNTT,
- Phát hiện các vấn đề tiềm ẩn về mức độ nguồn lực, khả năng và
việc phá vỡ các quy trình,
- Đảm bảo rằng hành động khắc phục đã được thực hiện một cách
chính xác và tuân thủ.
Tần suất Không có tần suất được thiết lập cho loại giao tiếp này. Mặc dù một số
Báo cáo Hiệu suất có thể được lập hàng ngày, hàng tuần hoặc hàng
tháng nhưng hầu hết các nhà quản lý đều tham gia vào việc giao tiếp
liên tục với các nhóm hoặc bộ phận của họ khi tình hình yêu cầu.
Trong các tình huống vận hành bình thường, giao tiếp này sẽ có xu
hướng ít thường xuyên hơn so với các tình huống có mức độ thay đổi
cao hoặc tổ chức đang gặp phải số lượng sự cố lớn và mức độ nghiêm
trọng của sự cố.
Người có vai - Các Nhà quản lý Vận hành Dịch vụ,

trò - Nhân viên Vận hành Dịch vụ,
- Các vấn đề hiệu suất có thể được leo thang đến Nhà quản lý Dịch
vụ hoặc CIO.
Nội dung - So sánh giữa hiệu suất cần thiết và hiệu suất thực tế,
- Những khuynh hướng hiệu suất theo thời gian,
- Những báo cáo cụ thể về hành vi sai trái hoặc thất bại trong việc
thực hiện một hành động bắt buộc.
Bối - Báo cáo hiệu suất định kỳ, ví dụ: Nhật ký sự cố, hồ sơ bảo trì, chỉ
cảnh/Nguồn số quy trình,
- Giao tiếp giữa các cá nhân và giao tiếp bằng lời nói trong các tình
huống làm việc,
- Họp nhóm hoặc bộ phận,
- Việc huấn luyện bởi một trưởng nhóm hoặc nhà quản lý,
- Việc điều tra sau một Báo cáo Dịch vụ kém có thể bắt đầu một loạt
các giao tiếp trong Vận hành Dịch vụ,
- Đánh giá Hiệu suất Cá nhân, thường sử dụng (các KPI) được ghi
trong mô tả công việc của cá nhân.
Bảng B.4 – Các yêu cầu Báo cáo Hiệu suất: nhóm hoặc bộ phận Vận
hành Dịch vụ
Hiệu suất của cơ sở hạ tầng hoặc quy trình

Như đối với hiệu suất nhóm hoặc bộ phận, đây là một giao tiếp ‘nội
bộ’ diễn ra giữa các thành viên của một nhóm hoặc bộ phận chịu
trách nhiệm cho việc quản lý một thành phần hoặc hệ thống cơ sở
hạ tầng, hoặc các thành viên của một nhóm quy trình. Những cá
nhân nằm ngoài các nhóm này không nên tham gia vào ki ểu giao
tiếp này vì nó nhằm mục đích quản lý con người thay vì đo lường
hiệu suất của một dịch vụ.
Mục đích Có ít nhất 3 mục đích của kiểu giao tiếp này
- Để đảm bảo hoạt động bình thường của cơ sở hạ tầng hoặc của một
quy trình,
- Để phát hiện các vấn đề tiềm ẩn với cơ sở hạ tầng hoặc với một
quy trình đang được quan tâm,
- Để đảm bảo rằng hành động khắc phục được thực hiện và đã có
hiệu quả.
Tần suất Tần suất của loại giao tiếp này sẽ khác nhau tùy thuộc vào bản chất
của (các) hệ thống đang được quản lý hoặc quy trình đang được thực
thi.
Một số thành phần của cơ sở hạ tầng có tính biến động hơn và sẽ đòi
hỏi giao tiếp thường xuyên và thậm chí cả các cuộc họp để đảm bảo
rằng nó hoạt động như dự đoán. Các thành phần ổn định hơn sẽ chỉ đơn
giản là yêu cầu một xác nhận rằng mọi thứ vẫn đang hoạt động như
mong đợi.
Một số quy trình có một yêu cầu về việc báo cáo và giao tiếp thường
xuyên. Ví dụ: Quản lý Sự cố có thể đòi hỏi cập nhật năm phút một lần
đối với sự cố có tác động lớn. Các quy trình khác không cần phải giao
tiếp ở mức thường xuyên như vậy. Ví dụ, Hoạch định Công suất cần
thông báo những thay đổi trên cơ sở hàng tháng hoặc thậm chí hàng
quý.
Người có vai - Những nhân viên đang quản lý các Đơn vị Cấu hình then chốt,
trò - Những nhân viên đang thực thi các quy trình,
- Các chủ sở hữu quy trình và các nhà quản lý kỹ thuật,
- Sự leo thang tiềm ẩn cho các nhà quản lý cấp cao hơn, Nhà quản lý
Dịch vụ.
Nội dung - Sự so sánh giữa hiệu suất cần thiết và hiệu suất thực tế,
- Những khuynh hướng của hiệu suất theo thời gian,
- Các báo cáo cụ thể về các đích nhắm mục tiêu bị bỏ lỡ hoặc các
mức hiệu suất không mong muốn.
Bối - Các Nhật ký Sự kiện,

cảnh/Nguồn - Các Hồ sơ Hiệu suất Hệ thống,
- Các Báo cáo Hiệu suất Quy trình,
- Các Hồ sơ Vấn đề và Sự cố,
- Các Báo cáo Ngoại lệ và Báo cáo Kiểm toán,
- Các cuộc đánh giá cùng với nhà thầu,
- Báo cáo Dịch vụ có thể chỉ ra một vấn đề cùng với một hoặc nhiều
lĩnh vực công nghệ hoặc quy trình.
Bảng B.5 – Các yêu cầu Báo cáo Dịch vụ: cơ sở hạ tầng hay quy
trình
B4 Truyền thông trong các dự án
Nhân viên Vận hành Dịch vụ thường tham gia vào các dự án. Điều
này có thể là để cung cấp đầu vào cho một thiết kế mới, hoặc để hỗ
trợ cho việc xác minh việc sử dụng hoặc tỷ lệ thông lượng, hoặc để
hỗ trợ việc thực hiện các thử nghiệm đối với các dịch vụ mới hoặc
đã được thay đổi. Trong các trường hợp khác, các dự án có thể ảnh
hưởng đến các OLA hiện có và phản hồi của họ sẽ là cần thiết. Cần
phải công nhận rằng sự tham gia này sẽ làm tăng thêm mức độ giao
tiếp mà những cá nhân này sẽ nhận và truyền đi. Điều này sẽ đòi
hỏi thêm thời gian và sự tập trung bổ sung, vốn nên được cho phép
bởi các nhà quản lý phân công các nguồn lực cho các dự án trên cơ
sở bán thời gian.
Mục đích Dự án giao tiếp vì nhiều mục đích, bao gồm:
- Để nhận được sự hỗ trợ từ các bên liên quan của dự án – giao

tiếp này sẽ tập trung vào phạm vi, chi phí và lợi ích của dự án và
sẽ tìm cách chứng minh lợi tức tổng thể từ khoản đầu tư của dự
án,
- Để đảm bảo rằng tất cả các thành viên của nhóm dự án hiểu và
được liên kết với các mục tiêu của dự án,
- Để phân công công việc cho các cá nhân hoặc nhóm,
- Để lên lịch trình cho các hoạt động và đảm bảo rằng các nguồn
lực đã sẵn sàng để bắt đầu giai đoạn của họ trong dự án,
- Để kiểm tra và báo cáo tiến độ của dự án,
- Để phát hiện và leo thang các ngoại lệ hoặc sự chậm trễ tiềm ẩn
trong dự án,
- Để chuẩn bị cho khách hàng và đối tượng của dự án về việc triển
khai giải pháp đang được xây dựng.
Tần suất Tần suất, những người có vai trò và nội dung của giao tiếp này sẽ phụ
thuộc vào bản chất của dự án và kiểu phương pháp Quản lý Dự án đang
được sử dụng.
Bảng B.6 – Giao tiếp trong các dự án
Truyền thông dự án chính thức có khuynh hướng tuân theo chu kỳ

của các cuộc họp dự án. Ví dụ:
 Các cuộc họp dự án hàng tuần hoặc hàng tháng sẽ được tổ

chức với Giám đốc Dự án và các trưởng nhóm riêng lẻ,
 Một cập nhật trạng thái hàng tháng sẽ được gửi đến Nhà bảo
trợ Điều hành của dự án và có thể là các bên liên quan chính
yếu khác,
 Các trường hợp ngoại lệ và kết quả của việc kiểm tra đảm bảo
chất lượng được báo cáo cho các nhóm Đảm bảo Dự án, những
người này sẽ thông báo nhu cầu hành động khắc phục khi cần
thiết.
Trong mỗi nhóm, giao tiếp sẽ tập trung hơn vào việc hoàn thành
nhiệm vụ của họ và nhìn chung sẽ thường xuyên hơn so với giao tiếp
quy mô toàn dự án.
Có khả năng cao sẽ có mức độ giao tiếp ít chính thức hơn trong mỗi
nhóm và giữa các nhóm để đảm bảo rằng các nhiệm vụ được hoàn
thành đúng thời hạn và các nguồn lực đã được cam kết sẵn sàng khi
nào và ở đâu. Giao tiếp rộng rãi cũng được yêu cầu như một phần
của quá trình bàn giao từ nhóm này sang nhóm khác khi dự án
chuyển từ giai đoạn này sang giai đoạn khác. Một quy tắc ngón tay
cái quan trọng là ghi lại bất kỳ thông tin liên lạc nào có thể ảnh
hưởng đến kết quả hoặc chi phí của dự án.
Người có vai - Giám đốc Dự án và nhân viên quản lý và điều phối dự án,
trò - Nhà Bảo trợ Dự án,
- Các Bên liên quan Chính của Dự án (ví dụ, khách hàng, các Nhà
quản lý CNTT, thành viên Hội đồng quản trị, người dùng, v.v…),
- Các nhóm dự án và những người đóng góp riêng lẻ,
- Nhân viên kinh doanh và kỹ thuật của nhà thầu khi việc mua các
dịch vụ hoặc giải pháp là một phần của dự án.
Nội dung - Thu thập các yêu cầu cho giải pháp đang được xây dựng bởi dự án
- Lập lịch trình dự án,
- Thông tin ‘Tiếp thị’ của Dự án bao gồm thông tin về Lợi nhuận trên
Khoản đầu tư hoặc Đề án Kinh doanh,
- Cập nhật trạng thái,
- Thu thập thông tin để hoàn thành một nhiệm vụ,
- Các sự kiện có thể ảnh hưởng đến phạm vi, chi phí hoặc thời gian
hoàn thành dự án,
- Báo cáo tiến độ trong các nhóm hoặc giữa các nhóm,
- Thông tin về kết quả kiểm nghiệm,
- Thông báo cho các nhóm hoặc cá nhân rằng dự án đang tiến đến
hoặc giai đoạn hoặc hoạt động ‘của họ’ và họ nên thực hiện các
bước chuẩn bị thích hợp,
- Báo cáo về việc hoàn thành thành công các hoạt động,
- Đánh giá về thành công tổng thể của dự án.
Bối - Điều lệ Dự án,

cảnh/Nguồn - Ngân sách Dự án,
- Tuyên bố về các yêu cầu,
- Lịch trình Dự án,
- Các cuộc họp Dự án,
- Các cuộc họp nhóm,
- Các báo cáo trạng thái và báo cáo tiến độ,
- Các báo cáo kiểm nghiệm,
- Các tài liệu ký kết với khách hàng,
- Các đánh giá Sau-Triển khai.
Bảng B.7 – Thông tin bàn giao dự án
B5 Truyền thông có liên quan đ ến những thay đổi
Quản lý Thay đổi được đề cập chi tiết trong ấn phẩm Chuyển tiếp
Dịch vụ ITIL và bao gồm những thông tin về truyền thông về những
thay đổi. Tuy nhiên, cần phải nhấn mạnh bản chất của giao tiếp
mang tính vận hành về những thay đổi.
Mục đích Để hỗ trợ cho quy trình Quản lý Thay đổi bằng cách:
- Đánh giá tác động tiềm ẩn của và những nguồn lực cần thiết đối
với thay đổi,
- Đảm bảo rằng mỗi nhóm nhận thức được về bản chất và lịch trình
của những thay đổi đã được chỉ định cho họ,
- Xây dựng, kiểm nghiệm và triển khai những thay đổi trong môi
trường của họ,
- Đảm bảo rằng mỗi nhóm báo cáo về tiến trình của từng thay đổi,
- Thông báo cho [quy trình] Quản lý Thay đổi rằng một thay đổi đã
sẵn sàng cho việc triển khai,
- Đảo ngược những thay đổi đã không thành công và truyền đạt
những kết quả cho Quản lý Thay đổi.
Tần suất Tần suất của giao tiếp liên quan đến những thay đổi được xác định bởi
bản chất của thay đổi và thời điểm được đưa ra trong Lịch trình Thay
đổi.
Hầu hết các nhóm hoặc bộ phận sẽ xem xét những thay đổi trên cơ sở
hàng ngày hoặc hàng tuần. Mỗi ngày, họ sẽ thảo luận và thiết lập ưu
tiên cho những thay đổi mới được chỉ định cho họ và báo cáo về tiến
trình của những thay đổi mà họ đang thực hiện. Sau mỗi thay đổi, họ
sẽ báo cáo về sự thành công của mỗi thay đổi và đảm bảo rằng bất kỳ
hành động khắc phục cần thiết nào được khởi đầu.
Người có vai - Nhà quản lý Thay đổi, quản trị viên và điều phối viên,
trò - Các Trưởng nhóm, Trưởng Bộ phận, Trưởng ca hoặc Giám đốc Dự
án,
- Nhân viên Vận hành Dịch vụ tham gia vào việc xây dựng, kiểm
nghiệm và triển khai những thay đổi (thường là các nhóm hoặc bộ
phận Quản lý Vận hành CNTT, Quản lý Ứng dụng Quản lý Kỹ thuật),
- Các nhà quản lý của Môi trường Kiểm nghiệm và các nhóm,
- Các nhóm Triển khai Phát hành hoặc Triển khai Thay đổi.
Nội dung - Yêu cầu và cấp phép thay đổi,

- Báo cáo về tính khả thi của một thay đổi,
- Báo cáo về các nguồn lực cần thiết để xây dựng, kiểm nghiệm hoặc
triển khai một thay đổi,
- Lập lịch trình Hoạt động Thay đổi,
- Mô tả chi tiết về sự thay đổi và các hoạt động cần thiết của từng
nhóm hoặc bộ phận,
- Tiến độ và báo cáo trạng thái của hoạt động thay đổi,
- Kết quả kiểm nghiệm,
- Báo cáo Ngoại lệ, bao gồm chi tiết về việc thực hiện các Kế hoạch
Dự phòng.
Bối - Các RFC,

cảnh/Nguồn - Giao tiếp về Kiểm soát Thay đổi (trong các cuộc họp vận hành hàng
ngày hoặc hàng tuần, hoặc qua email, các cuộc gọi hội nghị, hoặc
sử dụng các công cụ Quản lý Thay đổi),
- Các cuộc họp Hội đồng Tư vấn Thay đổi,
- Các Kế hoạch Phát hành,
- Các báo cáo về Tính sẵn sàng Dịch vụ đã Dự báo,
- Các cuộc Đánh giá Thay đổi.
Bảng B.8 – Truyền thông về những thay đổi
B6 Truyền thông có liên quan đ ến các ngoại lệ
Trong ngữ cảnh này, một ngoại lệ đề cập đến bất kỳ sự kiện nào
nằm ngoài hoạt động hoặc hiệu suất bình thường hoặc đã được dự
kiến. Hình thức ngoại lệ phổ biến nhất là Sự cố (được đề cập chi tiết
trong phần 4.2 của ấn phẩm này). Có những ngoại lệ khác không
nhất thiết phải thông qua Quản lý Sự cố, chẳng hạn như một ngoại
lệ quy trình (sẽ được xử lý trong bối cảnh của quy trình đó hoặc bởi
một quy trình Đảm bảo Chất lượng); một nhóm, bộ phận hoặc cá
nhân có hiệu suất không đạt tiêu chuẩn (sẽ bị xử lý theo quy trình
kỷ luật Nhân sự); hoặc một ngoại lệ đối với việc thực hiện hợp đồng
của nhà cung cấp. Mặc dù tất cả những điều này không liên quan
trực tiếp đến Quản lý Dịch vụ, nhưng chúng sẽ bổ sung chi phí quản
lý vào mức độ giao tiếp cần thiết của nhân viên trong giai đoạn Vận
hành Dịch vụ.
Mục đích Giao tiếp trong quá trình hoặc sau các ngoại lệ là nhằm mục đích
- Thông báo cho những cá nhân thích hợp về ngoại lệ,

- Đánh giá tầm quan trọng, mức độ nghiêm trọng và tác động của
ngoại lệ,
- Đảm bảo rằng nguồn lực với những kỹ năng và thâm niên thích hợp
được tham gia vào việc giải quyết ngoại lệ và thực hiện hành động
để ngăn ngừa sự tái diễn trong tương lai,
- Cung cấp thông tin cập nhật cho các bên liên quan bị ảnh hưởng
bởi ngoại lệ.
Tần suất Loại giao tiếp này mang tính ứng phó và không được dự tính trước (bất
ngờ), theo đó, nó sẽ không xảy ra trừ khi có một ngoại lệ được xác
định hoặc có nguy cơ xảy ra một ngoại lệ. Do đó, tần suất sẽ tỷ lệ
thuận với tần suất của các trường hợp ngoại lệ.
Khi một ngoại lệ được phát hiện, tần suất và nội dung giao tiếp sẽ được
xác định bởi tác động, mức độ khẩn cấp và mức độ nghiêm trọng của
ngoại lệ.
Người có vai Những người có vai trò chính xác sẽ phụ thuộc vào kiểu và mức độ của
trò ngoại lệ, nhưng có thể bao gồm:
- Quản lý Sự cố,
- Bộ phận Hỗ trợ Dịch vụ,
- Quản lý Vấn đề,
- Chủ sở hữu quy trình (nếu ngoại lệ có liên quan đến hiệu suất quy
trình),
- Các nhà quản lý của bộ phận hoặc các trưởng nhóm,
- SLM,
- Quản lý Nguồn nhân lực,
- Các Nhà Quản lý và chuyên gia Công nghệ,
- Nhân viên kinh doanh của nhà thầu,
- Chuyên gia kỹ thuật của nhà thầu.
Nội dung - Mô tả và đánh giá về ngoại lệ,

- Đánh giá tác động. Điều này thường liên quan đến việc trao đổi
thông tin với các bên liên quan, những người bị ảnh hưởng bởi
ngoại lệ,
- Ước tính và sau đó xác nhận chi phí giải quyết,
- Một quyết định về hành động sẽ được thực hiện,
- Thông báo về quyết định được thực hiện. Điều này có thể có một số
hình thức. Ví dụ: thông tin liên lạc với khách hàng có khả năng bao
gồm một lời xin lỗi và cái nhìn tổng quan cấp cao về những gì đang
được thực hiện để giải quyết ngoại lệ. Thông báo cho những người
được mong đợi để giải quyết ngoại lệ sẽ chi tiết hơn và sẽ bao gồm
các hành động và lịch trình rõ ràng,
- Xác nhận rằng ngoại lệ đã được giải quyết.
Bối - Đánh giá Quy trình,
cảnh/Nguồn - Đánh giá Thay đổi,
- Đánh giá Mức Dịch vụ,
- Các Sự kiện,
- Phân tích Xu hướng của các quy trình, thiết bị, hiệu suất nhóm,
v.v…
- Các Hồ sơ Sự cố, Hồ sơ Vấn đề và Hồ sơ Thay đổi,
- Các khảo sát về mức độ hài lòng của khách hàng.
Bảng B.9 – Truyền thông trong các ngoại lệ
B7 Truyền thông có liên quan đ ến các tình huống khẩn
cấp
Mặc dù ITIL chỉ định cách xử lý các tình huống khẩn cấp và có tác
động lớn như thiên tai (Quản lý Liên tục Dịch vụ CNTT) và Các sự cố
Nghiêm trọng (Quản lý Sự cố), các nhà quản lý trong giai đoạn Vận
hành Dịch vụ sẽ nhận thấy mình phải đối phó với nhiều loại và quy
mô khẩn cấp khác nhau đã không được đề cập đến trong các quy
trình này. Điều quan trọng cần lưu ý là đây không phải là một quá
trình riêng biệt, mà thay vào đó, nó là quan điểm của một số quá
trình và tình huống nhìn từ góc độ giao tiếp.
Truyền thông trong trường hợp khẩn cấp có mục đích và nội dung
tương tự như giao tiếp trong trường hợp ngoại lệ. Sự khác biệt chính
là về mức độ khẩn cấp và tác động của ngoại lệ.
Truyền thông trong trường hợp khẩn cấp thường do Nhà quản lý Sự
cố bắt đầu (xem đoạn 4.2.5 để thảo luận về Các sự cố Nghiêm
trọng) hoặc bởi Nhà quản lý CNTT cấp cao, người đã được chỉ định
làm đầu mối leo thang cho tất cả các trường hợp khẩn cấp như vậy.
Trong trường hợp Kế hoạch Liên tục Dịch vụ CNTT được viện dẫn, kế
hoạch này sẽ bao gồm Kế hoạch Truyền thông chi tiết sẽ được thực
thi bởi cơ quan có thẩm quyền thích hợp.
Nhà quản lý Sự cố hoặc một nhà quản lý được chỉ định thường sẽ
thành lập một nhóm ứng phó và việc liên lạc được khởi xướng và
điều phối bởi nhóm này.
Mục đích Mục đích của truyền thông trong trường hợp khẩn cấp là ngay lập tức
điều tra và xác nhận tác động và mức độ nghiêm trọng của Sự cố để
xác nhận rằng đó thực sự là một tình huống khẩn cấp. Nó cũng phải xác
nhận rằng Sự cố này không đại diện cho một thảm họa hoặc bất kỳ
trường hợp nào được đề cập trong các Kế hoạch Liên tục Dịch vụ CNTT.
Ngay sau khi phạm vi của trường hợp khẩn cấp đã được xác định, nhóm
chịu trách nhiệm cho việc quản lý tình huống sẽ phân bổ nguồn lực để
tạo ra kế hoạch hành động và bắt đầu giải quyết tình huống khẩn cấp
và khôi phục dịch vụ.
Tần suất Loại giao tiếp này không xảy ra trừ khi có một Sự cố Nghiêm trọng hoặc
một tình huống khẩn cấp.
Khi một ngoại lệ đã được phát hiện, tần suất và nội dung của giao tiếp
sẽ được xác định bởi tác động và mức độ nghiêm trọng của ngoại lệ, và
có khả năng bởi một Kế hoạch Khôi phụ Dịch vụ.
Người có vai - Nhà quản lý Sự cố,

trò - Các Nhà quản lý Cấp cao hoặc các nhóm chịu trách nhiệm đối với
nhân viên CNTT sẽ được yêu cầu để giải quyết tình huống,
- Các nhà quản lý doanh nghiệp và các Giám đốc điều hành (có khả
năng bao gồm nhân viên pháp lý nếu tổ chức có khả năng bị khởi
kiện do hậu quả của sự cố),
- Khách hàng và người dùng,
- Nhà quản lý Liên tục Dịch vụ CNTT và nhóm Điều phối Trung tâm,
- Nhân viên và các nhà quản lý cấp cao của nhà thầu (tùy thuộc vào
mức độ và bản chất của tình huống,
- Nhân viên và các nhà quản lý Quản lý Kỹ thuật,
- Nhân viên và các nhà quản lý Quản lý Ứng dụng,
- Nhân viên và các nhà quản lý Quản lý Vận hành CNTT.
Nội dung - Bản chất và mức độ của tình trạng khẩn cấp,
- Đánh giá tác động. Điều này thường liên quan đến việc trao đổi
thông tin với các bên liên quan bị ảnh hưởng bởi ngoại lệ,
- Ước tính và sau đó xác nhận chi phí giải quyết,
- Một quyết định về hành động sẽ được thực hiện,
- Thông báo về quyết định được thực hiện. Điều này có thể dưới một
số hình thức. Ví dụ: thông tin liên lạc với khách hàng có khả năng
bao gồm một lời xin lỗi và một cái nhìn tổng quan cấp cao về
những gì đang được thực hiện để giải quyết ngoại lệ. Thông báo
cho những người được mong đợi để giải quyết ngoại lệ sẽ chi tiết
hơn và sẽ bao gồm các hành động và lịch trình rõ ràng,
- Xác nhận rằng ngoại lệ đã được giải quyết.
Bối - Hồ sơ Sự cố đối với các Sự cố Nghiêm trọng,

cảnh/Nguồn - Các Sự kiện,
- Các cuộc họp về khủng hoảng hoặc tình huống khẩn cấp được triệu
tập bởi Nhà quản lý Sự cố, nhà quản lý được chỉ định, hoặc Nhà
quản lý Liên tục Dịch vụ CNTT.
Bảng B.10 – Truyền thông trong những tình huống khẩn cấp
B8 Truyền thông với người dùng và khách hàng
Phần này xuất hiện sau cùng, không phải vì nó ít quan trọng nhất,
mà bởi vì nó kết hợp một số lĩnh vực đã thảo luận ở trên. Một
nguyên tắc quan trọng trong giao tiếp với khách hàng là giao tiếp
không nên chỉ tập trung vào các khía cạnh nội bộ của Vận hành Dịch
vụ. Trọng tâm là yêu cầu của khách hàng hoặc người dùng và CNTT
đang làm gì để đáp ứng yêu cầu đó. Điều này không liên quan đến
các mô tả kỹ thuật và thông tin chi tiết về các quy trình nội bộ.
Mục đích Có một số nguyên nhân cho việc giao tiếp với khách hàng và người
dùng trong Vận hành Dịch vụ. Chúng bao gồm:
- Đảm bảo rằng các dịch vụ đã được cung cấp như thỏa thuận,
- Truyền thông xoay quanh việc thực hiện các Yêu cầu Dịch vụ,
- Báo cáo về các Sự cố và giữ cho người dùng và khách hàng được
cập nhật về trạng thái của chúng (các sự cố) đến khi chúng được
giải quyết,
- Thông báo cho người dùng và khách hàng về những thay đổi có thể
ảnh hưởng đến họ,
- Cung cấp quyền truy cập đến các dịch vụ,
- Xử lý các vấn đề bảo mật tiềm ẩn,
- Lập lịch trình các hoạt động liên quan đến người dùng và khách
hàng, ví dụ, bảo trì,
- Thông báo về các sự kiện kinh doanh đặc biệt đòi hỏi thêm sự hỗ
trợ hoặc thay đổi mức độ ưu tiên,
- Đánh giá mức độ hài lòng của người dùng và khách hàng,
- Điều phối trong những tình huống dự phòng.
Tần suất Giao tiếp với người dùng và khách hàng là liên tục tiếp diễn. Hình thức
và nội dung giao tiếp sẽ được xác định bởi các quy trình đang được
thực thi. Ví dụ, truyền thông về một Sự cố sẽ được xác định bởi quy
trình Quản lý Sự cố.
Một số giao tiếp sẽ chính thức và theo lịch trình, ví dụ: cung cấp các
báo cáo về hiệu suất của một dịch vụ trong cuộc họp đánh giá. Các giao
tiếp khác sẽ là chính thức, nhưng không dự tính trước, ví dụ: thông báo
về tình trạng của một sự cố.
Người có vai Danh tính của những người đóng vai trò và số lượng của họ sẽ phụ
trò thuộc vào việc quy trình nào đang được thực thi, loại tình huống đã xảy
ra và phạm vi của những gì đang được truyền đạt, ví dụ: cung cấp
thông tin cập nhật về trạng thái của Yêu cầu Dịch vụ sẽ có đối tượng
rất khác so với khi tham gia vào cuộc họp Đánh giá Mức Dịch vụ.
Nội dung Nội dung của giao tiếp này sẽ thay đổi tùy theo ngữ cảnh. Tuy nhiên,
điều quan trọng là phải truyền tải được thông tin đến khán giả. Điều
này có nghĩa là sử dụng tên gọi của dịch vụ chứ không phải tên của
máy chủ hoặc ứng dụng, mang tính chuyên nghiệp, tránh dùng biệt ngữ
kỹ thuật, không được trịch thượng và đối xử với khách hàng và người
dùng một cách tôn trọng.
Bối Bối cảnh của giao tiếp này là việc thực hiện các hoạt động vận hành
cảnh/Nguồn hàng ngày và cung cấp và hỗ trợ cho các dịch vụ. Nhóm Vận hành Dịch
vụ không được giao tiếp với khách hàng hoặc người dùng về các vấn đề
lập kế hoạch, chiến lược, thiết kế hoặc kiểm nghiệm - trừ khi họ được
bổ nhiệm cho nhóm dự án đang xử lý một trong những lĩnh vực này.
Bảng B.11 – Truyền thông với người dùng và khách hàng
Phụ lụ c C: Kepne r và Tregoe
Charles Kepner và Benjamin Tregoe đã phát tri ển một mô hình hữu

ích để phân tích các vấn đề. Trong phụ lục này, phương pháp của họ
được trình bày như một ví dụ về một phương pháp Phân tích Vấn đề.
Kepner và Tregoe cho rằng Phân tích Vấn đề nên là một quy trình có
hệ thống về việc giải quyết vấn đề và nên tận dụng tối đa những ưu
điểm của kiến thức và kinh nghiệm. Họ phân biệt 5 giai đoạn dưới
đây đối với Phân tích Vấn đề (được mô tả thêm dưới đây):
 Xác định vấn đề,

 Mô tả vấn đề liên quan đến danh tính, địa điểm, thời gian và
quy mô,
 Xác lập các nguyên nhân khả dĩ,
 Kiểm nghiệm nguyên nhân khả dĩ nhất,
 Xác minh nguyên nhân thực sự.
Tùy thuộc vào thời gian và thông tin sẵn có, các giai đoạn này có
thể được thực hiện ở mức độ lớn hơn hoặc nhỏ hơn. Ngay cả trong
những tình huống chỉ có một lượng thông tin hạn chế hoặc áp lực
lướn về thời gian, thì việc áp dụng phương pháp tiếp cận có cấu trúc
đối với Phân tích Vấn đề để cải thiện cơ hội thành công là rất đáng
giá.
C1 Xác định vấn đề
Bởi vì cuộc điều tra dựa trên định nghĩa về vấn đề, nên định nghĩa
này phải chỉ ra chính xác (các) sai lệch nào so với các mức dịch vụ
đã thỏa thuận đã xảy ra.
Thông thường, trong quá trình xác định vấn đề, nguyên nhân có thể
gây ra vấn đề khả dĩ nhất được chỉ ra. Hãy chú ý để đừng vội vàng
đi đến kết luận, vốn điều này có thể khiến cho cuộc điều tra đi sai
hướng ngay từ đầu.
Trong thực tế, xác định vấn đề thường là một nhiệm vụ khó khăn do
Cơ sở hạ tầng CNTT phức tạp và các thỏa thuận không minh bạch về
các mức dịch vụ.
C2 Mô tả vấn đề
Các khía cạnh sau đây được sử dụng để mô tả vấn đề, tức là vấn đề
là GÌ (IS):
 Nhân dạng. Bộ phận nào hoạt động không tốt? Vấn đề là gì?
 Vị trí. Vấn đề xảy ra ở đâu?
 Thời gian. Sự cố bắt đầu xảy ra khi nào? Sự cố đã xảy ra
thường xuyên như thế nào?
 Quy mô. Quy mô của vấn đề là gì? Có bao nhiêu bộ phận bị
ảnh hưởng?
Tình huống ‘IS’ được xác định bởi câu trả lời cho những câu hỏi này.
Bước tiếp theo là điều tra xem các bộ phận tương tự nào trong một
môi trường tương tự đang hoạt động một cách bình thường. Với điều
này, một câu trả lời được đưa ra cho câu hỏi 'Điều gì CÓ THỂ nhưng
KHÔNG PHẢI? [What COULD BE but NOT]?' (Những phần nào có thể
hiển thị cùng một vấn đề nhưng không [cho thấy vấn đề]?).
Sau đó, có thể tìm kiếm một cách hiệu quả những khác biệt có liên
quan trong cả hai tình huống. Hơn nữa, những thay đổi trong quá
khứ, có thể là nguyên nhân của những khác biệt này, có thể được
xác định.
C3 Xác lập các nguyên nhân khả dĩ
Danh sách những khác biệt và những thay đổi được đề cập ở trên có
khả năng nắm giữ nguyên nhân của vấn đề do đó, nguyên nhân khả
dĩ có thể được trích xuất từ danh sách này.
C4 Kiểm nghiệm nguyên nhân khả dĩ nhất
Từng nguyên nhân khả dĩ cần phải được đánh giá để xác định xem
liệu nó có thể là nguyên nhân của mọi triệu chứng của vấn đề hay
không.
C5 Xác minh nguyên nhân thực sự
Các nguyên nhân còn lại khả dĩ phải được xác minh là nguồn gốc của
vấn đề. Điều này chỉ có thể được thực hiện bằng cách chứng minh
điều này theo cách này hay cách khác - ví dụ bằng cách triển khai
một thay đổi hoặc thay thế một bộ phận. Hãy giải quyết các nguyên
nhân khả dĩ có thể được xác minh một cách nhanh chóng và đơn
giản trước tiên.
Phụ lụ c D: S ơ đ ồ I shikawa
Sơ đồ Ishikawa, hay còn được gọi là Sơ đồ Xương cá, Sơ đồ Nhân-

Quả hoặc Sơ đồ Cây, là một công cụ được sử dụng để xác định và
trình bày một cách có hệ thống mọi nguyên nhân khả dĩ của một vấn
đề cụ thể trên biểu đồ. Kỹ thuật này được đặt tên theo người đã
phát triển nó, Kaoru Ishikawa (1915 – 1989), người đi đầu trong lĩnh
vực kiểm soát chất lượng của Nhật Bản. Một ví dụ được trình bày
dưới đây.
Mục tiêu chính được thể hiện bằng trục xương sống hoặc thân của sơ
đồ và các yếu tố chính được biểu diễn dưới dạng các nhánh. Các yếu
tố thứ cấp sau đó được thêm vào dưới dạng thân cây, v.v… Việc tạo
ra sơ đồ kích thích sự thảo luận và thường dẫn đến việc tăng cường
hiểu biết về một vấn đề phức tạp. Những sơ đồ này được sử dụng
một cách rộng rãi trong việc xác định các giải pháp cho các vấn đề
mang tính hệ thống, chẳng hạn như xác định nguyên nhân của việc
giảm năng suất trên dây chuyền lắp ráp hoặc mức độ hài lòng của
khách hàng thấp hơn trong một tổ chức dịch vụ.
Kỹ thuật cơ bản để phát triển các sơ đồ này, cùng với một ví dụ rất
đơn giản, được hiển thị ở đây. Một nhóm giải quyết vấn đề sẽ sử
dụng Sơ đồ Ishikawa như sau:
1) Chuẩn bị một sơ đồ trống dưới định dạng mà cả nhóm có thể

xem được. Đây có thể là bảng lật, bảng, được chiếu qua máy
chiếu dữ liệu từ PC, v.v…
2) Xác định vấn đề mà nhóm đang cố gắng giải quyết bằng các
thuật ngữ rõ ràng và cụ thể và viết nó vào ô ở ô ‘đầu cá’ của
sơ đồ.
3) Viết các loại nguyên nhân vào các đầu mút của ‘xương cá’. Đây
phải là những danh mục khá rộng vì nguyên nhân chính xác v ẫn
chưa được biết đến. Một ví dụ được hiển thị trong Hình D.1,
trong đó nhóm đang cố gắng tìm ra nguyên nhân cho các m ức
không thể chấp nhận được của thời gian ngừng hoạt động của
mạng.
Hình D.1 – Ví dụ mẫu về khởi đầu của một Sơ đồ Ishikawa
4) Sử dụng kỹ thuật động não để những người tham gia [động

não] đề xuất những nguyên nhân khả dĩ, và ghi chú những
nguyên nhân đó trên các nhánh có liên quan c ủa sơ đồ. Một sơ
đồ đơn giản đã được hoàn chỉnh trong Hình D.2.
Hình D.2 - Ví dụ mẫu về một Sơ đồ Ishikawa đã hoàn tất
5) Diễn giải sơ đồ. Việc này có thể được hoàn thành bằng cách
xếp hạng các nguyên nhân hàng đầu dựa trên kinh nghiệm và
dữ liệu sẵn có. Khi các nguyên nhân hàng đầu đã được lựa
chọn, từng nguyên nhân sẽ được điều tra thêm tương ứng với
thứ hạng và độ ưu tiên của nó.
Phụ lụ c E: Mô t ả chi ti ết v ề Q u ả n lý C ơ s ở vậ t ch ất
Mục đích của phụ lục này không phải là để cung cấp một giải thích
chi tiết về mọi khía cạnh của Quản lý Cơ sở vật chất. Thay vào đó,
nó sẽ nêu bật những hoạt động quan trọng nhất để hỗ trợ cho việc
định vị một số trong số các chức năng khác và trong việc xác định
nơi mà các quy trình cụ thể tác động đến việc Quản lý Cơ sở vật
chất tốt và ngược lại.
Quản lý Cơ sở vật chất sẽ cung cấp thông tin về Quản lý Cấu hình có
liên quan đến vị trí và tình trạng của các Đơn vị Cấu hình, đồng thời
cũng sẽ trở thành một phần không thể thiếu của Quản lý Thay đổi,
Hoạch định Công suất, Hoạch định Tính sẵn sàng và Quản lý Liên tục
Dịch vụ.
Những thành phần chính của Quản lý Cơ sở vật chất bao gồm dưới
đây.
E1 Quản lý Tòa nhà
Mặc dù nhiều hoạt động Quản lý Tòa nhà được thuê ngoài hoặc ký
hợp đồng với các nhà cung cấp khác nhưng chúng vẫn thuộc trách
nhiệm của Quản lý Cơ sở vật chất. Các hoạt động tiêu biểu bao gồm:
 Vệ sinh. Điều này có thể được thực hiện bởi nhân viên hoặc
bởi bên thứ ba. Điều rất quan trọng ở đây là đảm bảo rằng
nhân viên vệ sinh tuân thủ tất cả các chính sách kiểm soát truy
cập và bảo mật.
 Xử lý chất thải, bao gồm việc phân loại các vật phẩm để tái
chế, các vật phẩm nguy hiểm (ví dụ như pin, chất lỏng và khí
như chất làm lạnh cho các thiết bị điều hòa không khí), tài liệu
mật.
 Lắp đặt các cơ sở vật chất, chẳng hạn như hệ thống cáp,
nguồn điện, sàn nâng, hệ thống ra vào an toàn, văn phòng, n ội
thất, v.v…
 Bãi đậu xe. Điều này nên bao gồm việc phân bổ chỗ đậu xe
cho nhân viên và nhà thầu, chỗ đậu xe cho khách và chỗ đậu
xe cho nhân viên hoặc du khách bị khuyết tật. Quản lý Cơ sở
vật chất cũng sẽ bao gồm việc lập hồ sơ và thực thi bất kỳ
chính sách nào về việc ai nên đậu xe ở đâu.
 Kiểm soát Truy cập và Giám sát An ninh. Điều này được
trình bày chi tiết hơn trong phần E6 dưới đây và cả trong Phụ
lục F.
 Biển báo, nghĩa là đảm bảo rằng tòa nhà có thể được tìm thấy
nhưng rõ ràng không phải là vị trí trọng yếu đáng bị tấn công.
E2 Lưu trữ Thiết bị
Cơ sở vật chất không chỉ được quản lý đơn giản vì chúng tồn tại và
thuộc về sở hữu của một tổ chức. Chúng [cơ sở vật chất] được quản
lý để con người và thiết bị mà chúng chứa có thể được sử dụng cho
các mục đích cụ thể. Trong trường hợp Cơ sở vật chất CNTT, chẳng
hạn như Trung tâm Dữ liệu, điều này bổ sung một số nhu cầu rất cụ
thể cho người quản lý của cơ sở đó.
Một trong số này là dịch vụ lưu trữ thiết bị CNTT. Đây không chỉ là
trường hợp cung cấp phòng ốc và cho phép các nhóm Quản lý Kỹ
thuật lắp đặt và quản lý thiết bị. Các loại thiết bị khác nhau có các
yêu cầu rất cụ thể của cơ sở vật chất mà nó được lắp đặt, ví dụ:
 Thiết bị làm mát bằng nước cần phải được tiếp cận với nước
mát - nước phải được cung cấp bởi cơ sở vật chất,
 Trọng lượng của thiết bị khác nhau và phải được phân bố để
không tạo áp lực quá lớn lên sàn,
 Nguồn cung cấp điện có thể khác nhau đối với các loại thiết bị
khác nhau.
Nếu thiết bị chỉ đơn giản được đặt trong Trung tâm Dữ liệu theo thứ
tự mà theo đó nó được nhận, sẽ rất khó tìm thấy bất cứ thứ gì và
nhân viên có thể phải qua lại rất nhiều lần để tìm kiếm thiết bị
tương tự. Lưu lượng truy cập này gây nguy hiểm cho tính toàn vẹn
và bảo mật của các thiết bị khác đang có trên sàn.
Điều này có nghĩa là Quản lý Cơ sở vật chất phải chịu trách nhiệm
lập kế hoạch và thiết kế bố trí của Trung tâm Dữ liệu để có quyền
truy cập và bảo mật tối ưu đối với các thiết bị sẽ được lưu trữ tại
đó. Đồng thời, cần phải nhớ rằng thiết bị này đang được sử dụng để
cung cấp các dịch vụ CNTT và bất kỳ yêu cầu nào đối với dịch vụ đó
cũng cần phải được tính đến khi lưu trữ thiết bị. Ví dụ: các tiêu
chuẩn của Trung tâm Dữ liệu có thể phải được thay đổi để phù hợp
với một máy chủ không theo tiêu chuẩn.
Ngoài ra, hầu hết các Trung tâm Dữ liệu cũng cung cấp các hoạt
động lưu trữ sau:
 Nhận thiết bị mới,

 Giải nén, thiết lập cấu hình và cài đặt thiết bị tiêu chuẩn,
 Tạo ra và duy trì sơ đồ bố trí Trung tâm dữ liệu,
 Quản lý lịch trình của bất kỳ hoạt động bảo trì nào đối với
thiết bị được lưu trữ trong Trung tâm Dữ liệu,
 Loại bỏ thiết bị đã ngừng hoạt động.
Từ danh sách các hoạt động này, một điều rõ ràng rằng Quản lý Cơ
sở vật chất không nên được xem như một chức năng riêng biệt, mà
là một phần rất quan trọng trong hoạt động tổng thể của CNTT
trong tổ chức.
E3 Quản lý Nguồn điện
Quản lý Nguồn điện đề cập đến việc quản lý việc tìm nguồn cung
ứng và sử dụng các nguồn điện được sử dụng để duy trì hoạt động
của cơ sở vật chất. Định nghĩa này về Quản lý Nguồn điện có một số
hàm ý, như được thảo luận dưới đây.
Nhiệm vụ đầu tiên của Quản lý Cơ sở vật chất trong việc quản lý
nguồn điện là xác định các yêu cầu về nguồn điện cho cơ sở vật
chất. Điều này bao gồm việc xác định:
 Nguồn điện sẽ cần thiết cho mục đích gì - ví dụ: không gian
văn phòng, thiết bị trong Trung tâm Dữ liệu, nhà ăn, v.v...
 Khi nào thì nguồn điện đó sẽ được cần đến. Một số hoạt động
yêu cầu cung cấp điện liên tục 24 giờ một ngày. Những nơi
khác, chẳng hạn như không gian văn phòng, s ẽ sử dụng nhiều
điện hơn vào ban ngày và rất ít vào ban đêm. Những hoạt động
khái lại chỉ cần điện tại một thời điểm cụ thể.
 Bao nhiêu điện năng sẽ được cần đến.
 Loại điện năng sẽ được sử dụng. Mặc dù hầu hết các tổ chức
đều sử dụng điện, nhưng ở nhiều nơi, hệ thống sưởi ấm lại phụ
thuộc vào nguồn khí đốt tự nhiên.
Quản lý Cơ sở vật chất cũng sẽ chịu trách nhiệm thiết lập hợp đồng
với các công ty tiện ích, hoặc trong nhiều trường hợp là chính quyền
địa phương hoặc chính quyền thành phố cung cấp dịch vụ đó. Điều
này sẽ bao gồm một tỷ lệ đã thỏa thuận và một mức độ sẵn có. Điều
này đã trở nên rất quan trọng ở những địa điểm mà nguồn cung cấp
điện thay đổi do thiếu cơ sở hạ tầng hoặc do người tiêu dùng nói
chung sử dụng quá mức.
Quản lý Cơ sở vật chất sẽ chịu trách nhiệm thiết lập các nguồn điện
dự phòng cho các trường hợp mất điện, thiên tai và các trường hợp
dự phòng khác. Điều này thường ở dạng Nguồn Cung cấp Điện Liên
tục (UPS) cho các thiết bị chính, và cả máy phát điện chạy bằng
nguồn năng lượng thay thế (thường là dầu diesel). Quản lý Cơ sở vật
chất không chỉ chịu trách nhiệm cung cấp những giải pháp thay thế
này mà còn kiểm tra chúng, giữ nguồn cung cấp nhiên liệu và bảo trì
chúng.
Cần phải nói rằng bất kỳ nguồn điện thay thế nào cũng cần được mô
hình hóa và thử nghiệm để đảm bảo rằng nó có thể đáp ứng nhu cầu
cần thiết và đồng thời nó sẽ tự động được kích hoạt sau khi mất
điện.
Một hoạt động chính khác của Quản lý Cơ sở vật chất là quản lý việc
sử dụng điện năng. Theo truyền thống, vai trò của Quản lý Cơ sở vật
chất chỉ là đảm bảo rằng điện năng luôn sẵn sàng. Tuy nhiên, khi
các nguồn tài nguyên thiên nhiên trở nên khan hiếm và đắt đỏ,
người ta đang tập trung nhiều hơn vào các kỹ thuật để quản lý việc
sử dụng một cách có trách nhiệm hơn.
Một trong những phương tiếp cận như vậy là quản lý động nguồn
điện năng trong Trung tâm Dữ liệu. Nguyên tắc là trong thời gian xử
lý cao điểm, nhiều máy tính hơn sẽ được sử dụng để thực hiện công
việc. Khi khối lượng công việc giảm xuống, công việc được tập trung
vào ít máy tính hơn, trong khi nh ững máy tính không được sử dụng
sẽ được tắt nguồn hoặc chuyển sang chế độ chờ. Điều này đòi hỏi sự
tích hợp đáng kể giữa các hoạt động của Quản lý Vận hành CNTT,
Quản lý Kỹ thuật và tất cả các quy trình Thiết kế Dịch vụ. Điều này
được thảo luận chi tiết hơn trong phần về chiến lược Trung tâm dữ
liệu.
E4 Điều kiện Môi trường và các Hệ thống Cảnh báo
Quản lý Cơ sở vật chất đảm bảo rằng các điều kiện vật lý trong
Trung tâm Dữ liệu hoặc các phòng máy tính được duy trì ở mức
chính xác cho Vận hành CNTT tối ưu.
Các điều kiện này bao gồm:
 Nhiệt độ,
 Độ ẩm,
 Chất lượng không khí,
 Không bị rủi ro về môi trường, chẳng hạn như hỏa hoạn, lũ lụt,
v.v…
Nhiệt độ được duy trì thông qua hệ thống sưởi ấm và làm mát, cũng
như cách bố trí các thiết bị trong cơ sở. Điều này sẽ yêu cầu các
hoạt động sau:
 Xác định sản lượng nhiệt đối với các Đơn vị Cấu hình và nhiệt
độ hoạt động tối ưu của chúng,
 Xác định tổng yêu cầu làm mát cho mọi thiết bị trong cơ sở vật
chất cũng như cho các hạng mục cụ thể. Ví dụ: máy điều hòa
không khí có thể giữ cho Trung tâm Dữ liệu ở nhiệt độ ổn định,
nhưng có thể có thiết bị cần được giữ ở nhiệt độ thấp hơn,
 Mô hình hóa các yêu cầu tổng thể về sưởi ấm và làm mát cũng
như lập bản đồ các khu vực cụ thể trong cơ sở có thể ấm hơn
hoặc mát hơn một cách tự nhiên. Thông tin này được sử dụng
để xác định vị trí tốt nhất dành cho thiết bị cụ thể. Điều quan
trọng cần lưu ý là khi thiết bị mới được lắp đặt trong một cơ
sở, nó sẽ thay đổi việc lập bản đồ các khu vực mát hơn và ấm
hơn trong cơ sở, do đó đòi hỏi các kỹ thuật lập bản đồ và mô
hình hóa phức tạp hơn. Các mô hình này cũn g sẽ cần phải tính
đến các biến đổi nhiệt độ theo mùa. Ví dụ, một số cơ sở có thể
cần được sưởi ấm vào mùa đông và làm mát vào mùa hè,
 Mua và bảo trì các thiết bị điều hòa không khí đủ công suất và
bảo trì các thiết bị này một cách định kỳ,
 Đầu tư vào các đơn vị thiết bị điều hòa không khí dự phòng có
thể được sử dụng nếu một đơn vị thiết bị chính bị hỏng, hoặc
cung cấp thêm công suất làm mát vào những ngày đặc biệt
nóng (mặc dù đây là một ngoại lệ hiếm hoi - nếu đơn vị thiết bị
dự phòng được sử dụng quá thường xuyên, điều này ngụ ý rằng
kế hoạch ban đầu không đầy đủ),
 Theo dõi liên tục nhiệt độ và điều chỉnh thiết lập làm mát theo
sự thay đổi của mùa và theo cách bố trí thiết bị. Các giám sát
này có thể được liên kết với Cầu nối vận hành, vốn có thể phản
ứng với bất kỳ độ lệch đáng kể nào so với nhiệt độ bình
thường,
 Xác định và tránh các lỗi ‘rõ ràng’, chẳng hạn như xác định vị
trí tỏa nhiệt của một máy chủ chính gần với cửa nạp của đơn vị
thiết bị điều hòa không khí; hoặc ngăn luồng không khí bằng
cách xếp chồng sách hướng dẫn vào không gian ‘trống’.
Các bước tương tự nên được thực hiện để xác định mức độ ẩm lý
tưởng và xác định xem liệu thiết bị hút ẩm có cần thiết hay không.
Thiết bị phát hiện khói thường được lắp đặt như một phần của chiến
lược kiểm soát hỏa hoạn tổng thể của cơ sở vật chất và được kết nối
với các hệ thống chữa cháy tự động. Tuy nhiên, Quản lý Cơ sở vật
chất không nên cho rằng phản ứng tự động đối với các mối đe dọa
hỏa hoạn là phù hợp. Các đơn vị thiết bị phát hiện khói phải được
kết nối tới Cầu nối vận hành và bất kỳ trường hợp ngoại lệ nào nên
được điều tra.
Các đơn vị thiết bị phát hiện chuyển động nên được lắp đặt ở tất cả
các khu vực hoạt động không có người giám sát. Những điều này sẽ
đảm bảo rằng truy cập trái phép được phát hiện và báo cáo cho Cơ
quan An ninh và có thể cho cả Cầu nối hoạt động. Điều này sẽ giúp
thực thi lập lịch trình phù hợp cho các hoạt động bảo trì hoặc lắp
đặt.
Phát hiện bụi và hạt nhỏ có thể hỗ trợ cho việc duy trì chất lượng
không khí xung quanh các hệ thống đặc biệt nhạy cảm. Một lần nữa,
các biện pháp giám sát nên được định tuyến đến Cầu nối Vận hành
để có thể điều tra và sửa chữa các sai lệch trước khi bất kỳ thiệt hại
đáng kể nào xảy ra.
Ngoài ra còn có một số hình thức giám sát cơ sở vật chất khác, dựa
trên vị trí của cơ sở. Ví dụ, các thiết bị giám sát chuyển động của
tòa nhà được lắp đặt ở những vị trí có mức độ hoạt động địa chấn
cao. Những hệ thống này hoạt động như những hệ thống cảnh báo
sớm để chỉ ra rằng một hệ thống cần phải được tắt hoặc được
chuyển đến một địa điểm thay thế trước khi một cơn địa chấn hoặc
động đất nghiêm trọng ảnh hưởng đến những thiết bị nhạy cảm. Các
biện pháp giám sát và bảo vệ tương tự cũng đang được lắp đặt tại
các cơ sở có hoạt động bão điện từ cao.
Các hệ thống này được gọi chung là Hệ thống Quản lý Tòa nhà
(Building Management Systems - BMS), mặc dù khi các công cụ này
được tích hợp, thuật ngữ này đang được sử dụng để chỉ một hệ
thống quản lý tích hợp duy nhất, thay vì một tập hợp lỏng lẻo các
công cụ thực hiện các chức năng tương tự. Hãy suy nghĩ về việc sử
dụng các công cụ giám sát được tích hợp hoặc ít nhất là nhất quán
với các công cụ giám sát hiện có. (Xem Chương 7 để biết thêm chi
tiết về các công cụ.)
E5 An toàn
Một mối quan tâm chính yếu của Quản lý Cơ sở vật chất là sự an
toàn của những người làm việc trong tòa nhà. Do đó, Quản lý Cơ sở
vật chất có trách nhiệm tìm hiểu và thực thi việc tuân thủ các tiêu
chuẩn và luật lệ về an toàn có liên quan.
An toàn được thực thi trong các lĩnh vực sau:
 Thiết kế và xây dựng tòa nhà,

 Bố trí các phòng và thiết bị trong cơ sở,
 Giáo dục cho tất cả nhân viên về các tiêu chuẩn an toàn có
hiệu lực trong cơ sở,
 Định nghĩa các thủ tục và tuyến đường sơ tán và các điểm tập
kết trong trường hợp hỏa hoạn hoặc các tình huống đe dọa đến
tính mạng khác,
 Đăng thông báo và thông tin liên quan đ ến bất kỳ thông tin an
toàn nào mà nhân viên cần phải được biết.
E6 Kiểm soát Truy cập Vật lý
Đây là một phần rất quan trọng của Quản lý Cơ sở vật chất và đã
được phát triển thành một lĩnh vực chuyên biệt. Do vậy, nội dung
được tóm tắt ở đây chỉ để tiện theo dõi, nhưng sẽ được thảo luận
chi tiết trong Phụ lục F.
Các thành phần chính của Kiểm soát Truy cập Vật lý (như được thảo
luận trong Phụ lục F) là:
 Hỗ trợ việc xác định và duy trì Kiểm soát Truy cập Vật lý như
một phần của các Chính sách Bảo mật của tổ chức,
 Duy trì sơ đồ mặt bằng cho biết những khu vực nào bị hạn chế,
 Lắp đặt và bảo trì các thiết bị kiểm soát truy cập vật lý,
 Giám sát và kiểm soát việc truy cập vào các cơ sở,
 Bố trí nhân viên an ninh,
 Lắp đặt và bảo trì thiết bị giám sát,
 Bảo vệ chống lại kỹ thuật xã hội.
E7 Giao nhận hàng hóa
Các cơ sở vật chất lớn cần có những khu vực đặc biệt nơi giao hàng
có thể lấy đồ nội thất, thiết bị máy tính, tủ rack, v.v… Khu vực này
cần được bảo vệ để nhân viên giao hàng không tiếp cận được với
phần còn lại của cơ sở vật chất. Cũng cần phải có một kho an toàn
gần khu vực nhận hàng, nơi các vật phẩm có thể được lưu trữ cho
đến khi chúng có thể được chuyển đến vị trí cuối cùng của chúng.
Cần phải có một quy trình để đảm bảo rằng các mặt hàng cần vận
chuyển được hạch toán và chỉ những mặt hàng đó mới được nhà
thầu giao hàng hoặc vận tải loại bỏ. Bất cứ khi nào có thể, những
mặt hàng này nên được chuyển vào kho an toàn trong khu vực vận
chuyển và giao hàng trước khi được gửi đi. Điều này sẽ ngăn chặn
việc truy cập trái phép vào cơ sở vật chất.
Hồ sơ giao nhận hàng hóa phải được hoàn thành, kiểm tra và ký tên
cho mỗi chuyến hàng được giao hoặc gửi đi. Một nhật ký trung tâm
của tất cả các lô hàng cũng nên được duy trì để kiểm soát.
E8 Tham gia vào Quản lý Hợp đồng
Hầu hết các cơ sở vật chất được cung cấp, quản lý và phục vụ bởi
một số thực thể. Mặc dù các hợp đồng thực tế với các đơn vị này
thường được quản lý bởi các bộ phận thương mại và pháp chế thích
hợp, Quản lý Cơ sở vật chất sẽ đóng vai trò quan trọng trong việc
xác định và thương lượng các hợp đồng này. Các hợp đồng điển hình
bao gồm:
 Quản lý hợp đồng thuê đối với tài sản được cho thuê. Điều
này còn khá hiếm hoi khi hầu hết các tổ chức đều xem Trung
tâm Dữ liệu của họ là tài sản quan trọng. Việc cho thuê các cơ
sở như vậy sẽ được coi là một rủi ro vì có khả năng tòa nhà
được bán, bên cho thuê ngừng kinh doanh hoặc bên cho thuê
không hoàn thành hợp đồng trong điều kiện bảo trì thích hợp,
 Cho thuê hoặc bảo trì thiết bị môi trường, chẳng hạn như
thiết bị điều hòa không khí, giám sát và cảnh báo môi trường
(ví dụ như thiết bị phát hiện khói và chữa cháy hoặc dập tắt),
 Hợp đồng bảo trì tòa nhà. Chúng bao gồm bảo dưỡng thang
máy, sàn, hệ thống ống nước và cung cấp điện,
 Cơ sở viễn thông. Mặc dù viễn thông thường được quản lý bởi
một nhóm hoặc bộ phận chuyên trách hoặc là một phần của
Mạng Diện Rộng (WAN), nhưng chúng thường phụ thuộc vào
các bên thứ ba để cung cấp và bảo trì thiết bị viễn thông nằm
trong hoặc ngay bên ngoài Trung tâm Dữ liệu. Ở nhiều quốc
gia, chúng được cung cấp bởi chính phủ hoặc các tổ chức viễn
thông cấp tiểu bang. Quản lý các loại hợp đồng này đòi hỏi một
bộ các kỹ năng đặc biệt,
 Các dịch vụ an ninh để cung cấp các dịch vụ kiểm soát truy
cập vật lý và các dịch vụ phản ứng được vũ trang.
Một phần rất quan trọng của Quản lý hợp đồng là đảm bảo rằng tất
cả mọi nhân viên của bên thứ ba đều nhận thức được và tuân thủ
các chính sách bảo mật của tổ chức. Điều này bao gồm kiểm soát
truy cập vật lý, tính bảo mật và việc sử dụng trái phép các phương
tiện hoặc thiết bị của tổ chức. Các cuộc kiểm toán định kỳ nên được
tổ chức để đảm bảo rằng điều này đang được thực thi.
E9 Bảo trì
Quản lý Cơ sở vật chất chịu trách nhiệm cho việc điều phối tất cả
các hoạt động bảo trì định kỳ trong phạm vi tòa nhà. Điều này đề
cập đến cả bảo trì tòa nhà cũng như bảo trì thiết bị trong Trung tâm
Dữ liệu.
Lý do để bao gồm việc bảo trì thiết bị chỉ đơn giản là để tránh việc
tòa nhà bị tiếp xúc với quá nhiều hoạt động bất thường cùng một
lúc. Nhiều nhóm làm việc ở những nơi khác nhau trong Trung tâm
Dữ liệu cùng một lúc dẫn đến những rủi ro về bảo mật và an toàn.
Điều quan trọng cần lưu ý là việc bảo trì thực tế thiết bị CNTT được
tiến hành bởi nhân viên Quản lý Kỹ thuật, nhưng dưới sự điều phối
của Quản lý Thay đổi và Quản lý Cơ sở vật chất.
Nhà quản lý Cơ sở vật chất nên duy trì một lịch trình tổng thể của
tất cả các hoạt động bảo trì đã được lập kế hoạch để đảm bảo rằng
hoạt động bảo trì được điều phối một cách đúng đắn. Lịch trình này
tạo thành một phần của Lịch trình Thay đổi Quản lý Thay đổi tổng
thể và được sử dụng để đảm bảo rằng không có xung đột giữa hoạt
động bảo trì định kỳ và việc triển khai các thay đổi.
Phụ lụ c F: Ki ểm so át Truy c ậ p V ậ t lý
Phần 5.12 và Phụ lục E đã giới thiệu lĩnh vực Kiểm soát Truy cập Vật
lý như một phần của Quản lý Cơ sở vật chất. Phần này sẽ cung cấp
một cuộc thảo luận chi tiết hơn về lĩnh vực này.
Quản lý Bảo mật Thông tin chịu trách nhiệm cho việc xác định và ghi
nhận lại tất cả các chính sách kiểm soát truy cập. Những chính sách
này sẽ xác định mọi biện pháp bảo mật vật lý cần được thực hiện và
những nhóm nhân viên nào nên được tiếp cận với loại cơ sở vật chất
nào. Quản lý Cơ sở vật chất sẽ đảm bảo rằng các chính sách này
được thực thi một cách đúng đắn. Các chính sách nên bao gồm:
 Khu vực nào bị hạn chế và cho đối tượng nào,

 Những biện pháp kiểm soát truy cập nào sẽ được đưa ra,
 Trong những trường hợp nào sẽ được phép truy cập vào các
khu vực bị hạn chế cụ thể. Ví dụ, ngăn chặn tất cả quyền truy
cập vào tầng Trung tâm Dữ liệu trừ khi mã số RFC đã được cấp
phép được nhập vào bàn phím,
 Kiểm soát truy cập sẽ được giám sát như thế nào,
 Một tuyên bố về các chính sách về quyền riêng tư và thông tin
nào cần được biết để cho phép truy cập,
 Các chính sách liên quan đến giám sát nhân sự, ví dụ, những gì
có thể được ghi lại, ở đâu và liệu có bất kỳ trường hợp ngoại lệ
nào không.
Hầu hết các tổ chức sử dụng nhiều cấp độ kiểm soát truy cập, bắt
đầu với quyền truy cập vào tài sản, sau đó chuyển sang quyền truy
cập vào các khu vực cụ thể trong tòa nhà và sau đó đến các chức
năng, thiết bị hoặc phòng ốc cụ thể. Mỗi cấp độ bảo mật được thực
thi bằng cách sử dụng các cơ chế và nhân viên khác nhau, do đó
cung cấp thêm tính bảo mật bổ sung.
Tất cả các cơ sở vật chất phải có sơ đồ tầng hiện tại được lập thành
văn bản chỉ ra chính xác khu vực nào bị hạn chế và khu vực nào
không. Kế hoạch này cũng sẽ chỉ ra những biện pháp an ninh nào
được triển khai và ở đâu. Điều này sẽ hỗ trợ việc kiểm tra an ninh
và cũng như để bảo trì thiết bị kiểm soát truy cập.
Các thiết bị kiểm soát ra vào cần được lắp đặt trên tất cả các lối vào
và lối ra. Mục đích của các thiết bị này là đảm bảo rằng chỉ những
người có thẩm quyền mới được phép tiếp cận khu vực hạn chế. Mặc
dù thoạt nhìn, đây là một chủ đề khá đơn giản, nhưng có một số
mục cần được tính đến (xem Bảng F.1).
Kiểm soát truy cập Ví dụ Ưu điểm Nhược điểm
Cơ khí Khóa và chìa Ổn định và đáng tin cậy. Đòi hỏi phải kiểm soát chìa khóa.
Rẻ tiền Các khóa phải được thay thế mỗi

lần ai đó rời khỏi tổ chức.
Có thể bị xâm phạm một cách dễ

dàng bởi bất kỳ ai với kiến thức và
một số kỹ thuật đơn giản.
Mã truy cập Cơ khí (ví dụ như Ổn định. Một người nào đó quan sát nhân
thiết bị nút bấm viên sử dụng thiết bị có thể lấy
Tương đối rẻ tiền.
được gắn vào cửa) được mã một cách dễ dàng
Điện tử (ví dụ, một Mã phải được thay đổi mỗi khi ai
bàn phím nhỏ được đó rời khỏi tổ chức.
sử dụng để kích
Mọi người có xu hướng viết mã truy
hoạt hoặc vô hiệu
cập xuống.
hóa báo động an
ninh)
Truy cập điện tử Khóa thẻ từ Dễ sử dụng. Tương đối đắt tiền, mặc dù chi phí
đã giảm, và thường rẻ hơn việc sử
Có thể được sử dụng để theo dõi việc
dụng nguồn nhân lực để bảo vệ vật
truy cập của cá nhân.
lý từng điểm truy cập.
Có thể được hủy bỏ hoặc thay đổi tập
Phụ thuộc vào tính sẵn sàng của
trung để thích hợp với các yêu cầu
thay đổi. nguồn điện năng.
Có thể được hủy bỏ thậm chí khi nhân Có thể bị xâm phạm bởi những
viên không trả lại thẻ của họ. người sử dụng thiết bị sao chép
chuyên dụng.
Sinh trắc học Máy quét võng mạc Cơ chế rất đáng tin cậy đối với việc Phụ thuộc vào tính sẵn sàng của
hoặc Phân tích xác định những cá nhân cụ thể. nguồn điện năng.
giọng nói
Khó để cưỡng ép truy cập. Đòi hỏi các hệ thống kiểm soát
truy cập tinh vi hơn.
Hiệu quả hơn khi đối phó kỹ thuật xã
hội. Tương đối đắt tiền.
Truy cập nhiều lớp Cửa với khóa thẻ Dễ dàng di chuyển từ khu vực này Khó kiểm soát.
từ. Một người mở sang khu vực khác, đặc biệt khi các
‘Tailgating’ (Đi theo người có thẩm
cửa và cho phép nhóm làm việc cùng nhau.
quyền).
truy cập đối với
Phụ thuộc vào nhận thức an ninh
bất kỳ số lượng
của nhân viên có thẩm quyền.
người nào đi cùng
với họ. Cực kỳ dễ bị tổn thương bởi kỹ
thuật xã hội.
Không nên sử dụng ở những khu

vực có độ bảo mật cao.
Truy cập một lớp (đơn Cửa xoay chỉ cho Dễ dàng kiểm soát truy cập hơn. Có thể trở thành một điểm nghẽn
lẻ) phép một người đi cổ chai vào giờ cao điểm.
Ngăn chặn kỹ thuật xã hội hiệu quả
vào. Cùng một
khóa thẻ từ không hơn. Đòi hỏi giám sát và bố trí nhân
thể được sử dụng viên với phạm vi rộng hơn.
cho một người thứ
hai.
Truy cập theo một Cửa xoay tròn chỉ Thích hợp đối với những tình huống Đòi hỏi việc giám sát nhiều hơn để
hướng duy nhất cho phép vào hoặc khi mà không cần phải giám sát những đảm bảo rằng mọi người không cố
ra. gì mà mọi người mang ra, tuy nhiên gắng đi sai hướng.
những thứ mà mọi người mang vào có
Thông thường, theo một hướng duy
thể gây ra thiệt hại đáng kể.
nhất cũng có hàm ý chỉ thiết bị
quét và giám sát bổ sung.
Truy cập theo cả hai Cửa truy cập được Thích hợp cho việc truy cập chung vào Những người đi ra có thể cung cấp
hướng kiểm soát những khu vực bị hạn chế. quyền truy cập cho những cá nhân
đi vào trái phép.
Có thể bị nghẽn cổ chai (ví dụ,

trong cửa xoay hai chiều, mọi
người đi ra phải đợi những người
đi vào).
Chủ động Đòi hỏi hành động Kiểm soát truy cập dễ dàng hơn. Đòi hỏi nhân sự phải nhớ một mật
bởi cá nhân để có mã hoặc mang theo một khóa thẻ
Bảo mật hơn.
được quyền truy từ.
cập, ví dụ quét
khóa thẻ từ hoặc
nhập một mật mã.
Thụ động Máy dò thụ động Cho phép mọi người thoát ra một cách Những người không được phép dễ
mở khóa một cửa an toàn khi xảy ra cháy nổ. dàng có được quyền truy cập chỉ
thoát ra từ bên đơn giản bằng cách đợi ở bên
Không đòi hỏi khóa thẻ từ để mọi
trong bất cứ khi ngoài cửa.
người di chuyển đến những khu vực
nào một ai đó tiếp
không bảo mật. Có thể được kích hoạt từ bên ngoài
cận.
bằng cách chèn một vật gì đó bên
dưới cửa và di chuyển nó trong
phạm vi của đầu dò.
Bảng F.1 – Các thiết bị kiểm soát truy cập
Hầu hết các cơ chế kiểm soát truy cập vật lý là không thể hư hỏng,
nên điều quan trọng là đảm bảo rằng quyền truy cập được giám sát
và kiểm soát. Việc này được thực hiện bởi nhân viên an ninh chuyên
biệt và bởi các thiết bị giám sát điện tử.
Vì bảo mật là tất cả về việc quản lý quyền truy cập của mọi người
vào một cơ sở vật chất, điều thích hợp là mọi người được sử dụng
để thực thi các biện pháp an ninh. Các tổ chức lớn hơn thỉnh thoảng
tự cung cấp nhân viên an ninh, nhưng h ầu hết có khuynh hướng
thuê ngoài kiểm soát truy cập vật lý cho những công ty được chuyên
môn hóa. Việc này thường là do những nguyên nhân sau:
 Nhân viên bảo vệ an ninh đòi hỏi phải được đào tạo chuyên
biệt và thường phải chịu các nguyên tắc kỷ luật gắt gao (gần
giống như lực lượng quân đội) khác với hầu hết nhân viên của
công ty. Điều này thường xung đột với loại nguyên tắc kỷ luật
thương mại và được quản lý tốt nhất bởi một tập hợp các nhà
quản lý khác và sử dụng một văn hóa quản lý khác,
 Các công ty bên ngoài thường ít có khả năng bị ảnh hưởng bởi
các tình huống kỹ thuật xã hội, khi họ được đào tạo chuyên
biệt và khó có thể hiểu được một số sắc thái nội bộ có thể
được sử dụng bởi một kỹ sư xã hội có kinh nghiệm.
Các thiết bị giám sát được sử dụng để mở rộng tính hiệu quả của cả
các cơ chế kiểm soát truy cập vật lý lẫn nhân viên an ninh. Điều
quan trọng cần lưu ý là không có thiết bị giám sát nào có thể thay
thế cho sự hiện diện của một nhân viên an ninh đã được đào tạo và
có nhận thức, chỉ đơn thuần là mở rộng tính hiệu quả của chúng.
Các ví dụ về các thiết bị giám sát phổ biến bao gồm:
 Các camera ghi hình để giám sát các điểm truy cập chính và
các điểm truy cập ít được sử dụng, từ đó cho phép một nhân
viên an ninh giám sát một số khu vực đồng thời. Chúng thường
được ghi lại và các video được lưu trữ trong một khoảng thời
gian trước khi được sử dụng lại một lần nữa. Việc này là để
đảm bảo rằng nếu bất kỳ hành vi sai trái nào được khám phá,
các băng từ có thể được sử dụng cho mục đích điều tra. Điều
này có nghĩa rằng chất lượng của hình ảnh phải đủ tốt để tạo
điều kiện cho việc xác định mọi người, tuy nhiên, nó cũng phải
ở một định dạng mà có thể dễ dàng lưu trữ một lượng lớn dữ
liệu trực quan.
 Truy cập các Nhật ký Sự kiện. Chúng thường ghi nhật ký lại
mọi sự kiện vào và ra của nhân viên bằng cách sử dụng các cơ
chế truy cập điện tử.
 Các đơn vị nhận diện thụ động để phát hiện sự hiện diện của
con người trong một khu vực không nên có nhân viên.
 Các cảnh báo sẽ thông báo cho nhân viên an ninh v ề truy cập
vào hoặc ra trái phép, thường được liên kết với một chuông
cảnh báo có thể được nghe rõ.
Bất kể môi trường được bảo mật như thế nào, nó vẫn phụ thuộc vào
nhận thức bảo mật của nhân viên và nhà thầu, những người làm việc
trong cơ sở vật chất. Kỹ thuật xã hội vẫn là một trong những vi
phạm bảo mật vật lý phổ biến nhất. Kỹ thuật xã hội đề cập đến thực
tiễn về việc có được truy nhập vào một cơ sở vật chất bằng cách sử
dụng các kỹ năng giao tiếp và giao tiếp giữa các cá nhân để thuyết
phục ai đó cho phép quyền truy cập trái phép vào một tòa nhà, khu
vực bị hạn chế, thiết bị và dữ liệu bị hạn chế, hoặc đến các tủ kệ có
chứa những tài liệu mật.
Các ví dụ về kỹ thuật xã hội bao gồm:
 Giả vờ như là một nhà thầu hoặc nhân viên hợp pháp của tổ
chức. Kỹ thuật thông thường là tiếp cận với nhân viên an ninh
và tuyên bố rằng họ đã quên thẻ từ truy cập của họ. Một Nhật
ký Truy cập được ký và một thẻ dành cho khách được cấp.
Thường thì sẽ không có kiểm tra thực tế về việc liệu một người
có phải là nhân viên hợp pháp hay không, đặc biệt là tại khu
vực lễ tân bận rộn.
 Giả vờ như là một ai đó có một lý do để có được quyền truy
cập hợp pháp vào cơ sở vật chất, ví dụ, một nhân viên tiện ích
hoặc nhân viên điều tra cháy nổ.
 Một cựu nhân viên hoặc nhà thầu tiếp cận với những người mà
họ quen biết để cho phép họ truy cập.
 ‘Tailgating’, khi một người chỉ đơn giản là đi theo một nhân
viên hợp pháp qua lối vào mà họ (nhân viên hợp pháp) đã mở
ra.
Kỹ thuật xã hội được chống lại tốt nhất bằng cách thực hiện việc
tuân thủ nghiêm ngặt các thủ tục kiểm soát truy cập, các chương
trình giáo dục liên tục, các cuộc họp giao ban thường xuyên của
nhân viên an ninh và các cuộc kiểm toán nghiêm ngặt.
Càng ngày càng có nhiều công ty cung cấp các dịch vụ để kiểm
nghiệm tính chặt chẽ của biện pháp kiểm soát truy cập với những
người chuyên sử dụng các kỹ thuật xã hội.
Chú gi ả i
Danh sách từ viết tắt
Viết tắt Nguyên gốc tiếng Anh Dịch tiếng Việt
ACD Automatic Call Distribution Tự động Phân phối Cuội gọi
AM Availability Management Quản lý Tính sẵn sàng
AMIS Availability Management Hệ thống Thông tin Quản lý Tính sẵn

Information System sàng
ASP Application Service provider Nhà cung cấp Dịch vụ Ứng dụng
BCM Business Capacity Quản lý Công suất Kinh doanh

Management
BCM Business Continuity Quản lý Liên tục Kinh doanh

Management
BCP Business Continuity Plan Kế hoạch Liên tục Kinh doanh
BIA Business Impact Analysis Phân tích Tác động Kinh doanh
BRM Business Relationship Quản lý Quan hệ Khách hàng

Management
BSI British Stvàard Institution Viện Tiêu chuẩn Anh
BSM Business Service Quản lý Dịch vụ Kinh doanh

Management
CAB Change Advisory Board Hội đồng Cố vấn Thay đổi
CAB/EC Change Advisory Hội đồng Cố vấn Thay đổi/Ủy ban
Board/Emergency Committee Khẩn cấp
CAPEX Capital Expenditure Chi tiêu Vốn
CCM Component Capacity Quản lý Công suất Thành phần

Management
CFIA Component Failure Impact Phân tích Tác động của Thành phần
Analysis Lỗi
CI Configuration Item Mục Cấu hình
CMDB Configuration Management Cơ sở dữ liệu Quản lý Cấu hình

Database
CMIS Capacity Management Hệ thống Thông tin Quản lý Công

Information System suất
CMM Capability Maturity Model Mô hình Năng lực Trưởng thành
CMMI Capability Maturity Model Tích hợp Mô hình Năng lực Trưởng
Integration thành
CMS Configuration Management Hệ thống Quản lý Cấu hình

System
COTS Commercial off the Shelf Thương mại Đóng gói sẵn
CSF Critical Success Factor Yếu tố thành công quan trọng
CSI Continual Service Liên tục Cải tiến Dịch vụ

Improvement
CSIP Continual Service Kế hoạch Liên tục Cải tiến Dịch vụ
Improvement Plan
CSP Core Service Package Gói Dịch vụ Cốt lõi
CTI Computer Telephony Máy tính Tích hợp Điện thoại

Integration
DIKW Data-to-Information-to- Dữ liệu đến Thông tin đến Kiến thức

Knowledge-to-Wisdom đến Sự thông thái
ELS Early Life Support Hỗ trợ Đầu đời
eSCM-CL eSourcing Capability Model Mô hình Năng lực thuê ngoài điện tử
for Client Organizations cho các Tổ chức của Khách hàng
eSCM-SP eSourcing Capability Model Mô hình Năng lực thuê ngoài điện tử
for Service providers cho các nhà cung cấp Dịch vụ
FMEA Failure Modes và Effects Phân tích các Chế độ Lỗi và Ảnh
Analysis hưởng
FTA Fault Tree Analysis Phân tích Cây Lỗi
IRR Inernal Rate of Return Tỷ suất Sinh lợi Nội bộ
ISG IT Steering Group Nhóm Chỉ đạo CNTT
ISM Information Security Quản lý Bảo mật Thông tin

Management
ISMS Information Security Hệ thống Quản lý Bảo mật Thông tin

Management System
ISO International Organization Tổ chức Tiêu chuẩn hóa Quốc tế
for Stvàardization
ISP Internet Service Provider Nhà cung cấp Dịch vụ Internet
IT Information Technology Công nghệ Thông tin
ITSCM IT Service Continuity Quản lý Liên tục Dịch vụ CNTT

Management
ITSM IT Service Management Quản lý Dịch vụ CNTT
itSMF IT Service Management Diễn đàn Quản lý Dịch vụ CNTT

Forum
IVR Interactive Voice Response Tương tác Trả lời Tự động
KEDB Known Error Database Cơ sở dữ liệu Lỗi Đã biết
KPI Key Performance Indicator Chỉ số Hiệu suất Chính yếu
LOS Line of Service Tuyến Dịch vụ
M_o_R Management of Risk Quản lý Rủi ro
MTBF Mean Time Between Failures Thời gian Hoạt động Giữa các Sự cố
MTBSI Mean Time Between Service Thời gian Hoạt động Giữa các Sự cố
Incidents Dịch vụ
MTRS Mean Time to Restore Thời gian trung bình để Khôi phục
Service Dịch vụ
MTTR Mean Time to Repair Thời gian trung bình để Sửa chữa
NPV Net Present Value Giá trị Ròng Hiện tại
OGC Office of Government Văn phòng Thương mại Chính phủ
Commence
OLA Operational Level Thỏa thuận Mức Vận hành

Agreement
OPEX Operational Expenditure Chi tiêu Vận hành
OPSI Office of Public Sector Văn phòng Thông tin Khu vực Công
Information
PBA Pattern of Business Activity Hình mẫu Hoạt động Kinh doanh
PIR Post-Implementation Review Xem xét Sau-Triển khai
PFS Prerequisite for Success Điều kiện tiên quyết để Thành công
PSO Projected Service Outage Ngừng Dịch vụ được Dự kiến
QA Quality Assurance Đảm bảo Chất lượng
QMS Quality Management System Hệ thống Quản lý Chất lượng
RCA Root cause Analysis Phân tích nguyên nhân gốc
RFC Request for Change Yêu cầu Thay đổi
ROI Return on Investment Lợi nhuận Đầu tư
RPO Recovery Point Objective Mục tiêu Điểm Khôi phục
RTO Recovery Time Objective Mục tiêu Thời gian Khôi phục
SoC Seperation of concerns Phân tách các mối quan tâm
SAC Service Acceptance Criteria Tiêu chí Chấp thuận Dịch vụ
SACM Service asset và Quản lý Cấu hình và Tài sản dịch vụ
Configuration Management
SCD Supplier và contract Cơ sở dữ liệu nhà cung cấp và hợp

database đồng
SCM Service Capacity Quản lý Công suất Dịch vụ

Management
SDP Service Design Package Gói Thiết kế Dịch vụ
SFA Service Failure Analysis Phân tích Lỗi Dịch vụ
SIP Service Improvement Plan Kế hoạch Cải tiến Dịch vụ
SKMS Service Knowledge Hệ thống Quản lý Kiến thức Dịch vụ

Management System
SLA Service Level Agreement Thỏa thuận Mức Dịch vụ
SLM Service Level Management Quản lý Mức Dịch vụ
SLP Service level package Gói mức Dịch vụ
SLR Service Level Requirement Yêu cầu Mức Dịch vụ
SMO Service Maintenance Mục tiêu Duy trì Dịch vụ

Objective
SOP Stvàard Operating Các Thủ tục Vận hành Tiêu chuẩn
Procedures
SOR Statement of requirements Tuyên bố về các yêu cầu
SPI Service provider Interface Giao diện nhà cung cấp Dịch vụ
SPM Service Porfolio Quản lý Danh mục Dịch vụ
Management
SPO Service Provisioning Tối ưu hóa Cung cấp Dịch vụ

Optimization
SPoF Single Point of Failure Điểm Đơn Lỗi
TO Technical Observation Quan sát Kỹ thuận
TOR Terms of reference Thuật ngữ tham chiếu
TCO Total Cost of Ownership Tổng Chí phí Sở hữu
TCU Total Cost of Utilization Tổng Chi phí Sử dụng
TQM Total Quality Management Quản lý Chất lượng Tổng thể
UC Underpinning Contract Hợp đồng Cơ sở
UP User Portfolio Danh mục Người sử dụng
VBF Vital Business Function Chức năng Kinh doanh Sống còn
VOI Value on Investment Giá trị của khoản Đầu tư
WIP Work in Progress Công việc đang Tiến hành
Danh sách các định nghĩa
Các tên ấn phẩm được đặt trong dấu ngoặc đơn sau tên của mỗi thuật ngữ xác định nơi mà độc
giả có thể tìm thấy nhiều thông tin hơn về thuật ngữ đó. Việc này là vì thuật ngữ chủ yếu được
sử dụng bởi ấn phẩm đó hoặc thông tin bổ sung hữu ích về thuật ngữ đó có thể được tìm thấy
ở đó. Những thuật ngữ không có tên ấn phẩm tương ứng với chúng có thể được sử dụng một
cách chung chung bởi các ấn phẩm, hoặc có thể không được định nghĩa chi tiết hơn những gì
có thể được tìm thấy trong bảng chú giải thuật ngữ này, nghĩa là chúng tôi chỉ muốn nhấn
mạnh với độc giả vào nơi nào đó mà họ có thể kỳ vọng mở rộng kiến thức của họ hoặc nhìn
thấy bối cảnh rộng hơn. Những thuật ngữ với nhiều tên ấn phẩm được mở rộng trong nhiều ấn
phẩm.
Khi định nghĩa về một thuật ngữ bao gồm thuật ngữ khác, những thuật ngữ liên quan đó được
làm nổi bật bằng màu thứ hai. Việc này được thiết kế để giúp độc giả hiểu thêm bằng cách
hướng họ đến các định nghĩa bổ sung mà tất cả đều là một phần của thuật ngữ ban đầu mà họ
quan tâm. Biểu mẫu ‘Xem thêm Thuật ngữ X, Thuật ngữ Y’ được sử dụng sau một định nghĩa
nơi một thuật ngũ liên quan quan trọng không được sử dụng cùng với bối cảnh của bản thân
định nghĩa.
Thuật ngữ Định nghĩa
Acceptance Thỏa thuận chính thức rằng một Dịch vụ, Quy trình, Kế hoạch CNTT hoặc Sản phẩm có
(Chấp thuận) thể chuyển giao được khác là hoàn thành, chính xác, Đáng tin cậy và đáp ứng các Yêu
cầu cụ thể của nó. Chấp thuận thường là kết quả của Đánh giá hoặc Kiểm nghiệm và
thường được yêu cầu trước khi tiến hành giai đoạn tiếp theo của một Dự án hoặc Quy
trình. Xem thêm Tiêu chí Chấp thuận Dịch vụ.
Accounting (Chiến lược Dịch vụ) Quy trình chịu trách nhiệm về việc xác định chi phí thực tế khi
(Kế toán) triển khai Dịch vụ CNTT, so sánh với ngân sách và kiểm soát các sai biệt với ngân sách
Activity Tập hợp các hành động được thiết kế, sắp xếp nhằm đạt được kết quả xác định. Các
(Hoạt động) hoạt động thông thường được định nghĩa như là một phần của các Quy trình, Kế
hoạch, và được tài liệu hóa trong các Thủ tục.
Agreed Service Time (Thiết kế Dịch vụ) Từ đồng nghĩa của Giờ dịch vụ, thường được sử dụng để tính toán
(Thời gian Dịch vụ đã về Tính sẵn sàng. Xem Downtime (Thời gian gián đoạn).
Thỏa thuận)
Agreement Một văn bản mô tả về sự thấu hiểu chính thức của hai hay nhiều bên. Một Thỏa thuận
(Thỏa thuận) không được xem là có tính pháp lý trừ khi nó là một phần của một Hợp đồng. Xem
thêm Thoả thuận mức dịch vụ và Thoả thuận mức vận hành.
Alert (Vận hành Dịch vụ) Sự cảnh báo về một ngưỡng nào đó đã bị vượt quá, cái gì đó đã bị
(Cảnh báo) thay đổi, hay một Hư hỏng đã xảy ra. Các cảnh báo thường được tạo ra và quản lý bởi
các công cụ Quản trị Hệ thống. Đồng thời cũng được quản lý bởi Tiến trình Quản lý Sự
kiện.
Analytical Modelling (Chiến lược Dịch vụ) (Thiết kế Dịch vụ) (Liên tục Cải tiến Dịch vụ) Một kỹ thuật sử
(Mô hình Phân tích) dụng các mô hình toán học để dự đoán trước hoạt động hành vi của một Đơn vị cấu
hình hoặc một Dịch vụ CNTT. Các Mô hình Phân tích thường được sử dụng trong lĩnh
vực Quản trị công suất và Quản trị tính sẵn sàng. Xem thêm Mô hình hóa.
Application Phần mềm (máy tính) cung cấp những Chức năng cần thiết được yêu cầu bởi một Dịch
(Ứng dụng) vụ CNTT. Mỗi Ứng dụng có thể là một phần của một hoặc nhiều Dịch vụ CNTT. Một Ứng
dụng có thể hoạt động trên một hay nhiều Máy chủ hoặc Máy trạm. Xem thêm Quản lý
Ứng dụng, Danh mục Ứng dụng.
Application (Thiết kế Dịch vụ) (Vận hành Dịch vụ) Chức năng chịu trách nhiệm cho việc quản lý
Management các Ứng dụng trong suốt Vòng đời của nó.
(Quản lý Ứng dụng)
Application Portfolio (Thiết kế Dịch vụ) Một cơ sở dữ liệu hay một hệ thống Văn bản có cấu trúc sử dụng để
(Danh mục Ứng dụng) quản lý các Ứng dụng trong suốt Vòng đời của nó. Danh mục Ứng dụng bao hàm tất cả
các Thuộc tính chính của mọi Ứng dụng. Danh mục Ứng dụng đôi khi cũng được triển
khai như một phần của Danh mục Dịch vụ hay một phần của Hệ thống Quản lý Cấu hình
Application Service (Thiết kế Dịch vụ) Một Nhà cung cấp từ Bên ngoài cung cấp các Dịch vụ CNTT sử dụng
provider các Ứng dụng hoạt động tại địa điểm của nhà cung cấp dịch vụ. Người sử dụng sẽ truy
(Nhà cung cấp Dịch vụ cập tới các Ứng dụng thông qua các kết nối mạng tới Nhà cung cấp dịch vụ
Ứng dụng)
Application Sizing (Thiết kế Dịch vụ) Hoạt động chịu trách nhiệm tìm hiểu yêu cầu Nguồn lực Cần có để
(Định quy mô Ứng hỗ trợ một Ứng dụng mới hoặc một thay đổi lớn trong Ứng dụng hiện hữu. Định quy
dụng) mô Ứng dụng giúp cho việc đảm bảo rằng Dịch vụ CNTT có thể đáp ứng mức Dịch vụ
được nhắm mục tiêu đã thỏa thuận về Công suất và Hiệu suất của dịch vụ.
Architecture (Thiết kế Dịch vụ) Cấu trúc của một Hệ thống hay một Dịch vụ CNTT, bao gồm Các mối
(Kiến trúc) quan hệ của các Thành phần với nhau và với môi trường mà chúng thuộc về. Kiến trúc
cũng bao gồm các Tiêu chuẩn và Hướng dẫn để định hướng cho việc thiết kế và phát
triển hệ thống.
Assessment Xem xét, phân tích nhằm kiểm tra xem một Tiêu chuẩn hay một tập hợp các Hướng dẫn
(Đánh giá) có được tuân thủ không, các Hồ sơ có chính xác hay không, hay các mục tiêu về Hiệu
quả và Năng suất là được thỏa mãn. Xem thêm Kiểm toán.
Asset (Chiến lược Dịch vụ) Bất cứ nguồn lực hay Năng lực nào. Tài sản của một nhà cung cấp
(Tài sản) Dịch vụ là bất cứ gì có thể tham gia đóng góp vào quá trình cung c ấp một Dịch vụ. Tài
sản có thể là một trong các loại sau: Năng lực quản lý, Tổ chức, Quy trình, Kiến thức,
Con người, Thông tin, Ứng dụng, Cơ sở hạ tầng, Năng lực tài chính.
Asset Management (Chuyển tiếp Dịch vụ) Quản lý Tài sản là một Quy trình chịu trách nhiệm cho việc theo
(Quản lý Tài sản) dõi, lập báo cáo về giá trị và sự sở hữu Tài sản tài chính trong suốt Vòng đời của nó.
Quản lý Tài sản là một phần của tài sản Dịch vụ và Quy trình Quản lý Cấu hình tổng
thể.
Attribute (Chuyển tiếp Dịch vụ) Một phần thông tin nào đó về Đơn vị Cấu hình. Ví dụ, tên, vị trí,
(Thuộc tính) Phiên bản và Chi phí. Thuộc tính của các Đơn vị cấu hình được lưu trữ trong Cơ sở dữ
liệu Quản lý Cấu hình (CMDB). Xem thêm Quan hệ.
Audit Kiểm tra và xác minh một cách chính thức rằng một Tiêu chuẩn hoặc tập hợp các
(Kiểm toán) Hướng dẫn có được tuân thủ không, các Hồ sơ có chính xác không, hoặc là mục tiêu về
Tính hiệu quả và Hiệu suất có đạt được không. Một cuộc Kiểm toán có thể được thực
hiện bởi các nhóm nội bộ (kiểm toán nội bộ) hoặc từ bên ngoài. Xem thêm Chứng
nhận, Đánh giá.
Automatic Call (Vận hành Dịch vụ) Sử dụng CNTT để chuyển hướng một cuộc gọi (thoại) từ ngoài vào
Distribution tới người phù hợp nhất trong khoảng thời gian ngắn nhất có thể. ACD đôi khi được gọi
(Tự động Phân phối là Phân phối Cuộc gọi được Tự động hóa.
Cuộc gọi)
Availability (Thiết kế Dịch vụ) Là khả năng của một Đơn vị Cấu hình hoặc Dịch vụ CNTT có thể
(Tính sẵn sàng) thực hiện một chức năng đã thỏa thuận khi được yêu cầu. Tính sẵn sàng được xác định
bởi: Độ tin cậy, Tính có thể Bảo trì được, Khả năng dịch vụ hoá, Hiệu suất, và Bảo
mật. Phép tính toán này thường dựa vào Thời gian Dịch vụ Thoả thuận và Thời gian
gián đoạn. Theo kinh nghiệm, Thực tiễn Tốt nhất để tính toán Tính sẵn sàng của một
Dịch vụ CNTT là đo lường các kết quả Kinh doanh đầu ra của tổ chức
Availability (Thiết kế Dịch vụ) Quy trình chịu trách nhiệm cho việc xác định, phân tính, Hoạch
Management định, đo lường và cải tiến mọi khía cạnh của Tính sẵn sàng của Dịch vụ CNTT. Quản lý
(Quản lý Tính sẵn sàng) Tính sẵn sàng chịu trách nhiệm cho việc đảm bảo rằng toàn bộ Cơ sở Hạ tầng, Quy
trình, Công cụ, Vai trò, v.v… CNTT là phù hợp với mục tiêu mức Dịch vụ được nhắm
đến đã thỏa thuận về Tính sẵn sàng.
Availability (Thiết kế Dịch vụ) Kho lưu trữ ảo của tất cả các dữ liệu về Quản lý Tính sẵn sàng,
Management thông thường được lưu trữ trên nhiều vị trí vật lý khác nhau. Xem thêm Hệ thống Quản
Information System lý Kiến thức Dịch vụ.
(Hệ thống Thông tin

Quản lý Tính sẵn sàng)
Availability Plan (Thiết kế Dịch vụ) Một kế hoạch nhằm đảm bào rằng những yêu cầu về Tính sẵn sàng
(Kế hoạch Tính sẵn của các Dịch vụ CNTT trong hiện tại và tương lai có thể được cung cấp với Chi phí
sàng) Hiệu quả.
Back-out Xem Khắc phục.
(Khôi phục)
Backup (Thiết kế Dịch vụ) (Vận hành Dịch vụ) Sao chép dữ liệu nhằm bảo vệ tránh khỏi sự mất
(Sao lưu) mát về Tính toàn vẹn hoặc Tính sẵn sàng của bản gốc
Balanced Scorecard (Liên tục Cải tiến Dịch vụ) Một công cụ quản lý được phát triển bởi tiến sĩ Robert
(Thẻ điểm Cân bằng) Kaplan (Harvard Business School) và David Norton. M ột Thẻ điểm Cân bằng cho phép
một Chiến lược có thể được phân rã thành các Chỉ số Hiệu suất Chính. Hiệu suât đối
với các KPI được sử dụng để chứng minh rằng một Chiến lược đã đạt được tốt đến mức
nào. Một Thẻ điểm Cân bằng gồm 4 khía cạnh chủ yếu, mỗi khía cạnh bao gồm một số
Chỉ số Hiệu suất Chính. Cả 4 khía cạnh này được xem xét ở các mức độ khác nhau
trong toàn bộ Tổ chức.
Baseline (Liên tục Cải tiến Dịch vụ) Một Điểm chuẩn được sử dụng như là một điểm thao khảo.
(Đường cơ sở) Ví dụ,
- Một Đường cơ sở ITSM (Quản lý Dịch vụ CNTT) có thể được sử dụng như điểm
khởi đầu để đo lường tính hiệu quả của Kế hoạch Cải tiến Dịch vụ
- Một Đường cơ sở Hiệu suất có thể được sử dụng để đo lường các thay đổi trong
Hiệu suất của một Dịch vụ CNTT trong suốt vòng đời của nó
- Một Đường cơ sở Quản trị cấu hình có thể được sử dụng để cho phép các cơ sở
hạ tầng CNTT được phục hồi đến một cấu hình đã được biết trong trường hợp có
thay đổi hoặc phát hành không thành công
Benchmark (Liên tục Cải tiến Dịch vụ) Trạng thái được ghi nhận của một điều gì đó tại một thời
(Điểm chuẩn) điểm cụ thể nào đó. Một Điểm chuẩn có thể được tạo ra cho một Cấu hình, một Quy
trình, hay bất kỳ tập hợp dữ liệu khác. Ví dụ, một Điểm chuẩn có thể được sử dụng
trong:
 Liên tục Cải tiến Dịch vụ, để thiết lập hiện trạng cho tiến trình quản lý sự cải
tiến,
 Quản trị Công suất để lập thành văn bản các đặc trưng về hiệu suất trong suốt
quá trình vận hành bình thường.
Xem thêm So sánh điểm chuẩn, Đường cơ sở.
Benchmarking (Liên tục Cải tiến Dịch vụ) So sánh một Điểm chuẩn với Đường cơ sở hoặc với Thực
(So sánh điểm chuẩn)) tiễn Tốt nhất. Thuật ngữ So sánh điểm chuẩn cũng được sử dụng để chỉ về ý nghĩa là
tạo ra một chuỗi các Điểm chuẩn theo thời gian, so sánh các kết quả nhằm đo lường
tiến trình hoặc sự cải tiến
Best Practice Các Hành động hoặc các Quy trình đã được chứng minh là được sử dụng một cách
(Thực tiễn Tốt nhất) thành công bởi nhiều Tổ chức. ITIL là một ví dụ về Thực tiễn Tốt nhất.
Brainstorming (Thiết kế Dịch vụ) Một kỹ thuật có thể giúp đội nhóm tạo ra các ý tưởng. Các ý tưởng
(Kích não) sẽ không được xem xét trong quá trình sử dụng Phương pháp Kích não nhưng sẽ được
đánh giá sau đó. Phương pháp này, thông thư ờng được sử dụng trong Quản lý Vấn đề
để xác định nguyên nhân có thể gây ra vấn đề.
Budget Một danh sách mọi lượng tiền mà một Tổ chức hoặc Đơn vị Kinh doanh lên kế hoạch để
(Ngân sách) nhận được, kế hoạch chi trả trong một khoảng thời gian nhất định nào đó. Xem thêm
Lập ngân sách, Hoạch định.
Budgeting Hành động dự báo và kiểm soát việc chi tiêu. Bao gồm các chu kỳ thương lượng lặp đi
(Lập ngân sách) lặp lại nhằm thiết lập Ngân sách cho tương lai (thường là hàng năm) đồng thời giám
sát và tinh chỉnh Ngân sách hiện tại hàng ngày.
Build (Chiến lược Dịch vụ) Hành động lắp ráp một số các Đơn vị Cấu hình để tạo ra một
(Xây dựng) thành phần của Dịch vụ CNTT. Thuật ngữ này cũng được sử dụng để chỉ các Phiên bản
đã được phép phân phối. Ví dụ, Server Build hoặc Laptop Build. Xem thêm Đường cơ sở
Cấu hình.
Business (Chiến lược Dịch vụ) Một thực thể tổng thể của doanh nghiệp hoặc Tổ chức được tạo
(Doanh nghiệp) thành từ một số các Đơn vị kinh doanh (Business Unit). Trong b ối cảnh Quản lý Dịch
vụ CNTT, thuật ngữ Doanh nghiệp bao gồm cả khối dịch vụ công cộng và các tổ chức
phi lợi nhuận khác cũng như là các công ty. Một nhà cung cấp các Dịch vụ CNTT cung
cấp Dịch vụ CNTT cho khách hàng trong một Doanh nghiệp. Nhà cung cấp Dịch vụ
CNTT có thể là một phần của cùng một Doanh nghiệp với Khách hàng của mình (nhà
cung cấp Dịch vụ Nội bộ) hoặc là một phần của Doanh nghiệp khác (nhà cung cấp Dịch
vụ Bên ngoài).
Business Capacity (Thiết kế Dịch vụ) Trong bối cảnh Quản lý Dịch vụ CNTT, Quản lý Công suất doanh
Management nghiệp là Hành động chịu trách nhiệm cho việc tìm hiểu Nhu cầu Doanh nghiệp trong
(Quản lý Công suất tương lai để sử dụng trong một Kế hoạch công suất. Xem thêm Quản lý Công suất
Doanh nghiệp) Dịch vụ.
Business Case (Chiến lược Dịch vụ) Sự biện giải cho một đề mục quan trọng trong việc chi tiêu. Bao
(Đề án Kinh doanh) gồm thông tin về Chi phí, lợi nhuận, các lựa chọn, các vấn đề, Rủi ro và các vấn đề có
thể gặp phải. Xem Phân tích Lợi ích Chi phí
Business Continuity (Thiết kế Dịch vụ) Một quy trình nghiệp vụ chịu trách nhiệm cho việc quản lý những
Management Rủi ro có thể gây ảnh hưởng nghiêm trọng tới Doanh nghiệp. Quản lý Liên tục Kinh
(Quản lý Liên tục Kinh doanh bảo vệ lợi ích của các bên liên quan, danh tiếng, thương hiệu và các hoạt động
doanh) tạo ra-giá trị. Quy trình Quản lý Liên tục Kinh doanh tham gia vào việc làm giảm thiểu
Rủi ro đến mức có thể chấp nhận được và hoạch định việc khôi phục các Quy trình
nghiệp vụ nếu sự gián đoạn xảy ra đối với Doanh nghiệp. Quản lý Liên tục Kinh doanh
cũng thiết lập các Mục tiêu, Phạm vi và các Yêu cầu đối với Quản lý Liên tục Dịch vụ
CNTT.
Business Continuity (Thiết kế Dịch vụ) Một bản kế hoạch xác định các bước chi tiết cần thiết để Khôi phục
Plan các Quy trình Nghiệp vụ sau khi bị gián đoạn. Kế hoạch này cũng đồng thời cũng xác
(Kế hoạch Liên tục Kinh định các điều kiện kích hoạt để Viện dẫn, những người tham gia, cách thức truyền
doanh) thông, v.v… Kế hoạch Liên tục Dịch vụ CNTT là một phần quan trọng trong các Kế
hoạch Liên tục Kinh doanh.
Business Customer (Chiến lược Dịch vụ) Là người nhận một sản phẩm hoặc một Dịch vụ nào đó từ Doanh
(Khách hàng (của) nghiệp. Ví dụ, nếu Doanh nghiệp là nhà sản xuất xe hơi thì Khách hàng (của) Doanh
Doanh nghiệp) nghiệp là người mua xe
Business Impact (Chiến lược Dịch vụ) BIA là Hoạt động trong Quản lý Liên tục Kinh doanh, xác định các
Analysis Chức năng Kinh doanh Sống còn và các phụ thuộc của nó. Các phụ thuộc này có thể là
(Phân tích Tác động các Nhà cung cấp, con người, các Quy trình Nghiệp vụ khác, các Dịch vụ CNTT, v.v…
Kinh doanh) Phân tích tác động đến Doanh nghiệp cũng xác định các yêu cầu khôi phục đối với các
Dịch vụ CNTT. Những yêu cầu này bao gồm Mục tiêu Thời gian Khôi phục, Mục tiêu về
Điểm Khôi phục và mức Dịch vụ được nhắm mục tiêu tối thiểu cho mỗi Dịch vụ CNTT.
Business Objective (Chiến lược Dịch vụ) Mục tiêu của một Quy trình Nghiệp vụ hoặc toàn thể Doanh
(Mục tiêu Kinh doanh) nghiệp. Mục tiêu Kinh doanh hỗ trợ cho Tầm nhìn Doanh nghiệp, cung cấp hướng dẫn
cho Chiến lược CNTT, và thường được hỗ trợ bởi các Dịch vụ CNTT
Business Operations (Chiến lược Dịch vụ) Thực thi, giám sát và quản trị các Quy trình Nghiệp vụ hàng ngày
(Vận hành Doanh

nghiệp)
Business Perspective (Liên tục Cải tiến Dịch vụ) Sự thấu hiểu về nhà cung cấp Dịch vụ và các Dịch vụ CNTT
(Quan điểm Kinh từ quan điểm của Doanh nghiệp, và sự thấu hiểu về Doanh nghiệp từ quan điểm của
doanh) nhà cung cấp Dịch vụ.
Business Process Một Quy trình được sở hữu và thực thi bởi một Doanh nghiệp. Một Quy trình Nghiệp vụ
(Quy trình Nghiệp vụ) tham gia vào quá trình cung cấp một sản phẩm hay một Dịch vụ tới một Khách hàng
(của) Doanh nghiệp. Ví dụ, một nhà bán lẻ có thể có một Quy trình mua hàng giúp cho
việc cung cấp các Dịch vụ tới Khách hàng (của) Doanh nghiệp của họ. Rất nhiều Quy
trình Nghiệp vụ phụ thuộc vào các Dịch vụ CNTT
Business Relationship (Chiến lược Dịch vụ) Quy trình hoặc Chức năng chịu trách nhiệm cho việc duy trì một
Management Mối quan hệ với Doanh nghiệp. Quản lý Mối quan hệ Kinh doanh thường bao gồm:
(Quản lý Mối quan hệ  Quản lý Mối quan hệ cá nhân với các nhà quản lý của Doanh nghiệp,
Kinh doanh)  Cung cấp đầu vào cho Quản lý Danh mục Dịch vụ,
 Đảm bảo rằng nhà cung cấp Dịch vụ CNTT thỏa mãn các nhu cầu Kinh doanh của
Khách hàng.
Quy trình này có mối liên hệ chặt chẽ với Quản lý Mức dịch vụ.
Business Service Một Dịch vụ CNTT hỗ trợ trực tiếp cho một Quy trình Nghiệp vụ, trái ngược với một
(Dịch vụ Kinh doanh) Dịch vụ Cơ sở hạ tầng, được sử dụng trong nội bộ nhà cung cấp Dịch vụ CNTT và
thường không hữu hình đối với Doanh nghiệp.
Thuật ngữ Dịch vụ Kinh doanh cũng được sử dụng để chỉ một Dịch vụ được cung cấp
cho Khách hàng (của) Doanh nghiệp bởi các Đơn vị Kinh doanh. Ví dụ, cung cấp các
dịch vụ tài chính cho Khách hàng của một ngân hàng, hoặc hàng hóa cho các Khách
hàng của một nhà bán lẻ. Sự thành công của việc cung cấp các Dịch vụ Kinh doanh
thường phụ thuộc vào một hoặc nhiều Dịch vụ CNTT
Business Service (Chiến lược Dịch vụ) (Thiết kế Dịch vụ) Một phương pháp tiếp cận để quản lý các Dịch
Management vụ CNTT xem xét các Quy trình Nghiệp vụ được hỗ trợ và giá trị Kinh doanh được cung
(Quản lý Dịch vụ Kinh cấp.
doanh) Thuật ngữ này cũng sử dụng để chỉ về sự quản lý các Dịch vụ Kinh doanh được cung
cấp cho các Khách hàng (của) Doanh nghiệp.
Business Unit (Chiến lược Dịch vụ) Một bộ phận của Doanh nghiệp có Kế hoạch, Chỉ số, thu nhập và
(Đơn vị Kinh doanh) Chi phí riêng. Mỗi Đơn vị Kinh doanh có các Tài sản riêng và sử dụng chúng này để tạo
ra các giá trị cho Khách hàng dưới dạng hàng hóa hoặc các Dịch vụ.
Call (Vận hành Dịch vụ) Một cuộc gọi điện thoại tới Bộ phận Hỗ trợ Dịch vụ (Service Desk)
(Cuộc gọi) từ Người sử dụng. Cuộc gọi báo cáo một Sự cố hoặc một yêu cầu Dịch vụ có thể được
ghi lại.
Call Centre (Vận hành Dịch vụ) Một Tổ chức hoặc một Đơn vị Kinh doanh có trách nhiệm xử lý một
(Trung tâm Cuộc gọi) số lượng lớn các cuộc gọi điện thoại cả hai chiều vào và ra. Xem thêm Service Desk
Capability (Chiến lược Dịch vụ) Khả năng mà một Tổ chức, cá nhân, Quy trình, Ứng dụng, Đơn vị
(Năng lực) Cấu hình hay một Dịch vụ CNTT có thể thực thi một Hoạt động. Năng lực là Tài sản vô
hình của một Tổ chức. Xem thêm Nguồn lực.
Capacity (Thiết kế Dịch vụ) Thông lượng tối đa mà một Đơn vị Cấu hình hoặc một Dịch vụ CNTT
(Công suất) có thể cung cấp trong khi đáp ứng mức Dịch vụ được nhắm mục tiêu đã được thỏa
thuận. Đối với vài kiểu CI, Công suất có thể là kích cỡ hoặc khối lượng, ví dụ, một ổ
đĩa.
Capacity Management (Thiết kế Dịch vụ) Quy trình chịu trách nhiệm cho việc đảm bảo rằng Công suất của
(Quản lý Công suất) các Dịch vụ CNTT và hệ thống Cơ sở hạ tầng CNTT đủ khả năng cung cấp mức Dịch vụ
được nhắm mục tiêu đã thỏa thuận với Chi phí Hiệu quả và đúng hạn. Quản lý công
suất xem xét tất cả các Nguồn lực cần thiết để cung cấp Dịch vụ CNTT, lên kế hoạch
để đáp ứng các Nhu cầu Kinh doanh ngắn, trung và dài hạn.
Capacity Management (Thiết kế Dịch vụ) Một kho lưu trữ ảo chứa tất cả dữ liệu về Quản lý Công suất, thông
Information System thường được lưu trữ trên nhiều vị trí vật lý khác nhau. Xem Hệ thống Thông tin Quản
(CMIS) lý Kiến thức Dịch vụ.
(Hệ thốngThông tin

Quản lý Công suất)
Capacity Plan (Thiết kế Dịch vụ) Một kế hoạch được sử dụng để quản lý tất cả các Nguồn lực cần
(Kế hoạch công suất) thiết để cung cấp các Dịch vụ CNTT. Kế hoạch này bao gồm các kịch bản dự báo trước
khác nhau về các yêu cầu của Doanh nghiệp, các lựa chọn về chi phí để cung cấp mức
Dịch vụ được nhắm mục tiêu đã thỏa thuận.
Capacity Planning (Thiết kế Dịch vụ) Hành động trong phạm vi Quản lý Công suất chịu trách nhiệm cho
(Hoạch định công suất) việc soạn thảo một Kế hoạch Công suất.
Category Một nhóm được đặt tên của những thứ có chung một đặc điểm nào đó. Thể loại được
(Thể loại) sử dụng để nhóm những điều tương tự lại với nhau. Ví dụ, Các loại Chi phí được sử
dụng để nhóm các loại Chi phí tương tự nhau. Thể loại Sự cố được sử dụng để nhóm
các kiểu Sự cố tương tự nhau, các Kiểu CI được sử dụng để nhóm các kiểu Đơn vị Cấu
hình tương tự nhau.
Certification Cấp chứng chỉ để xác nhận về sự Tuân thủ một Tiêu chuẩn. Việc Chứng nhận bao gồm
(Chứng nhận) cả sự Kiểm toán chính thức bởi một đơn vị độc lập và đã được Công nhận. Khái niệm
Chứng nhận cũng được sử dụng với hàm ý trao giấy chứng nhận để xác minh rằng một
người đã đạt được một trình độ chuyên môn.
Change (Chuyển tiếp Dịch vụ) Việc bổ sung, sửa đổi hoặc loại bỏ bất kỳ điều gì có thể ảnh
(Thay đổi) hưởng tới các Dịch vụ CNTT. Phạm vi nên bao gồm mọi Dịch vụ CNTT, Đơn vị Cấu hình,
Quy trình, Tài liệu, v.v…
Change Advisory Board (Chuyển tiếp Dịch vụ) Một nhóm chuyên gia tư vấn cho Giám đốc (quản lý) Thay đổi
(Hội đồng Cố vấn Thay trong quá trình đánh giá, thiết lập độ ưu tiên và lên lộ trình cho các Thay đổi. Hội
đổi) đồng này thường được thành lập từ tất cả các lĩnh vực trong phạm vi Nhà cung cấp
dịch vụ CNTT, các đại diện của Doanh nghiệp và Bên thứ ba chẳng hạn Nhà cung cấp.
Change History (Chuyển tiếp Dịch vụ) Thông tin về tất cả các thay đổi đã được thực hiệnđối với một
(Lịch sử thay đổi) Đơn vị Cấu hình trong suốt vòng đời của nó. Lịch sử Thay đổi cũng bao gồm tất cả các
Hồ sơ (về sự) Thay đổi áp dụng cho Đơn vị cấu hình.
Change Management (Chuyển tiếp Dịch vụ) Quy trình chịu trách nhiệm cho việc kiểm soát Vòng đời của mọi
(Quản lý thay đổi) Thay đổi. Mục đích chính của Quản lý Thay đổi là để cho phép các Thay đổi có lợi được
thực hiện đồng thời tối thiểu hoá sự gián đoạn của các Dịch vụ CNTT
Change Request Từ đồng nghĩa của Yêu cầu đối với Thay đổi.
(Yêu cầu thay đổi)
Change Schedule (Chuyển tiếp Dịch vụ) Một Tài liệu liệt kê tất cả các Thay đổi đã được phê duyệt và
(Lịch trình thay đổi) ngày triển khai đã được hoạch định. Một Lịch trình Thay đổi đôi khi được gọi là Lịch
trình Chuyển tiếp Thay đổi ngay cả khi nó chứa đựng thông tin về những thay đổi đã
thực sự được triển khai.
Change Window (Chuyển tiếp Dịch vụ) Thời điểm thường lệ, đã được thoả thuận để các Thay đổi hoặc
(Cửa sổ thay đổi) các Bản phát hành được triển khai với sự tác động ít nhất tới các Dịch vụ. Cửa sổ Thay
đổi thường được lập thành văn bản trong Thoả thuận Mức Dịch vụ (SLA).
Charging (Chiến lược Dịch vụ) Yêu cầu thanh toán cho các Dịch vụ CNTT. Định phí cho các Dịch
(Định phí) vụ CNTT là sự lựa chọn và rất nhiều Tổ chức xem nhà cung cấp Dịch vụ CNTT như là
Trung tâm Chi phí của họ.
Classification Hành động chỉ định một Thể loại cho một cái gì đó. Sự Phân loại được sử dụng để đảm
(Phân loại) bảo sự nhất quán trong quản lý và báo cáo. Các Đơn vị cấu hình, Sự cố, Vấn đề, Sự
thay đổi, v.v… thường được phân loại.
Client Một thuật ngữ chung mang nghĩa Khách hàng, Doanh nghi ệp hoặc một Khách hàng
(Khách hàng) (của) Doanh nghiệp. Ví dụ, Nhà quản lý Khách hàng cũng có thể được sử dụng như từ
đồng nghĩa của Quản lý Kinh doanh.
Khái niệm Khách hàng cũng thường được sử dụng để chỉ:
- Một máy tính được sử dụng trực tiếp bởi người sử dụng, ví dụ, một Máy tính cá
nhân, một Máy tính Cầm tay hoặc một Máy trạm.
- Một phần của Ứng dụng Máy chủ - Máy trạm mà Người sử dụng tương tác trực
tiếp với nó, ví dụ phần mềm thư điện tử.
Closed (Vận hành Dịch vụ) Trạng thái cuối cùng trong Vòng đời của một Sự cố, Vấn đề, Thay
(Đã đóng) đổi, v.v… Khi Trạng thái là Đã đóng, không có bất kỳ một hành động nào khác được
triển khai, thực thi thêm.
Closure (Vận hành Dịch vụ) Hành động thay đổi Trạng thái của Sự cố, Vấn đề, (sự) Thay đổi,
((Hành động) Đóng) v.v… thành Đã đóng
COBIT (Liên tục Cải tiến Dịch vụ) COBIT – Các mục tiêu Kiểm soát đối với Thông tin và Công
(COBIT) nghệ liên quan cung cấp hướng dẫn cũng như Thực tiễn Tốt nhất cho sự quản lý các
Quy trình CNTT. COBIT được công bố bởi Học viện Quản trị CNTT (ISACA). Tham khảo
thêm tại
Cold Stvàby
(Trạng thái chờ

“nguội”)
Commercial off the (Thiết kế Dịch vụ) Phần mềm ứng dụng hay Phần mềm trung gian mà có thể mua được
Shelf (COTS) từ Bên thứ ba
Compliance Việc Đảm bảo rằng một Tiêu chuẩn hoặc bộ các Hướng dẫn được tuân theo, hay các
(Tuân thủ) phương pháp kế toán hoặc các thực tiễn khác nhất quán và đúng đắn đang được sử
dụng.
Component Thuật ngữ chung để chỉ một phần của một cái gì đó phức tạp hơn. Ví dụ, một Hệ thống
(Thành phần) máy tính có thể là một thành phần của một Dịch vụ CNTT, một Ứng dụng có thể là
thành phần của Đơn vị Phát hành. Các Thành phần cần được quản lý nên là các Đơn vị
Cấu hình.
Component Capacity (Thiết kế Dịch vụ) (Liên tục Cải tiến Dịch vụ) Quy trình chịu trách nhiệm cho việc tìm
Management hiểu Công suất, Mức độ sử dụng, Hiệu suất của các Đơn vị Cấu hình. Dữ liệu được thu
(Quản lý Công suất thập, lưu trữ và phân tích để sử dụng trong Kế hoạch Công suất. Xem thêm Quản lý
Thành phần) Công suất Dịch vụ.
Component CI Một Đơn vị cấu hình là một phần, một bộ phận của một Tổ hợp. Ví dụ, một Đơn vị Cấu
(Đơn vị Cấu hình Thành hình CPU hay Bộ nhớ có thể là một thành phần, một bộ phận của Đơn vị Cấu hình Máy
phần) chủ.
Component Failure (Thiết kế Dịch vụ) Một Kỹ thuật giúp xác định tác động của Đơn vị cấu hình lỗi đối với
Impact Analysis các Dịch vụ CNTT. Một ma trận sẽ được tạo ra các Dịch vụ CNTT trên một cạnh và các
(Phân tích Tác động Đơn vị Cấu hình trên cạnh còn lại. Ma trận sẽ giúp xác định những Đơn vị Cấu hình
của Thành phần bị Lỗi) quan trọng (có thể gây ra sự cố cho nhiều Dịch vụ CNTT) và những Dịch vụ CNTT
“mong manh, dễ vỡ” (có nhiều Điểm Đơn Lỗi – Single Point of Failure)
Concurrency Một số đo số lượng Người sử dụng đồng thời tham gia vào cùng một hoạt động Vận
(Đồng thời) hành tại cùng một thời điểm.
Confidentiality (Thiết kế Dịch vụ) Một nguyên tắc bảo mật đòi hỏi rằng dữ liệu chỉ được truy cập bởi
(Tính bảo mật) người sử dụng được cấp phép.
Configuration (Chuyển tiếp Dịch vụ) Một thuật ngữ chung, được sử dụng để mô tả một nhóm các Đơn
(Cấu hình) vị Cấu hình làm việc cùng nhau để cung cấp một Dịch vụ CNTT, hay một phần có thể
được nhìn nhận của một Dịch vụ CNTT. Cấu hình cũng thường được sử dụng để mô tả
các tham số thiết lập của các Đơn vị Cấu hình.
Configuration Baseline (Chuyển tiếp Dịch vụ) Một Đường cơ sở Cấu hình đã được thỏa thuận một cách chính
(Đường cơ sở Cấu hình) thức và được quản trị bởi Quy trình quản lý (sự) Thay đổi. Một Đường cơ sở Cấu hình
được sử dụng như cơ sở cho các Thiết lập, Bản phát hành và Thay đổi trong tương lai
Configuration Control (Chuyển tiếp Dịch vụ) Hành động chịu trách nhiệm cho việc đảm bảo rằng sự thêm,
(Kiểm soát cấu hình) chỉnh sửa hay loại bỏ một Đơn vị Cấu hình được quản lý một cách đúng đắn, ví dụ, bởi
sự đệ trình Yêu cầu Thay đổi hoặc yêu cầu Dịch vụ.
Configuration (Chuyển tiếp Dịch vụ) Hành động chịu trách nhiệm cho việc thu thập thông tin về các
Identification Đơn vị Cấu hình và Mối quan hệ giữa chúng, sau đấy đưa những thông tin này vào Cơ
(Xác định Cấu hình) sở dữ liệu Quản lý Cấu hình (CMDB - Configuration Management Database). Vi ệc Xác
định Cấu hình đồng thời cũng chịu trách nhiệm gán nhãn cho bản thân các Đơn vị Cấu
hình, để từ đó, Hồ sơ Cấu hình tương ứng có thể được tìm thấy (khi cần thiết)
Configuration Item (Chuyển tiếp Dịch vụ) Bất kỳ Thành phần nào cần được quản lý nhằm cung cấp một
(Đơn vị Cấu hình) Dịch vụ CNTT. Thông tin về mỗi Đơn vị Cấu hình được lưu lại trong một Hồ sơ Cấu hình
trong Hệ thống Quản lý Cấu hình và được duy trì trong suốt Vòng đời của nó bởi Quản
lý Cấu hình. Các Đơn vị Cấu hình được kiểm soát bởi Quản lý (sự) Thay đổi. Các Đơn
vị cấu hình thông thường bao gồm các Dịch vụ CNTT, phần cứng, phần mềm ứng dụng,
các tòa nhà, con người, các tài liệu chính thống như tài liệu Quy trình, các Thoả thuận
Mức Dịch vụ.
Configuration (Chuyển tiếp Dịch vụ) Quy trình chịu trách nhiệm cho việc duy trì, bảo dưỡng thông tin
Management về các Đơn vị Cấu hình cần thiết để cung cấp một Dịch vụ CNTT, bao gồm Mối liên hệ
(Quản lý Cấu hình) giữa chúng (các Đơn vị cấu hình). Các thông tin này được quản trị trong suốt Vòng đời
của Đơn vị Cấu hình. Quản lý Cấu hình là một phần, một bộ phận của Quy trình Quản
lý Cấu hình và tài sản Dịch vụ tổng thể.
Configuration (Chuyển tiếp Dịch vụ) Một bộ các công cụ và cơ sở dữ liệu được sử dụng để quản lý dữ
Management System liệu về Cấu hình của một nhà cung cấp Dịch vụ CNTT. CMS (Hệ thống Quản lý Cấu
(Hệ thống Quản lý Cấu hình) cũng bao gồm những thông tin về các Sự cố, Vấn đề, Lỗi Đã biết, Thay đổi và
hình) Bản phát hành; và có thể bao gồm dữ liệu về nhân viên, Nhà cung cấp, vị trí, các Đơn
vị Kinh doanh, Khách hàng và Người sử dụng. CMS bao gồm các công cụ để thu thập,
lưu trữ, quản lý, cập nhật, và trình bày dữ liệu về mọi Đơn vị Cấu hình và Mối quan hệ
của chúng. CMS được duy trì bởi Quản lý Cấu hình và được sử dụng bởi mọi Quy trình
Quản lý Dịch vụ CNTT. Xem thêm Hệ thống Quản lý Kiến thức Dịch vụ.
Continual Service (Liên tục Cải tiến Dịch vụ) Một giai đoạn trong Vòng đời của một Dịch vụ CNTT và là
Improvement một tiêu đề của một trong những ấn phẩm cốt lõi của ITIL. Liên tục Cải tiến Dịch vụ
(Liên tục Cải tiến Dịch chịu trách nhiệm cho việc quản lý sự cải tiến của các Quy trình Quản lý Dịch vụ CNTT
vụ) cũng như các Dịch vụ CNTT. Hiệu suất của Nhà cung cấp Dịch vụ CNTT liên tục được
đo lường, và sự cải tiến được thực hiện trên các Quy trình, Dịch vụ CNTT, Cơ sở Hạ
tầng CNTT để nâng cao Tính hiệu quả, Năng suất và Hiệu quả chi phí. Tham khảo
Plan-Do-Check-Act (Lên kế hoạch-Thực thi-Kiểm tra-Hành động).
Continuous Availability (Thiết kế Dịch vụ) Một phương pháp tiếp cận hoặc thiết kế để đạt được hiệu suất
(Tính sẵn sàng Liên 100% về Tính sẵn sàng. Một Dịch vụ CNTT Liên tục Sẵn sàng là không có Thời gian
tục) gián đoạn bất kể có được lập kế hoạch hay không.
Continuous Operation (Thiết kế Dịch vụ) Một phương pháp tiếp cận hoặc thiết kế để giảm thiểu Thời gian
(Vận hành liên tục) gián đoạn được Lập kế hoạch của một Dịch vụ CNTT. Lưu ý rằng các Đơn vị Cấu hình
có thể không hoạt động ngay cả khi Dịch vụ CNTT vẫn luôn sẵn sàng.
Contract Một Thoả thuận mang tính pháp lý giữa hai hay nhiều bên.
(Hợp đồng)
Control Có nghĩa là quản lý Rủi ro, đảm bảo đạt được một mục tiêu của Doanh nghiệp, hay
(Kiểm soát) đảm bảo rằng một Quy trình được tuân thủ. Ví dụ về các Kiểm soát bao gồm: các Chính
sách, Thủ tục, Vai trò, RAID, khoá cửa, v.v… Một Kiểm soát, đôi khi được gọi là Biện
pháp đối phó hoặc bảo vệ. Kiểm soát cũng có nghĩa là quản lý mức độ sử dụng hoặc
hành vi của một Đơn vị Cấu hình, Hệ thống hoặc Dịch vụ CNTT.
Control Perspective (Chiến lược Dịch vụ) Một phương pháp tiếp cận để quản lý các Dịch vụ CNTT, Quy
(Quan điểm kiểm soát) trình, Chức năng, Tài sản, v.v… Có thể có nhiều Quan điểm Kiểm soát khác nhau cho
cùng một Dịch vụ CNTT, Quy trình, v.v… cho phép các cá nhân hay đội ngũ tập trung
vào những điều quan trọng và có liên quan tới vai trò cụ thể của họ. Ví dụ, Quan điểm
Kiểm soát bao gồm Đối phó, Quản lý Chủ động trong Vận hành CNTT, hay cái nhìn
Vòng đời đối với một đội Dự án Ứng dụng.
Cost Tổng lượng tiền đã chi tiêu cho một Hoạt động, Dịch vụ CNTT hay một Đơn vị Kinh
(Chi phí) doanh cụ thể. Chi phí bao gồm chi phí thực (tiền), chi phí ước tính chẳng hạn như thời
gian của con người và Khấu hao.
Cost Benefit Analysis Một Hoạt động phân tích và so sánh Chi phí với lợi ích có liên quan đến một hay nhiều
(Phân tích lợi ích chi chuỗi hành động thay thế khác. Xem thêm Đề án Kinh doanh, Lợi tức của Khoản đầu tư
phí)
Cost Effectiveness Một đại lượng đo lường sự cân bằng giữa tính Hiệu quả và Chi phí của một Dịch vụ,
(Hiệu quả (của) chi Quy trình hay hoạt động. Một Quy trình Hiệu quả (của) Chi phí là một quy trình đạt
phí) được các Mục tiêu của nó với Chi phí tối thiểu. Xem thêm KPI, Lợi tức Đầu tư, Giá trị
của tiền.
Countermeasure Có thể đượ sử dụng để chỉ bất kỳ loại Kiểm soát nào. Khái niệm Biện pháp đối phó
(Biện pháp đối phó) thường được sử dụng khi tham chiếu để đo lường Khả năng phục hồi, Khả năng chịu lỗi
hay Độ tin cậy của một Dịch vụ CNTT.
Crisis Management (Quản lý Liên tục Dịch vụ CNTT) Quản lý Khủng hoảng là một quy trình chịu trách
(Quản lý khủng hoảng) nhiệm cho việc quản lý hàm ý rộng hơn của Liên tục Kinh doanh. Một đội Quản lý
Kkhủng hoảng chịu trách nhiệm về các vấn đề mang tính Chiến lược chẳng hạn như
quản lý quan hệ công chúng, củng cố niềm tin của các cổ đông, và quyết định khi nào
thì thực thi Kế hoạch Liên tục Kinh doanh.
Critical Success Factor Điều gì đó sẽ phải diễn ra nếu một Quy trình, Dự án, Kế hoạch hay Dịch vụ CNNT được
(CSF) thành công. Các KPI được sử dụng để đo lường thành tích đạt được của mỗi CSF. Ví
(Yếu tố thành công dụ, một Yếu tố Thành công quan trọng về “bảo vệ Dịch vụ CNTT khi thực hiện các Thay
quan trọng) đổi” có thể được đo lường bởi các KPI như “giảm tỷ lệ % của các Thay đổi không thành
công” hoặc “ giảm tỷ lệ % các Thay đổi có thể gây ra Sự cố”, v.v…
Culture Một tập hợp các giá trị được chia sẻ bởi một nhóm người (cộng đồng) bao gồm các kỳ
(Văn hoá) vọng về cách mọi người nên cư xử như thế nào, các ý tưởng, niềm tin và hành động
của họ. Xem thêm Tầm nhìn.
Customer Một ai đó mua hàng hoá hoặc các Dịch vụ. Khách hàng của một Nhà cung cấp Dịch vụ
(Khách hàng) CNTT là cá nhân hay một nhóm người xác định và thoả thuận về các Mức Dịch vụ được
nhắm mục tiêu. Khái niệm Khách hàng thỉnh thoảng được sử dụng một cách không
chính thức để chỉ “Người sử dụng”, ví dụ “đây là một Tổ chức hướng tới Khách hàng”.
Dashboard (Vận hành Dịch vụ) Một sự thể hiện bằng đồ hoạ về Hiệu suất và Tính sẵn sàng tổng
(Bảng thống kê) thể của Dịch vụ CNTT. Các hình ảnh trong Bảng thống kê có lẽ được cập nhật theo thời
gian thực cũng như có thể được đưa vào các báo cáo quản lý và trằng web. Các Bảng
thống kê có thể được sử dụng để hỗ trợ Quản lý Mức Dịch vụ, Quản lý Sự kiện, Chẩn
đoán Sự cố.
Deliverable Điều gì đó cần phải được cung cấp để đáp ứng các cam kết trong Thoả thuận Mức Dịch
(Sản phẩm đầu ra) vụ hay một Hợp đồng. Sản phẩm có thể cung cấp được cũng được sử dụng một cách
không chính thức để chỉ đầu ra đã được lên kế hoạch của bất kỳ Quy trình nào.
Demvà Management Các Hoạt động tìm hiểu và ảnh hưởng đến nhu cầu của Khách hàng về Dịch vụ đồng
(Quản lý Nhu cầu) thời cung cấp đú công suất để đáp ứng các nhu cầu đó. Ở mức Chiến lược, Quản lý
Nhu cầu có thể tham gia vào phân tích các Hình mẫu của Hoạt động Doanh nghiệp, Đặc
tả Người sử dụng. Ở mức chiến thuật, Quản trị nhu cầu có thể tham gia vào việc áp
dụng Cách Định phí Khác nhau để khuyến khích Khách hàng sử dụng các Dịch vụ CNTT
vào giờ thấp điểm. Xem thêm Quản trị công suất
Dependency Sự phụ thuộc, trực tiếp hoặc gián tiếp của một Quy trình hay Hoạt động vào một Quy
(Phụ thuộc) trình hay Hoạt động khác
Deployment (Thiết kế Dịch vụ) Hoạt động chịu trách nhiệm về việc đưa một phần cứng, phần mềm
(Triển khai) ứng dụng, tài liệu, quy trình, v.v… mới hoặc đã được thay đổi vào Môi trường “Thật”.
Triển khai là một phần của Quy trình Quản lý Phát hành và Triển khai.
Design (Thiết kế Dịch vụ) Một Hoạt động hay Quy trình xác định các Yêu cầu sau đó định
(Thiết kế) nghĩa một giải pháp có khả năng đáp ứng các Yêu cầu đó. Tham khảo Thiết kế Dịch
vụ.
Detection (Vận hành Dịch vụ) Một giai đoạn trong Vòng đời Sự cố. Kết quả của Nhận diện là Sự
(Nhận diện) cố trở thành đã biết (đã được ghi nhận) bới nhà cung cấp Dịch vụ. Nhận diện có thế là
tự động hoá hoặc là kết quả của một quá trình ghi nhận Sự cố bởi người sử dụng
Development (Thiết kế Dịch vụ) Quy trình chịu trách nhiệm tạo ra hoặc chỉnh sửa một Dịch vụ hoặc
(Phát triển) Ứng dụng CNTT. Cũng được sử dụng để chỉ một Vai trò hoặc một nhóm chịu trách
nhiệm về công việc Phát triển
Development (Thiết kế Dịch vụ) Một Môi trường được sử dụng để tạo ra hoặc điều chỉnh các Dịch vụ
Environment hoặc Ứng dụng CNTT. Các Môi trường phát triển thông thường không có cùng cấp độ
(Môi trường phát triển) kiểm soát như Môi trường Thử nghiệm hay Môi trường “Thật”. Xem thêm Phát triển.
Diagnosis (Vận hành Dịch vụ) Một giai đoạn trong Vòng đời của Sự cố và Vấn đề. Mục đích của
(Chẩn đoán) Chẩn đoán là để xác định Cách giải quyết cho một Sự cố hoặc một Nguyên nhân gốc
của một Vấn đề
Differential Charging Một kỹ thuật sử dụng để hỗ trợ Quản lý Nhu cầu bằng cách tính phí khác nhau cho
(Tính giá phân biệt) cùng Chức năng Dịch vụ CNTT nhưng tại các thời điểm khác nhau
Document Thông tin dưới dạng có thể đọc được. Một Tài liệu có thể là tài liệu giấy hoặc tài liệu
(Tài liệu) điện tử. Ví dụ, một tuyên bố Chính sách, Thoả thuận mức dịch vụ, Hồ sơ Sự cố, sơ đồ
bố trí phòng máy tính. Xem thêm Hồ sơ
Downtime (Thiết kế Dịch vụ) (Vận hành Dịch vụ) Khoảng thời gian mà một Đơn vị cấu hình hoặc
(Thời gian gián đoạn) Dịch vụ CNTT không Sẵn sàng phục vụ theo Thời gian Dịch vụ đã Thoả thuận. Tính sẵn
sàng của một Dịch vụ CNTT thường được tính toán dựa vào Thời gian Dịch vụ đã Thoả
thuận và Thời gian gián đoạn
Driver Một điều gì đó có thể gây ảnh hưởng tới Chiến lược, Mục tiêu hoặc các Yêu cầu. Ví dụ,
(Yếu tố thúc đẩy) các quy định mới của luật pháp, các hành động của các đối thủ cạnh tranh
Economies of scale (Chiến lược Dịch vụ) Mức giảm trung bình có thể của Chi phí, có được từ việc tăng
(Tính kinh tế của quy hiệu quả sử dụng của một Dịch vụ hoặc Tài sản CNTT.
mô)
Effectiveness (Liên tục Cải tiến Dịch vụ) Một thước đo xác định xem Mục tiêu của một Quy trình,
(Tính hiệu quả) Dịch vụ, Hoạt động có đạt được hay không. Một Quy trình hoặc hoạt động có Tính hiệu
quả nếu nó đạt được các Mục tiêu đã thoả thuận. Xem thêm Chỉ số Hiệu năng Chính
yếu (KPI).
Efficiency (Liên tục Cải tiến Dịch vụ) Một thước đo xác định chính xác nguồn lực đã được sử
(Tính tối ưu) dụng để cung cấp một Quy trình, Dịch vụ hoặc Hoạt động. Một Quy trình tối ưu đạt
được các Mục tiêu của mình với thời gian, con người, tiền, hay nguồn lực khác là ở
mức tối thiểu. Xem thêm Chỉ số Hiệu năng Chính yếu (KPI).
Environment (Chuyển tiếp Dịch vụ) Một nhóm Hạ tầng CNTT được sử dụng cho một mục đích cụ thể
Môi trường nào đó. Ví dụ, Môi trường Thật, Môi trường Thử nghiệm, Môi trường Phát triển. Có khả
năng để Nhiều Môi trường khác nhau cùng chia sẻ một Đơn vị cấu hình với nhau, ví dụ,
Môi trường Thử nghiệm và Môi trường Thật có thể sử dụng các phần được dành riêng
của một máy chủ lớn duy nhất. Cũng được sử dụng trong thuật ngữ Môi trường Vật lý
để chỉ các phòng đủ tiện nghi, hệ thống điều hoà không khí, hệ thống cung cấp điện,
v.v…
Môi trường cũng được sử dụng như một thuật ngữ chung để chỉ các điều kiện bên
ngoài tác động hoặc ảnh hưởng tới một cái gì đó
Error (Vận hành Dịch vụ) Một lỗ hổng thiết kế hoặc trục trặc gây ra một Hư hỏng cho một
(Lỗi) hay nhiều Đơn vị Cấu hình hoặc các Dịch vụ CNTT. Một lỗi gây ra bởi con người hoặc
một lỗi Quy trình tác động tới một Đơn vị cấu hình hay Dịch vụ CNTT cũng là một Lỗi.
Escalation (Vận hành Dịch vụ) Một Hoạt động giành được thêm những Nguồn lực bổ sung khi cần
(Sự leo thàng) thiết để đáp ứng được mục tiêu mức Dịch vụ hoặc những kỳ vọng của Khách hàng. Sự
leo thàng có thể cần tới trong bất kỳ Quy trình Quản lý Dịch vụ CNTT nào, nhưng
thông thường được kết hợp với Quản lý Sự cố, Quản lý Vấn đề, Quản lý (sự) phàn nàn
của Khách hàng. Có hai loại Leo thàng: Leo thàng về Chức năng, Leo thàng theo Thứ
bậc.
eSourcing Capability (Chiến lược Dịch vụ) Một khuôn khổ để giúp các Nhà cung cấp Dịch vụ CNTT phát triển
Model for Service những Năng lực Quản lý Dịch vụ CNTT của họ từ khía cạnh Nguồn cung cấp Dịch vụ.
Providers (eSCM-SP) eSCM-SP được phát triển bởi Trường Đại học Carnegie Mellon, Hoa Kỳ.
(Mô hình Năng lực

nguồn cung cấp dịch vụ
cho Nhà cung cấp dịch
vụ)
Estimation Sử dụng kinh nghiệm để đưa ra một giá trị xấp xỉ gần đúng cho một Đại lượng đo đạc
(Ước tính) hoặc Chi phí. Sự ước tính cũng được sử dụng trong lĩnh vực Quản lý Công suất và Tính
sẵn sàng như một phương pháp rẻ nhất nhưng kém chính xác nhất
Evaluation (Chuyển tiếp Dịch vụ) Quy trình chịu trách nhiệm cho việc đánh giá một Dịch vụ CNTT
(Đánh giá) mới hoặc đã được thay đổi, nhằm đảm bảo rằng các Rủi ro đã được quản lý, đồng thời
giúp xác định xem có cần thiết phải tiến hành Thay đổi hay không.
Sự đánh giá cũng được sử dụng để chỉ sự so sánh giữa một Kết quả thực tế với Kết
quả dự định, hay so sánh một giải pháp thay thế với giải pháp khác
Event (Vận hành Dịch vụ) Một sự thay đổi trạng thái đáng quan tâm đối với việc quản lý một
(Sự kiện) Đơn vị cấu hình hoặc Dịch vụ CNTT.
Khái niệm Sự kiện cũng được sử dụng để chỉ một Cảnh báo hoặc thông báo được tạo ra
bởi Dịch vụ CNTT, Đơn vị cấu hình, hoặc Công cụ Giám sát. Sự kiện thường yêu cầu
các nhân viên Vận hành CNTT thực thi csac hành động, thường sẽ dẫn tới kết quả là
các Sự cố được ghi nhận lại.
Event Management (Vận hành Dịch vụ) Quy trình chịu trách nhiệm cho việc quản lý các Sự kiện trong
(Quản lý Sự kiện) suốt Vòng đời của chúng. Quản lý Sự kiện là một trong những Hoạt động chính của
Vận hành CNTT
Exception Report Một tài liệu chứa đựng các thông tin chi tiết về một hoặc nhiều Chỉ số Hiệu năng Chính
(Báo cáo về sự ngoại yếu hoặc các mục tiêu quan trọng khác đã vượt quá Ngưỡng đã định. Ví dụ bao gồm
lệ) các mục tiêu trong Thoả thuận Mức Dịch vụ không đạt hoặc có thể không đạt, và một
Đại lượng đo Hiệu suất chỉ ra các vấn đề tiềm tàng về Công suất
Excitement Attribute Xem Yếu tố kích thích
Thuộc tính kích thích
Expvàed Incident (Quản lý Tính sẵn sàng) Chi tiết các giai đoạn trong Vòng đời của một Sự cố. Các giai
Lifecycle đoạn đó là Nhận diện, Chẩn đoán, Sửa chữa, Khôi phục, Phục hồi. Vòng đời Sự cố Mở
(Vòng đời sự cố mở rộng được sử dụng để giúp hiểu về tất cả các đóng góp vào Tác động của các Sự cố
rộng) cũng như lên Kế hoạch về việc làm thế nào để kiểm soát hoặc giảm thiểu các tác động
đấy như thế nào.
External Service (Chiến lược Dịch vụ) Một nhà cung cấp Dịch vụ CNTT là một phần của một Doanh
Provider nghiệp/Tổ chức khác với Khách hàng của họ. Một nhà cung cấp Dịch vụ CNTT có thể có
(Nhà cung cấp dịch vụ cả Khách hàng Bên ngoài và Khách hàng N ội bộ.
bên ngoài)
External Sourcing Xem Thuê ngoài
(Nguồn cung bên

ngoài)
Facilities Management (Vận hành Dịch vụ) Chức năng chịu trách nhiệm cho việc quản lý Môi trường vật lý nơi
(Quản lý Cơ sở vật Hạ tầng CNTT được xác lập. Quản lý Cơ sở vật chất bao gồm mọi khía cạnh về quản lý
chất) Môi trường vật lý, ví dụ như: nguồn điện, làm mát, Quản lý Truy cập Tòa nhà, Giám
sát môi trường.
Failure (Vận hành Dịch vụ) Mất khả năng Vận hành theo đặc tả kỹ thuật, hoặc mất khả năng
(Lỗi) cung cấp đầu ra cần thiết. Thuật ngữ này cũng được sử dụng khi đề cập tới Dịch vụ
CNTT, Quy trình, Hoạt động, Đơn vị cấu hình, v.v… Một Lỗi thường gây ra một Sự cố.
Fast Recovery (Thiết kế Dịch vụ) Một Lựa chọn Khôi phục còn được gọi là Trạng thái chờ “Nóng”. Dự
(Khôi phục Nhanh) phòng được đưa ra để Khôi phục Dịch vụ CNTT trong thời gian ngắn nhất, thường là
dưới 24 giờ. Khôi phục nhanh thường sử dụng một Cơ sở vật chất Cố định chuyên dụng
với Hệ thống máy tính, phần mềm được thiết lập cấu hình sẵn sàng để chạy các Dịch
vụ CNTT. Khôi phục Nhanh có thể mất tới 24 giờ nếu có yêu cầu Khôi phục dữ liệu từ
các Bản sao lưu.
Fault Xem Error
(Lỗi)
Fault Tolerance (Thiết kế Dịch vụ) Khả năng của một Dịch vụ CNTT hay một Đơn vị cấu hình vẫn có thể
(Khả năng chịu lỗi) tiếp tục hoạt động một cách đúng đắn sau khi một Thành phần nào đó bị Lỗi. Xem
thêm Khả năng phục hồi, Phương án thay thế.
Fault Tree Analysis (Thiết kế Dịch vụ) (Liên tục Cải tiến Dịch vụ) Một kỹ thuật có thể được sử dụng để xác
(Phân tích Cây Lỗi) định chuỗi các Sự kiện dẫn đến một Vấn đề. Phân tích Cây Lỗi thể hiện một chuỗi các
Sự kiện bằng cách sử dụng ký hiệu Boolean trong một sơ đồ.
Financial Management (Chiến lược Dịch vụ) Chức năng và các Quy trình chịu trách nhiệm quản trị việc Lập
(Quản lý Tài chính) ngân sách, Hạch toán và Yêu cầu Tính phí của một Nhà cung cấp dịch vụ CNTT.
Fit for Purpose Một thuật ngữ không chính thức được sử dụng để mô tả rằng một Quy trình, Đơn vị
(Phù hợp với Mục đích) cấu hình, Dịch vụ CNTT, v.v… là đủ khả năng đáp ứng các mục tiêu hoặc Mức dịch vụ.
Đáp ứng mục tiêu đòi hỏi một thiết kế, triển khai, kiểm soát, duy trì thích hợp
Fulfilment Thực hiện các Hoạt động nhằm đạt được một nhu cầu hoặc Yêu cầu. Ví dụ, bởi việc
(Hoàn thành) cung cấp một dịch vụ công nghệ thông tin mới hoặc đáp ứng được một yêu cầu Dịch
vụ.
Function Một đội/nhóm người và các công cụ họ sử dụng để giải quyết một hay nhiều Quy trình
(Chức năng) hoặc Hoạt động. Ví dụ như Service Desk.
Thuật ngữ chức năng đồng thời có 02 nghĩa khác:
- Một mục đích được nhắm đến của một Đơn vị Cấu hình, Con người, Đội nhóm,
Quy trình hay Dịch vụ CNTT. Ví dụ như một Chức năng của một Dịch vụ email có
thể để lưu và chuyển tiếp thư đi ra ngoài, một Chức năng của Quy trình Nghiệp
vụ là gửi hàng tới Khách hàng.
- Để thực hiện mục đích được nhắm đến một cách đúng đắn, “Máy tính là Chức
năng”.
Governance Việc đảm bảo rằng các Chính sách và Chiến lược được triển khai một cách thực tế, và
(Quản trị) rằng các Quy trình cần thiết được tuân thủ một cách đúng đắn. Quản trị bao gồm việc
xác định các Vai trò và trách nhiệm, đo lường và báo cáo, và có các hành động để xử
trí bất kì các vấn đề được xác định.
Gradual Recovery (Thiết kế Dịch vụ) Một Lựa chọn Khôi phục được hiểu như là Cold Stanby. Dự phòng
(Khôi phục Dần dần) được đưa ra để khôi phục Dịch vụ CNTT trong một khoảng thời gian nhiều hơn 72 giờ.
Khôi phục Dần dần thường sử dụng một Cơ sở Di động hoặc Cố định có môi trường hỗ
trợ và hệ thống mạng có dây nhưng không có hệ thống máy tính. Phần cứng và phần
mềm được cài đặt như là một phần của dịch vụ Kế hoạch Liên tục Dịch vụ CNTT.
Guideline Một Tài liệu mô tả Thực tiễn Tốt nhất, khuyến nghị về những gì nên được hoàn thành.
(Hướng dẫn) Việc tuân thủ một hướng dẫn thường là không bắt buộc. Xem thêm Tiêu chuẩn.
High Availability (Thiết kế Dịch vụ) Một phuong pháp tiếp cận hoặc thiết kế nhằm làm giảm thiểu hoặc
(Tính sẵn sàng Cao) “che dấu” những tác động của việc một Đơn vị cấu hình bị lỗi đối với người sử dụng
một Dịch vụ CNTT. Các giải pháp có Tính sẵn sàng Cao được thiết kế để đạt được một
mức đã được thỏa thuận về Tính sẵn sàng và thường sử dụng các công nghệ chẳng hạn
như Chịu lỗi, Khả năng phục hồi và Khôi phục nhanh để giảm thiểu số lượng Sự cố và
Ảnh hưởng của các Sự cố.
Hot Stvàby Xem Khôi phục nhanh hoặc Khôi phục Ngay lập tức.
(Trạng thái chờ Nóng)
Immediate Recovery (Thiết kế Dịch vụ) Một Lựa chọn Khôi phục, được còn được hiểu như là Hot Stvàby. Dự
(Khôi phục Tức thời) phòng được đưa ra để Khôi phục Dịch vụ CNTT mà không bị gián đoạn dịch vụ. Khôi
phục Tức thời thường sử dụng công nghệ Phản chiếu (Mirroring), Cân bằng Tải và Phân
tách Địa điểm.
Impact (Vận hành Dịch vụ) (Chuyển tiếp Dịch vụ) Một thước đo sự ảnh hưởng của một Sự cố,
(Ảnh hưởng) Vấn đề hay Sự thay đổi đối với các Quy trình Nghiệp vụ. Ảnh hưởng thường dựa trên
việc các cấp độ Dịch vụ bị ảnh hưởng thế nào. Ảnh hưởng và Sự cấp bách thường được
sử dụng để chỉ định Độ ưu tiên.
Incident (Vận hành Dịch vụ) Một sự gián đoạn Dịch vụ CNTT nằm ngoài kế hoạch hoặc sự sụt
(Sự cố) giảm Chất lượng của một Dịch vụ CNTT. Lỗi của một Đơn vị cấu hình tuy không ảnh
hưởng tới Dịch vụ nhưng cũng được coi là một Sự cố. Ví dụ, lỗi của một đĩa trong bộ
đĩa phản chiếu.
Incident Management (Vận hành Dịch vụ) Quy trình chịu trách nhiệm cho việc quản lý Vòng đời của mọi Sự
(Quản lý Sự cố) cố. Mục đích chủ yếu của Quản lý Sự cố là nhằm cung cấp lại Dịch vụ CNTT đến Khách
hàng càng nhanh càng tốt.
Incident Record (Vận hành Dịch vụ) Một Hồ sơ chứa thông tin chi tiết về một Sự cố. Mỗi hồ sơ Sự cố sẽ
(Hồ sơ Sự cố) tài liệu hóa Vòng đời của một Sự cố đơn lẻ.
Indirect Cost (Chiến lược Dịch vụ) Chi phí để cung cấp một Dịch vụ CNTT nhưng không thể phân bổ
(Chi phí gián tiếp) đầy đủ đến một Khách hàng cụ thể. Ví dụ, Chi phí của việc cung cấp các Máy chủ chia
sẻ hoặc giấy phép sử dụng phần mềm. Còn được biết đến như là Chi phí quản lý.
Information Security (Thiết kế Dịch vụ) Quy trình đảm bảo tính Bảo mật, Toàn vẹn và Sẵn sàng của Tài sản,
Management thông tin, dữ liệu, và các Dịch vụ CNTT của một Tổ chức. Quản lý Bảo mật Thông tin
(Quản lý Bảo mật thường định hình một phần của phương pháp tiếp cận của Tổ chức đối với Quản lý Bảo
Thông tin) mật, có phạm vi rộng hơn nhà cung cấp Dịch vụ CNTT, và bao gồm việc quản lý giấy tờ
sổ sách, truy cập vào tài sản cố định, các cuộc gọi, v.v… cho toàn bộ Tổ chức.
Information Security (Thiết kế Dịch vụ) Một khuôn khổ các Chính sách, Quy trình, Tiêu chuẩn, Hướng dẫn và
Management System công cụ đảm bảo rằng một Tổ chức có thể đạt được các Mục tiêu Quản lý Bảo mật
(ISMS) Thông tin của mình.
(Hệ thống Quản lý Bảo

mật Thông tin)
Information Security (Thiết kế Dịch vụ) Chính sách quản trị phương pháp tiếp cận của một Tổ chức đối với
Policy Quản lý Bảo mật Thông tin.
(Chính sách Bảo mật

Thông tin)
Information Việc sử dụng công nghệ để lưu trữ, truyền thông hay xử lý thông tin. Công nghệ
Technology thường bao gồm các máy tính, kết nối viễn thông, các Ứng dụng và phần mềm khác.
(Công nghệ Thông tin) Thông tin có thể bao gồm dữ liệu của Doanh nghiệp, hình ảnh, âm thanh, phim, v.v…
Công nghệ Thông tin thường được sử dụng để hỗ trợ các Quy trình Nghiệp vụ thông
qua các Dịch vụ CNTT.
Infrastructure Service Một Dịch vụ CNTT không được sử dụng một cách trực tiếp bởi Doanh nghiệp nhưng cần
(Dịch vụ Cơ sở hạ tầng) thiết cho Nhà cung cấp Dịch vụ CNTT để họ có thể cung cấp các Dịch vụ CNTT khác. Ví
dụ, dịch vụ directory, naming service, hay dịch vụ truyền thông.
Insourcing Xem Thuê nguồn lực nội bộ.
(Tự cung cấp)
Integrity (Thiết kế Dịch vụ) Một nguyên tắc bảo mật đảm bảo rằng dữ liệu và các Đơn vị cấu
(Tính toàn vẹn) hình chỉ được thay đổi bởi các cá nhân và các Hoạt động được ủy quyền. Tính Toàn
vẹn xem xét mọi nguyên nhân có thể gây ra sự thay đổi bao gồm Lỗi phần mềm và
phần cứng, các Sự kiện môi trường và lỗi do con người.
Intermediate Recovery (Thiết kế Dịch vụ) Một Lựa chọn Khôi phục thường được biết đến như là Warm Stvàby
(Khôi phục Trung bình) – Trạng thái chờ Ấm. Dự phòng được đưa ra để Khôi phục Dịch vụ CNTT trong một
khoảng thời gian giữa 24 và 72 giờ. Khôi phục Trung bình thường sử dụng một Cơ sở
vật chất Cố định hoặc Di động, có sẵn Hệ thống Mạng và Hệ thống Máy tính. Phần
cứng và phần mềm sẽ cần phải được thiết lập lại cấu hình, dữ liệu sẽ cần được khôi
phục, như một phần của Kế hoạch Liên tục Dịch vụ CNTT.
Internal Service (Chiến lược Dịch vụ) Một nhà cung cấp dịch vụ CNTT và là một bộ phận của cùng
Provider Doanh nghiệp/Tổ chức. Một Nhà cung cấp dịch vụ CNTT có thể có cả Khách hàng nội
(Nhà cung cấp Dịch vụ bộ và Khách hàng bên ngoài.
Nội bộ)
Internal Sourcing (Chiến lược Dịch vụ) Sử dụng một nhà cung cấp Dịch vụ Nội bộ để quản lý các Dịch vụ
“Thuê trong” CNTT.
International Tổ chức Tiêu chuẩn hóa Quốc tế là tổ chức phát triển các Tiêu chuẩn lớn nhất thế giới.
Organization of ISO là một tổ chức phi chính phủ là một mạng lưới bao gồm các viện tiêu chuẩn của
Stvàardization (ISO) 156 quốc gia. Xem thêm thông tin tại trằng http://www.iso.org/. Xem thêm ISO.
(Tổ chức Tiêu chuẩn

hóa Quốc tế)
ISO 9000 Thuật ngữ chung sử dụng để chỉ một số Tiêu chuẩn quốc tế và Hướng dẫn cho Hệ
thống Quản lý Chất lượng. Xem thêm thông tin tại trằng http://www.iso.org/. Xem
thêm ISO.
ISO 9001 Một Tiêu chuẩn quốc tế về Hệ thống Quản lý Chất lượng. Xem thêm ISO 9000, Tiêu
chuẩn.
ISO/IEC 20000 Đặc tả kỹ thuật ISO và Quy tắc Thực hành về Quản lý Dịch vụ CNTT. ISO/IEC 20000
được liên kết với Thực tiễn Tốt nhất ITIL.
ISO/IEC 27001 (Thiết kế Dịch vụ)/(Liên tục Cải tiến Dịch vụ) Đặc tả kỹ thuật ISO về Quản lý Bảo mật
Thông tin. Quy tắc Thực hành tương ứng là ISO/IEC 17799. Xem thêm Tiêu chu ẩn.
IT Infrastructure Tất cả phần cứng, phần mềm, hệ thống mạng, cơ sở vật chất, v.v… cần thiết để phát
(Cơ sở hạ tầng CNTT) triển, Kiểm tra, cung cấp, Giám sát, Kiểm soát hoặc hỗ trợ các Dịch vụ CNTT. Thuật
ngữ Hạ tầng CNTT bao gồm mọi khái niệm liên quan đến CNTT nhưng không liên kết
với Con người, Quy trình và tài liệu.
IT Operations (Vận hành Dịch vụ) Các hoạt động được thực hiện bởi Kiểm soát Vận hành CNTT, bao
(Vận hành CNTT) gồm Quản lý Giao diện điều khiển, Lập kế hoạch làm việc, Sao lưu và Khôi phục, và In
ấn và Quản lý Đầu ra. Vận hành CNTT cũng được sử dụng như là từ đồng nghĩa của
Vận hành Dịch vụ.
IT Service Một Dịch vụ cung cấp cho một hay nhiều Khách hàng bởi một nhà cung cấp Dịch vụ
(Dịch vụ VNTT) CNTT. Một Dịch vụ CNTT dựa trên cơ sở sử dụng Công nghệ thông tin và hỗ trợ các
Quy trình Nghiệp vụ của Khách hàng. Một Dịch vụ CNTT được xây dựng dựa trên cơ sở
kết hợp các yếu tố Con người, các Quy trình và công nghệ, nên được xác định trong
Thỏa thuận Mức Dịch vụ.
IT Service Continuity (Thiết kế Dịch vụ) Quy trình chịu trách nhiệm cho việc quản lý Rủi ro có thể tác động
Management nghiêm trọng đến các Dịch vụ CNTT. ITSCM đảm bảo rằng nhà cung cấp Dịch vụ CNTT
(Quản lý Tính liên tục có thể luôn luôn cung cấp mức Dịch vụ tối thiểu đã được thỏa thuận, bằng cách giảm
Dịch vụ CNTT) thiểu Rủi ro đến một mức có thể chấp nhận được và Lên kế hoạch Khôi phục các Dịch
vụ CNTT. ITSCM nên được thiết kế để hỗ trợ Quản lý Tính liên tục Kinh doanh.
IT Service Continuity (Thiết kế Dịch vụ) Một Kế hoạch xác định các bước cần thiết để Khôi phục một hay
Plan nhiều Dịch vụ CNTT. Kế hoạch cũng xác định các yếu tố kích hoạt Bước khởi đầu
(Kế hoạch Liên tục Dịch (Invocation), các cá nhân liên quan, các kênh truy ền thông, v.v… Kế hoạch liên tục
vụ CNTT) Dịch vụ CNTT nên là một phần của Kế hoạch Liên tục Kinh doanh.
IT Service Management Triển khai và quản lý Chất lượng Dịch vụ CNTT đáp ứng được các nhu cầu của Doanh
(Quản lý Dịch vụ CNTT) nghiệp. Quản lý Dịch vụ CNTT được thực hiện bởi các Nhà cung cấp dịch vụ CNTT
thông qua sự kết hợp hợp lý các yếu tố con người, Quy trình và Công nghệ Thông tin.
Xem thêm Quản lý Dịch vụ.
IT Service Provider (Chiến lược Dịch vụ) Một nhà cung cấp dịch vụ chuyên cung cấp các Dịch vụ CNTT cho
(Nhà cung cấp Dịch vụ Khách hàng kể cả Khách hàng nội bộ và Khách hàng bên ngoài.
CNTT)
IT Steering Group Một nhóm chính thức chịu trách nhiệm cho việc đảm bảo rằng các Chiến lược và Kế
(Nhóm Chỉ đạo CNTT) hoạch của Doanh nghiệp và của Nhà cung cấp Dịch vụ CNTT là nhất quán với nhau. Một
Nhóm Chỉ đạo CNTT bao gồm các đại diện cao cấp từ Doanh nghiệp và Nhà cung cấp
Dịch vụ CNTT.
ITIL Một tập hợp các tài liệu hướng dẫn Thực tiễn Tốt nhất cho Quản lý Dịch vụ CNTT. ITIL
được sở hữu bởi OCG và bao gồm một loạt các ấn phẩm về việc cung cấp Chất lượng
dịch vụ CNTT, và về các Quy trình và các cơ sở cần thiết để hỗ trợ chúng. Xem
www.itil.co.uk để biết thêm thông tin.
Job Description Một Tài liệu xác định Vai trò, trách nhiệm, các kỹ năng và kiến thức cần thiết yêu cầu
(Mô tả Công việc) bởi một người cụ thể. Một Mô tả Công việc có thể bao gồm nhiều Vai trò khác nhau, ví
dụ, vai trò Quản lý Cấu hình và Quản lý Thay đổi có thể được đảm nhận bởi một người.
Job Scheduling (Vận hành Dịch vụ) Lên kế hoạch và quản lý việc thực thi các tác vụ phần mềm được
(Lên lịch trình Công yêu cầu bởi một phần của một Dịch vụ CNTT. Lên lịch trình công việc được thực hiện
việc) bởi Quản lý Vận hành CNTT và thường sử dụng các công cụ phần mềm được tự động để
chạy các tác vụ theo lô hoặc các tác vụ trực tuyến vào những thời gian cụ thể của
ngày, tuần, tháng hoặc năm.
Key Performance (Liên tục Cải tiến Dịch vụ) Một Chỉ số được sử dụng để giúp đỡ quản lý một Quy trình,
Indicator Dịch vụ CNTT hoặc Hoạt động. Nhiều Chỉ số có thể được đo lường, nhưng chỉ có những
(Chỉ số Hiệu suất Chính chỉ số quan trọng nhất sẽ được xác định là KPI và được sử dụng để quản lý và báo cáo
yếu) một cách chủ động về Quy trình, Dịch vụ CNTT hoặc Hoạt động. KPI nên được lựa chọn
để đảm bảo rằng Tính hiệu quả, Hiệu suất và Hiệu quả Chi phí được quản lý toàn bộ.
Xem thêm Yếu tố Thành công Quan trọng.
Knowledge Base (Chuyển tiếp Dịch vụ) Một cơ sở dữ liệu logic bao gồm dữ liệu được sử dụng bởi Hệ
(Cơ sở Kiến thức) thống Quản lý Kiến thức Dịch vụ.
Knowledge (Chuyển tiếp Dịch vụ) Quy trình chịu trách nhiệm cho việc thu thập, phân tích, lưu trữ
Management và chia sẻ kiến thức và thông tin trong một Tổ chức. Mục đích chính của Quản lý Kiến
(Quản lý Kiến thức) thức là để cải thiện tính Hiệu quả bằng cách giảm thiểu yêu cầu tìm hiểu lại kiến thức.
Xem thêm Hệ thống Quản lý Kiến thức Dịch vụ.
Known Error (Vận hành Dịch vụ) Một Vấn đề mà Nguyên nhân chính và Cách giải quyết đã được tài
(Lỗi Đã biết) liệu hóa. Lỗi Đã biết được tạo ra và quản lý trong suốt vòng đời của chúng bằng Quản
trị vấn đề. Lỗi đã biết có thể được xác định bởi Nhà phát triển hoặc Nhà cung cấp.
Lifecycle Các giai đoạn khác nhau trong cuộc đời của một Dịch vụ CNTT, Đơn vị cấu hình, Sự cố,
(Vòng đời) Vấn đề, Thay đổi, v.v… Vòng đời xác định các Thể loại về Trạng thái, và những Chuyển
đổi trạng thái được cho phép. Ví dụ,
- Vòng đời của một Ứng dụng bao gồm: Yêu cầu, Thiết kế, Xây dựng, Triển khai,
Vận hành, Tối ưu hóa.
- Vòng đời Mở rộng của Sự cố bao gồm Nhận diện, Phản hồi, Chẩn đoán, Sửa chữa,
Phục hồi, Khôi phục.
- Vòng đời của một Máy chủ có thể bao gồm: Đã đặt hàng, Đã nhận hàng, Đang
Kiểm tra, Đang Sử dụng, Đã hủy bỏ, v.v…
Line of Service (Chiến lược Dịch vụ) Một Dịch vụ Cốt lõi hoặc một dịch vụ Hỗ trợ có nhiều gói mức
(Tuyến Dịch vụ) Dịch vụ. Một tuyến Dịch vụ được quản lý bởi một Nhà quản lý Sản phẩm (Product
Manager) và mỗi gói mức Dịch vụ được thiết kế để hỗ trợ một phân khúc thị trường cụ
thể.
Live (Chuyển tiếp Dịch vụ) Đề cập tới một Dịch vụ CNTT hay một Đơn vị cấu hình đang
(Đang hoạt động) được sử dụng để cung cấp Dịch vụ cho một Khách hàng
Live Environment (Chuyển tiếp Dịch vụ) Một Môi trường được kiểm soát bao gồm các Đơn vị Cấu hình
(Môi trường Thật) thực tế đang hoạt động được sử dụng để cung cấp các Dịch vụ CNTT cho các Khách
hàng.
Maintainability (Thiết kế Dịch vụ) Một Thước đo về mức độ nhanh chóng và Tính hiệu quả của việc
(Khả năng duy trì) một Đơn vị cấu hình hay Dịch vụ CNTT có thể được khôi phục về tình trạng bình
thường sau khi bị Lỗi. Khả năng duy trì thường được đo lường và báo cáo như là
MTRS.
Khả năng duy trì cũng được sử dụng trong bối cảnh Phát triển Phần mềm hoặc Phát
triển Dịch vụ CNTT để chỉ khả năng có thể Thay đổi hoặc Sửa chữa một cách dễ dàng.
Major Incident (Vận hành Dịch vụ) Thể loại Tác động cao nhất của một Sự cố. Một Sự cố Nghiêm
(Sự cố Nghiêm trọng) trọng sẽ gây ra gián đoạn đáng kể cho Doanh nghiệp.
Managed Service (Chiến lược Dịch vụ) Một quan điểm về các Dịch vụ CNTT nhấn mạnh đến thực tế là
(Dịch vụ được Quản lý) chúng được quản lý. Thuật ngữ Dịch vụ được Quản lý này cũng được sử dụng như là
một từ đồng nghĩa của Dịch vụ CNTT được Thuê ngoài.
Management Thông tin được sử dụng để hỗ trợ việc ra quyết định của các nhà quản lý. Thông tin
Information Quản lý thường được tạo ra một cách tự động bằng các công cụ hỗ trợ các Quy trình
(Thông tin Quản lý) Quản lý Dịch vụ CNTT khác nhau. Thông tin Quản lý thường bao gồm các giá trị của
các KPI chẳng hạn như “Tỷ lệ phần trăm các Thay đổi dẫn tới các Sự cố” hoặc “Tỷ lệ
khắc phục ngay lần đầu tiên”.
Management of Risk Một phương pháp của OCG để quản lý Rủi ro. M_o_R bao gồm mọi Hoạt động cần thiết
(MoR) để xác định và Kiểm soát sự phơi bày đối với Rủi ro có thể có ảnh hưởng đến sự thành
(Quản lý Rủi ro) công của các Mục tiêu Kinh doanh của Tổ chức. Tham khảo http://www/m-o-r.org để
có thêm thông tin.
Management System Một khuôn khổ các Chính sách, Quy trình và Chức năng nhằm đảm bảo một Tổ chức có
(Hệ thống Quản lý) thể đạt được các Mục tiêu của mình.
Manual Workaround Một cách giải quyết đòi hỏi sự can thiệp thủ công. Cách giải quyết Thủ công cũng được
(Cách giải quyết Thủ sử dụng như một tên gọi của một Lựa chọn Khôi phục mà trong đó Vận hành Quy trình
công) Nghiệp vụ không cần sử dụng các Dịch vụ CNTT. Đây là một thước đo tạm thời và
thường được kết hợp với Lựa chọn Khôi phục khác.
Maturity (Liên tục Cải tiến Dịch vụ) Một thước đo vể Độ tin cậy, Hiệu suất và Tính hiệu quả của
(Trưởng thành) một Quy trình, Chức năng, Tổ chức, v.v… Các Quy trình và Chức năng “trưởng thành”
nhất thông thường được liên kết một cách chính thức với các Mục tiêu và Chiến lược
của Doanh nghiệp, và được hỗ trợ bởi một khuôn khổ cải tiến liên tục.
Mean Time Between (Thiết kế Dịch vụ) Một Chỉ số để đo lường và báo cáo về Độ tin cậy. MTBF là thời gian
Failures trung bình mà một Đơn vị cấu hình hay Dịch vụ CNTT có thể hoàn thành chức năng đã
(Thời gian hoạt động) được thỏa thuận mà không bị gián đoạn. Nó được đo bằng thời gian từ khi một Đơn vị
cấu hình hay Dịch vụ CNTT khởi động cho đến khi lần bị lỗi kế tiếp xảy ra.
Mean Time Between (Thiết kế Dịch vụ) Một thước đo sử dụng để đo lường và báo cáo về Độ tin cậy. MTBSI
Service Incidents là thời gian từ khi một Hệ thống hay một Dịch vụ CNTT bị lỗi cho đến lần bị lỗi kế
(Thời gian giữa hai sự tiếp. MTBSI bằng MTBF + MTRS
cố)
Mean Time to Repair Thời gian trung bình cần để sửa chữa một Đơn vị cấu hình hoặc Dịch vụ CNTT sau khi
(Thời gian sửa chữa) bị lỗi. MTTR được đo kể từ khi một Đơn vị cấu hình hay Dịch vụ CNTT bị lỗi cho đến
khi nó (Đơn vị cấu hình hay Dịch vụ CNTT) được sửa chữa. MTTR thỉnh thoảng, được
sử dụng một cách không chính xác để chỉ Thời gian khôi phục dịch vụ).
Mean Time to Restore Thời gian trung bình cần để khôi phục một Đơn vị cấu hình hoặc Dịch vụ CNTT sau khi
Service bị lỗi. MTRS được tính kể từ khi Đơn vị cấu hình hoặc Dịch vụ CNTT bị lỗi cho đến khi
(Thời gian khôi phục nó được hoàn toàn khôi phục và tiếp tục cung cấp chức năng thường lệ. Xem thêm Khả
dịch vụ) năng có thể Bảo trì, MTTR.
Metric (Liên tục Cải tiến Dịch vụ) Một cái gì đó được đo lường và báo cáo để giúp quản lý một
(Chỉ số) Quy trình, Dịch vụ CNTT hoặc Hành động nào đó. Xem thêm KPI.
Middleware (Thiết kế Dịch vụ) Phần mềm kết nối hai hay nhiều Thành phần khác nhau của Phần
(Phần mềm trung gian) mềm hay Ứng dụng. Phần mềm trung gian thường được mua từ Nhà cung cấp, hơn là
tự phát triển bởi Nhà cung cấp dịch vụ CNTT. Xem thêm Off-the-shell.
Model Một đại diện của Hệ thống, Quy trình, Dịch vụ CNTT, Đơn vị cấu hình, v.v… được sử
(Mô hình) dụng để hiểu hoặc dự đoán hành vi trong tương lai.
Modeling Một kỹ thuật được sử dụng để dự đoán hành vi tương lai của một Hệ thống, Quy trình,
(Mô hình hóa) Dịch vụ CNTT, Đơn vị cấu hình, v.v… Mô hình hóa thường được sử dụng trong Quản lý
Tài chính, Quản lý Công suất và Quản lý Tính sẵn sàng.
Monitoring (Vận hành Dịch vụ) Sự quan sát được lặp đi lặp lại về một Đơn vị cấu hình, Dịch vụ
(Giám sát) CNTT hoặc Quy trình để phát hiện các Sự kiện và đảm bảo rằng tình trạng hiện tại
được biết đến.
Objective Mục đích đã được xác định hoặc ý định của một Quy trình, Hành động hay một Tổ chức
(Mục tiêu) như là toàn thể. Các mục tiêu thường được thể hiện dưới dạng các đích nhắm mục tiêu
có thể đo lường được. Khái niệm Mục tiêu cũng được sử dụng để chỉ một Yêu cầu. Xem
thêm Kết quả.
Off-the-Shelf Từ đồng nghĩa của Phần mềm thương mại có sẵn
(Có sẵn)
Office of Government OCG sở hữu thương hiệu ITIL (bản quyền và tên thương mại). OCG là một Cơ quan
Commerce thuộc Chính phủ Anh, giúp hỗ trợ việc phân phối các chương trình mua sắm của Chính
(Văn phòng thương mại phủ thông qua các hoạt động mua sắm hợp tác và nâng cao trình độ, năng lực mua
chính phủ) sắm của các phòng ban. Nó cũng cung cấp sự hỗ trợ cho các dự án công phức tạp
khác.
Off-shore (Chiến lược Dịch vụ) Việc cung cấp Dịch vụ từ một địa điểm bên ngoài quốc gia nơi
(Xa bờ) Khách hàng đặt trụ sở, thường là ở một lục địa khác. Đây có thể là việc cung cấp một
Dịch vụ CNTT, hoặc Chức năng hỗ trợ như một Bộ phận Hỗ trợ Dịch vụ - Service Desk.
Xem thêm On-shore (Tại chỗ), Near-shore (Gần bờ).
On-shore (Chiến lược Dịch vụ) Việc cung cấp dịch vụ từ một địa điểm cùng quốc gia với nơi mà
(Tại chỗ) Khách hàng đặt trụ sở. Tham khảo Off-shore (Xa bờ), Near-shore (Gần bờ).
Operate (Vận hành Dịch vụ) Thực hiện như đã được kỳ vọng. Một Quy trình hay Đơn vị Cấu hình
(Vận hành) được cho là Vận hành nếu nó đang cung cấp một đầu ra được Yêu cầu. Vận hành cũng
có nghĩa là thực hiện một hay nhiều hơn các hoạt động vận hành. Ví dụ, Vận hành một
máy tính nghĩa là thực hiện các hoạt động vận hành hàng ngày cần thiết để hoàn
thành công việc như kỳ vọng.
Operation (Vận hành Dịch vụ) Việc quản lý hàng ngày một Dịch vụ CNTT, Hệ thống hay một Đơn
(Sự vận hành) vị cấu hình khác. Sự vận hành cũng được sử dụng để chỉ bất kỳ Hoạt động hay Giao
dịch nào đã được xác định trước. Ví dụ, nạp một băng từ, chấp nhận tiền mặt tại một
điểm bán hàng, hoặc đọc dữ liệu từ một ổ đĩa.
Operational Mức thấp nhất trong ba mức của việc Hoạch định và phân phối (Chiến lược, Chiến
((Thuộc về) Vận hành) thuật, Vận hành). Các Hoạt động (mang tính) Vận hành bao gồm các hoạt động hàng
ngày hoặc ngắn hạn trong việc Hoạch định hoặc cung cấp một Quy trình Nghiệp vụ hay
một Quy trình Quản lý Dịch vụ CNTT. Khái niệm Operational cũng đồng nghĩa với Live
Operational Cost Chi phí phát sinh từ việc chạy các Dịch vụ CNTT. Các khoản thanh toán thường lặp đi
Chi phí vận hành lặp lại. Ví dụ, chi phí cho nhân viên, chi phí bảo trì máy móc và chi phí điện (còn gọi
là “chi tiêu hiện tại” hoặc “chi tiêu doanh thu”)
Operational Level (Thiết kế Dịch vụ)/(Liên tục Cải tiến Dịch vụ) Một Thỏa thuận giữa nhà cung cấp Dịch
Agreement vụ CNTT và bộ phận khác của cùng một Tổ chức. Một OLA hỗ trợ khả năng cung cấp
(Thỏa thuận mức vận Dịch vụ CNTT cho Khách hàng của nhà cung cấp Dịch vụ CNTT. OLA xác định hàng hóa
hành) hoặc Dịch vụ sẽ được cung cấp và trách nhiệm của các bên liên quan. Ví dụ, những
điều sau đây có thể là OLA:
- Giữa Nhà cung cấp dịch vụ CNTT và Phòng mua hàng để có được phần cứng đúng
hạn đã thỏa thuận,
- Giữa Bộ phận Bộ phận Hỗ trợ Dịch vụ - Service Deks và một Nhóm hỗ trợ để cung
cấp Giải pháp Sự cố đúng hạn đã thỏa thuận.
Xem thêm Thỏa thuận Mức Dịch vụ.
Optimize Xem xét, Lập kế hoạch và yêu cầu Thay đổi, nhằm đạt được Hiệu suất và Hiệu quả tốt
(Tối ưu hóa) nhất từ Quy trình, Đơn vị cấu hình, Ứng dụng, v.v…
Organization Một công ty, pháp nhân hoặc cơ quan khác. Ví dụ, các Tổ chức không phải là các công
(Tổ chức) ty bao gồm ISO hoặc itSMF. Khái niệm Tổ chức thỉnh thoảng được sử dụng để chỉ bất
kỳ pháp nhân nào có Con người, Tài nguyên và Ngân sách. Ví dụ, một Dự án hoặc một
Đơn vị Kinh doanh.
Outcome Kết quả của việc thực hiện một Hành động, tuân theo một Quy trình, cung cấp một
(Kết quả) Dịch vụ CNTT, v.v… Khái niệm Kết quả được sử dụng để chỉ kết quả mong muốn, cũng
như là kết quả thực tế. Xem thêm Mục tiêu.
Outsourcing (Chiến lược Dịch vụ) Sử dụng một nhà cung cấp Dịch vụ Bên ngoài để quản lý các Dịch
(Thuê ngoài) vụ CNTT.
Overhead Xem chi phí Gián tiếp.
(Chi phí quản lý)
Partnership Một mối quan hệ giữa hai Tổ chức tham gia hợp tác chặt chẽ cùng nhau, cho các mục
(Sự cộng tác) đích chung hoặc cùng có lợi. Nhà cung cấp Dịch vụ CNTT nên có Sự cộng tác với Doanh
nghiệp, và Bên thứ ba khác quan trọng đối với việc cung cấp Dịch vụ CNTT. Tham khảo
Mạng lưới Giá trị.
Passive Monitoring (Vận hành Dịch vụ) Sự giám sát một Đơn vị cấu hình, một Dịch vụ CNTT hay Quy trình
(Giám sát thụ động) dựa vào một Cảnh báo hoặc một thông báo để khám phá trạng thái hiện tại.
Pattern of Business (Chiến lược Dịch vụ) Một hồ sơ Khối lượng công việc của một hoặc nhiều Hoạt động
Activity Kinh doanh. Hình mẫu Hoạt động Kinh doanh được sử dụng để giúp nhà cung cấp Dịch
(Hình mẫu Hoạt động vụ CNTT hiểu và lập kế hoạch cho các mức khác nhau của Hoạt động Kinh doanh.
Kinh doanh)
Performance Một thước đo về những gì đã đạt được hoặc đã được cung cấp bởi một Hệ thống, con
(Hiệu suất) người, đội nhóm, Quy trình hay Dịch vụ CNTT.
Performance (Liên tục Cải tiến Dịch vụ) Quy trình chịu trách nhiệm về mọi Hoạt động Quản lý Công
Management suất hàng ngày. Bao gồm giám sát, phát hiện ngưỡng, phân tích Hiệu suất, Điều chỉnh,
(Quản lý Hiệu suất) Triển khai các thay đổi liên quan đến Hiệu suất và Công suất.
Pilot (Chuyển tiếp Dịch vụ) Việc Triển khai một cách hạn chế một Dịch vụ CNTT, một Bản
(Thử nghiệm) phát hành (phần mềm) hay một Quy trình trong Môi trường Thật. Một thử nghiệm được
sử dụng để giảm thiểu rủi ro và để thu thập phản hồi và sự Chấp thuận của Người sử
dụng. Xem thêm Kiểm tra, Đánh giá.
Plan Một đề xuất chi tiết mô tả mọi Hoạt động và Tài nguyên cần thiết để đạt được một Mục
(Kế hoạch) tiêu. Ví dụ, một Kế hoạch triển khai Dịch vụ CNTT hay Quy trình mới. ISO/IEC 20000
yêu cầu một Kế hoạch quản lý cho mỗi Quy trình Quản lý Dịch vụ CNTT.
Plan-Do-Check-Act (Liên tục Cải tiến Dịch vụ) Một Chu kỳ gồm 4 giai đoạn để quản lý Quy trình, do
(Plan-Do-Check-Act) Edward Deming đưa ra. Plan-Do-Check-Act còn được gọi là Chu kỳ Deming.
- PLAN: Thiết kế hoặc sửa đổi các Quy trình hỗ trợ các Dịch vụ CNTT,
- DO: Triển khai Kế hoạch và quản lý các Quy trình,
- CHECK: Đo lường các Quy trình và Dịch vụ CNTT, so sánh với các Mục tiêu và các
thủ tục báo cáo,
- ACT: Lập kế hoạch và triển khai các thay đổi để cải tiến các Quy trình.
Planned Downtime (Thiết kế Dịch vụ) Khoảng thời gian được thỏa thuận để một Dịch vụ CNTT không sẵn
(Thời gian gián đoạn sàng (bị ngưng). Thời gian gián đoạn Đã được lập kế hoạch thường được sử dụng để
Đã được lập kế hoạch) bảo trì, nâng cấp hoặc kiểm tra. Xem thêm Change Windows (Cửa sổ Thay đổi),
Downtime (Gián đoạn).
Planning Một Hành động chịu trách nhiệm tạo ra một hay nhiều Kế hoạch. Ví dụ, Lên Hoạch định
(Hoạch định) Công suất.
PMBOK Một Tiêu chuẩn quản lý Dự án được công bố và duy trì bởi Học viện Quản lý Dự án
(PMBOK) (Project Management Institute). PMBOK là vi ết tắt của Project Management Body of
Knowledge. Tham khảo http://www.pmi.org/ để biết thêm thông tin. Xem thêm
PRINCE2.
Policy Các kỳ vọng và ý định quản lý được lập thành văn bản chính thức. Các chính sách được
(Chính sách) sử dụng để định hướng các quyết định, và nhằm đảm bảo rằng các Quy trình, Tiêu
chuẩn, Vai trò, Hoạt động, Hạ tầng CNTT được phát triển và triển khai một cách đúng
đắn và phù hợp.
Portable Facility (Thiết kế Dịch vụ) Một tòa nhà đúc sẵn, hoặc một xe tải lớn, được cung cấp bởi Bên
(Cơ sở Lưu động) Thứ ba và di chuyển đến địa điểm cần thiết bởi một Kế hoạch Liên tục Dịch vụ CNTT.
Xem thêm Lựa chọn Khôi phục.
Post Implementation Một sự Xem xét diễn ra sau khi một Thay đổi hoặc một Dự án đã được triển khai. Một
Review PIR xác định xem sự Thay đổi hay Dự án đã thành công và xác định các cơ hội để cải
(Đánh giá Sau Triển tiến.
khai)
Practice Cách thức làm việc, hoặc cách thức mà công việc phải được thực hiện. Thực tiễn có
(Thực tiễn) thể bao gồm các Hoạt động, Quy trình, Chức năng, Tiêu chuẩn và Hướng dẫn. Xem
thêm Thực tiễn Tốt nhất.
Prerequisite for Một hoạt động cần phải hoàn thành, hoặc một điều kiện cần phải thỏa mãn, để triển
Success khai thành công một Kế hoạch hoặc Dự án. Một PFS thường là đầu ra của một Quy
(Điều kiện tiên quyết trình là một đầu vào cần thiết của một Quy trình khác.
để Thành công)
Pricing (Chiến lược Dịch vụ) Hoạt động thiết lập mức phí mà Khách hàng sẽ phải trả.
(Định giá)
PRINCE2 Tiêu chuẩn của Chính phủ Anh về phương pháp quản lý Dự án. Tham khảo
(PRINCE2) http://www.ogc.gov.uk/prince2 để biết thêm thông tin. Xem thêm PMBOK.
Priority (Chuyển tiếp Dịch vụ)/(Vận hành Dịch vụ) Một Thể loại được sử dụng để xác định tầm
(Độ ưu tiên) quan trọng tương đối của một Sự cố, Vấn đề hay Thay đổi. Độ ưu tiên được căn cứ vào
Ảnh hưởng và độ Khẩn cấp, và được sử dụng để xác định thời gian cần thiết để thực
hiện các hoạt động. Ví dụ, Thỏa thuận Mức Dịch vụ (SLA) có thể cho rằng Sự cố có Độ
ưu tiên 2 phải được giải quyết trong vòng 12 giờ.
Problem (Vận hành Dịch vụ) Một nguyên nhân gây ra một hoặc nhiều Sự cố. Nguyên nhân
(Vấn đề) thường không được biết đến vào thời điểm Hồ sơ Vấn đề được tạo ra, và Quy trình
Quản lý Vấn đề sẽ chịu trách nhiệm về việc điều tra thêm
Problem Management (Vận hành Dịch vụ) Quy trình chịu trách nhiệm cho việc quản lý Vòng đời của mọi Vấn
(Quản lý Vấn để) đề. Mục tiêu chủ yếu của Quản lý Vấn đề là nhằm ngăn ngừa các Sự cố xảy ra, và
nhằm giảm thiểu Tác động của các Sự cố mà không thể ngăn ngừa được.
Procedure Một Tài liệu bao gồm các bước nhằm xác định làm thế nào để đạt được một Hoạt động.
(Thủ tục) Các Thủ tục được xác định như là một phần của các Quy trình. Xem thêm Hướng dẫn
Công việc - Work Instruction.
Process Một tập hợp các Hoạt động có cấu trúc được thiết kế để đạt được một Mục tiêu cụ thể.
(Quy trình) Một Quy trình có một hoặc nhiều đầu vào được xác định và biến chúng thành đầu ra đã
được xác định. Một Quy trình có thể bao gồm bất kỳ Vai trò, trách nhiệm, Công cụ và
Kiểm soát quản lý nào được yêu cầu để cung cấp các đầu ra một cách đáng tin cậy.
Một Quy trình có thể xác định các Chính sách, Tiêu chuẩn, Hướng dẫn, Hoạt động và
Hướng dẫn Công việc nếu chúng là cần thiết.
Process Control Một Hoạt động lên kế hoạch và điều chỉnh một Quy trình, với Mục tiêu về việc thực
(Kiểm soát quy trình) hiện Quy trình đó một cách Hiệu quả, Năng suất và nhất quán.
Process Owner Một Vai trò chịu trách nhiệm cho việc đảm bảo rằng một Quy trình là Đáp ứng được
(Chủ sở hữu Quy trình) Mục đích. Trách nhiệm của Chủ sở hữu Quy trình bao gồm tài trợ, Thiết kế, Quản lý
Thay đổi và liên tục cải tiến Quy trình và các chỉ số của nó. Vai trò này thường được
chỉ định cho cùng một người đang giữ Vai trò Người quản lý Quy trình, tuy nhiên hai
vai trò này có thể được tách riêng ra rong những Tổ chức lớn hơn.
Profoma Một Tài liệu biểu mẫu, hoặc ví dụ bao gồm dữ liệu ví dụ mà sẽ được thay thế với các
(Proforma) giá trị thực tế khi chúng sẵn sàng.
Programme Một số các Dự án và Hoạt động đã được lên kế hoạch và quản lý cùng nhau để đạt
(Chương trình) được một bộ tổng thể liên quan đến các Mục tiêu và các Kết quả khác.
Project Một Tổ chức tạm thời, với con người và Tài sản khác cần thiết để đạt được một Mục
(Dự án) tiêu hoặc Kết quả khác. Mỗi Dự án có Vòng đời riêng thường bao gồm khởi đầu, Lên kế
hoạch, thực thi, Đóng, v.v… Các Dự án thường được quản lý bằng một phương pháp
chính thức ví dụ như PRINCE2.
Quality Khả năng của một Sản phẩm, Dịch vụ hay Quy trình có thể cung cấp giá trị đã được dự
(Chất lượng) kiến. Ví dụ, một Thành phần phần cứng có thể được coi là có Chất lượng cao nếu nó
hoạt động như mong đợi và thỏa mãn yêu cầu về Độ tin cậy. Quy trình Chất lượng
cũng đòi hỏi khả năng giám sát Hiệu quả và Hiệu suất, và có thể cải tiến chúng nếu
cần thiết. Xem thêm Hệ thống quản lý chất lượng.
Quality Management (Liên tục Cải tiến Dịch vụ) Tập hợp các Quy trình chịu trách nhiệm cho việc đảm bảo
System rằng mọi công việc được thực hiện bởi một tổ chức có Chất lượng phù hợp để đáp ứng
(Hệ thống Quản lý Chất một cách đáng tin cậy các Mục tiêu Kinh doanh hoặc các Mức Dịch vụ. Xem thêm
lượng) ISO9000.
RACI (Thiết kế Dịch vụ)/(Liên tục Cải tiến Dịch vụ) Một Mô hình được sử dụng để giúp xác
(RACI) định Vai trò và Trách nhiệm. RACI là viết tắt của Responsible, Accountable, Consulted
và Informed.
Reciprocal (Thiết kế Dịch vụ) Một Lựa chọn Khôi phục. Một thỏa thuận giữa hai Tổ chức chia sẻ
Arrangement tài nguyên trong một tình huống khẩn cấp. Ví dụ, không gian Phòng Máy tính hoặc sử
(Thỏa thuận Đối ứng) dụng chung một máy chủ lớn (mainframe).
Record Một Tài liệu bao gồm các kết quả hay đầu ra khác từ một Quy trình hay một Hoạt
(Hồ sơ) động. Các Hồ sơ là bằng chứng thực tế cho thấy rằng một Hoạt động đã diễn ra và có
thể ghi lại trên giấy hoặc điện tử. Ví dụ, một báo cáo Kiểm toán, một Hồ sơ Sự cố,
hoặc biên bản cuộc họp.
Recovery (Thiết kế Dịch vụ)/(Vận hành Dịch vụ) Trả một Đơn vị cấu hình hoặc một Dịch vụ CNTT
(Khôi phục) về trạng thái đang hoạt động. Khôi phục một Dịch vụ CNTT thường bao gồm khôi phục
dữ liệu về một trạng thái nhất quán đã biết trước đó. Sau khi Khôi phục, các bước tiếp
theo có thể cần thiết trước khi Dịch vụ CNTT có thể sẵn sàng đối với người sử dụng
(Phục hồi).
Recovery Option (Thiết kế Dịch vụ) Một Chiến lược để ứng phó với một sự gián đoạn Dịch vụ. Các Chiến
(Lựa chọn khôi phục) lược thường được sử dụng là Không làm gì cả, Giải quyết Thủ công, Thỏa thuận Đối
ứng, Khôi phục Dần dần, Khôi phục Tức thời, Khôi phục Nhanh, và Khôi phục Trung
bình. Các Lựa chọn Khôi phục có thể sử dụng các cơ sở chuyên dụng, hoặc các cơ sở
của Bên thứ ba được chia sẻ bởi nhiều Doanh nghiệp khác nhau.
Redundancy Xem Khả năng Chịu lỗi.
(Dự phòng) Khái niệm Dự phòng cũng có nghĩa chung với lỗi thời, hoặc không còn cần thiết nữa.
Relationship Một kết nối hoặc tương tác giữa hai người hay sự vật nào đó. Trong Quản lý mối Quan
(Quan hệ) hệ Kinh doanh, đó là sự tương tác giữa nhà cung cấp Dịch vụ CNTT và Doanh nghiệp.
Trong Quản lý Cấu hình, nó là liên kết giữa hai Đơn vị Cấu hình xác định sự phụ thuộc
lẫn nhau hoặc kết nối giữa chúng. Ví dụ, các Ứng dụng có thể được liên kết với các
máy chủ mà chúng đang chạy trên đó. Các Dịch vụ CNTT có nhiều liên kết tới các Đơn
vị cấu hình mà đóng góp cho chúng.
Relationship Processes Nhóm Quy trình ISO/IEC 20000 bao gồm Quản lý Quan hệ Kinh doanh và Quản lý Nhà
(Các Quy trình (về) mối cung cấp.
Quan hệ)
Release (Chuyển tiếp Dịch vụ) Một tập hợp phần cứng, phần mềm, tài liệu, các Quy trình hay
(Bản phát hành) các Thành phần khác cần thiết để triển khai một hay nhiều Thay đổi đã được phê
duyệt đối với các Dịch vụ CNTT. Nội dung của mỗi Bản phát hành được quản lý, kiểm
tra và triển khai như là một thực thể đơn lẻ.
Release và Deployment (Chuyển tiếp Dịch vụ) Quy trình chịu trách nhiệm Quản lý Triển khai và Bản phát hành.
Management
(Quản lý Triển khai và

Bản phát hành)
Release Management (Chuyển tiếp Dịch vụ) Quy trình chịu trách nhiệm cho việc Lên kế hoạch, lập lịch biểu
(Quản lý Bản phát và kiểm soát việc chuyển các Bản phát hành tới Môi trường Kiểm thử và Môi trường
hành) Thật. Mục tiêu chính của Quản lý Bản phát hành là đảm bảo rằng tính toàn vẹn của
môi trường Thật được bảo vệ và các Thành phần đúng đắn được phát hành. Quản lý
Bản phát hành là một phần của Quy trình Quản lý Triển khai và Bản phát hành.
Release Record (Chuyển tiếp Dịch vụ) Một Hồ sơ trong Cơ sở dữ liệu Quản lý Cấu hình xác định thành
(Hồ sơ Phát hành) phần của một Bản phát hành. Một Hồ sơ Phát hành có các Mối quan hệ với mọi Đơn vị
cấu hình chịu ảnh hưởng bởi Bản phát hành đó.
Reliability (Liên tục Cải tiến Dịch vụ) Một thước đo về khoảng thời gian bao lâu mà một Đơn vị
(Độ tin cậy) cấu hình hay Dịch vụ CNTT có thể hoàn thành Chức năng đã được thỏa thuận mà không
bị gián đoạn. Thường được đo bằng MTBF hoặc MTBSI. Khái niệm Độ tin cậy cũng được
sử dụng để xác định khả năng một Quy trình, Chức năng, v.v… sẽ cung cấp đầu ra mà
nó được yêu cầu. Xem thêm Tính sẵn sàng.
Repair (Vận hành Dịch vụ) Sự thay thế hoặc sửa chữa một Đơn vị cấu hình bị lỗi.
(Sửa chữa)
Request for Change (Chuyển tiếp Dịch vụ) Một đề xuất chính thức cho một Thay đổi sẽ được thực hiện. Một
(Yêu cầu Thay đổi) RFC bao gồm chi tiết của Thay đổi được đề xuất, và có thể sẽ được ghi nhận lại bằng
giấy tờ hay bằng phiên bản điện tử. Khái niệm RFC cũng thường hay bị lạm dụng để
chỉ một Hồ sơ Thay đổi, hay chính bản thân Thay đổi.
Request Fulfillment (Vận hành Dịch vụ) Quy trình chịu trách nhiệm cho việc quản lý Vòng đời của mọi Yêu
(Yêu cầu thực hiện) cầu dịch vụ.
Requirement (Thiết kế Dịch vụ) Một tuyên bố chính thức về những gì cần thiết. Ví dụ, một Yêu cầu
(Yêu cầu) Mức Dịch vụ, một Yêu cầu Dự án hay các Sản phầm có thể cung cấp được cho một Quy
trình. Xem thêm Tuyên bố các yêu cầu.
Resilience (Thiết kế Dịch vụ) Khả năng của một Đơn vị cấu hình hoặc một Dịch vụ CNTT chống lại
(Khả năng phục hồi) Lỗi hoặc để Phục hồi một cách nhanh chóng sau một Lỗi. Ví dụ, một sợi cáp có bọc
thép sẽ không bị hỏng khi bị căng thẳng. Xem thêm Khả năng Chịu lỗi.
Resolution (Vận hành Dịch vụ) Hoạt động được thực hiện để sửa chữa Nguyên nhân gốc của một
(Giải pháp) Sự cố hay một Vấn đề, hay để triển khai một Giải pháp thủ công. Trong ISO/IEC
20000, Quy trình Giải pháp là nhóm Quy trình bao gồm Quản lý Sự cố và Quản lý Vấn
đề.
Resource (Chiến lược Dịch vụ) Khái niệm tổng thể bao gồm Hạ tầng CNTT, con người, tiền bạc
(Tài nguyên) hay bất kỳ khái niệm nào khác có thể hỗ trợ cho việc phân phối một Dịch vụ CNTT. Tài
nguyên được cân nhắc như là Tài sản của một Tổ chức. Xem thê m Năng lực , tài sản
Dịch vụ.
Response Time Một thước đo thời gian sử dụng để hoàn thành một sự Vận hành hay một Giao dịch.
(Thời gian hồi đáp) Được sử dụng trong Quản lý Công suất như là một thước đo Hiệu suất của Hạ tầng
CNTT, và trong Quản lý Vấn đề như là một thước đo thời gian trả lời điện thoại hay để
bắt đầu Chẩn đoán.
Responsiveness Một thước đo thời gian sử dụng để phản ứng (hồi đáp) lại một cái gì đó. Nó có thể là
(Phản ứng) Thời gian Hồi đáp lại một Giao dịch, hoặc tốc độ mà một Nhà cung cấp Dịch vụ CNTT
phản ứng lại một Sự cố hoặc Yêu cầu thay đổi, v.v…
Restoration of Service Xem Khôi phục.
(Khôi phục dịch vụ)
Restore (Vận hành Dịch vụ) Tiến hành các hành động để đưa một Dịch vụ CNTT trở về phục vụ
(Khôi phục) cho người sử dụng sau khi Sửa chữa hay Phục hồi sau một Sự cố. Đây là mục tiêu chủ
yếu của Quản lý Sự cố.
Retire (Chuyển tiếp Dịch vụ) Loại bỏ vĩnh viễn một Dịch vụ CNTT hay một Đơn vị cấu hình
(“Nghỉ hưu”) khác ra khỏi Môi trường Thực. “Nghỉ hưu” là một giai đoạn trong Vòng đời của nhiều
Đơn vị cấu hình.
Return of Investment (Chiến lược Dịch vụ)/(Liên tục Cải tiến Dịch vụ) Một phương pháp đo lường lợi ích
(ROI) được kỳ vọng của một khoản đầu tư. Theo ngữ nghĩa đơn giản nhất, đó là lợi nhuận
(Lợi nhuận đầu tư) ròng của một khoản đầu tư chia cho giá trị ròng của tài sản đầu tư.
Return to Normal (Thiết kế Dịch vụ) Một giai đoạn trong Kế hoạch Liên tục Dịch vụ CNTT trong đó toàn
(Trở lại Bình thường) bộ hoạt động được khôi phục về bình thường. Ví dụ, nếu một trung tâm tích hợp và xử
lý dữ liệu thay thế được sử dụng, sau đó, giai đoạn này sẽ khôi phục trung tâm dữ liệu
chính trở lại hoạt động, khôi phục khả năng viện dẫn Kế hoạch Liên tục Dịch vụ CNTT.
Review Một đánh giá về một Thay đổi, Vấn đề, Quy trình, Dự án, v.v… Các Xem xét thường
(Xem xét) được thực hiện tại các điểm được xác định trước trong Vòng đời, đặc biệt là sau khi
Đóng. Mục đích của một Xem xét là nhằm đảm bảo mọi Sản phẩm đã được cung cấp, và
nhằm xác định các cơ hội để cải tiến. Xem thêm Xem xét Sau-Triển khai.
Rights (Vận hành Dịch vụ) Quyền được làm, hoặc quyền được cấp cho một Người sử dụng hay
Quyền) một Vai trò. Ví dụ, Quyền điều chỉnh dữ liệu cụ thể hoặc ủy quyền cho phép Thay đổi.
Risk Một sự kiện khả dĩ, có thể gây ra hư hỏng, mất mát hay ảnh hưởng tới khả năng đạt
(Rủi ro) được các Mục tiêu. Một Rủi ro được đo lường bởi xác suất xảy ra của một Nguy cơ, Lỗ
hổng của Tài sản đối với Nguy cơ đó, và Ảnh hưởng của nó nếu nó xảy ra.
Risk Assessment Bước khởi đầu của quản lý Rủi ro. Phân tích giá trị của Tài sản đối với Tổ chức, xác
(Đánh giá Rủi ro) định các Nguy cơ đối với Tài sản đó, và đánh giá mức độ tổn thương của Tài sản đối
với Nguy cơ đó. Đánh giá rủi ro có thể định lượng (dựa trên các dữ liệu số) hoặc định
tính.
Risk Management Quy trình chịu trách nhiệm cho việc xác định, đánh giá và kiểm soát Rủi ro. Xem thêm
(Quản lý Rủi ro) Đánh giá Rủi ro.
Role Tập hợp các Trách nhiệm, Hành động và các quyền hạn đã được cấp cho một cá nhân
(Vai trò) hay một đội. Một Vai trò được xác định trong một Quy trình. Một cá nhân hay đội
nhóm có thể có nhiều Vai trò, ví dụ, các Vai trò Quản lý Cấu hình và Quản lý Thay đổi
có thể được nắm giữ bởi một cá nhân.
Root Cause (Vận hành Dịch vụ) Nguyên nhân gốc hay nguyên nhân cơ bản của một Sự cố hay một
(Nguyên nhân Gốc) Vấn đề.
Running Cost Xem Chi phí vận hành.
(Chi phí Hoạt động)
Scalability Khả năng của một Dịch vụ CNTT, một Quy trình, Đơn vị cấu hình v.v…để thực hiện
(Khả năng mở rộng) chức năng đã được thỏa thuận khi Khối lượng công việc hoặc Phạm vi thay đổi.
Scope Ranh giới, hay mức độ mà một Quy trình, Thủ tục, Chứng chỉ, Hợp đồng, v.v… được áp
(Phạm vi) dụng. Ví dụ, Phạm vi của Quản lý Thay đổi có thể bao gồm mọi Dịch vụ CNTT đang
Hoạt động và các Đơn vị cấu hình có liên quan, Phạm vi của Chứng chỉ ISO/IEC 20000
có thể bao gồm mọi Dịch vụ CNTT được cung cấp từ một Trung tâm tích hợp và xử lý
dữ liệu được đặt tên.
Security Xem Quản lý Bảo mật Thông tin.
(Bảo mật)
Security Management Xem Quản lý Bảo mật Thông tin.
(Quản trị bảo mật)
Security Policy Xem Chính sách Bảo mật Thông tin.
(Chính sách bảo mật)
Separation of Concerns (Chiến lược Dịch vụ) Một phương pháp tiếp cận trong việc Thiết kế một giải pháp hay
(Phân tách các mối một Dịch vụ CNTT trong đó vấn đề được tách ra làm nhiều mảnh để có thể được giải
quan tâm) quyết (từng mảnh) một cách độc lập. Phương pháp này tách biệt “cái gì” cần phải hoàn
thành ra khỏi “làm thế nào” để hoàn thành.
Server (Vận hành Dịch vụ) Một máy tính kết nối tới một hệ thống mạng và cung cấp các Chức
(Máy chủ) năng phần mềm được sử dụng bởi các máy tính khác.
Service Một khái niệm để chỉ việc cung cấp giá trị tới cho Khách hàng bằng cách tạo điều kiện
(Dịch vụ) để đạt được Kết quả mà Khách hàng mong muốn khi mà họ không cần quyền sở hữu
đối với Chi phí và Rủi ro cụ thể.
Service Acceptance (Chuyển tiếp Dịch vụ) Một bộ các tiêu chí được sử dụng để đảm bảo rằng một Dịch vụ
Criteria CNTT đáp ứng được các Yêu cầu về chức năng và Chất lượng của nó, đồng thời nhà
(Tiêu chí Chấp thuận cung cấp Dịch vụ CNTT sẵn sàng để Vận hành Dịch vụ CNTT mới khi nó đã được triển
Dịch vụ) khai. Xem thêm Chấp thuận.
Service Asset Mọi Năng lực hay Tài nguyên của một Nhà cung cấp Dịch vụ. Xem thêm Tài sản.
(Tài sản dịch vụ)
Service Capacity (Thiết kế Dịch vụ)/(Liên tục Cải tiến Dịch vụ) Hoạt động chịu trách nhiệm cho việc tìm
Management hiểu Hiệu suất và Công suất của các Dịch vụ CNTT. Các Tài nguyên được sử dụng bởi
(Quản lý Công suất mỗi Dịch vụ CNTT và hình mẫu của việc sử dụng theo thời gian được thu thập, ghi
Dịch vụ) nhận và phân tích để sử dụng trong Kế hoạch Công suất. Xem thêm Quản lý Công suất
Doanh nghiệp, Quản lý Công suất Thành phần.
Service Catalogue (Thiết kế Dịch vụ) Một cở sở dữ liệu hay một tài liệu có cấu trúc có chứa thông tin về
(Bản liệt kê Dịch vụ) mọi Dịch vụ CNTT đang hoạt động, bao gồm cả những Dịch vụ sẵn sàng để triển khai.
Mục lục Dịch vụ là phần duy nhất của Danh mục Dịch vụ được cung cấp cho Khách
hàng và được sử dụng để hỗ trợ việc bán hàng và cung cấp dịch vụ CNTT. Mục lục dịch
vụ bao gồm thông tin về sản phẩm, giá, liên hệ, đặt hàng và các Quy trình yêu cầu.
Tham khảo Danh mục hợp đồng.
Service Continuity Xem Quản lý Liên tục Dịch vụ CNTT

Management
(Quản lý Liên tục Dịch

vụ)
Service Culture Một Văn hóa định hướng-Khách hàng. Mục tiêu chủ yếu cú văn hóa Dịch vụ là sự hài
(Văn hóa Dịch vụ) lòng của Khách hàng và giúp cho Khách hàng đạt được các Mục tiêu Kinh doanh của
họ.
Service Design (Thiết kế Dịch vụ) Một giai đoạn trong Vòng đời của một Dịch vụ CNTT. Thiết kế Dịch
(Thiết kế Dịch vụ) vụ bao gồm một số các Quy trình hay Chức năng và là một trong những ấn phẩm cốt
lõi của ITIL. Xem thêm Thiết kế.
Service Design Package (Thiết kế Dịch vụ) (Các) Tài liệu xác định mọi khía cạnh của một Dịch vụ CNTT và các
(Gói Thiết kế Dịch vụ) Yêu cầu của nó trong mỗi giai đoạn trong Vòng đời của nó. Một Gói Thiết kế Dịch vụ
được xuất bản cho mỗi Dịch vụ CNTT mới, Thay đổi quan trọng hay Dịch vụ CNTT “Nghỉ
hưu”.
Service Desk (Vận hành Dịch vụ) Một Điểm Đơn Liên hệ giữa Nhà cung cấp dịch vụ và Người sử
(Bộ phận Hỗ trợ Dịch dụng. Một Bộ phận Hỗ trợ Dịch vụ thông thường sẽ quản lý các Sự cố và các yêu cầu
vụ) Dịch vụ đồng thời xử lý vấn đề truyền thông với Người sử dụng.
Service Failure Analysis (Thiết kế Dịch vụ) Một Hành động xác định các nguyên nhân cơ bản của một hay nhiều
(Phân tích Lỗi Dịch vụ) sự gián đoạn Dịch vụ CNTT. SFA xác định cơ hội để cải tiến các Quy trình và công cụ
của Nhà cung cấp Dịch vụ CNTT chứ không riêng Hạ tầng CNTT. SFA là bị hạn chế bởi
thời gian, hoạt động giống như-dự án hơn là một quá trình phân tích liên tục.
Service Hours (Thiết kế Dịch vụ)/(Liên tục Cải tiến Dịch vụ) Một khoảng thời gian được thỏa thuận
(Giờ Dịch vụ) khi mà Dịch vụ CNTT cụ thể là sẵn sàng. Ví dụ, “Từ 8:00 đến 17:00, thứ Hai đến thứ
Sáu, trừ các ngày lễ”. Giờ Dịch vụ nên được định nghĩa trong Thỏa thuận Mức Dịch vụ.
Service Improvement (Liên tục Cải tiến Dịch vụ) Một Kế hoạch chính thức nhằm triển khai việc cải tiến một
Plan Quy trình hay một Dịch vụ CNTT.
(Kế hoạch Cải tiến Dịch

vụ)
Service Knowledge (Chuyển tiếp Dịch vụ) Bộ công cụ và cơ sở dữ liệu được sử dụng để quản lý kiến thức
Management System và thông tin. SKMS bao gồm Hệ thống Quản lý Cấu hình, cũng như các công cụ và cơ
(Hệ thống Quản lý Kiến sở dữ liệu khác. SMKS lưu trữ, quản lý, cập nhật và giới thiệu mọi thông tin mà nhà
thức Dịch vụ) cung cấp Dịch vụ CNTT cần để quản lý Vòng đời đầy đủ của các Dịch vụ CNTT
Service Level Những thành tựu đã được đo lường và báo cáo đối với một hoặc nhiều mục tiêu về mức
(Mức Dịch vụ) Dịch vụ. Thuật ngữ mức Dịch vụ thỉnh thoảng được sử dụng một cách không chính thức
để chỉ mục tiêu mức Dịch vụ.
Service Level (Thiết kế Dịch vụ)/(Liên tục Cải tiến Dịch vụ) Một Thỏa thuận giữa một Nhà cung cấp
Agreement (SLA) Dịch vụ CNTT và một Khách hàng. SLA mô tả Dịch vụ CNTT, tài liệu hóa lại các mục
(Thỏa thuận Mức Dịch tiêu nhắm đến về mức Dịch vụ, xác định rõ trách nhiệm của nhà cung cấp Dịch vụ
vụ) CNTT cũng như của Khách hàng. Một SLA đơn lẻ có thể bao gồm nhiều Dịch vụ CNTT
hoặc nhiều Khách hàng. Xem thêm Thỏa thuận Mức Vận hành.
Service Level (Thiết kế Dịch vụ)/ (Liên tục Cải tiến Dịch vụ) Quy trình chịu trách nhiệm cho việc
Management (SLM) thương lượng về các Thỏa thuận Mức Dịch vụ, và đảm bảo rằng chúng được đáp ứng.
(Quản lý Mức Dịch vụ) SLM chịu trách nhiệm cho việc đảm bảo rằng mọi Quy trình Quản lý Dịch vụ CNTT,
Thỏa thuận Mức Vận hành và Hợp đồng Cơ sở là phù hợp với các mục tiêu mức Dịch vụ
đã được thỏa thuận. SLM giám sát và báo cáo các Mức Dịch vụ, và thường xuyên tổ
chức sự xem xét của Khách hàng.
Service Level Package (Chiến lược Dịch vụ) Một mức Sử dụng và Bảo đảm được xác định cho một Gói Dịch vụ
(Gói Mức Dịch vụ) cụ thể. Mỗi SLP được thiết kế để đáp ứng yêu cầu của một Hình mẫu Hoạt động Kinh
doanh cụ thể. Xem thêm Tuyến dịch vụ.
Service Level (Thiết kế Dịch vụ)/(Liên tục Cải tiến Dịch vụ) Một Yêu cầu của Khách hàng đối với một
Requirement khía cạnh của Dịch vụ CNTT. Các SLR dựa trên Mục tiêu Kinh doanh và được sử dụng
(Yêu cầu Mức Dịch vụ) để thương lượng các mục tiêu mức Dịch vụ đã thỏa thuận.
Service Level Target (Thiết kế Dịch vụ)/(Liên tục Cải tiến Dịch vụ) Một cam kết được tài liệu hóa lại trong
(Mục tiêu mức Dịch vụ) một Thỏa thuận Mức Dịch vụ. Các mục tiêu mức Dịch vụ dựa trên các Yêu cầu Mức Dịch
vụ, và cần thiết để đảm bảo rằng Thiết kế Dịch vụ CNTT là Phù hợp với Mục đích. Các
Mục tiêu Mức Dịch vụ nên theo tiêu là
S(Specific)M(Measurable)A(Attainable)R(Relevant)T(Timely), và thư ờng dựa vào KPI.
Service Management Quản lý Dịch vụ là tập hợp các khả năng mang tính tổ chức chuyên biệt để cung cấp
(Quản lý Dịch vụ) giá trị cho các Khách hàng dưới dạng các Dịch vụ.
Service Management Một phương pháp tiếp cận Quản lý Dịch vụ CNTT nhấn mạnh tầm quan trọng của sự
Lifecycle phối hợp và Kiểm soát đối với các Chức năng, Quy trình, và Hệ thống đa dạng để quản
(Vòng đời Quản lý Dịch trị toàn bộ Vòng đời của các Dịch vụ CNTT. Phương pháp tiếp cận Vòng đời Quản trị
vụ) Dịch vụ xem xét Chiến lược, Thiết kế, Chuyển giao, Vậnn hành và Liên tục cải tiến các
Dịch vụ CNTT.
Service Manager Một nhà quản lý chịu trách nhiệm quản lý Vòng đời từ-đầu đến-cuối của một hay nhiều
(Người Quản lý Dịch Dịch vụ CNTT. Khái niệm Người Quản lý Dịch vụ cũng đuợc sử dụng để chỉ bất kỳ cấp
vụ) quản lý nào của Nhà cung cấp Dịch vụ CNTT. Thường được sử dụng để đề cập tới một
Người Quản lý Quan hệ Kinh doanh, Người Quản lý Quy trình, một Quản lý Kinh doanh
hay một quản lý cấp cao chịu trách nhiệm tổng thể về Dịch vụ CNTT.
Service Operation (Vận hành Dịch vụ) Một giai đoạn trong Vòng đời của một Dịch vụ CNTT. Vận hành
(Vận hành Dịch vụ) Dịch vụ bao gồm một số các Quy trình và Chức năng và là tựa đề một ấn phẩm cốt lõi
của ITIL. Xem thêm Vận hành.
Service Owner (Liên tục Cải tiến Dịch vụ) Một Vai trò chịu trách nhiệm cho việc cung cấp một Dịch vụ
(Chủ sở hữu Dịch vụ) CNTT cụ thể.
Service Portfolio (Chiến lược Dịch vụ) Một tập hợp hoàn chỉnh các Dịch vụ được quản lý bởi nhà cung
(Danh mục Dịch vụ) cấp Dịch vụ. Danh mục dịch vụ được sử dụng để để quản lý toàn bộ Vòng đời của mọi
Dịch vụ, và bao gồm những Thể loại sau: Đường ống Dịch vụ (đã được để xuất hoặc
đang Phát triển), Bản Liệt kê Dịch vụ (Đang hoạt động hoặc sẵn sàng để Phát triển) và
các Dịch vụ đã “Nghỉ hưu”. Xem thêm Quản lý Danh mục Dịch vụ.
Service Portfolio (Chiến lược Dịch vụ) Quy trình chịu trách nhiệm cho việc quản lý Danh mục Dịch vụ.
Management Quản lý Danh mục Dịch vụ xem xét các Dịch vụ theo giá trị Kinh doanh mà chúng cung
(Quản lý Danh mục cấp.
Dịch vụ)
Service Provider (Chiến lược Dịch vụ) Một Tổ chức cung cấp các Dịch vụ cho một hay nhiều Khách hàng
(Nhà cung cấp Dịch vụ) Nội bộ hoặc Bên ngoài. Nhà cung cấp Dịch vụ thường được sử dụng như từ viết tắt của
Nhà cung cấp Dịch vụ CNTT.
Service Reporting (Liên tục Cải tiến Dịch vụ) Quy trình chịu trách nhiệm cho việc cung cấp và phân phối
(Báo cáo Dịch vụ) các báo cáo về thành tích đạt được và các xu hướng đối với các mức Dịch vụ. Báo cáo
Dịch vụ nên được thỏa thuận với Khách hàng về định dạng, nội dung và tần suất báo
cáo.
Service Request (Vận hành Dịch vụ) Một yêu cầu từ một Người sử dụng về thông tin hay lời khuyên,
(Yêu cầu Dịch vụ) hoặc cho một Thay đổi Tiêu chuẩn hoặc cho một Truy cập vào Dịch vụ CNTT. Ví dụ, đặt
lại mật khẩu, cung cấp các Dịch vụ CNTT tiêu chuẩn cho một Người sử dụng mới. Các
yêu cầu Dịch vụ thường được xử lý bởi một Bộ phận Hỗ trợ Dịch vụ, và không yêu cầu
sự đệ trinh một Yêu cầu Thay đổi. Xem thêm Hoàn thành Yêu cầu.
Service Strategy (Chiến lược Dịch vụ) Tựa đề của một Ấn phẩm cốt lõi của ITIL. Chiến lược Dịch vụ
(Chiến lược Dịch vụ) thiết lập Chiến lược tổng thể của các Dịch vụ CNTT và Quản lý Dịch vụ CNTT.
Service Transition (Chuyển tiếp Dịch vụ) Một giai đoạn trong Vòng đời của một Dịch vụ CNTT. Chuyển
(Chuyển tiếp Dịch vụ) tiếp Dịch vụ bao gồm một số các Quy trình và Chức năng và là tựa đề của một Ấn
phẩm cốt lõi của ITIL. Xem thêm Chuyển tiếp.
Service Warranty (Chiến lược Dịch vụ) Sự đảm bảo rằng một Dịch vụ CNTT sẽ đáp ứng được các Yêu cầu.
(Bảo đảm Dịch vụ) Đây có thể là một Thỏa thuận chính thức chẳng hạn như một Thỏa thuận Mức Dịch vụ
hay một Hợp đồng, hay có thể là một thông điệp marketing hay một hình ảnh thương
hiệu. Giá trị Kinh doanh của một Dịch vụ CNTT được tạo ra bởi sự kết hợp Tính tiện
dụng của Dịch vụ (những gì mà Dịch vụ sẽ làm) và sự bảo đảm Dịch vụ (Dịch vụ sẽ làm
tốt đến mức nào). Xem thêm Đảm bảo.
Serviceability (Thiết kế Dịch vụ)/(Liên tục Cải tiến Dịch vụ) Khả năng của một Nhà cung cấp Bên thứ
(Khả năng Phục vụ) ba nhằm đáp ứng các điều khoản trong Hợp đồng. Hợp đồng này sẽ bao gồm các mức
đã được thỏa thuận về độ Tin cậy, Khả năng bảo trì hay tính Sẵn sàng của một Đơn vị
cấu hình.
Shift (Vận hành Dịch vụ) Một nhóm hay một đội ngũ các cá nhân đảm trách một Vai trò cụ
(Ca) thể trong một khoảng thời gian cố định. Ví dụ, có thể có 4 ca của các cá nhân Kiểm
soát Vận hành CNTT nhằm hỗ trợ một Dịch vụ CNTT được sử dụng 24 giờ/ngày.
Simulation modeling (Thiết kế Dịch vụ)/ (Liên tục Cải tiến Dịch vụ) Một kỹ thuật tạo ra một mô hình chi tiết
(Mô hình hóa Giả lập) nhằm dự đoán hành vi của một Đơn vị Cấu hình hay một Dịch vụ CNTT. Các Mô hình
Giả lập có thể rất chính xác nhưng rất tốn kém và mất thời gian để tạo ra. Một Mô
hình Giả lập thường được tạo ra bằng cách sử dụng các Đơn vị Cấu hình thực tế đang
được mô hình hóa, với Khối lượng công việc hoặc các Giao dịch được nhân tạo hóa.
Chúng được sử dụng trong Quản lý Công suất khi kết quả chính xác là rất quan trọng.
Một mô hình giả lập thỉnh thoảng được gọi là Điểm chuẩn Hiệu suất.
Single Point of Failure (Thiết kế Dịch vụ) Bất kỳ Đơn vị cấu hình nào có thể gây ra một Sự cố khi nó bị lỗi, và
(Điểm Đơn Lỗi) khi mà Biện pháp đối phó đã không được triển khai. Một SPoF có thể là một cá nhân,
một bước trong một Quy trình hay Hoạt động, cũng có thể là một Thành phần của Hạ
tầng CNTT. Xem thêm Lỗi.
SMART (Thiết kế Dịch vụ)(Liên tục Cải tiến Dịch vụ) Một từ viết tắt giúp cho việc gợi nhớ rằng
các mục tiêu trong Thỏa thuận Mức Dịch vụ và Kế hoạch Dự án nên Cụ thể, Đo lường
được, Có thể đạt được, Có liên quan và Kịp thời.
Specification Một định nghĩa chính thức của các Yêu cầu. Một Đặc tả có thể được sử dụng để định
(Đặc tả) nghĩa các Yêu cầu kỹ thuật hay Yêu cầu Vận hành, và có thể là nội bộ hoặc bên ngoài.
Rất nhiều Tiêu chuẩn công cộng bao gồm một Quy tắc Thực hành và một Đặc tả. Đặc
tả xác định Tiêu chuẩn mà một Tổ chức có thể được Kiểm toán.
Stakeholder Tất cả các cá nhân có liên quan đến một Tổ chức, Dự án, Dịch vụ CNTT, v.v… Các bên
(Bên liên quan) liên quan có thể liên quan đến các Hoạt động, mục tiêu, Tài nguyên, hay Sản phẩm.
Các bên liên quan có thể bao gồm Khách hàng, Đối tác, Nhân viên, Cổ đông, Chủ sở
hữu, v.v… Xem thêm RACI.
Stvàard Một Yêu cầu bắt buộc. Các ví dụ bao gồm ISO/IEC 20000 (một Tiêu chuẩn quốc tế),
(Tiêu chuẩn) một tiêu chuẩn bảo mật nội bộ cho việc thiết lập cấu hình Unix, một tiêu chuẩn chính
phủ cho việc các Hồ sơ tài chính được duy trì như thế nào. Khái niệm Tiêu chuẩn cũng
được sử dụng để chỉ một Quy tắc Thực hành hay một Đặc tả được công bố bởi một Tổ
chức Tiêu chuẩn quốc tế như ISO hay BSI. Tham khảo Hướng dẫn.
Stvàby (Thiết kế Dịch vụ) Được sử dụng để đề cập tới các Tài nguyên không được yêu cầu để
(Trạng thái chờ) cung cấp một Dịch vụ CNTT đang Hoạt động, nhưng phải sẵn sàng để hỗ trợ Kế hoạch
Liên tục Dịch vụ CNTT. Ví dụ, một trung tâm tích hợp và xử lý dữ liệu Chờ được duy trì
để hỗ trợ các thỏa thuận Hot Stvàby, Warm Stanby hay Cold Stvàby.
Statement of (Thiết kế Dịch vụ) Một Tài liệu bao gồm mọi Yêu cầu về mua sắm một sản phẩm, hoặc
Requirements một Dịch vụ CNTT mới hay đã được thay đổi. Xem thêm Điều khoản Tham khảo.
(Tuyên bố về các Yêu

cầu)
Status Tên gọi một trường bắt buộc trong nhiều kiểu Hồ sơ. Nó cho thấy tình trạng hiện tại
(Trạng thái) trong Vòng đời của Đơn vị cấu hình, Sự cố, Vấn đề, v.v… có liên quan.
Strategic (Chiến lược Dịch vụ) Cấp cao nhất trong ba mức của việc Hoạch định và cung cấp
((Mang tính) Chiến (Chiến lược, Chiến thuật, Vận hành). Các Hoạt động (mang tính) Chiến lược bao gồm
lược) thiết lập Mục tiêu và Hoạch định dài hạn để đạt được Tầm nhìn tổng thể.
Strategy (Chiến lược Dịch vụ) Kế hoạch (mang tính) Chiến lược để đạt được các Mục tiêu đã
(Chiến lược) được xác định.
Supplier (Chiến lược Dịch vụ)/(Thiết kế Dịch vụ) Một Bên thứ ba chịu trách nhiệm cho việc cung
(Nhà cung cấp) cấp hàng hóa hay Dịch vụ được yêu cầu để cung cấp Dịch vụ CNTT. Ví dụ, các Nhà
cung cấp có thể bao gồm các nhà cung cấp phần cứng, phần mềm, hệ thống mạng, hệ
thống viễn thông, và Tổ chức thuê ngoài. Xem thêm Hợp đồng Cơ sở, Chuỗi cung ứng.
Supplier và Contract (Thiết kế Dịch vụ) Một Cơ sở dữ liệu hay một Tài liệu có cấu trúc được sử dụng để
Database quản lý các Hợp đồng cung cấp trong suốt Vòng đời của chúng. SCD bao gồm các
(Cơ sở dữ liệu Nhà cung Thuộc tính chủ yếu của mọi Hợp đồng với các Nhà cung cấp, và nên là một phần của
cấp và Hợp đồng) Hệ thống Quản lý Kiến thức Dịch vụ.
Supplier Management (Thiết kế Dịch vụ) Quy trình chịu trách nhiệm cho việc đảm bảo rằng mọi Hợp đồng và
(Quản lý Nhà cung cấp) Nhà cung cấp hỗ trợ các nhu cầu cần thiết của Doanh nghiệp, và mọi Nhà cung cấp
đáp ứng được các điều khoản cam kết trong hợp đồng.
Supply Chain (Chiến lược Dịch vụ) Các Hoạt động trong một Chuỗi Giá trị được thực hiện bởi các
(Chuỗi cung ứng) Nhà cung cấp. Một chuỗi Cung ứng thường liên quan đến nhiều Nhà cung cấp, trong đó
mỗi Nhà cung cấp thêm giá trị vào sản phẩm hay dịch vụ. Xem thêm Mạng Giá trị.
Support Group (Vận hành Dịch vụ) Một nhóm các cá nhân có kỹ năng kỹ thuật. Nhóm Hỗ trợ cung cấp
(Nhóm hỗ trợ) hỗ trợ Kỹ thuật cần thiết bởi mọi Quy trình Quản lý Dịch vụ CNTT. Xem thêm Quản lý
Kỹ thuật.
Support Hours (Thiết kế Dịch vụ)/(Vận hành Dịch vụ) Thời gian hoặc giờ khi mà sự hỗ trợ là sẵn sàng
(Giờ hỗ trợ) đối với Người sử dụng. Thông thường, đây là giờ mà Bộ phận Hỗ trợ Dịch vụ là sẵn
sàng. Giờ hỗ trợ nên được định nghĩa trong một Thỏa thuận Mức Dịch vụ, và có thể
khác với Giờ Dịch vụ. Ví dụ, Giờ Dịch vụ có thể là 24 giờ trong một ngày nhưng Giờ hỗ
trợ có thể là từ 7:00 đến 19:00
Supporting service (Chiến lược Dịch vụ) Một Dịch vụ kích hoạt hay tăng cường một Dịch vụ Cốt lõi. Ví dụ,
(Dịch vụ hỗ trợ) Dịch vụ Danh bạ hay Dịch vụ sao lưu.
SWOT Analysis (Liên tục Cải tiến Dịch vụ) Một kỹ thuật xem xét và phân tích các điểm mạnh và điểm
(Phân tích SWOT) yếu nội tại của một Tổ chức và các cơ hội bên ngoài và các nguy cơ mà nó (T ổ chức)
phải đối mặt. SWOT đại diện cho Strenghts – Điểm mạnh (S), Weaknesses – Điểm yếu
(W), Opportunities – Cơ hội (O) và Threats – Nguy cơ (T)
System Một số các sự vật có liên quan làm việc cùng nhau để đạt được một Mục tiêu tổng thể.
(Hệ thống) Ví dụ,
- Một Hệ thống máy tính bao gồm phần cứng, phần mềm và Ứng dụng.
- Một Hệ thống quản lý bao gồm nhiều Quy trình được lập kế hoạch và quản lý
cùng nhau. Ví dụ, một Hệ thống Quản lý Chất lượng.
- Một Hệ thống Quản lý Cơ sở dữ liệu hay một Hệ điều hành bao gồm nhiều mô-
đun phần mềm khác nhau, được thiết kế để hoàn thành một tập hợp các Chức
năng có liên quan.
System Management Một phần của Quản lý Dịch vụ CNTT tập trung vào việc quản lý Hạ tầng CNTT hơn là
(Quản lý Hệ thống) Quy trình
Tactical Mức nằm giữa trong 3 cấp độ của Hoạch định và cung cấp (Chiến lược, Chiến thuật,
(Chiến thuật) Vận hành). Các Hoạt động Chiến thuật bao gồm thuật ngữ Kế hoạch trung hạn cần
thiết để đạt được một số Mục tiêu đặc biệt, thường được trải dài từ vài tuần cho tới
vài tháng.
Technical Management (Vận hành Dịch vụ) Chức năng chịu trách nhiệm cho việc cung cấp kỹ năng kỹ thuật
(Quản lý Kỹ thuật) trong hỗ trợ Dịch vụ CNTT và quản lý Cở sở hạ tầng CNTT. Quản lý Kỹ thuật xác định
vai trò của nhóm Hỗ trợ cũng như là các công cụ, Quy trình và Thủ tục cần thiết.
Technical Service Xem Dịch vụ Cơ sở hạ tầng.
(Dịch vụ Kỹ thuật)
Technical Support Xem quản lý Kỹ thuật.
(Hỗ trợ kỹ thuật)
Terms of Reference (Thiết kế Dịch vụ) Một Tài liệu chỉ định các Yêu cầu, Phạm vi, Sản phẩm có thể cung
(Tham chiếu Thuật cấp được, Tài nguyên và lịch trình cho một Dự án hay Hoạt động.
ngữ)
Test (Chuyển tiếp Dịch vụ) Một hoạt động chỉ ra rằng một Đơn vị Cấu hình, Dịch vụ CNTT,
(Kiểm tra) Quy trình v.v… đáp ứng được Đặc tả hoặc các Yêu cầu đã Thỏa thuận. Chấp thuận.
Third Party Một người, nhóm hoặc Doanh nghiệp không phải là một phần của Thỏa thuận Mức Dịch
(Bên thứ ba) vụ đối với một dịch vụ CNTT, nhưng được yêu cầu để đảm bảo rằng việc cung cấp
thành công Dịch vụ CNTT đó. Ví dụ một Nhà cung cấp phần mềm, một công ty bảo trì
phần cứng hoặc một phòng ban liên quan đến hạ tầng. Các yêu cầu cho Bên thứ ba
thường được mô tả trong các Hợp đồng Cơ sở hoặc Những thỏa thuận Mức Vận hành.
Third-line Support (Vận hành Dịch vụ) Mức độ thứ ba trong cấu trúc phân cấp của nhóm Hỗ trợ liên tham
(Tuyến hỗ trợ thứ ba) gia vào giải quyết các Sự cố và điều tra về các Vấn đề. Mỗi cấp độ bao gồm nhiều kỹ
năng đặc biệt, hoặc có nhiều thời gian hoặc tài nguyên hơn.
Threat Bất kỳ điều gì có thể khai thác một Lỗ hổng. Bất kỳ nguyên nhân tiềm ẩn nào của Sự
(Mối đe dọa) cố đều có thể được coi là Mối đe dọa. Ví dụ hỏa hoạn là Mối đe dọa có thể khai thác
Lỗ hổng của lớp phủ sàn dễ cháy. Thuật ngữ này thường được sử dụng trong Quản lý
Bảo mật Thông tin và Quản lý Liên tục Dịch vụ CNTT, nhưng cũng áp dụng cho các lĩnh
vực khác như Quản lý Sự cố và Quản lý Tính sẵn sàng.
Threshold Giá trị của một Chỉ số sẽ gây ra một cảnh báo, hoặc các hành động quản lý được thực
(Ngưỡng) thi. Ví dụ “Sự cố có mức Ưu tiên 1 được giải quyết trong không quá 4 tiếng”, ”nhiều
hơn 5 đĩa phần mềm lỗi trong 1 giờ”, ”hoặc”nhiều hơn 10 thay đổi bị lỗi trong 1
tháng”.
Throughput (Thiết kế Dịch vụ) Một sự đo lường về số Giao dịch hoặc các Hoạt động khác, được
(Thông lượng) thực hiện trong một khoảng thời gian xác định. Ví dụ, 5000 thư điện tử được gửi trong
1 giờ, hoặc 200 tác vụ Đọc/Ghi của đĩa trong 1 giây.
Total Cost of (Chiến lược Dịch vụ) Một Phương pháp được sử dụng để hỗ trợ quyết định đầu tư. TCO
Ownership tiếp cận toàn bộ Vòng đời của Chi phí của một Đơn vị cấu hình, không chỉ là Chi phí
(Tổng Chi phí Sở hữu) ban đầu hoặc giá mua.
Transaction Một chức năng rời rạc được thực hiện bởi Dịch vụ CNTT. Ví dụ chuyển tiền từ tài khoản
(Giao dịch) ngân hàng này sang tài khoản ngân hàng khác. Một Giao dịch đơn lẻ có thể bao gồm
nhiều lần bổ sung, xóa và sửa đổi dữ liệu. Tất cả những điều này đều hoàn thành
thành công hoặc không có gì được thực hiện.
Transition (Chuyển tiếp Dịch vụ) Một sự thay đổi trong trạng thái tương ứng với một sự di
(Chuyển đổi) chuyển của Dịch vụ CNTT hoặc Đơn vị Cấu hình từ trạng thái Vòng đời này sang trạng
thái kế tiếp.
Trend Analysis (Phát triển dịch vụ) Việc phân tích dữ liệu nhằm xác định các hình mẫu liên quan tới-
(Phân tích xu hướng) thời gian. Phân tích xu hướng sử dụng trong Quản lý Vấn đề để xác định những Lỗi
phổ biến hoặc sự đổ vỡ của Đơn vị cấu hình, và trong việc Quản lý Công suất như là 1
công cụ Mô hình hóa nhằm đoán trước hành vi trong tương lai. Nó cũng thư ờng được
sử dụng như 1 công cụ quản lý cho việc xác định những điểm kém hiệu quả trong Quy
trình Quản lý Dịch vụ CNTT.
Tuning Hoạt động chịu trách nhiệm cho việc Hoạch định những thay đổi đế sử dụng Tài
(Điều chỉnh) nguyên hiệu quả nhất. Điều chỉnh là một phần của Quản lý Hiệu suất, vốn cũng bao
gồm giám sát Hiệu suất và triển khai những Thay đổi cần thiết.
Underpinning Contract (Thiết kế Dịch vụ) Một hợp đồng giữa nhà cung cấp Dịch vụ CNTT và một Bên thứ ba.
(Hợp đồng Cơ sở) Bên thứ ba cung cấp hàng hóa hoặc các Dịch vụ hỗ trợ việc cung cấp một Dịch vụ
CNTT cho một Khách hàng. Hợp đồng Cơ sở xác định các mục tiêu và trách nhiệm được
yêu cầu để đạt được các mức mục tiêu Dịch vụ đã thỏa thuận trong một SLA.
Urgency (Chuyển tiếp Dịch vụ)/(Thiết kế Dịch vụ) Một thước đo khoảng thời gian cho đến khi
((Tính) Khẩn cấp) một Vấn đề, Sự cố hay Thay đổi có tác động đáng kể tới Doanh nghiệp. Ví dụ, một Sự
cố có Tác động cao có thể có mức Khẩn cấp là thấp, nếu sự tác động không ảnh hưởng
tới doanh nghiệp cho đến khi kết thúc năm tài chính. Tác động và Khẩn cấp được sử
dụng để xác định Mức độ ưu tiên.
Usability (Thiết kế Dịch vụ) Sự dễ dàng mà một Ứng dụng, sản phẩm, hay Dịch vụ CNTT có thể
((Tính) Dễ sử dụng) được sử dụng. Các Yêu cầu về (tính) Dễ sử dụng thường được bao gồm trong một
Tuyên bố các yêu cầu.
Use Case (Thiết kế Dịch vụ) Một kỹ thuật được sử dụng để xác định các chức năng và các Mục
(Trường hợp Sử dụng) tiêu cần thiết, và để thiết kế các Kiểm tra. Các Trường hợp Sử dụng xác định các kịch
bản thực tế mô tả các tương tác giữa Người sử dụng và một Dịch vụ CNTT hoặc Hệ
thống khác.
Utility (Chiến lược Dịch vụ) Chức năng được cung cấp bởi một Sản phẩm hoặc Dịch vụ để đáp
(Tính tiện dụng) ứng một yêu cầu cụ thể. Tính tiện dụng thường được tóm tắt như là “những gì mà nó
làm”.
Validation (Chuyển tiếp Dịch vụ) Một Hoạt động đảm bảo rằng một Dịch vụ CNTT, Quy trình, Kế
(Xác nhận) hoạch, hay Sản phẩm có thể cung cấp được khác, mới hay đã thay đổi, thỏa mãn được
yêu cầu của Doanh nghiệp. Xác nhận đảm bảo rằng các Yêu cầu Kinh doanh vẫn được
đáp ứng ngay cả khi chúng có thể thay đổi so với thiết kế ban đầu. Xem thêm Xác
minh, Chấp thuận.
Value Chain (Chiến lược Dịch vụ) Một chuỗi các Quy trình tạo ra một sản phẩm hay Dịch vụ CNTT
(Chuỗi giá trị) có giá trị cho Khách hàng. Mỗi bước trong chuỗi này xây dựng từ bước trước đó và
đóng góp cho sản phẩm hay dịch vụ tổng thể. Tham khảo Mạng giá trị
Value for Money Một phép đo không chính thức về Hiệu quả Chi phí. Giá trị của Tiền thường được căn
(Giá trị của Tiền) cứ trên sự so sánh với Chi phí của phương án thay thế. Xem thêm Phân tích Lợi ích
(của) Chi phí.
Value Network (Chiến lược Dịch vụ) Một tập hợp phức tạp của các Mối quan hệ giữa hai hay nhiều
(Mạng giá trị) nhóm hay Tổ chức. Giá trị được tạo ra thông qua việc trao đổi kiến thức, thông tin,
hàng hóa hay Dịch vụ. Xem thêm Chuỗi giá trị, Sự cộng tác.
Variance Sự khác nhau giữa một giá trị đã được lên kế hoạch và giá trị được đo lường trong
(Phương sai) thực tế. Thường được sử dụng trong Quản lý Tài chính, Quản lý Công suất và Quản lý
Mức Dịch vụ, nhưng có thể được chấp nhận trong nhiều hoàn cảnh khác nơi mà có sẵn
các Kế hoạch.
Verification (Chuyển tiếp Dịch vụ) Một Họat động nhằm đảm bảo rằng một Dịch vụ CNTT, Quy
(Xác minh) trình, Kế hoạch hoặc Kết quả khác, mới hoặc được thay đổi, được hoàn thành, chính
xác và Đáng tin cậy và đáp ứng được theo đặc tả thiết kế của nó. Xem thêm Xác nhận,
Chấp thuận.
Version (Chuyển tiếp Dịch vụ) Một phiên bản được sử dụng để xác định một Đường cơ sở của
(Phiên bản) Đơn vị cấu hình. Các phiên bản thường sử dụng một quy tắc đặt tên cho phép sự tuần
tự hoặc ngày tháng của mỗi Đường cơ sở cần được xác định. Ví dụ, Ứng dụng Trả
lương Phiên bản 3 chứa đựng những chức năng được cập nhật từ Phiên bản 2.
Vision Một mô tả của Tổ chức về cái mà được định hình sẽ trờ thành trong tương lai. Một
(Tầm nhìn) tầm nhìn được tạo ra bởi các nhà quản trị cấp cao và nó thường được sử dụng nhằm
giúp ảnh hưởng tới Văn hóa và Hoạch định Chiến lược.
Vital Business Function (Thiết kế Dịch vụ) Một Chức năng của Quy trình Nghiệp vụ thực sự là rất quan trọng
(Chức năng Nghiệp vụ cho sự thành công của Doanh nghiệp. Các Chức năng Nghiệp vụ Trọng yếu là sự cân
Trọng yếu) nhắc quan trọng của Quản lý Liên tục Kinh doanh, Quản lý Liên tục Dịch vụ CNTT và
Quản lý tính Sẵn sàng.
Vulnerability Một điểm yếu có thể bị khai thác bởi một Nguy cơ. Ví dụ, một cổng đang mở trên
(Lỗ hổng) tường lửa, một mật khẩu không bao giờ thay đổi, hay một tủ có thể cháy. Mất kiểm
soát cũng được cân nhắc như là một Lỗ hổng.
Warm Stvàby Xem Khôi phục trung bình
(Trạng thái chờ Ấm)
Warranty (Chiến lược Dịch vụ) Một sự cam kết hoặc bảo đảm rằng một sản phẩm hoặc dịch vụ sẽ
Bảo hành đáp ứng các Yêu cầu đã được thỏa thuận. Xem thêm bảo đảm Dịch vụ.
Work Instruction Một tài liệu chứa đựng những hướng dẫn chi tiết mô tả một cách chính xác những bước
(Hướng dẫn công việc) cần tuân theo để thực hiện một Hoạt động. Một hướng dẫn công việc chứa đựng nhiều
chi tiết hơn một thủ tục và chỉ được tạo nếu rất nhiều các hướng dẫn chi tiết được cần
đến.
Workaround (Vận hành Dịch vụ) Sự giảm thiểu hoặc loại bỏ Tác động của một Sự cố hay một Vấn
(Giải pháp thủ công) đề khi mà Giải pháp đầy đủ chưa thực sự sẵn sàng. Ví dụ, khởi động lại một Đơn vị
Cấu hình bị lỗi. Các Giải pháp thủ công cho các Vấn đề được tài liệu hóa lại trong Hồ
sơ Lỗi Đã biết. Các Giải pháp thủ công cho các Sự cố không liên kết tới các Hồ sơ Vấn
đề được tài liệu hóa trong Hồ sơ Sự cố.
Workload Các nguồn lực cần thiết để cung cấp một phần có thể xác định đượccủa một dịch vụ
(Khối lượng công việc) CNTT. Khối lượng công việc có thể được Phân loại theo Người sử dụng, nhóm Người sử
dụng, hoặc các Chức năng trong Dịch vụ CNTT. Điều này được sử dụng để hỗ trợ trong
việc phân tích và quản lý Công suất, Hiệu suất và Sử dụng csc Đơn vị cấu hình và Dịch
vụ CNTT. Thuật ngữ Khối lượng công việc đôi khi được sử dụng như là từ đồng nghĩa
với Thông lượng.

04-211202 Axelos - ITILv3 - Service Operation - Vi - Van Hanh Dich Vu

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04-211202 Axelos - ITILv3 - Service Operation - Vi - Van Hanh Dich Vu

Uploaded by

Copyright:

Available Formats

AXELOS® ITIL V3

CORE PUBLISH #4: SERVICE OPERATION

- Chiến lược dịch vụ

Kiến trúc sư trưởng, Thực tiễn Quản lý Dịch vụ ITIL

APMG Service Desk

Kiến trúc sư trưởng và các tác giả

Sharon Taylor (Aspect Group Inc) Kiến trúc sư trưởng

David Cannon (HP) Tác giả

David Wheeldon (HP) Tác giả

Nhóm thiết kế ITIL

Những đóng góp khác

Những người đánh giá

1.1 Tổng quan

1.2.1 Quản lý Dịch vụ

1.2.2 Những thực tiễn tốt trong lĩnh vực công

Hình 1.1 – Nguồn cung cấp Thực tiễn Quản lý Dịch vụ

1.2.3 ITIL và những thực tiễn tốt trong Quản lý

Thư viện ITIL có những thành phần sau đây:

 Chiến lược Dịch vụ,

Hình 1.2 – Cốt lõi ITIL

1.2.3.1 Chiến lược Dịch vụ

1.2.3.2 Thiết kế Dịch vụ

1.2.3.4 Vận hành Dịch vụ

1.2.3.5 Liên tục Cải tiến Dịch vụ

1.3 Mục đích

1.5 Tổng quan về các chương

Chương 7 mô tả các công cụ và công nghệ được sử dụng trong quá

2.1 Quản lý Dịch vụ là gì?

Định nghĩa về Quản lý Dịch vụ

2.2 Dịch vụ là gì?

2.2.1 Đề xuất giá trị

Định nghĩa về dịch vụ

2.3.1 Các chức năng

2.3.2 Các quy trình

Hình 2.2 – Một quy trình cơ bản

 Có thể đo lường được: Chúng ta có thể đo lường được quy

2.3.3 Chuyên môn hóa và sự phối hợp trong suốt

2.4 Nền tảng cơ bản của Vận hành Dịch vụ

2.4.1 Mục đích/đích đến/mục tiêu

2.4.3 Giá trị đối với doanh nghiệp

 Khi một dịch vụ đã được thiết kế và kiểm nghiệm, nó được kỳ

2.4.4 Tối ưu hóa hiệu suất Vận hành Dịch vụ

2.4.5.1 Quản lý Sự kiện

2.4.5.2 Quản lý Sự cố và Vấn đề

2.4.5.3 Thực hiện Yêu cầu

2.4.5.4 Quản lý Quyền truy cập

2.4.6 Các chức năng trong Vận hành Dịch vụ

2.4.6.2 Quản lý Kỹ thuật

2.4.6.3 Quản lý Vận hành CNTT

2.4.6.4 Quản lý Ứng dụng

3 Các nguyên t ắ c V ậ n hành D ịch v ụ

3.1 Các chức năng, đội, nhóm, phòng ban

3.2 Đạt được sự cân bằng trong Vận hành Dịch vụ

3.2.1 Quan điểm CNTT nội bộ so với quan điểm

thành tựu kỹ thuật tốt cũng chính là dịch vụ kinh doanh.

3.2.2 Tính ổn định so với khả năng ứng phó

Trọng tâm  Công nghệ  Đầu ra đối với doanh nghiệp

tiêu chuẩn sẽ được thực hiện để cung cấp

thống ‘của riêng họ’ để có quyền

chỉnh và quản lý nhu cầu, không dịch vụ CNTT khác

khối lượng công việc không có liên quan

Lưu ý đặc biệt: bao nhiêu là đủ?

 CNTT giới hạn chất lượng của

3.2.4 Đối phó so với chủ động