TA : Perencanaan Information Technology Service Continuity Management Berdasarkan ITIL V-3 Pada PT. Telkom MSC Area V Jawa Timur.

TELKOM MSC AREA V JAWA TIMUR

TUGAS AKHIR

Nama : Wahyu Setiawan NIM : 09.41010.0186 Program : S1 (Strata Satu) Jurusan : Sistem Informasi

SEKOLAH TINGGI

MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA

ABSTRAK

Telkom MSC (Maintenance Service Center) merupakan salah satu divisi dari PT. Telekomunkasi Indonesia, Tbk yang fungsi utamanya yaitu melakukan infrastructure maintenance management perangkat telekomunikasi yang dimiliki oleh Telkom.

Selama ini proses maintenance dan repair yang dilakukan pada PT. Telkom MSC Area V Jawa Timur hanya sebatas mengacu pada standard kerja yang telah ditetapkan oleh manajemen, sehingga terdapat beberapa aktivitas pada maintenance dan repair yang dapat menimbulkan kendala.

Permasalahan yang dihadapi oleh PT. Telkom MSC Area V Jawa Timur ini adalah belum memiliki standard mengenai proses apa yang harus dilakukan ketika atau sebelum terjadi kendala pada proses maintenance dan repair itu sendiri, hanya sebatas melakukan rapat koordinasi terkait kendala yang sedang/telah terjadi agar tidak terulang di masa datang.

Framework ITIL-V3 digunakan sebagai acuan untuk menyusun pola

kerja yang terstruktur. Sehingga dengan adanya standard ini nantinya dapat memberikan arahan kerja yang jelas ketika atau sebelum terjadi kendala pada proses maintenance dan repair.Serta dapat memberikan rekomendasi perbaikan berupa Standard Operating Procedure (SOP), Instruksi Kerja (IK) dan Rekaman Kerja (RK) berdasarkan framework yang berkaitan dengan IT Continuity Management.

Kata kunci : Management, Information Technology Service Continuity Management, ITIL, Telkom

DAFTAR ISI

Halaman

ABSTRAK ... vi

KATA PENGANTAR ... vii

DAFTAR ISI ... ix

DAFTAR TABEL ... xii

DAFTAR GAMBAR ... xiv

DAFTAR LAMPIRAN ... xvi

BAB I. PENDAHULUAN ... 1

1.1 Latar Belakang Masalah ... 1

1.2 Perumusan Masalah ... 4

1.3 Batasan Masalah ... 4

1.4 Tujuan ... 5

1.5 Manfaat Penelitian ... 5

1.6 Sistematika Penulisan ... 5

BAB II. LANDASAN TEORI ... 7

2.1 Information Technology Service Continuity Management ... 7

2.2 Information Technology Infrastructure Library (ITIL) ... 8

2.3 Definisi Disaster / Bencana ... 9

2.4 Penyebab Disaster / Bencana ... 11

2.5 Akibat Dari Disaster / Bencana ... 11

2.6 Rencana Kelangsungan Bisnis (Business Continuity Plan / BCP) ... 13

2.7 Information Technology Service Continuity

Management Life Cycle ... 14

2.8 Metode M_O_R (Management of Risk) ... 17

2.9 Aktivitas pada ITSCM ... 19

2.9.1 Analisa Dampak Bisnis (Business Impact Analysis) ... 19

2.9.2 Rencana Pemulihan IT (IT Recovery Plan) ... 20

2.9.3 IT Service Continuity Plan ... 22

2.9.4 ITSCMStrategy ... 24

2.9.5 Identifikasi dan Analisa Resiko (Risk Assessment and Analysis) ... 24

2.9.6 Uji dan Tinjau Resiko (Risk Monitoring and Testing) ... 26

2.10 PT Telkom MSC Area V Jawa Timur ... 27

BAB III. METODOLOGI PENELITIAN... 29

3.1 Tahap Awal ... 30

3.1.1 Studi Literatur ... 30

3.1.2 Identifikasi dan Analisa Permasalahan ... 30

A.Wawancara ... 30

B.Observasi ... 31

3.2 Tahap Pengembangan ... 31

3.2.1 Initiation ... 31

3.2.2 Requirements and Strategy ... 35

A.Wawancara ... 42

3.2.3 Implementation ... 42

3.2.4 On-going Operation ... 50

3.3 Tahap Akhir ... 52

3.3.1 Evaluasi ... 52

3.3.2 Kesimpulan dan Saran ... 52

BAB IV. HASIL DAN PEMBAHASAN ... 54

4.1 Initiation ... 54

4.1.1 Mendefinisikan Kebijakan (Policy Setting) ... 54

4.1.2 Mendefinisikan Ruang Lingkup (Scope) ... 55

4.2 Requirements and Strategy ... 56

4.2.1 Business Impact Analysis (BIA) ... 56

4.2.2 Risk Assessment (RA) ... 62

4.2.3 ITSCM Strategy ... 65

4.3 Implementation ... 65

4.3.1 Recovery Plan ... 65

4.3.2 Testing Plan ... 66

4.3.3 Develop Recovery Plan ... 68

4.3.4 Recovery Procedures ... 68

4.4 On-going Operation ... 69

4.4.2 Review ... 69

4.4.2 Testing ... 69

BAB V. PENUTUP ... 71

5.1 Kesimpulan ... 71

5.2 Saran ... 71

DAFTAR PUSTAKA ... 72

LAMPIRAN ... 73

1.1Latar Belakang Masalah

Telkom MSC (Maintenance Service Center) merupakan salah satu divisi dari PT. Telekomunikasi Indonesia, Tbk yang bertugas melakukan infrastructure maintenance management perangkat telekomunikasi yang dimiliki oleh Telkom. Infrastruktur tersebut meliputi software, hardware, jaringan serta modul-modul yang ada di lapangan. Proses infrastructure maintenance management itu sendiri terdiri dari maintenance dan repair. Maintenance adalah proses kegiatan yang dilakukan secara berkesinambungan sesuai prosedur baku dan sesuai terhadap suatu alat (sarana dan prasarana) dalam rangka menjaga agar alat itu dalam keadaan siap pakai dan handal selama dioperasikan. Sedangkan repair adalah tindakan yang dilakukan untuk menjaga barang atau untuk memperbaikinya sampai pada suatu kondisi yang bisa diterima. Untuk melakukan infrastructure maintenance management, Telkom MSC membagi area pengelolaannya menjadi tujuh, yaitu Area I Sumatra, Area II DKI Jakarta, Area III Jawa Barat, Area IV Jawa Tengah dan DIY, Area V Jawa Timur, Area VI Kalimantan dan Area VII Kawasan Timur Indonesia (KTI).

Selama ini proses maintenance dan repair yang dilakukan pada PT. Telkom MSC Area V Jawa Timur hanya sebatas mengacu pada standard kerja yang telah ditetapkan oleh manajemen, sehingga terdapat beberapa aktivitas yang dapat menimbulkan kendala. Aktivitas-aktivitas itu tidak hanya terjadi pada proses maintenance tetapi juga pada saat proses repair dilakukan.

Gambar 1.1 Grafik Gangguan periode Januari – Maret 2011

Gambar 1.2 Grafik Gangguan periode Juni - Agustus 2011

Grafik pada gambar 1.1 dan gambar 1.2 adalah contoh yang menunjukkan jumlah gangguan yang menurun dari periode Januari – Maret 2011 hingga periode Juni – Agustus 2011. Hal itu diakibatkan oleh adanya kegiatan maintenance dan repair, sehingga kedua proses tersebut menjadi penting untuk tetap dilakukan dengan baik. Namun pada saat melakukan proses maintenance dan repair sering terjadi kendala.

Kendala yang dihadapi oleh PT. Telkom MSC Area V Jawa Timur ini adalah belum memiliki standard mengenai proses apa yang harus dilakukan ketika atau sebelum terjadi kendala pada proses maintenance dan repair itu sendiri. Selama ini hanya sebatas melakukan rapat koordinasi terkait kendala yang sedang/telah terjadi agar tidak terjadi lagi. Hal ini berakibat adanya beberapa kendala pada aktivitas maintenance dan repair yang seharusnya dapat diminimalisir terlebih dahulu. Jika dibiarkan akan mengakibatkan proses maintenance dan repair akan terhambat atau menjadi lebih lama, sehingga dapat menurunkan kualitas layanan yang berdampak profit dan kepercayaan pelanggan akan menurun.

Untuk dapat mengatasi kendala yang telah disebutkan maka diperlukan framework terkait proses mencegah permasalahan yang pernah terjadi untuk menjamin ketersediaan IT guna mendukung kelangsungan bisnis (Information Technology Service Continuity Management / ITSCM). Framework ITIL-V3 dapat digunakan sebagai acuan untuk menyusun pola kerja yang terstruktur.

Harapan atas penerapan framework ITIL-V3 ini adalah dapat memberikan arahan kerja yang jelas ketika atau sebelum terjadi kendala pada proses maintenance dan repair, sehingga kedua proses tersebut dapat berjalan secara berkelanjutan. Serta dapat mendukung kelangsungan bisnis dengan memastikan fasilitas IT yang dibutuhkan dapat tersedia. Secara keseluruhan penelitian ini menghasilkan dokumen perencanaan ITSCM yang bentuknya rekomendasi berupa framework yang di dalamnya juga terdapat Standard Operating Procedure (SOP), Working Instruction (WI) dan Supporting

Documents. Dokumen perencanaan ITSCM itu mengacu pada framework yang berkaitan dengan IT Service Continuity Management, dalam hal ini ITIL-V3.

1.2Perumusan Masalah

Berdasarkan latar belakang yang telah diuraikan di atas, maka dapat dirumuskan permasalahan pada PT. Telkom MSC Area V Jawa Timur dalam Tugas Akhir ini, yaitu bagaimana merancang dokumen perencanaan Information Technology Service Continuity Management (ITSCM) untuk dapat memberikan arahan kerja yang jelas ketika atau sebelum terjadi permasalahan pada proses maintenance dan repair agar kedua proses tersebut dapat berjalan secara berkelanjutan.

1.3Batasan Masalah

Dalam pembuatan Tugas Akhir Perencanaan ITSCM pada PT. Telkom MSC Area V Jawa Timur Berdasarkan ITIL V-3, ruang lingkup permasalahan dibatasi pada :

1. Dalam penerapan perencanaan ITSCM berdasarkan ITIL V-3 hanya dilakukan uji ahli tanpa dilakukan uji lapangan.

2. Kebijakan (policy) yang digunakan sebagai acuan adalah kebijakan dari pihak perusahaan.

1.4Tujuan

Dengan mengacu pada perumusan masalah yang telah disebutkan maka tujuan yang hendak dicapai dalam penyusunan Tugas Akhir ini adalah menghasilkan dokumen perencanaan ITSCM pada PT. Telkom MSC Area V Jawa Timur berdasarkan framework ITIL V-3. yaitu rekomendasi berupa SOP (Standard Operational Procedure), IK (Instruksi Kerja) dan RK (Rekaman Kerja).

1.5Manfaat Penelitian

