Information Technology Infrastructure Library (ITIL V3)


1.      Service Transition

A.    Konsep
a.      Pengertian Dan Tujuan Service Transition
Service transition adalah tahapan merealisasikan/mengimplementasikan hasil tahapan service design menjadi layanan baru atau modifikasi layanan sebelumnya.
Tujuan service transition : memastikan layanan baru/termodifikasi/retired services benar-benar memenuhi harapan bisnis seperti telah terdokumentasi dalam service strategy dan service design.

b.      Perubahan (Change) Dan Jenis-Jenis Perubahan
Perubahan (Change) mencakup penambahan, modifikasi, atau penghilangan apapun yang dapat mempengaruhi layanan TI.
Jenis-Jenis Perubahan :
            1)      Standard change
            2)      Emergency change
            3)      Normal change

c.   Change Models : urutan langkah-langkah standar yang sudah ditetapkan dan disetujui sebelumnya (predefined steps) untuk menjalankan sebuah perubahan dengan jenis tertentu (yakni standard change).

d.   Request For Change (RFC) : sebuah dokumen/proposal resmi untuk mengajukan sebuah perubahan, didalamnya mencakup detail perubahan yang akan dibuat.

e.   Proposal Perubahan (Change Proposal) : dokumen yang berisi deskripsi umum rencana perubahan besar atau sistem baru, disertai dengan business case dan jadwal implementasinya.

f.  Change Advisory Board (CAB) : sebuah tim/kelompok/lembaga yang berwenang memberikan autorisasi terhadap sebuah perubahandn membantu change management dalam menilai dan melakukan prioritisasi perubahan yang akan dilakukan.

g.   Configuration Item (CI) : komponen-komponen atau sebuah aset layanan yang perlu untuk dikelola dalam rangka penyediaan sebuah layanan TI.

h.   Configuration Management System (CMS) : sebuah software untuk mengakses dan menghubungkan data-data CI yang telah tersimpan di Configuration Management Databases (CMDBs).

i.   Service Knowledge Management System (SKMS) : sebuah tool (aplikasi) dan basis data sebagai tempat mengelola pengetahuan, informasi, dan data layanan TI.

j.  Configuration Baseline : standar konfigurasi sebuah aset TI yang telah disetujui secara formal. Perubahan terhadap configuration baseline ini harus melalui prosedur standar perubahan, misalnya melalui dokumen request for change (RFC). 

k.   Snapshots : potret/catatan konfigurasi sebuah aset TI pada saat tertentu. Hasil sebuah evaluasi terhadap sebuah aset TI tertentu dan dibandingkan dengan configuration baseline.

l.     Definitive Media Library (DML) : adalah tempat atau lokasi dimana kita menyimpan semua software-software resmi/licensed beserta dokumen-dokumen resminya secara aman.

m. Release ialah satu atau lebih perubahan pada satu layanan TI yang dibangun, diuji, dan diimplementasikan bersama-sama. Dapat juga mencakup aktivitas-aktivitas perubahan pada hardware, software dan komponen lainnya. 

n.    Release Policy : sekumpulan aturan untuk melakukan deployment sebuah release ke lingkungan kerja sebenarnya, berisi pilhan-pilihan skenario yang dipilih menyesuaikan dengan analisis urgency dan dampaknya. Umumnya dirumuskan dan disetujui oleh change manager, termasuk didalamnya pengelompokkan paket-paket release.

B.     Proses
a.   Change Management : proses utama dalam service transition yang bertugas memastikan perubahan-perubahan TI telah tercatat, terevaluasi, terautorisasi, dan terimplementasi ke lingkungan kerja yang sebenarnya dengan penuh kontrol.
Aktivitas-aktivitas proses change management :
            1)      Membuat dan mencatat RFC
            2)      Me-review RFC
            3)      Menilai dan mengevaluasi perubahan
            4)      Autorisasi implementasi perubahan
            5)      Update rencana perubahan
            6)      Koordinasi implementasi perubahan (pembangunan) dan pengujian
            7)      Autorisasi penerapan perubahan pada lingkungan kerja sebenarnya
            8)      Koordinasi chage deployment
            9)      Mereview dan menutup catatan perubahan.

