MANAJEMEN LAYANAN SISTEM INFORMASI
MANAJEMEN
LAYANAN SISTEM INFORMASI
Dosen: Tiya Novianti
Disusun oleh:
Ariq Syach Alfikri Zani (10117963)
Josafat Arianus Jogi Leve
(13117082)
Popo Alangsto Hutapea (16117915)
Reinal Agustivan Simbolon (15117028)
Soewandi (15117746)
UNIVERSITAS
GUNADARMA
FAKULTAS
ILMU KOMPUTER & TEKNOLOGI INFROMASI
SISTEM
INFORMASI
2018/2019
Kata Pengantar
Segala
puji dan syukur kami kehadirat Tuhan Yang Maha Esa, karena berkat rahmat dan
karunianya makalah ini dapat diselesaikan sesuai dengan rencana. Makalah yang
berjudul “Manajemen Layanan Sistem Informasi” ini untuk memenuhi tugas dari
Dosen Bahasa Indonesia Bapak Tri Budiarta.
Selama penyusunan makalah ini banyak
kendala yang dihadapi, namun berkat bimbingan serta bantuan dari berbagai pihak
semua kendala tersebut bias kami atasi. Pada kesempatan kali ini, kami ingin
menyampaikan rasa terima kasih yang sebanyak-banyaknya.
Kami merasa masih banyak kekurangan baik
pada teknis penulisan maupun materi yang kami sampaikan, untuk itu kami sangat
menerima berbagai kritik dan saran dari berbagai pihak agar tercapainya
kesempurnaan dari makalah ini.
Semoga makalah ini dapat bermanfaat dan
bisa jadi sumbangan informasi dan pemikiran bagi yang membutuhkanya, khususnya
bagi penulis sehingga tujuan yang diharapkan dapat tercapai.
BAB
I
PEMBAHASAN
1.1
Service
Transition
a. Konsep
Service transition
adalah tahapan merealisasikan/mengimplementasikan hasil tahapan service design
menjadi layanan baru atau modifikasi layanan sebelumnya.
Tujuan service
transition adalah memastikan layanan baru/termodifikasi/retired services
benar-benar memenuhi harapan bisnis seperti telah terdokumentasi dalam service
strategy dan service design.
Perubahan (change)
mencakup penambahan, modifikasi, atau penghilangan apapun yang dapat
mempengaruhi layanan TI. Jenis-jenis perubahan, yaitu:
1. Standard
change
2. Emergency
change
3. Normal
change
Change
Models merupakan urutan langkah-langkah standar yang sudah ditetapkan dan
disetujui sebelumnya (predefined steps) untuk menjalankan sebuah perubahan
dengan jenis tertentu (yakni standard change).
Request
For Change (RFC) merupakan dokumen yang berisi deskripsi umum rencana perubahan
besar atau sistem baru, disertai dengan business case dan jadwal
implementasinya.
Change
Advisory Board (CAB) merupakan sebuah tim/kelompok/lembaga yang berwenang
memberikan autorisasi terhadap sebuah perubahan dam membantu change management
dalam menilai dan melakukan prioritisasi perubahan yang akan dilakukan.
Configuration
item (CI) merupakan komponen-komponen atau sebuah asset layanan yang perlu
untuk dikelola dalam rangka penyediaan sebuah layanan TI.
Configuration
Management System (CMS) merupakan sebuah software untuk mengakses dan
menghubungkan data-data CI yang telah tersimpan di Configuration Management
Databases (CMDBs).
Service
Knowledge Management System (SKMS) merupakan sebuah tool (aplikasi) dan basis
data sebagai tempat mengelola pengetahuan, informasi, dan data layanan TI.
Configuration
Baseline merupakan standar konfigurasi sebuah asaet TI yang telah disetujui
secara formal. Perubahan terhadap configuration baselin ini harus melalui
prosedur standar perubahan, misalnya melalui dokumen request for change (RFC).
Snapshots
merupakan potret atau catatan konfigurasi sebuah asset TI pada saat tertentu.
Hasil sebuah evaluasi terhadap sebuah asset TI tertentu dan dibandingkan dengan
configuration baseline.
Definitive
Media Library (DML) adalah tempat atau lokasi dimana kita menyimpan semua
software-software resmi/licensed beserta dokumen-dokumen resminya secara aman.
Release
ialah satu atau lebih perubahan pada satu layanan TI yang dibangun, diuji, dan
diimplementasiikan bersama-sama. Dapat juga mencakup aktivitas-aktivitas
perubahan pada hardware, software dan komponen lainnya.
Release
Policy merupakan sekumpulan aturan untuk melakukan deployment sebuah release ke
lingkungan kerja sebenarnya, berisi pilihan-pilihan skenarion yang dipilih
menyesuaikan dengan analisis urgency dann dampaknya. Umumnya dirumuskna dan
disetujui oleh change manager, termasuk didalamnya pengelompokkan paket-paket
release.
b. Proses
Change
Management adalah proses utam dalam service transition yang bertugas memastikan
perubahan-perubahan TI telat tercatat, terevaluasi, terautorisasi, dan
terimplementasi ke lingkungan kerja yang sebenarnya dengan penuh control.
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.
Service
Asset and Configuration Management (SACM) merupakan 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
Release
and Deployment Management adalah proses merencanakam, 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
release and deployment management:
1. Perencanaan
2. Pembangunan
dan pengujian paket release
3. Deployment
4. Early
life support
5. Review
dan menutup akses
Knowledge
Management yakni proses mengumpulkan, mendokumentasikan, menganalisis,
membagi, menggunakan, dan mengupdate pengetahuan yang dibutuhkan dan diperoleh
selama mengelola layanan TI disemua
tahapan siklus layanan TI.
Aktivitas
– aktivitas knowledge management:
1. Strategi
manajemen pengetahuan
2. Transfer
pengetahuan
3. Pengelolaan
data, informasi dan pengetahuan
4. Pengelolaan
SKMS
Transition
Planning and Support adalah 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.
1.2
Service
Operation
a. Konsep
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).
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) merupakan sebuah event yang normal terjadi sehingga tidak memerlukan
tindakan apapun, misalnya seseorang yang login ke suatu sistem.
2. Peringatan
(warning) merupakan 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) merupakan sebuah event yang menginformasikan bahwa sebuah layanan
atau komponen berjalan tidak sewajarnya (abnormal) dan membutuhkankan respon
tindakan, seperti kecepatan akses internet yang sangat lambat.
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).
Impact,
Urgency, dan Priority
Impact
|
Urgency
|
Priority
|
Seberapa besar
potensi kerugian yang ditimbulkan atau seberapa banyak jumalah pengguna
terkena dampak dari sebuah incident, problem atau change pada proses-proses
bisnis.
Yang
umumnya diukur berdasarkan seberapa pemenuhan target/standar tingkat layanan
TI (Service levels) akan terpengaruh.
|
Seberapa lama
waktu yang dibutuhkan untuk penyelesaian atau penanganan dari incident,
problem, atau change yang memiliki dampak signifikasi pada bisnis.
Misalnya
sebuah incident yang memiliki impact tinggi namun urgencynya rendah. Seperti
down/error sebuah aplikasi akademik mahasiswa, secara impact berdampak
tinggi pada mahasiswa, namun urgencynya tidak begitu berpengaruh pada
bisnis karena belum efektifnya perkuliahan hingga semester baru dimulai.
|
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.
Contohnya:
dalam sebuah dokumen SLA* dinyatakan bahwa sebuah incident “prioritas 2”
harus diatasi dalam waktu 12 jam sejak laporan masuk.
*SLA
(Service Level Agreements) : kesepakatan penyedia layanan TI dan pelanggan
(eksternal). Berisi informasi tentang layanan TI, dokumentasi target tingkat
layanan, dan tanggung jawab antara penyedia layanan TI dan pelanggan.
|
Major Incident,
Timescale, dan Incident Model
Major Incident
ialah Kategori tertinggi sebuah incident, yang memiliki karakteristik:
a. Incident
yang memiliki dampak besar pada bisnis.
b. Memiliki
urgensi tinggi.
c. Penyebab
telah diketahui tetapi belum ada panduan solusi atau workaround.
Perusahaan
harus mendefinisikan indikator major incident (misal jika kejadian berdampak
pada minimal 5.000 pengguna) dan membuat prosedur penangan khususnya, baik
dalam hal timescale (umumnya timescale lebih pendek) maupun staf yang
menanganinya. Seringkali beberapa incident yang memiliki prioritas rendah namun
berdampak tinggi bagi perusahaan menggunakan major incidents ini.
Timescale
ialah Target waktu respon dan penyelesaian sebuah incident sesuai yang ditulis
di dokumen 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:
a. Tindakan-tindakan
yang harus diambil untuk menangani incident
b. Urutan
tindakan
c. Penanggung-jawab
d. Timescales
e. Prosedur
eskalasi
f. Workaround,
Known Error, dan Known Error Database (KEDB)
Workaround
merupakan 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 yang terkait, solusi standarnya atau
langkah meminimalisasi dampak buruknya apabila solusi totalnya belum diketahui
(workaround-nya).
Known
Error Database (KEDB) ialah basis data known error yang akan digunakan oleh
service desk dan staff pendukung lainnya untuk melakukan incident management
dan workaround.
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 artinya meneruskan penanganan sebuah incident ke tim pendukung atau
second level support.
2. Hierarchical
escalation artinya meneruskan/mengkomunikasikan informasi incident yang
belum terselesaikan ke manajemen bisnis diatasnya (seperti manajer) untuk
dicari solusinya.
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.
*service
desk (help desk, support desk, atau IT service center) adalah sebuah unit
(function) dalam organisasi yang berfungsi sebagai gerbang komunikasi (single
point of contact atau SPOC) antara penyedia layanan dengan pengguna.
Request
Model yakni 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.
Access
Request, Identity, Privileges
Access
Request merupakan 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
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.
Tujuan
Event Management ialah mengelola event, yang mencakup:
1. Mendteksi
Event (“Apa yang terjadi?”)
2. Menganalisis
Event: mengklasifikasikan jenis Event, penting/tidak? (“Apa artinya?”)
3. Menentukan
tindakan yang paling tepat dan sesuai dengan Event yang sedang terjadi tersebut:
mencatatnya/log, mengabaikannya, menyampaikan peringatan kepada orang lain,
atau menindaklanjuti dengan tindakan Incident Management, Problem Management,
atau Change Management. (“Apa yang harusdilakukan?”)
Aktivitas-aktivitas
pada Event Management:
1. Event
Notification, Event Detection, Event Logging
Event
Notification adalah aktivitas menentukan “pesan” apa yang kita ingin hasilkan
dan informasi apa yang terdapat didalan pesan tersebut.
Event
Detection adalah menentukan jenis notifikasi mana yang ingin dideteksi dan
dikenali oleh tools dan menentukan apakah event akan di catat di log/tidak dan bagaimana
pencatatannya.
Event
Logging adalah mencatat data di dalam tools yang mendeteksi event tersebut atau
menghasilkan rekaman event dalam event-logging tool tertentu.
2. Event
Filtered dan Event Correlation
Event
Filtered ialah aktivitas yang mengklasifikasi sebuah Event sebagai sebuah
informasi, peringatan atau ketidakwajaran dan memutuskan tindakan apa yang akan
diambil dari event tersebut.
Event
Correlation mengambil kesimpulan dari event yang terjadi berulang-ulang sehingga
dipahami dampak akumulasinya.
3. Response
selection menentukan jenis respon untuk setiap kemungkinan event, yaitu:
a. Auto
Response mengatur sebuah peralatan melakukan respon otomatis tertentu
khususuntuk sebuah event.
b. Alert
merupakan sistem akan secara otomatis menghasilkan dan mengirimkan informasi
peringatan untuk menarik perhatian.
c. Incident,
problem, dan change ialah sistem mampu secara otomatis menghasilkan
laporan/permintaan untuk proses Incident Management, Problem Management, atau
Change Management sesuai kriteria-kriteria tersebut. Namun, untuk melaksanakan
proses ini, perlu persetujuan dari manajemen.
4. Review
Action dan Close Event adalah me-review penanganan sebuah event perlu dilakukan
untuk memastikan bahwa langkah yang tepat telah diambil. Jika review penanganan
tersebut sudah tepat, maka aktivitas event dapat dikatakan selesai/ditutup.
Contoh: event-event
informasi otomatis selesai manakala telah tercatat (ter-log).
Incident Management yaitu mengembalikan
layanan yang bermasalah agar berfungsi seperti sedia kala.
Aktivitas-aktivitas pada
incident management:
1. identifikasi
incident dan logging merupakan aktivitas menemukan/mengenali sebuah incident.
2. kategorisasi
incident merupakan incident yang dicatat selanjutnya dikategorisasikan dnegan
kode kategori incident.
3. Prioritisasi
incident menentukan prioritas penanganan sebuah incident yang telah dicatat dan
dikategorisasi, secara teknis dengan memberi kode prioritas incident.
Priority
code
|
Description
|
Target
Resolution Time
|
1
|
Critical
|
1
hour
|
2
|
High
|
8
hour
|
3
|
Medium
|
24
hour
|
4
|
Low
|
48
hour
|
5
|
Planning
|
Planned
|
4. Diagnosis
Awal adalah service Desk akan berupaya untuk
menyelesaikan incident terlebih dahulu sebelum diteruskan kepada tim
teknis.
5. Investigasi
dan diagnosis adalah penyelesaian masalah dan pemulihan kondisi layanan
(resolution and recovery), tindakan pengembalian layanan harus dipastikan
benar-benar tuntas dan catatan incident harus di update.
6. Penutupan
incident: setelah incident diatasi, staf service desk harus
menginformasikan kepada pengguna bahwa masalah telah teratasi dan memastikan
pengguna puas dengan penanganan (misalnya dengan survei) dan setuju laporan
incident ditutup.
Problem
Management yakni proses menganalisis dan myelesaikan akar penyebab incident.
Reactive
Problem Management merupakan tindakan mencari akar permasalahan dan
menyelesaikan dipicu oleh sebuah/lebih kejadian (atau sebagai reaksi dari)
incident.
Proactive
Problem Management merupakan tindakan mencari dan menyelesaikan akar sebuah
masalah tanpa menunggu incident terjadi.
Aktivitas-aktivitas
dalam problem management mirip dengan aktivitas dari incident management, yang
biasanya dilakukan secara periodik/terjadwal (misal sebulan sekali atau tiga
bulan sekali).
Langkah-langkah
problem management:
a. Problem
detection and problem logging diawali dengan aktivitas mengenali (detection)
dan mencatat penyebab masalah (problem).
b. Problem
categorization and prioritization setiap problem dikategorisasi dan ditentukan
dengan prioritasnya.
c. Problem
investigation and diagnosis ialah tim teknis dapat juga bekerja sama dengan
supplier, melakukan sebuah investigasi menemukan akar permasalahan layanan TI
tertentu dan pilihan-pilihan solusinya.
d. Mencatat
sebuah known error dan disimpan ke known error database (KEDB).
e. Problem
resolution berdasarkan hasil problem investigation and diagnosis, selanjutnya
pilihan solusi atau workaround diaplikasikan untuk menyelesaikan problem.
f. Problem
closure artinya ketika sebuah permasalahan telah selesai diatasi dan catatan
known error juga telah dibuat, lalu diberistatus selesai dan ditutup.
g. Major
problem reviews dibuat khusus untuk permasalahan-permasalahan yang memiliki
dampak besar bagi bisnis.
Request
Fulfillment yakni proses memenuhi permintaan pengguna layanan TI, diluar
laporan terkaitdengan incident TI.
Service desk
bertugas memilah panggilan/laporan yang masuk apakah sebagai sebuah laporan
incident, permintaan akses, atau permintaan lainnya.
Aktivitas-aktivitas
dalam request fulfillment
1. Receive,
request, request logging dan validation.
2. Request
categorization, request prioritization.
3. Request
authorization.
4. Request
review, request model execution.
5. Request
closure.
Access
Management yakni proses pengelolaan hak akses pengguna ke sistem layanan TI.
Aktivitas-aktivitas
dalam access management:
1. Permintaan
akses
2. Verifikasi
3. Menyediakan
hak akses
4. Memonitor
status identitas, mencabut, membatasi hak akses
5. Pencatatan
dan penelusuran aktivitas akses
1.3
Continual
Service Improvement
Continual Service
Improvement (CSI) bertanggung jawab untuk memastikan bahwa perbaikan ini
diidentifikasi dan diimplementasikan. Kinerja penyedia layanan TI terus diukur
dan perbaikan dilakukan pada proses, layanan TI dan infrastruktur TI untuk
meningkatkan efisiensi, efektivitas, dan efektivitas biaya.
Continual Service
Improvement (CSI) bertujuan untuk memberikan nilai bisnis dengan memastikan
bahwa penerapan manajemen layanan terus memberikan manfaat bisnis yang
diinginkan.
Tujuan continual
service improvement sebagai berikut:
1. Untuk
meninjau, menganalisis, dan membuat rekomendasi tentang di mana perbaikan dapat
dilakukan pada titik mana pun sepanjang siklus hidup.
2. Untuk
meninjau dan menganalisis pencapaian tingkat layanan terhadap target.
3. Untuk
mengidentifikasi dan mengimplementasikan kegiatan individu untuk meningkatkan
kualitas layanan dan efisiensi dan efektivitas proses manajemen layanan.
4. Untuk
meningkatkan efektivitas biaya pengiriman layanan TI tanpa mempengaruhi
kepuasan pelanggan.
5. Menerapkan
metode manajemen mutu untuk mendukung peningkatan berkelanjutan.
Cakupan dari CSI berlaku di semua
tahap siklus hidup layanan dan tiga bidang utama:
a. Kesehatan
keseluruhan manajemen layanan sebagai suatu disiplin.
b. Keselarasan
berkesinambungan dari portofolio layanan dengan kebutuhan bisnis saat ini dan
masa depan.
c. Kematangan
proses TI yang memungkinkan.
Nilai untuk bisnis CSI mengakui bahwa
nilai yang diberikan TI untuk bisnis dapat direalisasikan dan diukur dengan
cara yang berbeda:
a. Improvement:
Hasil yang lebih baik bila dibandingkan dengan kondisi sebelumnya.
b. Benefits:
Keuntungan yang dicapai melalui perbaikan yang diterapkan.
c. Return
on Investment (ROI): Perbedaan antara manfaat yang direalisasikan dan biaya
pencapaiannya.
d. Value
on Investment (VOI): Nilai ekstra yang diciptakan oleh peningkatan termasuk
manfaat dan hasil non-moneter.
ITIL merekomendasikan agar daftar CSI
disimpan untuk mencatat peluang peningkatan dan mengelompokkannya menjadi
kecil, menengah dan besar. Waktu yang diharapkan untuk menerapkan setiap
peluang bersama dengan manfaat yang diantisipasi dan terukur juga harus
ditunjukkan.
1.4
Financial
Management For IT Services
Manajemen Keuangan
adalah suatu kegiatan perencanaan, penganggaran, pemeriksaan, pengelolaan,
pengendalian, pencarian dan penyimpanan dana yang dimiliki oleh organisasi atau
perusahaan.
Penjelasan singkat
masing-masing fungsi manajemen keuangan:
1. Perencanaan
euangan membuat rencana pemasukan dan pengeluaraan serta kegiatan-kegiatan
lainnya untuk periode tertentu.
2. Penganggaran
keuangan tindak lanjut dari perencanaan keuangan dengan membuat detail
pengeluaran dan pemasukan.
3. Pengelolaan
keuangan menggunakan dana perusahaan untuk memaksimalkan dana yang ada dengan
berbagai cara.
4. Pencarian
keuangan mencari dana mengeksploitasi sumber dana yang ada untuk operasional
kegiatan perusahaan.
5. Penyimpanan
keuangan mengumpulkan dana perusahaan serta menyimpan dana tersebut dengan
aman.
6. Pengendalian
keuangan melakukan evaluasi serta perbaikan atas keuangan dan sistem keuangan
pada perusahaan.
7. Pemeriksaan
keuangan melakukan audit internal atas keuangan perusahaan yang ada agar tidak
terjadi penyimpangan.
Tugas
pokok manajemen keuangann.
Tugas-tugas
dasar yang diemban oleh seorang manajer keuangan secara umum adalah:
1. Mendapatkan
dana perusahaan
2. Menggunakan
dana perusahaan
3. Membagi
keuntungan atau laba perusahaan
Tujuan
manajemn keuangan adalah dengan adanya manajer keuangan untuk mengeloka dana
perusahaan pada suatu perusahaan secara umum adalah untuk memaksimalisasi nilai
perusahaan. Dengan demikian apabila suatu saat perusahaan dijual maka harganya
dapat ditetapkan setinggi mungkin.
1.5
Demand
Management
Manajemen
Permintaan adalah modul gerbang dalam sistem MPC, menyediakan link ke pasar,
SOP dan MPS. Komunikasi antara DM dan pasar adalah komunikasi dua arah antara
pengumpulan informasi dari pelanggan & menginformasikan status pesanan
pelanggan.
Informasi yang
diberikan kepada SOP digunakan untuk mengembangkan penjualan dan rencana
operasi meliputi satu tahun atau lebih dalam durasi pada tingkat tinggi
agregasi. Urutan kedua penjualan dan perkiraan informasi diberikan kepada
sistem MPS. Hal ini dalam sistem MPS yang jangka pendek, rencana produk
manufaktur yang spesifik dikembangkan & dikendalikan sebagai permintaan
aktual menjadi tersedia dan informasi tersedia untuk memberikan janji
pengiriman dan status pesanan kepada pelanggan.
Perencanaan dan
Pengendalian
Bagian perencanaan
dari perencanaan manufaktur dan kontrol melibatkan penentuan kapasitas yang
diperlukan untuk memenuhi tuntutan masa depan yang sebenarnya. Bagian kontrol
menentukan bagaimana kapasitas akan dikonversi menjadi produk sebagai pesanan
masuk. Perusahaan mengeksekusi rencana sebagai informasi permintaan aktual yang
telah tersedia. Fungsi kontrol menentukan bagaimana perusahaan akan memodifikasi
titik terang kesalahan perkiraan dari rencana dan perubahan dalam asumsi
lainnya.
Forecast dan
Rencana
Perbedaan antara pola
permintaan dan respon oleh perusahaan menunjukkan perbedaan penting antara
proyeksi dan rencana. Dalam manajemen permintaan, perkiraan jumlah & waktu
permintaan pelanggan dikembangkan. Ini adalah perkiraan apa yang mungkin
terjadi di pasar. Manufaktur rencana yang menentukan bagaimana perusahaan akan
merespon didasarkan pada ramalan-ramalan tersebut.
Demand Management
and the MPC Environment
Aktivitas
manajemen permintaan harus sesuai dengan strategi perusahaan, capabilitas dari
manufaktur, dan kebutuhan konsumen. kunci untuk klasifikasi ini adalah konsep
customer order decoupling point atau, yang biasa disebut the order penetration
point. customer order decoupling point dapat dilihat sebagai poin dimana
permintaan berubah dari independen menjadi dependen. Ini poin dimana perusahaan
menjadi bertanggung jawab dalam menentukan waktu dan kuantitas material yang
dibeli, dibuat, atau diselesaikan. Perbedaan lokasi customer order decoupling
point menimbulkan perbedaan kategori lingkungan manufaktur.
Make-to-stock (MTS)
Environment.
Di dalam MTS
environment, kunci fokus aktivitas manajemen permintaan adalah pada
pemeliharaan persediaan barang jadi. Di lingkungan ini, ketika konsumen membeli
langsung dari persediaan yang tersedia, pelayanan pelanggan ditentukan dengan
apakah jumlah mereka di dalam stok atau tidak.
Aspek kunci dari
manajemen persediaan barang jadi adalah penentuan kapan, berapa banyak, dan
bagaimana mengisi kembali stok di lokasi spesifik. Ini adalah perhatian
distribusi fisik di dalam manajemen permintaan. Beberapa perusahaan MTS
mempekerjakan perencana gudang, pusat distribusi, gudang lokal, dan bahkan
vendor-managed inventory didalam lokasi konsumen mereka. Manajemen dari rantai
pasokan memerlukan informasi dalam status persediaan di dalam berbagai lokasi,
hubungan dengan penyedia transportasi, dan mengestimasikan permintaan konsumen
berdasarkan lokasi dan jumlah.
Banyak perusahaan
MTS berinvestasi dalam program lean manufacturing dalam permintaan untuk
menggeser trade-off, dll untuk mencapai level layanan yang lebih tinggi untuk
pemberian investasi persediaan. Tanpa memperhatikan bagaimana trade-off keluar,
fokus manajemen permintaan di dalam lingkungan MTS adalah dalam menyediakan
barang jadi dimana dan kapan konsumen menginginkannya.
Contohnya yaitu
perusahaan mie instan seperti Indomie. Perusahaan ini terus menerus melakukan
proses produksi agar tetap memiliki persediaan kapanpun dan dimanapun konsumen
membutuhkannya. Produksi dilakukan secara masal dalam jumlah yang besar.
Kemudian produk-produk mie instan tersebut didistribusikan ke seluruh lokasi
sehingga ketika konsumen menginginkannya, mereka akan mendapatkan produk
tersebut dengan mudah.
Assemble-to-order
(ATO) Environment
Dalam lingkungan
assemble-to-order, tugas utama manajemen permintaan adalah untuk menetapkan
pesanan konsumen di dalam komponen alternatif dan pilihan. Itu penting untuk memastikan
bahwa mereka dapat dikombinasikan kedalam produk yang dapat terus berjalan di
dalam proses yang dikenal sebagai configuration management. satu dari
kapabilitas yang diperlukan untuk sukses dalam lingkungan ATO adalah rekayasa
desain yang dapat fleksibel di dalam mengkombinasikan komponen, pilihan, dan
modul kedalam barang jadi yang memungkinkan.
Contoh industri
yang menerapkan sistem produksi ini adalah industri komputer, misalnya
toko-toko ritel di Hi-Tech Mall. Mereka memiliki persediaan bahan baku untuk
merakit sebuah komputer. Akan tetapi, perakitan dari komponen-komponen komputer
tersebut baru akan dilakukan apabila ada permintaan dan perakitan tersebut
disesuaikan dengan permintaan dan kebutuhan konsumen.
Make
(Engineer)-to-order (MTO) Environment
Di dalam lingkungan
make-to-order dan engineer-to-order, ada sumber daya lain yang diperlukan untuk
diambil kedalam akun yaitu engineering (keahlian teknik). Perpindahan customer
order decoupling point ke bahan mentah atau bahkan pemasok menaruh informasi
permintaan independen lebih lanjut ke dalam perusahaan dan menurunkan cakupan
informasi permintaan dependen. Oleh karena itu, yang diperlukan untuk
mendapatkan spesifikasi produk dari konsumen dan mengartikannya kedalam istilah
manufaktur di dalam perusahaan. Ini berarti bahwa tugas manajemen permintaan di
dalam lingkungan ini adalah untuk mengkoordikasikan informasi dalam produk yang
dibutuhkan konsumen dengan keahlian teknik.
Kebutuhan untuk
sumber daya keahlian teknik di dalam kasus engineer-to-order sedikit berbeda
dengan di dalam kasus make-to-order. Di dalam lingkungan make-to-order,
keahlian teknik menentukan material apa yang akan diperlukan, langkah apa yang
akan diperlukan di dalam manufaktur, dan biaya yang dilibatkan. Material dapat
datang dari persediaan perusahaan atau dibeli dari pemasok. Di dalam lingkungan
engineering-to-order, kebanyakan informasi yang sama ini diperlukan dari
konsumen, meskipun kebanyakan detail desain mungkin ditinggalkan untuk teknisi
dari pada konsumen. karena kebutuhansumber daya keahlian teknis di dalam
lingkungan ini, tugas peramalan manajemen permintaan sekarang termasuk
menentukan berapa banyak kapasitas keahlian teknis yang akan diperlukan untuk
memenuhi kebutuhan konsumen di masa depan.
DAFTAR PUSTAKA
Sumber :Susanto, Tony.D.2016.Manajemen Layanan Teknologi
Informasi.Surabaya;Asosiasi Sistem Informasi Indonesia (AISINDO)
Comments
Post a Comment