Layanan Operasi adalah fase siklus hidup manajemen layanan TI yang bertanggung jawab untuk "bisnis seperti biasa" kegiatan. Jika layanan tidak dimanfaatkan atau tidak disampaikan secara efisien dan efektif, mereka tidak akan memberikan nilai penuh mereka, tanpa memperhatikan di seberapa baik dirancang mereka mungkin. Ini adalah layanan operasi yang bertanggung jawab untuk memanfaatkan proses untuk memberikan layanan kepada pengguna dan pelanggan.

Layanan operasi merupakan nilai yang telah dibentuk dalam strategi pelayanan dan dikonfirmasi melalui desain layanan dan transisi layanan yang sebenarnya telah disampaikan.Jika tidak menjalankan dan memanfaatkan layanan operasi seperti yang dirancang, tidak akan ada kontrol dan manajemen layanan.

Tujuan Operasi Layanan

Tujuan dari layanan operasi untuk mengatur dan melakukan kegiatan serta proses yang diperlukan untuk memberikan layanan kepada pengguna bisnis pada tingkat yang disepakati layanan. Selain itu, layanan operasi bertanggung jawab untuk manajemen berkelanjutan dari teknologi (infrastruktur dan aplikasi) yang digunakan untuk menyampaikan dan mendukung layanan.

Layanan Operasi adalah tindakan balancing. Ini bukan hanya soal melaksanakan proses hari ke hari. Ada dinamis ‘perdebatan’ yang berlangsung pada empat tingkat.

Ini dikenal sebagai “Four Balances of Service Operation” :

1. Internal IT View Versus External Business View

Individu atau tim yang bertanggung jawab untuk menjalankan komponen tertentu mungkin tidak mengerti bagaimana komponen mereka cocok dengan keseluruhan pengiriman layanan tertentu. Jika sebuah organisasi terlalu fokus pada eksternal, ada risiko pejanjian akan dibuat dengan bisnis yang benar – benar tidak tersampaikan karena kurangnya pemahaman tentang bagaimana bagian-bagian konstituen internal yang perlu untuk beroperasi. Sebaliknya, sebuah organisasi yang berfokus terlalu internal cenderung berjuang untuk memahami dan memberikan kebutuhan bisnis.

2. Stability Versus Responsiveness

Perubahan sering menjadi penyebab insiden dan hilangnya ketersediaan, sehingga mungkin tergoda untuk membatasi jumlah perubahan dalam rangka untuk meningkatkan stabilitas layanan. Namun, perubahan akan selalu dibutuhkan untuk menjaga layanan up to date dan untuk mengadopsi kebutuhan perkembangan bisnis.

3. Quality of Service versus Cost of Service

Untuk meningkatkan kualitas layanan IT selagi mengendalikan biaya, tekanan pembiayaan yang intens dapat berujung pada penurunan tingkat dalam layanan dengan lebih banyak kegagalan dalam kurangnya dukungan. Disamping itu organisasi yang kehilangan keseimbangan di sisi lainnya akan banyak membayar untuk layanan yang tidak dapat dibenarkan. Kuncinya adalah mendapatkan hasil di atas modal, meyakinkan bahwa bisnis telah sepenuhnya memahami apa yang akan didapat dan apa yang tidak didapat untuk beberapa jumlah uang dan apa yang didapat jika menghasilkan dana kurang/lebih.

4. Reactive versus proactive

Organisasi yang kelewat proaktif akan memprediksikan beberapa hal akan gagal dan melakukan upaya untuk mencegah situasi. Terlebih lagi organisasi dapat terus-menerus mengganti dan menggunakan perubahan yang tidak perlu. Sebaliknya organisasi yang reaktif akan menghabiskan waktuya “melawan api” dan berurusan dengan situasi yang akan datang dan mereka harus bertindak lebih banyak untuk “mengatasi api” yang mendekat dan menghadapi kegagalan dan masalah.

Nilai Layanan Operasi

Tiap bagian dari siklus layanan ITIL menambah dan menghasilkan nilai kepada bisnis. Layanan operasi melakukan ini bersamaan dengan proses dan menjalankan layanan yang diinginkan oleh strategi layanan, konsep layanan dan tingkatan transisi layanan dari suatu siklus. Layanan operasi adalah hal yang terlihat oleh organisasi IT dan sangat dekat dengan pengguna dan pelanggan. Penyampaian yang efektif dan efisien adalah yang diharapkan dari layanan operasi

Fungsi dan Aktifitas utama

Fungsi dan Aktifitas Utama

Fungsi dan aktifitas utama yang dilakukan oleh layanan operasi adalah

1. Event Manajemen/ Manajemen Kegiatan

Ini adalah proses yang bertanggung jawab untuk memonitor semua kegiatan melalui infrastruktur IT dan aplikasi untuk menentukan operasi normal, manajemen kegiatan berfungsi meningkatkan dan bertindak akan semua hal.

2. Manajemen Insiden

Proses untuk menangani semua insiden. Mungkin insiden di mana layanan sedang terganggu atau di mana layanan belum terganggu.

3. Permintaan pemenuhan

Proses yang mengambil beberapa permintaan dari pengguna. Pemenuhan permintaan meliputi perubahan permintaan, permintaan untuk informasi dan keluhan, dari sudut pandang bagian layanan, proses dari pemenuhan permintaan bertujuan untuk menanggung semua panggilan yang berkaitan dengan masalah.

4. Masalah manajemen

Proses ini bertanggung jawab untuk memanajemen segala permasalahan pada infrastruktur IT, proses ini termasuk analisis pada akar maslaah, hingga sampai pada solusi masalah, manajemen masalah tetap bertanggung jawab hingga resolusi yang diimplementasikan lewat proses dan manajemen perubahan dan manajemen pengeluaran.