b.   Service Asset And Configuration Management (SACM) : proses mencatat, mendokumentasi, dan mengupdate informasi tentang berbagai service assets yang terkait layanan-layanan TI yang dikelola penyedia layanan.
Cakupan SACM ialah manajemen siklus hidup lengkap setiap CI, yakni setiap CI dapat telusuri sejak dari tahapan pembelian hingga pembuangan.
Aktivitas – aktivitas SACM :
            1)      Manajemen dan perencanaan
            2)      Identifikasi konfigurasi
            3)      Kontrol konfigurasi
            4)      Akuntansi dan pelaporan status asset
            5)      Verifikasi dan audit

c.   Release And Deployment Management : proses merencanakan, membuat time-table dan mengontrol pembangunan, pengujian dan pengimplementasian sistem/perubahan baru yang dibutuhkan oleh bisnis dengan tetap melindungi integritas layanan-layanan yang sudah ada sebelumnya.
Aktivitas-aktivitas and Deployment Management :
            1)      Perencanaan
            2)      Pembangunan dan pengujian paket release
            3)      Deployment
            4)      Early life support
            5)      Review dan menutup akses

d.   Knowledge Management : yakni proses mengumpulkan, mendokumentasikan, menganalisis, membagi, menggunakan, dan mengupdate pengetahuan yang dibutuhkan dan diperoleh selama mengelola layanan Tidisemua tahapan siklus layanan TI.
Aktivitas – aktivitas knowledge management :
            1)      Strategi manajemen pengetahuan
            2)      Transfer pengetahuan
            3)      Pengelolaan data, informasi dan pengetahuan
            4)      Pengelolaan SKMS

e.  Transition Planning And Support : kegiatan perencanaan dan dukungan untuk suatu transisi dari sistem/layanan lama ke sistem/layanan baru. Kegiatan transisi layanan sering dilakukan sebagai proyek, atau merupakan bagian dari proyek-proyek lain sehingga membtuhkan koordinasi terhadap semua aktivitas-aktivitas yang ada.

2.      Service Operation

A.    Konsep
 a.      Pengertian, tujuan dan peran penting tahapan Service Operation
Service operation ialah tahapan operasional layanan TI sehari – hari, termasuk melakukan aktivitas dukungan terhadap layanan TI untuk memastikan value layanan benar –benar dirasakan dan sesuai dengan harapan serta kebutuhan pengguna yang dilakukan secara berkala.
Service operation bertujuan untuk :
            1)      Mengkoordinasikan dan melaksanakan kegiatan dan proses yang dibutuhkan untuk
                   memberikan layanan TI kepada pengguna dan pelanggan, serta mengelola layanan 
                   memenuhi tingkat layanan yang telah disepakati.
            2)      Mengelola teknologi yang digunakan untuk menghasilkan dan mendukung layanan TI.
                   Seperti bagaimana memahami dan mengelola komponen-komponen teknologi seperti
                   server, mainframe, jaringan komputer, komunikasi, basis data, media penyimpanan,
                   sistem desktop dan aplikasi software.
             Peran penting dari tahapan service operation ialah adanya suatu hal yang menjalankan suatu
             proses supaya bisnis berjalan dengan lancar (terukur atau hanya biasa saja) dan menyeimbangkan
             konflik antar aspek (keseimbangan dari semua aspek ; Bisnis & TI, Cost & Quality). 

b.      Event dan Jenis Event
Event ialah sebuah perubahan keadaan pada infrasturktur TI yang memiliki nilai penting bagi manajemen layanan TI atau configuration item TI, berupa pesan atau tampilan yang dihasilkan oleh layanan, configuration item atau alat monitoring.
Jenis – jenis event :
            1)      Informasi (information) : sebuah event yang normal terjadi sehingga
                   tidak  memerlukan tindakan apapun, misalnya seseorang yang login ke suatu sistem.
            2)      Peringatan (warning) : sebuah event yang berada diambang batas normal dengan
                   adanya sebuah peringatan yang nantinya memerlukan sebuah respon tindakan yang
                   diperlukan atau tidak untuk mencegah potensi kegagalan. Contohnya adanya
                   peringatan bahwa volume disk hanya tersisa 5% dari maksimum kapasitas yang
                   diijinkan.
            3)      Ketidak-wajaran (Exception) : sebuah event yang menginformasikan bahwa sebuah
                   layanan atau komponen berjalan tidak sewajarnya (abnormal) dan membutuhkankan
                   respon tindakan, seperti kecepatan akses internet yang sangat lambat.

