Request Fulfillment (Permintaan pemenuhan)

Tujuan: ITIL Request Fulfillment  bertujuan untuk memenuhi Permintaan Service, yang dalam banyak kasus adalah ringan (standar) Perubahan (misalnya permintaan untuk mengubah password) atau permintaan informasi.

Deskripsi : Permintaan Pemenuhan ditambahkan sebagai proses baru untuk ITIL V3 dengan tujuan untuk memiliki proses yang berdedikasi berurusan dengan Permintaan Layanan .

Hal ini didorong oleh perbedaan yang jelas dalam ITIL V3 antara Insiden (Layanan Interupsi) dan Permintaan Layanan (permintaan standar dari pengguna, misalnya reset password).

Dalam ITIL 2011, Permintaan Pemenuhan telah sepenuhnya direvisi.

ITIL Permintaan Pemenuhan

Untuk mencerminkan Permintaan bimbingan terbaru Pemenuhan sekarang terdiri dari lima sub-proses , untuk memberikan penjelasan rinci tentang semua kegiatan dan poin keputusan.

Permintaan Pemenuhan sekarang berisi interface

·         dengan Manajemen Insiden - jika Permintaan Layanan ternyata menjadi Insiden dan

·         dengan Layanan Transisi - jika memenuhi Layanan Permintaan membutuhkan keterlibatan Manajemen Perubahan. Gambaran proses ITIL Permintaan Pemenuhan menunjukkan antarmuka yang paling penting (lihat Gambar 1).

Penjelasan lebih jelas dari informasi yang menggambarkan Permintaan Layanan dan siklus hidupnya telah ditambahkan.

Konsep Permintaan Layanan Model dijelaskan secara lebih rinci.

Sub-Proses

Ini adalah ITIL Permintaan Pemenuhan sub-proses dan tujuan proses mereka:

Dukungan Pemenuhan permintaan

·         Proses Tujuan: Untuk memberikan dan menjaga alat-alat, proses, keterampilan dan aturan untuk penanganan yang efektif dan efisien Permintaan Layanan .

Permintaan Logging dan Kategorisasi

·         Proses Tujuan: Untuk merekam dan mengkategorikan Permintaan Layanan dengan ketekunan yang sesuai dan memeriksa otorisasi pemohon untuk mengajukan permintaan, dalam rangka memfasilitasi pengolahan cepat dan efektif.

Permintaan Model Eksekusi

·         Proses Tujuan: Untuk memproses Permintaan Layanan dalam jadwal waktu yang disepakati.

Permintaan Monitoring dan Eskalasi

·         Proses Tujuan: Untuk terus memantau status pengolahan Permintaan Layanan yang luar biasa, sehingga langkah-langkah balasan dapat diperkenalkan sesegera mungkin jika tingkat pelayanan cenderung dilanggar.

Permintaan Penutupan dan Evaluasi

·         Proses Tujuan: menyampaikan Permintaan Rekam untuk kontrol kualitas akhir sebelum ditutup. Tujuannya adalah untuk memastikan bahwa Permintaan Layanan sebenarnya diproses dan bahwa semua informasi yang diperlukan untuk menggambarkan siklus hidup permintaan ini diberikan secara cukup rinci. Selain ini, temuan dari pengolahan permintaan harus dicatat untuk penggunaan masa depan.

definisi

Berikut hal ITIL dan akronim (informasi objek) yang digunakan dalam proses Pemenuhan Permintaan untuk mewakili output proses dan masukan:

Permintaan Layanan (Request for service)

·         Sebuah permintaan resmi dari pengguna untuk sesuatu yang akan diberikan - misalnya, permintaan untuk informasi atau saran; untuk me-reset password; atau untuk menginstal workstation untuk pengguna baru. Rincian dari Permintaan Layanan dicatat oleh Permintaan Pemenuhan dalam Permintaan Layanan Rekam .

Permintaan Layanan Model (service request model)