5. Managemen Access

Proses ini memungkinkan pengguna untuk mengakses aplikasi atau layanan. Ini juga memastikan bahwa tanpa otorisasi tidak dapat mengakses aplikasi dan layanan. Manajemen akses memungkinkan organisasi untuk mengontrol akses kedalam aplikasi dan layanan.

Fungsi Operasi Layanan

1. Layanan meja

Bagian ini mengadakan sejumlah proses, dalam beberapa kegagalan manajemen dan pemenuhan permintaan. Bagian layanan terbentuk dari sekelompok staff terlatih untuk berurusan dengan kegiatan layanan. Staff bagian layanan akan mempunyai akses kepada alat yang bersangkutan untuk mengatur kegiatan. Staff bagian layanan seharusnya menjadi kontak untuk pengguna IT melalui organisasi

2. Manajemen Teknis

Ini adalah fungsi yang menghasilkan sumber daya dan meyakinkan bahwa pengetahuan tentang teknologi tersebut selalu up to date. Manajemen teknis meliputi semua tim/area yang mendukung penyampaian dan pengetahuan teknis dan keahlian, ini meliputi tim seperti jaringan, mainframe midware desktop, server dan database.

3. Manajemen Aplikasi

Ini akan mengatur aplikasi melalui keseluruhan siklusnya. Ini dimulai dari ide awal bisnis dan selesai ketika aplikasi telah masuk kedalam layanan. Manajemen aplikasi ini tergabung dalam desain, pengembangan berkala dan layanan pendukung aplikasi.

4. Manajemen operasional TI

Ini bertanggung jawab untuk mengoperasikan organisasi IT infrastruktur dan aplikasi kedalam keseharian. Area yang menyampaikan nilai telah dibentuk dan dikonsep di suatu bagian, jadi layanan akan mempunyai beberapa interaksi kedalam proses yang menjadi bagian dari fase keseharian, pada beberapa asset layanan dan konfigurasi manajemen, kelangsungan manajemen layanan IT dan bagian layanan manajemen.

Kesimpulan

Operasi layanan adalah fase siklus hidup manajemen layanan TI yang bertanggung jawab untuk ‘bisnis seperti kegiatan biasa’. Jika layanan tidak dimanfaatkan atau tidak disampaikan secara efisien dan efektif, mereka tidak akan memberikan nilai penuh, terlepas dari kemungkinan seberapa baik mereka dirancang. Ini adalah layanan operasi yang bertanggung jawab untuk memanfaatkan proses untuk memberikan layanan kepada pengguna dan pelanggan.

Operasi layanan memiliki maksud dan tujuan dimana mereka mengatur dan melakukan kegiatan serta proses yang diberikan untuk memberikan layanan kepada pengguna bisnis pada tingkat yang disepakati oleh layanan.

Ada 4 tingkat atau dikenal dengan “empat keseimbangan operasi layanan” yaitu :

1. Tampilan TI Internal Vs Tampilan Bisnis Eksternal

2. Stabilitas Vs Tanggap

3. Kualitas Layanan VS Biaya Layanan

4. Reaktif VS Proaktif

Contoh Kasus

KPP Pratama Salatiga

Kantor Pelayanan Pajak (KPP) Pratama Salatiga merupakan salah satu instansi pemerintahan yang bergerak dalam urusan perpajakan di kota Salatiga dan Kabupaten Semarang yang menerapkan Teknologi Informasi dalam melayani wajib pajak. Peninjauan kualitas layanan IT salah satunya menggunakan ITIL V3. Penelitian ni mengunakan subdomain Service Operation yang memiliki fokus Event Management,problem Management, Request Fullfill,Access Management,Incident Management sebagai kerangka penelitian. Penelitian ini akan menilai sejauh mana kualitas layanan IT yang telah tercipta dalam seksi pelayanan khususnya pada bagian NPWP. Metode yang digunakan adalah metode kualitatif dengan pendekatan induktif dan metode pengumpulan data berupa wawancara dan observasi. Hasil penelitian menunjukkan bahwa pencapaian dan penerapan kualitas layanan TI belum maksimal dalam penerapannya dikarenakan system kerja yang praktis dan teknis dibandingkan dengan kerangka kerja ITIL V3 yang bersifat tersrtuktur dan procedural. Alasan Tata kelola TI belum maksimal dikarenakan terjadi kendala teknis seperti server internet down dan kesalahan pengguna dalam penginputan data.

Financial Management For IT Services

Tidak ada bisnis yang bisa bertahan lama, apalagi berkembang, jika gagal mengelola uangnya secara efektif. Seperti bisnis lainnya, penyedia layanan TI, apakah dijalankan sebagai bisnis komersial atau tidak, memerlukan pengelolaan keuangan yang baik. Ini harus memastikan bahwa ia memiliki jumlah uang yang tepat untuk menjalankan rencananya, untuk memastikan bahwa ia mengerti bagaimana uangnya digunakan, untuk menentukan apakah uang tersebut telah digunakan secara efektif atau apakah investasi baru yang diusulkan itu masuk akal.

Manajemen keuangan adalah tentang menjaga sumber keuangan organisasi, memastikan bahwa mereka dipekerjakan dengan bijaksana dan penggunaannya benar. Manajemen keuangan memastikan organisasi memiliki pemahaman tentang biaya operasinya, struktur biaya ini dan hal-hal yang memengaruhinya.

Manajemen keuangan membantu perencanaan keuangan, memastikan bahwa rencana organisasi sesuai dengan kemampuannya untuk mendukung biaya keuangan dan mengelola risiko. Ini mencatat pengeluaran sehingga jelas bagaimana uang itu digunakan.