c.      Incident vs Problem
Incident adalah kejadian interupsi sebuah layanan yang tidak terencana (tidak diharapkan) atau penurunan kualitas sebuah layanan Ti. Sedangkan problem ialah akar (sumber, penyebab)  dari satu atau lebih incident.
Contoh : sakit kepala yang merupakan gejala yang menginterupsi tubuh kita (incident) dan menjadi penyebab berbagai sumber penyakit seperti tekanan darah tinggi atau kolesterol tinggi (problem).

d.      Impact, Urgency, dan Priority
Impact adalah seberapa besar potensi kerugian yang ditimbulkan atau seberapa banyak jumalah pengguna terkena dampak dari sebuah incident, problem atau change pada proses-proses bisnis.
Urgency adalah seberapa lama waktu yang dibutuhkan untuk penyelesaian atau penanganan dari incident, problem, atau change yang memiliki dampak signifikasi pada bisnis.
Priority adalah sebuah kategori yang digunakan untuk menentukan nilai penting sebuah incident, problem, atau change. Priority diukur berdasarkan impact dan urgency, dan digunakan untuk menentukan seberapa cepat sebuah tindakan respon harus segera diambil.

e.      Major Incident, Timescale, dan Incident Model
Major Incident adalah kategori tertinggi sebuah incident, yang memiliki karakteristik :
            1)      Incident yang memiliki dampak besar pada bisnis,
            2)      Memiliki urgensi tinggi,
            3)      Penyebab telah diketahui tetapi belum ada panduan solusi atau workaround.
Timescale adalah target waktu respon dan penyelesaian sebuah incident sesuai yang ditulis di dokumen Service Level Agreements (SLA).
Incident Model adalah sebuah prosedur standar aktivitas dan timescale telah ditetapkan sebelumnya) yang dibuat untuk menangani incident “standar” atau “special”.
Informasi yang harus ada dalam incident model mencakup :
            1)      Tindakan-tindakan yang harus diambil untuk menangani incident,
            2)      Urutan tindakan,
            3)      Penanggung-jawab
            4)      Timescales
            5)      Prosedur eskalasi

f.      Workaround, Known Error, dan Known Error Database (KEDB)
Workaround adalah tindakan standar (terdokumentasi) untuk mengurangi dampak buruk dari sebuah incident atau problem yang belum diketahui solusi tuntasnya.
Known Error adalah sebuah masalah (problem) yang telah diketahui dan terdokumentasi akar masalahnya, gejala-gejala incident-incident yang terkait, solusi standarnya atau langkah meminimalisasi dampak buruknya apabila solusi totalnya belum diketahui (workaround-nya).
Known Error Database (KEDB)  adalah basis data known error yang akan digunakan oleh service desk dan staff pendukung lainnya untuk melakukan incident management dan workaround. 

g.      Escalation
Adalah tindakan meneruskan laporan dan penanganan incident yang belum terselesaikan ke function lain di perusahaan untuk memperoleh dukungan lebih lanjut.
Ada 2 macam eskalasi :
            1)      Functional escalation : meneruskan penanganan sebuah incident ke tim pendukung atau
                   second level support.
            2)      Hierarchical escalation : meneruskan/mengkomunikasikan  informasi incident yang
                   belum terselesaikan ke manajemen bisnis diatasnya (seperti manajer) untuk dicari
                   solusinya.   

h.     Service Request, Request Model, dan Self-Help Technology
Service Request  adalah permintaan pengguna tentang informasi tertentu, pertanyan atau permintaan saran, perubahan yang bersifat standar (standard change), atau akses ke suatu layanan TI. Permintaan layananan ini umumnya ditangani oleh service desk tanpa perlu membuat/mengirimkan RFC.
Request Model adalah standar prosedur (SOP) untuk menangani tipe-tipe permintaan tertentu yangrutin terjadi.
Self-Help Technology adalah teknologi berbasis web yang membantu permintaan pengguna. Umumnya dalam bentuk formulir online yang mengharuskan pengguna untuk login ke sistem terlebih dahulu.