·         A (Service) Permintaan Model mendefinisikan langkah-langkah spesifik yang disepakati yang akan diikuti untuk Permintaan Layanan dari jenis tertentu (atau kategori).

Permintaan Layanan Rekam ( service request record )

·         Sebuah catatan yang berisi semua rincian dari Permintaan Layanan. Permintaan layanan adalah permintaan resmi dari pengguna untuk sesuatu yang akan diberikan - misalnya, permintaan untuk informasi atau saran; untuk me-reset password; atau untuk menginstal workstation untuk pengguna baru.

Layanan Informasi Permintaan Status ( service request status information)

·         Sebuah pesan yang berisi status sekarang dari Permintaan Layanan dikirim ke pengguna yang sebelumnya dilaporkan meminta layanan. informasi status biasanya disediakan untuk pengguna pada berbagai titik selama siklus hidup Permintaan Layanan ini.

peran | tanggung jawab

Insiden Manager - Proses Owner

·         Insiden Manager bertanggung jawab untuk pelaksanaan yang efektif dari proses Manajemen Insiden dan melaksanakan pelaporan masing-masing. Dia merupakan tahap pertama dari eskalasi untuk Insiden, harus ini tidak diatasi dalam Tingkat Layanan yang disepakati.

Tingkat 1

·         Tanggung jawab 1 Tingkat Dukungan untuk mendaftar dan mengklasifikasikan Insiden diterima dan untuk melakukan upaya segera untuk memulihkan layanan TI gagal secepat mungkin. Jika tidak ada solusi ad-hoc dapat dicapai, Tingkat 1 Dukungan akan mentransfer Insiden kelompok dukungan ahli teknis ( 2 Tingkat Dukungan ). Tingkat 1 Dukungan juga proses Permintaan Layanan dan membuat pengguna informasi mengenai status Insiden mereka pada interval disepakati.

Layanan Permintaan Pemenuhan Grup ( request fulfilment group)

·         Layanan Permintaan Pemenuhan Grup mengkhususkan diri pada pemenuhan jenis tertentu Permintaan layanan . Biasanya, Tingkat 1 Dukungan akan memproses permintaan sederhana, sementara yang lain diteruskan ke Pemenuhan Grup khusus.

Tanggung jawab Matrix: ITIL Permintaan Pemenuhan
ITIL Peran / Sub-Proses	insiden Manajer	Tingkat 1 Dukungan	Layanan Permintaan Pemenuhan Grup
Dukungan Pemenuhan permintaan	A [1] R [2]
Permintaan Logging dan Kategorisasi	SEBUAH	R	-
Permintaan Model Eksekusi	SEBUAH	R	R
Permintaan Monitoring dan Eskalasi	AR	R	-
Permintaan Penutupan dan Evaluasi	SEBUAH	R	-

Keterangan

[1] A: ​​Akuntabel menurut Model RACI: Mereka yang akhirnya bertanggung jawab untuk penyelesaian yang benar dan menyeluruh dari proses Pemenuhan Permintaan.

[2] R: Bertanggung jawab sesuai dengan Model RACI: Orang-orang yang melakukan pekerjaan untuk mencapai suatu tugas dalam Permintaan Pemenuhan.

REFRENSI :

http://wiki.en.it-processmaps.com/index.php/Request_Fulfilment

https://www.ucisa.ac.uk/~/media/Files/members/activities/ITIL/service_operation/request_fulfilment/ITIL_a%20guide%20to%20request%20fulfilment%20pdf.ashx

 

 

 

Incident Management

Incident Management adalah salah satu proses dalam ITIL. Biasanya proses ini adalah salah satu proses yang diterapkan pertama kali saat implementasi ITIL.  Mengapa? Karena proses ini berhadapan langsung dengan customer/user, sehingga sangat mempengaruhi persepsi customer terhadap Service Provider.

Dengan menjaga ekspektasi customer sesuai dengan level yang sudah disepakati, maka tingkat kepuasan customer akan tetap terjaga dan memudahkan customer dalam mencapai tujuan bisnisnya.