Diharapkan dengan adanya dokumen perencanaan ITSCM berdasarkan ITIL V-3 dapat memberikan manfaat bagi PT. Telkom MSC Area V Jawa Timur

berupa :

1. Dapat memberikan arahan kerja yang jelas ketika atau sebelum terjadi permasalahan pada proses maintenance dan repair.

2. Dapat terjadi penataan dokumen secara terstruktur sehingga mendukung pola kerja yang baik pada PT. Telkom MSC Area V Jawa Timur.

1.6Sistematika Penulisan

Agar para pembaca dapat memahami dengan mudah persoalan dan pembahasanya, maka penulisan dari penelitian tugas akhir ini akan dibuat dengan sistematika yang terdiri dari beberapa bab yang di dalamnya terdapat penjabaran masalah, yakni :

Pada bab pertama ini akan membahas tentang perumusan dan penjelasan masalah umum, sehingga diperoleh suatu gambaran umum mengenai seluruh

penelitian yang dilakukan oleh penulis. Bab ini akan menyangkut beberapa masalah yang akan dibahas mengenai latar belakang masalah, perumusan masalah, batasan masalah, tujuan, manfaat penelitian, dan dilanjutkan oleh sistematika penulisan.

Pada bab kedua ini akan membahas tentang teori penunjang yang menjelaskan secara singkat mengenai landasan teori yang berkaitan dengan permasalahan dari penelitian tugas akhir mengenai ITIL service design dan ITSCM.

Pada bab ketiga membahas mengenai metode penelitian. Metode penelitian dalam tata kelola teknologi informasi terdiri dari identify needs, envision solution, dan plan solution.

Pada bab keempat membahas mengenai hasil dan pembahasan dari bab ketiga mengenai metode penelitian. Hasil dan pembahasan ini mengenai initiation, requirements & strategy, implementation, dan on-going operation.

Pada bab kelima ini akan membahas mengenai kesimpulan dari pembuatan perencanaan ITSCM pada PT. Telkom MSC Area V Jawa Timur dengan tujuan dan permasalahan yang ada, serta saran untuk pengembangan perencanaan ITSCM di masa mendatang.

BAB II

LANDASAN TEORI

2.1Information Technology Service Continuity Management (ITSCM)

Menurut Information Technology Service Management Forum (itSMF) (Meijer, 2008), teknologi sebagai komponen inti dalam proses bisnis, kelangsungan atau ketersediaan dari TI adalah hal penting bagi bisnis untuk bertahan secara keseluruhan. Hal ini dapat dicapai dengan memperkenalkan pengukuran pengurangan resiko dan pilihan pemulihan. Pemeliharaan kemampuan pemulihan merupakan hal penting agar proses bisnis dapat berjalan secara efektif.

Menurut itSMF (2007), tujuan ITSCM adalah untuk memelihara kemampuan pemulihan berjalan secara tepat dalam layanan TI untuk mencocokkan kebutuhan yang disetujui, persyaratan dan jadwal dari bisnis. Sedangkan menurut Information Technology Governance Institute (ITGI) (2007), ITSCM termasuk kelanjutan dari seluruh aktivitas siklus hidup layanan yang perlu dipastikan. Sekali rencana kelangsungan dan pemulihan layanan dikembangkan, keduanya harus selaras dengan rencana kelangsungan bisnis dan prioritas bisnis. Memeliharan kebijakan strategis ITSCM secara tepat dan rencana ITSCM selaras dengan rencana bisnis merupakan kunci suksesnya proses ITSCM. Hal ini dapat dilakukan dengan secara reguler melakukan analisa dampak bisnis dan latihan manajemen resiko.

2.2Information Technology Infrastructure Library (ITIL)

Menurut Wibowo (2009), ITIL (Information Technology Infrastructure Library) adalah suatu kerangka kerja umum yang menggambarkan best practice dalam manajemen layanan TI. ITIL menyediakan kerangka kerja bagi tata kelola TI dan berfokus pada pengukuran secara terus_‐menerus dan perbaikan kualitas layanan TI yang diberikan, baik dari sisi bisnis dan perspektif pelanggan.

Menurut Whittleston (2012), ITIL adalah suatu kerangka kerja yang telah berkembang untuk memenuhi isu organisasi. Framework ini lebih ditujukan kepada isu manajemen daripada isu teknis. ITIL dapat memberikan arahan yang tidak bergantung pada teknologi tertentu tetapi tetap dapat memberikan nilai lebih bagi organisasi. Sedangkan menurut Arraj (2010), ITIL adalah sebuah pendekatan untuk manajemen layanan TI. Layanan adalah sesuatu yang memberikan nilai bagi pelanggan.

Menurut Office of Government Commerce (OGC) (2007), ITIL merupakan framework untuk mengelola infrastruktur TI di suatu organisasi dan bagaimana memberikan service terbaik bagi pengguna layanan TI.

Menurut(Meijer, 2011), ITIL memberikan arahan untuk menggabungkan manajamen layanan TI dengan konsep dari manajemen informasi bisnis (business information management / BIS). ITIL membahas layanan TI dan memungkinkan konsep bisnis memberikan nilai melalui layanan itu kepada pelanggan. Layanan ini didefinisikan sebagai sarana untuk memberikan nilai kepada pelanggan dengan memfasilitasi hasil yang diinginkan pelanggan.

ITIL is a framework of best practice guidance in Information Technology Service Management (ITSM) (Clinch, 2009). ITIL menggambarkan proses, fungsi

dan struktur yang mendukung sebagian besar area ITSM, sebagian besar dari sudut pandang penyedia layanan.

Menurut Jogiyanto dan Abdillah (2010), ITIL adalah seperangkat konsep dan praktik untuk mengelola layanan TI, pengembangan, dan operasi TI. ITIL memberikan deskripsi rinci mengenai sejumlah praktik penting TI dan menyediakan daftar komprehensif mengenai tugas dan prosedur yang setiap organisasi dapat menyesuaikan dengan kebutuhan sendiri. Menurut Information Technology Government Institute (ITGI) dan OGC (2007), COBIT dan ISO/IEC 27002 digunakan untuk membantu menentukan apa yang harus dilakukan sedangkan ITIL menyediakan cara aspek manajemen pelayanan.

Menurut Fitriani (2010), ITIL merupakan best practice untuk memastikan layanan teknologi informasi berjalan sesuai dengan sebagaimana mestinya. Sedangkan menurut Gilbert, Morse and Lee (2007), dengan menerapkan penggunaan ITIL V-3 akan menciptakan manajemen pengetahuan (knowledge management) dari sebuah dokumentasi resolusi manajemen insiden sehingga dapat mempersingkat waktu penyelesaian dari sebuah insiden dan masalah

2.3Definisi Disaster / Bencana

Menurut Whitten (2008), disaster (bencana) didefiniskan sebagai kejadian yang waktu terjadinya tidak dapat diprediksi dan bersifat sangat merusak. Pengertian ini mengidentifikasikan sebuah kejadian yang memiliki empat faktor utama, yaitu :

1. Tiba-tiba

2. Tidak diharapkan

3. Bersifat sangat merusak

Dalam istilah lain disaster (bencana) didefinisikan sebagai gangguan dari operasi bisnis yang menghentikan organisasi dalam menyediakan pelayanan bisinisnya yang disebabkan oleh ketiadaan faktor-faktor seperti :

1. Tenaga Kerja dan keahlian 2. Fasilitas

3. Komunikasi 4. Power / Daya 5. Akses Informasi

Bencana dapat diakibatkan oleh ulah manusia, maupun akibat alam (natural disaster), seringkali tidak dapat diprediksi kapan akan terjadi. Untuk itu perlu dibuat sistem yang dapat mengurangi resiko dan kerugian bila bencana terjadi.

Bencana terjadi dengan frekuensi yang tidak menentu dan akibat yang ditimbulkannya meningkat bagi mereka yang tidak mempersiapkan diri terhadap kemungkinan-kemungkinan timbulnya bencana. Rencana pencegahan dan perbaikan terhadap bencana dapat membantu melindungi semua aset oraganisasi, termasuk sumber daya manusia, pekerjaan, data-data penting, dan fasilitas organisasi.

2.4Penyebab Disaster / Bencana

Menurut Whitten (2008), penyebab suatu kondisi bencana dapat dikategorikan sebagai berikut :

1. Bencana alam, seperti banjir dan gempa bumi. 2. Fasilitas, seperti listrik, air dan komunikasi.

3. Manusia, seperti sabotase, virus, teroris dan kerusuhan.

4. Kegagalan peralatan, seperti sistem informasi, telekomunikasi dan mesin produksi.

2.5Akibat dari Disaster / Bencana

Menurut Whitten (2008), akibat yang ditimbulkan dari suatu bencana dapat dikategorikan sebagai berikut :

1. Sudut pandang keuangan (Financial perspective)

Bencana atau gangguan akan berdampak pada kelancaran finansial dalam sebuah organisasi. Pengeluaran ekstra dan kerugian dari cash flow akan berdampak pada modal perusahaan. Pada saat itu waktu akan menjadi musuh utama dalam bisnis.

a. Beban operasional Normal (Normal operating expenses) 1) Gaji (Saleries)

Dengan adanya bencana atau gangguan yang menyebabkan kelangsungan bisnis berhenti dapat meningkatkan beban gaji.

2) Sewa (Rent)

b. Beban Besar (Large extraordinary expenses) 1) Penggantian peralatan (Equipment replacement) 2) Fasilitas Sementara (Temporary facility)

c. Keuntungan / aliran uang berhenti (Revenue / cash flow stops) d. Nilai Equity akan melemah (Equity position weakened) 2. Sumber Tenaga kerja (Human Resources)

Saat ini perusahaan cenderung hanya memiliki sedikit tenaga kerja, maka hilangnya tenaga kerja pada saat disaster / bencana dapat mengakibatkan efek yang besar, seperti :

a. Downsizing

b. Pelatihan ulang (Re-enginering) c. Outsourcing

3. Meningkatnya kompetisi sejalan dengan Global Economy (Increasing Competition in a Global Economy)

Pada saat terjadi disaster / bencana maka kompetisi perusahaan-perusahaan semakin meningkat yaitu dari pelayanan / service level yang diberikan, karena setiap perusahaan akan terus meningkatkan pelayanannya. Tentunya perusahaan yang tidak siap dengan keadaan ini dapat kehilangan customernya (lost costumer don’t return).

4. Meningkatnya penggunaan teknologi (Increasing use of technology)

Perusahaan akan menjadi sangat bergantung pada teknologi, apabila terjadi bencana maka teknologi yang biasa digunakan berubah menjadi manual. Sehingga kebutuhan akan teknologi tersebut dapat menjadi kebutuhan yang luar biasa penting. Teknologi tersebut seperti :

a. Faks (Fax)

b. Pesan suara (Voice mail)

c. Jaringan lokal dan WAN (Local and wide area networks) d. Sistem pengambilan keputusan (Decision support systems) e. Akses Internet (Internet Access)

5. Hutang terhadap ketidaktersedianya produk / pelayanan (Liabilities Associated with not providing products / services)