Tujuan

Tujuan pengelolaan keuangan untuk layanan TI adalah untuk memastikan bahwa penggunaan optimal dibuat dari sumber keuangan organisasi dan ini dicapai sesuai dengan kerangka peraturan di mana penyedia layanan TI beroperasi.

Tujuan pengelolaan keuangan adalah untuk memastikan bahwa:

Uang dikelola dan dihabiskan dengan bijak;
Sumber keuangan yang tersedia sepenuhnya sesuai dengan rencana dan persyaratan organisasi untuk penyediaan layanan TI;
Keputusan investasi sesuai dan sesuai dengan tujuan organisasi;
Risiko keuangan diidentifikasi dan dikelola secara efektif;
Pengaturan tata kelola dilakukan untuk memastikan pengelolaan sumber keuangan yang efektif dan untuk menentukan akuntabilitas yang jelas;
Organisasi mematuhi semua kewajiban peraturan keuangan yang relevan dan keseluruhan kebijakan dan strategi keuangan bisnis.

Tujuan utamanya adalah untuk memastikan bahwa:

Ada sistem yang efektif untuk perencanaan dan penganggaran keuangan;
Rencana keuangan dan alokasi anggaran disesuaikan dengan portofolio layanan;
Semua investasi yang diajukan memiliki kasus bisnis yang memenuhi standar organisasi;
Semua risiko keuangan yang signifikan diidentifikasi dan dikelola sepenuhnya;
Ada kerangka tata kelola yang tepat yang sesuai dengan akuntabilitas yang jelas dan semua pihak yang perlu dilatih dengan benar sehubungan dengannya;
Semua pengeluaran keuangan diperhitungkan dengan benar dan ada proses audit untuk memastikan pengelolaan sumber keuangan yang tepat;
Biaya dan nilai semua layanan, proses dan aktivitas TI dipantau, diukur dan dipahami serta tindakan yang tepat dilakukan atas dasar kinerja keuangan mereka.

Aktivitas Dan Konsep

Penganggaran Penting untuk merencanakan ke depan untuk memastikan bahwa rencana bisnis sesuai dengan uang yang tersedia. Produk dari perencanaan ini adalah rencana keuangan atau anggaran yang mencakup pengeluaran dan pendapatan yang diharapkan untuk periode tertentu, biasanya pada tahun (keuangan).

Anggaran harus mencerminkan layanan yang akan disampaikan, proyek baru, investasi dan rencana perubahan lainnya. Ini bukan sebuah artikulasi dari apa yang bisnis ingin lakukan:

Ini tentang apa yang bisa dicapai secara realistis. Meski begitu, anggaran adalah rencana dan rencana tidak selalu berhasil. Anggaran harus menjadi prediksi terbaik yang dapat dibuat oleh sebuah organisasi, namun harus mencakup beberapa kontinjensi yang tak terduga.

Akuntansi

Proses dalam akuntansi TI memungkinkan penyedia layanan TI memperhitungkan pengeluaran dan pendapatan, memberikan rincian tentang bagaimana biaya dan pendapatan dibagi antara pelanggan, layanan dan aktivitas. Analisis ini membantu menentukan efektivitas biaya layanan untuk membuat keputusan yang tepat mengenai hal tersebut.

Pengisian

Keputusan apakah akan menagih adalah keputusan strategis yang harus diambil dengan hati-hati. Pengisian tidak hanya meningkatkan biaya operasional penyedia layanan TI, namun juga meningkatkan akuntabilitas, keterpaparan dan transparansi. Pengisian menyediakan sarana untuk mempengaruhi perilaku pelanggan, membentuk permintaan dan penggunaan untuk menyesuaikan kapasitas, sehingga mengurangi biaya dan risiko. Tanpa pengisian, banyak pelanggan dan pengguna akan melihat layanan TI sebagai gratis dan akan menuntut layanan ini dengan sedikit minat terhadap implikasi keuangan atau operasional.

Kasus bisnis

Kasus bisnis adalah alat pendukung keputusan dan perencanaan yang memproyeksikan kemungkinan konsekuensi tindakan bisnis. Inti dari kasus bisnis biasanya merupakananalisis keuangan, namun pembenaran investasi seringkali bergantung pada pertimbangan finansial.

Contoh

Seorang pejabat setempat ingin mendirikan sebuah layanan untuk segera mengidentifikasi apakah seorang anak sebelumnya telah diidentifikasi beresiko. Jika seorang anak muncul di rumah sakit setempat dan bagian gawat darurat, dokter tugas akan dapat memeriksa rincian anak-anak tersebut di Register Resiko dan memberitahukan Pelayanan Sosial jika ada hasil yang positif. Ini melibatkan investasi yang cukup besar dalam sistem TI dan layanan pendukung namun tidak ada keuntungan finansial langsung. Namun demikian, manfaat potensial (mis., Untuk menghindari kematian atau cedera anak yang tidak perlu berisiko) mengesampingkan biaya finansial.

Manajemen keuangan, bersama dengan manajer bisnis dan pemangku kepentingan utama lainnya, akan menilai kasus bisnis terkait dengan skala investasi dan tingkat pengembalian yang diantisipasi, dampaknya terhadap bisnis, skala waktu untuk realisasi tunjangan, risiko dan kontinjensi yang terkait , kekokohan tokoh dan kepekaannya terhadap perubahan. Semua ini harus dicakup dalam kasus bisnis yang sehat.

