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 benarbenar 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 ialah 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
ialah Target waktu respon dan penyelesaian sebuah incident sesuai yang ditulis
di dokumen Service Level Agreements.
-
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
: tindakan standar (terdokumentasi) untuk mengurangi dampak buruk dari sebuah
incident atau problem yang belum diketahui solusi tuntasnya.
-
Known
Error : 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) : 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 : yakni 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 : yakni standar prosedur (SOP) untuk menangani tipe-tipe permintaan
tertentu yangrutin terjadi.
-
Self-Help
Technology : 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 : permintaan akses layanan, dapat berupa permintaan layanan standar
atau RFC.
-
Identity
: yakni 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
: yakni 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:
-
Membuat inventaris komprehensif semua perangkat
keras, perangkat lunak, dan aset.
-
Menumbuhkan pemahaman yang lebih kuat tentang
aset mana yang dibutuhkan organisasi untuk berfungsi.
-
Peningkatan efisiensi.
-
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:
-
Memecah production plan dalam product family
menjadi jadwal masing2 SKU, qty & tanggal produksi.
-
Memecah volume product family menjadi end-item
mix (campuran SKU), rolls up end item forecasts untuk menyesuaikan dengan
volume product family.
-
Menghasilkan master production schedules (MPS)
untuk masing2 individual end items/SKU.
-
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.
0 Comments