Manajemen bertanggung jawab dalam memastikan kelangsungan bisnis sehingga pemulihan bencana / gangguan (disaster recovery) harus direncanakan dengan matang. Sehingga tidak terjadi adanya penalti dari perusahaan lain atau hal-hal yang tidak diinginkan, seperti :

a. Penalties associated with notmeeting delivery schedules b. Shareholder / Board of directors’ new expectations

2.6Rencana Kelangsungan Bisnis (Business Continuity Plan / BCP)

Business Continuity Plan (BCP) adalah kebijakan dan prosedur yang memuat rangkaian kegiatan terencana dan terkoordinir mengenai langkah-langkah pengurangan resiko, penanganan dampak gangguan / bencana dan proses pemulihan agar kegiatan operasional dan pelayanan kepada customer tetap berjalan.

BCP adalah proses yang dirancang untuk mengurangi resiko dalam sebuah organisasi bisnis. (sumber : ISACA)

BCPadalah sekumpulan prosedur dan sumber informasi yang digunakan untuk memulihkan kegiatan operasional bisnis apabila terjadi gangguan / bencana. (sumber : James C. Barnes, A Guide to Business Continuity Planning)

2.7Information Technology Service Continuity Management Lifecycle

Gambar 2.1 ITSCM Lifecycle

Penjelasan langkah-langkah dalam ITSCM seperti yang tampak pada gambar 2.1 adalah :

1. Inisiasi (Initiation)

Fase ini meliputi seluruh organisasi dan mencakup kegiatan-kegiatan berikut : a. Mendefinisikan kebijakan

b. Menentukan ruang lingkup

c. Mendefinisikan dan memulai proyek

2. Persyaratan dan Strategi (Requirements and Strategy)

Fase ini untuk menentukan kebutuhan bisnisi bagi ITSCM untuk dapat mengetahui sejauh mana organisasi dapat bertahan saat terjadi bencana. Dua

hal penting dalam fase ini adalah kebutuhan dan strategi. Penjabaran kedua hal itu meliputi :

a. Analisa Dampak Bisnis (Business Impact Analysis)

Menurut Franklin Fletcher, BIA merupakan dasar dari program bisnis kontinuitas (business continuity program). Tujuaanya adalah untuk mengukur dampak yang disebabkan oleh hilangnya layanan. BIA mengidentifikasi layanan yang paling penting bagi organisasi sehingga dapat memberikan masukan penting bagi strategi. Analisis itu mengidentifikasi :

1) Jenis kerusakan (bencana/gangguan) 2) Bagaimana kerusakan bisa meningkat

3) Kompetensi, fasilitas dan layanan yang dibutuhkan untuk melanjutkan proses yang penting

4) Perkiraan penentuan jangka waktu proses pemulihan

Secara umum, langkah-langkah lebih preventif harus diambil untuk proses yang terjadi dengan cepat dan memiliki dampak yang tinggi. Jika dampak rendah dan proses membutuhkan lebih banyak waktu, penekanannya adalah kurang pada pencegahan dan lebih pada tindakan kuratif (recovery).

b. Perkiraan resiko

Menurut Michael Faber (2010), resiko adalah kejadian tak terduga yang memiliki dampak negatif terhadap kinerja maupun profit. Ada berbagai metode dan analisis resiko. Analisis resiko adalah penilaian risiko yang mungkin terjadi. Manajemen resiko mengidentifikasi respon dan tindakan yang dapat diambil. Sebuah metode standar seperti Manajemen Resiko /

Management of Risk (M_o_R) dapat digunakan untuk menyelidiki dan mengelola resiko. Metode ini terdiri dari :

1) Prinsip M_o_R

2) Pendekatan M_o_R (pendekatan organisasi)

3) Proses M_o_R (identifikasi, penilaian, perencanaan, pelaksanaan) 4) Pencocokan dan review M_o_R

5) Komunikasi (up-to-date dan penyediaan informasi yang memadai) c. Strategi

Contoh strategi yang dapat diterapkan meliputi :

1) Strategi 1 : langkah-langkah untuk mengurangi resiko

Langkah-langkah untuk mengurangi resiko harus diimplementasikan dalam kombinasi dengan manajemen ketersediaan karena penurunan kegagalan memiliki dampak pada ketersediaan layanan.

2) Strategi 2 : opsi pemulihan IT

Strategi kontinuitas harus menitikberatkan pada tindakan penguranngan biaya terhadap langkah-langkah pemulihan untuk mengembalikan proses kritis.

3. Implementasi (Implementation)

Rencana ITSCM dapat dibuat setelah strategi disetujui. Anda harus ingat, bagaimanapun, bahwa struktur organisasi (kepemimpinan dan proses pengambilan keputusan) dapat merubah proses pemulihan bencana. Mengatur hal ini pada umumnya bertanggung jawab pada area manajer senior, seperti dengan koordinator di bawahnya dan tim pemulihan di bawah itu.

4. Operasionalisasi (On-going Operation) Fase ini meliputi :

a. Review b. Testing

2.8Metode M_O_R (Management of Risk)

Menurut Graham Williams (2007:2011), M_O_R merupakan sebuah metodologi standard yang digunakan untuk menilai dan mengelola resiko dalam sebuah organisasi. Kerangka M_O_R dapat dilihat pada gambar 2.2 di bawah ini :

Gambar 2.2 Kerangka M_O_R (Management of Risk)

Pendekatan M_O_R seperti yang tampak pada gambar 2 terdiri dari : 1. M_O_R Principles (Prinsip M_O_R)

Prinsip-prinsip merupakan hal penting untuk pengembangan praktek manajemen resiko yang baik, prinsip-prinsip itu berasal dari kebijakan perusahaan.

2. M_O_R Approach (Pendekatan M_O_R)

Prinsip-prinsip dalam pendekatan dengan perusahaan perlu disepakati dan ditetapkan dalam dokumen seperti :

a. Risk Management Policy b. Process Guide

c. Plans d. Etc

3. M_O_R Proccesses (Proses-proses M_O_R)

Empat langkah utama yang menggambarkan input, proses dan output dari kegiatan yang memastikan bahwa resiko dikontrol :

a. Identify : ancaman dan peluang dalam kegiatan yang dapat mempengaruhi kemampuan untuk mencapai tujuan.

b. Assess : pemahaman tentang efek ancaman dan peluang yang diidentifikasi terkait dengan kegiatan ketika kedua hal itu dikumpulkan bersama-sama. c. Plan : untuk mempersiapkan sebuah manajemen respon tertentu yang akan

mengurangi ancaman dan memaksimalkan peluang.

d. Implement : tindakan manajemen risiko yang direncanakan untuk memantau efektivitas dan mengambil tindakan korektif mengenai respon yang tidak sesuai harapan.

4. Embedding and reviewing M_O_R (Pencocokan dan me-review M_O_R) Menempatkan prinsip-prinsip, pendekatan dan proses di satu tempat, semua hal itu harus terus dikaji dan ditingkatkan untuk memastikan semuanya tetap efektif.

5. Communication

Memiliki kegiatan komunikasi yang tepat di suatu tempat untuk memastikan bahwa semua orang terus up-to-date dengan perubahan-perubahan dalam ancaman, kesempatan dan aspek-aspek lain dari manajemen risiko.

2.9Aktivitas pada ITSCM

Aktivitas-aktivitas yang dapat dilakukan dalam lingkup ITSCM adalah analisa dampak bisnis, rencana pemulihan IT, IT service continuity plan, ITSCM strategy, identifikasi dan analisa resiko, uji dan tinjau resiko.

2.9.1 Analisa Dampak Bisnis (Business Impact Analysis)

Business Impact Analysis (BIA) adalah landasan awal dalam proses penyusunan BCP melalui proses identifikasi dampak bisnis, identifikasi aktivitas yang penting, penentuan target waktu pemulihan, dan pengukuran standar operasi minimal yang dibutuhkan. Menurut Franklin Fletcher, BIA landasan dari setiap program kelangsungan bisnis dalam sebuah organissai. Tujuan dari Analisis dampak bisnis (business impact analysis) ini adalah untuk mendapatkan :

1. Informasi yang menyeluruh mengenai fungsi organisasi dan business process 2. Informasi kepada manajemen mengenai Recovery Time Objective

3. Informasi mengenai kebutuhan minimal dalam penyelenggaraan organisasi (minimum resources)

2.9.2 Rencana Pemulihan IT (IT Recovery Plan)

Strategi pemulihan harus dikembangkan untuk teknologi informasi (TI) seperti sistem, aplikasi dan data. Ini termasuk jaringan, server, desktop, laptop, perangkat nirkabel, data dan konektivitas.

Prioritas pemulihan TI harus konsisten dengan prioritas untuk pemulihan fungsi bisnis dan proses yang dikembangkan selama analisis dampak bisnis. Sumber daya TI yang diperlukan untuk mendukung fungsi bisnis terhadap waktu dan proses juga harus diidentifikasi. Waktu pemulihan untuk sumber daya TI harus sesuai dengan tujuan waktu pemulihan untuk fungsi bisnis atau proses yang bergantung pada sumber daya TI.

Sistem teknologi informasi memerlukan perangkat keras, perangkat lunak, data dan konektivitas. Tanpa salah satu komponen dari sistem itu maka bisa saja sistem tidak dapat berjalan. Oleh karena itu, strategi pemulihan harus dikembangkan untuk mengantisipasi hilangnya satu atau lebih komponen sistem seperti berikut :

1. Ruang komputer lingkungan (ruang komputer aman dengan kontrol iklim, power supply, AC dan cadangan, dll)

2. Hardware (jaringan, server, komputer desktop dan laptop, perangkat nirkabel dan periferal)

3. Konektivitas ke penyedia layanan (fiber, kabel, nirkabel, dll)

4. Software aplikasi (electronic data interchange, surat elektronik, manajemen sumber daya perusahaan, produktivitas kantor, dll)

5. Data dan restorasi

1. Manual workarounds : solusi manual sementara dengan untuk jangka waktu yang terbatas

2. Reciprocal arrangements : dukungan perjanjian antara pihak-pihak terkait (tidak sering digunakan hari ini)

3. Gradual recovery (Pemulihan Bertahap) : Metode yang membuat fasilitas dasar seperti akomodasi dan ruang komputer menjadi tersedia dengan biaya yang terbatas dalam beberapa hari (empat atau lebih).

4. Intermediate recovery (Pemulihan Menengah) : pemulihan dalam waktu dua sampai tiga hari, umumnya didasarkan pada fasilitas yang disiapkan sering berbagi dengan beberapa pihak lain

5. Fast recovery (Pemulihan Cepat): pemulihan dalam waktu 24 jam yang berfokus pada layanan utama, yang melibatkan fasilitas yang bisa melakukan operasional sangat cepat dan dengan kehilangan data yang sangat rendah

6. Immediate recovery (Pemulihan Segera). pilihan untuk pemulihan segera terutama layanan bisnis penting dengan bantuan teknik mirroring dan solusi redundansi lainnya, tidak ada data yang rendah yang terlibat

2.9.3 IT Service Continuity Plan

Gambar 2.3 IT Service Continuity Plan

Berikut adalah penjelasan mengenai setiap bagian pada gambar 2.3 diatas : 1. Policy