Adalah penting bahwa kasus bisnis memperjelas bagaimana manfaat dan biaya telah dinilai, asumsi yang diandalkan dan tingkat kepercayaan pada angka tersebut. Kasus bisnis terkadang bergantung pada pandangan optimis atau bahkan meragukan masa depan, dan sangat penting bahwa hal ini dijelaskan kepada para pengambil keputusan.

Hubungan Dengan Proses Manajemen Layanan Lainnya

Manajemen keuangan untuk layanan TI sangat penting bagi manajemen layanan TI, dan memiliki hubungan dengan banyak disiplin manajemen layanan lainnya. Interaksi kunci adalah dengan manajemen tingkat layanan, manajemen portofolio layanan, manajemen kapasitas dan aset layanan dan manajemen konfigurasi.

Manajemen tingkat layanan

Manajemen tingkat layanan (SLM) perlu bekerja sama dengan manajemen keuangan sehubungan dengan biaya tingkat layanan yang diusulkan yang dibutuhkan untuk memenuhi kebutuhan bisnis organisasi saat ini dan yang direncanakan.

Pengelolaan portofolio layanan

Manajemen keuangan berkaitan dengan pengembangan kasus bisnis, penilaian peluang investasi, evaluasi opsi layanan yang berbeda, evaluasi risiko keuangan dan penentuan nilai layanan. Semua ini penting bagi keputusan tentang apa yang harus disertakan dalam portofolio layanan atau dihapus dari situ. Manajemen keuangan dapat memberikan kontribusi pada keputusan tentang bagaimana cara terbaik untuk menyediakan layanan yang diberikan, apakah ini harus melalui penyedia layanan TI in-house atau penyedia pihak ketiga.

Layanan aset dan manajemen konfigurasi

Manajemen aset dan konfigurasi layanan mengelola dan mengelola database manajemen konfigurasi (CMDB), yang menyimpan informasi keuangan dan informasi lainnya mengenai aset yang dibutuhkan oleh manajemen keuangan untuk berbagai kegunaan. Misalnya, dari CMDB, dimungkinkan untuk mengidentifikasi semua komponen yang dibutuhkan untuk memberikan layanan tertentu dan informasi ini digunakan oleh manajemen keuangan untuk menentukan keseluruhan biaya layanan. CMDB juga menyimpan informasi mengenai aset, seperti tanggal penggantian peralatan dan tanggal terminasi / perpanjangan lisensi, yang dapat digunakan dalam pengembangan anggaran dan perencanaan keuangan jangka panjang.

Manajemen hubungan bisnis

BRM membantu manajemen keuangan untuk layanan TI untuk memahami bagaimana pelanggan menilai nilai yang mereka dapatkan dari layanan TI dan apa yang mereka siap bayar untuk mereka. BRM membantu pelanggan memahami kebijakan keuangan, biaya, risiko dan masalah lainnya dari penyedia layanan TI, dan menjelaskan bagaimana biaya penyedia layanan diterjemahkan ke dalam tagihan pelanggan.

Demand Management

Bab ini mencakup masalah yang berkaitan dengan bagaimana perusahaan mengintegrasikan informasi dari dan tentang konsumen, internal dan eksternal perusahaan, kedalam sistem perencanaan dan pengendalian manufaktur. Manajemen permintaan termasuk aktivitas yang berkisar dari menentukan atau memperkirakan permintaan dari konsumen, dengan mengkonversi pesanan-pesanan spesifik konsumen ke tanggal pengiriman yang dijanjikan, untuk membantu menyeimbangkan permintaan dengan persediaan. Jadi, manajemen permintaan digunakan untuk menggambarkan kegiatan peramalan permintaan, perencanaan, dan pemenuhan pesanan.

Demand Management in MPC system

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.

Contoh

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.

Contoh

jenis ini misalnya pada industri pakaian jadi yang bersifat ‘adi busana’, yang hannya membuat satu item untuk satiap jenis rancangannya. Perusahaan tidak manyimpan bahan baku yang dibutuhkan sabelum mendapatkan spesifikasi pesanan dari konsumen. Bahan baku dan proses produksi baru dilakukan hanya bila ada pesanan. Dengan demikian, biasanya biaya produksi yang dikeluarkan juga sangat mahal.

Continual Service Improvement (CSI)

Dalam topik ini kita akan membahas tentang Continual Service Improvement.

Modul ini memberikan panduan untuk menciptakan dan mempertahankan nilai bagi pelanggan melalui strategi, perancangan, transisi dan pengoperasian layanan yang lebih baik. Ini menggabungkan prinsip, praktik dan metode dari manajemen mutu, peningkatan manajemen dan peningkatan kemampuan.

Continual Service Improvement menggambarkan praktik terbaik untuk mencapai peningkatan skala besar dan bertahap dalam kualitas layanan, efisiensi operasional dan kelangsungan bisnis dan untuk memastikan bahwa portofolio layanan terus disesuaikan dengan kebutuhan bisnis.

Panduan disediakan untuk menghubungkan upaya perbaikan dan hasil dengan layanan strategi, desain, transisi dan layanan operasi. Ini menggabungkan prinsip, praktik dan metode dari manajemen mutu, peningkatan manajemen dan peningkatan kemampuan.

Sistem umpan balik loop tertutup, berdasarkan siklus Plan-Do-Check- Act (PDCA). Umpan balik dari setiap tahap siklus hidup layanan dapat digunakan untuk mengidentifikasi peluang peningkatan untuk tahap siklus hidup lainnya.

Gambaran dan tujuan peningkatan layanan Continual Service secara singkat akan melihat fase siklus hidup kelima ITIL yang merupakan CSI (Continual Service Improvement), poin yang akan dibahas adalah:

Menggambarkan Siklus PDCA Deming
Menggambarkan Pendekatan CSI
Pahami proses perbaikan Tujuh langkah
Mengukur CSI
Mendefinisikan Tata Kelola Perusahaan.
Menjelaskan Continual Service Improvement (CSI) dan siklus hidup layanan
Klasifikasi berbagai jenis metrik di CSI
Mengidentifikasi Alur Kinerja
Mendefinisikan Register CSI

Topik lainnya dalam Continual Service Improvement meliputi pengukuran layanan, menunjukkan nilai dengan metrik, pengembangan baseline dan penilaian kedewasaan.

Mengapa continual service improvement penting ?

Menyampaikan layanan TI (seperti e. G. A cloud) bukanlah sebuah proyek. Sebuah proyek adalah sesuatu yang tidak biasa dan memiliki awal dan akhir yang jelas. Menjalankan dan Mengoperasikan layanan TI adalah tugas yang terus menerus. Konsumen layanan mengharapkan layanan TI tersedia kapan pun mereka membutuhkannya. Layanan TI seharusnya digunakan secara teratur untuk tugas bisnis reguler dan untuk jangka waktu yang tidak terbatas. Bahkan jika layanan TI memiliki masa pakai terbatas, mereka diharapkan dapat menjalankan selama mungkin mempertahankannya.
Tidak ada layanan TI yang beroperasi tanpa kesalahan. Perilaku pengguna yang salah atau salah konfigurasi dapat menyebabkan kegagalan pengoperasian. Oleh karena itu layanan TI harus dijaga secara rutin. Karena layanan TI digunakan terus menerus, tugas perbaikan dan pemeliharaan tersebut harus dilakukan berulang kali. Sementara pengoperasian layanan TI yang biasa diharapkan berlanjut (atau setidaknya sangat dekat dengannya), gangguan layanan terjadi secara tak terduga dan tugas pemeliharaan dilakukan secara bertahap. Oleh karena itu peningkatan layanan disebut “berkelanjutan” dan bukan “terus menerus”.

Proses “Perbaikan 7-Langkah Terus Berkesinambungan” adalah praktik terbaik untuk memperbaiki layanan TI. Jika kita ingin membuat proses 7 langkah untuk layanan , kita harus menjelaskan bagaimana masing-masing langkah dapat diterapkan ke layanan. Kita harus mendefinisikan apa yang kita lakukan pada setiap langkah dan hasil apa yang kita harapkan dari setiap langkah. Definisi ini akan dijelaskan di 7 bagian berikut.

langkah 1. apa yang harus diukur ?

Untuk membandingkan konfigurasi sistem Anda sebelum dan sesudah perubahan, Anda harus mengukur konfigurasi. Tapi apa yang harus diukur? Pendekatan yang baik adalah menggunakan “faktor keberhasilan kritis” dan menyimpulkan “indikator kinerja utama” dari mereka. Faktor keberhasilan kritis adalah tujuan penting bagi organisasi yang menjalankan sistem. Haruskah perusahaan penyedia cloud dipandang sebagai penyedia yang sangat andal? Maka reliabilitas merupakan faktor penentu keberhasilan. Indikator kinerja utama adalah aspek dari sistem yang diamati yang mengindikasikan keberhasilan organisasi yang mengoperasikan sistem. Mereka dapat disimpulkan langsung dari faktor keberhasilan kritis. Jika e. G. Penyedia harus bisa diandalkan sistem cloud harus tersedia Sebagai langkah pertama dalam proses, Anda harus membuat daftar indikator kinerja utama: ini adalah aspek penting. Aspek semacam itu bisa jadi:

1. Tersedianya

2. Kinerja

3. Kapasitas

Pada tahap ini Anda seharusnya tidak terlalu spesifik mengenai metrik yang ingin Anda gunakan, karena jika tidak, Anda akan mulai membingungkan indikator kinerja utama dan metrik kinerja. Sementara indikator kinerja utama memberi tahu Anda apa yang harus diukur, metrik kinerja menentukan bagaimana hal itu dapat diukur. Jangan bingung apa dan bagaimana pengukurannya. Anda seharusnya hanya menyatakan indikator kinerja umum yang ingin Anda ketahui lebih lanjut seperti e. G. Anda ingin sistem operasi awan Anda tersedia dengan sangat baik atau Anda menginginkan agar konsumen layanan bekerja dengan contoh kinerja tinggi. Hasilnya selalu merupakan daftar aspek (positif) yang ingin Anda miliki di sistem Anda.

Untuk contoh ini kita katakan bahwa sistem operasi cloud seharusnya
Sangat tersedia: kami menginginkan downtime yang rendah dan dampak pemadaman kecil. Performa tinggi: kami menginginkan sistem operasi yang responsif dengan cepat.Sangat reseptif: kami ingin agar sistem operasi cloud memiliki ruang disk kosong yang cukup untuk mengendalikan mesin virtual, gambar disk, file dll.

langkah 2 apa yang bisa diukur ?

Begitu Anda memiliki daftar aspek, Anda harus mempertimbangkan bagaimana cara mengukurnya. Anda harus menentukan metrik kinerja untuk indikator kinerja utama. Ketersediaan bisa e. G. Diukur secara tidak langsung dengan mengukur downtime selama periode waktu tertentu. Kinerja dapat diukur dengan melakukan beberapa query dan mengukur waktu respon. Seperti yang bisa kita lihat, tidak semua indikator kinerja dapat diukur secara langsung. Kita harus membangun metrik untuk setiap indikator untuk mengukur suatu sistem.
Dalam contoh ini, kami menentukan metrik berikut:
Ketersediaan: Kami secara teratur memotret sistem operasi cloud. Jika terjadi pemadaman, kita mengukur downtime dan dampak dari outage. Kinerja: Permintaan uji (seperti misalnya mengunggah beberapa data ke sebuah instance) harus dikirim secara teratur ke sistem operasi . Waktu respon dari query harus diukur. Kapasitas: Penggunaan disk dari sistem operasi dapat diukur secara teratur.

