NAMA: ILHAM RIZKY BAZARAH, RUBEN VAN LUTHER
Dosen: Ega Tassha Perwira
NPM: 1B117086, 1B117110
KELAS:4KA45
RANGKUMAN IT SERVICE MANAGEMENT
A GUIDE FOR ITIL FOUNDATION EXAM CANDIDATES SECOND EDITION
JUDUL : IT SERVICE MANAGEMENT A GUIDE FOR ITIL
PENULIS : Ernest Brewster, Richard Griffiths, Aidan Lawes and John Sansbury
PENERBIT : British Informatics Society
TAHUN : 2012
KATAGORI : IT
BAHASA : INGGRIS
ASET LAYANAN DAN PENGELOLAAN KONFIGURASI
PENDAHULUAN DAN RUANG LINGKUP
Organisasi menginvestasikan sejumlah besar uang dalam peralatan IT dan sumber daya tambahan, yang merupakan aset organisasi. Oleh karena itu, kita perlu menjaga informasi tentang aset-aset tersebut dalam hal sumber, nilai, lokasi, siapa yang mengendalikannya, dll. Ini adalah manajemen aset.
Manajemen konfigurasi melampaui ini dalam memberikan kami informasi tentang hubungan yang ada di antara berbagai komponen. Ini penting untuk solusi manajemen layanan yang efektif karena informasi ini mendukung semua proses lainnya terutama insiden, masalah, ketersediaan, dan manajemen perubahan.
Ketika perubahan diusulkan, informasi konfigurasi yang komprehensif memungkinkan penilaian cepat dan akurat dari dampak perubahan pada layanan dan komponen. Demikian pula, panggilan ke meja layanan dapat disederhanakan jika agen dapat secara otomatis melihat layanan dan sistem apa yang digunakan pemanggil.
MAKSUD DAN TUJUAN
Tujuan dari manajemen aset dan konfigurasi layanan (SACM) adalah untuk:
• mengidentifikasi dan mengendalikan semua hal yang diminati;
• mengelola dan melindungi integritas aset.
Tujuan SACM adalah untuk mendefinisikan dan mengendalikan komponen layanan dan infrastruktur, dan untuk menjaga informasi konfigurasi yang akurat tentang keadaan, layanan dan infrastruktur, komponen historis, terkini, dan terencana.
Manajemen aset mencakup aset layanan di seluruh siklus hidup layanan. Ini menyediakan inventarisasi lengkap aset dan catatan yang bertanggung jawab atas kendali mereka. Ini termasuk manajemen siklus penuh TI dan aset layanan, dari titik akuisisi hingga pemeliharaan hingga pembuangan.
Manajemen konfigurasi menyediakan model konfigurasi layanan, aset, dan infrastruktur dengan merekam hubungan antara aset layanan dan item konfigurasi. Ini memastikan bahwa komponen-komponen diidentifikasi, di-baseline dan dipertahankan dan bahwa perubahan-perubahan pada mereka dikendalikan. Ruang lingkup mencakup antarmuka ke penyedia layanan internal dan eksternal di mana ada aset dan item konfigurasi yang perlu dikontrol (misalnya aset bersama).
SACM mengoptimalkan kinerja aset dan konfigurasi layanan dan oleh karena itu meningkatkan kinerja layanan secara keseluruhan dan meminimalkan biaya dan risiko yang disebabkan oleh aset yang dikelola secara buruk (misalnya pemadaman layanan, denda, biaya lisensi yang salah, dan audit yang gagal).
KONSEP DASAR
Semua informasi yang kami minati akan disimpan dalam repositori yang dikenal sebagai sistem manajemen konfigurasi (CMS) sebagai serangkaian item konfigurasi (CI), yang masing-masing memiliki informasi deskriptif (dikenal sebagai atribut) termasuk data hubungan ke CI lainnya. CMS biasanya akan terdiri dari satu atau lebih konfigurasi manajemen database (CMDB). Secara historis, sering ada kebingungan tentang aspek ini, dengan banyak organisasi berusaha untuk mengembangkan CMDB fisik tunggal ketika itu adalah konsep logis dari repositori, CMS, yang penting.
ITEM KONFIGURASI
Item konfigurasi (CI) adalah komponen apa pun yang perlu dikelola untuk memberikan layanan TI. Informasi tentang setiap CI dicatat dalam catatan konfigurasi dalam sistem manajemen konfigurasi dan dipelihara di seluruh siklus hidupnya oleh aset layanan dan manajemen konfigurasi. CI berada di bawah kendali manajemen perubahan. CI biasanya mencakup layanan TI, perangkat keras, perangkat lunak, bangunan, orang-orang dan dokumentasi formal seperti dokumentasi proses dan SLA.
CI harus dipilih menggunakan kriteria pemilihan yang ditetapkan, dikelompokkan, diklasifikasikan dan diidentifikasi sedemikian rupa sehingga mereka dapat dikelola dan dapat dilacak selama siklus hidup layanan.
Salah satu aspek yang paling menantang dalam membangun manajemen konfigurasi yang efektif adalah menentukan tingkat yang paling tepat di mana CI didefinisikan. Suatu keseimbangan harus dicapai antara memiliki informasi yang cukup untuk benar-benar berguna dan upaya yang terlibat dalam pengumpulan dan pemeliharaan informasi.
Mewakili komponen dan hubungan mereka secara bergambar dapat sangat membantu dalam mencapai pemahaman tentang apa yang diperlukan.
SISTEM MANAJEMEN KONFIGURASI
Sistem manajemen konfigurasi (CMS) adalah seperangkat alat, data, dan informasi yang digunakan untuk mendukung aset layanan dan manajemen konfigurasi. CMS adalah bagian dari sistem manajemen pengetahuan layanan secara keseluruhan dan termasuk alat untuk mengumpulkan, menyimpan, mengelola, memperbarui, menganalisis dan menyajikan data tentang semua item konfigurasi dan hubungannya. CMS juga dapat memasukkan informasi tentang insiden, masalah, kesalahan yang diketahui, perubahan dan rilis. CMS dikelola oleh aset layanan dan manajemen konfigurasi dan digunakan oleh semua proses manajemen layanan TI.
DATABASE MANAJEMEN KONFIGURASI
Sebuah database manajemen konfigurasi (CMDB) menyimpan catatan konfigurasi yang berisi atribut dari CI dan hubungannya. CMS dapat menyertakan satu atau beberapa CMDB.
KONFIGURASI BASELINE
Suatu baseline konfigurasi adalah konfigurasi layanan, produk atau infrastruktur yang telah ditinjau dan disepakati secara resmi, yang setelah itu berfungsi sebagai dasar untuk kegiatan lebih lanjut dan dapat diubah hanya melalui prosedur perubahan formal. Sebuah baseline konfigurasi dapat digunakan untuk memeriksa tonggak pengembangan layanan, sebagai dasar untuk membangun dan perubahan di masa depan, untuk merakit komponen untuk perubahan atau rilis dan untuk menyediakan dasar untuk audit konfigurasi atau back-out.
MANAJEMEN PERUBAHAN
PENDAHULUAN DAN RUANG LINGKUP
Sering dikatakan bahwa satu-satunya konstanta adalah perubahan. Dengan demikian, perubahan harus dirangkul sebagai aspek esensial dan alami dari setiap lingkungan, tetapi perubahan yang tidak dikelola dengan baik dapat menyebabkan kekacauan dalam suatu organisasi. Memang, perubahan yang dikelola dengan buruk disebabkan oleh penyebab utama insiden. Tidak hanya ini menyebabkan gangguan kepada pengguna, itu juga mengarah ke pengerjaan ulang yang seringkali lebih sulit untuk dicapai daripada mendapatkan yang benar awalnya.
CONTOH : Sebuah maskapai besar menderita beberapa hari pergolakan dan malu setelah sistem penyelamatan mereka jatuh dan pelanggan tidak dapat melakukan banyak transaksi. Penyebabnya ditelusuri ke perubahan yang tidak teruji secara memadai ke sistem. Kerugiannya, baik finansial maupun reputasi, cukup besar.
Namun, proses manajemen perubahan tidak boleh dipandang sebagai inhibitor birokrasi yang membuat perubahan sulit untuk diperkenalkan. Sebaliknya itu harus menjadi enabler untuk memungkinkan perubahan yang tepat untuk berjalan semulus mungkin tanpa memandang skala atau kompleksitasnya.
Secara historis, banyak organisasi telah mengalami fragmentasi dan divergensi dalam-seperti penilaian dan otorisasi. Agar benar-benar efektif, diperlukan pendekatan holistik yang umum untuk menangani perubahan.
MAKSUD DAN TUJUAN
Manajemen perubahan memastikan bahwa selaras dengan efisiensi optimal dan gangguan minimum, bekerja kembali dan risiko dengan mempertahankan keselarasan. Tujuan dari proses manajemen perubahan adalah untuk memastikan bahwa semua perubahan dikelola melalui metode dan prosedur standar yang memastikan perubahan efektif, tepat waktu, memenuhi persyaratan yang ditentukan dan dicatat dengan benar dalam sistem manajemen konfigurasi.
Tujuan dari manajemen perubahan adalah untuk memastikan bahwa semua perubahan dicatat dan kemudian dievaluasi, disahkan, diprioritaskan, direncanakan, diuji, diimplementasikan, didokumentasikan dan ditinjau kembali dengan cara yang terkontrol.
Ruang lingkup manajemen perubahan mencakup perubahan pada aset layanan dan item konfigurasi di seluruh siklus hidup layanan. Proses ini membahas semua perubahan di semua tingkatan: strategis, taktis dan operasional. Oleh karena itu, meskipun manajemen perubahan digambarkan dalam volume transisi layanan, banyak perubahan akan terjadi pada tingkat operasional dan relatif kecil.
PERUBAHAN
Perubahan adalah penambahan, modifikasi atau penghapusan apa pun yang dapat memengaruhi layanan TI. Ruang lingkup harus mencakup semua layanan IT, CI, proses, dokumentasi, dll.
Organisasi dapat memilih apakah permintaan dibangkitkan oleh peran atau grup tertentu saja, atau apakah seseorang dalam organisasi dapat melakukannya.
KONSEP DASAR
Permintaan perubahan adalah komunikasi formal yang meminta perubahan ke satu atau lebih CI. Berbagai jenis perubahan yang berbeda mungkin memerlukan jenis permintaan perubahan yang berbeda, masing-masing dengan bentuk dan prosedur khusus (misalnya untuk penilaian dampak dan otorisasi perubahan).
RELEASE AND DEPLOYMENT MANAGEMENT
PENDAHULUAN DAN RUANG LINGKUP
Setelah layanan baru atau diubah telah dikembangkan, kita perlu memasukkannya ke dalam lingkungan hidup, mengaktifkannya, dan memberikan dukungan saat tidur. Paling umum, orang berpikir tentang merilis versi baru perangkat lunak, tetapi konsep ini berlaku sama untuk perangkat keras dan komponen lain seperti dokumentasi. Memang, upgrade besar atau layanan baru akan sering melibatkan kombinasi semua elemen.
Di masa lalu, banyak masalah disebabkan oleh pengembangan yang hanya mengalihkan kontrol ke operasi dalam gerakan 'bersih-istirahat'. Manajemen rilis dan penyebaran berkaitan dengan pembuatan ini proses yang lebih bertahap dan terkontrol, termasuk periode dukungan kehidupan awal untuk memastikan bahwa semuanya berfungsi sebagaimana mestinya dan dapat digunakan oleh bisnis.
Proses pelepasan dan penyebaran yang efektif memerlukan interaksi yang erat antara pengembangan dan operasi, mencegah sindrom 'melemparkannya ke dinding' yang begitu umum di masa lalu.
MAKSUD DAN TUJUAN
Harus ada rencana yang jelas yang memungkinkan bisnis untuk menyelaraskan kegiatannya dengan mereka dan setiap orang harus puas dengan mekanisme yang digunakan.
Manajemen rilis dan penyebaran bertujuan untuk membangun, menguji dan memberikan layanan baru atau diubah dengan sukses ke dalam lingkungan produksi dalam skala waktu yang diperlukan dan dengan gangguan minimal terhadap layanan yang ada.
Tujuannya adalah untuk memastikan bahwa paket rilis yang konsisten dan integral dikerahkan sesuai dengan kebijakan yang disepakati dan dengan rencana yang disepakati dengan pelanggan dan pemangku kepentingan, dan bahwa ini terjadi di bawah kendali penuh dan efektif. Setiap perubahan bisnis dan proses bisnis terkait, termasuk pelatihan dan transfer keterampilan, harus dikelola untuk berlangsung dalam skala waktu yang diselaraskan dengan jadwal rilis.
Tujuannya adalah untuk memastikan bahwa ada rencana konsisten yang jelas yang dipahami dan diikuti setiap orang, bahwa rilis dikelola secara efisien dan efektif melalui penyebaran dan penggunaan dan bahwa layanan baru dan pendukung
sistem mampu dioperasikan dengan sukses dan memberikan persyaratan layanan yang disepakati (utilitas dan garansi).
Ruang lingkup rilis dan manajemen penyebaran mencakup proses, sistem dan fungsi yang diperlukan untuk mengemas, membangun, menguji, dan menyebarkan rilis ke dalam produksi sesuai dengan paket desain layanan (SDP). Ini termasuk serah terima ke tahap siklus hidup operasi layanan.
Manajemen rilis dan penyebaran yang efektif menambah nilai dengan memastikan bahwa konsumen dan pengguna dapat menggunakan layanan baru atau yang diubah dengan cara yang mendukung bisnis, dan dengan memberikan perubahan lebih cepat dan dengan biaya optimal dan risiko minimal. Pembebasan dan penyebaran yang terencana dan dilaksanakan dengan baik dapat membuat perbedaan yang signifikan terhadap biaya layanan organisasi dengan meminimalkan pemecahan masalah dan pengerjaan ulang.
KONSEP DASAR
Dua aspek konstituen dari proses ini adalah rilis dan penyebaran.
RELEASE
Rilis adalah satu atau lebih perubahan pada layanan TI yang dibuat, diuji, dan disebarkan bersama. Rilis tunggal dapat mencakup perubahan pada perangkat keras, perangkat lunak, dokumentasi, proses, dan komponen lainnya.
DEPLOYMENT
Deployment adalah kegiatan yang bertanggung jawab atas pergerakan perangkat keras, perangkat lunak, dokumentasi, proses, dll. Baru ke lingkungan hidup.
Konsep utama adalah unit rilis (yaitu komponen layanan yang biasanya dirilis bersama). Unit rilis biasanya mencakup komponen yang cukup untuk melakukan fungsi yang bermanfaat. Misalnya, satu unit pelepasan mungkin adalah PC desktop, termasuk perangkat keras, perangkat lunak, lisensi, dokumentasi, dll. Mungkin ada unit standar untuk peran atau departemen yang berbeda, atau desktop dapat dikustomisasi untuk setiap merekrut baru (di mana setiap instance terpisah lepaskan unit). Unit rilis lain mungkin aplikasi lengkap, termasuk operasi TI dan pelatihan pengguna.
Ada kemungkinan bahwa rilis akan terdiri dari lebih dari satu unit rilis. Paket rilis adalah satu atau beberapa unit rilis yang diperlukan untuk mengimplementasikan layanan baru atau yang diubah.
Kebijakan rilis harus didefinisikan sebagai bagian dari kontrol manajemen atas rilis. Bahkan, tidak mungkin organisasi akan memiliki kebijakan pembebasan tunggal; ini lebih
cenderung memiliki beberapa, masing-masing mencakup satu atau lebih layanan. Setiap kebijakan harus mencakup Identifikasi, peran dan tanggung jawab, frekuensi yang diharapkan, mengubah kriteria penerimaan, otomatisasi, verifikasi konfigurasi, kriteria masuk dan keluar melalui fase, dan serah terima dari dukungan kehidupan awal ke operasi.
AKTIVITAS, METODE, DAN TEKNIK
• Rilis dan perencanaan penyebaran: Dimulai setelah manajemen perubahan mengesahkan perencanaan rilis.
• Rilis dan uji coba: Paket rilis dibuat dan diuji dan kemudian dipindahkan ke perpustakaan media definitif (DML) dalam kesiapan untuk penyebaran ke dalam lingkungan hidup.
• Deployment: Paket rilis dikerahkan dari DML ke dalam lingkungan hidup.
• Tinjau dan tutup: Apakah rilis tersebut berfungsi sebagaimana yang diharapkan dan memenuhi persyaratan antisipasi?
TANTANGAN
Tantangan yang akan dihadapi organisasi saat menentukan kebijakan yang tepat dan menerapkan rilis dan penyebaran yang efektif meliputi:
• menetapkan metrik kinerja standar untuk semua transisi;
• berurusan dengan proyek yang tidak akurat atau tanggal pengiriman pemasok;
• memahami semua perspektif pemangku kepentingan;
• memahami risiko;
• mengambil pendekatan pragmatis terhadap tantangan pengiriman.
HUBUNGAN DENGAN PROSES MANAJEMEN LAYANAN LAINNYA
Antarmuka kunci meliputi:
Ubah manajemen
Semua rilis didorong oleh RFC resmi.
Pengelolaan aset dan konfigurasi layanan
Memberikan masukan untuk komponen selama pembuatan dan pemutakhiran selama fase-fase berbeda dari rilis dan penyebaran.
Manajemen insiden
Khususnya selama dukungan kehidupan awal ketika perhatian ekstra dan sumber daya mungkin diperlukan.
Pengelolaan kontinuitas layanan TI
Rencana kontinuitas harus diperbarui untuk mencerminkan layanan baru atau yang diubah.
Manajemen kapasitas
Sumber daya baru mungkin diperlukan atau beban pada yang sudah ada diubah.
Koordinasi desain layanan
Rilis dan penyebaran berkontribusi pada penciptaan paket desain layanan dan pada akhirnya menggunakan ini sebagai input kunci untuk rilis dan aktivitas penyebaran.
Perencanaan dan dukungan transisi
Menyediakan kerangka kerja rilis dan penyebaran dan konteks.
METRICS
Berikut ini adalah beberapa metrik untuk menilai keefektifan solusi:
• Perbedaan dalam kinerja layanan terhadap yang diminta oleh pelanggan (harus minimal dan mengurangi).
• Jumlah insiden yang tercatat terhadap layanan (harus rendah dan berkurang).
• Peningkatan kepuasan pelanggan dan pengguna dengan layanan yang diberikan.
• Mengurangi ketidakpuasan pelanggan yang disebabkan oleh layanan yang jarang diuji dan disebarkan.
• Mengurangi insiden dan masalah dalam penyebaran dan produksi.
• Mengurangi perbedaan antara data terdaftar di CMS dan dunia nyata.
PERAN
Kemasan rilis dan tanggung jawab manajer desain meliputi:
• membuat konfigurasi rilis final dan membangun rilis final;
• menguji rilis dan mempublikasikan kesalahan dan solusi yang diketahui.
• Tanggung jawab manajer penerapan termasuk:
• merencanakan, menjadwalkan, dan mengendalikan pergerakan pelepasan untuk diuji dalam lingkungan hidup;
• memastikan integritas lingkungan hidup terlindungi dan komponen yang benar dilepaskan.
SERVICE DESK
PENDAHULUAN DAN RUANG LINGKUP
Service Desk adalah fungsi dan bukan proses. Fungsi adalah sekelompok orang yang melakukan proses atau proses tertentu. Service Desk biasanya melakukan sejumlah proses, khususnya manajemen insiden dan pemenuhan permintaan.
Service Desk terdiri dari sekelompok staf yang dilatih untuk menangani acara layanan. staf service desk akan memiliki akses ke alat yang diperlukan untuk mengelola acara-acara ini.
Untuk sebagian besar pengguna TI dalam suatu organisasi, service desk akan menjadi satu-satunya kontak mereka dengan Departemen IT. Oleh karena itu, kesan yang dibuat oleh service desk dalam penanganan acara akan memiliki pengaruh besar pada bagaimana Departemen TI secara keseluruhan dilihat dalam organisasi itu.
MAKSUD DAN TUJUAN
Tujuan utama dari SERVICE DESK adalah untuk memulihkan layanan secepat mungkin (manajemen insiden) dan untuk memenuhi permintaan layanan secara efisien dan efektif (permintaan pemenuhan).
KONSEP DASAR
Metode menghubungi meja layanan
Secara tradisional, sebagian besar pengguna TI telah menghubungi SERVICE DESK mereka melalui telepon. Namun, ada berbagai metode melakukan kontak dengan SERVICE DESK:
• Telephone;
• Web interface;
• Automated alert;
• Email;
• Pager;
• Personal contact.
Struktur SERVICE DESK
SERVICE DESK dapat disusun dalam beberapa cara. Struktur harus didorong oleh sifat bisnis yang didukung. Faktor-faktor seperti profil keterampilan pengguna dan lokasi geografis pengguna akan mempengaruhi struktur.
REQUEST FULFILMENT (Permintaan Permintaan)
PENDAHULUAN DAN RUANG LINGKUP
Permintaan pemenuhan adalah proses yang melakukan permintaan layanan dari pengguna. Ini mencakup permintaan perubahan standar, permintaan untuk informasi dan keluhan. Dari sudut pandang layanan meja, proses pemenuhan permintaan cenderung untuk menutup semua panggilan yang bukan insiden. Setel ulang kata sandi dan pertanyaan tentang mendapatkan perangkat lunak tambahan adalah beberapa permintaan volume yang lebih tinggi.
Permintaan biasanya bervolume tinggi, tetapi risiko rendah dan biaya rendah. Proses terpisah yang berbeda di tempat untuk menghindari kebingungan dengan penanganan insiden yang meja layanan juga melakukan.
MAKSUD DAN TUJUAN
Tujuan dari proses ini adalah untuk tindakan permintaan layanan secara efektif dan efisien. Permintaan pemenuhan memungkinkan pengguna untuk mendapatkan informasi dan menyelesaikan perubahan standar secepat mungkin.
PERMINTAAN LAYANAN
Permintaan layanan adalah permintaan dari pengguna untuk mendapatkan informasi, saran, untuk perubahan standar atau untuk akses ke layanan TI.
PERUBAHAN STANDAR
Perubahan standar adalah perubahan yang disetujui sebelumnya yang berisiko rendah, relatif umum dan mengikuti prosedur atau instruksi kerja.
MODEL PERMINTAAN
Dimana volume tinggi dari permintaan yang sama atau serupa diharapkan, model proses dapat didefinisikan untuk menstandardisasi kegiatan yang akan dilakukan. Adopsi model permintaan akan merampingkan 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 pemenuhan permintaan untuk memastikan bahwa volume, beban kerja dan penggunaan sumber daya sepenuhnya dipahami.
Manajemen Perubahan
Jika model permintaan terkait dengan perubahan standar, akan ada persetujuan yang diperlukan dari manajemen perubahan yang akan mempertimbangkan masalah manajemen keuangan
MANAJEMEN INSIDEN
PENDAHULUAN DAN RUANG LINGKUP
Manajemen insiden adalah proses untuk menangani semua insiden. Ini mungkin insiden di mana layanan sedang terganggu atau insiden di mana layanan belum terganggu.
Nilai manajemen insiden untuk bisnis adalah bahwa sumber daya dialokasikan untuk meminimalkan dan mengurangi dampak insiden dan ketidaktersediaan layanan sesuai dengan prioritas bisnis. Tingkat insiden yang lebih rendah dan waktu resolusi yang lebih cepat akan memungkinkan layanan berjalan sebagaimana dimaksud.
Selama penanganan insiden, meja layanan mungkin dapat mengidentifikasi peningkatan baik dalam proses bisnis maupun teknis. Meja layanan sering memiliki posisi yang unik dalam organisasi karena stafnya dapat mengambil pandangan holistik tentang bagaimana organisasi beroperasi, memungkinkan praktik yang baik untuk disebarkan dan praktik buruk untuk diberantas.
KONSEP DASAR
KEJADIAN
Insiden adalah gangguan yang tidak direncanakan pada layanan TI atau penurunan kualitas layanan TI. Kegagalan item konfigurasi yang belum memengaruhi layanan juga merupakan insiden.
• Timescales: Timescales untuk penanganan insiden dan pemicu untuk eskalasi harus disetujui dan didokumentasikan dalam SLA. Kinerja terhadap SLA kemudian dapat diukur dan dilaporkan. Alat dapat dikonfigurasi untuk mengaktifkan eskalasi otomatis sesuai dengan rentang waktu yang disepakati.
• Insiden model: Adopsi model insiden adalah metode standarisasi dan otomatisasi, jika mungkin, pendekatan terhadap kelompok insiden serupa. Model insiden adalah serangkaian langkah yang ditetapkan untuk dilakukan. Rincian model insiden dapat dimasukkan ke dalam alat penanganan insiden (s).
• Insiden besar: Organisasi yang berbeda akan memiliki definisi yang berbeda untuk apa yang merupakan insiden besar. Untuk beberapa organisasi, pemicu untuk 'menelepon' insiden besar adalah ketika sejumlah pengguna tertentu telah terkena dampak. Untuk organisasi lain, pemicu dapat berupa kerugian finansial aktual atau potensial dari hilangnya layanan. Jika kerugian finansial aktual atau potensial melebihi jumlah tertentu, insiden itu menjadi besar. Untuk beberapa area bisnis di beberapa industri, mungkin ada risiko cedera atau korban jiwa jika layanan tertentu tidak tersedia. Sekali lagi, ini mungkin menjadi pemicu untuk insiden menjadi besar. Kerusakan reputasi organisasi dapat menjadi pemicu lain.
Organisasi yang lebih besar mungkin telah mendedikasikan tim manajemen insiden besar yang tersedia 24/7 yang mengendalikan insiden yang telah ditetapkan utama. Salah satu peran penting yang dilakukan oleh manajer insiden besar adalah untuk melindungi mereka (sering manajemen operasi TI, manajemen teknis dan staf manajemen aplikasi) yang mencoba untuk memulihkan layanan dari tuntutan komunikasi yang dibuat pada mereka. Selama insiden besar, akan ada banyak permintaan dan permintaan pembaruan yang perlu dikelola. Tim manajemen insiden besar akan menetapkan rute untuk komunikasi dan eskalasi (baik fungsional maupun hierarkis).
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 masih harus dicatat, tetapi fokusnya adalah pada pemulihan layanan secepat mungkin dengan gangguan minimal.
KEGIATAN UTAMA
Alur proses manajemen insiden
Aliran proses manajemen insiden diilustrasikan pada Gambar 26.1 dan berisi langkah-langkah berikut:
• Masukan untuk proses: Insiden dapat dideteksi dan dilaporkan dengan berbagai cara. Pengguna akan menghubungi meja layanan untuk melaporkan insiden. Staf teknis dapat mencatat insiden atau rincian email tentang suatu insiden yang telah mereka identifikasi ke meja layanan. Semakin banyak insiden dibangkitkan melalui antarmuka web. Proses pengelolaan acara juga akan melaporkan insiden dengan pemantauan.
• Identifikasi insiden: Bekerja untuk memahami dan menyelesaikan insiden tidak dapat dimulai sebelum insiden diidentifikasi. Untuk alasan ini, pemantauan komponen yang membentuk layanan utama sangat penting. Insiden dapat diidentifikasi dengan berbagai cara oleh pengguna, staf teknis dan dengan pemantauan.
• Insident logging: Semua insiden harus dicatat dengan tanggal dan waktu yang direkam. Pada tahap ini, informasi yang diperlukan untuk mengelola insiden akan dicatat. Ini akan mencakup nomor referensi unik, deskripsi gejala, layanan atau CI berdampak, dampak, urgensi dan nama orang yang membesarkan insiden atau metode meningkatkan insiden.
• Kategorisasi insiden: Kode kategorisasi yang cocok akan dialokasikan. Sebagai contoh, ini mungkin perangkat keras atau perangkat lunak dengan sub-kode untuk kategorisasi tingkat yang lebih rendah. Kategorisasi yang akurat penting karena akan memungkinkan metrik berguna untuk dikumpulkan menyoroti bidang infrastruktur di mana insiden terjadi.
• Prioritas insiden: Prioritas insiden didasarkan pada dampak dan urgensi. Dampak adalah 'rasa sakit' bagi bisnis. Dampak mungkin terkait dengan jumlah pengguna yang terkena dampak, potensi kerugian finansial bagi organisasi, risiko pelanggaran peraturan peraturan atau legislatif atau, untuk beberapa layanan, risiko kehilangan nyawa. Urgensi berkaitan dengan seberapa cepat bisnis mengharuskan insiden itu diselesaikan.
Waktu resolusi target akan dialokasikan ke setiap tingkat prioritas. Ini akan disetujui oleh bisnis dan dicatat dalam SLA.
• Diagnosis awal: Jika insiden telah dinaikkan oleh panggilan ke meja layanan, maka itu akan menjadi meja layanan yang melakukan diagnosis awal, biasanya ketika pengguna masih di telepon. Ketersediaan skrip diagnosa akan membantu seperti kemampuan untuk mencocokkan dengan masalah dan kesalahan yang diketahui. CMDB juga dapat dikonsultasikan pada tahap ini.
• Eskalasi insiden: Eskalasi dapat bersifat fungsional atau hierarkis.
• Eskalasi fungsional terjadi ketika meja layanan tidak dapat menyelesaikan insiden atau di mana insiden belum diselesaikan dalam waktu resolusi tar. Meja layanan akan melibatkan dukungan tingkat kedua, yang memiliki pengetahuan teknis yang lebih spesifik. Pengalihan fungsi lebih lanjut dapat terjadi melalui siklus hidup insiden hingga dukungan tingkat ketiga, yang dapat menjadi bagian dari organisasi atau pihak ketiga seperti pemasok. Penting untuk diingat bahwa kepemilikan insiden selalu berada di meja layanan terlepas dari area pendukung lain mana yang bekerja pada resolusi.
• Eskalasi hirarkis meningkatkan profil insiden khusus dalam organisasi TI dan juga di dalam area bisnis. Staf TI yang lebih senior dapat memberikan fokus dan sumber daya, tetapi kepemilikan insiden akan disimpan oleh meja layanan. Organisasi akan memiliki pemicu yang menunjukkan kapan eskalasi hirarkis diperlukan. Ini mungkin untuk semua insiden 'Prioritas 1' atau ketika insiden dengan prioritas tertentu belum diselesaikan dengan skala waktu target. Pemicu untuk eskalasi akan dicatat dalam SLA yang relevan dan harus disorot oleh alat pendukung yang digunakan. Meja layanan akan terus memberi informasi kepada pengguna tentang semua eskalasi fungsional atau hierarkis yang terjadi selama siklus hidup suatu insiden dan pada saat yang sama catatan insiden akan diperbarui.
• Investigasi dan diagnosis: Dalam fase siklus hidup insiden ini, pekerjaan dilakukan oleh meja layanan atau area pendukung untuk memahami apa yang harus dilakukan untuk memulihkan layanan. Ini sering merupakan bagian yang paling memakan waktu dari proses meskipun dapat dipercepat menggunakan skrip diagnostik dan dengan referensi untuk insiden dan masalah lain serta database kesalahan yang diketahui.
• Resolusi dan pemulihan: Tahap investigasi dan diagnosis akan sampai pada resolusi. Ini perlu diterapkan dan kemudian pengujian perlu dilakukan untuk memastikan bahwa insiden tersebut telah diselesaikan dan layanan dipulihkan. Mungkin ada jeda waktu antara perbaikan yang diterapkan dan layanan berjalan normal lagi (mis. Mungkin ada backlog pemrosesan untuk mengejar ketinggalan). Pada kesempatan lain, mungkin tidak mungkin untuk memastikan apakah perbaikan telah bekerja untuk jangka waktu tertentu (misalnya jika masalah asli adalah dengan proses akhir bulan). Terlepas dari di mana resolusi telah diberlakukan atau yang terlibat, insiden itu harus diteruskan kembali ke meja layanan untuk penutupan.
• Insiden penutupan: Hanya meja layanan harus menutup insiden. Perlu persetujuan pengguna bahwa insiden telah diselesaikan. Semua dokumen insiden harus diselesaikan sebelum penutupan dan kategori penutupan dialokasikan untuk memungkinkan metrik yang berarti untuk diproduksi. Survei kepuasan pengguna harus dilakukan untuk persentase insiden yang disepakati (dalam SLA). 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 hubungan yang kuat dengan manajemen perubahan. Perubahan sering diterapkan untuk menyelesaikan insiden atau sejumlah insiden dan, sayangnya, perubahan yang tidak benar-benar melakukan apa yang seharusnya dilakukan dapat menyebabkan insiden. Pengelolaan aset dan konfigurasi layanan menyediakan informasi yang dibutuhkan untuk mengelola insiden. Manajemen tingkat layanan akan memberikan waktu resolusi target bersama dengan kriteria eskalasi.
MANAJEMEN PROBLEM (MASALAH)
PENDAHULUAN DAN RUANG LINGKUP
Manajemen masalah bertanggung jawab atas pengelolaan semua masalah dalam infrastruktur TI. Proses ini mencakup analisis akar masalah dan sampai pada pemecahan masalah. Manajemen masalah tetap bertanggung jawab hingga resolusi diimplementasikan melalui manajemen perubahan dan manajemen pembebasan.
Manajemen masalah memberikan nilai bagi organisasi dengan menghindari, mengurangi dan mengurangi dampak bisnis yang merugikan dari masalah. Ini memungkinkan layanan menjadi lebih tersedia dan menjadi lebih kuat.
MAKSUD DAN TUJUAN
Tujuan manajemen masalah adalah:
• untuk mencegah masalah dan mengakibatkan insiden terjadi;
• untuk menghentikan insiden berulang yang terjadi;
• untuk mengurangi dan mengurangi dampak buruk dari insiden yang tidak dapat dicegah.
Manajemen masalah, seperti kebanyakan proses, memiliki aspek reaktif dan proaktif. Dari perspektif reaktif, tujuan dari proses ini adalah untuk mengelola siklus masalah dari identifikasi hingga eliminasi dengan menentukan akar penyebab dan kemudian menerapkan perubahan yang diperlukan untuk mencegah kekambuhan. Dari perspektif yang proaktif, tujuan dari proses ini adalah untuk mencegah insiden di masa mendatang sedapat mungkin atau mengurangi dampak dari insiden-insiden yang tidak dapat dicegah.
Model masalah
Model masalah adalah ide yang mirip dengan model insiden. Model masalah menyediakan pendekatan standar untuk mengatasi masalah.
Perbedaan antara reaktif dan proaktif
Ada dua bagian dari manajemen masalah. Manajemen masalah reaktif merespon insiden dan masalah yang terjadi. Sisi proaktif dari manajemen masalah berkaitan dengan mencegah insiden dan masalah yang terjadi. Manajemen masalah proaktif sering dipicu oleh peningkatan layanan berkelanjutan.
Alur proses manajemen masalah
Alur proses manajemen masalah diilustrasikan pada Gambar 27.1 dan berisi langkah-langkah berikut:
• Masukan ke proses: Masukan ke manajemen masalah dapat berasal dari sejumlah sumber. Ini termasuk manajemen insiden, manajemen acara dan meja layanan. Selain itu, manajemen masalah proaktif dapat mengidentifikasi masalah. Pemasok dan proses lain seperti manajemen pelepasan, manajemen kapasitas dan manajemen ketersediaan juga dapat menjadi sadar akan masalah.
• Deteksi masalah: Masalah dapat dideteksi dengan banyak cara. Meja layanan mungkin percaya bahwa satu atau lebih insiden disebabkan oleh masalah tertentu. Area pendukung lini kedua dapat mengidentifikasi masalah ketika melakukan penanganan insiden. Masalah juga dapat dideteksi secara otomatis oleh alat manajemen layanan yang digunakan. Manajemen masalah proaktif akan mengidentifikasi masalah sering sebelum insiden terjadi. Demikian juga, proses lain seperti manajemen rilis dan manajemen ketersediaan akan menjadi sadar akan masalah.
• Masalah pencatatan: Sangat penting bahwa rincian lengkap masalah dicatat. Ini akan memungkinkan analisis dilakukan dan akan memungkinkan perbandingan dibuat antara masalah. Semua insiden yang disebabkan oleh masalah harus dikaitkan dengan catatan masalah yang memungkinkan lingkup dan skala dampak yang akan dipastikan secara mudah. Tanggal dan waktu semua masalah dicatat harus dicatat dalam catatan masalah.
• Kategorisasi masalah: Penting untuk mengkategorikan masalah dan direkomendasikan bahwa sistem yang sama digunakan sebagaimana diadopsi oleh insiden tersebut
• Soal prioritas: Masalah harus diprioritaskan dengan cara yang sama seperti insiden.
Target waktu penyelesaian masalah akan dialokasikan ke setiap tingkat prioritas. Ini akan disetujui oleh bisnis dan dicatat dalam SLA.
Salah satu faktor yang akan memberi makan dampak dan urgensi masalah adalah tingkat kekambuhan.
• Investigasi masalah dan diagnosis: Tujuan dari fase investigasi dan diagnosis adalah untuk memastikan akar penyebab masalah. Prioritas yang dialokasikan untuk masalah harus mendorong jumlah sumber daya yang bekerja pada investigasi dan diagnosis. Prioritas harus dinilai kembali selama masa hidup masalah untuk memastikan bahwa 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. Penyebab yang mungkin terjadi, dan kemudian kemungkinan penyebabnya teruji dan akhirnya penyebab yang sebenarnya diverifikasi.
• Analisis Kronologis: Pendekatan ini menetapkan semua hal yang telah terjadi di timeline. Ini membuatnya lebih jelas untuk melihat apa yang telah terjadi dan memungkinkan fokus pada bagian penting dari garis waktu.
• Brainstorming: Mengumpulkan bersama individu-individu kunci yang terlibat dengan masalah di satu tempat dan memetakan semua kemungkinan penyebab (dan kegiatan korektif potensial). Sesi semacam ini harus berada di bawah kendali manajer masalah.
• Analisis nilai nyeri: Teknik ini berguna untuk mengidentifikasi masalah mana yang harus ditangani di mana urutannya. Rasa sakit untuk suatu bisnis dapat didefinisikan dalam sejumlah cara yang berbeda, misalnya jumlah pengguna yang terkena dampak atau potensi kerugian finansial. Analisis nilai nyeri menghasilkan kerangka kerja untuk memutuskan masalah mana yang benar-benar melukai organisasi, memungkinkan sumber daya dialokasikan di tempat yang paling dibutuhkan.
• Analisis Pareto: Prinsip Pareto sering disebut sebagai 'Aturan 80 -20'. Aturannya menyatakan bahwa untuk banyak peristiwa, sekitar 80 persen dari efek berasal dari hanya 20 persen dari penyebabnya. Aturan ini dapat digunakan dalam manajemen masalah untuk menargetkan penyebab (masalah) yang bertanggung jawab untuk sebagian besar insiden.
• Penanganan Masalah: Terkadang sebelum perbaikan permanen dapat ditemukan, penyelesaian masalah diidentifikasi. Ini sering terjadi selama tahap investigasi masalah dan diagnosis. Workarounds adalah cara memulihkan layanan yang dapat digunakan tanpa memahami akar permasalahannya. Contoh yang jelas dan sering digunakan adalah pengguna yang menemukan bahwa layar mereka telah 'membeku'. Mungkin ada sejumlah penyebab, tetapi langkah pertama, yang cukup sering menyelesaikan masalah, biasanya untuk mematikan PC dan kemudian hidupkan kembali.
Catatan masalah harus tetap terbuka ketika solusi telah diidentifikasi dan solusi harus rinci dalam catatan masalah. Perbaikan permanen harus tetap dilakukan. Namun, mungkin ada beberapa alasan mengapa solusi tetap ada selama beberapa waktu. Alasan-alasan ini termasuk:
• Perbaikan permanen terlalu berisiko;
• Perbaikan permanen terlalu mahal;
• dampak bisnis dari masalah tidak cukup signifikan untuk membenarkan diagnosis lebih lanjut saat ini;
• masalah akan diperbaiki secara permanen oleh rilis baru yang saat ini sedang direncanakan.
• Meningkatkan catatan kesalahan yang diketahui: Database kesalahan yang diketahui adalah sumber informasi penting untuk meja layanan dan kelompok pendukung yang menangani insiden dan masalah. Catatan kesalahan yang diketahui harus ditingkatkan ketika diagnosis telah selesai dan terutama ketika solusi telah diidentifikasi.
KNOWN ERROR
Kesalahan yang diketahui adalah masalah yang memiliki akar masalah yang didokumentasikan dan solusi. Kesalahan yang dikenal dibuat dan dikelola di seluruh siklus hidup mereka oleh manajemen masalah. Kesalahan yang diketahui juga dapat diidentifikasi oleh pengembangan atau pemasok.
• Resolusi masalah: Setelah perbaikan permanen telah diidentifikasi, itu harus dilaksanakan sesegera mungkin. Namun, mungkin ada alasan bagus untuk tidak segera melakukan ini. Alasannya mirip dengan alasan mengapa organisasi hidup dengan solusi dan termasuk biaya dan risiko. Selain itu, perbaikan segera mungkin memerlukan pemadaman layanan yang tidak dapat dibenarkan dalam jangka pendek. Permintaan untuk perubahan (RFC) harus diajukan dan dikembangkan untuk setiap perubahan yang diperlukan diidentifikasi.
• Penutupan masalah: Catatan masalah harus ditutup setelah perubahan berhasil diterapkan. Penting bahwa catatan masalah tetap terbuka sampai yakin bahwa masalah telah diselesaikan. Memeriksa bahwa masalah telah diselesaikan harus dilakukan melalui pengujian. Mungkin perlu waktu untuk memastikan bahwa perbaikan telah berhasil, misalnya mungkin waktu berikutnya proses tertentu digunakan seperti akhir hari, akhir bulan, akhir quar ¬ter, akhir tahun atau akhir pajak tahun.
• Tinjauan masalah utama: Setiap kali masalah besar terjadi, tinjauan masalah utama harus dilakukan. Setiap organisasi akan memiliki definisi sendiri tentang masalah utama berdasarkan dampak dan urgensi. Sangat penting bahwa ulasan ini melihat pelajaran yang didapat daripada menjadi sesi 'alokasi dari kesalahan'. Output dari tinjauan masalah utama harus mencakup apa yang berjalan dengan baik, apa yang berjalan buruk, apa yang bisa dilakukan lebih baik di masa depan, bagaimana masalah itu bisa dicegah dan bagaimana dampak dari masalah itu bisa dikurangi.
PROBLEM MANAJEMEN PROAKTIF
Kegiatan proaktif dapat mencakup analisis tren yang terkait dengan insiden bersejarah untuk mengidentifikasi dan menghilangkan kelemahan infrastruktur atau aplikasi yang mendasarinya. Pekerjaan proaktif dapat dimulai dari rencana peningkatan layanan yang telah dibuat mungkin sebagai tanggapan terhadap kinerja yang buruk atau hanya dari keinginan untuk meningkatkan kinerja, misalnya dalam situasi kompetitif untuk mendapatkan keuntungan atas penyedia layanan lain.
MANAJEMEN OPERASI IT
PENDAHULUAN DAN RUANG LINGKUP
Manajemen operasi TI adalah fungsi dan bukan proses. Bertanggung jawab untuk mengoperasikan infrastruktur dan aplikasi TI organisasi pada basis sehari-hari. Infrastruktur dan aplikasi TI mendukung layanan organisasi.
MAKSUD DAN TUJUAN
Pengiriman layanan yang stabil dengan tidak tersedianya diminimalkan adalah tujuan utamanya.
Manajemen operasi TI adalah fungsi yang memastikan bahwa semua infrastruktur dan aplikasi TI organisasi dikelola dan dipelihara sehari-hari untuk memberikan tingkat layanan yang disepakati.
KEGIATAN UTAMA
IT operations management is made up of two parts:
• Operations control: Responsible for carrying out the day-to-day opera¬tional activities. This includes monitoring the IT infrastructure and applica¬tions and responding to events, incidents and problems. More specifically tasks include job scheduling, backup and restore, console management, print and output management as well as undertaking maintenance activities for technical management teams and application management teams.
• Facilities management: Responsible for the day-to-day management of the physical IT environment. This typically would include responsibility for the data centre, server rooms as well as recovery rooms and sites. The power supply and back-up power supply would also be in scope. If any part of the physical IT environment is outsourced, then the facilities management arm of IT operations management would be responsible for day-to-day management of the contract and the relationship with the supplier.
It is important that IT operations management is involved at the right time through¬out the service management lifecycle and in the right way. More specifically:
• Strategi layanan: Manajemen operasi TI akan memiliki pemahaman mendalam tentang bagaimana teknologi saat ini digunakan untuk memberikan layanan yang ada. Pemahaman ini, bersama dengan kesadaran akan teknologi baru dan yang muncul, memungkinkan manajemen operasi TI untuk memiliki masukan yang berarti bagi fase strategi siklus hidup manajemen layanan. Sangat penting bahwa mereka yang bertanggung jawab untuk strategi menggunakan pengetahuan yang tersedia tentang bagaimana layanan benar-benar disampaikan setiap hari.
• Desain layanan: Melakukan kegiatan yang ditetapkan dalam fase desain layanan adalah tanggung jawab manajemen operasi TI. Oleh karena itu, penting bahwa manajemen operasi TI memiliki kemampuan untuk memasukkan ke fase ini.
• Transisi layanan: Pengujian adalah bidang transisi layanan di mana Anda berharap manajemen operasi TI terlibat besar. Staf operasi TI memiliki pengetahuan dan pemahaman tentang lingkungan hidup, yang memungkinkan mereka memastikan pengujian dirancang dan dieksekusi dengan benar. Ini mungkin staf operasi TI, di bawah arahan dari transisi layanan, yang secara fisik memperkenalkan rilis ke lingkungan hidup dan memantau kemajuan mereka.
• Operasi layanan: Ini adalah tugas mendasar dari manajemen operasi TI. Mereka memelihara dan memantau komponen (infrastruktur dan aplikasi) yang mendukung layanan dan bereaksi secara tepat waktu terhadap peristiwa, insiden, dan masalah yang diidentifikasi.
• Peningkatan layanan berkelanjutan: Staf dari manajemen operasi TI akan selalu mencari cara untuk meningkatkan layanan dan meningkatkan efisiensi dan efektivitas.
MANAJEMEN EVENT (ACARA)
PENDAHULUAN DAN RUANG LINGKUP
Manajemen acara memantau semua acara di seluruh infrastruktur dan aplikasi TI organisasi untuk memastikan operasi normal. Manajemen acara menangani pesan-pesan normal serta berada di sana untuk mendeteksi, mengeskalasi dan bereaksi terhadap pengecualian.
Proses manajemen acara bertanggung jawab untuk mengelola acara selama siklus hidup mereka.
MANAJEMEN ACARA
Proses yang bertanggung jawab untuk mengelola acara di seluruh siklus hidup mereka. Manajemen acara adalah salah satu kegiatan utama operasi TI.
PERISTIWA
Peristiwa adalah perubahan keadaan yang memiliki arti penting bagi manajemen layanan TI atau item konfigurasi lainnya. Istilah ini juga digunakan untuk berarti peringatan atau pemberitahuan yang dibuat oleh layanan TI apa pun, item konfigurasi atau alat pemantauan. Peristiwa biasanya membutuhkan personil operasi TI untuk mengambil tindakan, dan sering menyebabkan insiden yang dicatat.
Acara dapat dibagi menjadi tiga jenis:
• Informasional: Seperti pemberitahuan tentang penyelesaian pekerjaan yang dijadwalkan atau pengguna yang mengakses aplikasi.
• Peringatan: Termasuk indikasi bahwa penggunaan CI tertentu telah mencapai persentase kapasitas tertentu.
• Pengecualian: Seperti perangkat lunak yang tidak sah mendeteksi atau kegagalan komponen.
Manajemen acara dapat digunakan oleh setiap bagian dari manajemen layanan di mana ada persyaratan untuk memantau dan mengendalikan suatu kegiatan, selama pemantauan dan kontrol dapat dilakukan secara otomatis. Manajemen acara membutuhkan kemampuan untuk meningkatkan peringatan otomatis. Jika peringatan tidak dapat dinaikkan, maka hanya pemantauan yang dilakukan. Manajemen acara jauh lebih proaktif daripada pemantauan.
ALERT
Peringatan didefinisikan sebagai pemberitahuan bahwa ambang telah tercapai, sesuatu telah berubah atau kegagalan telah terjadi.
MAKSUD DAN TUJUAN
Manajemen acara adalah proses operasi layanan yang bertanggung jawab untuk memastikan bahwa infrastruktur, aplikasi dan keamanan yang mendukung layanan TI secara proaktif dimonitor dengan peringatan yang ditempatkan dan ditindaklanjuti.
KEGIATAN UTAMA
Manajemen acara mengikuti proses yang serupa dengan manajemen insiden
Tahapan proses idealnya harus otomatis dalam alat yang dipilih (s), tetapi intervensi manual mungkin diperlukan di kali.
Semakin cepat kejadian terdeteksi, semakin cepat mereka dapat diatasi. Misalnya, untuk layanan yang wajib tersedia mulai pukul 7.00 pagi, diperlukan sejumlah peringatan untuk menunjukkan jika salah satu komponen yang diperlukan untuk menyediakan layanan tersebut tidak tersedia pada waktu sebelum pukul 7.00 pagi.
Proses lainnya
Banyak bidang manajemen layanan akan mengidentifikasi area yang ingin mereka kontrol dan pantau. Manajemen konfigurasi dan manajemen kapasitas akan memiliki sejumlah persyaratan untuk manajemen acara.
MANAJEMEN APLIKASI
PENDAHULUAN DAN RUANG LINGKUP
Manajemen aplikasi adalah fungsi dan bukan proses. Ini akan mengelola aplikasi melalui totalitas siklus hidup mereka. Ini dimulai dengan 'ide' bisnis pertama dan selesai saat aplikasi tidak lagi diperlukan. Manajemen aplikasi terlibat dalam desain, pengujian dan peningkatan berkelanjutan aplikasi dan layanan yang didukung oleh aplikasi.
MAKSUD DAN TUJUAN
Manajemen aplikasi memiliki dua tujuan:
• Kustodian pengetahuan teknis dan keahlian yang berkaitan dengan pengelolaan aplikasi. Manajemen aplikasi memastikan bahwa pengetahuan teknis yang diperlukan untuk merancang, menguji, mengoperasikan dan terus meningkatkan aplikasi tersedia.
• Penyedia sumber daya yang sebenarnya untuk memfasilitasi semua fase siklus hidup layanan, memastikan bahwa staf dilatih secara memadai dan efektif. Seringkali penting bagi staf yang akan dikerahkan dalam operasi layanan untuk terlibat dalam desain layanan dan kegiatan transisi layanan untuk aplikasi tertentu.
Manajemen pengembangan Aplikasi Aplikasi
Sifat Satu-kali Kumpulan Aktifitas yang sedang berlangsung untuk mengawasi dan kegiatan kegiatan untuk merancang mengelola aplikasi di seluruh mereka dan membangun seluruh solusi aplikasi siklus hidup
Ruang Lingkup Sebagian besar dilakukan untuk semua aplikasi, baik untuk aplikasi yang dibeli dari pihak ketiga atau dikembangkan di rumah yang dikembangkan di rumah
Manajemen pengembangan Aplikasi Aplikasi
Ini berarti bahwa sering kali ini berarti sangat sulit bagi pengembang untuk staf operasional untuk terlibat dalam memahami dan membangun proyek-proyek pengembangan, karena yang mengambil operasi yang sedang berlangsung, mereka jauh dari mereka yang sedang berlangsung terutama karena mereka tanggung jawab operasional tidak tersedia untuk mendukung aplikasi begitu mereka telah pindah ke proyek berikutnya
Fokus staf Life Development, Staf yang terlibat dalam manajemen berkelanjutan pada pengembangan perangkat lunak biasanya hanya mengendalikan satu atau dua siklus hidup, yang menyoroti tahapan siklus hidup ini - mengoperasikan dependensi untuk dan meningkatkan operasi yang sukses, tetapi tidak menetapkan akuntabilitas untuk ini
KEGIATAN UTAMA
Manajemen aplikasi harus dilibatkan di seluruh siklus hidup manajemen layanan. Penting bahwa manajemen aplikasi terlibat pada waktu yang tepat dan dengan cara yang benar. Lebih spesifik:
• Strategi layanan: Persyaratan tingkat tinggi merupakan keluaran dari fase ini. Kriteria pengambilan keputusan terkait dengan apakah aplikasi dikembangkan di rumah atau dibeli di (dan disesuaikan seperlunya) memiliki relevansi khusus dengan manajemen aplikasi. Manajemen aplikasi akan memiliki pengetahuan dan pengalaman untuk berkontribusi pada keputusan ini.
• Rancangan layanan: Bagaimana aplikasi dirancang dan kemudian dikem- bangkan didirikan selama tahap perancangan layanan. Manajemen aplikasi akan memiliki pemahaman tentang bagaimana aplikasi serupa dikelola saat ini, dan akan memberikan informasi dan pandangan selama fase desain layanan.
• Transisi layanan: Manajemen aplikasi akan dimasukkan dalam pengujian dan memastikan bahwa proses pengujian tepat dan kuat. Pengetahuan yang dimiliki dalam tim manajemen aplikasi pada aplikasi dan bagaimana mereka berinteraksi satu sama lain dan dengan infrastruktur teknis akan digunakan untuk membantu menyusun skrip uji. Kesalahan yang diketahui dapat diidentifikasi pada tahap ini. Kesalahan yang diketahui dapat diberantas atau, setelah penilaian biaya dan risiko, diizinkan masuk ke lingkungan hidup dengan manajemen masalah dan basis data kesalahan yang diketahui sedang diperbarui.
• Operasi layanan: Manajemen aplikasi biasanya akan tersedia untuk menanggapi permintaan dukungan untuk aplikasi yang mereka tanggapi. Adalah hal yang biasa bagi tim manajemen aplikasi untuk melakukan kegiatan operasional sebagai bagian dari fungsi manajemen operasi TI. Tim manajemen aplikasi menyediakan dukungan lini kedua dan tersedia untuk eskalasi fungsional terkait dengan peristiwa, insiden dan masalah.
• Peningkatan layanan berkelanjutan: Kinerja aplikasi yang membentuk atau mendukung layanan akan terus dipantau. Perbaikan akan diidentifikasi dan dipertimbangkan dari sudut pandang biaya dan urgensi. Untuk aplikasi yang telah dibeli, hubungan dekat diperlukan dengan pemasok untuk memastikan bahwa organisasi menyadari kemungkinan peningkatan yang dapat dipertimbangkan untuk implementasi.
MANAJEMEN TEKNIS
PENDAHULUAN DAN RUANG LINGKUP
Manajemen teknis bukanlah suatu proses, itu adalah fungsi yang menyediakan sumber daya dan memastikan bahwa pengetahuan tentang teknologi yang relevan terus diperbarui.
MAKSUD DAN TUJUAN
Manajemen teknis memiliki dua tujuan:
• Kustodian pengetahuan teknis dan keahlian yang berkaitan dengan infrastruktur TI organisasi. Manajemen teknis memastikan bahwa pengetahuan teknis yang diperlukan untuk merancang, menguji, mengoperasikan dan terus meningkatkan layanan TI tersedia.
• Penyedia sumber daya yang sebenarnya untuk memfasilitasi semua fase siklus hidup layanan, memastikan bahwa staf dilatih secara memadai dan efektif. Seringkali penting bagi staf yang akan dikerahkan dalam operasi layanan untuk terlibat dalam desain layanan dan kegiatan transisi layanan untuk layanan tertentu.
KEGIATAN UTAMA
Manajemen teknis harus dilibatkan di seluruh siklus hidup manajemen layanan. Penting bahwa manajemen teknis terlibat pada saat yang tepat dan dengan cara yang benar. Lebih spesifik:
• Strategi layanan: Pengetahuan dan keahlian yang diperlukan untuk mengelola dan mengoperasikan infrastruktur TI akan diidentifikasi dalam fase strategi layanan siklus hidup manajemen layanan. Tim manajemen teknis akan memiliki masukan penting untuk kesepakatan tentang standar untuk arsitektur teknis.
• Rancangan layanan: Selama tahap perancangan layanan, tim manajemen teknis akan memberikan keahlian pada infrastruktur TI dan akan membuat saran untuk bagaimana bagian baru dari infrastruktur dapat dikelola pada tingkat operasional.
• Transisi layanan: Manajemen teknis akan dimasukkan dalam pengujian dan memastikan bahwa proses pengujian tepat dan kuat. Pengetahuan yang dimiliki dalam tim manajemen teknis dari infrastruktur teknis dan bagaimana antarmuka dengan aplikasi akan digunakan untuk membantu menyusun skrip uji.
• Operasi layanan: Umum bagi tim manajemen teknis untuk memahami kegiatan operasional sebagai bagian dari fungsi manajemen operasi TI. Tim manajemen teknis menyediakan dukungan lini kedua dan tersedia untuk eskalasi fungsional terkait dengan peristiwa, insiden dan masalah.
• Peningkatan layanan berkelanjutan: Kinerja komponen infrastruktur TI yang mendukung layanan akan terus dipantau. Perbaikan akan diidentifikasi dan dipertimbangkan dari sudut pandang biaya dan urgensi. Untuk infrastruktur TI yang telah dibeli, hubungan dekat diperlukan dengan pemasok untuk memastikan bahwa organisasi menyadari kemungkinan peningkatan dan bahwa ini dipertimbangkan untuk implementasi.