Kebijakan kelangsungan pelayanan adalah

pernyataan keseluruhan kesiapan. Ini

mendefinisikan konteks kesinambungan layanan

untuk organisasi, mengidentifikasi langkah-langkah yang akan diambil untuk memberikan kontinuitas dalam kasus gangguan, dan

menyediakan kerangka kerja untuk penyusunan

dan pemeliharaan rencana ITSCM.

Kebijakan ini perlu dibaca dan dipahami oleh semua staf dalam organisasi, sehingga menjaganya agar tetap singkat dan “to the point” sangat penting untuk keberhasilannya.

Prosedur menggambarkan kegiatan yang akan dilakukan sebagai bagian

dari kontinuitas dan pemulihan, dan

mengidentifikasi tugas (instruksi kerja) yang diperlukan untuk menyelesaikan kegiatan.

3. Work instructions

Instruksi kerja menggambarkan langkah yang diperlukan untuk menyelesaikan tugas yang telah dilakukan sebagai bagian dari suatu kegiatan (prosedur).

4. Test procedures

Prosedur pengujian mengidentifikasi pemeriksaan spesifik dan tes yang akan dilakukan untuk memastikan kemampuan lanjutan, kelangsungan hidup

dan keandalan rencana ITSCM, dan jika

berlaku, bisnis fasilitas kelangsungan organisasi Anda.

5. Test instructions

Instruksi Uji menjelaskan langkah-langkah yang diperlukan untuk menyelesaikan kelangsungan individu dan tes pemulihan.

6. Test schedule

Jadwal Tes mengidentifikasi tanggal dan waktu

untuk pelaksanaan pemeriksaan dan tes.

Rencana ITSCM dilengkapi dengan satu set dokumen teknis dan bisnis yang berisi informasi untuk mendukung kelangsungan pelayanan dan pemulihan. Dokumen - seperti daftar komponen - mungkin sudah ada atau mungkin perlu disusun untuk referensi oleh, atau dimasukkan ke dalam rencana.

2.9.4 ITSCM Strategy

ITSCM Strategy harus menitikberatkan pada tindakan pengurangan biaya terhadap langkah-langkah pemulihan untuk mengembalikan beberapa proses kritis. Sejumlah pilihan pemulihan yang mungkin :

1. Manual workarounds : solusi manual sementara dengan untuk jangka waktu yang terbatas

2. Reciprocal arrangements : dukungan perjanjian antara pihak-pihak terkait (tidak sering digunakan hari ini)

3. Gradual recovery (Pemulihan Bertahap) : metode yang membuat fasilitas dasar seperti akomodasi dan ruang komputer menjadi tersedia dengan biaya yang terbatas dalam beberapa hari (empat atau lebih).

4. Intermediate recovery (Pemulihan Menengah) : pemulihan dalam waktu dua sampai tiga hari, umumnya didasarkan pada fasilitas yang disiapkan sering berbagi dengan beberapa pihak lain

5. Fast recovery (Pemulihan Cepat) : pemulihan dalam waktu 24 jam yang berfokus pada layanan utama, yang melibatkan fasilitas yang bisa melakukan operasional sangat cepat dan dengan kehilangan data yang sangat rendah

6. Immediate recovery (Pemulihan Segera) : pilihan untuk pemulihan segera terutama untuk layanan bisnis yang penting dengan bantuan teknik mirroring dan solusi redundansi lainnya, tidak ada data yang rendah yang terlibat

2.9.5 Identifikasi dan Analisa Resiko (Risk Assessment and Analysis)

Maksud dari identifikasi resiko adalah proses identifikasi resiko yang dihadapi suatu organisasi, identifikasi terhadap fungsi kritikal untuk menjamin kelangsungan operasional bisnis, serta memperoleh gambaran dalam pengendalian bisnis fungsi untuk mengurangi resiko kerugian apabila terjadi gangguan. Resiko Operasional adalah potensi seluruh gangguan dalam proses operasional suatu organisasi atau perusahaan yang menyebabkan kerugian dimasa yang akan datang (future losses) atau terjadi fluktuasi pendapatan dimasa yang akan datang.

Tujuan dilakukannya risk assessment adalah sebagai berikut : 1. Menentukan tingkat resiko dari berbagai jenis resiko.

2. Menentukan pengendalian dari jenis resiko.

3. Mengukur dampak dan kuantitas berbagai jenis resiko.

4. Menentukan kebjakan dalam rangka mengambil keputusan terhadap resiko yang berdampak besar.

Cakupan resiko risk assesment : 1. Operasional Proses

2. Operasional Sumber Daya Manusia 3. Operasional Sistem Teknologi Informasi 4. Faktor Eksternal

1. Identifikasi resiko :

a. Mengetahui dimana saja resiko berada b. Mengetahui penyebab timbulnya resiko

c. Mengetahui metode yang digunakan untuk mengidentifikasi keberadaan dan penyebab resiko

d. Mengetahui pengendalian yang ada bila resiko itu terjadi

2. Pengukuran resiko

a. Kuantitatif : “Analisis berdasarkan angka-angka nyata (nilai finansial) terhadap biaya dan besarnya kerugian yang terjadi”

b. Kualitatif : “Sebuah analisis yang menentukan resiko tantangan organisasi dimana penilaian tersebut dilakukan berdasarkan institusi, tingkat keahlian dalam menilai jumlah resiko yang mungkin terjadi dan potensi kerusakannya”

Hal-hal yang harus diperhatikan dalam risk assessment :

1. Membuat prioritisasi kemungkinan gangguan yang terjadi berdasarkan tingkat kerusakan dan kemungkinan terjadinya.

2. Membuat suatu gap analysis dengan membandingkan BCP atau DRP atau Contingency Plan yang dimiliki saat ini dengan hasil Risk Assessment.

3. Melakukan analisis resiko yang akantimbul bagi perusahaan dan stakeholders akibat adanya gangguan atau bencana.

2.9.6 Uji dan Tinjau Resiko (Risk Monitoring and Testing)

Risk monitoring and testing adalah langkah terahkir dalam proses rencana kelangsungan bisnis (business continuity plan). Risk monitoring and

testing memastikan bahwa BCP dalam sebuah perusahaan dapat berjalan dengan baik melalui :

1. Penggabungan BIA and ke risk assessment dalam BCP dan testing program. 2. Pengembangan program testing perusahaan.

3. Penetapan dari aturan dan tanggung jawab dalam implementasi testing program

4. Evaluasi dari testing program dan hasil test oleh menejemen senior dan unit kerja.

5. Penilaian dari testing program dan hasil testing oleh pihak independent.

6. Revisi dari BCP dan testing program berdasarkan perubahan operasi bisnis, audit, dan rekomendasi dari pemeriksaan dan hasil test

2.10 PT. Telkom MSC Area V Jawa Timur

PT. Telekomunikasi Indonesia, Tbk atau yang bisa disebut sebagai PT. Telkom merupakan perusahaan yang bergerak dibidang telekomunikasi, informasi, media dan edutainment (TIME). PT Telkom mempunyai beberapa divisi sebagai unit bisnisnya diantaranya adalah Divisi Akses, Divisi Infratel, Divisi Telkom Flexi, Divisi Multimedia, Telkom MSC dan lain-lain.

Telkom MSC (Maintenance Service Center) merupakan salah satu divisi dari PT. Telekomunkasi Indonesia, Tbk yang fungsi utamanya yaitu melakukan maintenance management infrastruktur perangkat telekomunikasi yang dimiliki oleh Telkom. Untuk melakukan maintenance management, Telkom MSC membagi area pengelolaannya menjadi tujuh, yaitu Area I Sumatra, Area II DKI

Jakarta, Area III Jawa Barat, Area IV Jawa Tengah dan DIY, Area V Jawa Timur, Area VI Kalimantan dan Area VII Kawasan Timur Indonesia (KTI).

Seiring berkembangnya teknologi telekomunikasi dan banyaknya unit bisnis yang dimiliki oleh PT. Telkom, maka Telkom MSC juga harus bisa melakukan maintenance management pada setiap divisi yang dimiliki oleh PT. Telkom dan mendukung kegiatan operasional pada setiap divisi diantaranya melakukan perbaikan dan pemeliharaan perangkat telekomunikasi pada infrastruktur yang dimiliki oleh Divisi Akses, Divisi Infratel, Divisi Multimedia, dan Divisi Telkom Flexi.

Pada Bab III dalam Perencanaan Information Technology Service

Continuity Management (ITSCM) akan membahas semua aktivitas yang

dilakukan dari awal kegiatan sampai akhir. Gambar 3.1 merupakan alur dari serangkaian kegiatan metodologi penelitian.

Gambar 3.1 Metodologi Penelitian

3.1 Tahap Awal 3.1.1 Studi Literatur

Studi literatur dilakukan selama kegiatan penelitian ini berlangsung. Studi ini dilakukan dengan cara studi literatur di perpustakan atau via web. Hal ini bertujuan untuk memperoleh data dan pengetahuan yang lebih mengenai materi perencanaan Information Technology Service Continuity Management yang akan dibuat adalah :

1. Mengenai frameworkITIL 2. Mengenai ITIL service design 3. Mengenai ITIL service support 4. Mengenai ITIL service delivery

5. Mengenai ITIL Continuity Management

6. Mengenai proses maintenance dan repair pada PT. Telkom MSC Area V Jawa Timur

3.1.2 Identifikasi dan Analisis Permasalahan

Identifikasi permasalahan dimaksudkan untuk mengetahui penyebab permasalahan atau manfaat peluang yang ada. Analisis permasalahan dimaksudkan untuk mengetahui permasalahan atau peluang apa yang ada pada perusahaan.

A.Wawancara

Wawancara yang dilakukan dengan officer access untuk mengetahui permasalahan yang sedang dihadapi perusahaan atau peluang apa yang bisa

diberikan untuk memberikan manfaat bagi perusahaan. Dari wawancara ini dapat diperoleh berbagai informasi seperti profil perusahaan, visi, misi, struktur, proses maintenance, proses repair, department need, department goal, dll. Wawancara ini dibagi menjadi empat topik seperti yang tampak pada gambar 3.2.

Gambar 3.2 Alur proses wawancara

B.Observasi

Selain melakukan wawancara, juga diperlukan observasi terkait proses bisnis maintenance dan repair pada PT. Telkom MSC Area V Jawa Timur. Selain itu dalam observasi juga dimaksudkan untuk mengetahui bagaimana proses maintenance dan repair dilakukan.

3.2 Tahap Pengembangan 3.2.1 Initiation

Pada tahap ini ada dua hal yang harus dilakukan untuk melakukan inisiasi sebuah proyek. Tahap ini mendifinisikan hal-hal terkait kebijakan, ruang lingkup, serta bagaimana memulai suatu proyek, khususnya dalam membuat perencanaan ITSCM. Initiation memiliki peran sebagai kumpulan persyaratan dan sasaran dari semua pihak untuk mendapatkan persetujuan

mengenai pendekatan, kebijakan dan ruang lingkup. Initiation memastikan bisnis dan majamenen untuk memahami dan mengapresiasi seluruh isu kunci permasalahan. Proses pada tahap initiation ini mencakup proses seperti :

