Axelos - ITILv3 - Service Design - Vi

AXELOS ® ITIL V3
CORE PUBLISH #2: SERVICE DESIGN
THIẾT KẾ DỊCH VỤ
ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

Chuyển ngữ: Nguyễn Thế Hùng – email: nguyenthehung.it@gmail.com
1
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 giao dịch vụ
- Vận hành dịch vụ
- Liên tục cải tiến dịch vụ

2
Mục lục
Lời t ự a ................................................................................................................................................... 11
Lời t ự a củ a O C G ............................................................................................................................. 11
Lời t ự a củ a Ki ến t rú c s ư trư ởn g .............................................................................................. 12
Lời g iớ i th iệu ...................................................................................................................................... 13
Th ôn g t in li ên h ệ ........................................................................................................................... 15
Lời cả m ơn ........................................................................................................................................... 16
Ki ến t rú c sư tr ư ởn g và t ác gi ả ................................................................................................. 16
Nh óm th i ết k ế I TI L ........................................................................................................................ 16
Cá c c ố vấn ........................................................................................................................................ 16
N h ữn g đón g góp k h ác .................................................................................................................. 16
Nh óm tư vấn I T IL ........................................................................................................................... 16
Ngư ời x e m x ét ................................................................................................................................ 17
1 Gi ới th i ệu ..................................................................................................................................... 18
1. 1 Tổn g q u an ........................................................................................................................... 20
1. 2 Bối cả n h .............................................................................................................................. 20
1. 2.1 Qu ản lý D ịc h vụ ........................................................................................................ 20
1. 2.2 Th ực ti ễn t ốt t ron g kh u v ực côn g ..................................................................... 21
1. 2.3 IT IL và th ự c t i ễn t ốt t ro n g q u ản lý d ịc h vụ ................................................... 22
1. 3 Mụ c đí ch ............................................................................................................................. 26
1. 4 Sử d ụ n g ............................................................................................................................... 26
2 Qu ản lý d ị ch vụ n h ư m ộ t th ự c t i ễn .................................................................................... 27
2. 1 Qu ản lý d ị ch vụ là gì ? ..................................................................................................... 27
2. 2 Cá c d ị ch vụ là gì ? ............................................................................................................. 28
2. 2.1 Đề xu ất g iá t r ị .......................................................................................................... 28
2. 3 Cá c Ch ứ c n ăn g và q u y t r ìn h t ron g su ốt v òn g đ ờ i ................................................. 29
2. 3.1 Cá c Ch ứ c n ăn g .......................................................................................................... 29
2. 3.2 Cá c Qu y tr ìn h ............................................................................................................ 30
2. 3.3 Ch u y ên môn h óa v à p h ố i h ợp tro n g su ốt vòn g đ ời .................................... 31
2. 4 Cá c n g u y ê n t ắ c cơ b ản t ron g T h i ết k ế D ịch v ụ ..................................................... 31
2. 4.1 Mụ c đí ch / đí ch đ ến / mụ c ti êu .............................................................................. 31
2. 4.2 Ph ạ m vi ....................................................................................................................... 32
2. 4.3 Gi á tr ị đ ối v ới d oan h n g h i ệ p ............................................................................... 38
3 Cá c n g u y ê n t ắ c Ch i ến lư ợc Dị ch vụ .................................................................................... 41
3. 1 Tạo ra gi á t r ị ...................................................................................................................... 43
3. 2 Cân b ằn g th i ết k ế ............................................................................................................ 44
3. 3 Xác đ ịn h c ác y êu c ầu d ị c h vụ ....................................................................................... 47
3. 4 Xác đ ịn h và gh i n h ận cá c y êu c ầu và đ ịn h h ư ớn g kin h d oan h ......................... 49
3. 5 Cá c h o ạ t độ n g th i ết k ế .................................................................................................. 51

3
3. 6 Cơ s ở n ền t ả n g củ a Ch i ế n lư ợc D ịch v ụ ................................................................... 53
3. 6.1 Th i ết k ế cá c gi ả i p h áp d ị ch vụ ................................................................................... 54
3. 6.2 Th i ết k ế cá c h ệ th ốn g h ỗ tr ợ, đ ặc b i ệt là Dan h m ụ c Dị ch vụ ......................... 57
3. 6.3 Th i ết k ế cá c k i ến t rú c côn g n gh ệ ............................................................................. 61
3. 6.3 .1 Qu ản lý Cô n g n g h ệ ..................................................................................................... 69
Cá c ki ến trú c côn g n g h ệ ......................................................................................................... 69
Cá c ki ến trú c q u ả n lý ............................................................................................................... 70
3. 6.4 Th i ết k ế cá c Qu y t rìn h .................................................................................................. 74
3. 6.5 Th i ết k ế cá c h ệ th ốn g và ch ỉ số đo l ư ờn g ............................................................. 77
3.7 Các hoạt động thiết kế tiếp theo ........................................................................................... 80
3. 7.1 Đán h giá cá c gi ả i p h á p t h ay th ế ........................................................................ 80
3. 7.2 Mu a sắ m gi ải p h áp ưu t i ên .................................................................................. 81
3. 7.3 Ph át t ri ển gi ải p h áp d ịc h vụ ................................................................................ 81
3.8 Những ràng buộc thiết kế ...................................................................................................... 82
3.9 Kiến trúc định hướng dịch vụ ................................................................................................. 83
3. 10 Qu ản lý D ịc h vụ N gh i ệp vụ ........................................................................................... 84
3. 11 Cá c mô h ìn h Th i ế t k ế Dị ch vụ ...................................................................................... 86
3. 11. 1 Cá c l ựa ch ọn m ô h ì n h c u n g c ấp ............................................................................. 87
3. 11. 2 Cá c l ựa ch ọn th i ết k ế và p h át t ri ển ...................................................................... 89
3. 11. 3 Cá c p h ươn g p h á p ti ếp c ận th i ết k ế và p h át t ri ển ........................................... 92
3. 11. 3. 1 Ph át t ri ển ứn g d ụ n g n h a n h ch ó n g .................................................................... 92
3. 11. 3. 2 Cá c g i ả i p h áp th ư ơn g m ại c ó sẵn ...................................................................... 96
4 Cá c q u y t rìn h Th i ết k ế D ịch vụ ............................................................................................. 97
4. 1 Qu ản lý M ụ c l ụ c D ịch v ụ ............................................................................................. 100
4. 1.1 Mụ c đí ch / đí ch đ ến / mụ c ti êu ............................................................................ 100
4. 1.2 Ph ạ m vi ..................................................................................................................... 100
4. 1.3 Gi á tr ị đ ối v ới d oan h n g h i ệ p ............................................................................. 100
4. 1.4 Cá c ch ín h s ách , n gu y ên t ắc và ý t ư ởn g cơ b ản .......................................... 100
4. 1.5 Cá c h o ạ t độ n g, p h ư ơn g p h áp và k ỹ th u ậ t q u y trì n h ................................ 104
4. 1.6 Cá c đ i ều ki ện kí ch h o ạt, đ ầu và o, đ ầ u ra và t ươ n g tá c .......................... 105
4. 1.7 Qu ản lý th ô n g tin .................................................................................................. 105
4. 1.8 Cá c Ch ỉ s ố Hi ệu s u ất Qu an tr ọ n g ( KPI s ) ........................................................ 105
4. 1.9 N h ữn g th á ch t h ứ c, các Y ếu t ố Th àn h cô n g Qu an tr ọn g và R ủ i ro ....... 106
4. 2 Qu ản lý M ức D ịch vụ .................................................................................................... 107
4. 2.1 Mụ c đí ch / đí ch đ ến / mụ c ti êu ............................................................................ 107
4. 2.2 Ph ạ m vi ..................................................................................................................... 108
4. 2.3 Gi á tr ị đ ối v ới d oan h n g h i ệ p ............................................................................. 109
4. 2.4 Cá c ch ín h s ách /n g u yê n t ắc/ý tư ởn g c ơ b ả n ................................................ 109
4. 2.5 Cá c h o ạ t độ n g, p h ư ơn g p h áp và k ỹ th u ậ t q u y trì n h ................................ 110

4
4. 2.5 .1 Th iế t k ế kh u ôn kh ổ S LA ...................................................................................... 112
4. 2.5 .2 Xác đ ịn h , l ập th àn h văn b ản và th ỏa t h u ận cá c y êu c ầu đ ối v ới cá c
d ịch v ụ mớ i và đ ưa cá c SL R ................................................................................................. 114
4. 2.5 .3 Gi á m sát h i ệu su ấ t d ị ch vụ so vớ i S LA ........................................................... 116
4. 2.5 .4 Ki ể m t ra, đ o l ư ờ n g v à c ải th i ện mứ c đ ộ h à i l òn g c ủ a kh ác h h àn g ...... 119
4. 2.5 .5 Xe m x ét và đi ều ch ỉn h c ác th ỏa th u ận và p h ạ m vi d ị ch vụ n ền t ản g . 120
4. 2.5 .6 Đưa ra cá c b áo cá o d ị ch vụ ............................................................................... 121
4. 2.5 .7 Ti ến h àn h x em x ét d ịc h vụ và th ú c đ ẩ y c ác c ả i ti ến t ron g mộ t SI P t ổn g
th ể 123
4. 2.5 .8 Xe m x ét và đi ều ch ỉn h c ác SL A, p h ạ m v i d ịch v ụ và cá c th ỏa th u ận n ền
tản g 123
4. 2.5 .9 Ph át t ri ển cá c mố i l i ên h ệ và q u an h ệ .......................................................... 124
4. 2.5 .1 0 Cá c p h àn n àn và kh en n g ợ i ........................................................................... 125
4. 2.6 4. 1.6 C ác đi ều ki ện k ích h o ạt, đ ầu và o, đ ầ u ra và tươ n g tác ............... 125
4. 2.6 .1 Cá c đ ầu vào c ủ a q u y t rì n h SL M ........................................................................ 126
4. 2.6 .2 Cá c đ ầu ra c ủ a q u y t rìn h SL M ........................................................................... 126
4. 2.7 Cá c Ch ỉ s ố Hi ệu s u ất Ch í n h y ếu ( KP I) ............................................................. 127
4. 2.7 .1 Cá c K PI ...................................................................................................................... 129
4. 2.8 Qu ản lý th ô n g tin .................................................................................................. 130
4. 2.9 N h ữn g th á ch t h ứ c, các Y ếu t ố Th àn h cô n g Qu an tr ọn g và r ủ i ro ........ 130
4. 2.9 .1 Cá c Y ếu t ố T h àn h côn g Qu an t r ọn g ................................................................ 133
4. 3 Qu ản lý Côn g su ất ......................................................................................................... 134
4. 3.1 Mụ c đí ch / đí ch đ ến / mụ c ti êu ................................................................................. 134
4. 3.2 Ph ạ m vi ......................................................................................................................... 135
4. 3.3 Gi á tr ị đ ối v ới d oan h n g h i ệ p ................................................................................. 138
4. 3.4 Cá c ch ín h s ách /n g u y ê n t ắc/ý tư ởn g c ơ b ả n .................................................... 138
4. 3.4 .1 Qu ản lý Côn g su ất K in h d oan h ......................................................................... 140
4. 3.4 .2 Qu ản lý Côn g su ất Dị ch vụ ................................................................................. 140
4. 3.4 .3 Qu ản lý Côn g su ất Th àn h p h ần ........................................................................ 140
4. 3.5 Cá c h o ạ t đ ộ n g, p h ư ơn g p h áp và k ỹ th u ậ t q u y trì n h ..................................... 141
4. 3.5 .1 Qu ản lý Côn g su ất K in h d oan h ......................................................................... 142
4. 3.5 .2 Qu ản lý Côn g su ất Dị ch vụ ................................................................................. 145
4. 3.5 .3 Qu ản lý Côn g su ất Th àn h p h ần ........................................................................ 146
4. 3.5 .4 Cá c h o ạ t độ n g n ền t ản g củ a Qu ản lý Côn g su ất ........................................ 147
4. 3.5 .5 Qu ản lý và k i ể m soát n g ư ỡn g ........................................................................... 154
4. 3.5 .6 Qu ản lý N h u c ầu .................................................................................................... 155
4. 3.5 .7 Mô h ìn h h ó a và t ạo xu h ư ớn g .......................................................................... 156
4. 3.5 .8 Địn h cỡ ứn g d ụ n g .................................................................................................. 158
4. 3.6 4. 1.6 C ác đi ều ki ện k ích h o ạt, đ ầu và o, đ ầ u ra và tư ơ n g tác ................... 159
4. 3.6 .1 Cá c Đ ầ u vào ............................................................................................................. 160

5
4. 3.6 .2 Cá c Đ ầ u ra ............................................................................................................... 161
4. 3.7 Cá c Ch ỉ s ố Hi ệu s u ất Qu an tr ọ n g ( KPI ) .............................................................. 162
4. 3.8 Qu ản lý th ô n g tin ...................................................................................................... 162
4. 3.8 .1 Hệ t h ốn g Th ôn g t in Qu ả n lý Côn g su ất ......................................................... 164
4. 3.9 N h ữn g th á ch t h ứ c, Y ếu t ố T h àn h côn g Qu an t r ọn g và r ủ i ro .................... 165
4. 4 Qu ản lý Tín h s ẵn sàn g .................................................................................................. 167
4. 4.2 Ph ạ m vi ......................................................................................................................... 167
4. 4.5 .1 N h ữn g h o ạ t độn g ứn g p h ó c ủ a Qu ả n lý T ín h s ẵ n sàn g ............................ 177
4. 4.5 .2 Cá c h o ạ t độ n g ch ủ độn g củ a Qu ản lý Tí n h s ẵn s à n g ................................ 191
4. 4.6 Cá c y ếu t ố kí ch h o ạt, đ ầ u v ào, đ ầu r a và gia o d i ện ..................................... 212
4. 4.6 .1 Cá c Đ ầ u vào ............................................................................................................. 212
4. 4.6 .2 Cá c Đ ầ u ra ............................................................................................................... 213
4. 4.7 Cá c Ch ỉ s ố Hi ệu s u ất Qu an tr ọ n g ..................................................................... 214
4. 4.8 Qu ản lý th ô n g tin .................................................................................................. 215
4. 4.9 N h ữn g th á ch t h ứ c, các Y ếu t ố Th àn h cô n g Qu an tr ọn g và r ủ i ro ........ 217
4. 5 Qu ản lý L iê n t ụ c D ịc h vụ CN T T .................................................................................. 218
4. 5.1 Mụ c đí ch / đí ch đ ến /c ác mụ c ti êu ......................................................................... 218
4. 5.2 Ph ạ m vi ......................................................................................................................... 219
4. 5.5 .1 Gi ai đo ạ n 1 – Kh ở i đ ầu ....................................................................................... 222
4. 5.5 .2 Gi ai đo ạ n 2 – Cá c y êu c ầ u v à ch i ến l ư ợ c ...................................................... 223
4. 5.5 .3 Gi ai đo ạ n 3 – T ri ển kh ai ..................................................................................... 236
4. 5.5 .4 Gi ai đo ạ n 4 – T iếp t ụ c V ận h àn h ..................................................................... 241
4. 5.6 4. 1.6 C ác đi ều ki ện k ích h o ạt, đ ầu và o, đ ầ u ra và tươ n g tác ................... 243
4. 5.6 .1 Đầu vào ..................................................................................................................... 244
4. 5.6 .2 Đầu r a ........................................................................................................................ 245
4. 5.7 Cá c Ch ỉ s ố Hi ệu s u ất Ch í n h y ếu ............................................................................ 245
4. 5.8 Qu ản lý th ô n g tin ...................................................................................................... 246
4. 5.9 N h ữn g th á ch t h ứ c, các Y ếu t ố Th àn h cô n g Qu an tr ọn g và r ủ i ro ............ 246
4. 6 Qu ản lý B ảo mậ t Th ôn g tin ......................................................................................... 248
4. 6.2 Ph ạ m vi ......................................................................................................................... 249

6
4. 6.4 .1 Kh u ôn kh ổ b ảo mật .............................................................................................. 250
4. 6.4 .2 Ch ín h sá ch B ảo mậ t Th ô n g t in .......................................................................... 251
4. 6.4 .3 Hệ t h ốn g Qu ản lý B ả o m ật Th ôn g t in ( IS M S) .............................................. 251
4. 6.5 .1 Cá c b i ện p h áp b ảo mật ....................................................................................... 256
4. 6.5 .2 Qu ản lý n h ữn g v i p h ạm b ảo mật v à c ác s ự cố. ........................................... 258
4. 6.6 Cá c y ếu t ố kí ch h o ạt, đ ầ u v ào, đ ầu r a và gia o d i ện ..................................... 258
4. 6.6 .1 Đầu vào ..................................................................................................................... 259
4. 6.6 .2 Đầu r a ........................................................................................................................ 260
4. 6.7 Cá c Ch ỉ s ố Hi ệu s u ất Qu an tr ọ n g ......................................................................... 261
4. 6.8 Qu ản lý Th ôn g t in ...................................................................................................... 261
4. 6.9 N h ữn g th á ch t h ứ c, các Y ếu t ố Th àn h cô n g Qu an tr ọn g và n h ữn g r ủ i r o
262
4. 7 Qu ản lý N h à cu n g c ấp .................................................................................................. 264
4. 7.2 Ph ạ m vi ......................................................................................................................... 265
4. 7.5 .1 Đán h giá n h à cu n g c ấp v à h ợp đ ồn g mớ i ..................................................... 269
4. 7.5 .2 Ph ân lo ạ i n h à cu n g c ấp và d u y t rì Cơ s ở d ữ li ệu v ề Nh à cu n g c ấp v à
các H ợp đ ồn g ................................................................................................................................ 275
4. 7.5 .3 Vi ệc th i ế t lậ p c ác n h à c u n g c ấp và h ợp đ ồn g m ới .................................... 280
4. 7.5 .4 Qu ản lý H ợp đ ồ n g v à Nh à cu n g c ấ p và h i ệu su ấ t ...................................... 281
4. 7.5 .5 Gi a h ạn v à/h o ặc ch ấm d ứt h ợp đ ồ n g ............................................................ 286
4. 7.6 Cá c đ i ều ki ện kí ch h o ạt, đ ầu và o, đ ầ u ra và các tươn g t ác ....................... 287
4. 7.6 .1 Đầu vào ..................................................................................................................... 288
4. 7.6 .2 Đầu r a ........................................................................................................................ 289
4. 7.7 Cá c Ch ỉ s ố Hi ệu s u ất Ch í n h y ếu ( KP I) ................................................................. 290
4. 7.8 Qu ản lý Th ôn g t in ...................................................................................................... 290
4. 7.9 N h ữn g th á ch t h ứ c, các Y ếu t ố Th àn h cô n g Qu an tr ọn g và r ủ i ro ............ 291
5 Cá c h o ạ t độ n g li ên q u an đ ến cô n g n gh ệ t ron g Th i ế t k ế D ị ch vụ ........................... 292
5. 1 Kỹ th u ật y êu c ầu ............................................................................................................ 293
5. 1.1 Cá c ki ểu y ê u c ầu kh á c n h au ................................................................................... 293
5. 1.1 .1 Cá c y êu c ầu ch ứ c n ă n g ........................................................................................ 293
5. 1.1 .2 Cá c y êu c ầu v ề q u ả n lý v à v ận h àn h .............................................................. 294
5. 1.1 .3 Cá c y êu c ầu v ề kh ả n ăn g s ử d ụ n g ................................................................... 295
5. 1.2 Cá c y êu c ầ u đ ối v ới s ự h ỗ tr ợ - q u an đi ể m n gư ời s ử d ụ n g ........................ 295
5. 1.3 Cá c k ỹ t h u ật tì m h i ểu c á c y êu c ầu ...................................................................... 296

7
5. 1.3 .1 Ph ỏn g vấn ................................................................................................................ 296
5. 1.3 .2 Cá c cu ộ c h ội th ảo ................................................................................................. 297
5. 1.3 .3 Qu an sá t ................................................................................................................... 298
5. 1.3 .4 Ph ân t ích g iao th ứ c .............................................................................................. 299
5. 1.3 .5 Đổ b ón g .................................................................................................................... 299
5. 1.3 .6 Ph ân t ích tìn h h u ốn g ........................................................................................... 299
5. 1.3 .7 Tạo n gu y ên m ẫu .................................................................................................... 300
5. 1.3 .8 Cá c k ỹ t h u ật kh á c .................................................................................................. 301
5. 1.4 N h ữn g vấn đ ề v ới k ỹ th u ật y êu c ầu .................................................................... 301
5. 1.4 .1 Gi ải q u y ế t c ác v ấn đ ề v ới k ỹ th u ậ t y êu c ầu ................................................ 303
5. 1.5 Lập tà i li ệu các y êu c ầu ........................................................................................... 304
5. 1.5 .1 Bản mụ c l ụ c cá c y êu c ầu .................................................................................... 306
5. 1.5 .2 Tà i l i ệu v ề y êu cầu đ ầy đ ủ ................................................................................. 308
5. 1.6 Cá c y êu c ầ u và s ự th u ê n goà i ............................................................................... 309
5. 1.6 .1 Cá c tì n h h u ố n g v ề cá c y êu c ầu t h u ê n g oài đi ển h ìn h .............................. 309
5. 2 Qu ản lý d ữ l iệu và th ôn g ti n ...................................................................................... 310
5. 2.1 Qu ản lý tà i s ản d ữ li ệu ............................................................................................ 311
5. 2.2 Ph ạ m vi c ủ a Qu ản lý D ữ li ệu ................................................................................. 311
5. 2.3 Qu ản lý D ữ li ệu và Vò n g đ ời D ịch vụ ................................................................. 313
5. 2.4 Hỗ tr ợ Vòn g đ ời Dị ch vụ ......................................................................................... 313
5. 2.5 Địn h gi á d ữ li ệu ......................................................................................................... 313
5. 2.6 Ph ân lo ạ i d ữ li ệu ....................................................................................................... 314
5. 2.7 Th iế t lậ p c ác ti êu ch u ẩn d ữ l i ệu .......................................................................... 315
5. 2.8 Ch ủ s ở h ữ u d ữ l iệu ................................................................................................... 315
5. 2.9 Ch u y ển đ ổ i d ữ li ệu ................................................................................................... 316
5. 2.1 0 Lưu t r ữ d ữ li ệu ........................................................................................................... 316
5. 2.1 1 N ắm b ắt d ữ li ệu ......................................................................................................... 316
5. 2.1 2 Tru y xu ấ t và s ử d ụ n g d ữ li ệu ................................................................................ 317
5. 2.1 3 Toà n v ẹn d ữ l iệ u và cá c v ấn đ ề l i ên q u an ........................................................ 317
5. 3 Qu ản lý Ứn g d ụ n g .......................................................................................................... 317
5. 3.1 Dan h mụ c Ứn g d ụ n g ................................................................................................. 318
5. 3.2 Vi ệc l iên k ết Ứn g d ụ n g v ới Dan h mụ c Dị ch vụ ................................................ 319
5. 3.3 Cá c kh u ôn kh ổ ứn g d ụ n g ........................................................................................ 319
5. 3.4 N h u cầu đ ố i vớ i các cô n g c ụ và kh o l ư u t rữ C AS E ......................................... 320
5. 3.5 Th iế t k ế các ứn g d ụ n g c ụ th ể ................................................................................ 321
5. 3.6 Qu ản lý sự đán h đ ổi ................................................................................................. 322
5. 3.7 Cá c đ ầu ra th i ết k ế đi ển h ìn h ............................................................................... 323
5. 3.8 Cá c h ìn h m ẫu th i ết k ế ............................................................................................ 323
5. 3.9 Ph át t ri ển cá c ứn g d ụ n g ri ên g l ẻ ......................................................................... 324

8
5. 3.1 0 Cá c q u y ư ớ c lập t rìn h n h ất q u án ......................................................................... 324
5. 3.1 1 Cá c b i ểu m ẫu và v i ệc t ạ o m ã l ập tr ìn h .............................................................. 325
5. 3.1 2 Đo đ ạ c ứn g d ụ n g đ ượ c n h ú n g ............................................................................... 325
5. 3.1 3 Cá c mó c kh ó a ch ẩn đ oá n ........................................................................................ 326
5. 3.1 4 Cá c đ ầu ra d ị ch vụ ch ín h t ừ gia i đ oạ n p h át t ri ển .......................................... 326
6 Vi ệc t ổ ch ức đ ối vớ i Th i ết k ế Dị ch vụ .............................................................................. 327
6. 1 Ph át t ri ển t ổ ch ứ c ......................................................................................................... 328
6. 2 Ph ân t ích h o ạ t độn g ..................................................................................................... 328
6. 3 Cá c k ỹ n ăn g v à th u ộc tí n h ......................................................................................... 329
6. 4 Vai trò và t rác h n h i ệ m ................................................................................................. 329
6. 4.1 Ch ủ s ở h ữ u q u y t rìn h ............................................................................................... 330
6. 4.2 N h à Qu ả n lý T h i ết k ế Dị ch vụ ................................................................................ 330
6. 4.3 N h à h o ạ ch đ ịn h CN T T ............................................................................................... 331
6. 4.4 N h à th i ế t k ế/ Ki ến trú c s ư C N T T ........................................................................... 333
6. 4.5 N h à Qu ả n lý M ụ c lụ c Dị c h vụ ................................................................................ 336
6. 4.6 N h à Qu ả n lý M ức Dị ch v ụ ....................................................................................... 336
6. 4.7 N h à Qu ả n lý T ín h s ẵ n sà n g ..................................................................................... 337
6. 4.8 N h à Qu ả n lý T ín h li ên t ụ c củ a D ị ch vụ CN T T ................................................... 338
6. 4.9 N h à Qu ả n lý C ôn g su ất ............................................................................................ 339
6. 4.1 0 N h à q u ản lý B ảo m ật ................................................................................................ 340
6. 4.1 1 N h à Qu ả n lý N h à cu n g c ấp ..................................................................................... 341
7 Xe m x ét côn g n gh ệ ................................................................................................................. 342
7. 1 Cá c c ôn g c ụ Th i ết k ế Dị c h vụ ......................................................................................... 343
7. 2 Cá c c ôn g c ụ Qu ản lý D ị c h vụ .......................................................................................... 347
8 Tr i ển kh a i Th i ế t k ế Dị ch vụ .................................................................................................. 351
8. 1 Ph ân t ích Tác đ ộn g Kin h d oan h .................................................................................... 352
8. 2 Cá c Y êu c ầu M ứ c D ịc h v ụ ................................................................................................ 353
8. 3 Rủ i ro đ ối vớ i c ác d ịc h vụ và q u y t rìn h ..................................................................... 353
8. 4 Tr i ển kh a i Th i ế t k ế Dị ch vụ ............................................................................................. 353
8. 4.1 Tầ m n h ìn là gì ? ............................................................................................................... 356
8. 4.2 Ch ú n g ta đan g ở đâu ? .................................................................................................. 356
8. 4.3 Ch ú n g ta m u ốn ở đâ u ................................................................................................... 358
8. 4.4 Là m th ế n à o đ ể ch ú n g t a đi đ ế n đó ? ...................................................................... 359
8. 4.5 Là m th ế n à o c h ú n g ta có th ể b i ết kh i ch ú n g ta đ ã đ ến đó ? .......................... 359
8. 4.6 Ch ú n g ta s ẽ ti ếp t ụ c n h ư th ế n à o ? .......................................................................... 359
8. 5 Đo l ườn g Th i ết k ế Dị ch vụ .............................................................................................. 360
8. 5.1 Cá c y ếu t ố ti ên q u y ết đ ể th àn h côn g ..................................................................... 361
8. 5.2 Cá c Y ếu t ố T h àn h côn g Qu an t r ọn g và Ch ỉ số H i ệu su ấ t Ch ín h y ế u ............. 361
9 N h ữn g th á ch t h ứ c, các Y ếu t ố Th àn h cô n g q u an t r ọn g và các r ủ i ro ................... 363

9
9. 1 N h ữn g th á ch t h ứ c .............................................................................................................. 363
9. 2 Cá c Rủ i ro .............................................................................................................................. 365
Lời b ạt ................................................................................................................................................. 366
Ph ụ lụ c A: G ói Th i ết k ế Dị ch vụ ................................................................................................. 368
Ph ụ lụ c B: Ti êu ch í Ch ấp th u ận Dị ch vụ ( ví d ụ ) .................................................................... 372
Ph ụ lụ c C : ( Ví d ụ v ề) C ác b i ểu mẫu tài li ệu q u y t r ìn h ........................................................ 374
C1 Kh u ôn kh ổ q u y t rìn h ................................................................................................................ 374
Ph ụ lụ c D: C ác tài li ệu t h i ế t k ế và h o ạ ch đ ịn h và n ội d u n g c ủ a ch ú n g ........................ 375
D1 Cá c t ài li ệu v à ti êu c h u ẩn th iế t k ế và ki ến t r ú c ............................................................ 376
D2 Cá c k ế h oạ ch CN T T ................................................................................................................... 377
Ph ụ lụ c E Cá c k i ến t rú c và ti êu ch u ẩn m ôi tr ư ờn g .............................................................. 378
Bản g E . 3 Cá c tru n g tâ m d ữ l i ệu q u an tr ọn g .......................................................................... 379
Bản g E . 4 Cá c tru n g tâ m d ữ l i ệu vù n g và cá c tr u n g tâ m th i ết b ị ch ín h y ếu ................ 380
Bản g E . 5 Ph òn g m áy ch ủ và th i ết b ị m ạn g ............................................................................. 381
Bản g E . 6 Môi tr ư ờn g vă n p h òn g ................................................................................................ 382
Ph ụ lụ c F: M ẫ u S LA v à O LA .......................................................................................................... 383
Ph ụ lụ c G : V í d ụ v ề Mụ c lụ c Dị ch vụ ........................................................................................ 390
Ph ụ lụ c H : Kh u ôn kh ổ tr ưởn g th àn h c ủ a q u y tr ìn h Qu ản lý D ị ch vụ ............................. 391
Ph ụ lụ c I : Ví d ụ v ề n ộ i d u n g c ủ a mộ t Tu y ên b ố v ề các Y êu c ầ u ( So R) và/h o ặc Th ư
mờ i th a m g ia Đ ấu t h ầ u ( IT T ) ....................................................................................................... 397
Ph ụ lụ c J : N ộ i d u n g đ i ển h ìn h c ủ a mộ t Kế h oạ ch Côn g su ất ........................................... 398
Ph ụ lụ c K: N ội d u n g đi ể n h ìn h c ủ a m ột k ế h oạc h kh ôi p h ụ c ........................................... 401
Th ôn g t in b ổ su n g ........................................................................................................................... 406
Th a m kh ảo ......................................................................................................................................... 406
Ch ú giả i th u ật n gữ .......................................................................................................................... 407
Dan h sá ch t ừ v i ết t ắ t ................................................................................................................. 407
Dan h sá ch cá c đ ịn h n gh ĩ a ......................................................................................................... 414

10
Lời tựa
Lời tựa của OCG
Kể từ khi được ra m ắt, 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 trong Quản lý
dịch vụ CNTT trên quy m ô toàn cầu. Tuy nhiên, cùng với thành công
này là trách nhi ệm đảm bảo rằng các hướng dẫn giữ được nhịp độ
theo kịp sự thay đổi của m ôi trường kinh doanh toàn c ầu. Các yêu
cầu quản lý dịch vụ, m ột cách chắc chắn, được định hình bởi sự
phát triển của công nghệ, các m ô hình kinh doanh đư ợc sửa đổi và
sự gia tăng trong 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 ra đời để đáp ứng những sự phát triển
đó.
Ấn phẩm này là m ột trong 5 ấn phẩm cốt lõi m ô tả những thực tiễn

trong Quản lý dịch vụ CNTT t ạo nên ITIL. Chúng là k ết quả của m ột
dự án xem xét và c ập nhật các hướng dẫn (ITIL) trong hai năm . S ố
lượng chuyên gia quản lý dịch vụ trên thế giới, những người đã giúp
đỡ để phát triển nội dung c ủa những ấn phẩm này là r ất ấn tượng.
Kinh nghiệm và kiến thức của họ đã đóng góp vào n ội dung đ ể m ang
lại cho bạn m ột bộ tài liệu hướng dẫn chất lượng cao nhất quán.
Đ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 đào t ạo toàn di ện, cùng với các khóa đào t ạo và tư vấn đã
được công nhận.
Cho dù bạn có là m ột thành 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 c ấp cho bạn quyền
tiếp cận với chuyên m ôn quản lý dịch vụ đẳng cấp thế giới. Về cơ
bản, nó (ITIL) đặt Dịch vụ CNTT ở nơi m à chúng thuộc về - trung
tâm của sự thành công trong ho ạt động của doanh nghi ệp.
Peter Fanning
Quyền Giám đốc Điều hành
Văn phòng Thương m ại Chính phủ.

11
Lời tựa của Kiến trúc sư trưởng
Năm 1997, các nhà s ản xuất từ Trung Quốc tham gia thị trường xe
gắn m áy với m ột chiến lược quản lý khác thường. Thay vì chu ẩn bị
các m ô hình và b ản vẽ chi tiết của các hệ thống phụ, quốc gia này
chỉ đơn giản xác định các cấu trúc và tiêu chu ẩn thực tiễn tốt nhất.
Cộng đồng các nhà cung c ấp được tự do đổi m ới và điều chỉnh các
thành phần trong các thiết kế thô và các thông s ố rộng đó. Kết quả
thật đáng kinh ng ạc – ngành công nghi ệp xe gắn m áy của Trung
Quốc giờ đây chiếm m ột nửa sản lượng toàn cầu và được coi là m ột
điểm nóng của sự đổi m ới ( 1 ) .
Những kết quả là r ất nổi bật. Chúng là kết quả từ việc tuân theo
hướng dẫn cấp thấp và thực tế và sản sinh ra m ột ngành công
nghiệp dịch chuyển trong sự phối hợp t ự-tổ chức trong các điều kiện
khác nhau. Thay vì các khuôn kh ổ cứng nhắc ngăn chặn sự thíc h
ứng m ềm dẻo trong các đi ều kiện thay đổi, vẫn còn chỗ cho s ự tự-
tối ưu hóa. Và đây là tri ết lý của ITIL: cấu trúc thực tiễn tốt với chỗ
trống dành cho s ự tự-tối ưu hóa.
Điều thú vị về hành vi nổi bật và tự-tối ưu hóa là nh ững kết qu ả
đáng ngạc nhiên. Khi phiên b ản trước đây c ủa ITIL đề xuất khuôn
khổ quản lý dịch vụ của m ình, đã không có ch ỗ cho sự tồn tại của
Cơ sở dữ liệu Quản lý Cấu hình đã được liên hợp (CMDB), Ki ến trúc
định hướng-Dịch vụ (SOA) hoặc sự hội tụ của các quy trình nghi ệp
vụ, ảo hóa và quản lý dịch vụ. ITIL phản ảnh sự năng động c ủa các
tổ chức, và nhu c ầu của họ trong việc liên tục thích nghi với m ột thế
giới đầy rẫy những điều kiện thay đổi.
Những điều này và các bài h ọc kinh nghiệm quan tr ọng khác đã
được áp dụng để tạo ra khuôn khổ được cải tiến đã mô tả trong
phiên bản này của thư viện (ITIL). Lần đầu tiên, ITIL cũng tìm ki ếm
m ột vài nền tảng cơ bản và các m ối quan hệ kinh doanh gi ữa tất cả
những người tham gia trong các t ổ chức hiện đại sử dụng CNTT. Ấn
phẩm này về Chiến lược Dịch vụ bao hàm phần lớn những nội dung
mới bằng cách xem xét chính xác dịch vụ là gì, làm thế nào m à cả
nhà cung cấp và khách hàng có th ể cùng có lợi khi bên này cung
cấp dịch vụ cho bên kia, và nơi m ỗi bên có l ựa chọn của m ình.
Có lẽ ý tưởng đơn l ẻ mạnh mẽ nhất của ấn phẩm này đem l ại cho ITIL
là khái niệm về cạnh tranh. Mọi nhà cung c ấp đều phải đối mặt với sự
cạnh tranh. Như nhi ều nhà cung c ấp nội bộ đã phát hiện ra một cách
chắc chắn rằng họ sẽ bị kiểm nghiệm bởi thị trường. Chìa khóa cho
các nhà cung c ấp là sự thấu hiểu về cách họ cung cấp giá tr ị như th ế
nào và tạo ra sự khác biệt cho những khách hàng m ục tiêu c ủa họ như
thế nào. Đối với khách hàng, đó là s ự thấu hiểu nơi tốt nhất họ nên tập
trung những nỗ lực của m ình, và nơi mà nhà cung c ấp dịch vụ chia sẻ
hoặc bên ngoài có t h ể làm điều đó tốt hơn. Có r ất nhiều yếu tố để cân
nhắc và một vài ý tư ởng không quen thu ộc có t hể được t r ình bày,
nhưng đây là m ột hành tr ình thú v ị. Hãy đ ể ấn phẩm này hư ớng dẫn
bạn.

12
Sharon Taylor
Kiến trúc sư trưởng, Những thực tiễn Quản lý Dịch vụ ITIL
Lời giới thiệu
‘Chất lượng của một sản phẩm ho ặc dịch vụ không phải là
những gì mà nhà cung c ấp đặt vào nó. Nó là nh ững gì mà khách
hàng có được và sẵn sàng trả tiền cho nó’. Peter Drucker, b ậc
thầy về quản lý người Mỹ.
Những thực tiễn Quản lý Dịch vụ ITIL dựa trên ý tưởng này. Cá c
dịch vụ là những tài sản từ những gì m à khách hàng thu đư ợc giá
trị. Các Dịch vụ được thiết kế càng phù hợp với nhu cầu trong tâm
trí của khách hàng s ẽ dự đoán được giá trị (m à khách hàng) có th ể
thu được từ chúng. Thi ếu Thiết kế Dịch vụ, dịch vụ sẽ phát triển m ột
cách tùy tiện, thường không tận dụng được tầm nhìn rộng hơn –
quan điểm kinh doanh.
Giai đoạn Thiết kế Dịch vụ trong Vòng đời Dịch vụ ITIL nắm lấy các
yêu cầu kinh doanh và, s ử dụng năm khía c ạnh của Thiết kế Dịch
vụ, tạo ra các dịch vụ và những thực tiễn hỗ trợ của chúng đáp ứng
được các nhu c ầu doanh nghi ệp về chất lượng, độ tin cậy và tính
linh hoạt. Thiết kế Dịch vụ được lặp đi lặp lại trong Vòng đời Dịch
vụ, và bắt đầu với m ột kế hoạch chi tiết vững chắc cho phép các giai
đoạn xây dựng, kiểm nghiệm và phát hành c ủa Chuyển tiếp Dịch vụ
thông qua các Gói Thi ết kế Dịch vụ.
Độc giả sẽ được học hỏi về các nguyên t ắc thiết kế cho ứng dụng,
cơ sở hạ tầng, các quy trình và tài nguyên, cũng như là các m ô hình
nguồn cung ứng. Các Nhà quản lý Dịch vụ cũng sẽ tìm thấy hướng
dẫn về kỹ thuật của các yêu c ầu rõ ràng, Qu ản lý Nhà cung c ấp và
các xem xét thi ết kế chính đối với việc thuê ngoài dịch vụ.
Dù cho bạn là nhà cung c ấp dịch vụ nội bộ hay bên ngoài, bạn là
m ột phần của m ột m ạng lưới giá tr ị và đảm trách m ột vai trò quan
trọng trong Vòng đ ời Dịch vụ, bằng cách tích hợp những thực tiễn
tốt nhất về Thiết kế Dịch vụ và Vòng đời Dịch vụ ITIL vào trong
những sản phẩm sáng t ạo cho việc kinh doanh c ủa khách hàng. Ân
phẩm Thiết kế Dịch vụ m ang lại những kiến thức và kỹ năng cần
thiết để tổ hợp sự kết hợp tốt nhất các tài s ản dịch vụ để tạo ra các
dịch vụ có thể đo lường được, có thể m ở rộng được và sáng t ạo,
cùng với con đường dẫn đến dịch vụ xuất sắc.
Bất kỳ nhà cung cấp dịch vụ CNTT nào đư ợc kỳ vọng cung cấp chất
lượng cho việc kinh doanh c ủa khách hàng cần phải có năng l ực để
thiết kế dịch vụ đáp ứng được các mong m uốn, và sau đó ti ếp tục
vượt qua các k ỳ vọng.
Hướng dẫn trong ấn phẩm này sẽ giúp đạt được điều này.

13
14
Thông tin liên hệ
Bạn có thể tìm thấy chi tiết đầy đủ về phạm vi của tài liệu đã được
xuất bản dưới biểu ngữ ITIL tại địa chỉ trằng web www.best-
m anagem ent-practice.com /itil .
Nếu bạn m uốn thông báo cho chúng tôi v ề bất kỳ những thay đổi nào
có thể cần thiết đối với ấn phẩm này, hãy vui lòng ghi l ại chúng tại
địa chỉ trằng web www.best-m anagem ent -practice.com /Changelog .
Để biết thêm thông tin v ề bằng cấp và công nhận đào tạo, vui lòng
truy cập trằng web www.itil-officialsite.com . Ngoài ra, vui lòng liên
hệ:
APMG Service Desk Sword
House Totteridge Road High
W ycom be Buckingham shire
HP13 6DG
Điện thoại: +44 (0) 1494 452 450 Em ail:
servicedesk@apm group.co.uk

15
Lời cảm ơn
Kiến trúc sư trư ởng và tác giả
Sharon Taylor (Aspect Group Inc) Ki ến trúc sư trưởng của Verm on
Llouy (Fox IT) Tác gi ả
Colin Rudd (IT Enterprise Managem en t Services Ltd – ITEMS) Tác

giả
Nhóm thi ết kế ITIL

Nhóm thiết kế ITIL đã đóng góp vào hư ớng dẫn (ITIL) này thông qua
các nhận xét về nội dung và sự liên k ết trên toàn bộ (ấn phẩm ). Vì
vậy, cũng xin c ảm ơn đến các tác giả ITIL khác, đặc biệt là Jeroen
Bronkhorst (HP), David Cannon (HP), Gary Case (Pink Elephant),
Ashley Hanna (HP), Shirley Lacy (ConnectSphere), Vernon Lloyd
(Fox IT), Ivor Macfarlane (Guillem ot Rock), Stuart Rance (HP),
Colin Rudd (ITEMS), George Spalding (Pink Elephant) and David
W heeldon (HP).
Các cố vấn
Tony Jenkins.
Sergio Rubinato Filho
Những đóng góp khác

Một số các chuyên gia đã hào phóng đóng góp th ời gian và ki ến
thức chuyên m ôn c ủa họ cho ấn phẩm Chiến lược Dịch vụ này. Jim
Clinch, với tư cách là Giám đ ốc Dự án OCG, r ất biết ơn sự hỗ trợ
của Accenture cho nhóm tác gi ả trong quá trình phát tri ển ấn phẩm
này, đặc biệt là s ự đóng góp c ủa Jack Bishof, và s ự hỗ trợ của
Ralph Russo (Merrill Lynch), Jenny Dugm ore, Ngư ời triệu tập của
Nhóm Công tác ISO/IEC 20000, Janine Eves, Carol Hulm , Aidan
Lawes và Michiel van der Voort.
Các tác giả cũng xin cảm ơn Tony Jenkins DOMAIN etc và Steve
Rudd IT Enterprise Managem ent Services Lim ited (ITEMS) .
Nhằm phát triển ITIL v3 đ ể phản ảnh thực tiễn tốt nhất hiện tại và
xuất bản ấn phẩm với giá tr ị bền vững, OCG đã tham vấn rộng rãi t ừ
các bên liên quan khác nhau trên toàn th ế giới tại m ỗi giai đoạn
trong quá trình. OCG cũng r ất biết ơ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ọ trong việc làm m ới hướng
dẫn ITIL.
Nhóm tư vấn ITIL

Pippa Bass, OGC; Tony Betts, Independent; Alison Cartlidge, Xansa;
Diane Colbeck, DIYm onde Solutions Inc; Ivor Evans, DIYm onde
Solutions Inc; Karen Ferris, ProActive; Malcolm Fry,

16
FRYConsultants; John Gibert, Independent; Colin Ham ilton,
RENARD Consulting Ltd ; Lex Hendriks, EXIN; Signe-Marie Hernes
Bjerke, Det Norske Veritas; Carol Hulm, British Com puter Society -
ISEB; Tony Jenkins, DOMAINetc; Phil Montanaro, EDS; Alan Nance,
ITPreneurs; Christian Nissen, Itilligence; Don Page, Marval Group;
Bill Powell, IBM; S ergio Rubinato Filho, CA; Jam es Sim inoski,
SOScorp; Robert E. Stroud, CA; Jan van Bon, Inform -IT; Ken
W endle, HP; Paul W ilkinson, Getronics PinkRoccade; Takashi Yagi,
Hitachi.
Người xem xét

Justin Alford, Spirit Consulting; Rajeev Andharia, Sun; Antonio Arevalo, SATEC;
Kamal Kishore Arora, Infosys Technologies; G. Arvinda; Martin Andenmatten,
Independent; Brian Barber, Sierra Systems; Pierre Bernard, Pink Elephant; Jason
Besant; Twane Boettinger, first cdn; Juergen Breithaupt, Infora; Javier Marques
Cabrero, Deloitte; Neil Chadwick; David Colburn, The Creek; Bob Costa, US
Army; Wills Damasio, Quint Wellington Redwood; Catalin Danila,
GlaxoSmithKline, SRL Romania; Juergen Dierlamm, Rechtsanwaitkanzlei
Dierlamm; Peter Doherty, CA; Thomas Dressler, EDV-Beratung; Fouad El Sioufy,
TUV Rheinland Secure iT GmbH; Jaime Eduardo Facioli, Kalendae IT Service
Management; Juergen Feldges, DNV; Prasad Gadgil, Satyam Computer Services
Ltd; Kingshuk Ghosh, HP; Sandeep Gondhalekar, Quint Wellington Redwood;
John Graham, Educad; Juergen Gross, Independent; Ib Guldager, CSC; Tsuyoshi
Hamada, HP; Eero Heikkonen, Efecte; Christoph Herwig, Accenture; Thomas
Hess, Pluralis AG; Maria Hondros, Microsoft; Thomas Jahn; Chris Jones, Ariston
Strategic Consulting; Daniel Keller, Swiss SUIT; Brian Kerr, Axios Systems;
Robert Kuhlig, mITSM; Hendrikje Kuhne, Ktp-organisationsterberatung; Dirk
Koetting, EDV – Konzepte; Madhav Lakshminarayanan; Jane Link, Acerit Limited;
Ernst Guido Leidheuser, Telelogic; Ryan Lloyd, MKS; Eduardo Magalhaes; Paul
Martini, HP; Raimund Martl, HP; Ruth Mason, Kcit; Tan Heng Meng, Starhub;
Rohit Nand, Infosys; Edward Newman; Glen Notman, Pink Elephant; Tuomas
Nurmela, TietoEnator Processing & Network Oy; Benjamin Orazem, SRC.SI; Fadi
Otoun; Gerard Persoon, E.Novation; Neil Pinkerton, Laughingtree; Christian
Probst, Quint Wellington Redwood; Rajwardhan Purohit; Rajesh Radhakrishnan,
IBM; Zahra Rahemtulla, BearingPoint; Arvind Raman, Infosys; Brian Rowlatt,
LogicaCMG; Sutirtha Roy Chowdhury, Sierra Systems; Parmjit Sangha;
Alexander Sapronov, HP; Frances Scarff, OGC; Alan Shepherd, Deutsche Bank
AG; Renato Maia Silva; Moira Stepchuk, Pultorak; Russel Steyn, Foster-Melliar;
Stephen Straker, Fujitsu; Rich Sylva, Microsoft; Jose Tamo, QualiTI7; Brett Tilney;
Michael Tomkinson, BT; Mathias Traugott, Swisscom; Ken Turbitt, BMC Software;
Wiley Vasquez, BMC Software; Brian Verbrugge, RBC; Ettiene Vermeulen,
Datacentrix; Joachim von Caron, Lufthansa Systems; Andreas Weinberger,
DekaBank; Sven Werner, Unilog Avinci GmbH; Ken Williamson, Tyler Stone
Consulting; Ann Winter, EMC; Theresa Wright, Computacenter Services; Geoffrey
Wyeth, Independent; Rob Young, Fox IT; Michael Zimmermann, NETCONS

17
1 Giới thiệu
Mục tiêu chủ yếu của Thiết kế Dịch vụ là đảm bảo rằng các d ịch vụ
CNTT được liên kết với các nhu c ầu kinh doanh và h ỗ trợ m ột cách
chủ động cho các nhu c ầu này. Một điều bắt buộc là các d ịch vụ
CNTT phải là nền tảng cho các quy trình nghi ệp vụ, nhưng vi ệc
CNTT đóng vai trò như là m ột tác nhân quan tr ọng đối với sự thay
đổi để tạo điều kiện chuyển đổi kinh doanh cũng ngày càng quan
trọng.
Mọi tổ chức sử dụng CNTT sẽ phụ thuộc vào CNTT để có thể thành
công. Nếu các quy trình và d ịch vụ CNTT được triển khai, quản lý và
hỗ trợ theo cách tương xứng, doanh nghi ệp sẽ càng thành công
hơn, ít bị gián đoạn và m ất giờ làm việc, giảm chi phí, tăng doanh
thu, cải thiện quan hệ công chúng và đ ạt được các m ục tiêu kinh
doanh của tổ chức.
Phần lớn các cơ quan ch ức năng hiện đang xác định bốn loại tài sản
CNTT cần phải có và cần được quản lý để góp phần vào việc cung
cấp hiệu quả dịch vụ CNTT. Chúng là cơ sở hạ tầng CNTT, các ứng
dụng, thông tin và con người. Đặc biệt có m ột sự nhấn mạnh m ạnh
m ẽ vào sự đạt được, q uản lý và tích hợp những tài sản đó trong
toàn bộ vòng đời ‘từ khi sinh ra đến khi nghỉ hưu’ của chúng. Việc
cung cấp các dịch vụ CNTT chất lượng phụ thuộc vào việc quản lý
hiệu quả và có hiệu lực những tài sản này.
Tuy nhiên, bản thân những tài sản này kh ông đủ để đáp ứng các nhu
cầu Quản lý Dịch vụ của doanh nghiệp. Những thực tiễn Quản lý
Dịch vụ ITIL sử dụng bốn loại tài sản này như là m ột phần của m ột
bộ các năng lực và tài nguyên được gọi là ‘tài sản dịch vụ’.
Hình 1.1 - Nguồn cung cấp cho thực tiễn quản lý dịch vụ
Một dịch vụ CNTT, được sử dụng trong việc hỗ trợ các quy trình
nghiệp vụ, được xây dựng từ sự kết hợp của các tài sản CNTT và
các dịch vụ ‘nền tảng’ được cung cấp bên ngoài. Khi đã có sẵn, m ột
dịch vụ CNTT phải được hỗ trợ trong suốt 'vòng đời' của nó, trong
thời gian đó, dịch vụ đó có thể được điều chỉnh nhiều lần, dù cho là
thông qua đổi m ới công nghệ, thay đổi m ôi trường kinh doanh, thay
đổi cách sử dụng dịch vụ, thay đổi các thông số chất lượng dịch vụ
hoặc thay đổi các tài sản hoặc năn g lực CNTT hỗ trợ cho nó (ví dụ:
thay đổi trong thành phần phần m ềm ứng dụng để cung cấp chức
năng bổ sung). Cuối cùng, dịch vụ CNTT được cho ngừng hoạt

18
động, khi các quy trình nghiệp vụ không còn được sử dụng cho nó
hoặc không còn hiệu quả -về-chi phí để hoạt động. Chuyển tiếp Dịch
vụ liên quan đến việc xây dựng và triển khai dịch vụ và hỗ trợ hàng
ngày, và cung cấp dịch vụ là vai trò của Vận hành Dịch vụ, trong khi
Liên tục Cải tiến Dịch vụ triển khai thực tiễn tốt nhất trong giai đoạn
tối ưu hóa và ngừng hoạt động.
Từ góc độ này, Thiết kế Dịch vụ có thể được coi là sự thu thập các
nhu cầu dịch vụ và ánh xạ chúng tới các yêu cầu đối với các dịch vụ
được tích hợp và tạo ra các đặc tả thiết kế cho các tài sản dịch vụ
cần thiết để cung cấp dịch vụ. Một điểm đặc biệt của phương pháp
tiếp cận này là nhấn m ạnh vào việc tái sử dụng trong quá trình thiết
kế.
Mục đích chính của Thiết kế dịch vụ là thiết kế các dịch vụ CNTT,
cùng với các thông lệ, quy trình và chính sách quản trị CNTT, để
hiện thực hóa chiến lược v à tạo điều kiện đưa các dịch vụ này vào
m ôi trường thật để đảm bảo cung cấp dịch vụ có chất lượng, sự hài
lòng của khách hàng và hiệu quả về chi phí cung cấp dịch vụ. Thiết
kế Dịch vụ cũng nên thiết kế các dịch vụ CNTT m ột cách hiệu quả để
chúng không cần cải tiến nhiều trong vòng đời của chúng. Tuy
nhiên, cải tiến liên tục nên được nhúng vào tất cả các hoạt động
Thiết kế Dịch vụ để đảm bảo rằng các giải pháp và thiết kế trở nên
hiệu quả hơn theo thời gian và xác định các xu hướng thay đổi trong
kinh doanh có thể m ang lại cơ hội cải tiến. Các hoạt động Thiết kế
dịch vụ có thể định kỳ hoặc dựa trên -ngoại lệ khi chúng có thể được
kích hoạt bởi m ột nhu cầu hoặc sự kiện kinh doanh cụ thể.
Nếu các dịch vụ hoặc quy trình không được thiết kế, chúng sẽ phát
triển m ột cách hữu cơ. Nếu chúng phát triển m à không có các biện
pháp kiểm soát phù hợp, chúng có khuynh hướng chỉ đơn giản là
phản ứng với các điều kiện m ôi trường đã xảy ra hơn là thấu hiểu
m ột cách rõ ràng tầm nhìn và nhu cầu tổng thể của doanh nghiệp.
Việc thiết kế để phù hợp với m ôi trường được dự kiến sẽ hiệu quả
và có hiệu lực hơn nhiều, nhưng thường là không thể - do đó cần
phải xem xét các phương pháp tiếp cận lặp đi lặp lại và gia tăng đối
với Thiết kế Dịch vụ. Các phương pháp tiếp cận lặp đi lặp lại v à gia
tăng là điều cần thiết để đảm bảo rằng các dịch vụ được đưa vào
m ôi trường thật sẽ thích ứng và tiếp tục phù hợp với nhu cầu kinh
doanh vẫn đang phát triển. Trong trường hợp không có Thiết kế Dịc h
vụ được chính thức hóa, các dịch vụ thường sẽ quá m ức đắt đỏ để
hoạt động, dễ bị hỏng hóc, tài nguyên sẽ bị lãng phí và các dịch vụ
sẽ không hoàn toàn được liên kết với nhu cầu kinh doanh. Không
thể chắc chắn rằng bất kỳ chương trình cải tiến nào sẽ có thể đạt
được những gì m à thiết kế đúng đắn sẽ đạt được n gay từ đầu.
Không có Thiết kế Dịch vụ, hiệu quả về chi phí dịch vụ là điều bất
khả thi. Các khía cạnh con người của Thiết kế Dịch vụ cũng là điều
quan trọng hàng đầu, và những khía cạnh này sẽ được khám phá chi
tiết trong phần sau của ấn phẩm này.

19
1.1 Tổng quan
Ấn phẩm này định hình m ột phần của những thực tiễn Quản lý Dịch
vụ ITIL và bao gồm thiết kế các dịch vụ CNTT thích hợp và sáng tạo
để đáp ứng các yêu cầu kinh doanh đã được thỏa thuận trong hiện
tại và tương lai. Ân phẩm này m ô tả các nguyên tắc Thiết kế Dịch vụ
và xem xét việc xác định, định nghĩa và liên kết giải pháp CNTT với
các yêu cầu kinh doanh. Nó cũng giới thiệu ý tưởng về Gói Thiết kế
Dịch vụ và xem xét sự lựa chọn m ô hình Thiết kế Dịch vụ phù hợp.
Đồng thời, ấn phẩm này cũng thảo luận về nền tảng cơ bản của các
quy trình thiết kế và năm khía cạnh của thiết kế:
 Các Dịch vụ;
 Thiết kế các hệ thống và công cụ Quản lý Dịch vụ, đặc biệt là
Danh m ục Dịch vụ;
 Các kiến trúc công nghệ và hệ thống quản lý;
 Các quy trình;
 Các phương pháp và chỉ số đo lườn g.
Ấn phẩm này bao gồm các phương pháp, thực tiễn và công cụ để
đạt được sự hoàn hảo trong Thiết kế Dịch vụ. Nó bắt buộc thi hành
nguyên tắc rằng khởi đầu Thiết kế Dịch vụ nên được định hướng bởi
m ột số các yếu tố, bao gồm các yêu cầu về chức năng, các yêu cầu
trong các Thỏa thuận Mức Dịch vụ (SLAs), những lợi ích của doanh
nghiệp và các ràng buộc thiết kế tổng thể.
Chương 4 giải thích các quy trình từ -đầu-đến-cuối của những lĩnh
vực chủ yếu để Thiết kế Dịch vụ thành công. Những quy trình này
được sử dụng ở mọi giai đoạn của Vòng đời Dịch vụ. Tuy nhiên, ở
đây thì Quản lý Mục lục Dịch vụ, Quản lý Mức Dịch vụ, Quản lý Công
suất, Quản lý Tính sẵn sàng, Quản lý Liên tục Dịch vụ CNTT, Quản
lý Bảo m ật Thông tin và Quản lý Nhà cung cấp được đề cập chi tiết.
Những phụ lục trong ấn phẩm này cung cấp những ví dụ về Gói
Thiết kế Dịch vụ, Tiêu chí Chấp thuận Dịch vụ, các biểu mẫu tài liệu
quy trình, các tài liệu thiết kế và hoạch định, các kiến trúc và tiêu
chuẩn m ôi trường, các m ẫu SLAs, OLA và Mục lục Dịch vụ và khuôn
khổ trưởng thành của quy trình Quản lý Dịch vụ.
1.2 Bối cảnh

1.2.1 Quản lý Dịch vụ
Công nghệ thông tin (CNTT) là m ột khái niệm đượ sử dụng m ột cách
phổ biến với các ý nghĩa thay đổi 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 là các tổ hợp con của m ột sản phẩm lớn hơn.
Chúng cho phép hoặc được nhúng vào trong các quy trình và các
dịch vụ. Trong quan điểm thứ hai, CNTT là m ột tổ chức với bộ năng
lực và tài nguyên của nó. Các tổ chức CNTT có thể có n hiều loại
khác nhau như các chức năng kinh doanh, các đơn vị chia sẻ dịch
vụ và các đơn vị cốt lõi cấp -doanh nghiệp.
Từ quan điểm thứ ba, CNTT là m ột thẩ loại các dịch vụ được s ử
dụng bởi doanh nghiệp. Các dịch vụ này thông thường là những ứng
dụng CNTT và cơ sở hạ tầng được đóng gói và cung cấp như là các

20
dịch vụ bởi các tổ chức CNTT nội bộ hoặc nhà cung cấp dịch vụ bên
ngoài. Chi phí cho CNTT được tính như là chi phí của doanh nghiệp.
Trong quan điểm thứ tư, CNTT lại là một thể loại tài sản của doanh
nghiệp có thể cung cấp m ột dòng lợi ích cho chủ sở hữu của chúng,
bao gồm nhưng không giới hạn doanh thu, thu nhập và lợi nhuận.
Chi phí cho CNTT được tính là chi phí đầu tư.
1.2.2 Thực tiễn tốt trong khu vực công

Các tổ chức vận hành trong các m ôi trường năng độn g với nhu cầu
học hỏi và thích nghi. Cần phải cải thiện hiệu suất trong khi quản trị
sự đánh đổi. Dưới áp lực tương tự, các khách hàng tìm kiếm lợi thế
từ các nhà cung cấp dịch vụ. Họ (khách hàng) theo đuổi chiến lược
tìm kiếm nguồn cung ứng phục vụ tốt nh ất cho lợi ích kinh doanh
của họ. Ở nhiều nước, các cơ quan chính phủ và các tổ chức phi lợi
nhuận có xu hướng tương tự nhau khi thuê ngoài vì lợi ích của hiệu
suất hoạt động. Điều này gây thêm áp lực cho các nhà cung cấp
dịch vụ trong việc duy trì lợi thế cạnh tranh liên quan tới các lựa
chọn thay thế khác m à khách hàng có thể có. Sự gia tăng của việc
thuê ngoài đã phơi bày các nhà cung cấp dịch vụ nội bộ đặc biệt là
đối với các cạnh tranh bất thường.
Để đối phó với áp lực, các tổ chức tự chuẩn m ực hóa m ì nh so với
các tổ chức khác tương tự và tìm cách thu hẹp khoảng cách về năng
lực. Một cách để thu hẹp khoảng cách đó là áp dụng các thực tiễn
tốt sử dụng rộng rãi trong ngành. Có một vài nguồn của thực tiễn tốt
bao gồm các khuôn khổ công khai, các tiêu chuẩ n và kiến thức độc
quyền của các tổ chức và các cá nhân.
Hình 1.2 – Thực tiễn Nguồn cung Quản l ý Dịch vụ
Các khuôn khổ và tiêu chuẩn công khai thực sự rất hấp dẫn khi
được so sánh với kiến thức độc quyền:
 Kiến thức độc quyền được nhúng sâu vào trong T ổ chức, và
do đó, khó được chấp nhận, nhân rộng hoặc chuyển giao
ngay cả với sự hợp tác của chủ sở hữu. Kiến thức như vậy

21
thường ở dạng kiến thức ngầm , vốn rắc rối 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 để phù hợp v ới bối
cảnh và nhu cầu kinh doanh của doanh nghiệp đến m ức trở
thành phong cách riêng. Trừ khi những người nhận kiến
thức đó có bối cảnh phù hợp, kiến thức đó có thể không
hiệu quả trong việc sử dụng nó.
 Chủ sở hữu các kiến thức độc quyền kỳ vọng rằng họ s ẽ
được tưởng thưởng cho khoản đầu tư dài hạn của họ. Họ
chỉ có thể cung cấp kiến thức như vậy theo các điều khoản
thương m ại thông qua các thỏa thuận m ua bán và cấp
phép.
 Các Tiêu chuẩn và Khuôn khổ công khai như ITIL, COBIT,
CMMI, eSCM-SP, PRINCE2, ISO 90 00, ISO/IEC 20000 và
ISO/IEC 27001 được xác thực thông qua m ột loạt các m ôi
trường và tình huống khác nhau thay vì trải nghiệm bị hạn
chế trong m ột tổ chức đơn lẻ. Chúng tùy thuộc vào việc
xem xét rộng rãi bởi nhiều tổ chức và ngành nghề khác
nhau. Chúng đ ược hiệu đính bởi tập hợp nhiều đối tác, nhà
cung cấp và đối thủ cạnh tranh đa dạng.
 Kiến thức từ các khuôn khổ công khai có nhiều khả năng
được triển khai m ột cách rộng rãi trong m ột cộng đồng lớn
các chuyên gia thông qua việc đào tạo và sự chứng nhận
công khai. Điều này giúp cho các tổ chức dễ dàng hơn
trong việc có được kiến thức thông qua thị trường lao động.
1.2.3 ITIL và 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à việc khuôn khổ ITIL được xem như là
m ột nguồn 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 cầu để thiết lập và cải thiện năng lực
trong Quản lý Dịch vụ. ISO/IEC 20000 cung cấp m ột tiêu chuẩn
chính thức và phổ quát cho các tổ chức đang tìm cách để năng lực
Quản lý Dịch vụ của m ình được kiểm tra và chứng thực. Trong khi
ISO/IEC là m ột tiêu chuẩn cần phải đạt và duy trì thì ITIL lại cung
cấp m ột khối kiến thức hữu ích để có thể đạt được tiêu chuẩn.
Thư viện ITIL bao gồm các thành phần như sau:
 Cốt lõi ITIL: hướng dẫn thực tiễn tốt nhất c ó thể áp dụng
cho m ọi kiểu tổ chức đang cung cấp dịch vụ cho m ột doanh
nghiệp.
 Hướng dẫn Bổ sung ITIL: m ột bộ các ấn phẩm bổ sung với
hướng dẫn cụ thể cho các ngành nghề, các kiểu tổ chức,
các m ô hình vận hành, và các kiến trúc công nghệ khác
nhau.
Cốt lõi ITIL bao gồm 5 ấn phẩm như hình dưới đây (Hình 1.3). Mỗi
ấn phẩm cung cấp sự 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ư yêu cầu trong m ô tả của Tiêu chuẩn
ISO/IEC 2000:
 Chiến lược Dịch vụ
 Thiết kế Dịch vụ

22
 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.3 - Cốt lõi ITIL
Mỗi ấn phẩm xác định những năng lực có thể ảnh hưở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 ITIL
chính là khuôn dạng Vòng đời. Nó 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 khả năng, năng lực
trong m ột lĩnh vực nào đó để học hỏi và cải thiện các lĩnh vực khác.
Cốt lõi được kỳ vọng sẽ cung cấp cấu trúc, sự ổn định và sức m ạnh
cho những 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 đảm bảo các khoản đầu tư được
bảo vệ, và cung cấp cơ sở cần thiết để do lường, học hỏi và cải
thiện.
Hướng dẫn trong ITIL có thể được điều chỉnh để sử dụng cho nhiều
m ôi trường kinh doanh và chiến lược tổ ch ức khác nhau. Các Hướng
dẫn Bổ sung cung cấp sự linh hoạt trong việc triển khai Cốt lõi trong
m ột loạt các m ôi trường khác nhau. Học viên có thể chọn Hướng
dẫn Bổ sung khi cần thiết để cung cấp sức kéo đối với bối cảnh nhất
định của Doanh nghiệp, giống như các 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 xá. Điều này là nhằm
làm gia tăng tính bền bỉ và linh động của tài sản tri thức và bảo vệ
các khoản đầu tư vào năng lực Quản lý Dịch vụ.

23
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ề cách thức thiết
kế, phát triển và tri ển khai Quản lý Dịch vụ như thế nào, không ch ỉ
như là năng l ực mà còn là tài s ản chiến lược của tổ chức. Hướng
dẫn được cung cấp dựa trên các nguyên t ắc củng cố thực tiễn về
quản lý dịch vụ hữu ích cho vi ệc phát tri ển các chính sách, hư ớng
dẫn, quy trình qu ản lý dịch vụ trong suốt Vòng đời của Dịch vụ ITIL.
Hướng dẫn Chiến lược Dịch vụ rất hữu ích theo ngữ 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ủ đề trong ấn phẩm Chiến lược Dịch vụ bao gồm
phát triển 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à việc triển khai chiến lược trong suốt Vòng đời Dịch
vụ. Quản trị Tài chính, Qu ản lý Danh m ục Dịch vụ, Phát triển Tổ
chức, và Rủi ro chiến lược nằm trong những chủ đề chính khác.
Các tổ chức sử dụng hướng dẫn để thiết lập các m ục tiêu và các k ỳ
vọng về hiệu suất hướng tới phục vụ khách hàng và không gian th ị
trường, đồng thời xác định, lựa chọn và ưu tiên hóa các cơ hội.
Chiến lược Dịch vụ là nhằm đảm bảo rằng các tổ chức đang ở vị th ế
quản lý được các chi phí và r ủi ro tương ứng với các Danh m ục Dịch
vụ của họ, đồng thời được thiết lập để không chỉ hiệu quả trong vận
hành m à còn m ang l ại hiệu suất đặc biệt. Những quyết định được
đưa ra liên quan t ới Chiến lược Dịch vụ luôn có hi ệu quả toàn diện,
kể cả những quyết định có hiệu lực chậm trễ.
Các tổ chức đang thực hành ITIL cũng có th ể sử dụng ấn phẩm này
để hướng dẫn việc đá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 họ, đồng thời cải thiện liên kết giữa
những năng lực đó với các chiến lược kinh doanh của m ình. T ập này
khuyến khích người đọc dừng lại và suy nghĩ về lý do t ại sao phả i
làm gì đó trư ớc khi suy nghĩ v ề cách thức làm điều đó như thế nào.
Những câu tr ả lời cho loại câu hỏi đầu tiên thư ờng gần gũi 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 ra khỏi đối tượng truyền thống của các
chuyên gia 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 cho việc thiết kế và
phát triển các dịch vụ cũng như các quy trình quản lý các dịch vụ
đó. Nó bao hàm các nguyên tắc thiết kế và phương pháp để chuyển
đổi từ các m ục tiêu chiến lược thành các danh m ục dịch vụ và các
danh m ục các 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ả các thay đổi và
những cải tiến cần thiết để gia tăng hoặc duy trì giá trị cung cấp cho
khách hàng trong suốt vòng đời của dịch vụ, tính liên tục c ủa dịc h
vụ, thành tựu của các m ức dịch vụ, cũng như sự phù hợp với các
tiêu chuẩn và luật lệ. Nó hướng dẫn cho các tổ chức về cách thức
làm thế nào để phát triển thiết kế các năng lực quản lý dịch vụ.

24
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 năng lực Chuyển tiếp Dịch vụ, kể cả dịch vụ m ới
hoặc dịch vụ đã được thay đổi sang giai đoạn vận hành. Ấn phẩm
này cũng cung cấp hướng dẫn cách thức làm thế nào để các yêu cầu
trong Chiến lược Dịch vụ vốn đượ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ụ trong
khi vẫn kiểm soát các rủi ro về lỗi hoặc gián đoạn dịch vụ. Nó (ấn
phẩm này) bao gồm những thực tiễn trong Quản lý Phát hành (phiên
bản), Quản lý Chương trình, Q uản lý rủi ro và đặt chúng vào bối
cảnh thực tế của quản lý dịch vụ. Nó cung cấp hướng dẫn về quản lý
các yếu tố phức tạp liên quan đến những thay đổi đối với dịch vụ
cũng như trong các quy trình quản lý dịch vụ, ngăn ngừa những hậu
quả không m ong muốn tro ng khi vẫn chấp nhận sự đổi m ới. Hướng
dẫn cũng được cung cấp trong việc chuyển giao sự kiểm soát 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 các thực tiễn trong quá trình quản lý sự vận
hành của dịch vụ. Nó bao gồ m các hướng dẫn cho việc đạt được
hiệu quả và hiệu suất trong quá trình phân phối và hỗ trợ dịch vụ, và
từ đó, đảm bảo các giá trị cho cả khách hàng lẫn nhà cung cấp dịch
vụ. Các m ục tiêu chiến lược rốt cuộc được thực hiện thông qua quá
trình vận hành dịch vụ, do đó làm cho nó trờ thành m ột năng lực
quan trọng. Hướng dẫn được cung cấp theo cách thức nhằm duy trì
sự ổn định trong vận hành dịch vụ, chấp nhận sự thay đổi trong thiết
kế, m ở rộng, phạm vi và các cấp độ dịch vụ. Các tổ chức được cung
cấp các hướn g dẫn, phương pháp và công cụ cho các quy trình chi
tiết, để sử dụng trong hai luận điểm kiểm soát chính là chủ động và
đối phó. Các nhà quản lý và học viên được cung cấp những kiến
thức cho phép họ đưa ra những 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 việc sử dụng năng lực, lập kế hoạch vận hành và sửa lỗi.
Hướng dẫn cũng được cung cấp trong việc hỗ trợ sự vận hành thông
qua các m ô hình và kiến trúc m ới chẳng hạn như chia sẻ dịch vụ,
điện toán tính tiện dụng, 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 này cung cấp hướng dẫn cụ thể trong việc tạo ra và duy trì
giá trị cho khách hàng thông qua thiết kế tốt hơn, giới thiệu và vận
hành dịch vụ tốt hơn. Nó kết hợp các ngu yên tắc, thực tiễn, và
phương pháp trong việc quản lý chất lượng, quản lý thay đổi và cải
tiến năng lực. Các tổ chức học cách thực hiện những cải tiến gia
tăng và cải tiến quy m ô lớn về chất lượng dịch vụ, vận hành hiệu
quả, và tính liên tục trong kinh doa nh. Hướng dẫn được cung cấp để
kết nối các nỗ lực cải tiến và các kết quả với Chiến lược Dịch vụ,
thiết kế và vận hành dịch vụ. Một hệ thống phản hồi khép kín dự a
trên m ô hình PDCA - Plan/Lên kế hoạch - Do/Thực thi - Check/Kiểm
tra - Act/Hành động đã được chỉ rõ trong Tiêu chuẩn ISO/IEC 20000,
được thiết lập và có khả năng tiếp nhận đầu vào để thay đổi từ bất
kỳ quan điểm hoạch định nào.

25
1.3 Mục đích
Mục đích của ấn phẩm này là để m ang lại cho độc giả sự hướng dẫn
về việc sử dụng các thực tiễn được khuyến nghị khi thiết kế các dịch
vụ CNTT và quy trình Quản lý Dịch vụ CNTT.
Đây là tập tiếp theo của ấn phẩm Chiến lược Dịch vụ, vốn cung cấp
hướng dẫn về sự liên kết và tích hợp những nhu cầu kinh doanh với
CNTT. Nó cho phép độc giả đánh giá về các yêu cầu khi thiế t kế m ột
dịch vụ, và tài liệu hóa thực tiễn tốt nhất trong ngành cho việc thiết
kế các dịch vụ và quy trình CNTT.
Mặc dù ấn phẩm này có thể được đọc m ột cách riêng biệt, tuy nhiên,
chúng tôi khuyến cáo rằng nó nên được sử dụng kết hợp với các ấn
phẩm ITIL khác. Hướng dẫn trong các ấn phẩm ITIL có thể được áp
dụng m ột cách tổng quát. Nó không quan liêu cũng không khó sử
dụng nếu được sử dụng m ột cách hợp lý và nhận thức đầy đủ về các
nhu cầu kinh doanh của tổ chức. Thiết kế Dịch vụ đóng vai trò quan
trọng tr ong việc tạo tiền đề cho việc cung cấp các dịch vụ m ột cách
hiệu quả cho doanh nghiệp và đáp ứng được nhu cầu về sự tăng
trưởng và thay đổi. Sự tăng cường thường sẽ tốn chi phí và tài
nguyên hơn là phát triển. Do đó, những cân nhắc đáng kể nên được
đưa ra đối với việc thiết kế để hỗ trợ dễ dàng và tiết kiệm trong toàn
bộ vòng đời, nhưng điều quan trọng hơn là sẽ không thể tái thiết kế
hoàn toàn m ột dịch vụ đang hoạt động. Có thể tiến tới gần, nhưng
sẽ không thể quay lại m ột thiết kế khi m à m ột thứ gì đó đ ang chạy.
Việc trang bị thêm thiết kế là khó khăn và tốn kém và không bao giờ
đạt được những gì có thể có thể đã đạt được nếu được thiết kế.
1.4 Sử dụng
Ấn phẩm này liên quan tới bất kỳ ai đã tham gia vào quá trình thiết
kế, cung cấp hoặc hỗ trợ các dịch v ụ CNTT. Nó sẽ liên quan tới Kiến
trúc CNTT, các nhà quản lý và thực hành CNTT ở m ọi cấp độ. Mọi
ấn phẩm trong bộ Thư viện Cốt lõi Quản lý Dịch vụ CNTT cần được
đọc để đánh giá và thấu hiểu đầy đủ về vòng đời tổng thể của các
dịch vụ và về Quản lý Dịch vụ C NTT.
Có nhiều cách để cung cấp m ột dịch vụ CNTT, chẳng hạn như có

sẵn trong nội bộ, được thuê ngoài và cộng tác. Ấn phẩm này liên
quan m ột cách tổng quát tới m ọi phương pháp cung cấp dịch vụ. Vì
thế, nhũng ai liên quan đến việc cung cấp các dịch vụ CNTT – bên
trong tổ chức của họ, trong cung cấp dịch vụ được thuê ngoài hoặc
làm việc trong quan hệ đối tác – sẽ nhận thấy rằng ấn phẩm này có
thể hữu dụng với họ. Các nhà quản lý doanh nghiệp có lẽ sẽ nhận ra
rằng ấn phẩm này rất hữu ích trong việc tìm hiểu và t hiết lập thực
tiễn tốt nhất cho dịch vụ và hỗ trợ CNTT. Các nhà quản lý từ các tổ
chức cung cấp cũng sẽ tìm thấy sự liên quan với ấn phẩm này khi
thiết lập các thỏa thuận trong việc cung cấp và hỗ trợ các dịch vụ.

26
2 Quản lý dịch vụ như một thực tiễn
2.1 Quản lý dịch vụ là gì?
Quản lý dịch vụ là m ột tập hợp những năng lực được chuyên m ôn
hoá của tổ chức để đem lại giá trị cho các khách hàng thông qua
hình thức dịch vụ. Những năng lực được định hình dưới dạng chức
năng và quy trình để quản lý dịch vụ trong suốt v òng đời của chúng,
cùng với những chiến lược, thiết kế, chuyển tiếp, vận hành và liên
tục cải tiến m ang tính chuyên m ôn hóa cao. Những năng lực này đại
diện cho khả năng, kiến thức, và sự tự tin trong hành động của m ột
tổ chức dịch vụ. Hành động chuyển đổi từ tài nguyên thành những
dịch vụ có giá trị chính là cốt lõi của Quản lý Dịch vụ. Không có
những năng lực này, m ột tổ chức dịch vụ đơn thuần chỉ là m ột nhóm
các tài nguyên m à bản thân chúng có giá trị nội tại tương đối thấp
với khách hàng.
Quản lý Dịch vụ là m ột tập hợp các năng lực của tổ chức có tính
chuyên m ôn hóa để cung cấp giá trị cho khách hàng dưới hình
thức các dịch vụ.
Các năng lực của tổ chức được định hình bởi những thách thức m à
chúng được kỳ vọng là sẽ vượt qua. Năng lực Quản lý Dịch vụ bị
ảnh hưởng bởi những thách thức được liệt kê dưới đây giúp phân
biệt dịch vụ với các hệ thống tạo ra giá trị khác như sản xuất, khai
khoáng, nông nghiệp:
 Bản chất vô hình của đầu ra và sản phẩm trung gian của
các quy trình dịch vụ: khó đo lường, khó kiểm soát và
xác nhận (hoặc chứng m inh).
 Nhu cầu được kết hợp chặt chẽ với tài sản của khách
hàng: người sử dụng và các tài sản của khách hàng nh ư
các quy trình, các ứng dụng, tài liệu và các giao dịch
xảy ra đồng thời với nhu cầu và kích thích (sự) sản xuất
(của) dịch vụ.
 Liên hệ ở m ức độ cao giữa người cung cấp và người sử
dụng dịch vụ: ít hoặc không có khoảng đệm giữa khách
hàng, tiền tuyến và h ậu phương.
 Bản chất dễ hư hỏng của đầu ra và năng lực của dịc h
vụ: m ột giá trị m ang lại cho khách hàng chính là sự đảm
bảo rằng dịch vụ sẽ được cung cấp liên tục với chất
lượng phù hợp. Các nhà cung cấp cần phải đảm bảo sự
ổn định trong việc cung cấp và đ áp ứng các yêu cầu từ
khách hàng.
Tuy nhiên, Quản lý Dịch vụ còn hơn là m ột bộ các năng lực. Nó còn
là m ột thực tiễn chuyên nghiệp được hỗ trợ bởi m ột khối kiến thức,
kinh nghiệm và kỹ năng toàn diện. Một cộng đồng bao gồm các cá
nhân và tổ chức trên toà n cầu trong lĩnh vực công và tư nhân đang
thúc đẩy sự phát triển và trưởng thành của nó. Các đề án chính thức
hiện diện đối với giáo dục, đào tạo và chứng nhận các tổ chức và

27
các cá nhân hành nghề cũng 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 đóng góp vào vốn tri thức của nó và được rút
ra từ nó.
Khởi thủy của quản lý dịch vụ chính là 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ác công ty điện thoại. Thực tiễn quản lý dịch vụ không ngừng phát
triển với sự chấp thuận từ các tổ chức CNTT về phương pháp tiếp
cận định hướng-dịch vụ để quản lý các ứng dụng, hạ tầng, quy trình
CNTT. Các giải pháp đề ra cho những vấn đề của doanh nghiệp và
hỗ trợ các m ô hình kinh doanh, chiến lược và vận hành của doanh
nghiệp ngày càng gia tăng theo hình thái dịch vụ. Sự phổ biến của
các dịch vụ chia sẻ và thuê ngoài đã đóng góp cho sự tăng trưởng
số lượng các tổ chức cung cấp dịch vụ, bao gồm cả các đơn vị nội
bộ trong tổ chức. Điều này, đến lượt nó, đã tăng cường thực tiễn
Quản lý Dịch vụ hơn đồng thời đặt ra thêm những thách thức m ới
lớn hơn đối với quản lý dịch vụ.
2.2 Các dịch vụ là gì?

2.2.1 Đề xuất giá trị
Một dịch vụ là m ột phương tiện cung cấp giá trị cho khách hàng
bằng cách tạo điều kiện cho các kết quả khách hàng m uốn đạt
được m à không cần phải sở hữu chi phí và rủi ro cụ thể.
Các dịch vụ là các phương tiện m ang lại giá trị ch o khách hàng bằng
cách tạo điều kiện cho những kết quả m à khách hàng m uốn đạt
được m à không cần sở hữu chi phí và những rủi ro cụ thể. Các dịch
vụ tạo điều kiện cho kết quả bằng cách tăng cường hiệu suất của
những tài sản thích ứng và giảm tác động của các ràng buộc. Kết
quả là m ột sự gia tăng trong xác suất xảy ra của các kết quả m ong
m uốn.
Qua nhiều năm , các tổ chức không ngừng tranh luận về định nghĩa
của ‘dịch vụ’. Minh họa trong Hình 2.1 là m ột ví dụ về thực tế rằng
dịch vụ thực sự là sự cung cấp giá trị cho các khách hàng.

28
Hình 2.1 Cuộc thảo luận về định nghĩa và ý nghĩa của dịch
vụ.
2.3 Các Chức năng và quy trình trong su ốt 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 để
hoàn thành những kiểu công việc nhất địn h và chịu trách nhiệm cho
các kết quả cụ thể. Chúng tự chủ, cùng với các năng lực và tài
nguyên cần thiết cho hiệu suất và kết quả của chúng. Các năng lực
bao gồm các phương pháp làm việc bên trong các chức năng. Các
chức năng có khối kiến thức riên, vốn được tích lũy từ kinh nghiệm .
Chúng cung cấp cấu trúc và các tính ổn định cho các tổ chức.
Các chức năng là những 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 tương ứng và trách nhiệm đối với m ột
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 các phương
pháp làm việc của chúng m ột các h 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 kết
hợp với m ột sự tập trung hướng nội, dẫn đến các hầm ngầm chức
năng cản trở sự liên kết và phản hồi quan trọng đối với sự thành
công của tổ chức nói chung. Các m ô hình quy trình giúp tránh khỏi
vấn đề này với các 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 lực sản xuất trong và trên toàn
bộ các chức năng.

29
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 cung c ấp những thay đổi và sự chuyển đổi hướng về phía
m ục tiêu, và s ử dụng phản hồi để tự-củng cố và t ự-sửa chữa (Hình
2.2). Điều quan tr ọng là xem xét toàn b ộ quy trình hoặc các m à m ột
quy trình phù h ợp với quy trình khác.
Hình 2.2 – Một qu y trình cơ b ản
Các định nghĩa quy trình m ô t ả các hoạt động, phụ thuộc và chuỗi
trình t ự. Các quy trình có nh ững đặc trưng sau đây:
 Có thể đo lường được - chúng ta có thể đo lường quy trình

theo m ột cách thích đáng. Đó là hi ệu suất định hướng. Các
nhà quản lý m uố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 hành lại quan tâm đến
khoảng thời gian và năng su ất.
 Các kết quả cụ thể - lý do để m ột quy trình t ồn tại là để cung
cấp m ột kết quả cụ thể. Kết quả này phải có thể xác định được
và tính được m ột cách riêng rẽ. Trong khi chúng ta có th ể tính
được những thay đổi thì việc tính toán xem bao nhiêu Bộ
phận Hỗ trợ Dịch vụ đã được hoàn thành là đi ều bất khả thi.
 Khách hàng – m ọi quy trình đều cung cấp kết quả chủ yếu của
nó cho m ột khách hàng ho ặc bên liên quan. Khách hà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 các k ỳ vọng của họ.
 Ứng phó với một sự kiện cụ thể - khi m à m ột quy trình có
thể là liên t ục hoặc lặp đi lặp lại, nó nên có thể theo dõi được
đối với m ột sự kiện kích hoạt cụ thể.
Thường có s ự nhầm lần giữa chức năng, quy trình, vai trò và ho ạt
động. Các chức năng thường bị nhầm lẫn với quy trình và ngư ợc lại.
Thiết kế Dịch vụ, cũng như là m ột giai đoạn trong vòng đ ời của m ột
dịch vụ, tự bản thân nó có th ể được một số tổ chức xem như là m ột
chức năng, bởi m ột vài tổ chức khác là m ột vai trò hoặc một bộ các
quy trình hoặc như là m ột hoạt động. Thiết kế Dịch vụ có phải là m ột
chức năng, vai trò, hoạt động hay m ột bộ các quy trình hay không

30
phụ thuộc hoàn toàn vào quy m ô, c ấu trúc và văn hóa c ủa m ột tổ
chức. Điều quan tr ọng là dù cho nó đư ợc định nghĩa và triển khai
như thế nào trong m ột tổ chức thì sự thành công c ủa chức năng, quy
trình, vai trò ho ặc hoạt động vẫn được đo lư ờng và liên t ục cải tiến.
2.3.3 Chuyên môn hóa và ph ối hợp trong suốt vòng đời

Sự chuyên m ốn hóa và ph ối hợp là điều cần thiết trong phương pháp
tiếp cận theo 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 yếu tố của vòng đời làm
cho điều này trở nên khả thi. Hình m ẫu vượt trội trong vòng đời là
tiến trình tuần tự bắt đầu từ SS (Chiến lược Dịch vụ) qua SD (Thiết
kế Dịch vụ) – ST (Chuyển tiếp Dịch vụ) – SO (Vận hành dịch vụ) và
quay trở lại SS thông qua CSI (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 yếu tố của vòng
đời đều cung cấp các đi ểm dành cho phản hồi và kiểm soát.
Sự kết hợp giữa nhiều quan điểm cho phép linh động hơn, ki ểm soát
hơn qua những m ôi trường và tình huống. Phương pháp ti ếp cận
kiểu vòng đời bắt chước thực tế của hầu hết các tổ chức, nơi m à sự
quản lý hiệu quả đòi hỏi phải sử dụng nhiều quan điểm kiểm soát
khác nhau. Những ai chịu trách nhiệm cho thiết kế, phát triển và cải
tiến các quy trình 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. Đối với những ai chịu trách nhi ệm về
việc quản lý các th ỏa thuận, hợp đồng và các dịch vụ có thể được
phục vụ tốt hơn bởi m ội quan điểm kiểm soát dựa trên-vòng đời với
các giai đoạn riêng biệt. Cả hai quan đi ểm kiểm soát này đ ều đượ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ộ
những hình m ẫu m à có th ể không rõ ràng t ừ góc nhìn khác.
2.4 Các nguyên tắc cơ bản trong Thiết kế Dịch vụ

2.4.1 Mục đích/đích đến/mục tiêu
Mục đích chính của giai đoạn Thiết kế Dịch vụ của vòng đời là thiết
kế các dịch vụ m ới hoặc được thay đổi để đưa vào m ôi trường thật.
Điều quan trọng là m ột phương pháp tiếp cận m ang tính toàn diện
đối với m ọi khía cạnh thiết kế được thông qua, và rằng khi sự thay
đổi hoặc điều chỉnh bất kỳ yếu tố riêng rẽ nào trong thiết kế thì m ọi
yếu tố khác phải được xem xét. Do đó khi thiết kế và phát triển m ột
ứng dụng m ới, nó không nên được hoàn thành m ột cách độc lập m à
nên xem xét đến tác động đến tổng thể dịch vụ, các công cụ và hệ
thống quản lý (ví dụ, Danh m ục Dịch vụ và Mục lục Dịch vụ), kiến
trúc, công nghệ, các quy trình Quản lý Dịch vụ và các thước đo và
chỉ số cần thiết. Điều này sẽ đảm bảo rằng không chỉ các yếu tố
thuộc về chức năng được xác định bởi thiết kế m à m ọi yêu cầu quản
lý và vận hành cũng được xác định như là m ột phần cơ bản của thiết
kế và không được thêm vào như là m ột suy nghĩ đến m uộn.
Một phương pháp tiếp cận m ang tính toàn di ện nên được áp dụng
cho m ọi khía c ạnh và m ọi lĩnh vực Thiết kế Dịch vụ để đảm bảo tính
nhất quán và th ống nhất trong m ọi hoạt động và quy trình trên toàn
bộ công nghệ CNTT, cung cấp các chức năng và ch ất lượng liên
quan đến-kinh doanh từ đầu-đến-cuối.

31
Không phải m ọi thay đổi trong m ột dịch vụ CNTT đều sẽ đòi hỏi sự
thúc đẩy của các hoạt động Thiết kế Dịch vụ. Thiết kế Dịch vụ chỉ
được yêu cầu khi có những thay đổi ‘đáng kể’. Mọi tổ chức phải xác
định những cấu thành ‘đáng kể’ để từ đó m ọi người trong tổ chức
đều rõ ràng về việc khi nào thì hoạt động Thiết kế Dịch vụ được
thúc đẩy. Do đó, m ọi thay đổi nên được đánh giá về tác động của
chúng đến các hoạt động Thiết kế Dịch vụ để xác định xem liệu
chúng có đáng kể về m ặt yêu cầu hoạt động Thiết kế Dịch vụ hay
không. Điều này nên là m ột phần của quy trình đánh giá tác động
của Quản lý Thay đổi trong ấn phẩm Chuyển tiếp Dịch vụ của ITIL.
2.4.2 Phạm vi
Có năm khía cạnh riêng lẻ của Thiết kế Dịch vụ được xem xét trong
ấn phẩm này. Đó là thiết kế của:
 Những dịch vụ m ới hoặc được thay đổi.

 Các hệ thống và công cụ Quản lý Dịch vụ , đặc biệt là Danh
m ục Dịch vụ, bao gồm cả Mục lục Dịch vụ.
 Kiến trúc công nghệ và các hệ thống quản lý.
 Các quy trình được yêu cầu.
 Các phương pháp và chỉ số đo lường.
Giai đoạn Thiết kế Dịch vụ của vòng đời bắt đầu với m ột bộ các yêu
cầu kinh doanh m ới hoặc đã được thay đổi và kết thúc với sự phát
triển của m ột giải pháp dịch vụ được thiết kế để đáp ứng những nhu
cầu đã được tài liệu hóa của doanh nghiệp. Giải pháp được phát
triển này, cùng với Gói Thiết kế Dịch vụ (SDP – Service Design
Package – xem Phụ lục A) của nó sau đó được chuyển cho Chuyển
tiếp Dịch vụ để đánh giá, xây dựng, kiểm tra và triển khai dịch vụ
mới hoặc đã được thay đổi. Khi những hoạt động chuyển tiếp dịch
vụ này hoàn thành, biện pháp kiểm soát được chuyển cho giai đoạn
Vận hành Dịch v ụ của Vòng đời Dịch vụ. Các hoạt động liên quan
trong giai đoạn này được phác thảo trong phần 3. Phạm vi tổng thể
của Thiết kế Dịch vụ và năm khía cạnh thiết kế và chúng tương tác
như thế nào được m inh họa trong Hình 2.3.

32
Hình 2.3 – Phạm vi của Thiết kế Dịch vụ
Mục đích chính của Thiết kế Dịch vụ là thiết kế các dịch vụ mới hoặ c
được thay đổi. Những yêu cầu cho các dịch vụ m ới được trích xuất
từ Danh m ục Dịch vụ. Mỗi yêu c ầu được phân tích, ghi nhận lại và
thỏa thuận, và m ột giải pháp thi ết kế được đưa ra sau đó được so
sánh với những chiến lược và ràng bu ộc từ Chiến lược Dịch vụ để
đảm bảo rằng nó tuân thủ các chính sách c ủa công ty và các chính
sách CNTT. Mỗi Thiết kế Dịch vụ riêng lẻ cũng được cân nhắc trong
m ối liên k ết với m ỗi m ột trong các khía c ạnh của Thiết kế Dịch vụ:
 Các công cụ và hệ thống Quản lý Dịch vụ, đặc biệt là Danh
m ục Dịch vụ: để đảm bảo rằng dịch vụ mới hoặc được thay đổi
này nhất quán với m ọi dịch vụ khác, và r ằng m ọi dịch vụ khác
giao tiếp, hỗ trợ hoặc phụ thuộc vào dịch vụ m ới hoặc được
thay đổi này là nhất quán với dịch vụ mới. Nếu không thì thi ết
kế dịch vụ m ới hoặc các dịch vụ khác đang hi ện hữu sẽ cần
phải được thích ứng.
 Các ki ến trúc công ngh ệ và các hệ thống quản lý: để đảm
bảo răng m ọi kiến trúc công nghệ và các hệ thống quản lý nhất
quán với dịch vụ mới hoặc đã được thay đổi và có đ ủ năng lực
để vận hành và duy trì d ịch vụ m ới. Nếu không thì sau đó các
kiến trúc ho ặc hệ thống quản lý s ẽ cần phải được điều chỉnh
hoặc thiết kế dịch vụ m ới cần phải được sửa đổi.

33
 Các quy trình : để đảm bảo rằng các quy trình, vai trò, trách
nhiệm và kỹ năng có đủ năng lực để vận hành, hỗ trợ và duy
trì được dịch vụ mới hoặc đã được thay đổi. Nếu không, thi ết
kế của dịch vụ m ới sẽ cần phải được sửa đổi hoặc các năng
lực quy trình hiện hữu sẽ cần phải đưọc tăng cư ờng. Việc này
bao gồm m ọi quy trình Quản lý Dịch vụ và quy trình CNTT ch ứ
không chỉ các quy trình Thi ết kế Dịch vụ chủ yếu.
 Các phương pháp và ch ỉ số đo lường: để đảm bảo rằng các
phương pháp đo lư ờng hiện hữu có thể cung cấp các ch ỉ số
được yêu c ầu đối với dịch vụ m ới hoặc đã được thay đ ổi. Nếu
không, sau đó các phương pháp đo lư ờng sẽ cần phải được
tăng cường hoặc các chỉ số dịch vụ sẽ cần phải được điều
chỉnh.
Nếu m ọi hoạt động nói trên đã đư ợc hoàn tất trong giai đoạn Thiết
kế Dịch vụ thì điều này sẽ đảm bảo rằng sẽ có rất ít vấn đề phát
sinh trong nh ững giai đoạn tiếp theo c ủa Vòng đời Dịch vụ. Do đó,
Thiết kế Dịch vụ phải thống nhất m ọi vấn đề và hoạt động thiết kế
chủ yếu của m ọi quy trình Qu ản lý Dịch vụ và quy trình CNTT trong
bản thân các hoạt động thiết kế của nó, để đảm bảo rằng m ọi khía
cạnh được xem xét và bao g ồm trong m ọi thiết kế cho các d ịch vụ
mới hoặc đã được thay đổi như m ột phần của quy trình ho ạt động
hàng ngày.
Khả năng đo lường và chứng m inh giá tr ị đối với doanh nghi ệp đòi
hỏi phải có năng l ực để liên kết các kết quả kinh doanh, các m ục
tiêu và các quy trình và ch ức năng cơ sở của chúng với các dịch vụ
CNTT và các tài s ản, quy trình và ch ức năng cơ bản của chúng. Giá
trị này phải được khớp với:
 Việc thỏa thuận về các m ức dịch vụ, SLA và đích nh ắm m ục

tiêu trong toàn b ộ doanh nghiệp, đảm bảo các quy trình nghi ệp
vụ quan trọng nhận được sự quan tâm đầy đủ.
 Việc đo lường chất lượng của CNTT về m ặt doanh
nghiệp/người sử dụng, báo cáo nh ững gì liên quan đ ến người
sử dụng (ví dụ, mức độ hài lòng c ủa người sử dụng, giá trị
kinh doanh).
 Việc ánh xạ các quy trình nghiệp vụ với cơ sở hạ tầng CNTT,
kể từ khi các thành ph ần m ới được liên tục thêm vào, gia tăng
khả năng gián đoạn gây ra bởi CNTT và m ất tập trung vào các
quy trình ng hiệp vụ và dịch vụ kinh doanh.
 Việc ánh xạ giữa các quy trình nghi ệp vụ với doanh nghi ệp và
các thước đo dịch vụ, làm cho d ịch vụ tập trung vào các thư ớc
đo CNTT liên quan t ới các khía c ạnh chủ yếu của hiệu suất
kinh doanh.
 Việc ánh xạ giữa các tài nguyên cơ sở hạ tầng với các dịch vụ
nhằm tận dụng đầy đủ lợi thế của các thành phần CNTT quan
trọng trong H ệ thống Quản lý Cấu hình (Configuration
Managem ent System – CMS), vốn được liên k ết với các quy
trình nghiệp vụ quan trọng. Việc này có thể sử dụng thông tin
trong Hệ thống Quản lý Kiến thức Dịch vụ (Service Knowledge

34
Managem ent System - SKMS) hoàn ch ỉnh. Có thể tìm thấ y
nhiều thông tin hơn nữa trong ấn phẩm Chuyển tiếp Dịch vụ.
 Việc cung cấp sự giám sát từ đầu-đến-cuối và đo lường các
quy trình nghiệp vụ trực tuyến, được báo cáo đ ịnh kỳ so với
đích nhắm m ục tiêu SLA.
Thường thì việc thiết kế m ột dịch vụ m ột dịch vụ ưu việt m ới hoặc

được thay đổi sẽ đòi hỏi rằng những thay đổi thiết kế được cân
nhắc, và thường tác động hoặc bị tác động bởi tất cả bốn giai đoạn
khác của Vòng đời Dịch vụ. Do đó, đi ều thiết yếu là các h ệ thống và
dịch vụ CNTT được thiết kế, hoạch định, triển khai và qu ản lý m ột
cách tương xứng với toàn thể doanh nghi ệp. Yêu c ầu sau đó là cung
cấp các dịch vụ CNTT m à:
 Được định hướng, tập trung và thúc đẩy-doanh nghi ệp và

khách hàng,
 Có hiệu quả chi phí và b ảo m ật,
 Linh hoạt và có th ể thích ứng được, nhưng phù hợp với m ục
đích t ại thời điểm cung c ấp,
 Có thể hấp thụ nhu cầu ngày càng -tăng về khối lượng và tốc
độ thay đổi,
 Đáp ứng nhu c ầu kinh doanh ngày càng tăng đ ể hoạt động liên
tục,
 Được quản lý và vận hành ở m ột m ức độ rủi ro có thể chấp
nhận được,
 Phản ứng nhanh, với tính sẵn sàng tương ứng khớp với các
nhu cầu kinh doanh.
Với tất cả những áp lực này đối với cả CNTT và doanh nghi ệp, sự
cám dỗ - và không m ay là th ực tế trong m ột số trường hợp - là ‘cắt
giảm ’ các quy trình thi ết kế và hoạch định hoặc bỏ qua chúng m ột
cách hoàn toàn. Tuy nhiên, trong nh ững tình huống này, các ho ạt
động thiết kế và hoạch định thậm chí còn thi ết yếu hơn để cung c ấp
dịch vụ chất lượng tổng thể. Do đó, nên dành nhi ều thời gian hơn là
ít hơn cho các quy trình thi ết kế và thực hiện chúng.
Để có thể đạt được thiết kế chất lượng, hiệu quả, ngay c ả khi
khoảng thời gian là ng ắn và áp lực phải cung cấp dịch vụ cao, các tổ
chức nên đảm bảo rằng tầm quan tr ọng của chức năng Thi ết kế dịch
vụ được hiểu m ột cách đầy đủ và rằng sự hỗ trợ được cung c ấp để
duy trì và hoàn thi ện Thiết kế Dịch vụ như m ột yếu tố cơ bản của
Quản lý Dịch vụ. Các tổ chức nên cố gắng m ột cách liên t ục để xem
xét và c ải thiện năng lực Thiết kế Dịch vụ của họ, để Thiết kế Dịch
vụ đó có thể trở thành m ột thực tiễn nhất quán và có th ể lặp lại, cho
phép các t ổ chức cung cấp các dịch vụ chất lượng trong những
khoảng thời gian đ ầy thách thức. Việc có được m ột thực tiễn Thiết
kế Dịch vụ thuần thục cũng s ẽ cho phép các t ổ chức giảm thiểu rủi
ro trong các giai đo ạn chuyển tiếp và vận hành dịch vụ.
Nói chung, chìa khóa đ ể cung cấp m ột cách thành công các d ịch vụ
CNTT là m ức độ thiết kế và lập kế hoạch thích hợp để xác định

35
những dự án, quy trình và d ịch vụ nào sẽ có tác động hoặc lợi ích
lớn nhất đối với doanh nghi ệp. Với m ức độ suy nghĩ, thiết kế, chuẩn
bị và hoạch định thích hợp, nỗ lực có thể được nhắm m ục tiêu vào
những lĩnh vực sẽ m ang lại lợi nhuận lớn nhất. Đánh giá và qu ản lý
rủi ro là những yêu cầu chính trong m ọi hoạt động thiết kế. Do đó,
tất cả năm khía cạnh của Thiết kế Dịch vụ phải bao gồm đánh giá và
quản lý r ủi ro như m ột phần tích hợp và vốn có của m ọi việc m à các
khía cạnh này thực hiện. Điều này s ẽ đảm bảo rằng các r ủi ro liên
quan đến việc cung cấp dịch vụ và vận hành các quy trình, công
nghệ và phương pháp đo lư ờng được liên k ết với rủi ro và tác động
kinh doanh, bởi vì đánh giá và qu ản lý rủi ro được nhúng vào trong
tất cả các quy trình và ho ạt động t hiết kế.
Nhiều thiết kế, kế hoạch và dự án thất bại do thiếu sự chuẩn bị và

quản lý. Việc triển khai Quản lý Dịch vụ ITIL như m ột thông l ệ là sự
chuẩn bị và hoạch định việc sử dụng hiệu quả và hiệu quả bốn chữ
P: Con người (People), Quy trình (Processes), Sản phẩm (Products -
dịch vụ, công ngh ệ và công c ụ) và Đối tác (Partners - nhà cung c ấp,
nhà sản xuất và nhà cung c ấp), như đư ợc m inh họa trong Hình 2.4.
Hình 2.4 – Bốn ch ữ P
Tuy nhiên, không có l ợi ích nào trong vi ệc cung cấp các thi ết kế, kế
hoạch, kiến trúc và chính sách và gi ữ lại cho bản thân bạn. Chúng
phải được công b ố, thỏa thuận, lưu hành và s ử dụng m ột cách ch ủ
động.
Nhằm đảm bảo rằng các dịch vụ CNTT và dịch vụ kinh doanh vẫn
giữ được sự đồng bộ, nhiều tổ chức hình thành các ủy ban gồm các
nhà quản lý cấp cao t ừ các tổ chức CNTT và doanh nghi ệp. Ủy ban
đảm trách trách nhi ệm tổng thể cho việc thiết lập quản trị, định
hướng, chính sách và chi ến lược cho các dịch vụ CNTT. Rất nhiều
tổ chức gọi nhóm này là Nhóm Chi ến lược CNTT hoặc Nhóm Chỉ đạo
CNTT (ISG). Chức năng c ủa m ột ISG là đóng vai trò như m ột quan
hệ đối tác giữa CNTT và doanh nghi ệp. ISG nên họp m ột cách
thường xuyên và đánh giá các chi ến lược, thiết kế, kế hoạch, Danh

36
m ục Dịch vụ, kiến trúc và chính sách CNTT đ ể đảm bảo rằng chúng
được liên kết m ột cách chặt chẽ với nhau. H ọ (ISG) nên cung c ấp
tầm nhìn, thiết lập định hướng và xác định m ức độ ưu tiên c ủa các
chương trình và dự án riêng lẻ để đảm bảo rằng CNTT được liên k ết
với và tập trung vào các m ục tiêu và đ ịnh hướng kinh doanh. Nhóm
cung nên đảm bảo rằng những khoảng thời gian không th ực tế, vốn
có thể gây nguy hi ểm cho chất lượng hoặc làm gián đo ạn các yêu
cầu thuộc về vận hành, không bị áp đặt hoặc cố gắng bởi cả doanh
nghiệp lẫn CNTT. Xem Hình 2.5.
ISG sẽ bao gồm các cuộc thảo luận về m ọi khía c ạnh của doanh
nghiệp liên quan đến dịch vụ CNTT, cũng như những thay đổi được
đề xuất hoặc thay đổi khả dĩ ở cấp độ chiến lược. Những chủ đề
thảo luận của ISG có th ể bao gồm :
 Đánh giá các kế hoạch CNTT và kế hoạch kinh doanh : để

xác định bất kỳ thay đổi nào trong lĩnh v ực có thể sẽ kích hoạt
nhu cầu tạo ra, tăng cường hoặc cải thiện các dịch vụ.
 Hoạch định nhu cầu: để xác định bất kỳ thay đổi nào trong
nhu cầu trong c ả chân trời hoạch định ngắn hạn và dài hạn,
chẳng hạn như những thay đổi có thể làm tăng ho ặc giảm nhu
cầu, và quan tâm đến hoạt động kinh doanh-như-bình thư ờng
và các dự án.
 Cấp phép và thi ết lập độ ưu tiên cho d ự án: để đảm bảo
rằng các dự án được cấp phép và đư ợc thiết lập m ức ưu tiên
cho sự hài lòng chung c ủa cả doanh nghi ệp lẫn CNTT.
 Đánh giá các d ự án: để đảm bảo rằng những lợi ích kinh
doanh được kỳ vọng đang đư ợc hiện thực hóa phù hợp với các
đề án kinh doanh dự án, và để xác định liệu các dự án có
đang đúng theo l ịch trình hay không.
 Thuê ngoài ti ềm năng: để xác định nhu c ầu và nội dung của
các chiến lược thuê ngoài cho vi ệc cung cấp dịch vụ CNTT.
 Xem xét chi ến lư ợc kinh doanh/CNTT: để thảo luận về
những thay đ ổi quan trọng đối với chiến lược kinh doanh và
những thay đ ổi quan trọng được đề xuất đối với chiến lược và
công nghệ CNTT, để đảm bảo tính liên kết được liên tục.
 Liên tục kinh doanh và Liên t ục Dịch vụ CNTT: nhóm , hoặc
m ột phần hoạt động của nhóm , chịu trách nhi ệm cho việc liên
kết các chiến lược Liên tục Kinh doanh và Liên t ục Dịch vụ
CNTT.
 Các chính sách và tiêu chu ẩn: ISG chịu trách nhi ệm cho việc
đảm bảo rằng các chính sách và tiêu chu ẩn CNTT, đặc biệt là
liên quan đ ến các chiến lược tài chính và qu ản lý hiệu suất, là
có sẵn và được liên kết với tầm nhìn và các m ục tiêu tổng thể
của công ty.

37
Hình 2.5 – Nhóm Chiến lược/Chỉ đạo CNTT
Nhóm Chỉ đạo CNTT thi ết lập định hướng cho các chính sách và k ế
hoạch từ cấp công ty đến vận hành c ủa các t ổ chức CNTT và đảm
bảo rằng chúng (các chính sách và k ế hoạch) nhất quán với các
chiến lược ở cấp độ công ty. Xem Hình 2.5.
ISG đóng m ột vai trò quan trọng trong vi ệc liên k ết giữa các chi ến
lược và kế hoạch kinh doanh và CNTT như đã đư ợc m inh họa trong
Hình 2.5. Như có th ể thấy, Danh m ục Dịch vụ là m ột nguồn đầu vào
chủ yếu đối với ISG trong vai trò đưa ra -quyết định của mình, vốn
cho phép ISG để:
 Định hướng và chỉ đạo sự lựa chọn đầu tư vào những lĩnh vực
m à m ang lại giá trị kinh doanh và Lợi nhuận Đầu tư lớn nhất.
 Tiến hành vi ệc lựa chọn, thiết lập ưu tiên và ho ạch định dự án
và chương trình hi ệu quả.
 Thực thi hi ệu quả việc quản trị liên t ục và quản lý chủ động
‘đường ống’ các yêu cầu kinh doanh.
 Đảm bảo rằng những lợi ích của việc kinh doanh đư ợc dự
đoán của các chương trình và các d ự án được hiện thực hóa.
2.4.3 Giá trị đối với doanh nghiệp

Với Thiết kế Dịch v ụ tốt sẽ có có khả năng để cung cấp các dịch vụ
có chất lượng, hiệu quả về-chi phí và để đảm bảo rằng các yêu c ầ u
kinh doanh sẽ được đáp ứng.
Những lợi ích sau đây là k ết quả của thực tiễn Thiết kế Dịch vụ tốt:
 Giảm Tổng Chi phí Sở hữu (TCO): chi phí sở hữu chỉ có thể
được tối thiểu hóa nếu m ọi khía c ạnh của dịch vụ, quy trình và
công nghệ được thiết kế m ột cách đúng đ ắn và được triển khai
dựa vào thi ết kế.

38
 Chất lượng của dịch vụ được cải thiện: chất lượng của cả
dịch vụ lẫn vận hành sẽ được tăng cường.
 Tính nhất quán của dịch vụ được cải thiện: do các dịch vụ
được thiết kế theo chiến lược, các ki ến trúc và ràng bu ộc của
công ty.
 Triển khai các d ịch vụ mới ho ặc được thay đổi d ễ dàng
hơn: do có Thi ết kế Dịch vụ đầy đủ và được tích hợp và sự
sản xuất các SDP (Gói Thi ết kế Dịch vụ) toàn diện.
 Sự liên kết dịch vụ được cải thi ện: sự liên quan từ ý đồ của
dịch vụ, đảm bảo rằng các dịch vụ m ới hoặc đã được thay đổi
đáp ứng các nhu c ầu kinh doanh, cùng với các dịch vụ được
thiết kế để đáp ứng các Yêu cầu Mức Dịch vụ.
 Hiệu su ất dịch vụ hiệu quả hơn: với sự kết hợp và s ự công
nhận của các Kế hoạch Công su ất, Tính sẵn sàng Tài chính và
Kế hoạch Liên t ục Dịch vụ CNTT.
 Cải thiện quản trị CNTT: được trợ giúp với việc triển khai và
truyền đạt m ột bộ các biện pháp kiểm soát đối với quản trị
CNTT.
 Các qu y trình CNTT và Qu ản lý Dịch vụ hiệu quả hơn: các
quy trình s ẽ được thiết kế với chất lượng và hiệu quả chi phí
được tối ưu hóa.
 Thông tin và vi ệc đưa ra quyết định được cải thiện: các
thước đo và chỉ số toàn diện hơn s ẽ cho phép đưa ra quy ết
định tốt hơn và liên tục cải tiến những thực tiễn Quản lý Dịch
vụ trong giai đoạn thiết kế của Vòng đời Dịch vụ.
2.4.4 Tối ưu hóa hiệu suất thiết kế

Việc tối ưu hóa của các hoạt động thiết kế đòi hỏi sự triển khai các
quy trình được tài liệu hóa, cùng với m ột hệ thống quản lý dịch vụ
quan trọng hơn bất kỳ nhận định nào khác (chẳng hạn như ISO
9001) cho sự đo lường và cải tiến liên tục của chúng. Điều quan
trọng là khi xem xét sự cải thiện và tối ưu hóa các hoạt động Thiết
kế Dịch vụ, tác động của các hoạt động trong m ọi giai đoạn của
vòng đời nên được đo lường và không chỉ tác động đến giai đoạn
thiết kế. Do đó các thước đo và chỉ số Thiết kế Dịch vụ nên xem xét
đến lượng hoạt động phải thực hiện lại và các hoạt động cải thiện
cần thiết cho các hoạt động chuyển tiếp, vận hành và cải thiện như
là kết quả của sự không thỏa đáng trong thiết kế của các giải pháp
dịch vụ m ới hoặc được thay đổi. Thông tin thêm về thước đo Thiết
kế Dịch vụ có thể được tìm thấy trong phần 8.5.
2.4.5 Các quy trình Thiết kế Dịch vụ

Ấn phẩm này chi tiết hóa cá c quy trình cần thiết trong giai đoạn thiết
kế của Vòng đời Dịch vụ. Những quy trình này không thể được xem
xét m ột cách riêng biệt, do giá trị thực của chúng sẽ chỉ có thể được
hiện thực hóa khi các giao diện giữa các quy trình được xác định và
hoạt động được. Những quy trình sau đây được chi tiết hóa trong ấn
phẩm này:
 Quản lý Mục lục Dịch vụ : để đảm bảo rằng m ột Mục lục Dịch
vụ được đưa ra và duy trì, bao gồm các thông tin chính xác về

39
m ọi dịch vụ vận hành và những gì đang được chuẩn bị đối vớ i
hoạt động vận hành.
 Quản lý Mức Dịch vụ : thương lượng, thỏa thuận và ghi nhận
các đích nhắm m ục tiêu dịch vụ CNTT tương xứng với những
đại diện của doanh nghiệp, và sau đó giám sát và đưa ra các
báo cáo về khả năng của nhà cung cấp dịch vụ trong việc cung
cấp m ức đã thỏa thuận của dịch vụ.
 Quản lý Công suất : để đảm bảo công suất CNTT hợp lý về c hi
phí trong m ọi lĩnh vực của CNTT luôn luôn hiện hữu và khớp
với các nhu cầu hiện tại và trong tương lai được thỏa thuận
của doanh nghiệp m ột cách kịp thời.
 Quản lý Tính sẵn sàng: để đảm bảo rằng m ức sẵn sàng của
dịch vụ được cung cấp trong m ọi dịch vụ khớp với, hoặc vượt
quá, những nhu cầu hiện tại và trong tương lại được thỏa
thuận của doanh nghiệp theo cách hiệu quả về chi phí.
 Quản lý Liên tục Dịch vụ CNTT : để đảm bảo rằ ng công nghệ
và các phương tiện dịch vụ CNTT (bao gồm hệ thống m áy tính,
m ạng, ứng dụng, kho dữ liệu, truyền thông, m ôi trường, hỗ trợ
kỹ thuật và Bộ phận Hỗ trợ Dịch vụ ) có thể khôi phục lại trong
khung thời gian kinh doanh đã được yêu cầu và thỏa thuận.
 Quản lý Bảo mật Thông tin : để liên kết bảo m ật CNTT với
bảo m ật kinh doanh, và đảm bảo rằng bảo m ật thông tin được
quản lý m ột cách hiệu quả trong m ọi dịch vụ và hoạt động
Quản lý Dịch vụ.
 Quản lý Nhà cung cấp : để quản lý các nhà cung cấp và các
dịch vụ m à họ cung cấp, để cung cấp sự liền m ạch trong chất
lượng của dịch vụ CNTT đối với doanh nghiệp, đảm bảo thu
được giá trị của tiền.
Đây chỉ là m ột số trong các quy trình được m ô tả trong hướng dẫn
thực tiễn Quản lý Dịch vụ ITIL. Mọi quy trình trong vòng đời Quản lý
Dịch vụ phải được liên kết m ột cách chặt chẽ cùng với việc quản lý,
thiết kế, hỗ trợ và duy trì các dịch vụ, cơ sở hạ tầng CNTT, m ôi
trường, các ứng dụng và dữ liệu. Các quy trình khác được m ô tả chi
tiết trong các ấn phẩm khác của thư viện cốt lõi về những thực tiễn
Quản lý Dịch vụ ITIL. Các giao diện giữa m ọi quy trình và m ọi quy
trình khác cần được xác định m ột cách rõ ràng khi thiết kế m ột dịch
vụ hoặc cải thiện hoặc triển khai m ột quy trình. Những giao diện này
được m ô tả chi tiết trong phần 4 và không chỉ bao gồm các giao diện
cho m ỗi quy trình Thiết kế Dịch vụ m à còn có các giao diện cho
những quy trình trong các giai đoạn khác của vòng đời.
Khi thiết kế m ột dịch vụ hoặc m ột quy trình, m ột điều bắt buộc là m ọi

vai trò phải được xác định m ột c ách rõ ràng. Một thương hiệu của
các tổ chức có hoạt động cao là khả năng đưa ra quyết định đúng
m ột cách nhanh chóng và thực hiện chúng m ột cách nhanh chóng.
Dù là quyết định liên quan tới m ột lựa chọn chiến lược hay m ột hoạt
động quan trọng, sự rõ ràng v ề việc ai đã nhập đầu vào, ai quyết
định và ai thực thi sẽ cho phép tổ chức tiến lên về phía trước m ột
cách nhanh chóng.

40
3 Các nguyên tắc Chiến lược Dịch vụ
Trước tiên, hãy coi rằng thiết kế là thông minh và chính xác:
rằng đã được xác định chắc chắn, hãy t heo đuổi nó một cách
kiên qu yết, đừng vì chần chừ mà bỏ qua mục đích mà bạn đã
kiên quyết tác động.
William Shakespeare (1564 – 1616).
Sai lầm phổ biến mà mọi người hay mắc phải khi cố gắng thiết
kế một cái gì đó hoàn toàn không thể hư hỏng là đánh giá quá
thấp tính khéo léo của những kẻ hoàn toàn ngu ngốc.
Douglas Adams.
Thiết kế Dịch vụ CNTT là m ột phần của quy trình thay đổi doanh
nghiệp tổng thể. Quy trình thay đổi doanh nghiệp này và vai trò của
CNTT được m inh họa trong Hình 3.1.
Hình 3.1 – Quy trình thay đổi doanh nghiệp
Khi thông tin chính xác về những gì cần thiết đã được thu thập và
được ký xác nhận, liên quan tới những thay đổi cần thiết đối với
doanh nghiệp, kế hoạch cung cấp m ột dịch vụ đáp ứng được nhu
cầu đã thỏa thuận có thể được phát triể n.
Vai trò của giai đoạn Thiết kế Dịch vụ trong quy trình thay đổi doanh
nghiệp tổng thể có thể được xác định như là:
‘Thiết kế các dịch v ụ thích hợp và sáng tạo, bao gồm kiến trúc,
quy trình, chính sách và tài li ệu của chúng, để đáp ứng những yêu
cầu kinh doanh đã thỏa thuận trong hiện tại và tương lai.’
Điều quan trọng là phải tồn tại các giao diện và liên kết thích hợp
với các hoạt động thiết kế. Khi thiết kế các dịch vụ m ới hoặc đư ợc
thay đổi, quan trọng là toàn bộ Vòng đời Dịch vụ và các quy trình
ITSM phải tham gia ngay từ đầu. Thường thì các khó khăn xảy ra
trong vận hành khi m ột dịch vụ được thiết kế m ới được bàn giao để
hoạt động thực tế vào những phút cuối cùng. Dưới đây là nh ững
hành động cần được thực hiện ngay từ đầu của Thiết kế Dịch vụ để
đảm bảo rằng giải pháp đáp ứng được yêu cầu của doanh nghiệp:
 Giải pháp dịch vụ mới nên được thêm vào Danh m ục Dịch vụ
tổng thể ngay từ giai đoạn lên ý tưởng, và Danh m ục Dịch vụ
nên được cập nhật để phản ảnh tình trạng hiện tại thông qua

41
bất kỳ phát triển gia tăng hoặc lặp lại nào. Việc này được
hưởng lợi không chỉ từ quan điểm tài chính m à còn từ các lĩnh
vực khác trong quá trình thiết kế.
 Là m ột phần của phân tích dịch vụ/hệ thống ban đ ầu, sẽ có
m ột nhu cầu hiểu về các Yêu cầu Mức Dịch vụ (SLRs) cho dịch
vụ khi nó thực sự hoạt động.
 Từ SLRs, nhóm Quản lý Công suất có thể m ô hình hóa điều
này trong cơ sở hạ tầng hiện có để xác định nếu điều này có
khả năng hỗ trợ cho dịch vụ m ới. Nếu thời gian cho phép, kết
quả từ các hoạt động m ô hình hóa có thể được tích hợp vào
Kế hoạch Công suất.
 Nếu cơ sở hạ tầng mới được đòi hỏi cho dịch vụ m ới, hoặc sự
hỗ trợ được m ở rộng, Quản lý Tài chính sẽ cần phải tham gia
vào để thiết lập ngân sách.
 Một Phân tích Tác động Kinh doanh và đánh giá rủi ro ban đầu
nên được tiến hành đối với các dịch vụ trước khi triền khai vì
là đầu vào vô giá đối với Chiến lược Liên tục dịch vụ CNTT,
Thiết kế Tính sẵn sàng và Hoạch định Công suất.
 Bộ phận Hỗ trợ Dịch vụ (Service Desk) cần nhận thức về các
dịch vụ m ới trước khi vận hành thực tế để chuẩn bị và đào tạo
cho nhân viên Bộ phận Hỗ trợ Dịch vụ và nhân viên CNTT tiềm
năng của khách hàng.
 Chuyển tiếp Dịch vụ có thể bắt đầu việc hoạch định sự triển
khai và tích hợp vào lịch tr ình thay đổi.
 Quản lý Nhà cung cấp sẽ cần phải tham gia nếu sự m ua sắm
lằ cần thiết cho dịch vụ m ới.
Thành phần cấu tạo của m ột dịch vụ và các phần tử của nó được
m inh họa trong Hình 3.2.
Hình 3.2 – Thành phần cấu tạo dịch vụ

42
Thiết kế Dịch vụ phải xem xé t m ọi khía cạnh khi thiết kế các giải
pháp dịch vụ để đáp ứng các nhu cầu kinh doanh m ới và đang phát
triển:
 Quy trình nghiệp vụ: để xác định chức năng cần thiết của dịch
vụ sẽ được cung cấp, ví dụ, bán hàng qua điện thoại, lập hóa
đơn, đơn hàng, kiểm tra tín dụng.
 Dịch vụ: chính bản thân dịch vụ được cung cấp cho khách
hàng và cho doanh nghiệp bởi nhà cung cấp dịch vụ, ví dụ,
em ail, thanh toán.
 SLAs/SLRs: những tài liệu đã thỏa thuận với khách hàng chỉ
định m ức, phạm vi và chất lượng của dịch vụ sẽ được cu ng
cấp.
 Cơ sở hạ tầng : m ọi thiết bị CNTT cần thiết để cung cấp dịch
vụ cho khách hàng và người sử dụng, bao gồm m áy chủ, m ạng
chuyển m ạch, bộ chuyển m ạch, m áy tính, điện thoại.
 Môi trường: m ôi trường cần thiết để bảo vệ và vận hành cơ sở
hạ tầng, ví dụ, cá c trung tâm dữ liệu, nguồn điện, điều hòa
không khí.
 Dữ liệu: dữ liệu cần thiết để hỗ trợ dịch vụ và cung cấp thông
tin được yêu cầu bởi các quy trình nghiệp vụ, ví dụ, các hồ sơ
khách hàng, bút toán kế toán.
 Ứng dụng: m ọi phần m ềm ứng dụng cần thiết để vậ n dụng dữ
liệu và cung cấp các yêu cầu chức năng của các quy trình
nghiệp vụ, ví dụ ERM, Tài chính, CRM.
 Các Dịch vụ Hỗ trợ : bất kỳ dịch vụ nào cần thiết để hỗ trợ
việc vận hành của dịch vụ đã được cung cấp, ví dụ, m ột dịch
vụ được chia sẻ, một dịch vụ m ạn g được quản lý.
 Các Thỏa thuận Mức Vận hành (OLAs) và hợp đồng: bất kỳ
thỏa thuận cơ sở nào cần thiết để cung cấp chất lượng của
dịch vụ đã thỏa thuận trong SLA.
 Các Nhóm Hỗ trợ: bất kỳ nhóm hỗ trợ nội bộ nào cung cấp
tuyến hỗ trợ thứ hai và thứ ba cho bấ t kỳ thành phần nào
được yêu cầu để cung cấp dịch vụ, ví dụ, Unix, m áy chủ lớn
(m ainfram e), m ạng.
 Nhà cung cấp: bất kỳ bên thứ ba bên nào ngoài cần thiết để
cung cấp tuyến hỗ trợ thứ ba và thứ tư cho bất kỳ thành phần
nào được đòi hỏi để cung cấp dịch vụ, ví dụ, m ạng, phần
cứng, phần m ềm .
Các hoạt động thiết kế không chỉ phải xem xét m ỗi m ột thành phần
nói trên m ột cách độc lập m à còn phải xem xét m ối quan hệ giữa các
thành phần và sự tương tác và phụ thuộc giữa chúng đối với bất kỳ
thành phần và dịch vụ nà o khác, nhằm cung cấp m ột giải pháp hiệu
quả và toàn diện đáp ứng được các nhu cầu kinh doanh.
3.1 Tạo ra giá trị

Những m ục tiêu và m ục đích chính của Thiết kế Dịch vụ là để:
 Thiết kế các dịch vụ để thỏa m ãn các m ục tiêu kinh doanh,

dựa trên các yêu cầu chất lượng, tuân thủ, rủi ro và bảo m ật,

43
cung cấp các giải pháp, dịch vụ CNTT và giải pháp doanh
nghiệp hiệu quả và năng suất hơn được liên kết với các yêu
cầu kinh doanh bằng sự phối hợp với m ọi hoạt động thiết kế
đối với các dịch vụ CNTT để đảm bảo sự nhất qu án và tập
trung vào kinh doanh.
 Thiết kế các dịch vụ có thể được phát triển và được tăng
cường m ột cách dễ dàng và hiệu quả theo những khung thời
gian thích hợp và chi phí và, nếu có thể, giảm thiểu, tối thiểu
hóa hoặc hạn chế chi phí dài hạn của việc cung cấp dịch vụ.
 Thiết kế các quy trình hiệu quả và năng suất cho việc thiết kế,
chuyển tiếp, vận hành và cải thiện các dịch vụ CNTT chất
lượng cao, cùng với các công cụ, hệ thống và thông tin hỗ trợ,
đặc biệt là Danh mục Dịch vụ, để quản lý các dịch vụ trong
suốt vòng đời của chúng.
 Xác định và quản lý các rủi ro để từ đó chúng có thể được loại
bỏ hoặc giảm thiểu trước khi các dịch vụ đi vào hoạt động.
 Thiết kế những tài nguyên và năng lực cơ sở hạ tầng CNTT,
m ôi trường, ứng dụng và dữ liệu/thông tin bảo m ật và kiên
cường đám ứng được các nhu cầu hiện tại và tương lai của
doanh nghiệp và người khách hàng.
 Thiết kế các phương pháp và chỉ số đo lường để đánh giá tính
hiệu quả và năng suất của các quy trình thiết kế và những sản
phẩm có thể chuyển giao được của chúng (các quy trình thiết
kế).
 Cung cấp và duy trì các kế hoạch, quy trình, chính sách, kiến
trúc, khuôn khổ và tài liệu CNTT cho việc thiết kế các giải
pháp CNTT có chất lượng, đáp ứng được các nhu cầu kinh
doanh đã thỏa thuận hiện tại và trong tương lai .
 Hỗ trợ sự phát triển của các chính sách và tiêu chuẩn trong
m ọi lĩnh vực thiết kế và hoạch định dịch vụ và quy trình CNTT,
nhận và đóng vai trò phản hồi về các quy trình thiết kế từ m ọi
lĩnh vực và kết hợp các hoạt động vào m ột quy trình cải tiến
liên tục.
 Phát triển các kỹ năng và năng lực trong CNTT bằng cách dịch
chuyển các hoạt động chiến lược và thiêt kế thành các tác vụ
vận hành, sử dụng m ọi tài nguyên dịch vụ CNTT hiệu quả và
có năng suất.
 Góp phần vào sự cải thiện chất lượng tổng thể của dịch vụ
CNTT trong những điều kiện ràng buộc thiết kế bắt buộc, đặc
biệt là làm giảm thiểu nhu cầu thực hiện lại và tăng cường
những dịch vụ khi chúng đã được triển khai trong m ôi trường
thật.
3.2 Cân b ằng thiết kế

Đối với bất kỳ yêu cầu kinh doanh m ới nào, thiết kế các dịch vụ là
m ột hành động cân bằng tinh tế, đảm bảo rằng không ch ỉ các yêu
cầu chức năng m à còn các m ục tiêu được nhắm đến về hiệu suất
được đáp ứng. Tất cả những điều này cần được cân bằng thích hợp
với nguồn lực sẵn có theo khung th ời gian cần thiết và chi phí cho
các dịch vụ m ới. Jim McCarthy, tác gi ả của quyển Sự năng động củ a
Phát triển Phần mềm (Dynamics of Software Development) , cho rằng

44
‘Là m ột nhà quản lý sự phát triển, bạn đang làm vi ệc chỉ với ba điều
sau’:
 Chức năng: dịch vụ hoặc sản phẩm và những phương tiện,
chức năng và chất lượng của nó, bao gồm m ọi thứ về chức
năng quản lý và vận hành cần thiết.
 Tài ngu yên: con người, công ngh ệ và tiền bạc sẵn có.
 Lịch trình: khung thời gian.
Chúng được trình bày trong Hình 3.3.
Hình 3.3 – Các phần tử của dự án trong mối quan hệ tam giác
Ý tưởng này là cực kỳ quan trọng đối với các hoạt động Thiết kế
Dịch vụ và sự cân bằng giữa nỗ lực đã tiêu tốn cho thiết kế, phát
triển và cung cấp các dịch vụ để đáp ứng các yêu cầu kinh doanh.
Thiết kế Dịch vụ là m ột hoạt động cân bằng tinh t ế giữa mọi trong ba

45
phần tử và sự điều chỉnh động liên t ục của cả ba (phần tử) để đáp
ứng sự thay đổi trong các nhu c ầu kinh doanh. S ự thay đổi trong
m ột cạnh của tam giác luôn luôn có tác đ ộng đến ít nhất m ột trong
số các cạnh còn lại, nếu không nói là c ả hai cạnh. Do đó, đi ều quan
trọng là định hướng và nhu cầu của doanh nghi ệp phải được hiểu
m ột cách đầy đủ để các giải pháp kinh doanh hi ệu quả nhất được
thiết kế và cung cấp, sử dụng sự cân bằng phù hợp nhất giữa ba
phần tử. Sẽ có khả năng là các đ ịnh hướng và nhu cầu của doanh
nghiệp sẽ thay đổi trong quá trình thi ết kế và cung cấp, do áp l ực
của thị trường. Chức năng và ngu ồn lực nên được xem xét trong m ọi
giai đoạn của Vòng đời Dịch vụ, để từ đó các dịch vụ không ch ỉ
được thiết kế và phát triển m ột cách hi ệu quả và năng suất m à tính
hiệu quả và năng suất của dịch vụ được duy trì trong toàn b ộ m ọi
giai đoạn trong vòng đời của nó.
Sự xem xét thích đáng nên đư ợc đưa ra trong Thi ết kế Dịch vụ đối
với m ọi giai đoạn sau đó trong Vòng đ ời Dịch vụ. Thông thường thì
các nhà thiết kế và kiến trúc sư ch ỉ xem xét vi ệc phát triển m ột dịch
vụ m ới cho đến thời điểm triển khai dịch vụ vào m ôi trường thật. Một
phương pháp ti ếp cận toàn diện đối với thiết kế các dịch vụ CNTT
nên được áp dụng để đảm bảo rằng một giải pháp được tích hợp và
hoàn toàn đ ầy đủ được thiết kế để đáp ứng các yêu c ầu đã thỏ a
thuận của doanh nghi ệp. Phương pháp ti ếp cận này cũng nên đảm
bảo rằng m ọi cơ chế và chức năng c ần thiết được triển khai trong
dịch vụ m ới để từ đó nó có thể được quản lý và cải thiện m ột cách
hiệu quả trong suốt vòng đời vận hành của nó để đạt được m ọi m ục
tiêu được nhắm đến của nó. Một phương pháp có c ấu trúc và chính
thức nên được áp dụng để đảm bảo rằng m ọi khía c ạnh của dịch vụ
được xác định và đ ảm bảo nó được giới thiệu và vận hành m ột cách
trơn tru trong m ôi trư ờng thật.
Các nhà cung c ấp dịch vụ CNTT hiệu quả nhất tích hợp tất cả năm
khía cạnh của thiết kế thay vì chỉ m ột mình việc thiết kế riêng bi ệt.
Điều này đảm bảo rằng m ột Kiến trúc Doanh nghi ệp tích hợp được
tạo ra, bao g ồm một bộ các tiêu chu ẩn, thiết kế và kiến trúc th ỏa
m ãn đưuọc m ọi yêu cầu quản lý và vận hành các dịch vụ cũng như
các yêu c ầu về chức năng được yêu c ầu bởi doanh nghiệp. Thiết kế
được tích hợp này đảm bảo rằng khi m ột dịch vụ m ới hoặc đã thay
đổi được triển khai, nó không ch ỉ cung cấp chức năng được yêu c ầu
bởi doanh nghiệp m à còn đáp ứng và liên t ục đáp ứng các m ức và
m ục tiêu được nhắm đến của nó trong m ọi lĩnh vực. Điều này đảm
bảo rằng không có (hoặc tối thiểu tuyệt đối) những điểm yếu cần
phải được giải quyết m ột cách ngược về quá khứ.
Để đạt được điều này, quản lý t ổng thể các hoạt động thiết kế cần
phải đảm bảo:
 Truyền thông giao tiếp rõ ràng giữa các hoạt động thiết kế
khác nhau và gi ữa m ọi bên khác, bao gồm cả các nhà hoạch
định và lập chiến lược doanh nghi ệp và CNTT.

46
 Phiên bản m ới nhất của m ọi kế hoạch và chiến lược kinh
doanh và CNTT thích h ợp sẵn sàng cho m ọi nhà thiết kế.
 Mọi tài liệu kiến trúc và tài li ệu thiết kế nhất quán với m ọi
chính sách và k ế hoạch của doanh nghiệp và CNTT.
 Các kiến trúc và thi ết kế:
o Linh hoạt và cho phép CNTT ứng phó m ột cách nhanh
chóng với các nhu c ầu kinh doanh m ới.
o Tích hợp với m ọi chiến lược và chính sách.
o Hỗ trợ các nhu cầu của các giai đo ạn khác c ủa Vòng đ ời
Dịch vụ.
o Tạo điều kiện cho các dịch vụ và giải pháp m ới hoặc
được thay đổi về chất lượng, được liên k ết với nhu c ầu
và khung thời gian của doanh nghi ệp.
3.3 Xác định các yêu cầu dịch vụ

Thiết kế Dịch vụ phải xem xét m ọi phần tử của dịch vụ bằng cách
đưa ra m ột phương pháp tiếp cận toàn diện đối với việc thiết kế m ột
dịch vụ m ới. Phương pháp tiếp cận này nên xem xét d ịch vụ và các
thành phần cấu thành nó và các m ối quan h ệ qua lại lẫn nhau, đảm
bảo rằng dịch vụ được cung c ấp đáp ứng được những kỳ vọng về
chức năng và chất lượng dịch vụ của m ọi lĩnh vực kinh doanh:
 Khả năng m ở rộng của dịch vụ để đáp ứng những yêu cầu
trong tương lai, h ỗ trợ cho các m ục tiêu kinh doanh trong dài
hạn.
 Các quy trình nghi ệp vụ và các đơn vị kinh doanh được hỗ trợ
bởi dịch vụ.
 Dịch vụ CNTT và các ch ức năng và yêu cầu doanh nghi ệp đã
thỏa thuận.
 Bản thân d ịch vụ và Yêu cầu Mức Dịch vụ (SLR) hoặc Thỏa
thuận Mức Dịch vụ (SLA) của nó.
 Các thành ph ần công nghệ được sử dụng để triển khai và cung
cấp dịch vụ, bao gồm cơ sở hạ tầng, m ôi trường, dữ liệu và
các ứng dụng.
 Các dịch vụ và các thành ph ần hỗ trợ nội bộ và các Thỏa
thuận Mức Vận hành (OLA) tương ứng của chúng.
 Các dịch vụ và các thành ph ần hỗ trợ bên ngoài và các h ợp
đồng cơ sở tương ứng của chúng, vốn thường sẽ có các thỏ a
thuận và/hoặc lịch trình liên quan c ủa bản thân chúng.
 Các thước đo và chỉ số hiệu suất cần thiết.
 Các m ức bảo m ật cần thiết và theo lu ật pháp.
Các m ối quan hệ và sự phụ thuộc giữa các phần tử này được m inh
họa trong Hình 3.4.

47
Hình 3.4 – Các mối quan hệ và sự phụ thuộc của dịch vụ
Không m ột dịch vụ nào có thể được thiết kế, chuyển tiêp và vận
hành m ột cách riêng bi ệt. Mối quan hệ của m ỗi dịch vụ đối với các
thành phần và dịch vụ hỗ trợ nó phải được hiểu và nhận thức m ột
cách rõ ràng bởi mọi cá nhân trong t ổ chức của nhà cung c ấp dịch
vụ. Một điều khác cũng r ất thiết yếu là m ọi đích nhắm m ục tiêu được
bao hàm trong các th ỏa thuận hỗ trợ, chẳng hạn như các OLA và
hợp đồng, được lấy làm cơ sở cho những gì đã được thỏa thuận
giữa nhà cung c ấp dịch vụ và khách hàng c ủa m ình. Một số khái
niệm này sẽ được thảo luận chi tiết hơn trong các ph ần sau c ủa ấn
phẩm , liên quan đ ến các khía cạnh riêng l ẻ của Thiết kế Dịch vụ.
Tuy nhiên, khi m ột khía c ạnh riêng l ẻ của dịch vụ được thay đổi, tất
cả các lĩnh vực khác c ủa dịch vụ cũng nên được xem xét đ ể đảm
bảo rằng bất kỳ điều chỉnh cần thiết nào để hỗ trợ sự thay đổi đã
được bao gồm trong thi ết kế tổng thể. Càng ngày, các dịch vụ càng
phức tạp và được cung cấp bởi m ột số đối tác hoặc các tổ chức
cung cấp. Nếu có nhi ều nhà cung c ấp dịch vụ tham gia vào vi ệc
cung cấp m ột dịch vụ, điều quan trọng là cơ quan Thi ết kế Dịch vụ
trung tâm phải được thiết lập, để đảm bảo m ọi dịch vụ và quy trình
được tích hợp đầy đủ trong t ất cả các bên.
Trong lĩnh vực công ngh ệ cụ thể, có bốn lĩnh vực công ngh ệ riêng
biệt sẽ cần được giải quyết, vì chúng là các thành ph ần hỗ trợ của
m ọi dịch vụ và đóng góp cho hi ệu suất tổng thể của dịch vụ:
 Cơ sở hạ tầng: quản lý và ki ểm soát tất cả các yếu t ố cơ sở

hạ tầng, bao gồm máy tính lớn, m áy ch ủ, thiết bị m ạng, các h ệ
thống cơ sở dữ liệu, m ạng khu vực lưu tr ữ (SAN – Storage
Area Net works), lưu tr ữ gắn vào m ạng (NAS – Network-
Attached Storage), h ệ thống phần m ềm, tiện ích, hệ thống sao

48
lưu, tường lửa, m ôi trường phát tri ển và m ôi trư ờng thử
nghiệm , công cụ quản lý, v.v…
 Môi trư ờng: quản lý và kiểm soát tất cả các khía cạnh m ôi
trường của tất cả các phòng thi ết bị chính yếu, bao gồm không
gian vật lý và sơ đ ồ bố trí, nguồn điện, điều hòa không khí, h ệ
thống cáp, an ninh v ật lý, v.v…
 Dữ liệu: quản lý và kiểm soát m ọi dữ liệu và thông tin và
quyền truy c ập tương ứng của nó, bao gồm cả dữ liệu thử
nghiệm nếu có.
 Ứng dụng: quản lý và kiểm soát tất cả các phần m ềm ứng
dụng, bao gồm cả ứng dụng m ua sẵn và phần m ềm ứng dụng
được phát tri ển nội bộ.
3.4 Xác định và ghi nh ận các yêu c ầu và định hướng kinh doanh
CNTT phải lưu giữ thông tin chính xác v ề các yêu cầu và định
hướng kinh doanh n ếu m uốn cung cấp Mục lục Dịch vụ phù hợp nhất
với m ức chất lượng dịch vụ có thể chấp nhận và được liên kết vớ i
nhu cầu kinh doanh. Đ ịnh hướng kinh doanh là con ngư ời, thông t in
và nhiệm vụ hỗ trợ việc hoàn thành các m ục tiêu kinh doanh. Đi ều
này đòi hỏi CNTT phải phát triển và duy trì các m ối quan hệ và trao
đổi thông tin ch ặt chẽ, thường xuyên và thích h ợp để hiểu được các
yêu cầu về vận hành, chiến thuật và chiến lược của doanh nghiệp.
Thông tin này c ần được thu thập và thỏa thuận trong hai lĩnh vực
chính để duy trì s ự liên kết dịch vụ:
 Thông tin về các yêu cầu của các dịch vụ hiện có - những
thay đổi nào s ẽ được yêu cầu đối với các dịch vụ hiện hữu có
liên quan đến:
o Các yêu cầu về cơ sở vật chất và chức năng m ới.
o Những thay đổi trong quy trình nghi ệp vụ, sự phụ thuộc,
các ưu tiên, m ức độ quan trọng và tác đ ộng.
o Những thay đ ổi về khối lượng giao dịch dịch vụ.
o Mức dịch vụ được gia tăng và m ục tiêu được nhắm đến
đối với m ức dịch vụ do định hướng kinh doanh m ới hoặc
bị giảm bớt đối với các dịch vụ cũ, giảm m ức độ ưu tiên
cho những gì đến hạn phải thay thế.
o Các nhu cầu bổ sung về thông tin Quản lý Dịch vụ.
 Thông tin về các yêu cầu đối với các dịch vụ m ới:
o Cơ sở vật chất và chức năng c ần thiết.
o Thông tin quản lý cần thiết và nhu c ầu quản lý.
o Các quy trình nghi ệp vụ được hỗ trợ, sự phụ thuộc, ưu
tiên, m ức độ quan trọng và tác đ ộng.
o Chu k ỳ kinh doanh và s ự thay đổi theo m ùa.
o Yêu cầu m ức dịch vụ và m ục tiêu nhắm đến về m ức dịch
vụ.
o Mức độ giao dịch kinh doanh, m ức độ giao dịch dịch vụ,
số lượng và kiểu người sử dụng và m ức tăng trưởng
được dự kiến trong tương lai
o Lý lẽ biện m inh kinh doanh, bao g ồm các khía c ạnh tài
chính và chi ến lược.

49
o Mức độ thay đổi được dự đoán, ví dụ: yêu c ầu kinh
doanh đã biết trong tương lai ho ặc được nâng cao.
o Mức độ năng lực kinh doanh ho ặc hỗ trợ được cung c ấp,
ví dụ: hỗ trợ dựa trên doanh nghi ệp địa phương.
Việc thu thập thông tin này là giai đo ạn đầu tiên và quan tr ọng nhất
để thiết kế và cung cấp các dịch vụ mới hoặc các thay đổi lớn đối
với các dịch vụ hiện hữu. Nhu c ầu về thông tin chính xác và tiêu
biểu từ doanh nghi ệp là điều tối quan trọng. Điều này phải được
thỏa thuận và ký k ết với những đại diện cấp cao trong doanh nghi ệp.
Nếu thông tin không chính xác ho ặc sai lệch được thu th ập và sử
dụng ở giai đoạn này, thì tất cả các giai đo ạn tiếp theo sẽ cung cấp
các dịch vụ không đáp ứng được nhu cầu của doanh nghi ệp. Ngoài
ra, phải có m ột số quy trình chính th ức để thỏa thuận và ch ấp nhận
các thay đổi đối với các yêu cầu kinh doanh, vì chúng s ẽ thường
xuyên thay đổi và phát triển trong Vòng đời Dịch vụ. Các yêu c ầu và
thiết kế phải phát tri ển cùng với sự thay đổi của m ôi trường kinh
doanh để đảm bảo rằng các k ỳ vọng của doanh nghi ệp được đáp
ứng. Tuy nhiên, đây ph ải là m ột quy trình đư ợc quản lý cẩn thận để
đảm bảo rằng t ốc độ thay đổi được giữ ở m ức đã thỏa thuận và có
thể quản lý được, đồng thời không 'che lấp' và trì hoãn quá m ức dự
án hoặc việc triển khai nó.
Để thiết kế và cung c ấp các dịch vụ CNTT đáp ứng được các nhu
cầu của khách hàng và doanh nghi ệp, các thông s ố kỹ thuật rõ ràng,
ngắn gọn, không m ơ h ồ về các yêu c ầu phải được lập thành văn b ản
và được thỏa thuận. Thời gian dành cho các ho ạt động này s ẽ ngăn
chặn các vấn đề và thảo luận phát sinh sau này liên quan đ ến sự
khác biệt giữa kỳ vọng của khách hàng và c ủa doanh nghi ệp. Giai
đoạn yêu cầu kinh doanh này ph ải bao gồm :
 Bổ nhiệm người quản lý dự án, thành l ập nhóm dự án và thỏ a

thuận cách quản trị dự án bằng cách áp d ụng phương pháp
luận dự án chính th ức, có cấu trúc.
 Xác định tất cả các bên liên quan, bao g ồm tài liệu về tất cả
các yêu c ầu từ tất cả các bên liên quan và nh ững lợi ích của
các bên liên quan mà h ọ sẽ nhận được từ việc triển khai.
 Phân tích yêu c ầu, ưu tiên, th ỏa thuận và ghi nhận tài liệu.
 Xác định và th ống nhất phác thảo ngân sách và lợi ích doanh
nghiệp. Ngân sách ph ải được cam kết bởi cấp quản lý, vì theo
thông lệ là quyết định cho ngân sách c ủa năm tới vào quý cu ối
cùng của năm trước đó, vì vậy m ọi kế hoạch phải được đệ
trình trong chu k ỳ này.
 Giải quyết xung đột tiềm ẩn giữa các đơn vị kinh doanh và
thỏa thuận về các yêu c ầu của công ty.
 Các quy trình ký k ết đối với các yêu c ầu đã được thỏa thuận
và phương pháp đ ể đồng ý và chấp nhận các thay đ ổi đối với
các yêu cầu đã thỏa thuận. Thông thư ờng, quy trình cho vi ệc
phát triển các yêu cầu là phương pháp ti ếp cận lặp đi lặp lại
hoặc tăng dần cần được kiểm soát m ột cách cẩn thận để quản
lý việc ‘m ất phạm vi kiểm soát’.

50
 Phát triển m ột kế hoạch gắn kết khách hàng, phác thảo các
m ối quan h ệ chính giữa CNTT và doanh nghi ệp và cách thức
các m ối quan hệ này và giao ti ếp cần thiết với các bên liên
quan rộng lớn hơn sẽ được quản lý như th ế nào.
Khi các yêu cầu về dịch vụ được quan tâm , chúng đôi khi đi kèm v ới
m ột thẻ gắn giá (có thể không được biết đến hoàn toàn ở giai đoạn
này), vì vậy luôn cần phải có sự cân bằng giữa dịch vụ có thể đạt
được và chi phí. Đi ều này có thể có nghĩa là m ột số yêu cầu có thể
quá tốn kém để bao gồm và có th ể phải loại bỏ trong quá trình đánh
giá tài chính liên quan trong quá trình thi ết kế. Nếu điều này là c ầ n
thiết, tất cả các quyết định loại bỏ bất kỳ yêu cầu dịch vụ nào khỏ i
thiết kế của dịch vụ phải được lập thành văn b ản và được thỏa
thuận với các đại diện của doanh nghi ệp. Thường thì s ẽ gặp khó
khăn khi những gì doanh nghi ệp m uốn và ngân sách được phân b ổ
cho giải pháp không tính đ ến toàn bộ chi phí dịch vụ, bao gồm cả chi
phí liên tục.
3.5 Các hoạt động thi ết kế

Mọi hoạt động thiết kế được kích hoạt bởi những thay đổi trong nhu
cầu kinh doanh h oặc cải thiện dịch vụ. Một phương pháp ti ếp cận
toàn diện và có c ấu trúc đối với các hoạt động thiết kế nên được áp
dụng, để từ đo m ọi thông tin có s ẵn được xem xét đ ể đảm bảo tính
nhất quán và toàn v ẹn sẽ đạt được trong toàn b ộ tổ chức nhà cung
cấp dịch vụ CNTT, trong m ọi hoạt động thiết kế.
Những kiến trúc và thi ết kế nên được lưu gi ữ, rõ ràng, ng ắn gọn,

đơn giản và phù h ợp. Thông thường, các thi ết kế và kiến trúc là
phức tạp và m ang tính lý thuy ết và không liên quan t ới ‘thế giới
thực’.
Vấn đề chính hiện nay là các t ổ chức thường chỉ tập trung vào các
yêu cầu về chức năng. Một thiết kế hoặc kiến trúc theo định nghĩa
cần phải xem xét về m ọi khía c ạnh thiết kế. Nó không ph ải là m ột tổ
chức nhỏ hơn kết hợp những khía cạnh này, nó là m ột tổ chức hợp
lý.
Các hoạt động của quá trình thiết kế bao gồm :
 Thu thập, phân tích và thi ết kế các yêu c ầu để đảm bảo rằng
các yêu c ầu kinh doanh được lập thành văn b ản m ột cách rõ
ràng và được thỏa thuận.
 Thiết kế các dịch vụ, công nghệ, quy trình, thông tin và thư ớc
đo quy trình thích h ợp để đáp ứng các yêu cầu kinh doanh.
 Xem xét và s ửa đổi tất cả các quy trình và tài li ệu liên quan
đến Thiết kế Dịch vụ, bao gồm các thi ết kế, các kê ho ạch, kiến
trúc và chính sách.
 Liên lạc với tất cả các hoạt động và vai trò thi ết kế và hoạch
định khác, ví d ụ: thiết kế giải pháp.
 Xuất bản và duy trì các chính sách CNTT và tài li ệu thiết kế,
bao gồm các thiết kế, kế hoạch, kiến trúc và chính sách.

51
 Sửa đổi tất cả các tài liệu thiết kế và hoạch định việc triển
khai và thực hiện các chiến lược CNTT bằng cách s ử dụng các
'lộ trình', chương trình và k ế hoạch dự án.
 Đánh giá r ủi ro và qu ản lý t ất cả các quy trình thiết kế và các
sản phẩm có thể chuyển giao được.
 Đảm bảo sự liên kết với tất cả các chiến lược và chính sách
của công ty và CNTT.
Các yếu tố đầu vào cho các ho ạt động thiết kế khác nhau là:
 Tầm nhìn, chi ến lược, m ục tiêu, chính sách và k ế hoạch của
công ty, các t ầm nhìn, chi ến lược, m ục tiêu và kế hoạch trong
kinh doanh, bao gồm cả Kế hoạch Liên tục trong Kinh doanh
(BCP).
 Các ràng buộc và yêu c ầu đối với việc tuân thủ các tiêu chuẩn
và quy định của pháp luật.
 Các chiến lược CNTT và các tài li ệu chiến lược (từ Chiến lược
dịch vụ):
o Tất cả các chiến lược, chính sách và k ế hoạch chiến
lược CNTT.
o Chi tiết của các yêu cầu kinh doanh.
o Tất cả ràng buộc, ngân sách và k ế hoạch tài chính.
o Danh m ục Dịch vụ.
o Tầm nhìn, chi ến lược, chính sách, m ục tiêu và kế hoạch
Quản lý Dịch vụ.
o Các quy trình, r ủi ro và s ự cố Quản lý Dịch vụ và CNTT
được ghi nhận.
o Các kế hoạch Chuy ển tiếp Dịch vụ (các Kế hoạch Quản
lý Thay đổi, Cấu hình và Phiên bản và Triển khai).
o Các chính sách, s ổ tay và k ế hoạch bảo m ật.
o Chính sách m ua s ắm và hợp đồng, chiến lược nhà cung
cấp và các quy tringh Qu ản lý Nhà cung cấp.
o Kiến thức, kỹ năng và năng lực của nhân viên hiện tại.
o Các k ế hoạch kinh doanh CNTT, K ế hoạch Chất lượng
CNTT và Doanh nghi ệp và các chính sách.
o Các k ế hoạch Quản lý Dịch vụ, bao gồm các K ế hoạch
Quản lý Mức Dịch vụ, SLAs và SLRs, K ế hoạch Cải tiến
Dịch vụ (SIP), Kế hoạch Công su ất, Kế hoạch Tính sẵ n
sàng, K ế hoạch Liên tục Dịch vụ CNTT.
 Các công cụ và kỹ thuật đo lường.
Những sản phẩm có thể bàn giao được của các hoạt động thiết kế
bao gồm :
 Những sửa đổi được đề nghị đối với các chiến lược và chính
sách CNTT.
 Các thiết kế, kế hoạch và kiến trúc quản lý và công ngh ệ được
điều chỉnh, bao gồm :
o Cơ sở hạ tầng CNTT và quản lý cơ sở hạ tầng và chiế n
lược, thiết kế, kế hoạch, kiến trúc và chính sách m ôi
trường.
o Các chiến lược, thiết kế, kế hoạch, kiến trúc và chính
sách về ứng dụng và dữ liệu.

52
 Các thiết kế cho các dịch vụ, quy trình và công ngh ệ m ới hoặc
được thay đổi.
 Các báo cáo phân tích và đánh giá quy trình, cùng v ới các quy
trình và thủ tục được điều chỉnh và cải thiện.
 Các phương pháp và quy trình đo lư ờng đã được điều chỉnh.
 Mức độ rủi ro được quản lý, và các báo cáo đánh giá và qu ản
lý rủi ro.
 Các đề án kinh doanh và nghiên c ứu tiền khả thi, cung với
Tuyên bố về các Yêu cầu (Statem ents of Requirem ents -
SORs) và Thư m ời Thầu (Invitations to Tender – ITTs).
 Các bình lu ận và phản hồi về tất cả các kế hoạch khác.
 Những lợi ích c ủa doanh nghi ệp và đánh giá và báo cáo v ề sự
thực thi.
3.6 Cơ sở nền tảng của Chiến lược Dịch vụ

Một phương pháp ti ếp cận tổng thể và được tích hợp nên đư ợc áp
dụng cho các hoạt động thiết kế đã được ghi nhận lại trong phần
trước đó và nên bao g ồm thiết kế của:
 Các giải pháp d ịch vụ, bao gồm m ọi yêu c ầu về chức năng, tài
nguyên và năng l ực cần thiết và được thỏa thuận.
 Các công c ụ và hệ thống Quản lý Dịch vụ, đặc biệt là Danh
m ục Dịch vụ để quản lý và ki ểm soát các d ịch vụ trong suốt
vòng đời của chúng.
 Các kiến trúc công ngh ệ và kiến trúc quản lý và công c ụ cần
thiết để cung c ấp các dịch vụ.
 Các quy trình cần thiết để thiết kế, chuyển tiếp, vận hành và
cải thiện các dịch vụ.
 Các hệ thống, phương pháp và ch ỉ số đo lường đới với các
dịch vụ, các kiến trúc và các thành ph ần cấu thành c ủa chúng
và các quy trình.
Khía cạnh chủ yếu là việc thiết kế các giải pháp dịch vụ mới hoặc
được thay đổi để đáp ứng các nhu c ầu kinh doanh. Mỗi khi m ột giải
pháp dịch vụ m ới được đưa ra, nó c ần được kiểm tra từng khía c ạnh
m ột để đảm bảo rằng nó s ẽ tích hợp và giao ti ếp với mọi dịch vụ
khác đang thực sự hiện hữu. Năm khía c ạnh Thiết kế Dịch vụ này
được bao hàm chi ti ết hơn trong nh ững phần sau. Các kế hoạch
được đưa ra bởi Thiết kế Dịch vụ cho thiết kế, chuyển tiếp và vận
hành tiếp theo c ủa năm khía c ạnh khác nhau này nên bao g ồm :
 Phương pháp ti ếp cận đã tiến hành và khoảng thời gian tương
ứng.
 Tác động đến tổ chức của giải pháp m ới hoặc đã được thay
đổi đối với cả doanh nghiệp và CNTT.
 Tác động thương m ại của giải pháp đối với tổ chức, bao gồm
vốn, chi phí và ngân sách c ần thiết.
 Tác động về kỹ thuật của giải pháp và nhân viên và vai trò,
trách nhiệm , kỹ năng, kiến thức, đào tạo và năng lực cần thiết
của họ để triển khai, vận hành, duy trì và t ối ưu hóa giải pháp
mới cho doanh nghi ệp.
 Đánh giá biện m inh thương m ại cho tác động của giải pháp đối
với việc kinh doanh hi ện hữu – tác động này phải được đánh

53
giá từ quan điểm của các quy trình CNTT và Qu ản lý Dịch vụ,
bao gồm cả công suất và hiệu suất của chúng.
 Đánh giá và gi ảm thiểu rủi ro đối với các dịch vụ, quy trình và
các hoạt động Quản lý Dịch vụ.
 Lập kế hoạch truyền thông và m ọi khía cạnh của truyền thông
với tất cả các bên có liên quan.
 Tác động của giải pháp đến các hợp đồng hoặc thỏa thuậ n
mới hoặc đang hiện hữu.
 Những kết quả được kỳ vọng từ việc vận hành dịch vụ mới
hoặc được thay đổi theo các đi ều kiện có thể đo lường được,
thường được thể hiện trong các Th ỏa thuận Mức Dịch vụ
(SLAs) m ới hoặc đang hiện hữu, các m ức dịch vụ và sự hài
lòng của khách hàng.
 Sản xuất m ột Gói Thiết kế Dịch vụ (SDP – xem Phụ lục A)
chứa m ọi thứ cần thiết cho việc kiểm nghiệm , giới thiệu và vận
hành sau đó c ủa giải pháp hoặc dịch vụ.
 Sản xuất m ột bộ Tiêu chí Ch ấp thuận Dịch vụ (SAC) (xem Ph ụ
lục B) sẽ được sử dụng để đảm bảo rằng nhà cung c ấp dịch vụ
sẵn sàng đ ể cung cấp và hỗ trợ dịch vụ m ới hoặc được thay
đổi trong m ôi trường thật.
3.6.1 Thiết kế các giải pháp dịch vụ

Có rất nhiều hoạt động phải được hoàn thành trong giai đo ạn Thiết
kế Dịch vụ đối với m ột dịch vụ m ới hoặc được thay đổi. Một phương
pháp tiếp cận chính thức và có c ấu trúc là c ần thiết để đưa ra được
dịch vụ m ới với chi phí, chức năng, chất lượng phù hợp và trong
phạm vi khuôn khổ thời gian thích h ợp. Quy trình n ày và các giai
đoạn cấu thành của nó được m inh họa trong Hình 3.5, cùng v ới các
lĩnh vực chủ yếu khác cần được liên quan t ới trong quy trình. Quy
trình này phải đưuọc lặp đi lặp lại/gia tăng nh ằm đảm bảo rằng dịc h
vụ đã cung c ấp đáp ứng được các nhu cầu đang phát tri ển và thay
đổi của doanh nghi ệp trong vi ệc phát triển quy trình nghi ệp vụ và
Vòng đời Dịch vụ CNTT. Ngoài ra, các nhà qu ản lý và nhóm dự án
có thể cần được phân b ổ để quản lý các giai đo ạn trong vòng đời đối
với việc triển khai dịch vụ m ới.
Vai trò của nhóm dự án trong ho ạt động này trong vi ệc cung c ấp các
dịch vụ CNTT m ới và thay đổi cho doanh nghiệp và m ối quan h ệ củ a
mình cho các ho ạt động thiết kế được minh họa trong Hình 3.5.

54
Hình 3.5 – Sự liên kết giữa các dịch vụ mới với các yêu cầu kinh
doanh
Hình 3.5 cho th ấy vòng đời của m ột dịch vụ từ yêu cầu kinh doanh
khởi đầu hoặc được thay đổi qua các giai đo ạn thiết kế, chuyển tiế p
và vận hành c ủa vòng đời. Điều quan trọng là phải có sự chuyển
giao kiến thức ở mọi giai đoạn giữa nhân viên vận hành và nhân
viên dự án để đảm bảo tiến trình suôn sẻ qua từng giai đo ạn đã
được m inh họa.
Các lĩnh vực cần được xem xét trong thi ết kế giải pháp dịch vụ nên
bao gồm :
 Phân tích các yêu c ầu kinh doanh đã đư ợc thỏa thuận.

 Xem xét các các d ịch vụ và cơ sở hạ tầng CNTT hi ện hữu và
đưa ra gi ải pháp dịch vụ thay thế, với quan điểm tái sử dụng
hoặc khai thác các thành và d ịch vụ hiện hữu nếu có thể.
 Thiết kế các giải pháp dịch vụ m ới đối với các yêu c ầu mới,
bao gồm các thành ph ần cấu thành chúng, xét v ề các m ặt dưới
đây, và ghi nh ận lại thiết kế này:
o Các phương ti ện và chức năng c ần thiết, và thông tin
được yêu c ầu đối với việc giám sát hi ệu suất của dịch vụ
hoặc quy trình.
o Các quy trình nghi ệp vụ được hỗ trợ, các phụ thuộc,
m ức ưu tiên, t ầm quan tr ọng và tác động của dịch vụ,
cùng với những lợi ích cho doanh nghi ệp sẽ được cung
cấp bởi dịch vụ.

55
o Các chu k ỳ kinh doanh và thay đ ổi theo m ùa, và các m ức
giao dịch kinh doanh liên quan, m ức giao dịch dịch vụ,
số lượng và kiểu người sử dụng và sự tăng trưởng được
dự báo trong tương lai, và các yêu c ầu liên tục kinh
doanh.
o Các Yêu cầu Mức Dịch vụ và đích nh ắm m ục tiêu về m ức
dịch vụ và các hoạt động đo lư ờng, báo cáo và đánh giá
dịch vụ cần thiết.
o Những khung thời gian liên quan và các k ết quả đã được
lên kế hoạch từ dịch vụ m ới và tác động lên bất kỳ dịch
vụ hiện hữu nào.
o Các yêu cầu về kiểm nghiệm , bao gồm bất kỳ Kiểm
nghiệm Chấp thuận Người sử dụng (UAT) nào và trách
nhiệm cho vi ệc quản lý các kết quả kiểm nghiệm .
 Đảm bảo rằng nội dung c ủa Tiêu chí Chấp thuận Dịch vụ
(SAC) được kết hợp chặt chẽ và những thành t ựu cần thiết đã
được lên kế hoạch trong thi ết kế ban đầu.
 Đánh giá và thi ết kế chi phí cho giải pháp thay th ế, làm nổi bật
ưu điểm cũng như khuy ết điểm của các giải pháp thay th ế.
 Thỏa thuận về chi tiêu và ngân sách.
 Đánh giá lại và xác nhận về những lợi ích cho doanh nghi ệp,
bao gồm Lợi nhuận Đầu tư (RoI) từ các dịch vụ, bao gồm việc
xác định và đ ịnh lượng m ọi chi phí d ịch vụ và m ọi lợi ích cho
doanh nghi ệp và doanh thu đã gia tăng. Chi phí nên bao g ồm
Tổng Chi phí Sở hữu (TCO) c ủa dịch vụ, ngân sách d ự án, và
m ọi chi phí vận hành liên t ục bao gồm quản lý, hỗ trợ và duy
trì.
 Thỏa thuận về giải pháp được yêu thích và nh ững kết quả đã
được lên kế hoạch của nó và m ục tiêu nhắm đến (Yêu cầ u
Mức Dịch vụ - (SLR)).
 Kiểm tra giải pháp trong sự cân bằng với m ọi chiến lược,
chính sách, k ế hoạch và tài li ệu kiến trúc c ủa công ty và
CNTT. Nếu không, hãy đi ều chỉnh hoặc là giải pháp ho ặc tài
liệu chiến lược (có tính đ ến ảnh hưởng lên các tài li ệu chiến
lược, dịch vụ và thành ph ần khác) nếu có thể, tái s ử dụng
hoặc khai thác các thành ph ần hiện có (ví dụ, các đối tượng
phần m ềm , dữ liệu ‘thuộc tập thể’, phần cứng), trừ khi chiến
lược tuyên bố ngược lại. Sự thay đổi trong chiến lược sẽ liên
quan tới m ột lượng công việc đáng kể và sẽ được hoàn thành
trong m ối liên k ết với Chiến lược Dịch vụ.
 Đảm bảo rằng m ọi quản trị CNTT và công ty và các bi ện pháp
kiểm soát bảo m ật được bao gồm trong gi ải pháp.
 Hoàn thành m ột ‘đánh giá s ự sẵn sàng của tổ chức’ về CNTT
để đảm bảo rằng dịch vụ có thể được vận hành để đáp ứng
các đích nh ắm mục tiêu đã được thỏa thuận và rằng t ổ chức
có được năng l ực thích hợp để cung cấp m ức đã thỏa thuận.
Điều này sẽ bao gồm:
o Tác động thương m ại đối với tổ chức từ quan điểm
doanh nghiệp lẫn CNTT, bao g ồm m ọi lợi ích cho d oanh
nghiệp và m ọi chi phí (c ả chi phí dự án m ột lần lẫn chi

56
phí vận hành đang tiếp diễn) liên quan t ới thiết kế, phát
triển và vận hành đang ti ếp diễn và hỗ trợ của dịch vụ.
o Đánh giá và gi ảm thiểu rủi ro tương ứng với dịch vụ m ới
hoặc được thay đổi, đặc biệt là liên quan đến vận hành,
bảo m ật, tính s ẵn sàng và liên t ục của dịch vụ.
o Năng lực và sự trưởng thành c ủa doanh nghi ệp. Hoạt
động này nên đư ợc hoàn thành bởi chính b ản thân
doanh nghi ệp để đảm bảo rằng m ọi quy trình, c ấu trúc,
con người, vai trò, trác h nhiệm và phương ti ện phù hợ p
là có s ẵn để vận hành dịch vụ m ới.
o Năng lực và sự trưởng thành c ủa CNTT:
 Môi trường và m ọi lĩnh vực về công nghệ, có cân
nhắc đến tác động của các thành ph ần đang hi ện
hữu của cơ sở hạ tầng và các d ịch vụ sẵn có.
 Cơ cấu tổ chức CNTT và vai trò và trách nhi ệm .
 Các quy trình CNTT và tài li ệu văn bản của chúng.
 Kỹ năng, kiến thức và năng lực của nhân viên.
 Các quy trình và công c ụ hỗ trợ quản lý CNTT.
 Các thỏa thuận nhà cung cấp và thỏa thuận hỗ trợ cần thiết
để duy trì và cung cấp dịch vụ.
 Tổ hợp m ột Gói Thi ết kế Dịch vụ (SDP) cho việc chuyển tiếp,
vận hành và c ải thiện tiếp theo c ủa giải pháp dịch vụ m ới hoặc
được thay đổi.
3.6.2 Thiết kế các hệ thống hỗ trợ, đặc biệt là Danh mục Dịch vụ
Cách hiệu quả nhất để quản lý m ọi khía c ạnh của các dịch vụ trong
suốt vòng đời của chúng là b ằng cách s ử dụng các hệ thống và công
cụ thích hợp để hỗ trợ và duy trì và t ự động hóa các quy trình c ó
hiệu quả. Danh m ục Dịch vụ là hệ thống quan tr ọng bậc nhất được
sử dụng để hỗ trợ m ọi quy trình và mô tả các dịch vụ của nhà cung
cấp dịch vụ về m ặt giá trị đối với doanh nghiệp. Nó m ô tả rõ ràng
các nhu cầu của doanh nghi ệp và sự ứng phó của nhà cung cấp với
những nhu cầu này. Theo đ ịnh nghĩa, khái ni ệm giá tr ị doanh nghiệp
tương ứng với khái ni ệm thị trường, cung c ấp m ột phương ti ện s o
sánh tính c ạnh tranh c ủa dịch vụ so với các nhà cung c ấp thay th ế
khác. Bằng cách đóng vai trò như là cơ s ở của khuôn khổ ra quyết
định, m ột Danh m ục Dịch vụ hoặc làm rõ ho ặc giúp làm rõ nh ững
câu hỏi chiến lược dưới đây:
 Tại sao m ột khách hàng nên m ua nh ững dịch vụ này?
 Tại sao họ nên m ua nh ững dịch vụ này từ bạn?
 Những m ô hình đ ịnh giá hoặc hoàn phí là gì?
 Những điểm m ạnh, điểm yếu, m ức ưu tiên và r ủi ro c ủa tôi là
gì?
 Những nguồn lực và năng lực của tôi nên được phân bổ như
thế nào?
Hãy xem Hình 3.6. M ột cách lý tưởng, Danh m ục Dịch vụ nên định
hình m ột phần của m ột Hệ thống Quản lý Kiến thức Dịch vụ (SKMS)
toàn diện và được đăng ký như là m ột tài liệu trong Qu ản lý Cấu
hình (CMS). Thông tin thêm v ề cả CMS lẫn SKMS được cung c ấp
trong ấn phầm Chuyển tiếp Dịch vụ.

57
Hình 3.6 là m ột m ô tả về m ối quan hệ giữa Danh m ục Dịch vụ và
SKMS.
Hình 3.6 – Danh mục Dịch vụ - một kho lưu trữ tập trung
Khi m ột quyết định chiến lược để tuyên bố m ột dịch vụ được đưa ra,
đây là giai đo ạn trong Vòng đời Dịch vụ khi m à Thiết kế Dịch vụ bắt
đầu kiến tạo dịch v ụ, vốn cuối cùng sẽ trở thành m ột phần của Mục
lục Dịch vụ. Danh m ục Dịch vụ nên bao gồm những thông tin liên
quan đến m ọi dịch vụ và tình trạng hiện tại của nó trong tổ chức.
Các lựa chọn về tình trạng trong Danh m ục Dịch vụ nên bao g ồm :
 Các yêu cầu: m ột bộ phác thảo các yêu c ầu đã nhận được từ

doanh nghi ệp hoặc CNTT về m ột dịch vụ m ới hoặc được thay
đổi.
 Đã xác định: m ột bộ các yêu c ầu đối với dịch vụ m ới đang
được đánh giá, xác định và ghi nhận lại và SLR s ẽ được đưa
ra.
 Đã phân tích : bộ các yêu c ầu đối với dịch vụ m ới đang được
phân tích và thi ết lập độ ưu tiên.
 Đã phê du yệt: bộ các yêu c ầu đối với dịch vụ m ới đã được
hoàn thành và c ấp phép.
 Đã tu yên bố: các yêu c ầu dịch vụ m ới đang được truyền thông
và các tài nguyên và ngân sách đư ợc phân bổ.
 Đã thi ết kế: dịch vụ m ới và các thành ph ần cấu thành c ủa nó
đang được thiết kế - và m ua sắm , nếu cần thiết.
 Đã phát triển: dịch vụ và các thành phần cấu thành của nó
đang được phát triển hoặc thu hoạch, nếu có thể.

58
 Đã xây dựng: dịch vụ và các thành phần cấu thành c ủa nó
đang được xây dựng.
 Kiểm nghiệm: dịch vụ và các thành phần cấu thành c ủa nó
đang được kiểm nghiệm
 Đã phát hành : dịch vụ và các thành ph ần cấu thành c ủa nó
đang được phát hành.
 Vận hành: dịch vụ và các thành ph ần cấu thành c ủa nó đang
vận hành trong m ôi trư ờng thật.
 Ngừng hoạt động: dịch vụ và các thành phần cấu thành của
nó đã ngừng hoạt động.
Do đó, Danh m ục Dịch vụ sẽ bao gồm chi tiết về m ọi dịch vụ và tình

trạng của chúng liên quan đến giai đoạn hiện tại trong Vòng đ ời Dịch
vụ, như được m inh họa trong Hình 3.7.
Hình 3.7 – Danh mục Dịch vụ và nội dung của nó

59
Khách hàng và ngư ời sử dụng sẽ chỉ được phép truy cập vào các
dịch vụ trong Danh m ục Dịch vụ có trạng thái nằm giữa ‘đã tuyên bố’
và ‘đang ho ạt động’, như được m inh họa bằng ô trong Hình 3.7, t ức
là những dịch vụ có trong Danh m ục dịch vụ. Những cá nhân Thi ết
kế Dịch vụ và Chiến lược Dịch vụ sẽ cần quyền truy c ập vào tất cả
các hồ sơ trong Danh m ục Dịch vụ, cũng như các lĩnh vực quan
trọng khác như Qu ản lý Thay đ ổi. Các thành viên khác c ủa t ổ chức
cung cấp dịch vụ sẽ có quyền truy c ập vào m ột tập hợp con đã được
cấp phép c ủa các hồ sơ trong Danh m ục Dịch vụ. Mặc dù Danh m ục
Dịch vụ được thiết kế bởi Thiết kế Dịch vụ nhưng nó được sở hữu
và quản lý bởi Chiến lược Dịch vụ trong quy trình Quản lý Danh m ục
Dịch vụ. Chi tiết đầy đủ về Quản lý Danh m ục Dịch vụ đã được thảo
luận trong ấn phẩm Chiến lược Dịch vụ.
Đường ống Dịch vụ là m ột tập hợp con của Danh m ục Dịch vụ tổng
thể và chứa đựng những thông tin chi ti ết về tất cả các yêu c ầu kinh
doanh chưa trở thành các dịch vụ được phát hành ra m ôi trư ờng
thật. Nó được sử dụng làm cơ sở cho việc xác định, phân tích, thiết
lập độ ưu tiên và phê duy ệt, bởi ISG và Chi ến lược dịch vụ, đối với
tất cả các yêu c ầu về dịch vụ m ới hoặc đã được thay đổi, để đảm
bảo rằng các dịch vụ m ới và đã được thay đổi đều được liên k ết với
yêu cầu doanh nghi ệp. Về cơ bản, nó s ẽ được sử dụng làm đầu vào
cho các hoạt động của các giai đo ạn Chiến lược dịch vụ và Thiết kế
Dịch vụ của Vòng đ ời Dịch vụ. Nó cũng cung c ấp đầu vào có giá tr ị
cho các hoạt động của giai đo ạn Chuyển tiếp Dịch vụ của vòng đời
trong việc xác định các d ịch vụ sẽ được phát hành. Quy trình Qu ản
lý Danh m ục Dịch vụ phải đảm bảo rằng m ọi chi tiết trong Danh m ục
Dịch vụ là chính xác và đư ợc cập nhật theo yêu c ầu và dịch vụ m ới
hoặc đã được thay đổi của nó được chuyển tiếp vào môi trường
thật. Điều này sẽ liên quan đ ến m ối liên hệ chặt chẽ với tất cả các
hoạt động Chuyển tiếp Dịch vụ.
Các phần tử khác nhau của cùng m ột dịch vụ có thể có các tr ạng
thái khác nhau t ại cùng m ột thời điểm. Nếu không, Danh m ục Dịch
vụ sẽ không thể hỗ trợ sự phát triển ‘gia tăng và lặp đi lặp lại’. Mỗi
tổ chức nên thiết kế m ột cách cẩn thận Danh m ục Dịch vụ của m ình,
nội dung và quyền truy c ập được phép vào n ội dung. Nội dung nên
bao gồm :
 Tên Dịch vụ,

 Mô tả Dịch vụ,
 Tình trạng của Dịch vụ,
 Phân loại và m ức độ quan trọng của Dịch vụ,
 Các ứng dụng được sử dụng,
 Dữ liệu và/hoặc đồ án dữ liệu được sử dụng,
 Các quy trình nghiệp vụ được hỗ trợ,
 Chủ sở hữu doanh nghiệp,
 Người sử dụng của doanh nghiệp,
 Các chủ sở hữu của CNTT,
 Mức đảm bảo dịch vụ, các tham chiếu SLA và SLR,
 Các dịch vụ hỗ trợ,

60
 Các nguồn lực hỗ trợ,
 Các dịch vụ phụ thuộc,
 Các OLAs, hợp đồng và thỏa thuận hỗ trợ,
 Chi phí dịch vụ,
 Phí dịch vụ (nếu có),
 Doanh thu d ịch vụ (nếu có),
 Các chỉ số dịch vụ.
Danh m ục Dịch vụ là nguồn thông tin chủ yếu về các yêu c ầu và dịch
vụ và nhu c ầu cần được thiết kế m ột cách rất cẩn thận để đáp ứng
m ọi nhu cầu của mọi người sử dụng của nó. Thiết kế của Danh m ục
Dịch vụ cần được xem xét theo cùng m ột cách với thiết kế của bất
kỳ dịch vụ CNTT nào để đảm bảo rằng nó đáp ứng m ọi nhu cầu đó.
Phương pháp tiếp cận này cũng nên đư ợc sử dụng cho m ọi hệ thống
thông tin Quản lý Dịch vụ khác, bao g ồm:
 Hệ thống Quản lý Kiến thức Dịch vụ (SKMS),

 Quản lý Cấu hình (CMS),
 Hệ thống Bộ phận Hỗ trợ Dịch vụ,
 Hệ thống Thông tin Quản lý Công su ất (CMIS),
 Hệ thống Thông tin Quản lý Tính s ẵn sàng (AMIS),
 Hệ thống Thông tin Quản lý Bảo m ật (SMIS),
 Cơ sở dữ liệu Hợp đồng và Nhà cung c ấp (SCD).
3.6.3 Thiết kế các kiến trúc công ngh ệ

Các hoạt động thiết kế kiến trúc trong m ột tổ chức CNTT liên quan
tới việc cung cấp ‘bản thiết kế’ chiến lược tổng thể cho việc phát
triển và triển khai m ột cơ sở hạ tầng CNTT – m ột bộ các ứng dụng
và dữ liệu thỏa m ãn những nhu cầu hiện tại và tương lai c ủa doanh
nghiệp. Mặc dù những khía cạnh này là cơ sở cung cấp chất lượng
dịch vụ, m ột m ình chúng không th ể cung cấp được chất lượng dịch
vụ, và m ột điều thiết yếu là những khía c ạnh con ngư ời, quy trình
và/hoặc đối tác/nhà cung c ấp xoay quanh những thành phần công
nghệ đó (các s ản phẩm ) cũng nên được xem xét.
‘Kiến trúc’ là m ột thuật ngữ được sử dụng trong r ất nhiều bối cảnh.
Trong bối cảnh này, nó đư ợc định nghĩa là:
Nền tảng t ổ chức của m ột hệ thống, được thể hiện trong các thành
phần của nó, các m ối quan hệ của chúng đ ối với nhau và đối với m ôi
trường, và những nguyên t ắc hướng dẫn thiết kế và phát tri ển của
nó.
‘Hệ thống’ trong định nghĩa này được sử dụng theo nghĩa chung
nhất, không nhất thiết phải là CNTT, nghĩa là:
‘m ột tập hợp các thành phần được tổ chức để hoàn thành m ột chức
năng hoặc m ột bộ các chức năng c ụ thể’.
Do đó hệ thống có thể là, ví dụ, m ột tổ chức toàn thể, m ột chức

năng nghiệp vụ, m ột dây chuyền sản xuất hoặc m ột hệ thống thông

61
tin. Mỗi m ột hệ thống đó sẽ có m ột ‘kiến trúc’ như được định nghĩa ở
trên, được cấu thành từ các thành phần của hệ thống, các m ối quan
hệ giữa chúng (ch ẳng hạn như các giao diện và trao đổi thông tin),
các m ối quan hệ giữa hệ thống và m ôi trường của nó (chính tr ị, tổ
chức, công ngh ệ, v.v…) và các nguyên t ắc thiết kế cung cấp, hướng
dẫn và ràng buộc cấu trúc và ho ạt động của nó, cũng như là s ự phát
triển trong tương lai c ủa nó.
Về bản chất, thiết kế kiến trúc có th ể được định nghĩa là:
‘Sự phát triển và duy trì của các chính sách, chi ến lược, kiến trúc,
thiết kế, tài liệu, kế hoạch và quy trình CNTT cho s ự triển khai và
vận hành và cải thiện tiếp theo sau đó c ủa các dịch vụ và giải pháp
CNTT tương xứng trong toà n bộ m ột tổ chức’.
Công việc thiết kế kiến trúc cần đánh giá và đi ều giải rất nhiều loại
nhu cầu, m ột số trong chúng có th ể sẽ xung đột với nhu cầu khác.
Công việc nên đảm bảo rằng:
 Cơ sở hạ tầng, m ôi trường, dữ liệu, ứng dụng và các d ịch vụ

CNTT bên ngoài ph ục vụ cho nhu c ầu của doanh nghi ệp, các
sản phẩm và dịch vụ của nó. Hoạt động này không ch ỉ bao
gồm các thành ph ần công nghệ m à còn vi ệc quản lý chúng.
 Sự cân bằng thích hợp được đưa ra giữa sáng tạo, rủi ro và
chi phí trong khi tìm ki ếm ngưỡng cạnh tranh, nơi m à doanh
nghiệp m ong m uốn.
 Có sự tuân thủ các khuôn kh ố, chiến lược, chính sách, lu ật lệ
và tiêu chu ẩn kiến trúc có liên quan.
 Một giao di ện phối hợp được cung cấp giữa các nhà thiết kế
và hoạch định CNTT, các nhà chi ến lược, các nhà thiết kế và
hoạch định doanh nghi ệp.
Các hoạt động thiết kế kiến trúc nên sử dụng đầu vào từ doanh
nghiệp, Chiến lược Dịch vụ, các kế hoạch, nhà thiết kế và hoạch
định của nó để phát triển các thiết kế, kế hoạch, kiến trúc và chính
sách phù hợp cho t ất cả các lĩnh vực CNTT. Các thi ết kế, kế hoạch,
kiến trúc và chính sách này nên bao gồm mọi khía c ạnh của CNTT,
bao gồm vai trò và trách nhi ệm , dịch vụ, công nghệ, kiến trúc và
khuôn khổ, các quy trình và th ủ tục, đối tác và nhà cung c ấp và các
phương pháp qu ản lý. Quy trình thi ết kế kiến trúc cũng phải bao
gồm m ọi lĩnh vực về công nghệ, bao gồm cơ sở hạ tầng, m ôi trường,
ứng dụng và dữ liệu và được liên k ết chặt chẽ với các quy trình thi ết
kế và hoạch định doanh nghi ệp tổng thể.
Bất kỳ doanh nghiệp nào cũng là m ột hệ thống phức tạp, với nhiều
loại thành phần bao gồm đội ngũ nhân viê n, các chức năng và quy
trình nghiệp vụ, cơ cấu tổ chức và phân phối vật chất, nguồn thông
tin và hệ thống thông tin, tài chính và các ngu ồn lực khác bao gồm
công nghệ và các chi ến lược, kế hoạch, quản lý, chính sách c ấu trúc
quản trị định hướng cho doanh nghiệp. Một Kiến trúc Doanh nghi ệp
nên chỉ ra cách tất cả các thành ph ần này (và những thành ph ần

62
khác) được tích hợp nhằm đạt được các m ục tiêu kinh doanh, c ả
hiện tại và trong tương lai, như th ế nào.
Kiến trúc Doanh nghi ệp hoàn chỉnh có thể lớn và phức tạp. Ở đây
chúng tôi chỉ quan tâm đến những kiến trúc liên quan đến hoạt động
kinh doanh của tổ chức và các hệ thống thông tin h ỗ trợ nó. Mỗi kiến
trúc này đòi hỏi các lĩnh vực kiến trúc và lĩnh vực chuyên m ôn riêng
biệt, như được m inh h ọa trong Hình 3.8.
Hình 3.8 – Kiến trúc Doanh nghi ệp
Kiến trúc Doanh nghi ệp theo định nghĩa của Gartner là:
‘quá trình di ễn giải tầm nhìn và chi ến lược của doanh nghiệp
thành những thay đổi hiệu quả, bằng cách tạo ra, truyền đạt và cải
thiện các nguyên t ắc và m ô hình chủ yếu m ô tả trạng thái trong
tương lai c ủa doanh nghi ệp và cho phép sự phát triển của nó’.
Có rất nhiều khuôn kh ổ độc quyền và không độc quyền đối với sự
phát triển m ột Kiến trúc Doanh nghi ệp như được m inh họa trong
Bảng 3.1.

63
Tên đ ầ y đủ của kh uôn khổ Viết tắt
Architecture of Integrated Information Systems Framework ARIS
Khuôn khổ Kiến trúc của các Hệ thống Thông tin được Tích
hợp
Bredemeyer Framework Bredem eyer
Khuôn khổ Bredemeyer
Business Transformation Enablement Programme BTEP
Transformation Framework
Khuôn khổ Chuyển tiếp Chương trình Hỗ trợ Chuyển đổi Doanh
nghiệp
Command, Control, Communications, Computers Intelligences C4ISR
Surveillance and Reconnaissance
Chỉ huy, Kiểm soát, Truyền thông, Giám sát và Thăm dò Tin
tức Máy tính
CSC Catalyst Catalyst
CSC Catalyst
Computer Integrated Manufacturing Open Systems Architecture CIMOSA
Kiến trúc các Hệ thống Sản xuất Mở được Tích hợp với Máy
tính
Enterprise Architecture Framework Gartner
Khuôn khổ Kiến trúc Doanh nghiệp
Enterprise Architecture Planning EAP
Hoạch định Kiến trúc Doanh nghiệp
Extended Enterprise Architecture Framework E2AP
Khuôn khổ Kiến trúc Doanh nghiệp Mở rộng
FEA Reference Models FEA
Các Mô hình Tham chiếu FEA
Generalized Enterprise Reference Architecture and GERAM
Methodology
Phương pháp và Kiến trúc Tham chiếu Doanh nghiệp được
Tổng quát hóa
Integrated Architecture Framework IAF
Khuôn khổ Kiến trúc được Tích hợp
Pillars of EA Forrester
Các cột trụ EA

64
Reference Model for Open Distributed Processing RM-ODP
Mô hình Tham chiếu cho Xử lý Phân tán Mở
Technical Architectural Framework Information Management TAFIM
Quản lý Thông tin Khuôn khổ Kiến trúc Kỹ thuật
Treasury Enterprise Architecture Framework TEAF
Kho tàng Khuôn khổ Kiến trúc Doanh nghiệp
TOGAF Technical Reference Model TOGAF
Mô hình Tham chiếu Kỹ thuật TOGAF
Zachman Framework Zachm an
Khuôn khổ Zachman
Bảng 3.1 – Các khuôn kh ổ Kiến trúc Doanh nghi ệp
Những khuôn kh ổ này bao gồm các m ô tả về cơ cấu tổ chức, các

quy trình nghi ệp vụ, các hệ thống hoạch định và kiểm soát, các cơ
chế quản trị và quản lý, các chính sách và th ủ tục của doanh nghi ệp.
Chúng chỉ ra cách các thành ph ần này tương tác và đóng góp vào
việc đạt được các m ục đích và m ục tiêu c ủa doanh nghi ệp, đồng
thời cung c ấp cơ s ở để xác định các yêu cầu đối với hệ thống thông
tin hỗ trợ các quy trình nghi ệp vụ này.
Kiến trúc Doanh nghi ệp phải là m ột yếu tố tích hợp của Kiến trúc
Doanh nghiệp và phải bao gồm các lĩnh vực chính yếu sau đây:
 Kiến trúc Dịch vụ, diễn giải các ứng dụng, cơ sở hạ tầng, t ổ
chức và các hoạt động hỗ trợ thành m ột bộ các dịch vụ. Kiến
trúc Dịch vụ cung cấp phương pháp tiếp cận độc lập, được
tích hợp với doanh nghiệp để cung c ấp các dịch vụ cho doanh
nghiệp. Nó cung c ấp m ô hình để phân biệt giữa Kiến trúc Dịch
vụ, Kiến trúc Ứng dụng, Kiến trúc Dữ liệu và Kiến trúc Cơ sở
hạ tầng. Nó cũng cung c ấp khả năng chịu lỗi, kiểm chứng và
kiểm soát bảo m ật trong tương lai. Đi ều này có nghĩa là, có
khả năng, những thay đổi xảy ra trong b ất kỳ kiến trúc công
nghệ nào s ẽ m inh bạch với người sử dụng dịch vụ - ví dụ: cơ
chế cung c ấp dịch vụ tự-phục vụ dựa trên-nền web. Nó không
chỉ bao gồm bản thân các d ịch vụ và tích hợp tổng thể của
chúng m à còn bao g ồm việc quản lý các dịch vụ đó.
 Kiến trúc ứng dụng, cung cấp m ột kế hoạch chi tiết cho vi ệc
phát triển và tri ển khai các ứng dụng riêng l ẻ, ánh xạ các yêu
cầu chức năng và nghiệp vụ đối với các ứng dụng, đồng thời
chỉ ra m ối quan h ệ qua lại giữa các ứng dụng. Các Ki ến trúc
Ứng dụng m ới nổi có khả năng là dựa trên-thành phần.
Phương pháp ti ếp cận như vậy tối đa hóa vi ệc tái s ử dụng và
giúp duy trì tính linh ho ạt trong việc đáp ứng các thay đ ổi
trong chính sách tìm ngu ồn cung ứng.
 Kiến trúc Dữ liệu/Thông tin, m ô tả tài sản dữ liệu logic và
vật lý của doanh nghi ệp và các ngu ồn lực quản lý dữ liệu. Nó

65
cho thấy cách m à các ngu ồn thông tin được quản lý và chia s ẻ
như thế nào vì l ợi ích của doanh nghi ệp. Một chiến lược về dữ
liệu tập trung so với dữ liệu phân tán g ần như chắc chắn s ẽ
được đưa ra như m ột phần của kiến trúc như vậy. Kiến trúc
Dữ liệu/Thông tin sẽ bao gồm việc xem xét các công ngh ệ kho
lưu trữ dữ liệu tạo điều kiện thuận lợi cho việc khai thác các
tài sản thông tin c ủa công ty. Càng ngày nó s ẽ càng bao gồm
việc quản lý nội dung và các phương ti ện để cung cấp thông
tin thông qua nhi ều kênh.
 Kiến trúc cơ s ở hạ tầng CNTT, m ô tả cấu trúc, chức năng và
phân bố địa lý c ủa các thành phần phần cứng, phần m ềm và
truyền thông làm nền tảng và hỗ trợ kiến trúc tổng thể, cùng
với các tiêu chuẩn kỹ thuật áp dụng cho chúng. Đi ều này cũng
phải bao gồm 'Kiến trúc sản phẩm ' m ô tả các sản phẩm độc
quyền m ột cách c ụ thể và các tiêu chu ẩn ngành m à doanh
nghiệp sử dụng để triển khai cơ sở hạ tầng phù hợp với các
nguyên t ắc Kiến trúc Cơ sở hạ tầng CNTT
 Kiến trúc Môi trư ờng, m ô tả m ọi khía cạnh, loại hình và m ức
độ của các biện pháp kiểm soát m ôi trường và sự quản lý của
chúng. Một m inh h ọa về kiểu thông tin về m ôi trường cần thiết
được bao gồm trong Phụ lục E.
Những m ối quan h ệ giữa các quan đi ểm kiến trúc nói trên có th ể

được thấy trong Hình 3.9. S ự phát triển, ghi nhận tài liệu và duy trì
các kiến trúc doanh nghi ệp và CNTT sẽ thường định hình m ột phầ n
của các quy trình c ủa tư duy chiến lược và phát tri ển chiến lược
trong t ổ chức.

66
Hình 3.9 – Những mối quan hệ về kiến trúc
Trong phạm vi khuôn kh ổ đã được m ô tả trước đó, sẽ có khả năng

xác định (ít nhất) ba vai trò kiến trúc. H ọ đều có thể báo cáo cho
m ột ‘Kiến trúc sư Doanh nghi ệp’ cấp cao trong tổ chức:
 Kiến trúc sư Doanh nghi ệp/Tổ chức: liên quan tới các m ô
hình doanh nghi ệp, quy trình nghi ệp vụ và thiết kế tổ chức –
các thành ph ần chức năng và ki ến trúc của tổ chức và các m ối
quan hệ của chúng, và cách thức m à các ch ức năng và ho ạt
động kinh doanh c ủa tổ chức được phân phối giữa chúng như
thế nào; đồng thời sự quản trị của tổ chức và các vai trò và
trách nhiệm cần thiết.
 Kiến trúc sư Dịch vụ (thường tách bi ệt vai trò với Kiến trúc
sư Ứng dụng và Ki ến trúc sư D ữ liệu/Thông tin): liên quan t ới
các Kiến trúc D ịch vụ, Dữ liệu và Ứng dụng – các kiến trúc
logic hỗ trợ cho doanh nghiệp và các m ối quan hệ giữa chúng.
 Kiến trúc sư Cơ s ở hạ tầng CNTT: liên quan t ới các m ô hình
công nghệ vật lý, các thành ph ần cơ sở hạ tầng và m ối quan
hệ của chúng, bao gồm các lựa chọn về công nghệ, các giao

67
diện và giao thức, và sự lựa chọn các sản phẩm để triển khai
cơ sở hạ tầng.
Trong m ột số tổ chức, vai trò Ki ến trúc sư Doanh nghi ệp/Tổ chức,

Kiến trúc sư H ệ thống Thông tin (hoặc có khả năng là vai trò tách
biệt về Kiến trúc sư Ứng dụng và Kiến trúc sư Dữ liệu) và Ki ến trúc
sư Cơ sở hạ tầng CNTT sẽ là các chức năng tách biệt. Trong m ột số
tổ chức khác, m ột vài hoặc toàn bộ các vai trò có thể được kết hợp
lại. Các vai trò có th ể nằm trong các b ộ phận riêng bi ệt của t ổ chức
hoặc thậm chí nằm ngoài t ổ chức. Ví dụ:
 Vai trò Kiến trúc sư Doanh nghi ệp/Tổ chức có thể nằm trong
chức năng Chiến lược và Hoạch định Doanh nghi ệp trong tr ụ
sở của công ty.
 Vai trò Kiến trúc sư Dịch vụ có thể định hình m ột phần của m ột
chức năng n ội bộ với trách nhiệm xử lý các m ối quan h ệ giữa
doanh nghi ệp, các nhà cung c ấp bên ngoài và các đ ối tác
CNTT liên quan đ ến các s ự cố Dịch vụ. Một trong những trách
nhiệm chính của chức năng này là duy trì Ki ến trúc D ịch vụ.
Chức năng này có thể ở bên trong m ột chức năng CNTT hoặc
m ột phương di ện kinh doanh của m ột tổ chức.
 Kiến trúc sư Cơ sở hạ tầng CNTT có thể nằm trong nhà cung
cấp/đối tác dịch vụ, người chịu trách nhi ệm cho việc cung cấp
Kiến trúc Cở sở hạ tầng CNTT được sử dụng để cung c ấp các
Dịch vụ CNTT cho t ổ chức.
Nếu như các kiến trúc c ần thiết có sẵn, vai trò của Thiết kế Dịch vụ
sẽ bị ảnh hưởng theo những cách sau đây:
 Phải làm việc trong khuôn khổ và các tiêu chu ẩn kiến trúc đã
thỏa thuận.
 Sẽ có khả năng để tái sử dụng rất nhiều tài sản đã đư ợc tạo
ra như là m ột phần của kiến trúc.
 Nên làm vi ệc chặt chẽ với tất cả ba vai trò ki ến trúc để đảm
bảo việc tối đa hóa lợi ích t ừ những công việc đã hoàn thành
trong việc tạo ra kiến trúc.
Nếu thiết kế kiến trúc được tiến hành m ột cách hi ệu quả và kinh tế,
các tài liệu, quy trình và ho ạt động của doanh nghi ệp và thiết kế
kiến trúc nên được phối hợp và đồng bộ m ột cách chặt chẽ. Một
danh sách các tài li ệu kiến trúc này và nội dung c ủa chúng được
trình bày trong các Ph ụ lục C và D. Các chi ti ết riêng lẻ của công
nghệ được bao gồm trong thiết kế kiến trúc s ẽ được xem xét trong
những phần tiếp theo.
Lợi ích thực tế và RoI c ủa Kiến trúc Doanh nghi ệp không ch ỉ đến
từ bản thân ki ến trúc m à còn t ừ khả năng c ủa m ột tổ chức để thiết
kế và triển khai các d ự án và giải pháp theo m ột cách nhanh
chóng và nh ất quán.

68
3.6.3.1 Qu ản lý Công ngh ệ
Một phương pháp tiếp cận chiến lược nên được áp dụng liên quan
tới việc hoạch định m ột công ngh ệ thông tin và vi ệc quản lý nó. Đi ều
này hàm ý về việc tạo ra ‘các ki ến trúc’ ho ặc ‘đề án chi tiết’ cho
khuôn khổ dài hạn về công nghệ được sử dụng và hoạch định. Các
nhà hoạch định, thiết kế và kiến trúc sư CNTT c ần phải hiểu về
doanh nghi ệp, các yêu cầu và công ngh ệ hiện tại nhằm phát tri ển
các kiến trúc CNTT thích h ợp cho ngắn, trung và dài h ạn. Thiết kế
công nghệ cũng c ần tính đến các dịch vụ CNTT có khả năng s ẽ là cơ
sở, hoặc ít nhất là các lo ại dịch vụ từ sự thấu hiểu về doanh nghiệp
và định hướng tương lai c ủa nó, bởi vì doanh nghi ệp sẽ dựa vào các
dịch vụ CNTT, và chúng (các d ịch vụ CNTT) sẽ cần m ột công ngh ệ
tương xứng để cung cấp và phân ph ối những dịch vụ đó. Nếu có thể
cung cấp m ột công ngh ệ dài hạn, vốn có thể làm nền tảng cho m ột
số dịch vụ CNTT thì việc thực hiện m ột phương pháp ti ếp cận chiến
lược sẽ m ang lại những lợi ích trong dài h ạn.
Các kiến trúc cần được phát triển trong nh ững lĩnh vực quan tr ọng
của công nghệ.
Các ki ến trúc công ngh ệ

Các kiến trúc là c ần thiết trong m ọi lĩnh vực của cơ sở hạ tầng
CNTT. Khi có liên quan, chúng c ần được phát triển trong những lĩnh
vực sau:
 Các ứng dụng và phần m ềm hệ thống.

 Thông tin, d ữ liệu và cơ sở dữ liệu bao gồm bảo m ật thông tin
và tính bảo m ật, kho lữu trữ dữ liệu và khai thác d ữ liệu.
 Thiết kế và kiến trúc cơ sở hạ tầng:
o Máy chủ tập trung, ki ến trúc m áy ch ủ lớn, m áy ch ủ phân
tán theo vùng, bao g ồm các m áy chủ lưu trữ và in ấn cục
bộ.
o Mạng dữ liệu (LANs, MANs, W ANs, các giao th ức,
v.v…), các hệ thống internet, intranet và extranet.
o Công nghệ m ạng hội tụ, bao gồm m ạng âm thanh tho ại
(PABXs, Centrex, đi ện thoại bàn, điện thoại di động,
m áy fax, v.v…).
o Các hệ thống m áy khách (m áy tính đ ể bàn, m áy tính xác
tay, thiết bị truy cập di động (thiết bị cầm tay, đi ện thoại
di động, palm top, PDAs, m áy quét, v.v…).
o Các thiết bị lưu trữ, Mạng Khu vực Lưu trữ (SANs), Lưu
trữ Gắn vào Mạng (NAS), bao g ồm các hệ thống sao lư u
và phục hồi và các dịch vụ (m áy chủ, người m áy, v.v…).
o Lưu trữ, xử lý và quản lý tài liệu.
o Những lĩnh vực đặc biệt của công nghệ như EPOS, ATM,
quét thiết bị, hệ thống GPS, v.v…
 Các hệ thống và thi ết bị m ôi trường, bao gồm việc giám sát và
quản lý chúng.
Điều này sẽ dẫn đến m ột cấu trúc phân c ấp của các kiến trúc, sẽ
cần phải được bổ sung để xây dựng m ột bộ kiến trúc công nghệ
được tích hợp cho tổ chức. Kiến trúc Cơ sở hạ tầng nên nh ắm đến

69
việc cung cấp tương đ ối ít các nền tảng được tiêu chu ẩn hóa đối với
việc lưu trữ các ứng dụng. Nó cúng phải đặt ra các tiê u chuẩn cho
các kiến trúc ứng dụng sẽ được lưu tr ữ trong các trung tâm d ữ liệu
được kiểm soát để chúng phù hợp với các yêu c ầu vận hành, giám
sát và bảo m ật đã được tiêu chuẩn hóa.
Các ki ến trúc qu ản lý
CNTT phải quản lý chi phí, cung c ấp các dịch vụ phù hợp tại đúng
thời điểm , bảo m ật tài sản thông tin, cung c ấp dịch vụ đáng tin cậy
và dẫn dắt doanh nghiệp trong việc t ận dụng các công ngh ệ. Việc
này đòi hỏi các th ủ tục và công c ụ quản lý được tự động hóa nhằm
đạt được điều đó m ột cách hi ệu quả và năng suất. Việc lựa chọn
m ột kiến trúc quản lý thích h ợp là chìa khóa đ ể thiết lập m ức kiểm
soát và t ự động hóa c ần thiết. Có hai phương pháp ti ếp cận tách
biệt để phát triển một kiến trúc quản lý:
 Lựa chọn một ki ến trúc quản lý độc quyền: điều này dựa
trên việc lựa chọn m ột bộ các s ản phầm và công c ụ quản lý
đơn lẻ từ m ột nhà cung cấp các gi ải pháp quản lý độc quyền
duy nhất. Phương pháp ti ếp cận này thường sẽ đòi hỏi ít nỗ
lực, sẽ hỗ trợ và tích hợp vào m ột công cụ kiến trúc tổng thể,
nhưng thường có nghĩa là các thỏa hiệp sẽ phải được đưa ra
với chức năng và phương ti ện quản lý, sẽ có thể dẫn đến các
lỗ hổng.
 Lựa chọn một kiến trúc quản lý ‘t ốt nhất trong ngành’ :
phương pháp ti ếp cận này liên quan t ới việc lựa chọn m ột bộ
các công c ụ và sản phẩm quản lý ‘t ốt nhất trong ngành’ t ừ m ột
số các nhà cung c ấp giải pháp qu ản lý và sau đó tích h ợp
chúng để cung cấp m ột giái pháp quản lý toàn di ện. Nói
chung, việc này s ẽ đòi hỏi nhiều nỗ lực hơn trong vi ệc tích
hợp các công c ụ vào m ột giải pháp quản lý toàn di ện nhưng
thường sẽ cung cấp chức năng và phương ti ện quản lý tốt hơn
dẫn đến tiết kiệm về chi phí trong dài h ạn.
Những thách thức đối với quản lý CNTT là ph ối hợp và làm vi ệc

trong quan hệ đối tác với doanh nghi ệp trong vi ệc xây dựng các gi ải
pháp quản lý này, hỗ trợ các quy trình thích hợp và cung cấp các
thước đo và ch ỉ số cần thiết. Điều này phải đạt được trong khi gi ảm
hoặc tối ưu hóa các chi phí có liên quan, đ ặc biệt là các chi phí liên
tục, hàng năm . Cách t ốt nhất để giảm thiểu chi phí là thi ết kế m ột
cách khéo léo và cẩn thận - ví dụ: sử dụng t ốt nhất công su ất để
không cần phải m ua thêm công su ất bổ sung (với chi phí liên t ục liên
quan) hoặc thiết kế m ột giải pháp sao lưu/phục hồi không yêu cầu
m ột bộ cơ sở hạ tầng bổ sung hoàn chỉnh. Chi phí đáng k ể có th ể
được tiết kiệm nhờ thiết kế thông m inh và c ẩn thận, sử dụng công
nghệ có thể hỗ trợ và ít gây ra s ự cố trong m ôi trư ờng vận hành.
Phương pháp chính đ ể hiện thực hóa các m ục tiêu này là thiết kế
các giải pháp giúp làm gi ảm chi phí hỗ trợ và quản lý m ạng tổng thể,
trong khi vẫn duy trì ho ặc thậm chí cải thiện chất lượng dịch vụ
được cung cấp cho doanh nghi ệp. Để đạt được lợi ích lớn nhất từ

70
việc sử dụng Bốn chữ P (Four Ps), các t ổ chức nên xác đ ịnh vai trò
của các quy trình và con ngư ời, sau đó triển khai các công cụ để tự
động hóa các quy trình, t ạo điều kiện cho các vai trò và nhi ệm vụ
của con người. Cách tốt nhất để đạt được điều này là phát triển m ột
m ô hình hoặc kiến trúc dựa trên những nguyên tắc này. Kiến trúc
này nên tạo điều kiện cho việc triển khai m ột bộ các quy trình và
công cụ được tích hợp, hỗ trợ quản lý 'từ đầu-đến-cuối' đối với tất
cả các lĩnh vực công ngh ệ được sử dụng, đảm bảo rằng không có l ỗ
hổng và không có ‘h ầm ngầm kỹ thuật'.
Tuy nhiên, CNTT ph ải đối m ặt với m ột thách thức lớn trong vi ệc phát
triển và duy trì các k ỹ năng m ềm cần thiết để thực hiện các vai trò
và quy trình qu ản lý này m ột cách hiệu quả. Trong các t ổ chức thực
sự hiệu quả, các vai trò và quy trình này đư ợc liên k ết với các vai
trò và quy trình c ủa doanh nghiệp. Điều này đảm bảo rằng các quy
trình và thông tin c ủa Doanh nghiệp và Quản lý CNTT có các m ục
tiêu và m ục đích gi ống nhau. Tuy nhiên, các t ổ chức thường xuyên
không dành đ ủ thời gian và n ỗ lực cho việc phát triển các kỹ năng
m ềm (ví dụ: kỹ năng giao tiếp giữa các cá nhân, kỹ năng truyền
thông, kỹ năng hội họp) cần thiết để các quá trình và s ự liên k ết với
doanh nghiệp đạt được hiệu quả.
Có năm lĩnh vực cần được xem xét liên quan đ ến việc thiết kế các
kiến trúc quản lý, như được m inh họa trong Hình 3.10.
Hình 3.10 – Quản lý công nghệ theo định hướng-doanh nghiệp

được tích hợp
Các m ối quan hệ giữa những quan đi ểm thiết kế có thể được nhận

thấy trong sơ đ ồ nói trên. Vi ệc phát tri ển, ghi nhận lại và duy trì các

71
kiến trúc doanh nghi ệp và CNTT s ẽ thường định hình các quy trình
về tư duy chiến lược và phát triển chiến lược trong t ổ chức.
Năm lĩnh vực quản lý này c ần được xem xét có thể được định nghĩa
m ột cách tóm tắt như sau:
 Doanh nghiệp: các nhu c ầu, yêu c ầu, quy trình, m ục đích và
m ục tiêu c ủa các đơn vị kinh doanh và c ác nhà quản lý trong
tổ chức.
 Con người: phạm vi, các tác vụ và hoạt động của các nhà
quản lý và nhân viên tham gia vào qu ản lý việc cung cấp các
dịch vụ CNTT.
 Các quy trình : các quy trình và th ủ tục được sử dụng để quả n
lý các dịch vụ CNTT cho doanh nghi ệp và khách hàng c ủa nó.
 Các công cụ: các công c ụ quản lý và h ỗ trợ cần thiết để quản
lý cơ sở hạ tầng CNTT m ột cách hi ệu quả.
 Công nghệ: các sản phẩm và công nghệ CNTT được sử dụng
để cung cấp dịch vụ và thông tin cho đúng ngư ời, ở đúng địa
điểm và đúng t hời điểm .
Một kiến trúc như vậy có thể được sử dụng để thiết kế và triển khai
các giải pháp quản lý hiệu quả, có hiệu lực và được tích hợp và
được liên kết với các yêu c ầu của kinh doanh c ủa tổ chức và các
Nhà Quản lý Kinh doanh c ủa nó. Kiến trúc quản lý này có thể được
áp dụng trong tổ chức để:
 Thiết kế từ trên xu ống, đảm bảo rằng các quy trình, công c ụ
và thông tin Quản lý Dịch vụ và quản lý công ngh ệ được liên
kết với các nhu c ầu và m ục tiêu c ủa doanh nghiệp.
 Triển khai từ dưới lên, đảm bảo rằng các quy trình qu ản lý
công nghệ và Quản lý Dịch vụ hiệu quả, có hiệu lực được tích
hợp đầy đủ với các công c ụ và công ngh ệ đang sử dụng trong
tổ chức.
 Các qu y trình và công c ụ được tích hợp, đảm bảo rằng các
công cụ được khai thác nhiều hơn trong qu ản lý và sự hỗ trợ
của công nghệ và các quy trình t ừ đầu-đến-cuối.
Những gạch đầu dòng này cũng đư ợc m inh họa trong Hình 3.10.
Chìa khóa đ ế phát triển m ột kiến trúc qu ản lý là đảm bảo rằng nó

được định hướng bởi nhu cầu kinh doanh và không đư ợc phát tri ể n
chỉ cho các nhu cầu biệt lập của CNTT:
Các ki ến trúc qu ản lý cần phải:
‘… được liên kết với doanh nghiệp, KHÔNG PH ẢI định hướng

bởi công nghệ’.
Trong cấu trúc t ổng thể này, m ột kiến trúc quản lý là cần thiết để có
thể được áp dụng cho t ất cả các lĩnh vực Quản lý CNTT chứ không
chỉ cho các lĩnh vực biệt lập riêng lẻ. Sau đó, đi ều này có thể được

72
triển khai trong m ột chương trình ph ối hợp làm việc lẫn nhau, đ ể
cung cấp Quản lý Doanh nghi ệp tổng thể từ đầu-đến-cuối, vốn rất
cần thiết cho việc quản lý hiệu quả cơ sở hạ tầng CNTT ngày nay.
Nếu chỉ có các khu vực riêng lẻ tham gia vào kiến trúc, thì các ‘hòn
đảo xuất sắc’ riên g lẻ sẽ phát triển và sẽ không thể cung cấp các
giải pháp từ đầu-đến-cuối hoàn chỉnh cần thiết để hỗ trợ các giải
pháp kinh doanh đi ện tử ngày nay.
Ngoài việc đảm bảo rằng t ất cả các lĩnh vực của CNTT đều được
tích hợp, điều quan trọng là kiến trúc quản lý phải được phát triển từ
quan điểm doanh nghi ệp và dịch vụ (tức là ‘từ trên xuống’). Do đó,
các yếu tố chính c ần được thỏa thuận và xác định trước khi phát
triển kiến trúc quản lý là:
 Quản lý các quy trình nghi ệp vụ: Các quy trình nghi ệp vụ là gì
và chúng có liên quan như th ế nào đến m ạng và các d ịch vụ
và thành phần CNTT?
 Quản lý chất lượng dịch vụ: Chất lượng dịch vụ là gì? Nó sẽ
được đo lường như thế nào và ở đâu?
Đây là những yếu t ố chính cần được xác định bởi SLM và Quản lý
CNTT. Chúng cung c ấp đầu vào quan trọng cho sự phát triển của
các kiến trúc quản lý t ập trung vào doanh nghi ệp. Tất cả các công
cụ và quy trình qu ản lý thường t ập trung vào các thành ph ần và
quản lý thành ph ần hơn là các dịch vụ và quy trình nghiệp vụ. Điều
này cần phải được thay đổi, với sự nhấn m ạnh m ột cách rõ ràng vào
việc thiết kế các hệ thống, quy trình và công c ụ quản lý, được thúc
đẩy bởi nhu c ầu kinh doanh và t ập trung vào vi ệc quản lý các quy
trình nghiệp vụ và dịch vụ CNTT. Nếu kiến trúc quản lý thích hợp
được thiết kế và triển khai, đi ều này sẽ cho phép các quy trình Qu ản
lý Dịch vụ tập trung vào qu ản lý dịch vụ và chất lượng dịch vụ và
vận hành từ đầu đến cuối trong toàn bộ doanh nghi ệp CNTT, cung
cấp Quản lý Dịch vụ Doanh nghiệp thực sự. Điều này s ẽ thực sự tạo
điều kiện thuận lợi cho việc quản lý các dịch vụ để đảm bảo rằng
các dịch vụ và chất lượng dịch vụ được liên k ết chặt chẽ với nhu
cầu của doanh nghi ệp.
Các kiến trúc đã được m ô tả cho thấy rằng tương lai c ủa quản lý
m ạng và hệ thống sẽ ít tập trung hơn vào công nghệ và trở nên tích
hợp hơn với các yêu c ầu tổng thể của doanh nghiệp và Quản lý
CNTT. Các h ệ thống và quy trình m ới này đã bắt đầu phát triển khi
các tiêu chu ẩn quản lý để trao đổi thông tin qu ản lý giữa các công
cụ được xác định đầy đủ hơn bởi các tổ chức như Distributed
Managem ent Task Force (DMTF). V ề bản chất, hệ thống quản lý sẽ
trở thành:
 Tập trung hơn vào nhu c ầu kinh doanh.

 Liên kết chặt chẽ hơn với các quy trình nghi ệp vụ.
 Ít phụ thuộc vào công ngh ệ cụ thể và lấy ‘dịch vụ làm trung
tâm ’ hơn.

73
 Tích hợp nhiều hơn với các công c ụ và quy trình quản lý khác
khi các tiêu chu ẩn quản lý phát tri ển. Điều này sẽ liên quan
đến việc tích hợp các công cụ và quy trình qu ản lý hệ thống,
quản lý vận hành và Qu ản lý Dịch vụ, với ít 'hầm ngầm công
nghệ' và 'hòn đảo xuất sắc'
 Một phần của hệ thống và quy trình qu ản lý từ đầu-đến-cuối,
tập trung hơn vào vi ệc cung c ấp chất lượng và dịch vụ khách
hàng.
 Linh hoạt hơn. Sẽ có sự chuyển đổi từ m ột số khuôn khổ nhà
cung c ấp đơn l ẻ, cứng nhắc hơn sang cách ti ếp cận ‘tốt nhất
trong ngành’ cởi m ở hơn.
3.6.4 Thiết kế các Quy trình

Phần này cung c ấp giới thiệu chung về lý thuyết và thực tiễn về quy
trình, vốn là cơ sở cho việc thiết kế các quy trình ITIL đư ợc sử dụng
trong Vòng đời Dịch vụ. Một m ô hình quy trình cho phé p hiểu và giúp
nói rõ về chức năng đặc biệt của m ột quy trình.
Một quy trình là m ột bộ các hoạt động có c ấu trúc đư ợc thiết kế để

hoàn thành m ột m ục tiêu cụ thể. Một quy trình có m ột hoặc nhiều
đầu vào và chuyển chúng thành các đ ầu ra đã được xác định. Một
quy trình bao g ồm m ọi vai trò, trách nhi ệm , công cụ và các bi ện
pháp kiểm soát qu ản lý cần thiết để cung cấp đầu ra đáng tin c ậy.
Một quy trình cũng có th ể xác định hoặc điều chỉnh các chính sách,
tiêu chuẩn, hướng dẫn, hoạt động, các quy trình, th ủ tục và hướng
dẫn công việc nếu chúng là c ần thiết.
Kiểm soát quy trình có th ể được định nghĩa là:

Hoạt động hoạch định và đi ều chỉnh m ột quy trình, cùng v ới m ục
tiêu hoàn thành m ột quy trình m ột cách hi ệu quả, hiệu suất và
nhất quán.
Các quy trình, khi đã đư ợc xác định, nên được lập thành văn b ản và
được kiểm soát. Khi đã đư ợc kiểm soát, chúng có th ể được lặp lại
và có thể quản lý được. Mức độ kiểm soát đối với các quy trình có
thể được xác định, và sau đó thư ớc đo và các chỉ số quy trình có
thể được xây dựng vào trong quy trình đ ể kiểm soát và c ải thiện quy
trình, như được m inh h ọa trong Hình 3.11.

74
Hình 3.11 – Các ph ần tử của quy trình chu ng
Các phần tử của quy trình chung cho th ấy dữ liệu đi vào quy trình,
được xử lý, là đầu ra và k ết quả được đo lường và xem xét. Mô t ả
rất cơ bản này làm nền tảng cho bất kỳ m ô tả quy trình nào. M ột quy
trình luôn đư ợc t ổ chức xung quanh m ột bộ các m ục tiêu. Các kết
quả đầu ra chính c ủa quy trình phải được định hướng bởi các m ục
tiêu và phải luôn bao gồm các thước đo, báo cáo, và c ải tiến quy
trình.
Mỗi quy trình phải thuộc sở hữu của m ột chủ sở hữu quy trình,
người nên chịu trách nhi ệm về quy trình và s ự cải tiến của nó và
đảm bảo rằng m ột quy trình đáp ứng được các m ục tiêu của nó. Các
m ục tiêu của bất kỳ quy trình CNTT nào c ần được xác định bằng các
thuật ngữ có thể đo lường được và nên được thể hiện dưới dạng lợi
ích kinh doanh và làm cơ s ở cho chiến lược và m ục tiêu kinh doanh.
Thiết kế Dịch vụ nên hỗ trợ m ỗi chủ sở hữu quy trình với việc thiết
kế các quy trình, nhằm đảm bảo rằng tất cả các quy trình sử dụng
các thuật ngữ và biểu m ẫu tiêu chuẩn, nhất quán và đư ợc tích hợp
với nhau để cung c ấp sự tích hợp từ đầu-đến-cuối trên m ọi lĩnh vực.
Đầu ra được sản xuất bởi m ột quy trình ph ải phù hợp với các tiêu
chuẩn hoạt động xuất phát từ các m ục tiêu kinh doanh. N ếu các s ản
phẩm phù hợp với tiêu chuẩn đã đặt ra thì quy trình có th ể được coi
là hiệu quả (vì nó có thể được lặp lại, đo lư ờng và quản lý). Nếu các
hoạt động được thực hiện với việc sử dụng tối thiểu các ngu ồn lực
thì quy trình cũng có th ể được coi là hiệu quả. Phân tích quy trình,

75
kết quả và các ch ỉ số nên được đưa vào các báo cáo qu ản lý và cải
tiến quy trình thường xuyên.
Tất cả các lĩnh vực này nên được bao gồm trong thi ết kế của bất kỳ
quy trình nào. Nh ững ấn phẩm ITIL m ới này đã được viết xung
quanh ‘các b ộ quy trình’ ph ản ánh các giai đo ạn trong vòng đời c ủa
m ột dịch vụ. Bộ các quy trình Thiết kế Dịch vụ được trình bày chi
tiết trong ấn phẩm này bao g ồm các quy trình chủ yếu liên quan đ ến
m ọi khía c ạnh của thiết kế.
Làm việc với các quy trình đã đư ợc xác định là nền tảng của ITIL
ngay từ đầu. Bằng cách xác định các ho ạt động của tổ chức là gì,
đầu vào nào là cần thiết và đầu ra nào s ẽ là kết quả của quá trình,
tổ chức có thể làm việc theo cách hiệu quả và hiệu suất hơn. Đo
lường và chỉ đạo các hoạt động làm gia tăng tính hi ệu quả này. Cuối
cùng, bằng cách thêm các tiêu chu ẩn vào quy trình, có t hể thêm các
thước đo chất lượng cho đầu ra.
Phương pháp ti ếp cận này làm nền tảng cho chu trình Lên K ế hoạch
– Thực hiện – Kiểm tra – Hành động về cải tiến liên t ục cho bất kỳ
hệ thống quản lý chất lượng nào. Lên kế hoạch cho m ục đích c ủa
quy trình theo c ách m à các hành đ ộng của quy trình có th ể được
xem xét, đánh giá ho ặc kiểm toán để đạt được thành tích thành công
và được cải thiện.
Các tiêu chu ẩn xác định những điều kiện nhất định m à các kết quả
nên đáp ứng được. Việc xác định các tiêu chuẩn đem lại khía cạnh
chất lượng cho quy trình. Ngay c ả trước khi bắt đầu, điều quan
trọng là suy nghĩ v ề những kết quả của quy trình sẽ trông như th ế
nào. Để khám phá xem liệu các hoạt động của quy trình có đang
đóng góp m ột cách tối ưu cho m ục đích kinh doanh và các m ục tiêu
của quy trình, đư ợc liên k ết với m ục đích kinh doanh, tính hi ệu quả
nên được đo lường m ột cách thường xuyên. Vi ệc đo lường cho phép
so sánh những gì thực tế đã được hoàn thành với những gì tổ chức
đã đặt ra để thực hiện, và để xác dịnh và tri ển khai những cải thiệ n
trong quy trình.
Mỗi tổ chức nên áp dụng m ột phương pháp tiếp cận được chính thức
hóa để thiết kế và triển khai các quy trình Qu ản lý Dịch vụ. Mục tiêu
không nên chỉ là thiết kế ‘những quy trình hoàn hảo’ m à là thi ết kế
các quy trình thực tế và thích hợp với các cơ ch ế cải thiện ‘được
tích hợp’, để từ đó tính hi ệu quả và hiệu suất của quy trình được cải
thiện theo cách phù h ợp nhất đối với tổ chức. Tài liệu các tiêu
chuẩn, quy trình và bi ểu m ẫu nên được sử dụng để đảm bảo rằng
các quy trình dễ dàng đư ợc áp dụng trong toàn b ộ tổ chức. Vài ví d ụ
về biểu m ẫu tài liệu quy trình được bao gồm trong Phụ lục C.
Mục đích trong hi ện tại và tương lai là để thiết kế các quy trình và
hỗ trợ chúng với các công c ụ có thể cung cấp sự tích hợp giữa các
tổ chức. Việc này gi ờ đây đã trở nên khả thi bởi vì các công c ụ quản
lý đang cung c ấp sự hỗ trợ cho các tiêu chu ẩn m ở chẳng hạn như

76
Distributed Managem ent Task Force (DMTF), h ỗ trợ việc trao đổi
thông tin d ựa trên các khái ni ệm ITIL, chẳng hạn như các s ự cố, vấn
đề và thay đổi với các định dạng và nội dung tiêu chu ẩn. Điều này
cho phép các nhà cung c ấp dịch vụ hỗ trợ các giao di ện quy trình
hiệu quả và có năng suất với các nhà cung c ấp chính c ủa họ với
việc trao đổi thông tin ho ạt động chính yếu được tự động hóa theo
thời gian thực.
3.6.5 Thiết kế các hệ thống và chỉ số đo lường

‘Nếu bạn không th ể đo lường nó nghĩa là b ạn không th ể quản lý
nó’.
Để quản lý và kiểm soát các quy trình thi ết kế thì chúng phải được
giám sát và đo lư ờng. Điều này đúng với m ọi khía cạnh của các quy
trình thiết kế. Thước đo và các ch ỉ số được trình bày chi tiết trong
ấn phầm Liên t ục Cải tiến Dịch vụ. Phần này chỉ bao gồm những
khía cạnh liên quan m ột cách đặc biệt và tương xứng với việc đo
lường chất lượng của các quy trình thi ết kế và những sản phẩm có
thể chuyển giao đư ợc của chúng.
Cần cẩn trọng khi l ựa chọn các thước đo và các chỉ số và phương
pháp được sử dụng để đưa ra chúng. Đó là vì các ch ỉ số và thước
đo đã được chọn sẽ thực sự ảnh hưởng và thay đ ổi hành vi của con
người đang làm việc trong các hoạt động và quy trình đư ợc đo
lường, đặc biệt là khi đi ều này liên quan t ới các m ục tiêu, hi ệu suất
đội nhóm và hi ệu suất cá nhân và các chương trình tr ả lương liên
quan tới hiệu suất. Do đó, chỉ nên lựa chọn những thước đo khuyến
khích sự tiến bộ hướng t ới việc đáp ứng các m ục tiêu kinh doanh
hoặc sự thay đổi hành vi m ong m u ốn.
Trong m ọi hoạt động thiết kế, yêu cầu nên:
 Thiết kế các giải pháp ‘phù h ợp với m ục đích’.

 Thiết kế m ức chất lượng thích hợp – không được quá m ức
hoặc dưới m ức.
 Thiết kế các giải pháp ‘đúng ngay t ừ đầu’ m à đáp ứng các
đích nhắm m ục tiêu được kỳ vọng của chúng.
 Thiết kế các giải pháp giảm thiểu số lượng ‘thực hiện lại công
việc’ hoặc ‘bổ sung’ cần phải đưuọc phát triển m ột cách nhanh
chóng sau khi các gi ải pháp đã được triển khai.
 Thiết kế các giải pháp có hiệu quả và năng suất từ quan điểm
của doanh nghi ệp và khách hàng. S ự nhấn m ạnh nên được đặt
vào các gi ải pháp hiệu quả hơn tất cả và năng su ất trong
phạm vi giới hạn duy trì hiệu quả.
Các phương pháp và ch ỉ số đo lường nên ph ản ảnh những yêu cầu

đó và được thiết kế để đo lường khả năng c ủa các quy trình thi ết kế
để đáp ứng được các yêu c ầu đó. Mọi thước đo và chỉ số được sử
dụng nên phản ảnh chât lượng và s ự thành công của các quy trình

77
thiết kế từ quan đi ểm của doanh nghiệp, khách hàng và ngư ời sử
dụng. Chúng c ần phải phản ảnh khả năng của các giải pháp đã cung
cấp để đáp ứng các yêu c ầu đã được xác định và được thỏa thuận
của doanh nghi ệp.
Các thước đo quy trình đã ch ọn cần phải phù hợp với khả năng và
m ức độ trưởng thành c ủa các quy trình được đo lường. Các quy
trình chưa trưởng thành không có kh ả năng hỗ trợ các thước đo, chỉ
số và phương pháp đo lư ờng phức tạp. Có bốn loại chỉ số có thể
được sử dụng để đo lường năng lực và hiệu suất của các quy trình:
 Tiến độ: các m ốc thời gian và các s ản phẩm có thể chuyển

giao được trong kh ả năng của quy trình.
 Tuân thủ: tính tuân thủ của quy trình đ ối với các yêu cầu quả n
trị, yêu cầu pháp lý và tuân th ủ của con người đối với việc sử
dụng quy trình.
 Hiệu quả: tính chính xác và đúng đắn của quy trình và năng
lực của nó (quy trình) trong vi ệc cung c ấp ‘kết quả đúng đắn’.
 Hiệu su ất: năng lực sản xuất của quy trình, t ốc độ của nó,
thông lượng và s ử dụng nguồn lực.
Các thước đo và chỉ số nên phát triển và thay đ ổi khi sự trưở ng

thành và năng lực của quy trình phát triển. Ban đầu, với các quy
trình chưa trưởng thành, hai m ức chỉ số đầu tiên nên được sử dụng
để đo lường tiến trình và sự tuân thủ của quy trình khi quy trình phát
triển trong quá trình trư ởng thành. Khi s ự trưởng thành của quy
trình phát tri ển, nên sử dụng nhiều hơn các thước đo về hiệu quả và
năng suất, nhưng không làm ảnh hưởng đến tiến độ hoặc sự tuân
thủ của quá trình.
Việc lựa chọn chỉ số, điểm đo và phương pháp đo lư ờng, việc tính
toán và báo cáo v ề chỉ số đo lường phải được thiết kế và hoạch định
m ột cách c ẩn thận. Các thước đo chính phải luôn t ập trung vào vi ệc
xác định hiệu quả và chất lượng của các gi ải pháp được cung c ấp.
Sau đó, các ch ỉ số thứ cấp có thể đo lường hiệu quả của các quy
trình được sử dụng để đưa ra và quản lý giải pháp. Ưu tiên luôn
phải đảm bảo rằng các quy trình m ang l ại kết quả những chính xác
cho doanh nghi ệp. Do đó, các phương pháp và ch ỉ số đo lường phải
luôn cung c ấp phép đo t ập trung vào doanh nghi ệp hơn t ất cả.
Phương pháp hiệu quả nhất về đo lường là thi ết lập m ột ‘Cây Ch ỉ số’
hoặc ‘cây KPI’. Rất nhiều tổ chức thu thập các thước đo trong các
lĩnh vực riêng lẻ, nhưng th ất bại trong việc tổng hợp chúng lại vớ i
nhau và đạt được lợi ích đầy đủ của các thước đo và do đó bị ảnh
hưởng bởi:
 Các thước đo không được liên k ết với các nhu cầu và m ục

tiêu của doanh nghi ệp.
 Không có tầm nhìn t ổng thể về bức tranh ở ‘cấp cao nhất’.
 Có những lỗ hổng trong các lĩnh v ực nơi m à các thước đo
không được ghi nhận.

78
 Không có s ự nhất quán trong phương pháp, trình bà y và tính
toán các thước đo.
 Các quyết định và hành đ ộng cải tiến dựa trên thông tin
không chính xác ho ặc không hoàn ch ỉnh.
Do đó, các t ổ chức nên c ố gắng phát triển các hệ thống đo lường tự
động hóa dựa trên hình th ức ‘Cây Chỉ số’ như được m inh họa trong
Hình 3.12.
Hình 3.12 – Cây Ch ỉ số
Cây trong Hình 3.12 là m inh h ọa cho m ột ví dụ về Cây Chỉ số dựa

trên m ột Thẻ điểm Cân bằng (Balance Scorecard) đi ển hình.Các Th ẻ
điểm Cân bằng thể hiện cho m ột hệ thống cho phép ngày càng nhi ều
tổ chức làm rõ t ầm nhìn tầm nhìn và chiến lược của họ thành các
hành động. Chúng (các Th ẻ điểm Cân bằng) cung cấp sự phản hồi
liên quan tới các quy trình nghi ệp vụ nội bộ và các k ết quả bên
ngoài để cải thiện hiệu suất và kết quả chiến lược m ột cách liên t ục.
Điều này cho phép m ọi người trong t ổ chức có được bức tranh v ề
hiệu suất của tổ chức ở m ức độ thích hợp:
 Các nhà quản lý và khách hàng c ủa doanh nghi ệp có thể có

được ‘bảng điều khiển’ kinh doanh ‘c ấp cao nhất’, được liên
kết với các nhu c ầu và các quy trình nghi ệp vụ.
 Các nhà quản lý CNTT cấp cao và khách hàng có th ể tập trung
vào bảng điều khiển CNTT cấp cao nhất.
 Các Nhà quản lý Dịch vụ và khách hàng có th ể tập trung vào
hiệu suất của các dịch vụ đặc biệt.
 Các chủ sở hữu quy trình và các nhà qu ản lý có thể xem xét
hiệu suất của quy trình c ủa họ.
 Các chuyên gia k ỹ thuật có thể xem xét hi ệu suất của các
thành phần riêng l ẻ.

79
 Bảng điều khiển cũng thể hiện cho m ột cơ hội để xem xét các
khuynh hướng theo thời gian, thay vì d ữ liệu tĩnh, để từ đó sự
suy giảm hiệu suất tiềm ẩn có thể được xác định và đư ợc điều
chỉnh tại giai đoạn đầu.
Điều này có nghĩa là trong m ột hệ thống đo lường có cấu trúc phân

cấp, m ỗi người trong tổ chức có thể tiếp cận với m ức độ thông tin và
phép đo thích hợp phù hợp với nhu c ầu cụ thể của họ. Nó cung c ấp
cho các nhà quản lý cấp cao cơ h ội giám sát b ảng điều khiên c ấp
cao nhất để đảm bảo rằng các dịch vụ tiếp tục được phân ph ối với
các m ức đã được thỏa thuận của chúng (các d ịch vụ) và nó cũng
cung cấp khả năng cho các chuyên gia k ỹ thuật và chủ sở hữu quy
trình đi sâu vào chi ti ết để phân tích phương sai t ừ dịch vụ, thành
phần hoặc hiệu suất quy trình đã được thỏa thuận.
Rõ ràng là vi ệc thu thập, phân tích và trình bày d ữ liệu này có thể là
m ột hoạt động rất tốn công sức và do đó cần được tự động hóa n ếu
có thể. Điều này có thể đạt được bằng cách sử dụng các công c ụ
phân tích dựa trên m acro, t ập lệnh, bảng tính hoặc tốt hơn là trên
các giải pháp dựa trên n ền web cụ thể. Các phép đo ở m ỗi m ức cần
được xác định m ột cách cụ thể để đáp ứng nhu c ầu của doanh
nghiệp, khách hàng và ngư ời sử dụng thông tin.
Thông tin chi ti ết hơn về các thước đo, chỉ số và phương pháp đo
lường được bao gồm trong ấn phẩm Cải tiến Dịch vụ Liên tục.
3.7 Các hoạt động thiết kế tiếp theo

Khi giải pháp dịch vụ m ong m uốn đã được thiết kế, sau đó các hoạt
động tiếp theo ph ải được hoàn thành cùng v ới giai đoạn Thiết kế
Dịch vụ trước khi gi ải pháp được chuyển sang giai đo ạn Chuyển tiếp
Dịch vụ.
3.7.1 Đánh giá các gi ải pháp thay thế

Một giai đoạn đánh giá b ổ sung có thể sẽ cần thiết nếu có liên quan
đến các giải pháp và dịch vụ của nhà cung c ấp bên ngoài. Đi ều này
bao gồm :
 Sự lựa chọn m ột tập hợp các nhà cung c ấp và hoàn thành m ột

quy trình đấu thầu. Điều này sẽ đòi hỏi đưa ra và hoàn thành:
o Tài liệu về phạm vi của dịch vụ và đưa ra m ột Tuyên b ố
về Yêu cầu (SoR) và/hoặc tài liệu Thuật ngữ tham chiế u
(ToR).
o Các tài li ệu Request For Inform ation – Yêu cầu về Thông
tin (RFI), Request For Proposal – Yêu cầu về Đề xuât
(RFP), Request For Quotation – Yêu cầu về Báo giá
(RFQ) và Invitation To Tender – Thư Mời thầu (ITT).
o Đưa ra và th ỏa thuận m ột bộ gồm giải pháp và tiêu chí
đánh giá nhà cung c ấp và m ột quy trình ch ấm điểm .
 Đánh giá và xem xét các ph ản hồi của nhà cung c ấp và lựa
chọn (các) nhà cung c ấp được ưu tiên và (các) gi ải pháp đã đ ề
xuất của họ. Điều này cũng có thể liên quan đến việc chạy thử

80
nghiệm hoặc thậm chí tạo nguyên m ẫu hoặc bằng chứng về
các hoạt động nhận thức nếu các khái niệm hoặc công ngh ệ
mới quan trọng có liên quan đ ến dịch vụ m ới để đảm bảo rằng
các thành phần m ới đáp ứng các k ỳ vọng của chúng.
 Đánh giá và lên chi phí cho các thi ết kế thay thế, có thể bao
gồm xác định các nhà cung c ấp tiềm năng và đánh giá các đ ề
xuất, công nghệ, giải pháp và h ợp đồng thay thế của họ. Cầ n
phải đảm bảo rằng chi phí bao g ồm chi phí m ột lần và chi phí
liên tục về vận hành và sở hữu, bao gồm cả hỗ trợ và bảo trì.
3.7.2 Mua sắm gi ải pháp ưu tiên

Có khả năng là không có y ếu tố bên ngoài được yêu cầu cho gi ải
pháp. Tuy nhiên, đây là đi ều không bình thường vì các nhà cung c ấp
phần m ềm ít nhất cũng có kh ả năng tham gia khá cao . Khi các nhà
cung cấp bên ngoài tham gia vào gi ải pháp được ưu tiên, các giai
đoạn bao gồm :
 Hoàn thành t ất cả các kiểm tra cần thiết đối với nhà cung cấp
được ưu tiên.
 Hoàn t ất các đi ều khoản và điều kiện của bất kỳ hợp đồng mới
nào, đảm bảo rằng tất cả các chính sách c ủa công ty được
thực thi
 Việc m ua sắm các giải pháp đã ch ọn.
3.7.3 Phát triển giải pháp dịch vụ

Giai đoạn phát tri ển bao gồm việc diễn giải Thiết kế Dịch vụ thành
m ột kế hoạch để phát triển, tái s ử dụng hoặc tái phát tri ển các thành
phần cần thiết để cung cấp dịch vụ và việc triển khai tiếp theo c ủa
dịch vụ đã được phát triển. Nó có thể cần được phát triển thành m ột
chương trình g ồm nhiều kế hoạch, nếu đây là m ột thay đổi lớn về
dịch vụ. Mỗi kế hoạch hoặc dự án trong chương trình s ẽ chịu trách
nhiệm cho việc cung c ấp m ột hoặc nhiều thành phần của dịch vụ và
sẽ bao gồm :
 Nhu cầu của doanh nghiệp.

 Chiến lược đã đư ợc thông qua để phát triển và m ua sắm giải
pháp.
 Khoảng thời gian liên quan.
 Các nguồn lực cần thiết, có tính đ ến cơ sở vật chất, cơ s ở hạ
tầng CNTT và k ỹ năng nhân s ự phù hợp để đảm bảo việc cung
cấp dịch vụ đáp ứng được nhu c ầu của khách hàng.
 Sự phát triển của dịch vụ và các thành ph ần cấu thành c ủa nó,
bao gồm cơ chế quản lý và cơ ch ế vận hành khác, ch ẳng hạn
như đo lường, giám sát và báo c áo.
 Các kế hoạch kiểm tra dịch vụ và các thành phần.
Quản lý dự án cẩn trọng sẽ cần được sử dụng để đảm bảo rằng

xung đột được tránh khỏi và các thành ph ần tương thích được phát
triển từ các hoạt động phát tri ển khác nhau.

81
3.8 Những ràng buộc thiết kế
Mọi hoạt động thiết kế vận hành với rất nhiều ràng buộc. Những
ràng buộc đó đến từ doanh nghiệp và Chiến lược Dịch v ụ và bao
trùm nhiều lĩnh vực khác nhau, như đư ợc m inh họa trong Hình 3.13.
Hình 3.13 – Những ràng buộc thiêt kế được định hướng bởi
chiến lược
Điều này có nghĩa r ằng các nhà thi ết kế không phải lúc nào cũng
‘rảnh rỗi’ để thiết kế giải pháp thích h ợp nhất cho doanh nghiệp, bởi
vì nó không nằm trong các ràng bu ộc bị áp đặt, như được m inh h ọa
trong Hình 3.13. H ạn chế rõ ràng nhất là vấn đề tài chính. Có thể
không có đủ ngân sách cho gi ải pháp thích hợp nhất, do đó, m ột
dịch vụ thay thế rẻ hơn sẽ phải được xác định và thỏa thuận với
doanh nghi ệp. Người thiết kế chỉ có thể cung c ấp giải pháp phù hợp
với tất cả các ràng buộc hiện đã biết, hoặc nếu không, hãy thử dỡ
bỏ hoặc thương lượng lại về m ột số ràng buộc - ví dụ: bằng cách thu
được ngân sách lớn hơn. Trong Hình 3.13, không ch ỉ cần thu thêm
ngân sách để triển khai các gi ải pháp m ong m uốn m à còn là không -
tuân thủ m ột số tiêu chuẩn và quy đ ịnh liên quan. Vì vậy, trong
trường hợp này, m ột giải pháp thay thế, rẻ hơn có thể được yêu
cầu.
Do đó các quy trình Thi ết kế Dịch vụ phải nhận ra m ột thực tế là

chúng được tự do thiết kế các giải pháp, nhưng l ại đang làm việc
trong m ột m ôi trường m à nhi ều yếu tố bên ngoài có thể ảnh hưởng
đến thiết kế.

82
Rất nhiều ảnh hưởng bên ngoài này là do nhu c ầu quản trị tốt công
ty và CNTT, và các tác đ ộng khác là t ừ yêu cầu tuân thủ các quy
định, luật pháp và tiêu chuẩn quốc tế, như được m inh họa trong
Hình 3.14. Do đó, đi ều thiết yếu là tất cả các nhà thi ết kế nhận thức
được những điều này và đảm bảo rằng các thiết kế và giải pháp m à
họ đưa ra có tất cả các kiểm soát và năng l ực cần thiết bên trong
chúng.
3.9 Kiến trúc định hướng dịch vụ

Quy trình và các gi ải pháp nghi ệp vụ cần được thiết kế và phát tri ển
bằng cách sử dụng m ột phương pháp ti ếp cận Kiến trúc Định hướng
Dịch vụ (SOA). Phương pháp ti ếp cận SOA được coi là thực tiễn tốt
nhất và được sử dụng bởi rất nhiều tổ chức để cải thiện hiệu suất và
hiệu quả của họ trong vi ệc cung c ấp các dịch vụ CNTT.
SOA được OASIS (www.oasis -open.org) định nghĩa là:
‘Một m ô hình đ ể tổ chức và sử dụng các năng lực phân tán có thể
nằm dưới sự kiểm soát của các lĩnh vực quyền sở hữu khác nhau.
Nó cung cấp m ột phương tiện thống nhất để cung cấp, khám phá,
tương tác và s ử dụng các năng lực để tạo ra các hi ệu ứng m ong
m uốn phù hợp với các điều kiện tiên quyết và kỳ vọng có thể đo
lường được.'

83
OASIS (Tổ chức vì Sự tiến bộ của các Tiêu chu ẩn Thông tin có C ấu
trúc – Organization for the Advancement of Structured Inform ation
Standards) là m ột tập đoàn quốc tế phi lợi nhuận thúc đẩy sự phát
triển, hội tụ và áp dụng các tiêu chuẩn doanh nghi ệp điện tử. SOA
m ang lại giá tr ị và sự nhanh nhạy cho tổ chức bằng cách khuyến
khích phát tri ển các dịch vụ 'khép kín' có th ể tái sử dụng được. Đến
lượt nó, điều này lại thúc đẩy m ột phương pháp tiếp cận theo ki ểu
m ô-đun và linh ho ạt để phát triển ‘các dịch vụ được chia sẻ’ có thể
được sử dụng trong rất nhiều lĩnh vực khác nhau của doanh nghi ệp.
Ngày càng có nhi ều tổ chức đang chuyển đổi các quy trình nghi ệp
vụ sang các ‘d ịch vụ được đóng gói’ phổ biến có thể được sử dụng
và chia s ẻ cho nhiều lĩnh vực kinh doanh.
Bất cứ khi nào có thể, các t ổ chức cung cấp dịch vụ CNTT nên s ử
dụng SOA và các nguyên t ắc để phát triển các dịch vụ CNTT linh
hoạt, có thể tái s ử dụng được phổ biến và có thể được chia s ẻ và
khai thác trên nhi ều lĩnh vực khác nhau của doanh nghi ệp. Khi
phương pháp này đư ợc sử dụng, điều thiết yếu là CNTT ph ải:
 Định nghĩa và xác đ ịnh dịch vụ là gì.

 Hiểu và xác định rõ ràng các giao di ện và sự phụ thuộc giữa
các dịch vụ.
 Sử dụng các t iêu chuẩn để phát triển và định nghĩa các dịch
vụ.
 Sử dụng công ngh ệ và bộ các công cụ phổ biến.
 Điều tra và hi ểu tác động của những thay đổi đối với 'dịch vụ
được chia s ẻ'.
 Đảm bảo rằng đào tạo liên quan đến SOA đã đư ợc lên kế
hoạch và đạt được cho nhân viên CNTT nhằm thiết lập m ột
ngôn ngữ chung và cải thiện việc triển khai và h ỗ trợ các dịch
vụ m ới hoặc đã được thay đổi.
Khi các nguyên t ắc SOA được sử dụng bởi tổ chức cung c ấp dịch vụ
CNTT, điều quan tr ọng là m ột Mục lục Dịch vụ chính xác ph ải được
duy trì như m ột phần của Hệ thống Quản lý Cấu hình (CMS) và Danh
m ục Dịch vụ tổng thể. Việc áp dụng phương pháp ti ếp cận này có
thể làm giảm đáng kể thời gian cung cấp các giải pháp m ới cho
doanh nghi ệp và hướng tới năng lực Quản lý Dịch vụ Nghiệp vụ
(BSM). Mục lục Dịch vụ cũng sẽ hiển thị m ối quan hệ giữa các d ịch
vụ và ứng dụng. Một ứng dụng duy nhất có thể là m ột phần củ a
nhiều dịch vụ và m ột dịch vụ duy nhất có thể sử dụng nhiều ứng
dụng.
3.10 Quản lý Dịch vụ Nghiệp vụ

Quản lý Dịch vụ Nghiệp vụ (BSM) là m ột chiến lược và m ột phương
pháp tiếp cận cho phép các thành ph ần CNTT được liên kết với các
m ục tiêu c ủa doanh nghi ệp. Bằng cách này, c ả tác động của công
nghệ đối với doanh nghi ệp và sự thay đổi của doanh nghi ệp có thể
tác động đến công ngh ệ như thế nào đều có t hể dự đoán được. Việc
tạo ra m ột Bản Mục dịch vụ được tích hợp hoàn toàn - bao gồm các
đơn vị kinh doanh, quy trình và d ịch vụ cũng như các m ối quan h ệ

84
và sự phụ thuộc của chúng vào các dịch vụ, công nghệ và thành
phần CNTT - là điều rất quan trọng để gia tăng năng l ực cung c ấp
BSM của nhà cung cấp dịch vụ CNTT. Mọi khía c ạnh của Thiết kế
Dịch vụ là yếu tố quan trọng trong vi ệc hỗ trợ và tăng cư ờng năng
lực Quản lý Dịch vụ Nghiệp vụ của nhà cung c ấp dịch vụ CNTT, đặc
biệt là thiết kế Danh m ục Dịch vụ, Mục lục Dịch vụ và các dịch vụ
CNTT riêng l ẻ. Tất cả các hoạt động này cũng s ẽ cải thiện sự liên
kết giữa việc cung cấp dịch vụ CNTT với hoạt động kinh doanh và
nhu cầu phát triển của nó. Xem Hình 3.15.
BSM cho phép t ổ chức cung c ấp dịch vụ CNTT:
 Liên kết việc cung cấp dịch vụ CNTT với các m ục tiêu và m ục
đích kinh doanh.
 Ưu tiên t ất cả các hoạt động CNTT về tác động và m ức độ
khẩn cấp đối với doanh nghi ệp, đảm bảo các quy trình và d ịch
vụ kinh doanh quan tr ọng nhận được sự quan tâm nhi ều nhất.
 Tăng năng su ất kinh doanh và lợi nhuận thông qua vi ệc gia
tăng hiệu quả và hiệu suất của các quy trình CNTT.
 Hỗ trợ các yêu c ầu về quản trị doanh nghiệp với việc quản trị
và kiểm soát CNTT thích h ợp.
 Tạo ra lợi thế cạnh tranh thông qua vi ệc khai thác và đ ổi m ới
cơ sở hạ tầng CNTT nói chung.
 Nâng cao ch ất lượng dịch vụ, sự hài lòng của khách hàng và
nhận thức của người sử dụng.
 Đảm bảo tuân thủ quy định và pháp lu ật
 Đảm bảo m ức độ bảo vệ thích hợp đối với m ọi tài sản CNTT
và tài s ản thông tin.
 Đảm bảo rằng các dịch vụ CNTT được liên k ết và sẽ tiếp tục
liên kết với nhu c ầu kinh doanh đang thay đ ổi.
Hình 3.15 m inh họa m ối quan hệ giữa các hoạt động dịch vụ và
Quản lý Dịch vụ, phạm vi tiếp cận và phạm vi m à họ cung cấp giá trị
cho Doanh nghi ệp và CNTT.

85
Hình 3.15 – Quản lý CNTT liên tục
3.11 Các mô hình Thi ết kế Dịch vụ

Mô hình được lựa chọn để thiết kế các dịch vụ CNTT sẽ phụ thuộc
chủ yếu vào m ô hình được chọn để cung cấp các dịch vụ CNTT.
Trước khi áp dụng m ô hình thi ết kế cho m ột dịch vụ m ới lớn, cần
tiến hành xem xét khả năng và các điều khoản hiện tại đối với tất cả
các khía cạnh của việc cung c ấp dịch vụ CNTT. Đánh giá này c ần
xem xét tất cả các khía c ạnh của dịch vụ m ới, bao gồm :
 Các yêu c ầu và định hướng kinh doanh.

 Phạm vi và năng l ực của đơn vị cung c ấp dịch vụ hiện tại.
 Nhu cầu, đích nh ắm m ục tiêu và yêu c ầu của dịch vụ m ới.
 Phạm vi và năng l ực của các nhà cung c ấp bên ngoài.
 Sự trưởng thành c ủa các tổ chức hiện đang tham gia và các
quy trình c ủa họ.
 Văn hóa của các t ổ chức có liên quan.
 Cơ sở hạ tầng CNTT, ứng dụng, dữ liệu, dịch vụ và các thành
phần khác có liên quan.
 Mức độ quản trị doanh nghi ệp và quản trị CNTT và m ức độ sở
hữu và kiểm soát c ần thiết.
 Ngân sách và tài nguyên có s ẵn.
 Trình độ và kỹ năng của nhân viên.
Sự xem xét/đánh giá này cung c ấp m ột cơ chế có cấu trúc để xác

định năng lực và tr ạng thái s ẵn sàng của m ột tổ chức để cung cấp
các dịch vụ m ới hoặc đã được sửa đổi nhằm hỗ trợ các yêu cầu và
định hướng kinh doanh đã xác đ ịnh. Thông tin có đư ợc từ đánh giá

86
như vậy có thể được sử dụng để xác định chiến lược cung cấp đố i
với m ột dịch vụ CNTT hoặc hệ thống CNTT cụ thể. Chiến lược cung
cấp là phương pháp ti ếp cận được thực hiện để chuyển m ột tổ chức
từ trạng thái đã biết, dựa trên đánh giá v ề tính sẵn sàng, sang tr ạng
thái m ong m uốn, được xác định bởi các nhu cầu và định hướng và
nhu cầu kinh doanh. Có nhi ều cách để chuẩn bị cho m ột tổ chức
trong việc triển khai m ột dịch vụ m ới. Phương pháp và chi ến lược
được lựa chọn nên dựa trên giải pháp m à tổ chức chọn để thực hiện
các định hướng kinh doanh chính c ủa mình, cũng như năng l ực củ a
tổ chức CNTT và các đ ối tác của nó. Quy m ô của các tùy ch ọn có
sẵn là khá lớn và không ph ải m ọi lựa chọn đều cần được xem xét
trong m ọi trường hợp. Tuy nhiên, vi ệc giữ cho tất cả các tùy chọn có
sẵn để xem xét là chìa khóa đ ể thiết kế và vận hành các giải pháp
sáng tạo cho những thách th ức kinh doanh khó khăn nh ất. Cuối
cùng, đây có th ể là sự khác biệt giữa một dự án thất bại - hoặc thậm
chí m ột công ty th ất bại - và m ột dự án thành công.
Hai m ô hình này, dành cho thi ết kế và cung cấp các dịch vụ CNTT,
có liên quan ch ặt chẽ với nhau và được xem xét trong hai ph ần sau
đây.
3.11.1 Các lựa chọn mô hình cung cấp

Mặc dù đánh giá tính s ẵn sàng xác định lỗ hổng giữa những năng
lực hiện tại và năng l ực m ong m uốn, m ột tổ chức CNTT không nh ất
thiết phải cố gắng để tự m ình thu hẹp khoảng cách đó. Có r ất nhiều
chiến lược cung c ấp khác nhau có th ể được sử dụng. Mỗi m ột trong
số chúng có m ột bộ các ưu và khuyết điểm của m ình, nhưng t ất cả
đều đòi hỏi m ột vài m ức độ thích ứng và tùy ch ỉnh cho tình hu ống
hiện tại. Bảng 3.2 li ệt kê các th ể loại chính về các chiến lược nguồ n
cung ứng cùng với m ột tóm tắt ngắn cho m ỗi thể loại. Các thực tiễn
cung cấp có khuynh hư ớng rơi vào m ột trong những thể loại này
hoặc m ột số biến thể của chúng.
Chiến lược cung Mô tả

cấp
Nội bộ Phương pháp ti ếp cận này dựa trên việc sử
dụng các nguồn lực nội bộ của tổ chức trong
việc thiết kế, phát triển, chuyển tiếp, duy trì,
vận hành và/hoặc hỗ trợ các dịch vụ m ới
hoặc đã được điều chỉnh hoặc vận hành trung
tâm dữ liệu
Thuê ngoài Phương pháp tiếp cận này s ử dụng nguồn lực
từ m ột tổ chức hoặc các tổ chức bên ngoài
theo m ột thỏa thuận chính thức để cung cấ p
các phần được xác định-rõ ràng về thiết kế,
phát triển, duy trì, vận hành và/ho ặc hỗ trợ
m ột dịch vụ. Điều này bao gồm sự tiêu thụ
dịch vụ từ các Nhà cung cấp Dịch vụ Ứng
dụng (ASPs) được m ô tả dưới đây.

87
Đồng-cung ứng Thường là m ột sự kết hợp giữa nội bộ và
thuê ngoài, sử dụng m ột số các t ổ chức thuê
ngoài làm việc cùng với nhau để cùng cung
ứng các phẩn tử chủ yếu trong vòng đ ời. Nói
chung thì việc này liên quan t ới việc sử dụng
m ột số các t ổ chức bên ngoài làm vi ệc cùng
nhau để thiết kế, phát triển, chuyển tiếp, duy
trì, vận hành và/hoặc hỗ trợ m ột phần của
m ột dịch vụ.
Đối tác hoặc đa- Các thỏa thuận chính thức giữa hai ho ặc
nguồn cung ứng nhiều tổ chức để làm việc cùng nhau đ ể thiết
kế, phát triển, chuyển tiếp, duy trì, vận hành
và/hoặc hỗ trợ (các) dịch vụ CNTT. Tr ọng tâm
ở đây là khuynh hướng trở thành đối tác
chiến lược để tận dụng chuyên m ôn quan
trọng hoặc cơ hội thị trường.
Thuê ngoài Quy trình Khuynh hướng ngày càng tăng c ủa việc di dời
Nghiệp vụ (BPO) toàn bộ các chức năng nghi ệp vụ bằng các h
sử dụng các thỏa thuận chính thức giữa các
tổ chức nơi m ột tổ chức cung c ấp và quản lý
(các) quy trình nghi ệp vụ hoặc (các) ch ức
năng của tổ chức kia ở m ột địa điểm có chi
phí thấp. Các ví d ụ phổ biến là hoạt động kế
toán, tính lương và trung tâm cu ộc gọi.
Cung cấp Dịch vụ Bao gồm các thỏa thuận chính thức với m ột
Ứng dụng tổ chức Nhà cung cấp Dịch vụ Ứng dụng
(ASP) sẽ cung cấp các dịch vụ dựa trên m áy
tính dùng chung cho các t ổ chức của khách
hàng qua m ạng. Các ứng dụng được cung
cấp theo cách này đôi khi cũng đư ợc gọi là
phần m ềm /ứng dụng theo yêu c ầu. Thông qua
ASP, sự phức t ạp và chi phí c ủa phần m ềm
dùng chung như v ậy có thể được giảm bớt và
cung cấp cho các tổ chức không th ể biện
m inh cho vi ệc đầu tư.
Thuê ngoài Quy trình Hình thức thuê ngoài m ới nhất, KPO đi trước
Kiến thức (KPO) BPO m ột bước về m ột khía cạnh nào đó. Các
tổ chức KPO cung c ấp các quy trình dựa trên-
lĩnh vực và chuyên m ôn k inh doanh thay vì
chỉ chuyên m ôn về quy trình, và đòi h ỏi các
kỹ năng phân tích và chuyên m ôn hóa nâng
cao từ tổ chức thuê ngoài.
Bảng 3.2 – Các chiến lược cung c ấp dịch vụ chính
Bảng 3.2 nêu b ật một điểm chính: t ập hợp các chiến lược phân ph ối
rất khác nhau và có phạm vi từ m ột tình hu ống tương đ ối đơn gi ản,

88
chỉ được quản lý trong ranh gi ới của m ột công ty, cho đ ến m ột tình
huống KPO đầy đủ. Phạm vi rộng rãi của nhiều lựa chọn thay thế
này cung c ấp tính linh ho ạt đáng k ể, nhưng thường có thêm sự phức
tạp, và trong m ột số trường hợp có thêm rủi ro bổ sung. Ưu đi ểm và
nhược điểm của t ừng loại chiến lược phân phối được thảo luận
trong Bảng 3.3 dưới đây.
Tất cả các sắp xếp trên có thể được cung cấp trong c ả tình huống
off-shore hoặc on-shore. Trong trường hợp on-shore, cả hai t ổ chức
đều có tr ụ sở trong cùng m ột quốc gia/châu l ục, trong khi với trường
hợp off -shore, các t ổ chức ở các quốc gia/châu l ục khác nhau. Các
thỏa thuận tìm ngu ồn cung ứng rất phức tạp tồn tại trong ngành
công nghệ thông tin và không th ể bao hàm tất cả các kết hợp và ý
nghĩa c ủa chúng ở đây. Loạt bài Bổ sung Thực tiễn Quản lý Dịch vụ
ITIL sẽ cung cấp thêm hướng dẫn về các chiến lược tìm ngu ồn cung
ứng.
Sáp nhập và m ua l ại cũng có th ể làm phức tạp thêm các vấn đề.
Những tình huống này xảy ra khi m ột công ty m ua l ại hoặc sáp nhập
với m ột công ty khác đ ể hoán đổi tiền m ặt và/hoặc vốn cổ phần của
cổ phiếu của công ty. Một lần nữa, điều này thường xảy ra để đáp
ứng với việc hợp nhất ngành, m ở rộng thị trường hoặc phản ứng
trực tiếp với áp lực cạnh tranh. N ếu các công ty có các chi ến lược
cung cấp dịch vụ khác nhau đư ợc m ua lại hoặc hợp nhất, m ột giai
đoạn xem xét và h ợp nhất thường được đòi hỏi để xác định chiến
lược tìm nguồn cung ứng phù hợp nhất cho t ổ chức m ới được sáp
nhập. Tuy nhiên, sáp nhập và m ua lại thường có thể cung cấp cho
các t ổ chức cơ hội củng cố thực tiễn t ốt nhất từ mỗi tổ chức, t ừ đó
cải thiện năng lực dịch vụ tổng thể và đạt được sự hiệp lực trong
toàn bộ tổ chức. Cơ hội cũng s ẽ tồn tại để cung cấp các lựa chọn
phát triển nghề nghiệp được cải thiện cho nhân viên Qu ản lý Dịch vụ
và hợp nhất hợp đồng cung cấp các dịch vụ.
3.11.2 Các lựa chọn thiết kế và phát tri ển

Các chiến lược cung cấp liên quan đ ến cả giai đoạn thiểt kế lẫn
chuyển tiếp của Vòng đời Dịch vụ cũng như là giai đo ạn vận hành.
Phải đặc biệt cẩn tr ọng khi lựa chọn các chi ến lược khác nhau cho
các giai đoạn khác nhau c ủa vòng đời để đảm bảo rằng m ọi tổ chức
liên quan hiểu m ột cách rõ ràng v ề các vai trò và trách nhi ệm riêng
lẻ của họ, và đồng thời về vai trò và trách nhi ệm của các tổ chức
khác để đảm bảo rằng sự chấp thuận và bàn giao các quy trình đã
được xác định, thỏa thuận và chấp nhận m ột cách rõ ràng.

89
Một ngân hàng quy m ô trung bình đã sáp nh ập với m ột ngân hàng
khác có m ột danh m ục sản phẩm bổ sung. Do đó s ự tích hợp các
ứng dụng đã rất đơn giản. Tuy nhiên, cả hai ngân hàng đ ều cảm
thấy rằng sự hợp nhất các hoạt động sẽ có lợi nhưng có thể sẽ
không t ận dụng được tính kinh t ế của quy m ô ở m ột phạm vi đầy
đủ. Việc thuê ngoài cũng là m ột lựa chọn, nhưng thay vào đó, hai
ngân hàng đã chọn hợp tác với m ột công ty cho thuê ngoài. Các
ngân hàng cung c ấp kiến thức cụ thể-về ngân hàng để làm cho t ổ
chức dịch vụ CNTT của họ trở thành m ột trung tâm dữ liệu hấp
dẫn cho các ngân hàng nh ỏ hơn. Đối tác thuê ngoài đã cung c ấp
chuyên m ôn công ngh ệ cần thiết và những khách hàng m ới để
được hưởng lợi từ tính kinh t ế của quy m ô.
Vậy, làm thể nào để m ột tổ chức xác định được chiến lược cung c ấp
tối ưu? Không có m ột câu trả lời duy nhất hoặc đơn giản cho câu h ỏi
này. Nó quá ph ụ thuộc vào tình huống độc đáo và c ụ thể cần xem
xét. Vì lý do này, hư ớng dẫn thích hợp nhất có thể được cung c ấp là
m ô tả những ưu đi ểm và khuyết điểm chính c ủa m ỗi chiến lược cung
cấp. Đến lượt nó, vi ệc này có th ể được sử dụng như là m ột danh
sách kiểm tra để xác định phương pháp ti ếp cận phân ph ối nào nên
được đánh giá thêm và m ang l ại lợi ích nhi ều nhất cho dự án hoặc
sáng kiến kinh doanh c ụ thể. Bảng 3.3 liệt kê m ỗi chiến lược và các
ưu khuyết điểm chính c ủa nó trong việc cung c ấp m ột ứng dụng
hoặc dịch vụ CNTT.
Chiến lược cung cấp Ưu điểm Khuyết điểm

Nội bộ Kiểm soát trực tiếp. Giới hạn quy m ô.
Tự do lựa chọn. Chi phí và thời gian tiếp
Nhanh chóng tạo nguyên m ẫu thị cho các d ịch vụ có
của các dịch vụ tiên tiến nhất. sẵn bên ngoài.
Các chính sách và th ủ tục Phụ thuộc vào tài nguyên
quen thuộc. nội bộ và kỹ năng và
năng lực của họ.
Kiến thức cụ thể của công ty.
Thuê ngoài Tính kinh t ế của quy m ô. Ít kiểm soát tr ực tiếp.
Chuyên m ôn được m ua. Các rào c ản thoát ra.
Hỗ trợ tập trung vào năng l ực Rủi ro về khả năng thanh
cốt lõi của công ty. toán của nhà cung c ấp.
Hỗ trợ cho những nhu cầu Không rõ về kỹ năng và
ngắn ngủi. năng lực của nhà cung
Kiểm nghiệm thử/dùng thử cấp.
các dịch vụ m ới. Nhiều thách th ức hơn
trong việc tích hợp quy
trình nghi ệp vụ.
Quản trị và xác m inh
được tăng cường.
Đồng-cung ứng Thời gian để tiếp thị. Dự án phức tạp.

90
Chuyên m ôn được t ận dụng. Bảo vệ tài s ản trí tuệ và
Kiểm soát. quyền sở hữu trí tuệ.
Sử dụng các nhà cung c ấp Xung đột văn hóa gi ữa
được chuyên m ôn hóa. các công ty.
Đối tác hoặc đa-nguồn Thời gian để tiếp thị. Dự án phức tạp.
cung ứng Xâm nhập/m ở rộng thị Bảo vệ tài s ản trí tuệ và
trường. quyền sở hữu trí tuệ.
Phản ứng với đối thủ cạnh Xung đột văn hóa gi ữa
tranh. các công ty.
Chuyên m ôn được t ận dụng.
Tin tưởng, liên kết và lợi ích
qua lại lẫn nhau.
Các thỏa thuận ‘Rủi ro và
phần thưởng’.
Thuê ngoài Quy trình Điểm đơn trách nhi ệm . Xung đột văn hóa gi ữa
Nghiệp vụ (BPO) ‘Cửa hàng m ột điểm -dừng’. các công ty.
Tiếp cận với những kỹ năng Mất kiến thức kinh
đặc biệt. doanh.
Rủi ro được chuyển cho nhà Mất m ối quan hệ với
cung cấp cho thuê ngoài. doanh nghiệp.
Vị trí chi phí th ấp.
Cung cấp Dịch vụ Ứng Tiếp cận với những dự án Xung đột văn hóa gi ữa
dụng phức tạp và toàn di ện. các công ty.
Vị trí chi phí th ấp. Tiếp cận với chỉ các
Bao gồm hỗ trợ và nâng cấp. phương ti ện chứ không
phải là kiến thức.
Bao gồm các lựa chọn bảo
m ật và ITSCM. Thường là các m ô hình
tính phí d ựa trên-sử
dụng.
Thuê ngoài Quy trình Tiếp cận với kỹ năng, ki ến Xung đột văn hóa gi ữa
Kiến thức (KPO) thức và chuyên m ôn đặc biệt. các công ty.
Vị trí chi phí th ấp. Mất chuyên m ôn nội bộ.
Tiết kiệm chi phí đáng k ể. Mất m ối quan hệ với
doanh nghiệp.
Bảng 3.3 – Ưu và khuyết điểm của các chiến lược cung c ấp dịch vụ
Chiến lược đã đư ợc chọn sẽ phụ thuộc vào năng l ực và nhu cầu của
tổ chức cụ thể, việc kinh doanh và con ngư ời của họ - văn hóa và
năng lực. Dù cho chi ến lược nào được lựa chọn thì sự thành công
và hoạt động của nó nên được đo lường và xem xét m ột cách
thường xuyên về hiệu quả và hiệu suất và được áp dụng để phù hợp
với các nhu c ầu kinh doanh đang thay đ ổi. Lựa chọn đã được thông

91
qua liên quan t ới việc cung cấp dịch vụ CNTT có thể thường bị ảnh
hưởng bởi văn hóa t ổng thể của doanh nghi ệp và phương pháp ti ếp
cận của họ đối với việc thuê ngoài và quan h ệ đối tác.
3.11.3 Các phương pháp ti ếp cận thi ết kế và phát tri ển

Một điều cũng không kém ph ần quan trọng là hiểu rõ các loại vòng
đời, phương pháp và phương pháp ti ếp cận khái quát hiện tại đ ối
với việc phát triển dịch vụ CNTT, nhằm để quyết định các tiêu chu ẩn
đối với giai đoạn Thiết kế Dịch vụ của vòng đời. Để đạt được điều
này, cần phải thấu hiểu rõ ràng về các khía c ạnh dưới đây c ủa
những phương pháp ti ếp cận Vòng đời Phát triển Dịch vụ (SDLC)
khác nhau:
 Cấu trúc (ví d ụ, các m ốc thời gian/giai đo ạn/thời kỳ).

 Các hoạt động (ví dụ, luồng công việc hoặc các bước/tác vụ
đã được m ô tả trong m ột phương pháp tiếp cận).
 Các m ô hình chính đư ợc liên k ết với phương pháp đư ợc chọn,
thông thường đưa ra m ột quan điểm quy trình, m ột quan điểm
dữ liệu, m ột quan điểm sự kiện và, thư ờng là, m ột quan đi ểm
người sử dụng. Các ví d ụ bao gồm biểu đồ trường hợp sử
dụng, biểu đồ lớp và các biểu đồ trạng thái từ Ngôn ng ữ Mô
hình hóa Hợp nhất (Unified Modelling Language – UML).
Chi tiết hơn về SDLC nằm trong Chương 5.
3.11.3.1 Phát triển ứng dụng nhanh chóng

Cần phải hiểu sự khác biệt giữa phát triển các hệ thống hướng-đối
tượng và các hệ thống có cấu trúc, các nguyên t ắc cơ bản của
phong trào 'Agile' (Phát tri ển Ứng dụng Nhanh chóng (RAD) ho ặc
phát triển tăng t ốc là các thuật ngữ khác được sử dụng trong lĩnh
vực này) và nhận biết về các m ột cam kết đối với m ột giải pháp gói
phần m ềm làm thay đổi cấu trúc của phương pháp tiếp cận như th ế
nào.
Theo m ặc định, những phương pháp ti ếp cận này chỉ giải quyết m ột
hệ thống đơn lẻ (và các dịch vụ liên quan), có thể được bổ sung
bằng các phương pháp ti ếp cận kiến trúc, chẳng hạn như các
phương pháp tiếp cận dựa trên việc tái sử dụng dựa trên-thành ph ần
(xem thêm phần về kiến trúc để thảo luận thêm ).
Mô hình vòng đời ứng dụng được m ô tả trong phần Quản lý Ứng
dụng (phần 5.1.3) có th ể được xem như là m ột ví dụ về phương
pháp tiếp cận dựa trên tuyến tính ho ặc 'thác nước' (hoặc m ô hình
'V') và s ẽ không được thảo luận chi tiết hơn ở đây, khác hơn cho
m ục đích so sánh v ới các cách tiếp cận khác.
Chức năng chính c ủa RAD là giới thiệu các bước tăng dần và lặp đi
lặp lại trong quá trình phát tri ển để quản lý các rủi ro liên quan đến
sự không chắc chắn và các yêu c ầu thay đổi. Các phương pháp ti ếp
cận truyền thống đã giả định rằng m ột bộ các yêu c ầu đầy đủ có thể
được xác định sớm trong vòng đ ời và rằng chi phí phát tri ển có thể
được kiểm soát bằng cách quản lý s ự thay đổi. Tuy nhiên, không

92
khuyến khích thay đ ổi có thể có nghĩa là tr ở nên không đáp ứng các
điều kiện kinh doanh. Nh ững phương pháp ti ếp cận RAD chấp nhậ n
rằng thay đổi là không th ể tránh khỏi và cố gắng giảm thiểu chi phí
cho việc đáp ứng chúng trong khi v ẫn giữ được chất lượng được yêu
cầu.
Việc sử dụng các ph ần gia tăng có ngụ ý rằng m ột dịch vụ được

phát triển từng phần m ột, trong đó m ọi phần đều có thể hỗ trợ m ột
trong các chức năng nghi ệp vụ m à toàn bộ dịch vụ cần. Cung c ấp
gia tăng d ần có th ể dẫn đến thời gian đưa vào th ị trường ngắn hơn
đối với các chức năng kinh doanh c ụ thể. Sự phát triển của m ọi gia
số đòi hỏi phải trải qua m ọi giai đoạn của vòng đời.
Phát triển lặp đi lặp lại có ngụ ý rằng vòng đời sẽ được xem xét k ỹ
lưỡng nhiều lần, theo thiết kế. Các k ỹ thuật chẳng hạn như tạ o
nguyên m ẫu được sử dụng để hiểu rõ hơn về các yêu cầu (bằng
cách kiểm nghiệm các hoạt động chức năng, qu ản lý và vận hành và
thông qua giao ti ếp với người sử dụng).
Sự kết hợp các phương pháp ti ếp cận lặp đi lặp lại và gia tăng d ần
là hoàn toàn kh ả thi. Có th ể bắt đầu với đặc tả kỹ thuật về các yêu
cầu cho toàn bộ dịch vụ, tiếp theo là th iết kế và phát tri ển ứng dụng
gia tăng dần.
Các phương pháp phát tri ển RAD, bao g ồm cả Quy trình được Hợp
nhất và Phương pháp Phát tri ển Hệ thống Động (DSDM) được xem
như ứng phó đối với các k ỳ vọng của doanh nghiệp, với m ục tiêu
giảm chi phí c ủa sự thay đổi trong suốt m ột dự án phát tri ển. DSDM
sử dụng sự tham gia liên t ục của người sử dụng trong m ột phương
pháp tiếp cận gia tăng d ần và phát tri ển lặp đi lặp lại, đáp ứng các
yêu cầu thay đổi, để phát triển m ột hệ thống phần m ềm thỏa m ãn
các yêu c ầu kinh do anh đúng thời gian và ngân sách. M ột ví d ụ
khác, Lập trình Cực độ - Extrem e Program ing (XP), kêu g ọi các nhà
phát triển:
 Sản xuất dịch vụ đầu tiên cung cấp trong vài tuần, để đạt
được chiến thắng sớm và phản hồi nhanh chóng.
 Phát m inh ra các gi ải pháp đơn giản, do đó ít ph ải sửa đổi hơn
và cũng t ạo điều kiện cho sự thay đổi.
 Cải thiện chất lượng thiết kế liên tục
 Kiểm tra sớm để tìm ra lỗi theo cách ít t ốn kém hơn.
 Sử dụng các nguyên t ắc cơ bản chẳng hạn như đánh giá, thi ết
lập cấu hình và qu ản lý thay đổi để giữ quyền kiểm soát.
Để sử dụng tốt m ột phương pháp tiếp cận gia tăng, quá trình thi ết
kế cần phải được dựa trên cơ sở tách biệt các m ối quan tâm , bằng
cách nhóm các chức năng trong các bư ớc tăng dần theo cách gi ảm
thiểu sự phụ thuộc lẫn nhau c ủa chúng.
Nói chung, các phương pháp phát tri ển ứng dụng tăng tốc áp dụng
m ột m ô hình vòng đ ời ba–giai đoạn: phân tích và thi ết kế được tăng
tốc, phát tri ển và s ản xuất và triển khai theo khung th ời gian. Các

93
phương pháp này thư ờng được củng cố bởi công nghệ kỹ thuật phần
m ềm và dựa vào quá trình làm vi ệc và tạo m ẫu chung (người sử
dụng - CNTT) để xác định m ột cách nhanh chóng các yêu c ầu và tạo
ra m ột nguyên m ẫu hoạt động.
Từ góc độ kinh doanh, việc sử dụng phát tri ển và cung cấp gia tăng
dần bởi các nhà phát triển có nghĩa là m ột phần hợp lệ, riêng bi ệt
của dịch vụ tổng thể có thể được cung cấp trước khi nhóm phát tri ể n
có thể hoàn thành toàn b ộ dự án. Phương pháp ti ếp cận này m ang
lại lợi ích ban đ ầu cho doanh nghiệp và cung c ấp m ột cơ hội cho c ả
nhóm doanh nghiệp lẫn nhóm phát triển khám phá các thu ộc tính
của dịch vụ m ới nổi và học hỏi từ trải nghiệm của họ. Tuy nhiên,
thường sẽ rất khó để tìm ra m ột khoản gia tăng đầu tiên đủ nhỏ có
thể cung cấp m ột dịch vụ có ý nghĩa cho doanh nghi ệp.
Các phương pháp RAD bao gồm sự lặp lại và cung c ấp gia tăng d ần
có thể được sử dụng để giảm cả rủi ro trong phát tri ển lẫn triển khai.
Các dự án thực tế không nhất thiết phải dễ quản lý hơn, nhưng
chúng có thể tạo điều kiện thuận lợi cho việc triển khai và nghi ệm
thu. Chúng cung cấp nhiều lựa chọn hơn để dự phòng và cho phép
các nhà phát triển ứng phó với các yêu c ầu kinh doanh và đi ều kiệ n
m ôi trường đang thay đổi. Chúng cũng cung c ấp cả các cột m ốc
quan trọng và những điểm quyết định cho m ục đích kiểm soát d ự án.
Ngoài ra, các phương pháp này còn có th ể được sử dụng để:
 Tiếp cận hoặc hội tụ trên m ột thiết kế có thể được khách hàng
chấp nhận và khả thi đối với nhóm phát triển.
 Hạn chế sự tiếp xúc của dự án với các yếu tố không thể đoán
trước của cả hoạt động kinh doanh và thay đ ổi m ôi trường.
 Tiết kiệm thời gian phát tri ển, m ặc dù đối với m ột dự án RAD
thành công, m ột cái gì đó khác với lịch trình phải được thương
lượng. (RAD có cơ hội thành công t ốt nhất nếu doanh nghi ệp
sẵn sàng thương lư ợng về cả chức năng và ch ất lượng).
Các ràng buộc đối với Phát triển Ứng dụng Nhanh chóng (RAD) ho ặc
các Yếu tố Thành công Quan tr ọng (CSF) bao gồm :
 'Phù hợp với m ục đích kinh doanh' là tiêu chí đ ể chấp nhận
các sản phẩm có thể được chuyển giao.
 Đại diện của tất cả các bên có thể ảnh hưởng đến các yêu cầu
ứng dụng trong su ốt quá trình phát tri ển.
 Khách hàng, các nhà phát tri ển và c ấp quản lý chấp nhận các
sản phẩm có thể chuyển giao không chính th ức, ví dụ: ghi chú
từ hội thảo của người sử dụng thay vì tài liệu yêu c ầu chính
thức.
 Tạo tài liệu t ối thiểu cần thiết để tạo điều kiện cho vi ệc phát
triển và bảo trì trong tương lai.
 Trao quyền cho các nhóm phát tri ển để đưa ra quyết định theo
truyền thống vốn được giao cho quản lý.
 Sự lặp lại được sử dụng theo cách h ội tụ để hướng tới m ột
giải pháp kinh doanh có thể chấp nhận được.

94
Các nguyên m ẫu có thể kết hợp các yêu c ầu đang phát triển

m ột cách nhanh chóng, đ ể sớm đạt được sự đồng thuận trong
vòng đời.
Việc sử dụng RAD đòi hỏi các nhóm có k ỹ năng, đa ngành, nh ững
người có khả năng tư vấn về thời điểm áp dụng phương pháp ti ếp
cận này.
Thể loại Phát triển thông thường Phát triển tăng tốc
Phương pháp ti ếp Các giai đo ạn có tr ình t ự. Tiến triển dần dần.
cận chung
Cam k ết tài nguyên ±15% trong toàn b ộ dự án. 100% trong toàn b ộ dự án
người sử dụng đối với nhà bảo trợ dự án,
±30% đối với những người
được chọn khác.
Rủi ro Cao hơn – các vấn đề của dự án Thấp hơn – các vấn đề
dài hạn có thể không xu ất hiện xuất hiện từ đầu trong quá
cho đến khi dự án đến giữa giai trình phát triển, đòi hỏi các
đoạn phát triển. giải pháp nhanh chóng.
Bảo trợ của c ấp điều Có thẩm quyền phê duyệt nhưng Mứ c độ tham gia cao –
hành không tham gia m ột cách t ích thiết lập phạm vi, xem xét
cực. tiến độ và giải quyết sự cố.
Sử dụng các k ỹ thuật Tùy chọn. Bắt buộc.
tạo nguyên m ẫu, lặp
đi lặp lại, phiên h ọp
chung
Các k ỹ năng của Các chuyên gia, t h ỉnh thoảng Các chuyên gia có kinh
người phát tri ển với kinh nghiệm giới hạn có thể nghiệm cao, đa k ỹ năng là
chấp nhận được. cần thiết.
Sử dụng công ngh ệ Tùy chọn. Bắt buộc.
hỗ trợ quy tr ình, ví
dụ công cụ CASE.
Cấu trúc nhóm Thường cồng k ềnh với các bộ kỹ Thường g ọn nhẹ với các
năng được chuyên m ôn hóa. bộ kỹ năng ph ổ biến, được
bổ sung bởi các chuyên
gia khi cần thiết.
Quản lý ph ạm vi khắt Cần thiết. Quan trọng.
khe
Cấu trúc giai đo ạn 4 – 5 giai đoạn. 3 giai đoạn.
Tính trách nhiệm cá Khó tiếp cận. Trách nhiệm giải tr ình
nhân chính xác.
Bảng 3.4 – So sánh giữa phương pháp tiếp cận thông thư ờng ( ‘thác
nước ’) và RAD

95
3.11.3.2 Các giải pháp thương mại có sẵn
Ngày nay, rất nhiều tổ chức lựa chọn hoàn thàn h các yêu cầu dịch
vụ CNTT của m ình thông qua vi ệc m ua s ắm và triển khai các gi ải
pháp gói ph ần m ềm thương m ại sẵn có (COTS). Một khuôn kh ổ dành
cho việc lựa chọn, tùy ch ỉnh và triển khai các gói gi ải pháp thương
m ại có sẵn này là c ần thiết và bao gồm nhu cầu để:
 Hiểu đầy đủ về ưu và khuyết điểm của phương pháp ti ếp cận

theo gói.
 Xác định m ột khuôn khổ để lựa chọn gói phần m ềm m ột cách
hiệu quả.
 Xác định m ột khuôn khổ để tích hợp và tùy chỉnh m ột cách
hiệu quả.
 Xác định các yêu c ầu chức năng ở m ức tương xứng.
 Phát triển m ột danh sách ki ểm tra cho các yêu c ầu vận hành
và quản lý.
 Xác định các yêu c ầu sản phẩm và nhà cung c ấp.
 Xác định và tìm hiểu các giải pháp gói phần m ềm thương m ại
sẵn có tiềm năng.
 Thể hiện các khuyến nghị về sự phù hợp của m ột gói phần
m ềm thương m ại có sẵn được lựa chọn so với các yêu cầu đã
được thỏa thuận, và xác định những hàm ý của chúng.
Các tiêu chuẩn chi tiết sẽ cần đến cho:
 Các gói và nguyên m ẫu.

 Việc xác định cấu trúc c ủa các m a trận đánh giá đư ợc đánh
trọng số.
 Sự lặp lại trong việc chọn gói.
Ngoài ra, các th ủ tục đánh giá và so sánh các gói c ạnh tranh xét về
m ặt các yêu cầu tùy chỉnh/tích hợp là c ần thiết và nên bao gồm :
 Sự đánh giá vi ệc đáp ứng chức năng.

 Sự m inh ch ứng theo kịch bản và đánh giá theo hư ớng-người
sử dụng.
 Sự đánh giá vi ệc đáp ứng vận hành và qu ản lý.
 Sự đánh giá vi ệc đáp ứng các yêu c ầu triển khai.
Các tiêu chu ẩn dành cho các yêu c ầu về việc tài liệu hóa trước khi
tìm hiểu các gói (phần m ềm ) trên thị trường nên bao g ồm các tiêu
chuẩn thể hiện cụ thể dưới đây:
 Các chức năng cấp-cao (cho m ục đích xác đ ịnh phạm vi).
 Các chức năng nghi ệp vụ và các s ự kiện quan tr ọng.
 Các yêu c ầu đầu vào và đ ầu ra quan tr ọng.
 Các cấu trúc dữ liệu (tĩnh).
 Việc xác định các m ối quan hệ giữa những cấu trúc, chức
năng và sự kiện đó.
 Các yêu cầu vận hành và qu ản lý trên toàn bộ dịch vụ.

96
 Các yêu cầu phi-chức năng chẳng hạn như hiệu suất, thông
lượng, năng l ực khôi phục sau thảm họa, các tiêu chuẩn cơ sở
hạ tầng và bảo m ật.
Khi đánh giá các gi ải pháp COTS, hãy xem xét ba cách dư ới đây m à
trong đó các yêu c ầu có thể được đáp ứng:
 Giải pháp thương m ại có sẵn.

 Có thể được thiết lập cấu hình. Hãy ư ớc tính nỗ lực để hoàn
thành việc thiết lập cấu hình. Điều này chỉ cần phải hoản
thành m ột lần và sẽ được bảo tồn qua những lần nâng c ấp sản
phẩm .
 Phải được tùy chỉnh. Hãy ước tính nỗ lực để hoàn thành vi ệc
tùy chỉnh ban đầu và để lặp lại nó trên m ỗi lần nâng cấp sản
phẩm , hãy lưu ý r ằng ý tưởng tùy chỉnh có thể không áp dụng
được cho các bản phát hành trong tương lai.
Cũng nên tìm hiểu chiến lược và k ế hoạch phát hành c ủa nhà cung
cấp gói (phần m ềm ) và xác định chắc chắn rằng liệu nó có được liên
kết với (doanh nghi ệp/việc kinh doanh – người dịch) của bạn không,
và m ức độ m ở rộng m à bạn có thể kỳ vọng rằng các yêu cầu trong
tương lai s ẽ được đáp ứng bởi gói (phần m ềm ).
4 Các quy trình Thi ết kế Dịch vụ

Chương này m ô t ả và giải thích các nguyên t ắc cơ bản của các quy
trình hỗ trợ chính cho Thi ết kế Dịch vụ. Các quy trình này ch ịu trách
nhiệm chủ yếu trong việc cung c ấp thông tin chính cho vi ệc thiết kế
các giải pháp dịch vụ m ới hoặc đã được thay đổi. Có năm khía c ạnh
của thiết kế cần được xem xét:
 Thiết kế của các dịch vụ, bao gồm tất cả các yêu c ầu chức
năng, nguồn lực và năng l ực cần thiết và đã được thỏa thuận.
 Thiết kế của các hệ thống và công c ụ Quản lý Dịch vụ, đặc
biệt là Danh m ục Dịch vụ, để quản lý và ki ểm soát các d ịch vụ
trong suốt vòng đời của chúng.
 Thiết kế của kiến trúc công ngh ệ và hệ thống quản lý cần thiết
để cung cấp dịch vụ.
 Thiết kế của các quy trình cần thiết để thiết kế, chuyển tiếp,
vận hành và c ải tiến các dịch vụ, kiến trúc và bản thân các quy
trình.
 Thiết kế của các phương pháp đo lư ờng và các ch ỉ số của các
dịch vụ, kiến trúc và các thành ph ần cấu thành c ủa chúng và
các quy trình.
Một phương pháp tiếp cận định hướng-kết quả nên được áp dụng
cho m ỗi khía c ạnh trong s ố năm khía c ạnh trên. Trong m ỗi khía
cạnh, kết quả kinh doanh m ong m u ốn và kết quả đã hoạch định nên
được xác định sao cho nh ững gì được cung cấp đáp được kỳ vọng
đợi của khách hàng và ngư ời sử dụng. Do đó, phương pháp tiếp cận
có cấu trúc này nên được áp dụng trong từng khía cạnh của năm
khía cạnh (thiết kế) để m ang lại chất lượng, tính nhất quán có th ể
lặp lại được và c ải tiến liên t ục trong toàn b ộ tổ chức. Sẽ không có

97
tình huống nào trong vi ệc cung c ấp dịch vụ CNTT với các nhà cung
cấp dịch vụ nội bộ hoặc bên ngoài m à không có quy trình trong lĩnh
vực Thiết kế Dịch vụ. Mọi tổ chức cung cấp dịch vụ CNTT đều đã có
sẵn m ột vài yếu t ố trong phương pháp ti ếp cận của họ đối với năm
khía cạnh này, bất kể nó cơ bản như thế nào. Trước khi bắt đầu
triển khai c ải tiến các hoạt động và quy trình, m ột đánh giá nên
được tiến hành để xem các yếu tố nào đang có và ho ạt động thành
công. Rất nhiều t ổ chức cung cấp dịch vụ đã có sẵn các quy trình
hoàn thiện để thiết kế các dịch vụ và giải pháp CNTT.
Mọi thiết kế và hoạt động thiết kế cần được định hướng chủ yếu bởi
các nhu c ầu kinh doanh và các yêu c ầu của tổ chức. Trong bối cảnh
này, chúng cũng phải phản ánh nhu cầu của các chiến lược, kế
hoạch và chính sách đư ợc tạo ra bởi các quy trình Chiến lược Dịch
vụ, như được m inh họa trong Hình 4.1.
Hình 4.1 – Các liên kết, đầu vào và đ ẩu ra chủ yếu của Thiết kế
Dịch vụ
Hình 4.1 cung c ấp m ột cái nhìn tổng quan rõ ràng v ề các liên k ết,
đầu vào và đầu ra có liên quan ở m ỗi giai đo ạn của Vòng đời Dịch
vụ. Nó m inh h ọa các đầu ra chủ yếu được tạo ra bởi m ỗi giai đo ạn,
sẽ được sử dụng làm đầu vào cho các giai đo ạn tiếp theo. Danh m ục
Dịch vụ đóng vai trò là 'xương s ống' của Vòng đời Dịch vụ. Đây là
nguồn thông tin đư ợc tích hợp duy nhất về trạng thái c ủa từng dịch

98
vụ, cùng với các chi ti ết dịch vụ khác và các giao di ện và s ự ph ụ
thuộc giữa các dịch vụ. Thông tin trong Danh m ục Dịch vụ được s ử
dụng bởi các hoạt động trong từng giai đo ạn của Vòng đời Dịch vụ.
Đầu ra chủ yếu của giai đo ạn Thiết kế dịch vụ là bản thiết kế các
giải pháp dịch vụ để đáp ứng các yêu c ầu thay đổi của doanh
nghiệp. Tuy nhiên, khi thi ết kế các giải pháp này, đ ầu vào từ nhiều
lĩnh vực khác nhau c ần được xem xét trong các ho ạt động khác
nhau có liên quan đ ến thiết kế giải pháp dịch vụ, từ việc xác định và
phân tích các yêu c ầu, đến việc xây dựng m ột giải pháp và SDP đ ể
chuyển giao cho Chuy ển tiếp Dịch vụ.
Để phát triển các gi ải pháp dịch vụ hiệu quả và hiệu suất đáp ứng và
tiếp tục đáp ứng các yêu c ầu của doanh nghiệp và nhu cầu của
CNTT, điều thiết yếu là m ọi yếu tố đầu vào và nhu c ầu của m ọi lĩnh
vực và quy trình khác ph ải được xem xét lại trong m ỗi hoạt động của
Thiết kế dịch vụ, như đư ợc m inh họa trong Hình 4.2. Đi ều này sẽ
đảm bảo rằng m ọi giải pháp dịch vụ sẽ nhất quán và tương t hích với
các giải pháp hiện hữu và sẽ đáp ứng được m ong đợi của khách
hàng và người sử dụng. Điều này sẽ đạt được m ột các hiệu quả nhất
bằng cách hợp nhất các khía c ạnh này c ủa các quy trình ch ủ yếu
vào tất cả các hoạt động Thiết kế Dịch vụ này, để từ đó m ọi đầu vào
được tự động tham chi ếu m ỗi khi m ột giải pháp dịch vụ mới hoặc
được thay đổi được đưa ra.

99
Hình 4.2 – Thiết kế Dịch vụ - một bức tranh l ớn
4.1 Quản lý Mục lục Dịch vụ

4.1.1 Mục đích/đích đ ến/mục tiêu
Mục đích c ủa Quản lý Mục lục Dịch vụ là để cung cấp m ột nguồn duy
nhất của thông tin nh ất quán về m ọi dịch vụ đã được thỏa thuận, và
đảm bảo rằng nó s ẵn sàng rộng rãi cho nh ững ai đã được phê duyệt
để tiếp cận nó.
Đích đến của Quản lý Mục lục Dịch vụ là để đảm bảo rằng m ột Mục
lục Dịch vụ được đưa ra và được duy trì, bao gồm thông tin chính
xác về m ọi dịch vụ vận hành và nh ững gì đang được chuẩn bị để
đưa vào ho ạt động vận hành.
Mục tiêu c ủa Quản lý Mục lục Dịch vụ là để quản lý những thông tin
bao gồm trong Mục lục Dịch vụ, và để đảm bảo rằng nó là chính x ác
và phản ảnh các chi ti ết, tình tr ạng, các giao diện và phụ thuộc hiệ n
tại của m ọi dịch vụ đang hoạt động, hoặc đang được chuẩn bị để
hoạt động, trong m ôi trường thật.
4.1.2 Phạm vi
Phạm vi của quy trình Qu ản lý Mục lục Dịch vụ là để cung cấp và
duy trì thông tin chính xác v ề m ọi dịch vụ đang được chuyển tiếp
hoặc đã được chuy ển tiếp vào m ôi trư ờng thật.
Các hoạt động Quản lý Mục lục Dịch vụ nên bao gồm :
 Định nghĩa c ủa dịch vụ.

 Sự sản xuất và duy trì m ột Mục lục Dịch vụ chính xác.
 Các giao di ện, phụ thuộc và tí nh nhất quán giữa Mục lục Dịc h
vụ và Danh m ục Dịch vụ.
 Các giao di ện và phụ thuộc giữa m ọi dịch vụ và các d ịch vụ hỗ
trợ trong Mục lục Dịch vụ và CMS.
 Các giao diện và phụ thuộc giữa m ọi dịch vụ, và các thành
phần hỗ trợ và các Đơn vị Cấu hình (Cis) trong Mục lục Dịch
vụ và CMS.

Mục lục Dịch vụ cung cấp m ột nguồn thông tin t ập trung v ề các dịch
vụ CNTT được cung cấp bởi tổ chức cung c ấp dịch vụ. Điều này
đảm bảo rằng m ọi lĩnh vực của doanh nghiệp đều có thể nhìn thấ y
m ột bức tranh chính xác và nh ất quán về các dịch vụ CNTT, các chi
tiết và tình tr ạng của chúng. Nó bao g ồm m ột cái nhìn đ ối m ặt-khách
hàng về các dịch vụ CNTT đang s ử dụng, các chúng d ự định được
sử dụng như thế nào, các quy trình nghi ệp vụ m à chúng cho phép,
và các m ức và chất lượng của dịch vụ m à khách hàng có th ể kỳ
vọng đối với m ỗi dịch vụ.
4.1.4 Các chính sách, nguyên t ắc và ý tưởng cơ bản

Trong những năm qua, cơ s ở hạ tầng CNTT của các t ổ chức đã tăng
trưởng và phát tri ển, và có thể không có m ột bức tranh rõ ràng v ề
m ọi dịch vụ hiện đang được cung c ấp và khách hàng c ủa m ỗi dịch

100
vụ. Để thiết lập m ột bức tranh chính xác, chúng tôi khuy ến nghị rằng
Danh m ục Dịch vụ CNTT chứa Mục lục Dịch vụ cần được tạo ra và
duy trì để cung cấp m ột bộ thông tin tập trung và chính xác v ề tất cả
các dịch vụ và để phát triển văn hóa tập trung-vào dịch vụ.
Danh m ục Dịch vụ nên chứa tất cả các yêu cầu trong tương lai đ ối
với các dịch vụ và Mục lục Dịch vụ nên chứa thông tin chi tiết về m ọi
dịch vụ hiện đang được cung cấp hoặc những dịch vụ đang được
chuẩn bị để chuyển tiếp sang m ôi trường thật, m ọt bản tóm tắt các
đặc điểm của chúng và thông tin chi ti ết về khách hàng và ngư ời
bảo trì của m ỗi dịch vụ . Một trình độ 'công việc thám tử' có thể
được cần đến để biên soạn danh sách này và th ỏa thuận nó với
khách hàng (ch ọn lọc tài liệu cũ, tìm ki ếm các thư viện chương
trình, nói chuyện với nhân viên CNTT và khách hàng, xem xét h ồ sơ
m ua sắm và nói chuyện với nhà cung cấp và nhà thầu, v.v…). Nếu
m ột CMS hoặc bất kỳ loại cơ sở dữ liệu nội dung nào đan g tồn tại,
chúng có thể cung cấp các nguồn thông tin có giá tr ị, m ặc dù chúng
nên được xác m inh trước khi được bao gồm trong Danh m ục Dịch vụ
hoặc Mục lục Dịch vụ. Danh m ục Dịch vụ được tạo ra như là m ột
phần của Chiến lược Dịch vụ và nên bao g ồm sự tham gia của
những người liên quan đến Thiết kế, Chuyển tiếp, Vận hành và Cả i
tiến Dịch vụ. Sau khi d ịch vụ được ‘tuyên b ố’ (đã được phát triển để
khách hàng sử dụng), Thiết kế Dịch vụ sẽ tạo ra các đặc tả kỹ thuật
cho dịch vụ và t ại thời điểm này, dịch vụ đó sẽ được thêm vào Mục
lục Dịch vụ.
Mỗi tổ chức nên phát tri ển và duy trì m ột chính sách liên quan đ ến
cả Danh m ục và Mục lục (Dịch vụ), liên quan đến các dịch vụ được
ghi nhận bên trong chúng, chi ti ết nào và tr ạng thái nào được ghi
nhận lại cho t ừng dịch vụ. Chính sách cũng nên bao g ồm các chi tiết
về trách nhiệm đối với từng phần của Danh m ục Dịch vụ tổng thể và
phạm vi của từng phần cấu thành.
Quy trình Quản lý Mục lục Dịch vụ tạo ra và duy trì M ục lục Dịch vụ,
đảm bảo rằng nguồn dữ liệu tập trung, chính xác và nhất quán được
cung cấp, ghi lại trạng thái c ủa tất cả các dịch vụ vận hành ho ặc các
dịch vụ đang được chuyển tiếp sang môi trường thật, cùng với các
chi tiết tương xứng của từng dịch vụ.
Dịch vụ là gì? Câu hỏi này không d ễ trả lời như lần đầu tiên nó xuất
hiện, và rất nhiều t ổ chức đã thất bại trong vi ệc đưa ra được định
nghĩa rõ ràng trong b ối cảnh CNTT. Nhân viên CNTT thư ờng nhầm
lẫn giữa m ột ‘dịch vụ’ m à khách hàng c ảm nhận với m ột hệ thống
CNTT. Trong r ất nhiều trường hợp, m ột 'dịch vụ' có thể được tạo
thành từ các 'dịch vụ' khác (v.v...), mà b ản thân chúng đư ợc tạ o
thành từ m ột hoặc nhiều hệ thống CNTT trong m ột cơ sở hạ tầng
tổng thể bao gồm phần cứng, phần m ềm, m ạng, cùng với m ôi
trường, dữ liệu và các ứng dụng. Một điểm khởi đầu tốt thường là
hỏi khách hàng h ọ đang sử dụng dịch vụ CNTT nào và cách các d ịch
vụ đó ánh xạ và hỗ trợ các quy trình nghi ệp vụ của họ như thế nào.
Khách hàng thư ờng hiểu rõ hơn về những gì họ tin rằng đó là m ột

101
dịch vụ. Mỗi tổ chức cần phát triển m ột chính sách về dịch vụ là gì
và nó được xác định và thống nhất như thế nào trong chính t ổ chức
của họ.
Để tránh nhầm lẫn, m ột ý tưởng không tồi là nên xác đ ịnh hệ thống
phân cấp các dịch vụ trong Mục lục Dịch vụ, bằng cách xác đ ịnh
chính xác ki ểu dịch vụ được ghi nhận lại, ví dụ: dịch vụ nghiệp vụ
(cái m à khách hàng nhìn th ấy). Ngoài ra, các d ịch vụ hỗ trợ, chẳng
hạn như dịch vụ cơ sở hạ tầng, dịch vụ m ạng, dịch vụ ứng dụng (tất
cả đều vô hình đối với khách hàng, nhưng là đi ều thiết yếu cho vi ệc
cung cấp dịch vụ CNTT) cũng sẽ cần được ghi nhận lại. Điều này
thường làm phát sinh h ệ thống cấu trúc phân cấp dịch vụ kết hợp
với dịch vụ khách hàng và các d ịch vụ có liên quan khác, bao g ồm
các dịch vụ hỗ trợ, dịch vụ được chia sẻ và dịch vụ tiện nghi, m ỗi
dịch vụ đều có các m ức dịch vụ được xác định và thỏa thuận.
Khi hoàn thành vào lúc ban đ ầu, Mục lục dịch vụ có thể bao gồm m ột
m a trận, bảng biểu hoặc bảng tính. Nhi ều tổ chức tích hợp và duy trì
Danh m ục Dịch vụ và Mục lục Dịch vụ như m ột phần của CMS của
mình. Bằng cách xác đ ịnh m ỗi dịch vụ như là m ột Đơn vị Cấu hình
(CI) và, nếu thích h ợp, liên k ết các dịch vụ này để tạo thành m ột hệ
thống phân c ấp dịch vụ, tổ chức có khả năng liên k ết các sự kiện
như các sự cố và các RFC với các dịch vụ bị ảnh hưởng, từ đó cung
cấp cơ sở cho việc giám sát và báo cáo d ịch vụ bằng cách sử dụng
m ột công cụ được tích hợp (ví dụ: 'liệt kê hoặc cung cấp số lượng
sự cố ảnh hưởng đến dịch vụ cụ thể này'). Do đó, đi ều thiết yếu là
các thay đổi trong Danh m ục Dịch vụ và Mục lục Dịch vụ phải tuân
theo quy trình Quản lý Thay đổi.
Mục lục Dịch vụ cũng có thể được sử dụng cho các m ục đích Quả n
lý Dịch vụ khác (ví dụ: để thực hiện Phân tích Tác động Kinh doanh
(BIA) như m ột phần của Hoạch định Liên tục Dịch vụ CNTT hoặc
như m ột nơi bắt đầu để tái phân ph ối lại khối lượng công vi ệc, như
m ột phần của Quản lý Công su ất). Chi phí và n ỗ lực của việc tạo ra
và duy trì danh m ục, với các m ối quan hệ của nó với các thành ph ần
công nghệ nền tảng, do đó, có thể dễ dàng biện m inh. Nếu được
thực hiện cùng với việc ưu tiên hóa c ủa BIA thì có th ể đảm bảo rằng
các dịch vụ quan tr ọng nhất được bao phủ trước tiên. Một ví dụ về
Mục lục Dịch vụ đơn giản có thể được sử dụng làm điểm khởi đầu
được nêu ra trong Phụ lục G.
Mục lục Dịch vụ có hai khía cạnh sau:
 Mục lục Dịch vụ Nghiệp vụ: bao gồm các chi ti ết về m ọi dịch
vụ CNTT được cung c ấp cho khách hàng, cùng với các m ối
quan hệ với các đơn vị kinh doanh và quy trình nghi ệp vụ dựa
trên các dịch vụ CNTT. Đây là quan đi ểm của khách hàng v ề
Mục lục Dịch vụ.
 Mục lục Dịch vụ Kỹ thuật: bao gồm các chi tiết về m ọi dịch
vụ CNTT được cung c ấp cho khách hàng, cùng với các m ối
quan hệ với các dịch vụ hỗ trợ, các dịch vụ được chia s ẻ, các

102
thành phần và các Cis c ần thiết để hỗ trợ việc cung cấp dịch
vụ cho doanh nghi ệp. Điều này nên làm cơ s ở cho Mục lục
Dịch vụ Nghiệp vụ và không định hình m ột phần của quan đi ểm
của khách hàng.
Mối quan hệ giữa hai khía c ạnh trên đư ợc m inh họa trong Hình 4.3.
Hình 4.3 – Mục lục Dịch vụ Nghiệp vụ và Mục lục Dịch vụ Kỹ

thuật
Một số tổ chức chỉ duy trì Mục lục Dịch vụ Nghiệp vụ hoặc Mục lục
Dịch vụ Kỹ thuật. Tình hu ống được ưu tiên được các tổ chức trưở ng
thành hơn áp d ụng duy trì c ả hai khía cạnh trong m ột Mục lục Dịch
vụ duy nhất, là m ột phần của hoạt động Quản lý Dịch vụ và Danh
m ục dịch vụ được tích hợp hoàn toàn. Thông tin thêm về thiết kế và
nội dung c ủa m ột Mục lục Dịch vụ được nêu trong Ph ụ lục G. Mục
lục Dịch vụ Nghiệp vụ tạo điều kiện cho việc phát triển quy trình
SLM chủ động hơn ho ặc thậm chí ưu tiên hơn nhi ều, cho phép quy
trình này phát triển nhiều hơn trong lĩnh vực Quản lý Dịch vụ Nghiệ p
vụ. Mục lục Dịch vụ Kỹ thuật cực kỳ hữu ích khi tiến hành xây d ựng
m ối quan hệ giữa các dịch vụ, SLA, OLA và các th ỏa thuận và thành
phần nền tảng khác, vì nó s ẽ xác định công nghệ cần thiết để hỗ trợ
m ột dịch vụ và (các) n hóm hỗ trợ hỗ trợ cho các thành ph ần. Sự kết
hợp giữa Mục lục Dịch vụ Nghiệp vụ và Mục lục Dịch vụ Kỹ thuật là
vô giá để đánh giá m ột cách nhanh chóng tác đ ộng của các sự cố và
thay đổi đối với doanh nghiệp. Một ví dụ về m ối quan hệ giữa các
phần Nghiệp vụ và Kỹ thuật của Mục lục Dịch vụ được trình bày
trong Hình 4.4.

103
Hình 4.4 – Ví dụ về Mục lục Dịch vụ
4.1.5 Các hoạt động, phương pháp và k ỹ thuật quy trình

Hoạt động chủ yếu của quy trình Quản lý Mục lục Dịch vụ nên bao
gồm :
 Thỏa thuận và ghi nh ận m ột định nghĩ a về dịch vụ với tất cả

các bên liên quan.
 Giao tiếp với Quản lý Danh m ục Dịch vụ để thỏa thuận về nội
dung của Danh m ục Dịch vụ và Mục lục Dịch vụ.
 Đưa ra và duy trì m ột Mục lục Dịch vụ và nội dung c ủa nó,
trong sự liên kết với Danh m ục Dịch vụ.
 Giao tiếp với doanh nghi ệp và Quản lý Liên tục Dịch vụ CNTT
về các phụ thuộc của các đơn vị kinh doanh và các quy trình
nghiệp vụ của họ vào các dịch vụ CNTT hỗ trợ, được bao gồm
trong Mục lục Dịch vụ Nghiệp vụ.
 Giao tiếp với nhóm hỗ trợ, nhà cung c ấp và Quản lý Cấu hình
về các giao diện và phụ thuộc giữa các dịch vụ CNTT và các
dịch vụ hỗ trợ, các thành ph ần và Cis được bao gồm trong
Mục lục Dịch vụ Kỹ thuật.

104
 Giao tiếp với Quản lý Mối quan hệ Kinh doanh và Qu ản lý Mức
Dịch vụ để đảm bảo rằng thông tin được liên kết với doanh
nghiệp và quy trình nghi ệp vụ.
4.1.6 Các điều kiện kích hoạt, đầu vào, đ ầu ra và tương tác
Có m ột số nguồn thông tin liên quan đ ến quy trình Qu ản lý Mục lục
Dịch vụ. Chúng nên bao g ồm :
 Thông tin kinh doanh t ừ việc kinh doanh và chi ến lược CNTT
của tổ chức, các kế hoạch và k ế hoạch tài chính, và thông tin
về các yêu c ầu hiện tại và trong tương lai c ủa họ từ Danh m ục
Dịch vụ.
 Phân tích Tác đ ộng Kinh doanh, cung c ấp thông tin về tác
động, độ ưu tiên và r ủi ro tương xứng với m ỗi dịch vụ hoặc
thay đổi đối với yêu cầu dịch vụ.
 Yêu cầu kinh doanh: chi ti ết về bất kỳ yêu cầu kinh doanh m ới
hoặc được thay đổi đã được thỏa thuận từ Danh m ục Dịch vụ.
 Danh m ục Dịch vụ.
 CMS.
 Phản hồi từ m ọi quy trình khác.
Điều kiện kích ho ạt đối với quy trình Qu ản lý Mục lục Dịch vụ là các
thay đổi trong yêu cầu kinh doanh và dịch vụ nghiệp vụ, và do đó,
m ột trong những điều kiện kích hoạt chủ yếu là Yêu cầu Thay đổi
(RFCs) và quy trình Qu ản lý Thay đ ổi. Điều này s ẽ bao gồm các dịch
vụ m ới, những thay đổi đối với các dịch vụ hiện tại hoặc dịch vụ
ngừng hoạt động.
Đầu ra quy trình của SCM là:
 Tài liệu và thỏa thuận về m ột ‘định nghĩa d ịch vụ’.

 Những cập nhật đối với Danh m ục Dịch vụ: nên bao g ồm tình
trạng hiện tại của mọi dịch vụ và yêu cầu đối với dịch vụ.
 Mục lục Dịch vụ: nên bao gồm các chi tiết và tình trạng hiện
tại của m ỗi tuyến dịch vụ đã được cung c ấp bởi nhà cung cấ p
dịch vụ, cùng với các giao diện và phụ thuộc. Một ví dụ về m ột
Mục lục Dịch vụ được bao gồm trong Phụ lục G.
4.1.7 Quản lý thông tin

Thông tin ch ủ yếu trong quy trì nh Quản lý Mục lục Dịch vụ nằm trong
Danh m ục Dịch vụ. Đầu vào chính của thông tin này đến từ Danh
m ục Dịch vụ và doanh nghiệp thông qua ho ặc Quản lý Mối quan hệ
Kinh doanh (BRM) ho ặc Quản lý Mức Dịch vụ (SLM). Thông tin này
cần được xác m inh về tính chính xác trước khi được ghi nhận trong
Mục lục Dịch vụ. Thông tin và b ản thân Mục lục Dịch vụ cần được
duy trì bằng cách s ử dụng quy trình Qu ản lý Thay đ ổi.
4.1.8 Các Chỉ số Hiệu su ất Quan trọng (KPIs)

Hai Chỉ số Hiệu suất Quan tr ọng (KPIs) tương ứng với Mục lục Dịch
vụ và việc quản lý nó là:

105
 Số lượng dịch vụ được ghi nhận và duy trì trong M ục lục Dịc h
vụ theo t ỷ lệ phần trăm của các dịch vụ đã được cung c ấp và
chuyển tiếp vào m ôi trường thật.
 Số lượng các bi ến đổi được phát hi ện giữa thông tin bao gồm
trong Mục lục Dịch vụ và tình huống trong ‘th ế giới thực’.
Các thước đo khác và KPIs có th ể được sử dụng là:
 Nhận thức của người sử dụng trong doanh nghi ệp về các dịch
vụ đang được cung cấp, nghĩa là t ỷ lệ phần trăm trong vi ệc
tăng m ức độ hoàn thiện của Mục lục Dịch vụ Nghiệp vụ đối với
các dịch vụ vận hành.
 Nhận thức của nhân viên CNTT v ề công nghệ hỗ trợ các dịch
vụ:
o Tỷ lệ phần trăm gia tăng m ức độ hoàn thiện của Danh
m ục Dịch vụ Kỹ thuật so với các thành ph ần CNTT hỗ trợ
cho các d ịch vụ.
o Bộ phận Hỗ trợ Dịch vụ có quyền tiếp cận tới thông tin
để hỗ trợ m ọi dịch vụ đang hoạt động, được đo lường
bởi tỷ lệ phần trăm các s ự cố không có thông tin liên
quan tới dịch vụ thích hợp.
4.1.9 Những thách thức, các Yếu tố Thành công Quan tr ọng và
Rủi ro
Thách thức chủ yếu m à quy trình Quản lý Mục lục Dịch vụ phải đối
m ặt là việc duy trì Mục lục Dịch vụ chính xác như là m ột phần của
Danh m ục Dịch vụ, kết hợp cả Danh m ục Dịch vụ Nghiệp vụ và Danh
m ục Dịch vụ Kỹ thuật như m ột phần của CMS và SKMS t ổng thể.
Điều này được tiếp cận tốt nhất bằng cách phát triển các bảng tính
hoặc cơ sở dữ liệu độc lập trước khi c ố gắng tích hợp Mục lục Dịch
vụ và Danh m ục Dịch vụ vào trong CMS hoặc SKMS. Để đạt được
điều này, văn hóa c ủa tổ chức cần chấp nhận rằng Mục lục và Danh
m ục (Dịch vụ) là những nguồn thông tin thiết yếu m à mọi người
trong t ổ chức CNTT cần sử dụng và giúp duy trì. Đi ều này thường sẽ
hỗ trợ việc tiêu chu ẩn hóa Mục lục Dịch vụ và Danh m ục Dịch vụ và
cho phép tăng hi ệu suất chi phí thông qua tính kinh t ế của quy m ô.
Các yếu tố thành công quan t rọng chính đối với quy trình Qu ản lý
Mục lục Dịch vụ là:
 Một Mục lục Dịch vụ chính xác.

 Nhận thức của người sử dụng của doanh nghi ệp về các dịch
vụ đang đư ợc cung cấp.
 Nhận thức của nhân viên CNTT v ề công nghệ hỗ trợ các dịch
vụ.
Các rủi ro tương ứng với việc cung c ấp m ột Mục lục Dịch vụ chính
xác là:
 Độ không chính xác c ủa dữ liệu trong m ục lục và không được

kiểm soát thay đ ổi m ột cách nghiêm ngặt.

106
 Mức độ chấp thuận kém đối với Mục lục Dịch vụ và việc sử
dụng nó trong m ọi quy trình ho ạt động. Mục lục càng hoạt
động thì càng có khả năng nó chính xác hơn v ề nội dung của
nó.
 Độ không chính xác c ủa thông tin nh ận được từ doanh nghi ệp,
CNTT và Danh m ục Dịch vụ, liên quan đ ến thông tin dịch vụ.
 Các công cụ và tài nguyên cần thiết để duy trì thông tin.
 Khả năng tiếp cận kém tới thông tin và các quy trình Qu ản lý
Thay đổi chính xác.
 Khả năng tiếp cận và hỗ trợ kém về CMS và SKMS tương
xứng và c ập nhật.
 Gian lận trong vi ệc sử dụng Danh m ục Dịch vụ và Mục lục
Dịch vụ.
 Thông tin ho ặc là quá chi ti ết để duy trì m ột cách chính xác
hoặc ở m ột mức quá cao đến m ức không có giá tr ị. Nó nên
nhất quán với m ức chi tiết trong CMS và SKMS.
4.2 Quản lý Mức Dịch vụ

Quản lý Mức Dịch vụ (SLM) thương th ảo, thỏa thuận và tài liệu hóa
các đích nhắm m ục tiêu c ủa dịch vụ CNTT thích h ợp với các đại diện
của doanh nghi ệp, và sau đó giám sát và đưa ra các báo cáo v ề
năng lực của nhà cung cấp dịch vụ để cung cấp m ức dịch vụ đã
được thỏa thuận. SLM là m ột quy trình quan tr ọng đối với m ọi nhà
cung cấp dịch vụ CNTT trong đó t ổ chức này có trách nhi ệm thỏa
thuận và ghi nhận lại các đích nh ắm mục tiêu và trách nhi ệm đối với
m ức dịch vụ trong các SLA và SLR, cho m ọi hoạt động CNTT. Nế u
các đích nh ắm m ục tiêu này phù hợp và phản ánh chính xác yêu c ầu
của doanh nghi ệp thì dịch vụ đưuọc cung c ấp bởi nhà cung cấp dịch
vụ sẽ liên kết với yêu cầu kinh doanh và đáp ứng được kỳ vọng của
khách hàng và ngư ời sử dụng về chất lượng dịch vụ. Nếu các đích
nhắm m ục tiêu không đư ợc liên kết với nhu c ầu kinh doanh, thì các
hoạt động và m ức dịch vụ của nhà cung cấp dịch vụ sẽ không liên
kết với kỳ vọng c ủa doanh nghi ệp và các vấn đề sẽ phát triển. SLA
thực sự là m ột m ức độ đảm bảo hoặc bảo hành liên quan đ ến m ức
chất lượng dịch vụ được cung c ấp bởi nhà cung cấp dịch vụ đối với
m ỗi dịch vụ được cung c ấp cho doanh nghiệp. Sự thành công của
SLM phụ thuộc rất nhiều vào chất lượng của Danh m ục Dịch vụ và
Mục lục dịch vụ và nội dung c ủa chúng, vì chúng cung c ấp thông tin
cần thiết về các dịch vụ được quản lý trong quy trình SLM.
4.2.1 Mục đích/đích đến/ mục tiêu

Mục tiêu của quy trình Quản lý Mức Dịch vụ là đảm bảo rằng m ột
m ức dịch vụ CNTT đã được thỏa thuận được cung c ấp cho tất cả
các dịch vụ CNTT hiện tại, và rằng các dịch vụ trong tương lai đư ợc
cung cấp với các điwch nh ắm mục tiêu có thể đạt được đã được
thỏa thuận. Các thước đo chủ động cũng được đưa ra đ ể tìm kiếm
và triển khai các c ải tiến đối với m ức dịch vụ đã được cung cấp.
Mục đích của quy trình SLM là đ ể đảm bảo rằng t ất cả các dịch vụ
vận hành và hi ệu suất của chúng được đo lường theo m ột cách nhất
quán, chuyên nghiệp trong toàn bộ tổ chức CNTT, và rằng các dịch

107
vụ và báo cáo đã đư ợc tạo ra đáp ứng được các nhu c ầu của doanh
nghiệp và khách hàng.
Mục tiêu c ủa SLM là:
 Xác định, tài li ệu hóa, thỏa thuận, giám sát, đo lư ờng, báo cáo
và xem xét m ức dịch vụ CNTT đã được cung c ấp.
 Cung cấp và c ải thiện m ối quan hệ và giao ti ếp với doanh
 Đảm bảo rằng các đích nhắm m ục tiêu c ụ thể và có thể đo
lường được phát tri ển cho m ọi dịch vụ CNTT.
 Theo dõi và cải thiện sự hài lòng c ủa khách hàng đ ối với chất
lượng dịch vụ đã được cung cấp.
 Đảm bảo rằng CNTT và khách hàng có k ỳ vọng rõ ràng và
không m ơ hồ về m ức độ dịch vụ sẽ được cung cấp.
 Đảm bảo rằng các thước đo chủ động để cải thiện các m ức
dịch vụ đã được cung cấp được triển khai ở bất kỳ nơi nào có
thể thực hiện được với chi phí hợp lý.
4.2.2 Phạm vi
SLM nên cung c ấp m ột đầu m ối liên hệ và giao tiếp thường xuyên
cho khách hàng và các nhà qu ản lý kinh doanh c ủa m ột tổ chức. Nó
phải đại diện cho nhà cung c ấp dịch vụ CNTT đối với doanh nghi ệp
và doanh nghiệp đối với nhà cung cấp dịch vụ CNTT. Hoạt động này
nên bao gồm cả việc sử dụng các dịch vụ hiện có và các yêu c ầ u
tiềm năng trong tương lai đ ối với các dịch vụ m ới hoặc đã được thay
đổi. SLM cần quản lý kỳ vọng và nhận thức của doanh nghi ệp, khách
hàng và người sử dụng và đảm bảo rằng chất lượng của đã đư ợc
cung cấp bởi nhà cung c ấp dịch vụ phù hợp với những kỳ vọng và
nhu cầu đó. Để thực hiện điều này m ột cách hiệu quả, SLM nên thiết
lập và duy trì các SLA cho t ất cả các dịch vụ hiện đang hoạt động và
quản lý m ức dịch vụ được cung c ấp để đáp ứng các m ục tiêu và
thước đo chất lượng được bao gồm trong các SLA. SLM cũng nên
đưa ra và thỏa thuận về SLR cho tất cả các dịch vụ m ới hoặc đã
thay đổi được hoạch định.
Việc này s ẽ cho phép SLM đ ảm bảo rằng t ất cả các dịch vụ và thành
phần được thiết kế và cung cấp để đáp ứng các đích nh ắm m ục tiêu
của chúng về nhu c ầu của doanh nghi ệp. Các quy trình SLM nên bao
gồm :
 Sự phát triển m ối quan hệ với doanh nghi ệp.

 Thương lượng và thỏa thuận về các yêu c ầu và đích nhắm
m ục tiêu hiện tại, tài liệu hóa và s ự quản lý SLA cho t ất cả các
dịch vụ đang vận hành.
 Thương lượng và thỏa thuận về các yêu c ầu và đích nhắm
m ục tiêu trong tương lai, tài li ệu hóa và s ự quản lý SLR cho
tất cả các dịch vụ m ới hoặc thay đổi được đề xuất.
 Phát triển và quản lý các Thỏa thuận Mức Vận hành (OLA)
thích hợp để đảm bảo rằng các đích nhắm m ục tiêu đư ợc liên
kết với các đích nhắm m ục tiêu SLA.

108
 Xem xét tất cả các hợp đồng và thỏa thuận cơ sở của nhà
cung cấp với Quản lý Nhà cung c ấp để đảm bảo rằng các đích
nhắm m ục tiêu được liên k ết với các đích nh ắm m ục tiêu SLA.
 Chủ động phòng ng ừa các lỗi dịch vụ, giảm thiểu rủi ro dịch vụ
và cải thiện chất lượng của dịch vụ, kết hợp với tất cả các quy
trình khác
 Báo cáo và quản lý m ọi dịch vụ và xem xét tất cả các vi ph ạm
và điểm yếu trong SLA.
 Thúc đẩy và điều phối m ột Kế hoạch Cải tiến Dịch vụ (SIP) để
quản lý, hoạch định và triển khai m ọi cải tiến dịch vụ và quy
trình.

SLM mang l ại một giao diện nhất quán cho doanh nghi ệp đối với mọi
vấn đề liên quan tới-dịch vụ. Nó cung c ấp cho doanh nghi ệp các đích
nhắm mục tiêu đã đư ợc thỏa thu ận và những thông tin qu ản lý cần
thiết để đảm bảo rằng những đích nhắm mục tiêu đó đã đư ợc đáp ứng.
Nếu các đích nhắm mục tiêu b ị vi phạm , SLM nên cung c ấp sự phản
hồi về nguyên nhân c ủa sự vi phạm và thông tin chi ti ết về các hành
động đã đư ợc thực hiện để ngăn chặn s ự vi ph ạm lặp lại. Do đó, SLM
cung cấp một kênh giao t i ếp xác thực và một mối quan hệ đáng tin c ậy
với khách hàng và các đ ại diện của doanh nghiệp tương xứng.
4.2.4 Các chính sách/nguyên t ắc/ ý tưởng cơ bản

SLM là tên g ọi được đặt cho các quy tr ình ho ạch định, điều phối, soạn
thảo, thỏa thu ận, giám sát và báo cáo v ề các SLA, và vi ệc xem xét liên
tục các thành t ựu c ủa dịch vụ để đảm bảo rằng chất lượng dịch vụ
được yêu cầu và có chi phí h ợp lý được duy tr ì và d ần dần được cả i
thiện. Tuy nhiên, SLM không ch ỉ liên quan đến việc đảm bảo rằng các
dịch vụ và SLA hiện tại được quản lý, mà còn liên quan đ ến việc đảm
bảo rằng các yêu c ầu mới được nắm bắt và các dịch vụ và SLA m ới
hoặc đã thay đổi đư ợc phát triển để phù hợp với nhu cầu và k ỳ vọng
của doanh nghiệp. Các SLA cung c ấp cơ sở để quản lý m ối quan h ệ
giữa nhà cung cấp d ịch vụ và khách hàng, và SLM cung c ấp tiêu điểm
trọng tâm đó cho m ột nhóm khách hàng, đơn v ị kinh doanh h oặc ngành
nghề kinh doanh.
Một SLA là một thỏa thuận bằng văn b ản giữa nhà cung c ấp dịch vụ
CNTT và (các) khách hàng c ủa CNTT, xác đ ịnh các đích nh ắm mục tiêu
dịch vụ chính và trách nhi ệm của cả hai bên. Phải nhấn mạnh vào thỏa
thuận và các SLA không nên đ ược sử dụng như một cách giữ bên này
hoặc bên kia đ ể đòi tiền chu ộc. Một mối quan hệ đối tác th ực sự nên
được phát triển giữa nhà cung c ấp dịch vụ CNTT và khách hàng đ ể đạt
được thỏa thuận đôi bên cùng có l ợi - nếu không SLA có th ể nhanh
chóng b ị phá vỡ và 'văn hóa đổ lỗi' có t hể phát triển và s ẽ ngăn cản
mọi cải tiến chất lượng dịch vụ thực sự được thực hiện.
SLM cũng ch ịu trách nhiệm cho việc đảm bảo rằng mọi đích nhắm mục
tiêu và thư ớc đo đã đư ợc thỏa t huận trong các SLA v ới doanh nghiệp
được hỗ trợ bởi các OLA hoặc hợp đồng cơ s ở thích h ợp, với các đơn
vị hỗ trợ nội bộ và các đối tác và nhà cung c ấp bên ngoài. Đi ều nà y
được minh họa trong Hình 4.5.

109
Hình 4.5 – Quản lý Mức Dịch vụ
Hình 4.5 cho thấy m ối quan hệ giữa doanh nghi ệp và các quy trình
và dịch vụ của nó, và công ngh ệ, dịch vụ hỗ trợ, các nhóm và nhà
cung cấp tương ứng cần thiết để đáp ứng các nhu cầu của họ. Nó
cho thấy các SLA, OLA và các h ợp đồng quan trọng như thế nào
trong việc xác định và đạt được m ức dịch vụ được yêu c ầu bởi
doanh nghiệp.
Một OLA là m ột thỏa thuận giữa m ột nhà cung cấp dịch vụ CNTT và
m ột bộ phận khác của cùng m ột tổ chức hỗ trợ cho việc cung cấp
dịch vụ - ví dụ, m ột bộ phận cơ sở vật chất chịu trách nhi ệm bảo trì
m áy điều hòa không khí, ho ặc nhóm hỗ trợ m ạng hỗ trợ cho dịch vụ
m ạng. Một OLA nên bao g ồm các đích nh ắm m ục tiêu làm nền tảng
cho những gì có trong m ột SLA để đảm bảo rằng các đích nh ắm mục
tiêu sẽ không bị vi phạm do lỗi của hoạt động hỗ trợ.

Những hoạt động chính trong quy trình SLM nên bao g ồm :
 Xác định, thương lượng, ghi nh ận và thỏa thuận về các yêu

cầu đối với các dịch vụ m ới hoặc đã thay đ ổi trong các SLR,
và quản lý và xem xét chúng trong su ốt Vòng đời Dịch vụ trong
các SLA đối với các dịch vụ vận hành.
 Giám sát và đo lường thành tựu về hiệu suất dịch vụ của m ọi
dịch vụ vận hành so với các đích nh ắm mục tiêu trong các
SLAs.
 Đối chiếu, đo lường và cải thiện sự hài lòng của khách hàng.

110
 Đưa ra các báo cáo d ịch vụ.
 Tiến hành xem xét đánh giá d ịch vụ và thúc đẩy sự cải thiện
trong m ột Kế hoạch Cải thiện Dịch vụ (SIP) tổng thể.
 Xem xét và điều chỉnh các SLA, ph ạm vi dịch vụ OLA, các hợp
đồng, và bất kỳ thỏa thuận cơ sở nào khác.
 Phát triển và ghi nhận các liên hệ và m ối quan hệ với doanh
nghiệp, khách hàng và các b ên liên quan.
 Phát triển, duy trì và vận hành các th ủ tục đối với việc ghi lại
nhật ký, hành động và giải quyết m ọi phàn nàn, và đối với việc
ghi lại nhật ký và phân phối những lời chúc m ừng.
 Ghi nhật ký và quản lý m ọi phàn nàn và lời chúc m ừng.
 Cung cấp những thông tin quản lý tương xứng để hỗ trợ cho
quản lý hiệu suất và chứng m inh cho thành t ựu của dịch vụ.
 Cung cấp và duy trì các bi ểu m ẫu tài liệu SLM và các tiêu
chuẩn được cập nhật .
Các giao di ện giữa các hoạt động chủ yếu được m inh họa trong Hình
4.6.
Hình 4.6 – Quy trình Quản lý Mức Dịch vụ
Mặc dù Hình 4.6 minh h ọa cho m ọi hoạt động chủ yếu của SLM là
các hoạt động tách biệt, chúng nên được triển khai như m ột quy
trình SLM được tích hợp có thể được áp dụng m ột cách nh ất quán

111
cho m ọi lĩnh vực của các doanh nghi ệp và cho m ọi khách hàng.
Những hoạt động này được m ô tả trong các ph ần sau đây.
4.2.5.1 Thiết kế khuôn khổ SLA

Sử dụng Mục lục Dịch vụ như m ột sự hỗ trợ, SLM phải thiết kế cấu
trúc SLA thích hợp nhất để đảm bảo rằng m ọi dịch vụ và khách hàng
được bao gồm theo m ột cách phù hợp nhất với các nhu c ầu của tổ
chức. Có m ột số lựa chọn tiềm năng, được bao gồm dưới đây.
SLA dựa trên-Dịch vụ

Đây là khi m ột SLA bao g ồm chỉ m ột dịch vụ, cho m ọi khách hàng
của dịch vụ đó, ví d ụ, m ột SLA có thể được thiết lập cho m ột dịch vụ
em ail c ủa tổ chức – bao gồm m ọi khách hàng c ủa dịch vụ đó. Điều
này trông có vẻ khá đơn giản. Tuy nhiên, khó khăn có th ể phát sinh
nếu các yêu c ầu cụ thể của các khách hàng khác nhau đ ối với cùng
m ột dịch vụ hoặc nếu các đặc điểm của cơ sở hạ tầng có nghĩa là
các m ức dịch vụ khác nhau là không th ể tránh khỏi (ví dụ: nhân viên
tại trụ sở chính có thể được kết nối qua m ạng LAN tốc độ cao, trong
khi các văn phòng đ ịa phương có thể phải sử dụng đường truyề n
W AN có tốc độ thấp hơn). Trong những trường hợp như v ậy, những
đích nhắm m ục tiêu tách bi ệt có thể sẽ cần đến trong chỉ m ột thỏa
thuận. Khó khăn cũng có th ể phát sinh trong vi ệc xác định ai nên là
người ký kết m ột thỏa thuận như vậy. Tuy nhiên, khi các m ức dịch
vụ chung được cung c ấp trên m ọi lĩnh vực của doanh nghi ệp, ví dụ:
e-m ail hoặc điện thoại, SLA dựa trên-dịch vụ có thể là m ột phương
pháp tiếp cận khá hi ệu quả để sử dụng. Nhiều lớp dịch vụ, ví dụ:
vàng, bạc và đồng, cũng có thể được sử dụng để làm gia tăng hi ệu
quả của SLA dựa trên-dịch vụ.
SLA dựa trên-Khách hàng

Đây là m ột thỏa thuận với m ột nhóm khách hàng riêng l ẻ, bao gồm
m ọi dịch vụ m à họ sử dụng. Ví dụ, các thỏa thuận có thể đạt được
với bộ phận tài chính của m ột tổ chức bao gồm , chẳng hạn như, hệ
thống tài chính, hệ thống kế toán, hệ thống tính lương, hệ thống
thanh toán, h ệ thống m ua sắm , và bất kỳ hệ thống CNTT nào m à họ
sử dụng. Khách hàng thư ờng ưa thích m ột thỏa thuận như vậy, khi
m ọi yêu c ầu của họ được bao gồm chỉ trong m ột tài liệu. Thường thì
chỉ yêu cầu m ột người ký (thỏa thuận) bắt buộc, giúp đơn giản hóa
vấn đề này.
Một sự kết hợp của m ột trong hai c ấu trúc này có th ể là thích hợp,
cung cấp sự bao phủ cho m ọi dịch vụ và khách hàng m à không b ị
chồng chéo hoặc trùng l ặp.
Các SLA nhi ều cấp độ

Vài tổ chức đã lựa chọn áp dụng m ột cấu trúc SLA có nhi ều cấp độ.
Ví dụ, m ột cấu trúc ba lớp như dưới đây:
 Mức công t y : bao gồm m ọi vấn đề SLM chung tương ứng với
m ọi khách hàng trong to àn bộ tổ chức. Những vấn đề này có

112
khả năng ít bi ến động hơn, vì vậy ít cần phải được cập nhật
hơn.
 Mức khách hàng : bao gồm m ọi vấn đề SLM liên quan t ới
nhóm khách hàng ho ặc đơn vị kinh doanh đ ặc biệt, bất kể dịch
vụ đang đư ợc sử dụng.
 Mức dịch vụ: bao gồm m ọi vấn đề SLM liên quan t ới dịch vụ
cụ thể, trong m ối tương quan với m ột nhóm khách hàng c ụ thể
(m ỗi m ột dịch vụ được bao phủ bởi m ột SLA).
Như được m inh h ọa trong Hình 4.7, m ột cấu trúc như vậy cho phép
các SLA được giữ ở m ột m ức có thể quản lý được, tránh sự trùng
lặp không c ần thiết, và làm giảm nhu cầu cập nhật thường xuyên.
Tuy nhiên, đi ều này có nghĩa là nh ững nỗ lực bổ sung là c ần thiết để
duy trì các m ối quan h ệ và liên k ết cần thiết trong Mục lục Dịch vụ
và CMS.
Hình 4.7 – Các SLA nhiều cấp độ
Nhiều tổ chức nhận thấy rất đáng giá để tạo ra các tiêu chu ẩn và
m ột bộ các m ẫu hoặc biểu m ẫu có thể được sử dụng như đi ểm khởi
đầu cho m ọi SLA, SLR và OLA. Mẫu thường có thể được phát tri ển

113
cùng với phác thảo SLA. Hướng dẫn về các m ục để được bao gồm
trong m ột SLA được đưa tra trong Phụ lục F. Việc phát tri ển các tiêu
chuẩn và biểu m ẫu sẽ đảm bảo rằng mọi thỏa thuận được phát tri ển
theo m ột cách nhất quán, và đi ều này s ẽ giúp dễ dàng sử dụng, vận
hành và quản lý chúng sau đó.
Hãy làm cho các vai trò và trách nhi ệm trở thành m ột phần của
SLA. Cân nhắc ba quan điểm – nhà cung c ấp CNTT, khách hàng
CNTT và ngư ời sử dụng thực tế.
Từ ngữ của SLA ph ải rõ ràng, ngắn gọn và không có ch ỗ cho sự m ơ

hồ. Thông thường, các thỏa thuận không nh ất thiết phải được viết
bằng các thuật ngữ pháp lý, và ngôn ng ữ đơn giản giúp cho vi ệc có
cùng m ột cách hiểu. Thường sẽ hữu ích nếu có m ột cá nhân độc lập,
người không tham gia vào việc soạn thảo, để thực hiện việc đọc qua
lần cuối. Điều này thường phát hi ện ra những m ơ hồ và khó khăn
tiềm ẩn m à sau đó có th ể được giải quyết và làm rõ. Chỉ vì lý do
này, chúng tôi khuy ến cáo rằng m ọi SLA nên chứa bảng thuật ngữ,
xác định bất kỳ thuật ngữ nào và cung c ấp sự rõ ràng cho b ất kỳ lĩnh
vực nào còn m ơ hồ.
Cũng cần phải nhớ rằng SLA có th ể phải bao gồm các dịch vụ được
cung cấp trên phạm vi quốc tế. Trong nh ững trường hợp này, SLA
có thể phải được dịch sang m ột vài ngôn ngữ. Hãy nhớ rằng SLA
được soạn thảo bằng m ột ngôn ngữ duy nhất có thể phải được xem
xét tính phù hợp ở m ột số nơi khác nhau trên th ế giới (nghĩa là m ột
phiên bản được soạn thảo ở Úc có th ể phải được xem xét để phù
hợp ở Hoa Kỳ hoặc Vương quốc Anh - và sự khác biệt về thuật ngữ,
phong cách và văn hóa ph ải được tính đến).
Khi các dịch vụ CNTT được cung c ấp cho m ột tổ chức khác bởi m ột
nhà cung c ấp dịch vụ bên ngoài, đôi khi các đích nh ắm m ục tiêu d ịch
vụ được bao gồm trong hợp đồng và vào những thời điểm khác,
chúng nằm trong SLA hoặc trong lịch trình được đính kèm với hợp
đồng. Bất kể tài liệu nào được sử dụng, điều thiết yếu là các đích
nhắm m ục tiêu đư ợc lập thành văn bản và thỏa thuận phải rõ ràng,
cụ thể và không mơ h ồ, vì chúng s ẽ cung cấp cơ sở cho m ối quan
hệ và chất lượng của dịch vụ được cung cấp.
4.2.5.2 Xác định, lập thành văn bản và thỏa thuận các yêu cầu
đối với các dịch vụ mới và đưa các SLR
Đây là m ột trong nh ững hoạt động đầu tiên trong giai đo ạn Thiết kế
Dịch vụ của Vòng đ ời Dịch vụ. Khi Mục lục Dịch vụ đã được đưa ra
và cấu trúc SLA đã được thỏa thuận, m ột SLR đầu tiên phải được
phác thảo. Một lời khuyên là b ạn nên bao g ồm khách hàng ngay t ừ
đầu thay vì đi m ột mình và b ắt đầu với m ột tờ giấy trắng, tốt hơn có
lẽ là nên đưa ra m ột phác thảo đầu tiên của các đích nh ắm m ục tiêu
về hiệu suất và các yêu c ầu quản lý và vận hành nhu là đi ểm khởi
đầu cho cuộc thảo luận chuyên sâu và chi ti ết hơn. Tuy nhiên, hãy

114
cẩn trọng để đừng đi quá xa và th ể hiện cho khách hàng như m ột
‘việc đã rồi’.
Không thể quá nhấn m ạnh về việc hoạt động này về việc xác định
đích nhắm m ục tiêu ban đ ầu đối với sự bao gồm với m ột SLA hoặc
SLR là khó khăn như th ế nào. Mọi quy trình khác c ần được tham vấn
về quan điểm của chúng về những đích nhắm m ục tiêu thực thế có
thể đạt được là gì, ch ẳng hạn như Quản lý Sự cố về các đích nhắm
m ục tiêu sự cố. Các quy trình Qu ản lý Tính s ẵn sàng và Qu ản lý
Công suất sẽ có giá trị cụ thể trong việc xác định tính sẵn sàng c ủa
dịch vụ tương xứng và các đích nh ắm m ục tiêu về hiệu suất. Nếu có
bất kỳ nghi ngờ nào, các đích nh ắm m ục tiêu t ạm thời nên được bao
gồm trong m ột SLA thử nghiệm được giám sát và đi ều chỉnh trong
m ột giai đoạn đảm bảo dịch vụ, như đã được m inh họa trong Hình
3.5.
Khi m à rất nhiều tổ chức phải đưa ra các ưu tiên ban đ ầu để giới
thiệu các SLA cho các d ịch vụ hiện hữu, điều quan trọng là ph ải
thiết lập các thủ tục cho việc thỏa thuận về các Yêu c ầu Mức Dịch
vụ (SLRs) đối với các dịch vụ m ới đang được phát triển hoặc được
sản xuất.
Các SLR nên là m ột phần thiết yếu của tiêu chí Thi ết kế Dịch vụ,
trong đó đặc tả kỹ thuật của chức năng là m ột phần của nó. Chúng
nên, ngay từ ban đầu, định hình m ột phần của các tiêu chí ki ểm
nghiệm /thử nghiệm khi dịch vụ tiến triển qua các giai đo ạn thiết kế
dịch vụ và phát tri ển hoặc m ua sắm . SLR này s ẽ được tinh chỉnh
dần dần khi dịch vụ tiến triển qua các giai đoạn của vòng đời của
nó, cho đến khi nó cuối cùng trở thành m ột SLA thử nghiệm trong
khoảng thời gian đ ầu đời của nó. Thử nghiệm này hoặc phác th ảo
của SLA nên đư ợc phát triển cùng với bản thân dịch vụ, và nên
được ký kết và chính th ức hóa trước khi dịch vụ được đưa vào m ôi
trường thật.
Có thể sẽ khó khăn để phác thảo các yêu c ầu khi m à doanh nghi ệp
có lẽ không biết họ m uốn gì – đặc biệt nếu họ chưa t ừng được hỏi
trước đây – và họ có thể sẽ cần sự trợ giúp trong vi ệc tìm hiểu và
xác định các nhu c ầu của họ, cụ thể là về m ặt công suất, bảo m ật,
tính sẵn sàng và liên t ục dịch vụ CNTT. Hãy nhận thức rằng các yêu
cầu được biểu lộ ban đầu có thể không phải là những gì được thỏa
thuận sau cùng. Vài quá trình thương lư ợng lặp đi lặp lại có thể cầ n
thiết trước khi m ột sự cân bằng hợp lý được đưa ra gi ữa những gì
được tìm kiếm và những gì có thể đạt được và hợp lý. Quá trình này
có thể liên quan đ ến việc thiết kế lại các giải pháp dịch vụ cho m ỗi
lần.
Nếu các dịch vụ mới được đưa vào môi trường thật m ột cách li ền
lạc, lĩnh vực khác đòi h ỏi sự quan tâm là việc hoạch định và chính
thức hóa các th ỏa thuận hỗ trợ cho dịch vụ và các thành ph ần của
nó. Nên tìm kiếm lời khuyên từ Quản lý Thay đổi và Quản lý Cấu
hình để đảm bảo việc hoạch định là toàn di ện và bao gồm việc triển

115
khai, thực hiện và hỗ trợ dịch vụ và các thành phần của nó. Trách
nhiệm cụ thể cần được xác định và bổ sung vào các hợp đồng/OLA,
hoặc những hợp đồng/OLA m ới cần được thỏa thuận. Các thỏa
thuận hỗ trợ và m ọi lộ trình leo thang cũng cần được thêm vào CMS,
bao gồm Mục lục Dịch vụ, nếu có thể, để từ đó Bộ phận Hỗ trợ Dịch
vụ và các nhân viên h ỗ trợ khác nhận thức được chúng. Nếu có thể,
đào tạo và làm quen ban đ ầu đối với Bộ phận Hỗ trợ Dịch vụ và các
nhóm hỗ trợ khác và chuyển giao kiến thức nên được hoàn thành
trước khi cần đến hỗ trợ thực tế.
Nên lưu ý r ằng các ngu ồn lực hỗ trợ bổ sung (nghĩa là nhi ều nhân
viên hơn) có thể cần đến để hỗ trợ các dịch vụ m ới. Thường có m ột
kỳ vọng rằng m ột nhóm hỗ trợ làm việc quá s ức thực sự có thể đố i
phó m ột cách thần kỳ với các nỗ lực bổ sung bị áp đặt bởi dịch vụ
mới.
Sử dụng phác thảo thỏa thuận làm nền tảng, các cu ộc đàm phán
phải được tổ chức với (các) khách hàng, ho ặc các đại diện của
khách hàng đ ể hoàn tất nội dung của SLA và các đích nhắm m ục
tiêu về m ức dịch vụ ban đầu, và với nhà cung c ấp dịch vụ để đảm
bảo rằng chúng là có th ể đạt được.
4.2.5.3 Giám sát hiệu su ất dịch vụ so với SLA

Không có gì nên đư ợc bao gồm trong m ột SLA trừ khi nó có thể
được giám sát và đo lư ờng m ột cách hiệu quả tại m ột điểm đã đư ợc
thỏa thuận chung. Tầm quan trọng của điều này không thể bị nhấn
m ạnh quá m ức, vì vi ệc bao gồm các m ục không thể được giám sát
m ột cách hiệu quả luôn luôn d ẫn đến tranh cãi và sau cùng m ất niềm
tin vào quy trình SLM. R ất nhiều tổ chức đã khám phá ra đi ều này
m ột cách khó khăn và k ết quả là đã ph ải gánh chịu những chi phí
nặng nề, cả về khía cạnh tài chính l ần những tác động tiêu cực đến
uy tín của họ.
Một nhà cung c ấp dịch vụ toàn cầu đã thỏa thuận về các đích
nhắm m ục tiêu về tính sẵn sàng cho việc cung cấp m ột dịch vụ
m ạng được quản lý. Các đích nh ắm mục tiêu này đã được thỏa
thuận tại điểm m à dịch vụ xâm nhập vào các cơ sở của khách
hàng. Tuy nhiên, nhà cung c ấp toàn c ầu này chỉ có thể giám sát
và đo lường tính s ẵn sàng t ại điểm kết nối rời khỏi cơ sở của họ.
Các liên kết m ạng đã được cung cấp bởi m ột số các nhà cung cấp
dịch vụ viễn thông t ại các quốc gia, với các m ức độ sẵn sàng r ất
khác nhau. Kết quả là m ột sự không tương xứng giữa những tính
toán về tính sẵn sàng được đưa ra b ởi nhà cung c ấp mạng và
khách hàng, với những cuộc tranh luận và luận cứ kéo dài và gay
gắt.
Những năng lực giám sát hiện hữu nên đư ợc xem xét và nâng c ấp
khi cần thiết. Lý tư ởng là điều này nên được hoàn thành trước khi,
hoặc song song với việc phác thảo các SLA, đ ể từ đó việc giám sát

116
có thể sẵn sàng trợ giúp với các đích nh ắm m ục tiêu được đề xuất
có hiệu lực.
Điều quan tr ọng là việc giám sát khớp với nhận thức thực sự của
khách hàng về dịch vụ. Không m ay là đi ều này rất khó để đạt được.
Ví dụ, việc giám sát các thành ph ần riêng lẻ, chẳng hạn như m ạng
hoặc m áy chủ, không đảm bảo rằng dịch vụ sẽ sẵn sàng cho đ ến này
như khách hàng quan tâm . Nh ận thức của khách hàng t hường là về
việc m ặc dù s ự cố có thể ảnh hưởng t ới nhiều hơn m ột dịch vụ, tất
cả gì m à họ bận tâm là d ịch vụ m à họ không thể tiếp cận t ại thời
điểm sự cố được báo cáo – điều này không phải lúc nào cũng đúng,
vì vậy sự thận trọng là cần thiết. Không có s ự giám sát m ọi thành
phần trong dịch vụ từ đầu-đến-cuối (vốn có thể rất khó khăn và t ốn
kém để có thể đạt được) thì không thể có được m ột bức tranh chân
thực. Tương tự, người sử dụng phải nhận thức được rằng họ nên
báo cáo về các sự cố ngay lập tức để hỗ trợ cho việc chẩn đoán,
đặc biệt nếu chúng có liên quan đ ến-hiệu suất, để từ đó nhà cung
cấp dịch vụ nhận thức được rằng các đích nhắm m ục tiêu c ủa dịch
vụ đang bị vi phạm .
Một số lượng đáng kể các t ổ chức sử dụng Bộ phận Hỗ trợ Dịch vụ

của riêng họ, được liên kết với m ột CMS toàn diện, để giám sát
nhận thức của khách hàng về tính sẵn sàng. Đi ều này có thể liên
quan tới việc thực hiện các thay đổi cụ thể đối với m àn hình ghi
nhận nhật ký sự cố/vấn đề và có thể đòi hỏi sự tuân thủ nghiêm ngặt
các thủ tục ghi nh ật ký sự cố. Tất cả những điều này cần được thảo
luận và thỏa thuận với quy trình Qu ản lý Tính sẵn sàng.
Bộ phận Hỗ trợ Dịch vụ cũng được sử dụng để giám sát thời gian
ứng phó và thời gian gi ải quyết sự cố, nhưng m ột lần nữa, m àn hình
ghi nhật ký có th ể cần được điều chỉnh để thích ứng với việc thu
thập dữ liệu, và th ủ tục gọi-quy trình ghi nhật ký có thể cần được
thắt chặt và phải được tuân thủ nghiêm ngặt. Nếu việc hỗ trợ đang
được cung c ấp bởi m ột bên thứ ba, việc giám sát này cũng có th ể
củng cố cho Quản lý Nhà cung c ấp.
Điều thiết yếu là phải đảm bảo rằng bất kỳ đích nhắm m ục tiêu xử lý
sự cố/vấn đề nào được đưa vào SLA đều phải giống với các m ục
tiêu được bao gồm các công c ụ của Service Desk và đư ợc sử dụng
cho m ục đích giám sát và leo thang. Khi các t ổ chức thất bại trong
việc nhận ra điều này, và có l ẽ đã sử dụng các giá tr ị m ặc định do
nhà cung c ấp công cụ cung cấp, họ đã rơi vào tình huống khi h ọ
đang theo dõi m ột thứ gì đó khác với những điều đã được thỏa
thuận trong SLA, và do đó không th ể nói liệu các đích nh ắm m ục
tiêu của SLA có đư ợc đáp ứng m à không c ần nỗ lực đáng kể để xử
lý dữ liệu. Một số điều chỉnh có thể là cần thiết để hỗ trợ các công
cụ, bao gồm các trường cần thiết để dữ liệu liên quan có th ể được
thu thập.
Một lĩnh vực nổi tiếng khó gi ám sát khác là thời gian ứng phó với
giao dịch (thời gian từ khi gửi m àn hình đến khi nhận được phản

117
hồi). Thông thường thời gian ứng phó từ đầu đến cuối về m ặt kỹ
thuật là rất khó giám sát. Trong nh ững trường hợp như vậy, có thể
thích hợp để giải quyết điều này như sau:
 Bao gồm m ột tuyên bố trong SLA với các dòng sau: ‘Các d ịch
vụ bao gồm trong SLA được thiết kế để ứng phó với tốc độ
cao và không có đ ộ trễ đáng kể nào xảy ra. Nếu độ trể của
thời gian ph ản hồi chậm hơn x giây trong nhi ều hơn y phút,
điều này phải được báo cáo ngay l ập tức cho Bộ phận Hỗ trợ
Dịch vụ.
 Thỏa thuận và đưa vào SLA m ột đích nhắm m ục tiêu có th ể
chấp nhận được về số lượng các s ự cố như trên có thể chịu
đựng được trong k ỳ báo cáo.
 Tạo m ột chỉ m ục sự cố 'ứng phó kém ' (ho ặc tương tự) và đảm
bảo rằng bất kỳ sự cố nào như vậy đều được ghi lại chính xác
và chúng có liên quan đ ến dịch vụ tương ứng.
 Đưa ra các báo cáo thư ờng xuyên về các trường hợp m à đích
nhắm m ục tiêu về thời gian phản hồi giao dịch SLA đã b ị vi
phạm và khởi nguồn các cuộc điều tra thông qua Qu ản lý Vấ n
đề để khắc phục tình hình.
Phương pháp tiếp cận này không chỉ khắc phục những khó khăn về
kỹ thuật trong giám sát m à còn đ ảm bảo rằng các sự cố được ứng
phó kém được báo cáo t ại thời điểm chúng xảy ra. Điều này là r ất
quan trọng, vì ứng phó kém thường do m ột số sự kiện tương tác
nhất thời chỉ có thể được phát hiện nếu chúng được điều tra ngay
lập tức
Phương pháp được ưa thích, tuy nhiên, là tri ển khai m ột vài hình
thức giám sát thời gian ứng phó m áy khách/m áy ch ủ được tự động
hóa trên cơ sở tham vẫn chặt chẽ với Vận hành Dịch vụ. Nếu có thể,
triển khai việc lấy m ẫu hoặc các công cụ và kỹ thuật ‘người m áy’ để
đưa ra các d ấu hiệu về hiệu suất kém hoặc chậm chạp. Những công
cụ này m ang l ại khả năng đo lường hoặc lấy m ẫu theo thời gian ứng
phó thực tế hoặc tương tự đối với những gì đang được trải nghiệm
bởi nhiều người sử dụng và ngày càng tiết kiệm chi phí hơn trong s ử
dụng.
Một vài t ổ chức nhận ra rằng, trong th ực tế, ‘ứng phó kém’ th ỉnh
thoảng là m ột vấn đề trong nhận thức của người sử dụng. Người
sử dụng, đã quen với m ột m ức độ ứng phó trong m ột khoảng thời
gian, bắt đầu phàn nàn ngay khi m ức độ ứng phó trở nên chậm
hơn. Có quan đi ểm rằng ‘nếu người sử dụng đang nghĩ rằng dịch
vụ đang chậm , thì đúng là v ậy’.

118
Nếu như SLA bao g ồm các đích nhắm m ục tiêu cho vi ệc đánh giá và
triển khai Yêu cầu Thay đổi (RFCs), việc giám sát các đích nh ắm
m ục tiêu liên quan t ới Quản lý Thay đ ổi lý tưởng là nên được thực
hiện bằng cách s ử dụng các công dụ Quản lý Thay đổi đang đư ợc
sử dụng (tốt nhất là m ột phần của công cụ hỗ trợ Quản lý Dịch vụ đã
được tích hợp) và các quy trình leo thang và thay đ ổi m àn hình ghi
nhật ký nên hỗ trợ cho việc này.
4.2.5.4 Kiểm tra, đo lư ờng và cải thiện mức độ hài lòng của
khách hàng
Có m ột số vấn đề "m ềm" quan trọng không thể được giám sát bằng
các phương tiện cơ giới hoặc thủ tục, chẳng hạn như cảm xúc t ổng
thể của khách hàng (những vấn đề này không nhất thiết phải khớp
với việc giám sát "cứng"). Ví dụ, ngay cả khi đã có m ột số lỗi dịch
vụ được báo cáo, khách hàng v ẫn có thể cảm thấy tích c ực về m ọi
thứ, bởi vì họ có thể cảm thấy hài lòng rằng các hành động thíc h
hợp đã được thực hiện để cải thiện m ọi thứ. Dĩ nhiên, đi ều ngược
lại là có th ể và khách hàng có th ể cảm thấy không hài lòng với m ột
số vấn đề (ví dụ: cách làm vi ệc của m ột số nhân viên t ại Bộ phận Hỗ
trợ Dịch vụ) khi m ột số hoặc không có đích nh ắm m ục tiêu SLA nào
bị phá vỡ.
Ngay từ đầu, điều khôn ngoan là thử và quản lý các k ỳ vọng của
khách hàng. Đi ều này có nghĩa là vi ệc thiết lập các k ỳ vọng thích
hợp và đích nh ắm các m ục tiêu phù h ợp ngay từ đầu, đồng thời đưa
ra m ột quy trình có hệ thống để quản lý các k ỳ vọng về sau, vì sự
hài lòng = nhận thức - kỳ vọng (trong đó đi ểm số 0 hoặc số dương
cho thấy khách hàng hài lòng). Các SLA ch ỉ là những tài liệu và bản
thân nó không làm thay đ ổi đáng k ể chất lượng dịch vụ đang được
cung cấp (m ặc dù chúng có thể ảnh hưởng đến hành vi và giúp hình
thành văn hóa dịch vụ tương xứng, vốn có thể có tác dụng tức thì và
có thể cải thiện trong dài hạn hơn). Do đó, m ột m ức độ kiên nhẫn là
cần thiết và nên đư ợc tích hợp trong các k ỳ vọng.
Khi các khoản phí được tính cho các dịch vụ được cung cấp, điều
này nên sửa đổi nhu c ầu của khách hàng. (Khách hàng có th ể có bất
cứ thứ gì họ có thể được cung c ấp chi phí h ợp lý - m iễn là nó phù
hợp với chiến lược công ty đã được thỏa thuận - và có ngân sách
được phép, nhưng không hơn. ) Khi tính phí tr ực tiếp không được
thực hiện, sự hỗ trợ của các nhà qu ản lý doanh nghi ệp cấp cao nên
được tranh thủ để đảm bảo rằng các nhu cầu quá m ức hoặc phi thực
tế không được đặt ra cho nhà cung c ấp CNTT bởi bất kỳ nhóm
khách hàng cá nhân nào.
Do đó, chúng tôi khuy ến nghị rằng những cố gắng cần được thực
hiện để theo dõi nh ận thức của khách hàng v ề các vấn đề m ềm này.
Các phương pháp thực hiện điều này bao g ồm :
 Các bảng câu hỏi và khảo sát khách hàng định kỳ.
 Phản hồi của khách hàng từ các cuộc họp xem xét dịch vụ.

119
 Phản hồi từ Đánh giá Sau tri ển khai (Post Im plem entation
Reviews – PIRs) được tiến hành như m ột phấn của quy trình
Quản lý Thay đ ổi đối với các thay đ ổi, bản phát hành, dịch vụ
mới hoặc được thay đổi quan trọng, v.v…
 Các khảo sát nhận thức qua điện thoại (có lẽ là ngẫu nhiên từ
Bộ phận Hỗ trợ Dịch vụ hoặc sử dụng các đại diện liên h ệ với
khách hàng thường xuyên).
 Công bố khảo sát m ức độ hài lòng của khách hàng (được để
lại cho khách hàng sau khi cài đ ặt, ghé thăm dịch vụ, v.v…).
 Các cuộc họp nhóm hoặc diễn đàn ngư ời sử dụng.
 Phân tích các phàn nàn và khen ng ợi.
Nếu có thể, các đích nh ắm m ục tiêu nên được thiết lập cho những
điều này và được giám sát như m ột phần của SLA (ví d ụ: điểm trung
bình là 3,5 nên đạt được bởi nhà cung c ấp dịch vụ căn cứ vào kết
quả đưa ra, dựa trên hệ thống cho đi ểm từ 1 đến 5, trong đó 1 là
hoạt động kém và 5 là xu ất sắc ). Hãy đ ảm bảo rằng nếu người sử
dụng cung cấp phản hồi, họ sẽ nhận được m ột số phản hồi và chứng
m inh cho họ thấy rằng nhận xét c ủa họ đã được kết hợp với m ột kế
hoạch hành động, có th ể là m ột SIP. Tất cả các thước đo về m ức độ
hài lòng c ủa khách hàng nên đư ợc xem xét lại và khi các bi ến thể đã
được xác định, chúng ph ải được phân tích cùng với hành động được
thực hiện để điều chỉnh sự khác biệt.
4.2.5.5 Xem xét và điều chỉnh các thỏa thu ận và phạm vi dịch
vụ nền tảng
Ở m ột m ức độ nào đó, các nhà cung c ấp dịch vụ CNTT phụ thuộc
vào nhóm hỗ trợ kỹ thuật nội bộ của chính họ hoặc vào các đ ối tác
hoặc nhà cung c ấp bên ngoài. H ọ không thể cam kết đáp ứng các
đích nhắm m ục tiêu SLA tr ừ khi hiệu suất của nhóm hỗ trợ và nhà
cung cấp của chính họ củng cố cho các đích nh ắm m ục tiêu này.
Các hợp đồng với các nhà cung c ấp bên ngoài là b ắt buộc, nhưng
nhiều tổ chức cũng đã xác đ ịnh được lợi ích t ừ việc có được các
thỏa thuận đơn giản với các nhóm hỗ trợ nội bộ, thường được gọi là
OLA. 'Các th ỏa thuận nền tảng’ là m ột thuật ngữ được sử dụng để
chỉ tất cả các OLA, SLA và hợp đồng cơ sở.
Thông thường, những thỏa thuận này còn được gọi là thỏa thuận
‘tương hỗ’. Điều này phản ánh sự cần thiết phải đảm bảo rằng m ọi
đích nhắm m ục tiêu trong các th ỏa thuận cơ sở hoặc 'tương h ỗ' đều
được liên k ết với và hỗ trợ cho, các đích nh ắm m ục tiêu đã được
thỏa thuận với doanh nghiệp trong các SLA ho ặc OLA. Có thể có
m ột vài lớp của các thỏa thuận nền tảng hoặc ‘tương hỗ’ này với các
đích nhắm m ục tiêu đã được liên k ết. Điều thiết yếu là các đích
nhắm m ục tiêu ở mỗi lớp phải được liên kết với, và hỗ trợ cho, các
đích nhắm m ục tiêu có trong các c ấp cao hơn (tức là những m ục tiêu
gần với m ục tiêu kin h doanh nhất).
Các OLA không c ần phải quá phức tạp, nhưng nên đặt ra các đíc h
nhắm m ục tiêu tương h ỗ cụ thể cho các nhóm hỗ trợ để làm cơ sở
cho các đích nhắm m ục tiêu có trong các SLA. Ví d ụ: nếu SLA bao

120
gồm thời gian t ổng thể để phản hồi và khắc phục các mục tiêu đối
với các sự cố (sự thay đổi về m ức độ ưu tiên), thì các OLA nên bao
gồm các đích nh ắm m ục tiêu cho t ừng yếu tố trong chuỗi hỗ trợ. Tuy
nhiên, c ần phải hiểu rằng các đích nh ắm mục tiêu giải quyết sự cố
bao gồm trong SLA thường không nên khớp với các đích nh ắm mục
tiêu tương t ự trong hợp đồng hoặc OLA với nhà cung cấp. Điều này
là vì các đích nhắm m ục tiêu SLA phải bao gồm m ột yếu tố cho m ọi
giai đoạn trong chu kỳ hỗ trợ (ví dụ: thời gian phát hi ện, thời gian
ghi nhật ký t ại Bộ phận Hỗ trợ Dịch vụ, thời gian leo thang, th ời gian
chuyển đến giữa các nhóm , v.v..., Bộ phận Hỗ trợ Dịch vụ xem xét
và thời gian đóng lại - cũng như thời gian thực tế xử lý lỗi).
Đích nhắm m ục tiêu SLA nên bao g ồm thời gian c ần thiết để trả lời
các cuộc gọi, leo thang s ự cố cho nhân viên hỗ trợ kỹ thuật và thờ i
gian cần thiết để bắt đầu tìm hiểu và giải quyết các s ự cố được giao
cho họ. Ngoài ra, giờ hỗ trợ tổng thể nên được quy định cho tất cả
các nhóm làm nền t ảng cho thời gian s ẵn sàng của dịch vụ được yêu
cầu trong SLA. Nếu có các th ủ tục đặc biệt dành cho nhân viên đư ợc
liên hệ (ví dụ: hỗ trợ qua điện thoại ngoài giờ làm việc) thì chúng
cũng phải được lập thành văn bản.
Các OLA nên được giám sát đ ối với các đích nh ắm m ục tiêu OLA và
SLA, và các báo cáo v ề những thành t ựu được cung c ấp dưới dạng
phản hồi cho các nhà quản lý tương x ứng của từng nhóm hỗ trợ.
Điều này làm nổi bật các khu vực có vấn đề tiềm ẩn, có thể cần
được giải quyết trong nội bộ hoặc bằng cách xem xét thêm SLA ho ặc
OLA. Sự xem xét nghiêm túc nên đư ợc thực hiện đối với việc giới
thiệu các OLA chính th ức cho m ọi nhóm hỗ trợ nội bộ, những nhóm
góp phần hỗ trợ cho các dịch vụ vận hành.
Trước khi cam kết với các SLA m ới hoặc đã được sửa đổi, do đó,
điều quan trọng là các th ỏa thuận hợp đồng hiện có phải được tìm
hiểu và nâng c ấp khi c ần thiết. Điều này có khả năng làm phát sinh
chi phí bổ sung, ph ải được CNTT gánh ch ịu hoặc chuyển sang cho
khách hàng. Trong trư ờng hợp thứ hai, khách hàng ph ải đồng ý với
điều này, hoặc các đích nhắm m ục tiêu được nới lỏng hơn trong các
hợp đồng hiện tại nên được thỏa thuận để đưa vào SLA. Hoạt động
này cần được hoàn thành với sự tham vấn chặt chẽ của quy trình
Quản lý Nhà cung c ấp, để đảm bảo rằng không chỉ đáp ứng các yêu
cầu SLM m à m ọi yêu c ầu khác c ủa quy trình được xem xét, đặc biệt
là các chính sách và tiêu chu ẩn đối với nhà cung c ấp và hợp đồng.
4.2.5.6 Đưa ra các báo cáo d ịch vụ

Ngay lập tức sau khi SLA đư ợc thỏa thuận và chấp nhận, việc giám
sát phải được tiến hành và các báo cáo v ề thành t ựu của dịch vụ
phải được tạo ra. Báo cáo vận hành phải được tạo ra m ột cách
thường xuyên (hàng tuần - thậm chí có thể thường xuyên hơn) và,
nếu có thể, các báo cáo ngo ại lệ phải được tạo ra bất cứ khi nào
SLA bị phá vỡ (hoặc bị đe dọa, nếu các ngưỡng thích hợp đã được
thiết lập để đưa ra 'c ảnh báo sớm '). Đôi khi có th ể sẽ gặp phải khó
khăn trong việc đáp ứng các đích nh ắm m ục tiêu của các dịch vụ

121
mới trong giai đoạn hỗ trợ đầu đời vì khối lượng lớn các RFC. Vi ệc
giới hạn số lượng RFC được xử lý trong thời gian hỗ trợ đầu đời có
thể hạn chế tác động của các thay đ ổi.
Các cơ chế báo cáo SLA, khoảng thời gian và đ ịnh dạng báo cáo
phải được xác định và thỏa thuận với khách hàng. T ần suất và hình
thức của các Cuộc họp Đánh giá Dịch vụ cũng phải được thỏa thuận
với khách hàng. Các kho ảng thời gian định kỳ được khuyến nghị, với
các báo cáo đ ịnh kỳ được đồng bộ với chu k ỳ xem xét.
Báo cáo định kỳ phải được tạo ra và g ửi cho khách hàng (ho ặc đại
diện của họ) và các nhà qu ản lý CNTT thích hợp m ột vài ngày trước
khi đánh giá m ức dịch vụ, để m ọi thắc m ắc hoặc bất đồng có thể
được giải quyết trước cuộc họp đánh giá. Cuộc họp sau đó sẽ không
bị chuyển hướng bởi những vấn đề như vậy.
Các báo cáo đ ịnh k ỳ nên kết hợp các chi ti ết về hiệu suất so với m ọi
đích nhắm m ục tiêu SLA, cùng với chi tiết về bất kỳ xu hướng hoặc
hành động cụ thể nào đang được thực hiện để cải thiện chất lượng
dịch vụ. Một kỹ thuật hữu ích là bao g ồm m ột biểu đồ Giám sát SLA
(SLAM) ở phần trước báo cáo d ịch vụ để cung c ấp m ột cái nhìn t ổng
quan ‘trong-nháy-mắt’ về cách thành tích ph ải được đo lường so với
các đích nh ắm m ục tiêu như th ế nào. Chúng hiệu quả nhất nếu được
m ã hóa bằng m àu (Đỏ, Hổ phách, Xanh l ục, và đôi khi được gọi là
biểu đồ RAG). Các báo cáo t ạm thời khác có th ể được yêu c ầu bởi
các nhà quản lý CNTT đ ối với OLA hoặc đánh giá hi ệu suất nội bộ
và/hoặc nhà cung c ấp hoặc quản lý hợp đồng. Đây có thể là m ột quá
trình đang phát tri ển - nỗ lực đầu tiên không ch ắc là kết quả cuối
cùng.
Các nguồn lực cần thiết để tạo ra và xác m inh báo cáo không nên b ị
đánh giá th ấp. Việc này có thể vô cùng tốn thời gian, và nếu các báo
cáo không phản ánh nhận thức của chính khách hàng về chất lượng
dịch vụ m ột cách chính xác, chúng có th ể làm cho tình hình t ồi tệ
hơn. Điều thiết yếu là thông tin chính xác t ừ m ọi lĩnh vực và quy
trình (ví dụ: Quản lý Sự cố, Quản lý V ấn đề, Quản lý Tính sẵn sàng,
Quản lý Công suất, Quản lý Thay đổi và Quản lý Cấu hình) được
phân tích và đối chiếu trong m ột báo cáo súc tích và toàn di ện về
hiệu suất dịch vụ, được đo lường dựa trên các đích nh ắm hoạt động
kinh doanh đã th ỏa thuận.
SLM nên xác đ ịnh các nhu c ầu báo cáo c ụ thể và tự động hóa vi ệc
tạo ra các báo cáo này, càng nhi ều càng t ốt. Mức độ, độ chính xác
và m ức độ dễ dàng m à các báo cáo t ự động có thể được tạo ra nên
định hình m ột phần của tiêu chí lựa chọn các công cụ hỗ trợ tích
hợp. Các báo cáo dịch vụ này không ch ỉ bao gồm chi tiết về hiệu
suất hiện tại so với các đích nh ắm m ục tiêu, m à còn phải cung c ấp
thông tin l ịch sử về hiệu suất và xu hư ớng trong quá kh ứ để từ đó
tác động của các hành đ ộng cải tiến có thể được đo lường và dự
đoán.

122
4.2.5.7 Tiến hành xem xét d ịch vụ và thúc đẩy các cải tiến trong
một SIP tổng th ể
Các cuộc hợp xem xét đ ịnh kỳ phải được tiến hành với khách hàng
trên cơ s ở định kỳ (hoặc các đại diện của họ) để xem xét thành t ựu
của dịch vụ trong chu k ỳ trước đo và để duyệt trước bất kỳ vấn đề
nào cho chu k ỳ tiếp theo. Thông thư ờng thì những cuộc họp này
được tiến hành hàng tháng, ho ặc tối thiểu, hàng quý.
Các hành động phải được thực hiện đối với cả khách hàng l ẫn nhà
cung cấp dịch vụ m ột cách thích hợp để cải thiện nhưng khu vực yếu
kém nơi m à các đích nh ắm m ục tiêu đã không đư ợc đáp ứng. Mọi
hành động phải được lập thành biên bản, và tiến trình nên được xem
xét trong cu ộc họp kế tiếp để đảm bảo rằng các m ục hành động
được theo dõi và tri ển khai m ột cách đúng đ ắn.
Sự tập trung đặc biệt cần được đặc biệt chú ý trên m ỗi sự vi phạm
m ức độ dịch vụ để xác định m ột cách chính xác nguyên nhân gây ra
m ất dịch vụ và những gì có th ể được hoàn thành đ ể ngăn ngừa bất
kỳ sự lặp lại nào. N ếu đã quyết định là m ức dịch vụ đã, hoặc đã trở
nên, không thể đạt được, có thể sẽ cần phải xem xét, thương lư ợng
lại, xem xét-thỏa thuận các đích nh ắm m ục tiêu khác nhau. N ếu như
sự cố gián đoạn dịch vụ có nguyên nhân là do l ỗi của bên th ứ ba
hoặc nhóm hỗ trợ nội bộ, cũng có thể sẽ phải xem xét thỏa thuận
hoặc OLA cơ sở. Phân tích chi phí và tác đ ộng của sự vi phạm dịch
vụ cung cấp đầu vào và sự biện m inh cho các ho ạt động SIP và các
hành động có giá trị. Nhu cầu liên t ục đối với các cải thiện cần được
cân bằng và tập trung vào những lĩnh vực có khác năng đem lại lợi
ích lớn nhất cho việc kinh doanh.
Các báo cáo nên đư ợc tạo ra về tiến trình và thành công c ủa SIP,
chẳng hạn như s ố lượng hành động SIP đã được hoàn thành và s ố
lượng hành động mang l ại được lợi ích đã đư ợc kỳ vọng của chúng.
‘Một gián điệp ở cả hai phe’ – Các Nhà Qu ản lý Mức Dịch vụ có

thể bị nhìn bằng ánh m ắt với m ột lượng nghi ngờ nhất định bởi cả
nhân viên nhà cung c ấp dịch vụ CNTT và đ ại diện khách hàng.
Điều này là do bản chất kép của công vi ệc, nơi họ đóng vai trò là
đại diện khách hàng không chính th ức khi nói chuyện với nhân
viên CNTT và là đ ại diện của nhà cung cấp CNTT khi nói chuy ện
với khách hàng. Đi ều này thường trở nên trầm trọng hơn khi ph ải
đại diện cho quan đi ểm của 'phe đối lập' trong bất kỳ cuộc họp
nào, v.v… Để tránh đi ều này, Nhà Qu ản lý Mức Dịch vụ nên cởi
mở và hữu ích nhất có thể (trong giới hạn của bất kỳ quyền
thương m ại nào) khi giao d ịch với cả hai bên, m ặc dù đồng nghiệp
không bao giờ nên bị chỉ trích m ột cách công khai.
4.2.5.8 Xem xét và đi ều chỉnh các SL A, ph ạm vi dịch vụ và các

thỏa thuận nền tảng
Tất cả các thỏa thuận và thỏa thuận nền tảng, bao gồm SLA, hợp
đồng nền tảng và OLA, phải được cập nhật. Chúng ph ải được đặt
dưới sự kiểm soát của Quản lý Thay đổi và Quản lý Cấu hình và

123
được xem xét m ột cách định kỳ, ít nhất là hàng năm , để đảm bảo
rằng chúng vẫn hiện hành và toàn diện, đồng thời vẫn được liên kết
với nhu c ầu và chiến lược kinh doanh.
Những đánh giá này ph ải đảm bảo rằng các dịch vụ được đề cập và
các đích nh ắm mục tiêu cho m ỗi dịch vụ vẫn còn phù hợp - và rằng
không có gì thay đ ổi đáng k ể làm m ất hiệu lực của thỏa thuận theo
bất kỳ cách nào (đi ều này nên bao g ồm thay đổi cơ sở hạ tầng, thay
đổi việc kinh doanh, thay đ ổi nhà cung cấp, v.v...). Khi các thay đ ổi
được thực hiện, các thỏa thuận phải được cập nhật dưới sự kiểm
soát của Quản lý Thay đổi để phản ánh tình hu ống m ới. Nếu tất cả
các thỏa thuận được ghi nhận dưới dạng các CI trong CMS, thì vi ệc
đánh giá tác động và th ực hiện các thay đ ổi m ột cách có kiểm soát
sẽ dễ dàng hơn.
Các đánh giá này cũng nên bao g ồm các tài li ệu chiến lược tổng thể,
để đảm bảo rằng m ọi dịch vụ và thỏa thuận dịch vụ tuân thủ các
chiến lược và chính sách kinh doanh và CNTT.
4.2.5.9 Phát triển các mối liên hệ và quan h ệ

Một điều rất quan trọng là SLM phải phát tri ển lòng tin và s ự tôn
trọng với doanh nghi ệp, đặc biệt là với các m ối quan hệ kinh doanh
chính yếu. Sử dụng Mục lục Dịch vụ, đặc biệt là phần tử Mục lục
Dịch vụ Nghiệp vụ của nó, cho phép SLM ch ủ động hơn nhi ều. Mục
lục Dịch vụ cung c ấp thông tin cho phép SLM hi ểu về các m ối quan
hệ giữa các dịch vụ với các đơn vị kinh doanh và các quy trình
nghiệp vụ phụ thuộc vào các d ịch vụ đó. Nó cũng nên cung c ấp
thông tin về tất cả các m ối liên hệ kinh doanh và CNTT chính y ếu
liên quan đ ến các dịch vụ, việc sử dụng và tầm quan trọng của
chúng. Để đảm bảo rằng việc này được thực hiện theo m ột cách
nhất quán, SLM nên thực hiện các hoạt động sau:
 Xác nhận các bên liên quan, khách hàng và các nhà qu ản lý
doanh nghiệp chủ chốt và người sử dụng dịch vụ.
 Hỗ trợ việc duy trì thông tin chính xác trong Danh m ục Dịch vụ
và Mục lục Dịch vụ.
 Linh hoạt và đáp ứng các nhu cầu của doanh nghiệp, khách
hàng và người sử dụng, đồng thời hiểu các quy trình nghi ệp
vụ m ới trong hiện tại và ddax được lập kế hoạch cũng như các
yêu cầu của chúng đối với các dịch vụ mới hoặc đã được thay
đổi, ghi nhận và truyền đạt các yêu c ầu này cho tất cả các quy
trình khác cũng như t ạo điều kiện và c ải tiến thay đổi ở bất cứ
đâu có lợi ích cho doanh nghi ệp.
 Phát triển m ột sự hiểu biết đầy đủ về các chiến lược, kế hoạch
kinh doanh, nhu c ầu và m ục tiêu kinh doanh c ủa doanh
nghiệp, khách hàng và ngư ời sử dụng, đảm bảo rằng CNTT
đang hoạt động trong m ối quan hệ cộng tác với doanh nghiệp,
khách hàng và ngư ời sử dụng, phát tri ển các m ối quan h ệ lâu
dài.
 Thường xuyên thực hiện hành trình của khách hàng và lấ y
m ẫu trải nghiệm của khách hàng, cung c ấp phản hồi về các

124
vấn đề của khách hàng cho CNTT. (Đi ều này áp d ụng cho c ả
khách hàng CNTT và c ả khách hàng doanh nghi ệp bên ngoài
sử dụng dịch vụ CNTT của họ).
 Đảm bảo rằng các quy trình quan h ệ đúng đắn có sẵn để đạt
được các m ục tiêu và chúng ph ải được cải tiến liên tục.
 Tiến hành và hoàn thành các cu ộc khảo sát khách hàng, h ỗ trợ
phân tích các cu ộc khảo sát đã hoàn thành và đ ảm bảo rằng
các hành động được thực hiện dựa trên kết quả.
 Đóng vai trò như m ột đại diện CNTT về việc tổ chức và tham
gia các nhóm ngư ời sử dụng.
 Chủ động tiếp thị và khai thác Danh m ục Dịch vụ và Mục lục
Dịch vụ và việc sử dụng các dịch vụ trong m ọi lĩnh vực của
doanh nghiệp.
 Làm việc với doanh nghi ệp, khách hàng và ngư ời sử dụng để
đảm bảo rằng CNTT cung cấp các m ức dịch vụ thích hợp nhất
để đáp ứng nhu c ầu kinh doanh hi ện tại và trong tương lai.
 Thúc đẩy nhận thức và hiểu biết về dịch vụ.
 Nâng cao nh ận thức về lợi ích cho doanh nghi ệp thu được từ
việc khai thác công ngh ệ m ới.
 Tạo điều kiện thuận lợi cho việc phát triển và thương lư ợng
các SLR và SLA phù h ợp, có thể đạt được và thực t ế giữa
doanh nghiệp và CNTT.
 Đảm bảo doanh nghi ệp, khách hàng và ngư ời sử dụng hiểu rõ
trách nhiệm /cam kết của họ đối với CNTT (nghĩa là các ph ụ
thuộc vào CNTT).
 Hỗ trợ việc duy trì m ột đăng ký t ất cả các cải tiến và tăng
cường nổi bật.
4.2.5.10 Các phàn nàn và khen ng ợi

Quy trình SLM cũng nên bao g ồm các ho ạt động và thủ tục đối với
việc ghi nhật ký và qu ản lý t ất cả các khiếu nại và khen ngợi. Các
thủ tục ghi nhật ký thường được thực hiện bởi Bộ phận Hỗ trợ Dịch
vụ vì chúng tương t ự như của các quy trình Qu ản lý Sự cố và Thực
hiện Yêu cầu. Định nghĩa về m ột lời phàn nàn và khen ng ợi phải
được thỏa thuận với khách hàng, cùng với các đầu m ối liên hệ và
thủ tục đã được thỏa thuận đối với sự quản lý và phân tích c ủa họ.
Mọi phàn nàn và khen ng ợi cần được ghi nhận lại và truyền đạt cho
các bên liên quan. M ọi phàn nàn cũng nên đư ợc tiến hành và xử lý
để người khởi xướng hài lòng. Nếu không, nên có m ột liên hệ và thủ
tục leo thang cho m ọi khiếu nại không được xử lý và giải quyết trong
phạm vi m ột khoảng thời gian thích h ợp. Tất cả các khiếu nại tồn
đọng nên được xem xét và chuyển lên cho qu ản lý cấp cao nếu thích
hợp. Các báo cáo cũng nên đư ợc tạo ra về số lượng và các loại
khiếu nại, các xu hướng đã được xác định và các hành đ ộng đã thực
hiện để giảm số lượng (khiếu nại) nhận được. Các báo cáo tương t ự
cũng nên được đưa ra đ ối với các lời khen.
4.2.6 4.1.6 Các điều kiện kích hoạt, đầu vào, đ ầu ra và tương tác
Có rất nhiều điều kiện kích hoạt thúc đẩy các hoạt động SLM. Chúng
bao gồm :

125
 Những thay đổi trong Danh m ục Dịch vụ, chẳng hạn như các
yêu cầu kinh doanh m ới hoặc được thay đổi hoặc các dịch vụ
mới hoặc được thay đổi.
 Các thỏa thuận, SLR, SLA, OLA và h ợp đồng m ới hoặc đã
đưọc thay đ ổi.
 Các cuộc họp và hành đ ộng xem xét d ịch vụ.
 Các lời khen và phàn nàn, khi ếu nại.
 Những hoạt động định kỳ chẳng hạn như xem xét, báo cáo và
khảo sát m ức độ hài lòng c ủa khách hàng.
 Những thay đ ổi trong chính sách hoặc chiến lược.
4.2.6.1 Các đầu vào của quy trình SLM

Có m ột số nguồn thông tin liên quan t ới quy trình Qu ản lý Mức Dịch
vụ. Chúng nên bao gồm :
 Thông tin kinh doanh: t ừ chiến lược kinh doanh, các k ế hoạch
và kế hoạch tài chính của tổ chức và thông tin về các yêu cầu
hiện tại và tương lai c ủa họ.
 Phân tích Tác đ ộng Kinh doanh: cung c ấp thông tin về tác
động, m ức độ ưu tiên, rủi ro và s ố lượng người sử dụng tương
ứng với từng dịch vụ.
 Yêu cầu kinh doanh: chi ti ết về bất kỳ yêu cầu kinh doanh m ới
hoặc thay đổi và đã được thỏa thuận.
 Các chiến lược, chính sách và ràng bu ộc từ Chiến lược Dịch
vụ.
 Danh m ục Dịch vụ và Mục lục Dịch vụ
 Thông tin về sự thay đổi: từ quy trình Quản lý Thay đ ổi với
m ột lịch trình thay đổi trước và nhu cầu đánh giá tất cả các
thay đổi về tác động của chúng đối với tất cả các dịch vụ
 CMS: bao g ồm những thông tin về các m ối quan hệ giữa các
dịch vụ nghiệp vụ, các dịch vụ hỗ trợ và công ngh ệ.
 Phản hồi của khách hàng và ngư ời sử dụng, những khiếu nại
và khen ngợi.
 Các đầu vào khác: ba o gồm các lời khuyên, thông tin và đ ầu
vào từ bất kỳ các quy trình nào khác (ví d ụ, Quản lý S ự cố,
Quản lý Công su ất và Quản lý Tính s ẵn sàng), cùng với các
SLA, SLR và OLA hi ện hữu và các báo cáo d ịch vụ trong quá
khứ về chất lượng của dịch vụ đã cung cấp.
4.2.6.2 Các đầu ra của quy trình SLM

Các đầu ra của Quản lý Mức Dịch vụ nên bao gồm :
 Báo cáo dịch vụ: cung c ấp thông tin chi ti ết về các m ức dịch
vụ đạt được trong m ối tương quan với các đích nh ắm m ục tiêu
được bao gồm trong SLA. Các báo cáo này nên ch ứa thông tin
chi tiết về m ọi khía cạnh của dịch vụ và việc cung cấp nó, bao
gồm hiệu suất hiện tại và trong l ịch sử, các vi phạm và những
điểm yếu, các sự kiện lớn, các thay đ ổi đã được hoạch định,
khối lượng công vi ệc hiện tại và được dự đoán, phản hồi của
khách hàng cũng như các k ế hoạch và hoạt động cải tiến.

126
 Kế hoạch Cải tiến Dịch vụ (SIP): m ột chương trình hoặc kế
hoạch tổng thể về các hành động cải tiến được được thiết lập
độ ưu tiên, bao g ồm m ọi dịch vụ và m ọi quy trình, cùng với
các tác động và rủi ro tương ứng.
 Kế hoạch Chất lượng Dịch vụ: lập hồ sơ và hoạch định cải tiến
tổng thể chất lượng dịch vụ.
 Biểu m ẫu tài li ệu: các bi ểu m ẫu tài liệu, định dạng và nội dung
tiêu chuẩn cho SLA, SLR và OLA, đư ợc liên k ết với tiêu chu ẩn
của công ty.
 Thỏa thuận Mức Dịch vụ (SLAs): m ột tập hợp các đích nh ắm
m ục tiêu và trách nhi ệm nên đư ợc lập thành văn b ản và thỏa
thuận trong m ột SLA cho m ỗi dịch vụ vận hành.
 Yêu cầu Mức Dịch vụ (SLRs): m ột tập hợp các đích nh ắm m ục
tiêu và trách nhi ệm nên đư ợc lập thành văn bản và thống nhất
trong SLR cho m ỗi dịch vụ m ới hoặc đã thay đổi được đề xuất.
 Thỏa thuận Mức Vận hành (OLA): m ột tập hợp các đích nhắm
m ục tiêu và trách nhi ệm nên được lập thành văn bản và thống
nhất trong OLA cho m ỗi nhóm hỗ trợ nội bộ.
 Các Báo cáo về OLA và các hợp đồng cơ sở.
 Các Biên bản cuộc họp và các hành đ ộng đánh giá d ịch vụ: tất
cả các cuộc họp nên được lên lịch trên cơ sở thường xuyên,
cùng với các chương trình ngh ị sự đã được lên k ế hoạch và
các cuộc thảo luận và hành đ ộng của chúng được ghi nhận lại
và tiến triển.
 Biên bản cuộc họp xem xét SLA và đánh giá ph ạm vi dịch vụ:
tóm tắt các hành đ ộng và s ửa đổi đã được thỏa thuận đối với
SLA và phạm vi dịch vụ.
 Hợp đồng được sửa đổi: các thay đ ổi đối với SLA ho ặc SLR
mới có thể đòi hỏi các hợp đồng nền tảng hiện tại phải thay
đổi hoặc các hợp đồng m ới phải được thương lư ợng và thỏa
thuận.
4.2.7 Các Chỉ số Hiệu su ất Chính yếu (KPI)

Các Chỉ số Hiệu suất Chính yếu (KPIs) và các chỉ số có thể được sử
dụng để phán xét tính hi ệu quả và hiệu lực của các hoạt động SLM
và tiến trình của SIP. Những chỉ số này nên đư ợc phát triển từ quan
điểm dịch vụ, khách hàng và kinh doanh và nên bao g ồm cả các
thước đo khách quan và ch ủ quan như dưới đây:
Khách quan:
 Số lượng hoặc tỷ lệ phần trăm các đích nh ắm m ục tiêu d ịch vụ

được đáp ứng.
 Số lượng và m ức độ nghiêm trọng của các vi ph ạm dịch vụ.
 Số lượng của các dịch vụ với SLA c ập nhật.
 Số lượng của các dịch vụ với các báo cáo k ịp thời và các xem
xét dịch vụ đang hoạt động.
Chủ quan:
 Các cải thiện trong m ức độ hài lòng của khách hàng.

127
Thông tin thêm về các KPI, thước đo và cải thiện có thể được tìm
thấy trong các ph ần sau đây và trong ấn phẩm Liên t ục Cải thiện
Dịch vụ.
Đừng rơi vào b ẫy của việc sử dụng t ỷ lệ phần trăm như là ch ỉ số

duy nhất. Rất dễ bị phát hiện khi có m ột hệ thống nhỏ với các
điểm đo lường hạn chế (tức là m ột lỗi duy nhất trong m ột tập hợp
100 chỉ là 1% ; m ột lỗi duy nhất trong t ập hợp 50 là 2% - nếu đích
nhắm m ục tiêu là 98.5% nghĩa là SLA đã th ực sự bị vi phạm). Hãy
luôn luôn tính đ ến số lượng các sự cố thay vì m ột tỷ lệ phần trăm
trên m ột tập hợp dưới 100, và hãy c ẩn thận khi các đích nh ắm
m ục tiêu được chấp thuận. Đây là đi ều m à các t ổ chức đã phải
học m ột cách khó khăn.
Quy trình SLM thư ờng t ạo ra m ột điểm khởi đầu tốt đẹp cho m ột SIP
- và quá trình đánh giá d ịch vụ có thể thúc đẩy điều này, nhưng m ọi
quy trình và m ọi lĩnh vực của tổ chức cung cấp dịch vụ nên tham gia
vào SIP.
Khi m ột khó khăn ti ềm ẩn đã được xác định có ảnh hưởng m ột cách

bất lợi đến chất lượng dịch vụ, SLM phải cùng với Quản lý V ấn đề
và Quản lý Tính s ẵn sàng thúc đ ẩy SIP xác định và triển khai bất kỳ
hành động nào c ần thiết để khắc phục khó khăn và khôi ph ục lại
chất lượng dịch vụ. Các sáng ki ến SIP cũng có th ể tập trung vào các
vấn đề chẳng hạn như đào t ạo người sử dụng, kiểm tra dịch vụ và
hệ thống và tài li ệu hóa. Trong những trường hợp này, những người
có liên quan c ần phải tham gia và đưa ra ph ản hồi đầy đủ để tiến
hành việc cải thiện cho tương lai. T ại bất kỳ thời điểm nào, m ột số
sáng kiến riêng bi ệt tạo thành m ột phần của SIP đều có thể hoạt
động song song đ ể giải quyết các khó khăn với m ột số dịch vụ.
Một vài t ổ chức đã ph ải thiết lập m ột ngân sách d ự chi hằng năm do
SLM nắm giữ để từ đó các sáng ki ến SIP có thể được tài trợ vốn.
Điều này có nghĩa r ằng hoạt động có thể được thực hiện m ột cách
nhanh chóng và SLM là có hiệu quả m ột cách rõ rệt. Thực tễ này
nên được khuyến khích và m ở rộng để cho phép SLM ngày càng tr ở
nên chủ động và mang tính dự báo. SIP cần được sở hữu và quản
lý, với m ọi hoạt động cải tiến được đánh giá về rủi ro và tác đ ộng
lên các dịch vụ, khách hà ng và doanh nghiệp, và sau đó được thiết
lập độ ưu tiên, lên l ịch trình và tri ển khai.
Nếu m ột tổ chức đang thuê ngoài vi ệc Cung cấp Dịch vụ của m ình
cho m ột bên thứ ba, vần đề về cải thiện dịch vụ nên được thảo luận
ngay từ ban đầu và bao gồm (và được lập ngân sách cho) trong h ợp
đồng, nếu không thì sẽ không có b ất kỳ khuyên khích nào trong su ốt
thời gian hợp đồng cho các nhà cung c ấp để cải thiện các đích nh ắm
m ục tiêu của dịch vụ nếu chúng đã đáp ứng các nghĩa vụ hợp đồng
và cần thêm chi tiêu bổ sung để tiến hành các cải thiện.

128
4.2.7.1 Các KPI
Quản lý chất lượng tổng thể của dịch vụ CNTT là c ần thiết, cả về s ố
lượng lẫn m ức dịch vụ đã được cung c ấp và quản lý:
 Tỷ lệ phần trăm của việc giảm các đích nh ẳm m ục tiêu SLA b ị

bỏ lỡ.
 Tỷ lệ phần trăm của việc giảm các đích nhẵm m ục tiêu SLA b ị
đe dọa.
 Tỷ lệ phần trăm của việc gia tăng nh ận thức và m ức độ hài
lòng của khách hàng v ề những thành t ựu của SLA, thông qua
đánh giá d ịch vụ và phản hồi về Khảo sát Độ hài lòng của
Khách hàng.
 Tỷ lệ phần trăm của việc giảm các vi ph ạm SLA do các hợp
đồng hỗ trợ của bên thứ ba (hợp đồng cơ sở).
 Tỷ lệ phần trăm của việc giảm các vi ph ạm SLA do các Thỏa
thuận Mức Vận hành nội bộ (OLAs).
Cung cấp dịch vụ như đã thỏa thuận trước đó với chi phí hợp lý:
 Tổng số và t ỷ lệ phần trăm tăng trong các SLA được ghi chép
đầy đủ có sẵn.
 Tỷ lệ phần trăm SLA tăng theo th ỏa thuận đối với các dịch vụ
hoạt động đang được vận hành.
 Tỷ lệ phần trăm của việc giảm chi phí liên quan đ ến việc cung
cấp dịch vụ
 Tỷ lệ phần trăm của việc giảm chi phí giám sát và báo cáo
SLA.
 Tỷ lệ phần trăm tăng về tốc độ và phát triển và thỏa thuận các
SLA thích hợp.
 Tần suất của các cuộc họp đánh giá dịch vụ.
Quản lý giao di ện kinh doanh:
 Tỷ lệ phần trăm của việc tăng dịch vụ được bao phủ bởi SLA.
 Có các quy trình và th ủ tục SLM đư ợc lập thành văn b ản và
được thỏa thuận.
 Giảm thời gian c ần thiết để ứng phó với, và triển khai các yêu
cầu SLA.
 Tăng t ỷ lệ phần trăm về đánh giá SLA đư ợc hoàn thành đúng
hạn.
 Giảm tỷ lệ về các SLA t ồn đọng để thương lượng lại hàng
năm .
 Giảm tỷ lệ về các SLA đòi hỏi những thay đổi khắc phục (ví
dụ: không thể đạt được các đích nh ắm m ục tiêu; thay đ ổi m ức
sử dụng). Cần phải thận trọng khi sử dụng KPI này.
 Tỷ lệ phần trăm về việc gia tăng trong ph ạm vi bao ph ủ của
các OLA và các h ợp đồng của bên thứ ba được áp dụng, trong
khi có thể giảm được số lượng các th ỏa thuận thực tế (sự hợp
nhất và tập trung)
 Bằng chứng tài liệu cho thấy các vấn đề đã phát sinh trong
đánh giá dịch vụ và SLA đang được theo dõi và giải quyết.

129
 Giảm số lượng và m ức độ nghiêm trọng của các vi phạm SLA.
 Xem xét và theo dõi hi ệu quả m ọi SLA, OLA và các vi ph ạm
hợp đồng cơ sở.

SLM cung cấp thông tin ch ủ yếu về mọi dịch vụ vận hành, các đích
nhắm m ục tiêu được kỳ vọng của chúng và các thành t ựu cũng như
các vi phạm dịch vụ đối với tất cả các dịch vụ vận hành. Nó h ỗ trợ
Quản lý Mục lục Dịch vụ với việc quản lý Mục lục Dịch vụ và cũng
cung cấp thông tin và xu hư ớng về sự hài lòng c ủa khách hàng, bao
gồm cả những lời phàn nàn và khen ng ợi.
SLM rất quan tr ọng trong vi ệc cung cấp thông tin về chất lượng của
dịch vụ CNTT được cung c ấp cho khách hàng và nh ững thông tin về
kỳ vọng và nhận thức của khách hàng về chất lượng dịch vụ đó.
Thông tin này nên đư ợc phổ biến rộng rãi cho t ất cả các lĩnh vự c
của tổ chức cung c ấp dịch vụ.
rủi ro
Một thách thức m à SLM ph ải đối m ặt là việc xác định các đại diện
khách hàng phù h ợp để thương lượng. Ai là người ‘sở hữu’ dịch vụ?
Trong m ột số trường hợp, việc này có thể rõ ràng và m ột nhà quản
lý của khách hàng s ẵn sàng đóng vai trò là ngư ời ký kết thỏa thuận.
Trong các trường hợp khác, có thể m ất khá nhi ều thời gian thương
lượng hoặc chần chừ để tìm m ột 'tình nguyện viên' đại diện (hãy lưu
ý rằng các tình nguy ện viên thường m uốn bày tỏ quan điểm cá nhân
của họ hơn là đại diện cho sự đồng thuận chung), ho ặc có thể cần
phải có được tất cả khách hàng để ký kết.
Nếu đại diện khách hàng t ồn tại, những người có thể thực sự đại
diện cho quan đi ểm của cộng đồng của khách hàng, vì h ọ gặp gỡ với
nhiều lựa chọn của khách hàng m ột cách thư ờng xuyên thì đi ều này
là lý tưởng. Thật không m ay, t ất cả các đại diện thường xuyên ở tại
trụ sở văn phòng chính và hi ếm khi tiếp xúc với khách hàng d ịch vụ
chính hãng. Trong trư ờng hợp xấu nhất, SLM có thể phải thực hiện
chương trình thảo luận và hội họp của riêng m ình v ới khách hàng để
đảm bảo các yêu c ầu thực sự được xác định.

130
Trong quá trình thương th ảo về giờ hiện tại và giờ hỗ trợ cho
m ột dịch vụ lớn, một tổ chức nhận thấy m ột sự thiếu nhất quán
trong thời gian s ử dụng giữa Trụ sở Chính và văn phòng chi
nhánh c ủa khách hàng. Tr ụ sở Chính (với m ột cộng đồng ngư ời
sử dụng giới hạn) muốn giờ dịch vụ vào khoảng 8 giờ đến 18 giờ,
trong khi văn phòng chi nhánh (v ới ít nhất cộng đồng người sử
dụng gấp 20 lần) tuyên b ố rằng bắt đầu (giờ dịch vụ) sớm hơn 1
giờ sẽ tốt hơn – nhưng m ọi văn phò ng đều đóng c ửa với công
chúng chậm nhất là lúc 16 giờ, và do đó, sẽ không đòi hỏi dịch vụ
nhiều hơn m ức này. Trụ sở Chính đã th ắng trong cuộc tranh lu ận
‘chính tr ị’, và do đó khoảng thời gian t ừ 8 đến 18 giờ được thiết
lập. Khi dịch vụ được đưa vào sử dụng (và do đó, đư ợc giám
sát), người ta đã nh ận ra rằng các ph ần m ở rộng dịch vụ đã
thường được yêu c ầu bởi văn phòng chi nhánh đ ể sử dụng thêm
giờ vào buổi sáng, và các s ố liệu sử dụng thực tế đã cho th ấ y
rằng dịch vụ đã không được truy c ập sau 17 giờ, ngoại trừ những
dịp rất hiếm hoi. Nhà Quản lý Mức Dịch vụ đã bị đổ lỗi bởi nhân
viên CNTT vì ph ải làm ca m uộn, và bởi đại diện khách hàng vì
tính phí cho m ột dịch vụ đã không được sử dụng (nghĩa là chi phí
cho nhân viên và cho vận hành).
Cần thận trọng khi m ở các cuộc thảo luận về các m ức dịch vụ
cho lần đầu tiên, vì có kh ả năng là 'các vấn đề hiện tại' (lỗi đã
xảy ra ngày hôm qua) ho ặc các khiếu nại lâu dài (m áy in cũ m à
chúng tôi đã cố gắng thay thế trong nhi ều năm ) có kh ả năng
được bộc lộ ngay t ừ đầu. Mặc dù có thể quan trọng nhưng chúng
không được phép c ản trở việc thiết lập các yêu c ầu dài hạn. Tuy
nhiên, hãy lưu ý r ằng có thể cần phải giải quyết bất kỳ vấn đề
nào đã phát sinh ngay t ừ đầu trước khi đạt được bât k ỳ sự tín
nhiệm nào để tiến bộ hơn nữa
Nếu chưa hề có kinh nghi ệm về SLM trước đây, thì l ời khuyên là b ạn

nên bắt đầu với dự thảo SLA. Một quyết định nên đưọc đưa ra v ề
dịch vụ hoặc khách hàng nào s ẽ được sử dụng cho dự thảo. Sẽ rất
hữu ích nếu khách hàng được lựa chọn m ong m uốn và nhi ệt tình
tham gia - có lẽ vì họ lo lắng khi thấy sự cải thiện trong chất lượng
dịch vụ. Kết quả của cuộc khảo sát về cảm nhận ban đầu của khác h
hàng có thể cung c ấp cho bạn m ột SLA dự thảo ban đầu phù hợp.
Đừng chọn m ột khu vực nơi có nhi ều vấn đề tồn tại làm SLA đầu
tiên. Hãy c ố gắng chọn m ột khu vực có khả năng cho th ấy m ột số
lợi ích nhanh chóng và hãy phát tri ển quy trình SLM. Không có gì
khuyến khích vi ệc chấp thuận m ột ý tưởng m ới nhanh hơn s ự
thành công.
Một khó khăn đôi khi g ặp phải là nhân viên ở các cấp khác nhau
trong cộng đồng khách hàng có th ể có những m ục tiêu và nh ận thức
khác nhau. Ví d ụ: m ột quản lý cấp cao có thể hiếm khi s ử dụng m ột
dịch vụ và có thể quan tâm hơn đến các vấn đề như giá trị đồng tiền
và đầu ra, trong khi m ột nhân viên cấp dưới có thể sử dụng dịch vụ

131
suốt cả ngày và có thể quan tâm hơn đ ến các vấn đề như khả năng
đáp ứng, khả năng khả dụng và độ tin cậy. Điều quan trọng là tất cả
các yêu c ầu thích h ợp và có liên quan c ủa khách hàng, ở tất cả các
cấp, phải được xác định và kết hợp trong các SLA.
Một số tổ chức đã thành l ập các nhóm tập trung từ các cấp khác
nhau từ trong cộng đồng khách hàng để giúp đảm bảo rằng tất c ả
các vấn đề đã được giải quyết m ột cách chính xác. Đi ều này làm t ốn
thêm tài nguyên bổ sung, nhưng có thể rất xứng đáng với nỗ lực.
Một nhóm người khác ph ải được tham vấn trong toàn b ộ quá trình
này là các đại diện thích hợp từ bên trong nhà cung c ấp CNTT (cho
dù nội bộ hay từ nhà cung cấp hoặc đối tác bên ngoài). H ọ cần thỏa
thuận rằng các m ục tiêu là thực tế, có thể đạt được và giá c ả phải
chăng. Nếu không, cần có các cu ộc đàm phán b ổ sung cho đ ến khi
m ột thỏa hiệp có thể chấp nhận được đối với tất cả các bên đư ợc
thỏa thuận. Quan đi ểm của các nhà cung c ấp cũng nên được tìm
kiếm , và bất kỳ hàm ý hợp đồng nào cũng nên đư ợc xem xét trong
giai đoạn đàm phán.
Trong trường hợp không có s ẵn dữ liệu được giám sát trong quá
khứ, lời khuyên là nên đ ể thỏa thuận ở dạng dự thảo trong thời gian
ban đầu, cho đến khi vi ệc giám sát có th ể xác nhận rằng các đích
nhắm m ục tiêu ban đầu là có th ể đạt được. Các đích nh ắm mục tiêu
có thể phải được thương lượng lại trong m ột vài trường hợp. Nhiều
tổ chức thương lượng m ột khung thời gian đã thỏa thuận để CNTT
đàm phán và t ạo ra m ột đường cơ s ở cho việc thiết lập các đích
nhắm m ục tiêu dịch vụ thực tế. Khi các đích nh ắm m ục tiêu và khung
thời gian đã được xác nh ận, SLA phải được ký.
Một khi SLA ban đ ầu đã được hoàn thành và m ọi khó khăn ban đ ầu
đã đưuọc vượt qua, hãy ti ếp tục và dần dần giới thiệu các SLA cho
các dịch vụ/khách hàng khác. N ếu ngay t ừ đầu đã quyết định áp
dụng cơ cấu nhiều cấp thì có khả năng các vấn đề cấp-công ty phải
được đề cập cho m ọi khách hàng t ại thời điểm của SLA ban đầu. Nó
cũng đáng để thử nghiệm các vấn đề của công ty trong giai đo ạn
đầu tiên này.
Đừng thiết lập các đích nhắm m ục tiêu dễ dàng ở m ức-công ty.
Chúng có thể dễ dàng đạt được nhưng không có giá tr ị gì trong
việc cải thiện chất lượng dịch vụ hoặc m ức độ tín nhiệm . Tương
tự, nếu các đích nh ắm m ục tiêu được thiết lập ở m ột m ức đủ cao,
SLA công ty có thể được sử dụng như là m ột tiêu chuẩn m à các
dịch vụ m ới nên đạt được.
Một điểm cần đảm bảo là tại thời điểm kết thúc quá trình so ạn thảo
và đàm phán, SLA th ực sự được ký k ết vào thỏa thuận bởi các nhà
quản lý thích hợp ở cả phía khách hàng l ẫn nhà cung cấp dịch vụ
CNTT. Điều này đưa ra cam k ết chắc chắn của cả hai bên rằng m ọi
nỗ lực sẽ được thực hiện để đáp ứng thỏa thuận. Nói chung, các
bên ký kết càng cao c ấp trong các t ổ chức tương ứng của họ thì

132
thông điệp cam kết càng m ạnh m ẽ. Một khi SLA được thỏa thuận,
cần phải sử dụng công khai rộng rãi để đảm bảo rằng khách hàng,
người sử dụng và nhân viên CNTT đ ều nhận thức giống nhau về sự
tồn tại của SLA và các đích nh ắm m ục tiêu chủ yếu.
Các bước phải được thực hiện để quảng bá sự tồn tại của các SLA
và OLA m ới giữa Bộ phận Hỗ trợ Dịch vụ và các nhóm hỗ trợ khác,
kèm theo chi ti ết về thời điểm chúng vận hành. Có thể hữu ích khi
trích xuất các đích nh ắm m ục tiêu chính yếu từ các thỏa thuận này
thành các b ảng có thể được hiển thị trong các khu vực hỗ trợ, để
nhân viên luôn nhận thức được về các đích nh ắm m ục tiêu m à h ọ
đang làm vi ệc. Nếu các công cụ hỗ trợ cho phép, các đích nh ắm m ục
tiêu này phải được ghi nhận lại trong các công c ụ, chẳng hạn như
trong Mục lục Dịch vụ hoặc CMS, để nội dung của chúng có th ể
được cung c ấp rộng rãi cho m ọi nhân viên. Chúng cũng nên đư ợc
đưa vào dưới dạng ngưỡng và cảnh báo m ột cách t ự động khi m ục
tiêu bị đe dọa hoặc thực sự bị xâm phạm. Các SLA, OLA và các đích
nhắm m ục tiêu m à chúng ch ứa đựng cũng phải được công khai trong
cộng đồng người sử dụng, để người sử dụng nhận thức được những
gì họ có thể m ong đợi từ các dịch vụ m à họ sử dụng và bi ết thời
điểm để bắt đầu bày t ỏ sự không hài lòng.
Điều quan tr ọng là nhân viên c ủa Bộ phận Hỗ trợ Dịch vụ cam kết
đối với quy trình SLM, và tr ở thành đại sứ chủ động cho các SLA, đi
theo văn hóa dịch vụ cần thiết, khi họ là điểm liên hệ đầu tiên cho
các sự cố, khiếu nại và thắc m ắc từ khách hàng. Nếu nhân viên c ủa
Bộ phận Hỗ trợ Dịch vụ không nhận thức đầy đủ về các SLA đang
có, và không tham gia vào n ội dung c ủa chúng, khách hàng s ẽ m ất
niềm tin vào SLA m ột cách nhanh chóng.
4.2.9.1 Các Yếu tố Thành công Quan trọng

Các Yếu tố Thành công Quan tr ọng chủ yếu đối với quy trình Quản
lý Mức Dịch vụ là:
 Quản lý chất lượng tổng thể của các dịch vụ CNTT được yêu
cầu.
 Cung cấp dịch vụ như đã được thỏa thuận trước đây với chi
phí hợp lý.
 Quản lý giao di ện với doanh nghi ệp và người sử dụng.
Rủi ro tương ứng có liên quan đến việc cung c ấp m ột Mục lục Dịch
vụ chính xác là:
 Thiếu đầu vào chính xác, s ự cam kết và tham gia c ủa doanh
 Các công c ụ và nguồn lực cần thiết để thỏa thuận, ghi nhận,
giám sát, báo cáo và xem xét các th ỏa thuận và các m ức dịch
vụ.
 Quy trình trở thành quy trình qu ản lý hành chính quan liêu
thay vì m ột quy trình ho ạt động chủ động cung cấp những lợi
ích có thể đo lường được đối với doanh nghi ệp.

133
 Tiếp cận đến và hỗ trợ của CMS và SKMS c ập nhật.
 Bỏ qua việc sử dụng các quy trình SLM.
 Các thước đo c ủa doanh nghiệp và khách hàng quá khó đ ể đo
lường và cải thiện, do đó không đư ợc ghi nhận lại.
 Các đầu m ối liên hệ và các m ối quan hệ với doanh nghi ệp và
khách hàng không thích h ợp được phát triển.
 Kỳ vọng cao và nh ận thức kém của khách hàng.
 Truyền thông kém và không thích h ợp được thực hiện với
doanh nghiệp và khách hàng.
4.3 Quản lý Công suất

Quản lý Công suất là m ột quá trình kéo dài trong su ốt Vòng đời Dịch
vụ. Một yếu tố thành công quan tr ọng trong việc quản lý công su ất là
đảm bảo nó được xem xét trong giai đo ạn thiết kế. Chính vì lý do
này m à quy trình Quản lý Công su ất được đưa vào ấn phẩm này.
Quản lý Công suất được hỗ trợ ban đầu trong Chi ến lược Dịch vụ,
nơi m à các quyết định và phân tích về yêu cầu kinh doanh và k ết
quả của khách hàng ảnh hưởng đến sự phát triển của các hình m ẫu
hoạt động kinh doa nh (PBA), m ức dịch vụ (LOS) và gói m ức dịch vụ
(SLP). Điều này cung c ấp các chỉ số năng lực dự đoán và liên t ục
cần có để điều chỉnh năng lực theo nhu cầu.

‘Mục đích của qu y trình Qu ản lý Công su ất là đ ể đảm bảo rằng
công su ất IT với chi phí hợp lý trong mọi lĩnh vực CNTT luôn tồn
tại và kh ớp với các nhu cầu kinh doanh hi ện tại và trong tương
lại, một cách kịp thời’.
Mục đích c ủa Quản lý Công su ất là cung c ấp m ột điểm tập trung và

quản lý cho m ọi công suất – và các vấn đề liên quan đến-hiệu suất,
liên quan tới cả dịch vụ và tài nguyên.
Những m ục tiêu c ủa Quản lý Công suất là để:
 Đưa ra và duy trì m ột Kế hoạch Công suất thích hợp và c ập

nhật, phản ảnh những nhu cầu kinh doanh hi ện tại và trong
tương lai.
 Cung cấp lời khuyên và hướng dẫn cho m ọi lĩnh vực khác của
doanh nghi ệp và CNTT về m ọi vấn đề công suất và liên quan
tới-hiệu suất.
 Đảm bảo rằng những thành tựu đạt được của hiệu suất dịch vụ
đáp ứng hoặc vượt quá t ất cả đích nhắm m ục tiêu về hiệu suất
đã thỏa thuận bằng cách quản lý hiệu suất và công su ất.
 Hỗ trợ chẩn đoán và gi ải quyết các sự cố và vấn đề liên quan
đến hiệu suất và công su ất.
 Đánh giá tác đ ộng của m ọi thay đổi đối với Kế hoạch Công
suất, và hiệu suất và năng lực của m ọi dịch vụ và tài nguyên.
 Đảm bảo rằng các biện pháp đo lường chủ động để cải thiện
hiệu suất của dịch vụ được triển khai ở bất cứ nơi nào có th ể
thực hiện được với chi phí hợp lý

134
4.3.2 Phạm vi
Quá trình Qu ản lý Năng l ực nên là tiêu đi ểm cho m ọi vấn đề về công
suất và hiệu suất CNTT. Các chức năng qu ản lý công nghệ như Hỗ
trợ Mạng, Hỗ trợ Máy chủ hoặc Quản lý Vận hành có th ể thực hiện
phần lớn các nhi ệm vụ vận hành hàng ngày, nhưng s ẽ cung c ấp
thông tin về hiệu suất cho quy trình Quản lý Công su ất. Quy trình
này nên bao g ồm tất cả các lĩnh vực công ngh ệ, cả phần cứng và
phần m ềm , cho m ọi thành phần và môi trường công nghệ CNTT.
Quản lý Công su ất cũng nên xem xét vi ệc hoạch định không gian và
công suất của hệ thống m ôi trường cũng như các khía c ạnh nhất
định của nguồn nhân lực, nhưng chỉ khi việc thiếu nguồn nhân lực
có thể dẫn đến vi phạm các m ục tiêu SLA hoặc OLA, chậm trễ trong
hiệu suất đầu cuối hoặc thời gian đáp ứng dịch vụ, hoặc không có
khả năng đáp ứng các cam kết và kế hoạch trong tương lai (ví d ụ
như sao lưu dữ liệu qua đêm đã không đư ợc hoàn thành k ịp thời vì
không có nhân viên v ận hành nào có m ặt để tải băng).
Nói chung, qu ản lý ngu ồn nhân lực là m ột trách nhi ệm quản lý theo

dây chuyền, m ặc dù vi ệc bố trí nhân viên của Bộ phận Hỗ trợ Dịch
vụ nên sử dụng các kỹ thuật Quản lý Công su ất giống hệt nhau. Do
đó, việc lập lịch trình cho ngu ồn nhân lực, cấp độ nhân viên, c ấp độ
kỹ năng và cấp độ năng lực nên được bao gồm phạm vi của Quản lý
Công suất. Động lực cho Quản lý Công suất nên là các yêu c ầu kinh
doanh của tổ chức và lập kế hoạch các ngu ồn lực cần thiết để cung
cấp các m ức dịch vụ phù hợp với các SLA và OLA. Qu ản lý Công
suất cần hiểu về tổng thể m ôi trường CNTT và kinh doanh, bao g ồm :
 Hoạt động kinh doanh hi ện tại và các yêu c ầu của nó, thông
qua các hình m ẫu về hoạt động kinh doanh.
 Các kế hoạch và yêu cầu trong tương lai thông qua Danh m ục
Dịch vụ.
 Những đích nh ắm m ục tiêu của dịch vụ và Vận hành Dịch vụ
CNTT thông qua các SLA và các Th ủ tục Vận hành Tiêu
chuẩn.
 Mọi lĩnh vực về công nghệ CNTT và công suất và hiệu suất
của nó, bao gồm cơ sở hạ tầng, dữ liệu, m ôi trường và ứng
dụng.
Việc hiểu được t ất cả những điều này s ẽ cho phép Quản lý Công
suất đảm bảo rằng m ọi khía cạnh công suất và hiệu suất hiện tại và
tương lai của các d ịch vụ được cung c ấp m ột cách hiệu quả về m ặt
chi phí.
Quản lý Công su ất cũng là về việc hiểu tiềm năng cung c ấp các dịch
vụ m ới. Công ngh ệ m ới cần được hiểu và, nếu thích hợp, được sử
dụng để đổi m ới và cung c ấp các dịch vụ được yêu cầu bởi khách
hàng. Quản lý Công suất cần nhận thức rằng t ốc độ thay đổi công
nghệ hầu như chắc chắn sẽ tăng lên và r ằng công ngh ệ m ới nên
được khai thác đ ể đảm bảo rằng các dịch vụ CNTT tiếp tục thỏa m ãn
những kỳ vọng kinh doanh đang thay đ ổi. Một liên k ết trực tiếp đến
Chiến lược Dịch vụ và Danh m ục Dịch vụ là cần thiết để đảm bảo

135
rằng các công ng hệ m ới nổi được xem xét trong vi ệc hoạch định
dịch vụ trong tương lai.
Quy trình Quản lý Công suất nên bao g ồm :
 Giám sát các hình m ẫu hoạt động kinh doanh và các k ế hoạch
m ức dịch vụ thông qua hi ệu suất, m ức độ sử dụng và thông
lượng của các dịch vụ CNTT và cơ sở hạ tầng hỗ trợ, các
thành phần m ôi trư ờng, dữ liệu và ứng dụng cũng như s ản
xuất các báo cáo thư ờng xuyên và đ ột xuất về công suất và
hiệu suất của dịch vụ và thành ph ần.
 Thực hiện các ho ạt động điều chỉnh để sử dụng hiệu quả nhất
các tài nguyên CN TT hiện có.
 Hiểu được nhu c ầu hiện tại và tương lai đã đư ợc thỏa thuậ n
của khách hàng v ề tài nguyên CNTT và đưa ra d ự báo cho các
yêu cầu trong tương lai.
 Ảnh hưởng đến Quản lý Nhu c ầu, có thể kết hợp với Quản lý
Tài chính.
 Xây dựng m ột Kế hoạch Công su ất cho phép nhà cung c ấp
dịch vụ tiếp tục cung c ấp các dịch vụ có chất lượng đã được
xác định trong SLA và bao g ồm m ột khung thời gian ho ạch
định đủ để đáp ứng các m ức dịch vụ trong tương lai đư ợc yêu
cầu như đã được xác định trong Danh m ục Dịch vụ và các
SLR.
 Hỗ trợ việc xác định và giải quyết bất kỳ sự cố và vấn đề nào
liên quan đến hiệu suất dịch vụ hoặc hiệu suất thành ph ần.
 Chủ động cải tiến hiệu suất của dịch vụ hoặc hiệu suất thành
phần ở bất kỳ nơi nào có th ể có chi phí h ợp lý và đáp ứng
được các nhu cầu của doanh nghi ệp.
Quản lý Công su ất của các cơ sở hạ tầng CNTT có độ phân tán cao

là m ột nhiệm vụ phức tạp và đòi hỏi khắt khe, đặc biệt là khi năng
lực CNTT và đầu tư tài chính ngày càng tăng. Do đó, vi ệc lập kế
hoạch tăng trưởng thậm chí ngày càng có ý nghĩa hơn. Khi chi phí
nâng cấp cho m ột thành phần riêng l ẻ trong m ôi trường phân tán
thường ít hơn chi phí nâng c ấp lên m ột thành phần trong m ôi trường
m áy tính lớn, thường có nhiều thành ph ần hơn trong môi trư ờng
phân tán cần phải được nâng c ấp. Ngoài ra, hiện nay có thể có tính
kinh t ế theo quy m ô, bởi vì chi phí cho m ỗi thành phần riêng l ẻ có
thể được giảm bớt khi nhiều thành ph ần cần được m ua s ắm thêm .
Quản lý Công suất nên có đầu vào cho Danh m ục dịch vụ và quy
trình m ua sắm để đảm bảo rằng các thỏa thuận tốt nhất với nhà
cung cấp được thương lượng.
Quản lý Công su ất cung cấp thông tin cần thiết về việc sử dụng tài
nguyên hiện tại và đã được hoạch định của các thành ph ần riêng l ẻ
để cho phép các t ổ chức tự tin quyết định:
 Những thành ph ần nào c ần được nâng cấp (nghĩa là nhi ều bộ

nhớ hơn, thiết bị lưu trữ nhanh hơn, b ộ xử lý nhanh hơn, băng
thông lớn hơn).

136
 Thời điểm nâng cấp - lý tưởng là không nên quá s ớm , dẫn đến
tình trạng thừa-công suất tốn kém , cũng không quá mu ộn,
không tận dụng được những tiến bộ của công nghệ m ới, dẫ n
đến tình trạng thắt cổ chai, hiệu suất không nhất quán và, cu ối
cùng, khách hàng không hài lòng và m ất đi cơ hội kinh doanh.
 Chi phí nâng cấp là bao nhiêu – việc dự báo và ho ạch định
các yếu tổ của Quản lý Công su ất được đưa vào vòng đời
ngân sách, đảm bảo đầu tư được hoạch định.
Rất nhiều quy trình khác kém hi ệu quả hơn nếu không có đ ầu vào t ừ
quy trình Quản lý Công suất. Ví dụ:
 Quy trình Qu ản lý Công suất có thể đánh giá m ột cách đúng

đắn về hiệu ứng của bất kỳ thay đổi nào của công suất sẵn có
không?
 Khi m ột dịch vụ m ới được triển khai, quy trình SLM có th ể đảm
bảo rằng các SLR của dịch vụ m ới là có th ể đạt được không,
và rằng các SLA c ủa các dịch vụ hiện hữu sẽ không bị ảnh
hưởng?
 Quy trình Qu ản lý Vấn đề có thể chẩn đoán nguyên nhân cơ
bản của sự cố gây ra bởi hiệu suất kém không?
 Quy trình Liên t ục Dịch vụ CNTT có thể xác định m ột cách
chính xác các yêu c ầu công suất của các quy trình nghi ệp vụ
chính yếu không?
Quản lý Công suất là m ột trong những quy trình hướng tới tương lai,
khi được thực hiện m ột cách đúng đắn sẽ thường có thể dự báo các
sự kiện và tác đ ộng kinh doanh trước khi chúng xảy ra. Quản lý
Công suất tốt đảm bảo rằng không có b ất ngờ nào liên quan đến
thiết kế và hiệu suất của dịch vụ và thành phần.
Quản lý Công suất có m ối quan hệ hai chiều, chặt chẽ với Chiế n
lược Dịch vụ và các quy trình ho ạch định trong t ổ chức. Một các h
thường xuyên, chi ến lược dài hạn của m ột tổ chức được đóng gói
trong m ột bản cập nhật của các k ế hoạch kinh doanh. Chi ến lược
Dịch vụ sẽ phản ánh các kế hoạch và chiến lược kinh doanh, được
phát triển từ sự hiểu biết của tổ chức về các yếu tố bên ngoài như
thị trường cạnh tranh, tri ển vọng kinh tế và luật pháp, và năng l ực
nội bộ về m ặt nguồn nhân lực, năng lực cung cấp, v.v... Thường thì
m ột kế hoạch chiến thuật ngắn hạn hơn hoặc m ột kế hoạch thay đổi
kinh doanh đư ợc phát tri ển để triển khai nh ững thay đổi cần thiết
trong thời gian ng ắn đến trung hạn để tiến triển kế hoạch kinh doanh
và Chiến lược dịch vụ tổng thể. Quản lý Công su ất cần hiểu về các
kế hoạch ngắn, trung và dài h ạn của doanh nghi ệp đồng thời cung
cấp thông tin về các ý tưởng, xu hướng và công ngh ệ m ới nhất đang
được phát triển bởi các nhà cung c ấp phần cứng và phần m ềm m áy
tính.
Các kế hoạch kinh doanh c ủa tổ chức định hướng cho Chi ến lược
Dịch vụ CNTT cụ thể, các nội dung m à Quản lý Công suất cần phải
làm quen và Qu ản lý Công su ất cần có đầu vào liên tục và đáng kể.

137
Mức công suất phù hợp vào đúng thời điểm là rất quan trọng. Các
kế hoạch Chiến lược Dịch vụ sẽ hữu ích cho việc hoạch định công
suất bằng cách xác đ ịnh thời gian để tiếp nhận và triển khai các
công nghệ, phần cứng và phần m ềm mới.

Quản lý Công su ất chịu trách nhiệm cho việc đảm bảo rằng các tài
nguyên CNTT được hoạch định và lập lịch trình để cung cấp m ột
m ức dịch vụ nhất quán đáp ứng được các nhu cầu của doanh nghiệ p
hiện tại và trong tương lai, như đư ợc thỏa thuận và ghi nhận lại
trong các SLA và OLA. K ết hợp với doanh nghi ệp và các kế hoạch
của họ, Quản lý Công suất cung cấp một Kế hoạch Công suất trong
đó phác thảo các tài nguyên CNTT và ngu ồn vốn cần thiết để hỗ trợ
kế hoạch kinh doanh, cùng với m ột bản xác m inh chi phí c ủa khoản
chi tiêu đó.
4.3.4 Các chính sách/nguyên t ắc/ý tư ởng cơ bản

Quản lý Công suất đảm bảo rằng công suất và hiệu suất của các
dịch vụ và hệ thống CNTT đáp ứng được các nhu c ầu của doanh
nghiệp đã được thỏa thuận và đang phát tri ểntheo cách hi ệu quả
nhất về thời gian và chi phí. Qu ản lý Công suất về cơ bản là m ột
hành động cân bằng:
 Cân bằng chi phí so với tài nguyên cần thi ết: nhu cầu đảm
bảo rằng công suất xử lý đã được m ua là hợp lý về chi phí
theo nhu c ầu của doanh nghiệp, và nhu c ầu sử dụng hiệu quả
nhất những tài nguyên đó.
 Cân b ằng cung và cầu: nhu cầu đảm bảo rằng nguồn cung
sẵn có của năng l ực xử lý CNTT đáp ứng được nhu cầu được
đưa ra bởi doanh nghiệp, kể cả bây giờ lẫn trong tương lai.
Cũng có th ể cần phải quản lý hoặc gây ảnh hưởng đến nhu
cầu đối với m ột tài nguyên cụ thể.
Các quy trình và h ọach định Quản lý Công su ất phải tham gia vào
tất cả các giai đo ạn của Vòng đời Dịch vụ từ Chiến lược và Thi ết kế,
thông qua Chuyển tiếp và Vận hành đến Cải tiến. Từ quan điểm
chiến lược, Danh m ục Dịch vụ chứa các tài nguyên và năng l ực
CNTT. Sự ra đời của Kiến trúc Định hướng Dịch vụ, sự ảo hóa và sử
dụng m ạng lưới giá trị trong cung cấp dịch vụ CNTT là nh ững yếu tố
quan trọng trong vi ệc việc quản lý công su ất. Công suất và hi ệu suất
thích hợp nên được thiết kế thành các d ịch vụ và các thành ph ần
ngay từ giai đoạn thiết kế ban đầu. Điều này sẽ đảm bảo rằng không
chỉ hiệu suất của bất kỳ dịch vụ m ới hoặc đã được thay đổi nào đều
đạt được các đích nhắm m ục tiêu được kỳ vọng m à còn là t ất cả các
dịch vụ hiện có vẫn tiếp tục đáp ứng t ất cả các đích nh ắm mục tiêu
của chúng. Đây là cơ s ở cho việc cung cấp dịch vụ ổn định.
Quy trình Quản lý Công su ất tổng thể liên t ục cố gắng hiệu quả về
m ặt chi phí để phù hợp với các nguồn lực và công suất CNTT đối với
nhu cầu và yêu c ầu luôn thay đ ổi của doanh nghi ệp. Điều này đòi
hỏi sự điều chỉnh và tối ưu hóa các nguồn lực hiện tại cũng như ước

138
tính và hoạch định hiệu quả cho các ngu ồn lực trong tương lai, như
được m inh họa trong Hình 4.8.
Hình 4.8 – Quy trình Quản lý Công su ất
Quản lý Công su ất là m ột quá trình c ực kỳ kỹ thuật, phức tạp và đòi

hỏi nhiều yêu c ầu, và để đạt được kết quả, cần có ba qu y trình con
hỗ trợ.
Một trong những hoạt động chính c ủa Quản lý Công su ất là đưa ra

m ột kế hoạch ghi nhận lại các m ức độ sử dụng tài nguyên và hi ệu
suất dịch vụ hiện tại và, sau khi xem xét Chi ến lược Dịch vụ và các
kế hoạch, dự báo các yêu cầu trong tương lai đối với các ngu ồn lực
CNTT m ới để hỗ trợ cho các dịch vụ CNTT làm nền tảng cho các
hoạt động kinh doanh. K ế hoạch nên chỉ ra m ột cách rõ ràng m ọi giả
định đã được đưa ra. Nó cũng nên bao g ồm bất kỳ khuyến nghị nào
đã được định lượng về nguồn lực cần thiết, chi phí, lợi ích, tác
động, v.v…
Việc đưa ra và duy trì K ế hoạch Công su ất nên diễn ra theo những
khoảng thời gian đã được xác định trước. Về cơ bản, nó là m ột kế
hoạch đầu tư và do đó nên đư ợc công b ố hàng năm , phù h ợp với
vòng đời kinh doanh hoặc ngân sách, và được hoàn thành trước khi
bắt đầu đàm phán về ngân sách trong tương lai. Có th ể cần phát
hành lại hàng quý m ột kế hoạch đã được cập nhật để tính đến
những thay đổi trong các kế hoạch dịch vụ, để báo cáo về tính chính
xác của các dự báo và để đưa ra hoặc tinh chỉnh các đề xuất. Điều
này cần thêm nỗ lực nhưng nếu được cập nhật thường xuyên, K ế
hoạch Công suất có nhiều khả năng chính xác và ph ản ánh đư ợc
nhu cầu kinh doanh đang thay đ ổi.

139
Nội dung điển hình của m ột Kế hoạch Công su ất được mô tả trong
Phụ lục J.
4.3.4.1 Quản lý Công suất Kinh doanh

Quy trình con này di ễn giải những nhu cầu và k ế hoạch kinh doanh
thành các yếu cầu đối với dịch vụ và cơ sở hạ tầng CNTT, đảm bảo
rằng các yêu cầu kinh doanh trong tương lai đ ối với các dịch vụ
CNTT được định lượng, thiết kế, hoạch định và triển khai m ột cách
kịp thời. Điều này có th ể đạt được bằng cách s ử dụng dữ liệu hiện
có về việc sử dụng tài nguyên hiện hữu bởi các dịch vụ và tài
nguyên khác nhau đ ể hướng về, dự đoán, m ô hình hóa ho ặc dự báo
các yêu c ầu trong tương lai. Nh ững yêu cầu trong tương lai đ ến từ
Chiến lược Dịch vụ và Danh m ục Dịch vụ chi tiết hóa các quy trình
và yêu cầu dịch vụ mới, những thay đổi, cải tiến, và đồng thời là sự
tăng trưởng trong các d ịch vụ hiện hữu.
4.3.4.2 Quản lý Công suất Dịch vụ

Trọng tâm của quy trình con này là qu ản lý, kiểm soát và d ự đoán về
hiệu suất và công su ất đầu cuối của việc sử dụng và khối lượng
công việc của các dịch vụ CNTT đang ho ạt động thực tế. Nó đảm
bảo rằng hiệu suất của m ọi dịch vụ, như đã được nêu chi tiết trong
các đích nhắm mục tiêu dịch vụ trong các SLA và SLR, đư ợc theo
dõi và đo lường, và rằng dữ liệu đã thu th ập được sẽ được ghi nh ận
lại, được phân tích và báo cáo. B ất cứ khi nào c ần thiết, hành động
chủ động và phản ứng lại nên được thúc đẩy, để đảm bảo rằng hiệu
suất của m ọi dịch vụ đáp ứng các đích nh ắm m ục tiêu kinh doanh đã
được thỏa thuận của chúng. Đi ều này được thực hiện bởi các nhân
viên có ki ến thức về tất cả các lĩnh vực công ngh ệ được sử dụng
trong việc cung c ấp dịch vụ từ đầu-đến-cuối và thường bao gồm việc
tìm kiếm lời khuyên từ các chuyên gia liên quan đ ến Quản lý Cống
suất Thành phần. Bất cứ khi nào có thể, các ngưỡng tự động nên
được sử dụng để quản lý m ọi dịch vụ vận hành, để đảm bảo rằng
các tình hu ống khi m à các đích nh ắm m ục tiêu dịch vụ bị vi phạm
hoặc bị đe dọa được xác định m ột cách nhanh chóng và các hành
động hiệu quả về chi phí để giảm hoặc tránh tác đ ộng tiềm tàng của
chúng được triển khai.
4.3.4.3 Quản lý Công suất Thành phần

Trọng tâm trong quy trình con này là vi ệc quản lý, kiểm soát và dự
đoán về hiệu suất, m ức độ sử dụng và công su ất của các thành
phần công nghệ CNTT riêng lẻ. Nó đảm bảo rằng tất cả các thành
phần trong cơ sở hạ tầng CNTT với tài nguyên hữu hạn đều được
giám sát và đo lư ờng, và dữ liệu thu thập được sẽ được ghi nhận
lại, được phân tích và báo cáo. M ột lần nữa, nếu có thể, các ngưỡng
tự động nên được triển khai để quản lý m ọi thành phần, để đảm bảo
rằng trong các tình hu ống m à các đích nh ắm m ục tiêu dịch vụ bị vi
phạm hoặc bị đe dọa bởi việc sử dụng hoặc hiệu suất của thành
phần được xác định m ột cách nhanh chóng, và các hành đ ộng hiệu
quả về chi phí để giảm hoặc tránh tác đ ộng tiềm ẩn của chúng được
triển khai.

140
Có rất nhiều hoạt động tương tự được hoàn thành bởi từng quy trình
con nói trên, tuy nhiên m ỗi quy trình con l ại có trọng tâm khác nhau.
Quản lý Công suất Kinh doanh t ập trung vào nh ững yêu cầu kinh
doanh hiện tại và trong tương lai, trong khi Qu ản lý Công suất Dịch
vụ lại tập trung vào việc cung c ấp các dịch vụ hiện hữu đang hỗ trợ
cho doanh nghi ệp, và Quản lý Công suất Thành phần tập trung vào
cơ sở hạ tầng CNTT làm nền tảng cho vi ệc cung cấp dịch vụ. Vai trò
của m ỗi quy trình con nói trên trong quy trình t ổng thể và việc sử
dụng các công c ụ quản lý được m inh họa trong Hình 4.9.
Hình 4.9 – Các quy trình con Qu ản lý Công suất
Các công cụ được sử dụng bởi Quản lý Công su ất cần phải phù hợp
với kiến trúc quản lý của tổ chức và tích hợp với các công c ụ khác
được sử dụng cho m ục đích quản lý các h ệ thống CNTT và t ự động
hóa các quy trình CNTT. Vi ệc giám sát và ki ểm soát các hoạt động
trong Vận hành D ịch vụ sẽ cung cấp một nền tảng phù hợp cho các
công cụ hỗ trợ và phân tích thông tin cho Qu ản lý Công su ất.

Một số hoạt động trong quy trình Qu ản lý Công suất m ang tính ứng
phó, trong khi những hoạt động khác mang tính ch ủ động. Các ho ạt
động chủ động của Quản lý Công su ất nên bao g ồm :
 Ngăn chặn trước các vấn đề về hiệu suất bằng cách th ực hiệ n
các hành động cần thiết trước khi chúng xảy ra.
 Đưa ra các xu hư ớng về m ức độ sử dụng thành phần hiện tại
và ước tính các yêu c ầu trong tương lai, s ử dụng các xu
hướng và các ngưỡng để lập kế hoạch nâng cấp và cải tiến.

141
 Mô hình hóa và t ạo xu hướng cho những thay đổi đã được dự
đoán trong các d ịch vụ CNTT, và xác đ ịnh những thay đổi cần
phải được thực hiện đối với các dịch vụ và thành ph ần của cơ
sở hạ tầng và ứng dụng CNTT để đảm bảo nguồn lực thích
hợp sẵn sàng.
 Đảm bảo rằng các nâng cấp được lập ngân sách, hoạch định
và triển khai trước khi SLA và các đích nh ắm m ục tiêu d ịch vụ
bị vi phạm hoặc các vấn đề về hiệu suất xảy ra.
 Tích cực tìm cách cải thiện hiệu suất dịch vụ ở bất cứ nơi nào
có thể với chi phí h ợp lý.
 Điều chỉnh và tối ưu hóa hi ệu suất của các dịch vụ và thành
phần.
Các hoạt động ứng phó c ủa Quản lý Công su ất nên bao gồm:
 Giám sát, đo lường, báo cáo và xem xét hi ệu suất hiện tại của
cả dịch vụ lẫn các thành phần.
 Đáp ứng tất cả các sự kiện 'ngưỡng' liên quan đến công su ất
và thúc đẩy hành động khắc phục.
 Phản ứng và hỗ trợ các vấn đề với hiệu suất cụ thể. Ví dụ: Bộ
phận Hỗ trợ Dịch vụ có thể chuyển các sự cố về hiệu suất kém
cho bộ phận Quản lý Công ngh ệ, bộ phận này sẽ sử dụng các
kỹ thuật Quản lý Công su ất để giải quyết chúng.
Các hoạt động chủ động và dự báo trước của Quản lý Công suất
càng thành công thì càng có ít nhu c ầu đối với các hoạt động ứng
phó của Quản lý Công su ất.
4.3.5.1 Quản lý Công suất Kinh doanh

Mục tiêu chính của quy trình con Quản lý Công su ất Kinh doanh là
để đảm bảo rằng các yêu c ầu kinh doanh trong tương lai (các k ết
quả của khách hàng) đ ối với các dịch vụ CNTT được xem xét và tìm
hiểu, và r ằng công su ất dịch vụ CNTT đầy đủ để hỗ trợ cho bất k ỳ
dịch vụ m ới hoặc được thay đổi nào đã được hoạch định và tri ển
khai theo m ột khung thời gian thích h ợp. Hình 4.10 m inh h ọa cho
việc BMC chịu ảnh hưởng bởi các hình m ẫu kinh doanh và cách m à
các dịch vụ được sử dụng như thế nào.

142
Hình 4.10 – Công suất phải hỗ trợ cho các yêu c ầu kinh doanh
Quy trình Quản lý Công suất phải sẵn sàng ứng phó với các yêu cầ u
thay đổi về nhu cầu công suất. Các dịch vụ m ới hoặc các dịch vụ
được thay đổi sẽ được đòi hỏi để củng cố hoạt động kinh doanh
đang thay đổi. Các dịch vụ hiện có sẽ yêu cầu sự điều chỉnh để cung
cấp thêm chức năng bổ sung. Các d ịch vụ cũ sẽ trở nên lỗi thời, giải
phóng công suất dự phòng. K ết quả là, khả năng đáp ứng các SLR
và SLA c ủa khách hàng s ẽ bị ảnh hưởng. Quản lý Công su ất chịu
trách nhiệm dự đoán nhu c ầu về công suất đối với những thay đ ổi đó
và quản lý nhu c ầu.
Những yêu c ầu m ới này có thể thu hút sự chú ý c ủa Quản lý Công

suất từ nhiều nguồn khác nhau và do nhi ều lý do khác nhau, nhưng
các nguồn cung cấp chính phải là Hình m ẫu Hoạt động Kinh doanh
từ Quản lý Nhu c ầu và các Gói Mức Dịch vụ được tạo ra cho Danh
m ục Dịch vụ. Những điều này cho thấy m ột cửa sổ của các yếu t ố
dự báo trong tương lai v ề công suất. Những ví dụ như vậy có thể là
m ột lời khuyến nghị về nâng cấp để tận dụng ưu điểm của công
nghệ m ới, hoặc triển khai m ột hoạt động điều chỉnh để giải quyết
m ột vấn đề về hiệu suất. Hình 4.11 cho thấy chu k ỳ của Quản lý Nhu
cầu.

143
Hình 4.11 – Quản lý Công su ất đặc bi ệt lưu ý t ới hình mẫu nhu
cầu
Quản lý Công su ất nên được bao gồm trong m ọi các hoạt động chiến
lược, hoạch định và thiết kế, được tham gia càng s ớm càng tốt trong
m ỗi quá trình, chẳng hạn như:
 Trợ giúp và h ỗ trợ xây dựng Chiến lược Dịch vụ.

 Tham gia vào vi ệc xem xét và c ải tiến các chiến lược và chính
sách CNTT.
 Tham gia vào việc xem xét và cải tiến các kiến trúc công ngh ệ.
Quản lý Công su ất không nên là m ột "đánh dấu vào hộp" vào phút
cuối ngay trước khi khách hàng ch ấp thuận và chấp thuận vận
hành.
Nếu có thể đạt được sự tham gia sớm từ Quản lý Công su ất trong
các quy trình này thì vi ệc hoạch định và thi ết kế công suất CNTT có
thể được liên kết m ột cách chặt chẽ với các yêu cầu kinh doanh và
có thể đảm bảo rằng các đích nhắm mục tiêu c ủa dịch vụ là có thể
đạt được và duy trì.
Hỗ trợ thỏa thuận các Yêu cầu về Mức độ Dịch vụ
Quản lý Công su ất nên hỗ trợ SLM trong việc tìm hiểu các yêu c ầu
của khách hàng về công suất và hiệu suất, về thời gian đáp ứng
dịch vụ/hệ thống cần thiết, thông lượng được kỳ vọng, hình m ẫu sử
dụng và số lượng người sử dụng. Quản lý Công su ất nên trợ giúp
trong quá trình đàm phán b ằng cách cung c ấp các giải pháp kh ả thi
cho m ột số tình huống. Ví dụ: nếu số lượng người sử dụng là dưới
2.000 thì thời gian ph ản hồi có thể được đảm bảo là dưới hai giây.
Nếu có hơn 2.000 ngư ời sử dụng đồng thời kết nối, thì băng thông
m ạng bổ sung là c ần thiết để đảm bảo thời gian phản hồi cần thiết,
hoặc thời gian ph ản hồi chậm hơn sẽ phải được chấp nhận. Các k ỹ
thuật m ô hình hóa, t ạo xu hướng hoặc định cỡ ứng dụng thường
được sử dụng ở đây để đảm bảo rằng các d ự đoán phản ánh m ột
cách chính xác tình hình th ực tế.
Thiết kế, mua sắm hoặc điều chỉnh cấu hình dịch vụ
Quản lý Công suất nên được tham gia vào vi ệc thiết kế các dịch vụ
mới hoặc thay đổi và đưa ra các khuy ến nghị cho việc m ua sắm
phần cứng và ph ần m ềm , trong đó hi ệu suất và/hoặc công su ất là
các yếu tố. Trong m ột số trường hợp, Quản lý Công su ất thúc đẩ y
việc triển khai yêu cầu m ới thông qua Quản lý Thay đ ổi, khi Quản lý
Thay đổi cũng tham gia v ới tư cách là thành viên của Ban Cố vấn
Thay đổi. Vì lợi ích của việc cân bằng giữa chi phí và công su ất, quy
trình Quản lý Công su ất thu được chi phí của các giải pháp được đề

144
xuất thay thế và đề xuất giải pháp hi ệu quả về chi phí thích hợp
nhất.
Xác minh SLA

SLA nên bao gồm chi tiết về thông lượng dịch vụ và các yêu cầu về
hiệu suất đã được dự kiến. Quản lý Công suất tư vấn cho SLM về
các đích nh ắm m ục tiêu có th ể đạt được m à có thể được giám sát và
Thiết kế dịch vụ đã căn cứ vào. Hãy t ự tin rằng Thiết kế Dịch vụ sẽ
đáp ứng được SLR và cung c ấp khả năng tăng trư ởng trong tương
lai có thể đạt được bằng cách sử dụng các k ỹ thuật m ô hình hóa,
tạo xu hướng hoặc định cỡ (ứng dụng).
Hỗ trợ đàm phán SLA

Kết quả của các k ỹ thuật dự đoán cung c ấp việc xác m inh năng l ực
hiệu suất dịch vụ. SLM có thể cần phải thương lượng lại SLA dựa
trên những phát hi ện này. Quản lý Công suất cung c ấp sự hỗ trợ cho
SLM nếu các cuộc đàm phán l ại là cần thiết, bằng cách đề xuất các
giải pháp tiềm năng và thông tin chi phí tương ứng. Khi đã đ ảm bảo
được rằng các yêu cầu là có thể đạt được, trách nhiệm của SLM là
thỏa thuận về các m ức dịch vụ và ký k ết SLA.
Kiểm soát và tri ển khai

Mọi thay đổi đối với năng lực dịch vụ và tài nguyên ph ải tuân theo
tất cả các quy trình CNTT như Thay đ ổi, Phát hành, (thiết lập) Cấu
hình và Quản lý Dự án để đảm bảo rằng m ức độ kiểm soát và ph ối
hợp phù hợp được áp dụng đối với m ọi thay đổi và rằng bất kỳ thành
phần m ới hoặc thay đổi nào đều được ghi lại và theo dõi trong vòng
đời của chúng.
4.3.5.2 Quản lý Công suất Dịch vụ

Mục tiêu chính của quy trình con Qu ản lý Công su ất Dịch vụ là xác
định và tìm hi ểu các dịch vụ CNTT, việc sử dụng tài nguyên của
chúng, hình m ẫu hoạt động, đỉnh và đáy c ủa chúng, và đảm bảo
rằng các dịch vụ đáp ứng các đích nh ắm m ục tiêu SLA c ủa chúng,
nghĩa là đ ảm bảo rằng các dịch vụ CNTT hoàn thành như đư ợc yêu
cầu. Trong quy trình con này, tr ọng tâm được đặt vào việc quản lý
hiệu suất dịch vụ, như đã được xác định bởi các đích nhắm mục tiêu
được bao gồm trong SLA ho ặc SLR đã thỏa thuận.
Quy trình con Qu ản lý Công suất dịch vụ đảm bảo rằng các d ịch vụ
đáp ứng được các đích nh ắm m ục tiêu về công suất dịch vụ đã được
thỏa thuận. Dịch vụ được giám sát cung c ấp dữ liệu có thể xác định
các xu hướng m à từ đó các m ức dịch vụ bình thường có thể được
thiết lập. Thông qua vi ệc giám sát thư ờng xuyên và so sánh với các
m ức này, các điều kiện ngoại lệ có thể được xác định, nhận diện và
báo cáo. Do đó, Qu ản lý Công su ất thông báo cho SLM về bất kỳ vi
phạm dịch vụ hoặc gần như bỏ sót nào.
Sẽ có những thời điểm , sự cố và vấn đề được chuyển đến Quản lý

Công suất từ các quy trình khác, ho ặc m ột dịch vụ được xác định là
có thể thất bại trong vi ệc đáp ứng các đích nhắm m ục tiêu SLA củ a

145
nó. Trong m ột số trường hợp đó, nguyên nhân c ủa lỗi tiềm ẩn có thể
không được giải quyết bằng Quản lý Công suất Thành phần. Ví dụ,
khi lỗi được phân tích, có th ể thấy rằng không bị thiếu công suất
hoặc không có thành ph ần riêng lẻ nào được sử dụng quá m ức. Tuy
nhiên, nếu việc thiết kế hoặc viết m ã lập trình của m ột ứng dụng
không hiệu quả thì hiệu suất dịch vụ có thể cần phải được quản lý,
cũng như là tài nguyên ph ần cứng hoặc phần m ềm riêng lẻ. Quản lý
Công suất Dịch vụ cũng nên giám sát kh ối lượng công vi ệc và các
giao dịch dịch vụ để đảm bảo rằng chúng vẫn nằm trong các giới
hạn và ngưỡng đã được thỏa thuận.
Chìa khóa đ ể Quản lý Công su ất Dịch vụ thành công là d ự báo các

vấn đề, bất cứ khi nào có thể, bằng cách giám sát nh ững thay đ ổi về
hiệu suất và giám sát tác đ ộng của các thay đổi. Vì vậy, đây là m ột
quy trình con khác ph ải có tính ch ủ động và dự đoán, thậm chí là dự
đoán trước, thay vì ứng phó. Tuy nhiên, có nh ững lúc nó ph ải phản
ứng với các vấn đề hiệu suất cụ thể. Từ kiến thức và hiểu biết về
các yêu c ầu hiệu suất của m ỗi dịch vụ đang được sử dụng, ảnh
hưởng của những thay đ ổi trong việc sử dụng dịch vụ là có thể ướ c
tính được, và các hành đ ộng được thực hiện để đảm bảo rằng hiệu
suất dịch vụ cần thiết có thể đạt được.
4.3.5.3 Quản lý Công suất Thành phần

Mục tiêu chính c ủa Quản lý Công suất Thành ph ần (CCM) là xác
định và tìm hiểu về hiệu suất, công su ất và việc sử dụng của từng
thành phần riêng l ẻ trong công nghệ được sử dụng để hỗ trợ các
dịch vụ CNTT, bao gồm cơ sở hạ tầng, m ôi trường, dữ liệu và các
ứng dụng. Điều này đảm bảo việc sử dụng t ối ưu các tài nguyên
phần cứng và ph ần m ềm hiện có để đạt được và duy trì các m ức
dịch vụ đã được thỏa thuận. Tất cả các thành phần phần cứng và r ất
nhiều thành ph ần phần m ềm trong cơ s ở hạ tầng CNTT đều có công
suất hữu hạn m à khi ti ệm cận hoặc bị vượt quá s ẽ có khả năng gây
ra các vấn đề về hiệu suất.
Quy trình con này liên quan đ ến các thành ph ần như bộ vi xử lý, bộ
nhớ, các đĩa, băng thông m ạng, kết nối m ạng, v.v… Vì vậy, thông tin
về m ức độ sử dụng tài nguyên c ần phải được thu thập liên tục. Giám
sát phải được cài đặt trên các thành ph ần phần cứng và ph ần m ềm
riêng lẻ, sau đó đư ợc thiết lập cấu hình để thu thập dữ liệu cần thiết
sẽ được tích lũy và lưu tr ữ trong m ột khoảng thời gian. Đây là m ột
hoạt động thường được thực hiện thông qua giám sát và ki ểm soát
trong Vận hành Dịch vụ. Một phản hồi trực tiếp cho CCM nên được
áp dụng trong quy trình con này.
Cũng như trong Qu ản lý Công su ất Dịch vụ, chìa khóa đ ể CCM thành
công là dự báo các vấn đề, bất cứ khi nào có thể, và do đó nó cũng
phải chủ động và có tính d ự đoán. Tuy nhiên, có nh ững lúc CCM
phải ứng phó với các vấn đề cụ thể do thiếu công suất hoặc sử dụng
thành phần không hi ệu quả. Từ kiến thức và hiểu biết về việc sử
dụng tài nguyên b ởi m ỗi dịch vụ đang hoạt động, tác động của
những thay đổi trong vi ệc sử dụng dịch vụ có thể ước tính được và

146
việc nâng c ấp phần cứng hoặc phần m ềm có thể được lập ngân sách
và được hoạch định. Ngoài ra, các d ịch vụ có thể được cân đối giữa
các nguồn lực hiện có để sử dụng hiệu quả nhất các nguồn lực hiện
tại.
4.3.5.4 Các hoạt động nền tảng của Quản lý Công suất
Các hoạt động được m ô tả trong phần này là c ần thiết để hỗ trợ các
quy trình con của Quản lý Công suất và các ho ạt động này có th ể
được thực hiện theo cả cách ứng phó hoặc chủ động, hoặc thậm chí
là đón trước.
Sự khác biệt chủ yếu giữa các quy trình con n ằm ở dữ liệu đang
được giám sát và thu thập, và quan điểm m à từ đó nó được phân
tích. Ví dụ: m ức độ sử dụng của các thành ph ần riêng l ẻ trong cơ sở
hạ tầng - chẳng hạn như bộ vi xử lý, đĩa và liên k ết m ạng - được
quan tâm trong Qu ản lý Công su ất Thành ph ần, trong khi t ốc độ
thông lượng giao dịch và thời gian ph ản hồi được quan tâm trong
Quản lý Công su ất Dịch vụ. Đối với Quản lý Công su ất Kinh doanh,
tốc độ thông lượng giao d ịch cho dịch vụ trực tuyến cần phải được
diễn giải thành kh ối lượng kinh doanh - ví dụ: về m ặt hóa đơn bán
hàng hoặc đơn đặt hàng tăng lên. Thách th ức lớn nhất mà Quản lý
Công suất phải đối m ặt là tìm hiểu về m ối quan hệ giữa các nhu c ầu
và yêu cầu của doanh nghi ệp và khối lượng công vi ệc của doanh
nghiệp, đồng thời có khả năng diễn dịch những điều này về m ặt tác
động và ảnh hưởng của những điều này đối với khối lượng công vi ệc
và sử dụng dịch vụ và nguồn lực, để từ đó các ngưỡng thích h ợp có
thể được thiết lập ở m ỗi cấp.
Các hoạt động điều chỉnh và tối ưu hóa

Một số hoạt động cần được thực hiện m ột cách l ặp đi lặp lại và tạo
thành m ột chu trình t ự nhiên, như đư ợc m inh họa trong Hình 4.12.

147
Hình 4.12 – Các ho ạt động lặp đi lặp lại liên tục của Quản lý
Công suất
Các hoạt động này cung cấp thông tin lịch sử cơ bản và các yếu tố
kích hoạt cần thiết cho m ọi hoạt động và quy trình khác trong Qu ả n
lý Công suất. Giám sát ph ải được thiết lập trên m ọi thành ph ần và
cho từng dịch vụ. Dữ liệu nên được phân tích bằng cách sử dụng,
bất cứ khi nào có thể, các hệ thống chuyên gia đ ể so sánh m ức độ
sử dụng với các ngưỡng. Các kết quả phân tích nên được đưa vào
các báo cáo, các khuy ến nghị được đưa ra khi thích h ợp. Một số
hình thức của cơ chế kiểm soát sau đó có th ể được áp dụng để thực
hiện các khuyến nghị. Điều này có thể dưới dạng cân bằng các d ịch
vụ, cân bằng khối lượng công việc, thay đổi m ức đồng thời và thêm
hoặc bớt tài nguyên. M ọi thông tin tích lũy đư ợc trong các hoạt động
này nên được lưu trữ trong Hệ thống Thông tin Qu ản lý Công su ất
(CMIS) và chu trình sau đó b ắt đầu lại, giám sát bất kỳ thay đổi nào
được thực hiện để đảm bảo chúng có tác động có lợi và thu th ập
thêm dữ liệu cho các hành đ ộng trong tương lai.
Giám sát sử dụng

Giám sát nên cụ thể đối với các hệ điều hành, c ấu hình ph ần cứng,
ứng dụng cụ thể, v.v... Điều quan tr ọng là giám sát có th ể thu thập
tất cả dữ liệu được yêu cầu bởi quy trình Quản lý Công su ất, đối với
m ột thành phần hoặc dịch vụ cụ thể. Dữ liệu được giám sát điển
hình bao gồm :
 Mức sử dụng bộ vi xử lý.

 Mức sử dụng bộ nhớ.
 Tỷ lệ bộ vi xử lý cho m ỗi loại giao dịch.

148
 Tỷ lệ Nhập/Xuât (Input/Output) (v ật lý và bộ đệm ) và m ức sử
dụng thiết bị.
 Độ dài của hàng đợi.
 Mức sử dụng đĩa.
 Tỷ lệ giao dịch.
 Thời gian ph ản hồi.
 Thời hạn của tập lệnh theo lô.
 Mức sử dụng cơ sở dữ liệu.
 Mức sử dụng chỉ mục.
 Tỷ lệ đạt được.
 Số lượng người sử dụng đồng thời.
 Tỷ lệ lưu lượng m ạng.
Khi xem xét dữ liệu cần được đưa vào, cần có sự phân biệt giữa dữ
liệu được thu thập để giám sát công suất (ví dụ: thông lư ợng) và d ữ
liệu để theo dõi hi ệu suất (ví dụ: thời gian ph ản hồi). Dữ liệu của cả
hai loại đều được yêu c ầu bởi các quy trình con Quản lý Công su ất
Dịch vụ và Thành phần. Việc giám sát và thu th ập này cần kết hợp
tất cả các thành phần trong dịch vụ, do đó, theo dõi tr ải nghiệm
khách hàng ‘từ đầu-tới-cuối’. Dữ liệu phải được thu thập ở m ức sử
dụng toàn bộ tài nguyên và ở m ột hồ sơ chi tiết hơn cho t ải trọng m à
m ỗi dịch vụ đặt lên từng thành ph ần cụ thể. Điều này c ần được thực
hiện trên toàn bộ công nghệ, host hoặc m áy chủ, m ạng, m áy ch ủ cục
bộ và m áy khách hoặc m áy trạm . Tương tự, dữ liệu cần được thu
thập cho m ỗi dịch vụ.
Một phần của hoạt động giám sát nên là các ngư ỡng và đường cơ
sở hoặc hồ sơ của các m ức vận hành bình thường. Nếu những điều
này bị vượt quá, c ảnh báo và các báo cáo ngo ại lệ nên được đưa ra.
Các ngưỡng và đư ờng cơ sở này nên đư ợc xác định từ việc phân
tích dữ liệu đã được ghi nhận trước đó và có th ể được thiết lập ở cả
m ức độ thành phần và dịch vụ. Mọi ngưỡng nên đư ợc thiết lập ở
dưới m ức m à tại đó, thành phần hoặc dịch vụ được sử dụng quá
m ức hoặc thấp hơn đích nh ắm m ục tiêu trong SLA. Khi đ ạt đế n
ngưỡng hoặc bị đe dọa, vẫn còn có cơ hội để tiến hành hành đ ộng
sửa chữa trước khi SLA b ị vi phạm hoặc tài nguyên đã bị sử dụng
quá m ức và có m ột khoảng thời gian hoạt động kém . Việc giám sát
và quản lý các sự kiện, ngưỡng và cảnh báo này được đề cập chi
tiết trong ấn phẩm Vận hành Dịch vụ.
Thông thường, sẽ khó hơn để lấy dữ liệu về khối lượng kinh doanh
hiện tại theo yêu cầu của quy trình con Qu ản lý Công su ất Kinh
doanh. Các thống kê này có thể cần được khởi nguồn từ dữ liệu có
sẵn cho các quy trình con Qu ản lý Công su ất Dịch vụ và Thành
phần.
Giám sát thời gian phản hồi

Rất nhiều SLA có th ời gian phản hồi cho người sử dụng là m ột trong
những đích nhắm mục tiêu c ần đo lường, nhưng cũng nhi ều t ổ chức
gặp khó khăn lớn trong vi ệc hỗ trợ yêu cầu này. Thời gian ph ản hồi

149
cho người sử dụng đối với các dịch vụ CNTT và m ạng có thể được
theo dõi và đo lường bằng cách sau:
 Kết hợp mã cụ thể trong phần mềm ứng dụng máy khách
và máy chủ. Điều này có thể được sử dụng để cung cấp thời
gian phản hồi của dịch vụ ‘từ đầu-đến-cuối’ hoàn ch ỉnh hoặc
các điểm thời gian trung gian đ ể chia nhỏ phản hồi t ổng thể
thành các thành ph ần cấu thành c ủa nó. Các s ố liệu thu được
từ các công c ụ này cung cấp thời gian phản hồi thực tế theo
nhận thức của người sử dụng dịch vụ.
 Sử dụng 'hệ thống kịch b ản robot' vớ i phần mềm mô phỏng
thiết bị đầu cuối. Các hệ thống này bao gồm các hệ thống
m áy khách với phần m ềm m ô phỏng thiết bị đầu cuối (ví dụ:
trình duyệt hoặc các hệ thống Telnet) và ph ần m ềm tập lệnh
chuyên dụng để tạo ra và đo lư ờng các giao dịch và phản hồi.
Những hệ thống này thường cung c ấp m ẫu thời gian phản hồi
dịch vụ ‘từ đầu-đến-cuối’ và rất hữu ích để cung cấp thời gian
phản hồi đại diện, đặc biệt cho các giao d ịch có nhi ều giai
đoạn hoặc các tương tác ph ức tạp. Những điều này chỉ cung
cấp m ẫu thời gian phản hồi, không ph ải thời gian ph ản hồ i
thực tế như được nhận thức bởi người sử dụng dịch vụ thực
sự.
 Sử dụng phần mềm giám sát với tác nhân được phân tán.
Những thông tin hữu ích về thời gian phản hồi của dịch vụ có
thể được thu thập bằng cách phân t án các tác nhân với phần
m ềm giám sát t ại các điểm khác nhau của m ạng (ví dụ: trong
các quốc gia khác nhau trên internet). Sau đó, các h ệ thống
này có thể được sử dụng để tạo ra các giao dịch từ m ột số địa
điểm và đưa ra nh ững phép đo định kỳ của m ột trang internet
như được nhận thức bởi người sử dụng quốc tế của m ột trang
web internet. Tuy nhiên, m ột lần nữa, thời gian nhận được chỉ
là những dấu hiệu về thời gian ph ản hồi và không ph ải là thời
gian phản hồi thực của người sử dụng.
 Sử dụng các hệ thống giám sát thụ động cụ thể. Theo dõi
m ột m ẫu đại diện về số lượng của hệ thống khách hàng.
Phương pháp này d ựa trên sự kết nối của các hệ thống giám
sát m ạng cụ thể, thường được gọi là ‘trình đánh hơi’ đư ợc
chèn vào các đi ểm thích hợp trong m ạng. Sau đó, chúng c ó
thể giám sát, ghi nh ận lại và định thời gian cho t ất cả lưu
lượng đi qua m ột điểm cụ thể trong m ạng. Khi đã được ghi lại,
lưu lượng này sau đó có th ể được phân tích đ ể đưa ra thông
tin chi tiết về thời gian phản hồi của dịch vụ. Tuy nhiên, m ột
lần nữa, chúng chỉ có thể được sử dụng để đưa ra con s ố gần
đúng với thời gian phản hồi thực tế của người sử dụng, ngay
cả khi chúng thường rất gần với tình huống thực tế, nhưng
điều này phụ thuộc vào vị trí của chính bản thân s ự giám sát
trong cơ sở hạ tầng CNTT.
Trong m ột số trường hợp, sự kết hợp của m ột số hệ thống có th ể

được sử dụng. Việc giám sát thời gian ph ản hồi là m ột quá trình
phức tạp ngay cả khi nó là m ột dịch vụ nội bộ hoạt động trên m ạng

150
riêng. Nếu đây là m ột dịch vụ internet bên ngoài, thì quy trình sẽ còn
phức tạp hơn nhi ều vì có r ất nhiều tổ chức và công ngh ệ khác nhau
tham gia.
Một công ty tư nhân với m ột trang web chính đã tri ển khai m ột

dịch vụ giám sát trang web t ừ m ột nhà cung c ấp bên ngoài m à s ẽ
cung cấp các cảnh báo tự động về m ức độ sẵn sàng và phản ứng
của trang web c ủa họ. Mức độ sẵn sàng và tốc độ của các đi ểm
giám sát đã th ấp hơn những gì m à trang web đư ợc giám sát. Do
đó, các s ố liệu đã được đưa ra bởi dịch vụ chính là m ức độ sẵn
sàng và phản ứng của bản thân dịch vụ thay vì là c ủa trang web
được giám sát.
Khi triển khai các dịch vụ giám sát t ừ bên ngoài, hãy đ ảm bảo
rằng các m ức dịch vụ và các cam kết về hiệu suất của dịch vụ
giám sát vuợt qua những gì m à (các) d ịch vụ đang giám sát.
Phân tích
Dữ liệu được thu thập từ việc giám sát nên được phân tích để xác
định các xu hư ớng m à từ đó việc sử dụng bình thường và các m ức
dịch vụ, hoặc các đường cơ sở, có thể được thiết lập. Bằng cách
thường xuyên giám sát và so sánh v ới đường cơ sở này, các điề u
kiện ngoại lệ trong vi ệc sử dụng các thành ph ần riêng lẻ của dịch vụ
có thể được xác định, và các vi phạm hoặc gần như bỏ lỡ trong các
SLA có thể được báo cáo và hành động. Dữ liệu cũng có thể được
sử dụng để dự báo trước m ức sử dụng tài nguyên trong tương lai,
hoặc để giám sát sự tăng trưởng kinh doanh thực tế so với tăng
trưởng được dự báo.
Phân tích dữ liệu có thể xác định được các vấn đề chẳng hạn như:
 ‘Nghẽn cổ chai’ và ‘các đi ểm nóng’ trong cơ s ở hạ tầng.

 Sự phân phối không thích h ợp khối lượng công vi ệc trên toàn
bộ tài nguyên s ẵn có.
 Đánh chỉ m ục cơ sở dữ liệu không phù hợp.
 Thiết kế ứng dụng không hiệu quả.
 Sự gia tăng bất thường trong kh ối lượng công việc hoặc tỷ lệ
giao dịch.
 Lên lịch trình hoặc sử dụng bộ nhớ không hiệu quả .
Việc sử dụng m ỗi thành phần và dịch vụ cần được xem xét trong
ngắn, trung và dài hạn, và m ức sử dụng tối thiểu, tối đa và trung
bình đối với những khoảng thời gian nói trên đ ã được ghi nh ận lại.
Thông thường, hình m ẫu ngắn hạn bao gồm m ức sử dụng trong
khoảng thời gian 24-giờ, trong khi trung h ạn có thể bao gồm m ột
khoảng thời gian t ừ m ột đến bốn tuần, và dài hạn là kho ảng thời
gian m ột năm . Theo thời gian, xu hư ớng trong vi ệc sử dụng tài
nguyên bởi các dịch vụ CNTT khác nhau s ẽ trở nên rõ ràng. Tính
hữu ích c ủa thông tin này đư ợc tăng cường thêm bởi việc ghi nhận
lại bất kỳ yếu tố đóng góp nào đư ợc quan sát d ẫn đến đỉnh hoặc đáy

151
của m ức độ sử dụng – ví dụ, nếu m ột thay đổi của quy trình nghiệ p
vụ hoặc sắp xếp nhân viên trùng v ới bất kỳ sai lệch nào so với m ức
sử dụng thông thường.
Điều quan tr ọng là hi ểu về m ức độ sử dụng trong m ỗi khoảng thời

gian này, đ ể từ đó những thay đổi trong vi ệc sử dụng bât k ỳ dịch vụ
nào có thể liên quan đến những thay đổi được dự báo trong m ức độ
sử dụng các thành ph ần riêng lẻ. Khả năng xác định các thành ph ần
phần cứng và phần m ềm cụ thể m à một dịch vụ CNTT đặc biệt phụ
thuộc vào được cải thiện đáng k ể bằng m ột CMS chính xác, c ập nhật
và toàn diện.
Khi m ức sử dụng m ột tài nguyên đ ặc biệt được xem xét, điều quan
trọng là hiểu về cả tổng m ức sử dụng lẫn m ức sử dụng bởi các dịch
vụ riêng lẻ của tài nguyên đó.
Nếu m ột bộ vi xử lý phải chịu 75% tải trong giờ cao điểm được sử
dụng bởi hai dịch vụ khác nhau, A và B, đi ều quan tr ọng là bi ết
được là bao nhiêu trong s ố 75% đó được sử dụng bởi mỗi dịch
vụ. Giả định rằng hệ thống chiếm 5% bộ vi xử lý, 70% còn lại có
thể được chia đều cho cả hai dịch vụ. Nếu m ột thay đổi trong
Dịch vụ A hoặc Dịch vụ B được ước lượng là s ẽ tốn gấp đôi tải
trên bộ vi xử lý thì sau đó b ộ vi xử lý sẽ bị quá t ải.
Tuy nhiên, n ếu Dịch vụ A sử dụng 60% và Dịch vụ B sử dụng 10%
của bộ vi xử lý thì sau đó b ộ vi xử lý sẽ bị quá tải nếu Dịch vụ A
tốn gấp đôi t ải trên bộ vi xử lý. Nhưng nếu Dịch vụ B tốn gấp đôi
tải trên bộ vi xử lý thì sau đó b ộ vi xử lý có thể không nhất thiết
bị quá t ải.
Điều chỉnh
Việc phân tích dữ liệu được giám sát có th ể xác định các khu vực
của cấu hình s ẽ có thể được điều chỉnh để sử dụng dịch vụ, hệ
thống và các thành ph ần tài nguyên t ốt hơn hoặc cải thiện hiệu suất
của dịch vụ cụ thể.
Các kỹ thuật điều chính được hỗ trợ bao gồm :
 Cân bằng khối lượng công vi ệc và lưu lượng – các giao dịch
có thể đi đến host hoặc m áy chủ tại m ột cửa ngõ c ụ thể, tùy
thuộc vào nơi m à giao d ịch khởi nguồn; sự cân bằng t ỷ lệ các
điểm khởi đầu đối với cửa ngõ có th ể m ang lại sự điều chỉnh
lợi ích.
 Cân bằng lưu lượng đĩa – việc lưu tr ữ dữ liệu trên đĩa m ột
cách hiệu quả và có chiến lược, ví dụ, việc tách dữ liệu trên
toàn bộ các trục xương sống có thể làm giảm tranh ch ấp dữ
liệu.
 Định nghĩa m ột chiến lược khóa đư ợc chấp nhận chỉ định thời
điểm các khóa là c ần thiết và có m ức độ thích hợp, ví dụ, cơ
sở dữ liệu, trang, t ập tin, hồ sơ và dòng – trì hoãn khóa cho
đến khi m ột cập nhật là cần thiết có thể m ang lại lợi ích.

152
 Sử dụng bộ nhớ hiệu quả - có thể bao gồm tìm cách sử dụng
nhiều hoặc ít bộ nhớ hơn, tùy thuộc tình huống.
Trước khi triển khai b ất kỳ khuyến nghị nào phát sinh từ các k ỹ
thuật điều chỉnh, có thể thích hợp để xem xét ki ểm nghiệm tính hợp
lệ của khuyến nghị. Ví dụ, ‘Quản lý Nhu c ầu có thể được sử dụng để
tránh nhu c ầu tiến hành bất kỳ điều chỉnh nào không?’ hoặc ‘Thay
đổi được đề xuất có thể được m ô hình hóa đ ể cho thấy tính hi ệu quả
của nó trước khi nó được triển khai không?’
Triển khai
Mục tiêu của hoạt động này là đ ể giới thiệu bất kỳ thay đổi nào đã
đưuọc xác định bởi các hoạt động giám sát, phân tích và đi ều chỉnh
cho các dịch vụ vận hành thực tế. Việc triển khai bất kỳ thay đổi nào
phát sinh từ những hoạt động này phải trải qua m ột quy trình Quản
lý Thay đổi chặt chẽ và chính thức. Tác động của những thay đ ổi
điều chỉnh hệ thống có thể có hàm ý quan tr ọng đối với khách hàng
của dịch vụ. Tác động và rủi ro tương ứng với những loại thay đổi
này có khả năng lớn hơn những kiểu thay đổi khác.
Điều quan trọng là ph ải tiếp tục giám sát thêm , để từ đó những ảnh
hưởng của thay đổi có thể được đánh giá. Có th ể cần phải tiếp tục
thay đổi thêm hoặc quay tr ở lại những thay đổi nguyên thủy.
Khai thác công ngh ệ mới

Điều này liên quan đ ến việc hiểu về những kỹ thuật m ới và công
nghệ m ới và cách chúng đư ợc sử dụng như thế nào để hỗ trợ doanh
nghiệp và cải tiến đổi m ới. Có thể thích hợp để giới thiệu công ngh ệ
mới để cải thiện việc cung cấp và hỗ trợ các dịch vụ CNTT m à tổ
chức phụ thuộc vào. Thông tin này có th ể được thu thập bằng cách
nghiên cứu các tài liệu chuyên nghi ệp (các t ạp chí hoặc bài báo) và
bằng cách tham gia:
 Các hội thảo quảng cáo c ủa các nhà cung c ấp phần cứng và
phần m ềm.
 Các cuộc họp nhóm người sử dụng của nhà cung c ấp phầ n
cứng và phần m ềm tiềm năng.
 Các cuộc họp nhóm người sử dụng đối với các chuyên gia
CNTT khác liên quan đ ến Quản lý Công suất.
Mỗi m ột trong s ố này m ang lại các nguồn thông tin liên quan đ ến các
kỹ thuật, công ngh ệ, phần cứng và phần m ềm tiềm năng, có th ể
thuận lợi cho CNTT để triển khai để đạt được những lợi ích kinh
doanh. Tuy nhiên, t ại m ọi thời điểm , Quản lý Công suât nên nh ận
thức rằng việc giới thiệu và sử dụng công ngh ệ m ới này ph ải hợp lý
về chi phí và m ang l ại lợi ích thực sự cho doanh nghi ệp. Không ch ỉ
bản thân công ngh ệ m ới là quan tr ọng m à Quản lý Công su ất cũng
cần lưu ý về những lợi thế có được từ việc sử dụng các công ngh ệ
mới, sử dụng các k ỹ thuật như ‘điện toán lưới’, ‘ảo hóa’ và ‘đi ện
toán theo nhu cầu’.
Thiết kế khả năng phục hồi

153
Quản lý Công su ất hỗ trợ việc xác định và c ải thiện khả năng phục
hồi trong cơ sở hạ tầng CNTT hoặc bất kỳ tập hợp con nào c ủa nó,
bất cứ khi nào có chi phí h ợp lý. Cùng với Quản lý Tính s ẵn sàng,
Quản lý Công su ất nên s ử dụng các k ỹ thuật như Phân tích Tác
động của Thành ph ần Hỏng hóc (Com ponent Failure Im pact Analysis
– CFIA), như được m ô tả trong phần 4.4 về Quản lý Tính s ẵn sàng)
để xác định m ức độ nhạy cảm của cấu hình hiện tại đối với sự cố
hoặc sự quá t ải của các thành ph ần riêng lẻ và đưa ra khuyến ngh ị
về bất kỳ các giải pháp có hi ệu quả về chi phí nào.
Quản lý Công su ất phải có khả năng xác đ ịnh tác động đối với các
nguồn lực sẵn có c ủa các lỗi cụ thể và khả năng vận hành các d ịch
vụ quan tr ọng nhất với các nguồn lực còn lại. Vì vậy, việc cung c ấp
công suất dự phòng có thể đóng vai trò như là kh ả năng phục hồi
hoặc dự phòng trong các tình hu ống hỏng hóc.
Các yêu c ầu đối với khả năng phục hồi trong cơ sở hạ tầng CNTT
phải luôn được xem xét tại thời điểm thiết kế dịch vụ hoặc thiết kế
hệ thống. Tuy nhiên, đ ối với rất nhiều dịch vụ, khả năng phục hồi
của dịch vụ chỉ được xem xét sau khi nó đư ợc đưa vào sử dụng thực
tế. Việc kết hợp khả năng phục hồi vào Thi ết kế Dịch vụ có hiệu quả
và hiệu suất hơn nhiều so với việc cố gắng thêm nó vào sau đó, khi
m ột dịch vụ đã đi vào ho ạt động.
4.3.5.5 Quản lý và kiểm soát ngưỡng

Những giới hạn và ràng bu ộc về kỹ thuật đối với các dịch vụ và
thành phần riêng l ẻ có thể được sử dụng bởi các hoạt động giám sát
để thiết lập các ngưỡng m à tại đó các cảnh báo và báo đ ộng và các
báo cáo ngo ại lệ được đưa ra. Tuy nhiên, c ần phải thận trọng khi
thiết lập các ngưỡng vì rất nhiều ngưỡng phụ thuộc vào công vi ệc
đang được vận hành trên các thành ph ần cụ thể.
Việc quản lý và kiểm soát các ngưỡng của dịch vụ và thành ph ần là

nền tảng để cung c ấp dịch vụ hiệu quả nhằm đáp ứng các m ức dịc h
vụ đã thỏa thuận của chúng. Đi ều này đảm bảo rằng tất cả các
ngưỡng của dịch vụ và thành phần được duy trì ở các m ức thích
hợp và được giám sát m ột cách liên t ục, tự động và các c ảnh báo và
báo động được tạo ra khi vi ph ạm xảy ra. Bất cứ khi nào các
ngưỡng được giám sát b ị vi phạm hoặc bị đe dọa, thì báo động sẽ
được đưa ra và các vi ph ạm , cảnh cáo và báo cáo ngo ại lệ được tạo
ra. Sau đó, việc phân tích tình hình c ần được hoàn thành và th ực
hiện các biện pháp kh ắc phục bất cứ khi nào hợp lý, đảm bảo rằng
tình trạng này s ẽ không tái diễn. Các m ục dữ liệu tương tự có thể
được sử dụng để xác định khi nào SLA bị vi phạm hoặc có khả năng
bị vi phạm hoặc khi hiệu suất thành phần suy giảm hoặc có khả năng
bị suy giảm . Bằng cách thiết lập ngưỡng thấp hơn hoặc cao hơn
đích nhắm m ục tiêu th ực tế, hành động có thể được thực hiện và
tránh được sự vi phạm các đích nh ắm mục tiêu SLA. Giám sát
ngưỡng không ch ỉ nên cảnh báo về việc vượt quá m ột ngưỡng m à
còn phải theo dõi t ốc độ thay đổi và dự đoán khi nào s ẽ đạt đến
ngưỡng. Ví dụ: m ột giám sát dung lư ợng ổ đĩa sẽ theo dõi t ốc độ

154
phát triển và đưa ra m ột báo động khi tốc độ hiện tại sẽ khiến cho
đĩa bị đầy trong N ngày t ới. Nếu m ột đĩa dung lượng 1GB đã đạt đến
90% dung lượng và đang tăng trư ởng ở m ức 100KB m ỗi ngày, thì s ẽ
phải m ất 1.000 ngày trước khi nó (đĩa) đầy. Nếu nó đang tăng ở
m ức 10MB m ỗi ngày, thì sẽ chỉ còn 10 ngày nữa là đầy. Việc giám
sát và quản lý các sự kiện và cảnh báo này đư ợc đề cập chi tiết
trong ấn phẩm Vận hành Dịch vụ.
Có thể có những trường hợp, việc tối ưu hóa các thành ph ần và tài
nguyên cơ sở hạ tầng và tài nguyên là c ần thiết để duy trì hoặc cải
thiện hiệu suất hoặc thông lượng. Điều này thường có thể được
thực hiện thông qua Qu ản lý Khối lượng công việc, là m ột thuật ngữ
chung để chỉ các hành đ ộng như:
 Lập lại lịch trình cho m ột dịch vụ hoặc khối lượng công vi ệc cụ
thể để chạy vào m ột thời điểm khác trong ngày ho ặc ngày
trong tuần, v.v... (thường là cách xa thời gian cao đi ểm đến
cửa sổ thấp điểm ) - điều này thường có nghĩa là ph ải điều
chỉnh phần m ềm lập lịch trình công vi ệc
 Di chuyển m ột dịch vụ hoặc khối lượng công việc từ m ột vị trí
hoặc m ột tập hợp các CI sang m ột vị trí khác - thường để cân
bằng giữa việc sử dụng hoặc lưu lượng
 Kỹ thuật ‘ảo hóa’: việc thiết lập và sử dụng các k ỹ thuật và h ệ
thống ảo hóa để cho phép di chuy ển việc xử lý xoay quanh cơ
sở hạ tầng nhằm mang lại hiệu suất/khả năng phục hồi tốt hơn
theo m ột cách năng động
 Hạn chế hoặc di chuyển nhu cầu đối với các thành ph ần hoặc
tài nguyên thông qua các k ỹ thuật Quản lý Nhu c ầu, kết hợp
với Quản lý Tài chính (xem ph ần 4.3.5.6).
Sẽ chỉ có thể quản lý khối lượng công việc m ột cách hiệu quả nếu
có sự hiểu biết đầy đủ về việc khối lượng công vi ệc nào sẽ chạy vào
thời điểm nào và m ức độ sử dụng tài nguyên c ủa m ỗi khối lượng
công việc trên cơ s ở hạ tầng CNTT. Do đó, c ần giám sát và phân
tích khối lượng công vi ệc cùng với m ột CMIS toàn diện là cần thiết
trên cơ sở hoạt động liên t ục.
4.3.5.6 Quản lý Nhu cầu

Mục tiêu chính của Quản lý Nhu c ầu là ảnh hưởng đến nhu cầu của
người dùng và khách hàng đ ối với các dịch vụ CNTT và qu ản lý các
tác động đến tài nguyên CNTT.
Hoạt động này có thể được tiến hành như m ột yêu c ầu ngắn hạn vì
không có đủ công suất hiện tại để hỗ trợ cho công vi ệc đang đư ợc
vận hành, hoặc theo m ột chính sách có ch ủ ý của quản lý CNTT, đ ể
giới hạn công suất cần thiết trong dài h ạn.
Quản lý Nhu c ầu ngắn hạn có thể xảy ra khi xảy ra sự cố m ột phần

của tài nguyên quan tr ọng trong cơ sở hạ tầng CNTT. Ví dụ, nếu đã
xảy ra lỗi của m ột bộ vi xử lý trong m áy ch ủ có nhiều bộ vi xử lý, thì
có thể không có kh ả năng chạy được đầy đủ các dịch vụ. Tuy nhiên,

155
m ột tập hợp con được giới hạn của các dịch vụ vẫn có thể được
chạy. Quản lý Công suất cần nhận thức được m ức độ ưu tiên kinh
doanh của từng dịch vụ, biết các yêu cầu về tài nguyên của từng
dịch vụ (trong trường hợp này là lượng công suất bộ vi xử lý cần
thiết để chạy dịch vụ) và sau đó có khả năng xác định dịch vụ nào
có thể được chạy khi có m ột lượng bị giới hạn trong năng l ực sẵn có
của bộ vi xử lý.
Quản lý Nhu cầu dài hạn có thể cần thiết khi khó xác m inh chi phí
cho m ột nâng cấp đắt tiền. Ví dụ, rất nhiều bộ xử lý được sử dụng
nhiều chỉ trong vài giờ m ỗi ngày, thư ờng là từ 10.00 – 12.00 và
14.00 –16.00. Trong nh ững khoảng thời gian này, b ộ vi xử lý có thể
bị quá tải chỉ trong m ột hoặc hai giờ. Trong kho ảng thời gian từ
18:00 - 08:00, các bộ vi xử lý này chỉ chịu tải rất nhẹ và các thành
phần đều chưa đư ợc sử dụng hết. Có thể biện m inh cho chi phí
nâng cấp chỉ để cung c ấp thêm dung lượng chỉ vài giờ trong tổng số
24 giờ không? Hoặc liệu có khả năng ảnh hưởng đến nhu cầu và lan
truyền yêu c ầu về tài nguyên trong 24 gi ờ, do đó trì hoãn ho ặc tránh
hoàn toàn nhu c ầu nâng cấp tốn kém ?
Quản lý Nhu cầu cần hiểu về việc dịch vụ nào đang sử dụng tài
nguyên và ở cấp độ nào, và lịch trình khi nào chúng ph ải được chạy.
Sau đó, m ột quyết định có thể được đưa ra về việc liệu có khả năng
ảnh hưởng đến việc sử dụng tài nguyên hay không và n ếu có thì lựa
chọn nào là thích h ợp.
Ảnh hưởng đến các dịch vụ đang chạy có thể được thực hiện bởi:
 Các ràng bu ộc vật lý: ví dụ, có khả năng ngừng cung c ấp m ột

số dịch vụ tại m ột số thời điểm nhất định hoặc giới hạn số
lượng khách hàng có th ể sử dụng m ột dịch vụ cụ thể - ví dụ,
bằng cách gi ới hạn số lượng người sử dụng đồng thời; ràng
buộc có thể được triển khai trên m ột tài nguyên ho ặc thành
phần cụ thể - ví dụ: bằng cách giới hạn số lượng kết nối vật lý
với bộ định tuyến hoặc bộ chuyển m ạch m ạng.
 Các ràng buộc về tài chính: nếu tính phí dịch vụ CNTT được
áp dụng, m ức giá giảm có thể được đưa ra đối với công vi ệc
đang vận hành vào các th ời điểm trong ngày khi nhu c ầu về tài
nguyên hiện tại ít hơn. Đây được gọi là tính phí phân bi ệt.
4.3.5.7 Mô hình hóa và t ạo xu hướng

Mục tiêu chính c ủa Quản lý Công suất là dự đoán hành vi c ủa các
dịch vụ CNTT theo m ột khối lượng và nhi ều loại công việc nhất định.
Mô hình hóa là m ột hoạt động có thể được sử dụng để m ang lại hiệu
quả có lợi trong bất kỳ quy trình con nào c ủa Quản lý Công suất.
Các loại m ô hình hóa khác nhau bao g ồm từ việc tiến hành các ước
tính lượng trên kinh nghiệm và thông tin s ử dụng tài nguyên hi ện tại,
đến các nghiên cứu thử nghiệm , các nguyên m ẫu và các đi ểm chuẩn
so sánh quy m ô đầy đủ. Phương pháp tiếp cận trước là rẻ và hợp lý
cho những quyết định nhỏ hàng ngày, trong khi cách sau là t ốn kém ,

156
nhưng có thể được khuyến khích khi tri ển khai m ột dự án hoặc dịch
vụ lớn m ới. Với t ất cả các kiểu m ô hình hóa, m ức độ chính xác
tương t ự có thể đạt được, nhưng t ất cả đều hoàn toàn ph ụ thuộc
vào kỹ năng của người xây dựng m ô hình và thông tin đư ợc sử dụng
để tạo ra nó.
Tạo đường cơ sở
Giai đoạn đầu tiên trong việc m ô hình hóa là t ạo ra m ột m ô hình
đường cơ sở phản ảnh m ột cách chính xác hi ệu suất đang đạt được.
Khi m ô hình đường cơ sở này đã được tạo ra, việc m ô hình hóa
m ang tính d ự báo có th ể đưuọc hoàn thành, nghĩa là hãy h ỏi rằng
‘Chuyện gì sẽ xảy ra nếu…?’ phản ảnh các l ỗi, những thay đ ổi đã
được hoạch định đối với phần cứng và/hoặc khối lượng/sự đa dạng
của khối lượng công vi ệc. Nếu m ô hình đường cơ sở là chính xác thì
độ chính xác về kết quả của các lỗi và các thay đ ổi tiềm năng là có
thể đáng tin c ậy.
Quản lý Công su ất hiệu quả, cùng với các k ỹ thuật m ô hình hóa, c ho
phép Quản lý Công su ất trả lời cho câu hỏi ‘Chuyện gì sẽ xảy ra nếu
…?’. Chuyện gì s ẽ xảy ra nếu thông lượng của Dịch vụ A gấp đôi?
Chuyện gì sẽ xảy ra nếu Dịch vụ B được chuyển từ m áy chủ hiện tại
sang m áy chủ m ới – tác động tới thời gian ph ản hồi của hai dịch vụ
sẽ là gì?
Phân tích xu hư ớng

Phân tích xu hướng có thể được thực hiện dựa trên thông tin s ử
dụng tài nguyên và hi ệu suất dịch vụ đã được thu thập bởi quy trình
Quản lý Công suất. Dữ liệu có thể được phân tích trong m ột bảng
tính và các phương ti ện dự báo và đồ họa, tạo xu hướng được sử
dụng để hiển thị việc sử dụng m ột tài nguyên c ụ thể trong m ột
khoảng thời gian trước đó và nó được dự kiến sẽ thay đổi như thế
nào trong tương lai.
Thông thư ờng, phân tích xu hư ớng chỉ cung cấp các ước lượng về
thông tin sử dụng tài nguyên trong tương lai. Phân tích xu hư ớng
kém hiệu quả hơn trong việc đưa ra ư ớc tính chính xác v ề thời gian
phản hồi, trong trư ờng hợp đó nên s ử dụng m ô hình hóa phân tích
hoặc m ô phỏng. Phân tích xu hư ớng có hiệu quả nhất khi có m ột m ối
quan hệ tuyến tính giữa m ột số lượng nhỏ các biến và ít hiệu quả
hơn khi có m ối quan h ệ phi tuyến tính gi ữa các biến hoặc khi có
nhiều biến.
Mô hình hóa phân tích

Mô hình hóa phân tích là các trình bày v ề hành vi c ủa hệ thống m áy
tính sử dụng các k ỹ thuật toán học, ví dụ: lý thuyết hàng đợi m ạng
nhiều lớp. Thông thường, m ột m ô hình được xây dựng sử dụng gói
phần m ềm trên m áy tính, b ằng cách ch ỉ định các thành ph ần và cấu
trúc của cấu hình bên trong gói c ần được m ô hình hóa, và vi ệc sử
dụng các thành ph ần, ví dụ: bộ vi xử lý, bộ nhớ và đĩa, bởi khối
lượng công việc hoặc ứng dụng khác nhau. Khi m ô hình đư ợc chạy,
lý thuyết hàng đợi được sử dụng để tính toán thời gian ph ản hồi

157
trong hệ thống m áy tính. N ếu như thời gian ph ản hồi m à mô hình d ự
đoán đủ gần với thời gian phản hồi được ghi nhận lại trong đời thực,
thì m ô hình có t hể được coi là m ột đại diện chính xác c ủa hệ thống
m áy tính.
Kỹ thuật m ô hình hóa phân tích đòi h ỏi ít thời gian và n ỗ lực hơn so
với m ô hình m ô ph ỏng, nhưng thông thư ờng nó cho k ết quả kém
chính xác hơn. Ngoài ra, m ô hình ph ải được cập nhật. Tuy nhiên,
nếu kết quả có độ chính xác trong vòng 5% đ ối với việc sử dụng và
15–20% đối với thời gian phản hồi đăng ký trực tuyến, thì kết quả
thường đạt yêu c ầu.
Mô hình hóa mô ph ỏng

Mô phỏng liên quan đ ến việc m ô hình hóa các s ự kiện rời rạc, ví dụ:
tỷ lệ dẫn đến giao dịch, so với m ột cấu hình phần cứng nhất định.
Kiểu m ô hình hóa này có th ể rất chính xác trong vi ệc định c ỡ các
ứng dụng m ới hoặc dự báo ảnh hưởng của những thay đổi đối với
các ứng dụng hiện có, nhưng cũng có th ể rất tốn thời gian và do đó
sẽ tốn kém .
Khi m ô phỏng t ỷ lệ dẫn đến giao dịch, sẽ có m ột số nhân viên nhậ p

m ột loạt giao dịch từ các tập lệnh đã được chuẩn bị sẵn hoặc sử
dụng phần m ềm để nhập các giao d ịch theo k ịch bản tương tự với tỷ
lệ đến ngẫu nhiên. Một trong hai phương pháp ti ếp cận này đều cần
thời gian và n ỗ lực để chuẩn bị và chạy. Tuy nhiên, nó có th ể hợp lý
về m ặt chi phí đối với các tổ chức có các d ịch vụ và hệ thống rất lớ n
m à chi phí chính và các tác đ ộng đến hiệu suất liên quan có t ầm
quan trọng lớn.
4.3.5.8 Định cỡ ứng dụng

Định cỡ ứng dụng có tuổi thọ hữu hạn. Nó được khởi đầu ở giai
đoạn thiết kế cho m ột dịch vụ m ới hoặc khi có sự thay đổi lớn đối
với m ột dịch vụ hiện hữu và được hoàn thành khi ứng dụng được
chấp nhận vào m ôi trường hoạt động thực tế. Các hoạt động định cỡ
nên bao gồm m ọi lĩnh vực công ngh ệ liên quan đ ến các ứng dụng
chứ không riêng gì các ứng dụng. Điều này nên bao gồm cơ sở h ạ
tầng, m ôi trường và dữ liệu, và thường sẽ sử dụng các k ỹ thuật m ô
hình hóa và tạo xu hướng.
Mục tiêu chính của việc định cỡ ứng dụng là ước tính các yêu c ầu
về tài nguyên đ ể hỗ trợ cho m ột thay đổi được đề xuất đối với dịch
vụ hiện có hoặc việc triển khai dịch vụ mới, để đảm bảo rằng nó đáp
ứng các m ức dịch vụ được yêu c ầu. Để đạt được điều này, định cỡ
ứng dụng phải là m ột phần không thể thiếu của Vòng đời Dịch vụ.
Trong quá trình yêu c ầu và thiết kế ban đầu, các m ức dịch vụ cần
thiết phải được chỉ định trong m ột SLR. Điều này cho phép Thi ết kế
Dịch vụ và phát tri ển sử dụng các công nghệ và sản phẩm thích hợp
để đạt được thiết kế đáp ứng các m ức dịch vụ được m ong m uốn. Sẽ
dễ dàng và ít tốn kém hơn nhi ều để đạt được các m ức dịch vụ cần
thiết nếu Thiết kế Dịch vụ xem xét các m ức dịch vụ được yêu c ầu

158
ngay từ ban đầu của Vòng đời Dịch vụ, thay vì ở m ột số giai đoạn
sau.
Các cân nhắc khác trong việc định cỡ ứng dụng là các khía c ạnh
khả năng phục hồi m à có thể cần thiết để tích hợp vào trong thi ết kế
của các dịch vụ m ới. Quản lý Công su ất có thể cung cấp lời khuyên
và hướng dẫn cho quy trình Qu ản lý Tính s ẵn sàng về các nguồn lực
cần thiết để cung c ấp m ức hiệu suất và khả năng phục hồi được yêu
cầu.
Kích thước của ứng dụng nên đư ợc tinh ch ỉnh khi quá trình thi ết kế
và phát triển tiến triển. Việc sử dụng m ô hình hóa có th ể được sử
dụng trong quá trình đ ịnh cỡ ứng dụng.
Các SLR c ủa những phát triển ứng dụng đã được hoạch định không
nên được xem xét m ột cách độc lập. Các tài nguyên s ẽ được sử
dụng bởi ứng dụng có khả năng sẽ được chia s ẻ với các dịch vụ
khác và các m ối đe dọa tiềm ẩn đối với các đích nh ắm m ục tiêu SLA
hiện tại phải được nhận biết và được quản lý.
Khi m ua gói phần m ềm từ các nhà cung c ấp bên ngoài, đi ều quan

trọng là phải hiểu các yêu c ầu về tài nguyên c ần thiết để hỗ trợ cho
dịch vụ. Thông thư ờng có thể sẽ khó để lấy thông tin này t ừ các nhà
cung cấp và nó có thể khác nhau, tùy thu ộc vào thông lượng. Do đó,
sẽ có lợi khi xác định những khách hàng tương t ự của sản phẩm và
hiểu được ý nghĩa của tài nguyên t ừ họ. Có thể thích hợp để so
sánh điểm chuẩn, đánh giá hoặc dùng thử sản phẩm trước khi m ua
sắm .
Chât lượng phải được tích hợp.
Một số khía cạnh c ủa chất lượng dịch vụ có thể được cải thiện sau
khi triển khai (ví d ụ: phần cứng bổ sung có th ể được thêm vào đ ể
cải thiện hiệu suất). Các khía c ạnh khác - đặc biệt là các khía c ạnh
như độ tin cậy và khả năng có thể bảo trì của phần m ềm ứng dụng -
dựa vào chất lượng được 'tích hợp sẵn', vì sự cố gắng thêm nó vào
giai đoạn sau, trên thực tế, chính là thi ết kế lại và phát triển lại,
thường với chi phí cao hơn nhi ều so với phát triển ban đầu. Ngay cả
trong ví dụ phần cứng được trích dẫn ở trên, việc bổ sung công suất
bổ sung sau khi triển khai dịch vụ có thể sẽ tốn nhiều chi phí hơn là
m ột phần của dự án ban đầu.
Có nhiều yếu tố kích hoạt sẽ khởi đầu các ho ạt động Quản lý Công
suất. Những yếu tố này bao gồm :
 Vi phạm dịch vụ, các sự kiện và cảnh báo về công suất hoặc
hiệu suất, bao gồm cả các sự kiện về ngưỡng.
 Các báo cáo ngoại lệ.

159
 Định kỳ xét duyeejtn lại công suất và hiệu suất hiện tại và xem
xét các dự báo, báo cáo và k ế hoạch.
 Các dịch vụ m ới và thay đổi đòi hỏi thêm công suất.
 Định kỳ tạo xu hướng và m ô hình hóa.
 Xem xét và xét duy ệt lại các kế hoạch và chiến lược kinh
doanh và CNTT.
 Xem xét và xét duy ệt lại các thiết kế và chiến lược.
 Xem xét và xét duy ệt lại các SLA, OLA, hợp đồng hoặc bất kỳ
thỏa thuận nào khác.
Có m ột số nguồn thông tin liên quan đ ến quy trình Qu ản lý Công

suất. Một vài trong số này như sau.
4.3.6.1 Các Đầu vào

 Thông tin kinh doanh : từ chiến lược, kế hoạch kinh doanh và
kế hoạch tài chính c ủa tổ chức, và thông tin v ề các yêu cầu
hiện tại và trong tương lai c ủa họ.
 Thông tin về dịch vụ và CNTT: từ Chiến lược Dịch vụ, chiến
lược và các k ế hoạch CNTT và ngân sách hi ện tại, bao g ồm
m ọi lĩnh vực công nghệ và kế hoạch công ngh ệ, bao gồm cơ
sở hạ tầng, m ôi trường, dữ liệu và ứng dụng cũng như cách
thức m à chúng liên q uan đến chiến lược và các k ế hoạch kinh
doanh .
 Thông tin về hiệu suất và công su ất của thành ph ần: của cả
công nghệ hiện hữu và công ngh ệ m ới, từ các nhà s ản xuất và
nhà cung c ấp.
 Các vấn đề về hiệu suất dịch vụ: các quy trình Quản lý Vấn
đề và Sự cố, với các sự cố và vấn đề liên quan đ ến hiệu suất
kém .
 Thông tin dịch vụ: từ quy trình SLM, với thông tin chi ti ết về
các dịch vụ từ Danh m ục Dịch vụ và Mục lục dịch vụ và các
đích nhắm m ục tiêu về m ức dịch vụ trong các SLA và SLR, và
có thể từ việc giám sát các SLA, đánh giá dịch vụ và vi phạm
SLA.
 Thông tin tài chính : từ Quản lý Tài chính, chi phí cung c ấp
dịch vụ, chi phí cho tài nguyên, các thành ph ần và nâng cấp,
lợi ích kinh doanh đ ạt được và các kế hoạch và ngân sách tài
chính, cùng với các chi phí liên q uan đến lỗi dịch vụ và lỗi
thành phần. Một số chi phí của các thành ph ần và nâng cấp
đối với các thành phần sẽ có được từ m ua sắm , nhà cung cấp
và nhà s ản xuất.
 Thay đổi thông tin: từ quy trình Qu ản lý Thay đổi, với m ột
Lịch trình Thay đ ổi và cần phải đánh giá m ọi thay đổi về tác
động của chúng đ ối với công suất của công nghệ.
 Thông tin về hiệu suất: từ Hệ thống Thông tin Qu ản lý Công
suất (CMIS) về hiệu suất hiện tại của tất cả dịch vụ hiện có và
các thành phần cơ sở hạ tầng CNTT.
 CMS: chứa thông tin về các m ối quan hệ giữa doanh nghi ệp,
các dịch vụ, các dịch vụ hỗ trợ và công ngh ệ.
 Thông tin về khối lượng công việc: từ nhóm Vận hành
CNTT, với các lịch trình c ủa m ọi công vi ệc cần được chạy, và

160
thông tin về sự phụ thuộc giữa các dịch vụ và thông tin khác
nhau, và sự phụ thuộc lẫn nhau trong m ột dịch vụ.
4.3.6.2 Các Đầu ra

Các kết quả đầu ra của Quản lý Công su ất được sử dụng trong t ất
cả các phần khác c ủa quy trình, bởi rất nhiều quy trình khác và các
bộ phận khác của t ổ chức. Thường thì thông tin này đư ợc cung cấp
dưới dạng các báo cáo đi ện tử hoặc được hiển thị trên các khu vực
được chia sẻ hoặc dưới dạng các trang trên các m áy ch ủ m ạng nội
bộ, để đảm bảo thông tin c ập nhật nhất luôn đư ợc sử dụng. Thông
tin được cung c ấp như dưới đây:
 Hệ thống Thông tin Qu ản lý Công suất (CMIS): lưu trữ

những thông tin c ần thiết của m ọi quy trình con của Quản lý
Công suất. Ví dụ: dữ liệu được giám sát và thu th ập như m ột
phần của Quản lý Công suất Thành phần và Dịch vụ được sử
dụng trong Quản lý Công suất Kinh doanh để xác định những
thành phần cơ s ở hạ tầng hoặc nâng cấp nào cho các thành
phần là cần thiết và khi nào.
 Kế hoạch Công suất: được sử dụng cho m ọi lĩnh vực của
doanh nghi ệp và quản lý CNTT, và được thực hiện bởi nhà
cung cấp dịch vụ CNTT và qu ản lý c ấp cao c ủa tổ chức để lê n
kế hoạch công su ất của cơ sở hạ tầng CNTT. Nó cũng cung
cấp đầu vào ho ạch định cho nhiều lĩnh vực CNTT và kinh
doanh khác. Nó ch ứa thông tin về việc sử dụng hiện tại các
dịch vụ và các thành ph ần cũng như các k ế hoạch phát triển
công suất CNTT để đáp ứng nhu cầu tăng trưởng của cả dịch
vụ hiện có và b ất kỳ dịch vụ m ới nào đã được thỏa thuận. Kế
hoạch Công su ất nên được sử dụng m ột các tích cực để làm
cơ sở cho việc ra quyết định. Thường thì các K ế hoạch Công
suất được t ạo ra và không bao gi ờ được tham khảo hoặc sử
dụng.
 Thông tin và báo cáo v ề hiệu su ất dịch vụ: được sử dụng
bởi rất nhiều quy trình khác. Ví d ụ: quy trình Quản lý Công
suất hỗ trợ cho Quản lý Mức Dịch vụ với báo cáo và đánh giá
hiệu suất dịch vụ và phát triển các SLR m ới hoặc thay đổi đối
với các SLA hi ện có. Nó cũng h ỗ trợ quy trình Quản lý Tài
chính bằng cách xác định khi nào thì tiền tệ cần được lậ p
ngân sách cho vi ệc nâng cấp cơ sở hạ tầng CNTT hoặc m ua
sắm các thành ph ần m ới.
 Phân tích và báo cáo kh ối lư ợng công việc: được sử dụng
bởi bộ phận Vận hành CNTT đ ể đánh giá và triển khai các thay
đổi kết hợp với Quản lý Công suất để lập lịch trình ho ặc lập lại
lịch trình khi các dịch vụ hoặc khối lượng công vi ệc được
chạy, nhằm đảm bảo rằng việc sử dụng các ngu ồn lực sẵn có
m ột cách hiệu quả và hiệu suất nhất.
 Báo cáo công su ất và hiệu su ất đột xuất: được sử dụng bởi
tất cả các lĩnh vực Quản lý Công su ất, CNTT và doanh nghi ệp
để phân tích và giải quyết các vấn đề về dịch vụ và hiệu suất.
 Các báo cáo d ự báo và dự đoán: được sử dụng bởi tất cả
các lĩnh vực để phân tích, d ự đoán và dự báo các kịch bả n

161
kinh doanh và k ịch bản CNTT cụ thể và các gi ải pháp tiềm
năng của chúng.
 Các Ngưỡng, cảnh báo và sự kiện.
4.3.7 Các Chỉ số Hiệu su ất Quan trọng (KPI)

Một số KPI và ch ỉ số có thể được sử dụng để đánh giá tính hiệu quả
và hiệu lực của các ho ạt động Quản lý Công su ất nên bao gồm :
 Dự báo kinh doanh chính xác:

o Đưa ra d ự báo khối lượng công việc đúng thời hạn.
o Tỷ lệ phần trăm về độ chính xác c ủa các dự báo về xu
hướng kinh doanh.
o Kết hợp kịp thời các kế hoạch kinh doanh vào Kế hoạch
Công suất.
o Giảm số lượng các bi ến thể so với kế hoạch kinh doanh
và Kế hoạch Công suất.
 Kiến thức về những công ngh ệ hiện tại và tương lai:
o Khả năng được tăng cường để giám sát hi ệu suất và
thông lượng của m ọi dịch vụ và thành phần.
o Biện m inh và tri ển khai kịp thời công nghệ m ới phù hợ p
với các yêu cầu kinh doanh (th ời gian, chi phí và ch ức
năng).
o Giảm thiểu việc sử dụng công nghệ cũ, gây ra các SLA
bị vi phạm do các v ấn đề về hỗ trợ hoặc hiệu suất.
 Khả năng chứng m inh hi ệu quả về chi phí:
o Giảm lượng m ua vào phút cu ối để giải quyết các vấn đề
cấp bách về hiệu suất.
o Giảm công su ất vượt m ức của CNTT.
o Dự báo chính xác v ề chi tiêu đã được hoạch định.
o Giảm thiểu sự gián đoạn kinh doanh do thi ếu năng lực
CNTT đầy đủ.
o Giảm tương đối chi phí sản xuất của Kế hoạch Công
suất.
 Khả năng lập kế hoạch và triển khai công su ất CNTT phù hợp
để đáp ứng các nhu cầu kinh doanh:
o Giảm tỷ lệ phần trăm số sự cố do hiệu suất kém .
o Giảm tỷ lệ phần trăm kinh doanh thua l ỗ do không đ ủ
công suất.
o Mọi dịch vụ m ới được triển khai đều đáp ứng Yêu c ầu
Mức Dịch vụ (SLR).
o Tăng t ỷ lệ phần trăm các khuyến nghị được đưa ra bởi
Quản lý Công su ất được thực hiện theo.
o Giảm thiểu số lần vi phạm SLA do hi ệu suất dịch vụ kém
hoặc hiệu suất thành phần kém .

Mục đích của CMIS là để cung cấp thông tin liên quan đ ến công su ất
và hiệu suất để đưa ra các báo cáo và h ỗ trợ cho quy trình Quản lý
Công suất. Những báo cáo này cung c ấp thông tin có giá tr ị cho rất
nhiều quy trình CNTT và Qu ản lý Dịch vụ. Các báo cáo này nên bao
gồm những loại dưới đây.

162
Các báo cáo dựa trên-thành phần
Đối với m ỗi thành ph ần nên có m ột nhóm nhân viên k ỹ thuật chị u
trách nhiệm kiểm soát và qu ản lý nó. Báo cáo ph ải được tạo ra để
m inh họa về cách các thành ph ần đang ho ạt động và m ức công suất
tối đa của chúng đang đư ợc sử dụng như thế nào.
Các báo cáo dựa trên-dịch vụ

Các báo cáo và thông tin cũng ph ải được đưa ra đ ể m inh họa cho
cách dịch vụ và các thành phần cấu thành c ủa nó đang ho ạt động
như thế nào liên quan t ới các đích nh ắm m ục tiêu dịch vụ và ràng
buộc tổng thể của chúng. Các báo cáo này s ẽ cung cấp cơ sở cho
SLM và các báo cáo d ịch vụ khách hàng.
Các báo cáo ngo ại lệ

Các báo cáo cho c ấp quản lý và nhân viên k ỹ thuật thấy khi công
suất và hiệu suất của m ột thành phần hoặc dịch vụ cụ thể trở nên
không thể chấp nhận được cũng là m ột yêu c ầu từ phân tích d ữ liệ u
công suất. Các ngư ỡng có thể được thiết lập cho bất kỳ thành ph ần,
dịch vụ hoặc thước đo nào trong CMIS. M ột ví dụ về ngưỡng có th ể
là tỷ lệ phần trăm sử dụng bộ vi xử lý cho m ột m áy chủ cụ thể đã vi
phạm 70% trong ba gi ờ liên tục hoặc số lượng người dùng đăng
nhập đồng thời vượt quá giới hạn đã thỏa thuận.
Đặc biệt, các báo cáo ngoại lệ quan tâm đến quy trình SLM trong
việc xác định liệu các đích nh ắm m ục tiêu trong các SLA có b ị vi
phạm hay không. Ngoài ra, các quy trình Qu ản lý Vấn đề và Sự cố
có thể sử dụng các báo cáo ngo ại lệ trong việc giải quyết các sự cố
và vấn đề.
Các báo cáo dự báo và dự đoán

Để đảm bảo nhà cung cấp dịch vụ CNTT vẫn tiếp tục cung c ấp các
m ức dịch vụ được yêu cầu, quy trình Quản lý Công suất phải dự
đoán khối lượng công vi ệc và t ốc độ tăng trưởng trong tương lai. Đ ể
làm được điều này, công su ất và hiệu suất của thành phần và dịc h
vụ trong tương lai ph ải được dự báo. Điều này có thể được thực
hiện theo nhi ều cách khác nhau, tùy thu ộc vào kỹ thuật và công
nghệ được sử dụng. Những thay đổi đối với khối lượng công việc do
sự phát triển và tri ển khai các ch ức năng và d ịch vụ m ới phải được
xem xét cùng với sự tăng trưởng trong chức năng và dịch vụ hiện tại
được thúc đẩy bởi tăng trưởng kinh doanh. M ột ví dụ đơn giản về dự
báo công suất là m ối tương quan gi ữa định hướng kinh doanh và
việc sử dụng thành ph ần, ví dụ: m ức sử dụng bộ vi xử lý so với số
lượng tài khoản khách hàng. D ữ liệu này có thể được tương quan
với nhau để tìm ra ảnh hưởng m à việc tăng số lượng tài kho ản
khách hàng sẽ có đối với việc sử dụng bộ vi xử lý. Nếu các d ự báo
về các yêu cầu công suất trong tương lai xác đ ịnh m ột yêu c ầu về
nguồn lực tăng lên thì yêu c ầu này c ần được đưa vào Kế hoạch
Công suất và được đưa vào chu trình ngân sách CNTT.

163
Thông thường các báo cáo công su ất được tổng hợp lại với nhau và
được lưu tr ữ trên m ột trang m ạng nội bộ để bất kỳ ai cũng có th ể
truy cập và tham khảo chúng.
4.3.8.1 Hệ thống Thông tin Qu ản lý Công su ất

Thông thư ờng, dữ liệu công suất được lưu trữ trong các công c ụ và
cơ sở dữ liệu dành riêng cho công ngh ệ, và giá tr ị đầy đủ của dữ
liệu, thông tin và phân tích c ủa nó không đư ợc thu thập. Giá trị thực
của dữ liệu chỉ có thể có được khi dữ liệu được kết hợp thành m ột
tập hợp các kho thông tin hoặc tập hợp các cơ sở dữ liệu được tích
hợp.
Hệ thống Thông tin Quản lý Công su ất (CMIS) là n ền tảng của m ột

quy trình Quản lý Công suất thành công. Thông tin ch ứa đựng trong
CMIS được lưu trữ và phân tích bởi m ọi quy trình con c ủa Quản lý
Công suất vì nó là m ột kho lưu trữ chứa m ột số loại dữ liệu khác
nhau, bao g ồm dữ liệu kinh doanh, dịch vụ, tài nguyên ho ặc m ức sử
dụng và tài chính, t ừ m ọi lĩnh vực công ngh ệ .
Tuy nhiên, CMIS không có kh ả năng là m ột cơ sở dữ liệu duy nhất

và hầu như chắc chắn tồn tại ở m ột số địa điểm vật lý. Dữ liệu từ
m ọi lĩnh vực công ngh ệ và tất cả các thành ph ần tạo nên dịch vụ
CNTT, sau đó có thể được kết hợp để phân tích và cung c ấp báo
cáo kỹ thuật và báo cáo quản lý. Chỉ khi tất cả thông tin được tích
hợp thì báo cáo dịch vụ ‘từ đầu-đến-cuối’ m ới được tạo ra. Tính
toàn vẹn và chính xác c ủa dữ liệu trong CMIS c ần được quản lý m ột
cách cẩn thận. Nếu CMIS không ph ải là m ột phần của CMS hoặc
SKMS t ổng thể thì các liên k ết giữa các hệ thống này c ần được triển
khai để đảm bảo tính nhất quán và chính xác c ủa thông tin được ghi
lại trong chúng.
Thông tin trong CMIS đư ợc sử dụng để tạo cơ sở cho các báo cáo
và quan điểm về hiệu suất và Quản lý Công su ất sẽ được cung c ấp
cho khách hàng, c ấp quản lý CNTT và nhân viên k ỹ thuật. Ngoài ra,
dữ liệu được sử dụng để tạo ra các d ự báo công suất trong tương
lai và cho phép Qu ản lý Công suất lập kế hoạch cho các yêu c ầu
công suất trong tương lai. Thư ờng thì m ột giao diện web được cung
cấp cho CMIS đ ể cung cấp các quyền truy c ập và chế độ xem khác
nhau được yêu cầu từ bên ngoài của chính quá trình Qu ản lý Công
suất.
Toàn bộ các kiểu dữ liệu được lưu tr ữ trong CMIS như sau.
Dữ liệu kinh doanh

Điều thiết yếu là phải có thông tin chất lượng về những nhu c ầu hiện
tại và tương lai c ủa doanh nghiệp. Các kế hoạch kinh doanh trong
tương lai của tổ chức cần được xem xét và các tác đ ộng đối với các
dịch vụ CNTT được hiểu rõ. Dữ liệu kinh doanh đư ợc sử dụng để dự
báo và xác m inh v ề việc những thay đổi trong các đ ịnh hướng kinh
doanh ảnh hưởng như thế nào đến công suất và hiệu suất của cơ sở
hạ tầng CNTT. Dữ liệu kinh doanh nên bao g ồm các giao dịch kinh

164
doanh hoặc các thước đo chẳng hạn như số lượng tài khoản, s ố
lượng hóa đơn được tạo ra, số lượng dòng s ản phẩm .
Dữ liệu dịch vụ
Để đạt được phương pháp t iếp cận theo định hướng-dịch vụ đối với
Quản lý Công suất, dữ liệu dịch vụ nên được lưu tr ữ trong CMIS. D ữ
liệu dịch vụ điển hình là thời gian phản hồi giao dịch, t ỷ lệ giao dịch,
khối lượng công vi ệc, v.v... Nói chung, các SLA và SLR cung c ấp
các đích nh ắm m ục tiêu dịch vụ m à quy trình Qu ản lý Công suât c ần
ghi nhận lại và giám sát dữ liệu. Để đảm bảo rằng các đích nh ắm
m ục tiêu trong SLA đ ạt được, các ngư ỡng SLM nên đư ợc bao gồm
để từ đó hoạt động giám sát có th ể đo lường dựa trên các ngưỡng
dịch vụ này và đưa ra các c ảnh báo và báo cáo ngo ại lệ trước khi
các đích nhắm m ục tiêu dịch vụ bị vi phạm .
Dữ liệu sử dụng thành phần

CMIS cũng c ần ghi lại dữ liệu về tài nguyên bao gồm thông tin s ử
dụng, ngưỡng và gi ới hạn trên m ọi thành ph ần công ngh ệ hỗ trợ cho
các dịch vụ. Hầu hết các thành ph ần CNTT có nh ững giới hạn về
m ức độ m à chúng nên đư ợc sử dụng. Vượt quá m ức sử dụng này,
tài nguyên s ẽ bị sử dụng quá m ức và hiệu suất của các dịch vụ sử
dụng tài nguyên s ẽ bị suy giảm . Ví dụ: m ức sử dụng khuyến nghị tối
đa trên bộ vi xử lý có thể là 80% ho ặc m ức sử dụng phân đoạn
m ạng LAN Ethernet đư ợc chia s ẻ không nên vượt quá 40%.
Các thành phần cũng có những giới hạn vật lý khác nhau m à kh ả
năng kết nối hoặc sử dụng nhiều hơn là bất khả thi. Ví dụ, số lượng
kết nối tối đa thông qua m ột ứng dụng hoặc m ột cửa ngõ m ạng là
100, hoặc m ột loại đĩa cụ thể có dung lượng vật lý là 15Gb. Do đó,
CMIS nên bao g ồm, đối với m ỗi thành ph ần và hiệu suất tối đa và
các giới hạn công suất, m ức tỷ lệ sử dụng (thành ph ần) hiện tại và
trong quá khứ và các ngưỡng tương ứng với m ỗi thành phần. Theo
thời gian, đi ều này có thể đòi hỏi m ột lượng dữ liệu cực kỳ lớn được
tích lũy, t ừ đó cần phải có những công ngh ệ thích hợp để phân tích,
tổng hợp và lưu tr ữ những dữ liệu này.
Dữ liệu tài chính

Quy trình Quản lý Công su ất đòi hỏi phải có dữ liệu về tài chính. Đ ể
đánh giá các lựa chọn nâng c ấp thay thể, khi đề xuất các kịch bản
khách nhau trong K ế hoạch Công su ất, chi phí tài chính c ủa những
nâng cấp đối với các thành phần của cơ sở hạ tầng CNTT, bên c ạnh
thông tin về ngân sách cho ph ần cứng CNTT hiện tại, phải được biết
đến và bao gồm trong các cân nh ắc. Phần lớn dữ liệu này có th ể có
sẵn từ Quản lý Tài chính đối với quy trình các d ịch vụ CNTT, nhưng
Quản lý Công suât c ần phải xem xét thông tin này khi qu ản lý các
yêu cầu kinh doanh trong tương lai.
4.3.9 Những thách thức, Yếu tố Thành công Quan trọng và rủi ro
Một trong những thách th ức chủ yếu m à Quản lý Công su ất đang
phải đối m ặt là thuy ết phục doanh nghi ệp cung cấp thông tin về các
kế hoạch chiến lược kinh doanh của minh, để cho phép t ổ chức nhà

165
cung cấp dịch vụ CNTT cung cấp Quản lý Liên tục Kinh doanh m ột
cách hiệu quả (BCM). Đi ều này đặc biệt chính xác trong các tình
huống được thuê ngoài khi có nh ững lý do thương m ại hoặc bảo m ật
giải thích cho viesjc t ại sao những dữ liệu này không thể được chia
sẻ. Ngay c ả khi nếu dữ liệu về chiến lược kinh doanh đã s ẵn sàng,
có thể vẫn có vấn đề liên quan đ ến chất lượng hoặc độ chính xác
của dữ liệu chứa đựng trong các k ế hoạch kinh doanh có liên quan
đến BCM.
Một thách thức khác đến từ việc kết hợp m ọi dữ liệu CCM thành m ột
tập hợp thông tin được tích hợp m à có thể được phân tích m ột cách
nhất quán để cung cấp những chi ti ết về việc sử dụng của m ọi thành
phần của các dịch vụ. Điều này đặc biệt thách thức khi thông tin t ừ
những công nghệ khác nhau được cung cấp bởi các công cụ khác
nhau dưới những định dạng khác nhau. Thường thì chât lượng của
thông tin thành ph ần về hiệu suất của công ngh ệ có thể thay đổi cả
về chất lượng lẫn độ chính xác.
Lượng thông tin được sản xuất bởi BCM, và đ ặc biệt là SCM và
CCM, là r ất lớn và vi ệc phân tích những thông tin này là r ất khó để
có thể đạt được. Con người và các quy trình c ần phải tập trung vào
những tài nguyên chính và s ự sử dụng chúng, trong khi đó b ỏ qua
những lĩnh vực khác. Đ ể làm được điều này, các ngưỡng thích h ợp
phải được sử dụng, và sự tín nhiệm được đặt vào các công c ụ và
công nghệ để quản lý công ngh ệ và đưa ra các c ảnh báo và báo
động m ột cách t ự động khi m ột điều gì đó l ệch hướng m ột cách đáng
kể so với ‘bình thường’.
Những Yếu tố Thành công Quan tr ọng chủ yếu đối với quy trình
Quản lý Công su ất là:
 Các dự báo kinh doanh chính xác.

 Kiến thức về những công ngh ệ hiện tại và tương lai.
 Khả năng chứng m inh tính hiệu quả về chi phí.
 Khả năng lập kế hoạch và triển khai công su ất CNTT thích hợp
để đáp ứng nhu c ầu kinh doanh.
Một số rủi ro tương ứng với Quản lý Công su ất bao gồm :
 Thiếu cam kết từ phía doanh nghi ệp đối với quy trình Qu ản lý
Công suất.
 Thiếu thông tin thích h ợp từ phía doanh nghi ệp cho các k ế
hoạch và chi ến lược trong tương lai.
 Thiếu cam kết từ phía quản lý cấp cao hoặc thiếu tài nguyên
và/hoặc ngân sách dành cho quy trình Qu ản lý Công su ất.
 SCM và CCM ti ến hành biệt lập vì BCM quá khó, ho ặc thiếu
thông tin kinh doanh thích h ợp và chính xác.
 Các quy trình tr ở thành quá quan liêu hoặc quá m ức thủ công.
 Các quy trình t ập trung quá nhi ều vào công ngh ệ (CCM) và
không đủ tập trung đối với các dịch vụ (SCM) và việc kinh
doanh (BCM).

166
 Các báo cáo và thông tin đưu ọc cung cấp là quá c ồng kềnh
hoặc quá m ức kỹ thuật và không m ang lại thông tin cần thiết
hoặc thích hợp đối với khách hàng và doanh nghi ệp.
4.4 Quản lý Tính s ẵn sàng

Mục tiêu hướng đến của Quản lý Tính sẵn sàng là để đảm bảo rằng
m ức sẵn sàng c ủa dịch vụ được cung cấp trong m ọi dịch vụ là đáp
ứng được hoặc vượt quá những nhu cầu hiện tại hoặc trong tương
lai của doanh nghi ệp, theo cách hi ệu quả về chi phí.
Mục đích c ủa Quản lý Tính s ẵn sàng là cung c ấp m ột tiêu đi ểm và

quản lý m ọi vẫn đề liên quan đ ến-tính sẵn sàng, liên quan đ ến cả
dịch vụ lẫn tài nguyên, đ ảm bảo rằng các đích nh ắm m ục tiêu về tính
sẵn sàng trong m ọi lĩnh vực được đo lường và đạt được.
Mục tiêu c ủa Quản lý Tính sẵn sàng là để:
 Cung cấp và duy trì m ột Kế hoạch về Tính sẵn sàng thích hợp
và cập nhật và phản ảnh được các nhu c ầu của doanh nghi ệp
trong hiện tại và tương lai.
 Cung cấp khuyến cáo và hư ớng dẫn cho m ọi lĩnh vực củ a
doanh nghi ệp và CNTT về m ọi vấn đề liên quan đến tính sẵn
sàng.
 Đảm bảo rằng những thành t ựu của tính s ẵn sàng của dịch vụ
đáp ứng hoặc vượt quá m ọi đích nhắm m ục tiêu đã đư ợc thỏa
thuận của chúng, bằng cách quản lý hiệu suất về tính sẵn
sàng của các dịch vụ và các tài nguyên có liên quan.
 Hỗ trợ việc chẩn đoán và gi ải quyết các vấn đề và s ự cố liên
quan đến tính sẵn sàng.
 Đánh giá tác động của m ọi thay đổi trong Kế hoạch về Tính
sẵn sàng và hi ệu suất và công suất của m ọi dịch vụ và tài
nguyên.
 Đảm bảo rằng những thước đo chủ động để cải thiện tính sẵn
sàng c ủa các dịch vụ được triển khai ở bất kỳ đâu có chi phí
hợp lý.
Quản lý Tính sẵn sàng nên đ ảm bảo cung c ấp được m ức độ của tính
sẵn sàng đã được thỏa thuận. Đo lường và giám sát tính s ẵn sàng
CNTT là hoạt động chủ chốt để đảm bảo các m ức độ của tính sẵn
sàng được đáp ứng m ột cách nhất quán. Quản lý Tính s ẵn sàng nên
tìm cách tối ưu hóa liên t ục và c ải thiện m ột cách chủ động tính s ẵn
sàng của cơ sở hạ tầng CNTT, các dịch vụ và hỗ trợ tổ chức, nhằm
cung cấp những cải thiện về tính sẵn sàng với chi phí-hiệu quả có
thể m ang lại lợi ích cho doanh nghi ệp và cho khách hàng.
4.4.2 Phạm vi
Phạm vi của quy trình Qu ản lý Tính sẵn sàng bao g ồm thiết kế, triển
khai, đo lường, quản lý và cải thiện tính s ẵn sàng của dịch vụ CNTT
và các thành phần. Quản lý Tính s ẵn sàng c ần phải tìm hiểu các yêu

167
cầu về tính sẵn sàng c ủa dịch vụ và các thành ph ần từ quan điểm
kinh doanh về m ặt:
 Các quy trình nghi ệp vụ hiện tại, sự vận hành và các yêu c ầu
của chúng.
 Các kế hoạch và yêu cầu kinh doanh trong tương lai.
 Các đích nh ắm m ục tiêu dịch vụ và Vận hành Dịch vụ CNTT và
cung cấp.
 Cơ sở hạ tầng CNTT, dữ liệu, các ứng dụng và m ôi trư ờng và
hiệu suất của chúng.
 Những tác động và ưu tiên kinh doanh liên quan đ ể các dịch
vụ và việc sử dụng dịch vụ.
Việc thấu hiêu những điều nói trên s ẽ cho phép Quản lý Tính sẵn
sàng đảm bảo rằng m ọi dịch vụ và thành ph ần được thiết kế và cung
cấp để đáp ứng đích nhắm m ục tiêu c ủa chúng về m ặt các nhu cầu
kinh doanh đã đư ợc thỏa thuận. Quy trình Quản lý Tính s ẵn sàng:
 Nên được áp dụng cho m ọi dịch vụ và công ngh ệ vận hành,

đặc biệt là cho nh ững gì được bao gồm bởi SLA. Nó cũng có
thể được áp dụng cho những dịch vụ CNTT được coi là quan
trọng đối với doanh nghi ệp bất kể SLA chính thức có tồn tại
hay không.
 Nên được áp dụng cho m ọi dịch vụ CNTT m ới và cho m ọi dịch
vụ hiện hữu khi các Yêu cầu Mức Dịch vụ (SLRs) ho ặc các
Thỏa thuận Mức Dịch vụ (SLAs) đư ợc thiết lập.
 Nên được áp dụng đối với m ọi dịch vụ hỗ trợ và các đ ối tác và
các nhà cung c ấp (kể cả nội bộ lẫn bên ngoài) đ ịnh hình nên
tổ chức hỗ trợ CNTT như m ột tiền thân của việc tạo ra các
thỏa thuận chính th ức.
 Xem xét m ọi khía c ạnh của các dịch vụ và thành phần CNTT
và các tổ chức hỗ trợ m à có thể tác động đến tính s ẵn sàng,
bao gồm đào t ạo, các k ỹ năng, tính hi ệu quả của quy trình, thủ
tục và các công c ụ.
Quy trình Quản lý Tính s ẵn sàng không bao g ồm Quản lý Liên t ục

Kinh doanh và sự bắt đầu xử lý kinh doanh l ại sau m ột thảm họa
lớn. Sự hỗ trợ của BCM được bao gồm trong Quản lý Liên tục Dịch
vụ CNTT (ITSCM). Tuy nhiên, Qu ản lý Tính s ẵn sàng không cung
cấp đầu vào chủ yếu cho ITSCM, và hai quy trình ( Quản lý Tính sẵn
sàng và ITSCM – người dịch) có m ối quan hệ chặt chẽ, đặc biệt
trong việc đánh giá và qu ản lý r ủi ro và trong vi ệc triển khai gi ảm
thiểu rủi ro và các biện pháp phục hồi.
Quy trình Quản lý Tính s ẵn sàng nên bao g ồm :
 Việc giám sát m ọi khía cạnh của tính sẵn sàng, độ tin c ậy và
khả năng có th ể bảo trì của các dịch vụ CNTT và các thành
phần hỗ trợ, cùng với các sự kiện tương ứng, các báo động và
sự leo thang, với các kịch bản được tự động hóa cho vi ệc khôi
phục.

168
 Duy trì m ột bộ các phương pháp, k ỹ thuận và tính toán đ ối với
m ọi thước đo, chỉ số và báo cáo về tính sẵn sàng.
 Hỗ trợ các hoạt động đánh giá và qu ản lý rủi ro.
 Thu thập các thước đo, phân tích và đưa ra các báo cáo đ ịnh
kỳ và đột xuất về tính sẵn sàng c ủa dịch vụ và các thành phần.
 Tìm hiểu về các nhu c ầu hiện tại và trong tương lai đã đư ợc
thỏa thuận của doanh nghiệp về các dịch vụ CNTT và tính sẵn
sàng của chúng.
 Sự tác động đến thiết kế các dịch vụ và các thành ph ần để
liên kết với các nhu cầu kinh doanh.
 Xây dựng Kế hoạch về Tính sẵn sàng cho phép nhà cung c ấp
dịch vụ tiếp t ục cung c ấp và cải tiến dịch vụ phù hợp với các
đích nhắm m ục tiêu về tính sẵn sàng đã được xác định trong
Thỏa thuận Mức Dịch vụ (SLA), đồng thời lập kế hoạch và dự
báo m ức độ về tính sẵn sàng trong tương lai đư ợc yêu cầu,
như được định nghĩa trong Yêu c ầu Mức Dịch vụ (SLR).
 Duy trì m ột lịch trình ki ểm tra cho m ọi thành phần và cơ ch ế
có khả năng phục hồi và dự phòng chịu lỗi.
 Hỗ trợ xác định và giải quyết bất kỳ sự cố và vấn đề nào liên
quan đến tính không sẵn sàng c ủa dịch vụ hoặc thành phần.
 Chủ động cải tiến tính s ẵn sàng c ủa dịch vụ hoặc thành phầ n
ở bất kỳ nơi nào có thể có chi phí hợp lý và đáp ứng được nhu

Quy trình Quản lý Tính sẵn sàng đảm bảo rằng tính s ẵn sàng của
các hệ thống và dịch vụ phù hợp với các nhu c ầu đã được thỏa
thuận vẫn đang phát tri ển của doanh nghiệp. Hiện nay, CNTT đang
đóng m ột vai trò then ch ốt trong doanh nghi ệp. Tính s ẵn sàng và đ ộ
tin cậy của các dịch vụ CNTT có thể ảnh hưởng trực tiếp đến sự hài
lòng của khách hàng và danh ti ếng của doanh nghiệp. Đây là lý do
tại sao Quản lý Tính sẵn sang là đi ều thiết yếu trong vi ệc đảm bảo
rằng CNTT cung c ấp đúng m ức độ của tính s ẵn sàng dịch vụ được
yêu cầu bởi doanh nghiệp để đáp ứng các m ục tiêu kinh doanh và
cung cấp chất lượng dịch vụ theo yêu c ầu của khách hàng c ủa mình.
Trong thị trường c ạnh tranh ngày nay, s ự hài lòng c ủa khách hàng
đối với (các) dịch vụ được cung c ấp là điều tối quan tr ọng. Lòng
trung thành c ủa khách hàng không còn đư ợc dựa vào nữa và s ự
không hài lòng v ề tính sẵn sàng và độ tin cậy của dịch vụ CNTT c ó
thể là yếu tố chính khiến khách hàng đưa doanh nghi ệp của họ vào
tay đối thủ cạnh tranh.
Quy trình và ho ạch định Quản lý Tính sẵn sàng, cũng gi ống như
Quản lý Công suất, phải được tham gia vào t ất cả các giai đo ạn của
Vòng đời Dịch vụ, từ Chiến lược và Thiết kế, thông qua Chuy ển tiếp
và Vận hành đến Cải tiến. Tính s ẵn sàng và kh ả năng phục hồi thích
hợp nên được thiết kế thành các d ịch vụ và thành ph ần từ các giai
đoạn thiết kế ban đầu. Điều này sẽ đảm bảo rằng không chỉ rằng
tính sẵn sàng c ủa bất kỳ dịch vụ m ới hoặc đã thay đ ổi nào đều đáp
ứng các m ục tiêu được kỳ vọng m à còn t ất cả các dịch vụ và thành

169
phần hiện có tiếp tục đáp ứng t ất cả các m ục tiêu của chúng. Đây là
cơ sở cho việc cung cấp dịch vụ ổn định.

Quy trình Quản lý Tính s ẵn sàng liên t ục cố gắng để đảm bảo rằng
các dịch vụ vận hành đáp ứng được các đích nhắm mục tiêu đã
được thỏa thuận của chúng về tính s ẵn sàng, và răng các d ịch vụ
mới hoặc được thay đổi được thiết kế m ột cách thích hợp để đáp
ứng các đích nhắm m ục tiêu dự định của chúng m à không có s ự
thỏa hiệp nào về hiệu suất của xác dịch vụ hiện hữu. Để đạt được
điều này, Quản lý Tính s ẵn sàng nên tiến hành các ho ạt động ch ủ
động và ứng phó như được m inh họa trong Hình 4.13.
Hình 4.13 – Quy trình Quản lý Tính sẵn sàng
Các hoạt động ứng phó c ủa Quản lý Tính sẵn sàng bao g ồm giám
sát, đo lường, phân tích, báo cáo và xem xét t ất cả các khía cạnh
của tính sẵn sàng của thành phần và dịch vụ. Điều này nhằm đảm
bảo rằng m ọi đích nhắm m ục tiêu dịch vụ đã thỏa thuận đều được đo
lường và đạt được. Bất cứ khi nào các sai l ệch hoặc vi phạm được
phát hiện, chúng s ẽ được điều tra và các bi ện pháp khắc phục được
tiến hành. Hầu hết các hoạt động này được tiến hành trong giai
đoạn Vận hành c ủa vòng đời và được liên k ết với các hoạt động

170
giám sát và kiểm soát, và với các quy trình Qu ản lý Sự cố và Sự
kiện. (Xem ấn phẩm Vận hành Dịch vụ).
Các hoạt động chủ động bao gồm việc đưa ra các khuy ến cáo, k ế
hoạch và tài li ệu về các hướng dẫn và tiêu chí thi ết kế đối với các
dịch vụ m ới và đã được thay đổi, đồng thời liên tục cải tiến dịch vụ
và giảm thiểu rủi ro trong các d ịch vụ hiện có ở bất kỳ nơi nào c ó
thể hợp lý về chi phí. Đây là nh ững khía cạnh chính cần được xem
xét trong các ho ạt động Thiết kế Dịch vụ.
Một quy trình Quản lý Tính sẵn sàng hi ệu quả, bao gồm cả các hoạt
động chủ động và ứng phó, có th ể 'tạo ra sự khác biệt lớn' và s ẽ
được công nhận như vậy bởi doanh nghi ệp, nếu việc triển khai Quả n
lý Tính s ẵn sàng trong m ột tổ chức CNTT nhấn m ạnh vào nhu c ầu
của doanh nghiệp và khách hàng. Đ ể củng cố sự nhấn m ạnh này, có
m ột số nguyên tắc hướng dẫn sẽ làm nền tảng cho quy trình Qu ản lý
Tính sẵn sàng và tr ọng tâm của nó:
 Tính sẵn sàng c ủa dịch vụ là cốt lõi c ủa sự hài lòng c ủa khách

hàng và sự thành công của doanh nghiệp: trong hầu hết các t ổ
chức, có m ột m ối tương quan tr ực tiếp giữa tính s ẵn sàng của
dịch vụ và sự hài lòng c ủa khách hàng và ngư ời dùng, trong
đó hiệu suất dịch vụ kém được định nghĩa là không kh ả dụng.
 Công nhận rằng khi dịch vụ thất bại, vẫn có thể đạt được sự
hài lòng và công nh ận của doanh nghi ệp, khách hàng và ngư ời
dùng: cách m à m ột nhà cung c ấp dịch vụ phản ứng trong m ột
tình huống thất bại có ảnh hưởng lớn đến nhận thức và kỳ
vọng của khách hàng và ngư ời dùng.
 Cải thiện tính s ẵn sàng chỉ có thể được bắt đầu sau khi hi ểu
về cách thức các dịch vụ CNTT hỗ trợ cho hoạt động của
doanh nghiệp như thế nào.
 Tính sẵn sàng của dịch vụ chỉ tốt như liên kết yếu nhất trong
chuỗi: nó có th ể tăng lên đáng k ể bằng cách loại bỏ các Điểm
Đơn Lỗi (SpoF – Single Point of Failure) ho ặc m ột thành phầ n
không đáng tin c ậy hoặc yếu kém .
 Tính sẵn sàng không ch ỉ là m ột quá trình ph ản ứng. Quy trình
càng chủ động, dịch vụ càng sẵn sàng. Tính s ẵn sàng không
nên hoàn toàn ch ỉ là ứng phó với lỗi của dịch vụ và thành
phần. Càng nhiều sự kiện và sự cố được dự đoán, xử lý trước
và ngăn chặn thì mức độ sẵn sàng của dịch vụ càng cao.
 Thiết kế m ức độ sẵn sàng của dịch vụ vào m ột dịch vụ ngay từ
ban đầu sẽ rẻ hơn là thử và ‘gắn thêm ’ sau đó. Vi ệc thêm kh ả
năng phục hồi vào m ột dịch vụ hoặc thành ph ần luôn đ ắt hơn
so với việc thiết kế nó ngay từ đầu. Ngoài ra, m ột khi m ột dịch
vụ có tiếng xấu vì không đáng tin c ậy thì việc thay đổi hình
ảnh trở nên rất khó khăn. Kh ả năng phục hồi cũng là m ột yếu
tố quan tr ọng của ITSCM, và điều này cũng nên được xem xét
đồng thời.
Phạm vi của Quản lý Tính s ẵn sàng bao g ồm thiết kế, triển khai, đo
lường và quản lý tính s ẵn sàng c ủa cơ sở hạ tầng và dịch vụ CNTT.

171
Điều này được phản ánh trong m ô t ả quy trình được thể hiện trong
Hình 4.13 và được m ô tả trong các đoạn sau.
Quy trình Quản lý Tính s ẵn sàng có hai yếu tố chính:
 Hoạt động ứng phó: khía c ạnh ứng phó c ủa Quản lý Tính sẵn
sàng liên quan đ ến việc giám sát, đo lư ờng, phân tích và qu ản
lý m ọi sự kiện, sự cố và vấn đề liên quan đến tính s ẵn sàng.
Các hoạt động này chủ yếu liên quan đ ến các vai trò vận
hành.
 Hoạt động chủ động: các hoạt động chủ động của Quản lý
Tính sẵn sàng liên quan đ ến việc chủ động lập kế hoạch, thiết
kế và cải thiện tính sẵn sàng. Các ho ạt động này chủ yếu liên
quan đến vai trò thi ết kế và hoạch định.
Quản lý Tính s ẵn sàng được hoàn thành t ại hai m ức kết nối liền
nhau:
 Tính sẵn sàng của dịch vụ: liên quan đến m ọi khía c ạnh của
tính sẵn sàng và không s ẵn sàng c ủa dịch vụ và tác động của
tính sẵn sàng c ủa thành phần, hoặc tác động tiềm năng của
tính không s ẵn sàng c ủa thành ph ần lên tính s ẵn sàng c ủa
dịch vụ.
 Tính sẵn sàng của thành ph ần: liên quan đ ến m ọi khía c ạnh
của tính sẵn sàng và không s ẵn sàng c ủa thành phần.
Quản lý Tính s ẵn sàng dựa trên việc giám sát, đo lư ờng, phân tích
và báo cáo về các khía c ạnh dưới đây:
Tính sẵn sàng: khả năng của m ột dịch vụ, thành phần hoặc CI để
hoàn thành chức năng đã thỏa thuận của nó khi được yêu cầu. Nó
thường được đo lư ờng và báo cáo theo t ỷ lệ phần trăm :
(Thời gian Dịch vụ đã Thỏa thu ận ((AS T – Agreed Service Time)

– thời gian ngừng hoạt động)
Tính sẵn sàng (%) = ………………………………………………….. x

100%
Thời gian Dịch vụ đã Thỏa thuận ( AST)
Lưu ý: Thời gian ng ừng hoạt động chỉ nên đư ợc bao gồm trong công
thức nói trên khi nó x ảy ra trong Th ời gian Dịch vụ đã Thỏa thuận
(AST). Tuy nhiên, t ổng thời gian ngừng hoạt động cũng nên đưu ọc
ghi nhận và báo cáo lại.
Độ tin cậ y: m ột thước đo về thời gian bao lâu m à m ột dịch vụ,

thành phần hoặc CI có th ể hoàn thành chức năng đã th ỏa thuận của
mình m à không bị gián đoạn. Độ tin cậy của dịch vụ có thể được cải
thiện bằng cách gia tăng độ tin cậy của các thành ph ần riêng l ẻ hoặc
bằng cách gia tăng kh ả năng phục hồi của dịch vụ đối với lỗi của
các thành phần riêng lẻ (nghĩa là gia tăng tính d ự phòng của thành

172
phần, ví dụ, bằng cách s ử dụng kỹ thuật cân bằng t ải). Nó (đ ộ tin
cậy) thường được đo lường và báo cáo l ại như là Thời gian Trung
bình Giữa các Sự cố Dịch vụ - Mean Tim e Between Service
Incidents (MTBSI) ho ặc Thời gian Trung bình Gi ữa các Lỗi – Mean
Tim e Between Failures (MTBF):
Thời gian sẵn sàng tính bằng giờ
Độ tin cậ y (MTBSI tính b ằng giờ) = ---------------------------------------

-----
Số lần ngừng
Thời gian sẵn sàng tính b ằng giờ - Tổng thời gian gián đo ạn tính
bằng giờ
Độ tin cậ y (MTBF tính b ằng giờ) = ----------------------------------------

-----
Số lần ngừng
Khả năng duy trì : m ột thước đo về mức độ nhanh chóng và hi ệu

quả của m ột dịch vụ, thành phần hoặc CI có th ể được khôi phục về
hoạt động bình thư ờng sau m ột lỗi. Nó được đo lường và báo cáo
như là Thời gian Hữu ích để Khôi phục Dịch vụ - Mean Tim e to
Restore Service (MTRS) và nên đư ợc tính toán bằng cách sử dụng
công thức sau:
Tổng thời gian gián đo ạn tính bằng giờ
Khả năng duy trì (MTRS tính b ằng giờ) = --------------------------------

----
Số lần ngừng dịch vụ
MTRS nến đưuọc sử dụng để tránh s ự m ơ hồ của m ột thuật ngữ

trong ngành phổ biến hơn là Th ời gian Trung bình Đ ể Sửa chữa –
Mean Tim e To Repair (MTTR), m à trong m ột số định nghĩa ch ỉ bao
gồm thời gian sửa chữa, nhưng trong m ột số định nghĩa khác bao
gồm thời gian khôi ph ục. Thời gian ngừng hoạt động trong MTRS
bao gồm m ọi yếu t ố góp phần làm cho d ịch vụ, thành phần hoặc CI
trở nên không s ẵn sàng:
 Thời gian để ghi nhận lại.

 Thời gian để phản hồi.
 Thời gian để xử lý.
 Thời gian để sửa chữa hoặc thay thế vật lý.
 Thời gian để khôi phục.
Ví dụ: Một tình hu ống m à m ột dịch vụ 24 x 7 đã ho ạt động trong m ột

khoảng thời gian là 5,020 gi ờ chỉ với hai lần ngừng hoạt động, m ột

173
lần trong 6 giờ và lần còn lại trong 14 giờ, sẽ đưa ra các số liệu như
sau:
Tính sẵn sàng = (5,020 – (6 + 14))/5,020 x 100 = 99.60%
Độ tin cậy (MTBSI) = 5,020/2 = 2,510 gi ờ
Độ tin cậy (MTBF) = (5,020 – (6 + 14))/2 = 2,500 gi ờ
Khả năng duy trì (MTRS) = (6 + 14)/2 = 10 gi ờ
Khả năng phục vụ: khả năng của m ột nhà cung cấp bên thứ ba để
đáp ứng về m ặt các điều khoản trong hợp đồng của họ. Thường thì
hợp động này s ẽ bao gồm các m ức đã được thỏa thuận về tính sẵ n
sàng, độ tin cậy và/hoặc khả năng duy trì đối với m ột dịch vụ hoặc
thành phần hỗ trợ.
Những khía cạnh này và các m ối quan hệ giữa chúng được m inh h ọa
trong Hình 4.14.
Hình 4.14 – Các đi ều kho ản và thước đo tính sẵn sàng
Mặc dù đích nhắm m ục tiêu dịch vụ chính trong các SLA cho khách
hàng và doanh nghi ệp là tính s ẵn sàng, như đư ợc m inh họa trong
Hình 4.14, m ột số khách hàng cũng yêu c ầu các m ục tiêu về độ tin
cậy và khả năng duy trì cũng ph ải được bao gồm . Khi đã được bao
gồm , chúng phải liên quan đ ến các đích nhắm m ục tiêu về độ tin cậy
và khả năng duy trì của dịch vụ, trong khi các đích nh ắm mục tiêu về

174
độ tin cậy và khả năng duy trì có trong các OLA v à hợp đồng liên
quan đến các đích nh ắm m ục tiêu c ủa dịch vụ hỗ trợ và thành phần
và thường có thể bao gồm các đích nh ắm m ục tiêu về tính sẵn sàng
liên quan đến các thành phần hoặc dịch vụ hỗ trợ liên quan.
Thuật ngữ Chức năng Nghiệp vụ Quan trọng (VBF – Vital Business
Function) được sử dụng để phản ánh các yếu tố kinh doanh quan
trọng của quy trình nghiệp vụ được hỗ trợ bởi dịch vụ CNTT. Một
dịch vụ CNTT có thể hỗ trợ m ột số chức năng nghiệp vụ ít quan
trọng hơn. Ví dụ, m ột m áy rút tiền tự động (ATM) hoặc dịch vụ rút
tiền VBF s ẽ là nơi phân ph ối tiền m ặt. Tuy nhiên, khả năng lấy được
sao kê t ừ m ột m áy ATM có thể không được coi là quan tr ọng. Sự
khác biệt này là quan tr ọng và nên ảnh hưởng đến thiết kế sẵn có và
các chi phí tương ứng. Nói chung, ch ức năng kinh doanh càng quan
trọng thì m ức độ phục hồi và tính sẵn sàng càng cao c ần phải được
kết hợp vào thiết kế cần thiết trong các dịch vụ CNTT hỗ trợ. Đối với
m ọi dịch vụ, dù có là VBF hay không, các yêu c ầu về tính sẵn sàng
nên được xác định bởi doanh nghi ệp chứ không phải CNTT. Các
đích nhắm m ục tiêu về tính sẵn sàng ban đầu thường được đặt ở
m ức quá cao và đi ều này dẫn đến việc các dịch vụ được định giá
quá cao ho ặc cuộc thảo luận lặp đi lặp lại giữa nhà cung c ấp dịch vụ
và doanh nghi ệp để thỏa thuận về m ột thỏa hiệp thích hợp giữa tính
sẵn sàng c ủa dịch vụ và chi phí c ủa dịch vụ và công ngh ệ hỗ trợ nó.
Một số VBF nhất định có thể cần các thiết kế đặc biệt, hiện đang
được sử dụng như m ột lẽ đương nhiên trong các k ế hoạch Thiết kế
Dịch vụ, bao gồm :
 Tính sẵn sàng cao: m ột đặc trưng của dịch vụ CNTT làm tối
thiểu hóa ho ặc che giấu các tác đ ộng của lỗi của thành phần
CNTT đối với người sử dụng dịch vụ.
 Khả năng chịu lỗi: khả năng của m ột dịch vụ CNTT, thành
phần hoặc CI để tiếp tục vận hành m ột cách đúng đ ắn sau m ột
lỗi của m ột phần của thành phần.
 Tiếp tục vận hành: m ột phương pháp ti ếp cận hoặc thiết kế để
loại trừ thời gian gián đo ạn đã được lên kế hoạch của m ột
dịch vụ CNTT. Hãy lưu ý r ằng các thành ph ần hoặc CI riêng l ẻ
có thể bị gián đoạn ngay c ả khi dịch vụ CNTT vẫn sẵn sàng.
 Tiếp tục sẵn sàng: m ột phương pháp ti ếp cận hoặc thiết kế đ ể
đạt được 100% tính sẵn sàng. Một dịch vụ CNTT tiếp tục sẵn
sàng không có b ất kỳ gián đoạn kể cả đã được lên kế hoạch
hay không.
Rất nhiều nhà cung cấp cam kết các giải pháp có tính sẵn sàng
cao hoặc tiếp t ục sẵn sàng chỉ nếu các tiêu chuẩn m ôi trường
nghiêm ngặt và các quy trình có kh ả năng phục hồi được sử
dụng. Họ thường thỏa thuận các hợp đồng như vậy chỉ sau khi
m ột khảo sát th ực địa đã được hoàn tất và ngoài ra, thỉnh thoảng
tốn kém , các cải thiện đã được thực hiện.

175
Quản lý Tính s ẵn sàng khởi đầu ngay khi cá c yêu c ầu về tính sẵn
sàng đối với m ột dịch vụ CNTT là đủ rõ ràng để được trình bày rõ
ràng. Đây là m ột quá trình liên t ục, chỉ kết thúc khi dịch vụ CNTT
không được sử dụng nữa hoặc ngừng hoạt động. Các ho ạt động
chính của quy trình Quản lý Tính s ẵn sàng là:
 Xác định các yêu cầu về tính sẵn sàng t ừ doanh nghiệp đối vớ i
dịch vụ CNTT m ới hoặc được tăng cường và xây d ựng các tiêu
chí thiết kế về tính sẵn sàng và khôi phục cho các thành ph ần
CNTT hỗ trợ.
 Xác định VBF, k ết hợp với doanh nghi ệp và ITSCM.
 Xác định tác động phát sinh từ sự cố của dịch vụ CNTT và
thành phần, kết hợp với ITSCM và, n ếu thích hợp, xem xét các
tiêu chí thi ết kế tính sẵn sàng để cung cấp khả năng phục hồi
bổ sung nhằm ngăn ngừa hoặc giảm thiểu tác động đến doanh
nghiệp.
 Xác định các đích nhắm m ục tiêu về tính sẵn sàng, độ tin cậ y
và khả năng duy trì cho các thành ph ần cơ sở hạ tầng CNTT
làm nền tảng cho dịch vụ CNTT để cho phép các thành ph ần
này được ghi nh ận và thỏa thuận trong các SLA, OLA và h ợp
đồng.
 Thiết lập các thước đo và báo cáo về tính sẵn sàng, độ tin cậ y
và khả năng duy trì ph ản ánh quan đi ểm của doanh nghi ệp,
người sử dụng và t ổ chức hỗ trợ CNTT.
 Giám sát và phân tích xu hư ớng về tính sẵn sàng, đ ộ tin cậy
và khả năng duy trì của các thành ph ần CNTT.
 Xem xét tính sẵn sàng c ủa dịch vụ CNTT và thành ph ần và xác
định các m ức không thể chấp nhận được.
 Tìm hiểu những nguyên nhân cơ b ản đối với tính sẵn sàng
không thể chấp nhận được.
 Đưa ra và duy trì m ột Kế hoạch về Tính sẵn sàng để thiết lập
độ ưu tiên và lên k ế hoạch cải thiện tính sẵn sàng.

Quy trình Quản lý Tính s ẵn sàng phụ thuộc rất nhiều vào vi ệc đo
lường những thành tựu của dịch vụ và thành ph ần liên quan đến tính
sẵn sàng.
‘Nếu bạn không đo lường nó, bạn không thể quản lý nó’
‘Nếu bạn không đo lường nó, bạn không thể cải thiện nó’
‘Nếu bạn không đo lường nó, hầu như chắc chắn bạn sẽ không
quan tâm ’
‘Nếu bạn không th ể tác động hoặc kiểm soát nó, vậy thì đừng đo
lường nó’
'Đo lường cái gì và báo cáo như th ế nào' chắc chắn phụ thuộc vào
hoạt động nào đang đư ợc hỗ trợ, người nhận là ai và cách thông tin
được sử dụng như thế nào. Điều quan tr ọng là nhận thức được

176
những quan đi ểm khác nhau về tính s ẵn sàng để đảm bảo việc đo
lường và báo cáo đáp ứng các nhu c ầu đa dạng này:
 Quan điểm kinh doanh xem xét tính s ẵn sàng c ủa dịch vụ

CNTT về m ặt đóng góp hoặc tác động của nó đối với các VBF
thúc đẩy hoạt động kinh doanh.
 Quan điểm người dùng coi tính s ẵn sàng c ủa dịch vụ CNTT là
sự kết hợp của ba yếu tố, đó là t ần suất, thời lượng và phạm
vi tác động, tức là m ọi người sử dụng, m ột số người sử dụng,
tất cả các chức năng kinh doanh ho ặc m ột số chức năng kinh
doanh nhất định - người sử dụng cũng coi tính s ẵn sàng của
dịch vụ CNTT về m ặt thời gian phản hồi. Đối với nhiều ứng
dụng tập trung vào hi ệu suất, thời gian phản hồi kém được coi
là có tác động tương đương với các lỗi của công nghệ.
 Quan điểm của nhà cung cấp dịch vụ CNTT xem xét tính s ẵn
sàng của dịch vụ và thành phần CNTT liên quan đ ến tính sẵn
sàng, độ tin cậy và khả năng duy t rì.
Để thỏa m ãn các quan đi ểm khác nhau về tính sẵn sàng, Quản lý

Tính sẵn sàng c ần xem xét phạm vi các thước đo c ần thiết để báo
cáo cung m ột m ức độ sẵn sàng ‘giống nhau’ theo nhi ều cách khác
nhau. Các thước đo cần phải có ý nghĩa và gia tăng giá tr ị nếu việc
đo lường và báo cáo v ề tính sẵn sàng cu ối cùng là đ ể m ang lại lợi
ích cho các t ổ chức CNTT và doanh nghi ệp. Điều này ch ịu ảnh
hưởng m ạnh m ẽ bởi sự kết hợp giữa "những gì bạn đo lường" và
"cách bạn báo cáo nó".
4.4.5.1 Những hoạt động ứng phó của Quản lý Tính sẵn sàng
Giám sát, đo lường, phân tích và báo cáo v ề tính sẵn sàng của
dịch vụ và thành phần
Một đầu ra chính t ừ quy trình Quản lý Tính sẵn sàng là đo lường và
báo cáo về tính sẵn sàng c ủa CNTT. Các thước đo tính sẵn sàng
nên được kết hợp vào SLA, OLA và bất kỳ hợp đồng cơ sở nào.
Chúng nên được xem xét m ột cách thường xuyên t ại các cu ộc họp
đánh giá Mức Dịch vụ. Đo lường và báo cáo cung c ấp cơ sở cho:
 Sự giám sát tình tr ạng sẵn sàng thực tế được cung c ấp so vớ i

các m ục tiêu đã thỏa thuận.
 Việc thiết lập các thước đo về tính s ẵn sàng và th ống nhất các
đích nhắm m ục tiêu về tính sẵn sàng với doanh nghi ệp.
 Việc xác định m ức độ không thể chấp nhận của tính sẵn sàng
gây ảnh hưởng đến doanh nghiệp và người dùng.
 Việc đánh giá tính s ẵn sàng với t ổ chức hỗ trợ CNTT.
 Các hoạt động cải tiến liên tục để tối ưu hóa tính s ẵn sàng.
Trong rất nhiều năm, các t ổ chức cung c ấp dịch vụ CNTT đã đo

lường và báo cáo v ề quan điểm về tính sẵn sàng của họ. Theo
truyền thống, các thước đo này t ập trung vào tính s ẵn sàng c ủa
thành phần và đã ph ần nào tách bi ệt khỏi quan điểm của doanh
nghiệp và người dùng. Thông thư ờng, các thước đo truyền thống
này dựa trên sự kết hợp của tỷ lệ phần trăm sẵn sàng (%), thời gian

177
bị m ất và tần suất hỏng hóc. Một số ví dụ về các thước đo truyền
thống này như dưới đây:
 Tỷ lệ phần trăm sẵn sàng - thước đo thực sự ‘truyền thống’

biểu thị tính s ẵn sàng dư ới dạng phần trăm và do đó, h ữu ích
hơn nhiều như m ột thước đo tính sẵn sàng của thành phần
hơn là thước đo tính s ẵn sàng của dịch vụ. Nó thường được
sử dụng để theo dõi và báo cáo thành tích so v ới đích nh ắm
m ục tiêu về m ức dịch vụ. Nó có xu hướng nhấn m ạnh đến "con
số lớn", như vậy nếu m ục tiêu m ức độ dịch vụ là 98,5% và
thành tích là 98,3%, thì nó có v ẻ không tệ như vậy. Điều này
có thể khuyến khích hành vi tự m ãn trong t ổ chức hỗ trợ
CNTT.
 Tỷ lệ phần trăm không sẵn sàng - điều ngược lại với điều
trên. Tuy nhiên, th ể hiện này có lợi ích là t ập trung vào tình
trạng không sẵn sàng. Dựa trên ví d ụ trên, nếu m ục tiêu về
không sẵn sàng là 1,5% và thành tích là 1, 7%, thì đây là m ột
sự khác biệt tương đối lớn hơn nhiều. Phương pháp báo cáo
này có nhiều khả năng tạo ra nhận thức về sự thiếu hụt trong
việc cung c ấp m ức độ sẵn sàng c ần thiết.
 Thời lượng - đạt được bằng cách chuyển đổi tỷ lệ phần trăm
không sẵn sàng thành giờ và phút. Đi ều này cung cấp m ột
thước đo 'con người' hơn m à m ọi người có thể liên quan đ ến.
Nếu m ục tiêu thời gian chết hàng tuần là hai giờ, nhưng m ột
tuần thời gian ngừng hoạt động thực tế là bốn giờ; điều này s ẽ
đại diện cho m ột xu hướng dẫn đến việc doanh nghi ệp không
có thêm bốn ngày không s ẵn sàng trong vòng m ột năm . Lo ại
thước đo và báo cáo này có nhi ều khả năng khuyến khích sự
tập trung vào c ải tiến dịch vụ.
 Tần suất lỗi - được sử dụng để ghi lại số lần gián đo ạn dịch
vụ CNTT. Nó giúp cung c ấp m ột dấu hiệu tốt về độ tin c ậy từ
góc độ người dùng. Tốt nhất nên sử dụng kết hợp với "thời
lượng" để có cái nhìn cân b ằng về mức độ gián đoạn dịch vụ
và khoảng thời gian bị m ất đối với doanh nghi ệp.
 Tác động của lỗi - đây là thước đo thực sự của dịch vụ không
khả dụng. Điều này phụ thuộc vào việc ghi lại sự cố trưởng
thành m à trong đó ngư ời sử dụng không có kh ả năng thực
hiện các tác vụ nghiệp vụ của họ là phần thông tin quan tr ọng
nhất được thu th ập. Tất cả các biện pháp khác đều có khả
năng che gi ấu các tác động thực sự của sự cố dịch vụ và
thường được chuyển thành tác động tài chính.
Doanh nghi ệp có thể đã, trong nhiều năm , đã chấp nhận rằng tính
sẵn sàng của CNTT m à họ trải nghiệm được thể hiện dưới dạng tính
sẵn sàng c ủa bộ phận thay vì tính s ẵn sàng của dịch vụ hoặc doanh
nghiệp tổng thể. Tuy nhiên, đi ều này không còn được coi là có th ể
chấp nhận được nữa và doanh nghi ệp m uốn thể hiện tốt hơn tính
sẵn sàng trong (các) bi ện pháp chứng m inh hậu quả tích cực và tiêu
cực của tính sẵn sàng c ủa CNTT đối với doanh nghi ệp và ngư ời
dùng của họ.

178
Những thước đo về tính sẵn sàng quan tr ọng nhất là những gì
phản ảnh và đo lư ờng được tính s ẵn sàng t ừ quan điểm doanh
nghiệp lẫn quan đi ểm của người sử dụng.
Quản lý Tính sẵn sàng c ần phải xem xét tính s ẵn sàng từ cả quan
điểm của m ột doanh nghi ệp/nhà cung cấp dịch vụ CNTT lẫn quan
điểm thành phần CNTT. Đây là những khía c ạnh hoàn toàn khác
nhau và trong khi khái ni ệm cơ bản là tương t ự nhau, thư ớc đo,
trọng tâm và tác đ ộng là hoàn toàn khác nhau
Mục đích duy nh ất của việc đưa ra các báo cáo và đo lư ờng về tính
sẵn sàng, bao g ồm những gì từ quan điểm kinh doanh, là đ ể cải
thiện chất lượng và tính s ẵn sàng của dịch vụ CNTT đã cung c ấp
cho doanh nghi ệp và ng ười sử dụng. Mọi thước đo, báo cáo và ho ạt
động nên phản ảnh m ục đích này.
Tính sẵn sàng, khi được đo lường và báo cáo đ ể phản ảnh trải
nghiệm của người sử dụng, cung c ấp m ột cái nhìn m ang tính đ ại
diện hơn về chất lượng của dịch vụ CNTT. Quan điểm của người sử
dụng về tính sẵn sàng ch ịu ảnh hưởng bởi ba yếu tố sau:
 Tần suất gián đo ạn.

 Thời lượng gián đo ạn
 Phạm vi của tác động.
Do đó, các thước đo và báo cáo v ề tính sẵn sàng người sử dụng nên
bao quát các yếu t ố này. Phương pháp lu ận được sử dụng để phản
ảnh tính s ẵn sàng của người sử dụng có thể cân nhắc hai phương
pháp tiếp cận sau đây:
 Ảnh hưởng bởi số phút người sử dụng bị mất: đây là phép

tính dựa trên thời lượng gián đo ạn nhân với số lượng người
sử dụng bị ảnh hưởng. Đây có th ể là cơ sở để báo cáo về tính
sẵn sàng như là năng su ất của người sử dụng bị m ất hoặc để
tính toán t ỷ lệ phần trăm sẵn sàng từ quan điểm của người sử
dụng, và cũng có thể bao gồm chi phí khôi phục phần năng
suất bị m ât (ví dụ, thanh toán ti ền công ngoài gi ờ tăng lên).
 Ảnh hưởng bởi giao dịch kinh doanh : đây là phép tính d ựa
trên số lượng giao dịch kinh doanh không th ể được xử lý trong
khoảng thời gian gián đo ạn. Điều này cung c ấp m ột dấu hiệu
tốt hơn về tác động kinh doanh phản ảnh các hồ sơ xử lý giao
dịch khác nhau theo th ời gian ngày, tuần, v.v… Trong r ất
nhiều trường hợp, có thể xảy ra tình trạng tác động của người
sử dụng tương quan với VBF, ví d ụ, nếu người sử dụng nhận
đơn đặt hàng c ủa khách hàng và VBF là doanh thu khách
hàng. Thước đo duy nhất này là cơ sở để phản ảnh tác đ ộng
đến vận hành c ủa doanh nghi ệp và đến người sử dụng.
Phương pháp được sử dụng nên chịu ảnh hưởng của bản chất của
hoạt động kinh doanh. M ột hoạt động kinh doanh h ỗ trợ hoạt động

179
nhập liệu rất phù hợp với báo cáo phản ảnh năng suất người sử
dụng bị m ất. Các hoạt động kinh doanh hướng đến khách hàng
nhiều hơn, ví d ụ, các dịch vụ ATM, đư ợc hưởng lợi từ việc báo cáo
tác động của giao dịch. Cũng cần lưu ý rằng không ph ải m ọi tác
động kinh doanh đ ều liên quan đ ến người sử dụng. Với quá trình t ự
động hóa và xử lý điện tử ngày càng tăng, kh ả năng xử lý các giao
dịch t ự động hóa ho ặc đáp ứng thời gian k ỳ hạn của thị trường cũng
có tác động tài chính to l ớn có thể còn lớn hơn khả năng làm việc
của người dùng.
Tổ chức hỗ trợ CNTT cần phải có nhận thức sâu sắc về trải nghiệm
của người sử dụng về tính sẵn sàng. Tuy nhiên, l ợi ích thực sự đến
từ việc tổng hợp quan đi ểm của người sử dụng thành quan điểm của
doanh nghiệp. Một nguyên t ắc hướng dẫn quy trình Quản lý Tính sẵn
sàng là ‘Việc cải thiện tính sẵn sàng chỉ có thể bắt đầu khi đã
hiểu rõ cách thứ c mà công nghệ hỗ trợ cho doanh nghi ệp’. Do
đó, Quản lý Tính s ẵn sàng không ch ỉ là việc tìm hiêu tính s ẵn sàng
của m ỗi thành phần CNTT m à còn là m ọi thứ về việc tìm hiểu tác
động của các lỗi thành phần lên dịch vụ và tính s ẵn sàng của người
sử dụng. T ừ quan điểm doanh nghiệp, m ột dịch vụ CNTT chỉ có thể
được coi là s ẵn sàng khi doanh nghi ệp có khả năng hoàn thành m ọi
chức năng nghi ệp vụ quan tr ọng để thúc đẩy hoạt động kinh doanh.
Do đó, để dịch vụ CNTT sẵn sàng, nó phụ thuộc vào m ọi thành phần
m à dịch vụ phụ thuộc vào tính s ẵn sàng, tức là các hệ thống, các
thành phần chủ yếu, m ạng, dữ liệu và các ứng dụng.
Phương pháp ti ếp cận CNTT truyền thống sẽ là đo lường tính sẵn

sàng của từng thành ph ần này m ột cách riêng l ẻ. Tuy nhiên, thước
đo thực sự về tính sẵn sàng đã ph ải dựa trên những tác động tích
cực và tiêu c ực đối với các VBF (Vital Business Functions) m à các
hoạt động kinh doanh đang ph ụ thuộc vào. Phương pháp ti ếp cận
này đảm bảo rằng các SLA và báo cáo v ề tính sẵn sàng CNTT được
căn cứ vào các thư ớc đo đã được hiểu rõ bởi cả doanh nghiệp lẫn
CNTT. Bằng cách đo lường những VBF dựa trên các d ịch vụ CNTT,
các thước đo và báo cáo tr ở nên định hướng-kinh doanh, cùng với
tác động của lỗi phản ảnh hậu quả đối với doanh nghi ệp. Một điều
quan trọng nữa là tính sẵn sàng c ủa các dịch vụ được xác định và
thỏa thuận với doanh nghi ệp và được phản ảnh trong các SLA. Đ ịnh
nghĩa về tính sẵn sàng này nên bao g ồm:
 Mức độ sẵn sàng tối thiểu của chức năng c ủa dịch vụ là gì?
 Ở m ức độ đáp ứng nào của dịch vụ sẽ được coi là không s ẵn
sàng?
 Mức độ chức năng và ph ản hồi này s ẽ được đo lường ở đâu?
 Trọng số tương đối đối với dịch vụ không s ẵn sàng m ột phần
là gì?
 Nếu m ột địa điểm hoặc m ột văn phòng bị ảnh hưởng, toàn bộ
dịch vụ có được coi là không sẵn sàng không, ho ặc nó được
xem là ‘không s ẵn sàng m ột phần’? Điều này c ần được thỏa
thuận với khách hàng.

180
Các công cụ báo cáo và phân tích là b ắt buộc đối với việc kiểm soát
dữ liệu được lưu tr ữ trong các cơ sở dữ liệu khác nhau được sử
dụng bởi Quản lý Tính sẵn sàng. Nh ững công c ụ này có thể dựa trên
nền tảng hoặc dựa trên m áy tính và thư ờng thì là s ự kết hợp của cả
hai. Điều này sẽ bị ảnh hưởng bởi các công ngh ệ lưu trữ cơ sở dữ
liệu được lựa chọn và sự phức tạp của việc xử lý dữ liệu và báo
cáo. Quản lý Tính s ẵn sàng, m ột khi đã được thực hiện và triển khai,
sẽ được yêu c ầu t ạo ra các báo cáo thư ờng xuyên trên cơ s ở đã
thống nhất, ví dụ: báo cáo tình tr ạng sẵn sàng hàng tháng, K ế hoạch
về Tính sẵn sàng, báo cáo tr ạng thái Phân tích L ỗi Dịch vụ (SFA),
v.v... Các ho ạt động liên quan đến các hoạt động báo cáo này có th ể
đòi hỏi nhiều nỗ lực thủ công và giải pháp duy nhất là t ự động hóa
càng nhiều hoạt động tạo ra báo cáo càng t ốt. Đối với các m ục đích
báo cáo, các tiêu chu ẩn báo cáo của t ổ chức nên được sử dụng nếu
có thể. Nếu những tiêu chu ẩn này không t ồn tại, các tiêu chu ẩn
CNTT cần được phát triển để các báo cáo CNTT có th ể được phát
triển bằng các công cụ và kỹ thuật tiêu chu ẩn. Điều này có nghĩa là
việc tích hợp và hợp nhất các báo cáo sau đó s ẽ đạt được dễ dàng
hơn nhiều.
Phân tích tình tr ạng không sẵn sàng

Mọi sự kiện và sự cố gây ra tình trạng không s ẵn sàng c ủa dịch vụ
và thành ph ần cần phải được điều tra, với các hành đ ộng khắc phục
được triển khai trong K ế hoạch về Tính sẵn sàng hoặc SIP tổng thể.
Các xu hư ớng phải được tạo ra từ việc phân tích này để định hướng
và tập trung các hoạt động như Phân tích Lỗi Dịch vụ (SFA) đến
những khu vực gây ra tác đ ộng hoặc gián đoạn nhiều nhất cho
doanh nghiệp và người dùng.
Chi phí tổng thể của m ột dịch vụ CNTT bị ảnh hưởng bởi m ức độ
sẵn sàng c ần thiết và các khoản đầu tư c ần thiết vào công nghệ và
dịch vụ do tổ chức hỗ trợ CNTT cung cấp để đáp ứng yêu cầu này.
Sự sẵn sàng ch ắc chắn là không m iễn phí. Tuy nhiên, đi ều quan
trọng là phải phản ánh rằng việc không sẵn sàng CNTT cũng ph ải trả
giá, do đó, việc không s ẵn sàng cũng không ph ải là m iễn phí. Đố i
với các quy trình kinh doanh và VBF có t ầm quan tr ọng cao, c ần
phải xem xét không ch ỉ chi phí cung c ấp dịch vụ, m à còn c ả chi phí
phát sinh do l ỗi. Sự cân bằng tối ưu để đạt được là chi phí của giải
pháp khả dụng được cân nhắc với chi phí của việc không s ẵn sàng.
Trước khi bất kỳ SLR nào được chấp nhận và cuối cùng, SLR ho ặc
SLA được thương lượng và thống nhất giữa doanh nghi ệp và tổ
chức CNTT, điều thiết yếu là các yêu cầu về tính sẵn sàng c ủa
doanh nghiệp phải được phân tích để đánh giá xem /làm th ế nào dịc h
vụ CNTT có thể cung cấp các m ức được yêu cầu về tính sẵn sàng.
Điều này không ch ỉ áp dụng cho các d ịch vụ CNTT m ới đang đư ợc
giới thiệu m à còn cho bất kỳ thay đổi nào được yêu c ầu đối với các
yêu cầu về tính s ẵn sàng c ủa các dịch vụ CNTT hiện có.
Chi phí c ủa m ột lỗi CNTT có thể đơn giản được biểu thị bằng số
lượng giao dịch kinh doanh ho ặc giao dịch CNTT bị ảnh hưởng, dướ i

181
dạng m ột con s ố thực tế (lấy từ thiết bị đo đạc) hoặc dựa trên m ột
ước tính. Khi đã đư ợc đo lường đối với các VBF hỗ trợ hoạt động
kinh doanh, việc này có th ể cung cấp m ột dấu hiệu rõ ràng về hậu
quả của lỗi. Ưu điểm của phương pháp này là tương đ ối dễ lấy d ữ
liệu tác động và không c ần bất kỳ tính toán quá ph ức tạp nào. Nó
cũng trở thành m ột ‘giá tr ị’ được hiểu rõ bởi cả doanh nghiệp lẫn tổ
chức CNTT. Đây có thể là yếu tố kích thích đ ối với việc xác định các
cơ hội cải tiến và có th ể trở thành m ột chỉ số chủ yếu trong việc
giám sát tính s ẵn sàng c ủa các dịch vụ CNTT.
Khuyết điểm chính của phương pháp ti ếp cận này là nó không cung
cấp được giá tr ị tiền tệ rõ ràng s ẽ cần đến để biện m inh cho bất kỳ
quyết định đầu tư tài chính quan tr ọng nào để cải thiện tính s ẵn
sàng. Khi m à các quy ết định đầu tư tài chính quan trọng là cần thiết,
tốt hơn là nên thể hiện chi phí của thất bại phát sinh từ việc dịch vụ,
hệ thống, ứng dụng hoặc chức năng bị tổn thất đối với doanh nghi ệp
dưới dạng ‘giá tr ị’ tiền tệ.
Giá trị tiền tệ có thể được tính toán như là s ự tổng hợp của các chi
phí hữu hình tương ứng với thất bại, nhưng cũng có th ể bao gồm
m ột số chi phí vô hình khác. Giá tr ị tiền tệ cũng nên phản ảnh tác
động chi phí đối với toàn bộ tổ chức, nghĩa là doanh nghi ệp và t ổ
chức CNTT.
Chi phí hữu hình có thể bao gồm :
 Mất năng suất người sử dụng.

 Mất năng suất của nhân viên CNTT.
 Mất doanh thu.
 Chi phí làm thêm ngoài gi ờ.
 Lãng phí hàng hóa và nguyên v ật liệu.
 Bị phạt tiền.
Điều quan trọng không ch ỉ đơn giản là bỏ qua chi phí vô hình (và
các hậu quả tiềm tàng) vì lý do chún g có thể khó đo lư ờng. Tình
trạng không s ẵn sàng tổng thể của dịch vụ, tổng chi phí h ữu hình và
tổng chi phí vô hình phát sinh t ừ tình tr ạng không sẵn sàng của dịch
vụ là những chỉ số chủ yếu trong đo lường hiệu quả của quy trình
Quản lý Tính s ẵn sàng.
Vòng đời sự cố mở rộng

Nguyên tắc hướng dẫn của Quản lý tính s ẵn sàng là nh ận ra rằng
vẫn có thể có được sự hài lòng của khách hàng ngay c ả khi m ọi thứ
diễn ra không như ý m u ốn. Một phương pháp tiếp cận để giúp đạt
được điều này đòi hỏi rằng Quản lý Tính sẵn sàng phải đảm bảo
rằng thời gian c ủa bất kỳ sự cố nào được giảm thiểu để cho phép
các hoạt động kinh doanh bình thư ờng được tiếp tục m ột cách
nhanh nhất có thể. Mục đích c ủa Quản lý Tính sẵn sàng là đảm bảo
rằng thời lượng và tác đ ộng từ các sự cố ảnh hưởng đến dịch vụ
CNTT được giảm thiểu, để cho phép hoạt động kinh doanh ti ếp tục
m ột cách nhanh nh ất có thể. Việc phân tích ‘vòng đời sự cố m ở

182
rộng’ cho phép t ổng thời gian ngừng hoạt động của dịch vụ CNTT
đối với bất kỳ sự cố cụ thể nào được chia nhỏ và lập bản đồ theo
các giai đoạn chính m à qua đó t ất cả các sự cố đều tiến triển (vòng
đời). Quản lý sẵn sàng ph ối hợp chặt chẽ với Quản lý sự cố và Quản
lý vấn đề trong vi ệc phân tích tất cả các sự cố gây ra tình tr ạng
không sẵn sàng.
Một kỹ thuật tốt để giúp phân tích k ỹ thuật về các sự cố ảnh hưởng
đến tính sẵn sàng của các thành ph ần và dịch vụ CNTT là xem xét
‘vòng đời’ sự cố. Mọi sự cố đều trải qua m ột vài giai đoạn chính.
Thời gian trôi qua trong các giai đo ạn này có thể thay đổi đáng k ể.
Đối với m ục đích Q uản lý Sự cố, ‘vòng đời’ sự cố tiêu chuẩn, như
được m ô tả trong Quản lý Sự cố, đã được m ở rộng để cung c ấp
thêm trợ giúp và hướng dẫn, đặc biệt trong lĩnh vực ‘thiết kế đ ể
phục hồi’. Hình 4.15 m inh h ọa vòng đời sự cố m ở rộng.
Hình 4.15 – Vòng đời sự cố mở rộng
Từ những gì nói trên, có th ể thấy rằng m ột sự cố có thể được chia

nhỏ thành các giai đo ạn riêng lẻ trong m ột vòng đời để có thể được
tính thời gian và đo lường. Chế độ xem xét vòng đ ời này cung cấp
m ột khuôn khổ quan tr ọng trong vi ệc xác định, giữa những điều
khác, các yêu c ầu quản lý hệ thống đối với việc nhận diện các s ự
kiện và sự cố, các yêu cầu nắm bắt dữ liệu chẩn đoán và các công
cụ để chẩn đoán, các kế hoạch khôi ph ục để hỗ trợ khôi phục nhanh
chóng và cách làm th ế nào để xác m inh rằng dịch vụ CNTT đã được
khôi phục. Những giai đo ạn riêng lẻ trong vòng đời được xem xét chi
tiết hơn như dư ới đây:
 Nhận diện sự cố: thời điểm mà tại đó tổ chức cung c ấp dịch

vụ CNTT nhận thức được về sự cố. Các công cụ quản lý hệ
thống có ảnh hưởng m ột cách tích cực đến khả năng nhận

183
diện các s ự kiện và sự cố và do đó, cải thiện được m ức độ
của tính s ẵn sàng có th ể cung c ấp được. Việc triển khai và
khai thác nên t ập trung m ạnh m ẽ vào việc đạt được tình tr ạng
sẵn sàng cao và các m ục tiêu khôi phục được tăng cường.
Trong bối cảnh phục hồi, những công c ụ đó nên đư ợc khai
thác để cung c ấp việc nhận diện lỗi được tự động hóa, h ỗ trợ
chẩn đoán l ỗi và hỗ trợ khôi phục lỗi được tự động hóa, cùng
với những ứng phó theo t ập lệnh. Các công cụ là rất quan
trọng trong vi ệc giảm thiểu m ọi giai đoạn của vòng đời sự cố,
nhưng chủ yếu là phát hiện ra các s ự kiện và s ự cố. Lý tư ởng
nhât là sự cố được phát hiện và giải quyết m ột cách tự động,
trước khi người sử dụng nhận ra nó ho ặc bị ảnh hưởng theo
bất kỳ cách nào.
 Chẩn đoán sự cố: thời điểm mà tại đó sự chẩn đoán đ ể xác
định nguyên nhân cơ b ản được hoàn tất. Khi m ột thành phầ n
CNTT bị lỗi, điều quan tr ọng là m ức độ chẩn đoán c ần thiết
được thực hiện để cho phép xác đ ịnh vấn đề để từ đó xác
định được nguyên nhân c ốt lõi và gi ải quyết vấn đề. Việc sử
dụng và năng l ực của các công cụ và kỹ năng chẩn đoán là
rất quan tr ọng đối với việc giải quyết nhanh chóng các v ấn đề
dịch vụ. Đối với m ột số lỗi nhất định, việc thực hiện các chẩn
đoán có thể khiến thời gian gián đo ạn kéo dài thêm . Tuy
nhiên, việc không n ắm bắt được các chẩn đoán thích hợp sẽ
tạo ra và khi ến cho dịch vụ bị lặp lại các lỗi. Khi thời điểm cần
thiết để tiến hành chẩn đoán đư ợc coi là quá m ức hoặc khác
biệt so với đích nhắm m ục tiêu, m ột đánh giá nên được tiế n
hành để xác định xem liệu các k ỹ thuật và/hoặc các thủ tục
có thể được sắp xếp hợp lý để giảm thiểu thời gian c ần thiết
hay không. Ph ạm vi tương đương c ủa chẩn đoán dữ liệu về
tính sẵn sàng đ ể nắm bắt có thể được đánh giá đ ể đảm bả o
rằng chỉ có những dữ liệu chẩn đoán thi ết yếu m ới được thu
thập. Thời gian gián đo ạn bổ sung c ần thiết để nắm bắt chẩn
đoán nên đư ợc bao gồm trong các ch ỉ số khôi phục được lập
thành văn bản đối với m ỗi thành phần CNTT.
 Sửa chữa sự cố: thời điểm m à tại đó lỗi được sửa chữa/khắc
phục. Thời gian s ửa chữa đối với các sự cố nên được giám
sát liên tục và được so sánh với các đích nh ắm m ục tiêu đã
được thỏa thuận trong các OLA, các h ợp đồng cơ sở và các
thỏa thuận khác. Đi ều này đặc biệt quan tr ọng khi liên quan
đến các dịch vụ được cung c ấp bên ngoài và hiệu suất nhà
cung c ấp. Bất cứ khi nào sự vi phạm được phát hiện, các k ỹ
thuật nên được sử dụng để giảm thiểu hoặc loại bỏ vi phạm
từ các sự cố tương tự trong tương lai.
 Khôi phục sự cố: thời điểm m à tại đó việc khôi ph ục thành
phần được hoàn tất. Các yêu cầu sao lưu và khôi ph ục đối với
các thành ph ần cơ sở của m ột dịch vụ CNTT m ới nên được
xác định càng sớm càng t ốt trong chu k ỳ thiết kế. Nhưng yêu
cầu này nên bao hàm ph ần cứng, phần m ềm và dữ liệu và
những đích nhắm mục tiêu về khôi phục. Kết quả từ hoạt động
này nên là m ột bộ các yêu c ầu khôi phục được lập thành văn
bản cho phép phát tri ển các kế hoạch khôi phục tương xứng.

184
Để dự đoán trước và chuẩn bị cho việc thực hiện khôi phục
sao cho vi ệc khôi phục dịch vụ hiệu quả và đạt hiệu suất sẽ
đòi hỏi việc phát tri ển và kiểm nghiệm các kế hoạch khôi phục
tương xứng dựa trên các yêu c ầu khôi phục đã được lập
thành văn bản. Bất cứ khi nào có thể, các hoạt động vận hành
trong kế hoạch khôi phục nên được tự động hóa. Việc kiểm
nghiệm các kế hoạch khôi phục cũng cung c ấp thời gian xấp
xỉ để khôi phục. Những chỉ số khôi phục này có th ể được sử
dụng để hỗ trợ truyền thông về khả năng khôi ph ục ước tính
của dịch vụ và xác m inh hoặc tăng cường tài li ệu Phân tích
Tác động của Lỗi Thành phần. Quản lý Tính s ẵn sàng phải
liên tục tìm kiếm và thúc đ ẩy những phương pháp khôi ph ục
nhanh hơn cho m ọi Sự cố tiềm tàng. Đi ều này có thể đạt được
thông qua m ột loạt các phương pháp, bao g ồm tự động nhận
diện lỗi, t ự động khôi phục, các th ủ tục leo thang nghiêm ng ặt
hơn, khai thác các công c ụ và kỹ thuật m ới và nhanh hơn.
Các yêu c ầu về tính sẵn sàng cũng nên góp ph ần vào vi ệc xác
định những linh ki ện thay thế nào được giữ lại trong Linh ki ện
Cuối cùng để tạo điều kiện cho vi ệc sửa chữa nhanh chóng và
hiệu quả, như đã được m ô tả trong ấn phẩm Chuyển tiếp Dịch
vụ.
 Phục hồi Sự cố: thời điểm m à tại đó dịch vụ nghiệp vụ được
tiếp tục. Một sự cố có thể được coi là ‘đóng’ khi d ịch vụ đã
được phục hồi và hoạt động kinh doanh bình thư ờng được
tiếp tục. Điều quan trọng là dịch vụ CNTT được phục hồi phả i
được xác m inh là ho ạt động bình thư ờng ngay sau khi quá
trình phục hồi hoàn tất và trước khi bất kỳ nhân viên k ỹ thuật
nào liên quan đến sự cố sẽ tạm dừng công vi ệc của họ. Trong
phần lớn các trường hợp, đây ch ỉ đơn giản là trường hợp có
được sự xác nhận từ những người sử dụng bị ảnh hưởng. Tuy
nhiên, người sử dụng đối với m ột số dịch vụ có thể là khách
hàng của doanh nghi ệp, nghĩa là các dịch vụ ATM, các d ịch
vụ dựa trên Internet. Đối với những loại dịch vụ này, chúng tôi
khuyến nghị rằng các thủ tục xác m inh dịch vụ CNTT nên
được phát triển để cho phép t ổ chức cung c ấp dịch vụ CNTT
xác m inh r ằng dịch vụ CNTT được phục hồi giờ đây đang hoạt
động như đã được kỳ vọng. Đây có th ể chỉ đơn giản là m ột
kiểm tra trực quan về thông lượng giao dịch hoặc các tập
lệnh m ô phỏng người sử dụng xác nhận dịch vụ từ đầu-đến-
cuối.
Mỗi giai đoạn, và thời gian thực hiện tương ứng, ảnh hưởng đến
tổng thời gian gián đoạn được nhận thức bởi người sử dụng. Bằng
cách thực hiện phương pháp tiếp cận này, bạn sẽ có khả năng biết
được thời gian đang bị ‘m ất đi’ trong thời lượng của m ột sự cố. Ví
dụ, dịch vụ đã không s ẵn sàng đối với doanh nghi ệp trong 60 phút,
nhưng chỉ m ất 5 phút đ ể áp dụng bản vá lỗi – 55 phút còn l ại đã m ất
đi đâu?
Việc sử dụng phương pháp ti ếp cận này xác định các lĩnh vực có
khả năng kém hiệu quả có thể kết hợp để khiến cho tổn thất về dịch

185
vụ m à doanh nghiệp phải trải qua lớn hơn m ức cần thiết. Chúng c ó
thể bao gồm những lĩnh vực như tự động hóa kém (các c ảnh báo,
khôi phục tự động hóa, v.v…), các công cụ và t ập lệnh chẩn đoán
kém , các thủ tục leo thang không rõ ràng (làm trì hoãn s ự leo thang
đến nhóm hoặc nhà cung c ấp hỗ trợ kỹ thuật thích hợp), hoặc thiếu
tài liệu vận hành toàn diện. Quản lý Tính s ẵn sàng cần phải hoạt
động trong s ự kết hợp m ột cách c hặt chẽ với Quản lý Vấn đề và
Quản lý Sự cố để đảm bảo những sự cố lặp lại được loại trừ. Chúng
tôi khuyến cáo r ằng những thước đo này nên được thiết lập và nắm
bắt cho m ọi sự cố về tính sẵn sàng. Đi ều này cung cấp các chỉ số
cho Quản lý Tính s ẵn sàng về cả các sự cố cụ thể lẫn thông tin về
xu hướng. Thông tin này có th ể được sử dụng như là đ ầu vào đối
với các nhiệm vụ SFA, các ho ạt động SIP và báo cáo Qu ản lý Tính
sẵn sàng định kỳ và cung c ấp m ột sự thúc đẩy đối với hoạt động cải
tiến liên t ục để theo đuổi các cải thiện về hiệu quả chi phí. Nó cũng
có thể cho phép các đích nh ắm m ục tiêu được thiết lập cho các giai
đoạn cụ thể của vòng đ ời sự cố. Mặc dù việc chấp nhận rằng m ỗi sự
cố có thể có nhiều m ức độ phức tạp về kỹ thuật, các đích nh ắm m ục
tiêu có thể được sử dụng để phản ảnh tính nh ất quán trong cách m à
tổ chức cung cấp dịch vụ CNTT ứng phó với các sự cố như thế nào.
Một đầu ra từ quy trình Qu ản lý Tính s ẵn sàng là các yêu c ầu giám

sát theo thời gian thực đối với các thành ph ần và dịch vụ CNTT. Để
đạt được m ức độ sẵn sàng c ần thiết và/hoặc đảm bảo việc khôi phục
dịch vụ nhanh chóng sau m ột lỗi của CNTT đòi h ỏi sự đầu tư và khai
thác m ột bộ công c ụ quản lý hệ thống. Các công c ụ quản lý hệ thống
là những khối cơ s ở thiết yếu cho các dịch vụ CNTT, cần thiết cho
m ột m ức sẵn sàng cao và có th ể cung cấp vai trò vô giá trong vi ệc
giảm thiểu tổng thời gian gián đo ạn đã xảy ra. Các yêu c ầu Quản lý
Tính sẵn sàng bao hàm c ả việc nhận diện lẫn cảnh báo về các ngoại
lệ của dịch vụ và thành phần CNTT, các leo thang t ự động hóa và
thông báo về lỗi CNTT và t ự động khôi phục và phục hồi các thành
phần từ những tình hu ống lỗi CNTT đã bi ết. Điều này khiến cho vi ệc
xác định nơi ‘thời gian bị m ất’ và cung cấp cơ sở cho sự xác định
các yếu tố có thể cải thiện thời gian khôi ph ục và phục hối trở nên
khả thi. Những hoạt động này được tiến hành trên cơ s ở định k ỳ
trong Vận hành Dịch vụ.
Phân tích Lỗi Dịch vụ

Phân tích Lỗi Dịch vụ (SFA) là m ột kỹ thuật được thiết kế để cung
cấp m ột phương pháp ti ếp cận có cấu trúc để xác định những
nguyên nhân cơ b ản của sự gián đoạn dịch vụ đối với người sử
dụng. SFA sử dụng m ột loạt các nguồn dữ liệu để đánh giá vị trí và
lý do vì sao tình tr ạng thiếu hụt về tình trạng sẵn sàng lại xảy ra.
SFA cho phép m ột cái nhìn toàn diện được đưa ra để thúc đẩ y
không chỉ các cải tiến về m ặt công ngh ệ m à còn các cải tiến đối với
tổ chức, quy trình, thủ tục và công c ụ hỗ trợ CNTT. SFA ho ạt động
như m ột nhiệm vụ hoặc m ột dự án, và có th ể sử dụng các phương
pháp và k ỹ thuật Quản lý Tính sẵn sàng khác để định hình những
khuyến nghị cải tiến. Những phân tích chi ti ết về gián đoạn dịch vụ
có thể xác định các cơ hội để tăng cường m ức độ của tính sẵn sàng.

186
SFA là m ột kỹ thuật có cấu trúc để xác định những cơ hội cải thiện
trong tính sẵn sàng dịch vụ từ đầu-đến-cuối có thể cung c ấp lợi ích
cho người sử dụng. Rất nhiều hoạt động liên quan đ ến SFA đư ợc
liên kết m ột cách ch ặt chẽ với những gì c ủa Quản lý Vấn đề, và
trong m ột số tổ chức, những hoạt động này được hoàn thành b ởi sự
kết hợp giữa Quản lý Vấn đề và Quản lý Tính s ẵn sàng.
Mục tiêu c ấp-cao c ủa SFA là:
 Cải thiện tính s ẵn sàng t ổng thể của các dịch vụ CNTT bằng
cách đưa ra m ột bộ các cải tiến đề triển khai hoặc là đầu vào
cho Kế hoạch về Tính sẵn sàng.
 Xác định các nguyên nhân cơ b ản của sự gián đoạn của dịch
vụ đối với người sử dụng.
 Đánh giá tính hi ệu quả của tổ chức hỗ trợ CNTT và các quy
trình chủ yếu.
 Đưa ra các báo cáo chi ti ết về những vấn đề tìm thấy và
những khuyến nghị chính.
 Những cải thiện về tính sẵn sàng có ngu ồn gốc từ hoạt động
thúc đấy-SFA được đo lường.
Các sáng ki ến SFA nên s ử dụng đầu vào từ m ọi lĩnh vực và m ọi quy
trình bao gồm , quan trọng nhất, doanh nghi ệp và người sử dụng.
Mỗi nhiệm vụ SFA nên có (các) nhà tài tr ợ đã được công nh ận (lý
tưởng là sự đồng tài trợ từ CNTT và doanh nghi ệp) và liên quan đến
những nguồn lực từ rất nhiều lĩnh vực quy trình và k ỹ thuật. Việc sử
dụng phương pháp tiếp cận SFA:
 Cung cấp khả năng cung c ấp các m ức độ về tính s ẵn sàng

được tăng cường mà không có chi phí l ớn đáng kể.
 Cung cấp cho doanh nghiệp cam kết rõ ràng từ tổ chức hỗ trợ
CNTT.
 Phát triển những kỹ năng và năng l ực nội bộ để tránh các
nhiệm vụ tư vấn tốn kém liên quan đến cải thiện tính s ẵn sàng.
 Khuyến khích làm vi ệc nhóm đa-chức năng và phá v ỡ những
rào cản giữa các nhóm , và là y ếu tố thúc đẩy tư duy ngoại
biên, thách thức kiểu tư duy truyền thống và đem lại các gi ải
pháp, thường là không t ốn kém , đổi m ới sáng t ạo.
 Cung cấp m ột chương trình g ồm các cơ h ội cải thiện có thể
tạo ra sự khác biệt thực sự trong chất lượng dịch vụ và nhận
thức của người sử dụng.
 Cung cấp các cơ h ội được tập trung vào việc m ang lại lợi ích
cho người sử dụng.
 Cung cấp m ột ‘kiểm tra sức khỏe’ độc lập đối với các quy trình
Quản lý Dịch vụ CNTT và là yếu t ố kích thích các cải tiến quy
trình.
Để tối đa hóa c ả thời gian c ủa các cá nhân được phân b ổ cho

nhiệm vụ SFA lẫn chất lượng của các báo cáo được cung cấp, m ột
phương pháp ti ếp cận có cấu trúc là cần thiết. Cấu trúc này được
m inh họa trong Hình 4.16. Phương pháp ti ếp cận này tương t ự như

187
rất nhiều m ô hình tư v ấn đã được sử dụng trong ngành, và rất nhiề u
cách Quản lý Tính s ẵn sàng có thể được xem là cung c ấp thông qua
SFA, m ột hình thức tư vấn nội bộ.
Hình 4.16 – Phương pháp ti ếp cận có câu trúc đ ối với Phân tích
Lỗi Dịch vụ (SFA)
Những cấu trúc cấp-cao nói trên được m ô tả m ột cách ngắn gọn như
dưới đây:
 Lựa chọn cơ hội: trước khi lập lịch trình cho m ột nhiệm vụ
SFA, cần có thỏa thuận về dịch vụ hoặc công nghệ CNTT nào
sẽ được lựa chọn. Chúng tôi khuy ến nghị rằng m ột con s ố
được thỏa thuận về các nhiệm vụ được lập lịch trình m ỗi năm
trong Kế hoạch về Tính sẵn sàng và, nếu có thể, các dịch vụ
CNTT được lựa chọn trước như là m ột phần của phương pháp
tiếp cận chủ động đối với Quản lý Tính s ẵn sàng. Trư ớc khi
bắt đầu với SFA, đi ều quan tr ọng là nhi ệm vụ đã có m ột nhà
bảo trợ được công nhận trong t ổ chức CNTT và/hoặc doanh
nghiệp và r ằng họ có liên quan và đư ợc cập nhật thường
xuyên về tiến trình của hoạt động SFA. Điều này đảm bảo khả
năng m inh b ạch của tổ chức đối với SFA và đảm bảo các
khuyến nghị được xác nhận ở cấp cao trong t ổ chức.

188
 Phạm vi nhiệm vụ: điều này là nh ằm tuyên bố m ột cách rõ
ràng về những lĩnh vực được và không được bao hàm trong
nhiệm vụ. Điều này thường được lập thành văn b ản trong Các
điều khoản tham chi ếu trước nhiệm vụ.
 Lên kế hoạch nhi ệm vụ: nhiệm vụ SFA cần được lập kế
hoạch trước khi bắt đầu nhiệm vụ m ột vài tuần, với m ột kế
hoạch dự án được thỏa thuận và m ột bộ tài nguyên được cam
kết. Dự án nên xem xét vi ệc xác định các cơ h ội cải thiện có
lợi đối với người sử dụng. Do đó, đi ều quan trọng là đưa ra
được m ột quan điểm từ đầu-đến-cuối về các yêu c ầu về dữ
liệu và Hệ thống Thông tin Qu ản lý (MIS). Dữ liệu và tài li ệu
nên được thu thập từ m ọi lĩnh vực và được phân tích t ừ cả
quan điểm người sử dụng lẫn quan đi ểm doanh nghi ệp. Một
nhóm SFA ‘ảo’ nên được hình thành t ừ m ọi lĩnh vực có liên
quan để đảm bảo rằng m ọi khía c ạnh và quan điểm đều được
cân nhắc. Quy m ô của nhóm này nên ph ản ảnh được phạm vi
và độ phức t ạp của nhiệm vụ SFA.
 Xây dựng giả thuyết: đây là m ột phương pháp hữu ích để xây
dựng các k ịch bản có khả năng xảy ra, có thể giúp cho nhóm
nghiên cứu có thể rút ra kết luận từ sớm trong giai đoạn phân
tích. Những kịch bản này có thể được xây dựng t ừ việc thảo
luận về những nhiệm vụ sắp tới với các vai trò chính, ví d ụ
như quản lý c ấp cao và người sử dụng, hoặc bằng cách sử
dụng các phiên hoạch định để tổng hợp m ột danh sách các gi ả
thuyết từ nhóm được tập hợp. Danh sách các gi ả thuyết được
hoàn chỉnh nên đư ợc lập thành văn b ản và là đầu vào cho giai
đoạn phân tích đ ể sớm tập trung vào dữ liệu và Hệ thống
Thông tin Q uản lý (MIS) khớp với các tình hu ống riêng l ẻ. Nên
lưu ý rằng phương pháp ti ếp cận này cũng lo ại bỏ các vấn đề
nhận thức, nghĩa là không có d ữ liệu hoặc MIS m inh ch ứng
cho những gì được nhận thức là m ột vấn đề dịch vụ.
 Phân tích dữ liệu: số lượng các cá n hân hình thành nên nhóm
SFA quyết định cách thức phân bổ trách nhiệm phân tích c ụ
thể. Trong su ốt giai đoạn phân tích, danh sách các gi ả thuyết
nên được sử dụng để giúp rút ra các k ết luận từ sớm .
 Phỏng vấn những nhân sự chủ chốt: m ột điều thiết yếu là
các đại diện doanh nghi ệp và những người sử dụng được
phỏng vấn để đảm bảo rằng những quan đi ểm doanh nghi ệp và
quan điểm người dùng được nắm bắt. Một điều đáng ng ạc
nhiên là làm thế nào cuộc đối thoại này có th ể xác định những
cơ hội chiến thắng nhanh chón g, thường là những gì doanh
nghiệp coi là m ột vấn đề lớn có thể được giải quyết bởi m ột
giải pháp CNTT đơn gi ản. Do đó, những cuộc phỏng vấn này
nên khởi đầu càng sớm càng tốt trong tác vụ SFA. Nhóm
nghiên c ứu nên tìm kiếm đầu vào từ các cá nhân ch ủ chốt
trong t ổ chức cung cấp dịch vụ CNTT để xác định những lĩnh
vực vấn đề bổ sung và những giải pháp tiềm năng có th ể phản
hồi lại cho nhóm nghiên c ứu. Cuộc đối thoại cũng giúp nắm
bắt những vấn đề không dễ nhìn thấy từ các báo cáo MIS và
dữ liệu đã được tổng hợp.

189
 Các phát hi ện và kết luận: sau khi phân tích d ữ liệu và MIS
đã cung c ấp, các cuộc phỏng vấn và điều chỉnh liên tục danh
sách giả thuyết, nhóm nghiên c ứu nên bắt đầu ghi nh ận lại
những phát hiện và kết luận ban đầu. Chúng tôi khuy ến nghị
rằng nhóm nghi ên cứu nên họp ngay sau giai đoạn phân tích
để chia sẻ những phát hiện riêng l ẻ của họ và sau đó đưa ra
m ột cái nhìn t ổng hợp để hình thành dự thảo về những phát
hiện và k ết luận. Điều quan trọng là m ọi phát hiện có thể được
chứng m inh bằng các dữ kiện thu thập được trong quá trình
phân tích. Trong giai đo ạn này của nhiệm vụ (SFA), có th ể cần
phải xác m inh (các) phát hi ện bằng cách phân tích bổ sung để
đảm bảo rằng nhóm SFA có thể sao lưu m ọi phát hi ện cùng
với các bằng chứng được lập thành văn bản rõ ràng.
 Khuyến nghị: sau khi m ọi phát hiện và k ết luận đã được xác
m inh, nhóm SFA nên chu ẩn bị để xây dựng các khuyến nghị.
Trong rất nhiều trường hợp, các khuyến nghị hỗ trợ m ột phát
hiện cụ thể là đơn giản và rõ ràng. Tuy nhiên, l ợi ích c ủa việc
m ang m ột nhóm đa-chức năng lại cùng với nhau cho nhi ệm vụ
SFA là để tạo ra m ột m ôi trường cho các phương pháp ti ếp
cận tư duy ngo ại biên đổi m ới. Trưởng nhóm nhi ệm vụ SFA
nên tạo điều kiện cho phiên làm vi ệc này với m ục tiêu xác định
các khuyến nghị mang tính thi ết thực và bền vững sau khi đã
được triển khai.
 Báo cáo: báo cáo sau cùng nên đư ợc đệ trình cho nhà bảo trợ
cùng với m ột tóm tắt về m ặt quản lý. Kiểu báo cáo thư ờng
được xác định bởi các tổ chức riêng l ẻ. Điều quan trọng là báo
cáo phải trình bày m ột cách rõ ràng về nơi m à tổn thất về tính
sẵn sàng xảy ra và các khuy ến nghị giải quyết điều này như
thế nào. Nếu báo cáo bao gồm nhiều khuyến nghị, m ột nỗ lực
nên được đưa ra đ ể định lượng lợi ích c ủa từng khuyến nghị,
cùng với nỗ lực được ước tính dành cho việc triển khai. Điều
này cho phép những lựa chọn sáng suốt được thực hiện về
việc làm thế nào thúc đẩy những khuyến nghị về phía trư ớc và
các khuyến nghị này nên đư ợc ưu tiên và cung c ấp nguồn lực
như thế nào.
 Xác minh: chúng tôi khuy ến nghị rằng với m ỗi SFA, thước đo
chính phản ảnh các quan điểm của doanh nghiệp và ngư ời sử
dụng trước khi bắt đầu nhiệm vụ nên được nắm bắt và ghi
nhận lại như là quan đi ểm ‘trước’. Khi nh ững khuyến nghị SFA
được tiến hành, nh ững tác động tích cực lên tính sẵn sàng
nên được nắm bắt để cung cấp m ột quan điểm ‘sau’ cho m ục
đích so sánh. Khi m à nh ững lợi ích được dự báo trước đã
không được cung c ấp, việc này nên được tìm hiểu và đưa ra
các hành đ ộng khắc phục. Khi đã đ ầu tư công sức và thời
gian để hoàn thành nhi ệm vụ SFA, điều quan trọng là các
khuyến nghị, m ột khi đã được thỏa thuận bởi nhà bảo trợ, sau
đó sẽ được đưa ra để triển khai. Có ch ế tốt nhất để đạt được
điều này là b ằng cách k ết hợp các khuyến nghị như là các
hoạt động cần được hoàn thành trong K ế hoạch về Tính sẵn
sàng hoặc trong SIP tổng thể. Sự thành công c ủa nhiệm vụ

190
SFA nói chung nên đư ợc giám sát và đo lư ờng để đảm bảo
tính hiệu quả liên t ục của nó.
Xem xét vi ệc phân lo ại các khuyến nghị theo các tiêu đ ề dưới
đây:
NHẬN DIỆN: Các khuyến nghị, nếu được triển khai, s ẽ mang lại
các báo cáo được tăng cường về các chỉ số chính để đảm bảo
các vấn đề dịch vụ CNTT cơ bản được phát hiện sớm nhằm cho
phép ứng phó ch ủ động.
GIẢM THIỂU: Các khuyến nghị, nếu được triển khai, s ẽ làm giảm
thiểu hoặc tối thiếu hóa tác đ ộng đối với người sử dụng của việc
gián đoạn dịch vụ CNTT, ví dụ: khôi phục và/hoặc phục hồi có
thể được tăng cường để giảm thời lượng của tác động.
TRÁNH: Các khuy ến nghị, nếu được triển khai, sẽ loại trừ những
nguyên nhân c ụ thể gây ra gián đo ạn dịch vụ CNTT.
4.4.5.2 Các hoạt động chủ động của Quản lý Tính sẵn sàng
Năng lực của quy trình Qu ản lý Tính s ẵn sàng chịu ảnh hưởng tích
cực từ phạm vi và chất lượng của các phương pháp và k ỹ thuật chủ
động được sử dụng bởi quy trình. Những hoạt động dưới đây là
những hoạt động và k ỹ thuật chủ động của quy trình Qu ản lý Tính
sẵn sàng.
Xác định các Chứ c năng Nghiệp vụ Sống còn (VBF)

Thuật ngữ Chức năng Nghi ệp vụ Sống còn – Vital Business Function
(VBF) được sử dụng để phản ảnh những yếu tố nghiệp vụ quan
trọng của quy trình nghiệp vụ được hỗ trợ bởi m ột dịch vụ CNTT.
Dịch vụ cũng có th ể hỗ trợ cho các quy trình và ch ức năng nghiệp vụ
kém quan tr ọng hơn, và đi ều quan tr ọng là các VBF đư ợc nhận biết
và được lập thành văn b ản để m ang lại sự liên kết và tập trung kinh
doanh tương xứng.
Thiết kế dành cho tính sẵn sàng

Mức độ tính sẵn sàng c ần thiết bởi doanh nghi ệp ảnh hưởng tới chi
phí tổng thể của dịch vụ CNTT được cung c ấp. Nói chung, m ức độ
tính sẵn sàng c ần thiết càng cao thì chi phí càng cao. Chi phí không
chỉ là việc m ua sắm công nghệ CNTT cơ sở và các dịch vụ cần thiết
để làm nền tảng cho cơ sở hạ tầng CNTT. Các chi phí b ổ sung còn
phát sinh trong việc cung c ấp các quy trình Quản lý Dịch vụ tương
ứng, các công c ụ quản lý hệ thống và các giải pháp tính sẵn sàng
cao cần thiết để đáp ứng các yếu cầu nghiêm ngặt về tính sẵn sàng.
Mức độ tính sẵn sàng cao nh ất nên đư ợc bao gồm trong thi ết kế của
các dịch vụ hỗ trợ cho các VBF quan tr ọng nhất.

191
Khi xem xét cách mà các yêu c ầu về tính sẵn sàng s ẽ được đáp ứng
như thế nào, điều quan tr ọng là phải đảm bảo rằng m ức độ sẵn sàng
sẽ được cung c ấp đối với m ột dịch vụ CNTT là m ức độ cần thiết
thực tế, và có giá cả phải chăng và hợp lý về chi phí với doanh
nghiệp. Hình 4.17 ch ỉ ra các sản phẩm và quy trình c ần thiết để
cung cấp m ức độ sẵn sàng khác nhau và tác đ ộng chi phí.
Hình 4.17 – Mối quan hệ giữa các mức độ sẵn sàng và chi phí
tổng thể
Sản phẩm và các thành ph ần cơ bản

Việc m ua sắm hoặc phát tri ển các sản phẩm , công ngh ệ và thành
phần cơ bản nên dựa trên năng l ực của chúng để đáp ứng các yếu
cầu nghiêm ngặt về tính sẵn sàng và độ tin cậy. Chúng nên được
xem là nền tảng của thiết kế về tính sẵn sàng. Khoản đầu tư bổ
sung cần thiết để đạt được m ức độ sẵn sàng thậm chí cao hơn n ữa
sẽ bị lãng phí và các m ức độ sẵn sàng không đưu ọc đáp ứng nếu
như những sản phẩm và thành phần cơ bản này không đáng tin c ậ y
và dễ bị lỗi.
Quản lý hệ thống
Quản lý hệ thống nên cung c ấp sự giám sát, chẩn đoán và t ự động
khôi phục lỗi để cho phép nhận diện và giải quyết nhanh chóng
những lỗi tiềm năng và l ỗi thực tế trong CNTT.
Các quy trình Qu ản lý Hệ thống

192
Các quy trình Quản lý Hệ thống hiệu quả góp phần vào việc có đượ c
m ức độ sẵn sàng cao. Những quy trình như Qu ản lý Tính sẵn sàng,
Quản lý Sự cố, Quản lý Vấn đề, Quản lý Thay đ ổi, Quản lý Cấu hình,
v.v… đóng vai trò quan tr ọng trong qu ản lý t ổng thể dịch vụ CNTT.
Thiết kế sẵn sàng-cao

Thiết kế tính sẵn sàng cao cần xem xét việc loại bỏ các SpoF
và/hoặc cung cấp các thành ph ần thay thể để tối thiểu sự gián đoạn
đối với hoạt động kinh doanh n ếu xảy ra lỗi thành phần CNTT. Thiết
kế cũng cần loại bỏ hoặc tối thiểu tác động của thời gian ngừng hoạt
động đã được lập kế hoạch đối với hoạt động kinh doanh thông
thường, cần thiết để thích ứng với các hoạt động bảo trì, triển khai
những thay đổi đối với cơ sở hạ tầng CNTT ho ặc ứng dụng nghiệp
vụ. Các tiêu chí khôi ph ục nên xác định khôi ph ục và phục hồi nhanh
chóng dịch vụ CNTT là m ột m ục tiêu chủ yếu trong việc thiết kế giai
đoạn khôi phục của thiết kế.
Các giải pháp đặc biệt với dự phòng đầy đủ

Để tiếp cận tính s ẵn sàng liên tục trong ph ạm vi 100% đòi hỏi các
giải pháp đắt tiền kết hợp từ phản chiếu toàn thể hoặc dự phòng đầ y
đủ. Dự phòng là m ột kỹ thuật cải thiện tính sẵn sàng bằng cách s ử
dụng các thành ph ần được nhân bản. Để đáp ứng các yêu c ầu về
tính sẵn sàng nghiêm ngặt, chúng c ần phải hoạt động song song
với nhau m ột cách độc lập. Những giải pháp này không ch ỉ giới hạn
trong các thành ph ần CNTT m à còn trong m ôi trư ờng CNTT, nghĩa là
trung tâm dữ liệu, nguồn cung cấp điện, điều hòa không khí và vi ễ n
thông.
Khi các dịch vụ CNTT m ới đang đư ợc phát tri ển, điều thiết yếu là
Quản lý Tính s ẵn sàng phải đóng vai trò và tham gia v ào thiết k ế
sớm trong việc xác định các yêu c ầu về tính sẵn sàng. Đi ều này cho
phép Quản lý Tính sẵn sàng có ảnh hưởng tích cực đến thiết kế cơ
sở hạ tầng CNTT đ ể đảm bảo rằng nó có th ể cung cấp mức độ sẵn
sàng cần thiết. Tầm quan trọng của việc tham gia sớm vào vi ệc thiết
kế cơ sở hạ tầng CNTT không th ể bị đánh giá th ấp. Cần có m ột cuộc
đối thoại giữa CNTT và doanh nghi ệp để xác định sự cân bằng giữa
nhận thức của doanh nghi ệp về chi phí c ủa sự không sẵn sàng và
chi phí theo c ấp số nhân của việc cung c ấp m ức độ sẵn sàng cao
hơn.
Như m inh họa trong Hình 4.17, có m ột sự gia tăng đáng k ể về chi
phí khi yêu c ầu kinh doanh cao hơn m ức độ sẵn sàng tối ưu m à cơ
sở hạ tầng CNTT có th ể đáp ứng. Những chi phí gia tăng này là do
sự tái thiết kế lại đáng k ể của công ng hệ và sự thay đổi các yêu cầu
đối với tổ chức hỗ trợ CNTT.
Điều quan trọng là m ức độ sẵn sàng của dịch vụ được thiết kế

tương xứng với nhu cầu kinh doanh, m ức độ quan trọng của các quy
trình nghiệp vụ đang được hỗ trợ và ngân sách s ẵn có. Doanh
nghiệp cần được tư vấn sớm trong vòng đời Thiết kế Dịch vụ để các
nhu cầu về tính sẵn sàng của doanh nghiệp đối với m ột dịch vụ

193
CNTT m ới hoặc nâng cao có th ể được định giá và th ỏa thuận. Điều
này đặc biệt quan trọng khi các yêu c ầu nghiêm ngặt về tính sẵn
sàng có thể đòi hỏi phải đầu tư thêm vào các quy trình Qu ản lý Dịch
vụ, các công c ụ Quản lý Hệ thống và Dịch vụ CNTT, thiết kế tính sẵn
sàng cao và các gi ải pháp đặc biệt với dự phòng đầy đủ.
Có khả năng là nhu c ầu của doanh nghi ệp về tính sẵn sàng củ a

CNTT không th ể diễn đạt được bằng thuật ngữ kỹ thuật. Do đó,
Quản lý Tính s ẵn sàng cung cấp m ột vai trò quan tr ọng trong vi ệc có
khả năng chuyển các yêu c ầu của doanh nghiệp và người sử dụng
thành các đích nh ắm m ục tiêu và đi ều kiện về tính sẵn sàng có th ể
định lượng được. Đây là m ột đầu vào quan tr ọng đối với Thiết kế
Dịch vụ CNTT và cung c ấp cơ sở để đánh giá năng l ực của t ổ chức
thiết kế CNTT và h ỗ trợ CNTT trong việc đáp ứng các yêu c ầu về
tính sẵn sàng c ủa doanh nghi ệp.
Các yêu cầu của doanh nghi ệp đối với tính s ẵn sàng của CNTT ph ải
có ít nhất:
 Định nghĩa về VBF được hỗ trợ bởi dịch vụ CNTT,

 Định nghĩa về thời gian ngừng hoạt động của dịch vụ CNTT,
tức là các đi ều kiện m à doanh nghi ệp coi dịch vụ CNTT là
không s ẵn sàng,
 Tác động kinh doanh do t ổn thất dịch vụ, cùng với rủi ro liên
quan,
 Các yêu c ầu định lượng về tính sẵn sàng, tức là m ức độ m à
doanh nghiệp có thể chịu được thời gian ngừng hoạt động của
dịch vụ CNTT hoặc dịch vụ bị suy thoái,
 Giờ phục vụ bắt buộc, tức là khi dịch vụ đang được cung c ấp,
 Một đánh giá về tầm quan trọng tương đối của các giai đo ạn
hoạt động khác nhau,
 Các yêu c ầu bảo mật cụ thể,
 Khả năng sao lưu và ph ục hồi dịch vụ.
Một khi thiết kế công nghệ CNTT và t ổ chức hỗ trợ CNTT đã được
xác định, tổ chức cung cấp dịch vụ sẽ chuẩn bị để xác nhận xem có
thể đáp ứng các yêu cầu về tính sẵn sàng hay không. Khi s ự thiếu
hụt được xác định, cuộc đối thoại với doanh nghiệp là cần thiết để
trình bày các lựa chọn chi phí hiện có nhằm nâng cao thiết kế đề
xuất nhằm đáp ứng các yêu c ầu về tính sẵn sàng. Điều này cho
phép doanh nghiệp đánh giá lại nếu yêu cầu về m ức độ sẵn sàng
thấp hơn hoặc cao hơn là c ần thiết, đồng thời hiểu được tác động
tương xứng và chi phí liên quan đ ến quyết định của họ.
Việc xác định các yêu c ầu về tính sẵn sàng có th ể là m ột quá trình
lặp đi lặp lại, đặc biệt khi cần phải cân bằng giữa yêu c ầu về tính
sẵn sàng c ủa doanh nghi ệp với các chi phí liên quan. Các bư ớc cần
thiết là:
 Xác định tác động kinh doanh gây ra do vi ệc m ất dịch vụ,

194
 Từ các yêu cầu nghiệp vụ, chỉ định các yêu c ầu về tính sẵn
sàng, độ tin cậy và khả năng có th ể bảo trì đối với dịch vụ
CNTT và các thành ph ần được hỗ trợ bởi tổ chức hỗ trợ
CNTT,
 Đối với các dịch vụ và thành ph ần CNTT được cung cấp bên
ngoài, hãy xác đ ịnh các yêu cầu về khả năng phục vụ,
 Ước tính các chi phí li ên quan đến việc đáp ứng các yêu c ầu
về tính sẵn sàng, đ ộ tin cậy, khả năng có thể bảo trì và kh ả
năng phục vụ,
 Cùng với doanh nghi ệp xác định xem liệu chi phí đã được xác
định để đáp ứng các yêu c ầu về tính sẵn sàng là hợp lý hay
không,
 Từ phía doanh nghiệp, xác định các chi phí có th ể phát sinh
do sự m ất m át hoặc suy thoái d ịch vụ.
 Khi những yêu c ầu này được xem là hợp lý về m ặt chi phí, hãy
xác định các yêu c ầu về tính sẵn sàng, độ tin cậy, khả năng có
thể bảo trì và kh ả năng phục vụ trong các th ỏa thuận và đàm
phán thành các hợp đồng.
Nếu chí phí bị xem là hạn chế, thì:

 Hoặc đánh giá l ại thiết kế cơ sở hạ tầng CNTT và cung c ấp
các lựa chọn để giảm chi phí và đánh giá nh ững hậu quả
đối với tính s ẵn sàng,
 Hoặc đánh giá l ại mức độ sử dụng và phụ thuộc của doanh
nghiệp vào dịch vụ CNTT và thương lư ợng lại về các đích
nhắm m ục tiêu về tính sẵn sàng trong SLA.
Quy trình SLM thư ờng chịu trách nhiệm cho việc giao tiếp đối với
doanh nghi ệp về cách các yêu cầu về tính sẵn sàng c ủa họ đối với
các dịch vụ CNTT được đáp ứng như thế nào và đàm phán SLR/SLA
cho quy trình Thi ết kế Dịch vụ CNTT. Do đó, Qu ản lý Tính sẵn sàng
cung cấp hỗ trợ và đầu vào quan tr ọng cho cả SLM và quy trình thi ết
kế trong suốt giai đo ạn này. Mặc dù m ức độ sẵn sàng cao hơn
thường có thể được cung c ấp bằng cách đầu tư thêm vào các công
cụ và công nghệ, không có lý do gì đ ể biện m inh cho vi ệc cung c ấp
m ức độ sẵn sàng cao hơn m ức cần thiết và cao hơn kh ả năng chi tr ả
của doanh nghi ệp. Thực tế là việc đáp ứng các yêu cầu về tính sẵn
sàng luôn là sự cân bằng giữa chi phí và ch ất lượng. Đây là nơi m à
Quản lý Tính sẵn sàng có thể đóng m ột vai trò quan trọng trong việc
tối ưu hóa tính s ẵn sàng của Thiết kế dịch vụ CNTT để đáp ứng nhu
cầu về tính sẵn sàng ngày càng tăng trong khi trì hoãn s ự gia tăng
về chi phí.
Thiết kế dịch vụ cho tính s ẵn sàng là m ột hoạt động chủ yếu được
định hướng bởi Quản lý Tính sẵn sàng. Điều này đảm bảo rằng m ức
độ sẵn sàng c ần thiết cho m ột dịch vụ CNTT có thể được đáp ứng.
Quản lý Tính s ẵn sàng cần đảm bảo rằng hoạt động thiết kế về tính
sẵn sàng s ẽ xem xét nhi ệm vụ từ hai quan đi ểm có liên quan, nhưng
khác biệt:

195
 Thiết kế để sẵn sàng: hoạt động này liên quan đ ến thiết kế k ỹ
thuật của dịch vụ CNTT và s ự liên k ết của các nhà cung c ấp
bên trong và bên ngoài c ần thiết để đáp ứng các yêu cầu về
tính sẵn sàng của doanh nghiệp. Nó c ần bao gồm tất cả các
khía cạnh c ủa công ngh ệ, bao gồm cơ sở hạ tầng, m ôi trư ờng,
dữ liệu và ứng dụng.
 Thiết kế để phục hồi: hoạt động này liên quan đ ến các đi ểm
thiết kế cần thiết để đảm bảo rằng trong trư ờng hợp m ột dịch
vụ CNTT bị lỗi, dịch vụ và các thành ph ần hỗ trợ của nó có thể
được phục hồi để cho phép các ho ạt động kinh doanh bình
thường được tiếp tục m ột cách nhanh nh ất có thể. Điều này
m ột lần nữa cần phải bao gồm tất cả các khía c ạnh của công
nghệ.
Ngoài ra, khả năng phục hồi m ột cách nhanh chóng có th ể là m ột

yếu tố quan trọng. Nói m ột cách đơn gi ản, có thể là không kh ả thi
hoặc tốn kém để xây dựng m ột thiết kế có khả năng phục hồi cao đối
với (các) lỗi. Khả năng đáp ứng các yêu cầu về tính sẵn sàng trong
các thông s ố chi phí có th ể dựa vào khả năng phục hồi m ột cách
nhất quán k ịp thời và hiệu quả. Tất cả các khía c ạnh của tính sẵ n
sàng cần được xem xét trong quy trình Thi ết kế Dịch vụ và nên xem
xét tất cả các giai đoạn trong Vòng đời Dịch vụ.
Sự đóng góp của Quản lý Tính s ẵn sàng trong các ho ạt động thiết kế
là cung cấp:
 Đặc tả kỹ thuật của các yêu c ầu về tính sẵn sàng cho t ất cả

các thành phần của dịch vụ,
 Các yêu c ầu đối với các điểm đo lường tính s ẵn sàng (thi ết bị
đo đạc),
 Các yêu cầu đối với hệ thống m ới/được nâng cao và đ ối với
Quản lý Dịch vụ,
 Hỗ trợ thiết kế cơ sở hạ tầng CNTT,
 Đặc tả kỹ thuật của các yêu cầu về độ tin cậy, khả năng bảo
trì và khả năng phục vụ đối với các thành ph ần được cung cấp
bởi các nhà cung c ấp bên trong và bên ngoài,
 Thẩm định thiết kế cuối cùng để đáp ứng m ức độ sẵn sàng t ối
thiểu được yêu cầu bởi doanh nghi ệp đối với dịch vụ CNTT.
Nếu không thể đáp ứng các yêu cầu về tính sẵn sàng, nhi ệm vụ tiếp
theo là đánh giá l ại Thiết kế Dịch vụ và xác định các thay đổi thiết
kế hợp lý về chi phí. Những cải tiến trong thiết kế để đáp ứng các
yêu cầu về tính sẵn sàng có th ể đạt được bằng cách xem xét kh ả
năng của công ngh ệ sẽ được triển khai trong thi ết kế CNTT được đề
xuất. Ví dụ:
 Việc khai thác công ngh ệ có khả năng chịu lỗi để che giấu tác
động của thời gian ngừng hoạt động của thành ph ần dù là
được hay không đư ợc lập kế hoạch,

196
 Song lập, hoặc cung c ấp các thành ph ần cơ sở hạ tầng CNTT
thay thế để cho phép m ột thành ph ần tiếp quản công vi ệc của
thành phần khác,
 Cải thiện độ tin cậy của thành ph ần bằng cách tăng cư ờng các
chế độ kiểm tra,
 Cải thiện thiết kế và phát triển phần m ềm,
 Cải tiến các quy trình và th ủ tục,
 Cải tiến/khai thác quản lý hệ thống,
 Cải thiện các dịch vụ, hợp đồng hoặc thỏa thuận được cung
cấp bên ngoài,
 Phát triển năng l ực của con ngư ời bằng cách đào t ạo nhiều
hơn.
Hãy xem xét việc ghi nhận lại các yêu cầu thiết kế về tính s ẵn
sàng và các cân nh ắc đối với các dịch vụ CNTT m ới và làm cho
chúng trở nên s ẵn có đối với thiết kế và triển khai các ch ức
năng. Về lâu dài, hãy tìm cách b ắt buộc các yêu c ầu này và tích
hợp trong các cơ chế quản trị thích hợp bao gồm việc giới thiệu
các dịch vụ CNTT m ới.
Một phần của hoạt động thiết kế đối với tính sẵn sàng phải đảm bảo
rằng tất cả các yêu cầu kinh doanh, dữ liệu và bảo m ật thông tin đ ều
được kết hợp trong Thi ết kế Dịch vụ. Mục tiêu t ổng thể của bảo m ật
CNTT là ‘bảo m ật được cân bằng theo chiều sâu’, với các biện pháp
kiểm soát hợp lý được triển khai để đảm bảo rằng Chính sách B ảo
m ật Thông tin đư ợc thực thi và các d ịch vụ CNTT vẫn nằm trong các
thông số bảo m ật (tức là tính b ảo m ật, tính toàn vẹn và tính sẵn
sàng) tiếp tục hoạt động. Trong suốt quá trình thu thập các yêu c ầu
về tính sẵn sàng cho các d ịch vụ CNTT m ới, điều quan trọng là các
yêu cầu bao gồm bảo m ật CNTT phải được xác định. Các yêu c ầu
này cần được áp dụng trong suốt giai đoạn thiết kế đối với công
nghệ hỗ trợ. Với nhiều tổ chức, phương pháp ti ếp cận được thực
hiện để bảo m ật CNTT được bao hàm bởi Chính sách B ảo m ật
Thông tin được sở hữu và duy trì bởi Quản lý Bảo m ật Thông tin.
Trong việc thực thi chính sách b ảo m ật, Quản lý Tính s ẵn sàng đóng
m ột vai trò quan tr ọng trong ho ạt động của nó đối với các dịch vụ
CNTT m ới.
Trong trường hợp hoạt động kinh doanh ph ụ thuộc nhiều vào tính
sẵn sàng của dịch vụ CNTT và chi phí c ủa việc thất bại hoặc m ất uy
tín doanh nghiệp được coi là không thể chấp nhận được, doanh
nghiệp có thể xác định các yêu c ầu nghiêm ngặt về tính sẵn sàng.
Các yếu tố này có thể đủ để doanh nghiệp biện m inh cho các chi phí
bổ sung cần thiết để đáp ứng các m ức độ sẵn sàng khắt khe hơn
này. Việc đạt được m ức độ sẵn sàng đã thỏa thuận bắt đầu bằng
việc thiết kế, m ua sắm và/hoặc phát tri ển các sản phẩm và thành
phần có chất lượng cao. Tuy nhiên, nh ững điều biệt lập này không
có khả năng cung c ấp m ức độ sẵn sàng b ền vững cần thiết. Để đạt
được m ức độ sẵn sàng nh ất quán và b ền vững đòi hỏi phải đầu tư

197
và triển khai các quy trình Qu ản lý Dịch vụ hiệu quả, các công c ụ
quản lý hệ thống, thiết kế tính sẵn sàng cao và cu ối cùng là các gi ải
pháp đặc biệt với phản chiếu hoặc dự phòng đầy đủ.
Việc thiết kế tính s ẵn sàng là m ột hoạt động quan tr ọng, được định
hướng bởi Quản lý Tính sẵn sàng, điều này đảm bảo rằng các yêu
cầu về tính sẵn sàng đã tuyên bố cho m ột dịch vụ CNTT có th ể được
đáp ứng. Tuy nhiên, Qu ản lý Tính sẵn sàng cũng ph ải đảm bảo rằng
hoạt động thiết kế này tập trung vào các y ếu tố thiết kế cần thiết để
đảm bảo rằng khi dịch vụ CNTT bị lỗi, dịch vụ có thể được khôi ph ục
để cho phép ho ạt động kinh doanh bình thư ờng tiếp tục m ột cách
nhanh nhất có thể. Lúc đầu, ‘thiết kế để phục hồi’ có thể nghe có v ẻ
tiêu cực. Rõ ràng thi ết kế tính sẵn sàng tốt là tránh được các l ỗi và
cung cấp, nếu có thể, m ột cơ sở hạ tầng CNTT có kh ả năng chịu lỗi.
Tuy nhiên, với trọng tâm này là sự phụ thuộc quá nhiều vào công
nghệ và có t ập trung nhi ều vào khía cạnh chịu lỗi của cơ sở hạ tầng
CNTT không? Th ực tế là những thất bại sẽ vẫn xảy ra. Cách t ổ chức
CNTT quản lý các tình hu ống thất bại có thể có tác động tích cực
đến nhận thức của doanh nghi ệp, khách hàng và ngư ời sử dụng dịch
vụ CNTT.
Mọi thất bại đều là m ột "khoảnh khắc của sự thật" quan trọng -
m ột cơ hội để tạo nên hoặc phá vỡ danh tiếng của bạn với doanh
nghiệp.
Bằng cách cung c ấp trọng tâm vào các khía c ạnh ‘thiết kế để phục
hồi’ của tính sẵn sàng tổng thể, thiết kế có thể đảm bảo rằng m ọi
thất bại đều là cơ hội để duy trì và th ậm chí nâng cao s ự hài lòng
của người dùng và doanh nghi ệp. Để cung c ấp m ột 'thiết kế để khôi
phục' hiệu quả, điều quan trọng là ph ải nhận ra rằng cả doanh
nghiệp lẫn tổ chức CNTT đều có những nhu c ầu phải được đáp ứng
để cho phép m ột khôi phục hiệu quả sau lỗi CNTT. Đây là nh ững
nhu cầu về thông tin m à doanh nghi ệp đòi hỏi để giúp họ quản lý tác
động của thất bại đối với hoạt động kinh doanh c ủa họ và đặt kỳ
vọng trong doanh nghi ệp, cộng đồng người dùng và khá ch hàng
doanh nghiệp của họ. Đây là những kỹ năng, kiến thức, quy trình,
thủ tục và công c ụ cần thiết để cho phép vi ệc phục hồi kỹ thuật
được hoàn thành trong m ột khoảng thời gian t ối ưu.
Hãy xem xét vi ệc lập hồ sơ các yêu c ầu thiết kế khôi phục và các
cân nhắc cho các d ịch vụ CNTT m ới và cung c ấp chúng cho các
lĩnh vực chịu trách nhi ệm thiết kế và triển khai. V ề lâu dài, hãy
tìm cách ủy thác các yêu c ầu này và tích hợp chúng trong các cơ
chế quản trị thích hợp bao gồm việc giới thiệu các dịch vụ CNTT
mới.
Mục đích chính là đ ể ngăn ngừa những sự cố không đáng kể trở nên
nghiêm trọng bằng cách đ ảm bảo những người phù hợp tham gia đ ủ
sớm để tránh m ắc sai lầm và đảm bảo các thủ tục phục hồi kỹ thuật

198
và nghiệp vụ thích hợp được đưa ra s ớm nhất có thể. Việc thúc đẩ y
các hoạt động này là trách nhi ệm của quy trình Qu ản lý Sự cố và là
vai trò của Bộ phận Dịch vụ. Để đảm bảo rằng các nhu cầu kinh
doanh được đáp ứng trong khi xảy ra các sự cố dịch vụ CNTT lớn và
để đảm bảo khôi phục tối ưu nhất, quy trình Quản lý sự cố và Bộ
phận Hỗ trợ Dịch vụ cần phải xác định và thực hiện các thủ tục hiệu
quả để đánh giá và qu ản lý t ất cả các sự cố.
Trên đây không ph ải là trách nhi ệm của Quản lý Tính S ẵn sàng.

Tuy nhiên, hiệu quả của quy trình Qu ản lý Sự cố và Bộ phận Dịch
vụ có thể ảnh hưởng m ạnh m ẽ đến giai đo ạn khôi phục tổng thể.
Việc sử dụng các phương pháp và k ỹ thuật Quản lý Tính s ẵn
sàng để tối ưu hóa hơn nữa việc khôi ph ục CNTT có th ể là động
lực cho các ho ạt động cải tiến liên tục tiếp theo sau quy trình
Quản lý sự cố và Bộ phận Dịch vụ.
Để duy trì hiệu quả, khả năng có th ể bảo trì của các dịch vụ và
thành phần CNTT nên đư ợc giám sát và tác đ ộng của chúng đ ối với
‘vòng đời sự cố m ở rộng’ phải được hiểu, quản lý và c ải thiện.
Phân tích Tác động của Lỗi Thành phần

Phân tích Tác đ ộng của Lỗi Thành ph ần (Com ponent Failure Im pact
Analysis - CFIA) có thể được sử dụng để dự đoán và đánh giá tác
động đến dịch vụ CNTT phát sinh t ừ các lỗi thành ph ần trong công
nghệ. Đầu ra từ m ột CFIA có thể được sử dụng để xác định nơi m à
khả năng phục hồi bổ sung cần được xem xét đ ể ngăn ngừa hoặc
giảm thiểu tác động của lỗi thành phần đối với hoạt động kinh doanh
và đối với người dùng. Điều này đặc biệt quan trọng trong giai đo ạn
Thiết kế Dịch vụ, nơi cần phải dự đoán và đánh giá tác đ ộng đến
tính sẵn sàng c ủa dịch vụ CNTT phát sinh t ừ các lỗi thành ph ần
trong Thiết kế Dịch vụ CNTT được đề xuất. Tuy nhiên, k ỹ thuật này
cũng có thể được áp dụng cho các d ịch vụ và cơ sở hạ tầng hiện có.
CFIA là m ột kỹ thuật tương đối đơn giản có thể được sử dụng đ ể

cung cấp thông tin này. IBM đã phát m inh ra CFIA vào đ ầu những
năm 1970, với nguồn gốc của nó dựa trên thiết kế và cấu hình phần
cứng. Tuy nhiên, chúng tôi khuy ến cáo rằng CFIA nên được sử dụng
trong bối cảnh rộng hơn nhi ều để phản ánh toàn b ộ phạm vi c ủa cơ
sở hạ tầng CNTT, nghĩa là ph ần cứng, m ạng, phần m ềm , ứng dụng,
các trung tâm dữ liệu và nhân viên h ỗ trợ. Ngoài ra, k ỹ thuật này
cũng có thể được áp dụng để xác định tác động và sự phụ thuộc vào
các kỹ năng và năng l ực của tổ chức hỗ trợ CNTT giữa các nhân
viên hỗ trợ cho dịch vụ CNTT m ới. Hoạt động này thường được hoàn
thành cùng với ITSCM và có th ể là Quản lý Công su ất.
Đầu ra t ừ m ột CFIA cung c ấp những thông tin quan tr ọng để đảm

bảo rằng các tiêu chí thi ết kế để sẵn sàng và để khôi phục đối với
dịch vụ CNTT m ới được ảnh hưởng để ngăn ngừa hoặc tối thiểu hóa
tác động của lỗi đối với hoạt động của doanh nghiệp và đối với

199
người sử dụng. CFIA đ ạt được điều này bằng cách cung c ấp và ch ỉ
định:
 Các SpoF có th ể tác động đến tính s ẵn sàng,

 Tác động của các lỗi thành ph ần lên ho ạt động kinh doanh và
đối với người sử dụng,
 Thành phần và con người phụ thuộc,
 Thời gian khôi ph ục thành phần,
 Nhu cầu xác định và ghi nhận lại các lựa chọn khôi phục,
 Nhu cầu xác định và triển khai các bi ện pháp giảm thiểu rủi ro.
Những điều trên cũng có th ể cung cấp sự kích thích đầu vào cho
ITSCM để xem xét sự cân bằng giữa các tùy chọn khôi phục và các
biện pháp giảm thiểu rủi ro, tức là khi tác đ ộng kinh doanh tiềm ẩn
là cao và cần phải tập trung vào các bi ện pháp giảm thiểu rủi ro sẵn
sàng cao, t ức là khả năng phục hồi hoặc hệ thống dự phòng được
gia tăng.
Khi đã xác đ ịnh được cầu hình cơ s ở hạ tầng CNTT để được đánh
giá, bước đầu tiên là t ạo ra m ột lưới với các CI trên m ột trục và các
dịch vụ CNTT phụ thuộc vào CI trên tr ục kia, như được m inh họ a
trong Hình 4.18. Thông tin này nên có s ẵn từ CMS, hoặc thay vào
đó, nó có th ể được xây dựng bằng cách s ử dụng các biểu đồ cấu
hình và SLA đã đư ợc lập thành văn bản.
Hình 4.18 – Phân tích Tác động của Lỗi Thành phần
Bước tiếp theo là hoàn t ất CFIA và định vị trí của lưới như sau:

200
 Để trống nếu m ột lỗi của CI không tác động đến dịch vụ theo
bất kỳ cách nào.
 Chèn m ột chữ ‘X’ nếu lỗi của CI làm cho d ịch vụ không hoạt
động.
 Chèn m ột chữ ‘A’ khi có m ột CI thay thế để cung cấp dịch vụ.
 Chèn m ột chữ ‘M’ khi có m ột CI thay th ế nhưng dịch vụ đòi hỏi
sự can thiệp thủ công để được khôi phục.
Khi đã xây dựng được lưới, các CI có s ố lượng ‘X’ nhi ều sẽ là rất
quan tr ọng đối với nhiều dịch vụ và có th ể dẫn đến tác động lớn
nếu CI bị lỗi. Tương tự, các dịch vụ CNTT có s ố lượng ‘X’ nhiều rất
phức tạp và dễ bị tổn thương. Phương pháp ti ếp cận cơ bản này đối
với CFIA có thể cung cấp thông tin có giá tr ị trong việc xác định
nhanh chóng các SPoF, các d ịch vụ CNTT có nguy cơ thất bại do lỗi
của CI và những giải pháp thay th ế nào có s ẵn nếu CI bị lỗi. Phương
pháp này cũng nên đư ợc sử dụng để đánh giá sự tồn tại và xác m inh
các thủ tục khôi ph ục đối với các CI đã ch ọn. Ví dụ nói trên gi ả định
rằng cơ sở hạ tầng chung hỗ trợ cho nhiều dịch vụ CNTT. Phương
pháp tiếp cận tương tự có thể được sử dụng cho m ột dịch vụ CNTT
đơn lẻ bằng cách ánh xạ các CI thành ph ần với VBF và người dùng
được hỗ trợ bởi từng thành phần, do đó hiểu được tác động của lỗi
thành phần đối với doanh nghiệp và đối với người sử dụng. Phương
pháp tiếp cận này cũng có th ể được hoàn thi ện và phát triển hơn
nữa để bao gồm và phát tri ển các yếu tố ‘trọng số về tính sẵn sàng
của thành phần’ có thể được sử dụng để đánh giá và tính toán ảnh
hưởng tổng thể của lỗi thành ph ần đối với tổng số tính sẵn sàng của
dịch vụ.
Để đảm đương m ột CFIA nâng cao đòi h ỏi m a trận CFIA ph ải được

mở rộng để cung c ấp các trường bổ sung c ần thiết để phân tích chi
tiết hơn. Nó có th ể bao gồm các trường chẳng hạn như:
 Trọng số về tính sẵn sàng của thành phần: hệ số trọng số

tương xứng với tác động của sự cố của thành phần đối vớ i
tổng số tính s ẵn sàng của dịch vụ. Ví dụ: nếu sự cố của m ột
bộ chuyển m ạch m ạng có thể khiến 2.000 ngư ời dùng m ất dịch
vụ trong tổng số 10.000 người dùng dịch vụ, thì hệ số trọng số
phải là 0,2 ho ặc 20%
 Khả năng xảy ra l ỗi: điều này có th ể dựa trên độ tin c ậy của
thành phần được đo lường bằng thông tin Thời gian trung bình
Giữa các lần Hỏng hóc (MTBF) n ếu có hoặc theo xu hư ớng
hiện tại. Điều này có thể được biểu thị dưới dạng chỉ báo
thấp/trung bình/cao ho ặc dưới dạng trình bày s ố học.
 Thời gian khôi ph ục: đây là thời gian khôi ph ục ước tính để
khôi phục lại CI. Điều này có thể dựa trên thời gian khôi phục
gần đây, thông tin khôi ph ục t ừ thử nghiệm khôi phục sau
thảm họa hoặc khôi phục thử nghiệm đã được lên lịch trình.
 Thủ tục khôi phục: điều này là đ ể xác m inh r ằng các th ủ tục
khôi phục cập nhật có sẵn cho CI.
 Tính độc lập của thiết bị: khi m à các CI phần m ềm có các tập
tin song lập để cung cấp khả năng phục hồi, điều này là nhằm

201
đảm bảo rằng các vị trí tập tin đã đư ợc xác m inh là n ằm trên
các cấu hình đĩa ph ần cứng riêng bi ệt. Điều này cũng được áp
dụng cho ngu ồn cung c ấp điện – nên xác m inh rằng nguồ n
cung cấp điện thay thế đã được kết nối m ột cách đúng đắn.
 Phụ thuộc: điều này cho thấy bất kỳ sự phụ thuộc nào gi ữa
các CI. Nếu m ột CI bị lỗi sẽ có thể tác động đến các CI khác –
ví dụ, nếu m ột CI bảo m ật bị lỗi, hệ điều hành có th ể ngăn
chặn việc xử lý băng từ.
Phân tích Điểm Đơn Lỗi (Single Point of Failure – SpoF)

Một Điểm Đơn Lỗi (SpoF) là b ất kỳ thành phần nào trong cơ s ở hạ
tầng CNTT m à không có d ự phòng hoặc năng lực chịu lỗi, và có kh ả
năng gây ra sự gián đoạn đối với doanh nghi ệp, khách hàng hoặc
người sử dụng khi nó b ị lỗi. Một điều quan tr ọng là không có SPoF
nào không đư ợc nhận thức tồn tại trong thi ết kế cơ sở hạ tầng CNTT
hoặc công nghệ thực tế, và chúng nên đư ợc tránh bất cứ khi nào c ó
thể.
Việc sử dụng phân tích SPoF ho ặc CFIA như là các k ỹ thuật để xác
định các SPoF luôn đư ợc khuyến cáo. Các bài t ập Phân tích SPoF
và CFIA nên được tiến hành trên cơ s ở định kỳ, và tại bất cứ nơi
nào m à SPoF được xác định, CFIA có thể được sử dụng để xác dịnh
tác động tiềm năng đến doanh nghi ệp, khách hàng hoặc người sử
dụng và giúp xác đ ịnh những gì m à các gi ải pháp thay thế có thể
hoặc nên được xem xét đ ể cung cấp cho điểm yếu này trong thiết kế
hoặc thực tế cơ sở hạ tầng. Sau đó, các bi ện pháp ứng phó nên
được triển khai bất cứ nơi đâu phù hợp về chi phí. Tác đ ộng và s ự
gián đoạn gây ra b ởi lỗi tiềm ẩn của SPoF nên đ ược sử dụng để
biện m inh về chi phí của việc triển khai nó.
Phân tích Cây Lỗi (Fault Tree Anal ysis)

Phân tích Cây L ỗi (FTA) là m ột kỹ thuật có thể được sử dụng để xác
định chuỗi các sự kiện gây ra m ột gián đo ạn đối với các dịch vụ
CNTT. FTA, k ết hợp với các phương pháp tính toán, có th ể đề xuất
nên các m ô hình chi ti ết về tính sẵn sàng. Đi ều này có th ể được s ử
dụng để đánh giá c ải tiến tính sẵn sàng m à có thể đạt được bằng
các tùy chọn thiết kế công nghệ riêng lẻ. Sử dụng FTA:
 Thông tin có th ể được cung c ấp m à có thể được sử dụng cho

bất kỳ tính toán tính sẵn sàng nào.
 Những hoạt động có thể được hoàn thành trên cây l ỗi kết quả;
những hoạt động tương ứng với các tùy chọn thiết kế.
 Mức độ chi tiết m ong m uốn trong phân tích có th ể được lựa
chọn.
FTA tạo ra m ột trình bày về m ột chuỗi các sự kiện bằng các sử dụng
ký hiệu Boolean. Hình 4.19 đưa ra m ột ví dụ về cây lỗi.

202
Hình 4.19 – Ví dụ về Phân tích Cây L ỗi
Về cơ bản, FTA phân biệt các sự kiện sau:
 Các sự kiện cơ bản - các điểm đầu cuối cho cây l ỗi, ví dụ: lỗi
nguồn điện, lỗi người vận hành. Các sự kiện cơ bản không
được điều tra sâu. Nếu các s ự kiện cơ bản được nghiên c ứu
sâu hơn, chúng s ẽ tự động trở thành các sự kiện kết quả.
 Sự kiện kết quả - các nút trung gian trong cây l ỗi, là k ết quả
của sự kết hợp các sự kiện. Điểm cao nhất trong cây l ỗi
thường là lỗi của dịch vụ CNTT.
 Sự kiện có điều kiện - sự kiện chỉ xảy ra trong nh ững điều
kiện nhất định, ví dụ: sự cố của thiết bị điều hòa không khí ch ỉ
ảnh hưởng đến dịch vụ CNTT nếu nhiệt độ thiết bị vượt quá
giá trị có thể sử dụng.
 Sự kiện kích hoạt - sự kiện kích hoạt các sự kiện khác, ví dụ:
thiết bị phát hiện mất nguồn điện có thể kích hoạt tự động tắt
các dịch vụ CNTT.
Các sự kiện này có thể được kết hợp bằng cách sử dụng các toán t ử
luận lý, t ức là:

203
 Cổng-AND - sự kiện kết quả chỉ xảy ra khi t ất cả các s ự kiện
đầu vào xảy ra m ột cách đồng thời.
 Cổng-OR - sự kiện kết quả xảy ra khi m ột hoặc nhiều sự kiện
đầu vào xảy ra.
 Cổng-OR duy nh ất - sự kiện kết quả xảy ra khi m ột và chỉ m ột
trong các s ự kiện đầu vào xảy ra.
 Cổng cản trở - sự kiện kết quả chỉ xảy ra khi đi ều kiện đầu
vào không đư ợc đáp ứng.
Đây là k ỹ thuật FTA cơ bản. Kỹ thuật này cũng có th ể được cải tiến,
nhưng FTA ph ức t ạp và đánh giá toán h ọc về cây lỗi nằm ngoài
phạm vi của ấn phẩm này.
Mô hình hóa
Để đánh giá xem các thành ph ần m ới trong thi ết kế có thể phù hợ p
với các yêu c ầu đã nêu hay không, đi ều quan tr ọng là chế độ thử
nghiệm được tiến hành ph ải đảm bảo rằng tính s ẵn sàng đã k ỳ vọng
có thể được cung cấp. Các công cụ m ô phỏng, m ô hình hóa ho ặc
kiểm tra tải để tạo ra nhu cầu dự kiến của người dùng đối với dịch
vụ CNTT m ới nên được xem xét m ột cách nghiêm túc đ ể đảm bảo
các thành ph ần tiếp tục hoạt động trong đi ều kiện khối lượng và ứng
suất đã được dự kiến.
Các công cụ m ô hình hóa cũng đư ợc đòi hỏi để dự báo về tính sẵn
sàng và đánh giá tác đ ộng của những thay đ ổi đối với cơ sở hạ tầng
CNTT. Các đầu vào cho quá trình m ô hình hóa bao g ồm dữ liệu dùng
để m ô tả về độ tin c ậy, khả năng có th ể bảo trì và khả năng phục vụ
của thành phần. Một gói bảng tính để thực hiện các phép tính
thường là đủ. Nếu yêu cầu dữ liệu chi tiết và chính xác hơn, có th ể
cần phát triển hoặc m ua lại m ột công c ụ m ô hình hóa ph ức tạp hơn.
Việc thiếu các công cụ m ô hình hóa về tính sẵn sàng có sẵn trên thị
trường có thể yêu c ầu m ột công cụ như vậy phải được phát triển và
duy trì ‘nội bộ’, nhưng đây là m ột hoạt động rất tốn kém và tốn thời
gian chỉ nên được xem xét khi kho ản đầu tư có th ể được giải trình.
Trừ khi có lợi ích được nhận thức m ột cách rõ ràng t ừ sự phát triển
như vậy và chi phí cho bảo trì liên t ục, việc sử dụng các công c ụ và
bảng tính hi ện có là đủ. Tuy nhiên, m ột số công cụ Quản lý Hệ thống
cung cấp khả năng lập m ô hình và có th ể cung cấp thông tin hữu ích
về xu hướng và dự báo nhu c ầu về tính sẵn sàng.
Phân tích và quản lý rủi ro

Để đánh giá tính d ễ bị thất bại trong cấu hình và năng l ực của tổ
chức hỗ trợ và dịch vụ CNTT, chúng tôi khuy ến nghị rằng cơ sở hạ
tầng CNTT hi ện có hoặc được đề xuất, cấu hình dịch vụ, Thiết kế
Dịch vụ và tổ chức hỗ trợ (nhà cung c ấp nội bộ và bên ngoài) ph ải
tuân theo các bài t ập Phân tích và Qu ản lý Rủi ro chính thức. Phân
tích và Quản lý Rủi ro là m ột kỹ thuật có thể được sử dụng để xác
định và định lượng rủi ro và các bi ện pháp ứng phó hợp lý có th ể
được triển khai để bảo vệ tính sẵn sàng c ủa hệ thống CNTT. Vi ệc
xác định các rủi ro và cung c ấp các biện pháp ứng phó hợp lý để
giảm thiểu hoặc loại bỏ các m ối đe dọa do những rủi ro đó gây ra c ó

204
thể đóng m ột vai trò quan tr ọng trong việc đạt được mức độ sẵn
sàng cần thiết cho m ột dịch vụ CNTT m ới hoặc được nâng cao.
Phân tích R ủi ro nên được thực hiện trong su ốt giai đoạn thiết kế
đối với công nghệ và dịch vụ CNTT để xác định:
 Những Rủi ro có th ể phát sinh đ ối với các thành ph ần CNTT

trong công ngh ệ và Thiết kế dịch vụ.
 Rủi ro có th ể tiết lộ bí m ật và/hoặc tính toàn vẹn trong Công
nghệ CNTT và Thi ết kế Dịch vụ.
Phần lớn các phương pháp đánh giá và qu ản lý rủi ro liên quan đ ến
việc sử dụng phương pháp ti ếp cận chính thức để đánh giá rủi ro và
việc giảm thiểu rủi ro tiếp theo sau đó với việc triển khai các bi ện
pháp ứng phó với chi phí hợp lý, như được m inh họa trong Hình
4.20.
Hình 4.20 – Phân tích và Qu ản lý Rủi ro
Phân tích rủi ro liên quan đến việc xác định và đánh giá m ức độ (đo
lường) rủi ro được tính toán từ giá trị đã được đánh giá c ủa tài sản
và m ức độ đe dọa đã được đánh giá, và tính d ễ bị tổn thương đ ố i
với tài sản đó. Rủi ro cũng được xác định ở m ột m ức độ nhất định
bởi sự chấp nhận của nó. Một số tổ chức và doanh nghiệp có thể
sẵn sàng hơn để chấp nhận rủi ro trong khi những tổ chức và doanh
nghiệp khác thì không.
Quản lý rủi ro liên quan đến việc xác định, lựa chọn và áp dụng các
biện pháp ứng phó phù hợp với các rủi ro đã được xác định đối với
tài sản về m ặt tác động tiềm tàng c ủa chúng đối với dịch vụ nếu xả y
ra lỗi và giảm thiểu các rủi ro đó xuống đến m ức có thể chấp nhận
được. Quản lý rủi ro là m ột hoạt động gắn liền với nhiều hoạt động
khác, đặc biệt là ITSCM, Qu ản lý Bảo m ật và Chuyển đổi Dịch vụ.
Tất cả các bài tập đánh giá r ủi ro này nên được phối hợp với nhau
thay vì chỉ là các hoạt động riêng l ẻ.

205
Phương pháp ti ếp cận này, khi được áp dụng thông qua m ột phương
pháp chính th ức, đảm bảo phạm vi bảo hiểm đầy đủ, cùng với sự tin
tưởng đủ rằng:
 Tất cả các rủi ro có thể xảy ra và các bi ện pháp ứng phó đã

được xác định.
 Tất cả các lỗ hổng đã được xác định và đánh giá m ức độ của
chúng m ột cách chính xác.
 Tất cả các m ối đe dọa đã được xác định và đánh giá m ức độ
của chúng m ột cách chính xác.
 Tất cả các kết quả đều nhất quán trên ph ạm vi rộng c ủa công
nghệ được xem xét.
 Tất cả chi phí cho các biện pháp ứng phó đã ch ọn có thể được
hợp lý hóa.
Các phương pháp Phân tích và Qu ản lý Rủi ro chính th ức hiện đang

là m ột yếu tố quan trọng trong thi ết kế tổng thể và trong vi ệc cung
cấp các dịch vụ CNTT. Việc đánh giá rủi ro thường dựa trên xác
suất và tác động tiềm tàng c ủa m ột sự kiện xảy ra. Các bi ện pháp
ứng phó đư ợc thực hiện ở bất cứ nơi nào m à chúng có th ể hợp lý về
chi phí, để giảm tác động của m ột sự kiện, hoặc xác suất của sự
kiện xảy ra hoặc cả hai.
Quản lý rủi ro (M_o_R) cung c ấp m ột khuôn khổ thay thế tổng quát
để quản lý rủi ro trên toàn b ộ các bộ phận của tổ chức - chiến lược,
chương trình, dự án và hoạt động. Nó kết hợp tất cả các hoạt động
cần thiết để xác định và kiểm soát việc đối m ặt với bất kỳ loại rủi ro
nào, tích cực hay tiêu cực, có thể có tác động đến việc đạt được các
m ục tiêu kinh doanh c ủa tổ chức bạn.
M_o_R cung c ấp một khuôn khổ đã được thí nghiệm , thử nghiệm và
hiệu quả để giúp bạn loại bỏ - hoặc quản lý - những rủi ro liên quan
đến việc đạt được m ục tiêu c ủa m ình. M_o_R th ông qua vi ệc áp
dụng m ột cách có hệ thống các nguyên t ắc, phương pháp ti ếp cận
và quy trình vào nhi ệm vụ xác định, đánh giá, sau đó ho ạch định và
triển khai các ph ản ứng đối với rủi ro. Hướng dẫn nhấn m ạnh vào
phương pháp ti ếp cận hợp tác và t ập trung vào các yếu tố chính
sau:
 Việc phát tri ển m ột khuôn khổ m inh bạch, có thể lặp lại và có
thể áp dụng được.
 Việc truyền thông m ột cách rõ ràng v ề các chính sách và l ợi
ích của nó cho m ọi nhân viên.
 Việc đề cử các cá nhân quan tr ọng trong đội ngũ quản lý cấp
cao để ‘sở hữu’ những sáng ki ến quản lý r ủi ro và đảm bảo
rằng chúng ti ến lên phía trước.
 Đảm bảo rằng văn hóa gắn kết với và hỗ trợ m ột cách đúng
m ức những rủi ro được xem xét, bao g ồm cả sự đối m ới.
 Nhúng hệ thống quản lý rủi ro vào qu ản lý và áp dụng chúng
m ột cách nhất quán.

206
 Đảm bảo rằng quản lý rủi ro hỗ trợ cho các m ục tiêu – thay vì
ngược lại.
 Đánh giá m ột cách rõ ràng những rủi ro liên quan đ ến hoạt
động với các tổ chức khác.
 Áp dụng phương pháp ti ếp cận không-đổ lỗi để giám sát và
xem xét hoạt động đánh giá rủi ro.
Lịch trình kiểm tra tính sẵn sàng

Một sản phẩm chủ yếu từ quy trình Quản lý Tính s ẵn sàng là ‘l ịch
trình kiểm tra tính s ẵn sàng’. Đây là lịch trình kiểm tra thường xuyên
tất cả các cơ chế sẵn sàng. Một số cơ chế sẵn sàng, chẳng hạn như
"cân bằng t ải", "phản chiếu" và "điện toán lưới", được sử dụng trong
việc cung cấp dịch vụ bình thường trên cơ sở từng ngày; những dịch
vụ khác được sử dụng trên cơ sở dự phòng hoặc cấu hình lại bằng
thủ công. Do đó, đi ều cần thiết là tất cả các cơ chế sẵn sàng phải
được kiểm tra m ột cách thường xuyên và theo đúng l ịch trình đ ể
đảm bảo rằng chúng thực sự hoạt động khi thực sự cần thiết. Lịch
trình này c ần được duy trì và lưu hành r ộng rãi để tất cả các khu
vực đều nhận thức được nội dung của nó và để từ đó, tất cả các
hoạt động được đề xuất khác có th ể được đồng bộ với nội dung của
nó, chẳng hạn như:
 Lịch trình thay đổi.

 Phát hành các k ế hoạch và lịch trình.
 Mọi kế hoạch chuyển tiếp, dự án và chương trình.
 Các lịch trình bảo trì đã đư ợc hoạch định và có tính phòn g
ngừa.
 Lịch trình ki ểm nghiệm tính liên t ục dịch vụ CNTT và các kế
hoạch khôi ph ục.
 Các kế hoạch và lịch trình kinh doanh.
Bảo trì đã được ho ạch định và mang tính phòng ng ừa

Tất cả các thành phần CNTT phải tuân theo m ột chiến lược bảo trì
được lập kế hoạch. Tần suất và m ức độ bảo trì cần thiết là khác
nhau giữa các bộ phận, có tính đến các công ngh ệ liên quan, m ức
độ quan tr ọng và các lợi ích kinh doanh ti ềm năng có th ể được giới
thiệu. Các ho ạt động bảo trì đã được lập kế hoạch cho phép t ổ chức
hỗ trợ CNTT cung c ấp:
 Bảo trì m ang tính phòng ng ừa để tránh hỏng hóc.

 Nâng cấp phần m ềm hoặc phần cứng theo k ế hoạch để cung
cấp chức năng m ới hoặc năng lực bổ sung.
 Lĩnh vực kinh doanh đòi h ỏi thay đổi các ứng dụng nghiệp vụ.
 Triển khai công ngh ệ và chức năng m ới để doanh nghi ệp khai
thác.
Yêu cầu về thời gian ng ừng hoạt động đã được lập kế hoạch có ảnh
hưởng m ột cách rõ ràng đ ến m ức độ sẵn sàng có th ể được cung cấp
cho m ột dịch vụ CNTT, đặc biệt là những dịch vụ có yêu c ầu nghiêm
ngặt về tính sẵn sàng. Khi xác đ ịnh các yêu cầu về tính sẵn sàng
cho m ột dịch vụ CNTT m ới hoặc được nâng cao, lượng thời gian

207
ngừng hoạt động và kết quả là m ất thu nhập cần thiết cho việc bảo
trì đã được lập kế hoạch có thể là không thể chấp nhận được đối với
doanh nghiệp. Điều này đang trở thành m ột vấn đề ngày càng gia
tăng trong lĩnh v ực Vận hành Dịch vụ 24 x 7. Trong nh ững trường
hợp này, điều thiết yếu là hoạt động liên tục chính là đ ặc điểm thiết
kế cốt lõi để cho phép ho ạt động bảo trì được thực hiện m à không
ảnh hưởng đến tính sẵn sàng của các dịch vụ CNTT.
Trong trường hợp số giờ dịch vụ bắt buộc đối với các dịch vụ CNTT
dưới 24 giờ m ỗi ngày và/ho ặc bảy ngày m ỗi tuần, có khả năng phầ n
lớn các bảo trì đã được lập kế hoạch có thể được thực hiện m à
không ảnh hưởng đến tính sẵn sàng c ủa dịch vụ CNTT. Tuy nhiên,
khi doanh nghi ệp cần các dịch vụ CNTT sẵn sàng trên cơ s ở 24 giờ
và bảy ngày, Quản lý Tính sẵn sàng cần xác định phương pháp ti ếp
cận hiệu quả nhất trong việc cân bằng các yêu cầu cho bảo trì đã
được lập kế hoạch với việc m ất dịch vụ đối với doanh nghi ệp. Trừ
khi tồn tại các cơ ch ế để cho phép tiếp tục vận hành, thời gian
ngừng hoạt động đã được lên lịch cho các b ảo trì đã được lập kế
hoạch là điều thiêt yếu nếu như m ức độ sẵn sàng cao cần phải đạt
được và phải được duy trì. Đối với mọi dịch vụ CNTT, nên có m ột
khoảng thời gian ‘tác động-thấp’ để triển khai việc bảo trì. Một khi
các yêu cầu đối với việc quản lý việc bảo trì đã được lên kế hoạch
đã được xác định và thống nhất, chúng nên được lập thành văn bản
trong các tài liệu, tối tiểu là trong:
 Các SLA.
 Các OLA.
 Các hợp đồng cơ s ở.
 Các lịch trình Qu ản lý Thay đổi.
 Phát hành các lịch trình Quản lý Triển khai.
Quản lý Tính sẵn sàng nên đảm bảo rằng việc xây dựng bảo trì
m ang tính phòng ng ừa là m ột trong những xem xét thi ết kế chủ
yếu đối với các dịch vụ CNTT ’24 x 7’.
Thời điểm thích hợp nhất để lên lịch cho thời gian ngừng hoạt động
đã được kế hoạch rõ ràng là khi ảnh hưởng đến doanh nghiệp và
khách hàng là ít nh ất. Thông tin này nên đư ợc cung cấp ban đầu bởi
doanh nghiệp khi xác đ ịnh các yêu c ầu về tính sẵn sàng. Đối với m ột
dịch vụ CNTT hiện có hoặc m ột khi dịch vụ m ới đã được thiết lập,
việc giám sát các giao d ịch kinh doanh và khách hàng giúp thi ết lập
thời điềm m à việc sử dụng dịch vụ CNTT ở m ức thấp nhất. Điều này
sẽ xác định thời gian thích hợp nhất để (các) thành ph ần được tách
ra cho hoạt động bảo trì đã được lập kế hoạch.
Để đáp ứng các yêu c ầu thành phần riêng l ẻ cho thời gian ngừng
hoạt động đã được lập kế hoạch trong khi cân b ằng các yêu cầu về
tính sẵn sàng c ủa dịch vụ CNTT của doanh nghi ệp cung c ấp m ột cơ
hội để xem xét lập lịch trình cho vi ệc bảo trì đã được lập kế hoạch
cho nhiều thành ph ần đồng thời. Lợi ích c ủa phương pháp tiếp cận

208
này là số lần gián đoạn dịch vụ để đáp ứng các yêu c ầu bảo trì đư ợc
giảm thiểu. Mặc dù cách tiếp cận này có nh ững lợi ích, nhưng cũng
có những rủi ro tiềm ẩn cần được đánh giá. Ví d ụ:
 Năng lực của tổ chức hỗ trợ CNTT để phối hợp triển khai đồng
thời nhiều thay đổi.
 Khả năng thực hiện xác định vấn đề hiệu quả nơi m à d ịch vụ
CNTT bị ảnh hưởng sau khi hoàn thành nhi ều thay đổi.
 Tác động của sự phụ thuộc vào sự thay đổi trên nhi ều thành
phần trong đó sự rút lui c ủa m ột thay đổi không thành công đòi
hỏi phải loại bỏ nhiều thay đổi.
Việc quản lý hiệu quả thời gian ngừng hoạt động đã được lập kế
hoạch là m ột đóng góp quan tr ọng trong việc đáp ứng mức độ sẵn
sàng cần thiết cho m ột dịch vụ CNTT. Trong trường hợp thời gian
ngừng hoạt động đã được lập kế hoạch được yêu c ầu theo chu k ỳ
đối với (các) thành ph ần CNTT, thì thời gian m à thành ph ần đó
không s ẵn sàng để cho phép thực hiện hoạt động bảo trì đã được
lập kế hoạch phải được xác định và thống nhất với nhà cung cấp nội
bộ hoặc bên ngoài. Đi ều này trở thành m ột m ục tiêu đã tuyên b ố có
thể được chính th ức hóa, đo lư ờng và báo cáo.
Tất cả các hoạt động bảo trì đã được lập kế hoạch phải được lên
lịch trình, qu ản lý và kiểm soát để đảm bảo rằng các m ục tiêu và
khoảng thời gian riêng lẻ không bị vượt quá và đảm bảo rằng các
hoạt động được phối hợp với tất cả các lịch trình hoạt động khác đ ể
giảm thiểu va chạm và xung đ ột (ví dụ: các lịch trình thay đổi và
phát hành, các l ịch trình th ử nghiệm ). Ngoài ra, chúng cung c ấp m ột
cảnh báo sớm trong su ốt hoạt động bảo trì khi thời gian được phân
bổ cho thời gian ngừng hoạt động theo k ế hoạch bị vi phạm . Điều
này có thể cho phép việc m ột quyết định sớm được đưa ra về việc
liệu hoạt động (bảo trì) có được phép tiếp tục hoàn thành với khả
năng ảnh hưởng thêm đến dịch vụ hay không hoặc hủy bỏ hoạt động
và thực hiện kế hoạch dự phòng. Thời gian ngừng hoạt động đã
được lập kế hoạch và hiệu suất so với các m ục tiêu đã tuyên b ố cho
từng thành phần phải được ghi nhận lại và sử dụng trong báo cáo
dịch vụ.
Sản xu ất tài liệu Ngừng Dịch vụ Dự kiến (PSO)

Quản lý tính sẵn sàng phải tạo và duy trì tài li ệu PSO. Tài li ệu này
bao gồm bất kỳ sự thay đổi nào so với tính s ẵn sàng của dịch vụ đã
được thỏa thuận trong SLA. Tài li ệu này phải được tạo ra dựa trên
đầu vào t ừ:
 Lịch trình thay đổi,

 Lịch trình phát hành,
 Lịch trình b ảo trì đã được lập kế hoạch và m ang tính phòng
ngừa,
 Lịch trình ki ểm tra tính s ẵn sàng,
 Lịch trình ki ểm tra ITSCM và Qu ản lý Liên t ục Kinh doanh.

209
PSO chứa thông tin chi ti ết về m ọi thời gian ngừng hoạt động của
dịch vụ đã được lập kế hoạch và lên l ịch trình trong thời gian dịch
vụ đã được thỏa thuận cho tất cả các dịch vụ. Các tài liệu này cầ n
được thống nhất với tất cả các lĩnh vực thích hợp và đại diện của cả
doanh nghi ệp và CNTT. Khi PSO đã đư ợc thỏa thuận, Bộ phận Dịch
vụ phải đảm bảo rằng nó được truyền đạt cho t ất cả các bên liên
quan để m ọi người được nhận biết về bất kỳ thời gian ngừng dịch vụ
bổ sung và đã được lập kế hoạch nào.
Liên tục xem xét và c ải tiến

Thay đổi nhu c ầu kinh doanh và nhu c ầu của khách hàng có thể đòi
hỏi m ức độ sẵn sàng cung c ấp cho m ột dịch vụ CNTT phải được xem
xét lại. Các đánh giá như v ậy nên là m ột phần của các đánh giá d ịc h
vụ thường xuyên với doanh nghiệp do SLM đ ảm nhận. Các thông tin
đầu vào khác cũng c ần được xem xét thường xuyên từ ITSCM, đặc
biệt là từ các bài t ập Phân tích Tác đ ộng Kinh doanh và Phân tíc h
Rủi ro đã đư ợc cập nhật. Mức độ quan tr ọng của các dịch vụ sẽ
thường xuyên thay đổi và điều quan tr ọng là thiết kế và công ngh ệ
hỗ trợ cho các dịch vụ đó thường xuyên được Quản lý Tính sẵn sàng
xem xét và c ải tiến để đảm bảo rằng sự thay đổi về tầm quan trọng
của dịch vụ được phản ánh trong thi ết kế và công ngh ệ hỗ trợ đã
được sửa đổi. Khi các m ức độ sẵn sàng c ần thiết đã thực sự được
cung cấp, có thể sẽ tốn nhiều công s ức và chi phí đáng kể để đạt
được m ột cải tiến t ừng bước nhỏ tăng dần trong m ức độ sẵn sàng.
Một hoạt động chủ yếu của Quản lý Tính s ẵn sàng là liên t ục xem
xét các cơ h ội để tối ưu hóa tính kh ả dụng của cơ sở hạ tầng CNTT
cùng với các ho ạt động Liên tục Cải tiến Dịch vụ. Lợi ích của
phương pháp tiếp cận đánh giá thường xuyên này là đôi khi, m ức độ
sẵn sàng được nâng cao có thể đạt được nhưng với chi phí th ấp
hơn nhiều. Phương pháp t ối ưu hóa là bước đầu tiên hợp lý để
m ang lại giá tr ị của tiền tệ tốt hơn. Một số kỹ thuật Quản lý Tính sẵ n
sàng có thể được áp dụng để xác định các cơ h ội tối ưu hóa. Chúng
tôi khuyến nghị rằng phạm vi không nên b ị giới hạn đối với công
nghệ, m à còn bao g ồm việc xem xét cả quy trình kinh doanh và các
trách nhiệm từ đầu-đến-cuối khác thu ộc sở hữu của doanh nghiệp.
Để giúp đạt được những m ục tiêu này, Quản lý Tính s ẵn sàng c ần
được công nhận là m ột bộ phận có ảnh hưởng hàng đầu đối với tổ
chức cung c ấp dịch vụ CNTT để đảm bảo tiếp tục tập trung vào tính
sẵn sàng và ổn định của công nghệ.
Quản lý Tính s ẵn sàng có thể cung cấp cho tổ chức hỗ trợ CNTT m ột
quan điểm thực tế của người dùng và doanh nghi ệp về m ức độ ảnh
hưởng của những khiếm khuyết trong công ngh ệ cũng như quy trình
và thủ tục cơ bản đến hoạt động kinh doanh và cu ối cùng là khách
hàng của họ. Việc sử dụng các chỉ số định hướng-kinh doanh có th ể
chứng m inh cho tác đ ộng này trong đi ều kiện thực tế và quan tr ọng
là cũng giúp đ ịnh lượng lợi ích của các cơ hội cải tiến. Quản lý Tính
sẵn sàng có th ể đóng m ột vai trò quan tr ọng trong vi ệc giúp t ổ chức
cung cấp dịch vụ CNTT nhận ra nơi có thể gia tăng giá tr ị bằng các h
khai thác các k ỹ năng và năng l ực kỹ thuật của m ình trong b ối cảnh

210
về tính sẵn sàng. K ỹ thuật cải tiến liên tục có thể được sử dụng bởi
Quản lý Tính s ẵn sàng để khai thác kh ả năng kỹ thuật này. Điều này
có thể được sử dụng với m ột trong hai nhóm nh ỏ nhân viên k ỹ thuật
hoặc m ột nhóm rộng hơn trong hội thảo hoặc m ôi trường SFA.
Động lực để cải thiện tính sẵn sàng đến từ m ột hoặc nhiều yếu tố
sau đây:
 Các dịch vụ CNTT hiện có hoặc m ới không có kh ả năng đáp

ứng các m ục tiêu SLA trên m ột cơ sở nhất quán.
 (Các) giai đoạn dịch vụ CNTT không ổn định dẫn đến m ức độ
sẵn sàng không th ể chấp nhận được.
 Các xu hư ớng đo lường tính s ẵn sàng cho th ấy tình tr ạng sẵn
sàng giảm dần
 Thời gian khôi p hục và khôi ph ục dịch vụ CNTT không thể
chấp nhận được.
 Các yêu c ầu từ doanh nghiệp để tăng m ức độ sẵn sàng đã
được cung c ấp.
 Tác động ngày càng tăng lên doanh nghi ệp và khách hàng c ủa
họ của các l ỗi dịch vụ CNTT do tăng trưởng và/hoặc các ưu
tiên kinh doanh hoặc chức năng nghiệp vụ được gia tăng.
 Yêu cầu từ SLM để cải thiện tính s ẵn sàng như m ột phần của
m ột SIP tổng thể.
 Giám sát và phân tích xu hư ớng Quản lý Tính sẵn sàng.
Quản lý Tính s ẵn sàng nên có vai trò ch ủ động trong vi ệc xác định
và tiến hành các cơ hội cải thiện tình trạng sẵn sàng dựa trên chi
phí hợp lý trong K ế hoạch về Tính s ẵn sàng. Khả năng thực hiện
điều này phụ thuộc vào việc đo lường và báo cáo tính s ẵn sàng phù
hợp và có ý nghĩa. Đ ể đảm bảo các c ải thiện tính s ẵn sàng m ang lạ i
lợi ích c ho doanh nghi ệp và ngư ời dùng, điều quan tr ọng là vi ệc đo
lường và báo cáo phản ảnh không ch ỉ tính sẵn sàng của thành ph ần
CNTT m à còn về tính sẵn sàng từ quan điểm hoạt động kinh doanh
và quan điểm người sử dụng.
Khi doanh nghi ệp có yêu cầu cải thiện tính sẵn sàng, quy trình và
các kỹ thuật để đánh giá lại công nghệ và năng lực của tổ chức cung
cấp dịch vụ CNTT để đáp ứng những yêu c ầu gia tăng này nên đư ợc
tuân theo. Một đầu ra của hoạt động này là tính s ẵn sàng được tăng
cường và tiêu chí thi ết kế sự khôi phục. Để đáp ứng các yêu cầ u
doanh nghiệp đối với các m ức độ tính sẵn sàng được tăng cường c ó
thể đòi hỏi khoản đầu tư tài chính bổ sung để tăng cường công ngh ệ
nền tảng và/hoặc m ức độ dịch vụ được cung c ấp bởi tổ chức cung
cấp dịch vụ CNTT. Đi ều quan trọng là bất kỳ khoản đầu tư tài chính
nào để cải thiện m ức độ sẵn sàng đư ợc cung c ấp phải có thể biện
m inh được về chi phí. Vi ệc xác định chi phí c ủa tình trạng không sẵn
sàng do k ết quả của (các) lỗi CNTT có th ể giúp hỗ trợ cho bất k ỳ
quyết định đầu tư tài chính nào trong vi ệc cải thiện tính sẵn sàng.

211
4.4.6 Các yếu tố kích ho ạt, đầu vào, đ ầu ra và giao diện
Rất nhiều sự kiện có thể kích hoạt hoạt động Quản lý Tính sẵn sàng.
Chúng bao gồm :
 Các nhu cầu kinh doanh m ới hoặc thay đổi hoặc các dịch vụ
mới hoặc được thay đổi.
 Các đích nh ắm m ục tiêu m ới hoặc được thay đổi trong các
thỏa thuận chẳng hạn như SLR, SLA, OLA ho ặc các hợp đồng.
 Các vi phạm dịch vụ hoặc thành phần, các s ự kiện và cảnh
báo về tính s ẵn sàng, bao g ồm các s ự kiện ngưỡng, các báo
cáo ngoại lệ.
 Những hoạt động định kỳ như xem xét, đi ều chỉnh hoặc báo
cáo.
 Xem xét các d ự đoán, báo cáo và k ế hoạch Quản lý Tính sẵn
sàng.
 Xem xét và đi ều chỉnh các kế hoạch và chiến lược kinh doanh
và CNTT.
 Xem xét và đi ều chỉnh các thiết kế và chiến lược.
 Nhận biết hoặc lưu ý về m ột thay đổi của rủi ro hoặc tác động
của quy trình nghi ệp vụ hoặc VBF, m ột dịch vụ hoặc thành
phần CNTT.
 Yêu cầu từ SLM để hỗ trợ các đích nh ắm m ục tiêu về tính sẵn
sàng và gi ải trình về các thành t ựu.
Các giao di ện chủ yếu m à Quản lý Tính s ẵn sàng có với các quy
trình khác là:
 Quản lý Vấn đề và Sự cố: hỗ trợ việc giải quyết và theo sau

đó là biện m inh và kh ắc phục các vấn đề và sự cố về tính sẵn
sàng.
 Quản lý Công su ất: với việc cung c ấp khả năng phục hồi và
công suất dự phòng.
 Quản lý Liên tục Dịch vụ CNTT: với sự đánh giá về tác động
kinh doanh và r ủi ro và cung c ấp khả năng phục hồi, chịu lỗi
và các cơ ch ế khôi phục.
 Quản lý Mức Dịch vụ: hỗ trợ việc xác định các đích nhắm
m ục tiêu về tính sẵn sàng và tìm hiểu và giải quyết các xâm
phạm dịch vụ và thành phần.
4.4.6.1 Các Đầu vào

Một số nguồn thông tin là có liên quan đ ến quy trình Qu ản lý Tính
sẵn sàng. Một số trong chúng được liệt kê như dưới đây:
 Thông tin doanh nghi ệp: từ chiến lược, các k ế hoạch và kế

hoạch tài chính c ủa doanh nghi ệp, và thông tin về các yêu cầu
hiện tại và tương lai c ủa họ, bao gồm các yêu c ầu về tính sẵn
sàng cho các d ịch vụ CNTT m ới hoặc được tăng cường.
 Thông tin tác đ ộng kinh doanh : từ các BIA và đánh giá v ề
các VBF có n ền tảng là các dịch vụ CNTT.

212
 Các báo cáo Đánh giá và Ph ân tích R ủi ro trước đây và bả n
Đăng ký Rủi ro (một danh sách bao gồm các rủi ro đã được
xác định – người dịch)
 Thông tin dịch vụ: từ Danh m ục Dịch vụ và Bản Mục lục Dịch
vụ.
 Thông tin dịch vụ: : từ các quy trình SLM, với các chi ti ết về
các dịch vụ từ Danh m ục Dịch vụ và Bản Mục lục Dịch vụ, các
đích nhắm m ục tiêu m ức dịch vụ từ các SLA và SLR, và có kh ả
năng từ việc giám sát các SLA, xem xét d ịch vụ và xâm ph ạm
SLA.
 Thông tin tài chính : từ Quản lý Tài chính, chi phí c ủa việc
cung cấp dịch vụ, chi phí cho các tài nguyên và các thành
phần.
 Thông tin thay đ ổi và phát hành : từ quy trình Quản lý Thay
đổi với Lịch trình Thay đổi, Lịch trình Phát hành t ừ Quản lý
bản Phát hành và nhu c ầu đánh giá m ọi thay đổi đối với tác
động của chúng lên tính s ẵn sàng c ủa dịch vụ.
 Quản lý Cấu hình: bao gồm thông tin về m ối quan hệ giữ a
doanh nghiệp, các dịch vụ, các dịch vụ hỗ trợ và công ngh ệ.
 Các đích nh ắm mục tiêu Dịch vụ: từ các SLA, SLR, OLA và
hợp đồng.
 Thông tin về thành phần: về các yêu cầu về tính sẵn sàng,
độ tin cậy và khả năng có thể bảo trì được đối với các thành
phần công nghệ làm nền tảng cho (các) dịch vụ CNTT.
 Thông tin công ngh ệ: từ CMS và về sơ đồ cấu trúc và m ối
quan hệ giữa các thành phần và đánh giá v ề năng lực của
công nghệ m ới.
 Hiệu suất quá khứ: từ các đo lường, thành tựu và báo cáo và
Hệ thống Thông tin Quản lý Tính s ẵn sàng (AMIS).
 Thông tin về lỗi và tình trạng không sẵn sàng: từ các s ự cố
và vấn đề.
4.4.6.2 Các Đầu ra

Các đầu ra t ừ Quản lý Tính s ẵn sàng nên bao gồm :
 Hệ thống Thông tin Quản lý Tính s ẵn sàng (A MIS).

 Kế hoạch về Tính sẵn sàng đối với các c ải tiến chủ động về
dịch vụ CNTT và công ngh ệ.
 Tiêu chí thiết kế tính sẵn sàng và khôi ph ục và các đích nhắm
m ục tiêu dịch vụ đã được đề xuất đối với dịch vụ m ới hoặc
thay đổi.
 Các báo cáo tính s ẵn sàng, độ tin cậy và khả năng có thể bảo
trì của dịch vụ về những thành tựu so với m ục tiêu, bao g ồm
cả đầu vào cho m ọi báo cáo d ịch vụ.
 Các báo cáo tính s ẵn sàng, độ tin c ậy và khả năng có thể bảo
trì của thành ph ần về những thành t ựu so với m ục tiêu.
 Các đánh giá phân tích rủi ro đã đư ợc điều chỉnh và các báo
cáo và m ột Bản đăng ký Rủi ro được cập nhật.
 Các yêu cầu về việc giám sát, quản lý và báo cáo đối với các
dịch vụ và thành ph ần CNTT để đảm bảo rằng những sai l ệch

213
trong tính s ẵn sàng, độ tin cậy và khả năng có thể bảo trì
được sẽ được nhận diện, thực thi, ghi nh ận và báo cáo.
 Một lịch trình ki ểm nghiệm Quản lý Tính s ẵn sàng đ ể kiểm
nghiệm m ọi cơ chế về tính sẵn sàng, khả năng phục hồi và
khôi phục.
 Các lịch trình bảo trì đã được lập kế hoạch và m ang tính
phòng ngừa.
 Thời gian gián đoạn Dịch vụ Dự kiến (PSO) kết hợp với Quản
lý Thay đổi và Phát hành.
 Chi tiết của các k ỹ thuật và thước đo tính s ẵn sàng chủ động
sẽ được triển khai để cung cấp khả năng phục hồi bổ sung
nhằm ngăn ng ừa hoặc tối thiểu hóa tác động của lỗi thành
phần lên tính sẵn sàng c ủa dịch vụ CNTT.
 Các hoạt động cải tiến cho kết luận trong SIP
4.4.7 Các Chỉ số Hiệu suất Quan trọng

Rất nhiều KPI có thể được sử dụng để đo lường tính hiệu quả và
hiệu suất của Quản lý Tính s ẵn sàng, bao g ồm các ví dụ dưới đây:
Quản lý tính sẵn sàng và độ tin cậy của dịch vụ CNTT
 Tỷ lệ phần trăm giảm về tình tr ạng không sẵn sàng của các
dịch vụ và thành ph ần.
 Tỷ lệ phần trăm tăng về độ tin cậy của các dịch vụ và thành
phần.
 Xem xét và theo dõi hi ệu quả m ọi vi phạm SLA, OLA và hợp
đồng cơ sở.
 Tỷ lệ phần trăm cải thiện về tính s ẵn sàng t ổng thể từ đầu-
đến-cuối của dịch vụ.
 Tỷ lệ phần trăm giảm về số lượng và tác động của việc ngừng
dịch vụ.
 Cải thiện trong MTBF (Mean Tim e Between Failures).
 Cải thiện trong MTBSI (Mean Tim e Between System s
Incidents).
 Giảm MTRS (Mean Tim e to Restore Service).
Đáp ứng những nhu cầu của doanh nghi ệp đối với vi ệc tiếp cận
các dịch vụ CNTT
 Tỷ lệ phần trăm gi ảm về tình tr ạng không s ẵn sàng của dịch

vụ.
 Tỷ lệ phần trăm giảm về chi phí ngoài giờ của doanh n ghiệp
do CNTT không s ẵn sàng.
 Tỷ lệ phần trăm giảm về lỗi trong những thời điểm quan tr ọng,
ví dụ giờ kinh doanh cao đi ểm và các nhu c ầu về ưu tiên tính
sẵn sàng đã được lập kế hoạch cho nó.
 Tỷ lệ phần trăm cải thiện trong m ức độ hài lòng c ủa doanh
nghiệp và người sử dụng đối với dịch vụ (qua kết quả CSS).
Đạt đư ợc tính sẵn sàng của cơ sở hạ tầng CNTT với chi phí tối
ưu

214
 Tỷ lệ phần trăm giảm trong chi phí c ủa tình tr ạng không s ẵn
sàng.
 Tỷ lệ phần trăm cải thiện trong chi phí cho B ộ phận Dịch vụ.
 Hoàn thành đúng hạn việc xem xét định kỳ hệ thống và Phân
tích Rủi ro.
 Hoàn thành đúng h ạn việc phân tích đ ịnh kỳ lợi ích-chi phí đã
thiết lập cho Phân tích Tác đ ộng Lỗi Thành ph ần đối với cơ sở
hạ tầng.
 Tỷ lệ phần trăm giảm trong các lỗi của hiệu suất bên thứ ba
trên MTRS/MTBF so với các đích nhắm m ục tiêu trong hợp
đồng.
 Thời gian đã s ử dụng để hoàn thành (hoặc cập nhật) m ột Phân
tích Rủi ro được giảm thiểu.
 Thời gian đã s ử dụng để xem xét kh ả năng phục hồi của hệ
thống được giảm thiểu.
 Thời gian đã sử dụng để hoàn thành m ột Kế hoạch về Tính
sẵn sàng được giảm thiểu.
 Hoàn thành đúng h ạn các báo cáo qu ản lý.
 Tỷ lệ phần trăm giảm trong các đánh giá ho ạt động phát hiện
ra các biểu lộ bảo m ật và độ tin cậy trong các thiết kế ứng
dụng.

Quy trình Quản lý Tính sẵn sàng nên duy trì m ột AMIS có chứa m ọi
thước đo và thông tin c ần thiết để hoàn thành quy trình Qu ản lý Tính
sẵn sàng và cung c ấp những thông tin phù h ợp cho doanh nghiệp về
m ức độ của dịch vụ CNTT đã được cung c ấp. Thông tin này, bao
trùm các dịch vụ, thành ph ần và các d ịch vụ hỗ trợ, cung cấp cơ sở
cho báo cáo về tính sẵn sàng định kỳ, đột xuất và ngoại lệ và xác
định xu hướng trong d ữ liệu để thúc đẩy các hoạt động cải tiến.
Những hoạt động này và thông tin đư ợc bao hàm trong AMIS cung
cấp cơ sở cho việc phát triển nội dung của Kế hoạch về Tính sẵn
sàng.
Nhằm cung c ấp cấu trúc và s ự tập trung cho m ột loạt các sáng ki ến
m à có thể cần thiết để thực hiện cải tiến về tính sẵn sàng, m ột Kế
hoạch về Tính sẵn sàng nên được hình thành và duy trì. K ế hoạch
về Tính sẵn sàng nên có các m ục đích, m ục tiêu và các sản phẩm có
thể chuyển giao đư ợc và nên xem xét nh ững vấn đề rộng hơn về con
người, các quy trình, công c ụ và kỹ thuật cũng như là có m ột sự tập
trung vào công ngh ệ. Trong giai đo ạn khởi đầu, nó có th ể được liên
kết với việc triển khai m ột kế hoạch cho Qu ản lý Tính sẵn sàng,
nhưng cả hai là khác nhau, và không nên b ị nhầm lẫn. Khi quy trình
Quản lý Tính s ẵn sàng đã trư ởng thành, kế hoạch nên phát tri ển để
bao gồm những điều dưới đây:
 Mức độ của tính s ẵn sàng trong th ực tế so với m ức độ của

tính sẵn sàng đã được thỏa thuận đối với các dịch vụ CNTT
chủ yếu. Các thư ớc đo tính sẵn sàng nên thường xuyên tập
trung vào doanh nghi ệp và khách hàng và báo cáo v ề tính sẵn

215
sàng như đư ợc trải nghiệm bởi doanh nghiệp và người sử
dụng.
 Các hoạt động được tiến hành để giải quyết sự thiếu hụt tính
sẵn sàng đối với các dịch vụ CNTT hiện hữu. Khi các quy ết
định đầu tư là cần thiết, các lựa chọn cùng với chi phí và lợ i
ích tương ứng nên được bao gồm .
 Chi tiết về những thay đổi trong các yêu c ầu về tính sẵn sàng
đối với các dịch vụ CNTT hiện t ại. Kế hoạch nên ghi nh ận lại
các tùy ch ọn sẵn có để đáp ứng những yêu cầu đã đư ợc thay
đổi. Khi các quy ết định đầu tư là cần thiết, chi phí tương ứng
cho từng lựa chọn cũng nên được bao gồm .
 Chi tiết về những yêu cầu về tính s ẵn sàng đối với các dịch vụ
CNTT m ới sắp tới. Kế hoạch nên ghi nhận lại các tùy ch ọn có
sẵn để đáp ứng những yêu cầu m ới này. Khi các quy ết định
đầu tư là c ần thiết, chi phí tương ứng cho t ừng lựa chọn cũng
nên được bao gồm .
 Một lịch trình hướng tới tương lai cho các nhi ệm vụ SFA đã
được lập kế hoạch.
 Các đánh giá thường xuyên đối với các nhiệm vụ SFA nên
được hoàn thành đ ể đảm bảo rằng tính sẵn sàng c ủa công
nghệ đang được cải thiện m ột cách chủ động cùng với SIP.
 Một bộ phận tương lai công ngh ệ để cung c ấp chỉ báo về
những lợi ích và cơ h ội khai thác ti ềm năng hiện có cho các
nâng cấp công ngh ệ đã được lập kế hoạch. Các lợi ích về khả
năng sẵn sàng đã được dự đoán phải được trình bày chi ti ết,
nếu có thể, dựa trên các biện pháp tập trung vào doanh
nghiệp, kết hợp với Quản lý Công su ất. Nỗ lực cần thiết để
hiện thực hóa những lợi ích này, nếu có thể, cũng nên được
định lượng.
Trong quá trình xây d ựng Kế hoạch, chúng tôi khuyến nghị rằng nên
thực hiện liên hệ với tất cả các lĩnh vực chức năng, k ỹ thuật và quy
trình. Kế hoạch về Tính sẵn sàng nên bao trùm m ột khoảng thời gian
từ m ột đến hai năm, với cái nhìn và thông tin chi ti ết hơn cho sáu
tháng đầu tiên. K ế hoạch nên được xem xét thường xuyên, với
những sửa đổi nhỏ m ỗi quý và những sửa đổi lớn m ỗi nửa năm.
Trong trường hợp công ngh ệ chỉ có mức độ thay đổi thấp, điều này
có thể được m ở rộng khi thích hợp.
Chúng tôi cũng khuy ến nghị rằng Kế hoạch về Tính sẵn sàng được
coi là bổ sung cho Kế hoạch Công su ất và K ế hoạch Tài chính, và ấn
phẩm đó đưuọc liên k ết với công suất và chu trình lập ngân sách
kinh doanh. Nếu một nhu cầu được dự kiến trước về mức độ sẵn
sàng cao không th ể đáp ứng được do hạn chế của cơ sở hạ tầng
hoặc ngân sách CNTT hi ện có, thì các báo cáo ngo ại lệ có thể được
yêu cầu để được cả quản lý CNTT c ấp cao và qu ản lý doanh nghi ệp
chú ý đến.
Nhằm tạo điều kiện thuận lợi cho việc đưa ra Kế hoạch về Tính sẵn
sàng, Quản lý Tính sẵn sàng có th ể sẽ m uốn cân nhắc việc có kho
lưu trữ cơ sở dữ liệu của riêng m ình. AMIS có thể được sử dụng để

216
ghi nhận lại và lưu trữ dữ liệu đã chọn và thông tin cần thiết để h ỗ
trợ các hoạt động chính yếu như t ạo báo cáo, phân tích th ống kê,
dự báo và lập kế hoạch về tính sẵn sàng. AMIS ph ải là kho lưu tr ữ
chính để ghi lại các chỉ số, thước đo, m ục tiêu và tài liệu về tính sẵn
sàng của CNTT, bao g ồm Kế hoạch về Tính sẵn sàng, các thước đo
tính sẵn sàng, báo cáo thành tích, báo cáo phân công SFA, tiêu chí
thiết kế, kế hoạch hành động và lịch trình thử nghiệm .
Hãy thực dụng, xác đ ịnh các yêu c ầu về công cụ ban đầu và xác
định những gì đã th ực sự được triển khai có thể được sử dụng và
chia sẻ để bắt đầu nhanh nh ất có thể. Khi các công c ụ cơ bản
chưa thực sự sẵn sàng, hãy làm việc với các quy trình qu ản lý hệ
thống và dịch vụ CNTT khác đ ể xác định các yêu cầu chung nhằm
m ục đích lựa chọn các công cụ được chia sẻ và tối thiểu hóa chi
phí. AMIS nên giải quyết các nhu c ầu báo cáo cụ thể về Quản lý
Tính sẵn sàng hi ện không được cung cấp bởi các kho lưu tr ữ
hiện có và tích hợp với chúng và n ội dung c ủa chúng.
.
rủi ro
Quản lý Tính sẵn sàng đ ối m ặt với rất nhiều thách thức, nhưng có lẽ
thách thức chủ yếu là đáp ứng thực tế những kỳ vọng của khách
hàng, của doanh nghi ệp và của quản lý cấp cao. Những kỳ vọng này
là về việc các dịch vụ đó sẽ luôn luôn sẵn sàng không ch ỉ trong giờ
dịch vụ đã được thỏa thuận của chúng m à m ọi dịch vụ sẽ sẵn sàng
trên cơ sở 24 giờ m ỗi ngày, và 365 ngày. Khi chúng không s ẵn
sàng, chúng đư ợc giả định là sẽ được khôi phục chỉ trong vài phút.
Điều này chỉ xảy ra khi m ức đầu tư và thi ết kế tương xứng đã đư ợc
áp dụng đối với dịch vụ, và chỉ nên được thực hiện khi tác động kinh
doanh biện m inh được cho m ức đầu tư đó. Tuy nhiên, thông đi ệ p
cần đưuọc công b ố đến m ọi khách hàng và m ọi lĩnh vực của doanh
nghiệp, để từ đó khi các d ịch vụ bị lỗi, chúng có đư ợc m ức độ kỳ
vọng phù hợp về sự khôi phục của chúng. Đi ều này cũng có nghĩa là
Quản lý Tính sẵn sàng ph ải tiếp cận được m ức độ thông tin ch ất
lượng phù hợp về nhu cầu kinh doanh hi ện tại đối với các dịch vụ
CNTT và các kế hoạch của nó cho tương lai. Đây là m ột thách thức
khác m à rất nhiều quy trình Quản lý Tính sẵn sàng phải đối m ặt.
Quản lý Tính s ẵn sàng cũng đang đ ối m ặt với m ặt với m ột thách

thức khác là việc tích hợp m ọi dữ liệu về tính sẵn sàng thanh m ột
tập hợp thông tin được tích hợp (AMIS) có th ể được phân tích theo
m ột cách nhất quán để cung cấp chi ti ết về tình trạng sẵn sàng của
m ọi dịch vụ và thành phần. Đây là m ột thách thức phổ biến khi thông
tin từ các công ngh ệ khác nhau thường được cung c ấp bởi các côn g
cụ khác nhau dưới các định dạng khác nhau.
Vẫn còn m ột thách thức khác m à Quản lý Tính s ẵn sàng phải đối
m ặt là việc thuyết phục doanh nghiệp và quản lý cấp cao về khoả n
đầu tư cần thiết vào các bi ện pháp sẵn sàng chủ động. Khoản đầu
tư luôn được công nhận khi đã xảy ra lỗi, nhưng khi đó th ực sự là

217
quá m uộn. Thuyết phục doanh nghi ệp và khách hàng đ ầu tư vào kh ả
năng phục hồi để tránh những lỗi m ột cách chủ động có thể xảy ra là
m ột thách thức đầy khó khăn. Qu ản lý Tính s ẵn sàng nên làm vi ệc
m ột cách chặt chẽ với Quản lý Liên tục Dịch vụ, Quản lý Bảo m ật và
Quản lý Công su ất trong việc đưa ra những biện m inh cần thiết để
đảm bảo m ức đầu tư thích đáng.
Các CSF (Yếu tố Thành công Quan tr ọng) đối với Quản lý Tính s ẵn
sàng là:
 Quản lý tính s ẵn sàng và độ tin cậy của dịch vụ CNTT.

 Thỏa m ãn các nhu c ầu của doanh nghi ệp đối với việc tiếp cận
các dịch vụ CNTT.
 Tính sẵn sàng của cơ sở hạ tầng CNTT, như đã đư ợc lập
thành văn bản trong SLA, được cung c ấp với chi phí t ối ưu.
Một số những rủi ro chính tương ứng với Quản lý Tính sẵn sàng là:
 Thiếu cam kết từ phía doanh nghiệp cho quy trình Qu ản lý

Tính sẵn sàng.
 Thiếu cam kết từ phía doanh nghi ệp và thiếu thông tin tương
xứng về các k ế hoạch và chiến lược tương lai.
 Thiếu cam kế của quản lý cấp cao hoặc thiếu tài nguyên
và/hoặc ngân sách cho quy trình Qu ản lý Tính s ẵn sàng.
 Các quy trình báo cáo tr ở nên rất tốn công s ức.
 Các quy trình t ập trung quá m ức vào công nghệ và không t ập
trung đủ vào các dịch vụ và các nhu cầu của doanh nghiệp.
 Thông tin Quản lý Tính s ẵn sàng (AMIS) được duy trì m ột cách
biệt lập và không được chia s ẻ hoặc không nhất quán với các
lĩnh vực quy trình khác, đ ặc biệt là ITSCM, Qu ản lý Bảo m ật
và Quản lý Công suất. Khoản đầu tư này đặc biệt quan trọng
khi xem xét các công c ụ, công ngh ệ và quy trình sao lưu và
khôi phục cho dịch vụ và thành ph ần cần thiết để đáp ứng các
nhu cầu đã được thỏa thuận.
4.5 Quản lý Liên tục Dịch vụ CNTT

4.5.1 Mục đích/đích đ ến/các mục tiêu
‘Mục đích của ITSCM là đ ể hỗ trợ quy trình Qu ản lý Liên tục
Kinh doanh tổng thể bằng cách đảm bảo rằng công nghệ CNTT
và các phương ti ện dịch vụ cần thiết (bao gồm hệ thống máy
tính, mạng, ứng dụng, kho lưu trữ dữ liệu, viễn thông, môi
trường, hỗ trợ k ỹ thuật và Bộ phận Hổ trợ) có thể được ti ếp tục
trong khoảng th ời gian làm việc đã được thỏa thu ận và cần
thiết.’
Khi công nghệ là thành ph ần cốt lõi của hầu hết m ọi quy trình nghiệ p
vụ, CNTT được tiếp tục hoặc có tính sẵn sàng cao là y ếu t ố quan
trọng đối với sự tồn tại của toàn bộ doanh nghi ệp. Điều này có th ể
đạt được bằng cách đưa ra các bi ện pháp gi ảm thiểu rủi ro và các
tùy chọn khôi phục. Giống như m ọi thành ph ần của ITSM, vi ệc triển
khai thành công ITSCM ch ỉ có thể đạt được với cam kết của quản lý

218
cấp cao và s ự hỗ trợ của m ọi thành viên c ủa tổ chức. Việc duy trì
liên tục khả năng khôi ph ục là điều thiết yếu nếu nó vẫn còn cầ n
thiết. Mục đích c ủa ITSCM là đ ể duy trì năng l ực khôi phục liên tục
cần thiết trong các dịch vụ CNTT và các thành ph ần hỗ trợ của
chúng.
Mục tiêu c ủa ITSCM là để:
 Duy trì m ột bộ các Kế hoạch Liên t ục Dịch vụ CNTT và k ế

hoạch khôi phục CNTT hỗ trợ cho các Kế hoạch Liên tục Kinh
doanh (BCP) t ổng thể của tổ chức.
 Hoàn thành các bài t ập Phân tích Tác đ ộng Kinh doanh thư ờng
xuyên để đảm bảo rằng m ọi kế hoạch liên tục đều được duy trì
tương xứng với thay đổi trong các yêu c ầu và tác động kinh
doanh.
 Tiến hành các bài t ập Phân tích và Qu ản lý Rủi ro, đặc biệt khi
kết hợp với các quy trình nghi ệp vụ và Quản lý Tính sẵn sàng
và Quản lý Bảo m ật đang quản lý các dịch vụ CNTT theo m ột
m ức rủi ro kinh doanh đã đư ợc thỏa thuận.
 Cung cấp khuyến cáo và hư ớng dẫn cho m ọi lĩnh vực củ a
doanh nghi ệp và CNTT về m ọi vấn đề liên quan đ ến tính liên
tục – và khôi phục.
 Đảm bảo rằng các cơ chế khôi phục và liên t ục thích đáng là
có sẵn để đáp ứng hoặc vượt quá các đích nh ắm m ục tiêu liên
tục kinh doanh đã được thỏa thuận.
 Đánh giá tác động của m ọi thay đổi đối với các Kế hoạch Liên
tục Dịch vụ CNTT và các k ế hoạch khôi ph ục CNTT.
 Đảm bảo rằng các biện pháp ch ủ động để cải thiện tính sẵn
sàng của các dịch vụ được triển khai bất cứ khi nào chi phí
cho việc này là hợp lý.
 Thương thảo và thỏa thuận với các nhà cung c ấp về các hợp
đồng cần thiết cho việc cung cấp năng lực khôi phục cần thiết
để hỗ trợ m ọi kế hoạch liên tục kết hợp với quy trình Qu ản lý
Nhà cung c ấp.
4.5.2 Phạm vi
ITSCM t ập trung vào nh ững sự kiện mà doanh nghi ệp xem xét là đ ủ
quan trọng để được coi là m ột thảm họa. Các sự kiện ít quan trọng
hơn sẽ được xử lý như là m ột phần của quy trình Qu ản lý S ự cố.
Những gì cấu thành nên m ột thảm họa sẽ khác nhau gi ữa các tổ
chức. Tác động t ổn thất đối với quy trình nghiệp vụ, chẳng hạn như
tổn thất tài chính, thi ệt hại về danh tiếng hoặc vi phạm quy định,
được đo lường thông qua bài t ập BIA, xác đ ịnh các yêu cầu quan
trọng tối thiểu. Các yêu c ầu dịch vụ và kỹ thuật CNTT cụ thể được
hỗ trợ bởi ITSCM. Ph ạm vi của ITSCM trong m ột tổ chức được xác
định bởi cấu trúc, văn hóa và đ ịnh hướng chiến lược (về cả kinh
doanh lẫn công ngh ệ) của tổ chức về m ặt các dịch vụ đã được cung
cấp và chúng đư ợc phát triển và thay đổi như thế nào theo thời
gian.

219
ITSCM chủ yếu xem xét các tài sản và cấu hình CNTT hỗ trợ cho
các quy trình nghi ệp vụ. Nếu (sau m ột thảm họa) cần thiết phải di
dời đến m ột nơi làm việc thay thế, cũng s ẽ cần phải cung cấp các
hạng m ục như chỗ ở cho nhân viên và văn phòng, b ản sao các h ồ
sơ giấy tờ quan tr ọng, dịch vụ chuyển phát nhanh và phương ti ện
điện thoại để giao tiếp với khách hàng và các bên th ứ ban.
Phạm vi sẽ cần phải tính đến số lượng và vị trí của các văn phòng
của tổ chức và những dịch vụ được thực hiện bởi m ỗi văn phòng.
ITSCM thường không bao trùm tr ực tiếp những rủi ro dài hạn chẳng
hạn như những thay đổi trong định hướng kinh doanh, đa d ạng hóa,
tái cấu trúc, thất bại của đối thủ cạnh tranh lớn, v.v… Mặc dù những
rủi ro này có th ể có m ột tác động đáng k ể đến các thành phần của
dịch vụ CNTT và các cơ chế liên tục của chúng, nhưng thư ờng thì
sẽ có thời gian để xác định và đánh giá r ủi ro và bao g ồm sự giảm
thiểu rủi ro thông qua nh ững thay đổi hoặc chuyển đổi trong các
chiến lược kinh doanh và CNTT, t ừ đó trở thành m ột phần của
chương trình Quản lý Thay đổi CNTT tổng thể.
Tương t ự, ITSCM cũng không thư ờng bao phủ những lỗi kỹ thuật
không đáng kể (ví dụ, m ột lỗi đĩa không quan tr ọng), trừ khi có kh ả
năng tác động có thể đáng kể đối với doanh nghi ệp. Những rủi r o
này sẽ được kỳ vọng là được bao trùm chủ yếu thông qua Bộ phận
Dịch vụ và quy trình Qu ản lý Sự cố, hoặc được xử lý thông qua việc
hoạch định tương ứng với các quy trình về Quản lý Tính sẵn sàng,
Quản lý Vấn đề, Quản lý Thay đổi, Quản lý Cấu hình và qu ản lý vậ n
hành ‘doanh nghiệp như bình thường’
Quy trình ITSCM bao g ồm :
 Thỏa thuận về phạm vi của quy trình ITSCM và các chính sác h
được thông qua.
 Phân tích Tác đ ộng Kinh doanh (BIA) đ ể định lượng tác động
của tổn thất của dịch vụ CNTT có thể có đối với doanh nghiệp.
 Phân tích R ủi ro (RA) – xác định và đánh giá r ủi ro để xác định
những nguy cơ ti ềm tàng đối với tính liên t ục và khả năng
những nguy cơ đó tr ở thành hiện thực. Việc này cũng bao gồm
việc thực hiện các biện pháp để quản lý những nguy cơ đã
được xác định khi việc này có thể hợp lý về chi phí.
 Đưa ra m ột chiến lược ITSCM t ổng thể m à cần phải được tích
hợp vào chi ến lược BCM. Đi ều này có thể được thực hiện sau
hai bước đã xác đ ịnh ở trên, và có kh ả năng bao gồm các
thành phần của việc giảm thiểu rủi ro cũng như s ự lựa chọn
các tùy chọn khôi phục thích hợp và toàn di ện.
 Đưa ra k ế hoạch ITSCM, m ột lần nữa, phải được tích hợp vớ i
các kế hoạch BCM t ổng thể.
 Sự kiểm nghiệm các kế hoạch.
 Vận hành và duy trì liên t ục các kế hoạch.

220
ITSCM cung cấp m ột vai trò vô giá trong vi ệc hỗ trợ quy trình Hoạch
định Liên tục Kinh doanh. T ại rất nhiều tổ chức, ITSCM được sử
dụng để nâng cao nhận thức về các yêu c ầu liên t ục và yêu c ầu khôi
phục và cũng thư ờng được sử dụng để biện m inh và triển khai m ột
quy trình Ho ạch định Liên t ục Kinh doanh và các K ế hoạch Liên t ục
Kinh doanh. ITSCM nên đư ợc định hướng bởi các r ủi ro kinh doanh
như được xác định bởi Hoạch định Liên tục Kinh doanh, và đ ảm bảo
rằng các thỏa thuận khôi phục đối với các dịch vụ CNTT được liên
kết với những tác động, rủi ro và nhu c ầu của việc kinh doanh.

Một phương pháp ti ếp cận kiểu vòng đ ời nên được áp dụng để thiết
lập và vận hành quy trình ITSCM. Hình 4.21 m inh h ọa cho vòng đời
của ITSCM, t ừ khi bắt đầu đên đảm bảo liên t ục rằng sự bảo vệ
được cung c ấp bởi kế hoạch là hiện hành và ph ản ảnh m ọi thay đổi
đối với các dịch vụ và m ức dịch vụ. ITSCM là m ột quy trình theo chu
trình thông qua vòng đ ời để đảm bảo rằng m ột khi các k ế hoạch liên
tục và khôi ph ục dịch vụ đã được phát tri ển, chúng vẫn được giữ
liên kết với các K ế hoạch Liên tục Kinh doanh (BCP) và các ưu tiên
của doanh nghi ệp. Hình 4.21 cũng cho th ấy vai trò của BCM trong
quy trình ITSCM
Hình 4.21 – Vòng đời của Quản lý Liên tục Dịch vụ
Các giai đo ạn bắt đầu và yêu c ầu chủ yếu là các hoạt động BCM.
ITSCM chỉ nên tham gia vào các giai đo ạn này để hỗ trợ cho các
hoạt động BCM và để hiểu m ối quan hệ giữa các quy trình kinh
doanh và các tác đ ộng gây ra đối với chúng do tổn thất dịch vụ
CNTT. Là k ết quả của các hoạt động BIA và Phân tích Rủi ro ban
đầu này, BCM nên đưa ra Chi ến lược Liên t ục Kinh doanh và nhi ệm
vụ thực sự đầu tiên của ITSCM là tạo ra m ột chiến lược ITSCM làm
cơ sở cho chiến lược BCM và các nhu c ầu của nó.

221
Chiến lược Liên tục Kinh doanh chủ yếu nên t ập trung vào các qu y
trình nghiệp vụ và các vấn đề liên quan (ví dụ: tính liên tục của quy
trình nghiệp vụ, tính liên t ục của nhân viên, tính liên t ục của các tòa
nhà). Khi Chiến lược Liên t ục Kinh doanh đã đư ợc xây dựng và vai
trò m à các dịch vụ CNTT phải cung c ấp trong chi ến lược đã được
xác định thì m ột chiến lược ITSCM có thể được tạo ra để hỗ trợ và
cho phép Chi ến lược Liên tục Kinh doanh. Đi ều này đảm bảo rằng có
thể đưa ra các quyết định hiệu quả về chi phí, xem xét m ọi ‘nguồn
lực’ để đưa ra m ột quy trình nghiệp vụ. Không làm được điều này có
xu hướng khuyến khích các l ựa chọn ITSCM nhanh hơn, ph ức tạp
hơn và t ốn kém hơn so với thực tế cần thiết.
Các hoạt động được xem xét trong quá trình b ắt đầu phụ thuộc vào
m ức độ áp dụng các phương ti ện liên tục trong tổ chức. Một số bộ
phận của doanh nghi ệp có thể đã thiết lập các K ế hoạch Liên t ục
Kinh doanh riêng l ẻ dựa trên các giải pháp thủ công và CNTT có th ể
đã phát tri ển các k ế hoạch liên tục cho các h ệ thống được coi là
quan tr ọng. Đây là đ ầu vào t ốt cho quy trình. Tuy nhiên , hiệu quả
của ITSCM phụ thuộc vào việc hỗ trợ các chức năng nghi ệp vụ quan
trọng. Cách duy nh ất để triển khai ITSCM hiệu quả là thông qua vi ệc
xác định các quy trình nghi ệp vụ quan trọng và phân tích và đi ều
phối công nghệ cần thiết và các dịch vụ CNTT hỗ trợ.
Tình huống này th ậm chí có thể phức t ạp hơn trong các tình hu ống
thuê ngoài m à trong đó quy trình ITSCM trong m ột nhà cung c ấp
dịch vụ bên ngoài ho ặc tổ chức thuê ngoài phải đáp ứng các nhu
cầu không chỉ của quy trình và chi ến lược BCM của khách hàng m à
còn của quy trình và chiến lược BCM của riêng bên thuê ngoài.
Những nhu cầu này có th ể xung đột với nhau hoặc có thể xung đột
với nhu c ầu BCM c ủa m ột trong những khách hàng khác c ủa t ổ chức
thuê ngoài.
Tuy nhiên, trong r ất nhiều tổ chức, BCM vắng m ặt hoặc có rất ít sự

tập trung, và thường thì ITSCM được yêu c ầu để đáp ứng nhiều yêu
cầu và hoạt động c ủa BCM. Phần còn lại của phần này giả định rằng
ITSCM đã phải thực hiện rất nhiều hoạt động theo yêu cầu của BCM.
Khi quy trình BCM đư ợc thiết lập cùng với các Chiến lược và Kế
hoạch Liên t ục Kinh doanh, các tài li ệu này phải cung c ấp trọng tâm
và định hướng cho vi ệc thiết lập ITSCM.

Phần sau đây bao g ồm nhiều chi tiết về m ỗi giai đo ạn trong vòng đời
của ITSCM.
4.5.5.1 Giai đoạn 1 – Khởi đầu

Quá trình khởi đầu bao phủ toàn bộ tổ chức và bao gồm những hoạt
động sau đây:
 Thiết lập chính sách – điều này nên được thiết lập và truyền
đạt càng sớm càng tốt để từ đó m ọi thành viên c ủa t ổ chức
tham gia vào, ho ặc chịu ảnh hưởng bởi các vấn đề Liên tục

222
Kinh doanh, nh ận thức được trách nhi ệm của họ để tuân thủ
và hỗ trợ cho ITSCM. T ối thiểu, chính sách phải đề ra dự định
và m ục tiêu quản lý.
 Xác định các điều khoản tham chiếu và phạm vi – điều này
bao gồm việc xác định phạm vi và trách nhiệm của m ọi nhân
viên trong t ổ chức. Nó bao hàm những tác vụ chẳng hạn như
thực hiện Phân tích Rủi ro và Phân tích Tác đ ộng Kinh doanh
và xác định cấu trúc chỉ huy và ki ểm soát cần thiết để hỗ trợ
việc kinh doanh b ị gián đoạn. Cũng c ần phải tính đến những
vấn đề như các đi ểm đánh giá vượt trội, các quy đ ịnh hoặc
yêu cầu của khách hàng và nh ững quy định của tổ chức bảo
hiểm , và tuân thủ các tiêu chu ẩn như ISO 27001, Tiêu chu ẩn
về Quản lý B ảo m ật Thông tin, cũng xác đ ịnh các yêu cầu Liên
tục Dịch vụ.
 Phân bổ tài nguyên – việc thiết lập một m ôi trường Liên tục
Kinh doanh hiệu quả đòi hỏi những tài nguyên đáng k ể xét cả
về m ặt tiền bạc lẫn nhân lực. Phụ thuộc vào m ức độ trưởng
thành của t ổ chức, có liên quan t ới ITSCM, có th ể có m ột yêu
cầu làm quen và/ hoặc đào t ạo nhân viên đ ể hoàn thành các
nhiệm vụ của Giai đoạn 2. Ngoài ra, vi ệc sử dụng các chuyên
gia tư vấn từ bên ngoài có thể giúp cho vi ệc hoàn thành phân
tích nhanh chóng hơn. Tuy nhiên, đi ều quan tr ọng là sau đó t ổ
chức có thể duy trì tiến trình liên tục hướng về phía trước m à
không c ần phải hoàn toàn d ựa vào sự hỗ trợ từ bên ngoài
 Xác định cấu trúc kiểm soát và tổ chức dự án – các dự án
ITSCM và BCM có kh ả năng phức tạp và cần được tổ chức và
kiểm soát tốt. Chúng tôi đ ặc biệt khuyến cáo nên sử dụng
phương pháp l ập kế hoạch tiêu chu ẩn đã được công nhận như
Project IN a Controlled Environm ent (PRINCE2®) ho ặc Project
Managem ent Body of Knowledge (PMBOK®).
 Thống nhất các kế hoạch ch ất lượng và kế hoạch dự án –
các kế hoạch cho phép d ự án được kiểm soát và những biến
đổi được xác đ ịnh. Các k ế hoạch chất lượng đảm bảo rằng
những sản phẩm có thể chuyển giao là đ ạt được và với m ột
m ức chất lượng có thể chấp nhận được. Chúng cũng cung c ấp
m ột cơ chế cho việc truyền thông các yêu c ầu tài nguyên và
các sản phẩm có thể chuyển giao đư ợc của dự án, từ đó c ó
được ‘sự tín nhiệm ’ của tất cả các bên liên quan.
4.5.5.2 Giai đoạn 2 – Các yêu cầu và chi ến lược

Việc xác định các yêu c ầu kinh doanh đổi với liên tục dịch vụ CNTT
là m ột thành phần quan trọng để xác định m ức độ tồn tại của m ột tổ
chức tốt đến m ức nào sau khi gián đo ạn kinh doanh ho ặc sau m ột
thảm họa và các chi phí (m à doanh nghi ệp) sẽ phải gánh ch ịu. Nếu
phân tích yêu c ầu không chính xác, ho ặc thông tin quan tr ọng bị bỏ
sót sẽ có thể dẫn đến những hậu quả nghiêm trọng đối với hiệu quả
của các cơ chế ITSCM.
Giai đoạn này có th ể được tách ra thành hai ph ần m ột cách hiệu quả
như sau:

223
 Các yêu cầu – hoàn thành Phân tích Tác đ ộng Kinh doanh và
phân tích rủi ro.
 Chiến lược – bước tiếp theo sau phân tích yêu c ầu, chiến
lược nên ghi nh ận lại các biện pháp giảm thiểu rủi ro và các
tùy chọn khôi ph ục cần thiết để hỗ trợ doanh nghiệp.
Các yêu cầu – Phân tích Tác đ ộng Kinh doanh

Mục đích của Phân tích Tác đ ộng Kinh doanh (BIA) là đ ể định lượng
tác động đối với doanh nghi ệp m à tổn thất dịch vụ sẽ gây ra. Tác
động này có th ể là tác động ‘cứng’ có thể được xác định m ột cách
chính xác – chẳng hạn như tổn thất tài chính – hoặc tác động ‘m ềm ’
– chẳng hạn như quan h ệ công chúng, đạo đức, sức khỏe và an toàn
hoặc m ất lợi thế cạnh tranh. BIA sẽ xác định những dịch vụ quan
trọng nhất đối với tổ chức và do đó s ẽ trở thành đầu vào chủ yếu
của chiến lược.
BIA xác định:
 Hình thức m à thi ệt hại hoặc tổn thất có thể xảy ra – ví dụ:
o Mất doanh thu.
o Chi phí bổ sung.
o Tổn hại đến danh tiếng.
o Mất thiện chí.
o Mất lợi thế cạnh tranh.
o Vi phạm luật pháp, an toàn và s ức khỏe.
o Rủi ro đối với an toàn cá nhân.
o Mất thị phần ngay trước m ắt và về lâu dài.
o Sự khó chịu về chính trị, công ty ho ặc cá nhân.
o Mất năng l ực vận hành – ví dụ, trong m ột m ôi trường chỉ
huy và ki ểm soát.
 Mức độ thiệt hại hoặc tổn thất có khả năng leo thang như th ế
nào sau m ột gián đoạn dịch vụ, và thời gian tính b ằng ngày,
tuần, tháng hoặc năm khi sự gián đoạn sẽ nghiêm trọng nhất.
 Nhân sự, kỹ năng, cơ sở vật chất và dịch vụ (bao gồm các
dịch vụ CNTT) cần thiết để cho phép các quy trình nghi ệp vụ
thiết yếu và quan tr ọng tiếp tục hoạt động ở m ức tối thiểu có
thể chấp nhận được.
 Thời gian m à m ức độ tối thiểu của nhân s ự, cơ sở hạ tầng và
dịch vụ nên được khôi phục.
 Thời gian m à m ọi quy trình nghi ệp vụ cần thiết và hỗ trợ nhân
sự, cơ sở hạ tầng và dịch vụ nên được khôi phục.
 Độ ưu tiên khôi ph ục nghiệp vụ tương đối cho m ỗi dịch vụ
CNTT.
Một trong những đầu ra chủ yếu từ bài t ập BIA là m ột biểu đồ của
những tác động kinh doanh được dự báo gây ra bởi tổn thất quy
trình nghiệp vụ hoặc tổn thất của m ột dịch vụ CNTT theo thời gian,
như được m inh họa trong Hình 4.22.

224
Hình 4.22 – Trình bày d ạng đồ họa của các tác động kinh doanh
Biểu đồ này có thể được sử dụng để định hướng cho các chi ến lược
và các k ế hoạch liên tục CNTT và liên t ục kinh doanh. Cần áp dụng
nhiều hơn nữa các bi ện pháp m ang tính phòng ng ừa liên quan đ ến
những quy trình và dịch vụ có tác động sớm và cao hơn, trong khi
nên nhấn m ạnh đến các biện pháp liên t ục và khôi ph ục đối với
những quy trình và dịch vụ có tác động thấp hơn và cần nhiều thời
gian hơn đ ể phát tri ển. Một phương pháp tiếp cận cân bằng giữa hai
biện pháp nên được áp dụng cho những quy trình và d ịch vụ nằm ở
khoảng giữa.
Các m ục này cung cấp các định hướng cho m ức độ của các cơ chế
ITSCM cần được xem xét ho ặc triển khai. Sau khi đã đư ợc trình bày
với các tùy ch ọn này, doanh nghi ệp có thể quyết định rằng m ức độ
dịch vụ thấp hơn hoặc sự chậm trễ gia tăng có th ể được chấp nhận
hơn, dựa trên phân tích chi phí - lợi ích, hoặc có thể các biện pháp
phòng ngừa thảm họa toàn diện sẽ cần phải được triển khai.
Những đánh giá này cho phép ánh x ạ các thành ph ần dịch vụ, ứng
dụng và công ngh ệ quan trọng với các quy trình nghi ệp vụ quan
trọng, do đó giúp xác đ ịnh các yếu tố ITSCM cần được cung c ấp.
Các yêu cầu nghiệp vụ được xếp hạng và các yếu tố ITSCM tương
xứng được xác nh ận và được ưu tiên trong vi ệc lập kế hoạch giảm
thiểu rủi ro và ph ục hồi. Kết quả của BIA, đã được thảo luận trước
đó, là đầu vào vô giá cho m ột số lĩnh vực thiết kế quy trình bao gồm
Quản lý Mức Dịch vụ để hiểu về các mức dịch vụ cần thiết.
Các tác động nên được đo lường dựa trên các tình hu ống cụ thể đối
với m ỗi quy trình nghi ệp vụ, chẳng hạn như không có khả năng giải
quyết các giao dịch thương m ại trong quy trình xử lý trên thị trường
tiền tệ hoặc không có kh ả năng xuất hóa đơn trong m ột khoảng thời

225
gian dài ngày. M ột ví dụ là m ôi trường giao dịch thị trường tiền tệ
nơi m à việc m ất thông tin d ữ liệu thị trường có thể có nghĩa là t ổ
chức bắt đầu m ất tiền ngay lập tức vì giao dịch không th ể tiếp tục.
Thêm vào đó, khách hàng có th ể rời bỏ để đến với tổ chức khác, có
nghĩa là có ti ềm năng b ị m ất lĩnh vực kinh doanh cốt lõi. Việc m ất hệ
thống thanh toán không ngăn c ản giao dịch diễn ra, nhưng nếu các
giao dịch đã đư ợc thực hiện không thể được thanh toán trong trong
khoảng thời gian quy định, tổ chức có thể vi phạm các quy t ắc quy
định hoặc thời hạn giải quyết và phải chịu tiền phạt và danh tiếng bị
tổn hại. Đây thực sự có thể là m ột tác động đáng kể hơn so với việc
không có khả năng giao d ịch bởi vì không thể đáp ứng kỳ vọng của
khách hàng.
Điều quan tr ọng là ph ải hiểu các tác đ ộng có thể thay đổi như thế
nào theo thời gian. Ví dụ, m ột doanh nghiệp có thể hoạt động m à
không cần m ột quy trình cụ thể trong m ột khoảng thời gian ngắn.
Trong m ột kịch bản được cân bằng, các tác đ ộng đến doanh nghi ệp
sẽ xảy ra và trở nên lớn hơn theo thời gian. Tuy nhiên, không ph ải
tất cả các tổ chức đều bị ảnh hưởng theo cách này. Trong m ột vài t ổ
chức, tác động không rõ ràng m ột cách tức thời. Tuy nhiên, tại m ột
số thời điểm , đối với bất kỳ tổ chức nào, các tác đ ộng sẽ tích lũy
đến m ức doanh nghiệp không thể hoạt động được nữa. ITSCM đ ảm
bảo rằng các phương án d ự phòng được xác định để từ đó biện
pháp thích hợp có thể được áp dụng vào thời điểm thích hợp nhằm
giữ cho các tác đ ộng kinh doanh t ừ việc gián đoạn dịch vụ là ở m ức
tối thiểu.
Khi tiến hành BIA, đi ều quan trọng là ph ải tìm kiếm quan đi ểm của
các đại diện cao c ấp cho lĩnh vực kinh doanh về tác động sau khi
m ất dịch vụ. Một điều quan tr ọng không k ém là quan đi ểm của nhân
viên giám sát và nhi ều nhân viên c ấp dưới hơn được tìm kiếm để
đảm bảo tất cả các khía c ạnh của tác động sau khi m ất dịch vụ đều
đã được xác định chắc chắn. Thường thì các cấp nhân viên khác
nhau sẽ có quan đi ểm khác nhau về tác động và t ất cả những điều
này sẽ phải được tính đến khi xây dựng chiến lược tổng thể.
Trong nhiều tổ chức, việc khôi phục t ổng dịch vụ trong m ột khoảng
thời gian r ất ngắn là điều bất khả thi, hoặc sẽ không hợp lý về chi
phí. Trong r ất nhiều trường hợp, quy trình nghiệp vụ có thể được
thiết lập lại m à không c ần bổ sung đầy đủ nhân viên, hệ thống và
các phương ti ện khác m à vẫn duy trì m ức độ dịch vụ có thể chấp
nhận được đối với khách hàng. Do đó, các m ục tiêu phục hồi hoạt
động kinh doanh c ần được trình bày dư ới dạng:
 Thời gian m à đội ngũ cán bộ cốt cán đã đư ợc xác định trước
và các cơ sở vật chất tối thiểu đã nêu phải được phục hồi.
 Thời gian biểu để phục hồi nhân viên và cơ s ở vật chất còn
lại.
Có thể không phải lúc nào cũng có th ể cung cấp các yêu c ầu khôi
phục đến m ức chi tiết. Cần phải cân bằng giữa tác động tiềm tàng

226
so với chi phí khôi ph ục để đảm bảo rằng chi phí đó có th ể chấp
nhận được. Tuy nhiên, các m ục tiêu khôi phục cung cấp m ột điểm
khởi đầu m à từ đó có thể đánh giá các tùy ch ọn phục hồi kinh doanh
và ITSCM khác nhau.
Các yêu cầu – Phân tích Rủi ro

Định hướng thứ hai cho vi ệc xác định các yêu cầu là khả năng m à
m ột thảm họa hoặc m ột sự gián đoạn dịch vụ nghiêm trọng thực tế
sẽ xảy ra. Đây là m ột đánh giá về m ức độ nguy cơ và m ức độ dễ tổn
thương của m ột tổ chức đối với nguy cơ. Phân tích R ủi ro cũng có
thể được sử dụng trong vi ệc đánh giá và gi ảm thiểu cơ hội của
những sự cố vận hành bình thường và là m ột kỹ thuật được sử dụng
bởi Quản lý Tính s ẵn sàng để đảm bảo rằng m ức độ sẵn sàng và đ ộ
tin cậy cần thiết có thể được duy trì. Phân tích R ủi ro cũng là m ột
yếu tố chủ yếu của Quản lý Dịch vụ CNTT. Một sơ đồ Phân tích và
Quản lý Rủi ro (Hình 4.20) đư ợc bao hàm trong quy trình Qu ản lý
Tính sẵn sàng trong ph ần 4.4.
Một số phương pháp Phân tích và Qu ản lý Rủi ro có s ẵn cho c ả lĩnh

vực công lẫn thương m ại. Phân tích R ủi ro là đánh giá v ề các r ủi ro
có thể làm phát sinh s ự gián đoạn dịch vụ hoặc vi pham bảo m ật.
Quản lý rủi ro có liên quan v ới việc xác định các phản ứng rủi ro
thích đáng ho ặc biện pháp ứng phó có chi phí hợp lý để chống lại
những rủi ro đó.
Một phương pháp tiêu chu ẩn, chẳng hạn như Quản lý Rủi ro
(Managem ent of Risk (M_o_R), nên đư ợc sử dụng để đánh giá và
quản lý rủi ro trong m ột tổ chức. Khuôn khổ M__o_R đư ợc m inh họa
trong hình 4.23.

227
Hình 4.23 – Quản lý Rủi ro
Phương pháp ti ếp cận Quản lý Rủi ro dựa trên khuôn kh ổ nói trên,
 Các nguyên t ắc M_o_R: các nguyên t ắc này là đi ều thiết yế u

đối với việc phát tri ển thực tiễn quản lý rủi ro hữu hiệu và có
nguồn gốc từ các nguyên tắc quản trị doanh nghiệp.
 Phương pháp ti ếp cận M_o_R: phương pháp ti ếp cận của
m ột tổ chức đối với những nguyên t ắc này cần được thống
nhất và xác đ ịnh trong nh ững tài li ệu đang hoạt động dưới
đây:
o Chính sách Quản lý Rủi ro,
o Hướng dẫn Quy trình,
o Các Kế hoạch,
o Bản đăng ký rủi ro,
o Các Nhật ký Sự cố.
 Các quy trình M_o_R: bốn bước chính dưới đây m ô tả các
đầu vào, đầu ra và các hoạt động đảm bảo rằng rủi ro được
kiểm soát:
o Xác định: những m ối đe dọa và cơ hội trong m ột hoạt
động có th ể tác động đến khả năng đạt được m ục tiêu
của nó (c ủa hoạt động).

228
o Đánh giá: hiểu biết về tác động thực chất của các m ối
đe dọa và cơ hội tương xứng với một hoạt động khi
được tổng hợp lại cùng nhau.
o Lập kế hoạch: để chuẩn bị m ột phản ứng quản lý c ụ thể
m à sẽ làm giảm thiểu m ối các đe d ọa và tối đa hóa
những cơ hội.
o Triển khai: các hành động quản lý r ủi ro đã được lập kế
hoạch, giám sát tính hi ệu quả của chúng và ti ến hành
hành động khắc phục khi m à phản ứng không đáp ứng
được những kỳ vọng.
 Nhúng và xem xét M_o_R : đưa ra các nguyên t ắc, phương
pháp tiếp cận và các quy trình t ại chỗ, chúng c ần được liên
tục xem xét và c ải tiến để đảm bảo rằng chúng vẫn có hi ệu
quả.
 Tru yền đạt: có các ho ạt động truyền thông thích hợp tại chỗ
để đảm bảo rằng m ọi người đều được cập nhật về những thay
đổi về các m ối đe dọa, những cơ hội và bất kỳ khía c ạnh nào
khác của quản lý rủi ro.
Phương pháp M_o_R này đòi h ỏi việc đánh giá r ủi ro và phát tri ển
m ột hồ sơ rủi ro, như trong ví d ụ trong Hình 4.24.
Hình 4.24 – Ví dụ về hồ sơ rủi ro tổng hợp

229
Hình 4.24 trình bày m ột ví dụ về hồ sơ rủi ro, bao gồm rất nhiều rủi
ro nằm ngoài các m ức ‘rủi ro có thể chấp nhận được’ đã được xác
định. Sau khi Phân tích R ủi ro, có thể xác định những phản ứng với
rủi ro tương ứng hoặc các biện pháp gi ảm thiểu rủi ro (các cơ chế
ITSCM) để quản lý rủi ro, nghĩa làm gi ảm thiểu rủi ro đến m ột m ức
có thể chấp nhận được hoặc giảm nhẹ rủi ro. Bất cứ khi nào có thể,
các phản ứng với rủi ro nên đư ợc triển khai để giảm thiểu hoặc tác
động hoặc khả năng xảy ra, hoặc cả hai, c ủa những rủi ro đó từ việc
chúng t ự bộc lộ. Trong b ối cảnh ITSCM, có m ột số rủi ro cần phải
được xem xét. Dư ới đây không ph ải là m ột danh sách toàn di ện
nhưng đưa ra m ột số ví dụ về các rủi ro và những m ối đe dọa cần
được giải quyết bởi quy trình ITSCM.
Bảng 4.1 Ví dụ về các rủi ro và những mối đe dọa
Rủi ro Mối đe dọa

Mất hệ thống CNTT/m ạng, Cháy
Tổng đài, ACD, v.v… n ội Mất nguồn cung c ấp điện
bộ
Đốt phá và phá ho ại
Thiệt hại do thời tiết, ví dụ, bão
Thảm họa m ôi trường
Tấn công khủng bố
Phá hoại
Lỗi nghiêm trọng
Thiệt hại do điện, ví dụ, sét
Thiệt hại do tai nạn
Phần m ềm chất lượng kém
Mất hệ thống CNTT/m ạng Mọi điều trên
bên ngoài, ví d ụ, các m áy Nhu cầu dịch vụ bị quá tải
chủ thương m ại điện tử,
hệ thống m ã hóa Tấn công t ừ chối dịch vụ, ví dụ, tấn
công tường lửa Internet
Lỗi kỹ thuật, ví dụ, hệ thống m ã hóa
Mất dữ liệu Lỗi kỹ thuật
Lỗi con người
Virus, phần m ềm độc hại, ví dụ, tấn
công applet
Mất dịch vụ m ạng Thiệt hại hoặc bị từ chối truy cập vào cơ
sở của nhà cung c ấp dịch vụ m ạng
Mất hệ thống CNTT/m ạng của nhà cung
cấp dịch vụ
Mất dữ liệu của nhà cung c ấp dịch vụ
Lỗi của nhà cung cấp dịch vụ

230
Nhân viên k ỹ thuật và Hành động công nghi ệp
nhân viên h ỗ trợ chính Bị từ chối truy cập vào cơ sở vật chất
yếu không sẵn sàng
Từ chức
Đau ốm /chấn thương
Vận chuyển khó khăn
Lỗi của nhà cung c ấp dịch Thất bại thương m ại, ví dụ, vỡ nợ
vụ, ví dụ, CNTT được Bị từ chối truy cập vào cơ sở vật chất
thuê ngoài
Nhân viên của nhà cung c ấp dịch vụ
không s ẵn sàng
Không đáp ứng các m ức dịch vụ theo
hợp đồng.
Kết quả của Phân tích Tác động Kinh doanh và Phân tích R ủi ro sẽ
cho phép các chi ến lược Liên t ục Dịch vụ CNTT và Liên t ục Kinh
doanh tương xứng được đưa ra phù h ợp với các nhu c ầu của doanh
nghiệp. Chiến lược sẽ là sự cân bằng tối ưu giữa giảm thiểu rủi ro
và các tùy ch ọn liên tục hoặc khôi phục. Điều này bao gồm việc xem
xét các ưu tiên khôi ph ục dịch vụ tương đối và những thay đổi trong
ưu tiên dịch vụ tương đối đối với thời gian trong ngày, ngày trong
tuần, và các thay đ ổi hàng tháng và hàng năm . Nh ững dịch vụ đã
được xác định là có tác động cao trong ng ắn hạn trong BIA sẽ m uốn
tập trung những nỗ lực vào các phuong pháp gi ảm thiểu rủi ro – ví
dụ, thông qua kh ả năng phục hồi đầy đủ và khả năng chịu lỗi – trong
khi m ột tổ chức có các tác động ngắn hạn thấp tốt hơn sẽ phù hợp
với các tùy chọn khôi ph ục toàn diện, như được m ô tả trong csac
phần tiếp theo đây. Bạn có thể tìm thấy những khuyến cáo và hướng
dẫn tương tự trong Hướng dẫn Thực tiễn Tốt BCI c ủa Học viện Liên
tục Kinh doanh (Business Continuity Institute).
Các biện pháp ứng phó với rủi ro

Phần lớn các t ổ chức sẽ phải áp dụng m ột phương pháp ti ếp cận
cân bằng ở nơi m à vi ệc giảm thiểu rủi ro và khôi ph ục là bổ sung
cho nhau và cả hai đều được yêu cầu. Việc này kéo theo sự giảm
thiểu, càng xa càng t ốt, những rủi ro đối với việc cung c ấp dịch vụ
CNTT và thường đạt được thông qua Quản lý Tính s ẵn sàng. Tuy
nhiên, nếu được hoạch định tốt, có thể loại trừ hoàn toàn m ọi rủi ro
– ví dụ, m ột đám cháy ở gần tòa nhà sẽ gần như chắc chắn gây ra
thiệt hại, hoặc ít nhất, từ chối quyền truy c ập, do việc triển khai các
tuyến đường bị cảnh sát cô l ập. Theo nguyên t ắc chung, vi ệc thỉnh
cầu m ột năng lực khôi ph ục chỉ nên được coi là phương sách cu ối
cùng. Một cách lý tưởng, m ột tổ chức nên đánh giá m ọi rủi ro để
giảm thiểu yêu cầu tiềm ẩn đối với việc khôi phục hoạt động kinh
doanh, có khả năng baoa g ồm các dịch vụ CNTT.
Các biện pháp gi ảm thiểu rủi ro cần được triển khai và nên đư ợc
thực hiện cùng với Quản lý Tính sẵn sàng, vì nhi ều biện pháp trong

231
số chúng làm gi ảm xác suất của lỗi có ảnh hưởng tới tính sẵn sàng
của dịch vụ. Các bi ện pháp giảm thiểu rủi ro điển hình bao gồm :
 Lắp đặt thêm bộ lưu điệ hoặc nguồn cấp điện cho m áy tính,
 Các hệ thống có tính ch ịu lỗi cho các ứng dụng quan tr ọng,
nơi m à thậm chí thời gian gián đo ạn tối thiểu cũng là không
thể chấp nhận được – ví dụ, m ột hệ thống ngân hàng,
 Các m ảng đĩa d ự phòng RAID và phản chiếu đĩa cho các m áy
chủ m ạng để ngăn ngừa việc m ất dữ liệu và để đảm bảo tính
sẵn sàng c ủa dữ liệu được liên tục.
 Các thiết bị/thành phần dự phòng đư ợc sử dụng trong những
sự kiện thiết bị hoặc thành phần bị lỗi – ví dụ, m ột m áy ch ủ
m ạng đã được thiết lập cấu hình với cấu hình tiêu chu ẩn và
sẵn sàng để thay thế cho m ột m áy chủ bị lỗi với thời gian xây
dựng và thi ết lập cấu hình t ối thiểu.
 Việc loại bỏ các SPoF, chẳng hạn như điểm truy c ập mạng
đơn lẻ hoặc nguồn cấp điện đơn lẻ cho m ột tòa nhà.
 Hệ thống CNTT và m ạng có khả năng phục hồi.
 Thuê ngoài các dịch vụ từ nhiều nhà cung c ấp.
 Kiểm soát bảo m ật vật lý và CNTT t ốt hơn.
 Kiểm soát tốt hơn để phát hiện các gián đoạn dịch vụ, chẳng
hạn như hệ thống phòng cháy, k ết hợp với các hệ thống chữa
cháy.
 Một chiến lược sao lưu và khôi ph ục toàn diện, bao gồm lưu
trữ ngoại biên.
Các biện pháp trên đây không nh ất thiết sẽ giải quyết một vấn đề
của ITSCM và loại bỏ rủi ro m ột cách hoàn toàn, nhưng t ất cả (biện
pháp) hoặc kết hợp chúng có thể làm giảm rủi ro m ột cách đáng k ể
liên quan đ ến cách thức những dịch vụ được cung cấp cho doanh
nghiệp.
Lưu trữ ngoại biên

Một trong những phương pháp ứng phó với rủi ro là đ ảm bảo m ọi dữ
liệu sống còn được sao lưu và lưu tr ữ ngoại biên. Khi chi ến lược
khôi phục đã được xác định, m ột chiến lược sao lưu tương ứng nên
được áp dụng và tri ển khai để hỗ trợ cho nó (chi ến lược khôi phục).
Chiến lược sao lưu ph ải bao gồm việc chuyển dữ liệu (bao gồm CMS
để dễ dàng khôi ph ục) thường xuyên (có thể là hàng ngày) t ừ các
trung tâm dữ liệu chính đ ến m ột vị trí lưu tr ữ ngoại biên phù hợp.
Điều này sẽ đảm bảo việc truy xuất dữ liệu sau m ột sự cố hoạt động
tương đối nhỏ (không đáng kể) cũng như s ự cố hoàn toàn và sau
m ột thảm họa đầy đủ. Cũng như dữ liệu điện tử, m ọi thông tin và tài
liệu quan trọng khác nên đư ợc lưu tr ữ ngoại biên, với ví dụ chính là
các kế hoạch ITSCM.
Các tù y chọn khôi phục ITSCM

Chiến lược ITSCM của m ột tổ chức là m ột sự cân bằng giữa chi phí
của các biện pháp gi ảm thiểu rủi ro và các tùy ch ọn khôi ph ục để hỗ
trợ việc khôi phục các quy trình nghi ệp vụ quan trọng trong nh ững
khoảng thời gian đã được thỏa thuận. Dưới đây là m ột danh sách

232
các tùy chọn khôi phục CNTT tiềm năng cần phải được xem xét khi
phát triển chiến lược.
Giải quyết thủ công

Đối với nhiều loại dịch vụ nhất định, những cách giải quyết thủ công
có thể là m ột biện pháp tạm thời có hiệu quả trong m ột khung thời
gian giới hạn cho đ ến khi dịch vụ CNTT được khôi phục. Ví dụ, m ột
dịch vụ ghi nhật ký-cuộc gọi của Bộ phận Hỗ trợ Dịch vụ có thể tồn
tại trong m ột khoảng thời gian giới hạn bằng cách sử dụng các bi ểu
m ẫu giấy được liên kết với m áy tính xách tay có b ảng tính.
Thỏa thuận đối ứng

Trong quá khứ, các thỏa thuận đối ứng đã t ừng là biện pháp d ự
phòng điển hình khi các th ỏa thuận được đưa ra với m ột tổ chức
khác sử dụng công ngh ệ tương tự. Điều này không còn hi ệu quả
hoặc khả thi cho hầu hết các loại hệ thống CNTT, nhưng vẫn có thể
được sử dụng trong những trường hợp đặc biệt – ví dụ, thiết lập m ột
thỏa thuận để chia sẻ cơ sở vật chất in ấn tốc độ cao. Các th ỏa
thuận đối ứng cũng có thể được sử dụng cho lưu tr ữ ngoại biên các
bản sao lưu và thông tin quan tr ọng khác.
Khôi phục dần dần

Tùy chọn này (đôi khi còn đư ợc gọi là ‘trạng thái chờ lạnh’) bao g ồm
việc cung c ấp chỗ ở trống, được trang bị đầy đủ nguồn cấp điện, các
kiểm soát m ôi trường và cơ sở hạ tầng cáp m ạng cục bộ, các kết nối
viễn thông, và sẵn sàng trong tình hu ống thảm họa để m ột tổ chức
lắp đặt các thiết bị m áy tính của riêng mình. Nó không bao g ồm các
thiết bị m áy tính th ực tế, so đó không thể áp dụng cho những dịc h
vụ đòi hỏi khôi ph ục nhanh chóng, vì c ần phải có thời gian thi ết lập
trước khi việc khôi ph ục dịch vụ có thể bắt đầu. Tùy chọn khôi ph ục
này chỉ được khuyến nghị cho những dịch vụ có thể chịu được sự
chậm trễ của thời gian khôi ph ục theo ngày ho ặc tuần chứ không
phải vài giờ. Bất kỳ dịch vụ không quan tr ọng nào có th ể chịu được
kiểu trì hoãn này nên tính đ ến chi phí c ủa tùy chọn so với lợi ích đối
với doanh nghiệp trước khi xác định nếu m ột tùy chọn khôi phục dần
dần nên được bao gồm trong các tùy ch ọn ITSCM cho tổ chức.
Chỗ ở có thể được cung c ấp vì m ục đích thương m ại bởi m ột bên

thứ ba, có tính phí, ho ặc có thể của tư nhân, (được thiết lập bởi bản
thân tổ chức) và đư ợc cung cấp như dịch vụ cố định hoặc di động.
Một cơ sở di động thường là m ột tòa nhà đúc s ẵn được cung c ấp

bởi m ột bên thứ ba, và được đặt – khi cần thiết – tại m ột địa điểm
được xác định trước đã thỏa thuận với tổ chức. Đây có thể là m ột
địa điểm khác cách xa khu v ực văn phòng c ủa tổ chức, có thể là m ộ
tòa nhà thu ộc sở hữu của người khác. Các thiết bị m áy tính thay th ế
sẽ cần được lên k ế hoạch, tuy nhiên nh ững nhà cung c ấp thiết bị
m áy tính thường không đ ảm bảo các thiết bị m áy tính thay thế trong
m ột thời hạn cố định, m ặc dù thông thường thì họ sẽ làm vậy với nỗ
lực hết m ình của m ình.

233
Khôi phục trung gian
Tùy chọn này (đôi khi còn đư ợc gọi là ‘trạng thái chờ ấm ’) được lựa
chọn bởi các tổ chức cần khôi phục các cơ sở CNTT trong m ột
khoảng thời gian được định trước nhằm ngăn ngừa những tác động
đối với quy trình nghi ệp vụ. Khoảng thời gian được định trước sẽ
phải được thỏa thuận với doanh nghi ệp trong quá trình BIA.
Phổ biến nhất là sử dụng các cơ sở vật chất thương m ại, vốn được
cung cấp bởi tổ chức chuyên khôi phục của bên thứ ba cho m ột số
các thuê bao, tr ải đều chi phí cho các thuê bao này. Các cơ s ở vật
chất thương m ại thường bao gồm vận hành, quản lý hệ thống và hỗ
trợ kỹ thuật. Chi phí khác nhau t ùy thuộc vào cơ sở vật chất được
yêu cầu, chẳng hạn như bộ xử lý, thiết bị ngoại vi, truyền thông, và
các dịch vụ phải được khôi phục nhanh đến m ức nào.
Ưu điểm của dịch vụ này là khách hàng có th ể tiếp cận gần như t ức
thời vào m ột địa điểm , được đặt trong m ột tòa nhà an ninh, trong
trường hợp có thảm họa. Cần phải hiểu, tuy nhiên, r ằng việc khôi
phục các dịch vụ tại địa điểm có thể cần thời gian, vì có thể gặp
phải sự chậm trễ khi địa điểm được thiết lập cấu hình lại cho t ổ
chức yêu c ầu dịch vụ, và các ứng dụng và dữ liệu của tổ chức sẽ
cần phải được khôi ph ục từ các bản sao lưu.
Một khuyết điểm lớn tiềm ẩn là tác động bảo m ật của việc vận hành
các dịch vụ CNTT tại trung tâm dữ liệu của m ột bên thứ ba. Điều
này phải được tính đến khi lập kế hoạch để sử dụng kiểu cơ sở vật
chất này. Đối với vài tổ chức, tùy chọn khôi phục trung gian t ừ bên
ngoài có thể không thích hợp vì lý do này.
Nếu địa điểm được sử dụng, thường thì sẽ có m ột khoản phí hàng
ngày để được sử dụng dịch vụ trong tình huống khẩn cấp, m ặc dù
khoản phí này có th ể được bù đắp bởi chi phí b ổ sung của bảo hiểm
công việc.
Các dịch vụ khôi phục thương m ại có thể được cung c ấp dưới dạng
khép kín, có thể di chuyển được hoặc di động khi m ột hệ thống đã
thỏa thuận được cung c ấp cho m ột địa điểm của khách hàng, trong
m ột thời gian đã th ỏa thuận.
Khôi phục nhanh

Tùy chọn này (đôi khi còn đư ợc gọi là ‘tr ạng thái chờ nóng’) cung
cấp m ột sự khôi phục và phục hồi dịch vụ nhanh chóng và th ỉnh
thoảng được cung cấp như m ột phần mở rộng của khôi phục trung
gian đã được cung cấp bởi nhà cung c ấp dịch vụ khôi phục bên thứ
ba. Vài t ổ chức sẽ cung cấp các cơ s ở vật chất thuộc sở hữu của
riêng họ trong t ổ chức, nhưng không ph ải trên m ột địa điểm thay thế
cho cơ sở được sử dụng cho các hoạt động bình thường. Những t ổ
chức khác triển khai m ột địa điểm thứ hai nội bộ của riêng mình t ại
m ột địa điểm thay thế khác để cung cấp khả năng khôi ph ục linh
hoạt hơn.

234
Khi cần khôi phục nhanh m ột dịch vụ, có thể ‘thuê’ không gian sàn
tại địa điểm khôi phục và cài đặt các m áy ch ủ hoặc các hệ thống
cùng với các hệ thống ứng dụng và truyền thông đã có s ẵn, và dữ
liệu được phản chiếu từ các m áy chủ vận hành. Trong trường hợp
hệ thống bị lỗi, khách hàng sau đó có th ể khôi phục và chuyển sang
cơ sở vật chất dự phòng m à ít b ị m ất m át dịch vụ. Điều này thư ờng
liên quan đến việc tái thiết lập lại các hệ thống và dịch vụ quan
trọng trong vòng 24 gi ờ.
Khôi phục tức thời

Tùy chọn này (thường cũng được gọi là ‘tr ạng thái chờ nóng’, ‘phản
chiếu’, ‘cân bằng t ải’ hoặc ‘tách bi ệt’địa điểm ) cung cấp kahr năng
khôi phục các dịch vụ ngay tức thời m à không bị m ất dịch vụ. Đối
với các dịch vụ quan tr ọng của doanh nghi ệp, các t ổ chức đòi hỏi sự
vận hành liên t ục sẽ cung cấp cho các cơ s ở của riêng họ trong t ổ
chức nhưng không ph ải ở cùng m ột địa điểm với các hoạt động
thông thường. Các thi ết bị CNTT đầy đủ sẽ được ‘thiết lập kép’ tại
m ột địa điểm m à tổ chức hoặc sở hữu hoặc đi thuê để chạy dịch vụ
cạnh tranh từ m ột trong hai đ ịa điểm trong trường hợp mất m ột cơ
sở m à không bị m ất dịch vụ cho khách hàng. Địa điểm thứ hai sau
đó có thể được phục hồi trong khi các dịch vụ đang được cung c ấp
từ m ột địa điểm có thể vận hành duy nhất. Đây là m ột tùy chọn tốn
kém , tuy nhiên nó có th ể biện m inh cho các quy trình nghi ệp vụ quan
trọng hoặc các VBF m à n ếu không s ẵn sàng dù chỉ trong m ột thời
gian ngắn cũng s ẽ dẫn đến m ột tác động nghiêm trọng, hoặc ở nơi
m à không thích hợp để chạy các dịch vụ CNTT trên m ột cơ sở của
bên thứ ba vì lý do an ninh ho ặc lý do khác. Cơ s ở vật chất nên
được định vị m ột cách tách bi ệt và đủ xa từ địa điểm chính đ ể nó
không bị ảnh hưởng bởi m ột thảm họa tác động đến địa điểm chính.
Tuy nhiên, nh ững m áy ch ủ được phản chiếu và các tùy chọn về địa
điểm nên được triển khai trong m ối quan hệ gần gũi với Quản lý
Tính sẵn sàng vì chúng hỗ trợ cho các dịch vụ có m ức sẵn sàng cao.
Hình 4.25 – Ví dụ về bộ các tù y chọn khôi phục
Hình 4.25 cho thấy rằng m ột số các tùy chọn có thể được sử dụng
để m ang lại tính liên t ục của dịch vụ. Một ví dụ từ Hình 4.25 cho

235
thấy rằng, ban đầu, tính liên t ục của Bộ phận Hỗ trợ Dịch dụ được
cung cấp bằng cách s ử dụng các quy trình th ủ công chẳng hạn như
m ột tập hợp các bi ểu m ẫu, và có thể là m ột bảng tính chạy trên m ột
m áy tính xách tay, trong khi các k ế hoạch khôi phục dịch vụ được
thực hiện tại m ột địa điểm ‘khôi phục nhanh’ tha y thế. Khi địa điểm
thay thế trở thành địa điểm vận hành, B ộ phận Hỗ trợ Dịch vụ có thể
quay lại sử dụng dịch vụ CNTT. Tuy nhiên, s ử dụng địa điểm thay
thế ‘khôi phục nhanh’ từ bên ngoài có thể bị giới hạn về thời lượng,
vì vậy, trong khi ho ạt động t ạm thời từ địa điểm này, ‘địa điểm trung
gian’ có th ể đưuọc vận hành và các ho ạt động dài hạn có thể được
chuyển đến đây.
Các dịch vụ khác nhau trong m ột tổ chức đòi hỏi khả năng phục hồi
tích hợp khác nhau và các tùy ch ọn khôi ph ục khác nhau. B ất kể lựa
chọn phương án nào, gi ải pháp sẽ cần phải hợp lý về chi phí. Theo
nguyên tắc chung, doanh nghi ệp có thể tồn tại càng lâu m à không
cần dịch vụ thì giải pháp đó càng r ẻ. Ví dụ, m ột hệ thống chăm sóc
sức khỏe quan trọng đòi hỏi vận hành liên t ục sẽ rất tốn kém , vì khả
năng m ất dịch vụ phải được loại trừ bằng cách sử dụng khôi phục
tức thời, trong khi đó m ột dịch vụ thiếu hụt không ảnh hưởng nghiêm
trọng đến hoạt động kinh doanh trong m ột tuần hoặc tương đương
có thể được hỗ trợ bởi giải pháp r ẻ tiền hơn nhiều, chẳng hạn như
khôi phục trung gian.
Cũng giống như vi ệc khôi phục các thiết bị m áy tính, việc hoạch định
cần phải bao gồm sự khôi phục chỗ ở và cơ sở hạ tầng cho c ả nhân
viên CNTT và ngư ời sử dụng. Những khu vực khác c ần được tính
đến bao gồm những dịch vụ quan trọng như nguồn điện, viễn thông,
nước, chuyển phát nhanh, bưu đi ện, hồ sơ giấy tờ và các tài li ệu
tham chiếu. Điều quan trọng cần phải lưu ý là vi ệc khôi ph ục dựa
trên m ột chuỗi các thỏa thuận dự phòng bao gồm chỗ ở, các thủ tục
và con người, cũng như là các hệ thống và viễn thông. Các ho ạt
động nhất định là c ần thiết để triển khai các thỏa thuận dự phòng. Ví
dụ:
 Việc thương th ảo đối với các cơ sở khôi phục của bên th ứ ba

và đưa vào thỏa thuận hợp đồng.
 Việc chuẩn bị và lắp đặt chỗ ở dự phòng.
 Việc m ua sắm và cài đặt hệ thống m áy tính dự phòng.
4.5.5.3 Giai đoạn 3 – Triển khai

Khi chiến lược đã được phê duyệt, các Kế hoạch Liên tục Dịch vụ
CNTT cần được đưa ra phù hợp với các K ế hoạch Liên t ục Kinh
doanh.
Các kế hoạch ITSCM c ần được phát tri ển để cho phép nh ững thông
tin cần thiết về các hệ thống, dịch vụ và cơ sở vật chất quan trọng
tiếp tục được cung cấp hoặc được khôi ph ục trong m ột khoảng thời
gian có th ể chấp nhận được đối với doanh nghiệp. Một ví dụ về kế
hoạch khôi phục ITSCM được nêu trong Ph ụ lục K. Nói chung, các
Kế hoạch Liên t ục Kinh doanh d ựa trên sự sẵn sàng của các dịch vụ

236
CNTT, phương ti ện và tài nguyên. Do h ệ quả của điều này, các k ế
hoạch ITSCM cần xác định t ất cả các hoạt động để đảm bảo rằng
các dịch vụ, cơ sở vật chất và nguồn lực cần thiết được cung c ấp ở
m ột trạng thái ho ạt động có thể chấp nhận được và 'phù hợp với
m ục đích' khi được doanh nghi ệp chấp nhận. Điều này không chỉ đòi
hỏi việc khôi phục các dịch vụ và cơ sở vật chất m à còn ph ải hiểu rõ
về sự phụ thuộc giữa chúng, và vi ệc kiểm nghiệm là cần thiết trước
khi cung cấp (kiểm tra hiệu suất, chức năng, hoạt động và chấ p
nhận) và xác nh ận tính toàn vẹn và nhất quán của dữ liệu.
Nên lưu ý r ằng các kế hoạch liên t ục không ch ỉ là các kế hoạch phục
hồi, và nên bao g ồm tài liệu về các biện pháp phục hồi và các bi ện
pháp đã được áp dụng để cho phép ph ục hồi, cùng với giải thích tại
sao m ột phương pháp tiếp cận cụ thể đã được thực hiện (điều này
tạo điều kiện cho các quy ết định nếu viện dẫn xác định rằng tình
huống cụ thể đòi hỏi sửa đổi lại kế hoạch). Tuy nhiên, đ ịnh dạng của
kế hoạch phải cho phép truy c ập nhanh chóng vào chính b ản thân
thông tin khôi phục, có thể dưới dạng phụ lục có thể được truy cập
trực tiếp. Tất cả các nhân viên chủ chốt phải có quyền truy cập vào
các bản sao của t ất cả các t ài liệu khôi ph ục cần thiết.
Quản lý việc phân ph ối các kế hoạch là r ất quan tr ọng để đảm bảo

rằng các bản sao luôn s ẵn sàng cho các cán b ộ chủ chốt. Các kế
hoạch phải là các tài liệu được kiểm soát (với các tài li ệu chính th ức
được duy trì dư ới sự kiểm soát của Quản lý Thay đổi và Quản lý
Cấu hình) để đảm bảo rằng chỉ những phiên bản m ới nhất được lưu
hành và m ỗi m ột người nhận phải đảm bảo rằng m ột bản sao cá
nhân được duy trì ngo ại biên.
Kế hoạch nên đảm bảo rằng m ọi chi tiết liên quan đ ến việc khôi
phục các dịch vụ CNTT sau m ột thảm họa được lập thành văn bản
m ột cách đầy đủ. Nó nên có đ ầy đủ các chi tiết để cho phép m ột
nhân viên k ỹ thuật, người không quen thu ộc với các hệ thống sẽ có
thể tuân theo các thủ tục. Các k ế hoạch khôi ph ục bao gồm các chi
tiết chẳng hạn như đi ểm khôi ph ục dữ liệu, danh sách các h ệ thống
phụ thuộc, bản chất của sự phụ thuộc và điểm khôi ph ục dữ liệu của
chúng, các yêu c ầu về hệ thống phần cứng và phần m ềm, các chi
tiết cấu hình và tham chi ếu tới thông tin liên quan ho ặc thiết yếu
khác về dịch vụ và các hệ thống.
Một ý tưởng tốt là bao g ồm m ột danh sách kiểm tra bao trùm hoạt
động cụ thể cần thiết trong m ọi giai đo ạn của khôi phục dịch vụ và
hệ thống. Ví dụ, sau khi hệ thống đã được khôi phục đến m ức hoạt
động có thể chấp nhận được, các kiểm tra kết nối, kiểm tra chức
năng, kiểm tra tính nhất quán và toàn vẹn dữ liệu nên được tiế n
hành để bàn giao dịch vụ cho doanh nghi ệp.
Có m ột số kế hoạch kỹ thuật có thể đang tồn tại trong m ột tổ chức,

ghi nhận lại các th ủ tục khôi phục từ một lỗi vận hành bình thường.
Việc phát triển và duy trì nh ững kế hoạch này sẽ là trách nhi ệm của
các nhóm chuyên gia, nhưng s ẽ được điều phối bởi nhóm Quản lý

237
Liên tục Kinh doanh. Đây s ẽ là những bổ sung hoặc phụ lục hữu ích
cho kế hoạch chính. Ngoài ra, các kế hoạch sẽ cần được tích hợp
với BCP chính là:
 Kế hoạch Ứng phó Khẩn cấp: để tương tác với m ọi dịch vụ

và hoạt động trong tình hu ống khẩn cấp.
 Kế hoạch Đánh giá Thi ệt hại: bao gồm các chi ti ết về đầu m ối
liên hệ, các quy trình và k ế hoạch đánh giá thi ệt hại.
 Kế hoạch Cứu hộ: bao gồm thông tin về đầu m ối liên h ệ, các
hoạt động và quy trình c ứu hộ.
 Kế hoạch Hồ sơ Quan trọng: bao gồm chi tiết về m ọi hồ sơ
và thông tin m ang tính s ống còn, cùng với vị trí của chúng, có
tầm quan tr ọng đối với tiếp tục vận hành của doanh nghiệp.
 Kế hoạch Quản lý Khủng hoảng và Quan hệ Công chúng:
các kế hoạch về chỉ huy và kiểm soát các tình hu ống khủng
khoảng khác nhau, và qu ản lý phương ti ện truyền thông và
quan hệ công chúng.
 Kế hoạch Chỗ ở và Dịch vụ: chi tiết về việc quản lý chỗ ở, cơ
sở vật chất và các dịch vụ cần thiết cho hoạt động tiếp tục của
họ.
 Kế hoạch An ninh: thể hiện m ọi khía c ạnh về an ninh s ẽ được
quản lý trên tất cả các địa điểm chính và đ ịa điểm khôi ph ục.
 Kế hoạch Nhân sự: thể hiện cách m à m ọi vấn đề về nhân sự
sẽ được quản lý như thế nào trong m ột sự cố nghiêm trọng.
 Kế hoạch Truyền thông: thể hiện mọi khía c ạnh của việc
truyền thông s ẽ được xử lý và quản lý như thế nào với m ọi
lĩnh vực liên quan và m ọi bên liên quan trong m ột sự cố
nghiêm trọng.
 Kế hoạch Tài chính và Quản lý hành chính : bao gồm các chi
tiết về những phương pháp và quy trình thay th ế để có được
sự ủy quyền khẩn cấp có thể và tiếp cận được các nguồn qu ỹ
vốn thiết yếu trong m ột sự cố nghiêm trọng.
Cuối cùng, m ỗi m ột lĩnh vực kinh doanh quan tr ọng chịu trách nhiệm
cho việc phát triển m ột kế hoạch chi tiết về các cá nhân s ẽ tham gia
nhóm khôi ph ục và các tác vụ sẽ được thực hiện theo s ự yêu cầu
của các thỏa thuận khôi phục.
Kế hoạch ITSCM phải bao gồm m ọi thông tin c ần thiết để khôi phục
các hệ thống CNTT, m ạng và viễn thông trong m ột tình huống thảm
họa khi m à m ột quyết định kích hoạt được đưa ra, và sau đó, đ ể
quản lý việc doanh nghiệp quay trở lại hoạt động bình thường sau
khi gián đo ạn dịch vụ đã được giải quyết. Một trong những đầu vào
quan trọng nhất để phát triển kế hoạch là các k ết quả của Phân tích
Tác động Kinh doanh. Ngoài ra, các lĩnh v ực khác sẽ cần phải được
phân tích, chẳng hạn như Thỏa thuận Mức Dịch vụ (SLA), các yêu
cầu bảo m ật, các hướng dẫn và thủ tục vận hành và các hợp đồng
bên ngoài. Có khả năng là m ột SLA riêng biệt với các đích nh ắm
m ục tiêu thay th ế sẽ được thống nhất nếu hoạt động t ại địa điểm
khôi phục sau m ột thảm họa.

238
Các lĩnh vực khác sẽ cần được triển khai sau s ự phê duyệt của
chiến lược là:
Hoạch định tổ chức

Trong m ột quá trình khôi ph ục sau thảm họa, chắc chắn là cấu trúc
tổ chức sẽ khác biệt với những hoạt động bình thường và dựa trên:
 Thực thi – bao gồm ban điều hành/quản lý cấp cao, với quyền
hạn và kiểm soát tổng thể trong tổ chức và chịu trách nhi ệm
về quản lý k hủng hoảng và liên l ạc với các phòng, ban, t ổ
chức khác, phương tiện, quy định, các dịch vụ khẩn cấp, v.v…
 Điều phối – thường là m ột cấp dưới nhóm điều hành và chịu
trách nhiệm cho việc điều phối nỗ lực khôi phục tổng thể trong
tổ chức.
 Khôi phục – m ột loạt các nhóm khôi ph ục dịch vụ và khôi
phục kinh doanh, đ ại diện cho các ch ức năng và các d ịch vụ
nghiệp vụ quan tr ọng cần được thiết lập để hỗ trợ các chức
năng này. Mỗi nhóm chịu trách nhi ệm cho việc thực thi các kế
hoạch thuộc lĩnh vực của riêng h ọ và cho việc liên hệ với nhân
viên, khách hàng và các bên th ứ ba. Trong CNTT, các nhóm
khôi phục nên được nhóm lại theo dịch vụ và ứng dụng CNTT.
Ví dụ, nhóm cơ sở hạ tầng có thể có m ột hoặc nhiều ngườ i
chịu trách nhiệm cho việc khôi ph ục các kết nối bên ngoài, các
dịch vụ âm thanh, m ạng cục bộ, v.v… và các nhóm h ỗ trợ có
thể được tách ra theo nền tảng, hệ điều hành hoặc ứng dụng.
Ngoài ra, các ưu tiên khôi ph ục đối với dịch vụ, ứng dụng hoặc
các thành phần của nó đã được xác định trong quá trình Phân
tích Tác động Kinh doanh nên đư ợc lập thành văn b ản trong
các kế hoạch khôi ph ục và được áp dụng trong quá trình th ực
thi chúng.
Kiểm nghiệm
Kinh nghiệm cho th ấy rằng các k ế hoạch khôi ph ục không được kiểm
nghiệm đầy đủ sẽ không hoạt động như đã được dự định, dù b ất kể
m ức độ nào. Do đó, vi ệc kiểm nghiệm là m ột phần quan trọng của
quy trình ITSCM t ổng thể và là cách duy nhất để đảm bảo rằng chiến
lược, các thỏa thuận dự phòng, hậu cần, các k ế hoạch và thủ tục
khôi phục kinh doanh đã đư ợc chọn sẽ thực sự hoạt động trong thực
tế.
Nhà cung c ấp dịch vụ CNTT chịu trách nhi ệm cho việc đảm bảo rằng
các dịch vụ CNTT có thể được khôi phục sau m ột thảm họa trong
phạm vi khung thời gian đư ợc yêu c ầu với chức năng và hi ệu suất
được yêu cầu.
Có bốn loại kiểm nghiệm cơ bản có thể được thực hiện:
 Kiểm nghiệm tổng thể có thể được tiến hành khi k ế hoạch đã
được đưa ra, đơn giản bằng cách thu hút nh ững người có liên
quan lại với nhau để xem liệu (các) kế hoạch có ho ạt động
theo cách đã được m ô phỏng hay không.

239
 Các ki ểm nghiệm đầy đủ phải được tiến hành càng sớm càng
tốt sau khi đưa ra k ế hoạch và định kỳ ít nhất hàng năm sau
đó. Các kiểm nghiệm đầy đủ này nên có sự tham gia của các
đơn vị kinh doanh để hỗ trợ trong việc chứng m inh kh ả năng
khôi phục các dịch vụ m ột cách thích đáng. Trong chừng m ực
có thể, các kiểm nghiệm đầy đủ nên sao chép m ột lời thỉnh
cầu thực tế của tất cả các thỏa thuận dự phòng và nên có s ự
tham gia c ủa các bên bên ngoài n ếu họ được lên kế hoạch để
được tham gia vào m ột lời thỉnh cầu thực sự. Các ki ểm
nghiệm không chỉ phải chứng m inh s ự phục hồi của các dịch
vụ CNTT m à còn phải chứng m inh đư ợc sự phục hồi của các
quy trình nghi ệp vụ. Chúng tôi khuyến nghị rằng nên có m ột
quan sát viên đ ộc lập ghi lại tất cả các hoạt động của các thử
nghiệm và thời gian c ủa việc khôi phục dịch vụ. Tài li ệu của
người quan sát về các kiểm nghiệm sẽ là đầu vào quan tr ọng
cho việc đánh giá sau khi ‘khám nghi ệm tử thi’ tiếp theo. Các
kiểm nghiệm đầy đủ có thể được thông báo ho ặc không. Đợt
kiểm nghiệm đầu tiên của kế hoạch có thể sẽ được công bố và
lên kế hoạch cẩn thận, nhưng các ki ểm nghiệm tiếp theo có
thể bị ‘bung’ ra cho nh ững người chơi ch ủ chốt m à không cần
báo trước. Điều thiết yếu là có nhi ều người khác nhau tham
gia, kể cả những người không quen thu ộc với dịch vụ và hệ
thống CNTT, vì những người có kiến thức nhất có thể không
có m ặt khi thảm họa thực sự xảy ra.
 Các kiểm nghiệm từng phần cũng có thể được thực hiện khi
các yếu tố nhất định của kế hoạch tổng thể được kiểm nghiệm ,
chẳng hạn như các dịch vụ hoặc m áy chủ đơn lẻ. Những loại
kiểm nghiệm này nên bổ sung cho ki ểm nghiệm đầy đủ thay vì
kiểm nghiệm đầy đủ. Kiểm nghiệm đầy đủ là cách kiểm tra tốt
nhất m à tất cả các dịch vụ có thể được khôi phục trong phạm
vi khoảng thời gian được yêu c ầu và có th ể chạy cùng nhau
trên các hệ thống khôi phục.
 Các kiểm nghiệm tình huống có thể được sử dụng để kiểm
tra các phản ứng và kế hoạch đối với các điều kiện, sự kiện và
tình huống cụ thể. Chúng có th ể bao gồm việc kiểm tra xem
BCP và K ế hoạch Liên tục Dịch vụ CNTT có tương tác vớ i
nhau hay kh ông, cũng như giao ti ếp với tất cả các k ế hoạch
khác liên quan đ ến việc xử lý và quản lý m ột sự cố nghiêm
trọng.
Mọi kiểm nghiệm cần được thực hiện so với các kịch bản kiểm tra đã
được xác định, đư ợc m ô tả càng thực tế càng t ốt. Tuy nhiên, nên
lưu ý rằng ngay cả kiểm nghiệm toàn diện nhất cũng không bao hàm
được tất cả m ọi thứ. Ví dụ, trong m ột sự cố gián đoạn dịch vụ gây ra
chấn thương hoặc thậm chí t ử vong cho đồng nghiệp, phản ứng của
nhân viên đối với cuộc khủng hoảng không thể được kiểm nghiệm và
các kế hoạch cần phải dự phòng trước điều này. Ngoài ra, các ki ểm
nghiệm phải xác định các m ục tiêu m ột cách rõ ràng và các Y ếu t ố
Thành công Quan tr ọng sẽ được sử dụng để xác định thành công
hay thất bại của bài tập.

240
4.5.5.4 Giai đoạn 4 – Tiếp tục Vận hành
Giai đoạn này bao gồm các bước dưới đây:
 Giáo dục, nâng cao nh ận thức và đào tạo – việc này nên
bao gồm tổ chức, đặc biệt là tổ chức CNTT, đối với các hạng
m ục liên tục cụ thể của dịch vụ. Điều này đảm bảo rằng m ọi
nhân viên đ ều nhận thức được ý nghĩa của tính liên t ục kinh
doanh và liên t ục dịch vụ và xem chúng như là m ột phần của
hoạt động bình thư ờng hàng ngày c ủa họ, và rằng m ọi người
tham gia vào k ế hoạch đã được đào t ạo về cách làm thế nào
để triển khai các ho ạt động của họ.
 Xem xét – xem xét thường xuyên m ọi sản phẩm có thể chuyển
giao được t ừ quy trình ITSCM cần phải được thực hiện để đảm
bảo rằng chúng vẫn là hiện hành.
 Kiểm nghiệm – theo sau ki ểm nghiệm ban đầu, cần phải thiết
lập m ột chương trình ki ểm nghiệm thường xuyên để đảm bảo
rằng các thành ph ần quan trọng của chiến lược được kiểm
nghiệm , tốt nhất là hàng năm (ít nh ất), m ặc dù việc kiểm
nghiệm các Kế hoạch Liên t ục Dịch vụ CNTT nên được sắp
xếp phù hợp với nhu cầu của doanh nghiệp và của các BCP.
Mọi kế hoạch cũng nên được kiểm nghiệm ngay sau m ọi tha y
đổi lớn trong doanh nghi ệp. Điều quan trọng là bất kỳ thay đổi
nào trong công nghệ CNTT cũng được bao gồm trong chi ế n
lược, được triển khai theo m ột cách phù hợp và được kiểm
nghiệm để đảm bảo rằng chúng ho ạt động m ột cách đúng đắn
trong phạm vi cung cấp CNTT sau m ột thảm họa. Việc sao lưu
và khôi ph ục dịch vụ CNTT cũng nên được giám sát và kiểm
nghiệm để đảm bảo chúng sẽ hoạt động như c ần thiết khi
chúng được cần đến trong m ột sự cố nghiêm trọng. Khía c ạnh
này được bao gồm đầy đủ hơn trong ấn phẩm Vận hành Dịc h
vụ.
 Quản lý Thay đổi – quy trình Quản lý Thay đổi nên đảm bảo
rằng m ọi thay đổi được đánh giá về tác động tiềm ẩn của
chúng đối với các k ế hoạch ITSCM. Nếu thay đổi đã được lập
kế hoạch làm m ất hiệu lực của các k ế hoạch thì sau đó k ế
hoạch phải được cập nhật trước khi thay đ ổi được triển khai,
và nó nên được kiểm nghiệm như m ột phần của kiểm nghiệm
thay đổi. Bản thân các kế hoạch phải được kiểm soát nghiêm
ngặt bởi Quản lý Thay đổi và Quản lý Cấu hình. Các k ế hoạch
không chính xác và các năng l ực khôi phục không đầy đủ có
thể dẫn đến thất bại của các BCP. Tương t ự, trên cơ sở liên
tục, bất cứ khi nào có những dịch vụ mới hoặc khi các d ịch vụ
có những thay đổi lớn, điều thiết yếu là m ột BIA và đánh giá
rủi ro được tiến hành đối với dịch vụ mới hoặc được thay đổi
và chiến lược và các kế hoạch được cập nhật tương xứng.
Sự viện dẫn
Viện dẫn là bài ki ểm tra cuối cùng c ủa các Kế hoạch Liên tục Kinh
doanh và ITSCM. N ếu m ọi công việc chuẩn bị đã được hoàn thành
thành công và các k ế hoạch đã được phát tri ển và kiểm nghiệm , thì
việc viện dẫn các Kế hoạch Lt ục trong Kinh doanh nên là m ột quy

241
trình đơn gi ản, nhưng nếu các kế hoạch này chưa đư ợc kiểm
nghiệm thì thất bại là điều có thể dự đoán được. Điều quan trọng là
phải xem xét thích đáng vi ệc thiết kế tất cả các quy trình viện dẫn
để đảm bảo rằng chúng phù hợp với m ục đích và tương tác v ới tất
cả các quy trình viện dẫn có liên quan khác.
Viện dẫn là m ột thành ph ần chính c ủa các kế hoạch, phải bao gồm

quy trình và hướng dẫn việc viện dẫn. Nên lưu ý r ằng quyết định
viện dẫn, đặc biệt là nếu sử dụng phương ti ện khôi phục của bên
thứ ba, không nên được xem nhẹ. Chi phí s ẽ có liên quan và quá
trình này sẽ kéo theo sự gián đoạn đối với hoạt động kinh doanh.
Quyết định (viện dẫn) này thường được đưa ra bởi m ột nhóm 'qu ản
lý khủng hoảng', bao g ồm các nhà qu ản lý cấp cao từ bộ phận hỗ trợ
và kinh doanh (bao g ồm cả CNTT), sử dụng những thông tin thu
thập được thông qua đánh giá thi ệt hại và các ngu ồn khác.
Sự gián đoạn có thể xảy ra bất kỳ lúc nào trong ngày ho ặc đêm , vì
vậy điều thiết yếu là phải có s ẵn hướng dẫn về quy trình vi ện dẫn.
Các kế hoạch phải sẵn sàng cho các cán b ộ chủ chốt tại văn phòng
và ở xa văn phòng.
Quyết định viện dẫn phải được đưa ra nhanh chóng, vì có th ể cần
phải có thời gian để chuẩn bị liên quan đến việc thiết lập các cơ sở
tại địa điểm phục hồi. Trong trường hợp cháy tòa nhà nghiêm tr ọng,
quyết định có th ể khá dễ dàng. Tuy nhiên, trong trư ờng hợp m ất
điện hoặc lỗi phần cứng, việc giải quyết được kỳ vọng chỉ trong thời
gian ngắn, m ột thời hạn nên được đặt ra bởi thời điểm cuối cùng
nếu sự cố vẫn chưa được giải quyết, việc viện dẫn sẽ diễn ra. Nếu
sử dụng các nhà cung c ấp dịch vụ bên ngoài, h ọ phải được cảnh
báo ngay lập tức nếu có khả năng xảy ra viện dẫn.
Quyết định viện dẫn cần phải tính đến:
 Mức độ thiệt hại và phạm vi của lời viện dẫn tiềm năng.
 Có khả năng kéo dài thời gian gián đo ạn và tình tr ạng không
sẵn sàng c ủa cơ sở vật chất và/hoặc dịch vụ.
 Thời gian theo ngày/tháng/năm và tác đ ộng kinh doanh tiềm
ẩn. Vào cuối năm , nhu c ầu viện dẫn có thể cấp bách hơn, để
đảm bảo rằng quá trình xử lý cuối năm được hoàn thành đúng
hạn.
Do đó, thiết kế của quá trình vi ện dẫn phải cung cấp hướng dẫn về
cách đánh giá m ọi lĩnh vực và hoàn cảnh nói trên đ ể hỗ trợ cho
người viện dẫn kế hoạch liên tục.
Kế hoạch ITSCM nên bao gồm các chi ti ết về những hoạt động cần
được thực hiện, bao gồm :
 Truy xuất các băng sao lưu ho ặc sử dụng kho dữ liệu để lấy
dữ liệu.
 Truy xuất tài liệu thiết yếu, thủ tục, hình ảnh của m áy tr ạm ,
v.v... được lưu trữ ngoại biên.

242
 Huy động các nhân v iên kỹ thuật thích hợp để tiến hành ph ục
hồi địa điểm để bắt đầu khôi phục các hệ thống và dịch vụ cần
thiết.
 Liên hệ và cảnh báo các nhà cung c ấp viễn thông, các d ịch vụ
hỗ trợ, các nhà th ầu ứng dụng, v.v… những người có thể được
cần đến để thực hiện các hành động hoặc cung c ấp sự trợ
giúp trong quá trình khôi ph ục.
Việc viện dẫn và khôi phục ban đầu có thể là thời gian có nhi ều hoạt
động, liên quan đ ến nhiều giờ làm việc đối với nhiều cá nhân. Điề u
này phải được nhận thức và quản lý bởi các trưởng nhóm khôi phục
để đảm bảo rằng những khoảng thời gian nghỉ ngơi được sắp xếp và
ngăn chặn tình tr ạng 'kiệt sức'. Việc lập kế hoạch cho các ca làm
việc và bàn giao ph ải được thực hiện để đảm bảo rằng sẽ sử dụng
tốt nhất các cơ sở vật chất sẵn có. Một điều cực kỳ quan trọng là
đảm bảo rằng các bi ện pháp kiểm soát kinh doanh và công ngh ệ
thông thường vẫn được duy trì trong quá trình vi ện dẫn, khôi phục
và trở lại bình thường để đảm bảo rằng bảo m ật thông tin được duy
trì ở m ức đúng đắn và bảo vệ dữ liệu được duy trì.
Sau khi quá trình khôi ph ục hoàn tất, doanh nghiệp nên có khả năng
hoạt động t ừ địa điểm khôi ph ục ở m ức độ đã được xác định và thỏa
thuận trong chi ến lược và SLA có liên quan. Tuy nhiên, m ục tiêu s ẽ
là xây dựng hoạt động kinh doanh ở m ức bình thường, duy trì hoạt
động từ địa điểm khôi ph ục trong thời gian ng ắn và di dời địa điểm
khôi phục trong th ời gian ngắn nhất có thể. Chi tiết của tất cả các
hoạt động này c ần phải được bao gồm trong k ế hoạch. Nếu sử dụng
các dịch vụ bên ngoài, s ẽ có m ột thời hạn hợp đồng hữu hạn cho
việc sử dụng cơ sở vật chất. Dù ở bất kỳ giai đoạn nào, sự trở lại
bình thường phải được lên kế hoạch cẩn thận và thực hiện m ột cách
có kiểm soát. Thông thư ờng, thời gian này sẽ diễn ra vào cu ối tuầ n
và có thể bao gồm m ột số thời gian ng ừng hoạt động cần thiết trong
giờ làm việc. Điều quan trọng là việc này phải được quản lý tốt và
tất cả nhân viên liên quan đ ều nhận thức được trách nhi ệm của
mình để đảm bảo quá trình chuy ển tiếp diễn ra suôn sẻ.
Rất nhiều sự kiện có thể kích hoạt hoạt động ITSCM. Chúng bao
gồm :
 Các nhu c ầu kinh doanh m ới hoặc được thay đổi, hoặc các
dịch vụ m ới hoặc được thay đổi.
 Các đích nh ắm m ục tiêu m ới hoặc được thay đổi trong các
thỏa thuận, chẳng hạn như SLR, SLA, OLA ho ặc hợp đồng.
 Xảy ra m ột sự cố nghiêm trọng đòi hỏi phải đánh giá kh ả năng
viện dẫn hoặc Kế hoạch Liên t ục Kinh doanh hoặc Kế hoạch
Liên tục CNTT.
 Các hoạt động định kỳ chẳng hạn như các ho ạt động BIA ho ặc
Phân tích Rủi ro, bảo trì các Kế hoạch Liên tục hoặc các ho ạt
động xem xét, điều chỉnh hoặc báo cáo.

243
 Đánh giá nh ững thay đổi và sự tham gia các cu ộc họp của Hội
đồng Cố vấn Thay đổi.
và CNTT.
 Nhận biết hoặc thông báo về sự thay đổi của rủi ro hoặc tác
động của m ột VBF, m ột dịch vụ hoặc thành phần CNTT.
 Bắt đầu các ki ểm nghiệm đối với các k ế hoạch liên tục và khôi
phục.
Sự tích hợp và các tương tác t ồn tại từ ITSCM đến m ọi quy trình
khác. Những ví dụ quan trọng được m inh họa như dưới đây:
 Quản lý Thay đổi – m ọi thay đổi cần được xem xét về tác
động của chúng lên các k ế hoạch liên tục, và nếu bất kỳ sự
sửa đổi nào là cần thiết đối với kế hoạch, việc cập nhật kế
hoạch cần phải là m ột phần của sự thay đổi. Bản thân k ế
hoạch phải được đặt dưới sự kiểm soát của Quản lý Thay đ ổi.
 Quản lý Vấn đề và Sự cố - các sự cố có thể dễ dàng phát
triển thành các s ự cố hoặc thảm họa nghiêm trọng. Các tiêu
chí rõ ràng c ần được thống nhất và lập thành văn b ản để viện
dẫn các kế hoạch ITSCM.
 Quản lý Tính sẵn sàng – việc thực hiện Phân tích R ủi ro và
triển khai các ứng phó với rủi ro nên được điều phối m ột cách
chặt chẽ với quy trình s ẵn sàng đ ể tối ưu hóa vi ệc giảm thiểu
rủi ro.
 Quản lý Mứ c Dịch vụ - các yêu cầu khôi phục sẽ được thỏa
thuận và lập thành văn b ản trong các SLA. Các m ức dịch vụ
khác nhau có th ể được thỏa thuận và lập thành văn b ản m à có
thể được chấp nhận trong các tình huống thảm hoạ.
 Quản lý Công su ất – việc đảm bảo răng có đ ầy đủ tài nguyên
để cho phép khôi phục lên các m áy tính thay th ế sau m ột thảm
họa.
 Quản lý Cấu hình – các tài liệu CMS ghi nh ận lại các thành
phần cấu t ạo nên cơ sở hạ tầng và m ối quan hệ giữa các
thành phần. Thông tin này là vô giá đ ối với m ọi giai đoạn của
vòng đời ITSCM, sự duy trì các kế hoạch và các cơ sở vật
chất khôi phục.
 Quản lý Bảo mật Thông tin – có m ột m ối quan hệ cực kỳ chặt
chẽ tồn tại giữa ITSCM và Quản lý Bảo m ật Thông tin. M ọt vi
phạm bảo m ật nghiêm trọng có th ể được xem là m ột thảm họa,
do đó, khi ti ến hành BIA và Phân tích Rủi ro, bảo m ật sẽ m ột
m ối quan tâm cực kỳ quan trọng.
4.5.6.1 Đầu vào

Có rất nhiều nguồn đầu vào đư ợc đòi hỏi bởi quy trình ITSCM:
 Thông tin về doanh nghiệp: từ chiến lược kinh doanh, các k ế

hoạch và k ế hoạch tài chính c ủa t ổ chức, và thông tin về các
yêu cầu hiện tại và tương lai c ủa chúng.

244
 Thông tin về CNTT: từ chiến lược và các k ế hoạch và ngân
sách hiện tại của CNTT.
 Một Chiến lược Liên t ục Kinh doanh và m ột bộ các K ế hoạch
Liên tục Kinh doanh: t ừ m ọi lĩnh vực của doanh nghi ệp.
 Thông tin về dịch vụ: từ quy trình SLM, với các chi ti ết về các
dịch vụ từ Danh m ục Dịch vụ và Bản Mục lục Dịch vụ và các
đích nhắm m ục tiêu m ức dịch vụ trong các SLA và SLR.
 Thông tin tài chính: t ừ Quản lý Tài chính, chi phí cho vi ệc
cung cấp dịch vụ, chi phí cho các tài nguyên và các thành
phần.
 Thông tin về sự thay đổi: từ quy trình Quản lý Thay đổi, cùng
với m ột Lịch trình Thay đ ổi và nhu c ầu đánh giá m ọi thay đổi
về tác động của chúng lên m ọi kế hoạch ITSCM.
 CMS: bao g ồm những thông tin về các m ối quan hệ giữa
doanh nghiệp, các dịch vụ, các dịch vụ hỗ trợ và công ngh ệ.
 Các lịch trình ki ểm nghiệm Quản lý Liên t ục Kinh doanh và
Quản lý Tính s ẵn sàng.
 Các Kế hoạch Liên tục Dịch vụ CNTT và các báo cáo ki ểm
nghiệm từ các nhà cung c ấp và đối tác, nếu có thể.
4.5.6.2 Đầu ra
Các đầu ra của quy trình ITSCM bao g ồm:
 Một chính sách và chi ến lược ITSCM đã được điều chỉnh.

 Một bộ các k ế hoạch ITSCM, bao g ồm m ọi Kế hoạch Quản lý
Khủng hoảng, K ế hoạch Ứng phó với Tình trạng khẩn cấp và
Kế hoạch Khôi ph ục sau Thảm họa, cùng với m ột bộ các kế
hoạch hỗ trợ và các hợp đồng với các nhà cung c ấp dịch vụ
khôi phục.
 Các bài tập và báo cáo Phân tích Tác đ ộng Kinh doanh, k ết
hợp với BCM và doanh nghi ệp.
 Các xem xét và báo cáo Phân tích và Qu ản lý Rủi ro, kết hợp
với doanh nghiệp, Quản lý Tính s ẵn sàng và Quản lý B ảo m ật.
 Một lịch trình ki ểm nghiệm ITSCM.
 Các tình huống kiểm nghiệm ITSCM.
 Các đánh giá và báo cáo ki ểm nghiệm ITSCM.
Các báo cáo dự đoán và d ự báo trước được sử dụng bởi m ọi lĩnh
vực để phân tích, dự báo và dự đoán trước các tình hu ống c ụ thể
của doanh nghi ệp và CNTT và các gi ải pháp tiềm năng của họ.
4.5.7 Các Chỉ số Hiệu su ất Chính yếu

Các dịch vụ CNTT được cung cấp và có thể được khôi phục để đáp
ứng các m ục tiêu c ủa doanh nghi ệp:
 Thường xuyên ki ểm tra các K ế hoạch ITSCM đ ể đảm bảo rằng,

tại m ọi thời điểm , các yêu c ầu khôi phục đã được thỏa thuận
của doanh nghi ệp đều có thể đạt được.
 Mọi đích nh ắm m ục tiêu khôi ph ục dịch vụ được thỏa thuận và
lập thành văn b ản trong các SLA và có th ể đạt được trong các
Kế hoạch ITSCM.

245
 Kiểm nghiệm toàn diện và thường xuyên các K ế hoạch ITSCM.
 Việc đánh giá thường xuyên được thực hiện, ít nhất là hàng
năm , về các kế hoạch liên tục CNTT và liên t ục kinh doanh với
các lĩnh vực kinh doanh.
 Thương thảo và quản lý m ọi hợp đồng ITSCM c ần thiết với
bên thứ ba.
 Giảm rủi ro và tác động tổng thể của các lỗi dịch vụ CNTT tiềm
ẩn.
Nâng cao nh ận thức trong toàn bộ tổ chức về các kế hoạch:
 Đảm bảo nâng cao nh ận thức về tác động kinh doanh, nhu c ầu
và yêu cầu với toàn bộ CNTT.
 Đảm bảo rằng m ọi lĩnh vực dịch vụ CNTT và m ọi nhân viên
được chuẩn bị và có khả năng ứng phó với m ột viện dẫn củ a
các Kế hoạch ITSCM.
 Thường xuyên truyền đạt về các m ục tiêu và trách nhi ệm
ITSCM trong các lĩnh v ực kinh doanh và dịch vụ CNTT thích
hợp.

ITSCM cần ghi lại m ọi thông tin c ần thiết để duy trì m ột bộ các kế
hoạch ITSCM toàn di ện. Thông tin cơ s ở này bao gồm :
 Thông tin về phiên bản m ới nhất của BIA.

 Thông tin toàn di ện về rủi ro trong B ản đăng ký Rủi ro, bao
gồm đánh giá r ủi ro và các bi ện pháp ứng phó với rủi ro.
 Phiên bản m ới nhất của chiến lược BCM và các BCP.
 Các chi tiết liên quan đ ến m ọi kiểm nghiệm đã hoàn thành và
m ột lịch trình c ủa mọi kiểm nghiệm đã được lập kế hoạch.
 Các chi tiết về m ọi Kế hoạch ITSCM và nội dung của chúng.
 Các chi ti ết về m ọi kế hoạch khác liên quan đ ến các K ế hoạch
ITSCM.
 Các chi tiết về m ọi cơ sở vật chất dành cho vi ệc khôi phục
hiện hữu, các nhà cung c ấp và đối tác khôi ph ục, các thỏ a
thuận và hợp đồng khôi ph ục, các thi ết bị dự phòng và thay
thế.
 Các chi tiết về m ọi quy trình, lịch trình, hệ thống và phương
tiện sao lưu và khôi ph ục, và các vị trí liên quan của chúng.
Mọi thông tin trên c ần được tích hợp vào và liên k ết với m ọi thông
tin BCM và m ọi thông tin khác đư ợc yêu cầu bởi ITSCM. Những
tương tác với các quy trình khác c ần thiết để đảm bảo rằng sự liên
kết này được duy trì.
rủi ro
Một trong những thách thức lớn m à ITSCM phải đối m ặt là đưa ra
các kế hoạch thích hợp khi không có quy trình BCM. N ếu không có
quy trình BCM thì CNTT có kh ả năng đưa ra các giả định không
chính xác về m ức độ quan trọng đối với doanh nghi ệp của quy trình

246
nghiệp vụ và do đó áp d ụng các chi ến lược và lựa chọn sai lầm về
tính liên t ục. Không có BCM, các gi ải pháp và k ế hoạch ITSCM đắt
tiền sẽ trở nên vô dụng do không có các kế hoạch và thỏa thuận
tương ứng trong doanh nghi ệp. Tương tự, nếu không có BCM, doanh
nghiệp có thể không xác đ ịnh được các giải pháp phi-CNTT rẻ tiền
và lãng phí ti ền bạc vào các gi ải pháp CNTT không hi ệu quả, đắt
tiền.
Trong m ột số tổ chức, quan điểm doanh nghi ệp cho r ằng tính liên
tục là trách nhiệm của CNTT, và do đó, doanh nghi ệp giả định rằng
CNTT sẽ chịu trách nhiệm khôi ph ục sau thảm họa và các dịch vụ
CNTT sẽ tiếp tục hoạt động trong bất kỳ trường hợp nào. Điều này
đặc biệt đúng trong m ột số tình huống thuê ngoài khi doanh nghi ệp
có thể m iễn cưỡng chia sẻ thông tin BCM c ủa m ình với m ột nhà
cung cấp dịch vụ bên ngoài.
Nếu có m ột quy trình BCM đư ợc thiết lập thì thách thức sẽ trở thành
m ột trong s ố về sự liên kết và tích hợp. ITSCM phải đảm bảo rằng
thông tin chính xác thu đư ợc từ quy trình BCM v ề nhu cầu, tác động
và ưu tiên c ủa doanh nghiệp, đồng thời thông tin và các k ế hoạch
ITSCM phải được liên k ết và tích hợp với thông tin và k ế hoạch của
doanh nghiệp. Để đạt được sự liên kết đó, thách thức trở thành m ột
trong việc giữ chúng được liên k ết bằng cách quản lý và ki ểm soát
thay đổi trong ho ạt động kinh doanh và CNTT. Do đó, đi ều thiết yếu
là t ất cả các tài liệu và kế hoạch được duy trì dưới sự kiểm soát
nghiêm ngặt của Quản lý Thay đ ổi và Quản lý Cấu hình.
Các CSF chính cho quá trình ITSCM là:
 Các dịch vụ CNTT được cung c ấp và có thể được khôi ph ục để

đáp ứng các m ục tiêu c ủa doanh nghi ệp.
 Nâng cao nh ận thức trong toàn bộ tổ chức về các Kế hoạch
Liên tục Dịch vụ CNTT và Liên t ục Kinh doanh.
Một số rủi ro chính tương ứng với ITSCM bao gồm :
 Thiếu cam kết từ phía doanh nghi ệp đối với các quy trình và
thủ tục ITSCM.
 Thiếu cam kết từ phía doanh nghi ệp và thiếu thông tin thích
hợp về các kế hoạch và chiến lược tương lai.
 Thiếu cam kết của quản lý cấp cao hoặc thiếu tài nguyên
và/hoặc ngân sách dành cho quy trình ITSCM.
 Các quy trình t ập trung quá nhi ều vào các vấn đề về công
nghệ và không đ ủ tập trung vào các dịch vụ CNTT và nhu cầu
và độ ưu tiên c ủa doanh nghi ệp.
 Phân tích và Quản lý Rủi ro được tiến hành m ột cách biệt lập
và không liên kêt v ới Quản lý Tính s ẵn sàng và Quản lý Bảo
m ật.
 Các kế hoạch và thông tin ITSCM tr ở nên lỗi thời và m ất liên
kết với thông tin và các k ế hoạch của doanh nghi ệp và BCM.

247
4.6 Quản lý Bảo mật Thông tin
‘Mục tiêu của quy trình ISM là đ ể liên kết bảo mật CNTT với bí
mật kinh doanh và đ ảm bảo rằng bảo mật thông tin được quản lý
một cách hi ệu qu ả trong mọi dịch vụ và ho ạt động Qu ản lý Dịch
vụ’.
ISM cần đưọc xem xét trong m ột khuôn kh ổ quản trị doanh nghiệp
tổng thể. Quản tr ị doanh nghi ệp là m ột bộ các trách nhi ệm và các
thực tiễn đã được thực hành bởi ban lãnh đạo và quản lý đi ều hành
với m ục tiêu cung cấp định hướng chiến lược, đảm bảo đạt được
các m ục tiêu, chứng m inh rằng rủi ro đang được quản lý m ột cách
thích đáng và xác m inh r ằng những tài nguyên của doanh nghi ệp
được sử dụng m ột cách hiệu quả.
Bảo m ật thông tin là m ột hoạt động quản lý bên trong khuôn kh ổ

quản trị doanh nghiệp, cung c ấp định hướng chiến lược cho các
hoạt động bảo m ật và đảm bảo việc đạt được các m ục tiêu. Nó đ ảm
bảo thêm rằng những rủi ro bảo m ật thông tin được quản lý m ột
cách thích đáng và r ằng tài nguyên thông tin c ủa doanh nghi ệp được
sử dụng m ột cách có trách nhi ệm . Mục đích c ủa ISM là để cung cấp
m ột sự tập trung vào m ọi khía c ạnh của bảo m ật CNTT và quản lý
m ọi hoạt động bảo m ật CNTT.
Thuật ngữ ‘thông tin’ được sử dụng như m ột khái niệm phổ biến và
bao gồm kho dữ liệu, cơ sở dữ liệu và siêu dữ liệu. Mục tiêu c ủa
bảo m ật thông tin là b ảo vệ lợi ích của những gì dựa trên thông tin,
và các hệ thống và truyền thông cung c ấp thông tin, khỏi việc bị tổn
hại bởi các lỗi về tính sẵn sàng, bảo mật và toàn vẹn.
Đối với hầu hết các tổ chức, m ục tiêu bảo m ật được đáp ứng khi:
 Thông tin sẵn sàng và có th ể sử dụng được khi được yêu c ầu,
và các hệ thống cung c ấp nó có th ể chống lại các cuộc tấn
công m ột cách thích đáng và khôi ph ục từ hoặc ngăn ng ừa các
lỗi (tính sẵn sàng).
 Thông tin đư ợc quan sát bởi hoặc tiết lộ chỉ cho những ai có
quyền được biết (tính bảo m ật).
 Thông tin là hoàn ch ỉnh, chính xác và được bảo vệ chống lạ i
việc sửa đổi trái phép (tính toàn vẹn).
 Các giao dịch kinh doanh, cũng như các trao đ ổi thông tin gi ữa
các doanh nghiệp, hoặc với các đối tác, có thể tin cậy được
(tính xác th ực và không-từ chối).
Việc thiết lập độ ưu tiên về tính bảo mật, toàn vẹn và sẵn sàng ph ải
được xem xét trong b ối cảnh của doanh nghi ệp và các quy trình
nghiệp vụ. Hướng dẫn chủ yếu để xác định những gì phải được bảo
vệ và m ức độ bảo vệ phải đến từ doanh nghiệp. Để có hiệu quả, bảo
m ật phải xác định toàn bộ các quy trình nghi ệp vụ từ đầu đến cuối
và bao trùm các khía c ạnh vật lý và k ỹ thuật. Chỉ trong bối cảnh nhu

248
cầu của doanh nghi ệp và các r ủi ro, c ấp quản lý m ới có thể xác định
bảo m ật.
4.6.2 Phạm vi
Quy trình ISM nên là đ ầu m ối cho tất cả các vấn đề bảo m ật CNTT
và phải đảm bảo rằng Chính sách B ảo m ật Thông tin được đưa ra,
duy trì và th ực thi bao gồm việc sử dụng và sử dụng sai m ọi hệ
thống và dịch vụ CNTT. ISM cần phải hiểu tổng thể m ôi trường an
ninh CNTT và an ninh kinh doanh, bao g ồm :
 Các kế hoạch và Chính sách B ảo m ật Kinh doanh.

 Hoạt động kinh doanh hi ện tại và các yêu c ầu bảo m ật của nó.
 Các kế hoạch và yêu cầu của doanh nghi ệp trong tương lai.
 Yêu cầu pháp lý.
 Nghĩa vụ và trách nhi ệm liên quan đến bảo m ật trong SLA
 Những rủi ro trong kinh doanh và CN TT và việc quản lý của
chúng.
Việc hiểu được t ất cả những điều này s ẽ cho phép ISM đ ảm bảo
rằng m ọi khía c ạnh an ninh hiện tại và trong tương lai và các r ủi ro
của doanh nghi ệp được quản lý m ột cách hiệu quả về chi phí.
Quy trình ISM nên bao g ồm :
 Việc đưa ra, duy trì, phân ph ối và thực thi Chính sách B ảo m ật
Thông tin và các chính sách b ảo m ật hỗ trợ.
 Việc hiểu các yêu cầu bảo m ật hiện tại và tương lai đã đư ợc
thỏa thuận của doanh nghi ệp cũng như các k ế hoạch và Chính
sách Bảo m ật Doanh nghi ệp hiện có.
 Việc triển khai m ột tập hợp các biện pháp kiểm soát b ảo m ật
hỗ trợ cho Chính sách B ảo m ật Thông tin và quản lý các r ủi ro
liên quan đ ến việc truy c ập vào các dịch vụ, thông tin và h ệ
thống.
 Tài liệu hóa t ất cả các biện pháp ki ểm soát an ninh, cùng với
việc vận hành và duy trì các bi ện pháp kiểm soát và các r ủi ro
liên quan c ủa chúng.
 Quản lý các nhà cung c ấp và các h ợp đồng liên quan đến
quyền truy c ập vào các h ệ thống và dịch vụ, kết hợp với Quản
lý Nhà cung c ấp.
 Quản lý m ọi vi phạm và sự cố bảo mật liên quan đến tất cả
các hệ thống và dịch vụ.
 Cải tiến chủ động các biện pháp ki ểm soát bảo m ật và quản lý
rủi ro bảo m ật và giảm thiểu các rủi ro bảo m ật.
 Tích hợp các khía cạnh bảo m ật trong tất cả các quy trình
ITSM khác.
Để đạt được hiệu quả quản lý bảo m ật thông tin, c ấp quản lý phả i
thiết lập và duy trì Hệ thống Quản lý Bảo m ật Thông tin (ISMS) đ ể
hướng dẫn việc phát triển và quản lý m ột chương trình b ảo m ật
thông tin toàn diện hỗ trợ cho các m ục tiêu c ủa doanh nghi ệp.

249
ISM đảm bảo rằng m ột Chính sách B ảo m ật Thông tin đư ợc duy trì
và thực thi để đáp ứng các nhu cầu của Chính sách Bảo m ật Doanh
nghiệp và các yêu c ầu của quản trị doanh nghiệp. ISM nâng cao
nhận thức về các nhu c ầu đối với bảo m ật trong m ọi dịch vụ và tài
sản CNTT trên toàn bộ tổ chức, đảm bảo rằng chính sách là tương
xứng với các nhu c ầu của tổ chức. ISM quản lý m ọi khía cạnh củ a
CNTT và bảo m ật thông tin trong m ọi lĩnh vực của CNTT và hoạt
động Quản lý Dịch vụ.
ISM m ang l ại sự bảo đảm cho các quy trình nghi ệp vụ bằng các h
thực thi các biện pháp kiểm soát bảo m ật thích hợp trong m ọi lĩnh
vực CNTT và bằng cách quản lý rủi ro CNTT phù h ợp với các quy
trình và hư ớng dẫn quản trị rủi ro doanh nghiệp và rủi ro kinh
doanh.

Những thực tiễn kinh doanh th ận trọng đòi hỏi rằng các quy trình và
sáng kiến CNTT phải liên k ết với các quy trình và m ục tiêu của
doanh nghiệp. Đây là đi ều quan trọng khi đề cập đến bảo m ật thông
tin, vốn phải được liên kết m ột cách chặt chẽ với bảo m ật kinh
doanh và nhu cầu của doanh nghi ệp. Thêm vào đó, m ọi quy trình
trong t ổ chức CNTT ph ải bao gồm các cân nhắc về bảo m ật.
Cấp quản lý điều hành ch ịu trách nhi ệm sau cùng về thông tin của tổ
chức và có nhi ệm vụ ứng phó với những vấn đề ảnh hưởng tới sự
bảo vệ của nó. Ngoài ra, các hội đồng quản trị được kỳ vọng là sẽ
đưa bảo m ật thông tin thành m ột phần không th ể tách rời của quản
trị doanh nghiệp. Do đó, m ọi tổ chức cung c ấp dịch vụ CNTT phải
đảm bảo rằng họ có m ột (hoặc nhiều) chính sách ISM toàn di ện và
các biện pháp kiểm soát bảo m ật cần thiết ngay t ại chỗ để giám sát
và thực thi các chính sách.
4.6.4.1 Khuôn khổ bảo mật

Quy trình và khuôn kh ổ Quản lý Bảo m ật Thông tin thường sẽ bao
gồm :
 Một Chính sách B ảo m ật Thông tin và các chính sách b ảo m ật

cụ thể xác định m ỗi khía c ạnh của chiến lược, các biện pháp
kiểm soát và quy đ ịnh.
 Một Hệ thống Quản lý Bảo m ật Thông tin (ISMS), bao g ồm các
tiêu chuẩn, thủ tục và hướng dẫn quản lý hỗ trợ cho các chính
sách bảo m ật thông tin.
 Một chiến lược bảo m ật toàn diện, được liên k ết chặt chẽ với
các m ục tiêu, chi ến lược và kế hoạch của doanh nghi ệp.
 Một cấu trúc bảo mật về m ặt tổ chức có hiệu quả.
 Một bộ các biện pháp kiểm soát bảo m ật để hỗ trợ cho chính
sách.
 Quản lý các r ủi ro về bảo m ật.
 Các quy trình giám sát đ ể đảm bảo tính tuân thủ và cung cáp
phản hồi về tính hiệu quả.

250
 Chiến lược và kế hoạch truyền thông đối với bảo m ật.
 Chiến lược và kế hoạch đào t ạo và nâng cao nh ận thức.
4.6.4.2 Chính sách B ảo mật Thông tin

Các hoạt động Quản lý Bảo m ật Thông tin nên đư ợc tập trung vào và
được định hướng bởi m ột Chính sách Bảo m ật Thông tin t ổng thể và
m ột bộ các chính sách bảo m ật cơ sở. ITP nên có được sự hỗ trợ
đầy đủ từ cấp quản lý điều hành CNTT và lý tư ởng nhất là sự hỗ trợ
và cam kết từ cấp quản lý điều hành c ấp cao nhất của doanh nghi ệp.
Chính sách nên bao trùm m ọi lĩnh vực của bảo m ật, và phù hợp, đáp
ứng các nhu c ầu của doanh nghi ệp và bao g ồm :
 Một Chính sách B ảo m ật Thông tin t ổng thể.

 Chính sách về việc sử dụng và s ử dụng sai tài s ản CNTT.
 Một chính sách ki ểm soát truy c ập.
 Một chính sách ki ểm soát m ật khẩu.
 Một chính sách sử dụng thư điện t ử.
 Một chính sách sử dụng internet.
 Một chính sách ch ống virus m áy tính.
 Một chính sách phân lo ại thông tin.
 Một chính sách phân lo ại hồ sơ.
 Một chính sách truy c ập từ xa.
 Một chính sách liên quan đ ến quyền truy cập của nhà cung
cấp vào dịch vụ CNTT, thông tin và các thành ph ần.
 Một chính sách loại bỏ tài sản.
Những chính sách này nên s ẵn sàng trên diện rộng đối với m ọi
khách hàng và ngư ời sử dụng, và tính tuân th ủ của họ nên được đ ề
cập đến trong m ọi SLR, SLR, hợp đồng và thỏa thuận. Các chính
sách nên được cấp phép bởi cấp quản lý điều hành cao nhất trong
tổ chức và CNTT, và vi ệc tuân thủ chúng nên được xác nhận trên cơ
sở thường xuyên. Mọi chính sách b ảo m ật nên được đánh giá – và,
khi cần thiết, được điều chỉnh – trên cơ sở ít nhất là hàng năm .
4.6.4.3 Hệ thống Quản lý Bảo mật Thông tin (ISMS)

Khuôn khổ hoặc ISMS, đến lượt m ình, cung cấp m ột cơ sở cho việc
phát triển m ột chương trình bảo m ật thông tin hiệu quả về chi phí hỗ
trợ cho các m ục tiêu của doanh nghi ệp. Nó sẽ liên quan đến Bốn
chữ P bao gồm People – Con người, Process – Quy trình, Products
– Sản phẩm , và công nghệ cũng như là Partners – Đối tác, và các
nhà cung c ấp để đảm bảo m ức bảo m ật cao được áp dụng.
ISO 27001 là m ột tiêu chuẩn chính thức m à các t ổ chức có thể tìm
kiếm chứng nhận độc lập cho hệ thống ISMS của họ (nghĩa là các
khuôn khổ của họ để thiết kế, triển khai, qu ản lý, duy trì và thực thi
các quy trình và bi ện pháp kiểm soát bảo m ật thông tin m ột cách có
hệ thống và nhất quán trong toàn bộ tổ chức). ISMS thể hiện trong
Hình 4.26 cho thấy m ột phương pháp ti ếp cận được sử dụng m ột
cách rộng rãi và đư ợc dựa trên những khuyến nghị và hướng dẫn từ
rất nhiều nguồn, bao gồm cả ISO 27001.

251
Hình 4.26 – Khuôn khổ quản lý b ảo mật CNTT
Dưới đây là năm thành phần trong khuôn kh ổ này:
Kiểm soát
Mục tiêu c ủa thành ph ần kiểm soát của ISMS là đ ể:
 Thiết lập m ột khuôn kh ổ quản lý để khởi đầu và quản lý bảo

m ật thông tin trong t ổ chức.
 Thiết lập m ột cấu trúc tổ chức để chuẩn bị, phê duyệt và triển
khai Chính sách B ảo m ật Thông tin.
 Phân bổ trách nhi ệm.
 Thiết lập và ki ểm soát tài li ệu.
Lập kế hoạch
Mục tiêu của thành ph ần lập kế hoạch của ISMS là để sắp đặt và
khuyến nghị các biện pháp bảo m ật thích ứng, dựa trên hiểu biết về
các yêu cầu của tổ chức.
Các yêu c ầu sẽ được thu thập từ những nguồn như rủi ro kinh doanh
và rủi ro dịch vụ, các k ế hoạch và chi ến lược, các SLA và OLA và
những trách nhi ệm pháp lý, luân lý và đ ạo đức đối với bảo m ật
thông tin. Các yếu tố khác, chẳng hạn như t ổng lượng nguồn vốn
đang sẵn có và vă n hóa tổ chức đang chi ếm ưu thế và thái đ ộ đối
với bảo m ật, cần phải được xem xét.
Chính sách B ảo m ật Thông tin xác đ ịnh thái đ ộ và lập trường của tổ
chức đối với các vấn đề về bảo m ật. Đây nên là m ột tài liệu quy m ô
toàn t ổ chức chứ không chỉ có thể áp dụng cho nhà cung c ấp dịch vụ
CNTT. Trách nhi ệm cho việc giữ tài liệu này được cập nhật hiện
hành là c ủa Nhà Quản lý Bảo m ật Thông tin.

252
Triển khai
Mục tiêu c ủa việc triển khai ISMS là để đảm bảo rằng các thủ tục,
công cụ và biện pháp ki ểm soát thích h ợp có sẵn để làm nền t ảng
cho Chính sách B ảo m ật Thông tin.
Giữa các biện pháp đó là:
 Trách nhiệm đối với tài sản – Quản lý Cấu hình và CMS là vô
giá ở đây.
 Phân loại Thông tin – thông tin và kho lưu tr ữ nên đư ợc phân
loại tùy theo độ nhạy cảm và tác động của việc bị tiết lộ.
Việc triển khai thành công các bi ện pháp và ki ểm soát bảo m ật tùy
thuộc vào m ột số các yếu tố:
 Việc xác định m ột chính sách rõ ràng và đư ợc thỏa thuận,

được tích hợp với nhu cầu của doanh nghi ệp.
 Các thủ tục bảo m ật được chứng m inh, thích ứng và hỗ trợ bởi
các quản lý cấp cao.
 Tiếp thị và giáo d ục hiệu quả về các yêu cầu bảo m ật.
 Một cơ chế cải thiện
Đánh giá
Mục tiêu c ủa thành ph ần đánh giá c ủa ISMS là để:
 Giám sát và kiểm tra tính tuân th ủ với chính sách b ảo m ật và

các yêu cầu bảo m ật trong các SLA và OLA.
 Tiến hành ki ểm toán định kỳ bảo m ật về m ặt kỹ thuật của các
hệ thống CNTT.
 Cung cấp thông tin cho các ki ểm toán viên và cơ quan pháp lý
bên ngoài, nếu được yêu cầu.
Duy trì
Mục tiêu c ủa thành ph ần duy trì này c ủa ISMS là đ ể:
 Cải thiện các thỏa thuận bảo m ật như được chỉ định trong, ví
dụ, các SLA và OLA.
 Cái thiện việc triển khai các bi ện pháp và kiểm soát bảo mật.
Việc này nên đạt được bằng cách s ử dụng chu k ỳ PDCA (Plan – Do
– Check – Act), vốn là m ột phương pháp tiếp cận chính thức được
đề xuất bởi ISO 27001 cho vi ệc thiết lập khuôn khổ hoặc Hệ thống
Quản lý Bảo m ật Thông tin. Chu k ỳ 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ụ.
Quản trị bảo mật

Quản trị bảo m ật thông tin, khi đư ợc triển khai m ột cách đúng đ ắn,
nên cung cấp 6 kết quả cơ bản sau đây:
 Sự liên k ết chiến lược:

o Các yêu cầu bảo mật nên được định hướng bởi các yêu

253
o Các giải pháp bảo m ật cần phải phù hợp với các quy
trình doanh nghi ệp.
o Khoản đầu tư vào bảo m ật thông tin nên đưu ọc liên k ết
với chiến lược doanh nghi ệp và nhất trí về hồ sơ rủi ro.
 Cung cấp giá tr ị:
o Một bộ tiêu chuẩn các thực tiễn bảo mật, ví dụ, các yêu
cầu bảo m ật đường cơ sở theo những thực tiễn t ốt nhất.
o Nỗ lực được phân phối và ưu tiên hóa m ột cách đúng
đắn cho những lĩnh vực có tác đ ộng lớn nhất và có lợi
ích nhiều nhất.
o Các giải pháp được thể chế hóa và thương m ại hóa.
o Các giải pháp hoàn ch ỉnh, bao hàm tổ chức và quy trình
cũng như công ngh ệ.
o Một văn hóa liên t ục cải tiến.
 Quản lý rủi ro:
o Nhất trí về hồ sơ rủi ro.
o Hiểu về sự phát lộ rủi ro.
o Nhận thức về các ưu tiên quản lý rủi ro.
o Giảm thiểu rủi ro.
o Chấp nhận rủi ro/chênh l ệch.
 Quản lý hiệu suất:
o Bộ các chỉ số được xác định, thỏa tuận và có ý nghĩa.
o Quy trình đo lường sẽ giúp xác đ ịnh những thiếu sót và
cung c ấp phản hồi về tiến độ đã đạt được khi gi ải quyết
vấn đề.
o Bảo hiểm độc lập.
 Quản lý tài nguyên:
o Kiến thức được nắm bắt và sẵn sàng.
o Các quy trình và th ực tiễn bảo m ật được lập thành văn
bản.
o (Các) Ki ến trúc bảo m ật được phát triển để sử dụng m ột
cách hiệu quả các tài nguyên cơ sở hạ tầng.
 Đảm bảo quy trình nghiệp vụ.

Mục đích c ủa quy trình ISMS là đ ể đảm bảo rằng các khía cạnh bảo
m ật liên quan đến dịch vụ và m ọi hoạt động Quản lý Dịch vụ được
quản lý và ki ểm soát m ột cách thích đáng, phù h ợp với các nhu c ầu
và những rủi ro kinh doanh:
Những hoạt động chính trong quy trình ISMS là:
 Đưa ra, xem xét và đi ều chỉnh m ột Chính sách B ảo m ật Thông

tin t ổng thể và m ột bộ các dịch vụ hỗ trợ cụ thể.
 Truyền đạt, triển khai và thực thi các chính sách b ảo m ật.
 Đánh giá và phân lo ại m ọi tài sản và tài li ệu thông tin.
 Triển khai, xem xét, đi ều chỉnh và c ải thiện m ột bộ các kiểm
soát bảo m ật, đánh giá và ứng phó rủi ro.
 Giám sát và qu ản lý m ọi vi phạm bảo m ật và các s ự cố bảo
m ật nghiêm trọng.

254
 Lịch trình và hoàn thi ện việc xem xét, ki ểm toán và ki ểm
nghiệm xâm nhập về bảo m ật.
Sự tương tác giữa các hoạt động chính yếu này được m inh h ọa
trong Hình 4.27.
Hình 4.27 – Quy trình Quản lý Bảo mật CNTT
Các quy trình Quản lý Bảo m ật Thông tin đã được phát tri ển, cùng
với các phương pháp, công cu và k ỹ thuật, tạo thành nên chi ến lược
bảo m ật. Nhà quản lý bảo m ật nên đảm bảo rằng những công ngh ệ,
sản phẩm và dịch vụ là có sẵn và rằng chính sách t ổng thể được
phát triển và công bố rõ ràng. Nhà qu ản lý bảo m ật cũng chịu trách
nhiệm cho kiến trúc, xác th ực, cấp phép, quản lý và khôi ph ục bảo
m ật.
Chiến lược bảo m ật cũng c ần xem xét về việc những thực tiễn bảo
m ật tốt sẽ được nhúng vào m ọi lĩnh vực của doanh nghi ệp như th ế
nào. Đào tạo và nâng cao nhận thức là điều sống còn trong chi ến
lược tổng thể, vì bảo m ật thường là yếu nhất tại phía người dùng
đầu cuối. Cũng t ại đây, cần phải phát tri ển các phương pháp và quy
trình cho phép các chính sách và tiêu chu ẩn được tuân thủ và triể n
khai m ột cách dễ dàng hơn.
Những tài nguyên c ần được phân bổ để theo dõi sự phát triển của
những công nghệ cho phép này và nh ững sản phẩm m à chúng h ỗ
trợ. Ví dụ, quyền riêng tư vẫn tiếp tục quan trọng và, ngày càng gia
tăng, sự tập trung của quy định của chính ph ủ, làm cho các công

255
nghệ tuân thủ quyền riêng tư trở thành m ột công nghệ cho phép
quan trọng.
4.6.5.1 Các biện pháp b ảo mật

Nhà Quản lý Bảo mật Thông tin phải hiểu rằng bảo m ật không ph ải
là m ột bước trong vòng đời của dịch vụ và các hệ thống và rằng bảo
m ật không thể được giải quyết chỉ bằng công nghệ. Thay vào đó,
bảo m ật thông tin phải là m ột phần không th ể thiếu của mọi dịch vụ
và hệ thống và là m ột quy trình liên t ục cần phải được quản lý m ột
cách liên tục bằng cách sử dụng m ột bộ các kiểm soát bảo m ật, như
trong Hình 4.28.
Hình 4.28 – Các bi ện pháp ki ếm soát bảo mật đối với các mối đe
dọa và các sự cố
Bộ các biện pháp ki ểm soát bảo m ật nên được thiết kế để hỗ trợ và

thực thi Chính sách B ảo m ật Thông tin và đ ể tối thiểu hóa m ọi m ối
đe dọa đã được xác định và được nhận biết.Các biện pháp kiểm
soát sẽ tiết kiệm chi phí m ột cách đáng kể nếu được bao gồm trong
thiết kế của m ọi dịch vụ. Điều này s ẽ đảm bảo sự bảo vệ liên t ục
của m ọi dịch vụ hiện hữu và rằng những dịch vụ m ới và sự truy cậ p
chúng phù hợp với chính sách.
Các biện pháp bảo m ật có thể được sử dụng tại m ột giai đoạn cụ th ể
trong việc ngăn ngừa và xử lý các s ự cố bảo m ật, như được m inh

256
họa trong Hình 4.28. Các s ự cố bảo m ật không ch ỉ do các m ối đe
dọa kỹ thuật – thống kê cho th ấy rằng, ví dụ, phần lớn bắt nguồn từ
lỗi con người (có chủ đích hoặc không) ho ặc lỗi thủ tục, và thường
có liên quan đến những lĩnh vực khác như an toàn, pháp lý ho ặc sức
khỏe.
Những giai đoạn dưới đây có thể được xác định. Ngay từ đầu, có
m ột rủi ro là m ối đe dọa sẽ trở thành hiện thực. Một m ối đe dọa có
thể là bất cứ gì làm gián đo ạn quy trình nghi ệp vụ hoặc có tác đ ộng
tiêu cực đến doanh nghi ệp. Khi m ối đe dọa trở thành hi ện thực,
chúng ta gọi nó là s ự cố bảo m ật. Sự cố bảo m ật này có thể dẫn đến
thiệt hại (đối với thông tin hoặc tài sản) phải được sửa chữa hoặ c
nói cách khác, đư ợc khắc phục. Các bi ện pháp phù h ợp có thể được
lựa chọn cho m ỗi một trong số các giai đo ạn này. Việc lựa chọn các
biện pháp s ẽ phụ thuộc vào m ức độ quan tr ọng của thông tin.
 Ngăn ngừa: các biện pháp bảo m ật được sử dụng để ngăn

ngừa việc xảy ra một sự cố bảo m ật. Ví dụ nổi tiếng nhất về
các biện pháp ngăn ngừa là phân bổ quyền truy cập (thông tin)
cho m ột nhóm hạn chế những người được ủy quyền. Những
yêu cầu bổ sung liên quan t ới biện pháp này bao gồm kiểm
soát quyền truy c ập (cấp quyền, bảo trì và rút l ại quyền), ủy
quyền (việc xác định ai được phép tr uy cập vào những thông
tin nào và sử dụng công c ụ nào), nhận dạng và xác th ực (xác
nhận ai đang tìm kiếm quyền truy c ập) và kiểm soát truy cập
(việc đảm bảo rằng chỉ có những người được ủy quyền có thể
được truy cập).
 Giảm thiểu: những biện pháp bổ sung có thể được thực hiện
trước để tối thiểu bất kỳ thiệt hại tiềm ẩn nào có thể xảy ra.
Đây là những biện pháp ‘gi ảm thiểu’. Các ví dụ khá quen thuộc
về các biện pháp giảm thiểu là thực hiện sao lưu thư ờng
xuyên và phát tri ển, kiểm nghiệm và duy trì các k ế hoạch dự
phòng.
 Nhận diện: nếu m ột sự cố bảo m ật xảy ra, điều quan trọng là
khám phá ra nó càng s ớm càng t ốt – nhận diện. Một ví dụ
quen thuộc về điều này là vi ệc giám sát, được liên kết với m ột
thủ tục cảnh báo. Một ví dụ khác là phần m ềm kiểm tra virus
m áy tính.
 Áp ch ế: những biện pháp sau đó được sử dụng để chống lại
bất kỳ sự tiếp tục hoặc lặp lại nào c ủa sự cố bảo m ật. Ví dụ,
m ột tài khoản hoặc m ột địa chỉ m ạng được khóa tạm thời sau
nhiều lần nỗ lực đăng nhập thất bại hoặc giữ lại thẻ khi nỗ lực
nhiều lần với m ã PIN sai.
 Khắc phục: Hư hỏng được sửa chữa trong chừng m ực nhiều
nhất có thể bằng các biện pháp khắc phục. Ví dụ, các bi ện
pháp khắc phục bao gồm việc khôi ph ục từ bản sao lưu, ho ặc
quay lại tình tr ạng ổn định trước đó (roll-back, back-out).
Fallback cũng có th ể được coi là m ột biện pháp khắc phục.

257
Tài liệu về m ọi biện pháp kiểm soát nên được duy trì để phản ảnh
m ột cách chính xác ho ạt động, duy trì của chúng và phương pháp
hoạt động của chúng.
4.6.5.2 Quản lý những vi phạm bảo mật và các sự cố.

Trong tr ường hợp vi phạm bảo m ật hoặc sự cố nghiêm trọng, m ột
đánh giá đúng hạn là cần thiết để xác định đã xảy ra điều gì sai,
những nguyên nhân nào gây ra nó và nó có th ể được ngăn ng ừa như
thế nào trong tương lai. Tuy nhiên, quy trình này không ch ỉ nên bị
giới hạn ở những sự cố bảo m ật nghiêm trọng. Mọi vi phạm bảo m ật
và sự cố bảo m ật cần được nghiên c ứu nhằm có được m ột bức tranh
toàn cảnh về tính hiệu quả của các biện pháp bảo m ật nói chung.
Một thủ tục báo cáo đ ối với các sự cố bảo m ật là cần thiết để có th ể
đánh giá tính hiệu quả và hiệu lực của các biện pháp bảo m ật hiện
tại dựa trên m ột cái nhìn sâu s ắc vào trong m ọi sự cố bảo m ật. Điều
này được tạo điều kiện bởi việc duy trì các t ập tin nhật ký và, dĩ
nhiên, hồ sơ về sự cố của chức năng H ỗ trợ Dịch vụ. Việc phân tích
các số liệu thống kê về các vấn đề bảo m ật nên dẫn đến các hành
động cải tiến tập trung vào vi ệc giảm thiểu tác động và khối lượng
của m ọi vi phạm và sự cố bảo m ật, cùng với Quản lý Vấn đề.
4.6.6 Các yếu tố kích ho ạt, đầu vào, đ ầu ra và giao diện

Hoạt động ISMS có thể được kích ho ạt bởi rất nhiều sự kiện, bao
gồm :
 Những hướng dẫn quản trị doanh nghi ệp m ới hoặc được thay
đổi.
 Chính sách B ảo m ật Doanh nghiệp m ới hoặc được thay đổi.
 Các quy trình và hư ớng dẫn quản lý r ủi ro doanh nghiệp mới
hoặc được thay đổi.
 Các nhu c ầu m ới hoặc được thay đổi của doanh nghi ệp về
những dịch vụ m ới hoặc được thay đổi.
 Các yêu c ầu m ới hoặc được thay đổi trong các th ỏa thuận,
chẳng hạn như các SLR, SLA, OLA ho ặc hợp đồng.
và CNTT.
 Những vi phạm bảo m ật thành phần hoặc bảo m ật dịch vụ
hoặc cảnh báo, s ự kiện và báo đ ộng, bao gồm các sự kiện
ngưỡng, các báo cáo ngo ại lệ.
 Những hoạt động định kỳ, chẳng hạn như xem xét , điều chỉnh
hoặc báo cáo, bao gồm xem xét và đi ều chỉnh các chính sách,
báo cáo và k ế hoạch ISM.
 Nhận ra hoặc thông báo về m ột thay đổi của rủi ro hoặc tác
động của m ột quy trình nghiệp vụ hoặc VBF, m ột dịch vụ hoặc
thành phần CNTT.
 Các yêu c ầu t ừ những lĩnh vực khác, đặc biệt là SLM để hỗ trợ
cho các vấn đề về bảo m ật.
Việc triển khai hiệu quả và hiệu lực Chính sách B ảo m ật Thông tin
trong m ột tổ chức sẽ, ở m ột m ức độ rộng lớn, tùy thuộc vào các quy

258
trình Quản lý Dịch vụ tốt. Thật vậy, việc triển khai hiệu quả m ột số
quy trình có thể được xem là đi ều kiện tiên quyết để kiểm soát b ảo
m ật hiệu quả. Các tương tác chính m à ISM có v ới các quy trình khác
được liệt kê dưới đây:
 Quản lý V ấn đề và Sự cố: trong việc cung cấp hỗ trợ cho giải

pháp và bi ện m inh và kh ắc phục các v ấn đề và sự cố bảo m ật
sau đó. Nhân viên thu ộc Hỗ trợ Dịch vụ và Vận hành Dịch vụ
phải ‘nhận ra’ được m ột sự cố bảo m ật.
 ITSCM: cùng với đánh gía về tác động và r ủi ro kinh doanh, và
việc cung c ấp khả năng phục hồi, khả năng chịu lỗi và các cơ
chế khôi phục. Bảo m ật là m ột vấn đề chính khi các k ế hoạch
liên tục được kiểm nghiệm hoặc triệu hồi. Một kế hoạch ITSCM
hoạt động là yêu c ầu bắt buộc của ISO 27001.
 SLM: hỗ trợ cho việc xác định các yêu c ầu bảo m ật và trách
nhiệm và kết luận của chúng trong các SLR và SLA, cùng v ới
việc tìm hiểu và giải pháp cho các vi ph ạm bảo m ật dịch vụ và
thành phần.
 Quản lý Thay đ ổi: ISM nên h ỗ trợ cho việc đánh giá m ọi thay
đổi đối với tác động của bảo m ật và các biện pháp ki ểm soát.
ISM cũng có th ể cung cấp thông ti n về những thay đổi trái
phép.
 Các vấn đề về pháp lý và Nhân s ự phải được xem xét khi điều
tra các vấn đề về bảo m ật.
 Quản lý Cấu hình s ẽ m ang lại khả năng cung c ấp tài sản thông
tin chính xác đ ể hỗ trợ cho việc phân loại bảo m ật. Có m ột
CMS chính xác, d o đó, là m ột đầu vào hữu ích tối hậu của
ISM.
 Bảo m ật thường được xem nhu là m ột thành phần của Quản lý
Tính sẵn sàng, với Tính bảo m ật, Tính toàn vẹn và Tính sẵn
sàng (CIA) tr ở thành bản chất của Tính s ẵn sàng và ISM đ ể
tiền hành các bài t ập Phân tích và Quản lý Rủi ro đã được
nhúng.
 Quản lý Công su ất phải xem xét các tác đ ộng bảo m ật khi lựa
chọn và giới thiệu công ngh ệ m ới. Bảo m ật là m ột cân nhắc
quan trọng khi m ua sắm công ngh ệ hoặc phần m ềm mới.
 Quản lý Tài chính nên cung c ấp đủ nguồn vốn cho các yêu cầu
bảo m ật tài chính.
 Quản lý Nhà cung c ấp nên hỗ trợ cho việc quản lý chung các
nhà cung c ấp và quyền truy cập của họ vào các dịch vụ và hệ
thống, và các khái ni ệm và thuật ngữ sẽ được bao gồm trong
các hợp đồng liên quan đến trách nhi ệm của nhà cung c ấp.
4.6.6.1 Đầu vào

Quản lý Bảo m ật Thông tin sẽ cần có được đầu vào từ rất nhiều lĩnh
vực, bao gồm :
 Thông tin về doanh nghiệp: từ chiến lược, các k ế hoạch và kế

hoạch tài chính về việc kinh doanh c ủa tổ chức, và thông tin
về các yêu cầu hiện tại và trong tương lai của họ.

259
 Các chính sách và hư ớng dẫn quản trị doanh nghiệp và bảo
m ật kinh doanh, các k ế hoạch bảo m ật, Phân tích R ủi ro và
các biện pháp ứng phó với rủi ro.
 Thông tin về dịch vụ: từ quy trình SLM với các chi ti ết về dịch
vụ từ Danh m ục Dịch vụ và Bản Mục lục Dịch vụ và các đích
nhắm m ục tiêu m ức dịch vụ trong các SLA và SLR, và có th ể
có từ việc giám sát các SLA, đánh giá d ịch vụ và những vi
phạm SLA.
 Các quy trình và báo cáo Phân tích Rủi ro: t ừ ISM, Quản lý
Tính sẵn sàng và ITSCM.
 Chi tiết về m ọi sự kiện và vi ph ạm bảo m ật: từ m ọi lĩnh vực
của IT và BẢO MẬT THÔNG TIN, đ ặc biệt là Quản lý S ự cố và
Quản lý Vấn đề.
 Thông tin về các thay đổi: từ quy trình Quản lý Thay đ ổi với
m ột Lịch trình Thay đ ổi và nhu c ầu đánh giá m ọi thay đổi về
tác động của chúng lên m ọi chính sách, k ế hoạch và bi ện pháp
kiểm soát bảo m ật.
 CMS: bao g ồm thông tin về các m ối quan hệ giữa doanh
nghiệp, các dịch vụ, các dịch vụ hỗ trợ và công ngh ệ.
 Các chi tiết về quyền truy c ập của đối tác và nhà cung c ấp: từ
Quản lý Nhà cung c ấp và Quản lý Tính sẵn sàng về quyền truy
cập từ bên ngoài vào các d ịch vụ và hệ thống.
4.6.6.2 Đầu ra
Những đầu ra là k ết quả của quy trình Quản lý Bảo m ật Thông tin
được sử dụng trong m ọi lĩnh vực và nên bao g ồm :
 Một Chính sách Qu ản lý Bảo m ật Thông tin tổng thể, cùng với
m ột bộ các chính sách b ảo m ật cụ thể.
 Một Hệ thống Thông tin Qu ản lý Bảo m ật (SMIS), bao gồm m ọi
thông tin liên quan t ới ISM.
Các quy trình và báo cáo đánh giá r ủi ro bảo m ật đã được điều
chỉnh
 Một bộ các biện pháp kiểm soát b ảo mật, cùng với các chi tiết
về việc vận hành và bảo trì những rủi ro tương ứng của chúng.
 Các báo cáo kiểm toán và báo cáo ki ểm toán bảo m ật.
 Các lịch trình và k ế hoạch kiểm nghiệm bảo m ật, bao gồm các
kiểm nghiệm xâm nhập, các kiểm nghiệm và báo cáo b ảo m ật
khác.
 Một bộ các phân lo ại bảo m ật và m ột bộ những tài s ản thông
tin đã được phân lo ại.
 Các xem xét và báo cáo v ề các vi ph ạm bảo m ật và những sự
cố (bảo m ật) nghiêm trọng.
 Các chính sách, quy trình và thủ tục dành cho việc quản lý các
đối tác và các nhà cung c ấp và quyền truy cập của họ vào các
dịch vụ và thông tin.

260
4.6.7 Các Chỉ số Hiệu su ất Quan trọng
Rất nhiều KPI và các chỉ số có thể được sử dụng để đánh giá tính
hiệu quả và hiệu lực của quy trình và c ác hoạt động ISM. Nh ững chỉ
số này cần phải được phát triển từ quan điểm dịch vụ, khách hàng
và doanh nghiệp, chẳng hạn như:
 Bảo vệ doanh nghi ệp chống lại những vi phạm :

o Tỷ lệ phần trăm giảm trong các vi ph ạm bảo m ật được
báo cáo cho H ỗ trợ Dịch vụ.
o Tỷ lệ phần trăm giảm trong tác đ ộng của các vi phạm và
sự cố bảo m ật.
o Tỷ lệ phần trăm tăng trong m ức độ tuân thủ SLA đối với
các điều khoản về bảo m ật.
 Xác định m ột chính sách rõ ràng và th ống nhất, được tích hợp
với nhu c ầu của doanh nghiệp: giảm số lượng m ức độ không
tuân thủ của quy trình ISM đối với chính sách và quy trình b ả o
m ật doanh nghi ệp.
 Các thủ tục bảo m ật được chứng m inh, thích hợp và được hỗ
trợ bởi các qu ản lý cấp cao:
o Gia tăng trong s ự chấp thuận và tuân th ủ các thủ tục
bảo m ật.
o Gia tăng m ức độ hỗ trợ và cam kết của các quản lý c ấp
cao.
 Một cơ chế cải thiện:
o Số lượng các cải thiện được đề xuất đối với các th ủ tục
và biện pháp kiểm soát bảo m ật.
o Giảm thiểu số lượng m ức độ không tuân thủ bảo m ật
được phát hi ện trong các k ỳ kiểm toán và kiểm nghiệm
bảo m ật.
 Bảo m ật thông tin là m ột phần không thể thiếu của m ọi dịch vụ
CNTT và m ọi quy trình ITSCM: tăng s ố lượng các dịch vụ và
quy trình tuân th ủ các thủ tục và các bi ện pháp kiểm soát bảo
m ật.
 Giới thiệu và giáo d ục hiệu quả về các yêu c ầu bảo m ật, nhân
viên CNTT có nh ận thức về những công ngh ệ hỗ trợ cho các
dịch vụ:
o Nhận thức trong toàn b ộ tổ chức được gia tăng về chính
sách bảo m ật và nội dung của nó.
o Tỷ lệ phần trăm tăng trong m ức độ hoàn thiện của Bản
m ục lục Dịch vụ về kỹ thuật đối với các thành ph ần
CNTT hỗ trợ cho các dịch vụ.
o Hỗ trợ Dịch vụ hỗ trợ cho m ọi dịch vụ.
4.6.8 Quản lý Thông tin

Mọi thông tin được yêu cầu bởi ISM nên được đóng gói trong SMIS.
Việc này nên bao g ồm m ọi biện pháp kiểm soát, r ủi ro, vi ph ạm , các
quy trình và báo cáo về bảo m ật cần thiết để hỗ trợ và duy trì Chính
sách Bảo m ật Thông tin và ISMS. Thông tin này nên bao hàm m ọi
dịch vụ và thành phần CNTT và các nhu c ầu sẽ được tích hợp và
duy trì trong m ối liên k ết với m ọi hệ thống quản lý thông tin CNTT
khác, đặc biệt là Danh m ục Dịch vụ và CMS. SMIS cũng s ẽ cung cấp

261
đầu vào cho các k ỳ kiểm toán và đánh giá b ảo m ật và cho các ho ạt
động cải thiện liên tục quan tr ọng đối với m ọi ISMS. SMIS cũng s ẽ
cung cấp đầu vào vô giá cho thi ết kế các hệ thống hoặc dịch vụ m ới.
những rủi ro
ISM đang phải đối m ặt với rất nhiều thách thức trong vi ệc thiết lập
m ột Chính sách B ảo m ật Thông tin thích h ợp cùng với quy trình h ỗ
trợ và các biện pháp ki ểm soát hiệu quả. Một trong những thách
thức lớn nhất là đảm bảo rằng có sự hỗ trợ đầy đủ từ doanh nghi ệp,
bảo m ật kinh doanh và các qu ản lý c ấp cao. Không có nh ững điều
này sẽ không thể thiết lập m ột quy trình ISM hi ệu quả. Nếu có sự hỗ
trợ của quản lý CNTT cấp cao, nhưng không có s ự hỗ trợ từ doanh
nghiệp, việc kiểm soát bảo m ật CNTT và đánh giá r ủi ro sẽ bị hạn
chế nghiêm trọng trong những gì họ có thể đạt được vì thi ếu sự hỗ
trợ này t ừ doanh nghi ệp. Việc triển khai các chính sách, th ủ tục và
biện pháp kiểm soát bảo m ật CNTT sẽ là vô nghĩa n ếu chúng không
thể được thực thi trong toàn b ộ doanh nghiệp. Việc sử dụng chủ yếu
các dịch vụ và tài s ản CNTT nằm bên ngoài CNTT, và ph ần lớn các
m ối đe dọa và rủi ro bảo m ật cũng vậy.
Trong m ột số tổ chức, doanh nghiệp cho rằng bảo m ật là trách

nhiệm của CNTT, và do đó doan h nghiệp giả định rằng CNTT sẽ chị u
trách nhiệm về m ọi khía c ạnh của bảo m ật CNTT và rằng các dịch vụ
CNTT sẽ được bảo vệ m ột cách thích đáng. Tuy nhiên, n ếu không có
sự cam kết và hỗ trợ của doanh nghi ệp và nhân viên c ủa doanh
nghiệp, khoản tiền đã đầu tư vào các biện pháp kiểm soát và th ủ tục
bảo m ật đắt tiền sẽ bị lãng phí ph ần lớn và chúng h ầu như không có
hiệu quả.
Nếu có m ột quy trình b ảo m ật kinh doanh đã đư ợc thiết lập, thách

thức sẽ trở thành m ột trong những sự liên k ết và tích hợp. ISM ph ải
đảm bảo rằng thông tin chính xác thu đư ợc từ quy trình bảo m ật của
doanh nghiệp về nhu cầu, rủi ro, tác đ ộng và r ằng ưu tiên c ủa doanh
nghiệp cũng như các chính sách, thông tin và k ế hoạch ISM phải
phù hợp và được tích hợp với các chính sách, thông tin và k ế hoạch
của doanh nghiệp. Để đạt được sự liên kết đó, thách th ức trở thành
m ột trong việc giữ cho chúng được liên k ết bằng cách quản lý và
kiểm soát s ự thay đổi trong kinh doanh và CNTT b ằng cách sử dụng
biện pháp ki ểm soát Quản lý Cấu hình và Quản lý Thay đ ổi nghiêm
ngặt. Một lần nữa, điều này đòi hỏi sự hỗ trợ và cam kết từ phía
doanh nghiệp lẫn các quản lý cấp cao.
Các CSF chính đối với quy trình ISM là:
 Doanh nghiệp được bảo vệ chống lại các vi ph ạm .

 Xác định m ột chính sách rõ ràng và th ống nhât, được tích hợp
với những nhu c ầu của doanh nghi ệp.
 Các thủ tục bảo m ật được chứng m inh, thích hợp và hỗ trợ bởi
các quản lý cấp cao.
 Giới thiệu và giáo d ục hiệu quả về các yêu cầu bảo m ật.

262
 Một cơ chế cải thiện.
 Bảo m ật thông tin là m ột phần không thể thiểu của m ọi dịch vụ
CNTT và quy trình ITSCM.
 Tính sẵn sàng của các dịch vụ không bị xâm phạm bởi các sự
cố bảo m ật.
 Chủ sở hữu và nh ận thức rõ ràng về các chính sách b ảo m ật
giữa cộng đồng khách hàng.
Hệ thống thông tin có th ể tạo ra r ất nhiều lợi ích cả trực tiếp lẫn
gián tiếp, cũng như rất nhiều rủi ro trực tiếp và gián ti ếp. Những rủi
ro này dẫn tới m ột khoảng cách gi ữa nhu c ầu bảo vệ các hệ thống
và m ức độ bảo vệ được áp dụng. Khoảng trống này có nguyên nhân
từ các yếu tố bên trong l ẫn bên ngoài, bao g ồm việc sử dụng rộng
rãi công nghệ, sự gia tăng m ức phụ thuộc của doanh nghi ệp vào
CNTT, sự gia tăng m ức độ phức tạp và sự liên kết với nhau c ủa các
hệ thống, sự biến m ất của những ranh giới tổ chức truyền thống và
những yêu cầu quy định pháp luật nghiêm khắc ngày càng gia tăng.
Điều này có nghĩa là có nh ững lĩnh vực rủi ro m ới có thể có tác động
đáng kể lên hoạt động kinh doanh quan tr ọng, chẳng hạn như:
 Yêu cầu ngày càng cao về tính sẵn sàng và sự m ạnh m ẽ.

 Tăng khả năng sử dụng sai và l ạm dụng hệ thống thông tin
gây ảnh hưởng đến quyền riêng tư và các giá tr ị đạo đức.
 Các m ối nguy hi ểm bên ngoài t ừ tin tặc, dẫn đến các cuộc tấn
công từ chối dịch vụ và vi rút, tống tiền, gián điệp công nghi ệp
và rò r ỉ thông tin t ổ chức hoặc dữ liệu cá nhân.
Bởi vì công ngh ệ mới m ang lại tiềm năng tăng cường đáng kể cho
hiệu suất kinh doanh, b ảo m ật thông tin đã đư ợc cải thiện và chứng
m inh có thể làm tăng giá tr ị thực cho tổ chức bằng cách góp phần
vào tương tác với các đối tác thương m ại, các m ối quan hệ với
khách hàng ch ặt chẽ hơn, lợi thế cạnh tranh được cải thiện và danh
tiếng được bảo vệ. Nó cũng có thể cho phép những cách thức m ới
và dễ dàng hơn đ ể xử lý các giao d ịch điện tử và t ạo ra sự tin
tưởng. Trong n ền kinh tế toàn cầu cạnh tranh ngày nay, n ếu m ột tổ
chức m uốn kinh doanh, t ổ chức đó có thể được yêu cầu phải trình
bày chi tiết về vị thế bảo m ật và kết quả hoạt động trong quá kh ứ
của tổ chức đó dưới dạng các bài kiểm tra được thực hiện để đảm
bảo tính bảo m ật cho các nguồn thông tin c ủa tổ chức đó.
Các lĩnh vực rủi ro chính khác l iên quan đ ến ISM bao gồm :
 Thiếu sự cam kết từ doanh nghiệp đối với các quy trình và th ủ
tục ISM.
 Thiếu cam kết từ doanh nghi ệp và thi ếu thông tin tương x ứng
về các kế hoạch và chiến lược trong tương lai.
 Thiếu cam kết của các nhà quản lý cấp cao hoặc thiếu nguồn
lực và/hoặc ngân sách cho quy trình ISM.

263
 Các quy trình t ập trung quá nhiều vào các vấn đề công nghệ
và không đủ vào các dịch vụ CNTT cũng như các nhu c ầu và
ưu tiên c ủa doanh nghi ệp.
 Đánh giá và quản lý rủi ro được tiến hành riêng bi ệt và không
kết hợp với Quản lý Tính s ẵn sàng và ITSCM.
 Các chính sách, k ế hoạch, rủi ro và thông tin ISM tr ở nên lỗi
thời và m ất liên kết với thông tin và các k ế hoạch liên quan
tương xứng của doanh nghiệp và bảo mật doanh nghi ệp.
4.7 Quản lý Nhà cung cấp

‘Mục tiêu của quy trình Qu ản lý Nhà cung c ấp là đ ể quản lý các
nhà cung cấp và các dịch vụ mà họ cung cấp, để mang lại ch ất
lượng liền mạch của dịch vụ CNTT đối với doanh nghiệp, đả m
bảo đạt được giá trị về tiền bạc’.
Quy trình Quản lý Nhà cung c ấp đảm bảo rằng các nhà cung c ấp và
các dịch vụ m à họ cung cấp được quản lý để hỗ trợ các đích nhắm
m ục tiêu c ủa dịch vụ CNTT và các k ỳ vọng của doanh nghi ệp. Mụ c
tiêu của phần này là đ ể nâng cao nhận thức của bối cảnh kinh doanh
trong việc hoạt động cùng với các đối tác và nhà cung c ấp, và làm
thế nào m à hoạt động này có thể tốt nhất trực tiếp hướng tới việ c
hiện thực hóa lợi ích kinh doanh cho t ổ chức như thế nào.
Điều thiết yếu là các quy trình và k ế hoạch Quản lý Nhà cung c ấp và
tham gia vào m ọi giai đo ạn của Vòng đ ời Dịch vụ, từ chiến lược đến
thiết kế, qua chuyển tiếp và vận hành, đến cải thiện. Những nhu c ầu
phức tạp của doanh nghi ệp đòi hỏi phải có đầy đủ các kỹ năng và
năng lực để hỗ trợ cho việc cung c ấp m ột bộ các dịch vụ CNTT toàn
diện cho m ột doanh nghiệp, do đó, vi ệc sử dụng những m ạng lưới
giá trị và các nhà cung c ấp và các dịch vụ m à họ cung cấp là m ột
phần không thể thiếu của bất kỳ giải pháp t ừ đầu-đến-cuối nào. Các
nhà cung cấp và việc quản lý các nhà cung c ấp và các đối tác là
điều thiết yếu để cung cấp các dịch vụ CNTT chất lượng.
Mục đích của quy trình Quản lý Nhà cung c ấp là đạt được giá tr ị về
tiền bạc từ các nhà cung c ấp và đảm bảo được rằng các nhà cung
cấp hoàn thành các đích nh ắm m ục tiêu được bao gồm trong các
hợp đồng và thỏa thuận của họ, trong khi vẫn tuân thủ m ọi điều
khoản và điều kiện.
Mục tiêu chính c ủa quy trình Qu ản lý Nhà cung c ấp là để:
 Đạt được giá tr ị về tiền bạc từ các nhà cung cấp và các hợp
đồng.
 Đảm bảo rằng các hợp đồng và thỏa thuận cơ sở với các nhà
cung cấp được liên kết với các nhu c ầu của doanh nghi ệp, và
hỗ trợ và liên kết với các đích nh ắm m ục tiêu đã được thỏa
thuận trong các SLR và SLA, k ết hợp với SLM.
 Quản lý m ối quan hệ với các nhà cung cấp.
 Quản lý hiệu suất của nhà cung c ấp.

264
 Thương thảo và thỏa thuận các hợp đồng với các nhà cung
cấp và quản lý chúng trong suốt vòng đời của chúng.
 Duy trì m ột chính sách nhà cung c ấp và m ột hỗ trợ cho Cơ s ở
dữ liệu về Nhà cung cấp và Hợp đồng (SCD).
4.7.2 Phạm vi
Quy trình Quản lý Nhà cung c ấp nên bao g ồm việc quản lý m ọi nhà
cung cấp và hợp đồng cần thiết để hỗ trợ cho việc cung c ấp các dịch
vụ CNTT cho doanh nghi ệp. Mỗi nhà cung c ấp dịch vụ nên có các
quy trình chính thức đối với việc quản lý m ọi nhà cung c ấp và hợp
đồng. Tuy nhiên, các quy trình này nên thích ứng để đáp ứng tầm
quan trọng của nhà cung cấp và/hoặc hợp đồng và tác động kinh
doanh tiềm tàng trong vi ệc cung c ấp các dịch vụ. Rất nhiều nhà
cung cấp cung c ấp các dịch vụ và sản phẩm hỗ trợ độc lập có vai trò
tương đối nhỏ và khá gián tiếp trong vi ệc tạo ra giá tr ị, nhưng nói
chung, đóng góp quan tr ọng và trực tiếp cho việc tạo ra giá tr ị và
triển khai chi ến lược kinh doanh t ổng thể. Nhà cung c ấp đóng góp
càng nhiều cho doanh nghi ệp thì nhà cung c ấp càng c ần phải nỗ lực
nhiều hơn nữa trong vi ệc quản lý nhà cung c ấp và nhà cung c ấp đó
càng tham gia nhiều hơn nữa trong việc phát triển và hiện thực hóa
chiến lược kinh doanh. Giá tr ị đóng góp c ủa nhà cung c ấp càng ít,
có khả năng lớn là m ối quan hệ sẽ được quản lý chủ yếu ở m ức độ
vận hành, với tương tác h ạn chế với doanh nghiệp. Điều này có th ể
thích hợp với m ột vài tổ chức, đặc biệt là các t ổ chức lớn hơn, đ ể
quản lý các nhóm và các nhà cung c ấp khi m à các đơn v ị kinh doanh
có thể cung cấp hỗ trợ cho các yếu tố chính.
Quy trình Quản lý Nhà cung c ấp nên bao g ồm :
 Việc triển khai và thực thi chính sách nhà cung c ấp.
 Việc duy trì m ột Cơ sở dữ liệu Nhà cung cấp và Hợp đồng
(SCD).
 Phân loại nhà cung cấp và hợp đồng và đánh giá rủi ro.
 Đánh giá và lựa chọn nhà cung cấp.
 Phát triển, thương thảo và thỏa thuận về hợp đồng.
 Xem xét, gia hạn và chấm dứt hợp đồng.
 Việc quản lý các nhà cung c ấp và hiệu suất của nhà cung c ấp.
 Thỏa thuận và tri ển khai dịch vụ và các kế hoạch cải tiến dịch
vụ.
 Duy trì các hợp đồng tiêu chu ẩn, các đi ều khoản và điều kiện.
 Quản lý việc giải quyết tranh chấp hợp đồng.
 Quản lý các nhà cung c ấp hợp đồng phụ.
Quản lý Nhà cung c ấp CNTT thường phải tuân thủ với các tiêu
chuẩn, hướng dẫn của doanh nghi ệp hoặc tổ chức, đặc biệt là
những gì về pháp lý, tài chính và m ua hàng c ủa doanh nghi ệp như
được m inh họa trong Hình 4.29.

265
Hình 4.29 – Quản lý Nhà cung c ấp – vai trò và tương tác
Nhằm đảm bảo rằng các nhà cung c ấp cung c ấp được giá trị về tiền
bạc và đáp ứng các đích nh ắm m ục tiêu của dịch vụ của họ, m ối
quan hệ giữa m ỗi nhà cung c ấp nên được sở hữu bởi m ột các nhân
trong tổ chức cung cấp dịch vụ. Tuy nhiên, m ột cá nhân đơn lẻ c ó
thể sở hữu m ối quan h ệ với m ột hoặc nhiều nhà cung c ấp, như được
m inh họa trong hình 4.29. Đ ể đảm bảo rằng các m ối quan hệ được
phát triển theo m ột cách nhất quán và rằng hiệu suất của nhà cun g
cấp được xem xét và qu ản lý m ột cách thích đáng, các vai trò c ần
phải được thiết lập đối với chủ sở hữu quy trình Quản lý Nhà cung
cấp và m ột Nhà Quản lý Hợp đồng. Trong các t ổ chức nhỏ hơn,
những vai trò riêng bi ệt này có thể được kết hợp lại thành m ột trách
nhiệm duy nhất.

Mục tiêu chính của quy trình Qu ản lý Nhà cung c ấp là cung cấp giá
trị về tiền bạc từ nhà cung c ấp và các hợp đồng để đảm bảo rằng
m ọi đích nhắm m ục tiêu trong các hợp đồng và các th ỏa thuận cơ sở
với nhà cung cấp được liên k ết với các nhu cầu của doanh nghi ệp
và các đích nh ắm m ục tiêu đã được thỏa thuận trong các SLA. Đi ề u
này là nhằm đảm bảo rằng việc cung c ấp các dịch vụ CNTT có ch ất
lượng, liền m ạch và từ đầu-đến-cuối được liên kết với kỳ vọng của
doanh nghiệp. Quy trình Quản lý Nhà cung c ấp nên liên kết với m ọi
yêu cầu doanh nghi ệp và yêu cầu của m ọi quy trình IT và SM khác,
đặc biệt là ISM và ITSCM. Vi ệc này đảm bảo rằng doanh nghiệp có
được giá trị từ các dịch vụ của nhà cung c ấp hỗ trợ và rằng chúng
được liên k ết với các nhu c ầu của doanh nghi ệp.

Quy trình Quản lý Nhà cung c ấp cố gắng đảm bảo răng các nhà cung
cấp đáp ứng được các điều khoản, điều kiện và đích nh ắm m ục tiêu
của các hợp đồng và thỏa thuận của họ, trong khi vẫn cố gắng gia
tăng giá tr ị về tiền bạc có được từ các nhà cung c ấp và các d ịch vụ
m à họ cung cấp. Mọi hoạt động của quy trình Qu ản lý Nhà cung c ấp

266
nên được định hướng bởi m ột chiến lược nhà cung cấp và Chi ến
lược Dịch vụ. Nhằm đạt được tính nhất quán và tính hi ệu quả trong
việc triển khai chính sách, m ột Cơ sở dữ liệu về Nhà cung c ấp và
Hợp đồng (SCD) nên đư ợc thiết lập, như được m inh họa trong Hình
4.30, cùng với các vai trò và trách nhi ệm được xác định một cách r õ
ràng.
Hình 4.30 – Quy trình Quản lý Nhà cung cấp
Lý tưởng nhất là SCD nên định hình m ột thành phần được tích hợp
của m ột CMS hoặc SKMS toàn di ện, ghi nh ận m ọi chi tiết về nhà
cung cấp và hợp đồng, cùng với các chi ti ết về kiểu (các) d ịch vụ
hoặc (các) s ản phẩm được cung c ấp bởi m ỗi nhà cung c ấp, và m ọi
thông tin và m ối quan h ệ khác với các CI khác tương ứng. Các d ịch
vụ được cung c ấp bởi các nhà cung c ấp cũng sẽ hình thành m ột
phần chủ yếu của Danh m ục Dịch vụ và Bản Mục lục Dịch vụ. Mối
quan hệ giữa các d ịch vụ hỗ trợ và CNTT và các dịch vụ nghiệp vụ
m à họ hỗ trợ là chìa khóa đ ể cung cấp các dịch vụ CNTT có ch ất
lượng.
Thông tin này trong SCD s ẽ cung cấp m ột bộ hoàn chỉnh những
thông tin tham kh ảo cho m ọi thủ tục và hoạt động Quản lý Nhà cung
cấp:
 Phân loại nhà cung cấp và sự duy trì Cơ sở dữ liệu về Nhà

cung cấp và Hợp đồng (SCD).
 Sự đánh giá và thi ết lập các nhà cung c ấp và hợp đồng m ới.
 Việc thiết lập các nhà cung cấp m ới.
 Quản lý Nhà cung c ấp, Quản lý Hợp đồng và hiệu suất.

267
 Gia hạn và chấm dứt hợp đồng.
Hai thành phần đầu tiên trong danh sách nói trên đư ợc bao hàm
trong giai đo ạn Thiết kế Dịch vụ. Thành ph ần thứ ba là m ột phần của
Chuyển tiếp Dịch vụ, và hai thành ph ần sau cùng là những bộ phận
của giai đoạn Vận hành Dịch vụ và được bao hàm chi tiết hơn trong
các ấn phẩm đó.

Phần này cung c ấp thông tin chi ti ết về quy trình Qu ản lý Nhà cung
cấp, các quy trình con và nh ững hoạt động của nó, và vi ệc quản lý
vòng đời hợp đồng.
Khi thỏa thuận với các nhà cung c ấp bên ngoài, chúng tôi khuyến
cáo m ạnh m ẽ rằng m ột hợp đồng chính th ức với các trách nhi ệm và
đích nhắm m ục tiêu được xác định, thỏa thuận và lập thành văn b ản
m ột cách rõ ràng đư ợc thiết lập và quản lý trong các giai đo ạn của
vòng đời của nó, t ừ xác định các nhu c ầu của doanh nghiệp đến vận
hành và đình ch ỉ hợp đồng:
 Xác định các nhu c ầu của doanh nghi ệp và sự chuẩn bị đề án

kinh doanh:
o Đưa ra m ột Tuyên bố về Yêu cầu (SOR) và/ho ặc Thư
mời tham gia Đấu thầu (ITT).
o Đảm bảo tuân thủ chiến lược/chính sách.
o Chuẩn bị đề án kinh doanh ban đầu, bao gồm các lựa
chọn (nội bộ và bên ngoài), chi phí, khung th ời gian,
đích nhắm m ục tiêu, lợi ích, đánh giá r ủi ro.
 Đánh giá và thu đư ợc các hợp đồng và nhà cung c ấp m ới:
o Xác định phương pháp m ua ho ặc thu mua.
o Thiết lập các tiêu chí đánh giá – ví dụ, các dịch vụ, năng
lực (của cá nhân và t ổ chức), chất lượng và chi phí.
o Đánh giá các l ựa chọn thay thế.
o Lựa chọn.
o Thương th ảo hợp đồng, các đích nh ắm m ục tiêu và các
điều khoản và điều kiện, bao gồm trách nhi ệm , chấm
dứt, gia hạn, m ở rộng, tranh ch ấp, chuyển giao.
o Thống nhất và trao hợp đồng.
 Thiết lập các nhà cung c ấp và hợp đồng m ới:
o Thiết lập dịch vụ và hợp đồng của nhà cung cấp, trong
SCD và bất kỳ hệ thống doanh nghi ệp tương ứng nào
khác.
o Chuyển tiếp dịch vụ.
o Thiết lập các liên h ệ và các m ối quan hệ.
 Phân loại nhà cung cấp và hợp đồng:
o Đánh giá hoặc tái đánh giá nhà cung c ấp và hợp đồng.
o Đảm bảo những thay đổi được tiến hành thông qua
Chuyển tiếp Dịch vụ.
o Phân loại nhà cung cấp.
o Cập nhật SCD.
o Tiếp tục duy trì SCD.

268
 Quản lý hiệu suất của nhà cung c ấp và hợp đồng:
o Quản lý và ki ểm soát sự vận hành và cung c ấp dịch
vụ/sản phẩm .
o Giám sát và báo cáo (d ịch vụ, chất lượng và chi phí).
o Xem xét và c ải thiện (dịch vụ, chất lượng và chi phí).
o Quản lý nhà cung c ấp và m ối quan hệ (truyền thông, các
rủi ro, thay đổi, lỗi, cải thiện, liên hệ, tương tác).
o Xem xét, ít nh ất hàng năm , phạm vi dịch vụ so với nhu
cầu của doanh nghi ệp, đích nhắm m ục tiêu và các th ỏa
thuận.
o Kế hoạch về khả năng kết thúc/gia h ạn/mở rộng.
 Kết thúc nhi ệm kỳ:
o Xem xét (xác đ ịnh những lợi ích đã m ang lại, những yêu
cầu tiếp theo).
o Tái thương thảo và gia h ạn hoặc chấm dứt hoặc chuyển
tiếp.
Doanh nghiệp, CNTT, tài chính, m ua hàng và thu m ua c ần phải làm

việc cùng với nhau để đảm bảo rằng mọi giai đoạn của vòng đời hợp
đồng được quản lý m ột cách hiệu quả. Mọi lĩnh vực cần được tham
gia cùng với nhau trong vi ệc lựa chọn giải pháp và qu ản lý hi ệu suất
tiếp theo đó của nhà cung c ấp, m ỗi lĩnh vực chịu trách nhi ệm về m ối
quan tâm của lĩnh vực của riêng m ình, trong khi đó v ẫn nhận thức
được những tác động lên toàn th ể tổ chức. Các quy trình liên quan
trong các giai đo ạn của vòng đời hợp đồng được giải thích chi tiết
trong những phần sau.
4.7.5.1 Đánh giá nhà cung cấp và h ợp đồng mới

Những hoạt động liên quan đ ến việc xác định các nhu cầu của
doanh nghiệp và s ự đánh giá tiếp theo sau đó v ề các nhà cung c ấp
và hợp đồng m ới là m ột phần của quy trình Thiết kế Dịch vụ. Các
đầu ra t ừ lĩnh vực này cung cấp các đầu vào cho m ọi giai đo ạn khác
của vòng đời hợp đồng. CNTT là điều sống còn đối với sự thành
công tiếp sau c ủa hợp đồng và m ối quan hệ m à doanh nghi ệp liên
quan chặt chẽ đến m ọi khía c ạnh của những hoạt động này. Mọi tổ
chức nên có các bi ểu m ẫu và m ột phương pháp chính th ức cho việc
đưa ra các đ ề án kinh doanh cũng như s ự phê duyệt và ký xác nhận
của các đề án này. Ch i tiết về các nhu cầu của doanh nghi ệp và nội
dung của đề án kinh doanh nên đư ợc thống nhất, phê duyệt và ký
xác nhận bởi cả doanh nghi ệp lẫn CNTT.
Khi lựa chọn m ột nhà cung cấp hoặc hợp đồng m ới, m ột số yếu tố
cần được cân nhắc, bao gồm hồ sơ lý lịch chuyên m ôn, năng l ực,
tham chiếu, tỷ lệ tín nhiệm và quy m ô tương đối cho doanh nghi ệp
đang được thiết lập. Ngoài ra, tùy thuộc vào kiểu quan hệ với nhà
cung cấp, có thể có các vấn đề cá nhân c ần phải được cân nhắc.
Mỗi tổ chức nên có các quy trình và th ủ tục cho việc thiết lập các
nhà cung c ấp và dịch vụ m ới.
Mặc dù đã được công nh ận rằng các yếu tố có thể tồn tại ảnh hưởng
đến quyết định về kiểu của m ối quan hệ hoặc lựa chọn nhà cung c ấp

269
(ví dụ, chính tr ị bên trong tổ chức, các m ối quan hệ hiện hữu), điều
thiết yếu là trong nh ững trường hợp như vậy, lý do được xác định và
tác động được đánh giá m ột cách đầy đủ để đảm bảo tránh được
những chi phí sai lầm.
Các dịch vụ có thể được thuê t ừ m ột nhà cung cấp duy nhất hoặc từ
nhiều nguồn khác nhau. Các d ịch vụ có nhiều khả năng được thuê t ừ
hai hoặc nhiều nhà cung c ấp cạnh tranh khi m à các yêu c ầu đối với
các dịch vụ hoặc sản phẩm tiêu chuẩn là thực sự có sẵn ‘trên kệ’.
Việc có nhiều nguồn cung ứng có nhiều khả năng được sử dụng khi
chi phí là yếu tố quyết định hàng đầu, và các yêu c ầu cho vi ệc phát
triển các biến thể của dịch vụ là thấp, nhưng cũng có th ể được thực
hiện để phân tán rủi ro. Các nhà cung c ấp trong m ột danh sách đa
nguồn cung ứng có thể được chỉ định với tình tr ạng là ‘Nhà cung c ấp
được Ưa thích’ trong m ột tổ chức, giới hạn hoặc loại bỏ phạm vi sử
dụng các nhà cung c ấp khác.
Những m ối quan hệ cộng tác được thiết lập ở cấp điều hành và ph ụ
thuộc vào s ự sẵn lòng trao đ ổi thông tin chiến lược để liên kết các
chiến lược kinh doanh v ới nhau. R ất nhiều m ối quan hệ nhà cung
cấp m ang tính chi ến lược giờ đây được định vị như là m ối quan h ệ
cộng tác. Điều này ph ản ảnh m ột sự dịch chuyển khỏi các m ối quan
hệ phân cấp truyền thống, khi m à các nhà cung c ấp hoạt động m ột
cách phụ thuộc vào tổ chức của khách hàng, với m ột đặc trưng là:
 Liên kết chiến lược: sự liên k ết tốt giữa văn hóa, giá tr ị và
các m ục tiêu dẫn đến m ột liên k ết giữa các chiến lược kinh
doanh.
 Sự tích hợp: m ột sự tích hợp chặt chẽ các quy trình c ủa hai
tổ chức.
 Luồng thông tin: truyền thông và trao đổi thông tin rõ ràng t ại
m ọi cấp độ, đặc biệt là cấp chiến lược, dẫn đến việc thấu hiểu
chặt chẽ.
 Tin tưởng lẫn nhau: m ột m ối quan hệ được xây dựng trên cơ
sở tin tưởng lẫn nhau giữa các tổ chức và các cá nhân c ủa họ.
 Cởi mở: khi báo cáo v ề hiệu suất dịch vụ, Phân tích R ủi ro và
chi phí.
 Trách nhiệm tập thể: các nhóm cộng tác chung ch ịu trách
nhiệm tập thể đối với hiệu suất hiện tại và việc phát tri ển m ối
quan hệ trong tương lai.
 Rủi ro và phần thưởng được chia sẻ: ví dụ, sự đồng thuận
về việc các chi phí và lợi ích hiệu quả từ kết quả được chia s ẻ
như thế nào, hoặc làm thế nào m à các rủi ro và ph ần thưởng
từ việc biến động chi phí và nguyên v ật liệu được chia s ẻ.
Tất cả các bên đều nhận được lợi ích từ m ối quan hệ cộng tác. Một
tổ chức nhận được giá trị ngày càng nhiều hơn từ m ột m ối quan h ệ
với nhà cung cấp khi sự thấu hiểu của nhà cung cấp về tổ chức nói
chung gia tăng lên, t ừ các kiến trúc ki ểm kê CNTT đến văn hóa
doanh nghiệp, giá trị và m ục tiêu kinh doanh c ủa họ. Cùng với thờ i
gian, nhà cung cấp có khả năng phản ứng lại m ột cách nhanh chóng

270
hơn, thích đáng hơn đ ối với các nhu c ầu của tổ chức. Những lợi ích
của nhà cung c ấp đến từ cam kết dài hạn của tổ chức, m ang lại cho
họ (nhà cung cấp) sự ổn định tài chính hơn nữa, và cho phép các
khoản đầu tư tài ch ính dài hạn, đem lại lợi ích cho khách hàng c ủa
họ.
Một quan hệ đối tác khi ến cho tất cả các bên có th ể liên kết những
cơ sở hạ tầng CNTT của họ lại với nhau. Những thỏa thuận kiểm
soát rủi ro và kiến trúc chung với nhau cho phép các đ ối tác triển
khai m ột loạt các giải pháp tương thích t ừ bảo m ật, m ạng, trao đ ổi
dữ liệu/thông tin, đ ến luồng công việc và hệ thống xử lý ứng dụng.
Sự tích hợp này có thể đem lại những cải thiện cho dịch vụ và chi
phí thấp hơn. Những dịch chuyển như vậy cũng làm giảm thiểu rủi ro
và chi phí tương ứng với các giải pháp m ột lần m ang tính chi ến
thuật, được xây dựng để làm cầu nối CNTT gi ữa CNTT c ủa nhà cung
cấp và t ổ chức với nhau.
Chìa khóa cho m ột m ối quan hệ cộng tác thành công là tr ở nên rõ

ràng m ột cách tuyệt đối về những lợi ích và chi phí m à m ột m ối quan
hệ như vậy sẽ m ang lại trước khi tham gia vào nó. Sau đó, t ất c ả
các bên hi ểu về những gì m à họ kỳ vọng ngay t ừ khi bắt đầu. Sự
thành công c ủa quan hệ cộng tác có thể liên quan đ ến việc thống
nhất về việc chuyển giao nhân vi ên cho đối tác hoặc tổ chức thuê
ngoài như là m ột phần của thỏa thuận hoặc của m ối quan hệ.
Các tổ chức cung cấp dịch vụ nên có các quy trình chính th ức và
được lập thành văn bản để đánh giá và lựa chọn các nhà cung c ấp,
dựa trên:
 Tầm quan tr ọng và tác động: tầm quan trọng của dịch vụ đối
với doanh nghiệp, được cung c ấp bởi nhà cung cấp.
 Rủi ro: những rủi ro tương ứng với việc sử dụng dịch vụ.
 Chi phí: chi phí c ủa dịch vụ và của việc cung c ấp nó.
Thường thì những lĩnh vực khác của tổ chức cung cấp dịch vụ,
chẳng hạn như Pháp lý, Tài chính ho ặc Thu m ua, sẽ có liên quan
đến khía c ạnh này của quy trình. Các t ổ chức cung cấp dịch vụ nên
có các quy trình bao hàm :
 Việc đưa ra tài liệu về đề án kinh doanh.

 Việc đưa ra SoR và Thư m ời tham gia Đấu thầu hoặc các tài
liệu yêu cầu đề xuất giải pháp.
 Sự đánh giá và l ựa chọn chính th ức các nhà cung c ấp và các
hợp đồng.
 Kết luận về các điều khoản tiêu chu ẩn, các điều khoản và điều
kiện trong hợp đồng, bao gồm việc chấm dứt sớm , điểm chuẩ n
tham chiếu, thoát (hủy) hoặc chuyển hợp đồng, xử lý tranh
chấp, quản lý các nhà cung c ấp là nhà thầu phụ và việc chấm
dứt như bình thường (chỉ việc chấm dứt việc cung c ấp dịch vụ
khi t ổ chức không còn nhu c ầu sử dụng hoặc hết hạn hợp đồng
và không ti ếp tục gia hạn – người dịch).

271
 Sự chuyển tiếp các hợp đồng và nhà cung c ấp m ới.
Những quy trình này có th ể, và nên th ế, khác nhau, d ựa trên ki ểu,

quy m ô và thể loại của nhà cung c ấp và hợp đồng.
Bản chất và m ức độ của m ột thỏa thuận phụ thuộc vào kiểu quan hệ
và m ột đánh giá về rủi ro có liên q uan. Một Phân tích Rủi ro trước
khi thỏa thuận là m ột giai đoạn m ang tính sống còn trong vi ệc thiết
lập bất kỳ thỏa thuận với nhà cung c ấp bên ngoài nào. Đ ối với m ỗi
bên, nó hiển lộ những rủi ro cần được giải quyết và cần phải toàn
diện như là m ột thực tiễn, bao gồm m ột loạt các r ủi ro như tài chính,
danh tiếng của doanh nghiệp, vận hành, quy định và pháp lý.
Một thỏa thuận toàn di ện làm tối thiểu hóa rủi ro từ những tranh
chấp phát sinh do s ự khác biệt về những kỳ vọng. Một thỏa thuậ n
linh hoạt, đáp ứng m ột cách đầy đủ sự thích ứng của nó thông qua
các điều khoản của thỏa thuận, là có thể duy trì được và hỗ trợ cho
những thay đổi với số lần thương lư ợng lại ít nhất.
Nội dung c ủa m ột hợp đồng cơ sở nền tảng hoặc thỏa thuận dịch vụ
 Các điều kho ản và điều ki ện cơ b ản: kỳ hạn (thời lượng) của

hợp đồng, các bên, vị trí, phạm vi, các đ ịnh nghĩa và cơ s ở
thương m ại.
 Mô tả dịch vụ và phạm vi: chức năng của dịch vụ sẽ được
cung cấp và m ức độ của nó, cùng với những hạn chế (ràng
buộc) trong việc cung c ấp dịch vụ, chẳng hạn như hiệu suất,
tính sẵn sàng, công su ất, giao diện kỹ thuật và bảo m ật. Chức
năng dịch vụ có thể được xác định một cách rõ ràng, hoặ c
trong trường hợp những dịch vụ được thiết lập-tốt, được bao
gồm bởi các tham chiếu tới những tài li ệu đã được thiết lập
khác, chẳng hạn như Danh m ục Dịch vụ và Bản Mục lục Dịc h
vụ.
 Các tiêu chu ẩn dịch vụ: những thước đo dịch vụ và m ức độ
tối thiểu tạo nên hiệu suất và chất lượng có thể chấp nhận
được, ví dụ, CNTT có th ể có m ột yêu c ầu về hiệu suất để đáp
ứng đối với m ột yêu cầu về hệ thống m áy tính đ ể bàn m ới
trong vòng 24 giờ, với dịch vụ có thể chấp nhận được coi là đã
xảy ra khi yêu c ầu hiệu suất này được đáp ứng trong 95% các
trường hợp. Mức dịch vụ phải thực tế, có thể đo lường được
và được liên k ết với các ưu tiên kinh doanh c ủa tổ chức và
làm nền tảng cho các đích nh ắm m ục tiêu đã th ỏa thuận trong
các SLR và SLA.
 Phạm vi khối lượng công việc: m ột phạm vi khối lượng m à
các tiêu chuẩn dịch vụ được áp dụng, hoặc cho những chế độ
giá cụ thể được áp dụng.
 Thông tin qu ản lý (MI): dữ liệu phải được báo cáo bởi nhà
cung c ấp về hiệu suất vận hành – hãy cẩn thận để đảm bảo
rằng MI được tập trung vào các thư ớc đo báo cáo quan tr ọng
nhất hoặc nổi bật nhất về m ối quan hệ sẽ được đánh giá. Các

272
Chỉ số Hiệu suất Quan tr ọng (KPI) và Th ẻ điểm Cân bằng
(BSC) có th ể hình thành nên c ốt lõi c ủa dữ liệu báo cáo hi ệu
suất.
 Trách nhiệm và phụ thuộc: m ô tả những nghĩa vụ pháp lý của
tổ chức (trong vi ệc hỗ trợ cho nhà cung cấp trong những nỗ l ự
cung cấp dịch vụ) và của nhà cung c ấp (trong việc cung cấp
dịch vụ của m ình), bao gồm truyền thông, liên h ệ và leo thang.
Một thỏa thuận dịch vụ m ở rộng có thể bao gồm :
 Các chế độ ghi nợ và tín dụng dịch vụ (bao gồm những ưu đãi
và phạt).
 Các tiêu chí hi ệu suất bổ sung.
Những điều dưới đây cung c ấp m ột số m ẫu giới hạn về các chủ đề

pháp lý và thương m ại thường được đề cập trong m ột thỏa thuận
dịch vụ hoặc hợp đồng:
 Phạm vi của các dịch vụ được cung c ấp.

 Các yêu c ầu hiệu suất dịch vụ.
 Phân chia và thỏa thuận về trách nhi ệm.
 Các điểm liên h ệ, tần suât và nội dung c ủa truyền thông và
báo cáo.
 Các quy trình xem xét h ợp đồng và giải quyết tranh ch ấp.
 Cơ cấu giá c ả.
 Các điều khoản về thanh toán.
 Những cam kết đối với sự thay đổi và đầu tư.
 Quy trình thay đ ổi thỏa thuận.
 Tính bảo m ật và thông báo.
 Bản quyền và quyền sở hữu trí tuệ.
 Những giới hạn pháp lý.
 Quyền chấm dứt (thỏa thuận) của các bên.
 Nghĩa vụ pháp lý khi ch ấm dứt (thỏa thuận) và hơn n ữa.
Hình thức cuối cùng của m ột thỏa thuận, và m ột vài thuật ngữ, có
thể được quy định bởi quan điểm và tham chiếu của phòng thu m ua
hoặc pháp chế, hoặc bởi các công ty lu ật chuyên nghi ệp.
Hãy tìm kiếm tư vấn pháp lý khi chính th ức hóa các th ỏa thuận
cung cấp từ bên ngoài.
Các hợp đồng chính thức

Các hợp đồng chính thức thích hợp đối với các thỏa thuận cung c ấp
từ bên ngoài có đóng góp đáng k ể cho việc cung c ấp và phát tr iển
doanh nghiệp. Các hợp đồng cung c ấp các cam kết pháp lý ràng
buộc giữa khách hàng và nhà cung c ấp, và bao g ồm các nghĩa v ụ
pháp lý c ủa m ỗi tổ chức đối với bên còn lại từ những ngày đầu của
hợp đồng, thường kéo dài sau khi h ợp đồng đã chấm dứt. Một hợp
đồng được sử dụng làm cơ sở cho các th ỏa thuận với nhà cung c ấp
từ bên ngoài khi m ột cam kết có thể thực thi được là cần thiết. Các
m ối quan hệ chiến lược và có giá trị cao được củng cố bởi m ột hợ p

273
đồng chính thức. Hình thức và bản chất ràng buộc của m ột hợp đồng
không m âu thuẫn với văn hóa c ủa m ột thỏa thuận đối tác, m à thay
vào đó, hình thành cơ s ở niềm tin cho m ối quan hệ.
Một hợp đồng có khả năng được cấu trúc với m ột nội dung chính
bao gồm các điều khoản thương m ại và pháp lý, và v ới các thành
phần của m ột thỏa thuận dịch vụ, như đã được m ô tả trước đây,
được đính kèm dưới dạng các lịch trình. Các hợp đồng cũng có thể
bao gồm m ột số các tài li ệu liên quan khác như các l ịch trình, ví d ụ:
 Các yêu c ầu về bảo m ật,

 Các yêu c ầu về liên tục kinh doanh,
 Các tiêu chuẩn kỹ thuật bắt buộc,
 Các kế hoạch chuyển đổi (thay đổi trước-lịch trình đã được
thống nhất),
 Các thỏa thuận tiết lộ.
Hầu hết các tổ chức lớn có các phòng pháp ch ế và thu m ua được
chuyên m ôn hóa cho các h ợp đồng nguồn cung ứng. Các công ty
pháp lý chu yên nghiệp có thể được thuê để hỗ trợ chức năng pháp
chế và thu m ua nội bộ khi thiết lập các hợp đồng chính thức quan
trọng.
Các thỏa thuận nền tảng

Theo ITIL, m ột SLA đư ợc xác định như m ột ‘thỏa thuận bằng văn
bản giữa m ột nhà cung c ấp dịch vụ và (các) k hách hàng, ghi l ại cac
m ức dịch vụ đã được thỏa thuận đối với m ột dịch vụ’. Nhà cung cấ p
dịch vụ nên nhận thức được rằng các SLA đư ợc sử dụng m ột cách
rộng rãi để chính thức hóa các m ối quan hệ dựa trên-dịch vụ, cả nội
bộ lẫn bên ngoài, và các th ỏa thuận này khác nhau m ột cách đáng
kể về chi tiết được đề cập.
Quan điểm của một vài tổ chức, chẳng hạn như Chartered
Institute of Purchase and Supply (CIPS) và các lu ật sư chuyên
m ôn khác cho rằng các SLA không nên đư ợc sử dụng để quản lý
các m ối quan hệ bên ngoài tr ừ khi chúng là m ột phần của m ột
hợp đồng cơ sở. Hướng dẫn Hoàn ch ỉnh để Chuẩn bị và Triển
khai các Thỏa thuận Mức Dịch vụ (2001) nh ấn m ạnh rằng m ột
SLA-độc lập có thể không có hi ệu lực pháp lý m à thay vào đó ‘th ể
hiện cho thiện chí và lòng tin c ủa các bên ký vào nó’. Do đó, m ối
quan tâm của nhà cung c ấp và nhà cung c ấp dịch vụ là đảm bảo
rằng các SLA được đưa và m ột khuôn khổ hợp đồng thích hợ p
đáp ứng được m ục tiêu ITIL r ằng các SLA là những thỏa thuận
ràng buộc.
Các SLA, các th ỏa thuận cơ sở và các hợp đồng nên đư ợc xem xét
trên cơ sở thường xuyên đ ể đảm bảo hiệu suất tuân thủ các m ức
dịch vụ đã được thống nhất.
Ở m ột m ức độ nào đó, t ổ chức có khả năng phụ thuộc và các nhóm

hỗ trợ nội bộ của riêng m ình. Đ ể có thể đạt được các đích nh ắm

274
m ục tiêu SLA, chúng tôi khuy ến cáo nên có các th ỏa thuận chính
thức cho các nhóm này. Các Th ỏa thuận Mức Vận hành (OLA) đ ảm
bảo rằng các dịch vụ nền tảng hỗ trợ cho các đích nhắm m ục tiêu
SLA CNTT/doanh nghi ệp. Các OLA t ập trung vào các yêu c ầu vận
hành m à các dịch vụ cần phải đáp ứng. Đây là m ột tài liệu không
phải hợp đồng, định hướng-dịch vụ mô tả các dịch vụ và các tiêu
chuẩn dịch vụ, cùng với trách nhi ệm và nghĩa vụ pháp lý nếu thích
hợp.
Cũng như với SLA, đi ều quan tr ọng là các OLA được giám sát đ ể
làm nổi bật những vấn đề tiềm ẩn. Nhà Quản lý Mức Dịch vụ chịu
trách nhiệm tổng thể cho việc xem xét hiệu suất so với đích nhắm
m ục tiêu để từ đó, hành đ ộng có thể được thực hiện để khắc phục,
và ngăn ngừa sự tái diễn trong tương lai c ủa bất kỳ vi phạm OLA
nào. Tùy thu ộc vào quy m ô c ủa tổ chức và sự đa dạng của dịch vụ,
ví dụ, các SLA và OLA, m ột Nhà Quản lý Mức Dịch vụ nên chịu trách
nhiệm cho dịch vụ và bộ các dịch vụ của m ình.
4.7.5.2 Phân loại nhà cung cấp và du y trì Cơ s ở dữ liệu về Nhà

cung cấp và các H ợp đồng
Quy trình Quản lý Nhà cung c ấp nên thích nghi và dành nhi ều thờ i
gian và nỗ lực cho việc quản lý các nhà cung c ấp chủ chốt hơn là
các nhà cung c ấp ít quan tr ọng hơn. Đi ều này có nghĩa là vài hình
thức của quy trình phân lo ại nên hiện hữu trong quy trình Qu ản lý
Nhà cung c ấp để phân loại nhà cung c ấp và các dịch vụ được cung
cấp cho doanh nghi ệp. Các nhà cung c ấp có thể được phân lo ại theo
nhiều cách, nhưng m ột trong những phương pháp t ốt nhất để phân
loại nhà cung c ấp là dựa vào việc đánh giá rủi ro và tác đ ộng tương
ứng với việc sử dụng nhà cung c ấp, và giá trị và tầm quan trọng của
nhà cung cấp và các dịch vụ của họ đối với doanh nghiệp, như đư ợc

275
Hình 4.31 – Phân loại nhà cung cấp
Lượng thời gian và nỗ lực tiêu t ốn cho vi ệc quản lý nhà cung c ấp và

m ối quan hệ sau đó có th ể phù hợp với phân loại của nó:
 Chiến lược: cho các m ối quan hệ ‘đối tác’ quan tr ọng liên
quan đến việc các nhà qu ản lý c ấp điều hành chia s ẻ những
thông tin chi ến lược bí m ật để tạo điều kiện cho các k ế hoạch
dài hạn. Những m ối quan hệ này s ẽ thường được quản lý và
sở hữu tại m ột cấp quản lý điều hành trong t ổ chức cung cấp
dịch vụ, và s ẽ liên quan đến việc liên hệ thường xuyên và đều
đặn và đánh giá hi ệu suất. Các m ối quan hệ này hầu như chắc
chắn sẽ đòi hỏi sự tham gia c ủa những tài nguyên Chi ến lược
Dịch vụ và Thi ết kế Dịch vụ, và sẽ bao gồm các chương trình
cải tiến cụ thể liên tục (ví dụ, m ột nhà cung c ấp dịch vụ mạng
cung cấp các dịch vụ m ạng toàn cầu và sự hỗ trợ cho chúng).
 Chiến thu ật: cho các m ối quan hệ liên quan tới hoạt động và
tương tác kinh doanh thương m ại quan trọng. Những m ối quan
hệ này sẽ thường được quản lý bởi quản lý cấp trung và s ẽ
liên quan đ ến việc liên hệ thường xuyên và đánh giá hi ệu suất,
thường bao gồm các chương trình c ải tiến liên t ục (ví dụ m ột
tổ chức bảo trì phần cứng cung c ấp dịch vụ xử lý các l ỗi m áy
chủ).
 Vận hành: cho các nhà cung c ấp các sản phẩm hoặc dịch vụ
vận hành. Những m ối quan hệ này thường được quản lý bởi
các quản lý vận hành sơ c ấp và sẽ liên quan vi ệc liên h ệ đều
đặn nhưng không thư ờng xuyên và đánh giá hi ệu suất (ví dụ,

276
m ột nhà cung c ấp dịch vụ lưu tr ữ Internet, cung c ấp không
gian lưu trữ cho m ột trang web ít sử dụng, tác động thấp hoặc
được sử dụng nội bộ bởi dịch vụ CNTT).
 Hàng hóa: cho các nhà cung c ấp cung cấp các sản phẩm và
dịch vụ giá tr ị thấp và/hoặc sẵn có, vốn có thể được thay thế
nguồn cung ứng một cách dễ dàng (ví dụ, nhà cung c ấp giấ y
hoặc m ực in).
Các m ối quan hệ với nhà cung c ấp quan tr ọng m ang tính chiến lược
cần được tập trung nhi ều nhất. Trong nh ững trường hợp này, các
Nhà Quản lý Nhà cung c ấp phải đảm bảo rằng văn hóa c ủa tổ chức
cung cấp dịch vụ được m ở rộng vào lĩnh vực cung cấp dịch vụ để từ
đó m ối quan hệ hoạt động vượt qua hợp đồng ban đầu. Sự gia tăng
phổ biến của nguồn cung ứng bên ngoài, và s ự gia tăng trong phạm
vi và độ phức tạp của m ột số thỏa thuận thuê nguồn cung ứng đã
dẫn đến sự đa dạng hóa các ki ểu quan hệ với nhà cung cấp. Ở cấp
độ chiến lược, điều quan tr ọng là ph ải hiểu về các tùy ch ọn đang
sẵn có để từ đó kiểu quan hệ với nhà cung c ấp phù hợp nhất có thể
được thiết lập để có được lợi ích kinh doanh l ớn nhât và phát tri ển
phù hợp với nhu c ầu của doanh nghiệp.
Để lựa chọn thành công kiểu quan hệ với nhà cung c ấp phù hợp
nhất, cần phải hiểu rõ vể các m ục tiêu của doanh nghiệp cần phả i
đạt được.
Một số các yếu tố, từ bản chất của dịch vụ đến chi phí tổng thể, xác
định m ức độ quan trọng của m ột nhà cung cấp, nhìn từ quan điểm
của doanh nghi ệp. Như được trình bày ở phần sau, ý nghĩa c ủa m ột
m ối quan hệ với nhà cung c ấp càng lớn đối với doanh nghiệp thì các
nhu cầu của doanh nghiệp càng cần phải liên quan nhiều hơn nữa
vào việc quản lý và phát tri ển m ối quan hệ. Một phương pháp ti ếp
cận phân loại chính thức có thể giúp thiết lập tầm quan tr ọng này.
Giá trị đối với doanh nghi ệp, được đo lường bằng đóng góp đã thực
hiện đối với chuỗi giá trị doanh nghiệp, cung cấp m ột đánh giá gắn
kết với doanh nghiệp hơn là giá c ả trên hợp đồng thuần túy. Tương
tự, các dịch vụ được m ua càng đạt tiêu chu ẩn thì sự phụ thuộc của
doanh nghi ệp vào nhà cung c ấp càng thấp, và nhà cung c ấp có thể
được thay thế dễ dàng hơn (n ếu cần). Các dịch vụ được tiêu chuẩn
hóa hỗ trợ cho doanh nghiệp thông qua thời gian tối thiểu để xâm
nhập thị trường khi tri ển khai các dịch vụ nghiệp vụ m ới hoặc đã
được thay đổi, và trong vi ệc theo đuổi những chiến lược giảm -chi
phí. Thông tin thêm về chủ đề này có thể tìm thấy trong ấn phẩm
Chiến lược Dịch vụ.
Các dịch vụ được tùy chỉnh càng nhi ều thì càng khó để chuyển sang
m ột nhà cung c ấp thay thế. Việc tùy chỉnh có thể có lợi cho doanh
nghiệp, đóng góp cho l ợi thế cạnh tranh thông qua dịch vụ khác bi ệt,
hoặc có thể là kết quả của sự phát triển trong hoạt động.

277
Các dịch vụ phù hợp làm tăng sự phụ thuộc vào nhà cung c ấp, tăng
rủi ro và có th ể dẫn đến sự gia tăng chi phí. T ừ quan điểm của nhà
cung cấp, các dịch vụ phù hợp có thể làm giảm khả năng c ủa họ
trong việc đạt được hiệu quả kinh t ế của quy m ô thông qua các ho ạt
động thông thường, dẫn đến tỷ suất lợi nhuận bị thu hẹp, và làm
giảm nguồn vốn sẵn có cho khoản đầu tư trong tương lai.
Các sản phẩm và dịch vụ tiêu chuẩn là phương pháp tiếp cận được
ưa thích, tr ừ khi t ồn tại m ột lợi thế kinh doanh rõ ràng, trong trư ờng
hợp đó, m ột nhà cung c ấp chiến lược cung c ấp dịch vụ phù hợp.
Các m ối quan h ệ có giá tr ị cao hoặc m ức độ phụ thuộc cao cũng

sẽ m ang lại nhiều rủi ro hơn cho t ổ chức. Những m ối quan h ệ này
cần các hợp đồng toàn di ện và quản lý m ối quan hệ chủ động.
Sau khi đã thi ết lập kiểu của nhà cung cấp, tiếp theo, m ối quan h ệ
cần được chính thức hóa. Trong đoạn thảo luận dưới đây, thu ật ngữ
‘thỏa thuận’ được sử dụng nói chung đ ể chỉ bất kỳ việc chính thức
hóa m ột m ối quan h ệ giữa tổ chức khách hàng và nhà cung c ấp, và
có thể có phạm vi t ừ không chính th ức đến các hợp đồng ràng bu ộc
pháp lý toàn di ện. Nói m ột cách đơ n giản, các m ối quan hệ có giá tr ị
thấp có thể được bao hàm bởi m ột điều khoản và điều kiện tiêu
chuẩn của nhà cung c ấp, và được quản lý toàn b ộ bởi CNTT. Một
m ối quan hệ chiến lược có t ầm quan tr ọng đối với doanh nghi ệp, nói
cách khác, đòi h ỏi m ột hợp đồng toàn di ện đảm bảo rằng nhà cung
cấp hỗ trợ cho việc phát triển các nhu cầu của doanh nghi ệp thông
qua vòng đời của hợp đồng. Một hợp đồng cần được quản lý và phát
triển kết hợp với các bộ phận thu m ua và pháp ch ế cũng như các
bên liên quan với doanh nghi ệp.
Thỏa thuận là nền tảng của m ột m ối quan hệ. Các thỏa thuận
càng phù hợp và hoàn chỉnh thì m ối quan hệ càng có kh ả năng
cung cấp những lợi ích kinh doanh ch o tất cả các bên.
Chất lượng của m ối quan hệ giữa nhà cung cấp dịch vụ và (các)
khách hàng c ủa họ thường phụ thuộc vào những cá nhân liên
quan của cả hai bên. Do đó, đi ều quan tr ọng là các cá nhân v ới
các thuộc tính, k ỹ năng, năng lực và tính cách phù h ợp được lựa
chọn để tham gia vào những m ối quan hệ này.
Một dịch vụ nghiệp vụ có thể phụ thuộc vào m ột số các nhà cung
cấp nội bộ và/hoặc bên ngoài để cung cấp nó (dịch vụ nghiệp vụ).
Điều này có thể bao gồm m ột sự pha trộn giữa các nhà cung c ấp
chiến lược và nhà cung c ấp hàng hóa. Một vài nhà cung c ấp trực
tiếp cung cấp cho tổ chức, m ột số khác lại là nhà cung cấp gián tiếp
hoặc nhà thầu phụ đang làm vi ệc với nhà cung cấp khác. Các nhà
cung cấp trực tiếp được quản lý tr ực tiếp bởi nhà cung c ấp dịch vụ,
các nhà cung cấp gián ti ếp hoặc nhà thầu phụ được quản lý bởi nhà

278
cung cấp hàng đầu. Bất kỳ m ột nhà cung c ấp nào cũng có thể cung
cấp các s ản phẩm hoặc dịch vụ được sử dụng để hỗ trợ cho m ột số
các dịch vụ nghiệp vụ khác nhau.
Phân tích chu ỗi cung ứng cho thấy việc ánh xạ giữa các dịch vụ
nghiệp vụ và các nhà cung c ấp dịch vụ. Phân tích các quy trình
nghiệp vụ sẽ tiết lộ về những nhà cung c ấp liên quan đến m ỗi quy
trình và các đi ểm giao thoa giữa họ. Việc quản lý chuỗi cung ứng
đảm bảo rằng các ranh gi ới chức năng và các yêu c ầu hiệu suất
được thiết lập m ột cách rõ ràng đối với từng nhà cung c ấp để đảm
bảo cho việc đạt được m ức dịch vụ nghiệp vụ tổng thể. Các dịch vụ
nghiệp vụ có nhiều khả năng đạt được các đích nhắm m ục tiêu củ a
chúng m ột cách nh ất quán khi có m ột số lượng nhỏ các nhà cung
cấp trong chuỗi cung ứng, và khi m à tương tác gi ữa các nhà cung
cấp trong chuỗi bị giới hạn, đơn giản và được xác định rõ ràng.
Việc giảm thiểu số lượng các nhà cung c ấp gián tiếp làm giảm số
lượng của các m ối quan hệ cần phải được quản lý, s ố lượng c ủa các
vấn đề nhà cung c ấp ngang hàng nhau c ần phải được giải quyết, và
giảm thiểu m ức độ phức tạp của các ho ạt động Quản lý Nhà cung
cấp. Một số tổ chức có thể giảm hoặc thu gọn thành công toàn b ộ
chuỗi cung ứng quanh m ột nhà cung cấp dịch vụ duy nhất, thường
được gọi là nhà cung c ấp ‘hạng nhất’. Việc quản lý các cơ s ở vật
chất thường được thuê ngoài cho m ột đối tác hoặc nhà cung c ấp
chuyên nghiệp duy nh ất, người m à lần lượt có thể ký các hợp đồng
thầu phụ cho các dịch vụ nhà hàng, bảo trì m áy bán hàng t ự động và
vệ sinh.
Việc thuê ngoài toàn b ộ các dịch vụ nghiệp vụ cho m ột ‘nhà cung
cấp hạng nhất’ duy nh ất có thể có thêm những rủi ro bổ sung. Vì lý
do này, các tổ chức cần phải cân nhắc m ột cách c ẩn trọng các chi ến
lược chuỗi cung ứng của m ình trước các hoạt động thuê ngoài chủ
yếu. Phạm vi của các dịch vụ được thuê ngoài cũng c ần được cân
nhắc để làm giảm thiểu số lượng các nhà cung c ấp trong khi vẫn
đảm bảo rằng rủi ro được quản lý và nó phù hợp với những năng lực
điển hình trên th ị trường.
SCD là m ột cơ sở dữ liệu bao gồm những chi tiết về các nhà cung
cấp của tổ chức, cùng với những chi ti ết về các sản phẩm và dịch vụ
m à họ cung cấp cho doanh nghi ệp (ví dụ, dịch vụ thư điện tử, cung
cấp m áy tính, H ỗ trợ Dịch vụ), và những chi tiết về các hợp đồng.
SCD chứa những chi ti ết về nhà cung cấp, m ột bản tổng hợp về m ỗi
sản phẩm /dịch vụ (bao gồm các thỏa thuận hỗ trợ), thông tin về quy
trình đặt hàng và, n ếu có thể, các chi ti ết hợp đồng. Lý tưởng nhất,
SCD nên được bao gồm trong CMS t ổng thể.
Các SCD có lợi vì chúng có th ể được sử dụng để khuyến khích các

nhà cung cấp được ưa thích và ngăn ch ặn việc m ua sắm những
hạng m ục không đư ợc phê duyệt hoặc không tương thích. B ằng cách
phối hợp và kiểm soát hoạt động m ua sắm , tổ chức có nhi ều kh ả
năng có thể thương lượng được m ức giá ưu đãi.

279
4.7.5.3 Việc thiết lập các nhà cung c ấp và h ợp đồng mới
Việc thêm các nhà cung c ấp hoặc hợp đồng m ới vào SCD cần được
xử lý thông qua quy trình Qu ản lý Thay đổi để đảm bảo rằng bất k ỳ
tác động nào cũng sẽ được đánh giá và hi ểu rõ. Trong h ầu hết các
tổ chức, SCD được sở hữu bởi quy trình Qu ản lý Nhà cung c ấp hoặc
Phòng Thu m ua ho ặc Mua hàng. SCD đem l ại m ột đầu mối t ập hợp
thông tin trung tâm và duy nh ất cho việc quản lý m ọi nhà cung cấp
và hợp đồng.
Đánh giá rủi ro, ho ạt động cùng với các nhà cung c ấp, là trung tâm
của việc đánh giá nh ững lỗ hổng trong từng thỏa thuận hoặc hợp
đồng với nhà cung cấp gây ra các m ối đe dọa đối với bất kỳ khía
cạnh nào c ủa doanh nghi ệp, bao gồm tác động kinh doanh, xác su ất,
sự hài lòng của khách hàng, hình ảnh thương hi ệu, thị phần, lợ i
nhuận, giá c ổ phiếu hoặc những tác động pháp lý ho ặc hình ph ạt
(trong m ột số ngành).
Bản chất của m ối quan hệ ảnh hưởng đến m ức độ rủi ro đối với
doanh nghi ệp. Những rủi ro liên quan t ới nhà cung c ấp chiến lược
hoặc được thuê ngoài có th ể có khả năng nhiều hơn về số lượng, và
phức tạp hơn để quản lý so với nguồn cung nội bộ. Hiếm khi có khả
năng xảy ra rủi ro ‘thuê ngoài’, m ặc dù đôi khi m ột vài r ủi ro có th ể
được chuyển sang cho t ổ chức cho thuê ngoài. Vi ệc đổ lỗi cho nhà
cung cấp không gây ấn tượng cho khách hàng hoặc người dùng n ội
bộ bị ảnh hưởng bởi m ột sự cố bảo m ật hoặc m ột lỗi hệ thống kéo
dài. Những rủi ro m ới phát sinh từ mối quan hệ cần được xác định
và quản lý, cùng với đó là truyền thông và leo thang khi có th ể.
Một sự đánh giá rủi ro đáng k ể nên được thực hiện trước-hợp đồng,
tuy nhiên việc này cần được duy trì trong đi ều kiện nhu cầu kinh
doanh thay đ ổi, phạm vi hợp đồng thay đổi hoặc những thay đổi
trong m ôi trường hoạt động.
Tổ chức cung cấp dịch vụ và nhà cung cấp phải xem xét những m ối
đe dọa đối với những tài sản của riêng họ do m ối quan hệ gây ra, và
lập hồ sơ rủi ro của riêng những tài sản này. Mỗi m ột hồ sơ phải xác
định được chủ sở hữu rủi ro tương ứng của chúng. Trong m ột m ối
quan hệ vẫn đang hoạt động t ốt, có khả năng phần lớn hoặc toàn b ộ
m ọi đánh giá được chia s ẻ m ột cách c ởi m ở với các bên khác. B ằng
cách m ời các chuyên gia c ủa nhà cung c ấp tham gia vào vi ệc đánh
giá rủi ro, đặc biệt là trong các Đánh giá R ủi ro Vận hành (ORA), t ổ
chức có thể có được những quan đi ểm sâu s ắc vô giá về cách thức
tốt nhất để giảm thiểu rủi ro cũng như vi ệc cải thiện phạm vi bao
phủ của đánh giá.
Khi đánh giá những rủi ro hoặc gián đoạn đối với các dịch vụ hoặc
chức năng nghiệp vụ, doanh nghi ệp phải có các m ức độ ưu tiên
khác nhau cho việc khôi phục dịch vụ/chức năng. Phân tích Tác
động Kinh doanh (BIA) là m ột phương pháp được sử dụng để đánh
giá tác động lên nh ững lĩnh vực khác nhau c ủa doanh nghi ệp, do k ết
quả của việc m ất dịch vụ. Các hoạt động đánh giá rủi ro và BIA liên

280
quan đến các nhà cung c ấp và các h ợp đồng nên được thực hiện
cùng với Quản lý Liên t ục Dịch vụ, Quản lý Tính s ẵn sàng và Quản
lý Bảo m ật thông tin, v ới quan điểm nhằm làm giảm thiểu tác động
và xác suất của lỗi dịch vụ do nhà cung cấp hoặc lỗi dịch vụ của nhà
cung cấp.
Khi những hoạt động này đã hoàn thành, và thông tin v ề nhà cung
cấp và hợp đồng đã đư ợc nhập vào SCD, bao g ồm các cá nhân
được chỉ định chịu trách nhiệm cho việc quản lý nhà cung c ấp
và/hoặc các hợp đồng m ới, tần suất của các cuộc họp xem xét dịch
vụ/nhà cung c ấp và các cuộc họp xem xét hợp đồng cần được thiết
lập, với các điểm ngắt, các ngư ỡng và c ảnh báo tự động có s ẵn
thích hợp. Việc giới thiệu các nhà cung c ấp và hợp đồng m ới nên
được xử lý như là nh ững thay đổi quan trọng thông qua quá trình
chuyển tiếp đi vào vận hành. Việc này s ẽ đảm bảo rằng các hợp
đồng và điểm liên hệ thích hợp được thiết lập.
4.7.5.4 Quản lý Hợp đồng và Nhà cung c ấp và hiệu suất

Ở cấp độ vận hành, các quy trình tích h ợp cần phải được đặt giữa
tổ chức và các nhà cung c ấp của họ để đảm bảo những thực tiễn
hoạt động hằng ngày. Ví d ụ:
 Nhà cung cấp có được kỳ vọng sẽ tuân thủ quy trình Qu ản lý

Thay đổi hoặc bất kỳ quy trình nào khác c ủa tổ chức không?
 Bộ phận Hỗ trợ Dịch vụ thông báo cho nhà cung c ấp về các
sự cố như thế nào?
 Thông tin CMS được cập nhật như thế nào khi CI thay đ ổi do
kết quả từ các hoạt động của nhà cung c ấp? Ai sẽ là người
chịu trách nhiệm ?
Có thể có xung đ ột về lợi ích giữa tổ chức cung c ấp dịch vụ và nhà

cung cấp của họ, đặc biệt khi liên quan đ ến các quy trình Quản lý
Thay đổi, Quản lý S ự cố, Quản lý Vấn đề và Quản lý Cấu hình. Nhà
cung cấp có thể muốn sử dụng các quy trình và h ệ thống của họ,
trong khi t ổ chức cung cấp dịch vụ sẽ m uốn sử dụng các quy trình
và hệ thống của riêng h ọ. Nếu đúng như vậy, các trách nhiệm và
giao diện rõ ràng s ẽ cần phải được xác định và thống nhất.
Những lĩnh vực này và r ất nhiều lĩnh vực khác c ần được giải quyết
để đảm bảo hoạt động trơn tru và hi ệu quả ở cấp độ vận hành. Để
làm được điều này, m ọi điểm tiếp xúc và liên h ệ cần được xác đ ịnh
và các thủ tục có sẵn để m ọi người hiểu rõ vai trò và trách nhi ệm
của m ình. Đi ều này nên bao g ồm việc xác định cá nhân được ch ỉ
định duy nhất, chịu trách nhi ệm về quyền sở hữu của từng nhà cung
cấp và hợp đồng. Tuy nhiên, m ột tổ chức nên lưu ý rằng không nên
áp đặt các quy trình của riêng m ình m ột cách t ự động mà nên t ận
dụng cơ hội để học hỏi từ các nhà cung cấp của m ình.

281
Một hợp đồng đã được trao cho m ột Hệ thống Kiểm soát Cửa
hàng được tùy chỉnh vì những gì m à bộ phận CNTT c ủa t ổ chức
đã phát tri ển các quy trình đ ể hỗ trợ dịch vụ trực tiếp sau khi
được cài đặt. Điều này bao gồm các thủ tục để ghi nhận lại và ghi
thành văn bản công việc do các k ỹ sư hiện trường thực hiện trên
dịch vụ (ví dụ: thay đổi, sửa chữa, tăng cư ờng và thiết lập cấu
hình lại). T ại m ột cuộc họp về tiến độ dự án, nhà cung c ấp xác
nhận rằng họ đã xem xét các thủ tục và có th ể làm theo n ếu được
yêu cầu. Tuy nhiên, vì đã ở trong tình huống này rất nhiều lần
trước đây, họ đã xây dựng m ột bộ các thủ tục để ứng phó với
những sự kiện như vậy. Các thủ tục này hợp thời, hiệu quả và d ễ
tuân thủ hơn đáng kể so với các thủ tục do tổ chức phát triển và
đề xuất.
Ngoài các giao di ện quy trình, điều thiết yếu là phải xác định cách
thức m à các vấn đề được xử lý ở cấp độ vận hành. Bằng cách xác
định m ột cách rõ ràng và truy ền đạt các lộ trình leo thang, các vấn
đề có khả năng đư ợc xác định và giải quyết sớm hơn, gi ảm thiểu
được các tác động. Cả tổ chức và nhà cung c ấp đều được hưởng lợi
từ việc nắm bắt và giải quyết sớm các vấn đề.
Cả hai bên đều nên cố gắng thiết lập các kết nối truyền thông rõ
ràng. Nhà cung c ấp học hỏi được nhiều hơn về việc kinh doanh củ a
tổ chức, các yêu c ầu và kế hoạch của họ, giúp cho nhà cung c ấp
hiểu và đáp ứng được các nhu c ầu của tổ chức. Đến lượt m ình, tổ
chức được hưởng lợi từ m ột nhà cung cấp nhạy bén hơn, ngư ời
nhận thức về những định hướng và bất kỳ vấn đề kinh doanh nào,
và do đó, có nhiều khả năng hơn để cung cấp các giải pháp thích
hợp. Những liên k ết hàng ngày chặt chẽ có thể giúp cho các bên
nhận thức được văn hóa và c ách thức hoạt động của bên khác, d ẫn
đến việc ít hiểu nhầm hơn và m ột m ối quan hệ dài hạn và thành
công hơn.
Hai cấp độ xem xét chính thức cần phải có trong toàn bộ vòng đời
hợp đồng để tối thiểu hóa r ủi ro và đảm bảo doanh nghi ệp hiện thực
hóa lợi ích t ối đa từ hợp đồng:
 Xem xét hi ệu suất của dịch vụ/nhà cung c ấp: các báo cáo
về hiệu suất nên được đưa ra trên cơ s ở định kỳ, căn c ứ vào
thể loại nhà cung c ấp, và nên hình thành cơ s ở của các cuộc
họp đánh giá dịch vụ. Nhà cung cấp càng quan tr ọng thì tần
suất và độ sâu r ộng của các báo cáo và xem xét càng nên ph ải
nhiều hơn.
 Xem xét dịch vụ, phạm vi dịch vụ và hợp đồng: những xem
xét này cũng nên đư ợc tiến hành trên cơ s ở định kỳ, ít nhất
hàng năm đối với các nhà cung c ấp chính yếu. Mục tiêu của
những xem xét này nên là đ ể đánh giá dịch vụ, hiệu suất tổng
thể, phạm vi dịch vụ và các đích nh ắm m ục tiêu và hợp đồng,
cùng với bất kỳ thỏa thuận tương ứng nào. Việc (xem xét) này
nên được so sánh với nhu cầu doanh nghiệp ban đầu và nhu

282
cầu doanh nghi ệp hiện tại để đảm bảo rằng nhà cung cấp và
các hợp đồng vẫn giữ được liên k ết với nhu c ầu của doanh
nghiệp và ti ếp tục cung c ấp giá tr ị về tiền bạc (cho doanh
nghiệp).
Các cuộc họp xem xét hiệu suất chính thức phải được tiến hành trên
cơ sở định kỳ để xem xét hi ệu suất của nhà cung cấp so với các
m ức dịch vụ, ở m ột m ức vận hành chi ti ết. Những cuộc họp này cung
cấp m ột cơ hội để kiểm tra việc quản lý hiệu suất dịch vụ đang diễn
ra vẫn giữ được sự tập trung vào vi ệc hỗ trợ cho các nhu c ầu của
doanh nghiệp. Các ch ủ đề phổ biến bao gồm :
 Hiệu suất dịch vụ so với các đích nh ắm m ục tiêu.

 Các đánh giá s ự cố và vấn đề, bao gồm bất kỳ vấn đề được
leo thang nào.
 Phản hồi của doanh nghi ệp và khách hàng.
 Những thay đ ổi chính được kỳ vọng là s ẽ (hoặc có thể) ảnh
hưởng đến dịch vụ trong chu kỳ dịch vụ tiếp theo, cũng như là
những thay đ ổi thất bại và những thay đổi gây ra vấn đề.
 Các sự kiện kinh doanh then ch ốt trong chu k ỳ dịch vụ tiếp
theo cần được đặc biệt chú ý bởi nhà cung cấp (ví dụ, xử lý
cuối quý).
 Thực tiễn tốt nhất và các K ế hoạch Cải thiện Dịch vụ (SIPs).
Các sáng ki ến và hoạt động cải tiến dịch vụ chính yếu được kiểm
sóat thông qua các SIP với m ỗi nhà cung cấp, bao gồm bất kỳ hành
động nào để xử lý bất kỳ lỗi hoặc điểm yếu nào. Tiến trình c ủa các
SIP hiện tại, hoặc nhu cầu đối với sáng kiến m ới, được xem xét t ại
các cuộc họp đánh giá dịch vụ. Các t ổ chức tiên phong hoặc có t ư
duy tiến bộ không ch ỉ sử dụng SIP để xử lý các lỗi m à còn đ ể cả i
thiện m ột dịch vụ đạt được m ột cách nhất quán. Điều quan trọng là
m ột hợp đồng cung cấp các đãi ngộ phù hợp để cả hai bên đ ầu tư
vào cải thiện dịch vụ. Những khía c ạnh này được bao hàm chi tiết
hơn trong ấn phẩm Liên tục Cải tiến Dịch vụ.
Các cơ chế quản trị đối với các nhà cung c ấp và hợp đồng được rút
ra từ những nhu c ầu của các bên liên qua n tương ứng tại các c ấp độ
khác nhau trong m ỗi tổ chức, và được cấu trúc để từ đó các đại diện
của tổ chức đối đầu với các đối tác c ủa họ trong tổ chức của nhà
cung cấp. Việc xác định trách nhi ệm cho m ỗi đại diện, các di ễn đàn
hội họp và các quy trình đ ảm bảo rằng m ỗi cá nhân tham gia vào
đúng thời điểm để gây ảnh hưởng hoặc định hướng các hoạt động
đúng đắn.
Quy m ô và tầm quan tr ọng của dịch vụ và/hoặc nhà cung c ấp có ảnh
hưởng đến các th ỏa thuận quản trị cần thiết. Sự phụ thuộc càng
đáng kể thì sự cam kết và nỗ lực liên quan đ ến việc quản lý m ối
quan hệ càng nhiều. Nỗ lực cần thiết từ phía nhà cung cấp để quản
lý m ột hợp đồng thuê ngoài không nên b ị đánh giá quá thấp, đặc biệt
là trong các ngành đư ợc quản lý m ột cách ch ặt chẽ, chẳng hạn như
các lĩnh vực tài chính và dược phẩm .

283
Mục tiêu chủ yếu của Quản lý Nhà cung c ấp là đảm bảo rằng giá tr ị
của m ột nhà cung c ấp đối với tổ chức được hiện thực hóa m ột cách
đầy đủ. Giá tr ị được hiện thực hóa thông qua m ọi khía c ạnh c ủa m ối
quan hệ, từ đảm bảo hiệu suất vận hành, khả năng đáp ứng các yêu
cầu thay đổi và s ự dao động của các nhu c ầu, thông qua vi ệc đóng
góp kiến thức và kinh nghi ệm cho năng lực của tổ chức. Nhà cung
cấp dịch vụ cũng phải đảm bảo rằng các ưu tiên c ủa nhà cung c ấp
khớp với các ưu tiên c ủa doanh nghiệp. Nhà cung cấp phải hiểu
được rằng m ức dịch vụ nào của m ình là quan tr ọng nhất đối với
doanh nghiệp.
Một công ty đa qu ốc gia lớn đã có m ột thỏa thuận về phần m ềm

với cùng m ột nhà cung cấp ở không ít hơn 24 quốc gia. Bằng
cách thu xếp m ột hợp đồng cấp phép toàn c ầu duy nhất với nhà
cung cấp, công ty đã ti ết kiệm hàng năm 5.000.000 b ảng Anh.
Để đảm bảo rằng tất cả các hoạt động và liên h ệ với nhà cung c ấp là
nhất quán và phối hợp, m ỗi m ối quan hệ với nhà cung c ấp phải c ó
m ột cá nhân được chỉ định duy nhất chịu trách nhi ệm về tất cả các
khía cạnh của m ối quan hệ.
Một tổ chức bán lẻ trên quy m ô toàn qu ốc có m ột cá nhân tổng

thể sở hữu quyền quản lý nhà cung c ấp các dịch vụ m ạng chính
của họ. Tuy nhiên, các d ịch vụ, hợp đồng và thanh toán l ại được
quản lý bởi m ột số cá nhân tr ải rộng khắp tổ chức. Chủ sở hữu cá
nhân đưa ra m ột đề án kinh doanh cho quy ền sở hữu duy nhất
của nhà cung c ấp và tất cả các hợp đồng khác nhau, cùng với
việc hợp nhất t ất cả các hóa đơn riêng l ẻ thành m ột hóa đơn
hàng quý. Chi phí ư ớc tính tiết kiệm được cho tổ chức là hơn
600.000 bảng Anh m ỗi năm .
Các khảo sát về mức độ hài lòng cũng đóng m ột vai trò quan tr ọng
trong việc tiết lộ việc các m ức dịch vụ của nhà cung c ấp được liên
kết với các nhu c ầu của doanh nghi ệp tốt đến m ức nào. Một khảo
sát có thể tiết lộ các trường hợp cho thấy có sự không hài lòng với
dịch vụ, nhưng nhà cung c ấp dường như đang hoạt động tốt so với
các đích nh ắm m ục tiêu của họ (và ngược lại). Điều này có thể xảy
ra khi các m ức dịch vụ được xác định m ột các không thích đáng và
nên dẫn đến m ột đánh giá về các hợp đồng, thỏa thuận và đích
nhắm m ục tiêu. Một số nhà cung c ấp dịch vụ công bố bảng xếp hạng
các nhà cung cấp dựa trên các k ết quả khảo sát c ủa họ, kích thíc h
được sự cạnh tranh gi ữa các nhà cung cấp với nhau.
Đối với các m ối quan h ệ với nhà cung cấp m à doanh nghiệp có lợi
ích trực tiếp, cả doanh nghiệp (kết hợp với bộ phận thu m ua) và
CNTT sẽ phải thiết lập các m ục tiêu của họ cho m ối quan hệ, và xác
định những lợi ích m à họ kỳ vọng sẽ được hiện thực hóa. Điều này
hình thành nên m ột phần chính yếu của đề án kinh doanh cho vi ệc
bước vào m ối quan hệ.

284
Những lợi ích này ph ải được liên k ết và bổ sung, và ph ải được đo
lường và quản lý. Khi doanh nghi ệp đang tìm kiếm những cải thiện
trong dịch vụ khách hàng, các m ối quan h ệ với nhà cung cấp CNTT
góp phần vào những dịch vụ khách hàng đó phải có khả năng chứng
m inh là dịch vụ đã được cải thiện trong lĩnh vực của riêng h ọ, và
việc này đã góp ph ần cải thiện dịch vụ khách hàng nhiều đến m ức
nào.
Để việc đánh giá lợi ích vẫn giữ được hiệu lực trong suốt thời hạ n
của hợp đồng, những thay đổi trong hoàn c ảnh đã xảy ra kể từ khi
tình cảnh quyền lợi ban đầu đã được chuẩn bị phải được tính đến.
Một nhà cung c ấp có thể đã được lựa chọn dựa trên khả năng tiết
kiệm 5% chi phí hoạt động hàng năm so v ới các lựa chọn khác,
nhưng sau hai năm vẫn không m ang l ại được sự tiết kiệm . Tuy
nhiên, trong trường hợp điều này xảy ra là do những thay đổi đối với
hợp đồng, hoặc chi phí chung c ủa ngành cũng s ẽ ảnh hưởng đến
các lựa chọn khác, thì r ất có khả năng là việc tiết kiệm chi phí tương
đối vẫn đang đư ợc hiện thực hóa. Một hoàn cảnh lợi ích được duy
trì cho thấy sự tiết kiệm .
Đánh giá lợi ích thường nhận được m ức độ ưu tiên thấp hơn so với
các sáng ki ến tiết kiệm chi phí và ít được ưu tiên hơn trong báo cáo
về hiệu suất so với các sự cố và tóm tắt vấn đề, nhưng đi ều quan
trọng đối với m ối quan hệ lâu dài là các thành t ựu được công nhận.
Một báo cáo lợi ích phải đưa ra những đánh giá khách quan so v ới
các m ục tiêu ban đ ầu, nhưng cũng có thể bao gồm bằng chứng giai
thoại thúc đẩy tinh thần về thành tích và giá tr ị gia tăng.
Điều quan tr ọng đối với cả hai t ổ chức, và đối với sự trường t ồn
của m ối quan hệ, là những lợi ích thu được từ m ối quan hệ phải
được xem xét và báo cáo thư ờng xuyên.
Từ quan điểm doanh nghiệp, việc đánh giá m ức độ thành công c ủa

m ối quan hệ với nhà cung cấp có thể chủ yếu dựa trên hiệu suất của
hoạt động tài chính. Ngay cả khi m ột dịch vụ đang hoạt động t ốt, nó
có thể không đáp ứng được m ục tiêu tài chính c ủa m ột hoặc cả hai
bên. Điều quan tr ọng là c ả hai bên tiếp tục được hưởng lợi về m ặt
tài chính từ m ối quan h ệ. Một hợp đồng ép biên đ ộ lợi nhuận của
nhà cung cấp quá chặt có thể dẫn đến việc nhà cung c ấp đầu tư quá
thấp, dẫn đến dịch vụ dần dần xuống cấp, hoặc thậm chí đe d ọa khả
năng tồn tại của nhà cung c ấp. Trong c ả hai trường hợp, điều này có
thể dẫn đến các tác động kinh doanh b ất lợi đối với tổ chức
Chìa khóa đối với sự thành công trong Qu ản lý Tài chính dài h ạn
của m ột hợp đồng là m ột nỗ lực chung hướng tới việc duy trì trạng
thái cân bằng tài chính hơn là m ột m ối quan hệ đối đầu chỉ m ang lại
những lợi ích ngắn hạn chỉ cho m ột bên.
Việc xây dựng các m ối quan hệ đòi hỏi cả thời gian lẫn nỗ lực. Kết
quả là t ổ chức có thể chỉ có khả năng xây dựng những m ối quan hệ

285
dài hạn với m ột số ít các nhà cung c ấp. Kinh nghiệm , văn hóa và
cam kết của những người tham gia vào vi ệc quản lý m ột m ối quan
hệ với nhà cung c ấp ít nhất cũng quan trọng như việc có được m ột
hợp đồng và cơ ch ế quản trị tốt. Con người phù hợp với thái độ phù
hợp trong nhóm quan h ệ có thể làm cho m ột hợp đồng tồi có đư ợc
hiệu quả, nhưng m ột hợp đồng tốt không đảm bảo rằng m ột nhóm
quan hệ kém sẽ m ang lại hiệu quả (của hợp đồng).
Thông thường thì m ột lượng thời gian và ti ền bạc đáng kể được đầu
tư cho việc thương thảo các giao dịch với các nhà cung c ấp lớn, với
nhiều rủi ro hơn cho cả hai bên nếu mối quan hệ không thành công.
Cả hai tổ chức phải đảm bảo rằng họ đã đầu tư thích đáng cho
nguồn nhân lực đã phân b ổ cho việc quản lý m ối quan hệ. Cá tính,
hành vi và văn hóa c ủa những đại diện cho m ối quan hệ đều có ảnh
hưởng đến m ối quan hệ. Đối với m ột quan hệ đối tác, tất cả những
ai tham gia c ần phải có khả năng tôn trọng và làm việc chặt chẽ và
hiệu quả với những đối tác của họ.
4.7.5.5 Gia hạn và/hoặc chấm dứt hợp đồng

Các xem xét hợp đồng phải được thực hiện trên cơ sở định kỳ để
đảm bảo rằng hợp đồng vẫn tiếp tục đáp ứng được những nhu c ầu
của doanh nghi ệp. Việc xem xét hợp đồng đánh giá ho ạt động của
hợp đồng m ột cách tổng thể và ở cấp độ cao hơn các xem xét d ịch
vụ được thực hiện ở cấp độ vận hành. Những xem xét (h ợp đồng)
này nên cân nh ắc:
 Hợp đồng hoạt động tốt đến m ức nào và m ức độ liên quan của
nó trong tương lai.
 Những thay đ ổi nào là c ần thiết: các dịch vụ, sản phẩm , hợp
đồng, thỏa thuận hay các đích nh ắm m ục tiêu.
 Tầm nhìn tương lai cho m ối quan hệ là gì – tăng trưởng, co
rút, thay đổi, chấm dứt, chuyển, v.v…?
 Hiệu suất thương m ại của hợp đồng, các đánh giá so v ới điểm
chuẩn so sánh ho ặc đánh giá th ị trường, độ phù hợp của cơ
cấu giá và các th ỏa thuận định phí.
 Hướng dẫn về định hướng hợp đồng tương lai và s ự đảm bả o
các quy trình qu ản lý thực tiễn tốt nhất được thiết lập.
 Quản trị nhà cung c ấp và hợp đồng.
Đối với các thỏa thuận cung c ấp có giá tr ị cao, kéo dài hoặc phức
tạp, thời gian thương thảo và thỏa thuận hợp đồng có thể kéo dài,
tốn kém và có th ể làm kéo dài thời gian đàm phán. Đây có th ể là m ột
khuynh hư ớng tự nhiên khi m ong m uốn tránh nh ững thay đổi thêm
đối với hợp đồng càng lâu càng t ốt. Tuy nhiên, đ ể doanh nghiệp thu
được đầy đủ giá trị từ m ối quan hệ với nhà cung c ấp, hợp đồng phải
có khả năng được điều chỉnh m ột cách thường xuyên và nhanh
chóng để cho phép doanh nghi ệp được hưởng lợi từ việc phát triển
dịch vụ.
Việc so sánh đi ểm chuẩn cung cấp m ột đánh giá so với thị trường.
Nhà cung cấp có thể được cam kết bởi hợp đồng để duy trì các

286
khoản phí so với t ỷ giá trên thị trường. Để duy trì được tỷ suất lợi
nhuận như cũ, nhà cung c ấp có nghĩa vụ cải thiện hiệu quả vận
hành của m ình để thích ứng với các đối thủ cạnh tranh của họ. Nói
chung, những phương pháp này giúp m ang l ại m ột đánh giá về m ột
sự cải thiện hoặc giảm sút trong tính hi ệu quả.
Trọng điểm của trách nhi ệm trong m ột tổ chức cho việc quyết định
thay đổi m ột m ối quan hệ với nhà cung c ấp có nhiều khả năng phụ
thuộc vào kiểu của m ối quan hệ. Nhà cung c ấp dịch vụ có thể phải
xác định nhu c ầu thay đổi nhà cung c ấp, căn c ứ vào hiệu suất của
nhà cung cấp hiện hành, tuy nhiên, đ ối với m ột m ối quan h ệ hợp
đồng, quyết định cần được đưa ra cùng với bộ phận thu m ua và
pháp lý của tổ chức.
Tổ chức nên tiến hành các bư ớc m ột cách c ẩn trọng để:
 Hoàn thành m ột Phân tích Tác đ ộng và Rủi ro triệt để về việc

thay đổi nhà cung c ấp đối với tổ chức và việc kinh doanh của
nó, đặc biệt là trong su ốt giai đoạn chuyển tiếp. Việc này có
thể đặc biệt quan tr ọng trong trường hợp về m ột m ối quan hệ
chiến lược.
 Đánh giá về m ặt thương m ại đối với chi phí thoát ra (kh ỏi m ối
quan hệ). Việc này có thể bao gồm các chi phí chấm dứt hợp
đồng nếu trách nhiệm pháp lý của nhà cung cấp không rõ
ràng, nhưng kho ản chi phí lớn nhất có khả năng liên quan đến
m ột dự án chuyển tiếp. Đối với bất kỳ m ối quan hệ có quy m ô
đáng kể nào, việc này thường bao gồm một khoảng thời gian
cung c ấp-kép khi cá c dịch vụ được chuyển đổi. Bất kỳ thay đổi
liên quan đ ến việc thay đổi m ột nhà cung c ấp sẽ làm gia tăng
chi phí, ngay c ả ngay lập tức dưới dạng chi phí c ố định, hoặc
theo thời gian khi m à nhà cung c ấp gánh chịu chi phí và ph ản
ảnh trở lại dưới dạng các khoản phí dịch vụ.
 Tư vấn pháp lý về các điều khoản chấm dứt, thời hạn và cơ
chế thông báo có thể được áp dụng, và bất kỳ hậu quả nào
khác, đặc biệt nếu hợp đồng bị chấm dứt sớm (so với thời hạn
hợp đồng).
 Tái đánh giá thị trường để xác định những lợi ích tiềm năng
trong việc thay đổi nhà cung c ấp.
Một tổ chức thận tr ọng thực hiện hầu hết các bước này t ại thời điểm
hợp đồng ban đầu được thiết lập, để đảm bảo các điều khoản và
điều kiện được bao gồm (trong hợp đồng), tuy nhiên, ho ạt động xem
xét cần được tái đ ánh giá khi m ột thay đổi nhà cung c ấp được cân
nhắc.
4.7.6 Các điều kiện kích hoạt, đầu vào, đ ầu ra và các tương tác
Có rất nhiều sự kiện có thể kích hoạt hoạt động Quản lý Nhà cung
cấp. Những sự kiện này bao g ồm :
 Các hướng dẫn quản trị doanh nghi ệp mới hoặc được thay đổi.

287
 Các chiến lược, chính sách và k ế hoạch doanh nghi ệp hoặ c
CNTT m ới hoặc được thay đổi.
 Những nhu cầu kinh doanh hoặc các dịch vụ m ới hoặc được
thay dổi.
 Những yêu c ầu mới hoặc được thay đổi trong thỏa thuận,
chẳng hạn như các SLR, SLA, OLA ho ặc hợp đồng.
 Các hoạt động định kỳ như xem xét, đi ều chỉnh hoặc báo cáo,
bao gồm xem xét và đi ều chỉnh các chính sách, báo cáo và k ế
hoạch Quản lý Nhà cung c ấp.
 Các yêu cầu từ những lĩnh vực khác, đặc biệt là SLM và Quản
lý Bảo m ật, để hỗ trợ cho các vấn đề của nhà cung cấp.
 Các yêu cầu đối với các hợp đồng m ới, gia hạn hợp đồng hoặc
chấm dứt hợp đồng.
 Tiến hành tái phân lo ại các nhà cung c ấp và/hoặc hợp đồng.
Những tương tác chính m à Qu ản lý Nhà cung c ấp có với các quy

trình khác bao gồm :
 ITSCM: liên quan đ ến việc quản lý tính liên t ục của các nhà
cung cấp dịch vụ.
 SLM: hỗ trợ cho việc xác định các đích nh ắm m ục tiêu, các
yêu cầu và trách nhiệm và những kết luận của chúng trong các
thỏa thuận và hợp đồng nền tảng để đảm bảo rằng chúng hỗ
trợ cho m ọi đích nh ắm m ục tiêu c ủa SLR và SLA. Tương t ự đối
với việc điều tra về các vi phạm SLR và SLA do hi ệu suất kém
của nhà cung cấp.
 ISM: trong vi ệc quản lý các nhà cung c ấp và quyền truy cập
của họ vào các dịch vụ và hệ thống, và trách nhi ệm của họ
liên quan đến việc tuân thủ các yêu c ầu và chính sách ISM.
 Quản lý Tài chính: đ ể cung cấp nguồn vốn đầy đủ cho các yêu
cầu Quản lý Nhà cung c ấp về m ặt tài chính và các h ợp đồng
và để cung cấp khuyến cáo và hướng dẫn về các vấn đề thu
m ua và m ua s ắm .
 Quản lý Danh m ục Dịch vụ: để đảm bảo rằng m ọi dịch vụ hỗ
trợ và các chi ti ết và những m ối quan hệ của chúng được
phản ảnh m ột cách chính xác trong Danh m ục Dịch vụ.
4.7.6.1 Đầu vào

 Thông tin về doanh nghiệp: từ chiến lược, các k ế hoạch và
kế hoạch tài chính c ủa doanh nghiệp, và thông tin v ề các yêu
cầu hiện tại và tương lai c ủa họ.
 Chiến lư ợc nhà cung cấp và h ợp đồng: điều này bao gồm
chính sách nguồn cung ứng của nhà cung c ấp dịch vụ và kiểu
của nhà cung c ấp và các hợp đồng được sử dụng. Được đưa
ra bởi các quy trình Chi ến lược Dịch vụ.
 Các kế hoạch và chiến lược của nhà cung cấp: những chi
tiết về các kế hoạch và chiến lược kinh doanh của nhà cung
cấp, cùng với các chi ti ết về những phát triển và kế hoạch về
công nghệ của họ, và các báo c áo và thông tin v ề trạng thái

288
tài chính hiện tại của họ và khả năng kinh doanh đư ợc dự
kiến.
 Các hợp đồng, thỏa thuận và đích nh ắm mục tiêu của nhà
cung cấp: của cả các hợp đồng và nhà cung c ấp m ới lẫn hiện
tại.
 Các vấn đề hiệu suất: các quy trình Qu ản lý Vấn đề và Sự cố,
cùng với các vấn đề và sự cố liên quan đ ến hiệu suất hợp
đồng hoặc nhà cung cấp kém .
 Thông tin về tài chính: từ Quản lý Tài chính, chi phí c ủa
(các) dịch vụ của nhà cung cấp và chi phí cung c ấp (dịch vụ),
chi phí của các hợp đồng và k ết quả lợi ích kinh doanh cũng
như các k ế hoạch và ngân sách tài chính, cùng v ới các chi phí
liên quan đến lỗi dịch vụ và lỗi nhà cung cấp.
 Thông tin về dịch vụ: từ các quy trình SLM, với các chi ti ết
về dịch vụ từ Danh m ục Dịch vụ và Bản Mục lục Dịch vụ, các
đích nhắm m ục tiêu m ức dịch vụ trong các SLA và SLR, và có
thể từ việc giám sát các SLA, đánh giá d ịch vụ và các vi ph ạm
SLA. Đồng thời là dữ liệu về m ức độ hài lòng của khách hàng
đối với chất lượng dịch vụ.
 CMS: bao gồm thông tin về các m ối quan hệ giữa doanh
nghiệp, các dịch vụ, các dịch vụ hỗ trợ và công ngh ệ.
4.7.6.2 Đầu ra
Các đầu ra của Quản lý Nhà cung cấp được sử dụng trong m ọi phần
khác của quy trình, bởi rất nhiều quy trình khác và bởi các bộ phận
khác của tổ chức. Thông tin này thư ờng được cung c ấp dưới dạng
các báo cáo đi ện t ử hoặc những hiển thị trên các khu vực được chia
sẻ hoặc các trang trên các m áy ch ủ intranet để đảm bảo rằng phần
lớn thông tin c ập nhật luôn được sử dụng. Thông tin đư ợc cung c ấp
như dưới đây:
 Cơ sở dữ liệu về Nhà cung cấp và Hợp đồng (SCD): nắm

giữ các thông tin c ần thiết bởi m ọi quy trình con trong Qu ản lý
Nhà cung cấp – ví dụ, dữ liệu được giám sát và thu th ập như
m ột phần của Quản lý Nhà cung c ấp. Sau đó thông tin này
luôn luôn được sử dụng như là đ ầu vào của m ọi phần khác
của quy trình Qu ản lý Nhà cung c ấp.
 Thông tin và các báo cáo v ề hiệu su ất của nhà cung c ấp và
hợp đồng: được sử dụng như là đ ầu vào đối với các cu ộc họp
đánh giá nhà cung c ấp và hợp đồng để quản lý chất lượng của
dịch vụ được cung cấp bởi nhà cung c ấp và các đ ối tác. Thông
tin này nên bao g ồm thông tin về rủi ro được chia s ẻ, nếu
thích hợp.
 Các biên b ản của cuộc họp đánh giá nhà cung c ấp và hợp
đồng: được đưa ra để ghi lại các biên bản và hoạt động của
m ọi cuộc họp đánh giá với các nhà cung c ấp.
 Các Kế ho ạch Cải thiện Dịch vụ của Nhà cung c ấp (SIP):
được sử dụng để ghi lại m ọi hoạt động và kế hoạch cải tiến đã
được thống nhất giữa các nhà cung c ấp dịch vụ và nhà cung

289
cấp của họ, khi cần đến các nhà cung c ấp, và nên được sử
dụng để quản lý tiến trình c ủa các hoạt động cải tiến đã thống
nhất, bao gồm các biện pháp giảm thiểu rủi ro.
 Các báo cáo kh ảo sát nhà cung cấp: thường thì có r ất nhiều
người trong tổ chức cung cấp dịch vụ phải thỏa thuận với các
nhà cung c ấp. Phản hồi từ các cá nhân này nên đư ợc đối
chiếu để đảm bảo tính nhất quán trong ch ất lượng của dịch vụ
được cung c ấp bởi nhà cung cấp được cung c ấp trong m ọi lĩnh
vực. Những phản hồi này có thể được công bố như bảng xếp
hạng để khuyến khích s ự cạnh tranh gi ữa các nhà cung c ấp.
4.7.7 Các Chỉ số Hiệu suất Chính yếu (KPI)

Rất nhiều KPI và chỉ số có thể được sử dụng để đánh giá tính hiệu
quả và hiệu suất của quy trình và các ho ạt động Quản lý Nhà cung
cấp. Những chỉ số này cần được phát triển từ quan điểm dịch vụ,
khách hàng và doanh nghi ệp, chẳng hạn như:
 Doanh nghi ệp được bảo vệ khỏi hiệu suất kém của nhà cung
cấp hoặc sự gián đoạn:
o Gia tăng s ố lượng các nhà cung c ấp đáp ứng được các
đích nhắm m ục tiêu trong hợp đồng.
o Giảm thiểu số lượng các vi phạm các đích nh ắm m ục
tiêu c ủa hợp đồng.
 Các dịch vụ hỗ trợ và các đích nh ắm m ục tiêu c ủa chúng liên
kết với các nhu c ầu và đích nhắm m ục tiêu c ủa doanh nghi ệp:
o Gia tăng s ố lượng các xem xét hợp đồng và dịch vụ
được nắm giữ bởi các nhà cung c ấp.
o Gia tăng s ố lượng các nhà cung c ấp và đích nh ắm m ục
tiêu hợp đồng được liên k ết với các đích nh ắm mục tiêu
của SLA và SLR.
 Tính sẵn sàng của các dịch vụ không bị xâm phạm bởi hiệu
suất của nhà cung c ấp:
o Sự giảm thiểu trong số lượng của các vi ph ạm dịch vụ
gây ra bởi nhà cung cấp.
o Sự giảm thiều trong số lượng của nguy cơ vi ph ạm dịch
vụ gây ra bởi nhà cung c ấp.
 Chủ sở hữu và nhận thức rõ ràng về nhà cung cấp và các vấn
đề về hợp đồng:
o Gia tăng số lượng các nhà cung c ấp cùng với các nhà
quản lý nhà cung c ấp được chỉ định.
o Gia tăng s ố lượng các hợp đồng cùng với các nhà quản
lý hợp đồng được chỉ định.
4.7.8 Quản lý Thông tin

Mọi thông tin được yêu cầu bởi Quản lý Nhà cung c ấp nên được
đóng gói trong SCD. Vi ệc này nên bao gồm m ọi thông tin liên quan
đến các nhà cung cấp và hợp đồng, cũng như m ọi thông tin liên
quan tới sự vận hành c ủa các dịch vụ hỗ trợ được cung c ấp bởi các
nhà cung cấp. Thông tin liên quan đ ến những dịch vụ hỗ trợ đó cũng
nên được đóng gói trong Danh m ục Dịch vụ, cùng với các m ối quan
hệ đối với m ọi dịch vụ và thành ph ần khác. Thông tin này nên đư ợc

290
tích hợp và duy trì trong s ự liên kết với m ọi hệ thống quản lý thông
tin CNTT khác, đ ặc biệt là Danh m ục Dịch vụ và CMS.
4.7.9 Những thách thức, các Yếu tố Thành công Quan trọng và
rủi ro
Quản lý Nhà cung c ấp đang đối diện với rất nhiều thách thức, vốn có
thể bao gồm m ột số trong những điều dưới đây:
 Thay đổi liên tục trong nhu cầu của doanh nghi ệp và CNTT và
việc quản lý các thay đ ổi đáng k ể song song với việc cung cấp
dịch vụ đang hiện hữu.
 Làm việc với m ột hợp đồng không lý tưởng bị áp đặt, m ột hợp
đồng có các đích nhắm m ục tiêu hoặc điều khoản và đi ều kiện
kém , hoặc định nghĩa kém hoặc không t ồn tại về các đích
nhắm m ục tiêu về hiệu suất của nhà cung cấp hoặc dịch vụ.
 Các vấn đề kế thừa, đặc biệt là với các dịch vụ được thuê
ngoài gần đây.
 Không đủ chuyên môn đư ợc giữ lại trong tổ chức.
 Bị ràng buộc vào các hợp đồng dài hạn, không có kh ả năng cải
thiện, có phí trừng phạt nếu chấm dứt (hợp đồng) sớm .
 Các tình hu ống m à trong đó nhà cung c ấp phụ thuộc vào t ổ
chức trong vi ệc thực hiện việc cung cấp dịch vụ (ví dụ: đối với
nguồn cấp dữ liệu) có thể dẫn đến các vấn đề về trách nhiệm
giải trình đối với hiệu suất dịch vụ kém .
 Các tranh ch ấp về phí.
 Bị can thiệp bởi một trong hai bên trong vi ệc điều hành ho ạt
động của bên kia.
 Bị kẹt trong chế độ chữa cháy hàng ngày, đánh m ất phương
pháp tiếp cận chủ động.
 Giao tiếp - không tương tác đ ủ thường xuyên ho ặc đủ nhanh
chóng hoặc tập trung vào đúng vấn đề.
 Các xung đ ột về tính cách.
 Một bên sử dụng hợp đồng gây bất lợi cho bên kia, d ẫn đến
những thay đ ổi được-m ất hơn là nh ững thay đổi cùng có lợi
 Đánh m ất quan điểm chiến lược, tập trung vào các vấn đề vậ n
hành, gây ra s ự thiếu tập trung vào các m ục tiêu và vấn đề
quan hệ chiến lược.
Các yếu tố chính có thể giúp tránh được các vấn đề nêu trên là:
 Hợp đồng được viết rõ ràng, xác định rõ và được quản lý t ốt

 Mối quan hệ cùng có lợi.
 Những vai trò và trách nhi ệm của cả hai bên được xác định
m ột cách rõ ràng (và đư ợc trao đổi).
 Tương tác và thông tin liên l ạc tốt giữa các bên.
 Các quy trình Quản lý Dịch vụ được xác định rõ ràng ở cả hai
bên
 Lựa chọn các nhà cung c ấp đã đạt được chứng nhận so với
các chứng nhận được quốc tế công nhận, chẳng hạn như ISO
9001, ISO/IEC 20000, v.v…

291
Các CSF chính cho quy trình Qu ản lý Nhà cung c ấp là:
 Doanh nghiệp được bảo vệ khỏi hiệu suất kém hoặc sự gián
đoạn của nhà cung cấp.
 Các dịch vụ hỗ trợ và các đích nhắm m ục tiêu của chúng phù
hợp với nhu cầu và m ục tiêu c ủa doanh nghiệp.
 Tính sẵn sàng c ủa các dịch vụ không bị ảnh hưởng bởi hiệu
suất của nhà cun g cấp.
 Quyền sở hữu và nhận thức rõ ràng về các vấn đề đối với nhà
cung cấp và hợp đồng.
Các lĩnh vực rủi ro chính liên quan đ ến Quản lý Nhà cung c ấp bao
gồm :
 Thiếu cam kết của doanh nghi ệp và quản lý cấp cao đối với
quy trình và các th ủ tục Quản lý Nhà cu ng cấp.
 Thiếu thông tin thích h ợp về các chính sách, k ế hoạch và
chiến lược của doanh nghiệp và CNTT trong tương lai.
 Thiếu tài nguyên và/ho ặc ngân sách cho quy trình ISM.
 Kế thừa các hợp đồng được viết và thỏa thuận kém không làm
nền tảng hoặc hỗ trợ cho các nhu cầu của doanh nghi ệp hoặc
các đích nhắm m ục tiêu SLA và SLR.
 Các nhà cung c ấp thỏa thuận với các đích nh ắm m ục tiêu và
m ức dịch vụ không thể đạt được, hoặc các nhà cung c ấp thất
bại hoặc không có kh ả năng đáp ứng các điều khoản và đi ều
kiện của hợp đồng.
 Nhân sự của nhà cung cấp hoặc văn hóa của tổ chức không
liên kết với nhân viên hoặc văn hóa của nhà cung c ấp dịch vụ
hoặc doanh nghiệp.
 Các nhà cung c ấp không phối hợp và không s ẵn lòng tham gia
vào và hỗ trợ cho quy trình Quản lý Nhà cung c ấp cần thiết.
 Các nhà cung cấp được tiếp quản và các m ối quan hệ, nhân
sự và hợp đồng được thay đổi.
 Những nhu c ầu về lập thành nhà cung c ấp và các th ủ tục hợp
đồng là quá m ức và quan liêu.
 Các quy trình tài chính doanh nghi ệp kém , chẳng hạn như thu
m ua và m ua s ắm , không hỗ trợ tốt cho (quy trình) Qu ản lý Nhà
cung cấp.
5 Các hoạt động liên quan đ ến công nghệ trong Thiết kế Dịch
vụ
Chương này xem xét các ho ạt động liên quan đ ến công nghệ về yêu
cầu kỹ thuật và phát triển các kiến trúc công ngh ệ. Các kiến trúc
công nghệ bao hàm các khía c ạnh về Thiết kế Dịch vụ trong nh ững
lĩnh vực sau:
 Quản lý Cơ sở hạ tầng.
 Quản lý Môi trường.
 Quản lý Dữ liệu và Thông tin.
 Quản lý Ứng dụng.

292
5.1 Kỹ thuật yêu cầu
Kỹ thuật yêu c ầu là phương pháp ti ếp cận m à theo đó, sự nghiêm
ngặt đầy đủ được đưa vào trong quy trình tìm hi ểu và ghi nhận lại
các yêu cầu của doanh nghi ệp và của người sử dụng, và đảm bảo
tính có thể truy nguyên c ủa những thay đ ổi đối với từng yêu c ầu.
Quy trình này bao g ồm các giai đo ạn khám phá, phân tích (v ốn phản
hồi lại trong phám phá), và xác m inh. T ất cả những việc này góp
phần đưa ra m ột tài liệu về yêu cầu nghiêm ngặt và đầy đủ. Cốt lõi
của tài liệu này là m ột kho lưu trữ về các yêu cầu riêng lẻ được phát
triển và quản lý. Thường thì các yêu c ầu này được thúc đ ẩy bởi
CNTT nhưng cu ối cùng, chúng c ần phải được lập thành văn bản và
thống nhất với doanh nghi ệp.
Có rất nhiều hướng dẫn về kỹ thuật yêu cầu, bao gồm Thực tiễn
được Khuyến cáo đối với các Đặc tả kỹ thuật Yêu cầu Phần m ềm –
Recomm ended Practice for Software Requi rem ents Specifications
(IEEE830), Cơ s ở Kiến thức Kỹ thuật Phần m ềm – Software
Engineering Body of Knowledge (SW EBOK), CMMI và V -Model, được
m ô tả chi tiết trong ấn phẩm Chuyển tiếp Dịch vụ.
5.1.1 Các ki ểu yêu cầu khác nhau

Có m ột giả định cơ bản ở đây là việc phân tích các quy trình nghi ệp
vụ hiện tại và bắt buộc dẫn đến các yêu cầu chức năng được đáp
ứng thông qua các dịch vụ CNTT (bao gồm các ứng dụng, dữ liệu,
cơ sở hạ tầng, m ôi trường và các k ỹ năng hỗ trợ).
Điều quan tr ọng cần lưu ý là có ba lo ại yêu cầu phổ biến đối với bất
kỳ hệ thống nào - yêu cầu về chức năng, yêu cầu về quản lý và vận
hành và yêu c ầu về khả năng sử dụng.
 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ề quản lý và vận hành (đôi khi đư ợc gọi là các
yêu cầu phi ch ức năng) xác đ ịnh nhu cầu về m ột dịch vụ đáp
ứng, có s ẵn và bảo m ật, đồng thời xử lý các vấn đề như tính
dễ triển khai, kh ả năng vận hành, nhu cầu quản lý và b ảo m ật.
 Các yêu cầu về khả năng sử dụng là những yêu cầu xác đ ịnh
nhu cầu "nhìn và c ảm nhận" của người dùng và dẫn đến các
tính năng c ủa dịch vụ tạo điều kiện cho việc sử dụng dễ dàng.
Loại yêu cầu này thường được coi là m ột phần của các yêu
cầu quản lý và vận hành, nhưng đ ối với các m ục đích của
phần này, nó s ẽ được giải quyết m ột cách riêng bi ệt.
5.1.1.1 Các yêu c ầu chức năng

Các yêu c ầu về chức năng m ô tả những thứ m à m ột dịch vụ được dự
định thực hiện và có thể được thể hiện dưới dạng các tác vụ hoặc
chức năng m à thành ph ần được yêu c ầu hoàn thành. Một phương
pháp tiếp cận để xác định các yêu cầu chức năng là thông qua các
phương pháp như sơ đ ồ ngữ cảnh hệ thống hoặc m ô hình Use case.
Các phương pháp ti ếp cận khác cho thấy cách thức các đầu vào

293
được chuyển thành đầu ra (luồng dữ liệu hoặc sơ đồ đối tượng) và
m ô tả dạng văn b ản như thế nào.
Ví dụ, m ột sơ đồ ngữ cảnh hệ thống nắm bắt tất cả các trao đ ổi

thông tin giữa m ột m ặt là dịch vụ CNTT và m ôi trường của nó, m ặt
khác là các ngu ồn hoặc đích đến của dữ liệu được sử dụng bởi dịch
vụ. Những trao đổi thông tin và nguồn dữ liệu này thể hiện những
ràng buộc đối với dịch vụ đang được phát triển.
Mô hình Use case xác đ ịnh m ột tập hợp các tương tác theo đ ịnh
hướng m ục tiêu gi ữa các tác nhân bên ngoài và d ịch vụ đang được
xem xét. Các tác nhân là các bên n ằm bên ngoài dịch vụ có tương
tác với dịch vụ. Tác nhân có thể phản ánh m ột lớp các vai trò c ủa
người sử dụng có thể đảm nhận, hoặc các dịch vụ khác và yêu c ầu
của chúng. Mục đích chính của m ô hình Use case là thi ết lập ranh
giới của hệ thống được đề xuất và nêu ra đ ầy đủ những năng l ực
chức năng s ẽ được cung c ấp cho ngư ời dùng. Các Use case cũng
rất hữu ích cho vi ệc thiết lập giao tiếp giữa doanh nghi ệp và nhà
phát triển ứng dụng. Chúng cung c ấp cơ sở để định cỡ và cung c ấp
định nghĩa về các yêu c ầu về khả năng sử dụng. Các Use case xác
định tất cả các tình hu ống m à m ột ứng dụng phải hỗ trợ và do đó có
thể dễ dàng m ở rộng thành các trường hợp kiểm nghiệm . Vì các Us e
case m ô tả chức năng c ủa dịch vụ ở cấp độ dễ hiểu đối với cả
doanh nghiệp lẫn CNTT, chúng có thể đóng vai trò như m ột phương
tiện để chỉ định các yếu tố chức năng của SLA, chẳng hạn như các
sản phầm có thể chuyển giao thực tế từ dịch vụ.
‘Dưới’ m ột m ức so với Use case và sơ đ ồ ngữ cảnh, rất nhiều k ỹ

thuật m ô hình hóa khác có th ể được áp dụng. Các m ô hình này m ô
tả các đặc điểm tĩnh và đ ộng của các dịch vụ đang được phát tri ển.
Một m ô hình dữ liệu khái niệm (cho dù được gọi là đối tượng hay dữ
liệu) m ô tả ‘các đối tượng’ khác nhau trong d ịch vụ, các m ối quan h ệ
lẫn nhau và cấu trúc bên trong c ủa chúng. Nh ững động lực của dịch
vụ có thể được m ô tả bằng cách s ử dụng các m ô hình tr ạng thái (ví
dụ: các biểu đồ chuyển đổi trạng thái) hi ển thị các trạng thái khác
nhau của các thực thể hoặc đối tượng, cùng với các s ự kiện có thể
gây ra sự thay đổi trạng thái. Các tương tác giữa các thành phần
ứng dụng khác nhau có th ể được m ô tả bằng sơ đồ tương tác (ví d ụ:
sơ đồ tương tác đ ối tượng). Cùng với quy trình m ô hình hóa các yêu
cầu trưởng thành, các công c ụ CASE có thể giúp có được và gi ữ cho
các m ô hình này nh ất quán, chính xác và hoàn ch ỉnh.
5.1.1.2 Các yêu c ầu về quản lý và vận hành

Các yêu c ầu về quản lý và vận hành (hay còn g ọi là các yêu c ầu phi
chức năng) được sử dụng để xác định các yêu c ầu và ràng bu ộc đối
với dịch vụ CNTT. Các yêu c ầu đóng vai trò như là cơ s ở cho định
cỡ ban đầu các hệ thống và dịch vụ và ước lượng chi phí, và có th ể
hỗ trợ cho việc đánh giá kh ả năng tồn t ại của dịch vụ CNTT được đề
xuất. Các yêu c ầu về quản lý và vận hành cũng nên khuy ến khíc h
các nhà phát tri ển có m ột cái nhìn rộng hơn về các m ục tiêu c ủa dự
án.

294
Các loại yêu cầu về quản lý và vận hành bao g ồm :
 Tính có thể quản lý được: Nó có ho ạt động không? Nó có b ị

lỗi không? Nó b ị lỗi như thế nào?
 Tính hiệu quả: Nó tiêu tốn hết bao nhiêu tài nguyên?
 Tính sẵn sàng và đ ộ tin cậy: Nó c ần phải đáng tin cậy đế n
m ức nào?
 Công suất và hiệu suất: Chúng ta c ần m ức công suất nào?
 Bảo mật: Mức phân loại bảo m ật nào được yêu cầu?
 Cài đ ặt: Cần phải bỏ ra bao nhiêu n ỗ lực để cài đặt ứng dụng?
Nó có đang s ử dụng các thủ tục cài đặt được tự động hóa
không?
 Tính liên tục: Mức độ khôi phục và khả năng phục hồi nào là
cần thiết?
 Tính có th ể kiểm soát được: Nó có th ể được giám sát, quản
lý và điều chỉnh không?
 Tính có th ể bảo trì được: Ứng dụng có thể được điều chỉnh,
khắc phục, bảo trì và thay đổi tốt đến m ức nào cho những yêu
cầu trong tương lai?
 Khả năng hoạt động: Các ứng dụng có làm phi ền các ứng
dụng khác trong các ch ức năng c ủa chúng không?
 Tính có th ể đo lư ờng và báo cáo đư ợc: Chúng ta có thể đo
lường và báo cáo v ề m ọi khía c ạnh cần thiết của ứng dụng
không?
Các yêu c ầu về quản lý và vận hành có thể được sử dụng để chỉ

định các thu ộc tính chất lượng của ứng dụng đang đư ợc xây dựng.
Những thuộc tính chất lượng này có thể được sử dụng để thiết kế
các kể hoạch kiểm tra để kiểm nghiệm các ứng dụng về tính tuân thủ
với các yêu cầu về quản lý và vận hành.
5.1.1.3 Các yêu c ầu về khả năng sử dụng

Mục đích chủ yếu của các yêu c ầu về khả năng sử dụng là để đảm
bảo rằng dịch vụ đáp ứng được các k ỳ vọng của người sử dụng nó
liên quan đến m ức độ dễ dàng khi sử dụng. Để đạt được điều này:
 Hãy thiết lập các tiêu chu ẩn hiệu suất cho các đánh giá v ề
khả năng s ử dụng.
 Hãy xác đ ịnh các kịch bản kiểm nghiệm cho các k ế hoạch
kiểm tra khả năng sử dụng và kiểm nghiệm khả năng sử dụng.
Giống như các yêu c ầu về quản lý và v ận hành, các yêu c ầu về khả

năng sử dụng cũng có th ể được sử dụng như là các thuộc tính chất
lượng của việc thiết kế các kế hoạch kiểm tra để kiểm nghiệm các
ứng dụng về khả năng tuân thủ của chúng đối với các yêu c ầu về
khả năng sử dụng.
5.1.2 Các yêu cầu đối với sự hỗ trợ - quan điểm người sử dụng
Người sử dụng có các vai trò và ho ạt động được xác định m ột cách
chính thức với tư cách là đại diện cho người sử dụng trong định
nghĩa các yêu c ầu và kiểm nghiệm sự chấp thuận. Họ nên được

295
tham gia m ột cách tích c ực vào việc xác định m ọi khía cạnh của các
yêu cầu dịch vụ, bao gồm ba loại (yêu cầu) nói trên, và:
 Các thủ tục và cơ s ở đào t ạo người dùng.

 Các hoạt động hỗ trợ và các thủ tục Bộ phận Hỗ trợ Dịch vụ.
5.1.3 Các k ỹ thu ật tìm hiểu các yêu c ầu

Có m ột loạt các k ỹ thuật có thể được sử dụng để tìm hiểu về các
tình huống của doanh nghi ệp và khám phá ra các yêu c ầu về dịch
vụ. Thỉnh thoảng, khách hàng và doanh nghi ệp không hoàn toàn
chắc chắn về việc những yêu cầu của m ình thực sự là gì và sẽ cần
đến sự trợ giúp và khuyên b ảo từ các nhà thiết kế hoặc người thu
thập yêu c ầu. Điều này nên được hoàn thành theo m ột cách cẩn
trọng để đảm bảo rằng nó không b ị coi là CNTT b ắt buộc các yêu
cầu doanh nghiệp thêm m ột lần nữa. Hai k ỹ thuật được sử dụng phổ
biến nhất là phỏng vấn và hội thảo, tuy nhiên chúng cũng được bổ
sung bằng các k ỹ thuật khác, chằng hạn như quan sát và các k ịch
bản.
5.1.3.1 Phỏng vấn

Phỏng vấn là m ột công c ụ chủ yếu và có thể m ang tính quyết định
trong việc đạt được m ột số m ục tiêu, chẳng hạn như:
 Liên hệ ban đầu với các bên liên quan ch ủ chốt và thiết lập
m ột cơ sở cho tiến trình.
 Xây dựng và phát triển m ối quan hệ với những người sử dụng
và các nhà qu ản lý khác nhau.
 Có được thông tin về tình huống của doanh nghi ệp, bao gồm
các sự cố và vấn đề.
Có ba lĩnh vực được xem xét trong các cu ộc phỏng vấn:
 Các quy trình hiện tại của doanh nghiệp cần được hoàn thành
trong bất kỳ hệ thống và dịch vụ nghiệp vụ nào.
 Các vấn đề với sự vận hành hiện t ại cần được giải quyết.
 Các chức năng m ới cần thiết từ hệ thống hoặc dịch vụ nghiệp
vụ và bất kỳ dịch vụ CNTT hỗ trợ nào.
Quy trình phỏng vấn được cải thiện khi ngư ời tiến hành phỏng vấn
đã chuẩn bị m ột cách k ỹ lưỡng vì điều này giúp ti ết kiệm thời gian
bằng cách tránh nh ững giải thích không c ần thiết và m inh chứng cho
sự quan tâm và chuyên nghi ệp. Cấu trúc câu hỏi cổ điển về ‘Tại sao,
Cái gì, Ai, Khi nào, Ở đâu và Như th ế nào’ cung c ấp m ột khuôn kh ổ
tuyệt vời để chuẩn bị cho các cuộc phỏng vấn.
Một điều quan tr ọng không kém là chính th ức kết thúc cuộc phỏng
vấn bằng cách:
 Tổng hợp các đi ểm đã được bao hàm và các ho ạt động được

thống nhất.
 Giải thích về những bước tiếp theo, c ả sau cuộc phỏng vấn và
hơn thế nữa.

296
 Hỏi người được phỏng vấn về cách thức liên hệ thêm .
Luôn là m ột ý kiến hay khi vi ết lại các ghi chú c ủa cuộc phỏng vấn
càng sớm càng tốt – lý tưởng là ngay l ập tức và thường là ngày hôm
sau.
Những ưu điểm của việc phỏng vấn là:
 Xây dựng được m ối quan hệ với người sử dụng.

 Có thể m ang lại thông tin quan tr ọng.
 Cơ hội để tìm hiểu và các quan đi ểm thái độ khác nhau trong
nhóm người sử dụng..
 Cơ hội để tìm hiều về các lĩnh vực m ới phát sinh.
 Thu thập các ví dụ về các tài li ệu và báo cáo.
 Nghiên cứu về m ôi trường m à trong đó dịch vụ m ới sẽ vận
hành.
Khuyết điểm của phỏng vấn là:
 Tốn kém do thời gian trôi qua.

 Không có cơ hội giải quyết xung đột.
5.1.3.2 Các cuộc hội thảo

Các cuộc hội thảo cung c ấp m ột diễn đàn m à trong đó các v ấn đề có
thể được thảo luận, các xung đột được giải quyết và các yêu c ầu
được khám phá. Các h ội thảo đặc biệt có giá trị khi thời gian và
ngân sách bị ràng bu ộc m ột cách chặt chẽ, m ột số quan đi ểm cần
được thảo luận và m ột quan điểm lặp đi lặp lại và tăng d ần về phát
triển dịch vụ đang được đưa ra.
Những ưu điểm của hội thảo là:
 Có được cái nhìn bao quát v ề lĩnh vực đang được tìm hiểu –
việc có được m ột nhóm các bên liên quan trong m ột phòng s ẽ
cho phép tìm hiểu đầy đủ hơn về các sự cố và vấn đề
 Tăng t ốc độ và năng suất - sẽ nhanh hơn nhi ều khi có m ột
cuộc họp với m ột nhóm người so với phỏng vấn từng người
m ột.
 Có được sự tín nhiệm và chấp nhận đối với dịch vụ CNTT
 Đạt được m ột quan điểm đồng thuận - nếu tất cả các bên liên
quan đều tham gia, cơ h ội để họ nắm quyền sở hữu kết quả sẽ
được cải thiện.
Có m ột số khuyết điểm , bao gồm :
 Có thể tốn thời gian để tổ chức - ví dụ, không phải lúc nào
cũng dễ dàng tập hợp tất cả những người cần thiết cùng m ột
lúc.
 Có thể khó để có được tất cả những người tham gia với m ức
độ quyền hạn cần thiết.
 Có thể khó để có được sự kết hợp giữa những nhân s ự kinh
doanh và vận hành để hiểu được những yêu cầu khác nhau.

297
Sự thành công hay thất bại của m ột buổi hội thảo phần lớn phụ
thuộc vào công tác chu ẩn bị của người điều hành và nhà b ảo trợ
doanh nghi ệp cho h ội thảo. Họ nên dành th ời gian trước sự kiện để
hoạch định các lĩnh v ực sau:
 Mục tiêu của buổi hội thảo – phải có m ột m ục tiêu có th ể đạt

được trong ph ạm vi ràng bu ộc thời gian của buổi hội thảo.
 Ai sẽ được m ời tham gia vào bu ổi hội thảo – điều quan tr ọng
là m ọi bên liên quan quan tâm đ ến m ục tiêu nên đư ợc m ời
tham dự hoặc được đại diện.
 Cấu trúc c ủa buổi hội thảo và các k ỹ thuật được sử dụng.
Những điều này c ần được hướng tới việc đạt được m ục tiêu
đã được xác định, ví dụ, thu thập các yêu c ầu hoặc thiết lập
độ ưu tiên, và nên tính đ ến các nhu cầu của những người
tham gia.
 Sắp xếp m ột địa điểm thích hợp – địa điểm có thể nằm trong tổ
chức, nhưng t ốt hơn là sử dụng m ột địa điểm ‘trung lập’ nằm
ngoài văn phòng.
Trong suốt buổi hội thảo, người điều hành c ần phải đảm bảo rằng
các vấn đề được thảo luận, các quan điểm được đưa ra và tiến trình
được hướng đến việc đạt được m ục tiêu đã nêu. M ột bản ghi cầ n
được giữ lại về các điểm chủ yếu xuất hiện từ cuộc thảo luận. T ại
cuối buổi hội thảo, người điều hành c ần tóm tắt lại các điểm và các
hoạt động chính. M ỗi hoạt động nên được chỉ định cho m ột chủ sở
hữu.
Có hai thể loại kỹ thuật chính c ần thiết đối với m ột hội thảo về yêu
cầu – các kỹ thuật khám phá và các k ỹ thuật lập tài liệu, như được
Hình 5.1 – Các k ỹ thuật cho hội thảo về yêu cầu
5.1.3.3 Quan sát

Việc quan sát khu v ực làm việc là r ất hữu ích trong việc có được
những thông tin về m ôi trường doanh nghi ệp và thực tiễn công việc.
Điều này có hai ưu đi ểm như sau:

298
 Hiểu tốt hơn nữa về các vấn đề và những khó khăn m à ngư ời
dùng doanh nghi ệp đang phải đối m ặt.
 Nó sẽ giúp phát m inh ra các gi ải pháp có th ể hoạt động được
m à có nhiều khả năng sẽ được doanh nghi ệp chấp thuận.
Ngược lại, việc bị quan sát có th ể trở nên khá đáng sợ, và câu nói
cũ ‘bạn thay đổi khi bị quan sát’ c ần được đưa vào phương pháp
tiếp cận và phát hi ện của bạn.
Quan sát chính th ức liên quan đến việc xem xét m ột tác vụ cụ thể
đang được thực hiện. Có m ột nguy cơ về việc chỉ được hiển thị ‘câu
chuyện trước m ặt’ m à không có bất kỳ khác biệt hàng ngày nào, tuy
nhiên, nó vẫn là m ột công c ụ hữu ích.
5.1.3.4 Phân tích giao th ức

Phân tích giao th ức chỉ đơn giản là yêu cầu người sử dụng thực
hiện m ột tác vụ và để họ m ô tả m ỗi bước khi họ thực hiện nó.
5.1.3.5 Đổ bóng
Đổ bóng (shadowing) liên quan đ ến việc theo sau m ột người sử
dụng trong m ột khoảng thời gian, chẳng hạn như m ột ngày, để tìm
hiểu m ột công việc cụ thể. Đây là m ột cách hi ệu quả để hiểu về m ột
vai trò ngư ời sử dụng cụ thể. Hãy yêu cầu sự giải thích về các công
việc được thực hiện như thế nào, hoặc luồng công việc, làm rõ về
m ột số khía cạnh đã được giả định.
5.1.3.6 Phân tích tình hu ống

Phân tích Tình huống, về cơ bản là vi ệc kể lại câu chuyện về m ột
tác vụ hoặc giao dịch. Giá tr ị của nó nằm ở chỗ nó giúp cho m ột
người sử dụng đang m ơ hồ về những gì c ần thiết từ m ột dịch vụ m ới
để nhận ra điều đó m ột cách rõ ràng hơn. Các tình hu ống cũng rất
hữu ích khi phân tích ho ặc tái thiết kế các quy trình nghi ệp vụ. Một
tình huống sẽ theo dõi tiến trình của một giao dịch t ừ khi kích ho ạt
kinh doanh ban đ ầu đến m ỗi bước cần thiết để đạt được kết quả
thành công.
Các tình huống cung c ấp m ột khuôn kh ổ cho việc khám phá nh ững lộ
trình thay thế có thể được tuân theo đ ể hoàn thành giao dịch. Điều
này cực kỳ hữu ích trong vi ệc khám phá và phân tích các yêu c ầu
bởi vì đây là các tình hu ống-thực tế, bao gồm các trường hợp ngoại
lệ, được tranh luận.
Các tình huống cung cấp những ưu điểm đáng k ể sau:
 Chúng bắt buộc người sử dụng phải bao gồm m ọi bước, do đó,
không có yếu tố được sử dụng cho-m ọi-cấp và vấn đề về kiến
thức ngầm được xác định.
 Bằng cách giúp đỡ người sử dụng hình dung ra m ọi phương
án dự phòng, chúng giúp đ ối phó với những tình huống mơ hồ
về các hệ thống và dịch vụ tương lai.
 Một hội thảo nhóm tinh chỉnh m ột tình huống sẽ xác định
những lộ trình không phù hợp với văn hóa doanh nghi ệp.

299
 Chúng cung cấp một công c ụ để chuẩn bị các kịch bản kiểm
tra.
Khuyết điểm của các tình hu ống là chúng có thể tốn thời gian để
phát triển, và vài tình huống có thể trở nên rất phức tạp. Trong
trường hợp đó, s ẽ dễ dàng hơn đ ể phân tích n ếu như m ỗi lộ trình
trong các lộ trình thay thế chủ yếu được coi là m ột tình huống biệt
lập.
Một phương pháp ti ếp cận phổ biến là lập tài liệu m ô tả tình huống
để phát triển các mô t ả Use case đ ể hỗ trợ cho các sơ đồ use case.
Tuy nhiên, cũng có m ột số các phương pháp đ ồ họa về việc lập tài
liệu m ột tình huống, chẳng hạn như bảng phân c ảnh, các sơ đ ồ hoạt
động, các m ô hình tác v ụ và các sơ đ ồ của cây quyết định (decision
tree).
5.1.3.7 Tạo ngu yên mẫu

Tạo nguyên m ẫu là m ột kỹ thuật quan trọng đối với việc khám phá,
phân tích, ch ứng m inh và xác th ực các yêu c ầu. Sẽ rất khó cho
người sử dụng để hình dung về dịch vụ m ới trước khi nó thực sự
được xây dựng. Các nguyên m ẫu cung cấp m ột cách để cho người
sử dụng thấy được cách m à dịch vụ mới có thể hoạt động như thế
nào và cách th ức mà trong đó dịch vụ có thể được sử dụng. Nếu m ột
người sử dụng không rõ ràng v ề những gì họ cần dịch vụ phải làm
cho họ thì việc sử dụng m ột nguyên m ẫu thường giải phóng các khối
để tư duy và có th ể sản sinh ra m ột làn sóng yêu c ầu mới. Những
phương pháp ti ếp cận tăng dần và lặp đi lặp lại đối với phát triể n
dịch vụ như Phương pháp Phát tri ển các Hệ thống Động – Dynam ic
System s Development Method (DSDM), s ử dụng việc tạo nguyên
m ẫu tiến hóa như m ột phần không thể thiếu của vòng đời phát tri ển
của chúng.
Có nhiều phương pháp ti ếp cận để xây dựng các nguyên m ẫu.

Chúng có thể được xây dựng bằng cách sử dụng m ột môi trường
phát triển ứng dụng để từ đó chúng ph ản chiếu dịch vụ, những hình
ảnh của m àn hình và đi ều hướng có thể được xây dựng bằng cách
sử dụng phần m ềm trình chi ếu, hoặc chúng có th ể đơn giản là được
‘m ô phỏng’ trên gi ấy.
Có hai phương pháp t ạo nguyên m ẫu cơ bản:
 Mô phỏng bỏ-đi, vốn chỉ được sử dụng để chứng m inh gia o

diện.
 Sự triển khai tăng dần, khi các nguyên m ẫu được phát tri ển
thành hệ thống sau cùng.
Điều quan trọng là lựa chọn m ột cách có ý th ức những gì sẽ được

sử dụng, nếu không, sẽ có nguy cơ m ột m ô phỏng với chất lượng tồi
trở thành cơ s ở cho hệ thống thực, và sau đó gây ra v ấn đề.
Có m ột liên k ết m ạnh m ẽ giữa các tình huống và việc tạo nguyên

m ẫu bởi vì các tình hu ống có thể được sử dụng như cơ s ở cho việc

300
phát triển các nguyên m ẫu. Ngoài vi ệc xác nhận các yêu cầu của
người sử dụng, việc tạo nguyên m ẫu thường có thể giúp cho người
sử dụng xác định các yêu c ầu m ới.
Các nguyên m ẫu được sử dụng m ột cách thành công để:
 Làm rõ bất kỳ sự mơ hồ nào từ phía các nhà phát tri ển dịch vụ

và xác nhận với người sử dụng rằng những gì họ đã yêu cầu
đã được hiểu rõ.
 Mở ra cho người sử dụng những yêu c ầu m ới khi họ hiểu rõ về
những gì dịch vụ có khả năng hỗ trợ cho họ.
 Cho người sử dụng thấy ‘giao diện’ của dịch vụ được đề xuất
và khám phá các yêu c ầu về khả năng sử dụng.
 Xác m inh các yêu c ầu và xác định bất kỳ lỗi nào.
Các vấn đề tiềm ẩn bao gồm :
 Vòng lặp vô tận.

 Một quan đi ểm rằng nêu nguyên m ẫu hoạt động thì đầy đủ
dịch vụ có thể sẵn sàng vào hôm sau.
5.1.3.8 Các k ỹ thuật khác

Các kỹ thuật khác có th ể được sử dụng, bao gồm :
 Các câu hỏi: có thể hữu ích để có được m ột lượng thông tin
giới hạn từ rất nhiều người khi việc phỏng vấn tất cả họ sẽ
không thực t ế hoặc không hi ệu quả về chi phí.
 Các hồ sơ có mục đích đặc bi ệt: kỹ thuật liên quan đế n
người sử dụng trong vi ệc giữ m ột hồ sơ về m ột vấn đề hoặc
tác vụ cụ thể. Ví dụ, họ có thể giữ m ột bản ghi đơn gi ản 5-ô về
tần suất họ cần chuyển các cuộc gọi điện thoại – điều này có
thể cung cấp thông tin về các vấn đề với quy trình nghiệp vụ
này.
 Lấy mẫu chủ động: là m ột hình thức quan sát m ang tính đ ịnh
lượng hơn và có th ể được sử dụng khi c ần biết về việc m ọi
người sử dụng thời gian của họ như thế nào – ví dụ, bao nhiêu
thời gian đã tiêu t ốn cho việc lập hóa đơn? Bao nhiêu th ời
gian đã được tiêu tốn cho việc điều chỉnh các kho ản thanh
toán? Bao nhiêu th ời gian đã tiêu t ốn cho việc sắp xếp các
truy vấn?
5.1.4 Những vấn đề với kỹ thuật yêu cầu

Các yêu c ầu được người sử dụng coi là ph ần nhỏ không ph ức tạp
của việc phát triển m ột dịch vụ m ới, thực tế lại là khía c ạnh có nhi ều
vấn đề nhất, và tuy nhiên, đư ợc phân bổ thời gian ít hơn nhi ều so
với các giai đoạn khác.
Khoảng thời gian và ngân sách eo h ẹp – cả hai đều dẫn đến những
ràng buộc đối với doanh nghi ệp – gây áp lực lên nhóm phát tri ển để
cung cấp m ột dịch vụ. Rắc rối là nếu không có thời gian thích hợp
để tìm hiểu và xác định các yêu c ầu m ột cách đúng đắn, dịch vụ

301
được cung c ấp đúng hạn có thể không phải là dịch vụ m à doanh
nghiệp nghĩ rằng họ đang yêu c ầu.
Các nghiên cứu đã được tiến hành trong các d ự án CNTT thất bại
đều kể lại m ột câu chuyện phổ biến. Rất nhiều dự án và dịch vụ
CNTT không đạt yêu cầu đưa ra các k ết luận sau:
 Một tỷ lệ lớn các lỗi (trên 80%) được phát hi ện ra ở giai đoạ n
yêu cầu.
 Rất ít lỗi (ít hơn 10%) xu ất hiện khi thiết kế và phát tri ển - các
nhà phát tri ển đang phát triển những điều đúng đắn, nhưng
thường thì lại không phát triển những điều đúng đắn
 Phần lớn thời gian của dự án được phân bổ cho các giai đo ạn
phát triển và thử nghiệm của dự án
 Ít hơn 12% thời gian của dự án được phân bổ cho các yêu
cầu.
Những phát hiện này đặc biệt có ý nghĩa vì chi phí s ửa lỗi trong các
yêu cầu sẽ tăng lên đáng k ể khi chúng (các l ỗi) được phát hi ện càng
m uộn trong vòng đời phát triển.
Một trong những vấn đề chính đối với kỹ thuật yêu cầu là thi ếu kỹ
năng chi ti ết hóa và hiểu biết tổng thể về lĩnh vực khi m ọi người sử
dụng nó. Nếu được thực hiện m ột cách chính xác, công vi ệc có thể
tích hợp các yêu c ầu từ nhiều lĩnh vực chỉ trong m ột vài câu h ỏi.
Các vấn đề điển hình khác đ ối với các yêu c ầu đã được xác định là:
 Thiếu sự liên quan với các m ục tiêu c ủa dịch vụ.

 Từ ngữ thiếu rõ ràng.
 Sự m ơ hồ.
 Sự trùng lặp giữa các yêu cầu.
 Xung đột giữa các yêu c ầu.
 Các yêu cầu được thể hiện theo cách m à r ất khó để đánh giá
liệu chúng có đạt được hay không.
 Các yêu cầu giả định m ột giải pháp thay vì nêu rõ nh ững gì sẽ
được cung c ấp bởi dịch vụ.
 Người dùng không ch ắc chắn về những gì họ cần từ dịch vụ
mới.
 Người dùng bỏ qua việc xác định các yêu c ầu.
 Mức độ chi tiết không nhất quán.
 Một giả định rằng người dùng và nhân viên CNTT có ki ến thức
m à họ không có và do đó không đ ảm bảo rằng có sự hiểu biết
chung.
 Yêu cầu leo thang - việc bổ sung dần dần các yêu cầu trông
có vẻ nhỏ m à không tính đ ến nỗ lực bổ sung trong kế hoạch
dự án.
Một vấn đề khác là người dùng rõ ràng là không có kh ả năng trình

bày m ột cách rõ ràng v ề những gì họ m uốn dịch vụ làm cho h ọ. H ọ
rất thường bị ngăn cản làm như vậy vì bản chất của yêu c ầu là được
giải thích trong m ột tuyên bố đơn giản.

302
5.1.4.1 Giải quyết các vấn đề với k ỹ thuật yêu cầu
Xác định các tác nhân
Có m ột số bên liên quan ph ải tham gia vào quy trình yêu c ầu. Họ thể
hiện cho ba nhóm bên có liê n quan r ộng:
 Doanh nghiệp.
 Cộng đồng người sử dụng.
 Nhóm phát triển dịch vụ.
Cộng đồng người sử dụng nên đư ợc đại diện bởi chuyên gia v ề lĩnh
vực (hoặc chuyên gia về chủ đề) và ngư ời dùng cuối.
Thỏa thuận với kiến thức ngầm

Khi phát triển m ột dịch vụ m ới, người sử dụng sẽ chuyển cho chúng
ta những kiến thức rõ ràng c ủa họ, tức là những kiến thức về các
thủ tục và dữ liệu nằm phía trước tâm trí của họ và họ có thể phát
biểu m ột cách dễ dàng. Một vấn đề chủ yếu khi khám phá các yêu
cầu là về những kiến thức ngầm , nghĩa là nh ững khía cạnh khác của
công việc m à m ột người sử dụng không th ể phát biểu hoặc giải
thích.
Một số thành phần phổ biến gây ra vấn đề và sự hiểu nhầm là:
 Kỹ năng - việc giải thích về cách tiến hành các hành đ ộng như
thế nào bằng cách sử dụng các từ ngữ đơn lẻ là cực kỳ khó
khăn.
 Thông tin cho-m ọi-cấp độ - ngay c ả những người sử dụng là
chuyên gia và đầy kinh nghi ệm cũng có thể thất bại khi đề cập
tới thông tin hoặc làm rõ thu ật ngữ, và chuyên viên phân tích
cũng có thể không nhận ra rằng việc thêm các câu h ỏi là cần
thiết.
 Front -story/back-story – vấn đề này đề cập tới khuynh hư ớng
đóng khung m ột m ô tả của thực tiễn công việc hiện t ại, hoặc
m ột khu vực công việc, nhằm đưa ra m ột quan điểm tích cực
hơn tình huống thực tế.
 Kiến thức về các hệ thống tương lai – nếu nghiên cứu là để
phát triển m ột dịch vụ m ới m à không có chuyên gia ho ặc kiến
thức (về dịch vụ mới đó) hiện hữu trong tổ chức, làm thế nào
để người sử dụng tiềm năng có thể biết được họ m uốn gì?
 Sự khó khăn của m ột người ngoài cuộc khi giả định về m ột
ngôn ngữ chung cho vi ệc diễn ngôn và các chuẩn m ực chung
trong giao ti ếp. (Nếu họ không có đi ều này thì phạm vi trình
bày sai lệch về tình huống có thể tăng lên m ột cách đáng k ể).
 Hiểu biết trực quan, thường sinh ra t ừ những trải nghiệm đáng
kể. Người đưa ra quyết định thường được cho là tuân theo
m ột lộ trình tìm hiểu hợp lý và tuyến tính khi đưa ra các quy ết
định của họ. Tuy nhiên, trong th ực tế, khi m à các ki ến thức và
kỹ năng ra quyết định được cải thiện, lộ trình tuyến tính
thường bị bỏ qua để chuyển sang nhận dạng hình m ẫu trực
quan.

303
 Văn hóa t ổ chức – không có sự thấu hiểu về văn hóa c ủa m ột
tổ chức, việc thực hiện các yêu cầu có thể bị khiếm khuyết.
Back-story là từ dùng để mô tả những sự việc xảy ra trước đó, tức những sự việc đã xảy ra
trước khi những việc hiện tại xảy ra.
Cộng đồng thực tiễn là những nhóm người lao động rời rạc – có thể
có liên quan do nhi ệm vụ, bởi phòng ban, do khu v ực địa lý ho ặc
m ột vài yếu tố khác – có các bộ chuẩn m ực và thực tiễn của riêng
mình, khác bi ệt với các nhóm khác trong t ổ chức và toàn b ộ tổ chức.
Ngầ m T ường mi nh
Cá nh ân Các k ỹ n ă ng , g i á tr ị , c ho- m ọ i- Các t ác vụ , m ô t ả c ôn g v iệc ,
c ấp , tr ự c q u an . đíc h nh ắm m ục ti ê u, k h ố i lư ợ n g
v à tầ n s u ất .
T ập đo àn Các c hu ẩ n m ự c , ba c k - s tor y, Các th ủ t ục , p ho n g c á c h hư ớ n g
v ăn hó a, c ộn g đ ồn g t h ự c t i ễn . dẫ n , q u y trì n h, c h i a s ẻ k iến
thứ c .
Bảng 5.1 Kỹ thuật yêu cầu – Những kiến thức ngầm và kiến thức
tường minh
Ví dụ về các cấp độ kiến thức ngầm và kiến thức tường m inh
K ỹ t h u ật Ki ến t h ứ c Ki ến th ứ c K ỹ n ăng Cá c yê u c ầu
t ườ ng min h ngầ m tươ ng la i
Phỏ ng v ấn   x 
Bóng đ ổ    x
Hội th ảo   x 
T ạo ngu yê n    
mẫu
Ph ân tí ch   x 
tình hu ố ng
Ph ân tí ch    x
gia o th ứ c
Bảng 5.2 Kỹ thuật yêu cầu; các ví dụ về kiến thức ngầm và tường
minh (Maiden và R ugg, 1995)
5.1.5 Lập tài li ệu các yêu cầu

Việc lập thành tài li ệu các yêu cầu là trọng tâm của quy trình và có
thể có m ột số hình thức. Thông thường, tài li ệu sẽ bao gồm m ột bản
m ục lục các yêu cầu, cùng với các yêu cầu riêng l ẻ được lập thành
văn bản, sử dụng một biểu m ẫu tiêu chuẩn. Một hoặc nhiều m ô hình

304
m inh họa cho các khía c ạnh cụ thể, chẳng hạn như các yêu c ầu về
xử lý hoặc dữ liệu, có thể bổ sung cho bản m ục lục này.
Trước khi chúng (các yêu c ầu) được nhập vào trong b ản m ục lục
m ột cách chính thức, các yêu cầu cần phải được xem xét k ỹ lưỡng.
Sự kỹ lưỡng này có th ể liên quan đến việc tổ chức các yêu cầu
thành các nhóm và ki ểm tra r ằng m ỗi yêu c ầu đã được ‘định dạng
tốt’.
Khi tài liệu đã được coi là hoàn t ất, nó phải được đánh giá bởi các
đại diện của doanh nghiệp và được xác nh ận để trở thành m ột tuyên
bố rõ ràng về các yêu c ầu, t ại thời điểm đó. Trong su ốt giai đo ạn
này, người đánh giá ki ểm tra các yêu c ầu và đặt câu hỏi về việc liệu
chúng có được xác định đầy đủ, rõ ràng và hoàn ch ỉnh hay không.
Khi chúng ta phát hi ện ra các nhu c ầu từ những người dùng khác

nhau của m ình, chúng ta c ần phải lập thành tài li ệu những yêu cầ u
này. Tốt nhất, việc này được thực hiện trong hai giai đo ạn riêng biệt
– xây dựng danh sách các nhu c ầu, sau đó, phát tri ển m ột bản m ục
lục các yêu cầu đã được tổ chức. Danh sách này có khuynh hư ớng
trở thành m ột tài liệu không chính th ức và có thể được trình bày
dưới dạng 4 cột, như được m inh họa trong B ảng 5.3.
Cá c yê u c ầu Ngu ồn Cá c bìn h lu ậ n M ức đ ộ c hi ti ết
Bảng 5.3 Danh sách các y êu cầu
Mỗi yêu c ầu trong danh sách ph ải được kiểm tra xem liệu nó có
được định dạng tốt hay không và có phải là SMART (Specific – Cụ
thể, Measurable – Có thể đo lường, Achievable – Có thể đạt được,
Realistic – Thực t ế, Tim ely – Hợp thời) không .
Khi kiểm tra các yêu cầu riêng lẻ và tổng thể, danh m ục kiểm tra
dưới đây có thể được sử dụng:
 Các yêu c ầu đã được nắm bắt và không mơ hồ?

 Ý nghĩa có rõ ràng không?
 Yêu cầu có liên kết với phát triển dịch vụ và các m ục tiêu kinh
doanh không, hay nó (yêu c ầu) không l iên quan?
 Yêu cầu có hợp lý không, hay nó s ẽ đắt đỏ và tiêu t ốn thời
gian để đáp ứng?
 Có bấy kỳ yêu cầu nào xung đột với yêu cầu khác khiến cho
chỉ có m ột yêu cầu được triển khai.
 Chúng có bao hàm m ột giải pháp thay vì ch ỉ tuyên bố m ột yêu
cầu không?
 Chúng có phải là cấu trúc nguyên t ử không, hay chúng th ực sự
là m ột số yêu cầu được nhóm lại thành m ột m ục nhập?
 Vài yêu cầu có bị trùng lặp hoặc chồng chéo lên yêu c ầu khác
không?

305
Có m ột số kết quả tiềm năng t ừ bài kiểm tra như sau:
 Chấp thuận yêu cầu như nó vốn t ồn tại.

 Thay đổi lại từ ngữ của yêu cầu để loại bỏ biệt ngữ và sự m ơ
hồ.
 Hợp nhất các yêu c ầu trùng lặp/chồng chéo.
 Trả lại các yêu c ầu không rõ ràng và m ơ h ồ cho người sử
dụng để làm rõ.
5.1.5.1 Bản mục lục các yêu c ầu

Mục lục các Yêu c ầu là kho lưu trữ trung tâm của các yêu cầu của
người sử dụng và m ọi yêu c ầu nên được lập thành tài li ệu ở đây,
tiếp theo là phân tích danh sách đã xác đ ịnh ở trên. Mục lục các Yêu
cầu nên hình thành m ột phần của Đường ống Dịch vụ tổng thể trong
Danh m ục Dịch vụ tổng thể. Mỗi yêu cầu đã được phân tích được lập
thành tài li ệu bằng cách sử dụng m ột biểu m ẫu tiêu chuẩn, như
được m inh họa trong Bảng 5.4.
Dịch vụ CNTT Tác giả Ngày
Mã định danh yêu c ầu Tên yêu cầu
Nguồn Chủ sở hữu Độ ưu tiên Quy trình

nghiệp vụ
Mô tả yêu cầu về chức năng
Các yêu c ầu về Quản lý, Mô tả

Vận hành và Khả năng
sử dụng
Biện m inh
Các tài liệu có liên quan
Các yêu c ầu có liên quan
Các bình lu ận
Giải pháp
Phiên bản Lịch sử thay đổi Ngày Yêu cầu

thay đổi
Bảng 5.4 Biểu mẫu về các yêu cầu
Các m ục nhập chủ yếu trong biểu m ẫu được giải thích dưới đây:
 Mã định danh yêu cầu – đây là m ột m ã định danh duy nh ất,

không bao giờ thay đổi và đư ợc sử dụng cho m ục đích có th ể

306
theo dõi được – ví dụ, để tham chiếu đến yêu cầu trong tài
liệu thiết kế, các đặc tả kỹ thuật kiểm nghiệm hoặc m ã ngu ồn
được triển khai. Đi ều này đảm bảo rằng m ọi yêu c ầu đã được
đáp ứng và m ọi chức năng đư ợc triển khai đều căn c ứ vào các
yêu cầu.
 Nguồn – lĩnh vực kinh doanh hoặc người sử dụng, người m à
đã đưa ra yêu c ầu hoặc tài liệu nơi mà yêu cầu được đưa ra.
Việc ghi nhận nguồn của m ột yêu c ầu giúp đảm bảo rằng các
câu hỏi có thể được trả lời hoặc nhu c ầu có thể được đánh giá
lại trong tương lai n ếu cần thiết.
 Chủ sở hữu – người sử dụng, người m à chấp nhận quyền chủ
sở hữu của yêu cầu riêng l ẻ, sẽ thống nhất rằng nó đư ợc viết
và lập thành tài li ệu m ột cách chính xác, và s ẽ ký xác nh ận tại
giai đoạn kiểm nghiệm chấp thuận khi được thỏa m ãn (yêu
cầu).
 Độ ưu tiên – m ức độ quan tr ọng và cần thiết của m ột yêu c ầu.
Thông thường, các phương pháp ti ếp cận như MoSCoW đư ợc
sử dụng, khi áp dụng cách giải thích sau về ghi nhớ:
o Must have (Ph ải có) – m ột yêu cầu then chốt m à nếu
không có thì dịch vụ không có giá trị.
o Should have (Nên có) – m ột yêu cầu quan tr ọng phải
được cung c ấp, nhưng nếu bị hạn hẹp về thời gian, có
thể được trì hoãn đ ể được cung cấp trong tương lai. Đây
nên là m ột trì hoãn ng ắn hạn, tuy nhiên d ịch vụ vẫn sẽ
có thể có giá tr ị m à không có các yêu c ầu này.
o Could have (Có th ể có) – m ột yêu cầu sẽ có lợi nếu
được bao gồm nếu như không t ốn quá nhiều chi phí
hoặc thời gian để cung c ấp, nhưng nó không ph ải là
trọng tâm của dịch vụ.
o Won’t have (S ẽ không có
Mo S C oW đư ợc v i ế t t ắt từ c ác c h ữ c á i đạ i d i ện c ủ a c ác t ừ M us t h a v e, S h ou l d
hav e , Co u l d v à W o n ’t hav e .
Những điều dưới đây nên được thống nhất m ột cách rõ ràng trong
suốt hoạt động thiết lập độ ưu tiên này:
 Các ưu tiên yêu c ầu có thể và sẽ thay đổi trong suốt vòng đời
của m ột dự án phát triển dịch vụ.
 Các yêu cầu ‘Nên có’ cần được xem xét m ột cách cẩn trọng
bởi vì nếu chúng không đư ợc chuyển giao tro ng giai đo ạn thiết
kế ban đầu, chúng có th ể sẽ không khả thi để triển khai sau
đó.
 Các yêu cầu luôn luôn khó khăn hơn và đắt hơn để đáp ứng
sau này trong Vòng đ ời dịch vụ.
 Không chỉ các yêu cầu chức năng m ới có thể là các yêu cầu
"Phải có" - m ột số yêu cầu về quản lý và vận hành ph ải là
"phải có".
 Mô t ả yêu c ầu - m ột m ô tả ngắn gọn về yêu cầu. Một phương
pháp tiếp cận hữu ích là m ô tả yêu cầu bằng cách sử dụng cấu
trúc:

307
o Tác nhân (hoặc vai trò người dùng),
o Cụm động t ừ,
o Đối tượng (danh t ừ hoặc cụm danh từ).
 Khi yêu c ầu kết hợp với các quy tắc nghiệp vụ phức t ạp hoặc
xác thực dữ liệu, bảng quyết định hoặc cây quyết định có thể
hữu ích hơn đ ể xác định các quy t ắc nghiệp vụ phức tạp, trong
khi các quy t ắc xác thực dữ liệu có thể được xác định trong
m ột kho lưu trữ. Nếu m ột kỹ thuật bổ sung được sử dụng để
xác định hoặc m ô hình hóa yêu c ầu, thì nên có m ột tham chiếu
chéo đến tài li ệu liên quan.
 Quy trình nghiệp vụ - m ột cụm từ đơn giản để nhóm lại cùng
với nhau các yêu c ầu hỗ trợ m ột hoạt động cụ thể, chẳng hạn
như bán hàng, hàng t ồn kho, dịch vụ khách hàng, v.v…
 Biện m inh - không phải tất cả các yêu cầu được đưa ra sẽ
được đáp ứng. Điều này có thể do hạn chế về thời gian và
ngân sách, ho ặc có thể do yêu c ầu bị loại bỏ để thay thế cho
m ột yêu cầu m âu thu ẫn. Thường thì yêu cầu này không được
đáp ứng vì nó tạo thêm ít giá tr ị cho doanh nghi ệp. Bản biện
m inh đưa ra các lý do đưa ra yêu cầu.
 Các yêu cầu liên quan - các yêu cầu có thể liên quan đ ến nhau
vì m ột số lý do. Đôi khi có m ột liên k ết giữa chức năng được
yêu cầu bởi các yêu c ầu hoặc m ột yêu cầu cấp cao đư ợc làm
rõ bởi m ột loạt các yêu cầu chi tiết hơn.
 Lịch sử thay đổi – những m ục nhập trong phần này cung cấp
m ột hồ sơ về m ọi thay đổi ảnh hưởng đến yêu c ầu. Việc này là
cần thiết cho m ục đích quản lý cấu hình và m ục đích theo dõi
được.
5.1.5.2 Tài li ệu về yêu cầu đầy đủ

Một tài liệu có hiệu lực về các yêu cầu nên bao gồm những thành
phần sau đây:
 Một bảng chú giải thuật ngữ để xác định m ỗi thuật ngữ thuộc
về tổ chức được sử dụng trong tài liệu về các yêu c ầu. Điều
này giúp quản lý vấn đề về biệt ngữ địa phương và s ẽ làm rõ
các t ừ đồng nghĩa và đ ồng âm cho b ất kỳ ai sử dụng tài li ệu.
 Một m ô hình phạm vi, chẳng hạn như sơ đồ bối cảnh hệ thống.
 Bản Mục lục các Yêu c ầu, lý tưởng nhất là được duy trì như
m ột phần của Danh m ục Dịch vụ tổng thể.
 Các m ô hình h ỗ trợ, chẳng hạn như các m ô hình quy trình
nghiệp vụ, các sơ đ ồ luồng dữ liệu và sơ đồ tương tác.
Quản lý những thay đổi đối với tài liệu

Những thay đổi có thể xảy ra bởi vì:
 Phạm vi của dịch vụ m ới đã thay đổi do ràng bu ộc về ngân

sách.
 Dịch vụ phải tuân thủ những quy định và luật lệ m ới.
 Những thay đ ổi trong ưu tiên kinh doanh đã đư ợc thông báo.
 Các bên liên quan đã hi ểu tốt hơn về m ột yêu c ầu sau m ột số
phân tích chi ti ết – ví dụ, sử dụng m ột tình huống hoặc nguyên

308
m ẫu – và đã điều chỉnh yêu cầu ban đầu m ột cách tương
xứng.
Có m ột số công c ụ hỗ trợ chuyên nghiệp trên thị trường để hỗ trợ

cho các quy trình yêu c ầu. Chúng thỉnh thoảng còn được gọi là
CARE – Com puter Aided Requirem ents Engineering (K ỹ thuật Yêu
cầu được Máy tính Hỗ trợ) hoặc CASE – Com puter Aided Software
Engineering (K ỹ thuật Phần m ềm được Máy tính Hỗ trợ). Các chức
năng bao gồm :
 Duy trì các tham chi ếu chéo giữa các yêu cầu.
 Lưu trữ tài liệu về các yêu cầu.
 Quản lý các thay đổi đối với tài liệu về các yêu cầu.
 Quản lý các phiên b ản của tài liệu về các yêu c ầu.
 Đưa ra các tài li ệu đặc tả kỹ thuật về các yêu c ầu đã được
định dạng từ cơ sở dữ liệu.
 Đảm bảo các tài li ệu được cung cấp bởi bất kỳ dự án giải pháp
nào là thích hợp để cho phép s ự hỗ trợ.
5.1.6 Các yêu cầu và sự thuê ngoài

Mục đích là để lựa chọn các giải pháp đã được đóng gói tiêu chu ẩn
ở bất cứ nơi đâu kh ả thi để đáp ứng các yêu cầu dịch vụ. Tuy
nhiên, bất kể các yêu c ầu CNTT đư ợc m ua sắm giải pháp thương
m ại có sẵn, được phát tri ển bởi nội bộ hoặc được thuê ngoài, m ọi
hoạt động cho đến việc đưa ra m ột đặc tả kỹ thuật của yêu cầu kinh
doanh đều được hoàn thành trong n ội bộ. Rất nhiều hợp đồng phát
triển dịch vụ CNTT giả định rằng có thể biết được các yêu cầu là
những gì ngay t ại khi bắt đầu, và rằng có thể đưa ra m ột đặc tả kỹ
thuật thể hiện các yêu c ầu m ột cách rõ ràng. Đ ối với các dịch vụ, trừ
các dịch vụ đơn giản nhất, điều này hi ếm khi đúng. Phân tích các
yêu cầu là m ột quy trình lặp đi lặp lại – các yêu c ầu sẽ thay đổi
trong suốt khoảng thời gian m à ứng dụng và dịch vụ đang được phát
triển. Nó sẽ đòi hỏi sự tham gia c ủa người sử dụng trong su ốt quá
trình phát tri ển, như trong các phương pháp ti ếp cận DSDM và
‘agile’ khác.
5.1.6.1 Các tình huống về các yêu cầu thuê ngoài điển hình
Những phương pháp ti ếp cận điển hình để ký kết hợp đồng phát
triển các hệ thống CNTT sẽ được cung cấp để hỗ trợ cho m ột dịch
vụ CNTT như sau:
 Đặc tả k ỹ thuật các yêu c ầu cấp-thấp – ranh giới giữa ‘khách

hàng’ và nhà cung c ấp được rút ra gi ữa đặc tả kỹ thuật yêu
cầu chi tiết và bất kỳ hoạt động thiết kế nào. Mọi yêu c ầu có
tác động đến người sử dụng đã được xác định cụ thể, đưa ra
m ột đích nh ắm m ục tiêu triển khai rất rõ ràng và chính xác cho
nhà cung c ấp. Tuy nhiên, n ỗ lực dành cho đ ặc tả kỹ thuật ngày
càng tăng và giá tr ị cộng thêm của nhà cung c ấp bị hạn chế ở
những khía cạnh khó khăn c ủa việc phát triển.
 Đặc tả kỹ thuật các yêu cầu cấp cao – ranh giới khách
hàng/nhà cung c ấp nằm giữa các yêu c ầu cấp cao và m ọi giai

309
đoạn khác. Hợp đồng với nhà cung cấp bao gồm m ọi thứ nằm
ở tuyến dưới. Khách hàng ch ịu trách nhi ệm cho việc kiểm
nghiệm các dịch vụ đã được cung c ấp so với các yêu cầu của
doanh nghi ệp. Do việc xác định các yêu cầu cấp cao là d ễ
dàng hơn, nên n ỗ lực để phát triển các đầu vào của hợp đồng
sẽ giảm . Tuy nhiên, có th ể có những vấn đề đáng kể về việc
chi phí và r ủi ro cũng gia tăng đ ối với cả khách hàng lẫn nhà
cung c ấp, cùng với đó là sự gia tăng kh ả năng bị m ắc lỗi, sự
thiếu ổn định c ủa các yêu cầu và m ức độ khó khăn gia tăng
trong việc biết về việc bạn m uôn hệ thống thông tin nào.
5.2 Quản lý dữ liệu và thông tin

Dữ liệu là m ột loại tài sản quan tr ọng cần được quản lý nhằm phát
triển, cung c ấp và hỗ trợ cho các dịch vụ CNTT m ột cách hiệu quả.
Quản lý Dữ liệu/thông tin là cách m à t ổ chức lập kế hoạch, thu thập,
tạo ra, tổ chức, sử dụng, kiểm soát, ph ổ biến và hủy bỏ d ữ
liệu/thông tin c ủa mình như th ế nào, kể các các hồ sơ có cấu trúc và
dữ liệu phi cấu trúc. Nó cũng đ ảm bảo rằng giá tr ị của dữ liệu/thông
tin đó được xác định và được khai thác, cả trong việc hỗ trợ lẫn hoạt
động nội bộ và trong vi ệc thêm giá tr ị cho các quy trình nghi ệp vụ
đối m ặt với-khách hàng c ủa họ.
Một số thuật ngữ là khá phổ biến trong lĩnh vực này, bao g ồm ‘Quản
lý Dữ liệu’, ‘Quản lý Thông tin’, và ‘Qu ản lý Tài nguyên Thông tin’.
Do m ục đích c ủa ấn phẩm này, khái niệm ‘Quản lý Dữ liệu’ được sử
dụng như bản tốc ký của cả ba thuật ngữ nói trên.
Vai trò của Quản lý Dữ liệu được m ô tả không chỉ là quản lý dữ liệu
thô m à còn là qu ản lý m ọi siêu dữ liệu theo ng ữ cảnh – ‘dữ liệu về
dữ liệu’ bổ sung – đi kèm với nó, và k hi được thêm vào d ữ liệu thô
sẽ cung cấp ‘thông tin’ ho ặc ‘dữ liệu theo ngữ cảnh’.
Dữ liệu, như là n ền tảng của thông tin của tổ chức, có m ọi thuộc

tính cần thiết để đưọc coi như m ột tài sản (hoặc tài nguyên). Ví d ụ,
nó là điều thiết yếu đối với ‘thành tựu của các m ục tiêu kinh doanh
và những hoạt động hàng ngày thành công c ủa m ột tổ chức’. Ngoài
ra, nó có thể ‘có được và bảo quản bởi m ột tổ chức nhưng ch ỉ với
chi phí tài chính’. Và cu ối cùng, nó có th ể, cùng với những tài
nguyên/tài sản khác, được sử dụng để ‘tiếp tục đạt được thành tựu
của những m ục tiêu của tổ chức’.
Các yếu tố then chốt để Quản lý Dữ liệu thành công bao g ồm:
 Tất cả những người dùng đều có quyền truy cập sẵn sàng
thông qua nhiều kênh khác nhau đến thông tin m à h ọ cần để
thực hiện công việc của m ình.
 Tài sản dữ liệu được khai thác tri ệt để, thông qua chia s ẻ dữ
liệu trong tổ chức và với các cơ quan khác.
 Chất lượng của dữ liệu của tổ chức được duy trì ở m ột m ức có
thể chấp nhận được, và thông tin s ử dụng trong doanh nghi ệp
là chính xác, đáng tin c ậy và nhất quán.

310
 Các yêu c ầu pháp lý đ ối với việc duy trì quyền riêng tư, bảo
m ật, bí m ật và toàn vẹn của dữ liệu được tuân thủ.
 Tổ chức đạt được tính hiệu quả và hiệu suất cao trong các
hoạt động xử lý dữ liệu và thông tin c ủa m ình.
 Một m ô hình d ữ liệu doanh nghiệp để xác định những thực thể
quan trọng nhất và các m ối quan hệ của chúng – điều này giúp
tránh được sự dư thừa và tránh được sự xuống cấp của kiến
trúc khi nó thay đổi qua nhiều năm .
5.2.1 Quản lý tài s ản dữ liệu

Nếu dữ liệu không được quản lý m ột cách hiệu quả:
 Mọi người duy trì và thu thập dữ liệu không c ần thiết.

 Tổ chức có thể có những thông tin quá kh ứ không đư ợc sử
dụng nữa.
 Tổ chức có thể giữ m ột lượng lớn dữ liệu không thể truy cập
được bởi những người dùng tiềm năng.
 Tổ chức có thể sử dụng những phương pháp l ạc hậu và không
hiệu quả để thu thập, phân tích, lưu tr ữ và hồi phục dữ liệu.
 Tổ chức có thể thất bại trong việc thu thập dữ liệu m à mình
cần, làm giảm chất lượng của dữ liệu và m ất tính toàn vẹn dữ
liệu, ví dụ, giữa các nguồn dữ liệu.
Ngoài ra, thông tin có đư ợc khởi nguồn từ dữ liệu có chất lượng tốt
hay không là m ột câu hỏi khó tr ả lời, bởi vì không có m ột thước đo
nào có s ẵn để so sánh nó. Ví dụ, chất lượng dữ liệu thấp thường
phát sinh do vi ệc kiểm tra đầu vào và/ho ặc các thủ tục cập nhật
kém . Khi dữ liệu không chính xác ho ặc không đầy đủ đã được lưu
trữ trên hệ thống CNTT, bất kỳ báo cáo nào được đưa ra sử dụng
những dữ liệu đó s ẽ phản ảnh những sự không chính xác ho ặc lỗ
hổng đó. Cũng có th ể có sự thiếu nhất quán giữa thông ti n quản lý
được tạo ra-trong nội bộ với các hệ thống vận hành, và với các hệ
thống nội bộ khác, ch ỉ được sử dụng trong n ội bộ, sẽ phát sinh do
dữ liệu trung tâm không đáng tin c ậy.
Một cách để cải thiện chất lượng của dữ liệu là sử dụng quy trình
Quản lý Dữ liệu nhằm thiết lập chính sách và các tiêu chu ẩn, cung
cấp kiến thức chuyên m ôn và làm cho vi ệc xử lý các khía c ạnh dữ
liệu của các dịch vụ m ới trở nên dễ dàng hơn. Sau đó, đi ều này cho
phép Quản lý Dữ liệu/Thông tin đầy đủ để:
 Thêm giá tr ị vào các dịch vụ được cung cấp cho khách hàng.
 Giảm rủi ro trong doanh nghi ệp.
 Giảm chi phí c ủa các quy trình nghi ệp vụ.
 Khuyến khích sự đổi m ới trong các quy trình nghi ệp vụ nội bộ.
5.2.2 Phạm vi của Quản lý Dữ liệu

Có bốn lĩnh vực của quản lý được bao gồm trong phạm vi của Quản
lý Dữ liệu/Thông tin:
 Quản lý tài nguyên d ữ liệu: việc quản trị thông tin trong t ổ
chức phải đảm bảo rằng m ọi tài nguyên đó đã đư ợc biết đế n

311
và rằng các trách nhi ệm đã được chỉ định cho việc quản lý
chúng, bao gồm quyền sở hữu dữ liệu và siêu d ữ liệu. Quy
trình này thường được gọi là quản trị dữ liệu và bao g ồm
những trách nhiệm đối với:
o Xác định các nhu cầu thông tin.
o Xây dựng kho dữ liệu và m ột m ô hình dữ liệu doanh
nghiệp.
o Xác định sự trùng lặp và thi ếu sót dữ liệu.
o Duy trì m ột bản m ục lục/chỉ m ục của nội dung d ữ
liệu/thông tin.
o Đo lường chi phí và giá tr ị của dữ liệu của tổ chức.
 Công nghệ Quản lý Dữ liệu/Thông tin: việc quản lý của
CNTT làm nền tảng cho các h ệ thống thông tin c ủa t ổ chức,
việc này bao g ồm các quy trình như thi ết kế cơ sở dữ liệu và
quản trị cơ sở dữ liệu. Khía cạnh này thường được xử lý bởi
các chuyên gia trong ch ức năng CNTT – xem thêm ấn phẩm
Vận hành Dịch vụ để biết thêm chi tiết.
 Quản lý các quy trình thông tin : các quy trình nghi ệp vụ sẽ
dẫn đến việc các dịch vụ CNTT tham gia vào m ột hoặc các tài
nguyên dữ liệu khác của tổ chức. Quy trình t ạo, thu thập, truy
cập, sửa đổi, lưu tr ữ, xóa và lưu gi ữ dữ liệu – nghĩa là vòng
đời của dữ liệu – phải được kiểm soát m ột cách đúng đắn,
thường kết hợp với quy trình qu ản lý các ứng dụng.
 Các tiêu chu ẩn và chính sách qu ản lý dữ liệu: tổ chức sẽ
cần xác định các tiêu chu ẩn và chính sách cho quy trình Qu ản
lý Dữ liệu của m ình như là m ột khía c ạnh của chiến lượ c
CNTT. Các chính sách s ẽ chi phối các thủ tục và trách nhiệm
đối với Quản lý Dữ liệu trong tổ chức, và các chính sách, ki ến
trúc và tiêu chu ẩn kỹ thuật sẽ áp dụng cho cơ s ở hạ tầng
CNTT hỗ trợ cho các hệ thống thông tin của tổ chức.
Phạm vi của thực tiễn tốt nhất của quy trình Quản lý Dữ liệu bao
gồm việc quản lý dữ liệu không có c ấu trúc và không được lưu gi ữ
trong các hệ thống cơ sở dữ liệu thông thường - ví dụ: sử dụng các
định dạng như văn bản, hình ảnh và âm thanh. Nó cũng ch ịu trác h
nhiệm đảm bảo cho chất lượng của quy trình ở tất cả các giai đo ạn
của vòng đời dữ liệu, từ các yêu cầu cho đến khi ngừng hoạt động.
Trọng tâm chính trong ấn phẩm này sẽ đặt vào vai trò c ủa nó trong
các giai đoạn yêu c ầu, thiết kế và phát triển của Vòng đời Dịch vụ
và tài sản.
Nhóm hỗ trợ quy trình Quản lý Dữ liệu cũng có th ể cung cấp dịch vụ
hỗ trợ thông tin doanh nghiệp. Trong trường hợp này, họ có khả
năng trả lời các câu h ỏi về ý nghĩa, định dạng và tính khả dụng của
dữ liệu trong nội bộ tổ chức, vì họ là người quản lý siêu d ữ liệu. Họ
cũng có khả năng hiểu và giải thích nh ững dữ liệu bên ngoài nào có
thể cần thiết để thực hiện các quy trình nghiệp vụ cần thiết và sẽ
tiến hành các hành động cần thiết để tìm nguồn này.
Điều quan tr ọng là khi t ạo hoặc thiết kế lại các quy trình và h ỗ trợ
cho các dịch vụ CNTT, sẽ là m ột thực tiễn tốt khi xem xét vi ệc tái sử

312
dụng lại dữ liệu và siêu dữ liệu trên các lĩnh vực khác nhau c ủa tổ
chức. Khả năng thực hiện điều này có th ể được hỗ trợ bởi m ột m ô
hình dữ liệu công ty - đôi khi được gọi là m ô hình thông tin chung -
để giúp hỗ trợ việc tái sử dụng, thường là m ục tiêu chín h để quản lý
dữ liệu.
5.2.3 Quản lý Dữ liệu và Vòng đời Dịch vụ

Chúng tôi khuyến cáo rằng m ột phương pháp ti ếp cận kiểu vòng đời
được áp dụng khi tìm hiểu về việc sử dụng dữ liệu trong các quy
trình nghiệp vụ. Những vấn đề chung bao g ồm :
 Những dữ liệu nào hiện đang được xử lý và dữ liệu được phân

loại như thế nào?
 Những dữ liệu nào cần được thu th ập hoặc tạo ra bởi các quy
trình nghiệp vụ?
 Dữ liệu sẽ được lưu trữ và duy trì như thế nào?
 Dữ liệu sẽ được truy cập như thế nào, bởi ai và theo cách
nào?
 Dữ liệu sẽ được hủy bỏ như thế nào, và dưới quyền hạn của
ai?
 Chất lượng c ủa dữ liệu sẽ được duy trì như th ế nào (tính
chính xác, nh ất quán, hiện hành, v.v…)?
 Làm thế nào để dữ liệu có thể truy cập/sẵn sàng hơn nữa?
5.2.4 Hỗ trợ Vòng đời Dịch vụ

Trong suốt giai đo ạn yêu c ầu và thiết kế ban đầu, Quản lý Dữ liệu có
thể hỗ trợ cho các nhóm thiết kế và phát tri ển với việc m ô hình hóa
dữ liệu dịch vụ-cụ thể và đưa ra khuyến cáo về việc sử dụng các k ỹ
thuật khác nhau đối với m ô hình dữ liệu.
Trong giai đo ạn thiết kế và phát tri ển chi tiết (‘vật lý’), chức năng
Quản lý Dữ liệu có thể cung cấp chuyên m ôn k ỹ thuật về các hệ
thống quản lý cơ s ở dữ liệu và về việc làm thế nào để chuyển đổi
các m ô hình ‘lu ận lý’ ban đ ầu của dữ liệu thành m ô hình v ật lý, sản
phẩm cụ thể và các triển khai.
Rất nhiều dịch vụ mới đã thất bại bởi chất lượng dữ liệu kém đã
không được giải quyết trong giai đo ạn phát tri ển dịch vụ, hoặc bởi vì
m ột phát triển đặc biệt đã tạo ra dữ liệu và siêu dữ liệu của riêng nó
m à không tham vấn các chủ sở hữu khác của dịch vụ hoặc với Quản
lý Dữ liệu.
5.2.5 Định giá dữ liệu

Dữ liệu là m ột tài s ản và nó có giá tr ị. Trong m ột số tổ chức, điều
này được quan sát thấy m ột cách rõ ràng hơn là trong nh ững tổ
chức khác. Các t ổ chức là những nhà cung c ấp dữ liệu cho các t ổ
chức khác – Yell, Dun và Bradstreet, và Reuters – có thể định giá
dữ liệu như m ột ‘đầu ra’ xét về m ặt giá cả m à họ tính phí cho các t ổ
chức bên ngoài đ ể nhận được nó (dữ liệu). Cũng có th ể nghĩ về giá
trị về m ặt những gì m à dữ liệu nội bộ sẽ có giá trị đối với tổ chức
khác.

313
Việc định giá dữ liệu về m ặt những gì có giá tr ị đối với tổ chức ngày
càng phổ biến. Có m ột số cách được đề nghị để làm điều này:
 Định giá dữ liệu bởi tính sẵn sàng: m ột phương pháp tiếp
cận thường sử dụng là xem xét những quy trình nghi ệp vụ nào
sẽ không thể thực hiện được nếu m ột phần cụ thể của dữ liệu
không sẵn sàng, và vi ệc không có s ẵn dữ liệu đó sẽ khiến
doanh nghiệp phải chịu bao nhiêu chi phí.
 Định giá dữ liệu bị mất: m ột phương pháp tiếp cận khách
thường được sử dụng để nghĩ về chi phí c ủa việc có lại được
m ột số dữ liệu khi nó đã b ị phá hủy.
 Định giá dữ liệu bằng cách xem xét vòng đ ời của dữ liệu:
điều này liên quan đ ến việc suy nghĩ về cách dữ liệu được tạo
ra hoặc có được ngay t ừ đầu, cách nó sẵn sàng để cho m ọi
người sử dụng và cách dữ liệu được gỡ bỏ như thế nào, thông
qua lưu giữ hoặc phá hủy vật lý. Có th ể là m ột số dữ liệu được
cung cấp từ m ột nguồn bên ngoài và sau đó đư ợc lưu tr ữ nội
bộ hoặc có thể dữ liệu đó phải được tạo bởi các hệ thống nội
bộ của tổ chức. Trong hai trường hợp này, vòng đời (của dữ
liệu) là khác nhau và các quá trình di ễn ra để thu thập dữ liệu
sẽ hoàn toàn riêng bi ệt. Trong c ả hai trường hợp, chi phí của
việc thực hiện lại các giai đo ạn này có thể được đánh giá. Dữ
liệu càng được đánh giá cao thì càng ph ải nỗ lực nhiều hơn để
đảm bảo tính toàn v ẹn, tính sẵn có và tính b ảo m ật của nó.
5.2.6 Phân loại dữ liệu

Dữ liệu có thể được phân loại ban đầu theo vận hành, chi ến thuật
hoặc chiến lược:
 Dữ liệu vận hành: cần thiết cho các chức năng liên t ục tiếp
diễn của m ột tổ chức và có thể được coi là m ức thấp nhất và
cụ thể nhất.
 Dữ liệu chi ến thu ật: thường được cần đến bởi các quản lý
tuyến hai – hoặc cao hơn – và thường được đề cập cùng vớ i
dữ liệu tổng hợp và dữ liệu lịch sử, thông thường là dữ liệu
hàng năm hoặc hàng quý. Thông thư ờng, dữ liệu được sử
dụng ở đây xuất hiện trong các h ệ thống thông tin qu ản lý đòi
hỏi dữ liệu t ổng hợp từ m ột số các hệ thống vận hành, ví dụ,
nhằm xử lý các yêu cầu kế toán.
 Dữ liệu chiến lược: thường được đề cập cùng với những
khuynh hướng dài hạn hơn và so sánh với thế giới bên ngoài,
do đó, việc cung c ấp dữ liệu cần thiết cho m ột hệ thống hỗ trợ
chiến lược liên quan đến việc tập hợp dữ liệu vận hành và d ữ
liệu chiến thuật từ rất nhiều lĩnh vực khác nhau với những d ữ
liệu từ bên ngoài có liên quan. Các nguồn dữ liệu từ bên ngoài
được đòi hỏi nhiều hơn.
Một phương pháp thay th ế là sử dụng m ột sự phân loại bảo m ật của

dữ liệu và các tài li ệu. Việc này thường được áp dung như là m ột
chính sách doanh nghi ệp trong m ột tổ chức.

314
Một phép phân loại trực giao phâ n biệt dữ liệu ở quy m ô toàn bộ-tổ
chức, dữ liệu khu vực-chức năng và dữ liệu của dịch vụ-cụ thể.
 Dữ liệu ở quy m ô toàn b ộ tổ chức cần phải được quản lý tập

trung.
 Mức tiếp theo c ủa dữ liệu là dữ liệu khu vực-chức năng nên
được chia s ẻ qua m ột chức năng nghiệp vụ hoàn chỉnh. Việc
này liên quan đ ến việc chia s ẻ dữ liệu ‘các trường hợp’ – ví
dụ, các hồ sơ khách hàng riêng l ẻ - và cũng đảm bảo rằng tính
nhất quán c ủa siêu dữ liệu qua khu vực chức năng đó, ch ẳng
hạn như định dạng địa chỉ tiêu chuẩn, được sử dụng.
 Mức cuối cùng là (d ữ liệu) dịch vụ CNTT cụ thể, khi m à dữ liệu
và siêu dữ liệu có hiệu lực đối với m ột dịch vụ CNTT và không
nhất thiết được chia sẻ với các dịch vụ khác.
5.2.7 Thiết lập các tiêu chu ẩn dữ liệu

Một trong những khía c ạnh quan trọng của quản trị dữ liệu là đảm
bảo có sẵn các tiêu chu ẩn cho siêu dữ liệu - ví dụ: siêu dữ liệu nào
sẽ được lưu gi ữ cho các ‘kiểu dữ liệu’ nền tảng khác nhau. Các chi
tiết khác nhau được lưu giữ về dữ liệu dạng bảng có cấu trúc so với
các lĩnh vực khác. ‘Quyền sở hữu’ là m ột m ục quan trọng của siêu
dữ liệu này, m ột số loại m ã định danh duy nhất là m ột m ục khác, m ô
tả bằng các thuật ngữ có ý nghĩa kinh doanh là m ột m ục khác và
định dạng có thể là m ột định dạng khác. Người giám sát ho ặc người
quản lý, m ột người nào đó trong bộ phận CNTT chịu trách nhiệm
quản lý dữ liệu hàng ngày, cũng sẽ được ghi lại.
Một lợi ích khác c ủa quy trình Quản lý Dữ liệu sẽ là trong lĩnh v ực
dữ liệu tham chiếu. Một số kiểu dữ liệu nhất định, chẳng hạn như
m ã bưu đi ện hoặc tên của các quốc gia, có thể cần thiết trên nhiều
hệ thống và cần phải được nhất quán. Một phần trách nhi ệm của
quản trị viên dữ liệu là quản lý dữ liệu tham chiếu thay m ặt cho toàn
doanh nghiệp và đảm bảo rằng cùng m ột dữ liệu tham chi ếu đều
được sử dụng bởi tất cả các hệ thống trong t ổ chức.
Các tiêu chu ẩn về đặt tên phải được đặt ra; vì vậy, ví dụ, nếu m ột
loại dữ liệu m ới được yêu cầu trong m ột dịch vụ m ới, thì cần phải sử
dụng các tên gọi đáp ứng các tiêu chuẩn này. Tiêu chu ẩn m ẫu có
thể là "tất cả các chữ hoa, không gạch chân và không viết tắt".
5.2.8 Chủ sở hữu dữ liệu

Quản trị viên dữ liệu có thể hỗ trợ nhà phát tri ển dịch vụ bằng cách
đảm bảo quyền sở hữu đối với dữ liệu được thực hiện m ột cách
nghiêm túc bởi cả doanh nghiệp lẫn bộ phận CNTT. Một trong những
cách thành công nh ất để thực hiện việc này là yêu cầu bộ phận
CNTT và doanh nghi ệp cùng ký vào m ột điều lệ dữ liệu – một bộ các
tiêu chuẩn thủ tục và hướng dẫn về việc quản lý cẩn trọng dữ liệu
trong t ổ chức, bằng cách tuân th ủ các tiêu chuẩn đã được xác định
m ột cách xác đá ng. Trách nhi ệm của chủ sở hữu dữ liệu thường
được xác định ở đây và có thể bao gồm:

315
 Thống nhất về m ột m ô tả doanh nghi ệp và m ục đích của dữ
liệu.
 Xác định ai có thể tạo ra, điều chỉnh, đọc và xóa các l ần xuất
hiện của dữ liệu.
 Cho phép nh ững thay đổi trong cách dữ liệu được thu thậ p
hoặc dẫn xuất.
 Phê duyệt bất kỳ định dạng, lĩnh vực và phạm vi dữ liệu nào.
 Phê duyệt m ức bảo m ật liên quan, bao gồm việc đảm bảo rằng
các yêu c ầu pháp lý và chính sách n ội bộ về bảo m ật dữ liệu
được tuân th ủ.
5.2.9 Chuyển đổi dữ liệu

Chuyển đổi dữ liệu là m ột vấn đề khi mà m ột dịch vụ m ới đang thay
thế m ột số (có thể chỉ m ột) dịch vụ hiện hữu, và nó (dữ liệu) cần
phải chuyển sang dịch vụ m ới, dữ liệu chất lượng t ốt từ các hệ
thống và dịch vụ hiện có. Có hai lo ại chuyển đổi dữ liệu đáng quan
tâm cho các trù ho ạch ở đây: m ột là chuyển đổi dữ liệu vào kho dữ
liệu, v.v... cho các m ục đích kinh doanh/phân tích; còn l ại là di
chuyển dữ liệu sang m ột dịch vụ vận hành, giao dịch m ới. Trong c ả
hai trường hợp, sẽ có lợi nếu các tiêu chu ẩn, thủ tục và quy trình
chuyển đổi dữ liệu đã được đặt ra bởi Quản lý dữ liệu. Các công c ụ
chuyển đổi dữ liệu có thể đã được m ua bởi nhóm Quản lý Dữ liệu
thay m ặt cho tổ chức. Nếu không có sự hỗ trợ này, rất dễ dàng đánh
giá thấp lượng nỗ lực cần thiết, đặc biệt nếu việc hợp nhất và làm
sạch dữ liệu phải diễn ra giữa nhiều hệ thống nguồn và chất lượng
dữ liệu của các dịch vụ hiện có được cho là có vấn đề.
5.2.10 Lưu trữ dữ liệu

Một lĩnh vực m à công nghệ đã phát tri ển rất nhanh chóng là lĩnh v ực
lưu trữ dữ liệu. Cần phải xem xét các phương ti ện lưu trữ khác nhau
- ví dụ, bộ lưu trữ quang - và lưu ý về kích thước và tác động chi phí
tương ứng với điều này. Lý do chính đ ể tìm hiểu sự phát triển trong
lĩnh vực này là chúng có thể tạo ra nhiều loại lĩnh vực quản lý dữ
liệu m à trước đây được coi là quá đ ắt đỏ. Ví dụ, để lưu trữ video
thời gian thực, sử dụng m ột băng thông lớn, đã từng, cho đến hai
đến ba năm qua, đư ợc coi là quá đ ắt đỏ. Điều này cũng đúng v ới
việc quét m ột số lượng lớn tài liệu bằng giấy, đặc biệt khi những tài
liệu đó không phải là văn bản m à chứa các sơ đ ồ hoặc hình ảnh chi
tiết. Việc hiểu được sự phát triển của công ngh ệ liên quan đ ến lưu
trữ dữ liệu điện tử là rất quan tr ọng để hiểu về các cơ hội cho doanh
nghiệp để khai thác tài nguyên thông tin m ột cách hiệu quả bằng
cách sử dụng tốt nhất công nghệ m ới.
5.2.11 Nắm bắt dữ liệu

Một điều cũng rất quan trọng là làm vi ệc với Quản lý Dữ liệu về các
biện pháp hiệu quả để thu thập dữ liệu. Mục đích ở đây là thu th ập
dữ liệu m ột cách nhanh nhất và chính xác nhất có thể. Cần phải đảm
bảo rằng các quy trình thu th ập dữ liệu yêu cầu số lượng nhập li ệu
tối thiểu và khai thác các l ợi thế m à giao di ện người dùng đồ họa
m ang lại để giảm thiểu số lần nhấn phím cần thiết, đồng thời giảm
cơ hội xảy ra lỗi trong quá trình thu th ập dữ liệu. Sẽ hợp lý khi k ỳ

316
vọng rằng quy trình Quản lý Dữ liệu có các tiêu chu ẩn đối với, và có
thể cung cấp kiến thức chuyên m ôn về các phương pháp thu th ập d ữ
liệu hiệu quả trong các m ôi trư ờng khác nhau, bao g ồm cả việc thu
thập dữ liệu 'không có cấu trúc' bằng cách sử dụng các cơ chế như
quét (scan).
5.2.12 Tru y xuất và sử dụng dữ liệu

Khi dữ liệu đã được thu thập và lưu tr ữ, khía cạnh tiếp theo cần xem
xét là truy xuất thông tin t ừ dữ liệu. Các dịch vụ cho phép truy c ập
dễ dàng vào dữ liệu có c ấu trúc thông qua c ác công c ụ truy vấn ở
nhiều m ức độ phức tạp khác nhau được cần đến bởi m ọi tổ chức, và
tạo ra các nhu c ầu kiến trúc cụ thể của riêng họ. Toàn bộ khu vực
tìm kiếm trong văn bản được quét và những dữ liệu không có c ấu
trúc khác như video, hình ảnh tĩnh hoặc âm thanh là m ột khu vực
mở rộng chủ yếu. Các k ỹ thuật như lập chỉ m ục tự động và sử dụng
công cụ tìm kiếm để truy cập hiệu quả thông qua các t ừ khóa đến
các phần liên quan c ủa tài liệu là những công nghệ thiết yếu đã
được triển khai m ột cách rộng rãi, đặc biệt là trên Internet. Cần có
chuyên m ôn trong vi ệc sử dụng dữ liệu hoặc nội dung trong các
trang web trong Qu ản lý Dữ liệu cũng như Qu ản lý Nội dung - các
tiêu chuẩn và quy trình là điều sống còn đối với các trang web .
5.2.13 Toàn vẹn dữ liệu và các vấn đề liên quan

Khi xác định các yêu cầu đối với các dịch vụ CNTT, m ột điều sống
còn là các yêu c ầu về quản lý và vận hành có liên quan đến dữ liệu
phải được xem xét. Cụ thể, những lĩnh vực dưới đây phải được xác
định:
 Khôi phục dữ liệu bị m ất hoặc bị lỗi.

 Quyền truy cập tới dữ liệu được kiểm soát.
 Việc triển khai các chính sách v ề việc lưu giữ dữ liệu, bao
gồm tuân thủ quy định về khoảng thời gian lưu giữ.
 Các kiểm tra định kỳ tính toàn vẹn dữ liệu.
Toàn vẹn dữ liệu được đề cập cùng v ới việc đảm bảo rằng dữ liệu
có chất lượng cao và không b ị lỗi. Đó cũng là v ề việc ngăn ng ừa sự
sao chép dữ liệu không được kiểm soát, và do đó tránh đư ợc bất kỳ
sự nhầm lẫn nào về phiên bản hợp lệ của dữ liệu. Có m ột số
phương pháp tiếp cận có thể hỗ trợ cho việc này. Các thi ết bị công
nghệ khác nhau như ‘khóa cơ s ở dữ liệu’ cũng được sử dụng để
ngăn chặn việc cập nhật dữ liệu nhiều lần và không nhất quán.
Ngoài ra, vi ệc ngăn ngừa cập nhật bất hợp pháp cũng có thể đạt
được thông qua các cơ ch ế kiểm soát truy c ập.
5.3 Quản lý Ứng dụng

Một ứng dụng được xác định ở đây như là (các) c hương trình
phần m ềm thực hiện các chức năng c ụ thể nòa đó hỗ trợ trực
tiếp cho sự thực thi các quy trình và/ho ặc thủ tục nghiệp vụ.

317
Các ứng dụng, cùng với dữ liệu và các thành ph ần cơ sở hạ tầng
như phần cứng, hệ điều hành và ph ần m ềm trung gian, t ạo nên các
thành phần công ngh ệ là m ột phần của m ột dịch vụ CNTT. Ứng
dụng, bản thân nó chỉ là m ột thành ph ần, m ặc dù là m ột thành ph ần
quan trọng của dịch vụ. Do đó, điều quan tr ọng là ứng dụng được
cung cấp phải thích hợp với các yêu cầu đã được thỏa thuận của
doanh nghi ệp. Tuy nhiên, có quá nhi ều tổ chức dành quá nhi ều thời
gian để tập trung vào các yêu c ầu chức năng c ủa dịch vụ và ứng
dụng m ới, m à không dành đủ thời gian dành cho vi ệc thiết kế các
yêu cầu quản lý và vận hành (các yêu c ầu phi chức năng) của dịch
vụ. Điều này có nghĩa là khi d ịch vụ đi vào hoạt động, nó đáp ứng
tất cả các chức năng c ần thiết, nhưng hoàn toàn thất bại trong việc
đáp ứng kỳ vọng của doanh nghi ệp và khách hàng v ề chất lượng và
hiệu suất, và do đó trở thành không sử dụng được.
Hai phương pháp tiếp cận thay thế là cần thiết để triển khai m ột
cách đầy đủ (quy trình) Quản lý Ứng dụng. Một phương pháp tiếp
cận sử dụng m ột Vòng đời Phát triển Dịch vụ m ở rộng (SDLC) đ ể h ỗ
trợ việc phát triển dịch vụ CNTT. SDLC là m ột phương tiếp cận c ó
hệ thống để giải quyết vấn đề và bao gồm các bước sau:
 Nghiên cứu tiền khả thi.

 Phân tích.
 Thiết kế.
 Kiểm nghiệm .
 Triển khai.
 Đánh giá.
 Bảo trì.
Phương pháp tiếp cận khác có m ột quan điểm toàn cầu về m ọi dịc h
vụ để đảm bảo tính có khả năng bảo trì được và có thể quản lý liên
tục của các ứng dụng:
 Mọi ứng dụng được m ô tả m ột cách nh ất quán, thông qua m ột

Danh m ục Ứng dụng được quản lý và duy trì để cho phép sự
liên kết với nhu c ầu kinh doanh năng đ ộng.
 Sự nhất quán trong phương pháp tiếp cận để việc phát triển
được thực thi thông qua m ột số các khuôn khổ ứng dụng và
các hình m ẫu thiết kế hạn chế và thông qua triết lý đầu tiên
"tái sử dụng".
 Các thành phần phần m ềm phổ biến, thường để đáp ứng các
yêu cầu quản lý và vận hành, được tạo ra hoặc có được ở cấp
độ 'tổ chức' và đư ợc sử dụng bởi các hệ thống riêng l ẻ khi
chúng được thiết kế và xây dựng.
5.3.1 Danh mục Ứng dụng

Đây đơn giản là m ột hồ sơ đầy đủ về m ọi ứng dụng trong m ột tổ
chức và năng động trong nội dung của nó.
T ên Ứn g d ụ ng Ch ủ s ở hữ u v ận h à nh Ch i p hí ph át tr i ể n m ớ i
CNT T

318
Mã đị n h d an h Ứ ng dụ n g Ch ủ s ở hữ u ph át tr i ể n Ch i p hí v ận h à nh hà n g
CNT T năm
Mô t ả Ứ ng dụ n g Các đ ầ u m ố i l iê n h ệ h ỗ Ch i p hí h ỗ tr ợ h ằ n g nă m
tr ợ
Q u y tr ì n h n gh i ệ p v ụ Các c ô n g n gh ệ c ơ s ở Ch i p hí b ả o trì hà n g
đư ợc h ỗ tr ợ dữ l i ệu năm
Các d ịc h v ụ C NT T đư ợc Các ứ ng d ụ ng ph ụ t hu ộc Các t h àn h p h ầ n đư ợc

hỗ tr ợ th u ê ng o à i
Nh à b ảo tr ợ đi ề u h àn h Các h ệ t hố n g CNT T Các đ ố i t ác th u ê ng o à i

đư ợc h ỗ tr ợ
Các k hu vự c đ ịa l ý đư ợc Các g i a o d i ệ n n gư ờ i Các c h ỉ s ố s ản x u ấ t

hỗ tr ợ dù n g
Mứ c đ ộ q ua n tr ọn g c ủ a K iế n tr úc CNT T , ba o L iê n k ế t O L A
v i ệc k i nh d o an h gồm s ơ đồ Mạ n g
L iê n k ế t S L A Các c ô n g n gh ệ ứ n g Các c h ỉ s ố hỗ tr ợ
dụ n g đư ợc s ử dụ n g
Ch ủ s ở hữ u do a nh S ố lư ợ ng ngư ờ i s ử
ng h i ệp dụ n g
Bảng 5.5 Ví d ụ về các thuộc tính c ủa Danh mục Ứng dụng
5.3.2 Việc liên kết Ứng dụng với Danh mục Dịch vụ
Một số tổ chức duy trì m ột Danh m ục Ứng dụng tách bi ệt với các
thuộc tính tách bi ệt, trong khi với các tổ chức khác thì Danh m ục
Ứng dụng được lưu trữ trong CMS, cùng với các m ối quan hệ tương
ứng. Các t ổ chức khác n ữa thì k ết hợp Danh m ục Ứng dụng cùng
với Danh m ục Dịch vụ. Mỗi tổ chức tự quyết định về chiến lược thích
hợp nhất cho nhu cầu của riêng m ình. Rõ ràng là nên có các m ối
quan hệ và liên k ết chặt chẽ giữa các ứng dụng và các d ịch vụ m à
chúng hỗ trợ và các thành phần cơ sở hạ tầng đã được sử dụng.
5.3.3 Các khuôn kh ổ ứng dụng

Khái niệm về khuôn khổ ứng dụng là m ột khái niệm rất m ạnh m ẽ.
Khuôn khổ ứng dụng bao gồm tất cả các khía c ạnh quản lý và vận
hành và thực sự cung cấp các giải pháp cho m ọi yêu cầu quản lý và
vận hành xoay quanh m ột ứng dụng.
Ngụ ý trong việc sử dụng các khuôn kh ổ ứng dụng là ý tưởng về tiêu
chuẩn hóa. Nếu m ột tổ chức sử dụng và phải duy trì m ột khuôn khổ
ứng dụng cho m ọi ứng dụng đơn lẻ thì sẽ không có được nhiều lợi
ích của việc sử dụng m ột khuôn khổ ứng dụng.
Một tổ chức m uốn phát triển và duy trì các khuôn kh ổ ứng dụng và
để đảm bảo các khuôn khổ ứng dụng phù h ợp với nhu c ầu của các
nhà phát triển ứng dụng thì họ phải đầu tư vào việc đó. Điều thiết

319
yếu là các kiến trúc khuôn khổ ứng dụng không đư ợc phát triển m ột
cách biệt lập m à có liên quan ch ặt chẽ và được tích hợp với tất cả
các khuôn khổ và hoạt động kiến trúc khác. T ất cả các Dịch vụ, Cơ
sở hạ tầng, Môi trường và Kiến trúc Dữ liệu phải được tích hợp m ột
cách chặt chẽ với Khuôn khổ và Kiến trúc Ứng dụng.
Các tiêu chuẩn và khuôn kh ổ kiến trúc, ứng dụng

Các hoạt động liên quan đến kiến trúc phải được hoạch định và
quản lý m ột cách tách biệt khỏi các dự án phần m ềm dựa trên-hệ
thống riêng lẻ. Một điều quan trọng nữa là các ho ạt động liên quan
đến kiến trúc phải được thực hiện vì lợi ích của nhiều hơn m ột ứng
dụng. Các nhà phát tri ển ứng dụng nên tập trung vào m ột ứng dụng
duy nhất, trong khi các nhà phát triển khuôn khổ ứng dụng nên t ập
trung vào nhiều hơn m ột ứng dụng và nói riêng vào các tính năng
chung của các ứng dụng đó.
Một thực tế phổ biến là phân biệt giữa các kiểu ứng dụng khác
nhau. Ví dụ: không ph ải m ọi ứng dụng đều có thể được xây dựng
trên nền tảng hệ điều hành Microsoft® W indows, đư ợc kết nối với
m áy chủ UNIX, sử dụng HTML, Java applet, JavaBeans và cơ s ở dữ
liệu quan hệ. Các loại ứng dụng khác nhau có th ể được coi là các
họ ứng dụng. Mọi ứng dụng trong cùng m ột họ đều dựa trên cùng
m ột khuôn khổ ứng dụng.
Khi sử dụng khái ni ệm khuôn khổ ứng dụng, bước đầu tiên của giai
đoạn thiết kế ứng dụng là xác định khuôn khổ ứng dụng thích hợp.
Nếu khuôn khổ ứng dụng đã hoàn thi ện, m ột số lượng lớn các quyết
định thiết kế sẽ được đưa ra. Nếu nó chưa hoàn thiện và không th ể
đáp ứng t ất cả các yêu c ầu về quản lý và vận hành trên khuôn khổ
ứng dụng hiện có, thì chi ến lược ưu tiên là thu th ập và phân tích các
yêu cầu không th ể xử lý được trong phiên b ản hiện hành của khuôn
khổ ứng dụng. Dựa trên các yêu c ầu ứng dụng, các yêu c ầu m ới có
thể được xác định cho khuôn khổ ứng dụng. Tiếp theo, khuôn kh ổ
ứng dụng có thể được điều chỉnh để nó có thể đáp ứng các yêu c ầu
của ứng dụng. Trên thực tế, toàn bộ họ ứng dụng tương ứng với
khuôn khổ ứng dụng sau đó có th ể sử dụng các tính năng m ới được
thêm vào hoặc thay đổi của khuôn khổ.
Việc phát triển và duy trì m ột khuôn kh ổ ứng dụng là m ột tác vụ phụ
thuộc và, giống như các ho ạt động thiết kế khác, nên được thực
hiện bởi những cá nhân có năng l ực và kinh nghi ệm . Ngoài ra,
khuôn khổ ứng dụng có thể có được từ các bên thứ ba.
5.3.4 Nhu cầu đối với các công cụ và kho lưu trữ CASE
Một khía cạnh quan trọng của sự liên k ết tổng thể đó là nhu c ầu liên
kết các ứng dụng với những cấu trúc hỗ trợ nền tảng của nó. Những
m ôi trường phát tri ển ứng dụng, theo truyền thống, có các công c ụ
Kỹ thuật Phần m ềm được Máy tính H ỗ trợ (Com puter Assisted/Aided
Software Engineering) cung c ấp phương ti ện để xác định các yêu
cầu, vẽ các sơ đồ thiết kế (tùy theo các tiêu chu ẩn m ô hình hóa c ụ
thể), hoặc thậm chí tạo ra các ứng dụng hoàn chỉnh, hoặc bộ khung

320
ứng dụng gần như hoàn chỉnh, gần như sẵn sàng để triển khai.
Những m ôi trư ờng này cũng cung c ấp m ột khu vực trung tâm để lưu
trữ và quản lý m ọi thành phần đã được tạo ra trong giai đo ạn phát
triển ứng dụng, còn được gọi chung là m ột kho lưu tr ữ. Chức năng
của kho lưu tr ữ bao gồm kiểm soát phiên b ản và kiểm tra tính nh ất
quán qua các m ô hình khác nhau. Phương pháp ti ếp cận hiện hành
là sử dụng các công c ụ m etacase đ ể lập m ô hình nh ững ngôn ng ữ
cụ thể của lĩnh vực và sử dụng chúng để làm cho ho ạt động CASE
được liên k ết hơn với nhu cầu của doanh nghiệp.
5.3.5 Thiết kế các ứng dụng cụ thể

Giai đoạn yêu c ầu của vòng đời đã được giải quyết trước đó trong
phần nói về kỹ thuật yêu cầu. Giai đoạn thiết kế là m ột trong những
giai đoạn quan trọng nhất trong vòng đời ứng dụng. Nó đảm bảo
rằng m ột ứng dụng được hình thành với khả năng vận hành và Quản
lý Ứng dụng trong tâm trí . Giai đoạn này lấy các đầu ra t ừ giai đoạn
yêu cầu và biến chúng thành đặc tả kỹ thuật sẽ được sử dụng để
phát triển ứng dụng.
Mục tiêu cho các thi ết kế phải đáp ứng các yêu c ầu của tổ chức.
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 cơ sở hạ tầng và m ôi trường m à trong đó ứng dụng vận hành.
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 vận hành. Những cân nhắc về kiến trúc đối với
ứng dụng (thiết kế của Kiến trúc Ứng dụng) và những cân nhắc về
kiến trúc đối với môi trường (thiết kế của Kiến trúc CNTT) có liên
quan m ột cách chặt chẽ và cần phải được liên k ết với nhau. Ki ến
trúc và thiết kế Ứng dụng không nên đư ợc xem xét m ột cách bi ệt lập
m à nên t ạo thành m ột thành phần tích hợp tổng thể của kiến trúc và
thiết kế dịch vụ.
Nói chung, trong giai đo ạn thiết kế, các m ô hình tương t ự sẽ được
đưa ra như đã được cung cấp trong giai đo ạn yêu cầu, nhưng trong
quá trình thiết kế, có nhiều chi tiết hơn nữa được thêm vào. Các m ô
hình m ới bao gồm các m ô hình ki ến trúc, nơi m à trong đó cách th ức
m à các thành ph ần chức năng khác nhau đư ợc ánh xạ tới các thành
phần vật lý (ví dụ: m áy tính đ ể bàn, m áy chủ, cơ sở dữ liệu và
m ạng) cần được xác định. Việc ánh xạ nói trên, cùng với tải ước
tính của hệ thống, sẽ cho phép xác đ ịnh cỡ của cơ sở hạ tầng cần
thiết.
Một khía c ạnh quan trọng khác c ủa m ô hình ki ến trúc là vi ệc nhúng

ứng dụng vào m ôi trường hiện hành. Những phần nào của cơ s ở hạ
tầng hiện tại sẽ được sử dụng để hỗ trợ các chức năng m ới cần
thiết? Các m áy ch ủ hoặc m ạng hiện tại có thể được sử dụng không?
Với tác động nào? Các chức năng bắt buộc có sẵn trong các ứng
dụng hiện tại có thể được sử dụng không? Các gói đang tồn tại có
cung cấp các chức năng cần thiết hay các chức năng nên được xây
dựng ngay từ đầu không?

321
Giai đoạn thiết kế xem xét tất cả các yêu cầu và bắt đầu tổ hợp
chúng thành m ột thiết kế ban đầu cho giải pháp. Làm điều này không
chỉ cung cấp cho các nhà phát tri ển cơ sở để bắt đầu làm việc: nó
còn có khả năng đưa ra các câu h ỏi cần được hỏi của khách
hàng/người sử dụng. Nếu có thể, các khuôn kh ổ ứng dụng nên được
áp dụng như m ột điểm khởi đầu.
Không phải lúc nào b ạn cũng có thể thấy trước m ọi khía cạnh của
thiết kế của giải pháp. Khi m ột giải pháp được phát triển, những
điều m ới sẽ được học về cách làm những điều đó và cả cách không
làm .
Chìa khóa là t ạo ra m ột thiết kế linh hoạt, để từ đó việc tiến hành

thay đổi không khi ến cho các nhà phát triển phải quay trở lại giai
đoạn đầu của giai đoạn thiết kế. Có m ột số phương pháp tiếp cận có
thể giảm thiểu khả năng xảy ra điều này, bao gồm :
 Thiết kế cho các yêu cầu quản lý và vận hành.

 Quản lý sự đánh đổi.
 Sử dụng các hướng dẫn thiết kế độc lập với ứng dụng; sử
dụng các khuôn kh ổ ứng dụng.
 Sử dụng quy trình thi ết kế có cấu trúc/danh sách kiểm tra khả
năng quản lý.
Thiết kế cho các yêu cầu về quản lý và vận hành có nghĩa là đưa
cho các yêu c ầu về quản lý và vận hành m ột mức độ quan trọng
tương t ự như đối với các yêu c ầu về chức năng, và bao gồm chúng
như m ột phần bắt buộc của giai đo ạn thiết kế. Điều này bao gồm
m ột số yêu cầu về quản lý và vận hành như tính sẵn sàng, công
suất, khả năng có thể bảo trì, độ tin cậy và bảo m ật. Bây giờ không
thể tưởng tượng được trong các d ự án phát tri ển ứng dụng hiện đại
rằng việc thiết kế giao diện người dùng (các yêu c ầu về khả năng sử
dụng) sẽ được bỏ qua như m ột hoạt động thiết kế chính. Tuy nhiên,
rất nhiều tổ chức đã bỏ qua hoặc quên đi khả năng quản lý. Chi ti ết
về các yêu cầu quản lý và vận hành c ần thiết được nêu trong SDP
và SAC trong Phụ lục A và B.
5.3.6 Quản lý sự đánh đổi

Việc quản lý những quyết định đánh đ ổi tập trung vào sự cân bằng
m ối quan hệ giữa tài nguyên, lịch trình dự án, và những chức năng
cần được đưa vào trong ứng dụng vì m ục đích chất lượng.
Khi các nhóm phát tri ển cố gắng hoàn tất sự cân bằng này, nó
thường phải trả giá bằng các yêu c ầu về quản lý và vận hành. Một
cách để tránh điều đó là đưa các yêu c ầu về quản lý và vận hành
vào các hướng dẫn thiết kế độc lập với ứng dụng - ví dụ, dưới dạng
m ột khuôn khổ ứng dụng. Khả năng vận hành và khả năng quản lý
m ột cách hiệu quả trở thành các thành ph ần tiêu chu ẩn của m ọi quy
trình thiết kế - ví dụ, dưới dạng m ột khuôn kh ổ ứng dụng - và được
nhúng vào thực tiễn hoạt động và văn hóa c ủa tổ chức phát triển.

322
5.3.7 Các đầu ra thiết kế điển hình
Sau đây là các ví d ụ về kết quả đầu ra từ m ột thiết kế ứng dụng tạo
thành m ột phần của Thiết kế Dịch vụ tổng thể:
 Thiết kế đầu vào và đầu ra, bao g ồm các biểu m ẫu và báo cáo.
 Thiết kế giao di ện người dùng có thể sử dụng được (tương tác
m áy tính/con người).
 Một m ô hình dữ liệu/đối tượng phù hợp.
 Một m ô hình quy trình hoặc luồng công việc.
 Thông số kỹ thuật chi tiết cho các quy trình c ập nhật và chỉ
đọc.
 Cơ chế để đạt được kiểm soát ki ểm toán, bảo m ật, bí m ật và
quyền riêng tư.
 Một thiết kế 'vật lý' cụ thể về công nghệ.
 Tập lệnh để kiểm tra thiết kế hệ thống.
 Giao diện và s ự phụ thuộc vào các ứng dụng khác.
Có các hướng dẫn và khuôn kh ổ có thể được thông qua đ ể xác định
và xác định đầu ra thi ết kế trong Quản lý ứng dụng, chẳng hạn như
Tích hợp m ô hình trưởng thành kh ả năng (CMMI).
5.3.8 Các hình mẫu thiết kế

Mẫu thiết kế là m ột giải pháp chung, có th ể lặp lại cho m ột vấn đề
thường xảy ra trong thiết kế phần m ềm . Các m ẫu thiết kế hướng đối
tượng thường hiển thị các m ối quan hệ và tương tác gi ữa các lớp
hoặc đối tượng, m à không chỉ định các lớp hoặc đối tượng ứng dụng
cuối cùng có liên quan. Các m ẫu thiết kế m ô tả cả m ột vấn đề và
giải pháp cho các v ấn đề chung gặp phải trong quá trình phát tri ể n
ứng dụng.
Một nguyên t ắc thiết kế quan tr ọng được sử dụng làm cơ sở cho m ột

số lượng lớn các m ẫu thiết kế được tìm thấy trong các tài li ệu gầ n
đây là m ối quan tâm tách bi ệt. Việc tách biệt các m ối quan tâm sẽ
dẫn đến việc các ứng dụng được chia thành các thành ph ần, với sự
gắn kết chặt chẽ và sự ghép nối tối thiểu giữa các thành ph ần. Ưu
điểm của ứng dụng như vậy là có thể thực hiện sửa đổi đối với các
thành phần riêng l ẻ m à ít hoặc không ảnh hưởng đến các thành
phần khác.
Trong các d ự án phát triển ứng dụng điển hình, hơn 70% n ỗ lực
được dành cho vi ệc thiết kế và phát tri ển các chức năng chung và
cho việc đáp ứng các yêu c ầu quản lý và vận hành. Đây là bởi vì m ỗi
ứng dụng riêng l ẻ cần cung c ấp m ột giải pháp cho các ch ức năng
chung như in ấn, xử lý lỗi và bảo m ật.
Giữa tất cả những điều này, Nhóm Quản lý Đối tượng – Object
Managem ent Group (OMG, www.om g.com ) đã xác đ ịnh m ột số lượng
lớn các dịch vụ cần thiết trong m ọi ứng dụng. Kiến trúc Quản lý Đố i
tượng – Object Managem ent Architecture (OMA) c ủa OMG phân biệt
m ột cách rõ ràng gi ữa các khía c ạnh chức năng, quản lý và vận
hành của m ột ứng dụng. Điều này xây dựng trên ý tưởng về việc

323
cung cấp m ột m ôi trường thời gian-thực thi cung cấp m ọi loại cơ sở
vật chất cho m ột ứng dụng.
Theo ý tưởng này, ứng dụng bao hàm các khía c ạnh chức năng, và
m ôi trường bao hàm mọi khía cạnh quản lý và vận hành. Các nhà
phát triển ứng dụng nên, theo đ ịnh nghĩa, t ập trung vào các khía
cạnh chức năng c ủa m ột dịch vụ, trong khi nh ững người khác tập
trung vào việc tạo ra m ột m ôi trường cung cấp các dịch vụ quản lý
và vận hành. Điều này có nghĩa là các nhà phát tri ển ứng dụng t ập
trung vào các yêu c ầu của doanh nghiệp, trong khi các nhà phát
triển kiến trúc hoặc các nhà phát tri ển khuôn kh ổ ứng dụng tập trung
vào các yêu c ầu của các nhà phát tri ển ứng dụng.
5.3.9 Phát triển các ứng dụng riêng lẻ

Khi giai đoạn thiết kế hoàn tất, nhóm phát tri ển ứng dụng sẽ nhận
lấy các thiết kế đã được đưa ra và chuy ển sang phát tri ển ứng dụng.
Các ứng dụng lẫn m ôi trường có liên quan đều sẵn sàng để triển
khai. Các thành ph ần ứng dụng được lập trình hoặc được m ua,
được tích hợp và ki ểm nghiệm .
Để đảm bảo rằng ứng dụng được phát triển với sự quản lý nằm ở
cốt lõi, nhóm phát tri ển cần tập trung vào vi ệc đảm bảo rằng giai
đoạn phát triển vẫn tiếp tục giải quyết m ột cách đúng đ ắn các khí a
cạnh quản lý và vận hành của thiết kế (ví dụ, khả năng đáp ứng, tính
sẵn sàng, tính b ảo m ật).
Hướng dẫn của giai đoạn phát triển bao gồm các chủ đề sau:
 Các quy ước lập trình nhất quán.

 Các hướng dẫn xây dựng ứng dụng độc lập.
 Kiểm nghiệm khả năng vận hành.
 Danh m ục kiểm tra sự quản lý đối với giai đoạn xây dựng.
 Sự tổ chức của các vai trò trong nhóm xây d ựng.
5.3.10 Các quy ước lập trình nhất quán

Nguyên nhân chính c ủa việc sử dụng một bộ thiết kế và quy ư ớc lập
trình nhất quán là để tiêu chuẩn hóa cấu trúc và ki ểu mã lập trình
của m ột ứng dụng để từ đó m ọi người đều có thể đọc, hiểu và quản
lý m ột cách dễ dàng quy trình phát tri ển ứng dụng. Thiết kế và các
quy ước lập trình tốt dẫn đến m ã nguồn chính xác, có thể đọc được
và rõ ràng, nhất quán với các tiêu chu ẩn quản lý và lập trình c ủa tổ
chức và càng tr ực quan để tuân theo càng t ốt. Việc thêm khả năng
vận hành ứng dụng vào quy ước này đảm bảo rằng m ọi ứng dụng đề
được xây dựng theo m ột cách đảm bảo được rằng chúng có thể
quản lý m ột cách đầy đủ trong suốt vòng đời của chúng.
Bản thân m ột quy ước lập trình có th ể trở thành m ột sự trợ giúp
đáng kể để quản lý các ứng dụng khi mà s ự nhất quán cho phép các
công cụ quản lý tương tác v ới ứng dụng theo cách th ức đã đư ợc
biết. Tốt hơn là đưa ra m ột bộ quy ước tối thiểu m à m ọi người sẽ
tuân theo thay vì t ạo ra m ột bộ quá m ức phức tạp bao gồm được m ọi

324
khía cạnh nhưng không đư ợc tuân theo ho ặc được sử dụng m ột
cách nhất quán trong toàn b ộ tổ chức.
5.3.11 Các biểu mẫu và vi ệc tạo mã l ập trình

Một số các công d ụ phát triển cung cấp các biểu m ẫu đa dạng để tạo
ra các thành ph ần ứng dụng phổ biến. Thay vì t ạo ra m ọi m ảnh củ a
m ột ứng dụng ngay từ đầu, các nhà phát tri ển có thể tùy biến m ột
biểu m ẫu đang có sẵn. Họ cũng có th ể tái sử dụng các thành ph ần
tùy biến trong nhi ều ứng dụng bằng cách tạo ra các biểu m ẫu của
riêng họ. Các công cụ phát triển khác sẽ tạo ra m ột lượng lớn các
m ẩu m ã nguồn (khung xương) dựa trên các m ô hình thi ết kế và các
quy ước lập trình. Mã nguồn có thể bao gồm các ‘m óc khóa’ t ại các
m ẩu m ã nguồn cần được thêm vào.
Về m ặt này, các bi ểu m ẫu và khuôn khổ ứng dụng nên được xem

như là các tài s ản CNTT. Những tài s ản này không ch ỉ hướng dẫn
cho việc phát triển các ứng dụng m à còn kết hợp các bài học ứng
dụng hoặc nguồn vốn tri thức từ những nỗ lực phát triển ứng dụng
trước đây. Các thành ph ần được thiết kế trong các giải pháp càng
tiêu chuẩn thì các ứng dụng có thể được phát triển càng nhanh hơn,
với chi phí thấp hơn về dài hạn (không bỏ qua thực tế là việc phát
triển các biểu m ẫu, tạo ra m ã lập trình và các khuôn kh ổ ứng dụng
đòi hỏi khoản đầu tư đáng k ể).
5.3.12 Đo đạc ứng dụng được nhúng

Giai đoạn phát tri ển đề cập đến việc kết hợp việc đo đạc vào k ết cấu
của ứng dụng. Các nhà phát tri ển cần m ột cách nhất quán để cung
cấp công cụ cho trình điều khiển ứng dụng/các thành phần phần
m ềm trung gian (ví dụ, trình điều khiển cơ sở dữ liệu) và các ứng
dụng hiệu quả và dễ triển khai. Để giữ cho các nhà phát tri ển ứng
dụng luôn sáng t ạo lại bánh đà với mọi ứng dụng m ới mà họ phát
triển, ngành công nghi ệp m áy tính cung c ấp các phương pháp và
công nghệ để đơn giản hóa và tạo điều kiện cho quy trình đo đạc.
Chúng bao gồm :
 Application Response Managem ent (ARMS).

 IBM Application Managem ent Specification (AMS).
 Comm on Inform ation Model (CMI) và W eb -based Enterprise
Managem ent (W BEM) t ừ Distributed Managem ent Task Force
(DMTF).
 Destop Managem ent Instrum enta tion (DMI).
 Microsoft W indows© Managem ent Instrum entation (W MI).
 Java Managem ent Extension (JMX).
Lưu ý : Đoạn này sẽ giữ nguyên không ch uy ển sang ti ếng Vi ệt để đả m bảo

tính ch ính xác trong tên g ọi của các phươn g pháp.
Mỗi m ột công ngh ệ cung c ấp m ột m ô hình nhất quán và giàu tính m ô

tả của các khía c ạnh cấu hình, tr ạng thái và vận hành c ủa các ứng
dụng và dịch vụ. Chúng được cung cấp thông qua vi ệc lập trình các
Giao diện Chương trình Ứng dụng – Application Program Interfaces

325
(APIs) m à các nhà phát tri ển kết hợp vào trong m ột ứng dụng,
thường thông qua vi ệc sử dụng các biểu m ẫu lập trình tiêu chu ẩn.
Điều quan trọng là đảm bảo rằng m ọi ứng dụng được xây dựng tuân
theo m ột số m ức độ tuân thủ đối với đo đạc ứng dụng. Những cách
để thực hiện điều này bao g ồm :
 Cung cấp quyền truy cập vào dữ liệu quản lý thông qua API đo
đạc.
 Công bố thông tin quản lý cho các h ệ thống quản lý khác, vẫn
thông qua API đo đ ạc.
 Cung cấp xử lý sự kiện ứng dụng.
 Cung cấp m ột m óc khóa ch ẩn đoán.
5.3.13 Các móc khóa ch ẩn đoán

Các m óc khóa chẩn đoán có giá tr ị lớn nhất trong quá trình ki ểm
nghiệm và khi m ột lỗi đã được khám phá trong d ịch vụ đang hoạt
động. Các m óc khóa ch ẩn đoán chủ yếu cung cấp những thông tin
cần thiết để giải quyết vấn đề và lỗi ứng dụng m ột cách nhanh
chóng và khôi ph ục lại dịch vụ. Chúng cũng có th ể được sử dụng đ ể
cung cấp thước đo và thông tin qu ản lý của ứng dụng.
Ba thể loại chủ yếu là:
 Thông tin ở m ức hệ thống được cung c ấp bởi hệ điều hành và

phần cứng.
 Thông tin ở m ức phần m ềm được cung cấp bởi cơ sở hạ tầng
ứng dụng.
 Thông tin tùy ch ỉnh được cung c ấp bởi ứng dụng
 Thông tin về hiệu suất của dịch vụ và thành phần.
5.3.14 Các đầu ra dịch vụ chính từ giai đoạn phát tri ển

Đầu ra chính từ giai đoạn phát triển là:
 Các t ập lệnh được chạy trước hoặc sau triển khai.

 Các t ập lệnh để khởi động hoặc dừng dịch vụ.
 Các t ập lệnh kiểm tra các cấu hình phần cứng và ph ần mềm
của m ôi trường m ục tiêu trước triển khai hoặc cài đặt.
 Đặc tả kỹ thuật của các chỉ số và sự kiện có thể được truy
xuất từ ứng dụng và chỉ ra tình trạng hiệu suất của ứng dụng.
 Các t ập lệnh được tùy chỉnh, khởi nguồn từ nhân viên Vận
hành Dịch vụ để quản lý ứng dụng (bao gồm xử lý các nâng
cấp ứng dụng).
 Đặc tả kỹ thuật của thông tin kiểm soát truy cập đối với tài
nguyên hệ thống được sử dụng bởi ứng dụng.
 Đặc tả kỹ thuật của các chi tiết cần thiết để theo dõi các giao
dịch chính c ủa m ột ứng dụng.
 Các đích nh ắm m ục tiêu và yêu c ầu SLA.
 Các yêu c ầu và tài liệu vận hành.
 Các yêu c ầu hỗ trợ.
 Khôi phục và sao lưu ứng dụng.
 Các yêu c ầu và đích nh ắm mục tiêu IT SM khác.

326
6 Việc tổ chức đối với Thi ết kế Dịch vụ
Để Thiết kế Dịch vụ thành công, đi ều thiết yếu là xác định các vai
trò và trách nhi ệm trong vi ệc tổ chức các ho ạt động đa d ạng khác
nhau.
Khi thiết kế m ột dịch vụ hoặc m ột quy trình, đi ều bắt buộc là m ọi vai

trò được xác định m ột cách rõ ràng. Một nhãn hiệu của m ột tổ chức
hoạt động hiệu quả là khả năng đưa ra các quy ết định đúng đắn m ột
cách nhanh chóng và th ực thi chúng m ột cách hiệu quả. Cho dù
quyết định là liên quan đ ến m ột lựa chọn chiến lược hoặc m ột hoạt
động quan trọng, s ự rõ ràng về việc ai sẽ nhập số liệu, ai quyết định
và ai thực hiện hành động sẽ cho phép công ty ti ến lên phía trước
m ột cách nhanh chóng.
Mô hình RACI s ẽ có ích trong việc cho phép các quy ết định được
đưa ra m ột cách nhanh chóng và t ự tin. RACI là m ột từ viết tắt của
bốn vai trò về:
 Trách nhiệm – người hoặc cá nhân ch ịu trách nhiệm cho việc

hoàn thành công vi ệc.
 Trách nhiệm gi ải trình – chỉ m ột người hoặc m ột cá nhân có
thể chịu trách nhi ệm cho m ỗi tác vụ.
 Được tham kh ảo – người được tham khảo ý kiến và những ai
m à có ý kiến được tìm kiếm .
 Được thông báo – người m à được cập nhật về tiến trình.
Đôi khi m ột phiên b ản m ở rộng của RACI còn được gọi là RACI -VS,
với thêm hai vai trò đư ợc thêm vào như sau:
 Xác minh – người hoặc nhóm kiểm tra xem li ệu các tiêu chí
chấp thuận có được đáp ứng không.
 Ký tên – người phê duyệt quyết định V và cho phép s ản phẩm
xuất xưởng. Đây cũng có thể là người có vai trò A nói trên.
Một biến thể thứ ba của m ô RACI là RASCI, khi S đ ại diện cho Hỗ
trợ. Ví dụ, vai trò này cung c ấp những tài nguyên bổ sung để tiến
hành công vi ệc, hoặc đóng vai trò h ỗ trợ trong quá trình tri ển khai.
Điều này có thể sẽ có ích cho vi ệc triển khai dịch vụ CNTT.
G iá m đốc Nhà Q u ản l ý Nhà Q u ản l ý Nhà Q u ản l ý Nhà Q u ả n l ý

Q uản l ý D ị ch Dị ch v ụ V ấn đ ề Bảo m ật T hu mu a
vụ
Ho ạt độ n g 1 AR C I I C
Ho ạt độ n g 2 A R C C C
Ho ạt độ n g 3 I A R I C
Ho ạt độ n g 4 I A R I
Ho ạt độ n g 5 I I A C I
Bảng 6.1 Ví dụ về ma trận RACI

327
Sơ đồ RACI trong B ảng 6.1 cho thấy cấu trúc và sức m ạnh của việc
m ô hình hóa RACI cùng với các hoạt động được liệt kê trong cột
phía bên trái bao g ồm những hành động cần được thực hiện và các
quyết định phải được đưa ra. Ở dòng trên cùng, sơ đồ liệt kê các vai
trò chức năng ch ịu trách nhiệm thực hiện sáng kiến hoặc đóng m ột
phần vai trò trong vi ệc đưa ra quyết định.
Bất kể là RACI hay là vài công c ụ hoặc m ô hình nào đư ợc sử dụng,

điều quan trọng là không để việc chỉ định trách nhiệm ngẫu nhiên
hoặc để đến tận những phút cuối cùng m ới đưa ra quyết định. Các
xung đột có thể tránh được và các quyết định có thể được đưa ra
m ột cách nhanh chóng n ếu các vai trò đã đư ợc phân bổ trước.
Để xây dựng sơ đồ RACI, việc tuân theo những bước sau đây là
cần thiết :
 Xác định các ho ạt động/quy trình.

 Xác định/định nghĩa các vai trò ch ức năng.
 Tiến hành cu ộc họp và chỉ định m ã RACI.
 Xác định những lỗ hổng hoặc sự chồng chéo – ví dụ, khi có
hai R hoặc không có R nào (xem thêm phân tích dư ới đây).
 Phân phối sơ đồ và kết hợp phản hồi.
 Đảm bảo rằng các phân bổ đang được tuân thủ.
6.1 Phát triển tổ chức

 Có quá nhiều A: Trách nhi ệm có được tách biệt m ột cách rõ
ràng không? Nên có m ột ai đó ch ịu trách nhiêm cho m ột vài
trong số các hoạt động? Điều này có đang gây ra s ự tắc nghẽn
cổ chai trong m ột số lĩnh vực làm chậm trễ việc ra quyết định?
 Có quá nhiều R: Điều này có là quá nhi ều đối với m ột chức
năng không?
 Không có kho ảng trống nào: Vai trò này có c ần phải tham gia
vào nhiều tác vụ không?
 Và, loại hoặc m ức độ tham gia có phù h ợp với trình đ ộ của vai
trò này không?
6.2 Phân tích ho ạt động

 Nhiều hơn m ột A: chỉ m ột vai trò có thể chịu trách nhiệm .
 Không có A nào: ít nh ất m ột A phải được chỉ định cho m ỗi hoạt
động.
 Nhiều hơn m ột R: có quá nhiều vai trò ch ịu trách nhiệm
thường có nghĩa là không ai ch ịu trách nhi ệm . Trách nhiệm có
thể được chia s ẻ nhưng chỉ khi các vai trò đã rõ ràng.
 Không có R nà o: ít nhất m ột người phải chịu trách nhiệm .
 Có quá nhiều C: Có m ột yêu cầu nào về tham khảo ý kiến vớ i
nhiều vai trò như v ậy không? Nh ững lợi ích là gì và thời gian
bổ sung có thể hợp lý không?
 Không có C và I nào: Các kên truy ền thông có m ở để cho phép
m ọi người và phòng ban trao đ ổi và c ập nhật cho nhau không?

328
6.3 Các k ỹ năng và thuộc tính
Mọi vai trò cụ thể trong Quản lý Dịch vụ theo ITIL đều đòi hỏi các k ỹ
năng, tính cách và năng l ực cụ thể từ những người tham gia đ ể cho
phép họ hoạt động m ột cách hiệu quả và năng su ất. Tuy nhiên, dù
cho vai trò là gì, điều bắt buột là người thực hiện vai trò đó ph ải có
những thuộc tính sau:
 Nhận thức về các ưu tiên, m ực tiêu c ủa doanh nghiệp và định

hướng kinh doanh.
 Nhận thức về vai trò của CNTT trong vi ệc cho phép đáp ứng
các m ục tiêu c ủa doanh nghi ệp.
 Các kỹ năng phục vụ khách hàng.
 Nhận thức về những gì CNTT có th ể cung cấp cho doanh
nghiệp, bao gồm những năng lực m ới nhất.
 Năng lực, kiến thức và những thông tin c ần thiết để hoàn
thành vai trò c ủa họ.
 Khả năng sử dụng, hiểu rõ và diễn dịch thực tiễn tốt nhất, các
chính sách và th ủ tục để đảm bảo tính tuân th ủ.
Dưới đây là m ột số ví dụ về các thuộc tính cần thiết cho rất nhiều
vai trò, tùy thu ộc vào tổ chức và vai trò cụ thể:
 Kỹ năng quản lý – từ cả góc độ quản lý con người và t ừ việc

kiểm soát tổng thể quá trình.
 Kỹ năng hội họp – để tổ chức, chủ trì, lập tài liệu và đảm bảo
rằng các ho ạt động được tuân theo.
 Tru yền thông – m ột yếu tố quan trọng của m ọi vai trò là nâng
cao nhận thức về các quy trình có s ẵn để đảm bảo tín nhiệm
và tuân thủ. Khả năng giao ti ếp ở m ọi cấp độ trong tổ chức là
điều bắt buộc.
 Phát biểu rõ ràng – cả viết, đối với các báo cáo, v.v… và nói.
 Thương th ảo – được yêu cầu đối với vài khía c ạnh, chẳng
hạn như thu m ua và hợp đồng.
 Phân tích – để phân tích các ch ỉ số được đưa ra từ các hoạt
động.
Những thông tin thêm về các kỹ năng và năng lực của các vai trò đó
có thể được tìm thấy trong Khuôn kh ổ các Kỹ năng cho Thời đại
Thông tin – Skills Fram ework for the Inform ation Age (SFIA –
www.sfia.org.uk ).
6.4 Vai trò và trách nhi ệm

Những phần dưới đây ghi nh ận lại thành văn b ản những vai trò và
trách nhiệm của các vai trò khác nhau trong Thi ết kế Dịch vụ. Trong
m ột số tổ chức, đây có th ể là m ột cá nhân toàn-thời gian, và trong
m ột số tổ chức khác l ại có thể là m ột vài người, hoặc có thể là m ột
vai trò bán th ời gian. Trong các t ổ chức nhỏ hơn, rất nhiều vai trò có
thể được đảm nhận bởi m ột người duy nhất. Điều này s ẽ tùy thuộc
vào quy m ô và s ự biến động của tổ chức. Các vai trò hoặc chức
danh công việc thường khác nhau giữa các tổ chức. Tuy nhiên, đi ều
quan trọng là các vai trò, trách nhi ệm , quy trình, ph ụ thuộc và tương

329
tác được xác định và định phạm vi m ột cách rõ ràng cho mỗi tổ chức
riêng lẻ (Xem Phụ lục C để biết thêm về ví dụ về biểu mẫu tài liệu
quy trình).
Dưới đây là những m inh họa về các hoạt động chủ yếu trong m ỗi vai
trò Thiết kế Dịch vụ.
6.4.1 Chủ sở hữu quy trình

Một Chủ sở hữu Quy trình ch ịu trách nhi ệm cho việc đảm bảo rằng
quy trình của họ đang được hoàn thành tương xứng với quy trình đã
được thống nhất và lập thành văn bản và đang đáp ứng được m ục
tiêu của định nghĩa quy trình. Điều này bao gồm các tác vụ như:
 Tài liệu hóa và công khai hóa quy trình.

 Xác định các Chỉ số Hiệu suất Quan tr ọng (KPIs) để đánh giá
tính hiệu quả và hiệu suất của quy trình.
 Xem xét các KPI và ti ến hành hoạt động cần thiết theo k ết quả
phân tích.
 Hỗ trợ và chịu trách nhiệm sau cùng cho thiết kế quy trình.
 Cải thiện hiệu quả và hiệu suất của quy trình.
 Xem xét và b ất kỳ biện pháp tăng cường được đề xuất đối với
quy trình.
 Cung cấp đầu vào cho K ế hoạch Cải thiện Dịch vụ liên tục.
 Giải quyết bất kỳ vấn đề nào đối với quy trình đang ho ạt động.
 Đảm bảo m ọi nhân viên có liên quan đư ợc đào t ạo cần thiết về
quy trình và nh ận thức được vai trò của họ trong quy trình.
 Đảm bảo rằng quy trình, các vai trò, trách nhi ệm và tài li ệu
thường xuyên được kiểm tra và đánh giá.
 Tương tác với quản lý tuyến, đảm bảo rằng quy trình nhận
được nguồn nhân l ực cần thiết. (Quản lý tuyến và các ch ủ sở
hữu quy trình có các tác vụ bổ sung cho nhau – họ cần phải
làm việc cùng nhau để đảm bảo tính hi ệu quả và hiệu suất của
các quy trình. Thư ờng thì đây là nhi ệm vụ của quản lý tuyến
để đảm bảo đào t ạo cần thiết cho nhân viên).
6.4.2 Nhà Quản lý Thi ết kế Dịch vụ

Vai trò và trách nh iệm chủ yếu của Nhà Quản lý Thiết kế Dịch vụ
được bao hàm xuyên su ốt trong ấn phẩm này và họ chịu trách nhi ệm
cho việc phối hợp và triển khai t ổng thể các thiết kế giải pháp có
chất lượng đối với các dịch vụ và quy trình.
Những trách nhi ệm của so với và tr ên cả những gì của quản lý tuyến

của m ọi cá nhân tham gia vào các vai trò Thi ết kế Dịch vụ bao gồm :
 Thực hiện các Chiến lược Dịch vụ tổng thể và đảm bảo rằng
chúng được phản ảnh trong th ực tiễn Thiết kế Dịch v ụ và
những Thiết kế Dịch vụ được đưa ra để đáp ứng và hoàn
thành các yêu c ầu doanh nghi ệp đã được lập thành văn bản.
 Thiết kế các khía c ạnh chức năng c ủa các dịch vụ cũng như
cơ sở hạ tầng, m ôi trường ứng dụng và quản lý dữ liệu.

330
 Đưa ra các thi ết kế có chất lượng, bảo m ật và có kh ả năng
phục hồi cho c ác dịch vụ, kiến trúc hạ tầng, quy trình ho ặc hệ
thống đo lường, m ới hoặc được cải thiện, đáp ứng được m ọi
yêu cầu CNTT của tổ chức trong hi ện tại và tương lai đã đư ợc
thống nhât.
 Đưa ra và duy trì m ọi tài liệu thiết kế, bao gồm các thiết kế, kế
hoạch, kiến trúc và chính sách.
 Đưa ra và duy trì m ọi SDP cần thiết.
 Đo lường tính hi ệu quả và hiệu suất của quy trình Thi ết kế
Dịch vụ.
6.4.3 Nhà hoạch định CNTT

Một nhà Hoạch định CNTT chịu trách nhi ệm cho việc đưa ra và duy
trì các kế hoạch CNTT. Mục tiêu chủ yếu của vai trò này đư ợc liệt kê
như dưới đây:
 Phát triển các k ế hoạch CNTT đáp ứng và tiếp tục đáp ứng
các yêu cầu về CNTT của doanh nghi ệp.
 Phối hợp, đo lường và xem xét ti ến trình tri ển khai m ọi chiến
lược và kế hoạch CNTT.
 Đưa ra và duy trì m ột bộ tổng thể các tiêu chu ẩn, chính sách,
kế hoạch và chi ến lược CNTT, bao trùm m ọi khía cạnh CNTT
cần thiết để hỗ trợ cho m ột chiến lược kinh doanh c ủa tổ
chức. Việc hoạch định CNTT bao g ồm việc tham gia vào vi ệc
tạo ra các SLA và ho ạch định m ọi khía cạnh của cơ sở hạ tầng
– cả nội bộ lẫn bên ngoài, công khai ho ặc tư nhân, Internet và
Intranet – cần thiết để đảm bảo rằng việc cung cấp các dịch vụ
CNTT thỏa m ãn đư ợc doanh nghi ệp.
 Chịu trách nhiệm về m ọi khía cạnh về việc triển khai các tiêu
chuẩn CNTT, chính sách và chi ến lược cho CNTT nói chung và
cho các d ự án quan trọng hoặc các ứng dụng chiến lược m ới
quan trọng.
 Đề xuất chính sách đ ể sử dụng hiệu quả CNTT trong toàn bộ
tổ chức và làm vi ệc với các Nhà thi ết kế CNTT để đảm bảo
rằng các kế hoạch và chiến lược t ổng thể được phát tri ển cùng
với thiết kế CNTT cho m ọi lĩnh vực CNTT.
 Xem xét chi phí CNTT so v ới ngân sách và các phát tri ển mới,
đưa ra các đ ề xuất thay đổi các k ế hoạch và chiến lược CNTT
khi thích hợp, kết hợp với Quản lý Tài chính.
 Chịu toàn bộ trách nhiệm về quản lý, hoạch định và điều phối
các hệ thống và dịch vụ CNTT, bao g ồm điều tra, phân tích,
đặc tả kỹ thuật, thiết kế, phát triển, thử nghiệm , bảo trì, nâng
cấp, chuyển tiếp và vận hành. Điều thiết yếu là trong khi thực
hiện các hoạt động này, m ọi quy trình nghiệp vụ, Quản lý
CNTT và Qu ản lý Dịch vụ phải được cập nhật cùng với tiến đ ộ
của các dự án.
 Thu thập và đánh giá các đ ề xuất từ các nhà cung cấp thiết bị,
phần m ềm , dịch vụ truyền dẫn và các dịch vụ khác, đảm bảo
rằng m ọi yêu c ầu của doanh nghi ệp và CNTT được đáp ứng.

331
 Xác định các yếu tố ảnh hưởng nội bộ và bên ngoài, dự báo
nhu cầu trong tương lai và thiết lập các kế hoạch sử dụng hiệ u
quả CNTT trong t ổ chức.
 Bảo trợ và giám sát việc nghiên cứu, phát tri ển và hoạch định
dài hạn cho vi ệc cung c ấp và sử dụng các kiến trúc, sản phẩm
và dịch vụ CNTT
 Đánh giá hi ệu suất CNTT so với tất cả các lĩnh vực khác và
bắt đầu bất kỳ cải tiến nào trong t ổ chức để đảm bảo rằng các
m ức dịch vụ và đích nhắm m ục tiêu tiếp tục được đáp ứng
trong t ất cả các lĩnh vực.
 Chịu trách nhiệm cuối cùng cho việc sắp xếp thứ tự ưu tiên và
lên lịch trình triển khai các dịch vụ mới hoặc được thay đổi
trong CNTT.
 Làm việc với quản lý cấp cao và các chuyên gia và nhà ho ạch
định cấp cao khác trong vi ệc xây dựng kế hoạch và đưa ra các
quyết định m ua sắm có thể được áp dụng cho tất cả các lĩnh
vực CNTT.
 Nhận ra các định hướng kinh doanh chủ yếu và những lĩnh vực
kinh doanh cần thiết nhưng không được hỗ trợ đầy đủ bởi các
dịch vụ CNTT hiện tại và đã được lên kế hoạch, phát tri ển các
kế hoạch và đáp ứng CNTT cho các yêu c ầu kinh doanh.
 Xác định các ứng dụng, dịch vụ và sản phẩm phù hợp, cùng
với m ôi trư ờng của chúng, để đáp ứng nhu c ầu kinh doanh
trong khung th ời gian hoạch định cần thiết.
 Xây dựng kế hoạch ban đầu cho vi ệc triển khai các dịch vụ
CNTT, ứng dụng và hỗ trợ cơ sở hạ tầng m ới đã được cấp
phép, xác định các ràng bu ộc về ngân sách, k ỹ thuật và nhân
sự, đồng thời liệt kê rõ ràng chi phí và l ợi ích được kỳ vọng.
 Giám sát các k ế hoạch CNTT hi ện có liên quan đ ến nhu c ầu
kinh doanh và chi ến lược CNTT để xác định các cơ hội để cải
tiến quy trình kinh doanh thông qua vi ệc sử dụng công ngh ệ
mới và xác đ ịnh các r ủi ro không lư ờng trước được đối với
việc đạt được lợi ích kinh doanh d ự báo.
 Tìm hiểu về các lựa chọn chính để cung cấp các dịch vụ CNTT
m ột cách hi ệu quả và hiệu suất và đề xuất các giải pháp sáng
tạo m ới, dựa trên các phương pháp ti ếp cận m ới đối với các
quy trình, sự cung cấp, tuyển dụng và duy trì cũng như các
hợp đồng cung c ấp toàn c ầu.
 Đưa ra các nghiên c ứu, m ô hình kinh doanh, m ô hình CNTT,
trường hợp kinh doanh, SoR và ITT khả thi cho các h ệ thống
CNTT m ới được đề xuất, xác định tác động kinh doanh, xác
suất đáp ứng nhu c ầu kinh doanh, lợi ích kinh doanh được dự
kiến và rủi ro và hậu quả của thất bại.
 Giám sát và đi ều phối chương trình triển khai những dự án
CNTT và những thay đổi theo k ế hoạch, thực hiện các hành
động tương xứng để xác định và khắc phục các vấn đề và giải
quyết xung đột.
 Tiến hành Đánh giá Sau Triển khai (PIR) kết hợp với Quản lý
Thay đổi đối với những hệ thống thông tin đã được giới thiệu
để theo đuổi các kế hoạch, để đánh giá m ức độ m à các lợi ích
kinh doanh kỳ vọng đã được hiện thực hóa.

332
 Liên lạc với các nhóm và quy trình Chi ến lược, Chuyển tiếp và
Vận hành để lập kế hoạch cho những nhu cầu tức thời và
trong tương lai c ủa họ.
 Cung cấp lời khuyên và hướng dẫn có đủ thẩm quyền về các
tiêu chuẩn, quy định, giao th ức và biểu thuế có liên quan,
trong nước và quốc tế.
 Lập thành tài li ệu m ọi công việc bằng cách sử dụng các tiêu
chuẩn, phương pháp và công c ụ cần thiết.
 Đảm bảo rằng t ất cả các quy trình, vai trò, trách nhi ệm và tài
liệu hoạch định CNTT thường xuyên được xem xét và đánh giá
về tính hiệu quả, hiệu lực và tuân thủ.
 Duy trì kiến thức tổng thể đầy đủ về m ọi năng lực của sản
phẩm CNTT và các khuôn kh ổ kỹ thuật m à chúng ho ạt động
trong đó.
 Khi cần thiết, đánh giá các thay đ ổi về sự phù hợp của chúng
với các chiến lược thiết kế, bao gồm cả việc tham dự các cuộc
họp CAB nếu thích hợp.
6.4.4 Nhà thi ết kế/Kiến trúc sư CNTT

Một Nhà Thiết kế/Kiến trúc sư CNTT ch ịu trách nhiệm về sự phối
hợp và thiết kế tổng thể của công nghệ cần thiết. Thường thì các
Nhà Thiết kế và Kiến trúc sư trong các t ổ chức lớn sẽ chuyên m ôn
hóa về m ột trong năm khía c ạnh cua thi ết kế (xem hành động 3).
Tuy nhiên, m ột phương pháp ti ếp cận được tích hợp luôn luôn nên
được áp dụng, do đó, các Nhà Thi ết kế/Kiến trúc sư cần làm việc
cùng nhau theo m ột phương pháp tiếp cận và khuôn khổ chính thức
để đảm bảo các thi ết kết nhất quán và phù hợp được đưa ra. Trong
các t ổ chức nhỏ hơn, m ột vài hoặc m ọi vai trò thường được kết hợp
lại, và điều này có ít vấn đề hơn, m ặc dù m ột phương pháp ti ếp cận
chính thức vẫn nên được sử dụng. Bất cứ khi nào các thiêt k ế đã
được đưa ra, chúng nên luôn luôn áp d ụng m ột phương pháp ti ếp
cận được tích hợp, bao trùm m ọi lĩnh vực, và nên được chấp thuận
và ký xác nh ận bởi m ọi lĩnh vực. Mọi nhà thiết kế cần phải hiểu về
cách m à các kiến trúc, chi ến lược, thiết kế và kế hoạch phù hợp với
nhau và m ọi khía c ạnh chính của thiết kế.
Nhà thiết kế/Kiến trúc sư nên đưa ra m ột bản đồ quy trình chi tiết
ghi nhận thành văn bản m ọi quy trình và các tương tác cao c ấp của
chúng. Điều này đảm bảo rằng cấu trúc tổng thể không cần phải quá
phức tạp, rằng các tương tác trung tâm c ủa quy trình là m ột phần
của thiết kế, và cung cấp m ột cái nhìn t ổng quan cho m ọi người về
cách m à khách hàng và các bên liên quan khác tương tác v ới các
quy trình như th ế nào.
Để hoàn thành vai trò Nhà Thi ết kế hoặc Kiến trúc sư, điều cần thiết
đối với nhân viên là ph ải có kiến thức và kinh nghi ệm thực tiễn tốt
về lý thuyết và hoạch định thiết kế, bao gồm Quản lý Chương trình,
Dự án và Dịch vụ, cũng như là các phương pháp và nguyên t ắc. Mục
tiêu chủ yếu của Nhà Thiết kế/Kiến trúc sư CNTT là:

333
 Đưa ra và xem xét các thi ết kế của m ọi dịch vụ, SLA, OLA và
hợp đồng m ới hoặc đã được thay đổi.
 Tạo ra m ột bản đồ quy trình c ủa m ọi quy trình và các tương
tác cấp cao c ủa chúng, để đảm bảo sự tích hợp, tính nhất
quán và liên t ục trên tất cả các quy trình.
 Thiết kế các kiến trúc công nghệ an toàn và có kh ả năng phục
hồi đáp ứng m ọi yêu cầu CNTT hiện tại và được dự đoán trong
tương lai c ủa tổ chức.
 Đảm bảo rằng thiết kế của m ọi quy trình, vai trò, trách nhi ệm
và tài liệu được xem xét và đánh giá thư ờng xuyên về hiệu
quả, hiệu lực và sự tuân thủ.
 Thiết kế m ột Danh m ục Dịch vụ tương xứng và phù hợp, hỗ trợ
cho m ọi hoạt động trong Vòng đời Dịch vụ hoàn chỉnh.
 Thiết kế các hệ thống và k ỹ thuật đo lường để hỗ trợ cho việc
cải tiến liên tục việc cung c ấp dịch vụ và m ọi quy trình h ỗ trợ
khác.
 Đưa ra và cập nhật tất cả tài liệu thiết kế, kiến trúc, chính
sách và đặc tả kỹ thuật CNTT.
 Đưa ra và duy trì m ọi khía cạnh của đặc tả CNTT, bao gồm
thiết kế tổng thể, các kiến trúc, c ấu trúc liên k ết topology và
cấu hình c ủa cơ sở hạ tầng, m ôi trường, ứng dụng và d ữ liệu
cũng như tài li ệu thiết kế của m ọi hệ thống CNTT. Đi ều này
không chỉ bao gồm công nghệ m à còn bao g ồm hệ thống quản
lý, quy trình, lu ồng thông tin và các d ịch vụ bên ngoài.
 Đề xuất các giải pháp CNTT ch ủ động, sáng tạo để cải tiến
thiết kế và vận hành CNTT b ất cứ khi nào và b ất cứ khi nào có
thể.
 Diễn dịch các thiết kế logic thành các thi ết kế vật lý, có tính
đến các yêu c ầu của doanh nghiệp, môi trường m ục tiêu, các
quy trình, yêu c ầu về hiệu suất, các hệ thống và dịch vụ hiện
có cũng như b ất kỳ khía cạnh tiềm năng nào liên quan đ ến an
toàn.
 Tạo ra và duy trì các chính sách, tri ết lý và tiêu chí thi ết kế
CNTT, bao g ồm m ọi lĩnh vực bao gồm kết nối, công suất, giao
diện, bảo m ật, khả năng phục hồi, khôi phục, truy c ập và truy
cập từ xa, đồng thời đảm bảo rằng mọi dịch vụ m ới đều đáp
ứng các m ức dịch vụ và đích nhắm m ục tiêu của chúng.
 Làm việc với Quản lý Công suất và xem xét yêu c ầu và khối
lượng lưu lượng CNTT, xác định xu hư ớng trong các lu ồng lư u
lượng và m ức dịch vụ.
 Đề xuất cải tiến thiết kế đối với cơ sở hạ tầng CNTT, thay đổi
công suất, tính liên t ục, các thỏa thuận sao lưu và ph ục hồi,
theo yêu cầu, và lưu ý các yêu c ầu vận hành, đặc biệt là về
m ặt m ức dịch vụ, tính s ẵn sàng, thời gian hồi đáp, bảo m ật và
thời gian sửa chữa. Tất cả các hoạt động này được thực hiện
trong m ối liên k ết với tất cả các quy trình Quản lý Dịch vụ.
 Xem xét chi phí CNTT so v ới các nhà cung c ấp dịch vụ bên
ngoài, các phát tri ển m ới và dịch vụ m ới, đưa ra các đề xuất
ban đầu để thay đổi thiết kế CNTT để có thể đạt được lợi ích
và m ức giảm chi phí thích hợp, với sự tham vấn của Quản lý
Tài chính.

334
 Cung cấp lời khuyên và hướng dẫn cho cấp quản lý về các giai
đoạn thiết kế và hoạch định hệ thống CNTT, để đảm bảo rằng
các yêu c ầu (đặc biệt là các nhu cầu về công suất, phục hồi,
hiệu suất và bảo mật) được phản ánh trong các thông s ố k ỹ
thuật tổng thể.
 Cung cấp lời khuyên và hư ớng dẫn cho tất cả các lĩnh vực
Quản lý Doanh nghi ệp và CNTT, các nhà phân tích, ho ạch
định, thiết kế và phát tri ển về m ọi khía cạnh của thiết kế và
công nghệ CNTT.
 Tương tác với các nhà thiết kế và lập kế hoạch từ các nhà
cung cấp và nhà cung c ấp dịch vụ bên ngoài, đ ảm bảo m ọi
dịch vụ CNTT bên ngoài đư ợc thiết kế để đáp ứng các m ức và
đích nhắm m ục tiêu dịch vụ đã được thỏa thuận của họ.
 Đóng m ột vai trò quan tr ọng trong vi ệc lựa chọn bất kỳ cơ sở
hạ tầng CNTT ho ặc giải pháp công ngh ệ m ới nào.
 Chịu trách nhi ệm về kỹ thuật cho m ọi tiêu chuẩn, chính sác h
và thiết kế CNTT đối với m ọi dự án hoặc lĩnh vực ứng dụng
chủ yếu quan tr ọng, hỗ trợ cho đánh giá tác đ ộng và đánh giá
các lựa chọn thiết kế CNTT m ới quan trọng.
 Cung cấp lời khuyên và hướng dẫn về kỹ thuật liên quan đế n
các tiêu chu ẩn, quy định, giao thức và thuế quan của quốc gia
và quốc tế.
 Chịu trách nhi ệm hoàn toàn về m ọi khía c ạnh thiết kế của m ọi
giai đoạn của vòng đời của hệ thống CNTT, bao g ồm tìm hiểu,
phân tích, đặc tả kỹ thuật, thiết kế, phát triển, xây dựng, kiểm
nghiệm , bảo trì, nâng cấp, chuyển tiếp, vận hành và c ải thiện.
 Làm việc với các đồng nghiệp trong lĩnh vực CNTT khi có thể,
đưa ra hoặc nâng c ấp tài liệu thiết kế và các m ô hình CNT T và
doanh nghiệp.
 Cập nhật hoặc cung cấp đầu vào cho các phân tích lợi ích chi
phí, phân tích r ủi ro, đề án kinh doanh, SoR và ITT và các k ế
hoạch phát tri ển, có tính đến các quyết định thiết kế.
 Thu thập và hỗ trợ cho việc đánh giá và lựa chọn các gi ải
pháp và đề xuất từ các nhà cung cấp thiết bị, phần m ềm và
các nhà cung c ấp dịch vụ và sản phẩm CNTT khác.
 Xây dựng, diễn dịch và giám sát các k ế hoạch kiểm nghiệm để
xác m inh sự vận hành chu ẩn xác c ủa các hệ thống đã hoàn
chỉnh so với các m ục tiêu thiết kế của chúng.
 Lập thành tài li ệu m ọi công vi ệc sử dụng các tiêu chuẩn,
phương pháp và công c ụ cần thiết.
 Duy trì m ột kiến thức kỹ thuật đầy đủ về m ọi năng l ực sản
phẩm CNTT và các khuôn kh ổ kỹ thuật m à chúng vận hành
trong đó.
 Khi cần thiết, đánh giá nh ững thay đổi đối với tính tuân th ủ
các nguyên t ắc thiết kế, bao gồm việc tham dự các cuộc họp
CAB nếu thích hợp.
Lưu ý: Thông thư ờng các Nhà thiết kế và Kiến trúc sư trong các t ổ
chức lớn sẽ chuyên về m ột trong năm khía c ạnh của thiết kế (xem
phần 3 và 4 để biết thêm chi ti ết). Tuy nhiên, m ột cách ti ếp cận
được tích hợp để thiết kế luôn phải được áp dụng, do đó Nhà thi ết

335
kế và Kiến trúc sư cần làm việc cùng nhau trong m ột phương pháp
và khuôn khổ chính thức để đảm bảo các thiết kế nhất quán và
tương thích được tạo ra. Trong các t ổ chức nhỏ hơn, m ột số hoặc
tất cả các vai trò thường được kết hợp và điều này ít gây trở ngại
hơn, m ặc dù vẫn nên s ử dụng m ột cách tiếp cận chính thức. Bất cứ
khi nào các thi ết kế được sản xuất, chúng phải luôn áp dụng m ột
cách tiếp cận tổng thể, bao gồm tất cả các lĩnh vực và phải được
chấp nhận và ký kết bởi tất cả các lĩnh vực. T ất cả các Nhà thi ết k ế
cần phải hiểu cách các ki ến trúc, chiến lược, thiết kế và kế hoạch
phù hợp với nhau như thế nào.
6.4.5 Nhà Quản lý Mục lục Dịch vụ

Nhà Quản lý Mục lục Dịch vụ chịu trách nhiệm cho việc đưa ra và
duy trì Mục lục Dịch vụ. Điều này bao g ồm các trách nhi ệm như:
 Đảm bảo rằng m ọi dịch vụ vận hành và m ọi dịch vụ đang được

chuẩn bị để hoạt động vận hành được ghi nhận lại trong Mục
lục Dịch vụ.
 Đảm bảo rằng m ọi thông tin trong M ục lục Dịch vụ là chính xác
và được cập nhật.
 Đảm bảo rằng m ọi thông tin trong M ục lục Dịch vụ là nhất
quán với thông tin trong Danh m ục Dịch vụ.
 Đảm bảo rằng thông tin trong M ục lục Dịch vụ được bảo vệ và
sao lưu m ột cách đầy đủ.
6.4.6 Nhà Quản lý Mức Dịch vụ

Nhà Quản lý Mức Dịch vụ chịu trách nhi ệm cho việc đảm bảo rằng
m ục tiêu c ủa Quản lý Mức Dịch vụ được đáp ứng. Những trách
nhiệm này bao gồm :
 Luôn nhận thức được về những nhu cầu kinh doanh đang thay
đổi.
 Đảm bảo rằng các yêu c ầu dịch vụ hiện tại và tương lai c ủa
khách hàng được xác định, hiểu rõ và ghi nhận lại trong các
tài liệu SLA và SLR.
 Đàm phán và thỏa thuận về các m ức độ dịch vụ sẽ được cung
cấp với khách hàng (n ội bộ hoặc bên ngoài); ghi nhận lại các
m ức dịch vụ m ột cách chính thức trong SLA.
 Đàm phán và thỏa thuận các OLA và trong m ột số trường hợp,
các SLA và th ỏa thuận khác làm cơ s ở cho các SLA với khách
hàng của dịch vụ.
 Hỗ trợ việc đưa ra và duy trì Danh m ục Dịch vụ, Mục lục Dịch
vụ, Danh m ục Ứng dụng và các thủ tục bảo trì tương ứng.
 Đảm bảo rằng các đích nhắm m ục tiêu đã th ỏa thuận trong các
hợp đồng cơ sở phù hợp với các đích nhắm m ục tiêu SLA và
SLR.
 Đảm bảo rằng các báo cáo dịch vụ được tạo ra cho từng dịch
vụ khách hàng và rằng các vi phạm đích nhắm mục tiêu SLA
được đánh dấu, điều tra và các hành đ ộng được thực hiện để
ngăn chặn chúng tái di ễn.

336
 Đảm bảo rằng các đánh giá v ề hiệu suất dịch vụ được lên lịch
trình, được thực hiện cùng với khách hàng m ột cách thường
xuyên và được lập thành văn b ản với các hành đ ộng đã thỏa
thuận được tiến hành.
 Đảm bảo rằng các sáng ki ến cải tiến được xác định trong các
đánh giá dịch vụ đã được thực hiện và báo cáo về tiến độ
được cung c ấp cho khách hàng.
 Xem xét ph ạm vi dịch vụ, các SLA, OLA và các th ỏa thuận
khác m ột cách thường xuyên, lý tưởng là ít nhất hàng năm .
 Đảm bảo rằng tất cả các thay đ ổi được đánh giá về tác động
của chúng đ ối với các m ức dịch vụ, bao gồm các SLA, OLA và
các hợp đồng nền tảng, bao gồm cả việc tham dự các cuộc
họp CAB nếu thích hợp.
 Xác định tất cả các bên liên quan và khách hàng chính .
 Phát triển m ối quan hệ và giao ti ếp với các bên liên quan,
khách hàng và ngư ời dùng chính.
 Xác định và thỏa thuận về các khiếu nại và việc ghi lại, quản
lý, báo cáo, khi c ần thiết, và việc giải quyết các khiếu nại đó.
 Ghi nhận lại định nghĩa và truyền thông về m ọi khiếu nại.
 Đo lường, ghi nhận, phân tích và c ải thiện sự hài lòng của
khách hàng.
6.4.7 Nhà Quản lý Tính sẵn sàng

Một Nhà Quản lý Tính s ẵn sàng chịu trách nhi ệm cho việc đảm bảo
rằng m ục tiêu của Quản lý Tính s ẵn sàng được đáp ứng. Những
trách nhiệm này bao g ồm :
 Đảm bảo rằng m ọi dịch vụ hiện hữu cung c ấp các m ức sẵn

sàng đã th ỏa thuận với doanh nghiệp trong SLA.
 Đảm bảo rằng m ọi dịch vụ m ới được thiết kế để cung c ấp các
m ức sẵn sàng được yêu cầu bởi doanh nghi ệp, và xác m inh
thiết kế sau cùng đáp ứng được m ức sẵn sàng tối thiểu như
đã được thỏa thuận bởi doanh nghiệp đối với các dịch vụ
CNTT.
 Hỗ trợ cho việc điều tra và ch ẩn đoán m ọi sự cố và vấn đề gây
ra vấn đề cho tính sẵn sàng ho ặc sự không sẵn sàng của các
dịch vụ hoặc các thành ph ần.
 Tham gia vào thi ết kế cơ sở hạ tầng CNTT, bao g ồm chỉ định
các yêu cầu về tính sẵn sàng đối với phần cứng và ph ần mềm .
 Chỉ định các yêu c ầu đối với hệ thống quản lý sự kiện mới
hoặc nâng cao đ ể tự động giám sát tính sẵn sàng của các
thành phần CNTT.
 Chỉ định các yêu c ầu về độ tin c ậy, khả năng bảo trì và kh ả
năng phục vụ đối với các thành phần được cung cấp bởi các
nhà cung c ấp bên trong và bên ngoài .
 Chịu trách nhi ệm giám sát m ức độ sẵn sàng thực tế của CNTT
đã đạt được so với các đích nhắm m ục tiêu SLA và cung c ấp
m ột loạt các báo cáo về tính sẵn sàng của CNTT để đảm bảo
rằng m ức độ sẵn sàng, độ tin cậy và khả năng bảo trì đã th ỏa
thuận được đo lư ờng và giám sát liên t ục.

337
 Cải thiện tính sẵn sàng của dịch vụ m ột cách chủ động bất cứ
khi nào có thể, và t ối ưu hóa tính sẵn sàng của cơ sở hạ tầng
CNTT để cung c ấp những cải tiến hiệu quả về chi phí m ang l ại
lợi ích cụ thể cho doanh nghi ệp.
 Tạo ra, duy trì và thường xuyên xem xét m ột AMIS và Kế
hoạch về Tính sẵn sàng được m ong đ ợi, nhằm cải thiện tính
sẵn sàng tổng thể của các dịch vụ CNTT và các thành ph ần cơ
sở hạ tầng, để đảm bảo rằng các yêu cầu về tính sẵn có của
doanh nghiệp hiện tại và trong tương lai có thể được đáp ứng.
 Đảm bảo rằng quy trình Quản lý Tính sẵn sàng, các k ỹ thuật
và phương pháp liên quan c ủa nó được xem xét và đánh giá
m ột cách thường xuyên, và t ất cả những điều này phải được
cải tiến liên tục và vẫn phù hợp với m ục đích.
 Tạo ra các tiêu chí thi ết kế khôi phục và sẵn sàng để áp dụng
cho thiết kế cơ sở hạ tầng m ới hoặc được nâng cao.
 Làm việc với Quản lý Tài chính, đ ảm bảo m ức độ sẵn sàng của
CNTT được yêu c ầu phải phù hợp với chi phí.
 Duy trì và hoàn thành m ột lịch trình kiểm tra tính sẵn sàng cho
tất cả các cơ chế về tính sẵn sàng.
 Đảm bảo rằng t ất cả các kế hoạch và kiểm nghiệm tính khả
dụng được kiểm tra sau m ỗi thay đổi lớn của doanh nghiệp.
 Hỗ trợ Quản lý Liên tục Dịch vụ CNTT và Bảo m ật cùng với
đánh giá và qu ản lý rủi ro.
 Đánh giá các thay đ ổi về m ặt tác động của chúng đối với tất
cả các khía c ạnh của tính sẵn sàng, bao gồm cả tính sẵn sàng
của dịch vụ tổng thể và Kế hoạch về Tính sẵn sàng.
 Tham dự các cuộc họp CAB khi thích h ợp.
6.4.8 Nhà Quản lý Tính liên tục của Dịch vụ CNTT

Nhà Quản lý Tính liên t ục của Dịch vụ CNTT chịu trách nhi ệm cho
việc đảm bảo rằng các m ục tiêu c ủa Quản lý Tính liên t ục Dịch vụ
CNTT được đáp ứng. Việc này bao gồm các tác vụ và trách nhi ệm
như:
 Tiến hành các Phân tích Tác đ ộng Kinh doanh đ ối với m ọi dịch
vụ CNTT đang hi ện hữu và dịch vụ CNTT m ới.
 Triển khai và duy trì quy trình ITSCM, tương x ứng với các yêu
cầu tổng thể của quy trình Qu ản lý Liên tục Kinh doanh c ủa tổ
chức, và đại diện cho các chức năng dịch vụ CNTT trong quy
trình Quản lý Liên t ục Kinh doanh.
 Đảm bảo rằng m ọi kế hoạch, rủi ro và ho ạt động ITSCM có cơ
sở và liên k ết với m ọi kế hoạch, rủi ro và ho ạt động BCM, và
có khả năng đạt được cac đích nhắm m ục tiêu đã được thỏa
thuận và lập thành văn b ản trong bất kỳ trường hợp nào.
 Tiến hành đánh giá và quản lý rủi ro nhằm ngăn ng ừa thảm
họa khi chi phí là h ợp lý và thực tế.
 Phát triển và duy trì chiến lược liên tục của tổ chức.
 Đánh giá các vấn đề tiềm năng về tính liên tục dịch vụ và thỉnh
cầu Kế hoạch Liên t ục Dịch vụ nếu cần thiết.

338
 Quản lý Kế hoạch liên t ục dịch vụ trong khi nó đang ho ạt động,
bao gồm việc chuyển đổi dự phòng sang vị trí phụ và khôi
phục về vị trí chính.
 Tiến hành đánh giá sau khi khám nghi ệm pháp y về các thỉnh
cầu và kiểm nghiệm về tính liên t ục của dịch vụ, đồng thời đưa
ra các hành đ ộng khắc phục nếu cần thiết.
 Phát triển và quản lý các k ế hoạch ITSCM để đảm bảo rằng,
tại m ọi thời điểm , các m ục tiêu khôi phục của doanh nghiệp c ó
thể đạt được.
 Đảm bảo rằng tất cả các lĩnh vực dịch vụ CNTT đều được
chuẩn bị và có thể đáp ứng yêu cầu của các k ế hoạch về tính
liên tục.
 Duy trì m ột lịch trình ki ểm tra CNTT toàn di ện, bao g ồm kiểm
tra tất cả các kế hoạch liên t ục phù hợp với yêu c ầu kinh
doanh và sau m ỗi thay đổi lớn trong doanh nghiệp.
 Tiến hành đánh giá chất lượng của tất cả các thủ tục và đảm
bảo rằng những thủ tục này được đưa vào lịch trình th ử
nghiệm .
 Truyền thông và duy trì nhận thức về các m ục tiêu ITSCM
trong các lĩnh v ực kinh doanh được hỗ trợ và các lĩnh vực dịch
vụ CNTT.
 Tiến hành đánh giá thường xuyên, ít nh ất là hàng năm , các K ế
hoạch Liên t ục với các lĩnh vực kinh doanh đ ể đảm bảo rằng
chúng phản ánh chính xác các nhu cầu của doanh nghiệp.
 Thương thảo và quản lý hợp đồng với các nhà cung c ấp dịch
vụ khôi phục bên thứ ba.
 Đánh giá các thay đ ổi về m ặt tác động của chúng đối với các
Kế hoạch Liên t ục và Liên t ục Dịch vụ.
 Tham dự các cuộc họp CAB khi thích h ợp .
6.4.9 Nhà Quản lý Công su ất

Một Nhà Quản lý Công su ất chịu trách nhi ệm cho việc đảm bảo rằng
các m ục tiêu c ủa Quản lý Công suất được đáp ứng. Những trách
nhiệm này bao gồm :
 Đảm bảo rằng công su ất CNTT đầy đủ để đáp ứng các m ức

dịch vụ được yêu cầu, và r ằng quản lý CNTT cao cấp được tư
vấn m ột cách đúng đắn về cách làm thế nào để khớp nối công
suất và nhu cầu và để đảm bảo rằng việc sử dụng công su ất
hiện tại được tối ưu hóa.
 Xác định, cùng với Nhà Quản lý Mức Dịch vụ, các yêu c ầu về
công suất thông qua các cu ộc thảo luận với người dùng của
doanh nghiệp.
 Hiểu việc sử dụng cơ sở hạ tầng và dịch vụ CNTT hiện tại
cũng như công suất tối đa của từng thành phần.
 Tiến hành định cỡ trên m ọi dịch vụ và hệ thống m ới được đề
xuất, có thể sử dụng các k ỹ thuật m ô hình hóa, đ ể xác định
các yêu cầu về công suất.
 Dự báo yêu c ầu công suất trong tương lai d ựa trên các kế
hoạch kinh doanh, xu hư ớng sử dụng, định cỡ của các dịch vụ
mới, v.v…

339
 Đưa ra, xem xét thường xuyên và điều chỉnh Kế hoạch Công
suất, phù hợp với chu kỳ lập kế hoạch kinh doanh của t ổ chức,
xác định các yêu c ầu sử dụng hiện tại và dự báo trong kho ảng
thời gian được đề cập trong kế hoạch.
 Đảm bảo rằng các m ức độ giám sát tài nguyên và hi ệu suất hệ
thống thích hợp được thiết lập.
 Phân tích d ữ liệu sử dụng và dữ liệu hiệu suất và báo cáo về
hiệu suất so với các đích nhắm m ục tiêu có trong SLA .
 Đưa ra các s ự cố và vấn đề khi các vi phạm các ngưỡng công
suất hoặc hiệu suất được phát hi ện, và hỗ trợ điều tra và chẩn
đoán các sự cố và vấn đề liên quan đ ến công suất.
 Xác định và bắt đầu bất kỳ điều chỉnh nào được thực hiện để
tối ưu hóa và c ải thiện công suất hoặc hiệu suất.
 Xác định và triển khai các sáng ki ến để cải thiện việc sử dụng
tài nguyên - ví dụ, các kỹ thuật quản lý nhu c ầu.
 Đánh giá công ngh ệ m ới và m ức độ phù hợp của nó với tổ
chức về m ặt hiệu suất và chi phí .
 Làm quen với nhu cầu tiềm năng trong tương lai đ ối với các
dịch vụ CNTT và đánh giá đi ều này về các m ức độ dịch vụ
hiệu suất.
 Đảm bảo rằng tất cả các thay đ ổi được đánh giá về tác động
của chúng đối với công suất và hiệu suất và tham dự các cuộc
họp CAB khi thích h ợp.
 Đưa ra các báo cáo qu ản lý thư ờng xuyên bao g ồm việc sử
dụng tài nguyên, xu hư ớng và dự báo hiện tại.
 Định cỡ m ọi dịch vụ và hệ thống m ới được đề xuất để xác định
tài nguyên m áy tính và m ạng cần thiết, để xác định việc sử
dụng phần cứng, mức dịch vụ hiệu suất và tác động chi phí.
 Đánh giá các k ỹ thuật và các s ản phẩm phần cứng và phầ n
m ềm mới để sử dụng bởi Quản lý Công suất có thể cải thiện
hiệu quả và hiệu suất của quy trình.
 Kiểm tra hiệu suất của các dịch vụ và hệ thống m ới.
 Báo cáo về hiệu suất dịch vụ và thành phần so với các đích
nhắm m ục tiêu trong các SLA.
 Duy trì m ột kiến thức về các nhu cầu trong tương lai đ ối với
các dịch vụ CNTT và dự báo những tác động của nhu c ầu về
các m ức dịch vụ hiệu suất.
 Xác định các m ức dịch vụ hiệu suất có thể duy trì được và hợp
lý về chi phí.
 Khuyến nghị điều chỉnh các hệ thống và dịch vụ, và đưa ra các
khuyến cáo cho qu ản lý CNTT về thiết kế và sử dụng các hệ
thống để giúp đảm bảo việc sử dụng tối ưu m ọi tài nguyên
phần cứng và phần m ềm hệ điều hành.
 Làm đầu m ối cho mọi vấn đề công suất và hiệu suất.
6.4.10 Nhà quản lý Bảo mật

Nhà Quản lý Bảo m ật chịu trách nhiệm cho việc đảm bảo rằng các
m ục tiêu c ủa Quản lý Bảo m ật được đáp ứng. Những trách nhi ệm
này bao gồm các tác vụ và trách nhiệm dưới đây:

340
 Phát triển và duy trì Chính sách B ảo mật Thông tin và m ột bộ
các chính sách hỗ trợ cụ thể, đảm bảo sự ủy quyền, cam kết
và chứng thực tương xứng từ quản lý cấp cao c ủa CNTT và
của doanh nghi ệp.
 Truyền thông và công khai Chính sách Bảo m ật Thông tin cho
m ọi bên liên quan thích h ợp.
 Đảm bảo rằng Chính sách B ảo m ật Thông tin đư ợc thực thi và
tuân thủ.
 Xác định và phân lo ại những tài s ản thông tin (các Đơn v ị Cấu
hình) và CNTT và m ức độ kiểm soát và bảo vệ cần thiết.
 Hỗ trợ các Phân tích Tác động Kinh doanh.
 Tiến hành Phân tích R ủi ro Bảo m ật và đánh giá rủi ro kết hợp
với Quản lý Liên t ục Dịch vụ CNTT và Quản lý Tính s ẵn sàng.
 Thiết kế các biện pháp ki ểm soát bảo m ật và phát tri ển các k ế
hoạch bảo m ật.
 Phát triển và lập thành văn bản các thủ tục vận hành và duy trì
các biện pháp ki ểm soát bảo m ật.
 Giám sát và quản lý m ọi vi phạm bảo m ật và xử lý các s ự cố
bảo m ật, thực hiện các hành đ ộng khắc phục nhằm ngăn ngừa
sự tái diễn, nếu thích hợp.
 Báo cáo, phân tích và gi ảm thiểu tác động và khối lượng của
các sự cố, kết hợp với Quản lý V ấn đề.
 Khuyến khích đào t ạo và nhận thức về bảo m ật.
 Duy trì m ột bộ các biện pháp và tài li ệu kiểm soát bảo m ật,
xem xét và đánh giá m ọi biện pháp ki ểm soát và thủ tục bảo
m ật m ột cách thường xuyên.
 Đảm bảo rằng m ọi thay đổi được đánh giá về tác động trên
m ọi khía cạnh bảo m ật, bao gồm Chính sách B ảo m ật Thông
tin và các bi ện pháp ki ểm soát b ảo m ật, và tham dự các cuộ c
họp CAB khi thích h ợp.
 Tiến hành các ki ểm nghiệm bảo m ật.
 Tham dự bất kỳ cuộc xem xét về bảo m ật nào phát sinh do vi
phạm bảo m ật và thúc đẩy các hành động khắc phục.
 Đảm bảo rằng tính bảo m ật, toàn vẹn và s ẵn sàng của các
dịch vụ được duy trì ở m ức độ đã thỏa thuận trong các SLA và
rằng chúng tuân th ủ m ọi yêu cầu luật định có liên quan.
 Đảm bảo rằng m ọi truy cập tới dịch vụ bởi nhà cung c ấp và
các đối tác bên ngoài ph ải tuân theo các th ỏa thuận và trách
nhiệm của hợp đồng.
 Làm đầu m ối cho mọi vấn đề về bảo m ật.
6.4.11 Nhà Quản lý Nhà cung cấp

Nhà Quản lý Nhà cung c ấp chịu trách nhi ệm cho việc đảm bảo rằng
các m ục tiêu c ủa Quản lý Nhà cung c ấp được đáp ứng. Việc này bao
gồm những tác vụ như:
 Cung cấp sự trợ giúp trong vi ệc phát triển và xem xét các
SLA, hợp đồng, thỏa thuận hoặc bất kỳ tài liệu nào khác đố i
với các nhà cung c ấp bên thứ ba.
 Đảm bảo rằng thu được giá trị về tiền bạc từ m ọi nhà cung cấp
và hợp đồng CNTT.

341
 Đảm bảo rằng m ọi quy trình nhà cung c ấp CNTT là nh ất quán
và tương tác với m ọi chiến lược, quy trình nhà cung c ấp
doanh nghiệp và các đi ều khoản và điều kiện tiêu chuấn.
 Duy trì và xem xét m ột Cơ sở dữ liệu Hợp đồng và Nhà cung
cấp (SCD).
 Xem xét và Phân tích R ủi ro c ủa m ọi nhà cung c ấp và hợp
đồng trên cơ sở định kỳ.
 Đảm bảo rằng bất kỳ hợp đồng cơ sở hoặc thỏa thuận hoặc
SLA đã được phát triển nào được liên kết với những gì thuộc
về doanh ng hiệp.
 Đảm bảo rằng m ọi dịch vụ hỗ trợ được xác định phạm vi và l ập
thành tài liệu và rằng các tương tác và s ự phụ thuộc giữa các
nhà cung cấp, các dịch vụ hỗ trợ và các quy trình nhà cung
cấp được thống nhất và lập thành văn b ản.
 Đảm bảo rằng m ọi vai trò và m ối quan hệ giữa khách hàng
tiềm năng và bất kỳ nhà thầu phụ nào đều được lập thành văn
bản, duy trì và tuân theo th ỏa thuận hợp đồng.
 Tiến hành xem xét các h ợp đồng hoặc SLA ít nhất hàng năm,
và đảm bảo rằng mọi hợp đồng là nh ất quán với các yêu cầu
và các điều khoản và điều kiện tiêu chu ẩn của tổ chức, khi
thích hợp.
 Cập nhật các hợp đồng hoặc SLA khi c ần thiết, đảm bảo rằng
quy trình Qu ản lý Thay đ ổi được tuân thủ.
 Duy trì m ột quy trình xử lý những tranh chấp hợp đồng, và
đảm bảo rằng bất kỳ tranh chấp nào được xử lý theo cách
thức có hiệu quả và hiệu lực.
 Duy trì m ột quy trình xử lý dự kiến kết thúc, kết thúc sớm và
chuyển giao d ịch vụ.
 Giám sát, báo cáo và xem xét m ột cách thường xuyên hi ệu
suất của nhà cung cấp so với các đích nh ắm m ục tiêu, xác
định các hành đ ộng cải thiện thích hợp và đảm bảo những
hành động đó đư ợc thực hiện.
 Đảm bảo những thay đổi được đánh giá về tác động c ủa chúng
đối với các nhà cung c ấp, các dịch vụ hỗ trợ và các hợp đồng
và tham dự các cuộc họp CAB khi thích hợp.
 Phối hợp và hỗ trợ m ọi nhà quản lý hợp đồng và nhà cung c ấp
CNTT riêng l ẻ, đảm bảo rằng m ỗi nhà cung c ấp/hợp đồng đều
có m ột chủ sở hữu được chỉ định trong tổ chức cung c ấp dịch
vụ.
7 Xem xét công ngh ệ

Một điều thường được thừa nhận là việc sử dụng các công cụ Quản
lý Dịch vụ là điều thiết yếu cho sự thành công của m ọi hoạt động
triển khai quy trình, tr ừ những quy trình nh ỏ nhất. Tuy nhiên, đi ề u
quan trọng là công cụ đang được sử dụng hỗ trợ cho các quy trình
chứ không phải là ngược lại. Theo nguyên t ắc chung, đừng s ửa đổi
các quy trình để phù hợp với công c ụ. Tuy nhiên, với việc sử dụng
các công c ụ để hỗ trợ cho các quy trình, c ần phải thực dụng và th ừa
nhận rằng có thể không có m ột công c ụ hỗ trợ cho toàn bộ quy trình
đã được thiết kế, do đó, m ột yếu tố về việc thiết kế lại quy trình có
thể là cần thiết. Đừng giới hạn các yêu cầu đối với chức năng: xem

342
xét khả năng của sản phẩm để tiến hành, m ở rộng kích thước của
cơ sở dữ liệu, khôi phục sau khi bị lỗi và duy trì tính toàn v ẹn của
cơ sở dữ liệu. Sản phẩm có tuân th ủ các tiêu chuẩn quốc tế không?
Nó có đủ hiệu quả đế cho phép bạn đáp ứng các Yêu c ầu Quản lý
Dịch vụ của bạn không?
Thường thì các tổ chức tin r ằng bằng cách m ua sắm hoặc phát tri ển
m ột công cụ thì m ọi vấn đề của họ sẽ được giải quyết, và họ rất dễ
quên rằng chúng ta vẫn phụ thuộc vào quy trình, ch ức năng và, quan
trọng nhất là con người. Hãy nhớ: ‘một tên ngốc với một công c ụ
vẫn là một tên ngốc’.
7.1 Các công cụ Thiết kế Dịch vụ

Có rất nhiều công c ụ và kỹ thuật có thể được sử dụng để hỗ trợ cho
thiết kế các dịch vụ cùng với các thành ph ần tương ứng của chúng.
Những công c ụ và kỹ thuật này cho phép:
 Thiết kế phần cứng.

 Thiết kế phần m ềm .
 Thiết kế m ôi trường.
 Thiết kế quy trình.
 Thiết kế dữ liệu.
Các công c ụ và k ỹ thuật là rất đa dạng và khác bi ệt, bao gồm cả độc
quyền lẫn không đ ộc quyền, và r ất hữu ích trong:
 Tăng tốc quy trình thi ết kế.

 Đảm bảo rằng các tiêu chuẩn và quy ước được tuân thủ.
 Đề xuất các nguyên m ẫu, cơ sở m ô hình hóa và giả lập.
 Cho phép các tình hu ống ‘Chuyện gì xảy ra nếu?’ được kiểm
tra.
 Cho phép các tương tác và ph ụ thuộc được kiểm tra và khắc
phục.
 Thẩm định các thi ết kế trước khi chúng được phát tri ển và
triển khai để đảm bảo rằng chúng đáp ứng và hoàn thành các
yêu cầu được dự định của chúng.
Việc phát triển các Thi ết kế Dịch vụ có thể được đơn giản hóa bằng
các sử dụng các công c ụ cung cấp các chế độ xem dưới dạng đồ
họa và các thành ph ần cấu thành của nó, t ừ các quy trình nghi ệp vụ
đến dịch vụ và SLA đến cơ sở hạ tầng, m ôi trư ờng, dữ liệu và ứng
dụng, quy trình, OLA, đ ội nhóm , hợp đồng và nhà cung c ấp. Một s ố
công cụ Quản lý Cấu hình cung c ấp những phuong ti ện như vậy, và
thỉnh thoảng còn được coi là m ột thành phần của các công c ụ Quản
lý Dịch vụ Nghiệp vụ (BSM). Chúng có thể bao gồm hoặc được liên
kết tới các công cụ và cơ chế ‘khám phá -tự động’ và cho phép các
m ối quan hệ giữa m ọi thành phần nói trên để được trình bày dưới
dạng đồ họa, m ang l ại khả năng đi sâu vào t ừng thành phần và thu
được những thông tin chi ti ết nếu cần thiết.
Nếu những loại công c ụ này cũng bao g ồm thông tin tài chín h, và
sau đó đư ợc liên k ết tới m ột ‘Cây Chỉ số’ cung cấp các KPS và ch ỉ

343
số của các khía cạnh khác nhau c ủa dịch vụ thì dịch vụ có thể được
giám sát và qu ản lý trong m ọi giai đo ạn của vòng đời của nó. Việc
chia sẻ bộ thông tin d ịch vụ duy nhất và được tập trung hóa này cho
phép m ọi người trong tổ chức cung c ấp dịch vụ và doanh nghiệp tiếp
cận được m ột cái nhìn duy nhất, nhất quán, ‘thế giới thực’ về dịch
vụ và hiệu suất của nó, và cung c ấp m ột nền tảng vững chắc cho
việc phát triển các m ối quan hệ và sự cộng tác t ốt đẹp giữa nhà
cung cấp dịch vụ và khách hàng c ủa m ình.
Các loại công c ụ này không ch ỉ tạo điều kiện cho các quy trình thi ết
kế m à cũng hỗ trợ và trợ giúp rất nhiều cho m ọi giai đoạn trong
Vòng đời Dịch vụ, bao gồm :
 Quản lý m ọi giai đoạn trong Vòng đời Dịch vụ.

 Mọi khía c ạnh của dịch vụ và hiệu suất của nó.
 Đo lường, báo cáo và quản lý thành tích dịch vụ, SLA, OLA,
theo hợp đồng và nhà cung cấp.
 Các chỉ số và Cây chỉ số được hợp nhất, với các chế độ xem
từ bảng điều khiển quản lý xuống đến thông tin thành phần chi
tiết, phân tích và xác đ ịnh hiệu suất và lỗi.
 Quan điểm nhất quán và thống nhất trên tất cả các quy trình,
hệ thống, công ngh ệ và nhóm .
 Các m ối quan hệ và sự tích hợp của doanh nghi ệp và các quy
trình của nó với các dịch vụ, hệ thống và quy trình CNTT.
 Một tập hợp toàn diện các phương ti ện tìm kiếm và báo cáo,
cho phép thông tin và phân tích chính xác đ ể đưa ra quyết
định sáng suốt.
 Quản lý chi phí d ịch vụ
 Quản lý các m ối quan hệ, tương tác và sự phụ thuộc lẫn nhau.
 Quản lý Mục lục Dịch vụ và Danh m ục Dịch vụ.
 Một Hệ thống Quản lý Cấu hình (CMS).
 Hệ thống Quản lý Kiến thức Dịch vụ (SKMS).
Các hoạt động chung chung dưới đây sẽ là cần thiết để triển khai
m ột phương pháp tiếp cận như vậy:
 Thiết lập vòng đời chung cho các tài s ản CNTT (Yêu cầu, Thiết
kế và Phát triển, Xây dựng, Kiểm nghiệm , Triển khai, Vận
hành và Tối ưu hóa, Lo ại bỏ) và xác đ ịnh các quy trình, chính
sách, hoạt động và công ngh ệ chính trong t ừng giai đo ạn của
vòng đời cho từng loại tài sản.
 Chính thức hóa các m ối quan hệ giữa các loại tài s ản CNTT
khác nhau và m ối quan hệ giữa việc m ua và qu ản lý tài sả n
CNTT và các lĩnh v ực CNTT khác.
 Xác định tất cả các vai trò và trách nhi ệm liên quan đ ến các
hoạt động tài sản CNTT.
 Thiết lập các bi ện pháp để hiểu (Tổng) Chi phí Sở hữu m ột
dịch vụ CNTT.
 Thiết lập các chính sách cho vi ệc tái sử dụng các tài sản
CNTT trên các d ịch vụ, ví dụ: ở cấp độ công ty.

344
 Xác định m ột chiến lược để m ua lại và quản lý các tài s ản
CNTT, bao g ồm cả cách thức m à nó nên liên k ết với các chi ến
lược CNTT và kinh doan h khác như thế nào.
Ngoài ra, đối với loại tài sản ứng dụng:
 Xác định m ột chiến lược m ua lại và quản lý các tài sản CNTT,
bao gồm cách th ức m à nó nên được liên k ết với các chi ến
lược doanh nghi ệp và chiến lược CNTT khác.
 Ghi nhận lại vai trò m à ứng dụng đã đóng góp trong việc cung
cấp các dịch vụ CNTT cho doanh nghi ệp.
 Đảm bảo rằng m ô hình vòng đời tài s ản CNTT phổ biến được
áp dụng đối với m ột vòng đời ứng dụng, phù hợp với các lo ại
ứng dụng khác nhau.
 Thiết lập các tiêu chuẩn cho việc sử dụng các phương p háp
tiếp cận khác nhau để phát triển các ứng dụng, và công nhận
vai trò c ủa các phương pháp phát tri ển, bao gồm những gì dựa
trên ‘tái-sử dụng’ (xem phân về Thiết kế và Phát tri ển để biết
thêm chi ti ết).
 Đảm bảo rằng các thủ tục sẵn sàng để xem xét m ọi kiểu yêu
cầu (chẳng hạn như khả năng vận hành được, hiệu suất dịch
vụ, khả năng bảo trì được, bảo m ật) trong các giai đo ạn sớm
của phát tri ển ứng dụng.
 Thiết lập các tiêu chu ẩn cho việc quyết định về sự cung cấp
tối ưu các ứng dụng cho t ổ chức, chẳng hạn như sử dụng Nhà
cung cấp Dịch vụ Ứng dụng, các phát tri ển được tối ưu hóa,
COTS và các gói tùy ch ỉnh.
Ngoài ra, đối với loại tài sản dữ liệu/thông tin:
 Thiết lập cách m à những nguyên tắc chung trong m ua l ại và

quản lý tài s ản CNTT có th ể giúp quản lý tài nguyê n dữ
liệu/thông tin c ủa một tổ chức như thế nào.
Đảm bảo rằng các thi ết kế dữ liệu được thực hiện dựa trên:
 Tầm quan tr ọng của siêu dữ liệu có thể tái-sử dụng và được
tiêu chuẩn hóa.
 Nhu cầu về chất lượng của dữ liệu.
 Giá trị của dữ liệu đối với tổ chức.
 Nhu cầu đối với các kỹ năng quản trị dữ liệu và quản trị cơ sở
dữ liệu.
 Hiểu về lĩnh vực chủ đề ‘công ty’ (ho ặc chung/cộng tác) và các
quan điểm về dữ liệu dịch vụ (‘hệ thống’) riêng l ẻ.
 Nhu cầu quản lý dữ liệu về các kiểu dữ liệu phi-truyền thống
như văn bản, hình ảnh được quét, phim và âm thanh.
 Nhận thức được về những vấn đề chủ yếu về lưu trữ, bảo m ật
và pháp lý đối với dữ liệu.
 Chỉ định cách thức m à m ô hình vòng đ ời tài s ản CNTT phổ
biến có thể được áp dụng cho kiểu tài sản dữ liệu như thế
nào.

345
Ngoài ra, đối với kiểu tài sản cơ sở hạ tầng và m ôi trường CNTT:
 Thiết lập các tiêu chu ẩn cho việc m ua lại và quản lý các thi ết
bị m ôi trường và cơ sở hạ tầng CNTT (bao gồm phần cứng,
nguồn điện, phần m ềm hệ điều hành, phần m ềm dbm s, ph ần
m ềm trung gian và m ạng) và đảm bảo chúng cung c ấp m ột nền
tảng ổn định nhưng có khả năng thích ứng để làm cơ sở cho
việc cung c ấp các dịch vụ CNTT cho doanh nghi ệp.
 Thiết lập cách th ức m à m ô hình vòng đ ời tài sản CNTT ph ổ
biến nên được áp dụng đối với vòng đời cơ sở hạ tầng CNTT
cụ thể.
 Thiết lập các hoạt động để tối ưu hóa vi ệc sử dụng các tài sản
cơ sở hạ tầng CNTT thông qua vi ệc tái sử dụng chúng.
 Xác định nhu c ầu đối với các công c ụ và m ô tả cách sử dụng
và tích hợp t ổng thể của chúng trợ giúp trong vi ệc quản lý m ột
cơ sở hạ tầng và các dịch vụ liên quan có hi ệu quả.
Ngoài ra, đối với các k ỹ năng (con ngư ời, năng lực):
 Chính thức hóa về m à cách năng lực của các cá nhân ch ịu

trách nhiệm đối với tài sản CNTT và các dịch vụ liên quan có
thể được coi là m ột tài sản trong m ột tổ chức và được quản lý
như vậy.
 Xác định các vòng đời tài s ản CNTT đang áp d ụng cho tài sản
con người, đặc biệt là về m ặt những năng lực có thể đo lường
được, ví dụ như kỹ năng, kiến thức, hiểu biết, trình độ, kinh
nghiệm , thái độ và hành vi.
 Đảm bảo tài li ệu về các năng lực hiện tại đang có và xác đ ịnh
cách thức làm thế nào m à chúng có th ể được tái sử dụng hoặc
được tăng cường.
 Đảm bảo các tiêu chuẩn của tổ chức tương thích v ới các
khuôn khổ năng lực tiêu chuẩn hiện có đối với lĩnh vực CNTT,
chẳng hạn như các kỹ năng và năng l ực SFIA+ (Kỹ năng Cho
Thời đại Thông tin – Skills For The Inform ation Age) được kết
hợp vào các vai trò và trách nhi ệm .
Ngoài ra, nhằm thiết lập các tương tác và ph ụ thuộc hiệu quả:
 Xác định các tương tác m à vi ệc m ua lại và quản lý tài sản

CNTT có với (quy trình) Thay đ ổi Kinh doanh hỗ trợ bởi CNTT,
Quản lý Dự án CNTT và B ảo m ật CNTT.
 Chính thức hóa các tương tác m à vi ệc m ua lại và quản lý tài
sản CNTT đang có với các chức năng và quy trình n ằm ngoài
CNTT.
 Cuối cùng, chính th ức hóa các bi ện pháp đo lường và báo cáo
trong lĩnh vực này bởi:
o Việc xác định các chỉ số và báo cáo về tài sản CNTT phù
hợp để phân phối trong toàn b ộ tổ chức khi phù hợp.
o Việc chính th ức hóa biện pháp kiểm soát và đo lường
chất lượng trong việc m ua lại và quản lý các tài sản
CNTT.

346
7.2 Các công cụ Quản lý Dịch vụ
Các công c ụ sẽ cho phép các quy trình Thi ết kế Dịch vụ hoạt động
m ột cách hi ệu quả hơn. Các công cụ sẽ gia tăng tính hi ệu quả và
hiệu suất, và cung cấp nhiều thông tin quản lý, dẫn đến việc xác
định các lĩnh vực còn yếu kém . Những lợi ích dài hạn sẽ thu được từ
việc sử dụng các công c ụ là tiết kiệm chi phí và tăng năng su ất, đế n
lượt m ình có th ể gia tăng ch ất lượng của việc cung c ấp dịch vụ
CNTT.
Việc sử dụng các công c ụ sẽ cho phép sự tập trung các quy trình
chính và tự động hóa và tích hợp của các quy trình Qu ản lý Dịch vụ
cốt lõi. Dữ liệu thô được thu thập bởi các các công c ụ có thể được
phân tích, d ẫn đến việc xác định ‘các xu hư ớng’. Các biện pháp
phòng ngừa sau đó có thể được triển khai, m ột lần nữa, cải thiện
chất lượng của việc cung c ấp dịch vụ CNTT.
Một số điểm m à tổ chức nên cân nh ắc khi đánh giá các công c ụ
Quản lý Dịch vụ bao gồm :
 Cấu trúc dữ liệu, xử lý và tích hợp dữ liệu.

 Sự tích hợp các thành ph ần cơ sở hạ tầng của nhiều nhà cung
cấp, và nhu cầu hấp thu các thành ph ần m ới trong tương lai –
những điều này sẽ đặt ra các nhu c ầu cụ thể về các năng lực
xử lý dữ liệu và m ô hình hóa c ủa các công c ụ.
 Sự phù hợp với các tiêu chu ẩn m ở của quốc tế.
 Tính linh hoạt trong triển khai, s ử dụng và chia s ẻ dữ liệu.
 Khả năng sử dụng – m ức độ dễ sử dụng được cho phép bởi
giao diện người dùng.
 Hỗ trợ giám sát các m ức dịch vụ.
 Các m áy khách phân tán v ới m ột cơ sở dữ liệu tập trung (ví d ụ
m áy khách – m áy chủ).
 Yêu cầu chuyển đổi đối với dữ liệu được theo dõi trước đó.
 Sao lưu, kiểm soát và b ảo m ật dữ liệu.
 Các tùy ch ọn hỗ trợ được cung cấp bởi nhà thầu cung cấp
công cụ.
 Khả năng m ở rộng khi tăng công su ất (số lượng người sử
dụng, khối lượng dữ liệu, v.v…).
Phải xem xét các yêu c ầu chính xác đ ối với công cụ. Các yêu cầu
bắt buộc là gì và các yêu c ầu m ong m uốn là gì? Nói chung, công c ụ
phải hỗ trợ các quy trình ch ứ không phải ngược lại, vì vậy hãy gi ảm
thiểu việc sửa đổi các quy trình đ ể phù hợp với công cụ. Nếu có thể,
tốt hơn hết là nên m ua m ột công cụ đã được tích hợp đầy đủ (m ặc
dù không phải trả giá bằng hiệu quả và hiệu suất) để củng cố rất
nhiều (nếu không nói là tất cả) các quy trình Qu ản lý Dịch vụ. Nếu
điều này là không khả thi, phải xem xét các tương tác giữa các công
cụ khác nhau.
Điều thiết yếu là phải có m ột Tuyên bố về Yêu cầu (SoR) để sử dụng

trong quá trình l ựa chọn - tuyên bố này có thể được sử dụng như

347
m ột ‘danh sách đánh d ấu’. Các yêu c ầu về công cụ nên được phân
loại bằng cách sử dụng phân tích MoSCoW :
 M – MUST – phải có.

 S – SHOULD – nên có toàn bộ, nếu có thể.
 C – COULD – có thể có nếu nó không ảnh hưởng tới bất cứ gì
khác.
 W – W ON’T – sẽ không có t ại thời điểm này nhưng S Ẽ có
trong tương lai.
Công cụ phải đủ linh hoạt để hỗ trợ cho các quyền truy cập cần thiết
của bạn. Bạn phải có khả năng xác đ ịnh ai được cấp phép truy c ập
vào dữ liệu nào và cho m ục đích gì, ví dụ: quyền đọc tới (dữ liệu)
khách hàng.
Trong giai đo ạn đầu, cũng cần phải xem xét n ền tảng m à công cụ sẽ
được dự định hoạt động trong đó – đây có thể là dựa trên phần cứng
và phần m ềm hiện có hoặc m ột giao dịch m ua sắm m ới. Có thể có
những hạn chế được đặt ra bởi chiến lược CNTT - ví dụ, m ọi sản
phẩm mới có thể phải nằm trên các m áy ch ủ cụ thể. Điều này có thể
hạn chế những sản phẩm nào có thể được đưa vào quá trình đánh
giá. Hãy đảm bảo rằng việc m ua sắm phù hợp với ngân sách đã
được phê duyệt hiện có.
Có rất nhiều công cụ Quản lý Dịch vụ có sẵn. Thông tin chi ti ết có

thể được tìm thấy trên Internet, các ấn phẩm Quản lý Dịch vụ, từ
việc hỏi các tổ chức khác, hỏi các chuyên gia tư vấn hoặc tham dự
các hội thảo, hội nghị để xem những sản phẩm nào đang có sẵn.
Trong giai đo ạn đầu của quá trình l ựa chọn, hãy nghĩ về độ tin cậy
của nhà cung c ấp và công c ụ. Họ (nhà cung cấp) vẫn sẽ hỗ trợ m ua
hàng trong thời gian vài tháng hay m ột năm ? Hãy xem xét hồ sơ quá
khứ của nhà cung c ấp cũng như của công c ụ. Hãy gọi điện thoại cho
Bộ phận Hỗ trợ Dịch vụ của nhà cung cấp để xem việc triển khai d ễ
dàng như thế nào và đặt m ột số câu hỏi kiểm tra để đánh giá năng
lực kỹ thuật của họ. Hãy yêu cầu nhà cung cấp sắp xếp m ột chuyến
viếng thăm đến địa điểm tham khảo để xem trải nghiệm với công c ụ
trong thực tế là gì - nếu có thể m à không có m ặt nhà cung cấp hoặc
nhà cung cấp. Đảm bảo rằng tổ chức có các yêu c ầu tương tự về
công cụ. Quan sát công cụ đang hoạt động và nói với người dùng về
trải nghiệm của họ, cả ban đầu và đang trong hiện tại.
Hãy đánh giá nhu c ầu đào t ạo của tổ chức và đánh giá năng lực của
nhà cung cấp để cung cấp được sự đào tạo thích hợp. Ngoài ra, vi ệc
đào t ạo cập nhật công cụ liên t ục và (nâng c ấp và thay đ ổi trong yêu
cầu của người dùng) s ẽ cần phải được đánh giá đ ể xác định chắc
chắn về chi phí h ỗ trợ và đào tạo. Đặc biệt, hãy xem xét chi phí đào
tạo, địa điểm đào tạo, thời gian c ần thiết, bao lâu sau khi đào t ạo
công cụ sẽ được sử dụng và trong quá trình triển khai dự án đảm
bảo rằng sự đào t ạo đầy đủ được cung c ấp - hãy nghĩ về cách công
cụ m ới sẽ tác động đến cả CNTT lẫn khách hàng như thế nào. Đồng

348
thời đảm bảo rằng các giao diện với các công c ụ và điện thoại khác
đang hoạt động bình thường. Điều khôn ngoan là xác đ ịnh xem li ệu
sự kết hợp theo k ế hoạch đã được sử dụng (hoặc chạy thử) ở nơi
nào khác và m ang l ại kết quả gì. Cân nh ắc các giai đo ạn chạy song
song cùng với các gi ải pháp hiện đang có trước khi đưa vào hoạt
động.
Khi đánh giá các công c ụ, m ột kết quả 100% phù hợp với các yêu
cầu không nên được kỳ vọng và hầu như chắc chắn sẽ không tìm
thấy. Thay vào đó, ‘quy t ắc 80/20’ sẽ có hiệu lực. Một công c ụ được
xem là phù hợp với m ục đích nếu nó đáp ứng được 80% hoặc hơn
các yêu c ầu vận hành c ủa doanh nghi ệp. Những yêu c ầu vận hành
đó nên được phân loại như đã được đề cập trước đây.
Bất kỳ sản phẩm nào cũng ph ải được t ừ chối là không phù h ợp nếu
m ọi yêu cầu bắt buộc (‘phải có’) không được đáp ứng. Trong m ột số
trường hợp, sẽ sẽ là không khả thi khi tìm kiếm m ột sản phẩm phần
m ềm hiện có đáp ứng tất cả các yêu c ầu bắt buộc hoặc cung cấp sự
phù hợp đến 80%. Trong tình hu ống này, s ản phẩm cung cấp thiết
kế chức năng tốt nhất nên được chọn và viết lại (lập trình l ại) các
yếu tố không phù h ợp. Quá trình nâng cao nà y nên được thực hiện
bởi nhà cung cấp nếu có thể. Trong m ột số trường hợp, người m ua
có thể phải trả m ột phần chi phí nâng c ấp. Một số sản phẩm đã
được thiết kế để bao gồm các m óc khóa người dùng - điều này cung
cấp khả năng truy c ập vào m ã được viết tại chỗ, tại các điểm thủ tục
chính m à không c ần phải sửa đổi gói.
Quá trình không k ết thúc khi s ản phẩm đã được chọn. Theo nhi ều
cách, đây chỉ có thể được xem là bước khởi đầu. Công c ụ bây giờ
phải được triển khai. Khi nền tảng phần cứng đã được chuẩn bị và
phần m ềm đã được tải, tập hợp dữ liệu cần phải được xem xét. Cái
gì, từ đâu, như th ế nào và khi nào? Thời gian đóng vai trò quan
trọng đối với các quy trình thử nghiệm, triển khai và ho ạt động thực
tế. Các nguồn lực phải sẵn sàng để đảm bảo cho sự thành công. Nói
cách khác, đừng lên lịch triển khai trong kho ảng thời gian b ận rộn
đã biết, chẳng hạn như xử lý cuối năm. Ngày nay, các s ản phẩm
'phần m ềm như m ột dịch vụ' có sẵn, trong đó phần cứng và ph ần
m ềm là không cần thiết. Các sản phẩm này cho phép truy c ập vào và
quản lý phần m ềm dựa trên-m ạng có sẵn trên thị trường. Những loại
sản phẩm này sẽ vẫn yêu cầu việc hoạch định và triển khai, nhưng
điều này sẽ làm đơn giản hóa quá trình vì không c ần đến phần cứng
chuyên dụng.
Sự cân nhắc cũng nên được đưa ra đ ối với các nhà cung c ấp dịch
vụ được quản lý và Nhà cung c ấp Dịch vụ Ứng dụng, những người
có thể cung cấp chức năng tương t ự.
Bất kể công cụ hoặc loại công c ụ nào được chọn, việc đáp ứng các
yêu cầu có thể được phân biệt giữa:
 Bên ngoài hộp (Out-of-the-box) – yêu cầu đã được đáp ứng.

349
 Cấu hình – công cụ có thể được cấu hình với x ngày n ỗ lực đ ể
đáp ứng yêu cầu và điều này sẽ được giữ nguyên qua các lần
nâng cấp sản phẩm .
 Tùy chỉnh – công cụ phải được lập trình lại với x ngày nỗ lực
để đáp ứng yêu c ầu, và điều này có thể được lặp lại m ỗi lần
nâng cấp sản phẩm .
Tốt nhất, việc tùy biến rộng rãi bất kỳ sản phẩm nào nên được tránh
bởi vì chi phí dành cho vi ệc nâng cấp sản phẩm rất cao. Các nhà
cung cấp có thể sẵn sàng hỗ trợ cho các phiên b ản phát hành cũ, và
người m ua có thể không có khả năng có nguồn lực để áp dụng lại
bất kỳ tùy chỉnh thiết kế riêng c ần thiết nào. Việc tùy chỉnh cũng c ó
thể giải phóng nhà cung c ấp khỏi phần lớn nghĩa vụ hỗ trợ của họ -
điều này có thể sẽ là tai hại nếu do đó m à hệ thống Quản lý Dịch vụ
của bạn không s ẵn sàng trong bât k ỳ khoảng thời gian nào.
Các chi phí khác có th ể phát sinh trong việc cung c ấp đào tạo được
thiết kế riêng m à có thể sẽ được yêu c ầu. Sẽ là không khả thi để tận
dụng bất kỳ khóa đào t ạo giá r ẻ theo lịch trình nào do nhà cung cấp
phần m ềm vận hành.
Quy trình đánh giá công c ụ được m inh họa trong Hình 7.1.
Hình 7.1 – Quy trình đánh giá công c ụ Quản lý Dịch vụ
Hình 7.1 m inh h ọa cho phương pháp ti ếp cận tiêu chuẩn trong việc x
xác định các yêu c ầu trước khi xác đ ịnh sản phẩm , nhưng trên thực
tế có thể có m ột số các yếu tố bị chồng chéo, nơi m à việc khám phá
các công c ụ trên thị trường m ở ra những tùy chọn m ới làm thay đổi
các yêu cầu của mọi người. Các giai đo ạn này được nhắm m ục tiêu
chủ yếu vào việc đánh giá các s ản phẩm phần m ềm được đóng gói,
tuy nhiên phương pháp ti ếp cận tương tự cũng có thể được sử dụng
khi đánh giá phần m ềm được xây dựng-tùy chỉnh. Hãy đưa ra m ột
Tuyên bố về các Yêu c ầu (SoR) rõ ràng xác đ ịnh các yêu cầu của
doanh nghi ệp cùng với các phương ti ện bắt buộc và những chức

350
năng m à nếu ‘có được thì rất tuyệt’. Đồng thời hãy xác định các
chính sách và tiêu chu ẩn về địa điểm và sản phẩm phải tuân th ủ.
Những tiêu chuẩn như vậy có thể bao gồm việc nó vận hành trong
phần m ềm hệ thống cụ thể nào, hoặc trên phần cứng cụ thể nào.
Hãy ghi nhớ những cân nh ắc về tính phù hợp của nhà cung cấp, và
tiến hành m ột đánh giá chính th ức về các sản phẩm đang được xem
xét.
Nếu các công c ụ thích hợp và được phát triển tốt được sử dụng để
hỗ trợ cho các quy trình, các k ết quả đạt được sẽ càng lớn hơn
nhiều và thường thì chi phí t ổng thể của việc cung c ấp dịch vụ sẽ ít
hơn. Việc lựa chọn công c ụ phù hợp có nghĩa là ph ải chú ý đến m ột
số vấn đề sau:
 Một tỷ lệ 80% phù h ợp vơi m ọi yêu c ầu kỹ thuật và chức năng.

 Một cuộc họp về MỌI yêu cầu bắt buộc.
 Ít (nếu có) tùy chỉnh sản phẩm được đòi hỏi.
 Sự tuân thủ của công cụ và nhà cung cấp đối với những thực
tiễn tốt nhất trong Quản lý Dịch vụ.
 Cấu trúc và xử lý dữ liệu hợp lý.
 Sự tích hợp với các công c ụ Quản lý Dịch vụ và Quản lý Vận
hành khác.
 Sự hỗ trợ của các tiêu chuẩn và giao di ện m ở.
 Định hướng-doanh nghi ệp chứ không phải định hướng-công
nghệ.
 Chi phí quản trị và bảo trì trong ngân sách.
 Các m ức độ có thể chấp nhận được của các chính sách b ảo trì
và phát hành.
 Bảo m ật và toàn vẹn.
 Tính sẵn sàng c ủa các dịch vụ đào tạo và tư vấn.
 Tạo ra báo cáo t ốt.
 Khả năng m ở rộng và tăng trưởng.
8 Triển khai Thiết kế Dịch vụ

Phần này của ấn phẩm sẽ xem xét nhiệm vụ triển khai các quy trình
Thiết kế Dịch vụ và giải quyết các vấn đề chẳng hạn như:
 Chúng ta bắt đầu từ đâu?

 Chúng ta s ẽ cải thiện như thế nào?
 Làm thế nào để chúng ta biêt được rằng chúng ta đang ti ế n
bộ?
Những hoạt động triển khai và c ải thiện Thiết kế Dịch vụ cần phải
tập trung vào nhu c ầu và m ong m uốn của doanh nghi ệp và củ a
khách hàng. Do đó, những hoạt động này nên đư ợc định hướng và
ưu tiên bởi:
 Nhu cầu của doanh nghiệp và tác đ ộng đến kinh doanh.
 Những rủi ro đối với các dịch vụ và quy trình.

351
Những hoạt động s ẽ phải chịu ảnh hưởng đáng k ể bởi các yêu c ầu
được phác thảo trong SLR và bởi các thỏa thuận được đưa ra trong
SLA.
8.1 Phân tích Tác đ ộng Kinh doanh

Một nguồn đầu vào vô giá khi c ố gắng xác m inh các nhu c ầu, tác
động và r ủi ro của doanh nghi ệp là Phân tích Tác đ ộng Kinh doanh
(Business Im pact Analysis – BIA). BIA là m ột thành phần thiết yếu
của quy trình liên t ục kinh doanh t ổng thể (xem phần 4.7) và sẽ đưa
ra chiến lược để giảm thiểu rủi ro và khôi phục sau thảm họa. Mục
đích thông thường của nó là xác đ ịnh ảnh hưởng của m ột thảm họa
sẽ có thể gây ra cho doanh nghi ệp. Nó sẽ cho thấy những bộ phận
nào của tổ chức sẽ bị ảnh hưởng nặng nề nhất bởi m ột sự cố
nghiêm trọng và nó ảnh hưởng như thế nào đến toàn thể công ty. Do
đó, nó cho phép công nh ận các chức năng nghiệp vụ quan tr ọng
nhất đối với sự tồn tại của công ty và m ức độ quan trọng này khác
nhau tùy thuộc vào thời gian theo ngày, tuần, tháng hoặc năm.
Ngoài ra, kinh nghi ệm đã cho thấy rằng các k ết quả từ BIA có thể là
m ột đầu vào c ực kỳ hữu ích cho m ột số các lĩnh vực khác, và cũng
sẽ cung cấp sự hiểu biết sâu sắc hơn nữa về dịch vụ so với các
trường hợp khác.
BIA có thể được chia thành hai lĩnh vực:
 Một là quản lý doanh nghiệp, vốn phải điều tra tác động của
tổn thất (hoặc tổn thất m ột phần) của m ột quy trình nghi ệp vụ
hoặc m ột chức năng nghi ệp vụ. Điều này bao gồm kiến thức
về những cách giải quyết thủ công và chi phí c ủa chúng.
 Vai trò thứ hai nằm ở Quản lý Dịch vụ là điều thiết yếu để phá
vỡ tác động c ủa việc tổn thất dịch vụ đối với doanh nghiệp.
Yếu tố này c ủa BIA cho th ấy tác động của sự gián đoạn dịch
vụ đối với doanh nghi ệp. Các dịch vụ có thể được quản lý và
chịu ảnh hưởng bởi Quản lý Dịch vụ. Các khía c ạnh khác cũng
được bao hàm trong ‘BIA Doanh nghi ệp’ không th ể bị ảnh
hưởng bởi Quản lý Dịch vụ.
Là m ột phần của giai đo ạn thiết kế m ột dịch vụ m ới hoặc đã được

thay đổi, m ột BIA nên được tiến hành để giúp xác định chiến lược
liên tục kinh doanh và đ ể cho phép s ự hiểu biết sâu sắc hơn về
chức năng và m ức độ quan trọng của dịch vụ. Điều này s ẽ cho phép
tổ chức xác định:
 Những dịch vụ nào là quan tr ọng, những gì c ấu thành nên m ột

sự cố nghiêm trọng đối với các dịch vụ đó, và những tác đ ộng
và sự gián đoạn tiếp theo đó gây ra cho doanh nghi ệp – điều
quan trọng trong vi ệc quyết định khi nào và làm cách nào đ ể
triển khai nh ững thay đổi.
 Các m ức có thể chấp nhận được và thời gian c ủa m ức độ
ngừng hoạt động dịch vụ - m ột lần nữa, là điều quan tr ọng
trong việc cân nhắc về sự thay đổi và các l ịch trình tri ển khai.

352
 Các chu k ỳ dịch vụ và chu k ỳ nghiệp vụ quan tr ọng – những
chu kỳ quan trọng cần tránh.
 Chi phí c ủa t ổn thất dịch vụ - quan tr ọng đối với Quản lý Tài
chính.
 Các tác động bảo m ật tiềm ẩn của tổn thất dịch vụ - các cân
nhắc quan trọng trong quản lý rủi ro.
8.2 Các Yêu cầu Mức Dịch vụ

Là m ột phần của quy trình Qu ản lý Mức Dịch vụ (xem Chương 4),
các Yêu cầu Mức Dịch vụ đối với m ọi dịch vụ sẽ được xác m inh và
khả năng cung cấp (các m ức dịch vụ) so với các yêu c ầu đó s ẽ được
đánh giá và cu ối cùng, được thỏa thuận trong m ột SLA chính th ức.
Đối với các dịch vụ m ới, các yêu c ầu phải được xác m inh ngay t ừ
giai đoạn bắt đầu quy trình phát tri ển, không phải sau khi hoàn
thành. Việc xây dựng dịch vụ với các Yêu cầu Mức Dịch vụ là m ối
quan tâm hàng đ ầu là điều thiết yếu, xét từ quan điểm Thiết kế Dịch
vụ.
8.3 Rủi ro đối với các dịch vụ và quy trình

Khi triển khai các quy trình Thi ết kế Dịch vụ và ITSM, các hoạt động
thực tiễn kinh doanh-như-thông thư ờng không b ị ảnh hưởng bất lợi
(bởi các quy trình đó). Khía c ạnh này ph ải được xem xét trong giai
đoạn đưa ra và lựa chọn giải pháp đư ợc ưa thích để đảm bảo rằng
sự gián đoạn đối với các dịch vụ vận hành được tối thiểu hóa. Sau
đó, đánh giá r ủi ro này nên được xem xét chi tiết trong các ho ạt
động Chuyển tiếp Dịch vụ như m ột phần của quy trình triển khai.
8.4 Triển khai Thiết kế Dịch vụ

Quy trình, chính sách và ki ến trúc đối với thiết kế các dịch vụ CNTT
được phác thảo trong ấn phẩm này s ẽ cần được lập thành văn bản
và được sử dụng để đảm bảo các dịch vụ CNTT sáng tạo thích hợp
có thể được thiết kế và triển khai để đáp ứng các yêu c ầu hiện tại
và tương lai của doanh nghi ệp.
Các quy trình Qu ản lý Dịch vụ CNTT được phác thảo trong Chương
4 của ấn phẩm này và trong các ấn phẩm khác trong loạt (ấn phẩm )
cũng sẽ cần phải được triển khai để đảm bảo dịch vụ cung cấp đáp
ứng được các yêu c ầu của doanh nghi ệp.
Có m ột câu hỏi thường được hỏi là ‘Quy trình nào tôi s ẽ triển khai
trước tiên?’ Câu tr ả lời trong thực t ế là tất cả chúng (các quy trình),
vì giá trị thực của việc triển khai m ọi quy trình Qu ản lý Dịch vụ lớn
hơn nhiều so với việc triển khai t ổng các quy trình riêng l ẻ. Mọi quy
trình đều liên quan, và trong m ột số trường hợp, phụ thuộc hoàn
toàn vào nh ững quy trình khác. Những gì được yêu c ầu cuối cùng là
m ột bộ các quy trình đư ợc tích hợp, cung c ấp sự quản lý và bi ện
pháp kiểm soát đối với m ột bộ các dịch vụ CNTT trong toàn bộ vòng
đời của chúng.
Khi thừa nhận điều này, để có được lợi ích hoàn toàn t ừ việc triển
khai Quản lý Dịch vụ CNTT, m ọi quy trình c ần được xác định, đồng

353
thời công nhận rằng tổ chức không có khả năng để có thể làm m ọi
thứ cùng m ột lúc. Do đó, chúng tôi khuy ến cáo rằng những lĩnh vực
quan trọng nhất cần được giải quyết trước tiên. Một đánh giá chi ti ết
cần được thực hiện để chứng m inh cho đi ểm mạnh và điểm yếu của
việc cung cấp dịch vụ CNTT. Việc này nên được thực hiện bằng
cách hoàn thành các kh ảo sát m ức độ hài lòng c ủa khách hàng, trao
đổi với khách hàng, trao đ ổi với nhân viên CNTT và phân tích các
quy trình đang ho ạt động. T ừ đánh giá này, nh ững chiến lược ngắn,
trung và dài h ạn có thể được phát triển.
Có thể m ột ‘chiến thắng sớm ’ cần được triển khai trong ngắn hạn để
cải thiện tình huống hiện tại, tuy nhiên các quy trình c ải thiện đó có
thể phải bị hủy bỏ hoặc điều chỉnh như m ột phần của các chi ến lược
trung và dài h ạn. Nếu ‘các chi ến thắng sớm ’ được triển khai, đi ều
quan trọng là chúng không nên đư ợc thực hiện với các chi phí cho
những m ục tiêu dài hạn, vì vậy, chúng phải được cân nhắc m ọi lúc.
Tuy nhiên, m ọi tổ chức sẽ phải bắt đầu ở đâu đó, và điểm bắt đầu
sẽ là bất cứ nơi đâu m à t ổ chức đang đứng xét về m ặt độ trưởng
thành của Quản lý Dịch vụ CNTT.
Các m ức độ ưu tiên tri ển khai nên được thiết lập so với các m ục tiêu
của m ột SIP. Ví dụ, nếu tính sẵn sàng của các dịch vụ CNTT là m ột
vấn đề quan trọng, trọng tâm của các quy trình đó đư ợc nhắm m ục
tiêu đến việc tối đa hóa tính s ẵn sàng (ví d ụ, Quản lý Sự cố, Quản lý
Vấn đề, Quản lý Thay đ ổi và Quản lý Tính S ẵn sàng). Trong toàn b ộ
quá trình tri ển khai, các vai trò ch ủ chốt phải tham gia vào quy trình
đưa ra quyết định. Họ (các vai trò ch ủ chốt) sẽ bao gồm cả người
nhận dịch vụ cũng như người cung c ấp dịch vụ. Có thể trở thành
m ột xu hướng khi phân tích các lĩnh v ực cần thiết nhất và đi th ẳng
vào các công cụ để cải thiện tình hu ống. Các hội thảo hoặc các
nhóm trọng tâm sẽ có lợi trong việc hiểu các yêu c ầu và quy trình
phù hợp nhất cho vi ệc triển khai, s ẽ bao gồm con người, các quy
trình, sản phẩm và đối tác.
Việc đầu tiên c ần thực hiện là thiết lập m ột quy trình và phương
pháp chính thức để triển khai và c ải thiện Thiết kế Dịch vụ, cùng với
sự quản trị thích hợp có s ẵn. Quy trình chính th ức này nên có cơ s ở
xoay quanh quy trình 6 -giai đoạn được m inh họa trong Hình 8.1.
Thông tin thêm về quy trình này cũng có th ể được tìm thấy trong ấn
phẩm Liên tục Cải tiến Dịch vụ.
Điều quan trọng là khi triển khai hoặc cải tiến các quy trình, m ột
phương pháp Qu ản lý Dự án có c ấu trúc được sử dụng. Trước tiên,
quá trình cải tiến có thể được tóm tắt là việc hiểu được tầm nhìn
bằng cách xác m inh chắc chắn các m ục tiêu kinh doanh c ấp cao.
Việc 'thiết lập tầm nhìn' nên thiết lập và liên kết các chiến lược kinh
doanh và CNTT. Th ứ hai, hãy đánh giá tình hình hi ện tại để xác định
những điểm m ạnh để có thể xây dựng trên nó và những điểm yếu
cần phải được giải quyết. Vì vậy, ‘Chúng ta đang ở đâu?’ là m ột
phân tích vị thế hiện tại về m ặt doanh nghiệp, tổ chức, con người và
quy trình. Th ứ ba, ‘Chúng ta m uốn ở đâu?’ là sự phát t riển của các

354
nguyên t ắc đã được xác định trong ‘thiết lập tầm nhìn’, thống nhất
các ưu tiên cải tiến, và thứ tư, nêu chi tiết SIP để đạt được việc
cung cấp dịch vụ có chất lượng cao hơn. Tiếp theo, các phép đo
lường và chỉ số cần được đưa ra đ ể m inh họa rằng các cột m ốc
quan trọng đã đạt được và các m ục tiêu kinh doanh cũng như ưu
tiên của doanh nghiệp đã được đáp ứng. Cuối cùng, quá trình này
phải đảm bảo rằng động lực cải tiến chất lượng được duy trì.
Sau đây là các yếu tố chính để liên kết thành công các m ục tiêu
CNTT với các m ục tiêu kinh doanh:
 Tầm nhìn và khả năng lãnh đ ạo trong vi ệc thiết lập và duy trì
định hướng chiến lược, m ục tiêu rõ ràng và phương pháp đo
lường việc hiện thực hóa m ục tiêu theo đ ịnh hướng chiến
lược.
 Chấp nhận sự đổi mới và cách l àm việc mới.
 Hiểu biết kỹ lưỡng về doanh nghi ệp, các bên liên quan và m ôi
trường của nó.
 Nhân viên CNTT hiểu được nhu cầu của doanh nghiệp.
 Doanh nghiệp hiểu được tiềm năng của CNTT.
 Thông tin và truyền thông có sẵn và có thể tiếp cận được đối
với những ai cần nó.
 Phân bổ thời gian một cách riêng bi ệt để làm quen với tài liệu.
 Theo dõi liên t ục các công ngh ệ để xác định các cơ hội cho
doanh nghiệp.
Chu trình triển khai/cải tiến rất hữu ích trong vi ệc kiểm tra s ự liên
kết giữa doanh nghi ệp và CNTT, như được thể hiện trong Hình 8.1.
Hình 8.1 – Chu trình triển khai/cải tiến

355
8.4.1 Tầm nhìn là gì?
Điểm khởi đầu cho m ọi hoạt động trên là văn hóa và m ôi trư ờng của
tổ chức cung c ấp dịch vụ. Con người và văn hóa phải tương xứng và
có thể chấp nhận để cải thiện và thay đổi. Do đó, trước khi c ố gắng
bất kỳ điều gì khác, văn hóa trong n ội bộ nhà cung c ấp dịch vụ cần
được xem xét đ ể đảm bảo rằng nó (văn hóa) s ẽ chấp nhận và t ạo
điều kiện cho việc triển khai các thay đ ổi và cải thiện cần thiết. Các
bước chủ yếu sau đây c ần được hoàn thành đ ể đạt được (kết quả)
giai đoạn này của chu trình:
 Thiết lập m ột tầm nhìn, được liên kết với tầm nhìn và các m ục
tiêu của doanh nghi ệp.
 Thiết lập m ột phạm vi của dự án/chương trình.
 Thiết lập m ột bộ các m ục tiêu cao cấp.
 Thiết lập việc quản trị, bảo trợ và ngân sách.
 Đạt được cam kết từ các quản lý c ấp cao.
 Thiết lập m ột văn hóa đư ợc tập trung vào:
o Chất lượng.
o Trọng tâm khách hàng và doanh nghi ệp.
o Một m ôi trường học tập.
o Liên tục cải thiện.
o Cam kết đối với ‘chu trình c ải thiện’.
o Sự sở hữu và tinh thần trách nhi ệm
8.4.2 Chúng ta đang ở đâu?

Khi tầm nhìn và các m ục tiêu cấp cao đã đư ợc xác định, sau đó nhà
cung cấp dịch vụ cần phải xem xét tình huống hiện tại, xét về m ặt
những quy trình nào đang có s ẵn và m ức độ trưởng thành c ủa tổ
chức. Các bước và các hoạt động cần phải được hoàn thành ở đây
bao gồm :
 Một xem xét, đánh giá ho ặc kiểm toán chính thức hơn về tình
huống hiện tại, sử dụng m ột kỹ thuật được ưa thích:
o Một xem xét hoặc kiểm toán nội bộ.
o Đánh giá m ức độ trưởng thành.
o Một đánh giá ho ặc điểm chuẩn so sánh bên ngoài.
o Một kiểm toán ISO/IEC 20000.
o Một phân tích Đi ểm m ạnh, Điểm yếu, Cơ hội và Mối đe
dọa (Strengths, W eaknesses, Opportunities và Threats –
SW OT).
o Một phương pháp đánh giá và qu ản lý rủi ro.
 Việc xem xét nên bao g ồm :
o Văn hóa và độ trưởng thành c ủa tổ chức cung c ấp dịch
vụ.
o Các quy trình có s ẵn và năng l ực và độ trưởng thành
của chúng.
o Các k ỹ năng và năng l ực của con người.
o Các dịch vụ và công nghệ.
o Các nhà cung c ấp, hợp đồng và năng l ực của họ.
o Chất lượng của dịch vụ và các phương pháp đo lường,
chỉ số và KPI hiện tại.

356
o Một báo cáo t ổng hợp về những phát hiện và các khuyến
nghị.
Việc xem xét văn hóa nên bao g ồm sự đánh giá văn hóa xét v ề m ặt
năng lực và độ trưởng thành c ủa văn hóa trong t ổ chức cung c ấp
dịch vụ CNTT, như được m inh họa trong Hình 8.2.
Hình 8.2 – Đánh giá độ trưởng thành văn hóa
Việc đánh giá này nên đư ợc căn cứ vào thực tế rằng m ỗi giai đo ạn
tăng trưởng thể hiện cho m ột sự chuyển đổi của tổ chức CNTT và
như vậy sẽ yêu cầu:
 Những thay đ ổi về con người (các k ỹ năng và năng lực).

 Các quy trình và cách th ức làm vi ệc.
 Công nghệ và các công cụ (để hỗ trợ và cho phép con ngư ời
và các quy trình).
 Sự chỉ đạo (t ầm nhìn, m ục tiêu và kết quả).
 Thái độ (các giá tr ị và niềm tin).
 Mức độ phù hợp của sự tương tác với doanh nghi ệp, các bê n
liên quan, khách hàng và ngư ời sử dụng.
Việc đánh giá cũng nên bao g ồm m ột xem xét về năng lực và độ
trưởng thành c ủa các quy trình Thi ết kế Dịch vụ, như được m inh h ọa
trong Hình 8.3.

357
Hình 8.3 – Khuôn khổ trưởng thành của quy trình
Đánh giá này và nên bao gồm m ọi khía c ạnh của quy trình và vi ệc
sử dụng chúng, bao gồm :
 Tầm nhìn: sự chỉ đạo, các m ục tiêu và k ế hoạch.

 Độ trưởng thành, chức năng, sử dụng, ứng dụng, tính hi ệu
quả và hiệu suất của quy trình cùng với quyền sở hữu, quản lý
và tài liệu.
 Con người: vai trò, trách nhi ệm , kỹ năng và ki ến thức của con
người.
 Các sản phẩm , bao gồm các công c ụ và công nghệ được sử
dụng để tự động hóa các quy trình.
 Văn hóa: trọng tâm , thái đ ộ và niềm tin.
Khuôn khổ trên đây có thể được sử dụng để m ang lại tính nhất quán
cho việc đánh giá qu y trình. Việc đánh giá hai khía c ạnh này s ẽ xác
định tình tr ạng hiện tại của tổ chức và năng lực Quản lý Dịch vụ và
sự trưởng thành của tổ chức. Khi bắt đầu triển khai hoặc cải tiến
Thiết kế Dịch vụ, hoặc bất kỳ bộ quy trình nào, đi ều quan trọng là
phải xây dựng dựa trên những điểm m ạnh của các văn hóa và quy
trình hiện có, đồng thời nhanh chóng xác đ ịnh và c ải thiện những
điểm yếu. Phần giải thích chi tiết hơn về khuôn khổ này có trong
Phụ lục H.
8.4.3 Chúng ta muốn ở đâu

Dựa trên đánh gi á về tình trạng hiện tại, và tầm nhìn và các m ục
tiêu cấp cao, m ột tương lai m ong m u ốn có thể được xác định. Điều
này nên được thể hiện dưới dạng các k ết quả đã được lên kế hoạch,
bao gồm m ột số hoặc tất cả:
 Việc cung c ấp dịch vụ CNTT đã cải thiện được liên kết với các
yêu cầu tổng thể của doanh nghi ệp.

358
 Chất lượng được cải thiện của Thiết kế Dịch vụ.
 Những cải thiện trong m ức và chất lượng dịch vụ.
 Gia tăng m ức độ hài lòng c ủa khách hàng.
 Những cải thiện trong hi ệu suất quy trình.
8.4.4 Làm th ế nào đ ể chúng ta đi đến đó?

Sau đó, m ột bộ các biện pháp c ải tiến nên đư ợc xác định để tiến lên
phía trước từ tình trạng hiện tại đến tình trạng tương lai đã th ống
nhất. Tiếp theo, m ột kế hoạch để triển khai các biện pháp cải thiện
đó nên được phát triển, kết hợp với Chuyển tiếp Dịch vụ và Vận
hành Dịch vụ, và nên bao g ồm :
 Các hành động cải thiện.

 Phương pháp ti ếp cận đưuọc thực hiện và các phương pháp
được sử dụng.
 Các hoạt động và khung thời gian.
 Đánh giá và qu ản lý rủi ro.
 Tài nguyên và ngân sách.
 Vai trò và trách nhi ệm .
 Sự giám sát, đo lường và đánh giá.
8.4.5 Làm th ế nào chúng ta có th ể biết khi chúng ta đã đ ến đó?

Thông thường, các tổ chức đưa ra các sáng ki ến cải tiến m à không
xem xét hoặc thiết kế hệ thống đo lư ờng ngay từ đầu. Do đó, sự
thành công của sáng ki ến không thể được xác định chắc chắn bởi vì
chúng ta không có điểm chuẩn so sánh nào trước, trong ho ặc sau
khi triển khai. Điều bắt buộc là các phép đo ph ải được thiết kế trước
khi triển khai. Một bộ chỉ số đã được xác định sẽ phải được sử dụng
để đảm bảo đạt được trạng thái m ong m uốn trong tương lai. Tr ạng
thái tương lai m ong m u ốn này cần được thể hiện bằng các thu ật ngữ
có thể đo lường được như:
 Giảm X% sự không phù hợp của Thiết kế Dịch vụ.

 Mức độ hài lòng của khách hàng tăng lên X% .
 Tăng X% kh ả năng cung c ấp dịch vụ của các dịch vụ quan
trọng.
Do đó, khi các hành đ ộng và k ế hoạch cải tiến đã được hoàn thành,
việc kiểm tra và đánh giá cũng cần được hoàn tất để xác định:
 Chúng ta đã đạt được trạng thái và các m ục tiêu m ới m ong

m uốn không?
 Có bài học kinh nghi ệm nào k hông và chúng ta có th ể làm tốt
hơn vào lần sau không?
 Chúng ta có xác đ ịnh bất kỳ hành động cải tiến nào khác
không?
8.4.6 Chúng ta s ẽ tiếp tục như thế nào?

Sau khi đã được cải thiện, bây giờ chúng ta c ần củng cố và tiếp tục.
Tổ chức và văn hóa phải nhận ra rằng chúng ta luôn có th ể trở nên
tốt hơn, và do đó cần phải thiết lập m ột m ôi trường cải tiến liên tục.
Vì vậy, khi đã đạt được trạng thái m ong m uốn m ới, chúng ta ph ải

359
xem xét lại tầm nhìn và các m ục tiêu, xác đ ịnh thêm các hành đ ộng
cải tiến và lặp lại quy trình sáu giai đo ạn m ột lần nữa. Vì vậy, giai
đoạn này là t ất cả về:
 Phát triển m ôi trường học tập.

 Xác lập m ong m uốn cải tiến trong toàn bộ tổ chức.
 Công nhận và củng cố thông điệp rằng chất lượng và c ải tiến
là công vi ệc của tất cả m ọi người.
 Duy trì động lực cải tiến và chất lượng.
8.5 Đo lường Thi ết kế Dịch vụ

Sự thành công của Thiết kế Dịch vụ và thành công c ủa sự cải thiệ n
đối với các quy trình xoay quanh Thi ết kế Dịch vụ phải được đo
lường, dữ liệu phải được phân tích và báo cáo. Khi thiết kế hoặc
quy trình không đáp ứng được các yêu cầu của doanh nghi ệp nói
chung, những thay đổi đối với quy trình có th ể là cần thiết và kết
quả của những thay đổi đó cũng ph ải được đo lường. Liên t ục đo
lường, phân tích và báo cáo là yêu c ầu bắt buộc đối với cả quy trình
Thiết kế Dịch vụ và các quy trình ITSM.
Có m ột số phương pháp đo lư ờng sẵn có cho phép phân tích c ải tiến

dịch vụ. Thẻ điểm Cân bằng (Balanced Scorecard) là m ột phương
pháp được phát tri ển bởi Robert Kaplan và David Norton như là m ột
ý tưởng để đo lường các hoạt động của m ột công ty xét về m ặt tầm
nhìn và chiến lược của họ. Nó cung c ấp m ột cái nhìn toàn di ện về
hiệu suất của m ột doanh nghiệp. Hệ thống bắt buộc các nhà qu ản lý
tập trung vào các ch ỉ số hiệu suất quan trọng định hướng cho s ự
thành công. Nó câ n bằng m ột quan điểm tài chính với khách hàng,
các quy trình nội bộ với các quan đi ểm về học tập và tăng trư ởng.
Thông tin thêm về phưong pháp Th ẻ điểm Cân bằng có thể tìm thấy
trong ấn phẩm Liên tục Cải tiến Dịch vụ.
Six Sigm a là m ột phương pháp lu ận được phát triển bởi Bill Sm ith
tại Motorola Inc. vào năm 1986, và ban đ ầu được thiết kế để quản lý
các biến thể của quy trình gây ra các khiếm khuyết, được xác định
là các phương sai không th ể chấp nhận được so với giá trị trung
bình hoặc so với đích nhắm m ục tiêu, và đ ể làm việc m ột cách có h ệ
thống hướng đến sự quản lý biến thể để loại bỏ những khiếm
khuyết đó. Six Sigma giờ đây đã phát triển vượt quá biện pháp ki ểm
soát khiếm khuyết và thường được sử dụng để đo lường sự cải tiến
trong việc thực thi quy trìn h CNTT. (Six Sigm a là m ột nhãn hiệu dịc h
vụ đã được đăng ký và nhãn hi ệu thương m ại của Motorola Inc.).
Sis Sigm a (DMADV) là m ột hệ thống cải tiến được sử dụng để phát

triển các quy trình m ới với m ức chất lượng Six Sigm a và đư ợc định
nghĩa là:
 Xác định/Define – xác định m ột cách chính thức các m ục tiêu

của hoạt động thiết kế nhất quán với các yêu cầu của khách
hàng và chi ến lược của tổ chức.

360
 Đo lường/Measure – xác định các Yếu tố Thành công Quan
trọng, năng l ực, năng lực quy trình, và đánh giá r ủi ro.
 Phân tích/ Anal yse – phát triển và thi ết kế các giải pháp thay
thế, tạo ra các thi ết kế cao cấp và đánh giá năng l ực thiết kế
để lựa chọn thiết kế tốt nhất.
 Thiết kế/Design - phát triển thiết kế chi tiết, tối ưu hóa thi ết
kế và lập kế hoạch để kiểm chứng thiết kế.
 Kiểm chứng/Verif y – thiết lập việc chạy thử, triển khai quy
trình thực tế và bàn giao cho chủ sở hữu quy trình.
Quy trình Six Sigm a (DMA IC) (xác định, đo lường, phân tích, c ải tiến
(Im prove), ki ểm soát (Control) ) là m ột hệ thống cải tiến cho các quy
trình hiện có thấp hơn các đặc tả kỹ thuật và tìm kiếm sự cải tiến gia
tăng.
8.5.1 Các yếu tố tiên quyết để thành công

Có m ột số điều kiện tiên quyết cần thiết cho Thiết kế Dịch vụ và cho
sự giới thiệu thành công các quy trình m ới hoặc đã được điều chỉnh.
Thường t hì những điều kiện tiên quyết để thành công này (PFSs) là
những yếu tố của m ột quy trình đư ợc yêu c ầu bởi m ột quy trình
khác. Ví dụ, Mục lục Dịch vụ Nghiệp vụ và Mục lục Dịch vụ Kỹ thuật
hoàn chỉnh hoàn toàn và được cập nhật được yêu cầu trước khi
Quản lý Mức Dịch vụ có thể thiết kế SLA và cấu trúc thỏa thuận hỗ
trợ, và trước khi SLM có thể thiết lập m ột thỏa thuận với các SLA.
Quản lý Vấn đề sẽ phụ thuộc vào m ột quy trình Qu ản lý Sự cố thành
thục. Các PFS có thể sẽ rộng hơn nhiều so với chỉ sự phụ thuộc lẫn
nhau của quy trình ITSM. Ví d ụ, thiết kế của tính sẵn sàng và công
suất cho m ột dịch vụ m ới không th ể đạt được m à không có các chi
tiết của kế hoạch kinh doanh để sử dụng dịch vụ m ới. Thiết kế của
dịch vụ sẽ là bất khả thi nếu không có Danh m ục Dịch vụ và Gói
Thiết kế Dịch vụ. Còn có r ất nhiều ví dụ khác nữa về những PFS này
cần được xem xét và l ập kế hoạch trước khi có thể đạt được m ức độ
thành thục của quy trình cao. M ức độ thành thục thấp của m ột quy
trình sẽ có nghĩa là các m ức độ thành thục cao sẽ không thể đạt
được trong các quy trình khác.
8.5.2 Các Yếu tố Thành công Quan tr ọng và Chỉ số Hiệu suất
Chính yếu
Yếu tố Thành công Quan tr ọng (CSF) là m ột thuật ngữ về m ột yếu tố
cần thiết cho m ột tổ chức hoặc dự án để đạt được sứ m ệnh của
mình. Các CSF có th ể được sử dụng như m ột phương ti ện để xác
định các yếu tố quan trọng của thành công.
CSF là những thứ phải có ngay trong Thi ết kế Dịch vụ và trong m ỗi

quy trình ITSM. Các Ch ỉ số Hiệu suất Chính yếu (KPI) là các thước
đo lượng hóa các m ục tiêu và cho phép đo l ường về hiệu suất. Các
KPI nên được thiết lập và đo lường so với thiết kế và cho từng quy
trình để đảm bảo các CSF được đáp ứng. Cùng với nhau, các CSF
và KPI thiết lập đường cơ sở và các cơ chế để theo dõi hiệu suất.

361
Chúng tôi khuyến cáo rằng m ỗi tổ chức CNTT nên t ập trung vào m ột
nhóm nhỏ các CSF và KPI tại cùng m ột thời điểm . Các CSF và KPI
bắt buộc phải được đặt ở phần bắt đầu của Kế hoạch Cải tiến Dịch
vụ Liên t ục (CSIP).
Điều quan trọng là các CSF đư ợc thống nhất trong giai đo ạn thiết kế
của m ột dịch vụ và các qu y trình, và các Ch ỉ số Hiệu suất Chính yếu
(KPI) được thiết lập, đo lường và báo cáo đ ể chỉ ra chất lượng của
Thiết kế Dịch vụ và các quy trình Thiết kế Dịch vụ. Có m ột yêu c ầu
để có thể phân tích cơ sở hạ tầng dịch vụ được thiết kế tốt như thế
nào. Có khả năng là s ẽ đạt được m ột thiết kế tốt nhưng không hi ệu
quả về nguồn lực và ngược lại, vì vậy chúng ta cần xem xét ch ất
lượng cũng như các ngu ồn lực cần thiết để đạt được chất lượng yêu
cầu. Các KPI xung quanh s ự thành công c ủa việc cung c ấp dịch vụ
cho thấy tính hiệu quả của Thiết kế Dịch vụ có thể áp dụng được - ví
dụ: dịch vụ có đáp ứng các yêu c ầu kinh doanh (đã được xác định)
về tính sẵn sàng, độ tin cậy, thông lư ợng, bảo m ật, khả năng bảo
trì, khả năng phục vụ, chức năng, v.v… hay không. Tuy nhiên, các
KPI xung quanh các ước tính về tài nguyên sẽ cho chúng ta th ấy
rằng chúng ta đã thi ết kế hiệu quả đến m ức nào.
Những điều này nên được xác định như m ột phần của hoạch định
QA và chấp thuận phiên b ản phát hành. Các KPI này có th ể được hỗ
trợ bởi các chỉ số thành phần tương t ự.
Các KPI đối với quy trình Thiết kế Dịch vụ bao gồm :
 Tỷ lệ phần trăm của các đặc tả kỹ thuật yêu c ầu Thiết kế Dịch

vụ được đưa ra đúng h ạn (và trong ngân sách).
 Tỷ lệ phần trăm các kế hoạch Thiết kế Dịch vụ được đưa ra
đúng hạn.
 Tỷ lệ phần trăm các gói Thi ết kế Dịch vụ được hoàn thành
đúng hạn.
 Tỷ lệ phần trăm các kế hoạch QA và tiêu chí ch ấp thuận được
đưa ra đúng hạn.
 Độ chính xác của Thiết kế Dịch vụ - ví dụ, cơ sở hạ tầng phù
hợp có đã được xây dựng để hỗ trợ cho dịch vụ không?
 Tỷ lệ phần trăm độ chính xác của ước tính chi phí của toàn thể
giai đoạn Thiết kế Dịch vụ.
 Độ chính xác c ủa (các) SLA, (các) SLR và (các) h ợp đồng –
chúng có th ực sự hỗ trợ cho m ức dịch vụ được yêu cầu
không?
Để đánh giá hiệu suất cung c ấp dịch vụ và hiệu suất của quy trình
ITSM, các m ục tiêu đư ợc xác định m ột cách rõ ràng với các đích
nhắm m ục tiêu có th ể đo lường được phải được thiết lập.
Cần phải xác nhận rằng các m ục tiêu này và các cột m ốc quan tr ọng
được thiết lập trong giai đo ạn Liên t ục Cải tiến Dịch vụ (CSI) c ủa
vòng đời đã đạt được và chất lượng dịch vụ m ong m uốn hoặc cải
tiến chất lượng m ong m uốn đã đạt được. Điều sống còn khi thiết kế

362
các dịch vụ hoặc quy trình là các KPI được thiết kế ngay từ đầu và
được thu thập m ột cách thường xuyên và ở các cột m ốc quan trọng.
Ví dụ, khi thiết kế ở giai đoạn hoàn thành của m ỗi giai đo ạn quan
trọng của chương trình, m ột Đánh giá sau Triển khai (PIR) nên đượ c
tiến hành để đảm bảo các m ục tiêu đã được đáp ứng. PIR s ẽ bao
gồm việc xem xét tài li ệu hỗ trợ và nhận thức chung giữa các nhân
viên về các quá trình đã đư ợc tinh chỉnh.
Một sự so sánh về những gì đã đạt được so với m ục tiêu ban đầu

đặt ra trong dự án là cần thiết. Khi điều này đã đư ợc xác nh ận, các
đích nhắm mục tiêu cải tiến m ới cần được xác định. Để xác nhận
rằng các cột m ốc đã đạt được, các KPI cần được theo dõi m ột cách
liên tục. Các KPI này bao g ồm các đích nhắm mục tiêu về sự hài
lòng của khách hàng, vì v ậy sẽ cần phải khảo sát khách hàng đã
được lên kế hoạch ở các giai đoạn khác nhau để xác nhận rằng
những thay đổi được thực hiện đang c ải thiện nhận thức của khách
hàng về chất lượng dịch vụ. Có khả năng r ằng các dịch vụ có tính
sẵn sàng cao hơn, ít s ự cố hơn và th ời gian phản hồi đã được cải
thiện, nhưng đồng thời nhận thức của khách hàng về chất lượng
dịch vụ vẫn chưa được cải thiện. Rõ ràng đây là đi ều quan tr ọng và
cần được giải quyết bằng cách trao đổi với khách hàng để xác định
chắc chắn m ối quan tâm của họ. Cần phải xác nhận rằng các CSI
được đưa ra đang giải quyết nhu cầu chính c ủa khách hàng.
Để có thêm thông tin v ề thực tiễn cải tiến dịch vụ, vui lòng tham
khảo thêm ấn phẩm Liên t ục Cải tiến Dịch vụ.
9 Những thách thức, các Yếu tố Thành công quan trọng và

các rủi ro
9.1 Những thách thức
Với m ỗi công việc, sẽ có những thách thức hoặc khó khăn phải đối
m ặt và vượt qua. Đi ều này đặc biệt đúng khi cố gắng thiết kế những
dịch vụ và quy trình m ới để đáp ứng các yêu c ầu của m ọi bên có liên
quan trong doanh nghi ệp. Kinh nghiệm đã cho th ấy rằng những điều
sau đây s ẽ giúp vư ợt qua những thách thức:
 Hiểu về các yêu cầu và các ưu tiên c ủa doanh nghi ệp và đảm

bảo rằng chúng luôn đư ợc quan tâm hàng đ ầu khi thi ết kế các
quy trình và d ịch vụ.
 Truyền thông s ẽ cực kỳ quan trọng trong c ả việc giải thích
những gì đang xảy ra và cách m à các cá nhân s ẽ bị ảnh
hưởng như thế nào và trong vi ệc lắng nghe các yêu c ầu và
nhu cầu của các cá nhân. Đi ều cực kỳ quan trọng là giao tiếp
với m ọi người về những m ối quan tâm liên quan đ ến công vi ệc
hàng ngày c ủa họ.
 Càng nhiều người tham gia vào vi ệc thiết kế càng t ốt. Việc
thiết lập các nhóm t ập trung hoặc các nhóm chỉ đạo có thể rất
hiệu quả trong việc đưa ra được giải pháp phù hợp cũng nhue
nhận được sự ủng hộ rộng rãi hơn n ữa.
 Nhận được sự cam kết từ quản lý c ấp cao cũng như t ừ tất cả
các cấp nhân viên.

363
Những ví dụ về các thách thức có thể phải đối m ặt bao gồm:
 Nhu cầu đảm bảo sự liên kết với các định hướng, chiến lược
và chính sách v ề kiến trúc hiện tại. Một ví dụ về việc này có
thể là cơ sở hạ tầng đã được m ua sắm có thể có các chứ c
năng giám sát và ki ểm soát kém .
 Việc sử dụng các công ngh ệ và ứng dụng đa dạng và khác
nhau.
 Tài liệu hóa và tuân th ủ với những thực tiễn và quy trình đã
được thống nhất.
 Các yêu cầu không rõ ràng ho ặc bị thay đổi từ phía doanh
nghiệp. Điều này có thể là không th ể tránh khỏi trong m ột số
trường hợp bởi vì các nhu cầu doanh luôn có khả năng thay
đổi. Điều quan trọng là phải đảm bảo rằng có m ột m ối quan h ệ
chặt chẽ giữa tổ chức cung c ấp dịch vụ CNTT và khách hàng
doanh nghiệp của dịch vụ, để từ đó bất kỳ yêu cầu thay đổi
nào đều có thể được xác định càng nhanh chóng càng t ốt.
 Thiếu nhận thức và kiến thức về dịch vụ và các đích nhắm
m ục tiêu và yêu c ầu.
 Được liên k ết với điều nói trên, có thể là m ột số cơ sở vật chất
không được tích hợp vào trong thiết kế. Một lần nữa, điều bắt
buộc là các đại diện của m ọi người sử dụng dịch vụ hoặc quy
trình đã được thiết kế phải được tham gia trong su ốt quá trình
để giảm nguy cơ đi ều này xảy ra. Những chi tiết về kiểm
nghiệm dịch vụ (một yếu tố quan trọng ở đây) được đề cập
trong ấn phẩm Chuyển tiếp Dịch vụ.
 Sự phản kháng chống lại việc hoạch định, hoặc thiếu hoạch
định dẫn đến các sáng kiến và m ua hàng không theo đúng kế
hoạch.
 Sử dụng tài nguyên không hi ệu quả gây lãng phí chi tiêu và
đầu tư.
 Như đã đề cập trước đây, có kiến thức tốt và đánh giá đúng về
các tác động và ưu tiên c ủa doanh nghi ệp là điều bắt buộc.
 Mối quan hệ, giao tiếp kém hoặc thiếu sự hợp tác giữa nhà
cung cấp dịch vụ CNTT và doanh nghi ệp có thể dẫn đến việc
thiết kế không đáp ứng được các yêu c ầu của doanh nghi ệp.
 Sự phản kháng lại việc làm việc theo chiến lược đã thỏa
thuận.
 Sử dụng, và do đó là nh ững hạn chế của công nghệ cũ và các
hệ thống kế thừa.
 Các công cụ cần thiết quá tốn kém hoặc quá phức tạp để triển
khai hoặc duy trì với các kỹ năng hiện tại của nhân viên.
 Thiếu thông tin, giám sát và đo lường.
 Các đích nhắm mục tiêu và khoảng thời gian không hợp lý đã
được thỏa thuận trước đó trong các SLA và OLA.
 Cam kết quá m ức đối với các ngu ồn lực sẵn có kèm theo
tương ứng là không có kh ả năng cung cấp (ví dụ: các dự án
luôn trễ hạn hoặc vượt quá ngân sách).
 Quản lý nhà cung c ấp kém và/hoặc hiệu quả hoạt động của
nhà cung c ấp kém .
 Thiếu tập trung vào tính sẵn sàng của dịch vụ.

364
 Thiếu nhận thức và tuân thủ các khía cạnh vận hành của các
chính sách và th ủ tục bảo m ật.
 Đảm bảo hoạt động hàng ngày bình thường hoặc kinh doanh
như bình thường được coi là m ột phần của thiết kế.
 Ràng buộc về chi phí và ngân sách.
 Xác định ROI và việc hiện thực hóa lợi ích kinh doanh.
9.2 Các Rủi ro

Có m ột số rủi ro tr ực tiếp liên quan với giai đoạn Thiết kế Dịch vụ
của Vòng đời Dịch vụ. Những rủi ro này c ần phải được xác định để
đảm bảo rằng chúng không đư ợc hiện thực hóa. Chúng (các r ủi ro)
bao gồm :
 Nếu bất kỳ PFS nào đối với Thiết kế Dịch vụ không được đáp
ứng thì quy trình Thi ết kế Dịch vụ hoặc Quản lý Dịch vụ sẽ
không thành công.
 Nếu m ức thành thục của m ột quy trình là thấp, sẽ không có
khả năng đạt được m ức thành thục đầy đủ trong các quy trình
khác.
 Các yêu cầu của doanh nghi ệp là không rõ ràng đ ối với nhân
viên CNTT.
 Khoảng thời gian kinh doanh lên đ ến m ức không còn đủ thời
gian dành cho vi ệc Thiết kế Dịch vụ thích hợp.
 Kiểm nghiệm không đầy đủ, dẫn đến thiết kế kém và do đó,
triển khai kém .
 Sự cân bằng không chính xác diễn ra giữa sự đổi m ới, rủi ro
và chi phí trong khi tìm ki ếm lợi thế cạnh tranh, nơi m à doanh
nghiệp m ong m uốn.
 Sự phù hợp giữa cơ sở hạ tầng, khách hàng và đ ối tác không
đủ để đáp ứng các yêu cầu kinh doanh t ổng thể.
 Một giao diện phối hợp không được cung cấp giữa các nhà
hoạch định CNTT và các nhà hoạch định doanh nghiệp.
 Các chính sách và chi ến lược, đặc biệt là chiến lược Quản lý
Dịch vụ, không sẵn sàng từ Chiến lược Dịch vụ, hoặc nội dung
của nó không được hiểu m ột cách rõ ràng.
 Không có đ ủ nguồn lực và ngân sách cho các ho ạt động Thiết
kế Dịch vụ.
 Rủi ro của việc các dịch vụ được phát tri ển biệt lập bằng cách
sử dụng tài sản và cơ sở hạ tầng của ‘riêng’ họ. Điều này có
vẻ rẻ hơn tính toán theo cách riêng lẻ, nhưng có thể tốn kém
hơn nhiều trong dài hạn do tiết kiệm tài chính khi m ua công ty
và thêm chi phí hỗ trợ các kiến trúc khác nhau.
 Không đủ thời gian dành cho giai đo ạn thiết kế, hoặc đào tạo
không đầy đủ cho nhân viên được giao nhiệm vụ thiết kế.
 Sự tham gia ho ặc cam kết không đầy đủ với sự phát triển chứ c
năng của ứng dụng, dẫn đến việc không chú ý đầy đủ đến các
yêu cầu của Thiết kế dịch vụ.

365
Lời bạt
Thiết kế Dịch vụ, như đã đư ợc m ô tả trong ấn phẩm này, bao hàm
việc thiết kế các dịch vụ CNTT thích hợp và sáng t ạo để đáp ứng
các yêu c ầu hiện tại và tương lai của doanh nghi ệp đã được thống
nhất. Thiết kế Dịch vụ phát triển m ột Gói Thi ết kế Dịch vụ và xem
xét việc lựa chọn m ô hình Thiết kế Dịch vụ phù hợp. Trong ấn phẩm
này, chúng ta cũng đã ki ểm tra các m ô hình thuê ngoài khác nhau
đang sẵn có và đưa ra m ột số lợi ích và khuyết điềm đối với m ỗi m ô
hình.
Ấn phẩm này cũng thảo luận về nền tảng của các quy trình thi ết kế
và năm khía c ạnh của thiết kế:
 Việc thiết kế các giải pháp dịch vụ, bao gồm m ọi yêu cầu về
chức năng, tài nguyên và năng l ực cần thiết và được thỏa
thuận.
 Việc thiết kế các hệ thống và công cụ Quản lý Dịch vụ, đặc
biệt là Danh m ục Dịch vụ để quản lý và kiểm soát các d ịch vụ
trong suốt vòng đời của chúng.
 Việc thiết kế các kiến trúc công ngh ệ và các ki ến trúc và công
cụ quản lý c ần thiết cho việc cung cấp các dịch vụ.
 Việc thiết kế hoặc đặc tả kỹ thuật các quy trình cần thiết đ ể
thiết kế, chuyển tiếp, vận hành và cải thiện các dịch vụ, các
kiến trúc và bản thân các quy trình.
 Việc thiết kế các hệ thống, phương pháp và ch ỉ số đo lường
đối với các dịch vụ, các kiến trúc và các thành ph ần và các
quy trình c ấu thành của chúng.
Định nghĩa về Thiết kế Dịch vụ là:
‘Việc thiết kế các dịch vụ CNTT thích hợp và sáng tạo, bao gồm
các kiến trúc, quy trình, chính sách và tài li ệu của chúng (các
dịch vụ), để đáp ứng các yêu c ầu hiện tại và tương lai c ủa doanh
nghiệp đã được thỏa thuận.
Ấn phẩm này đã gi ải thích rằng thiết kế tốt hơn và càng cẩn trọng
hơn thì giải pháp được đưa vào m ôi trư ờng vận hành thực tế càng
tốt hơn. Cũng có nhi ều khả năng là thi ết kế càng t ốt thì càng c ần ít
thời gian dành cho vi ệc làm lại cần thiết trong suốt giai đoạn chuyển
tiếp và vận hành th ực tế.
Phạm vi của ấn phẩm này bao g ồm việc thiết kế các dịch vụ, cũng
như là thi ết kế các hệ thống và quy trình Qu ản lý Dịch vụ. Thiết kế
Dịch vụ không ch ỉ giới hạn ở các dịch vụ m ới m à còn ba o gồm cả
các thay đổi cần thiết để gia tăng hoặc duy trì giá trị đối với khách
hàng theo vòng đời của các dịch vụ.
Ấn phẩm này cũng gi ải thích rằng đôi khi, ch ủ nghĩa thực dụng ghi
đè lên gi ải pháp hoàn h ảo m à chúng ta đã bi ết là nó sẽ như thế nào,
tuy nhiên khối lượng nỗ lực và chi phí không th ể biện m inh cho m ột
giải pháp hoàn hảo. Như m ọi khi, nó s ẽ phụ thuộc vào nhu cầu và

366
yêu cầu của doanh nghiệp. Như m ọi khi, điều bắt buộc là bất kỳ thứ
gì được hoàn thành trong CNTT đ ều phải có m ột lợi ích trực tiế p
đối với việc kinh doanh t ổng thể.

367
Phụ lục A: Gói Thi ết kế Dịch vụ
Một ‘Gói Thiết kế Dịch vụ’ hay là SDP nên đư ợc đưa ra trong giai
đoạn thiết kế đối với m ỗi dịch vụ m ới, những thay đổi đáng k ể đối
với m ột dịch vụ hoặc loại bỏ m ột dịch vụ hoặc thay đổi đối với chính
bản thân ‘Gói Thiết kế Dịch vụ’. Gói này sau đó đư ợc chuyển từ
Thiết kế Dịch vụ sang Chuyển tiếp Dịch vụ và chi tiết hóa m ọi khía
cạnh của dịch vụ và các yêu cầu của nó cho toàn b ộ những giai
đoạn tiếp theo c ủa vòng đời của dịch vụ. SDP nên bao gồm:
T h ể lo ạ i T h ể lo ạ i p h ụ M ô t ả v ề nh ững gì t r ong S D P
Các yê u c ầ u Các yê u cầu của Nhữ n g yê u c ầu c ủ a do a nh n gh i ệ p đư ợc t hỏ a
do a nh ng h iệ p th u ận và lậ p t hà n h tà i l i ệ u b a n đ ầ u .
K hả n ăn g c ó t h ể á p Đi ề u nà y x ác đ ị n h c á c th ứ c v à n ơi m à d ịc h v ụ
dụ n g đư ợc c ủ a d ịc h v ụ s ẽ đư ợc s ử dụ n g. Có th ể t ham k h ảo t h êm t ừ
yê u c ầ u c ủ a do a nh ng h iệ p , k hác h h à n g và
ngư ờ i s ử d ụn g đ ố i v ớ i d ịc h v ụ n ộ i bộ .
Các đ ầ u m ối l i ên h ệ Các đ ầ u m ối l i ê n h ệ c ủa d o an h n gh i ệ p, k hác h
d ịc h vụ hà n g v à c ác b ê n l i ên q ua n k hác tr on g d ịc h v ụ .
T hiế t k ế D ịc h v ụ Các yê u c ầ u về c hứ c Các c h ứ c n ă n g đ ã đ ư ợc t h a y đ ổ i c ủa d ịc h vụ
nă n g d ịc h v ụ m ới h o ặc đ ã t h a y đ ổ i , ba o g ồm c ác k ết qu ả v à
s ản ph ẩm c ó th ể c h u yển g ia o đ ư ợc đ ã đư ợc lậ p
k ế ho ạc h c ủ a n ó, tro ng m ột T u yê n b ố v ề c ác
Yê u c ầ u ( So R) đ ã đư ợ c t hỏ a t hu ậ n.
Các Yê u c ầ u Mứ c Dịc h S LR , đ ã đư ợc đ i ề u c h ỉn h h o ặc S L A, ba o g ồm
vụ c ác đ íc h n h ắm m ục ti ê u về d ịc h vụ và c hấ t
lư ợ ng .
Các yê u c ầ u về q uả n Các yê u c ầu v ề q u ản l ý đ ể q u ả n l ý dịc h v ụ m ới
l ý d ịc h v ụ v à qu ả n l ý ho ặc đư ợc t ha y đ ổi v à c ác th à nh p h ầ n c ủ a nó ,
v ận hà n h ba o g ồm m ọi d ịc h vụ v à t hỏ a h ỗ tr ợ , b i ệ n p há p
k iếm s oát , v ậ n h à nh , g iám s át , đ o l ư ờn g v à bá o
c áo .
T hiế t k ế D ịc h vụ và m ô V iệc th i êt k ế, c hu yể n ti ế p v à tr i ể n k hai v à v ận
hì n h T o po l o g y hà n h t iế p t h eo đ ó c ủ a c ác g iả i ph á p d ịc h v ụ và
c ác th à nh ph ầ n hỗ t r ợ nó , b ao g ồm :
 Đị n h n gh ĩa v à m ô hì n h d ịc h vụ , đ ể c h u yể n
ti ế p v à v ậ n h àn h.
 Mọ i t h àn h p h ầ n và c ơ s ở hạ t ầ ng d ịc h v ụ
(ba o g ồm ph ần c ứ ng , ph ầ n m ềm , m ạng, m ôi
trư ờn g , dữ l i ệ u, ứ n g dụ n g, c ô ng n g h ệ , c ô n g
c ụ, tà i l i ệ u) , b a o g ồm s ố p h iê n b ả n v à c ác
m ối q u a n h ệ , t ốt n h ât l à tro n g C MS .
 Mọ i n gư ờ i s ử d ụ ng , d oa n h ng h i ệp , d ịc h vụ ,
th à nh p h ần , c hu yế n ti ếp , tà i l i ệ u hỗ tr ợ v à
v ận hà n h.
 Các q u y tr ìn h , th ủ t ụ c , thư ớc đ o , c h ỉ s ố v à
bá o c á o.
 Các s ản p hẩm , d ịc h v ụ, th ỏ a t hu ậ n và nh à
c un g c ấ p h ỗ tr ợ.

368
Đá n h g iá t ín h s ẵ n Đá n h g iá t ín h sẵn B áo c á o v à k ế h oạc h ‘ Đá n h g iá t ín h s ẵ n s àn g
s àn g c ủ a t ổ c hứ c s àn g c ủ a t ổ c hứ c c ủa t ổ c hứ c ’ , ba o g ồm : l ợ i íc h k in h d oa n h, đ án h
g iá t à i c h í nh , đá n h g i á k ỹ th u ật , đá n h gi á tà i
ng u yê n v à đá n h g i á t ổ c hứ c , c ùn g v ới c ác c hi
ti ế t c ủa m ọi k ỹ n ăn g , nă ng lự c , k hả n ă ng m ới
c ần t hi ế t c ủ a tổ c hứ c c un g c ấ p d ịc h v ụ, nh à
c un g c ấ p, c ác d ịc h vụ h ỗ tr ợ v à h ợ p đ ồn g c ủa
họ .
K ế ho ạc h V òn g Chư ơ n g tr ì n h D ịc h vụ Mộ t c h ư ơn g tr ì nh ho ặ c k ế hoạc h t ổ ng t hể ba o
đ ờ i D ịc h vụ hàm m ọi g i ai đo ạ n c ủ a v ò ng đ ờ i d ịc h vụ , ba o
gồm c ác k hu ng t h ờ i g i an và gi a i đ o ạ n , đ ể
c hu yể n t i ếp , v ận h àn h v à tr i ển k h a i t i ếp th e o đó
c ủa dịc h vụ m ới , g ồm c ó:
 V iệc qu ả n l ý, p h ối h ợ p v à tíc h h ợ p v ới bấ t
k ỳ dự án n à o k hác , h o ặc c ác h o ạ t độ n g m ới
ho ặc đư ợc t ha y đ ổ i, c ác d ịc h vụ h oặc c ác
qu y tr ì nh .
 V iệc qu ả n l ý r ủ i ro v à v ấn đề .
 P hạm vi , c ác m ục ti ê u v à t hà n h p h ầ n c ủ a
d ịc h vụ .
 Các k ỹ n ă ng , n ă ng l ự c , v a i tr ò v à tr ác h
nh i ệm .
 Các q u y tr ìn h c ầ n t hi ế t.
 Các g ia o d i ệ n tư ơ ng tác và s ự ph ụ t h uộ c
v ào c ác d ịc h vụ k hác .
 V iệc qu ả n l ý đ ội n h óm , t à i n gu yê n , c ô n g c ụ,
c ôn g n g h ệ , n g ân s ác h, c ơ s ở v ật c hấ t c ầ n
th i ết .
 V iệc q uả n l ý c ác n h à c un g c ấ p và c ác h ợ p
đồ n g.
 Các bá o c áo , x em x ét v à đ i ều c hí n h q u y
trì nh c ủa c h ư ơn g trì n h v à c ác k ế ho ạc h.
 Các k ế ho ạc h tru yề n t hố n g v à đ ào t ạ o.
 Các k h un g t h ờ i gi a n, c ác s ả n ph ẩm c ó t h ể
c hu yể n g i a o đư ợc , c á c đíc h n h ắm m ục ti êu
v à đíc h n h ắm m ục ti êu v ề c hấ t lư ợ n g c h o
m ỗi g i a i đ o ạ n .

369
K ế h oạc h C hu yể n t iế p Ch i ến lư ợc t ổ ng t h ể, c ác m ục t i êu , c hí n h s ác h ,
Dịc h vụ đá n h g i á r ủ i r o và c ác k ế h o ạc h c h u yể n ti ế p
d ịc h vụ , b ao gồm :
 X â y d ự n g c h ín h s ác h , c ác k ế ho ạc h v à yê u
c ầu , b ao g ồm c ác k ế h oạc h x ấ y dự n g d ịc h
v ụ v à t h àn h ph ấ n, c ác đ ặc t ả k ỹ t hu ậ t, k iêm
s oá t và m ôi tr ư ờn g, c ô ng ng h ệ, c ôn g c ụ , q u y
trì nh , p hư ơ n g p há p và c ơ c h ế, b ao gồm m ọi
nề n t ản g .
 Ch ín h s ác h , c ác k ế h oạc h v à yê u c ầu k i ểm
ng h i ệm , ba o g ồm m ôi trư ờ n g, c ôn g n g h ệ ,
c ôn g c ụ, qu y trì nh , p h ư ơ ng p há p v à c ơ c h ế
k iểm ng h iệm .
 V iệc k iểm n g h iệm p h ải b a o g ồm :
o K iểm n g h iệm c hứ c nă ng .
o K iểm n g h iệm t hà n h p h ầ n , ba o g ồm m ọi
nh à c u n g c ấp , h ợ p đồ n g v à c ác s ả n
ph ẩm hỗ tr ợ đư ợc c un g c ấ p từ b ên
ng o à i.
o K iểm n gh i ệm c hấ p t h u ậ n c ủ a n gư ờ i s ử
dụ n g v à k iểm n gh i ệ m tính c ó th ể s ử
dụ n g đư ợc .
o K iểm n gh i ệm tín h tư ơ ng t híc h v à t íc h
h ợp hệ t h ốn g.
o K iểm n g hi ệm c ôn g s u ấ t và h i ệ u s uấ t c ủa
d ịc h vụ v à th à nh p h ầ n.
o K iểm n gh i ệm tín h l iê n t ục v à k h ả n ăn g
ph ục h ồ i.
o P hâ n lo ạ i, x ử l ý và k i ểm ngh iệm lỗ i ,
c ản h b á o v à s ự k iệ n .
o K iểm n g hi ệm bả o m ật v à to à n v ẹn d ịc h
v ụ v à t hà n h ph ầ n.
o K iểm n g hi ệm hậ u c ầ n, p h át h àn h v à
ph â n p hố i .
o K iểm n gh i ệm qu ản l ý, b a o g ồm k iêm
s oá t, g i ám s át , đ o l ư ờ ng và b á o c áo ,
c ùn g v ớ i s a o lư u, k hô i p h ục v à m ọi l ịc h
trì nh v à x ử l ý tậ p l ệ nh t he o l ô .
 V iệc tr iể n k ha i c hí n h s ác h , p h át hà n h c h í nh
s ác h , c ác k ế h oạc h v à yê u c ầ u , ba o g ồm
hậ u c ần , tr i ể n k ha i, ro ll - o ut , p h ân đ o ạ n ,
tri ể n k h a i m ôi trư ờ n g, th a y đ ổ i v ăn hó a, t h a y
đổ i t ổ c hứ c , c ôn g n gh ệ, c ô n g c ụ, q u y trì n h,
phư ơ n g p h áp t i ế p c ậ n, p hư ơ n g p há p và c ơ
c hế , b a o g ồm m ọi nề n t ản g , k iế n t hứ c , k ỹ
nă n g v à n ă n g l ự c c hu yể n đ ổ i v à tr i ể n k ha i,
c hu yể n t iế p n h à c u n g c ấ p v à h ợ p đ ồ ng ,
c hu yể n đ ổi v à d i c h u y ển dữ l i ệu .

370
K ế h o ạc h C hấ p t h uậ n Ch i ến lư ợc , c ác m ục t i êu , c h í nh s ác h, đá n h g iá
V ận h à n h D ịc h vụ r ủ i ro v à c ác k ế ho ạc h vậ n hà n h t ổn g t h ể, ba o
gồm :
 Q u ản l ý v à h o ạc h đ ịn h g i ao di ệ n v à s ự p h ụ
th u ộc .
 Các s ự k iệ n , b áo c á o , c ác v ấ n đề d ịc h v ụ,
ba o g ồm m ọi t ha y đ ổ i , ph á t h àn h , s ự c ố đ ã
đư ợc g i ải qu yế t , c ác v ấn đề và l ỗi đã b i ết ,
ba o gồm tro n g d ịc h v ụ và b ất k ỳ l ỗ i, v ấn đ ề
ho ặc k hô ng t u ân t h ủ tr on g d ịc h v ụ m ớ i .
 Ch ấ p th u ận d ịc h v ụ s a u c ù ng .
T iêu c hí C h ấp t h uậ n V iệc p há t tr i ển v à s ử dụ n g T iê u c hí C h ấp th uậ n
Dịc h vụ Dịc h vụ ( S AC) c h o t i ế n trì n h qu a m ỗi g i ai đ o ạ n
c ủa Vò n g đ ờ i D ịc h v ụ, b a o gồm :
 Mọ i m ôi trư ờ n g.
 Các t iê u c hí và k ho ản g t h ờ i g ia n b ảo đ ảm v à
thử n g h iệm .
Bảng A.1 N ội dung của Gói Thiết kế Dịch vụ

371
Phụ lục B: Tiêu chí Chấp thu ận Dịch vụ (ví dụ)
Tiêu chí chấp thuận dịch vụ là m ột bộ các tiêu chí được sử dụng để
đảm bảo rằng dịch vụ đáp ứng được chức năng và chất lượng được
kỳ vọng của nó và r ằng nhà cung c ấp dịch vụ sẵn sàng để cung cấp
dịch vụ m ới m ột khi nó đã được triển khai.
T iêu ch í T rác h n hi ệm
Có n gà y ‘ ho ạ t đ ộ ng ’ v à t h ờ i h ạ n đ ảm bả o đ ã đư ợc t hỏ a t h uậ n v ớ i T ha y đ ổ i , Mứ c dịc h
tấ t c ả c ác b ê n l iê n q u an , c ù ng v ớ i t iê u c h í c h ấ p t hu ậ n c u ối c ùn g ? vụ
L ịc h trì n h v à t r i ể n k ha i d ự á n đư ợc l ậ p t hà n h t à i l i ệ u c ó đư ợc t h ỏ a T ha y đ ổ i , Sự c ố
th u ận và c ôn g b ố c h o m ọi c á nh â n b ị ả nh h ư ở ng ?
S L A/ S LR đ ã đư ợc x e m x ét, đ i ều c hỉ n h v à th ỏ a th u ận v ớ i m ọi b ên Mứ c d ịc h v ụ
l iê n q u an ?
Dịc h vụ đã đư ợc n h ậ p v à o/c ậ p n hậ t tr on g M ục lục D ịc h vụ /D a n h Mứ c D ịc h v ụ, Cấ u
m ục dịc h vụ tr on g C M S và c ác m ối q u an h ệ t híc h h ợ p đư ợc th i ết hì n h
l ập c h o m ọi t hà n h ph ầ n h ỗ tr ợ c hư a?
Mọ i k hác h hà n g v à c á c b ên li ê n qu a n đ ã đư ợc x ác đ ị nh và g h i nh ận Mứ c D ịc h vụ , Q ua n
tr o n g CM S c h ư a ? hệ K in h d o an h
Mọ i r ủ i ro vậ n h à n h t ư ơ ng x ứ n g v ớ i v iệc v ận hà n h d ịc h v ụ m ới đã L iê n t ục K i n h d oa n h,
đư ợc đá n h g iá và c ác h o ạ t độ n g g iảm th i ể u đư ợc ho à n t h à nh k h i T ính s ẵ n s à ng .
ph ù h ợ p ?
Mọ i b iệ n p h áp d ự p h òn g và c h u yể n đ ổ i d ự ph ò ng đã đư ợc k iể m L iê n t ục K i n h d oa n h,
ng h i ệm và bổ s u ng th àn h c ôn g v ào l ịc h tr ìn h k i ểm ng h iệm k hả n ă ng T ính s ẵ n s à ng .
ph ục h ổ i tổ n g th ể c hư a?
Mọ i đíc h n h ắm m ục ti êu S L A/ S LR c ó t h ể đ ư ợc gi ám s át, đ o lư ờ ng , Mứ c D ịc h vụ , T ín h
bá o c á o v à x em x é t c h ư a, b a o g ồm tí nh s ẵ n s àn g và h i ệ u s uấ t ? s ẵn s àn g.
Mọ i n gư ờ i d ù ng đ ã đ ư ợc x ác đ ị n h/ ph ê d u yệt và n h ữ n g t à i k h o ả n Q u ản l ý T à i k h o ả n .
tư ơn g ứ n g đ ã đư ợc t ạ o r a c h o h ọ c hư a?
Mọ i đặc trư ng , đ íc h n h ắm m ục tiê u về h iệ u s uấ t và c ôn g s u ấ t c ủ a Cô n g s u ấ t.
k hối lư ợ n g c ô n g v iệc c ó t h ể đ ư ợc đ o lư ờ ng v à k ết h ợp và o c ác K ế
ho ạc h Cô n g s u ất k hô n g?
Mọ i q u y trì nh , l ịc h tr ì nh và t h ủ t ục vậ n h à nh c ó đư ợc t hố n g n h ất , V ận hà n h, L iê n t ục
k iểm ngh i ệm , lậ p th à n h vă n b ả n v à c h ấp t hu ận c hư a ( ví d ụ, t à i l iệ u, K in h d o an h .
s ao lư u, t h ủ k ho , lư u g i ữ , t h ờ i g ia n lư u g i ữ tạ i đ ị a đ iểm )?
Mọ i tác v ụ t h eo l ô v à yê u c ầu i n ấ n đã đư ợc t h ốn g nh ất , k iể m V ận h à n h.
ng h i ệm , l ậ p th à nh vă n b ả n v à c h ấp t h uậ n c h ư a?
Mọ i k ế ho ạc h k i ểm ng h iệm đ ã h oà n t hà n h th àn h c ô n g c hư a? Nh à Q u ả n lý K iểm
ng h i ệm
Mọ i k i ểm tra v à k i ểm ng h iệm bả o m ật đ ã ho à n t hà n h t hà n h c ô n g T uân t h ủ B ảo m ật.
c hư a ?
Các c ô n g c ụ v à th ủ t ụ c g i ám s át v à đ o lư ờ n g th íc h h ợ p c ó s ẵ n đ ể Q u ản l ý H ệ t h ốn g.
g iám s át d ịc h v ụ m ớ i, c ù n g v ớ i m ột qu y trì nh h ỗ tr ợ ng o à i g i ờ
k hôn g?
Mọ i k h ố i lư ợn g c ô ng v i ệc và c h i ph í v ận h à n h li ê n t ục đ ã đ ư ợc x á c V ận hà n h, T ài c hí n h,
đ ịn h v à p h ê du yệ t c hư a? CNT T .
Mọ i c hí ph í v ậ n hà n h d ịc h vụ v à t h àn h p h ần c ó đư ợc h iể u v à k ết T ài c hí n h CNT T .
h ợp v ào c ác qu y tr ìn h tà i c h ín h và m ô h ì nh c h i ph í k h ôn g ?
Các t h ể l o ạ i và q u y tr ì nh s ự c ố và vấ n đ ề đ ã đư ợc x em x ét v à đ i ề u B áo c á o S ự c ố, Vấ n

372
c h ỉn h đ ố i v ớ i dịc h vụ m ới, c ù n g v ớ i bâ t k ỳ l ỗi v à t hi ế u s ó t đ ã b i ế t đề .
c hư a ?
Mọ i n h à c u ng c ấ p m ới đ ã đư ợc x ác đ ị nh v à c ác h ợ p đồ n g tư ơn g Q u ản l ý N hà c un g
ứ ng v ớ i h ọ c ó đư ợc p hác t h ảo m ột c ác h p hù h ợ p c hư a ? c ấp v à H ợp đ ồ ng .
Mọ i t h ỏa t h uậ n h ỗ tr ợ đã đư ợc x em x ét và đ i ề u c h ỉ nh – c ác S L A , Nh à Q u ả n l ý D ự á n.
S LR , O L A v à t h ỏ a t hu ận h ợ p đ ồ ng , v ớ i c ác tà i l i ệ u đã c h ấp t hu ậ n
b ở i m ọi đ ộ i n hóm ( ba o g ồm nhà c u ng c ấp , c ác n h óm h ỗ tr ợ, Q u ả n
l ý N hà c u n g c ấ p, c ác nh óm p há t tr i ể n và h ỗ tr ợ ứ n g dụ n g) c hư a ?
T ài l i ệu hỗ tr ợ k ỹ t h u ật tư ơ n g x ứ n g đ ã đư ợc p h át tr i ển v à c h ấ p Sự c ố , V ấn đề .
th u ận b ở i c ác nh óm S ự c ố , V ấ n đề v à hỗ t r ợ C NT T c hư a ?
Mọ i R FC S và H ồ s ơ Ph át hà n h đ ã đư ợc c ấp p h ép v à c ậ p n h ật T ha y đ ổ i .
c hư a ?
Mọ i d ịc h vụ , S L A, SL R , O L A v à c ác c h i t i ết h ợ p đ ồn g, c ùn g v ớ i m ọi Q u ản l ý D ự án , c ác
c h i t i ết về t hà n h ph ầ n ứ n g dụ n g v à c ơ s ở hạ t ần g , đã đư ợc n h ậ p Nh óm H ỗ tr ợ , Cấ u
v ào C M S c hư a ? hì n h.
G i ấ y p hé p s ử d ụ ng p hầ n m ềm thíc h h ợ p đ ã đư ợc m ua và t á i p h ân Cấ u h ìn h .
bổ gi ấ y p h ép đ ã đư ợc s ử d ụ ng c hư a ?
Mọ i t h àn h p h ầ n p h ần c ứ n g m ớ i đ ã đư ợc l ư u tr ữ tr on g D L v ớ i c h i Cấ u h ìn h.
ti ế t đư ợc g h i nh ậ n tr o ng C M S c hư a ?
Mọ i t h àn h p h ầ n p h ần m ềm đã đư ợc g h i n h ậ n tro n g DL v ớ i c ác c h i Cấ u h ìn h.
ti ế t đư ợc g h i nh ậ n tr o ng C M S c hư a ?
Mọ i k ế h o ạc h b ảo tr ì v à n ân g c ấp đ ã đư ợ c th ốn g nh ấ t, c ùn g v ớ i P há t h à nh v à T ri ể n
v i ệc ph á t hà n h c ác c h í nh s ác h , t ầ n s u ất v à c ơ c h ế ? k hai .
Mọ i n gư ờ i d ùn g đ ã đ ư ợc đ ào t ạ o, và t à i l i ệu n gư ờ i d ùn g đ ã đư ợc Nh à Q u ả n l ý D ự á n.
c hấ p t hu ậ n v à p hâ n p h ố i c ho m ọi n gư ờ i d ù ng ?
Mọ i m ối q u an hệ , g i a o d iệ n và ph ụ t hu ộc v ớ i m ọi h ệ th ố ng v à c á c Nh à Q u ả n l ý D ự á n.
d ịc h v ụ n ộ i b ộ và bê n ng oà i k hác đ ã đư ợc l ập th à nh tà i l i ệ u, th ố n g
nh ấ t v à h ỗ tr ợ c hư a?
Các n hà q u ả n l ý do a n h n g h i ệ p th íc h h ợ p đ ã k ý c h ấ p th u ận d ịc h v ụ Nh à Q u ả n l ý D ự á n.
m ới c hư a?
Bảng B.1 Các tiêu chí Ch ấp thuận Dịch vụ.

373
Phụ lục C: (Ví dụ về) Các biểu mẫu tài liệu quy trình
C1 Khuôn khổ quy trình
Khi thiết kế m ột quy trình m ới hoặc đã được sửa đổi cho bất kỳ quy
trình Quản lý Dịch vụ, chúng tôi khuyến cáo r ằng m ột đặc tả kỹ thuật
quy trình hoặc m ột khuôn khổ nên được đưa ra. Đặc tả kỹ thuật nên
được giữ ở m ức khá cao nhưng nó c ần chi ti ết hóa được phạm vi và
các giao diện của quy trình. Các thủ tục đã được chi tiết hóa và
hướng dẫn công vi ệc cũng s ẽ được cần đến để đảm bảo tính nhất
quán của quy trình và vi ệc ứng dụng nó. Nội dung phổ biến của m ột
Khuôn khổ Quy trình ho ặc Đặc tả kỹ thuật là:
 Tên quy trình, m ô t ả và quản lý (quản lý tài li ệu: phiên b ản,

kiểm soát thay đ ổi, người soạn thảo, v.v…).
 Các tuyên b ố tầm nhìn và s ứ m ệnh.
 Các m ục tiêu.
 Phạm vi và các thuật ngữ tham chiếu.
 Tổng quan về Quy trình:
o Mô tả và t ổng quan.
o Các đầu vào.
o Các thủ tục.
o Các hoạt động.
o Các đầu ra.
o Các điều kiện kích hoạt.
o Các công c ụ và sản phẩm có thể chuyển giao được
khác.
o Truyền thông (giao tiếp).
 Các vai trò và trách nhi ệm :
o Trách nhiệm vận hành.
o Chủ sở hữu quy trình.
o Các thành viên c ủa quy trình.
o Những người sử dụng quy trình.
o Các vai trò khác.
 Các tài liệu và tham chi ếu thích hợp.
 Các giao di ện và phụ thuộc với:
o Các quy trình SM khác.
o Các quy trình CNTT khác.
o Các quy trình nghiệp vụ.
 Các thước đo và chỉ số quy trình: xem xét, đánh giá và ki ểm
toán.
 Các sản phẩm có thể chuyển giao đư ợc và các báo cáo đư ợc
đưa ra bởi quy trình:
o Tần suất.
o Nội dung.
o Phân phối.
 Chú giải thuật ngữ, viết tắt và tham chiếu.

374
Phụ lục D: Các tài li ệu thiết kế và hoạch định và nội dung của
chúng
Phụ lục này bao gồm các chi tiết được đề xuất về các kiểu tài liệu
thiết kế, các tài li ệu kế hoạch và tiêu chu ẩn nên được đưa ra và duy
trì bởi CNTT, và đ ồng thời phác thảo nội dung tối thiểu của các c ấu
trúc và k ế hoạch CNTT. Tuy nhiên, nên nh ấn m ạnh rằng tất cả các
tài liệu nói trên nên đư ợc xem xét và đi ều chỉnh m ột cách định kỳ và
thường xuyên và nên đư ợc sử dụng m ột cách ch ủ động trong các
quy trình và th ủ tục hàng ngày c ủa CNTT.
Chúng cũng ph ải được duy trì trong m ối liên kết với tất cả các tài
liệu tương tự đang được sử dụng trong doanh nghi ệp và tổ chức
tổng thể.

375
D1 Các tài liệu và tiêu chu ẩn thiết kế và kiến trúc
Các tài liệu thiết kế và tiêu chuẩn do CNTT phát tri ển và duy trì ph ải
bao gồm :
 Các t iêu chu ẩn, chính sách, quy tr ình và th ủ tục thiết kế và
hoạch định.
 Các kiến trúc, phương pháp thi ết kế và t iêu chuẩn ứng dụng.
 Yêu cầu kinh doanh, đánh giá tác đ ộng kinh doanh và ưu tiên và
các phương pháp và tiêu chu ẩn cho đề án kinh doanh.
 Các tiêu chuẩn cho yêu cầu chức năng .
 Các tiêu chuẩn và phương pháp SoR và ITT đ ể đánh giá chúng .
 Các k iến trúc công ngh ệ, tiêu chu ẩn thiết kế và chính sách
CNTT, bao g ồm mọi lĩnh vực công nghệ, bao g ồm máy t ính lớn,
máy ch ủ, máy t ính đ ể bàn, máy t ính xách tay, thi ết bị cầm tay và
di động, h ệ thống điện tho ại, lưu tr ữ, sao lưu, m ạng và đánh địa
chỉ mạng.
 Các kiến trúc, chính sách và t iêu chu ẩn thiết kế hệ điều hành,
phần mềm hệ thống, tiện ích và f irm ware.
 Các kiến trúc, chính sách và ti êu chu ẩn thiết kế dữ liệu, thông
tin và cơ sở dữ liệu, bao g ồm luồng thông tin, Quản lý Tri thức,
bảo mật thông tin và quyền truy cập, Q uản lý Dữ liệu, lưu tr ữ,
lưu giữ, phân t ích và khai thác d ữ liệu.
 Các hệ thống quản lý, nền tảng, công cụ và tác nhân cũ ng như
kiến trúc và chính sách thi ết kế và tiêu chuẩn của chúng, bao
gồm chức năng, lĩnh vực, giao diện, giao thức quản lý, phân lo ại
và xử lý sự kiện và c ảnh báo, tự động hóa và leo thang .
 Các k iến trúc, thiết kế và tiêu chuẩn cáp.
 Các tiêu chuẩn, phư ơng pháp và chính sách phát tri ển.
 Các phư ơng pháp, chính sách và tiêu chu ẩn thử nghiệm.
 Các tiêu chuẩn và phương pháp bàn giao, nghi ệm thu và ký k ết.
 Các tiêu chu ẩn và chính sách đối với đối tác, nhà cung c ấp và
hợp đồng.
 Các chính sách và tiêu chu ẩn truyền thông .
 Các tiêu chuẩn và chính sách đối với tài liệu và thư viện tài li ệu.
 Các k iến trúc, các tiêu chuẩn và chính sách thi ết k ế mạng
Internet và Intranet, bao g ồm cả thương mại và kinh doanh đi ện
tử.
 Các kiến trúc, tiêu chu ẩn và chính sách thi ết kế E-mail và phần
mềm nhóm.
 Các yêu cầu, chính sách thi ết kế và tiêu chuẩn về môi trư ờng.
 Các chính sách và tiêu chu ẩn t hi ết kế bảo mật CNTT, bao g ồm
tường lửa, kiểm tra virus, mức độ truy c ập dịch vụ và hệ thống,
các phương pháp và chính sách, truy c ập từ xa, quản lý tài
khoản người dùng và m ật khẩu.
 Các tiêu chuẩn và chính sách mua s ắm.
 Các t iêu chu ẩn và chính sách c ủa chương trình, phương pháp d ự
án và hoạch định dự án và xem xét các chính sách và tiêu
chuẩn.
 Tiêu chu ẩn và chính sách ch ất lượng.
 Các tiêu chuẩn và giao di ện người dùng.

376
D2 Các kế hoạch CNTT
CNTT nên đưa ra và duy trì m ột số các kế hoạch nhằm phối hợp và
quản lý việc phát triển tổng thể và chất lượng của các dịch vụ CNTT.
Các kế hoạch này nên bao gồm :
 Các kế hoạch kinh doanh CNTT: các k ế hoạch kinh doanh đối
với việc phát tri ển các dịch vụ CNTT.
 Các kế hoạch Chiến lược: cung cấp các k ế hoạch cho vi ệc đạt
được tầm nhìn, sứ mệnh và mục tiêu của CNTT trong dài h ạn.
 Các kế hoạch Chiến thuật: cung cấp các k ế hoạch cho việc đạt
được tầm nhìn, sứ mệnh và mục tiêu của CNTT trong trung và
ngắn hạn.
 Các kế hoạch Chức năng: cung cấp các k ế hoạch cho vi ệc đạt
được tầm nhìn, sứ mệnh và mục t iêu c ủa các chức năng chính
của CNTT.
 Các k ế hoạch Vận hành: cung cấp các k ế hoạch cho việc phát
triển và cải thiện các quy tr ình, thủ tục và phương pháp vận
hành.
 Các k ế hoạch và chương trình d ự án:
o Các chương trình CNTT và doanh nghi ệp.
o Các dự án CNTT.
 Các k ế hoạch và chương trình quy trình :
o Các mục tiêu và đích nh ắm mục tiêu.
o Cải tiến quy tr ình.
o Các vai trò và trách nhi ệm.
 Các k ế hoạch chuyển tiếp:
o Các k ế hoạch và lịch trình xây dự ng.
o Các lịch tr ình kiểm nghiệm và phát hành.
o Các môi trư ờng phát triển và kiểm nghiệm.
o Các lịch tr ình chuyển tiếp.
 Các k ế hoạch Quản l ý Dịch vụ:
o (Các) Kế hoạch Ch ất lượng Dịch vụ.
o Các K ế hoạch và Chương trình C ải tiến Dịch vụ.
o Các K ế hoạch và ng ân sách Tài chính.
o Các Kế hoạch Liên t ục Dịch vụ và Khôi phục CNTT và các
Kế hoạch Liên tục Kinh doanh.
o Kế hoạch Công suất.
o Kế hoạch về T ính sẵn sàng.
o Các K ế hoạch Hỗ trợ Dịch vụ.
o Các K ế hoạch Phát hành và lịch tr ình.
o Các K ế hoạch Quản lý Cấu hình.
o Các K ế hoạch Quản lý Thay đổi và L ịch tr ình Thay đ ổi.
o Các Kế hoạch Bộ phận Hỗ trợ Dịch vụ, Quản lý Sự cố và
Quản lý Vấn đề.
o Các K ế hoạch Nhà cung cấp và H ợp đồng.
Mọi kế hoạch CNTT phải đư ợc phát tr iển, duy tr ì và xem xét m ột cách
tương xứng với doanh nghiệp và toàn bộ tổ chức. Điều này nên đ ạt
được bằng cách sử dụng quy tr ình đánh giá tác đ ộng của một hệ thống
Quản lý Thay đ ổi phù hợp. Các tổ chức nên xem xét các yêu c ầu pháp
lý đối với hệ thống, đồng thời cũng xem xét các tiêu chu ẩn và quy đ ịnh
quốc tế và quốc gia cũng như nhu c ầu quản trị công ty.

377
Phụ lục E Các ki ến trúc và tiêu chu ẩn môi trường
Phụ lục này bao gồm các chi ti ết về các kiến trúc và tiêu chu ẩn về
m ôi trường. Mỗi tổ chức nên đưa ra m ột chính sác h m ôi trường cho
vị trí của thiết bị, với các tiêu chuẩn t ối thiểu được thống nhất cho
các m ật độ cụ thể của thiết bị. Ngoài ra, các tiêu chu ẩn tối thiểu
cũng nên được thống nhất đối với sự bảo vệ các tòa nhà có ch ứa
các thiết bị và phòng chứa thiết bị. Các bảng biểu dưới đây bao hàm
các khía c ạnh chủ yếu cần phải được xem xét, cùng với các đặc
điểm ví dụ.
Bảng E.1 Tòa nhà/đ ịa điểm

T iếp c ận Ph ạm v i an n inh , l ối v ào an nin h, d ấu v ết ki ểm t ra
B ảo vệ t òa n h à v à đ ịa Hà n g r à o a n n i n h, m áy q u a y p h im , ph á t h iệ n c h u yể n độ n g v à
đ iêm x âm nhậ p, c ả n h b áo c ử a s ổ và c ử a, c h i ếu s án g , m ôi trư ờ ng
l àm v iệc a n t o àn (t i êu c hu ẩ n).
Lố i và o Nh i ều lố i và o đư ợc k iể m s oát .
Mô i trư ờ n g b ên ng o ài T ối t h iể u r ủ i r o t ừ bê n n g oà i .
Các d ịc h v ụ Nế u c ó t h ể v à h ợ p l ý, c ác tu yế n v à nh à c u ng c ấp t h a y th ế đ ố i
v ớ i m ọ i d ịc h v ụ t h i ết yếu , b ao gồm c ả c ác dị c h v ụ m ạn g .
Bảng E.2 Phòng thi ết bị chính

T ru y c ậ p Lố i và o đư ợc k iểm s o át a n n i nh , k h óa k ết h ợp , q ué t th ẻ , m á y
qu a y p h im (n ế u l ĩ nh v ự c k in h d oa n h q ua n tr ọn g và vắ n g m ặt) .
V i trí T ầng m ột b ất c ứ k h i nà o c ó th ể, k hô ng c ó nư ớc , k hí đ ố t, h ó a
c hấ t h o ặc n gu y c ơ c h á y tr on g k hu v ự c lâ n c ận , b ê n tr ên , b ê n
dư ớ i ho ặc x u n g q ua n h .
K hả n ă n g h iể n t hị K hô n g b ản g c h ỉ d ẫn , k hô n g c ó c ử a s ổ bê n n go à i.
B ề ng o à i V ỏ b ê n n g oà i : c h ố ng th ấm , k ín g ió , c ác h â m , c h ốn g c há y ( 0 .5
đế n 4 g i ờ t ù y t he o m ứ c đ ộ n gh i êm tr ọ n g).
Cu n g c ấp t h i ết b ị V iệc c un g c ấ p đ ầ y đ ủ c ần đư ợc thự c hi ệ n đ ể c u ng c ấ p và đ ị n h
v ị c ác t h iế t b ị l ớ n v à t i nh v i.
S àn n h à b ên tr o ng Đư ợc đó n g k í n.
P hò n g đ ặt m á y r i ê ng Ng u ồn c ấp đ i ện k hô n g gi á n đ o ạn ( U P S). Ng u ồ n c ấp đ iệ n v à b ộ
b iệ t c hu yể n m ạc h, đ ơ n vị x ử l ý k hô n g k hí, c ác đ ơ n v ị v à ph ò ng k é p
nế u l ĩ nh vự c k i n h do a nh là qu a n tr ọ n g.
B ên n g o ài Má y p há t đ i ện c h o c ác tr un g t âm d ữ l i ệu và c ác h ệ t h ốn g
ng h i ệp vụ qu a n tr ọ n g.

378
Bảng E.3 Các trung tâm d ữ liệu quan trọng
Nh i ệt đ ộ K iểm s o át n g hi êm n g ặ t, 2 2 ° (± 3 ° ). C un g c ấp c h o l ên đ ế n
2
55 0W W /m . Bi ế n t hi ê n 6 ° k h ắp ph ò ng và t ố i đa 6° m ỗi g i ờ.
K iểm s o á t đ ộ ẩm K iểm s o á t ng h i êm ng ặ t : 50 % (± 10 %).
Ch ất lư ợ ng k hô ng k hi Á p s u ất d ư ơn g, lư ợ n g ô n h i ễm k hí đư ợc l ọc t h ấ p ( ví d ụ k hí
s u lf ur d i ox id e 0, 1 4 p p m ), m ứ c bụi đố i v ớ i c ác h ạt > 1 m ic ro n, ít
3
h ơn 5 x 1 0 6 h ạ t/m . T ự đ ộ ng t ắt k h i ph á t h i ệ n k h ói ho ặc lử a .
Ng u ồn đ i ệ n B ộ p h ân ph ố i ng u ồn đ iệ n ( PD U), v ớ i ng u ồ n c u n g c ấ p b a ph a
c ho c ác t ủ k hôn g c h u yển m ạc h , m ột ph a c h o m ỗi p h ần c ủ a th i ết
b ị, v ớ i b ộ ng ắ t m ạc h da n h đ ị n h t híc h h ợ p c ho m ỗ i n g uồ n c un g
c ấp . N go à i ra , c ó t h ể s ử dụ ng c ác d ả i p hâ n ph ố i đ iệ n đ ã đư ợc
ph ê d u yệ t . T ả i b a ph a c â n b ằ n g. U P S (tư ơ ng t ác tr ự c t u yế n
ho ặc tư ơn g tác đư ờ ng dâ y v ớ i Q u ả n l ý G ia o th ứ c Q u ả n l ý M ạ ng
Đ ơn g iả n ( SN M P)) đ ể đảm bả o đi ệ n á p đ ư ợc c un g c ấp n ằm
tr o n g p h ạm v i ± 5% đ án h g iá v ới m ứ c x u n g t ố i t h i ểu , s ụt á p,
tă n g áp v à đ i ề u k i ệ n đ i ện á p q u á c ao / áp q u á t h ấ p .
S àn n â n g G ạc h lá t n ền c h ố ng t ĩn h đ i ệ n , c ó t h ể n ân g đư ợc tr ên b ệ đ ỡ ,
k íc h thư ớc 60 0 x 6 0 0 m m , vớ i c ác b ệ t h a y t hế đư ợc b ắt v ít v ào
s àn vữ ng c hắc . Kh o ản g h ở t ố i th i ể u 6 00m m s o v ớ i s à n đ ặc . T ải
2
tr ọ n g s àn lê n đ ế n 5k N/m v ớ i t ối t h i ểu k hu yến n g h ị l à 3m g iữ a
s àn v à tr ầ n g i ả.
T ư ờn g b ên tr o ng T ừ s àn n â ng l ên đ ến tr ầ n, c h ốn g c há y n hư ng c ó lu ồ ng k h ôn g
k hí tr ê n v à dư ớ i m ứ c s àn .
Hệ t h ốn g p hò n g HS S D ho ặc V E S D A n h i ề u m ứ c b áo đ ộ ng v ớ i F M 20 0 ( h o ặc k hí
c há y/ n g ă n c há y tr ơ th a y t h ế) t ự độ n g ph u n k hi p há t h i ện ‘d o ub l e - k noc k ’ ( c hắc là
k h i ph á t h iệ n c h áy – n gư ời dịc h) .
P há t h iệ n c ác yế u t ố Đố i v ớ i k hó i, nh i ệt đ ộ, ng u ồn đ iệ n , đ ộ ẩ m , nư ớc và k ẻ x âm
th u ộc v ề m ôi t r ư ờn g nh ậ p vớ i k hả n ăn g c ả nh b áo t ự đ ộn g . B ả n g b á o đ ộn g c ục b ộ
v ớ i b ản g l ặ p v à c ũ ng c ó k h ả nă n g b áo đ ộ n g t ừ x a .
Ch i ếu s án g Mứ c đ ộ c hi ế u s á n g b ìn h t hư ờ ng trê n t r ầ n v ớ i h ệ t h ốn g c hi ế u
s án g k h ẩ n c ấp k hi m ất đ i ện .
A n to à n đ i ệ n Ng u ồn đ iệ n s ạc h p h ả i đư ợc l ắp đ ặt c ho P DU và m ọi th i ết b ị.
V ớ i c ác n út t ắt n g uồ n từ x a đư ợc đ án h d ấ u r õ r à ng tr ê n m ỗi lầ n
th o át . C ác ổ c ắm đi ệ n bẩ n, đ ư ợc đ á n h d ấ u r õ r àn g , c ũn g c ầ n
đư ợc c u ng c ấp .
Bì n h c h ữ a c h á y Có đ ủ b ìn h c h ữ a c h á y đ i ệ n, c ó b iể n b áo v à q u y trì n h ph ù h ợ p.
Ru n g đ ộ n g Ru n g độ n g p hả i ở m ứ c t ố i t h i ểu tr o n g k hu v ự c h o àn c h ỉ n h.
Nh i ễu đi ệ n từ Nê n c ó n h iễ u ( đ iệ n t ừ ) tố i th i ể u (c ư ờn g độ từ t rư ờn g x un g
qu a nh 1. 5 V/m ).
Lắ p đ ặt T ất c ả c ác t h i ết b ị p h ả i đư ợc c u ng c ấ p và l ắp đ ặt b ở i c ác n hà
c un g c ấ p và l ắp đ ặ t c ó đ ủ n ăn g l ự c th e o c ác t iê u c h u ẩn ph ù
h ợp v ề đ iệ n v à s ứ c k h ỏe v à an t o àn .

379
K ết n ố i m ạn g K hô n g g i an t hi ế t b ị ph ả i đư ợc tra n g b ị d â y c áp đ ầ y đ ủ v ớ i c ô n g
s uấ t t híc h h ợ p đ ể tă n g trư ở n g h ợ p l ý. T ấ t c ả c ác c áp ph ả i đư ợc
đ ịn h v ị và c ố đ ịn h v à o c ác k h a y c áp t h íc h h ợ p.
K hô i p h ục s a u th ảm h ọa Các k ế ho ạc h k hô i p h ục đ ã đư ợc k iểm tr a đ ầ y đ ủ n ê n đư ợc
ph á t tr i ển c h o t ất c ả c ác tr u ng tâm d ữ li ệ u c hí nh b ao g ồm c ả
v i ệc s ử d ụ ng c ác đ ịa đ i ểm và t h i ết b ị dự ph ò ng .
Bảng E.4 Các trung tâm d ữ liệu vùng và các trung tâm thi ết bị
chính yếu
qu a y p h im (n ế u l ĩ nh v ự c k in h d o a n h q ua n tr ọn g và vắ n g m ặt) .
Nh i ệt đ ộ K iểm s o á t nh i ệ u độ , 2 2° (± 5 ° ) t híc h h ợ p h ơ n.
K iểm s o á t đ ộ ẩm K iểm s o á t ng h i êm ng ặ t : 50 % (± 10 % ) th íc h h ợp h ơn .
Ch ất lư ợ ng k hô ng k hi Á p s u ất d ư ơn g, lư ợ n g ô n h i ễm k hí đư ợc l ọc t h ấ p ( ví d ụ k hí
s u lf ur d i ox id e 0, 1 4 p p m ), m ứ c bụi đố i v ớ i c ác h ạt > 1 m ic ro n, ít
3
h ơn 5 x 1 0 6 h ạ t/m . T ự đ ộ ng t ắt k h i ph á t h i ệ n k h ói ho ặc lử a .
Ng u ồn đ i ệ n B ộ p h ân ph ố i ng u ồn đ iệ n ( PD U), v ớ i ng u ồ n c u n g c ấ p b a ph a
c ho c ác t ủ k hôn g c h u yển m ạc h , m ột ph a c h o m ỗi p h ần c ủ a th i ết
b ị, v ớ i b ộ ng ắ t m ạc h da n h đ ị n h t híc h h ợ p c ho m ỗ i n g uồ n c un g
c ấp . N go à i ra , c ó t h ể s ử dụ ng c ác d ả i p hâ n ph ố i đ iệ n đ ã đư ợc
ph ê d u yệ t . T ả i b a ph a c â n b ằ n g. U P S (tư ơ ng t ác tr ự c t u yế n
ho ặc tư ơn g tác đư ờ ng dâ y v ớ i Q u ả n l ý G ia o th ứ c Q u ả n l ý M ạ ng
Đ ơn g iả n ( SN M P)) đ ể đảm bả o đi ệ n á p đ ư ợc c un g c ấp n ằm
tr o n g p h ạm v i ± 5% đ án h g iá v ới m ứ c x u n g t ố i t h i ểu , s ụt á p,
tă n g áp v à đ i ề u k i ệ n đ i ện á p q u á c ao / áp q u á t h ấ p .
S àn n â n g G ạc h lá t n ền c h ố ng t ĩn h đ i ệ n , c ó t h ể n ân g đư ợc tr ên b ệ đ ỡ ,
k íc h thư ớc 60 0 x 6 0 0 m m , vớ i c ác b ệ t h a y t hế đư ợc b ắt v ít v ào
s àn vữ ng c hắc . Kh o ản g h ở t ố i th i ể u 6 00m m s o v ớ i s à n đ ặc . T ải
2
tr ọ n g s àn lê n đ ế n 5k N/m v ớ i t ối t h i ểu k hu yến n g h ị l à 3m g iữ a
s àn v à tr ầ n g i ả.
T ư ờn g b ên tr o ng T ừ s àn n â ng l ên đ ến tr ầ n, c h ốn g c há y n hư ng c ó lu ồ ng k h ôn g
k hí tr ê n v à dư ớ i m ứ c s àn .
Hệ t h ốn g p hò n g Nó i c hu n g l à p h át h i ệ n đ ám c há y n hư ng k h ôn g d ậ p t ắt đư ợc ,
c há y/ n g ă n c há y m ặc dù bá o đ ộ ng đa c ấp H S SD ho ặc V E SD A v ớ i FM 2 00 tự
độ n g p hu n (h o ặc k hí t rơ t h a y th ế) k hi p h át h i ệ n ‘ d ou b l e- k noc k '
c ó t h ể đư ợc b ao g ồm n ếu c ó c ác h ệ th ố n g qu a n t r ọ n g tr o ng
k inh d o an h .
P há t h iệ n c ác yế u t ố Đố i v ớ i k hó i, nh i ệt đ ộ, ng u ồn đ iệ n , đ ộ ẩ m , nư ớc và k ẻ x âm
th u ộc v ề m ôi t r ư ờn g nh ậ p v ớ i k hả n ăn g c ả n h b áo t ự đ ộ n g.
A n to à n đ i ệ n Ng u ồn đ iệ n s ạc h p h ả i đư ợc l ắp đ ặt c ho P DU và m ọi th i ết b ị.
V ớ i c ác n út t ắt n g uồ n từ x a đư ợc đ á nh d ấ u r õ r à ng tr ê n m ỗi
c ử a th o át h i ểm . C ác ổ c ắm đ iệ n b ẩn , đư ợc đ á nh d ấ u r õ rà n g,

380
c ũn g c ầ n đư ợc c u n g c ấp .
qu a nh 1. 5 V/m ).
đ ịn h v ị và c ố đ ịn h v à o c ác k h a y c á p t h íc h h ợ p.
K hô i p h ục s a u th ảm h ọa Các k ế ho ạc h k hô i p h ục đ ã đư ợc k iểm tr a đ ầ y đ ủ n ê n đư ợc
ph á t tr i ển c h o t ất c ả c ác tr u ng tâm d ữ li ệ u c hí nh b ao g ồm c ả
v i ệc s ử d ụ ng c ác đ ịa đ i ểm và t h i ết b ị dự ph ò ng .
Bảng E.5 Phòng máy ch ủ và thi ết bị mạng

Nh i ệt đ ộ Mô i tr ư ờ ng v ă n p h ò ng bì n h t hư ờ ng , n hư n g n ếu tr on g c ác p h òn g
đó n g k ín v à c ó k h óa , t hô n g g ió đ ầ y đ ủ n ê n đ ư ợc c u n g c ấ p.
K iểm s o á t độ ẩm Mô i tr ư ờ n g v ă n p hò n g bì n h thư ờ n g.
Ch ất lư ợ ng k hô ng k hi Mô i tr ư ờ n g v ă n p hò n g bì n h thư ờ n g.
Ng u ồn đ i ệ n Ng u ồn c ấ p đ iệ n s ạc h v ớ i ng u ồ n c ấ p đ i ện U P S c ho c ác t ủ ho à n
c h ỉn h.
S àn n â n g K hu yế n n g h ị t ố i t h i ểu 3m giữ a s àn và tr ần v à t ất c ả c á p đư ợc
bả o vệ tr o ng hệ t h ốn g đư ờn g ố n g n hi ề u n gă n .
T ư ờn g b ên tr o ng Nế u c ó t h ể , c ác b ứ c t ư ờ ng nê n l à c h ố ng c h á y.
Hệ t h ốn g p hò n g Các hệ t h ốn g p h át hi ệ n k hó i/ lử a b ìn h t hư ờn g c ủ a v ă n p hò n g tr ừ
c há y/ n g ă n c há y k hi nh ữ n g n ơ i t ập tr u n g th i ết bị c hí nh .
P há t h iệ n c ác yế u t ố Đố i v ớ i k hó i, n gu ồ n đ i ện , và k ẻ x âm nh ậ p v ớ i k hả nă n g c ả n h
th u ộc v ề m ôi t r ư ờn g bá o tự đ ộ ng .
A n to à n đ i ệ n Ng u ồn đ i ệ n s ạc h ph ả i đư ợc lắ p đ ặt c ho m ọ i th i ết b ị . V ớ i c ác
nú t t ắt n g uồ n đư ợc đ á nh d ấ u r õ rà n g.

381
qu a nh 1. 5 V/m ).
đ ịn h v ị và c ố đ ịn h v à o c ác k h a y c áp t h íc h h ợ p.
K hô i p h ục s a u th ảm h ọa Các k ế h oạc h k hô i p h ục đư ợc k iểm n gh i ệm đ ầ y đ ủ n ên đư ợc

ph á t tr i ể n, n ế u t híc h h ợ p.
Bảng E.6 Môi trư ờng văn phòng

T ru y c ậ p Mọ i vă n p h òn g n ên c ó c ác l ố i t ru y c ậ p đư ợc b ảo v ệ an n i n h
th íc h h ợ p tù y t hu ộc v ào l ĩ nh v ự c k in h d oa n h, t hô n g t i n v à th i ết
b ị bê n tr o ng c h ú ng .
Ch i ếu s án g, nh i ệt đô , độ Mộ t m ôi tr ư ờ ng v ă n p hò n g b ì nh t hư ờn g s ạc h s ẽ , t h oả i m á i và
ẩm v à c h ấ t lư ợ n g k h ô ng ng ă n n ắ p, p hù h ợ p v ớ i c ác yê u c ầu v ề s ứ c k h ỏe , a n t o àn v à
k hí m ôi tr ư ờ n g c ủ a tổ c hứ c .
Ng u ồn đ i ệ n Ng u ồn đ i ệ n s ạc h c h o t ấ t c ả c ác t h iế t b ị m áy t ín h, v ớ i c ác t h iế t
b ị UP S nế u t híc h h ợ p.
S àn n â n g Đư ợc ư u t iê n n ếu c ó t h ể , n hư n g t ất c ả c ác c áp p h ả i đư ợc c hứ a
tr o n g đư ờ ng ố n g b ảo v ệ th íc h h ợp .
P há t h iệ n /n g ăn c há y v à Hệ th ố ng p há t hi ệ n k hó i / lử a v ă n p h òn g th ôn g thư ờ n g và h ệ
bì n h c h ữ a c há y th ố ng c ả nh b áo k ẻ x â m nh ậ p, tr ừ k hi n ơ i t ập tr un g n hi ề u t h i ết
b ị. Có đ ủ b ì nh c hữ a c há y l o ạ i t híc h h ợp , c ó b i ể n b á o v à q u y
tr ì nh ph ù h ợ p.
K ết n ố i m ạn g K hô n g gi a n v ăn p h òn g t ố t n h ất n ên đư ợc bố tr í đ ầ y đ ủ c ôn g
s uấ t đ ể t ă ng tr ư ởn g h ợ p l ý. T ất c ả c ác c á p p h ả i đư ợc đ ị n h v ị
v à c ố đ ị n h và o c ác k ha y c á p th íc h h ợ p. T ất c ả c ác th i ết b ị
m ạng p hả i đư ợc bả o m ật tr on g t ủ h oặc t ủ a n to à n .
K hô i p h ục s a u th ảm h ọa Các k ế h oạc h k hô i p h ục đư ợc k iểm n gh i ệm đ ầ y đ ủ n ên đư ợc

ph á t tr i ể n, n ế u t híc h h ợ p.

382
Phụ lục F: Mẫu SLA và OLA
Phụ lục này bao gồm các ví dụ về các SLA và OLA và n ội dung của
chúng. Chúng tôi không khuy ến cáo r ằng m ọi SLA và OLA nhất thiết
phải chứa m ọi phần được liệt kê trong tài liệu m ẫu dưới đây. Có ý
kiến đề xuất rằng các lĩnh vực này được xem xét khi chu ẩn bị các
biểu m ẫu tài liệu, nhưng chúng chỉ được kết hợp vào bản thân các
tài liệu thực tế khi chúng phù hợp và có liên quan. Do đó, nh ững
phác thảo dưới đây ch ỉ nên được xem là hướng dẫn hoặc danh sách
kiểm tra.
THỎ A THUẬN MỨC DỊCH VỤ (SLA – Mẫu)
Thỏa thuận này được lập giữa …………………… và ……………………
Thỏa thuận bao gồm việc cung c ấp và hỗ trợ cho các dịch vụ ABC
…………………………………… (m ô tả ngắn gọn dịch vụ).
Thỏa thuận này có hi ệu lực trong 12 tháng k ể từ (ngày) đến (ngày).

Thỏa thuận sẽ được xem xét hàng năm. Nh ững thay đổi nhỏ có thể
được ghi nhận vào bi ểu m ẫu ở cuối thỏa thuận, m iễn là chúng cùng
được hai bên xác nhận thực tế và được quản lý thông qua quy trình
Quản lý Thay đổi.
Ký
Tên ……………………………….. V ị trí ………………….. Ngày…………..
Tên ……………………………….. V ị trí ………………….. Ngày…………..
Mô tả dịch vụ
Dịch vụ ABC bao g ồm ……………… (m ột m ô tả đầy đủ hơn để bao
gổm các chức năng nghiệp vụ, các s ản phẩm có thể chuyển giao
được chủ yếu và m ọi thông tin liên quan đ ể m ô tả dịch vụ và quy
m ô, tác động và độ ưu tiên c ủa nó đối với doanh nghi ệp).
Phạm vi của thỏa thuận

Những gì được bao gồm trong thỏa thuận và những gì nằm ngoài
thỏa thuận?
Giờ dịch vụ
Một m ô tả về những giờ m à khách hàng có th ể kỳ vọng là dịch vụ sẽ
sẵn sàng (ví dụ 7 x 24 x 365, 08:00 đ ến 18:00 – Thứ Hai đến Thứ
Sáu).
Những điều kiện đặc biệt đối với các ngoại lệ (ví dụ, cuối tuần,
những ngày lễ chung) và các thủ tục yêu c ầu các ngoại lệ dịch vụ
(đầu m ối liên hệ - thường là B ộ phận Hỗ trợ Dịch vụ - và những chu
kỳ thông báo nào là bắt buộc).
Điều này có thể bao gồm m ột lịch dịch vụ hoặc tham chi ếu đến m ột
lịch dịch vụ.

383
Hãy liệt kê các chi tiết về bất kỳ thời điểm bảo trì hoặc dọn dẹp vệ
sinh tr ước-thỏa thuận nào, nếu có tác động đến giờ dịch vụ, cùng
với các chi ti ết về cách thức bất kỳ sự cố gián đoạn tiềm ẩn nào
khác phải được thương lượng và thỏa thuận – bởi ai và th ời gian
thông báo, v.v…
Các thủ tục đối với việc thay đổi vĩnh vi ễn giờ dịch vụ.
Tính sẵn sàng của dịch vụ

Đích nhắm m ục tiêu về m ức độ sẵn sàng m à nhà cung c ấp dịch vụ
CNTT sẽ tìm cách cung c ấp trong giờ dịch vụ đã thỏa thuận. Các
đích nhắm m ục tiêu về tính sẵn sàng trong các gi ờ dịch vụ đã thỏa
thuận, thường được biểu thị bằng t ỷ lệ phần trăm (ví d ụ: 99,5%),
khoảng thời gian đo lường, phương pháp và tính toán ph ải được quy
định. Con s ố này có thể được biểu thị cho dịch vụ tổng thể, các dịch
vụ nền tảng và các thành ph ần quan trọng hoặc cả ba. Tuy nhiên,
rất khó để liên hệ những con số phần trăm khả dụng đơn gi ản như
vậy với chất lượng dịch vụ hoặc với các hoạt động kinh doanh c ủa
khách hàng. Do đó, t ốt hơn là hãy cố gắng đo lường sự không s ẵn
có của dịch vụ xét về m ặt khách hàng không có kh ả năng tiến hành
các hoạt động kinh doanh của m ình. Ví d ụ: ’doanh số bán hàng b ị
ảnh hưởng ngay l ập tức do CNTT không cung c ấp dịch vụ hỗ trợ
POS thích hợp’. Mối liên hệ chặt chẽ này giữa dịch vụ CNTT và quy
trình nghiệp vụ của khách hàng là d ấu hiệu cho thấy sự trưởng
thành trong c ả quy trình SLM và các quy trình Quản lý Tính sẵ n
sàng.
Các chi tiết đã được thống nhất về cách thức và thời điểm m à điề u
này sẽ được đo lường và báo cáo, và trong kho ảng thời gian đã th ỏa
thuận cũng cần được lập thành văn bản.
Độ tin cậy
Số lần ngừng dịch vụ tối đa có thể chịu đựng được trong m ột khoảng
thời gian đã th ỏa thuận (có thể được định nghĩa là s ố lần ngừng, ví
dụ: bốn lần m ỗi năm hoặc là Thời gian trung bình Gi ữa các lần Hỏng
hóc (MTBF) ho ặc Thời gian trung bình Gi ữa các Sự cố Hệ thống
(MTBSI)).
Định nghĩa về những gì tạo thành m ột 'sự cố ngừng (dịch vụ)' và

cách những điều này s ẽ được theo dõi và ghi l ại.
Hỗ trợ khách hàng

Chi tiết về cách thức liên hệ với Bộ phận Hỗ trợ Dịch vụ, giờ làm
việc (của Bộ phận Hỗ trợ Dịch vụ), giờ sẵn sàng hỗ trợ và những
việc cần làm ngoài nh ững giờ này để được hỗ trợ (ví dụ: hỗ trợ theo
cuộc gọi, hỗ trợ của bên thứ ba, v.v…) phải được ghi lại. SLA cũng
có thể bao gồm tham chi ếu đến Internet/Intranet Self Help và/ho ặc
ghi nhật ký Sự cố. Các chỉ số và phép đo nên đư ợc bao gồm chẳng
hạn như m ục tiêu tr ả lời cuộc gọi điện thoại (số lần đổ chuông, cu ộc
gọi nhỡ, v.v...).
Mục tiêu về thời gian ph ản hồi Sự cố (bao lâu trư ớc khi ai đó bắt

384
đầu hỗ trợ khách hàng - có thể bao gồm thời gian di chuyển, v.v…).
Cần có định nghĩa về ‘phản hồi’ - Đó là m ột cuộc điện thoại gọi lại
cho khách hàng hay m ột chuyến thăm trang viếng địa điểm ? - khi
thích hợp.
Các thỏa thuận để yêu cầu hỗ trợ m ở rộng, bao gồm cả khoảng thờ i
gian thông báo b ắt buộc (ví dụ: yêu cầu phải được gửi đến Bộ phận
Hỗ trợ Dịch vụ trước 12 giờ trưa đối với m ở rộng vào buổi tối, m uộn
nhất là 12 giờ trưa thứ năm đối với m ở rộng vào cuối tuần)
Ghi chú. Cả thời gian ph ản hồi và giải quyết Sự cố sẽ dựa trên bất
kỳ m ã ưu tiên/tác đ ộng sự cố nào được sử dụng - chi tiết về phân
loại Sự cố cũng nên được nêu ở đây.
Ghi chú. Trong m ột số trường hợp, có thể thích hợp để tham chi ếu
đến các liên h ệ và hợp đồng và OLA của bên thứ ba - nhưng đây
không phải là m ột cách chuyển hướng trách nhiệm .
Đầu mối liên hệ và leo thang

Chi tiết về đầu m ối liên hệ trong m ỗi bên tham gia vào th ỏa thuận và
các quy trình leo thang cùng đ ầu m ối liên hệ. Việc này cũng bao
gồm định nghĩa về m ột khiếu nại và thủ tục để quản lý các khi ếu nại.
Hiệu suất dịch vụ

Chi tiết về khả năng đáp ứng dự kiến của dịch vụ CNTT (ví d ụ: thời
gian phản hồi trung bình c ủa m áy trạm m ục tiêu, hoặc thời gian phả n
hồi tối đa của m áy trạm , đôi khi được biểu thị dưới dạng phân vị - ví
dụ: 95% trong vòng hai giây), chi ti ết về thông lượng dịch vụ được
kỳ vọng dựa trên m ục tiêu và bất kỳ ngưỡng nào có t hể làm m ất hiệu
lực của các m ục tiêu).
Điều này nên bao gồm chỉ số về lưu lượng có thể có, hoạt động
thông lượng, các ràng bu ộc và phụ thuộc (ví dụ: số lượng giao d ịch
được xử lý, số lượng người dùng đồng thời và lượng dữ liệu được
truyền tải qua m ạng). Điều này rất quan tr ọng để từ đó có thể xác
định được các vấn đề về hiệu suất gây ra bởi thông lượng quá m ức
nằm ngoài các đi ều khoản của thỏa thuận.
Thời gian quay vòng hàng lo ạt

Nếu thích hợp, thông tin chi ti ết về bất kỳ thời gian quay vòng c ủa
hàng loạt, thời gian hoàn thành và các s ản phẩm chính, bao g ồm
thời gian giao đ ầu vào và thời gian và đ ịa điểm giao đầu ra nếu
thích hợp.
Chức năng (n ếu thích hợp)

Chi tiết về chức năng t ối thiểu được cung c ấp và số lỗi của các loại
cụ thể có thể được chấp nhận trước khi SLA b ị vi phạm . Nên bao
gồm m ức độ nghiêm trọng và thời gian báo cáo.
Thay đổi cách quản lý

Đề cập ngắn gọn và/hoặc tham chiếu đến các thủ tục Quản lý Thay

385
đổi của tổ chức phải được tuân thủ - chỉ để củng cố sự tuân thủ.
Ngoài ra, các đích nhắm m ục tiêu về phê duyệt, xử lý và triển khai
RFC, thường dựa trên thể loại hoặc m ức độ khẩn cấp/ưu tiên của
thay đổi, cũng c ần được bao gồm và chi tiết về bất kỳ thay đổi đã
biết nào sẽ ảnh hưởng đến thỏa thuận, nếu có.
Liên tục dịch vụ

Đề cập ngắn gọn và/hoặc tham chiếu đến các K ế hoạch Liên t ục
Dịch vụ của tổ chức, cùng với các chi ti ết về cách SLA có thể bị ảnh
hưởng hoặc tham chi ếu đến SLA Liên tục riêng bi ệt, chứa các chi
tiết về bất kỳ m ục tiêu d ịch vụ nào bị cắt giảm hoặc sửa đổi nếu tình
huống thiên tai xảy ra. Chi ti ết về bất kỳ trách nhiệm cụ thể nào của
cả hai bên (ví d ụ: sao lưu dữ liệu, lưu trữ bên ngoài địa điểm ).
Ngoài ra, chi ti ết về việc yêu c ầu các kế hoạch và phạm vi c ủa bất
kỳ vấn đề bảo m ật nào, đặc biệt là bất kỳ trách nhiệm nào của khách
hàng (ví dụ: điều phối các hoạt động kinh doanh, tài li ệu kinh doanh,
sao lưu các m áy tính cá nhân, thay đ ổi m ật khẩu).
Bảo mật
Đề cập ngắn gọn và/hoặc tham chiếu đến Chính sách Bảo m ật của
tổ chức (bao gồm các vấn đề như kiểm soát m ật khẩu, vi ph ạm bảo
m ật, phần m ềm trái phép, vi rút, v.v ...). Chi tiết về bất kỳ trác h
nhiệm cụ thể nào c ủa cả hai bên (ví d ụ: Bảo vệ chống Vi-rút, Tường
lửa).
In ấn
Chi tiết về bất kỳ điều kiện đặc biệt nào liên quan đến in ấn hoặc
m áy in (ví d ụ: chi tiết phân phối bản in, thông báo về các lần hoạt
động in ấn tập trung lớn hoặc xử lý bất kỳ văn phòng ph ẩm đặc biệt
nào có giá trị cao).
Trách nhiệm
Chi tiết về trách nhi ệm của các bên khác nhau liên quan đ ến dịch vụ
và các trách nhi ệm đã thỏa thuận của họ, bao gồm nhà cung c ấp
dịch vụ, khách hàng và ngư ời dùng.
Tính phí (nếu có)

Chi tiết về bất kỳ công thức tính phí nào đư ợc sử dụng, thời hạ n
tính phí hoặc tham chiếu đến các tài li ệu chính sách tính phí, cùng
với quy trình l ập hóa đơn và điều kiện thanh toán, v.v.. phải được
bao gồm . Điều này cũng nên bao g ồm chi tiết về bất kỳ hình phạt
hoặc tiền thưởng tài chính nào s ẽ được chi trả nếu m ục tiêu dịch vụ
không đạt được kỳ vọng. Các khoản phạt/tiền thưởng sẽ như thế
nào và chúng sẽ được tính toán, th ỏa thuận và thu/trả như thế nào
(phù hợp hơn với các tình huống của bên thứ ba). Nếu SLA bao g ồm
m ối quan hệ thuê ngoài, các kho ản phí nên được nêu chi tiết trong
Phụ lục vì chúng thường được bao gồm trong các đi ều khoản về độ
tin cậy thương m ại.
Cần lưu ý r ằng các đi ều khoản phạt có thể tạo ra những khó khăn
của riêng chúng. Chúng có thể chứng minh m ột rào cản đối với quan

386
hệ đối tác nếu bị viện dẫn không công bằng về tính kỹ thuật và cũng
có thể khiến cho nhân viên của nhà cung cấp dịch vụ không m uốn
thừa nhận sai lầm vì sợ bị phạt. Điều này, trừ khi được sử dụng
đúng cách, có th ể là rào c ản để phát triển các m ối quan hệ hiệu quả
và giải quyết vấn đề.
Báo cáo và xem xét d ịch vụ

Nội dung, t ần suất, nội dung, thời điểm và sự phân phối các báo cáo
dịch vụ, và tần suất của các cuộc họp đánh giá dịch vụ liên quan.
Ngoài ra, chi ti ết về cách thức và thời điểm SLA và các m ục tiêu
dịch vụ tương ứng sẽ được xem xét và có th ể được sửa đổi, bao
gồm cả những người sẽ tham gia và công suất như thế nào.
Bảng chú giải

Giải thích bất kỳ từ viết tắt hoặc thuật ngữ không thể tránh khỏi
được sử dụng, để hỗ trợ sự cho hiểu biết của khách hàng.
Bản ghi sửa đổi

Bao gồm m ột bản ghi về bất kỳ sửa đổi đã được thống nhất nào, vớ i
các chi tiết của sửa đổi, ngày tháng và ngư ời ký. Nó cũng nên chứa
các chi tiết về lịch sử thay đổi hoàn chỉnh của tài liệu và các b ản
sửa đổi của nó.
Cần lưu ý r ằng nội dung SLA đưa ra ở trên chỉ là ví dụ. Chúng
không nên được coi là đầy đủ hoặc bắt buộc, nhưng chúng cung c ấ p
m ột điểm khởi đầu tốt cho bạn.

387
THỎ A THUẬN MỨC VẬN HÀNH (OLA – Mẫu)
Thỏa thuận này được lập giữa ……………………..và ……………………
Thỏa thuận bao gồm việc cung c ấp dịch vụ hỗ trợ cung cấ p

…………………….. (m ô tả tóm tắt dịch vụ).
Thỏa thuận này có hi ệu lực trong 12 tháng t ừ (ngày) đến (ngày).
Thỏa thuận sẽ được xem xét hàng năm. Nh ững thay đổi nhỏ có thể
được ghi nhận vào bi ểu m ẫu ở cuối thỏa thuận, m iễn là chúng cùng
được hai bên xác nhận thực tế và được quản lý thông qua quy trình
Quản lý Thay đổi.
Ký
Tên ……………………………….. V ị trí ………………….. Ngày…………..
Tên ……………………………….. V ị trí ………………….. Ngày…… ……..
Chi tiết về các điều chỉnh trước đó

Mô tả dịch vụ hỗ trợ
Giải thích toàn di ện và chi tiết về dịch vụ hỗ trợ đang được cung
cấp.
Phạm vi của thỏa thuận

Những gì được bao gồm và không được bao gồm trong thỏa thuận?
Giờ dịch vụ
Một m ô tả về những giờ m à dịch vụ hỗ trợ được cung c ấp.
Đích nhắm mục tiêu dịch vụ

Các đích nhắm m ục tiêu đối với việc cung c ấp dịch vụ hỗ trợ và báo
cáo và xem xét các quy trình và t ần suất.
Đầu mối liên hệ và leo thang

Thông tin chi ti ết về các địa chỉ liên hệ trong m ỗi bên liên quan trong
thỏa thuận và các quy trình leo thang và các đ ầu m ối liên hệ.
Bộ phận Hỗ trợ Dịch vụ và thời gian phản hồi sự cố và trách

nhiệm
Các trách nhi ệm và đích nhắm m ục tiêu đã được thống nhất cho ti ến
độ và giải quyết các Sự cố và sự hỗ trợ của Bộ phận Hỗ trợ Dịch vụ.
Thời gian và trách nhi ệm phản hồi sự cố

Các trách nhi ệm và đích nhắm m ục tiêu đã được thống nhất cho ti ến
độ và giải quyết các vấn đề.
Quản lý Thay đổi

Các trách nhiệm và đích nhắm m ục tiêu đã được thống nhất về tiế n
độ và việc triển khai các thay đổi.

388
Quản lý Phát hành
Các trách nhiệm và đích nhắm m ục tiêu đã được thống nhất về tiế n
độ và việc triển khai các bản phát hành.
Quản lý Cấu hình

Các trách nhi ệm đối với quyền sở hữu, cung c ấp và duy trì thông tin
Quản lý Cấu hình chính xác.
Quản lý Bảo mật Thông tin

Các trách nhiệm và đích nhắm m ục tiêu đã được thống nhất để hỗ
trợ (các) Chính sách B ảo m ật và quy trình Quản lý Bảo mật Thông
tin.
Quản lý Tính sẵn sàng

Trách nhiệm cho việc đảm bảo rằng mọi thành phần trong lĩnh vực
hỗ trợ của chúng được quản lý và hỗ trợ để đáp ứng và tiếp t ục đáp
ứng tất cả các đích nhắm m ục tiêu về tính sẵn sàng của dịch vụ và
thành phần.
Quản lý Liên tục Dịch vụ

Trách nhiệm cho việc đảm bảo rằng mọi thành phần trong lĩnh vực
hỗ trợ của chúng có các kế hoạch khôi phục đã được cập nhật và
kiểm tra để hỗ trợ các yêu cầu của doanh nghi ệp đã được thống
nhất và được lập thành văn bản. Việc này nên bao gồm hỗ trợ về
đánh giá về m ặt kỹ thuật và quản lý và gi ảm thiểu rủi ro tiếp theo đó.
Quản lý Công suất

Trách nhiệm cho việc hỗ trợ các nhu c ầu của quy trình Qu ản lý Công
suất trong phạm vi đã đư ợc thỏa thuận của lĩnh vực kỹ thuật của họ.
Quản lý Mức Dịch vụ

Hỗ trợ định nghĩa và th ỏa thuận các đích nh ắm m ục tiêu thích hợp
trong SLA, SLR và OLA, liên quan đ ến các thành ph ần trong phạm vi
lĩnh vực kỹ thuật của họ.
Quản lý Nhà cung cấp

Hỗ trợ quản lý các hợp đồng và nhà cung c ấp, m ột lần nữa, chủ yếu
trong phạm vi lĩnh vực kỹ thuật của họ.
Cung cấp thông tin

Việc cung c ấp và duy trì thông tin chính xác, bao g ồm dữ liệu tài
chính cho m ọi thành phần trong phạm vi đã th ỏa thuận của lĩnh vực
kỹ thuật của họ.
Bảng chú giải
Giải thích bất kỳ từ viết tắt hoặc thuật ngữ không thể tránh khỏi
được sử dụng, để giúp hiểu rõ các điều khoản trong thỏa thuận.
Bản ghi sửa đổi
Bao gồm m ột hồ sơ về bất kỳ sửa đổi đã đồng ý nào, với các chi tiết
về sửa đổi, ngày tháng và ngư ời ký. Nó cũng nên chứa các chi tiết
về lịch sử thay đổi hoàn chỉnh của tài liệu và các bản sửa đổi của
nó.

389
Phụ lục G: Ví dụ về Mục lục Dịch vụ
Mục lục Dịch vụ là tài liệu chủ yếu bao gồm những thông tin có giá tr ị về toàn bộ các dịch vụ đã được cung c ấp.
Tốt hơn hết là nó nên đư ợc lưu tr ữ như là m ột bộ các CI ‘dịch vụ’ trong m ột CMS, được duy trì trong Quản lý
Thay đổi. Vì nó là m ột tập hợp thông tin c ực kỳ có giá trị, vì vậy, nó nên sẵn sàng cho b ất kỳ ai trong t ổ chức.
Mọi dịch vụ m ới nên được đưa vào Mục lục Dịch vụ ngay lập tức m ột khi định nghĩa ban đầu của nó về các yêu
cầu đã được lập thành văn b ản và thống nhất. Vì vậy, cũng như thông tin dư ới đây, Mục lục Dịch vụ nên ghi
nhận lại tình trạng của m ỗi dịch vụ, thông qua các giai đo ạn của vòng đời đã được xác định của nó.
Tê n Mô t ả Kiểu Các (các) Chủ (các) Đơn (các) Tá c đ ộ n g Ưu tiên SLA Giờ Đầu Đầu Báo Xe m Xế p
dịch dịch dịch dịch vụ sở hữu vị K i n h Nhà quản kinh của doanh dịch mối mối cáo xé t hạng
vụ vụ vụ hỗ trợ DN doanh lý dịch doanh nghiệp vụ liên liên hệ dịch dịch bảo
vụ hệ leo vụ vụ mật
của thang
DN
Dịch
vụ 1
Dịch
vụ 2
Dịch
vụ 3
Dịch
vụ 4
Bảng G.1 Ví dụ về Mục lục Dịch vụ

390
Phụ lục H: Khuôn kh ổ trưởng thành của qu y trình Quản lý Dịch
vụ
Khuôn khổ m ức độ trưởng thành của quy trình (PMF) có th ể được sử
dụng làm khuôn kh ổ để đánh giá m ức độ trưởng thành c ủa từng quy
trình Quản lý Dịch vụ riêng lẻ hoặc để đo lường m ức độ trưởng
thành của toàn bộ quy trình Quản lý Dịch vụ. Đây là m ột phương
pháp tiếp cận đã đư ợc sử dụng rộng rãi trong ngành CNTT trong m ột
số năm , với nhiều m ô hình độc quyền được m ột số tổ chức sử dụng.
PMF cụ thể này đã được phát triển để m ang lại m ột phương pháp
tiếp cận chung, thực tiễn tốt nhất cho vi ệc xem xét và đánh giá m ức
độ hoàn thiện của quy trình Qu ản lý Dịch vụ. Khuôn khổ này, được
thể hiện trong Hình H.1, có th ể được các tổ chức sử dụng để đánh
giá nội bộ các quy trình Qu ản lý Dịch vụ của chính họ cũng như các
tổ chức bên thứ ba được đưa vào v ới tư cách là người xem xét,
đánh giá hoặc kiểm toán bên ngoài.
Hình H.1 – Khuôn khổ trưởng thành của qu y trình
Việc sử dụng PMF trong đánh giá các quy trình Qu ản lý Dịch vụ dựa
trên sự thích hợp của Mô hình Tăng trưởng Tổ chức CNTT. S ự
trưởng thành c ủa các quy trình Qu ản lý Dịch vụ phụ thuộc nhiều vào
giai đoạn phát tri ển của toàn bộ tổ chức CNTT. Rất khó, nếu không
m uốn nói là không th ể, để phát triển sự trưởng thành c ủa các quy
trình Quản lý Dịch vụ vượt quá sự trưởng thành và khả năng của
toàn bộ tổ chức CNTT. Sự trưởng thành của tổ chức CNTT không
chỉ phụ thuộc vào sự trưởng thành của các quy trình Qu ản lý Dịc h
vụ. Mỗi cấp độ đòi hỏi sự thay đổi của sự kết hợp của các yếu tố để
đạt được hiệu quả đầy đủ.
Do đó, việc xem xét các quy trình s ẽ yêu c ầu sự đánh giá phải đượ c
hoàn thành đối với năm lĩnh vực:

391
 Tầm nhìn và ch ỉ đạo.
 Quy trình.
 Con người.
 Công nghệ.
 Văn hóa.
Đây là năm lĩnh v ực đã được m ô tả trong PMF đ ể đánh giá s ự

trưởng thành c ủa quy trình. Các đặc điểm chính của m ỗi cấp củ a
PMF như sau.
Khởi đầu (Mức độ 1)

Quy trình đã được công nhận nhưng có r ất ít hoặc không có ho ạt
động quản lý quy trình và nó không đư ợc phân bổ tầm quan tr ọng,
tài nguyên ho ặc sự tập trung trong tổ chức. Mức độ này cũng có th ể
được m ô ta là ‘đ ột xuất’ hoặc đôi khi th ậm chí là ‘h ỗn loạn’.
T ầm nhì n v à s ự c h ỉ đạ o Ng u ồn v ốn v à t à i n g u yê n t ố i t h iể u v ớ i ít ho ạ t
độ n g.
Các k ết q uả t ạm th ờ i , k hôn g đư ợc g iữ lạ i .
Các b á o c á o v à đ án h g iá l ẻ t ẻ.
Q u y trì n h Các q u y t rì nh và t h ủ t ục đư ợc x ác đ ị n h m ột c ác h
l ỏn g l ẻ o, đư ợc s ử d ụ n g m ột c ác h ứ n g p hó k h i c ó
v ấn đề x ả y r a.
Các q u y tr ìn h h o àn t o àn là ứ ng ph ó.
Các h o ạt độ n g k hôn g t hư ờn g x u yê n , k hô n g c ó k ế
ho ạc h.
Co n n gư ờ i Các va i tr ò và tr ác h nh i ệm đư ợc x ác đ ị n h m ột
c ác h lỏ n g l ẻo .
Cô n g ng h ệ Các q u y trì n h t h ủ c ôn g ho ặc m ột s ố c ô n g c ụ c ụ
th ể, r ờ i r ạc ( p oc k ets / is la n ds ) ( đ o ạn này k hô n g
h iể u t ác g iả đ ị n h n ói g ì v ớ i ha i t ừ poc k et / is la nd ) .
V ăn h ó a Dự a trê n c ôn g c ụ v à c ôn g n g h ệ v à đ ư ợc th úc
đẩ y v ớ i m ột tr ọ ng t âm ho ạ t độ n g m ạn h m ẽ.
Bảng H.1 PMF Mức độ 1: khởi đầu

392
Có thể lặp lại (Mức độ 2)
Quy trình đã được công nhận và nó được phân bổ m ột chút t ầm
quan tr ọng, tài nguyên ho ặc sự tập trung trong t ổ chức. Các ho ạt
động thông thư ờng liên quan đ ến quy trình là không đư ợc phối hợp,
không thư ờng xuyên, không có đ ịnh hướng và được định hướng t ới
tính hiệu quả của quy trình.
T ầm nhì n v à s ự c h ỉ đạ o K hô n g c ó m ục ti êu r õ ràn g h o ặc đ íc h nh ắm m ục
ti ê u c hí n h th ứ c .
K in h p hí v à n gu ồ n lự c c ó s ẵ n.
Các ho ạ t đ ộn g , b áo c áo v à đ á nh g iá k hô n g
thư ờ n g x u yê n , k h ôn g c ó k ế h oạc h .
Q u y trì n h Các q u y tr ìn h v à t h ủ t ục đ ã đư ợc x ác đ ị nh .
Q u y trì n h p h ả n ứ n g m ạn h m ẽ.
Các h o ạt độ n g k hôn g t hư ờn g x u yê n , k hô n g c ó k ế
ho ạc h.
Co n n gư ờ i Các va i tr ò v à tr ác h n h i ệm k hé p k ín .
Cô n g ng h ệ Nh i ều c ôn g c ụ r ờ i r ạc , n hư ng t h i ếu k iểm s o á t .
Dữ l i ệu đư ợc lư u tr ữ ở c ác v ị t rí ri ê n g b i ệ t.
V ăn h ó a Dự a tr ê n v à đ ị nh h ư ớn g s ả n ph ẩm v à d ịc h v ụ .
Bảng H.2 PMF Mức độ 2: có thể lặp lại

393
Đã xác định (Mức độ 3)
Quy trình đã được công nhận và được lập thành văn b ản nhưng vẫn
chưa được thỏa thuận, chấp thuận hoặc công nhận chính thức về
vai trò c ủa nó trong vận hành toàn thể CNTT. Tuy nhiên, quy trình
đã có chủ sở hữu quy trình, các m ục tiêu và đích nhắm m ục tiêu
chính thức với các tài nguyên đư ợc phân bổ, và được tập trung vào
hiệu suất cũng như t ính hiệu quả của quy trình. Các báo cáo và k ết
quả được lưu tr ữ cho m ục đích tham chi ếu trong tương lai.
T ầm nhì n v à s ự c h ỉ đạ o Các m ục ti ê u và đíc h nh ắm m ục ti êu c hí n h th ứ c

đư ợc l ậ p t h à nh vă n b ả n v à t hố n g nh ấ t.
Các k ế h o ạc h đư ợc c ôn g b ố, g i ám s át v à x em
x ét m ột c ác h c hí nh t h ứ c .
Đư ợc tà i tr ợ t ốt v à c ó ng u ồn lự c t híc h h ợ p.
B áo c á o và đ á n h g iá t hư ờn g x u yê n , c ó k ế h oạc h .
Q u y trì n h Các q u y t rì nh và t h ủ t ục đư ợc x ác đ ị n h m ột c ác h
r õ r à ng v à c ôn g k ha i .
Các h o ạt đ ộ ng t hư ờ n g x u yê n , c ó k ế ho ạc h.
T ài l i ệu t ốt .
Đô i k hi l à q u y tr ìn h c h ủ đ ộn g
Co n n gư ờ i V ai tr ò và trác h nh i ệ m đư ợc x ác đ ịn h m ột c ác h
r õ r à ng v à đư ợc t hố n g n h ất .
Các m ục t i êu v à đíc h nh ắm m ục t iê u c h ín h t h ứ c .
K ế ho ạc h đà o t ạ o v ề qu y tr ìn h đư ợc c h ín h th ứ c
hó a .
Cô n g ng h ệ T hu t h ập d ữ l iệ u l i ên t ục vớ i c ả n h bá o v à g iám
s át n gư ỡ n g.
Dữ li ệ u tổ n g h ợ p đư ợc lư u gi ữ và s ử dụ n g để
l ập k ế ho ạc h, d ự bá o v à x u hư ớ n g c hí n h th ứ c .
V ăn h ó a Đị n h hư ớ ng D ịc h v ụ v à K h ác h hà n g v ớ i m ột
phư ơ n g p há p t i ếp c ậ n đư ợc c hí n h th ứ c hó a .
Bảng H.2 PMF Mức độ 3: đã được xác định

394
Đã được quản lý (Mức độ 4)
Giờ đây, quy trình đã đư ợc công nhận và chấp thuận hoàn toàn
CNTT. Dịch vụ được tập trung và đã có các m ục tiêu và đích nh ắm
m ục tiêu dựa trên nh ững m ục đích và m ục tiêu c ủa doanh nghi ệp.
Quy trình được xác định và quản lý hoàn toàn, và trở nên chủ động
với các giao diện và phụ thuộc được thiết lập với quy trình CNTT
khác.
T ầm nhì n v à s ự c h ỉ đạ o Đị n h hư ớ ng r õ rà ng v ớ i m ục tiê u , m ục đíc h v à

đíc h n h ắm k in h d oa n h c hí nh th ứ c , t i ế n đ ộ đ ư ợc
đo lư ờn g .
Các b áo c á o q u ản l ý h iệ u qu ả đư ợc t íc h c ự c s ử
dụ n g.
Các k ế h oạc h q u y tr ì nh t íc h h ợ p đư ợc li ê n k ết
v ớ i k ế h o ạc h k in h d oa nh v à CNT T .
Cả i t i ế n t hư ờn g x u yê n, đư ợc lê n k ế h oạc h và
đư ợc x em x ét .
Q u y trì n h Các q u y tr ìn h , th ủ t ụ c và t i ê u c hu ẩ n đư ợc x ác
đ ịn h rõ r àn g , đư ợc b a o g ồm tron g t ấ t c ả c ác bả n
m ô tả c ô n g v i ệc c ủ a n hâ n vi ê n CNT T .
Các g ia o di ệ n và p h ụ th uộc c ủ a q u y tr ì nh đư ợc
x ác đ ịn h m ột c ác h r õ r àn g .
Q u ản l ý d ịc h v ụ và c ác q u y tr ì nh p há t tr i ể n c ác
hệ t h ốn g đư ợc t íc h h ợ p.
Ch ủ yế u l à q u y trì n h c h ủ độ n g.
Co n n gư ờ i Làm vi ệc n h óm c ả tro n g v à n go à i q u y trì n h .
T r ác h n h i ệm đư ợc x á c đ ị n h r õ rà n g tr o ng t ất c ả
c ác m ô t ả c ô n g v i ệc C NT T .
Cô n g ng h ệ L iê n t ục đ o lư ờn g g i á m s át , bá o c á o v à c ả n h b áo
ngư ỡ n g đố i v ớ i m ột t ập h ợ p đư ợc t ậ p tr u n g và o
c ác bộ c ô n g c ụ, c ơ s ở dữ l i ệu và q u y trì n h tíc h
h ợp .
V ăn h ó a Do a nh n g h iệ p t ập tr u ng v ớ i s ự h i ể u b iế t v ề c ác
v ấn đề r ộ n g l ớ n h ơ n.
Bảng H.2 PMF Mức độ 4: đã được quản lý

395
Tối ưu hóa (Mức đ ộ 5)
Đến đây thì quy trình đã được công nhận hoàn toàn và có các m ục
đích và m ục tiêu chi ến lược phù hợp với các m ục tiêu chiến lược
tổng thể của doanh nghiệp và CNTT. Giờ đây, những điều này đã
được ‘thể chế hóa’ như m ột phần của hoạt động hàng ngày cho m ọi
người tham gia vào qu y trình này. Một quá trình c ải tiến liên tục
khép kín được thiết lập như m ột phần của quá trình, vốn giờ đây
đang được phát triển khả năng ngăn chặn trước .
T ầm nhì n v à s ự c h ỉ đạ o Các k ế h o ạc h c h i ến l ư ợc đư ợc t íc h h ợ p g ắ n b ó
m ột c ác h c h ặt c h ẽ v ớ i c ác k ế h o ạc h , m ục đíc h
v à m ục ti ê u k i n h do a n h t ổ n g th ể .
L iê n t ục t h e o dõ i , đ o lư ờ n g, b á o c á o c ản h b á o
v à đ á n h g i á l i ê n k ết v ớ i m ột qu á trì nh c ả i ti ế n
l iê n t ục .
Đá n h g iá v à / h oặc k i ể m toá n t hư ờ ng x u yê n v ề
tí nh hi ệ u lự c , h iệ u q u ả v à t u ân t h ủ.
Q u y trì n h Các q u y trì n h v à t h ủ tục đư ợc x ác đ ị n h r õ ràn g
như l à m ột p hầ n c ủ a v ăn hó a d oa n h n gh i ệ p.
Q u y trì n h c h ủ độ n g v à n g ăn c h ặ n trư ớc .
Co n n gư ờ i Các m ục ti ê u và đíc h nh ắm m ục ti êu c hí n h th ứ c
l iê n k ết v ó i v iệc k i n h do a nh đư ợc g i ám s át m ột
c ác h tíc h c ự c n hư m ột ph ầ n c ủa h oạ t độ n g h àn g
ng à y.
V ai tr ò và tr ác h n h i ệ m là m ột p hầ n c ủa v ă n h ó a
do a nh ng h iệ p t ổ ng t h ể .
Cô n g ng h ệ K iế n trúc c ô ng c ụ t ổ ng th ể đư ợc gh i nh ậ n đ ầ y
đủ , c ùn g v ớ i s ự tíc h h ợp h oà n c h ỉn h tro n g m ọi
lĩ n h vự c v ề c on ngư ờ i , q u y trì n h v à c ô ng ng h ệ.
V ăn h ó a T hái đ ộ c ả i t i ế n l i ê n t ục , c ù ng v ớ i m ột c h iế n
lư ợc t ập tr u ng và o d oa n h ng h i ệp . H iể u b i ết về
g iá tr ị c ủa CNT T đ ố i v ớ i do a nh n g hi ệ p v à va i t rò
c ủa nó tr o ng c hu ỗ i g iá tr ị k i n h do a n h .
Bảng H.2 PMF Mức độ 5: tối ưu hóa.
Khuôn khổ trưởng thành này được liên kết với Sofrware Engineering
Institute Capability Maturity Model® Integration (SEI CMMI) và các
m ô hình biến thể của chúng, bao gồm m ô hình ti ến hóa CMMI -SVC,
vốn tập trung vào vi ệc cung c ấp các dịch vụ.

396
Phụ lục I: Ví dụ về nội dung của một Tu yên bố về các Yêu cầu
(SoR) và/ho ặc Thư mời tham gia Đ ấu thầu (ITT)
Dưới đây là m ột ví dụ về m ột bộ tối thiểu các nội dung nên được bao
gồm trong m ột ITT hoặc SoR:
 Một m ô tả về các dịch vụ, sản phẩm và/hoặc các thành phần
cần thiết.
 Mọi đặc tả kỹ thuật, chi tiết và các yêu cầu kỹ thuật liên quan.
 Một SLR nếu có thể.
 Các yêu cầu về tính sẵn sàng, độ tin cậy, khả năng bảo trì và
khả năng phục vụ.
 Các chi ti ết về quyền sở hữu phần cứng, phần m ềm , các tòa
nhà, các cơ sở vật chất, v.v…
 Các chi tiết về tiêu chí hiệu suất cần được đáp ứng bởi thiết bị
và (các) nhà cung c ấp.
 Các chi tiết về m ọi tiêu chuẩn cần được tuân thủ (nội bộ, bên
ngoài, quốc gia và qu ốc tế).
 Các yêu cầu quy định và pháp lý (c ủa ngành, qu ốc gia, EU và
quốc tế).
 Các chi tiết về tiêu chí chất lượng.
 Các khung thời gian, chi tiết và yêu c ầu, các điều khoản và
điều kiện hợp đồng.
 Mọi xem xét về m ặt thương m ại: chi phí, định phí, thanh toán
và lịch trình phần thưởng và các kho ản phạt.
 Các giao di ện và hợp đồng cần thiết.
 Các phương pháp qu ản lý dự án được sử dụng.
 Các thủ tục báo cáo, giám sát và xem xét và các tiêu chí đư ợc
sử dụng trong và sau khi tri ển khai.
 Các yêu c ầu và đi ều kiện nhà cung c ấp.
 Các yêu c ầu đối với nhà thầu phụ.
 Các chi tiết về bất kỳ điều khoản và điều kiện có liên quan.
 Mô tả về các yêu c ầu phản hồi nhà cung cấp:
o Định dạng.
o Tiêu chí.
o Các điều kiện.
o Các khung thời gian.
o Những khác bi ệt và thiếu sót.
o Trách nhiệm và các yêu cầu của khách hàng.
 Các chi ti ết về sự tăng trưởng khả thi và đã được lập kế
hoạch.
 Các thủ tục cho xử lý thay đổi.
 Các chi tiết về nội dung và cấu trúc c ủa những phản hồi cần
thiết.

397
Phụ lục J: Nội dung điển hình của một Kế hoạch Công suất
Những nội dung điển hình của m ột Kế hoạch Công suất bao gồm :
1 Giới thiệu
Phần này giải thích ngắn gọn về nền t ảng của vấn đề này của Kế
hoạch Công su ất, cách nó được đưa ra như thế nào và nội dung c ủa
nó là gì. Ví dụ:
 Các dịch vụ, công nghệ và tài ngu yên hiện tại.
 Mức công su ất hiện tại của tổ chức.
 Các vấn đề đang trải qua hoặc được hình dung do công su ất
quá cao hoặc quá thấp.
 Mức m à các m ức độ dịch vụ đang đạt được.
 Những gì đã thay đ ổi kể từ vấn đề cuối cùng c ủa kế hoạch
2 Tóm tắt quản lý

Phần lớn Kế hoạch Công suất, do sự cần thiết, đều chứa các chi ti ết
kỹ thuật không được tất cả người đọc kế hoạch quan tâm . B ản tóm
tắt quản lý nên nêu rõ các vấn đề chính, các lựa chọn, khuyến nghị
và chi phí. Có thể cần phải tạo ra m ột tài liệu tóm tắt chung riêng
biệt bao gồm các đi ểm chính từ m ỗi phần của kế hoạch chính.
3 Tình huống kinh doanh

Điều cần thiết là phải đặt kế hoạch vào bối cảnh của môi trư ờng
kinh doanh hi ện t ại và được dự kiến. Ví dụ, m ột hãng hàng không
của Anh đã lên k ế hoạch chuyển m ột lượng lớn nhân viên vào tòa
nhà trụ sở chính c ủa hãng. T ỷ lệ 1,7 người trên m ỗi thiết bị đầu cuối
m áy tính đ ể bàn đã được dự báo. Quản lý Công suất đã được cảnh
báo và đã có khả năng tính toán lưu lượng m ạng bổ sung s ẽ cần
đến.
Điều quan tr ọng là ph ải đề cập m ột cách rõ ràng t ất cả các dự báo

kinh doanh đã biết để người đọc có thể xác định những gì nằm trong
và ngoài phạm vi c ủa kế hoạch. Nó ph ải bao gồm sự tăng trưởng đã
được dự kiến trong các d ịch vụ hiện có, các dịch vụ m ới tiềm năng
và các dịch vụ hiện có đã được lên lịch trình dự kiến đóng c ửa.
4 Phạm vi và điều khoản tham chiếu của kế hoạch

Lý tưởng nhất, Kế hoạch Công suất nên bao gồm tất cả các tài
nguyên CNTT. Phần này nên đặt tên m ột cách rõ ràng những phần
tử của cơ sở hạ tầng CNTT đư ợc bao gồm và những phần tử bị loạ i
trừ, nếu có.
5 Phương pháp đư ợc sử dụng

Kế hoạch Công suất sử dụng thông tin được thu thập bởi các qu y
trình con. Do đó, ti ểu m ục này phải bao gồm chi tiết về cách thức và
thời điểm thu thập những thông tin này - ví dụ, dự báo kinh doan h
thu được từ kế hoạch kinh doanh, dự báo khối lượng công việc thu
được từ khách hàng, dự báo m ức độ dịch vụ thu được bằng cách s ử
dụng các công c ụ mô hình hóa.

398
6 Giả định được đưa ra
Điều quan tr ọng là bất kỳ giả định nào đã được đưa ra, đ ặc biệt là
những giả định liên quan đ ến các định hướng kinh doanh cho Năng
lực CNTT, phải được nêu rõ ngay t ừ đầu trong k ế hoạch. Nếu chúng
là nền tảng để xây dựng các tính toán chi ti ết hơn, thì đi ều sống còn
là tất cả những người có liên quan ph ải hiểu điều này
7 Tóm tắt dịch vụ

Phần tóm tắt dịch vụ nên bao gồm :
 Việc cung cấp dịch vụ hiện tại và g ần đây: đối với m ỗi dịch
vụ được cung cấp, hãy cung cấp m ột hồ sơ dịch vụ. Điều này
phải bao gồm tỷ lệ thông lượng và vi ệc kết quả sử dụng tài
nguyên - ví dụ: bộ nhớ, không gia n lưu trữ, tốc độ truyền, m ức
độ sử dụng bộ xử lý và m ức độ sử dụng m ạng. Các xu hướng
ngắn hạn, trung h ạn và dài hạn nên được trình bày ở đây.
 Dự báo dịch vụ: kế hoạch kinh doanh nên cung c ấp cho Quản
lý Công suất thông tin chi ti ết về các dịch vụ m ới được lên kế
hoạch và sự tăng trưởng hoặc thu hẹp trong vi ệc sử dụng các
dịch vụ hiện có. Ph ần phụ này nên báo cáo về các dịch vụ mới
và sự sụp đổ của các hệ thống kế thừa.
8 Tóm tắt tài nguyên

Phần tóm tắt tài nguyên nên bao g ồm :
 Việc sử dụng tài nguyên hi ện tại và gần đây: phần phụ này
tập trung vào kết quả việc sử dụng tài nguyên c ủa các dịch vụ.
Nó báo cáo, m ột lần nữa, về các xu hư ớng sử dụng tài nguyên
ngắn hạn, trung hạn và dài h ạn, được chia nhỏ theo nền tảng
phần cứng. Thông tin này đã đư ợc thu thập và phân tích bởi
các quy trình con c ủa Quản lý Công suất Dịch vụ và Quản lý
Công suất Thành phần và do đó, nên luôn s ẵn sàng.
 Dự báo tài ngu yên : phần phụ này dự báo khả năng s ử dụng
tài nguyên do kết quả từ dự báo dịch vụ. Mỗi tình huống kinh
doanh được đề cập ở trên cần được giải quyết ở đây. Ví dụ:
m ột doanh nghi ệp bán buôn th ảm ở m iền Bắc nước Anh có thể
dự đoán chính xác m ức sử dụng bộ vi xử lý cao nhất và trung
bình trước khi họ quyết định tiếp quản doanh nghi ệp đối thủ.
Nó đã được chứng m inh rằng m ột nâng cấp sẽ không cần
thiết. Điều này đã được đưa vào m ô hình chi phí, d ẫn đến việc
tiếp quản thành công.
9 Các tùy chọn để cải thiện dịch vụ

Được xây dựng dựa trên kết quả của phần trước, phần này phác
thảo các phương án kh ả thi để nâng cao hi ệu suất và hiệu quả củ a
Cung cấp Dịch vụ. Nó có thể bao gồm các tùy chọn để hợp nhất các
dịch vụ khác nhau trên m ột bộ vi xử lý duy nhất, nâng c ấp m ạng để
tận dụng các tiến bộ công nghệ, điều chỉnh việc sử dụng tài nguyên
hoặc hiệu suất dịch vụ, lập trình lại các hệ thống cũ, m ua phần cứng
hoặc phần m ềm mới, v.v…

399
10 Dự báo chi phí
Các chi phí liên quan đ ến các tùy chọn này nên được ghi nhận lại ở
đây. Ngoài ra, chi phí hi ện tại và được dự báo của việc cung c ấp
các dịch vụ CNTT cũng nên đư ợc bao gồm . Trên thực tế, Quản lý
Công suất thu được phần lớn thông tin này t ừ quy trình Qu ản lý Tài
chính và K ế hoạch Tài chính CNTT.
11 Khuyến nghị
Phần cuối cùng c ủa kế hoạch nên bao gồm m ột bản tóm tắt các
khuyến nghị được đưa ra trong k ế hoạch trước đó và tr ạng thái củ a
chúng - ví dụ, bị từ chối, đã được lên kế hoạch, đã triển khai - và
bất kỳ sự khác biệt nào so với kế hoạch. Mọi khuyến nghị m ới nên
được đưa ra ở đây, tức là những lựa chọn nào được đề cập trong kế
hoạch được ưu tiên hơn và nh ững tác động nếu kế hoạch và các
khuyến nghị của nó không được triển khai cũng nên được đưa vào.
Các khuyến nghị nên được định lượng theo:
 Lợi ích kinh doanh đư ợc kỳ vọng.

 Tác động tiềm tàng của việc thực hiện các khuyến nghị.
 Những rủi ro liên quan
 Nguồn lực cần thiết.
 Chi phí, c ả thiết lập (ban đầu) và liên tục.

400
Phụ lục K: Nội dung điển hình của một kế hoạch khôi phục
Nội dung điển hình của m ột kế hoạch khôi phục ITSCM bao gồm :
KẾ HO ẠCH KHÔI PHỤC CHUNG
1 KIỂM SOÁT TÀI LI ỆU

Tài liệu này phải được duy trì để đảm bảo rằng các hệ thống, cơ s ở
hạ tầng và cơ sở vật chất đã bao gồm, hỗ trợ m ột cách thích đáng
cho các yêu c ầu khôi ph ục của doanh nghi ệp.
1.1/ Phân phối tài liệu
Bản sao Phát hành cho Ngà y Vị trí

1.
2.
3.
4.
1.2/ Sửa đổi tài li ệu

Tài liệu này sẽ được xem xét m ỗi X tháng
Lần sửa đổi hiện tại: ngày
Lần sửa đổi kế tiếp: ngày
Ngà y sửa đổi Số phiên bản Tóm tắt những thay đổi
1.3/ Phê duyệt tài liệu

Tài liệu này phải được phê duyệt bởi những cá nhân sau:
Họ tên Chức danh Chữ ký

401
2 THÔNG TIN HỖ TRỢ
2.1/ Giới thiệu

Tài liệu này nêu chi ti ết các hướng dẫn và thủ tục bắt buộc phải
được tuân theo đ ể khôi phục hoặc tiếp tục sự vận hành của hệ
thống, Cơ sở hạ tầng, dịch vụ hoặc cơ sở vật chất để duy trì Tính
liên tục của Dịch vụ ở m ức đã xác định hoặc đã thỏa thuận với
doanh nghiệp.
2.2/ Chiến lược ph ục hồi

Hệ thống, Cơ sở hạ tầng, dịch vụ hoặc cơ sở vật chất sẽ được phục
hồi sang các hệ thống, Cơ sở hạ tầng, các dịch vụ hoặc cơ sở vật
chất thay thế.
Sẽ m ất khoảng X giờ để khôi phục hệ thống, Cơ s ở hạ tầng, dịch vụ

hoặc cơ sở vật chất. Hệ thống sẽ được phục hồi về điểm ổn
định/toàn vẹn dữ liệu cuối cùng đã được biết, đó là thời điểm trong
ngày/thời gian. Thời gian phục hồi cần thiết cho hệ thống, Cơ sở h ạ
tầng, dịch vụ hoặc cơ sở này là:
Thời gian và thủ tục khôi phục đối với hệ thống, Cơ sở hạ tầng, dịch
vụ hoặc cơ sở vật chất này được kiểm tra lần cuối trên:
2.3/ Sự thỉnh cầu

Những nhân viên sau đư ợc ủy quyền để thực hiện kế hoạch này:
1.
2.
2.4/ Các giao di ện và sự phụ thuộc vào các kế hoạch khác
Chi tiết về các m ối quan hệ lẫn nhau và các tham chiếu với m ọi kế
hoạch khôi phục và liên tục khác cũng như cách các giao di ện được
kích hoạt.
2.5/ Hướng dẫn chung

Tất cả các yêu c ầu cung c ấp thông tin t ừ các phương ti ện truyền
thông hoặc các ngu ồn khác phải được chuyển đến thủ tục của Công
ty.
Khi thông báo cho nhân viên v ề thảm họa thực tế hoặc tiềm ẩn, hãy
tuân theo các quy trình leo thang ho ạt động đã xác đ ịnh, và c ụ thể
là:
 Hãy bình tĩnh và tránh nói chuy ện dài dòng

 Hãy t ư vấn cho họ về sự cần thiết phải chuyển các yêu cầu
thông tin đến điểm leo thang báo cáo.
 Hãy thông báo cho họ về những kỳ vọng và hành động (tránh
cung cấp cho họ chi tiết về sự việc trừ khi thực sự cần thiết).
 Nếu cuộc gọi được trả lời bởi người khác:
o Hãy hỏi xem người cần được liên hệ có đang ở nơi khác
không.
o Nếu không liên l ạc được với họ, hãy để lại tin nh ắn để
liên hệ với bạn theo số đã cho.

402
o Không cung c ấp thông tin chi ti ết về vụ việc.
o Luôn ghi lại chi tiết thời gian cu ộc gọi, phản hồi và hành
động.
Mọi hoạt động và liên h ệ leo thang phải được ghi lại một cách rõ
ràng và chính xác. Đ ể tạo điều kiện thuận lợi cho việc này, các hành
động phải ở định dạng danh sách ki ểm tra và ph ải có khoảng trống
để ghi lại ngày và thời gian bắt đầu và hoàn thành hoạt động cũng
như ai là người đã thực hiện hoạt động.
2.6/ Phụ thuộc

Các phụ thuộc Hệ thống, Cơ sở hạ tầng, dịch vụ, cơ sở vật chất
hoặc giao diện nên được lập thành văn b ản (theo thứ tự ưu tiên) đ ể
từ đó, các kế hoạch hoặc thủ tục khôi phục liên quan sẽ cần được
gọi ra cùng với kế hoạch khôi phục này có thể được xác định và
thực hiện. Người chịu trách nhi ệm cho vi ệc gọi (kế hoạch hoặc thủ
tục khôi phục) nên đảm bảo các hoạt động khôi phục được phối hợp
với các kế hoạch khác.
Hệ thống Tài liệu tham chi ếu Liên hệ
2.7/ Danh sách l iên hệ

Các danh sách về m ọi tên người liên hệ, các t ổ chức và chi ti ết liên
hệ và cơ chế:
Họ tên Tổ chức/Vai trò Chức danh Chi tiết liên hệ
2.8/ Nhóm khôi ph ục

Các nhân viên/ch ức năng sau đây chịu trách nhiệm cho việc thực
hiện các thủ tục này hoặc đảm bảo các thủ tục được thực hiện và
cho việc ghi lại bất kỳ vấn đề hoặc sự cố nào gặp phải. Liên h ệ sẽ
được đưa ra thông qua các thủ tục leo thang thông thư ờng.
Họ tên Chức danh Chi tiết liên hệ

403
2.9/ Danh sách ki ểm tra của nhóm khôi phục
Để tạo điều kiện cho vi ệc thực thi các ho ạt động chính yếu m ột cách
kịp thời, m ột danh sách ki ểm tra tương t ự như dưới đây nên đư ợc
sử dụng.
Nhiệm vụ Mục tiêu hoàn Thực tế hoàn

thành thành
Xác nhận lời thỉnh c ầu
Bắt đầu cây cuộ gọi và các thủ tục leo thang
Kích ho ạt và tương tác với bất kỳ kế hoạch khôi ph ục
cần thiết khác ( ví dụ, BCP, Quản lý Kh ủng hoảng, Kế
hoạch Ứng phó t ình huống Kh ẩn cấp).
Sắp xếp phương tiện sao lưu và tài li ệu để được
chuyển đến (các) địa điểm khôi phục.
Thiết lập các nhóm khôi phục
Bắt đầu các ho ạt động khôi phục
Xác nhận báo cáo t i ến độ
Thông báo cho nhóm khôi ph ục về các yêu cầu báo
cáo
Xác nhận các yêu c ầu liên lạc với bất kỳ nhóm khôi
phục nào
Tư vấn cho khách hàng và c ấp quản lý về t hời gian
ước t ính hoàn t ất việc khôi phục

404
3 THỦ TỤC KHÔI PHỤC
Hãy nhập các hướng dẫn/thủ tục khôi phục hoặc tham chiếu đến m ọi
thủ tục khôi phục t ại đây.
Nội dung/định dạng phải phù hợp với các tiêu chu ẩn của công ty về
các thủ tục. Nếu không có, hướng dẫn nên được ban hành b ởi
Người quản lý hoặc Trưởng nhóm cho khu vực chịu trách nhi ệm về
hệ thống, Cơ sở hạ tầng, dịch vụ hoặc cơ sở vật chất. Hướng dẫn
duy nhất là các hướng dẫn nên có khả năng được thực hiện bởi m ột
chuyên gia có kinh nghi ệm m à không phụ thuộc quá nhiều vào ki ến
thức cục bộ.
Khi cần thiết, nên tham chiếu đến tài liệu hỗ trợ (và vị trí của nó), sơ
đồ và các ngu ồn thông tin khác. Việc này phải bao gồm số tham
chiếu tài liệu (nếu nó t ồn tại). Tác giả kế hoạch có trách nhi ệm đảm
bảo rằng thông tin này được duy trì với kế hoạch này. Nếu chỉ có
m ột lượng thông tin h ỗ trợ hạn chế, thì việc đưa thông tin này vào
kế hoạch có thể dễ dàng hơn, m iễn là kế hoạch này vẫn dễ đọc/dễ
theo dõi và không tr ở nên quá c ồng kềnh.

405
Thông tin bổ sung
Tham khảo
1. Service Strategy
2. Service Transition
3. Service Operation
4. Continual Service Improvement
5. Peter Drucker
6. COBIT – ISACA
7. CMMI – CMU
8. eSCM-Service Portfolio – CMU
9. PRINCE2 – OGC
10. ISO 9000
11. ISO/IEC 20000
12. ISO 27001
13. Enterprise Architecture – Gartner
14. Plan Do Check Act – W Edwards Deming
15. Balanced Scorecard – Kaplan/Norton
16. Service Oriented Architecture – OASIS
17. Management of Risk – OGC
18. Recommended Practice for Software Requirements Specification (IEEE 830)
19. The Software Engineering Body of Knowledge (SWEBOK)
20. Object Management Architecture – OMG
21. Common Information Model (CIM) – DMTF
22. Web-Based Enterprise Management (WEBM) – DMTF
23. Application Management Specification – IBM
24. Windows Management Instrumentation – Microsoft
25. Desktop Management Instrumentation – Windows
26. Six Sigma – Motorola Inc
27. Dynamics of Software Development – Jim McCarthy
28. Requirements engineering; examples of tacit and explicit knowledge (Maiden
& Rugg, 1995)
29. Business Analysis – Deborah Paul and Donald Yeates
30. Principles of Data Management – Keith Gordon
31. Practical Data Migration – John Morris

406
Chú giải thuật ngữ
Danh sách từ viết t ắt
Viết tắt Ngu yê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 Availabilit y Management Quản lý T ính sẵn sàng
AM I S Availabilit y Management Hệ thống Thông tin Qu ản lý T ính sẵn sàng
Inf ormation System
ASP Applicat ion Ser vice provider Nhà cung cấp Dịch vụ Ứng dụng
BCM Business Capacit y Man agement Quản lý Công suất Kinh doanh
BCM Business Continuit y Management Quản lý Liên t ục Kinh doanh

BCP Business Continuit y Plan Kế hoạch Liên t ục Kinh doanh
BI A Business Impact Analysis Phân t ích Tác đ ộng Kinh doanh

BRM Business Relat ionship Quản lý Quan hệ Khách hàng
Management
BSI Brit ish Standar d Institution Viện Tiêu chuẩn Anh
BSM Business Ser vice Management Quản lý Dịch vụ Kinh doanh

C AB Change Advisor y Board Hội đồng Cố vấn Thay đổi
C AB/ EC Change Advisor y Hội đồng Cố vấn Thay đổi/Ủy ban Khẩn cấp
Board/ Emergency Committee
C APEX Capital Expenditure Chi tiêu Vốn

407
CCM Component Capacit y Quản lý Công suất Thành phần
Management
CFI A Component Failure I mpact Phân t ích Tác đ ộng của Thành phần L ỗi
Analysis
CI Conf iguration Item Mục Cấu hình

CMDB Conf iguration Management Cơ sở dữ liệu Quản lý Cấu hình
Database
CMIS Capacit y Management Hệ thống Thông tin Qu ản lý Công su ất

Inf ormation System
CMM Capabilit y Maturit y Model Mô hình Năng lực Trưởng thành
CMMI Capabilit y Maturit y Model Tích hợp Mô hình Năng l ực Trưởng thành
Integration
CMS Conf iguration Management Hệ thống Quản lý Cấu hình

System
CO TS Commercial of f the Shelf Thương mại Đóng gói sẵn

CSF Crit ical Success Factor Yếu tố thành công quan tr ọng
CSI Cont inual Ser vice Improvement Liên tục Cải tiến Dịch vụ
CSIP Cont inual Ser vice Improvement Kế hoạch Liên t ục Cải tiến Dịch vụ
Plan
CSP Core Ser vice Package Gói Dịch vụ Cốt lõi
CTI Computer Telephony Integration Máy t ính T ích h ợp Điện thoại

408
DIKW Data-to-Inf ormation-t o- Dữ liệu đến Thông tin đến Kiến thức đến Sự thông thái
Knowledge-to-W isdom
ELS Early Lif e Support Hỗ trợ Đầu đời
eSCM- eSourcing Capabilit y Model f or Mô hình Năng lực thuê ngoài đi ện tử cho các T ổ chức của Khách hàng
CL Client Organizations
eSCM- eSourcing Capabilit y Model f or Mô hình Năng lực thuê ngoài đi ện tử cho các nhà cung c ấp Dịch vụ
SP Ser vice providers
FME A Failur e Modes and Eff ects Phân t ích các Ch ế độ Lỗi và Ảnh hưởng
Analysis
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 Inf ormation Secur it y Management Quản lý Bảo mật Thông tin
ISMS Inf ormation Secur it y Management Hệ thống Quản lý Bảo mật Thông tin
System
ISO International Organizat ion f or Tổ chức Tiêu chuẩn hóa Quốc tế

Standardization
ISP Internet Ser vice Provider Nhà cung cấp Dịch vụ Internet
IT Inf ormation Technology Công nghệ Thông tin
ITSCM IT Service Continuit y Quản lý Liên t ục Dịch vụ CNTT
Management

409
ITSM IT Service Managem ent Quản lý Dịch vụ CNTT
itSMF IT Service Managem ent Forum Diễn đàn Quản lý Dịch vụ CNTT
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 Perf ormance 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 Bet ween Failur es Thời gian Hoạt động Giữa các Sự cố
MTBSI Mean Time Bet ween Ser vice Thời gian Hoạt động Giữa các Sự cố Dịch vụ
Incidents
MTRS Mean Time to Restor e Ser vice Thời gian trung bình đ ể Khôi phục 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 Off ice of Government Commence Văn phòng Thương m ại Chính ph ủ

OL A Operational Level Agreement Thỏa thuận Mứ c Vận hành
OPEX Operational Expendit ure Chi tiêu Vận hành
OPSI Off ice of Public Sector Văn phòng Thông tin Khu v ực Công
Inf ormation
PB A Pattern of Business Activit y Hình mẫu Hoạt động Kinh doanh

410
PIR Post-Implementation Review Xem xét Sau-Triển khai
PFS Prerequisite f or Succes s Điều kiện tiên quyết để Thành công
PSO Projected Ser vice O utage Ngừng Dịch vụ được Dự kiến
QA Qualit y Assurance Đảm bảo Chất lượng
QMS Qualit y Management System Hệ thống Quản lý Ch ất lượng

RC A Root cause Analysis Phân t ích nguyên nhân g ốc
RFC Request f or Change Yêu cầu Thay đổi
ROI Return on Investment Lợi nhu ận Đầu tư
RPO Recover y Point Objective Mục tiêu Điểm Khôi phục
RTO Recover y Time Objective Mục tiêu Thời gian Khôi phục
SoC Seper ation of concer ns Phân tách các m ối quan tâm
S AC Ser vice Acceptance Criter ia Tiêu chí Ch ấp thuận Dịch vụ
S ACM Ser vice asset and Conf iguration Quản lý Cấu hình và Tài s ản dịch vụ
Management
SCD Supplier and contract database Cơ sở dữ liệu nhà cung cấp và hợp đồng
SCM Ser vice Capacit y Management Quản lý Công suất Dịch vụ
SDP Ser vice Design Package Gói Thiết kế Dịch vụ
SF A Ser vice Failure Analysis Phân t ích L ỗi Dịch vụ
SIP Ser vice Improvement Plan Kế hoạch Cải t iến Dịch vụ

411
SKMS Ser vice Knowledge Management Hệ thống Quản lý Kiến thức Dịch vụ
System
SL A Ser vice Level Agreement Thỏa thuận Mứ c Dịch vụ
SLM Ser vice Level Management Quản lý Mứ c Dịch vụ
SLP Ser vice level package Gói mức Dịch vụ

SLR Ser vice Level Requir ement Yêu cầu Mức Dịch vụ
SMO Ser vice Maintenance Objective Mục tiêu Duy tr ì Dịch vụ
SOP Standard Operat ing Procedures Các Thủ tục Vận hành Tiêu chu ẩn
SOR Statement of requirements Tuyên bố về các yêu cầu

SPI Ser vice provider Interf ace Giao diện nhà cung c ấp Dịch vụ
SPM Ser vice Porf olio Management Quản lý Danh m ục Dịch vụ
SPO Ser vice Provisioning Optimizat ion Tối ưu hóa Cung c ấp Dịch vụ
SPoF Sing le Point of Failure Điểm Đơn L ỗi
TO Technical Obser vation Quan sát K ỹ thuận

TO R Terms of ref erence Thuật ngữ tham chiếu
TCO Total Cost of Owner ship Tổng Chí phí S ở hữ u
TCU Total Cost of Utilizat ion Tổng Chi phí Sử dụng
TQM Total Qualit y Manag ement Quản lý Chất lượng Tổng thể
UC Under pinning Contract Hợp đồng Cơ s ở

412
UP User Portf olio Danh mục Người sử dụng
VBF Vital Business Funct ion Chức năng Kinh doanh S ống còn
VOI Value on Investment Giá trị của khoản Đầu tư
WIP W ork in Progress Công việc đang Tiến hành

413
Danh sách các định nghĩa
Các t ên ấn phẩm đư ợc đặt trong dấu ng oặc đơn sau tên c ủa mỗi t huật ngữ xác đ ịnh nơi mà đ ộc giả có thể t ìm th ấy
nhiều t hông tin hơn về thu ật ngữ đó. Việc này là vì th uậ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ó t hể không đư ợc định nghĩa chi t i ế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 t hấ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.

414
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ó thể chuyển giao
(Chấp thuận) được khác là hoàn t hà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 t iế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 triển khai D ịch vụ
(Kế toán) 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
Acti vit y 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 thông
(Hoạt độ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 về T ính sẵn
(Thời gian Dịch vụ đã 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 không đư ợc xem
(Thỏa thuận) 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.
Al ert (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 ị thay đổi, hay
(Cảnh báo) 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.
Anal ytical Modelling (Chiến lược Dịch vụ) (Thiết kế Dịch vụ) (Liên tục Cải t iến Dịch vụ) Một kỹ thuật sử dụng các mô hình
(Mô hình Phân tích) 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 vụ CNTT. Mỗi
(Ứng dụng) Ứ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.

415
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ý các Ứng dụng trong
Management suốt Vòng đời của nó.
(Quản lý Ứng dụng)
Application Portfoli o (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 để quản lý các Ứng
(Danh mục Ứng dụ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 tr iể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 các Ứng dụng
provider hoạt động tại địa điểm của nhà cung c ấp dịch vụ. Người sử dụng sẽ truy c ập tới các Ứng dụng thông
(Nhà cung cấp Dịch qua các k ết nối mạng tới Nhà cung c ấp dịch vụ
vụ Ứng dụng)
Application Sizi ng (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ó để hỗ trợ một Ứng
(Định quy mô Ứng dụng mới hoặc một thay đổi lớn trong Ứng dụng hiện hữu. Định quy mô Ứng dụng giúp cho việc đảm
dụng) 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 quan h ệ của
(Kiến trúc) 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 có được tuân
(Đánh giá) thủ không, các Hồ sơ có chính xác hay không, hay các m ục t iê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 Dịch vụ là b ất
(Tài sản) 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.

416
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 dõi, lập báo cáo
(Quản lý Tài sản) 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ể.
At tribute (Chuyển t iế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 í, Phiên bản và
(Thuộc tính) 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 Hướng dẫn có đư ợc
(Kiểm toán) 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 t ới người phù
Distribution hợp nhất trong khoảng thời gian ngắn nhất có thể. ACD đôi khi đư ợc gọi là Phân phối Cuộc gọi được
(Tự động Phân phối Tự động hóa.
Cuộc gọi)
Availabilit y (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ể thực hiện một ch ức
(Tính sẵn sàng) năng đã t h ỏa t huận khi đư ợc yêu cầu. T ính sẵn sàng được xác đ ịnh bởi: Độ t in 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
Availabilit y (Thiết k ế Dịch vụ) Q uy tr ình chịu trách nhiệm cho vi ệc xác đ ịnh, phân t ính, Ho ạch định, đo lư ờng và c ải
Management 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ý T ính s ẵn sàng chịu trách nhiệm cho
(Quản lý Tính sẵn 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
sàng) tiêu mức Dịch vụ đư ợc nhắm đến đã th ỏa thuận về T ính sẵn sàng.
Availabilit y (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, thông thư ờng được
Management lưu trữ trên nhiều vị trí vật lý khác nhau. Xem thêm H ệ thống Quản lý Kiến thức Dịch vụ.
Information System
(Hệ thống Thông tin
Quản lý Tính sẵn
sàng)

417
Availabilit y 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 của các Dịch vụ
(Kế hoạch Tính sẵn CNTT trong hiện tại và tương lai có th ể được cung cấp với Chi phí Hiệu quả.
sàng)
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 mát về T ính
(Sao lưu) 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 t iến Dịch vụ) Một công cụ quản lý đư ợc phát triển bởi t iến sĩ Robert Kaplan ( Har var d
(Thẻ điểm Cân bằng) Business School) và David Norton. M ột Thẻ điểm Cân bằng cho phép m ột Chiến lược có t hể đư ợ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. Ví dụ:
(Đường cơ sở) - 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ó t hể đượ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ó t hay đổ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 cụ thể nào
(Điểm chuẩn) đó. Một Điểm chuẩn có thể đư ợc tạo r a 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ở.

418
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 tiễn Tốt nhất.
(So sánh điểm chuẩn)) 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ành công b ởi
(Thực tiễn Tốt nhất) nhiều Tổ chức. ITIL là một ví dụ về Thực tiễn Tốt nhất.
Brainst orming (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 sẽ không được
(Kích não) 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 để nhận được, k ế
(Ngân sách) 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 t iêu. Bao g ồm các chu k ỳ t hương lư ợng lặp đi l ặp lại nhằm
(Lập ngân sách) 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 thành phần của Dịch
(Xây dựng) 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ụ:
Ser ver 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 thành t ừ một số
(Doanh nghiệp) 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 t y. 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 Capacit y (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 nghiệp là Hành
Management động ch ịu trách nhiệm cho việc t ìm hiểu Nhu cầu Doanh nghi ệp trong tương lai đ ể sử dụng trong một
(Quản lý Công suất Kế hoạch công suất. Xem thêm Quản l ý Công suất Dịch vụ.
Doanh nghiệp)

419
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 g ồm thông tin v ề
(Đề án Kinh doanh) 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 Continuit y (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 Rủi r o có t hể gây
Management ảnh hưởng nghiêm tr ọng tới Doanh nghiệp. Quản lý Liên t ục Kinh doanh b ảo vệ lợi ích c ủa các bên liên
(Quản lý Liên tục Kinh quan, danh ti ếng, thương hiệu và các hoạt động tạo ra-giá trị. Quy tr ình Quản lý Liên tục Kinh doanh
doanh) tham gia vào vi ệc làm giảm thiểu Rủi r o đế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 Q uản lý Liên t ục Dịch vụ CNTT.
Business Continuit y (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 các Quy tr ình
Plan Nghiệp vụ sau khi bị gián đoạn. Kế hoạch này cũng đồng thời cũng xác đ ịnh các điều kiện k ích hoạt để
(Kế hoạch Liên tục Viện dẫn, những người tham gia, cách th ức truyền thông, v. v… K ế hoạch Liên t ục Dịch vụ CNTT là một
Kinh doanh) 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 nghiệp. Ví dụ:
(Khách hàng (của) nếu Doanh nghiệp là nhà sản xuất xe hơi thì Khách hàng (c ủa) Doanh nghiệp là ngư ời mua xe
Doanh nghiệp)
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 Chức năng Kinh
Anal ysi s doanh S ống còn và các ph ụ thuộc của nó. Các phụ t huộc này có thể là các Nhà cung c ấp, con ngư ời,
(Phân tích Tác động các Quy tr ình Nghi ệp vụ khác, các D ịch vụ CNTT, v. v… Phân tích t ác động đến Doanh nghiệp cũng xác
Kinh doanh) đị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 t hiểu cho mỗi Dịch vụ
CNTT.
Business Objecti ve (Chiến lược Dịch vụ) Mục t iêu của một Q uy tr ình Nghi ệp vụ hoặc toàn thể Doanh nghiệp. Mục t iêu Kinh
(Mục tiêu Kinh doanh) 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 O perations (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)

420
Business Perspecti ve (Liên tục Cải t iến Dịch vụ) Sự thấu hiểu về nhà cung cấp Dịch vụ và các Dịch vụ CNTT từ quan điểm
(Quan điểm Kinh của Doanh nghiệp, và sự thấu hiểu về Doanh nghi ệp từ quan điểm của nhà cung cấp Dịch vụ.
doanh)
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ụ tham gia vào
(Quy trình Nghiệp vụ) 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 Mối quan hệ với
Management 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ụ Cơ sở hạ
(Dịch vụ Kinh doanh) 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 t i ếp cận để quản lý các D ịch vụ CNTT xem
Management xét các Quy tr ình Nghiệp vụ được hỗ trợ và giá trị Kinh doanh đư ợc cung cấp.
(Quản lý Dịch vụ Kinh 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
doanh) 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à Chi phí r iêng.
(Đơn vị Kinh doanh) Mỗi Đơn vị Kinh doanh có các Tài s ản r iê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ụ.

421
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ụ (Ser vice Desk) t ừ Người sử
(Cuộc gọi) 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 số lượng lớn
(Trung tâm Cuộc gọi) các cuộc gọi điện thoại cả hai chiều vào và ra. Xem thêm Ser vice Desk
Capabilit y (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ị Cấu hình hay
(Năng lực) 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.
Capacit y (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ó thể cung cấp
(Công suất) 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.
Capacit y Management (Thiết k ế Dịch vụ) Q uy tr ình ch ịu trách nhiệm cho việc đảm b ảo rằng Công suất của các D ịch vụ CNTT
(Quản lý Công suất) 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, t rung và dài h ạn.
Capacit y 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, t hông thư ờng đư ợc lưu
Information Syst em trữ trên nhiều vị tr í vật lý khác nhau. Xem H ệ thống Thông tin Qu ản lý Kiến thức Dịch vụ.
(CMIS)
(Hệ thốngThông tin
Quản lý Công suất)
Capacit y 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 thiết để cung c ấp
(Kế hoạch công suất) 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.
Capacit y 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 việc soạn thảo một
(Hoạch định công Kế hoạch Công suất.
suất)

422
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 sử dụng để nhóm
(Thể loại) 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 cả sự Kiểm
(Chứng nhận) 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ó t hể ảnh hưởng tới các D ịch
(Thay đổi) 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 Ad vi sory (Chuyển t iếp Dịch vụ) Một nhóm chuyên gia tư v ấn cho Giám đ ốc (quản lý) Thay đổi trong quá tr ình
Board đánh giá, thiết lập độ ưu t iên và lên l ộ tr ình cho các Thay đ ổi. Hội đồng này thư ờng được thành lập t ừ
(Hội đồng Cố vấn tất cả các lĩnh vực t rong phạm vi Nhà cung c ấp dịch vụ CNTT, các đại diện của Doanh nghi ệp và Bên
Thay đổi) thứ ba chẳng hạn Nhà cung cấp.
Change History (Chuyển t iếp Dịch v ụ) Thông tin v ề tất cả các t hay đổi đã đư ợc thực hiệnđối với một Đơn vị Cấu hình
(Lịch sử thay đổi) 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 Managemen t (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 Thay đổi. Mục
(Quản lý thay đổi) đích chính c ủa Quản lý Thay đổi là đ ể cho phép các Thay đ ổi có lợi được t hực hiện đồng thời tối t hiể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 t iế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à ngày tr iển khai đã
(Lịch trình thay đổi) đượ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ác Bản phát
(Cửa sổ tha y đổi) 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).

423
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 vụ CNTT là sự
(Định phí) 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 bảo sự nhất
(Phân loại) 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 (c ủa) Doanh nghiệp.
(Khách hàng) 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 t rạ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 đổi, v. v… Khi
(Đã đóng) 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, v. v… thành Đã
((Hành động) Đóng) đóng
COBI T (Liên tục Cải t iến Dịch vụ) COBIT – Các mục tiêu Ki ểm soát đối với Thông tin và Công ngh ệ liên quan
(COBIT) 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 https:// www.isaca.org
Cold Standb y Xem thêm Khôi ph ục dần dần
(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 từ Bên thứ ba
Shelf ( COTS )

424
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 phư ơng pháp k ế
(Tuân thủ) toán ho ặc các thực t iễ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 máy t ính có th ể
(Thành phần) 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 Capacit y (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 hi ểu Công suất,
Management Mứ c độ sử dụng, Hiệu suất của các Đơn v ị Cấu hình. Dữ liệu được thu thập, lưu trữ và phân t ích đ ể sử
(Quản lý Công suất dụng trong Kế hoạch Công suất. Xem thêm Quản l ý Công su ất Dịch vụ.
Thành phần)
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 hình CPU hay
(Đơn vị Cấu hình 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 chủ.
Thành phần)
Component Fail ure (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 các Dịch vụ
Impact Anal ysis 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 Đơn v ị Cấu hình trên cạnh
(Phân tích Tác động còn lại. Ma tr ận sẽ giúp xác đ ịnh những Đơn vị Cấu hình quan trọng (có th ể gây ra sự cố cho nhi ều
của Thành phần bị 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
Lỗi) Failur e)
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 hành t ại cùng một
(Đồng thời) thời điểm.
Confidentialit y (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 người sử dụng
(Tính bảo mật) đượ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 v ị Cấu hình làm
(Cấu hình) 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.

425
Configuration (Chuyển t iếp Dịch vụ) Một Đường cơ s ở Cấu hình đã đư ợc thỏa thuận một cách chính th ức và đư ợc
Baseline 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
(Đường cơ sở Cấu các Thiết lập, Bản phát hành và Thay đ ổi trong tương lai
hình)
Configuration Cont rol (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, chỉnh sửa hay loại
(Kiểm soát cấu hình) 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 t hu thập thông tin về các Đơn vị Cấu hình
Identification và Mối quan hệ giữ a chúng, sau đ ấy đưa những thông tin này vào Cơ s ở dữ liệu Quản lý Cấu hình
(Xác định Cấu hình) (CMDB - Conf iguration 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 Dịch vụ CNTT.
(Đơn vị Cấu hình) 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 v ề các Đơn vị
Management 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ệ giữa chúng (các Đơn v ị cấu
(Quản lý Cấu hình) hình). Các t hông tin này đư ợc quản trị t rong 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ữ liệu về Cấu
Management Syst em hình của một nhà cung cấp Dịch vụ CNTT. CMS ( Hệ thống Quản lý Cấu hình) cũng bao g ồm nhữ ng
(Hệ thống Quản lý thông tin v ề các Sự cố, Vấn đề, Lỗi Đã biết, Thay đ ổi và Bản phát hành; và có th ể bao g ồm dữ liệu về
Cấu hình) 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 t hậ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ụ.

426
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à m ột tiêu đề của
Improvement 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ụ chịu trách nhiệm cho vi ệc quản lý
(Liên tục Cải tiến Dịch sự cải t iến của các Quy tr ình Qu ản lý Dịch vụ CNTT cũng như các D ịch vụ CNTT. Hiệu suất của Nhà
vụ) 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 (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 100% về T ính sẵn
Availabilit y sàng. Một Dịch vụ CNTT Liên t ục Sẵn sàng là không có Th ời gian gián đo ạn bất kể có được lập kế
(Tính sẵn sàng Liên hoạch hay không.
tục)
Continuous Operati on (Thiết k ế Dịch vụ) Một phương pháp t i ếp cận hoặc thiết kế để giảm thiểu Thời gian gián đo ạn được Lập
(Vận hành liên tục) 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 đảm bảo rằng một
(Kiểm soá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ò, RAI D,
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 Perspecti ve (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 tr ình, Ch ức năng,
(Quan điểm kiểm soát ) 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 t rong 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 t iêu cho m ột Hoạt động, Dịch vụ CNTT hay m ột Đơn vị Kinh doanh c ụ thể. Chi
(Chi phí) 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 Anal ysis 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 chuỗi hành động
(Phân tích lợi ích chi thay thế khác. Xem thêm Đề án Kinh doanh, L ợi tức của Khoản đầu tư
phí)
427
Cost Effecti veness 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ụ, Quy tr ình hay ho ạt
(Hiệu quả (của) chi động. Một Quy tr ình Hi ệu quả (của) Chi phí là m ột quy tr ình đạt được các Mục tiêu của nó với Chi phí
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ó thư ờng được s ử
(Biện pháp đối phó) dụng khi tham chi ếu để đo lường Khả năng phục hồi, Khả năng chịu lỗi hay Độ t in 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 nhi ệm cho việc quản
(Quản lý khủng 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 t rách nhiệm về các vấn
hoảng) đề 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ì t hực thi Kế hoạch Liên tục Kinh doanh.
Critical Success Đ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 thành công.
Factor (CSF) Các KPI đư ợc sử dụng để đo lường thành t ích đạt được của mỗi CSF. Ví d ụ, một Yếu tố Thành công
(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 đ ổi” có th ể được đo lường bởi các KPI như
quan trọng) “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ọng về cách
(Văn hoá) 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ụ CNTT là cá nhân
(Khách hàng) 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ự t hể hiện bằng đồ hoạ về Hiệu su ất và T ính sẵn sàng tổng thể của Dịch v ụ
(Bảng thống kê) 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ó t hể
đượ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ố.
Deli verable Đ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 vụ hay m ột
(Sản phẩm đầu ra) 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.

428
Demand 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 thời cung cấp đú
(Quản lý Nhu cầu) công suất để đáp ứng các nhu c ầu đó. Ở mức Chiến lược, Q uản lý Nhu c ầu có t hể 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 t rị
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 trình hay Hoạt
(Phụ thuộc) động khác
Deplo yment (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 ứng dụng, tài
(Triển khai) 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 nghĩa m ột giải pháp
(Thiết kế) 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ự cố trở thành đã
(Nhận diện) biết (đã đư ợc ghi nh ận) bới nhà cung c ấp Dịch vụ. Nhận diện có t hế 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
Devel opment (Thiết k ế Dịch vụ) Q uy tr ình chịu trách nhiệm tạo ra hoặc chỉnh sửa một Dịch vụ hoặc Ứng dụng CNTT.
(Phát triển) 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
Devel opment (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ụ hoặc Ứng dụng
Environment CNTT. Các Môi trư ờng phát triển thông thư ờng không có cùng c ấp độ kiểm soát như Môi trư ờng Thử
(Môi trường phát nghiệm hay Môi trư ờng “Thật”. Xem thêm Phát tri ển.
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 là đ ể
(Chẩn đoán) 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 cùng Ch ức năng
(Tính giá phân biệt) Dịch vụ CNTT nhưng t ại các thời điểm khác nhau

429
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 điện tử. Ví dụ,
(Tài liệu) 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ơ
Dow ntime (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 Dịch vụ CNTT
(Thời gian gián đoạn) 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
Dri ver Một điều g ì đó có t h ể 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 ụ, các quy đ ịnh
(Yếu tố thúc đẩy) 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 hiệu quả sử dụng
(Tính kinh tế của quy của một Dịch vụ hoặc Tài sản CNTT.
mô)
Effecti ven ess (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, Dịch vụ, Hoạt động
(Tính hiệu quả) 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 t iến Dịch vụ) Một thước đo xác đ ịnh chính xác ngu ồn lực đã được sử dụng để cung cấp
(Tính tối ưu) 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 t iê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ể nào đó. Ví dụ:
Môi trường 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 hay nhi ều Đơn vị
(Lỗi) 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.
430
Escal ation (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 thiết để đáp ứng
(Sự leo thà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 Capabi lit y (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 những Năng
Model for Service 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ụ. eSCM- SP được phát tr iển bởi
Providers (eSCM -SP) 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 hoặc Chi phí. Sự
(Ước tính) ướ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 mới hoặc đã
(Đánh giá) đượ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 t iế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 Đơn vị cấu hình
(Sự kiện) 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 suốt Vòng đời của
(Quản lý Sự kiện) 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

431
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 yếu hoặc các
(Báo cáo về sự ngoại mục tiêu quan tr ọng khác đã vư ợt quá Ngư ỡng đã định. Ví d ụ bao g ồm các mục tiêu trong Th oả thuận
lệ) 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ỉ r a các vấn đề tiềm
tàng về Công suất
Excitement Attribut e Xem Yếu tố kích thích
Thuộc tính kích thí ch
Expanded 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 đo ạn đó là Nhận
Lifecycle diện, Chẩn đoán, Sử a chữa, Khôi phục, Phục hồi. Vòng đời Sự cố Mở r ộng được sử dụng để giúp hi ểu
(Vòng đời sự cố mở về tất cả các đóng góp vào Tác đ ộng c ủa các Sự cố cũng như lên K ế hoạch về việc làm thế nào để
rộng) 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 nghiệp/Tổ chức khác
Provider với Khách hàng của họ. Một nhà cung c ấp Dịch vụ CNTT có thể có cả Khách hàng Bên ngoài và Khách
(Nhà cung cấp dịch vụ 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 Hạ tầng CNTT
(Quản lý Cơ sở vật đượ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ý Môi trư ờng vật lý, ví dụ như:
chất) 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 cung c ấp đầu r a
(Lỗi) 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ự phòng đư ợc đư a
(Khôi phục Nhanh) ra để Khôi ph ục Dịch vụ CNTT trong thời g ian ng ắn nhất, t hường là dưới 24 g iờ. 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.

432
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ể t iếp tục hoạt
(Khả năng chịu lỗi) độ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 Anal ysis (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 đ ịnh chuỗi các
(Phân tích Cây Lỗi) 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ơ đồ.
Financi al 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 ngân sách, H ạch
(Quản lý Tài chính) 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 t hức được sử dụng để mô tả r ằng một Quy tr ình, Đơn vị cấu hình, D ịch v ụ
(Phù hợp với Mục CNTT, v. v… là đ ủ khả năng đáp ứng các mục t iêu hoặc Mứ c dịch vụ. Đáp ứ ng mục tiêu đòi h ỏi một
đích) 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 cung cấp một dịch
(Hoàn thành) 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 ho ặc Hoạt động.
(Chức năng) Ví dụ như Ser vice Desk.
Thuật ng ữ chức năng đồng thời có 02 ng hĩ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ụ em ail 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à r ằng các Quy
(Quản trị) 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.

433
Gradual Recovery (Thiết k ế Dịch vụ) Một Lựa chọn Khôi p hục được hiểu như là Cold Stanby. D ự phòng đư ợc đưa ra để
(Khôi phục Dần dần) 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 t hườ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. Vi ệc tuân t hủ
(Hướng dẫn) một hướng dẫn thường là không bắt buộc. Xem thêm Tiêu chu ẩn.
High Availabilit y (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 “che dấu” những
(Tính sẵn sàng Cao) 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 Standb y 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 Standby. D ự phòng đư ợc
(Khôi phục Tức thời) đư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 ( Mirror ing), 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ố, Vấn đề hay Sự
(Ảnh hưởng) 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 giảm Chất lượng
(Sự cố) 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ự cố. Mục đích ch ủ
(Quản lý Sự cố) 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ẽ tài liệu hóa
(Hồ sơ Sự cố) Vòng đời của một Sự cố đơn lẻ.

434
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ổ đầy đủ đến một
(Chi phí gián tiếp) 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 Securit y (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, thông tin, dữ
Management 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 thư ờng định hình m ột phần của
(Quản lý Bảo mật phương pháp tiếp cận của Tổ chức đối với Quản lý Bảo mật, có phạm vi rộng hơn nhà cung c ấp Dịch vụ
Thông tin) 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 Securit y (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à công cụ đảm
Management Syst em 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 Thông tin của m ình.
(ISMS)
(Hệ thống Quản lý
Bảo mật Thông tin)
Information Securit y (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 Quản lý Bảo m ật
Policy 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ý t hông tin. Công ngh ệ thường bao g ồm các
Technolog y máy t ính, k ết nối viễn thông, các Ứng dụng và phần mềm khác. Thông tin có th ể bao g ồm dữ liệu của
(Công nghệ Thông tin) 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 Servi ce 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 thiết cho Nhà
(Dịch vụ Cơ sở hạ 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ụ dir ector y, naming
tầng) ser vice, hay d ịch vụ truyền thông.
Insourci ng Xem Thuê nguồn lực nội bộ.

(Tự cung cấp)
Integrit y (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 hình ch ỉ được thay
(Tính toàn vẹn) đổ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.
435
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à W arm Standby – Trạng thái
(Khôi phục Trung 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
bình) 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 Doanh nghi ệp/Tổ
Provider chức. Một Nhà cung cấp dịch vụ CNTT có thể có cả Khách hàng nội bộ và Khách hàng bên ngoài.
(Nhà cung cấp Dịch
vụ 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ụ CNTT.
“Thuê trong”
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. ISO là một tổ
Organization of 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 156 quốc gia. Xem thêm thông
Standardization (ISO) 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 triển, Kiểm tra,
(Cơ sở hạ tầng CNTT) cung cấp, Giám sát, Kiểm soát hoặc hỗ trợ các Dịch vụ CNT T. 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.

436
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 g ồm Quản lý
(Vận hành CNTT) 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 r a. 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ụ CNTT. Một Dịch vụ
(Dịch vụ VNTT) 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 Continuit y (Thiết k ế Dịch vụ) Q uy tr ình ch ịu trách nhiệm cho việc quản lý Rủi ro có thể tác đ ộng nghiêm tr ọng đến
Management các Dịch vụ CNTT. ITSCM đ ảm bảo rằng nhà cung cấp Dịch vụ CNTT có thể luôn luôn cung c ấp mứ c
(Quản lý Tính liên tục Dịch vụ tối thiểu đã được thỏa thuận, bằng cách giảm thiểu Rủi ro đến một mức có thể chấp nh ận đư ợc
Dịch vụ CNTT) 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 C ontinuit y (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 nhiều Dịch vụ
Plan CNTT. Kế hoạch cũng xác đ ịnh các yếu t ố kích ho ạt Bước kh ởi đầu (Invocat ion), các cá nhân liên quan,
(Kế hoạch Liên tục các kênh tru yền thông, v. v… Kế hoạch liên t ục Dịch vụ CNTT nên là m ột phần của Kế hoạch Liên t ục
Dịch vụ CNTT) Kinh doanh.
IT Service 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 nghiệp. Quản lý
Management 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
(Quản lý Dịch vụ tố con ngư ời, Quy tr ình và Công ngh ệ Thông tin. Xem thêm Qu ản lý Dịch vụ.
CNTT)
IT Service Provi der (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 Khách hàng k ể
(Nhà cung cấp Dịch cả Khách hàng nội bộ và Khách hàng bên ngoài.
vụ CNTT)
IT St eering 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ế hoạch của Doanh
(Nhóm Chỉ đạo CNTT) 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.
437
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 b ởi một người c ụ
(Mô tả Công việ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 yêu cầu bởi một
(Lên lịch trình Công 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 bởi Quản lý Vận hành CNTT và
việc) 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, D ịch vụ CNTT
Indicator hoặc Hoạt động. Nhiều Chỉ số có thể được đo lường, nhưng ch ỉ có những ch ỉ số quan trọng nhất sẽ
(Chỉ số Hiệu suất được xác đ ịnh là KPI và đư ợc sử dụng để quản lý và báo cáo m ột cách ch ủ động về Quy tr ình, D ịch v ụ
Chính yếu) 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.
Know ledge 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ệ thống Quản lý
(Cơ sở Kiến thức) Kiến thức Dịch vụ.
Know ledge (Chuyển tiếp Dịch vụ) Quy tr ình chịu trách nhiệm cho vi ệc t hu thập, phân t ích, lưu tr ữ và chia s ẻ kiến
Management thức và thông tin trong m ột Tổ chức. Mục đích chính c ủa Q uản lý Kiến thức là để cải thiện t ính Hiệu
(Quản lý Kiến thức) 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ệ t hống Quản lý Kiến t hức Dịch
vụ.
Know n 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 li ệu hóa. Lỗi Đã
(Lỗi Đã biết) biết được tạo r a 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ó t hể
được xác đ ịnh bởi Nhà phát tri ển ho ặc Nhà cung cấp.

438
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ấn đề, Thay
(Vòng đời) đổ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 Dịch vụ. Một tuyến
(Tuyến Dịch vụ) 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 t iếp Dịch vụ) Đề cập t ới một Dịch vụ CNTT hay một Đơn vị cấu hình đang đư ợc sử dụng để
(Đang hoạt độ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 thực tế đang hoạt
(Môi trường Thật) động được sử dụng để cung cấp các D ịch vụ CNTT cho các Khách hàng.
Maintainabilit y (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 một Đơn vị cấu
(Khả năng duy trì) 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 du y
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ụ CNT T
để chỉ khả năng có thể Thay đổi hoặc Sử a chữa một cách dễ dàng.
Major Inci dent (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 trọng sẽ gây ra gián
(Sự cố Nghiêm trọng) đoạn đáng k ể cho Doanh nghiệp.
Managed Servi ce (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à chúng đư ợc quản
(Dịch vụ đượ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ụ
lý) CNTT đư ợc Thuê ngoài.

439
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 Qu ản lý thường
Information được tạo ra một cách tự động bằng các công c ụ hỗ trợ các Quy tr ình Qu ản lý Dịch vụ CNTT khác nhau.
(Thông tin Quản lý) 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 để xác đ ịnh và
(MoR) 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 công của các Mục tiêu Kinh
(Quản lý Rủi ro) doanh của Tổ chức. Tham khảo http://www/m -o-r.org để có thêm thông tin.
Management Syst em 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ó t hể đạt đư ợc
(Hệ thống Quản lý) 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 t hi ệp thủ công. Cách giải quyết Thủ công cũng đư ợc sử dụng như
(Cách giải quyết Thủ 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 Nghi ệp vụ không cần sử dụng
cô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.
Maturit y (Liên tục Cải t iến Dịch vụ) Một thước đo vể Độ t in cậy, Hiệu suất và T ính hi ệu quả của một Quy tr ình,
(Trưởng thà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 Betw een (Thiết k ế Dịch vụ) Một Chỉ số để đo lư ờng và báo cáo về Độ tin c ậy. MTBF là t hời gian trung bình mà
Failures một Đơn vị cấu hình hay D ịch vụ CNTT có thể hoàn thành ch ức năng đã đư ợc t hỏa thuận mà không bị
(Thời gian hoạt động) 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 r a.
Mean Time Betw een (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. MT BSI là th ời gian t ừ
Service Incidents khi một Hệ thống hay một Dịch vụ CNTT bị lỗi cho đến lần bị lỗi kế tiếp. MTBSI bằng MTBF + MTRS
(Thời gian giữa hai sự
cố)
Mean Time to Repai r 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 b ị lỗi. MTTR
(Thời gian sửa chữa) đượ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 ha y
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ụ).
440
Mean Time to Rest ore 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 b ị lỗi. MT RS
Service được t ính k ể từ khi Đơn vị cấu hình hoặc Dịch vụ CNTT bị lỗi cho đến khi nó đư ợc hoàn toàn khôi ph ục
(Thời gian khôi phục và t iếp tục cung cấp chức năng thư ờng lệ. Xem thêm Khả năng có thể Bảo tr ì, MT TR.
dịch vụ)
Metric (Liên tục Cải t iế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 Quy tr ình, D ịch
(Chỉ số) vụ CNTT hoặc Hành động nào đó. Xem thêm KPI.
Middlew are (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 mềm hay Ứng
(Phần mềm trung 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
gian) 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ử dụng để hiểu
(Mô hình) 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, Dịch vụ CNTT,
(Mô hình hóa) Đơ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ụ CNTT hoặc Quy
(Giám sát) 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.
Objecti ve 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 như là toàn
(Mục tiêu) 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 t huộc Chính ph ủ
Commerce Anh, giúp hỗ trợ việc phân phối các chương tr ình mua s ắm của Chính phủ thông qua các ho ạt động
(Văn phòng thương mua sắm hợp tác và nâng cao tr ình đ ộ, năng lực mua sắm của các phòng ban. Nó cũng cung c ấp sự hỗ
mại chính phủ) trợ cho các dự án công phức tạp khác.

441
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 Khách hàng đ ặt tr ụ
(Xa bờ) 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ụ CNT T, hoặc Chức năng hỗ
trợ như một Bộ phận Hỗ trợ Dịch vụ - Ser vice 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à Khách hàng đ ặt
(Tại chỗ) 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 đư ợc cho là
(Vận hành) 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 vị cấu hình khác.
(Sự vận hành) Sự vận hành cũng đư ợc sử dụng để chỉ bất kỳ Hoạt động hay G iao 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 ật, Vận hành) .
((Thuộc về) 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 Operat ional 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 t hanh t oán t hư ờng lặp đi lặp lại. Ví dụ, chi
Chi phí vận hành 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 t iê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 vụ CNTT và b ộ
Agreement phận khác của cùng một Tổ chức. Một OLA hỗ trợ khả năng cung c ấp Dịch vụ CNTT cho Khách hàng
(Thỏa thuận mức vận của nhà cung c ấp Dịch vụ CNTT. OLA xác định hàng hóa ho ặc Dịch vụ sẽ được cung cấp và trách
hành) 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 đã t hỏa
thuận,
- Giữa Bộ phận Bộ phận Hỗ trợ Dịch vụ - Ser vice 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ụ.

442
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 nhất từ Quy
(Tối ưu hóa) trình, Đơn v ị cấu hìn h, Ứng dụng, v.v…
Organization Một công t y, 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 ty bao g ồm ISO
(Tổ chức) 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 Dịch vụ CNTT, v. v…
(Kết quả) 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 vụ CNTT.
(Thuê ngoài)
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 t ham gia làm việc chặt chẽ cùng nhau, cho các m ục đích chung ho ặc
(Sự cộng tác) cùng có lợi. Nhà cung c ấp Dịch vụ CNT T 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ị.
Passi ve 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 d ựa vào một
(Giám sát thụ động) 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 Kinh doanh. Hình
Acti vit y mẫu Hoạt động Kinh doanh đư ợc sử dụng để giúp nhà cung c ấp Dịch vụ CNTT hiểu và l ập k ế hoạch
(Hình mẫu Hoạt động 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 ngư ời, đội nhóm,
(Hiệu suất) Quy tr ình hay D ịch vụ CNTT.
Performance (Liên tục Cải t iến Dịch vụ) Quy tr ình ch ịu trách nhiệm về mọi Hoạt động Quản lý Công su ất hàng ngày.
Management 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, Triển khai các thay đ ổi liên quan
(Quản lý Hiệu suất) đến Hiệu suất và Công suất.

443
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 phát hành (ph ần
(Thử nghiệm) 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 t iết mô tả mọi Ho ạt động và Tài nguyên c ần thiết để đạt được một Mục t iêu. Ví d ụ, m ột
(Kế hoạch) 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 Q uả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 Edward Deming đưa
(Plan-Do-Check- Act) ra. Plan-Do- Check -Act còn đư ợc gọi là Chu k ỳ Dem ing.
- 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 Q uy tr ình,
- CHECK: Đo lư ờng các Qu y tr ình và D ịch vụ CNTT, so sánh v ới các Mục t iê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 Dow ntime (Thiết k ế Dịch vụ) Khoảng thời gian đư ợc thỏa t huận để một Dịch vụ CNTT không sẵn sàng (bị ngưng).
(Thời gian gián đoạn Thời gian gián đo ạn Đã được lập k ế hoạch thường được sử dụng để bảo tr ì, nâng cấp hoặc kiểm tra.
Đã được lập kế Xem thêm Change W indows ( C ửa sổ Thay đ ổi), Downt ime (Gián đo ạn).
hoạch)
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 Công suất.
(Hoạch định)
PMBOK Một Tiêu chu ẩn quản lý Dự án được công b ố và duy t r ì b ởi Học viện Quản lý Dự án ( Project
(PMBOK) Management Institut e). PMBOK là vi ết t ắt của Pr oject Management Body of Knowl edge. Tham khảo
http://www.pm i.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 sử dụng để
(Chính sách) đị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 Facilit y (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 Thứ ba và di
(Cơ sở Lưu động) 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.

444
Post Implementat ion Một sự Xem xét diễn ra sau khi m ột Thay đổi hoặc một Dự án đã đư ợc tr iển khai. Một PIR xác định xem
Review sự Thay đổi hay Dự án đã thành công và xác đ ịnh các cơ hội để cải tiến.
(Đánh giá Sau Triể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 ể bao g ồm các
(Thực tiễn) 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 t hành, ho ặc một điều kiện cần ph ải t hỏa mãn, để triển khai thành công
Success một Kế hoạch ho ặc Dự án. Một PFS thư ờng là đầu ra của một Quy tr ình là m ột đầu vào cần thiết của
(Điều kiện tiên quyết 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.
Priorit y (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 quan trọng
(Độ ưu tiên) 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 thư ờng không đư ợc
(Vấn đề) 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 đề. Mục t iêu ch ủ
(Quản lý Vấn để) 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 t hiể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. Các Thủ tụ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.
445
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 t iêu cụ thể. Một Quy tr ình
(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 hiện Quy tr ình đó
(Kiểm soát quy trình) một cách Hiệu quả, Năng suất và nhất quán.
Process Ow ner 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 Mục đích. Trách
(Chủ sở hữu Quy 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) 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 t r ình, tuy nhiên hai vai trò này có th ể đư ợc tách r iê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 giá tr ị thực tế khi
(Proforma) 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à q uản lý cùng nhau để đạt đư ợc một bộ tổng
(Chương trình) 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 tiêu hoặc Kết quả
(Dự án) khác. Mỗi Dự án có Vòng đời r iê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.
Qualit y Khả năng c ủa một Sản phẩm, Dịch vụ hay Quy tr ình có th ể cung cấp g iá tr ị đã đư ợc dự kiến. Ví dụ, m ột
(Chất lượng) 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 t iến chúng nếu cần thiết. Xem thêm Hệ thống quản lý chất lượng.
Qualit y 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 r ằng mọi công
System việc được thực hiện bởi một tổ chức có Chất lượng phù hợp đ ể đáp ứng một cách đáng tin c ậy các Mục
(Hệ thống Quản lý tiêu Kinh doanh ho ặc các Mức Dịch vụ. Xem thêm ISO9000.
Chất lượng)

446
R ACI (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 định Vai trò và
(RACI) Trách nhiệm. RACI là viết tắt của Responsible, Accountable, Consulted và Inf ormed.
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ẻ tài nguyên trong
Arrangement một tình huống khẩn cấp. Ví dụ, không gian Phòng Máy t ính ho ặc sử dụng chung m ột máy chủ lớn
(Thỏa thuận Đối ứng) (mainf rame).
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 động. Các Hồ sơ là
(Hồ sơ) bằng chứng thực tế cho thấy rằng một Hoạt động đã diễn ra và có t h ể 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 về trạng thái
(Khôi phục) đ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ược t hường
(Lựa chọn khôi phục) đượ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 hệ Kinh doanh,
(Quan hệ) đó 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ó t hể đượ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 Nhóm Quy tr ình ISO/IEC 20000 bao g ồm Quản lý Quan hệ Kinh doanh và Qu ản lý Nhà cung c ấp.
Processes
(Các Quy trình (về)
mối Quan hệ)

447
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 các Thành ph ần
(Bản phát hành) khác cần thiết để tr iể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à tr iển khai như là m ột thực thể đơn lẻ.
Release and (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.
Deplo yment
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 và kiểm soát vi ệc
(Quản lý Bản phát chuyển các Bản phát hành t ới Môi trư ờng Kiểm thử và Môi trư ờng Thật. Mục tiêu chính c ủa Quản lý
hành) 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 t iế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 phần của m ột
(Hồ sơ Phát hành) 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 đó.
Reliabilit y (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ị cấu hình hay D ịch
(Độ tin cậy) 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 MT BSI. 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 t iếp Dịch vụ) Một đề xuất chín h thức cho một Tha y đổi s ẽ đư ợc thực hiện. Một RFC bao g ồm
(Yêu cầu Thay đổi) 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 cầu dịch vụ.
(Yêu cầu thực hiện)

448
Requirement (Thiết k ế Dịch vụ) Một tuyên bố chính th ức về những gì c ần t hiết. Ví d ụ, một Yêu cầu Mức Dịch vụ, m ột
(Yêu cầu) 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 Lỗi hoặc để
(Khả năng phục hồi) Phục hồi một cách nhanh chón g 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 Sự cố hay một
(Giải pháp) 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 hay bất kỳ khái
(Tài nguyên) 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 Ti me 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. Đư ợc sử dụng
(Thời gian hồi đáp) 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.
Responsi veness 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à Thời gian H ồi đáp
(Phản ứng) 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ụ cho người sử
(Khôi phục) 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 t iế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 khác ra kh ỏi Môi
(“Nghỉ hưu”) 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 đư ợc kỳ vọng của
(ROI) một khoản đầu tư. Theo ng ữ nghĩa đơn giản nhất, đó là l ợi nhuận ròng của một khoản đầu tư chia cho
(Lợi nhuận đầu tư) giá trị ròng của tài s ản đầu tư.

449
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 b ộ hoạt động
(Trở lại Bình thườ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 đề, Q uy tr ình, Dự án, v. v… Các Xem xét thư ờng được thực hiện tại
(Xem xét) 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 m ột Vai trò. V í
Quyền) 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 được các Mục
(Rủi ro) 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 Ngu y
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 các Nguy cơ
(Đánh giá Rủi ro) đối với Tài sản đó, và đánh g iá 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 Đánh giá R ủi ro.
(Quản lý 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 hay m ột đội. Một
(Vai trò) 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 Vấn đề.
(Nguyên nhân Gốc)
Running Cost Xem Chi phí vận hành.
(Chi phí Hoạt động)
Scalabilit y 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 chức năng đã đư ợc
(Khả năng mở rộng) thỏa thuận khi Kh ối lượng công vi ệc hoặc Phạm vi thay đổi.

450
Scope Ranh g iới, hay mức độ mà một Quy tr ình, Thủ tục, Chứng chỉ, Hợp đồng, v. v… đư ợc áp dụng. Ví d ụ,
(Phạm vi) 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.
Securit y Xem Quản l ý Bảo mật Thông tin.
(Bảo mật)
Securit y Management Xem Quản l ý Bảo mật Thông tin.
(Quản trị bảo mật)
Securit y Policy Xem Chính sách Bảo mật Thông tin.
(Chính sách bảo mật)
Separation of (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 m ột Dịch vụ
Concerns CNTT trong đó vấn đề được tách ra làm nhi ều mảnh để có t hể được giải quyết ( từng mảnh) một cách
(Phân tách các mối độ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.
quan tâm)
Server (Vận hành D ịch vụ) Một máy t ính k ết nối tới m ột hệ t hống m ạng và cung c ấp các Chức năng ph ần mềm
(Máy chủ) đượ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 để đạt được Kết
(Dịch vụ) 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ụ CNTT đáp ứng
Criteria được các Yê u cầu về chức năng và Ch ất lượng của nó, đồng thời nhà cung cấp Dịch vụ CNTT sẵn sàng
(Tiêu chí Chấp thuận để Vận hành D ịch vụ CNTT mới khi nó đã đư ợc triển khai. Xem thêm Ch ấp thuận.
Dịch vụ)
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ụ)

451
Service Capacit y (Thiết k ế Dịch vụ)/(Liên t ục Cải t iến Dịch vụ) Hoạt động ch ịu t rách nhiệm cho việc t ìm hi ểu Hiệu suất và
Management Công su ất của các Dịch vụ CNTT. Các Tài nguyên đư ợc sử dụng bởi mỗi Dịch vụ CNTT và hình m ẫu
(Quản lý Công suất của việc sử dụng theo thời gian đư ợc thu thập, ghi nh ận và phân t ích đ ể sử dụng trong Kế hoạch Công
Dịch vụ) 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 Catal ogue (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 t hông tin v ề mọi Dịch vụ
(Bản liệt kê 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 t in 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 Continuit y 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 t iêu chủ yếu cú văn hóa Dịch vụ là sự hài lòng của Khách
(Văn hóa Dịch vụ) hàng và giúp cho Khách hàng đ ạt được các Mục t iê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 vụ bao g ồm một
(Thiết kế Dịch vụ) 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 (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 Yêu c ầu của nó
Package 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ụ
(Gói Thiết kế 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ử dụng. Một Bộ phận
(Bộ phận Hỗ trợ Dị ch Hỗ trợ Dịch vụ thông thường sẽ quản lý các Sự cố và các yêu c ầu Dịch vụ đồng thời xử lý vấn đề
vụ) truyền thông với Người sử dụng.
Service Fail ure (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 sự gián đoạn
Anal ysi s 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ụ
(Phân tích Lỗi Dịch 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
vụ) là một quá tr ình phân t ích liên t ục.

452
Service Hours (Thiết k ế Dịch vụ)/(Liên t ục Cải t iến Dịch vụ) Một khoảng thời gian đư ợc thỏa thuận khi mà D ịch vụ
(Giờ 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 ng hĩ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 tr iển khai việc cải t iến một Quy tr ình hay m ột
Plan Dịch vụ CNTT.
(Kế hoạch Cải tiến
Dịch vụ)
Service Know ledge (Chuyển t iế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 và thông tin.
Management Syst em SKMS bao g ồm Hệ t hống Quản lý Cấu hình, cũng như các công cụ và cơ sở dữ liệu khác. SMKS lưu
(Hệ thống Quản lý trữ, quản lý, cập nhật và giới thiệu mọi thông tin mà nhà cung c ấp Dịch vụ CNTT cần đ ể quản lý Vòng
Kiến thức Dịch vụ) đờ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 Dịch vụ. Thuật
(Mức Dịch vụ) 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 t iến Dịch vụ) Một Thỏa thuận giữa một Nhà cung cấp Dịch vụ CNTT và
Agreement (SL A) 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 t iêu nh ắm đến về mức Dịch vụ, xác
(Thỏa thuận Mức Dịch định rõ trách nhi ệm của nhà cung c ấp Dịch vụ CNTT cũng như c ủa Khách hàng. Một SLA đơn lẻ có thể
vụ) 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 thương lư ợng về các
Management (SLM) Thỏa thuận Mứ c Dịch vụ, và đảm bảo rằng chúng đư ợc đáp ứng. SLM ch ịu trách nhiệm cho việc đảm
(Quản lý Mức Dịch vụ) 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ụ cụ thể. Mỗi
(Gói Mức Dịch vụ) SLP được thiết kế để đáp ứng yêu c ầu của một Hình mẫu Hoạt động Kinh doa nh cụ thể. Xem thêm
Tuyến dịch vụ.

453
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 khía cạnh của
Requirement Dịch vụ CNTT. Các SLR d ựa trên Mục tiêu Kinh doanh và đư ợc sử dụng để thương lượng các mục t iêu
(Yêu cầu Mức Dịch mức Dịch vụ đã thỏa thuận.
vụ)
Service Level Target (Thiết k ế Dịch vụ)/(Liên tục Cải t iến Dịch vụ) Một cam k ết được tài li ệu hóa lại trong m ột Thỏa thuận
(Mục tiêu mức Dịch 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
vụ) rằng Thiết kế Dịch vụ CNTT là Phù h ợp với Mục đích. Các Mục t iêu Mức Dịch vụ nên theo t iêu là
S(Specif ic) M( Measur able)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 giá tr ị cho các
(Quản lý Dịch vụ) 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ự phối hợp và Kiểm
Lifecycle soát đối với các Chứ c năng, Quy tr ình, và H ệ thống đa dạng để quản trị toàn bộ Vòng đời c ủa các D ịch
(Vòng đời Quản l ý vụ CNTT. Phương pháp ti ếp c ận Vòng đ ời Quản trị Dịch vụ xem xét Chiến lược, Thiết k ế, Chuyển giao,
Dịch vụ) Vậnn hành và Liên t ục cải t iế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 Dịch vụ CNTT.
(Người Quản lý Dịch 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 quản lý nào của Nhà cung cấ p
vụ) 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 D ịch vụ bao g ồm
(Vận hành Dịch vụ) 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 Ow ner (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ụ CNTT cụ thể.
(Chủ sở hữu Dịch vụ)
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 c ấp Dịch vụ.
(Danh mục 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ụ.

454
Service Portf olio (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ụ. Quản lý Danh m ục
Management Dịch vụ xem xét các Dịch vụ theo giá tr ị Kinh doanh mà chúng cung c ấp.
(Quản lý Danh mục
Dịch vụ)
Service Provi der (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 N ội bộ hoặc
(Nhà cung cấp Dịch 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ụ
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 các báo cáo về
(Báo cáo Dịch 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, hoặc cho một Thay
(Yêu cầu Dịch vụ) đổi T iê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ụ t hườ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 ụ thiết lập Chiến lược
(Chiến lược Dịch vụ) 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 tiếp Dịch vụ bao
(Chuyển tiếp Dịch vụ) 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 Warrant y (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. Đây có thể là
(Bảo đảm Dịch vụ) 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 m arketing hay m ột hình ảnh thương hi ệu. Giá tr ị Kinh doanh c ủa một Dịch vụ CNT T
đượ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.
Serviceabilit y (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ứ ba nhằm đáp
(Khả năng Phục vụ) ứng các điều khoản trong Hợp đồng. Hợp đồng này sẽ bao g ồm các mức đã đưuọ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.

455
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ụ thể trong một
(Ca) 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ỹ t huật t ạo ra một mô hình chi t iết nhằm dự đoán
(Mô hình hóa Giả lập) 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 G i ả 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 G iao
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 Fail ure (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à khi mà Biện
(Điểm Đơn Lỗi) 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.
SM ART (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 nghĩa các Yêu
(Đặc tả) 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 liên quan có
(Bên liên quan) 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.
Standard 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 ế), một tiêu chu ẩn bảo
(Tiêu chuẩn) mật nội b ộ cho việc thiết lập cấu hình Unix, m ột t iê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.

456
Standby (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 để cung cấp một
(Trạng thái chờ) 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 t hu ận Hot Standby, W arm
Stanby hay Cold Standby.
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 một Dịch vụ
Requirements 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 trong Vòng đời của
(Trạng thái) Đơ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 (Chiến lược, Chiến
((Mang tính) Chiến thuật, Vận hành). Các Ho ạt động (mang tính) Chi ến lược bao g ồm thiết lập Mục t iêu và Ho ạch định dài
lược) hạn để đạt được Tầm nhìn tổng thể.
Strateg y (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 đã đư ợc xác định.
(Chiến lược)
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 cấp hàng hóa
(Nhà cung cấp) 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 and 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 để quản lý các Hợp
Database đồng cung cấp trong suốt Vòng đời của chúng. SCD bao g ồm các Thuộc t ính ch ủ yếu của mọi Hợp đồng
(Cơ sở dữ liệu Nhà với các Nhà cung c ấp, và nên là m ột phần của Hệ thống Quản lý Kiến thức Dịch vụ.
cung cấp và Hợp
đồng)
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à Nhà cung c ấp hỗ
(Quản lý Nhà cung trợ các nhu c ầu cần thiết của Doanh ng hiệp, và mọi Nhà cung c ấp đáp ứng được các điều khoản cam
cấp) kết trong hợp đồng.

457
Suppl y 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 Nhà cung c ấp. Một
(Chuỗi cung ứng) 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 hỗ trợ Kỹ t huật
(Nhóm hỗ trợ) 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 đối với Người
(Giờ hỗ trợ) 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ụ Danh b ạ
(Dịch vụ hỗ trợ) hay Dịch vụ sao lưu.
SWOT Anal ysis (Liên tục Cải t iế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 yếu nội tại của
(Phân tích SWOT) 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. SW OT đại diện cho
Strenghts – Điểm mạnh (S), W eaknesses – Đ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à Quy tr ình
(Quản lý Hệ thống)
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 t huật, Vận hành). Các
(Chiến thuật) 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.

458
Technical (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 trong hỗ trợ Dịch
Management 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ư
(Quản lý Kỹ thuật) 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 Ref erence (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ó t hể cung cấp được, Tài
(Tham chiếu Thuật 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, Quy tr ình v. v…
(Kiểm tra) đáp ứng được Đặc t ả hoặc các Yêu cầu đã Thỏa thuận. Chấp thuận.
Third Part y Một người, nhóm ho ặc Doanh nghiệp không phải là một phần của Thỏa t huận Mức Dịch vụ đối với một
(Bên thứ ba) 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 gia vào gi ải
(Tuyến hỗ trợ thứ ba) 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 ng uyê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ự cố đều có t hể
(Mối đe dọa) đượ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 thi. Ví dụ “Sự cố
( Ngưỡng) 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”.

459
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ực hiện trong
(Thông lượng) 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 tiếp c ận toàn
Ow nership bộ Vòng đời của Chi phí c ủa một Đơn vị cấu hình, không ch ỉ là Chi phí ban đ ầu ho ặc giá mua.
(Tổng Chi phí Sở hữu)
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 t iền từ tài khoản ngân hàng này
(Giao dịch) 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 c ủa Dịch vụ
(Chuyển đổi) 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 Anal ysis (Phát tr iể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-thời gian. Phân
(Phân tích xu hướng) 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 nguyên hi ệu quả nhất.
(Điều chỉnh) Đ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à tr iển khai
những Thay đổi cần thiết.
Underpinning (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. Bên thứ ba cung
Contract 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
(Hợp đồng Cơ sở) 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 một Vấn đề, Sự cố
((Tính) Khẩn cấp) 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.

460
Usabilit y (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ể được sử dụng.
((Tính) Dễ 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 t iêu cần thiết, và
(Trường hợp Sử để 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
dụng) giữa Người sử dụng và một Dịch vụ CNTT hoặc Hệ thống khác.
Utilit y (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 ứng một yêu
(Tính tiện dụng) 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ế hoạch, hay Sản
(Xác nhậ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 có giá tr ị cho
(Chuỗi giá trị) 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 cứ trên sự s o
(Giá trị của Tiền) 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 Netw ork (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 nhóm hay T ổ chứ c.
(Mạng giá trị) Giá trị được tạo r a t hô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 thực tế. Thường
(Phương sai) được sử dụng trong Quản lý Tài chính, Q u ả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 trình, K ế hoạch hoặc
(Xác minh) 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.

461
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 Đơn vị cấu hình.
(Phiên bản) 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 đư ợc tạo
(Tầm nhìn) 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 (Thiết k ế Dịch vụ) Một Chức năng của Quy tr ình Nghiệp vụ t hực sự là rất quan trọng cho sự thành công
Function của Doanh nghiệp. Các Chức năng Nghiệp vụ Trọng yếu là sự cân nhắc quan trọng của Quản lý Liên
(Chức năng Nghiệp vụ 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.
Trọng yếu)
Vulnerabilit y 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 tường lửa, một mật
(Lỗ hổng) 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 Standb y Xem Khôi phục trung bình
(Trạng thái chờ Ấm)
Warrant y (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ẽ đáp ứng các
Bảo hành 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 cần t uân t heo
(Hướng dẫn công để 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 ỉ
việc) đượ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 đề khi mà Gi ải
(Giải pháp thủ công) 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ố.

462
Workload Các nguồn lực cần t hiết để cung cấp một phần có th ể xác đ ịnh đượccủa một dịch vụ CNTT. Khối lượng
(Khối lượng cô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
việc) 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.

463

Axelos - ITILv3 - Service Design - Vi

Uploaded by

Document Information

Original Title

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

Axelos - ITILv3 - Service Design - Vi

Uploaded by

Copyright:

Available Formats

AXELOS ® ITIL V3

CORE PUBLISH #2: SERVICE DESIGN

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

Ấn phẩm này là m ột trong 5 ấn phẩm cốt lõi m ô tả những thực tiễn

Cho dù bạn có là m ột thành viên của m ột công ty toàn c ầu, m ột cơ

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

Colin Rudd (IT Enterprise Managem en t Services Ltd – ITEMS) Tác

Nhóm thi ết kế ITIL

Sergio Rubinato Filho

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

Nhóm tư vấn ITIL

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

Người xem xét

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

1.2 Bối cảnh

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

1.2.2 Thực tiễn tốt trong khu vực công

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

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

1.2.3 ITIL và thực tiễn tốt trong quản lý dịch vụ

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

Hình 1.3 - Cốt lõi ITIL

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

1.2.3.2 Thiết kế Dịch vụ

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

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ụ

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

Có nhiều cách để cung cấp m ột dịch vụ CNTT, chẳng hạn như có

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

2.2 Các dịch vụ là gì?

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

2.3 Các Chức năng và quy trình trong su ốt vòng đời

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

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

 Có thể đo lường được - chúng ta có thể đo lường quy trình

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

2.3.3 Chuyên môn hóa và ph ối hợp trong suốt vòng đời

2.4 Các nguyên tắc cơ bản trong Thiết kế Dịch vụ

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

 Những dịch vụ m ới hoặc được thay đổi.

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

 Việc thỏa thuận về các m ức dịch vụ, SLA và đích nh ắm m ục

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY

Thường thì việc thiết kế m ột dịch vụ m ột dịch vụ ưu việt m ới hoặc

 Được định hướng, tập trung và thúc đẩy-doanh nghi ệp và

ITIL v3 - CHIẾN LƯỢC DỊCH VỤ - SERVICE STRATEGY