i.        Access Request, Identity, Privileges
Access Request adalah permintaan akses layanan, dapat berupa permintaan layanan standar atau RFC.
Identity adalah informasi unik dari setiap pengguna, yang menjelaskan status pengguna didalam organisasi dan sekaligus menentukan hak akses dia terhadap sistem layanan TI. Contoh : sidik jari.
Privileges adalah hak akses seseorang/grup pengguna ke satu/kelompok layanan IT. Misalnya : sistem kepegawaian hanya bagian HRD sebagai administratornya, sedangkan bagian keuangan hanya mengelola penggajian dari kinerja atau tingkat kehadiran seluruh karyawan.

B.     Proses
a.      Event Management
Event Management dasar untuk memantau kinerja dan ketersediaan layanan, tepat sasaran dan mekanisme untuk memantau apa yang harus ditentukan dan disepakati selama proses ketersediaan dan Kapasitas manajemen berlangsung.
Event Management tools ialah sebuah aplikasi yang mengautomatisasi aktivitas-aktivitas dalamEvent Management.

b.      Incident Management : mengembalikan layanan yang bermasalah agar berfungsi seperti sedia kala.

c.       Problem Management : yakni proses menganalisis dan myelesaikan akar penyebab incident.

d.  Request Fulfillment : yakni proses memenuhi permintaan pengguna layanan TI, diluar laporan terkaitdengan incident TI.

3.      Continual Service Improvement

Continual service improvement (CSI) menggunakan pendekatan yang digerakkan oleh metrik untuk mengidentifikasi peluang untuk perbaikan dan untuk mengukur dampak dari upaya peningkatan. Meskipun CSI adalah fase siklus hidup dan didokumentasikan dalam publikasi ITIL terpisah, CSI hanya dapat efektif jika diintegrasikan di seluruh siklus hidup, menciptakan budaya perbaikan yang berkelanjutan. CSI harus memastikan bahwa semua peserta dalam pemberian layanan memahami bahwa mengidentifikasi peluang untuk peningkatan adalah tanggung jawab mereka.

Tugas penting bagi CSI adalah mengidentifikasi metrik mana dari ribuan yang dibuat setiap hari yang harus dipantau. Ini dilakukan dengan mengidentifikasi, untuk setiap layanan atau proses, apa faktor penentu keberhasilan (CSF). CSF harus hadir jika proses atau layanan ingin berhasil. Disarankan agar setiap proses atau layanan mengidentifikasi tidak lebih dari tiga hingga lima CSF (satu atau dua di awal layanan atau proses).

Untuk menentukan apakah CSF hadir, perlu untuk mengidentifikasi indikator kinerja utama (KPI) yang mewakili sejauh mana CSF hadir. Sekali lagi, direkomendasikan agar setiap CSF diukur dengan tidak lebih dari tiga hingga lima KPI (satu atau dua di awal layanan atau proses). Penting untuk diingat bahwa, meskipun sebagian besar KPI adalah kuantitatif, KPI kualitatif, seperti kepuasan pelanggan, perlu dipertimbangkan juga.

CSI menggunakan proses 7 langkah untuk memandu bagaimana data dikumpulkan dan digunakan:
1)      Definisikan tujuan
2)      Tentukan apa yang diukur
3)      Kumpulkan data
4)      Memproses data
5)      Analisis data
6)      Sajikan dan gunakan informasi tersebut
7)      Menerapkan perbaikan