a. Mendefinisikan kebijakan (Policy Setting)

Proses ini bertujuan untuk mengetahui bagaimana kebijakan yang ada pada perusahaan terkait dengan proses maintenance dan repair. Kebijakan ini sangatlah penting karena akan menjadi acuan bagi setiap proses atau kegiatan yang ada pada perusahaan, termasuk juga dapat berpengaruh terhadap perencanaan ITSCM yang akan dibuat. Proses untuk mendapatkan kebijakan dapat dilihat pada gambar 3.3, sedangkan penjelasannya dapat dilihat pada tabel 3.1.

Ada revisi ? Literatur

Membuat dokumen wawancara

Dokumen wawancara

Wawancara dengan manajemen Ya

Verifikasi Tidak

Dokumen kebijakan

1

2

3

Alur pada gambar 3.3 dimulai dengan studi literatur. Untuk mendapatkan kebijakan manajemen terkait hal tersebut maka dilakukan proses wawancara yang dilakukan dengan pihak manajemen. Sebelum melakukan wawancara, perlu mempersiapkan materi terkait wawancara untuk dapat langsung dilakukan wawancara dengan pihak manajemen. Hasil wawancara itu nantinya digunakan sebagai acuan, karena dalam perencanaan ITSCM ini menggunakan kebijakan dari pihak perusahaan.

Tabel 3.1 Penjelasan alur mendefinisikan kebijakan

Nama Proses Input Kegiatan Output

1. Membuat dokumen wawancara

Dokumen literatur 1. Review literatur 2. Membagi wawancara

menjadi empat topik 3. Membuat dokumen

wawancara Dokumen wawancara 2. Wawancara dengan manajemen Dokumen wawancara Berdiskusi dengan

manajemen terkait materi wawancara

Catatan revisi (jika ada)

3. Verifikasi Catatan revisi (jika ada)

Pengecekan akhir Dokumen kebijakan

b. Mendefinisikan ruang lingkup (Scope)

Proses ini bertujuan untuk menentukan ruang lingkup perusahaan yang akan dijadikan bahan dalam membuat perencanaan ITSCM. Sehingga hasilnya nanti dapat sesuai dengan kebutuhan dan harapan bagi pihak perusahaan. Proses untuk mendapatkan ruang lingkup dapat dilihat pada gambar 3.4, sedangkan penjelasannya dapat dilihat pada tabel 3.2.

Ada revisi ? Literatur Membuat dokumen wawancara Dokumen wawancara Wawancara dengan manajemen Ya Verifikasi Tidak Ruang lingkup 1 2 3

Gambar 3.4 Alur mendefinisikan ruang lingkup

Alur pada gambar 3.4 dimulai dengan studi literatur. Untuk dapat menentukan ruang lingkup dalam perencanaan ITSCM ini, perlu dilakukan wawancara dengan pihak manajemen. Sama seperti wawancara untuk mendapatkan kebijakan, sebelum melakukan wawancara ini perlu dipersiapkan materi terkait wawancara yang akan dilakukan. Hasil wawancara itu nantinya dapat diketahui ruang lingkup terkait perencanaan ITSCM yang akan dibuat.

Tabel 3.2 Penjelasan alur mendefinisikan ruang lingkup

Nama Proses Input Kegiatan Output

1. Membuat dokumen wawancara

Dokumen literatur

1. Review literatur 2. Membagi wawancara

menjadi empat topik 3. Membuat dokumen

wawancara Dokumen wawancara 2. Wawancara dengan manajemen Dokumen wawancara

Berdiskusi dengan manajemen terkait materi wawancara

Catatan revisi (jika ada) 3. Verifikasi Catatan revisi

(jika ada)

Pengecekan akhir Dokumen

3.2.2 Requirements and Strategy

Setelah tahap initiation dilaksanakan, tahap selanjutnya adalah mengetahui bagaimana kebutuhan perusahaan. Kemudian dituangkan dalam langkah-langkah atau strategi apa saja yang akan digunakan untuk proses pembuatan perencanaan ITSCM guna menjawab kebutuhan tersebut. Proses lain dalam tahap ini adalah :

a. Business Impact Analysis (BIA)

Proses ini bertujuan untuk mengidentifikasi dampak permasalahan bagi bisnis perusahaan, mengetahui aktivitas yang penting dan penentuan target waktu pemulihan. Proses untuk menyusun BIA dapat dilihat pada gambar 3.5, sedangkan penjelasannya dapat dilihat pada tabel 3.3. Ada lima proses yang dilakukan pada saat tahap ini yaitu :

1. Membuat dokumen wawancara

Dokumen wawancara ini dibuat sesuai dengan topik wawancara yang akan dilakukan dengan pihak manajemen.

2. Menganalisis permasalahan

Analisis ini dimaksudkan untuk mengetahui permasalahan atau peluang apa yang ada pada perusahaan.

3. Mengidentifikasi permasalahan

Identifikasi ini dimaksudkan untuk mengetahui penyebab permasalahan atau manfaat peluang yang ada.

4. Mengisi lembar kerja

Lembar kerja ini dimaksudkan untuk mengetahui periode disaat resiko menjadi gangguan serta dampaknya terhadap operasional.

5. Membuat dokumen BIA

Dokumen ini dimaksudkan untuk mengetahui siapa dan apa saja yang berkaitan dengan proses BIA.

Ada revisi ? Literatur

Membuat dokumen wawancara

Dokumen wawancara

Analisa dan identifikasi permasalahan Ya Verifikasi Tidak Analisa dan identifikasi permasalahan

Membuat lembar kerja

Ada revisi ? Ya Verifikasi Tidak Lembar kerja A B A B Membuat dokumen BIA

Ada revisi ?

Verifikasi BIA Tidak Ya 1 2 3 4 5 6 7

Gambar 3. 5 Alur Menyusun BIA

Alur pada gambar 3.5 dimulai dengan studi literatur. Hasil analisa dan identifikasi permasalahan yang telah dibuat digunakan sebagai acuan dalam melakukan BIA. Dalam melakukan BIA itu sendiri terdapat empat proses utama yang harus dilakukan yaitu mengidentifikasi pihak dan sumber daya yang berkaitan dengan BIA, mengetahui hubungan antara peran setiap pihak dengan setiap sumber daya, mengidentifikasi periode pemulihan dan yang terakhir membuat daftar urutan prioritas pemulihan.

Keterangan :

1. Untuk lembar kerja mengacu pada ready business. 2. Untuk dokumen BIA mengacu pada CDC.

Tabel 3.3 Penjelasan alur menyusun BIA

Nama Proses Input Kegiatan Output

1. Membuat dokumen wawancara

Dokumen literatur

1. Review literatur 2. Membagi wawancara

menjadi empat topik 3. Membuat dokumen

wawancara

Dokumen wawancara

2. Analisa dan identifikasi permasalahan

Dokumen wawancara

1. Mengetahui alur proses layanan (maintenance dan repair)

2. Mengetahui permasalahan apa yang ada pada layanan 3. Mengetahui titik

keputusan apa yang diambil

4. Mengetahui siapa personil kuncinya

Template analisa dan identifikasi permasalahan

3. Verifikasi Template analisa dan identifikasi permasalahan

Pengecekan akhir Dokumen

analisa dan identifikasi permasalahan 4. Membuat lembar

kerja

Dokumen analisa dan identifikasi permasalahan

Membuat / mencari template yang sesuai untuk dokumen lembar kerja

Template lembar kerja

5. Verifikasi Template lembar kerja

Pengecekan akhir Dokumen

lembar kerja 6. Membuat dokumen BIA 1. Dokumen wawancara 2. Dokumen analisa dan identifikasi permasalahan 3. Dokumen lembar kerja

Membuat / mencari template yang sesuai untuk dokumen BIA

Catatan revisi (jika ada)

7. Verifikasi Catatan revisi (jika ada)

Pengecekan akhir Dokumen

b. Risk Assessment (RA)

Proses ini bertujuan untuk mengidentifikasi setiap resiko atau kendala yang dihadapi oleh perusahaan sehingga dapat diperoleh gambaran dalam pengendalian fungsi bisnis. Proses untuk menyusun RA dapat dilihat pada gambar 3.6, sedangkan penjelasannya dapat dilihat pada tabel 3.4.

Analisa Permasalahan

Identifikasi Permasalahan

Dokumen Wawancara

Melakukan Risk Assessment

Ada revisi ?

Ya

Verifikasi

Risk Assessment

Tidak

1

2

Gambar 3.6 Alur menyusun RA

Alur pada gambar 3.6 dimulai dengan melakukan review dokumen wawancara, dokumen analisa permasalahan dan dokumen identifikasi permasalahan. Proses yang harus dilakukan dalam RA ini terdapat lima proses utama yaitu mengidentifikasi bahaya, mengetahui siapa dan bagaimana yang dirugikan, mengevaluasi setiap resiko dan menentukan tindakan pemulihan, merekam temuan dan yang terakhir meninjau penilaian dan melakukan update jika dibutuhkan.

Tabel 3.4 Penjelasan alur menyusun RA

Nama Proses Input Kegiatan Output

1. Melakukan RA

1. Dokumen analisa permasalahan 2. Dokumen identifikasi permasalahan 3. Dokumen wawancara

1. Membuat / mencari template yang sesuai untuk dokumen RA 2. Memastikan setiap

proses pada RA telah sesuai

Catatan revisi (jika ada)

2. Verifikasi Catatan revisi (jika ada)

Pengecekan akhir Dokumen RA

Ada 4 proses yang dilakukan pada saat tahap RA ini yaitu : 1. Risk Assessment

Proses pertama yang dilakukan adalah menilai setiap resiko yang telah diidentifikasi. Proses ini dimaksudkan agar dapat mengetahui tingkat resiko dari berbagai jenis resiko, melakukan pengendalian dari setiap jenis resiko, mengukur dampak dan kuantitas berbagai jenis resiko serta pilihan keputusan yang dapat diambil terhadap resiko.

2. Manajemen resiko

Menggunakan metode Management of Risk (M_O_R) untuk melakukan analisis dan manajemen resiko pada PT. Telkom MSC Area V Jawa Timur. 3. Mengelompokkan resiko / gangguan

Hasil dari analisa dan identifikasi permasalahan, dapat diketaui kendala apa saja yang terjadi pada proses maintenance dan repair. Kemudian digambarkan pengelompokkan resiko atau gangguan tersebut serta penyebab apa saja yang membuat resiko itu dapat terjadi.

4. Menunjukkan profil dari setiap resiko

Proses selanjutnya adalah menentukan tindakan untuk mengelola resiko. Dalam konteks ITSCM, ada sejumlah resiko dan penyebab resiko yang perlu dipertimbangkan penanganannya terkait tingkat setiap resikonya dan penyebabnya. Dari setiap daftar penyebab yang telah dibuat pada saat proses pengelompokkan resiko / gangguan, nantinya disusun berdasarkan tingkat terjadi dan dampaknya, yang terbagi menjadi :

a. Most severe : beresiko tinggi