langkah 3 kumpulkan data

Setelah kami menentukan metrik kinerja, kami harus memikirkan bagaimana kami dapat mengumpulkan data untuk menetapkan nilai ke metrik. Langkah ini adalah tentang pengembangan alat untuk pemantauan layanan. Kita harus memikirkan bagaimana kita bisa mengukur hal-hal seperti downtime, padam, waktu respon, dll. Dua teknik pengumpulan data sangat penting.

Polling layanan TI: Data dikumpulkan dengan pemungutan suara secara teratur terhadap layanan TI dan memeriksa kejadian beberapa peristiwa (seperti server e. Tidak tersedia). Mekanisme pemungutan suara harus dijalankan secara berkala selama jangka waktu tertentu.Pengukuran Langsung: Data dikumpulkan secara langsung dengan memeriksa beberapa nilai konfigurasi sistem. Cek hanya berjalan sekali pada satu titik waktu tertentu. Aspek penting adalah memilih waktu ketika kita mengukur sesuatu dan frekuensi pengukuran. Haruskah kita mengukur sesuatu sekali per hari atau sebaiknya kita mengukur sesuatu per jam atau bahkan per menit? Dan begitu kita memilih frekuensi, kita harus menentukan jangka waktu pengukuran yang harus dilakukan

Dalam contoh ini kita mengumpulkan data selama tiga bulan dan kita mengukur semuanya sesuai dengan frekuensi berikut. Dampak dan Downtime: Kita bisa jajak pendapat setiap 100 detik jika terjadi pemadaman. Jika sebuah outage terdeteksi, dampaknya dapat diukur secara langsung sebagai nilai yang telah ditentukan sebelumnya yang mengikuti model ketergantungan kami. Response Time: Setiap jam kita bisa memulai script yang menjalankan beberapa query tes. Dengan demikian kami mengukur waktu penyelesaian kueri. Nilai waktu respon kemudian disimpan sebagai data . Pemanfaatan disk: Metrik ini tidak perlu sering disurvei. Hal ini dapat diukur setiap hari dengan menggunakan teknik pengukuran langsung. Kami hanya memeriksa ruang disk yang tersedia dan membaginya dengan total ruang disk yang tersedia Dengan menggunakan teknik pengumpulan data yang dijelaskan di atas, kami mengumpulkan nilai untuk dampak, waktu henti, waktu tanggap dan pemanfaatan disk.

langkah 4 proseskan data

Data yang terkumpul harus diproses sekarang agar bisa dianalisis. Pada tahap ini kita harus memikirkan fungsi agregasi dan bagaimana mengelompokkan agar bisa membuat pernyataan bermakna tentang data yang terkumpul.Ketika kami mengumpulkan data selama tiga bulan, kami tidak dapat melakukan sesuatu yang berguna dengannya jika kami tidak mengumpulkan keseluruhan data. Kita bisa mengumpulkan data yang terkumpul atau menghitung rata-rata. Fungsi agregasi bergantung pada skala data yang kami kumpulkan: jika kami mengumpulkan e. G. Hanya data kategoris, kita hanya bisa menghitung kejadian nilai. Jika data bisa dibawa ke dalam beberapa urutan yang berarti, kita bisa meringkas nilai. Jika data minimal berskala interval kita bisa menghitung rata-rata. Fungsi agregat penting lainnya adalah nilai maksimum dan minimum

Untuk contoh ini, kami memilih fungsi agregasi berikut :

Total Impact dan total downtime: Setiap kali kita mendeteksi outage, dampak dan downtime yang diderita dicatat. Untuk mengumpulkan data, kami menyimpulkan semua downtime yang diderita dan dampak dari padam. Waktu respon rata-rata: Kami jajak pendapat waktu respon awan secara teratur, tetapi untuk mendapatkan hasil agregat kita harus menghitung rata-rata waktu respon. Pemanfaatan disk maksimal: Sebaiknya gunakan utilisasi maksimal dari penggunaan rata-rata karena kita harus mencari tahu apakah ambang batas kritis tercapai. Jika disk penuh, data tambahan tidak dapat disimpan. Oleh karena itu penggunaan disk puncak adalah nilai yang ingin kita monitor.

Agar data dapat dianalisis, kita juga harus memikirkan penyebaran data. Fungsi agregat sangat sensitif terhadap nilai ekstrim dan outlier. Outlier langka dapat mendistorsi nilai rata-rata. Jika kita memiliki e. G. Banyak waktu respon singkat dan kemudian tiba-tiba nilai yang sangat besar (e. G adalah prosedur batch intensif CPU), rata-rata akan mendapatkan nilai yang besar yang tidak terlalu representatif terhadap pengukuran sebenarnya.

Dispersi berfungsi seperti e. G. Varians dan standar deviasi adalah fungsi untuk mengukur sejauh mana data tersebut berada jauh dari nilai rata-rata. Mereka sangat berguna bila kita ingin tahu lebih banyak tentang keberuntungan nilai rata-rata, Oleh karena itu kita juga harus mendefinisikan fungsi disperse yang ingin kita ukur

Untuk contoh ini, kami memilih pengukuran disperse berikut ini

