TUGAS KELOMPOK

IT Service Management

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 keuanganPerlu 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;
•  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 :

www.ITIL-officialsite.com.