b. Acceptable risk : resiko yang dapat diterima (beresiko sedang / jarang terjadi)

c. Least severe : beresiko rendah

d. Least likely : paling tidak sering terjadi e. Most likely : paling sering terjadi Keterangan :

1. Untuk risk assessment menggunakan metode dari HSE (Health and Safety Executive)

2. Untuk manajemen resiko menggunakan metode M_O_R

3. Dokumen untuk mengelompokkan resiko / gangguan telah disesuaikan dengan framework ITIL V-3

4. Dokumen untuk menunjukkan profil dari setiap resiko disesuaikan dengan framework ITIL V-3

c. ITSCM Strategy

Proses ini memiliki fokus terhadap tindakan atau pilihan langkah-langkah strategi yang akan diambil, yang disesuaikan antara kebutuhan bisnis dan tujuan bisnis dengan hasil dari proses BIA dan Risk Assessment (RA). Diharapkan strategi yang dibuat dapat sesuai dengan kebutuhan, proses, fungsi bisnis serta resiko. Proses untuk menyusun strategi ITSCM dapat dilihat pada gambar 3.7, sedangkan penjelasannya dapat dilihat pada tabel 3.5.

BIA Risk

Assessment

Review

Ada revisi ?

Ya

Verifikasi

Strategi ITSCM Tidak Menentukan strategi ITSCM

1

2

3

Gambar 3.7 Alur Menyusun Strategi ITSCM

Alur pada gambar 3.7 dimulai dengan review dokumen BIA dan dokumen RA. Kemudian menentukan strategi ITSCM yang disesuaikan dengan fungsi dan kebutuhan bisnis.

Tabel 3.5 Penjelasan alur menyusun strategi ITSCM

Nama Proses Input Kegiatan Output

1. Review 1. Dokumen BIA

2. Dokumen RA

Mengecek dokumen BIA dan RA yang telah dihasilkan

-

2. Menentukan strategi ITSCM

Hasil review Menyesuaikan strategi dengan fungsi dan kebutuhan bisnis

Strategi ITSCM

3. Verifikasi Strategi ITSCM Pengecekan akhir Dokumen strategi ITSCM

A.Wawancara

Wawancara yang dilakukan pada tahap ini bertujuan untuk menyelaraskan antara kebutuhan perusahaan dengan strategi yang akan digunakan. Hasil dari wawancara ini juga dapat memberi gambaran tentang resiko dan dampak apa saja yang mungkin dapat muncul sehingga dapat menjadi pertimbangan dalam penyusunan strategi.

3.2.3 Implementation

Tahap ini menentukan langkah-langkah pembuatan perencanaan ITSCM yang disesuaikan dengan hasil dari proses-proses sebelumnya. Nantinya langkah ini dapat menjadi acuan yang menghasilkan dokumen perencanaan ITSCM yang di dalamnya mencakup IT Service Continuity Plan,

Standard Operational Procedures, Work Instruction dan Work Record.

Disamping itu juga dapat menghasilkan dokumen tambahan (supporting documents) seperti Recovery Procedures, Test Procedures, Test Schedule dan Test Instructions. Proses dalam tahap ini adalah :

a. Recovery Plan

Proses ini bertujuan untuk menentukan rencana pemulihan apa yang akan dibuat yang telah disesuaikan dengan kebutuhan, proses, fungsi bisnis serta resiko. Proses untuk menyusun recovery plan dapat dilihat pada gambar 3.8, sedangkan penjelasannya dapat dilihat pada tabel 3.6.

BIA Risk

Assessment

Review

Ada revisi ?

Ya

Verifikasi

Recovery Plan Tidak Menentukan perencanaan pemulihan

ITSCM Strategy

1

2

3

Gambar 3.8 Alur Menyusun Recovery Plan

Alur pada gambar 3.8 dimulai review dokumen BIA, dokumen RA dan dokumen ITSCM strategy. Kemudian dapat menentukan pilihan pemulihan yang disesuaikan dengan karakteristik resiko dan fungsi bisnis.

Tabel 3.6 Penjelasan alur menyusun recovery plan

Nama Proses Input Kegiatan Output

1. Review 1. Dokumen BIA

2. Dokumen RA 3. Dokumen strategi

ITSCM

Mengecek dokumen BIA, dokumen RA dan dokumen strategi ITSCM yang telah dihasilkan

-

2. Menentukan perencanaan pemulihan

Hasil review Menyesuaikan

perencanaan pemulihan sesuai fungsi dan karakteristik bisnis

Rencana pemulihan

3. Verifikasi Rencana pemulihan Pengecekan akhir Dokumen recovery plan

b. Testing Plan

Testing plan merupakan bagian langkah yang ada pada proses Develop ITSCM Plans. Dalam penjabarannya, testing plan ini terbagi menjadi tiga, seperti yang tampak pada Gambar 3.9.

Gambar 3.9 Testing Plan Pembagian testing plan menjadi tiga proses yaitu : 1. Testing Procedures

Prosedur pengujian mengidentifikasi pemeriksaan secara spesifik mengenai tes yang akan dilakukan. Definisi untuk menjelaskan dokumen dan tujuan untuk menjelaskan fungsi dari dokumen.

2. Testing Instructions

Rencana pemulihan yang belum diuji sepenuhnya bisa tidak berjalan seperti yang direncanakan. Testing merupakan bagian penting pada proses ITSCM dan untuk memastikan setiap proses dalam ITSCM telah dilakukan. Proses untuk menyusun testing instruction dapat dilihat pada gambar 3.10, sedangkan penjelasannya dapat dilihat pada tabel 3.7.

Perencanaan ITSCM

Review

Ada revisi ?

Ya

Verifikasi

Testing Instruction

Tidak Melakukan pemeriksaan

Framework ITIL V-3

1

2

3

Gambar 3.10 Alur Menyusun Testing Instruction

Alur pada gambar 3.10 dimulai dengan review dokumen perencanaan ITSCM dan framework ITIL V-3. Kemudian dapat diuji kesesuaian antara keduanya.

Tabel 3.7 Penjelasan alur menyusun testing instruction

Nama Proses Input Kegiatan Output

1. Review 1. Dokumen

Perencanaan ITSCM

2. Framework ITIL V-3

Mengecek dokumen BIA, dokumen RA dan

dokumen strategi ITSCM yang telah dihasilkan

-

2. Menentukan pemeriksaan

Hasil review Menyesuaikan dokumen perencanaan ITSCM dengan framework ITIL V-3

Catatan revisi (jika ada)

3. Verifikasi Catatan revisi (jika ada)

Pengecekan akhir Dokumen testing instruction

3. Testing Schedule

Jadwal pengujian mengidentifikasi tanggal dan waktu untuk pelaksanaan pemeriksaan dan pengujian. Serta menentukan siapa saja pihak penguji dan apa saja topik yang akan dibahas pada saat pengujian. Proses untuk menyusun testing schedule dapat dilihat pada gambar 3.11, sedangkan penjelasannya dapat dilihat pada tabel 3.8.

Perencanaan ITSCM

Review

Ada revisi ?

Ya

Verifikasi

Testing Schedule Tidak

Tentukan hal-hal yang berkaitan dengan pengujian Framework ITIL V-3 1 2 3

Alur pada gambar 3.11 dimulai dengan review dokumen perencanaan ITSCM dan framework ITIL V-3. Kemudian dapat ditentukan jadwal pengujiannya dengan para ahli.

Tabel 3.8 Penjelasan alur menyusun testing schedule

Nama Proses Input Kegiatan Output

1. Review 1. Dokumen

Perencanaan ITSCM 2. Framework

ITIL V-3

Mengecek dokumen perencanaan ITSCM dan framework ITIL V-3

-

2. Menentukan hal-hal terkait dengan pengujian

Hasil review Menyesuaikan jadwal pengujian, lokasi pengujian dan para ahli selaku pihak penguji

Jadwal dan lokasi pengujian serta pihak penguji 3. Verifikasi Jadwal dan lokasi

pengujian serta pihak penguji

Pengecekan akhir Dokumen testing schedule

c. Develop Recovery Plan

Proses ini bertujuan untuk mengembangkan rencana pemulihan yang telah dibuat agar jika rencana pemulihan awal tidak dapat berjalan, dapat langsung dilakukan penerapan rencana pemulihan berikutnya. Waktu pemulihan harus sesuai dengan tujuan waktu pemulihan untuk setiap fungsi bisnis. Proses untuk menyusun develop recovery plan dapat dilihat pada gambar 3.12, sedangkan penjelasannya dapat dilihat pada tabel 3.9.

BIA

Review

Ada revisi ?

Ya Verifikasi Develop Recovery Plan Tidak Menentukan rencana pengembangan pemulihan Risk

Assessment ITSCM Strategy

1

2

3

Gambar 3.12 Alur Menyusun Develop Recovery Plan

Alur pada gambar 3.12 dimulai dengan review dokumen BIA, dokumen RA dan dokumen ITSCM strategy. Kemudian dapat menentukan rencana pengembangan pemulihan yang disesuaikan dengan karakteristik resiko dan fungsi bisnis.

Tabel 3.9 Penjelasan alur menyusun develop recovery plan

Nama Proses Input Kegiatan Output

1. Review 1. Dokumen BIA

2. Dokumen RA 3. Dokumen strategi

ITSCM

Mengecek dokumen BIA, dokumen RA dan dokumen strategi ITSCM yang telah dihasilkan

-

2. Menentukan rencana pengembang an pemulihan

Hasil review Menyiapkan rencana pengembangan pemulihan

Rencana pengembangan pemulihan 3. Verifikasi Rencana

pengembangan pemulihan

Pengecekan akhir Dokumen develop recovery plan

d. Recovery Procedures

Dari setiap pilihan pemulihan, perlu dijelaskan instruksi kerja apa saja terkait masing-masing dari pilihan pemulihan tersebut. Proses untuk menyusun recovery procedures dapat dilihat pada gambar 3.13, sedangkan penjelasannya dapat dilihat pada tabel 3.10.

BIA

Review

Ada revisi ?

Ya

Verifikasi

Recovery Procedures

Tidak Memberi penjelasan pilihan

pemulihan Risk

Assessment ITSCM Strategy

1

2

3

Gambar 3.13 Alur Menyusun Recovery Procedures

Alur pada gambar 3.13 dimulai dengan review dokumen BIA, dokumen RA dan dokumen ITSCM strategy. Kemudian memberikan penjelasan dari setiap pilihan pemulihan tersebut.

Tabel 3.10 Penjelasan alur menyusun recovery procedures

Nama Proses Input Kegiatan Output

1. Review 1. Dokumen BIA

2. Dokumen RA 3. Dokumen strategi

ITSCM

Mengecek dokumen BIA, dokumen RA dan dokumen strategi ITSCM yang telah dihasilkan

-

2. Memberi penjelasan pilihan pemulihan

Hasil review Menyiapkan penjelasan pilihan pemulihan

Penjelasan pilihan pemulihan 3. Verifikasi Penjelasan pilihan

pemulihan

Pengecekan akhir Dokumen recovery procedures

Keterangan :

1. Dokumen untuk recovery plan telah disesuaikan dengan framework ITIL V-3.