Jika CSI menjalankan perannya dengan benar, akan ada saran peningkatan yang muncul dari semua bagian pemberian layanan. Organisasi tidak mungkin memiliki sumber daya yang cukup untuk mengimplementasikan semua saran, sehingga perlu untuk menangkap peluang peningkatan, memahami dampaknya, ruang lingkup, dan persyaratan sumber daya, dan memprioritaskan implementasinya. CSI menggunakan daftar CSI sebagai alat untuk mendokumentasikan, menganalisis, dan merencanakan perbaikan.
Karena bisnis lebih bergantung pada layanan TI, penting bagi organisasi TI untuk terus mengevaluasi dan meningkatkan layanan TI mereka dan proses manajemen layanan TI yang memungkinkan layanan TI tersebut. Praktik peningkatan layanan berkelanjutan (CSI) formal, proaktif diperlukan untuk memenuhi dan mencapai perjanjian tingkat layanan. 
Untuk menerapkan CSI, organisasi perlu menanamkan sikap yang benar dan mendorong perilaku yang benar sampai mereka menjadi kebiasaan. Penyedia TI harus menanamkan budaya pengukuran yang terus-menerus menguji nilai, kualitas, kinerja, dan kepatuhan layanan dalam portofolio mereka dan mengimplementasikan inisiatif peningkatan yang memungkinkan hasil bisnis yang diinginkan. 
4.      Financial Management For IT Services

Manajemen Keuangan untuk Layanan TI mengacu pada bagian fase Strategi Layanan dari kerangka kerja ITIL. Selain manajemen keuangan, fase Strategi Layanan mencakup empat proses lainnya. Ini adalah:
1)      Manajemen portofolio layanan
2)      Pengelolaan permintaan
3)      Manajemen hubungan bisnis
4)      Manajemen strategi untuk layanan TI
Lima prinsip penting dari fase ini bekerja bersama untuk menawarkan praktik terbaik yang mengarah pada perbaikan proses yang berkelanjutan.

Untuk organisasi yang berorientasi pada layanan TI, layanan berkualitas tidak hanya berarti menyediakan layanan TI yang sangat baik bagi pelanggan. Ini juga berarti menerapkan praktik terbaik yang menawarkan efisiensi bermanfaat di seputar keuangan untuk meningkatkan model bisnis secara keseluruhan. Ini sangat berguna untuk organisasi TI yang memiliki pengeluaran teknologi yang semakin kompleks.

Tujuan utama manajemen keuangan untuk layanan TI adalah penilaian layanan atau menentukan nilai layanan yang ditawarkan kepada klien dengan memperhitungkan semua biaya. Dalam proses manajemen keuangan, akuntansi, penganggaran dan pengisian semua mengarah pada tujuan yang sama: memulihkan biaya dan menghasilkan laba untuk organisasi yang berorientasi pada layanan-TI.
Manfaat lain yang diperoleh dengan menerapkan kerangka kerja ITIL untuk manajemen keuangan meliputi:
1.      Membuat inventaris komprehensif semua perangkat keras, perangkat lunak, dan aset.
2.      Menumbuhkan pemahaman yang lebih kuat tentang aset mana yang dibutuhkan organisasi untuk
       berfungsi.
3.      Peningkatan efisiensi.
4.      Biaya layanan lebih rendah.

·         Akuntansi
Dalam konteks ini, akuntansi menetapkan untuk menentukan biaya penyediaan layanan dengan tujuan akhir meningkatkan efisiensi departemen TI.
Selama proses akuntansi TI, biaya, manfaat, kelas dan pencatatan ditugaskan untuk setiap layanan, membuatnya mudah untuk menentukan layanan mana yang paling menguntungkan, risiko terendah dan paling bermanfaat bagi pelanggan.

·         Penganggaran
Saat ini, penganggaran TI membutuhkan tindakan penyeimbangan yang cermat antara "menjaga lampu menyala" dan mendorong transformasi digital. Untuk itu, ada tiga kategori utama belanja TI sebagai berikut:
1)     Pengeluaran modal
Ini termasuk perolehan lisensi perangkat lunak besar, perbaikan besar, peningkatan perangkat
lunak, atau pembelian perangkat keras.
2)     Anggaran pengoperasian
Barang-barang ini mencakup pengeluaran untuk menjalankan bisnis seperti pemeliharaan dan
dukungan untuk perangkat keras maupun perangkat lunak.
3)     Pengeluaran strategis
      Proyek-proyek baru seperti yang dijelaskan di atas untuk mengubah bisnis.