Rentang dampak dan waktu henti: Karena dampak dan waktu henti diukur dari segi frekuensi (dampak dan kenaikan waktu turun saat terjadi padam), kita harus memilih kisaran (perbedaan antara waktu henti minimum dan downtime maksimum) sebagai ukuran disperse. Dengan mengumpulkan data ini kita bisa mencari tahu e. G. Jika kita memiliki lebih sedikit pemadaman kecil atau sedikit padam besar. Standar deviasi waktu respon: Karena waktu respon diukur sebagai angka kontinu, kami memilih standar deviasi sebagai fungsi pengukuran disperse kami.Standar deviasi pemanfaatan disk: Pemanfaatan disk akan terus berkembang seiring berjalannya waktu, namun terkadang pemanfaatan disk berkurang karena pekerjaan pemeliharaan dan aktivitas lainnya. Pertumbuhan utilisasi disk tidak linier dan kontinyu. Oleh karena itu kita harus mengukur perubahan utilisasi disk dan mengambil standar deviasi sebagai fungsi disperse kita

langkah 5 menganalisis data

Data yang kami kumpulkan dapat dilihat sebagai sampel statistik dengan nilai rata-rata, standar deviasi, dll. Agar menghasilkan sesuatu yang berguna dengan data, kami harus menentukan tes yang dapat kami terapkan pada sampel statistik yang dikumpulkan.
Jelas bahwa kita seharusnya tidak hanya menganalisis data entah bagaimana. Semua analisis data harus dilakukan sesuai dengan persyaratan yang kita definisikan untuk infrastruktur TI kita. Persyaratan ini biasa disebut “service level”. Biasanya kami ingin infrastruktur kami mencapai beberapa nilai kritis dalam hal perfomance, kapasitas dan ketersediaan. Aspek penting lainnya dari analisis adalah pengukuran dampak perubahan.

Pada langkah ini kita ingin mengetahui apakah kita mencapai nilai yang ingin kita capai. Hal ini dilakukan dengan menguji data agregat. Metode yang paling umum untuk memeriksa data adalah metode statistik. Metode statistik bisa deskriptif atau inferensial. Statistik deskriptif mengungkapkan karakteristik distribusi data dalam sampel statistik. Dalam statistik deskriptif kami memeriksa dimana rata-rata data berada dan bagaimana data didistribusikan sekitar rata-rata. Dalam statistik inferensial kita membandingkan sampel yang berbeda satu sama lain dan kita menginduksi distribusi nilai populasi dari distribusi nilai sampel

Statistik deskriptif diperlukan untuk memeriksa apakah tingkat pelayanan yang dibutuhkan telah tercapai atau tidak. Statistik inferensial berguna untuk memeriksa apakah pencapaian tersebut didapat secara tidak disengaja atau jika itu adalah hasil kerja pemeliharaan dan perubahan konfigurasi.Sebagai contoh sistem operasi awan kami, metode analisis deskriptif berikut diusulkan

Periksa Tingkat Ketersediaan: Ketersediaan dapat dihitung dengan mengurangi downtime total dari jangka waktu periode pengukuran, mengalikan hasilnya dengan 100 dan kemudian membagi hasilnya melalui jangka waktu periode pengukuran. Hasilnya adalah nilai persentase yang harus berada di atas tingkat ketersediaan yang dibutuhkan oleh konsumen jasa.

Untuk memeriksa bagaimana ketersediaan didistribusikan, seseorang harus memeriksa periksa dampak outage : Dampak total padam harus berada di bawah tingkat tertentu. Kita juga bisa menghitung ukuran dampak rata-rata dan varians dampak untuk melihat apakah kita memiliki banyak pemadaman kecil atau sedikit padam. Periksa Waktu Respon Rata-Rata: Untuk memeriksa waktu respons seseorang harus menghitung rata-rata waktu respons rata-rata serta varians dari waktu respons

Periksa Utilitas Maksimum Disk: Pemanfaatan Disk Maksimum harus diperiksa jika berada di atas beberapa nilai kritis. Untuk melihat apakah utilisasi disk tumbuh dengan cepat atau lambat, kita juga harus memeriksa rata-rata utilisasi disk maksimum serta varians pemanfaatan disk maksimum.Analisis deskriptif hanya mengungkapkan jika Anda mempertahankan tingkat layanan yang diminta selama jangka waktu yang teramati. Untuk melihat apakah hasil ini dicapai secara kebetulan atau tidak, diperlukan uji statistik lebih lanjut. Langkah-langkah berikut harus dilakukan juga. Uji distribusi nilai: Sebagai langkah pertama Anda harus memeriksa distribusi nilai seperti waktu outage, impact, response time dan utilisasi disk. Jika nilai mengikuti distribusi normal, sebaiknya pilih statistik lainnya

langkah 6 hadir dan gunakan informasinya

Menurut standar ITIL V3, informasi tidak lain adalah data yang ditafsirkan dengan cara yang berarti. Karena kita menambahkan makna pada data, kita ubah menjadi informasi. Keuntungan besar dari informasi adalah dapat digunakan untuk melakukan tindakan perbaikan dan mengubah sesuatu dalam layanan TI. Misalnya, kami telah melakukan analisis data terhadap layanan awan kami dan kami mendapati bahwa waktu respons rata-rata kami jauh lebih rendah daripada perkiraan kami. Dalam hal ini kami telah mengumpulkan beberapa informasi dari data. Dengan informasi itu sekarang kita bisa memutuskan untuk meningkatkan waktu respon rata-rata.

Pada tahap ini penting untuk menafsirkan informasinya dengan benar. Ada dua cara untuk menafsirkan informasi. Penalaran: Untuk menafsirkan hasil tes statistik Anda, Anda harus dapat mengidentifikasi implikasi apa yang mereka miliki untuk layanan TI Anda. Jika Anda e. G. Menemukan peningkatan yang signifikan dalam pemanfaatan disk, implikasi logisnya adalah bahwa Anda harus mencoba membatasi utilisasi disk atau menambahkan lebih banyak penyimpanan ke sistem Anda.