2. Dokumen untuk testingplan telah disesuaikan dengan framework ITIL V-3. 3. Dokumen untuk develop recovery plan telah disesuaikan dengan framework

ITIL V-3.

4. Dokumen untuk recovery procedures telah disesuaikan dengan framework ITIL V-3.

3.2.4 On-going Operation

Tahap ini adalah bagian akhir yang fungsinya untuk melakukan review dan perbandingan terhadap perencanaan Information Technology Service Continuity Management yang telah dibuat dengan framework ITIL V-3. Proses dalam tahap ini adalah :

a. Review

Proses ini bertujuan untuk me-review atau melakukan pengecekan terhadap dokumen perencanaan ITSCM yang telah dibuat apakah semua proses telah dilakukan atau belum.

b. Testing

Proses ini bertujuan untuk membandingkan hasil dokumen perencanaan ITSCM yang telah dibuat dengan framework ITIL V-3 terkait ITSCM, apakah setiap proses dan dokumennya sudah sesuai dengan framework tersebut atau tidak. Proses untuk menyusun fit test dapat dilihat pada gambar 3.14, sedangkan penjelasannya dapat dilihat pada tabel 3.11.

Perencanaan ITSCM

Review

Ada revisi ?

Ya

Verifikasi

Fit Test Tidak Melakukan pemeriksaan

Framework ITIL V-3

1

2

3

Gambar 3.14 Alur Menyusun Fit Test

Alur pada gambar 3.14 dimulai dengan review dokumen perencanaan ITSCM dan framework ITIL V-3. Kemudian memeriksa setiap proses dan detail proses di dalamnya. Serta memeriksa kesesuaian dengan framework ITIL V-3.

Tabel 3.11 Penjelasan alur menyusun fit test

Nama Proses Input Kegiatan Output

1. Review 1. Dokumen

Perencanaan ITSCM 2. Framework ITIL V-3

Mengecek dokumen perencanaan ITSCM dan framework ITIL V-3

-

2. Melakukan pemeriksaan

Hasil review Mengecek setiap dokumen sebelum dilakukan uji ahli

Catatan revisi (jika ada)

3. Verifikasi Catatan revisi (jika ada) Pengecekan akhir Dokumen fit test

3.3Tahap Akhir 3.3.1 Evaluasi

Pada tahap ini dilakukan evaluasi dan penyesuaian dari hasil perencanaan ITSCM yang telah dibuat dengan framework ITIL V-3. Akan dilakukan perbandingan ketepatan hasil perencanaan dengan data-data yang yang telah ada, sehingga hasilnya dapat menjadi acuan kerja bagi stakeholder.

3.3.2 Kesimpulan dan Saran

Pada tahap ini akan dijelaskan kesimpulan dari apa yang dikerjakan pada proses pembuatan perencanaan ITSCM. Isi kesimpulan berupa penjelasan hasil perbandingan kesesuaian perencanaan ITSCM yang telah dibuat dengan framework ITIL V-3. Dalam melakukan uji perbandingan tersebut, penulis mengacu pada ahli seperti :

1. Ahli dalam proses maintenance dan repair pada PT. Telkom MSC Area V Jawa Timur.

3. Ahli dalam bidang ITSCM.

Diharapkan hasil perbandingan tersebut dapat menjawab perumusan masalah dan tujuan yang telah ditetapkan. Sedangkan saran, berisi tentang saran perbaikan terhadap kekurangan yang ada dari perencanaan ITSCM yang telah dibuat.

BAB IV

HASIL DAN PEMBAHASAN

Pada Bab IV ini akan membahas hasil analisis dalam perencanaan

Information Technology Service Continuity Management (ITSCM) pada PT.

Telkom MSC Area V Jawa Timur. Hasil yang didapatkan dari masing-masing tahapan iniation, requirements & strategy, implementation dan on-going operation adalah sebagai berikut.

4.1Initiation

Initiation didapatkan dari hasil wawancara kepada pihak officer access perusahaan dan juga studi literatur.

4.1.1 Mendefinisikan Kebijakan (Policy Setting)

Hasil dari jawaban wawancara yang telah dilakukan dengan pihak officer access terkait kebijakan perusahaan mengenai kegiatan maintenance dan repair diperoleh form kebijakan perusahaan yang akan digunakan sebagai acuan dalam melakukan kegiatan maintenance dan repair, termasuk juga dapat berpengaruh terhadap dokumen perencanaan ITSCM yang akan dibuat. Pada Gambar 4.1 dan 4.2 dapat dilihat kebijakan yang mengatur layanan serta layanan apa saja yang diberikan oleh perusahaan.

Gambar 4.1 Kebijakan terkait layanan 4.1.2 Mendefinisikan Ruang Lingkup (Scope)

Pada Gambar 4.2 dapat diketahui layanan apa yang diberikan oleh perusahaan dan layanan itulah yang akan menjadi bahasan dalam pembuatan perencanaan ITSCM. Selain mengetahui layanan apa saja yang ada, perlu juga untuk mengetahui profil department atau divisi, dalam hal ini MSC.

Dari hasil wawancara dengan pihak officer access diperoleh informasi terkait visi dan misi MSC serta struktur organisasi yang ada, termasuk juga peran dan tanggung jawab dari setiap posisi.

Gambar 4.2 Layanan perusahaan yang telah disepakati

4.2Requirements and Strategy

4.2.1 Business Impact Analysis (BIA)

Berikut contoh hasil dokumen yang dihasilkan seperti : 1. Membuat dokumen wawancara

Dokumen wawancara ini dibuat berdasarkan 4 topik yang berbeda, yaitu menentukan studi Tugas Akhir (TA), menentukan ruang lingkup, identifikasi permasalahan dan analisis permasalahan. Gambar 4.3 dibawah ini merupakan contoh wawancara dalam menentukan studi TA.

Gambar 4.3 Dokumen wawancara 2. Menganalisis permasalahan

Proses ini dilakukan untuk dapat mengetahui bagaimana alur kerja dari proses maintenance dan repair, sehingga dapat diketahui permasalahan atau peluang apa yang ada. Seperti yang tampak pada gambar 4.4 merupakan hasil analisis terkait proses maintenance.

Gambar 4.4 Analisis Permasalahan 3. Mengidentifikasi permasalahan

Seperti yang tampak pada tabel 4.1. Proses ini menghasilkan dokumen yang dapat digunakan untuk mengetahui hal-hal terkait permasalahan dari setiap proses maintenance dan repair, seperti penyebab, dampak, solusi serta siapa personil yang bertanggung jawab.

Tabel 4.1 Dokumen Identifikasi Permasalahan

4. Mengisi lembar kerja

Dokumen lembar kerja ini dapat dilihat pada tabel 4.2. dokumen ini untuk mengetahui bagaimana dampak operasional yang terjadi sebagai akibat dari adanya permasalahan yang tidak dapak diselesaikan selama periode yang telah ditentukan kriterianya. Setiap kriteria durasi waktu yang telah ditentukan, ditentukan bagaimana dampak yang terjadi jika ada permasalahan selama periode durasi waktu tersebut.

Tabel 4.2 Dokumen Lembar Kerja

5. BIA

Dokumen yang dihasilkan dapat dilihat pada tabel 4.3, dan isi dari setiap detailnya seperti :

1. Hasil identifikasi pihak dan sumber daya yang berkaitan dengan BIA. Untuk mengetahui setiap pihak sumber daya yang ada terkait dengan proses BIA.

2. Hasil hubungan antara peran pihak setiap pihak dengan sumber daya. Untuk mengetahui hubungan antara peran dari setiap pihak dengan sumber daya yang ada.

3. Hasil identifikasi periode pemulihan.

Mengetahui dampak gangguan dan waktu pemulihan yang dipilih. Mengidentifikasi periode pemulihan maksimum yang dapat diterima

ketika sumber daya tidak ada sebelum terjadi dampak yang tidak diinginkan. Semua dokumen itu dihasilkan pada setiap proses dibawahnya.

4. Hasil daftar urutan prioritas pemulihan.

Daftar urutan prioritas pemulihan untuk semua sumber daya yang telah diidentifikasi sebelumnya. Prioritas pemulihan digambarkan dengan skala 1 (tinggi), 2 (sedang) dan 3 (rendah).

5. Dokumen BIA.

Menggabungkan hasil dari setiap proses diatas dan dituangkan kedalam satu dokumen yaitu dokumen BIA.

4.2.2 Risk Assessment (RA)

Berikut contoh dokumen yang dihasilkan seperti : 1. Risk Assessment

Dokumen ini dapat dilihat pada tabel 4.4. dokumen ini untuk mengetahui gangguan apa yang ada, bagaimana dan siapa saja pihak yang dirugikan, apa yang telah dilakukan untuk menangani gangguan tersebut dan siapa yang melakukan tindakan penanganan gangguan itu.

Tabel 4.4 Dokumen Risk Assessment

What are the hazards?

Who might be harmed and how?

What are you already doing?

Do you need to do anything else to manage this risk?

Action by whom? Action by when? Done Kesalahan dalam proses maintenance

dan repair sehingga selesai tidak tepat waktu atau kurang optimal

Konsumen, karena pekerjaan

maintenance repair

(MR)terhambat

Melakukan training

karyawan dan

sharing knowledge

Mengingatkan petugas MR untuk memahami proses RM lebih baik

Assisten Manager - - Kurangnya kemampuan SDM perusahaan Karyawan, karena menambah beban pekerjaan

Melakukan training

karyawan dan sharing knowledge Evaluasi kinerja karyawan Assisten Manager - -

Hilangnya data / data yang tidak tepat

Karyawan, pekerjaan dapat terganggu jika terjadi kesalahan data

Melakukan back-up dan sinkronisasi data

- Assisten

Manager

- -

Kesalahan dalam proses distribusi modul / perangkat

Petugas MR salah melakukan pekerjaan

Mengecek kesesuaian modul

Mengingatkan karyawan untuk lebih memahami modul

Assisten Manager

- -

Tidak tersedianya dukungan dari staf teknis

Pekerjaan petugas MR dapat terganggu

Meningkatan hubungan antar karyawan

- Assisten

Manager

- -

2. Manajemen resiko

Dokumen ini menampilkan hasil dari setiap pendekatan yang dilakukan pada saat manajemen resiko seperti prinsip apa yang digunakan untuk manajemen resiko serta hal-hal apa yang telah disepakati dengan pihak officer access untuk melakukan manajemen resiko. Dokumen ini dapat dilihat pada tabel 4.5.

Tabel 4.5 Dokumen Manajemen Resiko

3. Pengelompokkan resiko

Dokumen ini mengelompokkan setiap resiko gangguan sesuai dengan hal-hal yang menyebabkan resiko itu dapat terjadi, dikelompokkan sesuai dengan karakteristik resiko yang sama. Dokumen ini dapat dilihat pada tabel 4.6.

Tabel 4.6 Dokumen Pengelompokkan Resiko

4. Menentukan profil resiko

Dokumen ini menampilkan setiap resiko gangguan berdasarkan tingkat terjadinya dan tingkat dampaknya, seperti yang tampak pada tabel 4.7.