·         Pengisian daya
Saat membuat pertimbangan seputar penagihan, organisasi menentukan berapa banyak yang akan ditagih pelanggan untuk layanan yang diberikan. Ini biasanya memperhitungkan nilai layanan dan investasi waktu yang diperlukan untuk pemberian layanan.
Jika suatu organisasi hanya menyediakan layanan kepada pelanggan internal, seperti departemen TI internal untuk organisasi perusahaan, biasanya tidak perlu menagih pelanggan. Dalam hal ini, muatan diserap ke dalam overhead organisasi atau dialokasikan ke departemen itu secara internal.

·         Mengembangkan Model Tolak Bayaran
Sederhananya, model tolak bayar akan membantu Anda menentukan berapa banyak tagihan untuk memulihkan biaya. Membuat tingkat tolak bayar berarti memahami biaya dan menambahkan margin.Dalam lembar Ringkasan Tingkat Atas seperti ini, organisasi menentukan tarif dengan menambahkan persentase overhead ke tingkat pengembalian biaya.

5.      Demand Management

Berikut ini adalah gambar faktor-faktor yang berkaitan dengan demand management di suatu perusahaan yang harus selalu seimbang agar kinerja perusahaan semakin baik.

·         Sales & Operations Planning
Sales and operations planning dalam suatu perusahaan bertujuan untuk menghubungkan business planning dengan tactical planning di MPR, menyeimbangkan supply & demand pada level product family, Perencanaan pada level volume, bukan individual product mix level (SKU & campurannya).
Sales and operations planning tersebut mempunyai siklus tiap bulannya. sales and operations planning tersebut melibatkan sales, manufacturing, logistics, finance, new product development dll.
Perencanaan resource dibutuhkan untuk menetapkan, mengukur, dan meng-adjusts kapasitas jangka panjang, identifikasi items yang lead time nya panjang, perencanaan resource tersebut membutuhkan approval management untuk capital expenditure yang besar

·         Master Scheduling
Tujuan dari master scheduling adalah untuk:
1)      Memecah production plan dalam product family menjadi jadwal masing2 SKU, qty & tanggal
       produksi.
2)      Memecah volume product family menjadi end-item mix (campuran SKU), rolls up end item
       forecasts untuk menyesuaikan dengan volume product family.
3)      Menghasilkan master production schedules (MPS) untuk masing2 individual end items/SKU.
4)      Menyeimbangkan MPS dengan capacity

·         Distribution planning
Distribution planning dalam suatu perusahaan bertujuan untuk dipakai dalam inventory finished goods, merencanakan kapasitas logistics untuk kebutuhan S&OP, merencanakan replenishment order ke factory supply.

·         Demand Forecasting
Demand forecasting diperlukan untuk pemenuhan order customer lebih lama dari lead time produksi, perlu waktu untuk menambah /mengurangi kapasitas (mesin, labor, supplier, warehouse), untuk perencanaan budget keuangan

·         Petunjuk Evaluasi Forecasts
Petunjuk evaluasi forecast, meliputi forecasts secara alami tidak sempurna, forecasts yang baik mendekati rata-rata aktual, forecasts secara alami pasti mengandung kesalahan, perlu mengukur forecast error, perhatikanlah bias: demand yang secara konsisten selalu diatas atau dibawah forecast, identifikasi variasi demand yang besar nilainya, identikasi  peluang improvement forecast.

·         Hasil Evaluasi Forecast
Hasil evaluasi forecast ini digunakan untuk perbaiki bias melalui forecasts yang realistis & teknik yang lebih baik, improvement forecasts untuk mengurangi forecast error, identifikasi process improvements yang akan mengurangi demand variation, bekerjasama dengan dengan customers untuk antisipasi demand, menggunakan deviasi forecast error untuk menghitung  safety stock, mengurangi inventory & memperbaiki customer service.

·         Forecast Error
Beberapa cara untuk mengurangi forecast error yaitu meningkatkan akurasi dengan cara fokus untuk mengurangi forecast error (cara paling baik), forecast error memiliki bias, terminology forecast error dapat menggunakan teknik quality control untuk mengatasinya.

Daftar Pustaka

Komentar

Postingan Populer