IT Service Management
Kelompok 5
Nama Anggota :
- · Gusna Nilam Kharisma 14114634
- · Haryanto Isman 14114832
- · Herli Juliansyah 1C114800
- · Ira Rochimah 1C114882
- · Irman Yazid 15114466
Kelas :
2
KA 15
Ø REQUEST
FULFILMENT (SO 4.3)
PENDAHULUAN DAN RUANG LINGKUP
Permintaan
pemenuhan adalah proses yang melakukan permintaan layanan dari para pengguna.
Hal ini mencakup permintaan perubahan
standar, permintaan informasi dan pengaduan. Dari titik pandang layanan, proses
permintaan pemenuhan cenderung menutupi semua panggilan yang tidak insiden.
Sandi ulang dan pertanyaan tentang mendapatkan software tambahan beberapa
permintaan volume yang lebih tinggi. Permintaan biasanya tinggi dalam volume,
tapi risiko rendah dan biaya rendah. Sebuah proses yang berbeda yang terpisah
di tempat untuk menghindari kebingungan dengan kejadian penanganan bahwa
layanan juga melakukan usaha.
MAKSUD DAN TUJUAN
Tujuan dari proses
ini adalah untuk tindakan permintaan layanan secara efektif dan efisien.
Permintaan pemenuhan memungkinkan pengguna untuk mendapatkan informasi dan
perubahan standar lengkap secepat mungkin.
-
PERMINTAAN LAYANAN
Permintaan
layanan permintaan dari pengguna untuk informasi, saran, untuk perubahan
standar atau untuk akses ke layanan TI.
-
STANDAR PERUBAHAN
Perubahan
standar perubahan yang disetujui pra yang berisiko rendah, relatif umum dan
mengikuti prosedur atau bekerja instruksi.
KUNCI KEGIATAN
Permintaan
pemenuhan harus dibuat sesederhana mungkin. Tidak seperti insiden, permintaan
seharusnya diprediksi dan direncanakan untuk. Ini akan tergantung pada ukuran
dan skala organisasi apakah permintaan ditangani melalui sistem logging yang
sama seperti insiden. Untuk organisasi dengan sejumlah besar permintaan,
penebangan terpisah dan sistem maju mungkin tepat
Peran kunci dari
permintaan pemenuhan adalah untuk menangani sejumlah besar permintaan secara
efisien dan untuk menghindari adanya birokrasi. Pengguna akan frustasi jika
permintaan yang sah atau query tidak dapat ditangani secara efisien dan
menanggapi. Sebuah pandangan holistik situasi dapat diambil dengan menangani
semua permintaan di satu tempat, sehingga kebutuhan pelatihan, kesenjangan
komunikasi dan persyaratan untuk perubahan standar untuk diidentifikasi.
PERMINTAAN MODEL
Di mana volume
tinggi dari permintaan yang sama atau serupa diharapkan, model proses dapat
didefinisikan untuk membakukan kegiatan yang akan dilakukan. Adopsi model
permintaan akan memudahkan proses dan memungkinkan volume yang lebih besar
untuk diproses.
HUBUNGAN DENGAN PROSES MANAJEMEN LAYANAN LAINNYA
-
Manajemen keuangan
Perlu ada hubungan
yang kuat antara manajemen keuangan dan permintaan pemenuhan untuk memastikan
bahwa volume, beban kerja dan penggunaan sumber daya sepenuhnya dipahami.
-
Perubahan manajemen
Di mana model
permintaan berkaitan dengan perubahan standar, akan ada persetujuan yang diperlukan dari manajemen
perubahan yang akan diperhitungkan masalah pengelolaan keuangan.
Ø INCIDENT MANAGEMENT (SO 4.2)
PENDAHULUAN DAN RUANG LINGKUP
Nilai dari insiden manajemen untuk bisnis itu sumber
daya yang dialokasikan untuk meminimalisir dan mengurangi dampak insiden dan
jasa prioritas tidak tersedianya sejalan dengan bisnis. Tingkat yang lebih
rendah dari insiden dan cepat resolusi kali ini akan dapat digunakan oleh
layanan untuk menjalankan seperti dimaksudkan.
Selama penanganan insiden, pelayanan meja mungkin
dapat untuk mengidentifikasi perbaikan proses bisnis dan teknis di kedua.
Pelayanan meja sering memiliki posisi yang unik dalam pasukan organisasi di
holistik staf bisa mengambil sebuah pandangan bagaimana organisasi
mengoperasikan, memungkinkan baik praktek untuk menjadi disebarkan dan buruk
praktek untuk dihilangkan.
MAKSUD
DAN TUJUAN
Tujuan
utama proses pengelolaan kejadian tersebut yaitu memulihkan layanan normal
operasi secepat mungkin dan untuk meminimalisasi dampak yang merugikan terhadap
operasi bisnis .
KONSEP
DASAR
INSIDEN
Insiden
adalah gangguan yang tidak direncanakan oleh suatu layanan itu atau pengurangan
kualitas dari suatu layanan itu. Kegagalan konfigurasi item yang belum
berdampak layanan ini juga insiden.
·
Rentang
waktu : Rentang waktu untuk insiden mendorong penanganan untuk peningkatan yang
harus mendapat persetujuan dan didokumentasikan dalam SLA. Terhadap SLA kinerja
kemudian dapat diukur dan dilaporkan. Alat dapat dikonfigurasikan untuk
aktifkan peningkatan otomatis sesuai dengan rentang waktu yang telah
disepakati.
·
Model
Insiden : Penerapan model insiden adalah metode standardisasi dan mengotomatisasi
, mungkin jika pendekatan kelompok insiden serupa. Model insiden didefinisikan
dengan serangkaian langkah-langkahyang akan dilakukan. Detail model insiden
dapat menjadi masukan ke dalam alat penanganan insiden ( s ).
· Insiden Mayor : organisasi yang berbeda akan memiliki definisi yang berbeda untuk apa yang merupakan insiden besar . Untuk beberapa organisasi , pemicu untuk ' memanggil ' insiden besar adalah ketika sejumlah pengguna telah berdampak . Untuk organisasi lain , mungkin memicu kerugian keuangan aktual atau potensial dari hilangnya layanan . Jika kerugian keuangan aktual atau potensial adalah lebih dari jumlah tertentu , kejadian itu menjadi besar . Untuk beberapa area bisnis di beberapa industri , mungkin ada risiko cedera atau kehilangan nyawa jika layanan tertentu tidak tersedia . Sekali lagi , ini mungkin menjadi pemicu insiden menjadi besar . kerusakan reputasi organisasi bisa menjadi pemicu lain .
Organisasi yang lebih besar mungkin telah mendedikasikan tim manajemen insiden besar tersedia 24/7 yang mengendalikan insiden yang telah ditunjuk. Salah satu peran penting bahwa manajer insiden besar melakukan adalah untuk melindungi orang-orang (yang sering IT manajemen operasi , manajemen teknis dan staf manajemen aplikasi ) yang mencoba untuk memulihkan layanan dari tuntutan komunikasi yang dibuat pada mereka . Selama insiden besar , akan ada banyak tuntutan dan permintaan untuk update yang perlu dikelola . tim manajemen insiden besar akan telah menetapkan rute untuk komunikasi dan eskalasi ( baik fungsional dan hierarkis ) .
Sebuah
proses manajemen insiden besar mirip dengan proses manajemen insiden , tetapi
berkembang dengan urgensi yang lebih besar dan dengan profil yang lebih tinggi
dalam organisasi . Kegiatan yang dilakukan harus tetap login , tapi fokusnya
adalah pada pemulihan layanan secepat mungkin dengan minimal gangguan .
KEGIATAN
UTAMA
Alur
proses manajemen insiden
Aliran
proses manajemen insiden diilustrasikan pada Gambar 26.1 dan berisi
langkah-langkah berikut :
·
Masukan
ke proses : Insiden dapat dideteksi dan dilaporkan dalam berbagai cara .
Pengguna akan memanggil meja layanan untuk melaporkan insiden . staf teknis
dapat log insiden atau rincian email dari sebuah insiden yang mereka telah
mengidentifikasi ke meja layanan . insiden semakin dibangkitkan melalui
antarmuka web . Proses manajemen acara juga akan melaporkan insiden dengan
pemantauan .
·
Identifikasi
Insiden : Bekerja untuk memahami dan mengatasi insiden tidak dapat dimulai
sebelum insiden telah diidentifikasi . Untuk alasan ini , pemantauan komponen
yang membentuk layanan kunci penting . Insiden dapat diidentifikasi dengan
berbagai cara oleh pengguna , staf teknis dan dengan pemantauan .
·
Penebangan
Insiden : Semua insiden harus login
dengan tanggal dan waktu yang direkam . Pada tahap ini , informasi yang
diperlukan untuk mengelola insiden itu akan dicatat . Ini akan mencakup nomor
unik referensi , deskripsi gejala , layanan atau CI dampak , dampak, urgensi
dan nama orang meningkatkan insiden atau metode meningkatkan insiden tersebut .
·
Insiden
kategorisasi : Kode kategorisasi yang cocok akan dialokasikan . Misalnya , ini
mungkin hardware atau software dengan sub - kode untuk kategorisasi tingkat
yang lebih rendah . kategorisasi akurat adalah penting karena akan memungkinkan
metrik berguna untuk mengumpulkan menyoroti bidang infrastruktur di mana
insiden terjadi .
·
Insiden
prioritas : Prioritas insiden didasarkan pada dampak dan urgensi . Dampak
adalah ' sakit ' untuk bisnis . Dampak mungkin berhubungan dengan jumlah
pengguna yang terkena dampak , potensi kerugian keuangan untuk organisasi ,
risiko pelanggaran aturan peraturan atau legislatif atau , untuk beberapa
layanan , risiko hilangnya nyawa . Urgensi berkaitan dengan seberapa cepat
bisnis membutuhkan insiden untuk diselesaikan .
·
Diagnosis
Awal: Jika insiden itu telah dibangkitkan oleh panggilan ke meja layanan , maka
itu akan menjadi meja layanan yang melakukan diagnosis awal , biasanya
sementara pengguna masih di telepon . Ketersediaan script diagnostik akan
membantu seperti yang akan kemampuan untuk pertandingan melawan masalah dan
kesalahan dikenal . CMDB juga dapat berkonsultasi pada tahap ini .
·
Insiden
eskalasi : Eskalasi mungkin fungsional atau hirarkis .
~
Eskalasi
Fungsional terjadi ketika meja layanan tidak mampu menyelesaikan insiden atau
di mana insiden itu belum terselesaikan dalam waktu resolusi sasaran . Layanan
meja akan melibatkan dukungan tingkat kedua , yang memiliki pengetahuan teknis
yang lebih spesifik . eskalasi fungsional lanjut dapat terjadi melalui siklus
hidup insiden dukungan tingkat ketiga , yang mungkin menjadi bagian dari
organisasi atau pihak ketiga seperti pemasok . Penting untuk diingat bahwa
kepemilikan insiden selalu tetap dengan layanan meja terlepas dari daerah
pendukung lainnya bekerja pada resolusi .
~
Eskalasi
hirarkis meningkatkan profil dari insiden tertentu dalam organisasi TI dan juga
dalam bidang bisnis . Lebih senior staf TI mampu memberikan fokus dan sumber
daya, tetapi kepemilikan insiden tersebut akan disimpan oleh layanan meja .
Organisasi akan memiliki pemicu yang menunjukkan kapan eskalasi hirarkis
diperlukan . Hal ini mungkin untuk semua ' Prioritas 1 ' insiden atau ketika
insiden prioritas tertentu belum terselesaikan dengan skala waktu sasaran.
Pemicu eskalasi akan disimpan dalam SLA yang relevan dan harus disorot oleh
alat dukungan digunakan . Layanan meja akan menjaga pengguna informasi dari
semua eskalasi fungsional atau hirarki yang terjadi selama siklus hidup insiden
dan pada saat yang sama catatan insiden akan diperbarui .
·
Investigasi
dan diagnosis : Pada fase ini siklus hidup insiden , pekerjaan dilakukan oleh
daerah meja layanan atau dukungan untuk memahami apa yang harus dilakukan untuk
memulihkan layanan . Hal ini sering paling memakan waktu bagian dari proses
meskipun dapat dipercepat menggunakan script diagnostik dan dengan mengacu pada
insiden lainnya dan masalah serta dikenal database error.
·
Resolusi
dan pemulihan : Penyelidikan dan diagnosis fase akan tiba di resolusi . Hal ini
perlu diterapkan dan kemudian pengujian perlu dilakukan untuk memastikan bahwa
insiden tersebut telah diselesaikan dan layanan dipulihkan . Mungkin ada lag
waktu antara memperbaiki diterapkan dan layanan berjalan normal lagi ( mis
mungkin ada backlog pengolahan untuk mengejar ) . Pada kesempatan lain ,
mungkin tidak mungkin untuk memastikan apakah memperbaiki telah bekerja untuk
jangka waktu ( misalnya jika masalah asli dengan proses akhir bulan ) . Terlepas
dari mana resolusi telah dimasukkan ke dalam tempat atau yang terlibat ,
insiden itu harus diteruskan kembali ke meja layanan untuk penutupan .
·
Insiden
penutupan : Hanya meja layanan harus menutup insiden . Perlu kesepakatan
pengguna bahwa insiden itu telah diselesaikan . Semua dokumentasi kejadian
harus diselesaikan sebelum penutupan dan kategori penutupan dialokasikan untuk
memungkinkan metrik bermakna untuk diproduksi . survei kepuasan pengguna harus
dilakukan untuk disepakati ( dalam SLA ) persentase insiden . survei kepuasan
pengguna ini dapat dilakukan melalui telepon , email atau antarmuka web .
HUBUNGAN DENGAN PROSES
MANAJEMEN LAYANAN LAINNYA
Manajemen
insiden terkait erat dengan manajemen masalah dengan satu atau lebih insiden
yang disebabkan oleh masalah . Ada juga link yang kuat dengan manajemen
perubahan . Perubahan seringkali dilaksanakan untuk menyelesaikan insiden atau
sejumlah insiden dan , sayangnya , perubahan yang tidak melakukan apa yang
mereka dimaksudkan untuk melakukan dapat menyebabkan insiden . Layanan aset dan
manajemen konfigurasi menyediakan informasi yang dibutuhkan untuk mengelola
insiden . Layanan manajemen tingkat akan memberikan kali resolusi sasaran
bersama-sama dengan kriteria eskalasi .
METRIK
Metrik
insiden berguna termasuk :
·
persentase
insiden diselesaikan dalam SLA ;
·
biaya
rata-rata insiden ;
·
biaya
rata-rata insiden besar ;
·
persentase
insiden yang utama.
Selain
itu , dari sudut pandang staf pandang , penting untuk mengetahui volume kedua
insiden dan insiden besar . Sendiri , metrik ini tidak selalu memberikan ukuran
efektivitas atau efisiensi , tetapi mereka penting dalam memahami skala isu
yang diangkat .
PERAN
Manajer
Insiden bertanggung jawab atas efektivitas dan efisiensi proses manajemen
insiden . dukungan lini pertama dilakukan oleh meja layanan dengan dukungan
kedua dan ketiga -line yang disediakan oleh tim teknis baik internal organisasi
atau melalui pihak ketiga .
TANTANGAN
Perbedaan
antara insiden dan manajemen masalah
Ada
perbedaan yang sangat nyata antara manajemen insiden dan manajemen masalah .
manajemen insiden semata-mata terfokus pada pemulihan layanan secepat mungkin
sementara tujuan manajemen masalah adalah untuk memahami dan mengatasi akar
penyebab . Hal ini dapat menyebabkan ketegangan antara dua proses .
Tantangan
Lainnya
·
Deteksi
dini insiden ( sebaiknya sebelum layanan dipengaruhi ) .
·
Membujuk
dan menjelaskan kepada semua pengguna bahwa semua insiden harus login melalui
meja layanan . kampanye kesadaran sangat berguna di daerah ini .
PERTANYAAN UJI UNTUK BAB 26
SF 01
SO 05, SO 08, SO 13, SO 17
TA 03
A 16, A 20
Ø PROBLEM
MANAGEMENT (SO 4.4)
Pendahuluan
dan ruang lingkup
Masalah manajemen bertanggung jawab untuk
pengelolaan semua masalah dalam infrastruktur TI. Proses ini meliputi analisis
akar penyebab dan tiba di resolusi masalah. Masalah manajemen tetap bertanggung
jawab sampai resolusi diimplementasikan melalui manajemen perubahan dan
manajemen rilis.
Masalah manajemen memberikan nilai bagi organisasi
dengan menghindari, mengurangi dan mitigasi dampak bisnis yang merugikan dari
masalah. Hal ini memungkinkan layanan untuk menjadi lebih tersedia dan menjadi
lebih kuat.
MAKSUD
DAN TUJUAN
Tujuan dari manajemen masalah adalah:
• untuk mencegah masalah dan insiden yang dihasilkan
dari terjadi;
• untuk menghentikan insiden berulang terjadi;
• untuk mengurangi dan mengurangi dampak negatif
dari insiden yang tidak dapat dicegah.
Soal manajemen, seperti kebanyakan proses, memiliki
aspek reaktif dan proaktif. Dari perspektif reaktif, tujuan dari proses ini
adalah untuk mengelola siklus hidup masalah dari identifikasi untuk eliminasi
dengan menentukan akar penyebab dan kemudian menerapkan perubahan yang
diperlukan (s) untuk mencegah kekambuhan. Dari perspektif proaktif, tujuan dari
proses ini adalah untuk mencegah insiden di masa depan jika memungkinkan atau
mengurangi dampak dari insiden yang tidak dapat dicegah.
KONSEP
DASAR
MASALAH
Sebuah masalah adalah penyebab dari satu atau lebih
insiden.
Soal model
Sebuah model masalah adalah ide yang mirip dengan
model insiden. Soal model menyediakan pendekatan standar untuk masalah
mengatasi.
Perbedaan antara reaktif dan proaktif Ada dua bagian
dari manajemen masalah. manajemen masalah reaktif menanggapi insiden dan
masalah yang terjadi. Sisi proaktif manajemen masalah berkaitan dengan mencegah
insiden dan masalah yang terjadi. masalah manajemen proaktif sering dipicu oleh
peningkatan pelayanan terus-menerus.
Sebuah analogi yang baik adalah untuk
mempertimbangkan Pemadam Kebakaran. Setiap Fire Service akan terlibat dalam
pertempuran kebakaran. Ini adalah bagian reaktif dari peran mereka. Semua
Layanan Api juga terlibat dalam pencegahan kebakaran dengan meningkatkan kesadaran
masyarakat dan instalasi dan pengujian alarm asap dan sensor. Ini adalah sisi
proaktif. Masalah manajemen harus memiliki split yang sama, memastikan bahwa
sumber daya yang terlibat dalam pencegahan masalah jangka panjang serta di sini
dan sekarang respon reaktif terhadap masalah dan insiden. Hal ini sering sulit
untuk melepaskan sumber daya ke sisi proaktif, terutama ketika tuntutan reaktif
yang tinggi, tapi itu adalah pencegahan masalah proaktif yang memungkinkan
organisasi untuk menjadi lebih dewasa dalam manajemen layanan mereka.
KEGIATAN
UTAMA
Proses manajemen masalah aliran Aliran proses
manajemen masalah diilustrasikan pada Gambar 27.1 dan berisi langkah-langkah
berikut:
•
Masukan
ke proses: The masukan kepada manajemen masalah bisa datang dari sejumlah
sumber. Ini termasuk manajemen insiden, manajemen acara dan meja layanan.
Selain itu, manajemen masalah proaktif dapat mengidentifikasi masalah. Pemasok
dan proses lainnya seperti manajemen rilis, manajemen kapasitas dan manajemen
ketersediaan mungkin juga menyadari masalah.
•
Masalah
deteksi: Masalah dapat dideteksi dalam banyak cara. Meja layanan mungkin
percaya bahwa satu atau lebih insiden yang disebabkan oleh masalah tertentu.
daerah dukungan lini kedua dapat mengidentifikasi masalah ketika melakukan
penanganan insiden. Masalah juga dapat dideteksi secara otomatis oleh alat
manajemen layanan digunakan. masalah manajemen proaktif akan mengidentifikasi
masalah sering sebelum insiden terjadi. Demikian juga, proses lain seperti manajemen
rilis dan manajemen ketersediaan akan menyadari masalah.
·
Masalah
logging: Sangat penting bahwa rincian lengkap tentang masalah dicatat. Ini akan
memungkinkan analisis untuk mengambil tempat dan akan memungkinkan perbandingan
dibuat antara masalah. Semua insiden yang disebabkan oleh masalah harus
dikaitkan dengan catatan masalah yang memungkinkan lingkup dan skala dampak
dipastikan mudah. Tanggal dan waktu bahwa semua masalah login harus dicatat
dalam catatan masalah.
·
Soal
kategorisasi: Penting untuk mengkategorikan masalah dan dianjurkan bahwa sistem
yang sama digunakan sebagai diadopsi oleh proses manajemen insiden untuk setiap
organisasi tertentu. Yang benar dan bermakna kategorisasi akan memungkinkan
metrik bermanfaat untuk diproduksi dan memungkinkan manajemen masalah proaktif
untuk mengidentifikasi daerah-daerah untuk berkonsentrasi pada.
·
Masalah
prioritas: Masalah yang harus diprioritaskan dalam cara yang sama seperti
insiden. Tabel 27.1 menunjukkan sistem pengkodean prioritas masalah sederhana.
Target kali penyelesaian masalah akan telah
dialokasikan untuk masing-masing tingkat prioritas. Ini akan telah disepakati
dengan bisnis dan dicatat dalam SLA.
Salah satu faktor yang akan memberi makan ke dalam
dampak dan urgensi masalah adalah tingkat kekambuhan.
•
Masalah
investigasi dan diagnosis: Tujuan dari investigasi dan diagnosis tahap adalah
untuk memastikan penyebab akar masalah. Prioritas dialokasikan untuk masalah
harus mendorong jumlah sumber daya yang bekerja pada penyelidikan dan
diagnosis. Prioritas harus dinilai selama masa masalah untuk memastikan bahwa
hal itu tetap benar.
Ada berbagai teknik pemecahan masalah yang dapat
digunakan untuk membantu diagnosis masalah. Ini termasuk:
•
Kepner
dan Tregoe: Pendekatan logis untuk pemecahan masalah dimulai dengan
mendefinisikan dan kemudian menjelaskan masalah. Kemungkinan penyebab
ditetapkan, dan kemudian kemungkinan penyebab diuji dan akhirnya penyebab
sebenarnya diverifikasi.
•
Analisis
Kronologis: Pendekatan ini menetapkan semua hal yang telah terjadi di garis
waktu. Hal ini jelas untuk melihat apa yang telah terjadi dan memungkinkan
fokus pada bagian penting dari timeline.
•
Brainstorming:
Mengumpulkan bersama-sama individu kunci yang terlibat dengan masalah di satu
tempat dan memetakan semua kemungkinan penyebab (dan aktivitas korektif
potensial). Sesi tersebut harus di bawah kendali manajer masalah.
•
analisis
nilai sakit: Teknik ini berguna untuk mengidentifikasi masalah mana yang harus
ditangani agar yang. Sakit untuk bisnis dapat didefinisikan dalam sejumlah cara
yang berbeda, misalnya jumlah pengguna yang terkena dampak atau potensi
kerugian keuangan. analisis nilai sakit menyediakan kerangka kerja untuk
memutuskan masalah sebenarnya menyakiti organisasi paling, sehingga sumber daya
yang dialokasikan di mana mereka yang paling dibutuhkan.
•
Analisis
Pareto: Prinsip Pareto sering disebut sebagai '80 -20 Rule '. aturan menyatakan
bahwa untuk banyak peristiwa, sekitar 80 persen dari efek berasal dari hanya 20
persen dari penyebab. Aturan ini dapat digunakan dalam pengelolaan masalah
untuk menargetkan penyebab (masalah) yang bertanggung jawab untuk sebagian
besar insiden.
•
Workarounds:
Kadang-kadang sebelum perbaikan permanen dapat ditemukan, workarounds
diidentifikasi. Hal ini sering terjadi selama penyelidikan masalah dan tahap
diagnosis. Workarounds cara memulihkan layanan yang dapat digunakan tanpa
memahami akar penyebab. Sebuah contoh nyata dan sering digunakan adalah
pengguna yang menemukan bahwa layar mereka telah 'beku'. Mungkin ada sejumlah
penyebab, tetapi langkah pertama, yang cukup sering memecahkan masalah,
biasanya untuk mematikan PC dan kemudian mengubahnya kembali lagi.
Soal catatan harus tetap terbuka ketika solusi telah
diidentifikasi dan solusi yang harus rinci dalam catatan masalah. perbaikan
permanen masih harus berkembang. Namun, mungkin ada alasan mengapa workarounds
tetap di tempat untuk beberapa waktu. Alasan-alasan ini meliputi:
•
memperbaiki permanen terlalu berisiko;
•
memperbaiki permanen terlalu mahal;
•
dampak bisnis dari masalah adalah tidak cukup signifikan untuk membenarkan
diagnosis lebih lanjut saat ini;
•
masalah akan secara permanen ditetapkan oleh rilis baru yang sedang direncanakan.
•
Meningkatkan
rekor error dikenal: Database Kesalahan dikenal merupakan sumber informasi yang
penting untuk meja layanan dan dukungan kelompok penanganan insiden dan
masalah. Sebuah catatan kesalahan diketahui harus ditingkatkan ketika diagnosis
telah selesai dan terutama ketika solusi telah diidentifikasi.
DIKENAL
ERROR
Sebuah kesalahan dikenal adalah masalah yang
memiliki akar penyebab didokumentasikan dan solusi. kesalahan diketahui dibuat
dan dikelola di seluruh siklus hidup mereka dengan manajemen masalah. kesalahan
diketahui juga dapat diidentifikasi oleh pembangunan atau pemasok.
•
penyelesaian
masalah: Setelah memperbaiki permanen telah diidentifikasi, harus dilaksanakan
sesegera mungkin. Namun, mungkin ada alasan yang baik untuk tidak melakukan hal
ini segera. Alasan serupa dengan alasan mengapa organisasi hidup dengan
workarounds dan termasuk biaya dan risiko. Selain itu, memperbaiki segera
mungkin memerlukan pemadaman layanan yang tidak dibenarkan dalam jangka pendek.
Permintaan untuk perubahan (RFC) harus ditingkatkan dan berkembang untuk setiap
perubahan yang diperlukan diidentifikasi.
•
Masalah
penutupan: masalah catatan harus ditutup setelah perubahan telah berhasil
diterapkan. Adalah penting bahwa catatan masalah tetap terbuka sampai dapat
dipastikan bahwa masalah telah diselesaikan. Memeriksa bahwa masalah telah
diselesaikan harus dilakukan dengan pengujian. Mungkin diperlukan beberapa
waktu untuk memastikan bahwa memperbaiki telah berhasil, misalnya mungkin pada
saat proses tertentu digunakan seperti akhir hari, akhir bulan, akhir kuartal,
akhir tahun atau akhir tahun pajak.
•
Ulasan
masalah besar: Setiap kali masalah besar telah terjadi, review masalah utama
harus dilakukan. Setiap organisasi akan memiliki definisi sendiri dari masalah
utama berdasarkan dampak dan urgensi. Sangat penting bahwa ulasan ini melihat
pelajaran daripada menjadi 'alokasi menyalahkan' sesi. Output dari tinjauan
masalah besar harus mencakup apa yang baik, apa yang buruk, apa yang bisa
dilakukan lebih baik di masa depan, bagaimana bisa masalah dicegah dan
bagaimana bisa dampak dari masalah telah berkurang.
PROAKTIF
MANAJEMEN MASALAH
Hal ini jelas lebih baik bagi setiap organisasi
untuk mencegah insiden terjadi daripada menunggu mereka terjadi dan kemudian
melakukan sumber daya untuk memperbaiki mereka, sering berulang dari waktu ke
waktu. Ini adalah prinsip dasar jaminan kualitas, sebagai lawan kontrol
kualitas, dan itu tidak hanya baik untuk bisnis dan penggunanya tetapi juga lebih
efisien untuk IT. Oleh karena itu masalah manajemen adalah salah satu proses
yang paling penting dalam membantu mengurangi jumlah waktu staf TI menghabiskan
'pemadam kebakaran', terutama untuk tim baris kedua dan ketiga yang berperan
utama adalah terkait dengan proyek pekerjaan perbaikan dan untuk siapa bereaksi
terhadap insiden adalah tidak diinginkan gangguan.
In operating
proactively, problem management often works closely with both the availability
management process and continual service improvement since each of these
aspects has similar objectives, namely to protect the IT environment from
disruption and improve services wherever it is cost-effective to do so.
Proactive activities can include analysing trends
associated with historic incidents to identify and eliminate underlying
infrastructure or application weaknesses. Proactive work may be initiated from
a service improvement plan that has been created perhaps in response to poor
performance or simply from a wish to improve performance, for instance in a
competitive situation to gain an advantage over another service provider.
HUBUNGAN
DENGAN PROSES MANAJEMEN LAYANAN LAINNYA
Ada koneksi yang sangat erat antara manajemen
masalah dan manajemen insiden. Juga, manajemen masalah perlu bekerja sama dengan
proses pelayanan transisi dari manajemen perubahan, manajemen konfigurasi dan
rilis dan manajemen penyebaran.
Informasi tentang masalah dan kesalahan yang dikenal
akan datang dari proses seperti manajemen ketersediaan, kapasitas manajemen dan
manajemen kontinuitas layanan IT. Sisi proaktif manajemen masalah memiliki
hubungan dekat dengan kedua peningkatan pelayanan yang terus-menerus dan
manajemen ketersediaan. manajemen keuangan dan manajemen tingkat layanan
menyediakan beberapa biaya dan layanan pedoman yang manajemen masalah menganut.
Metrik
Metrik harus diletakkan di tempat untuk mengukur
efektivitas dan efisiensi proses manajemen masalah. Metrik harus mencakup:
• persentase masalah diselesaikan dalam rentang
waktu yang ditetapkan dalam SLA;
• biaya rata-rata menyelesaikan masalah;
• persentase masalah utama di mana ulasan besar
masalah telah dilakukan;
• persentase tindakan dari selesai ulasan masalah
utama yang telah selesai;
• jumlah kesalahan yang dikenal diidentifikasi.
Jumlah sebenarnya masalah yang diidentifikasi selama
periode ini berguna untuk memberikan indikasi skala masalah dan sumber daya
yang diperlukan, tapi sendiri itu bukan ukuran efektivitas atau efisiensi
proses.
PERAN
Peran utama adalah bahwa manajer masalah. Manajer
masalah bertanggung jawab untuk masalah manajemen dalam organisasi. organisasi
besar akan memiliki tim manajer masalah. Adalah penting bahwa manajer masalah
bisa memanggil staf dari berbagai kelompok dukungan ketika menangani masalah.
TANTANGAN
Manajemen insiden berfokus pada memulihkan layanan
secepat mungkin sementara manajemen masalah berkaitan dengan: memastikan dan
menghilangkan akar penyebab satu atau lebih insiden.
Kedua proses bekerja sama. Namun, ada dapat di kali
menjadi ketegangan antara proses manajemen insiden dan manajemen masalah.
Sering penyelidikan masalah dan tahap diagnosis
dapat memakan waktu. Jika manajemen insiden memiliki solusi cepat untuk
memulihkan layanan, mereka akan ingin menggunakannya. Ini mungkin tidak
membantu manajemen masalah yang perlu memahami akar penyebab. Masalah manajemen
mungkin memerlukan pemadaman atau untuk mengambil 'dump' data yang lagi mungkin
bertentangan dengan manajemen insiden berjuang untuk mendapatkan layanan
kembali berjalan secepat mungkin.
Tantangan lainnya:
• memastikan bahwa insiden dan masalah alat-alat
yang kompatibel dan berkomunikasi satu sama lain; • memahami dampak bisnis yang
nyata dari masalah.
PERTANYAAN UJI UNTUK BAB 27
SO 02, SO 06, SO 12, SO 13, SO 18
Ø IT
OPERATIONS MANAGEMENT (SO 6.5)
PENDAHULUAN DAN RUANG LINGKUP
manajemen operasi
adalah fungsi dan bukan proses. Hal ini bertanggung jawab untuk mengoperasikan
infrastruktur TI organisasi dan aplikasi
sehari-hari. Infrastruktur TI dan aplikasi mendukung layanan organisasi.
MAKSUD DAN TUJUAN
Pengiriman layanan
stabil dengan tidak tersedianya diminimalkan adalah tujuan utama. manajemen
operasional TI adalah fungsi yang menjamin bahwa semua infrastruktur TI organisasi dan aplikasi yang dikelola dan
dipelihara pada sehari-hari untuk memberikan tingkat yang disepakati layanan
KUNCI KEGIATAN
Manajemen operasi
terdiri dari dua bagian :
·
operasi kontrol: bertanggung jawab untuk melaksanakan
kegiatan operasional setiap hari. Hal ini mencakup monitoring yang
infrastruktur dan aplikasi dan merespon peristiwa, insiden dan masalah.Lebih
khusus lagi tugas termasuk penjadwalan pekerjaan, bantuan dan mengembalikan,
konsol manajemen, cetak dan output manajemen serta melakukan kegiatan
pemeliharaan untuk teknis manajemen tim dan aplikasi manajemen tim.
·
Fasilitas manajemen : manajemen bertanggung jawab atas
pengelolaan lingkungan fisik sehari hari. Ini biasanya akan mencakup tanggung
jawab atas pusat data, ruang server serta pemulihan ruang dan situs. Kekuatan
penawaran dan back-up listrik juga akan dalam lingkup.Jika setiap bagian fisik
dari lingkungan subkontrak, maka manajemen fasilitas lengan itu manajemen
operasi yang akan bertanggung jawab untuk hari-hari pengelolaan kontrak dan
hubungan dengan penyedia.Hal ini penting karena itu manajemen operasi terlibat
pada waktu yang tepat di seluruh sistem pengelolaan pelayanan yang tepat dengan
cara.
Lebih khusus lagi,
·
strategi pelayanan: IT manajemen operasi akan memiliki
pemahaman mendalam tentang bagaimana teknologi saat ini digunakan untuk
memberikan layanan yang ada. Pemahaman ini, bersama-sama dengan kesadaran baru
dan teknologi, memungkinkan TI manajemen operasi untuk memiliki masukan yang
berarti ke fase strategi siklus hidup manajemen pelayanan. Sangat penting bahwa
mereka yang bertanggung jawab untuk strategi menggunakan pengetahuan yang
tersedia tentang bagaimana layanan yang benar-benar disampaikan pada sehari-hari.
·
Desain Layanan: Melaksanakan kegiatan yang ditetapkan
dalam tahap desain layanan adalah tanggung jawab manajemen operasional TI. Oleh
karena itu, penting bahwa manajemen
operasional TI memiliki kemampuan untuk input ke tahap ini.
·
Layanan transisi: Pengujian adalah daerah layanan
transisi di mana Anda harapkan IT manajemen operasi untuk terlibat berat. Staf
operasional TI memiliki pengetahuan dan pemahaman tentang lingkungan hidup,
yang memungkinkan mereka untuk memastikan pengujian dengan benar dirancang dan
dilaksanakan. Mungkin saja staf TI operasi, di bawah arahan dari transisi
layanan, yang secara fisik memperkenalkan rilis dengan lingkungan hidup dan
memonitor perkembangan nya.
·
Operasi Layanan: ini adalah tugas mendasar dari manajemen
operasi TI. Mereka menjaga dan memantau komponen (infrastruktur dan aplikasi)
yang mendukung layanan dan bereaksi secara tepat waktu untuk peristiwa,
kejadian dan masalah yang diidentifikasi.
·
Peningkatan Pelayanan: Staf dari manajemen operasional TI
akan selalu mencari cara untuk meningkatkan layanan dan meningkatkan efisiensi
dan efektivitas.
HUBUNGAN DENGAN FUNGSI MANAJEMEN LAYANAN LAINNYA
Mungkin ada tumpang
tindih antara manajemen operasi TI , dan kedua manajemen teknis dan manajemen
aplikasi. Manajemen operasi TI adalah fungsi yang berbeda tetapi biasa untuk
tim dari kedua aplikasi manajemen dan manajemen teknis untuk menjadi bagian
dari fungsi ini. manajemen teknis bertanggung jawab untuk infrastruktur TI
sementara manajemen aplikasi yang bertanggung jawab untuk aplikasi. manajemen
teknis memiliki tanggung jawab yang sama untuk infrastruktur TI sebagai
aplikasi kepada manajemen aplikasi.
Referensi :