4.2.3 ITSCM Strategy

Dengan mengetahui permasalahan dan kebutuhan pada perusahaan, maka dapat ditentukan strategi apa yang akan digunakan untuk dapat sesuai dengan permasalahan dan kebutuhan. Contoh dokumen yang dihasilkan dapat dilihat pada tabel 4.8.

Tabel 4.8 Dokumen Strategi ITSCM

4.3Implementation

4.3.1 Recovery Plans

Hasil dari dokumen ini adalah menentukan tindakan pemulihan apa yang akan dilakukan terkait dengan adanya resiko ganguan permasalahan. Ketika

resiko gangguan itu terjadi maka dapat mengetahui tindakan yang harus dilakukan. Contoh dokumen yang dihasilkan dapat dilihat pada tabel 4.9.

Tabel 4.9 Dokumen Recovery Plan

4.3.2 Testing Plan

Contoh dokumen yang dihasilkan seperti :

1. Testing Instruction

Dokumen ini digunakan untuk mengecek ketersediaan setiap dokumen detail proses dari masing-masing langkah pada proses ITSCM apakah sudah ada atau belum. Contoh dokumen yang dihasilkan dapat dilihat pada tabel 4.10.

Tabel 4.10 Dokumen Testing Instruction

2. Testing Schedule

Dokumen ini dibuat untuk melakukan pengujian dengan pihak perusahaan, yang detailnya menjelaskan tanggal pengujian, tempat pengujian, topik atau bahasan pengujian serta penguji dari pihak perusahaan. Tabel 4.11 merupakan hasil pengujian dengan pihak perusahaan.

4.3.3 Develop Recovery Plan

Dokumen ini adalah bentuk pengembangan dari dokumen recovery plan. Ketika rencana pemulihan awal telah dilakukan dan belum berhasil, maka perlu dilakukan tindakan pemulihan yang lain. Dokumen ini menampilkan pilihan pemulihan lain selain yang telah ditentukan pada saat membuat dokumen recovery plan. Contoh dokumen yang dihasilkan dapat dilihat pada tabel 4.12.

Tabel 4.12 Dokumen Develop Recovery Plan

4.3.4 Recovery Procedures

Dokumen ini memberikan penjelasan singkat mengenai setiap prosedur pemulihan yang ada. Contoh dokumen yang dihasilkan dapat dilihat pada tabel 4.13.

Tabel 4.13 DokumenRecovery Procedures

4.4On-going Operation

4.4.1 Review

Proses ini bertujuan untuk memastikan kembali hasil dari dokumen perencanaan ITSCM yang telah dibuat dengan framework ITIL V-3 terkait ITSCM, apakah setiap proses telah dilaksanakan dan menghasilkan dokumen yang sesuai dengan ITIL V-3 atau belum.

4.4.2 Testing

Proses ini bertujuan untuk membandingkan hasil dokumen perencanaan ITSCM yang telah dibuat dengan framework ITIL V-3 terkait ITSCM, apakah

setiap proses dan dokumennya sudah tersedia dan sudah sesuai dengan framework tersebut atau tidak. Contoh dokumen yang dihasilkan dapat dilihat pada tabel 4.14.

5.1 Kesimpulan

Pada proses pembuatan perencanaan Information Technology Service Continuity Management (ITSCM) terdapat 4 proses utama yaitu :

1. Initiation

2. Requirements and Strategy 3. Implementation

4. On-going Operation

Semua proses tersebut telah dilaksanakan dan menghasilkan dokumen-dokumen. Setelah mengikuti langkah-langkah dalam proses pembuatan perencanaan ITSCM dapat disimpulkan bahwa terdapat 8 Standard Operational Procedure (SOP), 16 Instruksi Kerja (IK) dan 43 Rekaman Kerja (RK).

Perencanaan yang dibuat ini diharapkan dapat memberi arahan kerja yang jelas tentang apa yang harus dilakukan ketika atau sebelum terjadi masalah atau gangguan baik pada proses maintenance maupun pada proses repair.

5.2 Saran

Saran yang diberikan untuk pengembangan lebih lanjut adalah menerapkan setiap proses perencanaan ITSCM yang telah dibuat ini pada PT. Telkom MSC Area V Jawa Timur. Tetapi sebelum diterapkan perlu dilakukan uji coba secara bertahap dari setiap proses pada perencanaan ITSCM.

Arraj, Valerie. 2010. ITIL : The Basics. UK: APM Group.

Clinch, Jim. 2009. ITIL V3 and Information Security. UK: Clinch Consulting

Faber, Michael dan Rubina Faber. 2010. ITIL and Corporate Risk Alignment Guide. UK: The Stationery Office.

Fitriani, Ida dan Edwar. 2010. Pembangunan Layanan Ideal Pada Proses ITIL. Bandung: Andi.

Fletcher, Franklin. “Business Impact Analysis”. http://www.giac.org/cissp-papers/122.pdf. Diakses 15 Mei 2013.

Graham, Williams. 2007. Management of Risk : Guidance for Practitioners.

Graham, Williams. 2011. Everything You Wanted To Know About Management of Risk (M_O_R) is Less Than 1000 Words. UK: The Stationery Office.

ITGI. 2007. The Official Introduction to the ITIL Service Lifecycle. USA: IT Governance Institute

itSMF. 2007. Foundations of IT Service Management Based on ITIL V3. Van Haren Publishing

Jogiyanto dan Abdillah, Willy. 2010. Sistem Tata Kelola Teknologi Informasi. Bulaksumur: Andi.

Meijer, Machteld; Mark Smalley, Sharon Taylor, Candace Dunwoodie. 2008. ITIL V3 and ASL : Sound Guidance For Application Management and Application Development. UK: The Stationery Office.

Meijer, Machteld; Mark Smalley, Sharon Taylor, Candace Dunwoodie. 2011. ITIL V3 and BiSL : Sound Guidance For Business IT Alignment From A Business Perspective. UK: The Stationery Office.

OGC. 2007. ITIL : Service Design. UK: The Stationery Office. Whittleston, Sandra. 2012. ITIL is ITIL. UK: The Stationery Office. Wibowo, Arrianto Mukti. 2009. Pengantar ITIL V-3.

Tabel 4.10 Dokumen Testing Instruction

2. Testing Schedule

Dokumen ini dibuat untuk melakukan pengujian dengan pihak perusahaan, yang detailnya menjelaskan tanggal pengujian, tempat pengujian, topik atau bahasan pengujian serta penguji dari pihak perusahaan. Tabel 4.11 merupakan hasil pengujian dengan pihak perusahaan.

68

4.3.3 Develop Recovery Plan

Dokumen ini adalah bentuk pengembangan dari dokumen recovery plan. Ketika rencana pemulihan awal telah dilakukan dan belum berhasil, maka perlu dilakukan tindakan pemulihan yang lain. Dokumen ini menampilkan pilihan pemulihan lain selain yang telah ditentukan pada saat membuat dokumen recovery plan. Contoh dokumen yang dihasilkan dapat dilihat pada tabel 4.12.

Tabel 4.12 Dokumen Develop Recovery Plan

4.3.4 Recovery Procedures

Dokumen ini memberikan penjelasan singkat mengenai setiap prosedur pemulihan yang ada. Contoh dokumen yang dihasilkan dapat dilihat pada tabel 4.13.

Tabel 4.13 Dokumen Recovery Procedures

4.4 On-going Operation 4.4.1 Review

Proses ini bertujuan untuk memastikan kembali hasil dari dokumen perencanaan ITSCM yang telah dibuat dengan framework ITIL V-3 terkait ITSCM, apakah setiap proses telah dilaksanakan dan menghasilkan dokumen yang sesuai dengan ITIL V-3 atau belum.

4.4.2 Testing

Proses ini bertujuan untuk membandingkan hasil dokumen perencanaan ITSCM yang telah dibuat dengan framework ITIL V-3 terkait ITSCM, apakah

70

setiap proses dan dokumennya sudah tersedia dan sudah sesuai dengan framework tersebut atau tidak. Contoh dokumen yang dihasilkan dapat dilihat pada tabel 4.14.

5.1 Kesimpulan

Pada proses pembuatan perencanaan Information Technology Service Continuity Management (ITSCM) terdapat 4 proses utama yaitu :

1. Initiation

2. Requirements and Strategy 3. Implementation

4. On-going Operation

Semua proses tersebut telah dilaksanakan dan menghasilkan dokumen-dokumen. Setelah mengikuti langkah-langkah dalam proses pembuatan perencanaan ITSCM dapat disimpulkan bahwa terdapat 8 Standard Operational Procedure (SOP), 16 Instruksi Kerja (IK) dan 43 Rekaman Kerja (RK).

Perencanaan yang dibuat ini diharapkan dapat memberi arahan kerja yang jelas tentang apa yang harus dilakukan ketika atau sebelum terjadi masalah atau gangguan baik pada proses maintenance maupun pada proses repair.

5.2 Saran

Saran yang diberikan untuk pengembangan lebih lanjut adalah menerapkan setiap proses perencanaan ITSCM yang telah dibuat ini pada PT. Telkom MSC Area V Jawa Timur. Tetapi sebelum diterapkan perlu dilakukan uji coba secara bertahap dari setiap proses pada perencanaan ITSCM.

DAFTAR PUSTAKA

Arraj, Valerie. 2010. ITIL : The Basics. UK: APM Group.

Clinch, Jim. 2009. ITIL V3 and Information Security. UK: Clinch Consulting

Faber, Michael dan Rubina Faber. 2010. ITIL and Corporate Risk Alignment Guide. UK: The Stationery Office.

Fitriani, Ida dan Edwar. 2010. Pembangunan Layanan Ideal Pada Proses ITIL. Bandung: Andi.

Fletcher, Franklin. “Business Impact Analysis”. http://www.giac.org/cissp-papers/122.pdf. Diakses 15 Mei 2013.

Graham, Williams. 2007. Management of Risk : Guidance for Practitioners.

Graham, Williams. 2011. Everything You Wanted To Know About Management of Risk (M_O_R) is Less Than 1000 Words. UK: The Stationery Office.

ITGI. 2007. The Official Introduction to the ITIL Service Lifecycle. USA: IT Governance Institute

itSMF. 2007. Foundations of IT Service Management Based on ITIL V3. Van Haren Publishing

Jogiyanto dan Abdillah, Willy. 2010. Sistem Tata Kelola Teknologi Informasi. Bulaksumur: Andi.

Meijer, Machteld; Mark Smalley, Sharon Taylor, Candace Dunwoodie. 2008. ITIL V3 and ASL : Sound Guidance For Application Management and Application Development. UK: The Stationery Office.

Meijer, Machteld; Mark Smalley, Sharon Taylor, Candace Dunwoodie. 2011. ITIL V3 and BiSL : Sound Guidance For Business IT Alignment From A Business Perspective. UK: The Stationery Office.

OGC. 2007. ITIL : Service Design. UK: The Stationery Office. Whittleston, Sandra. 2012. ITIL is ITIL. UK: The Stationery Office. Wibowo, Arrianto Mukti. 2009. Pengantar ITIL V-3.