Incident Management bertanggung jawab untuk mengembalikan “normal service operation” secepat mungkin untuk meminimalkan dampak terhadap bisnis dan memastikan kualitas dan availability dari service level sebaik mungkin.

Yang dimaksud dengan Normal Service Operation adalah service level yang diharapkan oleh bisnis seperti yang didefinisikan dan disepakati dalam Service Level Agreement (SLA).

Scope dari Incident Management: setiap kejadian yang (dapat) menyebabkan gangguan terhadap service, penurunan kualitas service, atau gangguan terhadap infrastructure walaupun tidak berdampak terhadap service yang diterima customer.  Kejadian ini bisa dilaporkan langsung oleh user, staf teknikal, atau melalui interface dari Event Management.

Incident adalah

§  Gangguan yang tidak direncanakan terhadap IT service

§  Penurunan kualitas dari IT service

§  kegagalan terhadap salah satu Configuration Item (CI) yang tidak berdampak terhadap IT service

 REFRENSI : https://merdeca.files.wordpress.com/2013/03/incident-management-process2.gif

PROBLEM MANAGEMENT

(Pengelolaan Masalah)

Pengelolaan Masalah adalah proses bertanggung jawab untuk mengelola siklus hidup dari semua masalah. Tujuan utama dari manajemen masalah yang mencegah masalah dan insiden yang mengakibatkan terjadi, untuk menghilangkan insiden berulang, dan untuk meminimalkan dampak dari insiden yang tidak dapat dicegah. The Teknologi Informasi Infrastructure Library mendefinisikan masalah sebagai penyebab satu atau lebih insiden 

Jangkauan pengelolah masalah atau managemet problrem

Pengelolaan Masalah mencakup kegiatan yang dibutuhkan untuk mendiagnosa akar penyebab insiden diidentifikasi melalui Manajemen Insiden proses, dan untuk menentukan resolusi untuk masalah tersebut.Hal ini juga bertanggung jawab untuk memastikan bahwa resolusi ini dilaksanakan melalui prosedur kontrol yang tepat, terutama Manajemen Perubahan dan Manajemen Pers .

Pengelolaan Masalah juga akan menjaga informasi tentang masalah dan workarounds yang tepat dan resolusi, sehingga organisasi mampu mengurangi jumlah dan dampak insiden dari waktu ke waktu. Dalam hal ini, Pengelolaan Masalah memiliki antarmuka yang kuat denganManajemen Pengetahuan , dan alat-alat seperti Kesalahan database Disebut akan digunakan untuk keduanya. Meskipun Manajemen Insiden dan Pengelolaan Masalah adalah proses yang terpisah, mereka erat terkait dan biasanya akan menggunakan alat yang sama, dan dapat menggunakan sejenis kategorisasi, dampak dan prioritas coding sistem.Ini akan memastikan komunikasi yang efektif ketika berhadapan dengan insiden terkait dan masalah.

Value to business (keuntungan di dalam bisnis)

Masalah Manajemen bekerja sama dengan Manajemen Insiden dan Manajemen Perubahan untuk memastikan bahwa ketersediaan layanan IT dan kualitas meningkat. Ketika insiden diselesaikan, informasi tentang resolusi dicatat. Seiring waktu, informasi ini digunakan untuk mempercepat waktu penyelesaian dan mengidentifikasi solusi permanen, mengurangi jumlah dan resolusi waktu insiden. Hal ini menyebabkan downtime kurang dan kurang gangguan sistem bisnis penting.

Kegiatan proses, metode dan teknik 

Pengelolaan Masalah terdiri dari dua proses utama:

·         Reaktif Pengelolaan Masalah, yang umumnya dilaksanakan sebagai bagian dari Layanan Operasi

·         Manajemen Masalah proaktif yang dimulai pada Layanan Operasi , tetapi umumnya didorong sebagai bagian dari peningkatan pelayanan terus-menerus (CSI) .

Deteksi masalah 