Penalaran tidak dapat sepenuhnya otomatis karena kita harus memiliki pengetahuan akal sehat tentang layanan TI yang kita gunakan. Ada beberapa pendekatan untuk membantu orang dalam melakukan tugas penalaran sekalipun. Anda bisa e. G. Gunakan apa yang disebut “sistem pakar” untuk menemukan implikasi logis yang baik dari data Anda yang dianalisis. “Sistem pakar” adalah perangkat lunak yang harus diberi makan dengan data dan menggunakan logika formal untuk menghitung implikasi logis. Sistem ini dapat digunakan sebagai alat untuk mendukung Anda dalam mengambil keputusan tentang arsitektur TI dan aspek lain dari layanan TI anda.

Analisis Penyebab Akar: Terkadang penyedia mungkin menemukan masalah dengan menganalisis data. Waktu respon sistem bisa menurun secara signifikan atau mungkin ada kecenderungan pertumbuhan terjadinya padam. Begitu masalah seperti itu ditemukan, seseorang harus mengidentifikasi penyebab masalah ini. Prosedur ini disebut “analisis akar penyebab”. Pada analisis akar penyebab Anda berulang kali bertanya pada diri sendiri apa yang menyebabkan masalah dan kemudian apa penyebab penyebabnya. Rekursi yang terlibat dalam analisis akar penyebab memiliki kedalaman yang terbatas. Analisis akar penyebab juga merupakan proses yang hanya bisa dilakukan secara manualDengan beralasan tentang hasil uji statistik Anda, Anda menciptakan informasi berharga. Informasi ini berfungsi sebagai dasar untuk melakukan tindakan korektif

Langkah 7 terapkan tindakan korektif
Langkah terakhir dalam proses Perbaikan Layanan 7 Langkah Terus-menerus adalah dengan melakukan tindakan perbaikan. Tindakan korektif bergantung pada informasi yang dihasilkan pada langkah 6. Karena proses 7-langkah adalah proses perbaikan yang berkesinambungan, langkah terakhir juga memiliki tujuan untuk menutup siklus perbaikan. Hal ini dilakukan dengan menyelaraskan TI dengan strategi bisnis

Bagian pertama dari langkah ini adalah segera memperbaiki kesalahan di lingkungan TI. Ini bisa jadi kesalahan pemrograman, konfigurasi perangkat keras atau perangkat lunak yang buruk, konsepsi jaringan yang buruk atau bahkan keputusan arsitektur yang buruk sekalipun. Penting untuk mendokumentasikan tindakan apa yang kami lakukan untuk memperbaiki masalah dan perubahan apa yang dilakukan di infrastruktur TI. Hal ini juga penting untuk mencerminkan hasil tindakan yang dilakukan dalam dokumentasi. Jika kita menghadapi masalah dalam pelaksanaan perubahan, kita harus mendokumentasikannya. Jika tidak, tindakan “korektif” kita akan mengganggu kestabilan layanan awan kita dan kita tidak tahu mengapa segala sesuatunya semakin buruk. Oleh karena itu kita harus membuat laporan yang berisi tindakan korektif dan hasil tindakan yang dilakukan
Bagian kedua dari langkah ini adalah menutup siklus proses. Hal ini dilakukan dengan melaporkan hasil siklus proses 7 langkah kepada pengambil keputusan bisnis – biasanya manajer penyedia awan. Untuk me-restart proses itu juga harus didefinisikan kapan dan bagaimana memulai siklus berikutnya. Tugas ini juga merupakan sesuatu yang harus dikoordinasikan dengan pengambil keputusan. Untuk alasan praktis, rencana untuk siklus berikutnya harus dibuat dan disetujui.
pengulalangan siklus perbaikan secara terus menerus Setelah proses perbaikan siklus selesai, itu harus dimulai lagi. Oleh karena itu, tujuan baru untuk Strategi Bisnis harus didefinisikan. Pada tahap ini kita harus mengambil keputusan bisnis. Rencana untuk siklus berikutnya harus ditarik. Tujuan dari redefinisi strategi bisnis ini adalah untuk mendefinisikan kembali faktor-faktor keberhasilan yang penting untuk menerapkan kembali pengukuran dan peningkatan iterasi berikutnya. Strategi Bisnis adalah keluaran utama dan masukan dari proses Peningkatan Layanan 7 Langkah Berkelanjutan. Ara. 2 menunjukkan keseluruhan proses serta hasil yang kita dapatkan pada setiap langkahnya. Ini juga menunjukkan bahwa proses 7-Langkah Perbaikan mempengaruhi dan dipengaruhi terutama oleh strategi bisnis penyedia

kesimpulan

Dari uraian tersebut bahwa continual service improvement atau disebut juga perbaikan layanan terus menerus. yang berarti bagaimana dalam suatu bisnis mampu dalam mempertahankan nilai terhadap pelayanan untuk pelanggan agar suatu bisnis tersebut mencapai peningkatan skala besar dan bertahap dalam kualitas layanan, efisiensi operasional, dan kelangsungan bisnis untuk memastikan bahwa portofolio layanan terus disesuaikan dengan kebutuhan bisnis melalui strategi, perancangan, transisi dan pengoperasian layanan yang lebih baik yaitu menggabungkan prinsip, praktik dan metode dari manajemen mutu, peningkatan manajemen dan peningkatan kemampuan.

SERVICE TRANSITION

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 danservice design.

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 semuasoftware-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.