·         Kecurigaan atau deteksi penyebab satu atau lebih insiden oleh Desk Service , menghasilkan Soal Rekam dibesarkan - Service Deskmungkin telah diselesaikan insiden tersebut namun belum menentukan penyebab pasti dan mencurigai bahwa kemungkinan untuk kambuh.

·         Analisis insiden oleh kelompok dukungan teknis yang mengungkapkan bahwa masalah mendasar ada, atau mungkin ada.

·         Otomatis deteksi infrastruktur atau aplikasi kesalahan, menggunakan alat event / peringatan otomatis menaikkan insiden yang dapat mengungkapkan kebutuhan untuk Masalah Rekam .

·         Sebuah pemberitahuan dari pemasok atau kontraktor bahwa ada masalah yang harus diselesaikan.

·         Analisis insiden sebagai bagian dari proaktif Manajemen Soal: menonton-buletin, rilis, makalah yang relevan

Problem logging

Semua rincian yang relevan dari masalah harus dicatat sehingga catatan sejarah penuh ada. Ini harus menjadi tanggal dan waktu dicap untuk memungkinkan kontrol yang sesuai dan eskalasi. Sebuah referensi silang harus dilakukan untuk insiden (s) yang memprakarsai "Masalah Record":

·         rincian layanan

·         rincian peralatan

·         Tanggal / waktu awalnya login

·         Prioritas dan kategorisasi rincian

·         deskripsi insiden

·         Rincian untuk semua tindakan pemulihan diagnostik atau dicoba diambil.

Problem Prioritization ( Masalah prioritas)

Masalah dapat dikategorikan menurut tingkat keparahan dan prioritas mereka dalam cara yang sama seperti insiden untuk memfasilitasi pelacakan mereka, mengambil dampak dari insiden terkait dan frekuensi mereka kejadian ke rekening. Dari sudut pandang infrastruktur pandang satu mungkin bertanya:

·         Dapat sistem dipulihkan, atau tidak perlu diganti?

·         Berapa biayanya?

·         Berapa banyak orang akan diminta untuk memperbaiki masalah?

·         Berapa lama waktu yang dibutuhkan untuk memperbaiki masalah?

·         Berapa banyak sumber daya tambahan akan terlibat?

·         Apa dampak dari tidak menyelesaikan masalah?

Masalah penyelidikan dan diagnosis

Hasil investigasi untuk masalah akan menjadi akar penyebab diagnosis atau laporan RCA. Resolusi itu harus merupakan penjumlahan dari tingkat yang tepat dari sumber daya dan keterampilan yang digunakan untuk menemukannya. Ada beberapa teknik pemecahan masalah yang berguna yang dapat digunakan untuk membantu diagnosis dan masalah diselesaikan.

·         CMS harus digunakan untuk membantu menentukan tingkat dampak dan untuk membantu dalam penentuan titik kegagalan.

·         The Disebut Kesalahan database atau KEDB harus diakses dan diperiksa untuk mengetahui apakah masalah telah terjadi di masa lalu, jika demikian resolusi harus sudah di tempat.

·         Analisis Kronologis, peristiwa yang dipicu masalah akan diperiksa dalam urutan kronologis untuk memiliki waktu peristiwa. Tujuannya adalah untuk melihat acara memicu acara berikutnya dan seterusnya, atau untuk menyingkirkan beberapa peristiwa mungkin.

The Pain Analisis Nilai berisi pandangan yang lebih luas dari dampak insiden atau masalah pada bisnis. Daripada menganalisa jumlah insiden / masalah dari jenis tertentu dalam interval waktu tertentu, teknik ini fokus pada analisis mendalam dari apa yang tingkat rasa sakit telah menyebabkan bisnis dengan insiden / masalah. Sebuah formula untuk menghitung tingkat rasa sakit harus memperhitungkan:

·         jumlah orang yang terkena dampak

·         durasi downtime yang disebabkan

·         biaya untuk bisnis

The Kepner dan Tregoe metode yang digunakan untuk menyelidiki masalah yang lebih dalam-berakar. Mereka didefinisikan tahapan sebagai berikut:

·         mendefinisikan masalah

·         menjelaskan masalah dalam hal identitas, lokasi, waktu (durasi) dan ukuran (dampak)

·         mendirikan kemungkinan penyebab

·         menguji penyebab paling mungkin

·         memverifikasi penyebab sebenarnya

Analisis Pareto atau grafik Pareto adalah teknik untuk memisahkan potensi penyebab penting dari masalah sepele. Langkah-langkah berikut harus diambil:

1.   Membentuk tabel daftar penyebab dan frekuensi mereka sebagai persentase

2.   Mengatur baris dalam urutan menurun dari pentingnya penyebab (penyebab paling penting pertama)

3.   Menambahkan persentase kolom kumulatif ke meja

4.   Buat bar chart dengan penyebab, agar persentase mereka total

5.   Menarik garis di 80% pada sumbu Y, kemudian turun garis pada titik persimpangan dengan X-axis. Dari grafik Anda dapat melihat penyebab utama untuk kegagalan jaringan. Ini harus ditargetkan pertama.

	kegagalan jaringan
Penyebab	Persentase dari total	perhitungan%	Kumulatif
network controller	35	0 + 35%	35
file korupsi	26	35% + 26%	61
Server OS	6	61% + 6%	67%

Known Error Record

Setelah penyelidikan selesai dan solusi (atau bahkan solusi permanen) telah ditemukan, sebuah Disebut Kesalahan Rekam harus diangkat dan ditempatkan di Kesalahan database Dikenal untuk mengidentifikasi dan menyelesaikan masalah lebih lanjut yang sama. Tujuan utama adalah untuk mengembalikan layanan yang terkena secepat mungkin dengan dampak minimal pada bisnis.

Sebuah praktek yang baik akan meningkatkan Kesalahan Disebut Rekam lebih awal dalam penyelidikan - hanya untuk tujuan informasi

Major Problem Review (Mayor Soal Ulasan)

Sebuah praktek yang baik adalah memiliki review untuk semua masalah utama. review harus memeriksa:

·         Langkah-langkah yang benar diambil

·         Masalah yang dihadapi selama pelaksanaan dari solusi

·         Kebutuhan untuk meningkatkan

·         Mencegah terulangnya insiden serupa lanjut

·         Pihak Ketiga / vendor / pemasok yang terlibat dalam pelaksanaan

Pengetahuan dipelajari dari tinjauan harus dimasukkan ke dalam review layanan dengan pelanggan bisnis untuk memastikan bahwa pelanggan menyadari tindakan yang diambil dan rencana untuk mencegah insiden serupa di masa depan dari occurring.This membantu untuk meningkatkan kepuasan pelanggan dan menjamin bisnis yang layanan Operasi adalah penanganan insiden besar bertanggung jawab dan aktif bekerja untuk mencegah terulangnya masa depan mereka.

Refrensi : https://en.wikipedia.org/wiki/Problem_management

IT Operations Management

 

Deskripsi

Manajemen Operasi IT merupakan bagian dari Manajemen Infrastruktur TIK di ITIL V2, di mana beberapa aspek operasional dijelaskan secara lebih rinci seperti dalam buku ITIL V3 baru.

Antarmuka antara IT Manajemen Operasi dan proses ITIL lainnya disesuaikan untuk mencerminkan struktur proses V3 ITIL baru.

Tidak ada sub-proses yang ditentukan untuk Operasi IT Management.

Peran ITIL

IT Operations Manager - Proses Owner

Sebuah Operations Manager IT akan diperlukan untuk mengambil tanggung jawab keseluruhan untuk semua kegiatan Manajemen Operasi TI. Dia akan memastikan bahwa semua kegiatan operasional sehari-hari dilakukan dengan cara yang tepat dan dapat diandalkan

 

Refrensi : http://wiki.en.it-processmaps.com/index.php/IT_Operations_Management

KElOMPOK 5 :

HADI CAHYA

LUCKY I

BAYU HARI

TRI PRAMUDITA

AHMADZULFIKAR