09 Wika-Mif-Pm-03.01 - Prosedur Operasi Teknologi Informasi (01 Amd 01)

PT WIJAYA KARYA (Persero) Tbk No. Dok : WIKA-MIF-PM-03.
01
Divisi Infrastruktur II Rev : 01 Amd 01
JI. D.I. Panjaitan Kav. 10 Jakarta
Judul : Tanggal diberlakukan: Tanggal Review Berikutnya:
PROSEDUR OPERASI TEKNOLOGI INFORMASI 01 Juli 2020 30 Juni 2023
SEJARAH PERUBAHAN
Bentuk Perubahan : Lihat Sejarah Perubahan
Sebab Perubahan : Restrukturisasi Organisasi
Peraturan Peralihan : Tidak ada
MENYETUJUI
DEPARTEMENT REPRESENTATIVE
Nama Ainul Yakin
Jabatan MQHSE
Tanda Tangan
Tanggal 29 Juni 2021 29 Juni 2021
DISTRIBUSI
NO PENERIMA NO PENERIMA
1 PPD - Bendungan Lau Simeme Paket I (MYC)-JO 22 PPD - Jalan Tol Probolinggo
2 PPD - IPAL Pekanbaru 23 PPD - Bendungan Jeragung Paket II
3 PPD - Irigasi Sei Silau, (Deli - Serdang) 24 PPD - Pengamanan Muara Bogowonto Sisi Timur (KSN YIA)
4 PPD - Proyek Tol Pekanbaru - Padang 25 PPD - Pembangunan Penyediaan Air Baku Kendal
5 PPD - PLTU Pangkalan Susu 26 PPD - DEPT 5
6 PPD - Tol Serang - Panimbang 27 PPD - Jalan Tol Balikpapan - Samarinda, segmen 2, 3, 4
7 PPD - Bendungan Komering II / Tiga Dihaji 28 PPD - Dermaga Kijing
8 PPD - Pelabuhan Patimban Paket 1, Subang 29 PPD - Jembatan Sei Alalak
9 PPD - Pembangunan Bendungan Cipanas Paket 1-JO 30 PPD - Rehabilitasi & Peningkatan Jaringan Irigasi Rawa Kapuas
10 PPD - Bendungan Sukamahi 31 PPD - DEPT 6
11 PPD - Bendungan Kuningan 32 PPD - Bendungan Kuwil Kawangkoan, Sulut
12 PPD - Toll Cisumdawu Phase II-JO 33 PPD - Bandara Sultan Hasanudin Makasar
13 PPD - Pembangunan Bendungan Sadawarna Paket I - JO 34 PPD - Pembangunan Jalur KA Makasar - Pare-pare
14 PPD - DEPT 4 35 PPD - Bendungan Pamukkulu
15 PPD - Bendungan Tugu II Trenggalek 36 PPD - Bendungan Ameroro Paket 1
16 PPD - Fly Over Teluk Lamong (Pelindo 3) 37 PPD - DEPT 7
17 PPD - Bendungan RanduGunting 38 PPD - Bendungan Manikin
18 PPD - Reklamasi Kalibaru Semarang 39 PPD - Infrastruktur & Jaringan Utilitas Kawasan Mandalika
19 PPD - Pembangunan Waduk Bendo-JO 40 PPD - Pelabuhan Labuan Bajo
20 PPD - Fly Over Purwosari 41 PPD - Pemb. Jalan Perbatasan Oksibil - Towe Hitam (MYC) Lanjutan
21 PPD - Tol Semarang - Demak 27 Km 42 PPD - Jl SP Goro Muri
13 01/07/2020
PT. Wijaya Karya (Persero) Tbk No. Dok. : WIKA-MIF-PM-03.01
Jalan D.I. Panjaitan Kav. 9-10 Jakarta No. Rev. : 01 Amd 01
Prosedur Operasi Teknologi Informasi
SEJARAH PERUBAHAN
No. Revisi Amd. Tanggal Perubahan

1. Perubahan Organisasi, Perubahan PPD
1 01 00 1 Juli 2020
1. Perubahan Daftar distribusi
2 01 01 1 Okt 2020
2. Restrukturisasi penomoran di lampiran
Halaman 2 dari 17
No. Dok. : WIKA-MIF-PM-03.01
No. Rev. : 01 Amd 01
1.0 TUJUAN
Sebagai panduan dalam hal-hal yang terkait dengan pengembangan dan implementasi TI.
2.0 RUANG LINGKUP

2.1 Prosedur ini memberikan pengaturan terkait dengan:
a. Manajemen tingkat layanan TI
b. Manajemen pihak ketiga
c. Manajemen kapasitas
d. Manajemen ketersediaan
e. Manajemen keberlangsungan layanan
f. Manajemen keamanan
g. Manajemen insiden dan permintaan layanan
h. Manajemen permasalahan
i. Manajemen konfigurasi
j. Manajemen data
k. Manajemen pemeliharaan
2.2 Prosedur ini berlaku di seluruh Unit Kerja Perusahaan yang mengadakan kerja sama
dengan Pihak Luar dan bagi Pihak-Pihak Luar yang melakukan pekerjaan untuk dan
kerja sama dengan Perusahaan.
3.0 DEFINISI
3.1 Perusahaan adalah Perusahaan PT Wijaya Karya (Persero) Tbk.
3.2 Komite Pengarah TI (IT Steering Committee) merupakan struktur pengambil keputusan
TI pada level strategis yang membantu Dewan Direksi dalam implementasi arahan
strategis TI dan Tata Kelola TI di perusahaan, serta melakukan pengawasan atas
keberjalanan pengelolaan TI (pemberian layanan TI dan eksekusi proyek-proyek TI).
3.3 Departemen Sistem Informasi adalah unit kerja struktural Perusahaan yang
bertanggung jawab untuk mengelola Sistem Informasi Perusahaan, temasuk di
dalamnya adalah perencanaan, akusisi dan/ atau pengembangan aplikasi, pengelola
data, implementasi infrastruktur dan teknologi, operasional dan pemeliharaan aset TI,
penyampaian layanan, serta pelaksanaan quality assurance.
3.4 Tata Kelola TI adalah pengelolaan TI dalam perusahaan yang mencakup
kepemimpinan, struktur dan proses-proses yang memastikan efektifitas dan efisiensi
penggunaan TI yang memungkinkan organisasi untuk mencapai tujuannya.
3.5 Teknologi Informasi adalah suatu teknologi yang mencakup perangkat keras
(hardware), perangkat lunak (software), jaringan komunikasi, serta teknik pengelolaan
sumber data yang membantu mengumpulkan dan mentransformasikan sumber data
menjadi produk informasi serta menyebarkan informasi tersebut ke pengguna.
3.6 Informasi adalah data dalam segala bentuknya (input, output, dan data terproses) yang
digunakan oleh aktivitas bisnis.
3.7 Infrastruktur adalah teknologi dan fasilitas (hardware, sistem operasi, database
management system, networking, multimedia, beserta lingkungan yang memfasilitasi
dan mendukungnya) yang memungkinkan pemrosesan aplikasi-aplikasi.
3.8 Pelanggan/Pengguna adalah individu atau kelompok dalam unit struktural Perusahaan
yang membuat suatu kesepakatan berupa Perjanjian Tingkat Layanan dengan Unit
Pengelola TI dalam hal penggunaan suatu layanan Teknologi Informasi.
3.9 Pemilik Data adalah suatu unit organisasi Perusahaan yang memiliki data / informasi
yang dikelola melalui suatu sistem database sesuai dengan lingkup kerjanya.
Halaman 3 dari 17
3.10 Pemilik Proses Bisnis (Business Process Owner) adalah suatu unit organisasi
Perusahaan yang memiliki dan bertanggung jawab dalam pengelolaan proses bisnis
yang dijalankan melalui suatu sistem aplikasi sesuai dengan lingkup kerjanya.
3.11 Master Plan TI merupakan arsitektur TI masa depan dan tahapan implementasinya,
yang selaras dengan rencana bisnis perusahaan.
3.12 CAPEX (Capital Expenditure) adalah pengeluaran belanja TI yang dicatat sebagai aset,
baik terkait dengan pengembangan dan/atau akusisi software aplikasi atau
implementasi infrastruktur.
3.13 OPEX (Operational Expenditure) adalah pengeluaran belanja TI untuk mendukung
operasional TI tetap berlangsung dan tidak dicatat sebagai aset.
3.14 Arsitektur TI merupakan rancangan sistem informasi dan infrastruktur ke depan
perusahaan yang akan diimplementasikan, digunakan sebagai rujukan dalam
implementasi tahunan program TI.
3.15 Shared Services merupakan layanan TI yang digunakan secara bersama-sama di
lingkungan grup WIKA.
3.16 Pengelola Anggaran Teknologi Informasi adalah unit struktural Perusahaan yang
ditunjuk untuk mengelola anggaran Perusahaan termasuk didalamnya anggaran yang
terkait dengan pengelolaan Teknologi Informasi.
3.17 SDLC (Software Development Life Cycle) merupakan tahapan pengembangan
perangkat lunak yang mencakup analisa kebutuhan, desain, pengembangan koding,
testing dan implementasi.
3.18 Pengendalian Aplikasi (Application Control) adalah kontrol input, proses dan output
yang diimplementasikan pada aplikasi untuk memastikan akurasi, kelengkapan dan
keamanan informasi.
3.19 Perjanjian Tingkat Layanan (Service Level Agreement [SLA]) adalah suatu perjanjian
yang merepresentasikan kesepakatan formal antara Unit Pengelola Teknologi
lnformasi dengan Pelanggan/Pengguna untuk menghasilkan suatu pemahaman
bersama tentang layanan, prioritas, dan tanggung jawab.
3.20 QMS (Quality Management System) adalah suatu sistem yang mengelola kebijakan
dan prosedur yang diperlukan untuk memperbaiki dan mengontrol proses-proses untuk
meningkatkan performansi bisnis.
3.21 Risiko adalah segala kejadian dalam setiap aktivitas Perusahaan yang timbul karena
faktor eksternal maupun internal, yang mengandung potensi menghambat pencapaian
tujuan Perusahaan atau mengoptimalkan peluang bisnis.
3.22 Keamanan Teknologi Informasi adalah proteksi perlindungan informasi dari ancaman-
ancaman yang relevan untuk memastikan keberlangsungan bisnis, dan meminimalkan
risiko bisnis.
3.23 Segregation of duties (SOD) adalah pemisahan tanggung jawab personil untuk
memastikan tidak terjadinya conflict of interest.
3.24 Service Desk adalah titik kontak terpusat (central point of contact) antara Unit Pengelola
TI dengan Pelanggan/ Pengguna / Pengguna pada kegiatan operasional harian.
3.25 Unit Internal Audit adalah unit struktural Perusahaan yang ditunjuk untuk melakukan
audit internal termasuk diantaranya audit yang terkait dengan pengelolaan Teknologi
Informasi.
3.26 Configuration Management Database (CMDB) adalah database yang berisi aset-aset
TI pada tahapan operasional dan menjadi obyek pengelolaan dan monitoring.
Halaman 4 dari 17
4.0 REFERENSI
4.1 COBIT 4.1
4.1.1 DS1 Define and Manage Service Levels
4.1.2 DS2 Manage Third-party Services
4.1.3 DS3 Manage Performance and Capacity
4.1.4 DS4 Ensure Continuous Service
4.1.5 DS5 Ensure Systems Security
4.1.6 DS6 Identify and Allocate Cost
4.1.7 DS7 Educate and Train Users
4.1.8 DS8 Manage Service Desk and Incidents
4.1.9 DS9 Manage the Configurations
4.1.10 DS10 Manage Problems
4.1.11 DS11 Manage Data
4.1.12 DS12 Manage the Physical Environment
4.1.13 DS13 Manage Operations
4.2 ISO 20000-1
4.2.1 Part 1 Service Management System Requirements
4.2.2 Part 2 Guidance on the application of service management system
4.3 ISO 27001
5.0 KETENTUAN UMUM

5.1 Manajemen Tingkat Layanan TI
5.1.1 Lingkup seluruh layanan yang diselenggarakan pada tahapan operasi
dituangkan dalam Katalog Layanan.
5.1.2 Setiap layanan dalam katalog layanan harus dilengkapi kriteria layanan,
termasuk layanan-layanan pendukungnya; dikelola dalam proses manajemen
tingkat layanan.
5.1.3 Manajemen Katalog Layanan
5.1.3.1 Layanan yang diselenggarakan pada lingkungan operasional secara
rutin diinventarisir. Jika terdapat layanan yang belum dimasukkan dalam
katalog layanan, maka akan dimasukkan ke dalam katalog layanan.
5.1.3.2 Inventarisir layanan tersebut dilakukan minimal setiap 3 bulan.
5.1.4 Manajemen Tingkat Layanan
5.1.4.1 Setiap layanan harus dilengkapi dengan metrik SLA, yaitu ukuran kinerja
yang dijanjikan atas sebuah layanan yang disediakan oleh Penyedia
Layanan kepada Konsumen/Pengguna Layanan.
5.1.4.2 Jika sebuah SLA kepada Konsumen/Pengguna memiliki dependensi
dengan layanan atau sumberdaya pendukung lain, maka layanan atau
sumberdaya pendukung tersebut harus dilengkapi dengan OLA
(Operational Level Agreement). Nilai SLA merupakan fungsi dari OLA
layanan atau sumberdaya pendukungnya.
5.1.4.3 Konten SLA atau OLA terdiri tapi tidak terbatas pada aspek-aspek
berikut:
Halaman 5 dari 17
a. Nama layanan
b. Deskripsi outcome
c. Mekanisme komunikasi antara penyedia layanan dan konsumen
layanan
d. Rentang waktu pemberian layanan
e. Target tingkat layanan, misalkan availability, capacity/performance,
continuity atau waktu penyelesaian layanan
f. Tipe dan tingkat dukungan
g. Tanggung jawab, baik pada sisi penyedia layanan,
pelanggan/pengguna layanan
h. Panduan penggunaan layanan
5.1.4.4 Setiap layanan harus dimonitor realisasi pencapaian SLA atau OLA-nya,
dan digunakan untuk perbaikan berkelanjutan.
5.1.4.5 Evaluasi pencapaian tingkat layanan dilakukan minimal per semester,
untuk digunakan sebagai perbaikan pada siklus berikutnya.
5.2 Manajemen Pihak Ketiga
5.2.1 Proses pemilihan Pihak Ketiga merujuk kepada prosedur pengadaan yang sudah
ada sebelumnya di WIKA.
5.2.2 Dalam konteks manajemen layanan, Pihak Ketiga akan menyediakan layanan
kepada WIKA. Karena itu, layanan oleh Pihak Ketiga harus mengikuti ketentuan
Manajemen Tingkat Layanan, yang dituangkan dalam persyaratan SLA.
5.2.3 Khusus untuk layanan Pihak Ketiga yang bersifat kritikal terhadap operasional TI
dan pembayaran jasanya dilakukan secara reguler, maka dipersyaratkan
keberadaan restitusi. Restitusi adalah pembayaran kembali atas durasi layanan
yang tidak sesuai dengan target SLA yang telah disepakati di kontrak.
5.2.4 Manager Sistem Informasi dapat mengusulkan keikutsertaan klausul restitusi
pada kontrak dengan pihak ketiga, sebagai input kepada unit kerja yang
bertanggungjawab dalam pengelolaan kontrak dengan Pihak Ketiga.
5.2.5 SLA layanan Pihak Ketiga selalu dimonitoring dan dievaluasi reguler
ketercapaiannya. Jika tidak mencapai target SLA, maka Pihak Ketiga harus
memperbaiki layanannya, sekaligus membayarkan restitusi (jika ada dalam
klausul kontrak).
5.3 Manajemen Kapasitas
5.3.1 Setiap layanan yang akan diselenggarakan harus memiliki persyaratan teknis
yang akan dapat digunakan sebagai input untuk mengidentifikasi kebutuhan
kapasitas infrastruktur. Misalnya adalah jumlah pengguna, rata-rata pengguna
yang mengakses dalam satu waktu, pengguna yang mengakses pada saat peak
time, karakteristik penggunaan sumberdaya oleh layanan (bandwidth, besar
data, dan sejenisnya).
5.3.2 Lingkup sumberdaya yang harus dikelola kapasitasnya minimal adalah sebagai
berikut:
5.3.2.1 Perangkat keras (baik server, storage atau perangkat keras jaringan):
processor, memory, disk, I/O
5.3.2.2 Link jaringan komunikasi: utilisasi total, utilisasi per network-service
Halaman 6 dari 17
5.3.2.3 Fasilitas: catudaya listrik, sistem pendinginan (HVAC = Heating,

ventilation, and air conditioning)
5.3.3 Perencanaan Kapasitas (beserta evaluasinya) minimal dilakukan sekali dalam
satu tahun dengan memperhatikan input berikut:
5.3.3.1 Penambahan pengguna atau perubahan karakteristik teknis pada
layanan eksisting
5.3.3.2 Penambahan layanan baru
5.3.3.3 Statistik dan log penggunaan kapasitas sebelumnya
5.3.3.4 Cadangan kapasitas untuk kepentingan antisipasi risiko kebutuhan
tambahan di tengah tahun berjalan
5.3.4 Monitoring atas penggunaan kapasitas dilakukan menggunakan tool aplikasi,
yang mampu mencatat penggunaan kapasitas secara otomatis dan menyimpan
log statistik terkait dengannya.
5.3.5 Evaluasi atas hasil monitoring dilakukan minimal tiap semester, untuk
mendapatkan data faktual apakah kapasitas terpasang masih memadai. Hasil
kegiatan evaluasi dituangkan dalam Laporan Monitoring dan Evaluasi Kapasitas.
5.4 Manajemen Ketersediaan
5.4.1 Setiap layanan yang akan diselenggarakan harus memiliki persyaratan teknis
yang akan dapat digunakan sebagai input untuk mengidentifikasi kebutuhan
ketersediaan layanan, mencakup tetapi tidak terbatas pada:
5.4.1.1 Service Availability, yaitu persentase antara waktu layanan dikurangi
oleh downtime dengan total waktu layanan yang telah disepakati.
5.4.1.2 Service Maintainability, yaitu waktu rata-rata downtime untuk setiap
gangguan pada layanan (total durasi downtime dibagi dengan jumlah
kejadian gangguan pada layanan). Kriteria ini khusus diberikan untuk
layanan-layanan yang bersifat kritikal berdasarkan pertimbangan
profesional Manager Sistem Informasi.
5.4.2 Obyek ketersediaan adalah ketersediaan layanan dan sumberdaya
pendukungnya. Yang dimaksud dengan sumberdaya pendukungnya adalah:
5.4.2.1 Server dan storage
5.4.2.2 Perangkat jaringan komunikasi
5.4.2.3 Link komunikasi
5.4.2.4 Fasilitas di Data Center, khususnya catudaya listrik dan sistem HVAC
5.4.3 Penyusunan rencanan ketersediaan (availability planning) atas dilakukan
minimal sekali dalam setahun dengan memperhatikan input:
5.4.3.1 Karakteristik layanan dalam katalog layanan
5.4.3.2 Rencana layanan baru yang akan diselenggarakan
5.4.4 Monitoring atas ketersediaan dilakukan menggunakan tool aplikasi, yang mampu
mencatat penggunaan ketersediaan secara otomatis dan menyimpan log
statistik terkait dengannya.
5.4.5 Evaluasi atas hasil monitoring dilakukan minimal tiap semester, untuk
mendapatkan data faktual apakah ketersediaan masih memadai. Hasil kegiatan
evaluasi dituangkan dalam Laporan Monitoring dan Evaluasi Ketersediaan.
Halaman 7 dari 17
5.5 Manajemen Keberlangsungan Layanan

5.5.1 Layanan-layanan dalam katalog layanan harus didukung oleh rencana
keberlangsungan layanan
5.5.2 Rencana keberlangsungan layanan (yang dituangkan dalam IT Disaster
Recovery Plan) minimal mencakup hal-hal berikut ini:
5.5.2.1 Hasil Risk Assessment
a. Daftar kejadian yang berisiko mengganggu keberlangsungan
layanan
b. Kontrol yang dapat diimplementasikan untuk tiap risiko yang berhasil
diidentifikasi, sehingga mengurangi potensi risiko keberlangsungan
layanan.
5.5.2.2 Hasil Business Impact Analysis, yang berisi:
a. Persyaratan RTO (Recovery Time Objective) per layanan dan per
sumberdaya TI
b. Persyaratan RPO (Recovery Point Objective) per layanan dan per
sumberdaya TI
c. Klasifikasi kritikalitas layanan berdasarkan rentang RTO dan RPO.
Misalkan adalah HOT, WARM, COLD.
5.5.2.3 Struktur organisasi yang akan mengelola dan mengeksekusi jika terjadi
bencana. Peran minimal yang harus ada adalah:
a. Koordinator IT DRP
b. Tim Recovery & Resumption Sistem Informasi
c. Tim Recovery & Resumption Infrastruktur
d. Tim Dukungan Teknis Pengguna, yang akan bertanggungjawab atas
informasi dan dukungan teknis atas layanan kepada pengguna
dalam kondisi bencana.
5.5.2.4 Prosedur terkait keberlangsungan layanan, yang mencakup:
a. Prosedur identifikasi bahwa sebuah insiden adalah bersifat disaster
dan harus mengaktifkan IT DRP
b. Prosedur backup data
c. Prosedur recovery sistem informasi
d. Prosedur recovery infrastruktur
e. Prosedur resumption
5.5.2.5 Rencana Training
5.5.2.6 Rencana Testing
5.5.3 Training atas IT DRP dilakukan kepada staff-staff terkait sehingga mampu
menganalisa persoalan dan melakukan kegiatan yang tepat saat kejadian
bencana.
5.5.4 Pengujian atas IT DRP dilakukan minimal satu kali dalam satu tahun. Evaluasi
atas hasil pengujian dilakukan untuk peningkatan kapasitas SDM atau
penyesuaian IT DRP.
Halaman 8 dari 17
5.6 Manajemen Keamanan TI

5.6.1 Departemen Sistem Informasi setiap tahun menyusun Security Plan yang akan
menjadi panduan dalam pengelolaan keamanan informasi di tahun anggaran
terkait. Security Plan minimal mencakup hal berikut:
5.6.1.1 Identifikasi risiko-risiko terkait dengan keamanan informasi
5.6.1.2 Analisa umum kondisi keamanan informasi saat itu
5.6.1.3 Security Risk Treatment Plan yang berisi kegiatan-kegiatan yang akan
dilakukan untuk pengelolaan risiko keamanan informasi.
5.6.2 Kegiatan Vulnerability Assessment dan Penetration Testing (VA-Pentest)
dilakukan minimal sekali setiap tahun
5.6.2.1 Obyek VA-Pentest pada tahun terkait disesuaikan dengan justifikasi
layanan yang memiliki profil risiko yang harus diprioritaskan.
5.6.2.2 Kegiatan VA-Pentest dapat dilakukan secara internal dengan
pemenuhan syarat independensi.
5.6.2.3 Minimal setiap dua tahun sekali dilakukan VA-Pentest oleh Pihak Ketiga
yang independen.
5.6.2.4 VA-Pentest oleh Pihak Ketiga independen harus disupervisi oleh fungsi
terkait di Departemen Sistem Informasi
5.6.3 Pengelolaan akun dan hak akses logical
5.6.3.1 Pengguna hanya dapat mengakses atau menggunakan sumberdaya
atau fasilitas TI perusahaan jika memiliki Akun Akses. Setiap pegawai
hanya diperbolehkan memiliki satu Akun Akses, merujuk kepada ID
Kepegawaian yang ada.
5.6.3.2 Akun Akses dikelola pada sistem terpusat dan digunakan sebagai
referensi untuk melakukan otentikasi pada layanan email, akses
internet, akses berbagai sistem informasi atau sumberdaya TI lain.
5.6.3.3 Pengelolaan akun akses untuk internal
a. Permintaan hak akses (atau perubahannya) hanya dapat dilakukan
oleh Kepala Divisi dimana staff berada.
b. Pemetaan Akun Akses ke sistem informasi yang relevan dilakukan
pada level administrasi sistem informasi terkait.
c. Setiap perubahan posisi staff (misalkan: mutasi, promosi atau
pemberhentian) yang akan berdampak terhadap akses ke sistem
informasi atau sumberdaya TI terkait lainnya, harus disampaikan
oleh Kepala Divisi terkait kepada Departemen Sistem Informasi.
Pemberitahuan ini akan digunakan untuk penyesuaian Hak Akses.
d. Penggunaan Hak Akses akan selalu dimonitoring. Jika terdapat
pelanggaran, maka akan dieskalasikan ke Kepala Divisi terkait untuk
diproses sesuai dengan ketentuan yang berlaku di perusahaan.
5.6.3.4 Pengelolaan akun akses Pihak Ketiga
a. Permintaan hak akses untuk Pihak Ketiga hanya dapat dilakukan
oleh Kepala Divisi yang relevan.
b. Hak akses untuk Pihak Ketiga dibatasi hanya untuk kegiatan yang
relevan dengan lingkup pekerjaan dalam kontrak.
Halaman 9 dari 17
c. Penggunaan hak akses oleh Pihak Ketiga diawasi dan dicatat secara
otomatis oleh sistem.
d. Jika terdapat pelanggaran Hak Akses, Akun Pihak Ketiga akan
dinonaktifkan dan dilakukan eskalasi kepada Departemen terkait.
Tahapan selanjutnya akan merujuk kepada aturan hubungan
dengan pihak ketiga yang ada di perusahaan.
e. Hak Akses Pihak Ketiga akan otomatis berakhir sesuai dengan
tanggal perikatan dalam kontrak.
5.6.3.5 Penghapusan Akun akses
Akun akses akan secara otomatis berubah sesuai dengan
pengelompokan peran pada aplikasi Single Sign On (SSO) berdasatkan
data yang diperoleh dari data kepegawaian (Human Capital).
5.6.4 Manajemen Antimalware
5.6.4.1 Kontrol Antimalware diimplementasikan pada jaringan dan host
(khususnya desktop/laptop).
5.6.4.2 Update Antimalware pada desktop/laptop dilakukan secara terpusat
menggunakan Antimalware Server.
5.6.4.3 Departemen Sistem Informasi dapat menunda Hak Akses staff yang
antimalware di desktop/laptop-nya tidak terupdate.
5.6.5 Pengelolaan akun dan hak akses fisikal
5.6.5.1 Hak Akses fisik atas fasilitas Data Center/Disaster Recovery Center
hanya diberikan kepada staff internal yang bertanggungjawab langsung
dengan operasional Data Center/Disaster Recovery Center.
5.6.5.2 Pemberian Hak Akses Fisikal kepada Pihak Ketiga
a. Persetujuan hanya dapat diberikan oleh Manager Sistem Informasi,
dengan rekomendasi dari fungsi terkait, setelah sebelumnya
melengkapi data personil yang akan masuk ke fasilitas Data
Center/Disaster Recovery Center.
b. Kunjungan Pihak Ketiga ke lokasi Data Center/Disaster Recovery
Center harus disupervisi langsung oleh minimal satu staff internal
perusahaan.
5.6.5.3 Kontrol fisik atas fasilitas Data Center/Disaster Recovery Center
menggunakan Two-Factor Authentication dan dilengkapi dengan kontrol
CCTV surveillance.
5.7 Manajemen Insiden dan Permintaan Layanan
5.7.1 Manajemen Insiden
5.7.1.1 Pelaporan dan pencatatan insiden dilakukan menggunakan prinsip satu
pintu yaitu oleh Service Desk di Fungsi Service Management di
Departemen Sistem Informasi.
5.7.1.2 Penanganan insiden dibagi menjadi dua tipe:
a. Insiden yang dapat diselesaikan langsung di Service Desk
berdasarkan pengetahuan atau database insiden-solusi yang telah
ada sebelumnya.
Halaman 10 dari 17
b. Insiden yang harus dieskalasi ke Fungsi IT Infrastructure atau

Solution Development. Tipe kedua ini adalah insiden yang tidak
dapat diselesaikan pada tahapan pertama.
5.7.1.3 Minimal setiap bulan dilakukan pengolahan data statistik atas insiden-
insiden yang masuk dan diselesaikan. Fokus pada pengolahan data ini
adalah statistik kelompok insiden dan identifikasi insiden-insiden yang
berulang. Laporan bulanan pengelolaan insiden ini akan digunakan
sebagai input dalam manajemen permasalahan.
5.7.2 Permintaan Layanan
5.7.2.1 Yang dimaksud dengan permintaan layanan di sini adalah permintaan
yang memerlukan perubahan kecil dan risiko rendah, sering terjadi dan
tidak dibutuhkan biaya.
5.7.2.2 Lingkup permintaan layanan ini mencakup tapi tidak terbatas pada hal-
hal berikut:
a. Permintaan informasi
b. Permintaan perubahan password
c. Permintaan instalasi software spefisik di laptop atau desktop
d. Permintaan peripheral atau perbaikan atasnya
5.7.2.3 Permintaan atas instalasi software pada laptop atau desktop harus
mengacu kepada katalog software aplikasi legal yang dimiliki
perusahaan.
5.7.2.4 Permintaan spesifik yang belum pernah ada sebelumnya harus
dieskalasi ke General Manajer Sistem Informasi untuk diputuskan
pemenuhannya
5.8 Manajemen Permasalahan
5.8.1 Yang dimaksud dengan Permasalahan (Problem) adalah sebab yang mendasari
sebuah seri insiden. Jika insiden terjadi berulang-ulang, berarti ada
permasalahan yang menjadi sebab atas terjadinya insiden-insiden tersebut.
5.8.2 Minimal sebulan sekali dilakukan Problem Management Meeting, yaitu forum
untuk membahas permasalahan yang terjadi berdasarkan Laporan Manajemen
Insiden di bulan tersebut.
5.8.3 Peserta Problem Management Meeting adalah perwakilan masing-masing fungsi
dan dikoordinasi oleh Fungsi Service Management.
5.9 Manajemen Konfigurasi
5.9.1 Layanan yang diselenggarakan direpresentasikan dalam model layanan yang
terdiri dari CI (Configuration Item) beserta dependensinya, dan dikelola dalam
CMDB (Configuration Management Database).
5.9.2 Seluruh CI pada layanan yang operasional di lingkungan produksi harus tercatat
dalam CMDB.
5.9.3 Akurasi CMDB dievaluasi minimal satu bulan sekali. Jika terdapat CI yang masih
belum tercatat dalam CMBD, maka akan dicatatkan pada tahap selanjutnya.
5.9.4 Audit atau Verifikasi secara menyeluruh dilakukan minimal sekali per tahun untuk
memastikan ketepatan CMDB.
5.10 Manajemen Data
5.10.1 Backup Data
Halaman 11 dari 17
5.10.1.1 Backup Data dilakukan sesuai dengan persyaratan RPO layanan

5.10.1.2 Mekanisme Backup Data yang dimplementasikan adalah backup Disk-
to-Disk, yang dapat menggunakan solusi terotomatisasi pada level
database atau storage.
5.10.1.3 Mempertimbangkan tingkat kritikalitas layanan, berikut ini adalah
kriteria backup yang dilakukan:
a. Backup Data terkait layanan yang bersifat HOT minimal adalah tiap
1 jam
b. Backup Data terkait layanan yang bersifat WARM minimal adalah
tiap 6 jam
c. Backup Data terkait layanan yang bersifat HOT minimal adalah tiap
24 jam
5.10.1.4 Minimal setiap bulan sekali dilakukan evaluasi bahwa data hasil
backup memungkinkan untuk di-recovery jika dibutuhkan.
5.10.2 Disposal Data
5.10.2.1 Retensi data yang digunakan sebagai dasar kegiatan disposal merujuk
kepada ketentuan yang ada di perusahaan atau di regulasi.
5.10.2.2 Disposal hanya dilakukan pada data yang telah melewati masa
retensi.
5.10.2.3 Data yang sudah mengalami tahapan Disposal harus dipastikan tidak
dapat di-recovery kembali.
5.11 Manajemen Pemeliharaan
5.11.1 Pemeliharaan Software Aplikasi
5.11.1.1 Pemeliharaan software aplikasi mencakup tetapi tidak terbatas pada
kegiatan berikut:
a. Bug fixing atas aplikasi
b. Patching atas software aplikasi
c. Monitoring kinerja aplikasi, analisa dan resolusinya
5.11.1.2 Jika terdapat perubahan konfigurasi atas software aplikasi, maka
perubahan dan implementasinya mengikuti prosedur manajemen
perubahan.
5.11.1.3 Jika aplikasi dikembangkan oleh pihak ketiga, kontrak pekerjaan
dengan pihak ketiga harus memuat lingkup pemeliharaan aplikasi
minimal setahun setelah serah terima software aplikasi.
5.11.2 Pemeliharaan Infrastruktur
5.11.2.1 Pemeliharaan infrastruktur mencakup tetapi tidak terbatas pada
kegiatan berikut:
a. Patching firmware
b. Monitoring kinerja, analisa dan resolusinya
c. Pemberian dukungan teknis atas permasalahan yang terjadi,
termasuk penggantian infrastruktur jika dibutuhkan.
5.11.2.2 Jika terdapat perubahan konfigurasi atas infrastruktur, maka
perubahan dan implementasinya mengikuti prosedur manajemen
perubahan.
Halaman 12 dari 17
5.11.2.3 Jika infrastruktur disediakan oleh pihak ketiga, kontrak pekerjaan

dengan pihak ketiga harus memuat lingkup pemeliharaan minimal
setahun setelah serah terima infrastruktur.
5.12 Monitoring dan Evaluasi Rekaman
5.12.1 Rekaman/Bukti Kerja dibuat oleh masing-masing fungsi, sesuai dengan tugas
masing-masing
5.12.2 Identifikasi Rekaman
5.12.2.1 Petugas Pengendalian Rekaman di masing – masing fungsi
bertanggung jawab dalam hal identifikasi rekaman yang dilaksanakan
dalam kurun waktu maksimal 1 minggu.
5.12.2.2 Petugas Pengendalian Rekaman di masing – masing fungsi perlu
memperhatikan ketentuan-ketentuan identifikasi rekaman. Adapun
ketentuan identifikasi rekaman adalah sebagai berikut:
a. Jenis rekaman dalam Sistem Manajemen Keamanan Informasi
bermacam-macam sesuai dengan proses yang terkait dengannya,
misalnya:
1) Insiden keamanan
2) Perubahan
3) Item konfigurasi
4) Log kejadian keamanan
b. Untuk rekaman yang bersifat lintas proses, misalnya: risalah rapat.
Untuk memudahkan identifikasi, tool yang dipergunakan dalam
suatu proses dapat menerbitkan penomoran yang bersifat unik,
sebagai contoh: INC000001 untuk insiden keamanan; CHG000001
untuk perubahan.
c. Sedangkan untuk rekaman yang dibuat secara manual, aturan yang
diberlakukan adalah:
1) Rekaman yang berupa Risalah Rapat diberi nama sesuai dengan
agenda dan tanggal pelaksanaan rapat.
2) Rekaman yang berupa Laporan diberi nama sesuai dengan jenis
laporan dan periode pelaporannya.
3) Rekaman yang berupa Log diberi nama sesuai dengan judul log
dan tanggal/waktu periode log tersebut.
d. Apabila ada jenis-jenis rekaman yang lain, penamaannya dilakukan
sedemikian hingga nama yang diberikan memudahkan proses
identifikasi rekaman tersebut.
5.12.3 Penyimpanan Rekaman

5.12.3.1 Petugas Pengendalian Rekaman di masing–masing fungsi perlu
memperhatikan ketentuan ketentuan penyimpanan rekaman. Adapun
ketentuan penyimpanan rekaman adalah sebagai berikut:
a. Seluruh rekaman disimpan di lokasi yang sesuai dengan jenis dan
tujuan pembuatan rekaman. Sebagian rekaman dalam Sistem
Halaman 13 dari 17
Manajemen Keamanan Informasi disimpan dalam database yang

dibuat khusus, misalnya: database insiden keamanan.
b. Rekaman yang tidak berupa database disimpan sesuai dengan area
yang relevan dalam Sistem Manajemen Keamanan Informasi.
c. Jika memungkinkan, seluruh rekaman disimpan dalam format
elektronik. Rekaman dalam bentuk kertas sebaiknya dipindai dan
disimpan di lokasi yang sesuai.
d. Petugas Pengendalian Rekaman di masing – masing fungsi
bertanggung jawab dalam menentukan periode penyimpanan
rekaman dalam Sistem Manajemen Keamanan Informasi sesuai
dengan penilaian tingkat manfaat.
e. Petugas Pengendalian Rekaman di masing – masing fungsi
bertanggung jawab dalam hal penyimpanan rekaman yang
dilakukan dalam kurun waktu sesuai masa simpan.
5.12.4 Perlindungan Rekaman

memperhatikan ketentuan ketentuan perlindungan rekaman. Adapun
ketentuan perlindungan rekaman adalah sebagai berikut:
a. Rekaman yang disimpan dalam database aplikasi harus di-backup
sesuai dengan Prosedur Keberlanjutan Layanan TI. Lokasi
penyimpanan file juga di-backup secara reguler. Keseluruhan
backup yang terakhir dilakukan disimpan di lokasi offsite.
b. Akses terhadap rekaman dibatasi hanya untuk individu yang
memiliki hak akses dan dilakukan dengan mengikuti Kebijakan
Keamanan Informasi organisasi.
5.12.5 Pengambilan Rekaman

memperhatikan ketentuan ketentuan pengambilan rekaman. Adapun
ketentuan pengambilan rekaman adalah sebagai berikut:
a. Rekaman dalam bentuk file elektronik diambil menggunakan aplikasi
yang digunakan untuk membuatnya, misalnya: sistem help desk
untuk insiden, permasalahan, dll.
b. Tool pelaporan sebaiknya digunakan untuk memproses dan
mengonsolidasikan data-data dalam rekaman menjadi informasi
yang bermanfaat.
5.12.6 Pemusnahan Rekaman

5.12.6.1 Petugas Pengendalian Rekaman di masing – masing fungsi
bertanggung jawab dalam hal pemusnahan Rekaman yang dilakukan
dalam kurun waktu maksimal 1 minggu. Pemusnahan rekaman
berdasarkan persetujuan unit kerja yang terkait atau telah melewati
masa simpan.
Halaman 14 dari 17

memperhatikan ketentuan ketentuan pemusnahan rekaman. Adapun
ketentuan pemusnahan rekaman adalaha sebagai berikut:
a. Apabila rekaman diputuskan untuk dihapus, maka rekaman tersebut
harus dihapus dengan mengikuti prosedur disposal yang berlaku di
organisasi.
b. Rekaman dalam format elektronik (misalnya: database) dihapus
dengan menggunakan software yang sesuai misalnya help desk
biasanya memiliki fungsi dan fitur untuk menghapus rekaman
insiden.
c. Jika rekaman tersebut disimpan pada perangkat yang juga akan
dibuang, maka perangkat tersebut harus dihancurkan oleh vendor
yang ditetapkan.
d. Rekaman berbentuk kertas yang akan dibuang harus dihancurkan
sesuai dengan kebijakan keamanan informasi Pusdatin.
6.0 PROSEDUR DAN URUTAN KERJA

Tata Laksana dan Urutan Kerja dijelaskan pada Lampiran.
7.0 PENGECUALIAN
Perubahan dan penyimpangan atas ketentuan dan tata laksana prosedur ini harus mendapat
persetujuan dari Direksi atau Pejabat yang ditunjuk.
8.0 REKAMAN.
8.1 Semua rekaman dan dokumen dalam Tata Laksana dan Urutan Kerja dilakukan untuk
setiap tahapan relevan dalam flowchart yang mendukung SOP ini.
8.2 Rekaman dalam perangkat bantu software merupakan rekaman yang dapat diterima
sebagai bukti keberjalanan prosedur ini.
9.0 LAMPIRAN
9.1 Manajemen Tingkat Layanan
9.1.1 Flowchart Manajemen Tingkat Layanan
9.1.2 Katalog Layanan
9.1.3 Perjanjian Tingkat Layanan TI
9.1.4 Laporan Layanan
9.1.5 Operational Level Agreement
9.1.6 User Satisfaction survey
9.2 Manajemen Pihak Ketiga TI
9.2.1 Flowchart Manajemen Pihak Ketiga TI
9.2.2 Permohonan Penyediaan Penyedia Jasa TI
9.2.3 Laporan Monitoring Kinerja Pihak Penyedia Jasa
9.2.4 Memo Kompensasi
Halaman 15 dari 17
9.3 Manajemen Kapasitas

9.3.1 Flowchart Manajemen Kapasitas
9.3.2 Perencanaan Kapasitas TI
9.3.3 Laporan Monitoring Kapasitas Hardware
9.4 Manajemen Ketersediaan
9.4.1 Flowchart Manajemen Ketersediaan
9.4.2 Form Perencanaan Availability
9.4.3 Laporan Monitoring Availability layanan TI
9.5 Manajemen Keberlangsungan Layanan
9.5.1 Flowchart Penyusunan Continuity Plan
9.5.2 Flowchart Pengujian Continuity Plan
9.5.3 Flowchart Eksekusi Continuity Plan
9.5.4 Disaster Recovery Plan
9.5.5 Rencana Pengujian DRP
9.5.6 Service Continuity Test Report
9.6 Manajemen Keamanan
9.6.1 Flowchart Penyusunan Security Plan
9.6.2 Flowchart Vulnerability Management
9.6.3 Flowchart Manajemen Akun dan Akses
9.6.4 Flowchart Manajemen Malware
9.6.5 Flowchart Akses Fisik ke DC/DRC
9.6.6 Form Vulnerability Assesment
9.6.7 Pengajuan Perubahan UAM
9.6.8 Laporan Review Log Akses Logis
9.6.9 form Permohonan Akses ke Data Center – Internal
9.6.10 form Permohonan Akses ke Data Center – Eksternal
9.6.11 Log Book DC
9.6.12 form Laporan Review Log Akses Data Center
9.7 Manajemen Insiden dan Permintaan
9.7.1 Flowchart Manajemen Permintaan Layanan
9.7.2 Flowchart Request Fulfillment
9.7.3 Laporan Penanganan Insiden & Permintaan Layanan
9.8 Manajemen Permasalahan
9.8.1 Flowchart Manajemen Permasalahan
9.8.2 Laporan Penanganan Masalah
Halaman 16 dari 17
9.9 Manajemen Konfigurasi

9.9.1 Flowchart Manajemen Konfigurasi
9.9.2 Data Inventaris Aset
9.9.3 Laporan Konfigurasi
9.10 Manajemen Data
9.10.1 Flowchart Manajemen Backup Data
9.10.2 Flowchart Displosal Data
9.10.3 Flowchart Pengendalian Rekaman
9.10.4 Checklist Backup Data
9.10.5 Berita Acara Backup
9.10.6 form Disposal Data
9.10.7 Pengendalian Rekaman
9.11 Manajemen Pemeliharaan
9.11.1 Flowchart Manajemen Pemeliharaan Aplikasi
9.11.2 Flowchart Manajemen Pemeliharaan Infrastruktur
Halaman 17 dari 17
Lampiran 9.1.1
3.1.2. Manajemen Tingkat Layanan
Pelaksana
No. Uraian Kegiatan GM Sistem Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning & Input Output
Informasi Management Infrastructure Development Compliance
Lampiran 9.1.2
Mulai Katalog Layanan Daftar layanan yang
Identifikasi layanan dalam Katalog Lampiran 9.1.3 belum memiliki SLA
1 Perjanjian Tingkat
Layanan yang belum memiliki SLA
Layanan TI
Lampiran 9.1.2 Lampiran 9.1.2

Katalog Layanan : Katalog Layanan :
Penetapan (atau Update dalam kasus Daftar layanan yang SLA tiap layanan
2 sudah ada) SLA bersama dengan belum memiliki SLA
perwakilan pengguna layanan Lampiran 9.1.3
Perjanjian Tingkat
Layanan
Penetapan OLA untuk pendukung Katalog Layanan : Operational Level
layanan berdasarkan informasi SLA tiap layanan Agreement (OLA)
dependensi di Katalog Layanan untuk sumberdaya
3 pendukung SLA
Identifikasi apakah semua layanan sudah
Belum
ditetapkan SLA-nya? Jika belum, maka
diulang sampai semua layanan memiliki
SLA. Sudah
Log keberjalanan
4 Monitoring keberjalanan layanan layanan
Lampiran 9.1.2 Laporan evaluasi

Evaluasi rutin atas ketercapain SLA dan Katalog Layanan : rutin ketercapaian
5 Log keberjalanan SLA dan OLA
OLA penyusunnya Y
layanan
Laporan evaluasi Evaluasi kebutuhan
rutin ketercapaian penyesuaian SLA
Evaluasi apakah dibutuhkan SLA dan OLA
6 penyesuaian SLA untuk layanan dan
terkait?
T
Dokumentasi
Perbaikan kualitas layanan sesuai perbaikan layanan
dengan lingkup tanggungjawab masing-
7 masing fungsi, termasuk berkoordinasi
dengan pihak ketiga jika layanan
bekerjasama dengan pihak ketiga.
Semua output di 1. Lampiran 9.1.6

tahap sebelumnya User Satisfaction
Survey
2. Lampiran 9.1.4
Review per semester keberjalanan Selesai Laporan layanan
8
manajemen tingkat layanan
Lampiran 9.1.2
KATALOG LAYANAN
PT WIJAYA KARYA (PERSERO)
Version: 1.0
Draft 1
Document Author:
Document Owner:
TI PT.WIJAYA KARYA (Persero)
Lampiran 9.1.2
Riwayat Dokumen
Versi Tanggal Nomor RFC Ringkasan Perubahan
Peninjauan Dokumen
Jadwal Peninjauan Berikutnya
Distribusi
Nama Jabatan
Persetujuan
Nama Jabatan Tanda Tangan Tanggal
2
Lampiran 9.1.2
Daftar Isi
1 PENDAHULUAN 4
1.1 LATAR BELAKANG 4
1.2 TUJUAN 4
1.3 BATASAN 4
2 MODEL LAYANAN TI 4
2.1 MODEL LAYANAN TI 4
2.2 KATEGORISASI LAYANAN 5
2.3 KERANGKA PROFIL LAYANAN 6
3 DRAFT KATALOG LAYANAN 8

3.1 LAYANAN FINANANCIAL MANAGEMENT 8
3.1.1 GENERAL LEDGER 8
3.1.2 ACCOUNT RECEIVABLE AND PAYABLE 9
3.1.3 ASSET ACCOUNTING 12
3.1.4 BANK ACCOUNTING 14
3.1.5 TRAVEL MANAGEMENT 15
3.1.6 FUND MANAGEMENT 16
3.2 LAYANAN FINANCIAL CONTROL 17
3.2.1 COST ELEMENT ACCOUNTING 17
3.2.2 COST CENTER ACCOUNTING 19
3.2.3 ACTIVITY BASED ACCOUNTING 20
3.2.4 INTERNAL ORDER 22
3.2.5 PRODUCT COST CONTROLLING 23
3.2.6 PROFITABILITY ANALYSIS 25
3.2.7 PROFIT CENTER ACCOUNTING 26
3
Lampiran 9.1.2
1 Pendahuluan
1.1 Latar Belakang
PT.Wijaya Karya (Persero) Tbk telah mengimplementasikan TI pada sebagian
besar layanan organisasinya. Pada [tahun] PT Wijaya Karya (Persero) Tbk
telah mengagendakan untuk meningkatkan kematangan atau kapabilitas TI ke
depan, salah satunya terkait dengan manajemen layanan TI.
Sehingga dokumen ini dimaksudkan sebagai sarana komunikasi antara
[Penyedia Layanan] dan Stakeholders PT.Wijaya Karya (Persero) Tbk. Dalam
dokumen ini dijelaskan kategori dan deskripsi dari layanan TI yang ada pada
PT.Wijaya Karya (Persero) Tbk
Dokumen ini mencakup periode [bulan …] sampai dengan [bulan ….] tahun ….
1.2 Tujuan
1. Memberikan informasi kepada semua pihak pengguna layanan TI tentang
Katalog Layanan (Service Catalogue) TI yang diberikan oleh Bidang
Teknologi Informasi Perusahaan.
2. Memberikan panduan bagi pengguna mengenai tata cara pemanfaatan
layanan TI yang difasilitasi oleh Bidang Teknologi Informasi Perusahaan.
1.3 Batasan
Pedoman ini berlaku bagi semua operasional layanan Teknologi Informasi (TI) di
Perusahaan, dengan kriteria:
1. Pengguna TI lebih dari satu unit kerja, dan/atau
2. Penggunaan TI berdampak langsung kepada pelanggan.
2 Model Layanan TI
2.1 Model Layanan TI
Dalam konteks Service Management System, layanan TI merupakan bagian dari
layanan bisnis. Terdapat pemetaan antara layanan TI ke layanan bisnis, juga
pemetaan layanan TI ke sistem-sistem TI pendukung. Daftar layanan TI yang
diselenggarakan tersebut dikelola dalam Katalog Layanan.
Untuk penyusunan Katalog Layanan TI WIJAYA KARYA (PERSERO) TBK,

digunakan model konseptual sebagai berikut:
4
Lampiran 9.1.2
sumber: Mark O’Loughlin, The Service Catalog – A Practitioner Guide.

2.2 Kategorisasi Layanan
Berdasarkan model logical atas Katalog Layanan TI, dapat disusun kategorisasi
layanan sebagai berikut:
KATEGORI LAYANAN PENYUSUN

LAYANAN
Layanan Financial
1. General Ledger
Management
2. Account Receivable and Payable
3. Asset Accounting
4. Bank Accounting
5. Travel Management
6. Fund Management
Layanan Financial 1.
Control
5
Lampiran 9.1.2
2.3 Kerangka Profil Layanan

Untuk setiap profil layanan dalam katalog layanan, diperlukan dokumentasi profil
layanan yang seragam. Diusulkan untuk menggunakan kerangka proil sebagai
berikut.
ITEM PENJELASAN
Deskripsi Layanan
Memberikan informasi singkat tentang profil layanan.
Deskripsi singkat ini harus mudah dipahami oleh
pengguna, sesuai dengan kelaziman yang berlaku di
organisasi.
Fitur Memberikan informasi tentang fitur-fitur yang disediakan
oleh layanan terkait. Yang dimaksud dengan fitur
termasuk fungsionalitas atau kapabilitas yang disediakan
oleh layanan. Hal ini dapat merujuk kepada spesifikasi
fungsional pada sistem informasi, infrastruktur atau
proses layanan yang dijalankan.
Business Process
Unit kerja yang berperan sebagai Pemilik Proses Bisnis
Owner
atas layanan yang diselenggarakan. Item ini kritikal terkait
dengan pendefinisian pertama kali layanan atau
perubahannya.
Pengguna
Unit kerja atau pengguna yang mendapatkan layanan
Layanan yang diselenggarakan.
Jam Layanan
Durasi pemberian layanan. Misalnya adalah 24 jam 7 hari
dalam seminggu, atau 08.00 sd 17.00 pada hari kerja, dan
sejenisnya.
Tingkat Layanan
Merupakan metrik kualitas atas layanan yang diberikan.
Beberapa alternatif yang dapat digunakan, tapi harus
dipilih sesuai dengan konteks layanan adalah sbb:
a. Availability (ketersediaan) yaitu rasio ketersediaan
layanan dibandingkan dengan total waktu layanan,
dituangkan dalam satuan persentase.
b. RTO (Recovery Time Objective) yaitu waktu yang
dibutuhkan untuk melakukan recovery atas layanan TI
setelah terjadi bencana atas layanan yang
mengganggu keberlangsungan layanan.
c. RPO (Recovery Point Objective) yaitu durasi waktu
dimana data masih ditolelir untuk hilang, berlakuk ke
belakang sejak terjadinya status bencana.
d. Waktu minimal Service Desk memberikan tanggapan
terkait masalah yang ada pada layanan.
6
Lampiran 9.1.2
ITEM PENJELASAN
Sistem TI Terkait
Sistem-sistem TI yang secara langsung mendukung
keberjalanan layanan. Misalnya adalah sistem informasi
atau infrastruktur terkait.
Dukungan dan
Dokumentasi yang digunakan untuk sebagai dasar untuk
Dokumentasi pemberian layanan. Dokumentasi tersebut diperlukan oleh
pengguna jika memerlukan informasi lebih detail terkait
dengan layanan yang diselenggarakan, diantaranya
adalah:
a. SOP bisnis terkait
b. Manual sistem informasi
c. Tambahan informasi lain yang sekiranya dapat
meningkatkan pemahaman pengguna atas layanan
yang akan dikonsumsi
Proses untuk
Tahapan kegiatan yang harus dilakukan oleh pengguna
mendapatkan
agar mendapatkan layanan untuk pertama kali. Hal ini
layanan
penting agar pengguna segera mendapatkan layanan
yang terkait dengan profil otorisasinya dalam organisasi.
Tanggung jawab
Hal-hal yang harus diperhatikan oleh pengguna ketika
pengguna menggunakan layanan, misalnya terkait dengan:
a. Kebijakan organisasi terkait
b. Kebijakan TI terkait khususnya adalah terkait dengan
keamanan informasi
7
Lampiran 9.1.2
3 Draft Katalog Layanan

3.1 Layanan Finanancial Management
3.1.1 General Ledger

Deskripsi Layanan
Fungsi dari layanan General Ledger adalah memberikan
gambaran komprehensif tentang external accounting and
accounts.
Mencatat semua transaksi bisnis dalam sistem perangkat
lunak yang terintegrasi penuh dengan semua area
operasional perusahaan serta memastikan bahwa data
akuntansi selalu lengkap dan akurat.
Fitur
- Management reporting
- Extensibility
- Balanced books
- Parallel accounting
- Fast close
- Total cost of ownership reduction
- Transparency
- Compliance
- Legal entity reporting
- Segment reporting
Business Process
- General Ledger Officer/Staff
Owner
Pengguna
- Corporate Management
Layanan
- Plant Manager
- Sales Manager
- Cost Accountant
- Central Controller
- Accountant
Jam Layanan
24 x 7 (24 jam dalam satu hari dan 7 hari dalam satu
minggu)
Tingkat Layanan Berikut ini adalah metrik tingkat layanan relevan yang
dapat dipertimbangkan dan ke depan perlu ditetapkan:
- Availability:
Lampiran 9.1.2
- RTO:
- RPO:
- Response Time:
Sistem TI Terkait
- Asset Accounting (FI-AA)
- FI Accounts Receivable and Accounts Payable
- Controlling (CO)
- Materials Management (MM)
- Human Capital Management (HCM)
- Treasury and Risk Management (TRM)
- Travel Management (FI-TV)
- Public Sector Management - Funds Management
Government (PSM-FM)
Dukungan dan
Beberapa dokumentasi yang potensial akan membantu
Dokumentasi
pengguna adalah:
1. Manual Aplikasi
Proses untuk
Pelaksanaan permintaan layanan dilakukan oleh user
mendapatkan kepada unit helpdesk TI berdasarkan memo yang
layanan disepakati dan selanjutnya akan dieskalasikan kepada
unit TI terkait
Tanggung jawab
Penggunaan layanan oleh user mengacu terhadap
pengguna
Kebijakan dan SOP terkait aspek spesifik akan
direkomendasikan pada kajian berikutnya. Beberapa
aspek berikut ini direkomendasikan untuk lebih
ditekankan:
- Risiko atas keamanan informasi
- Aturan-aturan internal PT Wijaya Karya (Persero) Tbk
lainnya
3.1.2 Account Receivable and Payable

Deskripsi Layanan
Fungsi dari layanan Accounts receivable and Payable
adalah mengelola keseluruhan aktifitas akunting yang
berhubungan dengan customer dan vendor
Fitur - Master Data
- Credit Management
Lampiran 9.1.2
- Invoice Processing
- Cash Receipting / Payments
- Account Analysis / Reconciliation
- Periodic Processing
- Reporting
Business Process
Account Receivable and Payable Officer/Staff
Owner
Pengguna - Account Receivable and Payable Officer/Staff
Layanan
- Kustomer
- Vendor
Jam Layanan
minggu)
Tingkat Layanan
Berikut ini adalah metrik tingkat layanan relevan yang
- Availability:
- RTO:
- RPO:
- Response Time:
Sistem TI Terkait
-
Dukungan dan
Dokumentasi pengguna adalah:
- Manual Aplikasi
Proses untuk
mendapatkan
kepada unit helpdesk TI berdasarkan memo yang
layanan
disepakati dan selanjutnya akan dieskalasikan kepada
unit TI terkait
Tanggung jawab
pengguna
ditekankan:
lainnya
Lampiran 9.1.2
3.1.3 Asset Accounting

Deskripsi Layanan
Fungsi dari layanan Asset Accounting adalah mengelola
dan mengawasi aset tetap. Layanan ini berfungsi sebagai
buku besar yang mendukung fungsi General Ledger serta
memberikan informasi terperinci mengenai transaksi yang
melibatkan aset tetap
Fitur
- Traditional asset accounting
- Processing leased assets
- Preparation for consolidation
- Information System
- Response Time
Business Process
General Ledger Officer/Staff
Owner
Pengguna
General Ledger Officer/Staff
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability:
- RTO:
- RPO:
- Response Time:
Sistem TI Terkait
SAP:
1. Materials Management
2. General Ledger
3. Consolidation
4. Profit Center
5. Cost Center
6. Equipment
7. Investment Measure
8. Purchasing
9. Production
Lampiran 9.1.2
Dukungan dan Beberapa dokumentasi yang potensial akan membantu

Manual Aplikasi
Proses untuk
mendapatkan
layanan
unit TI terkait
Tanggung jawab
pengguna Kebijakan dan SOP terkait aspek spesifik akan
ditekankan:
lainnya
Lampiran 9.1.2
3.1.4 Bank Accounting

Deskripsi Layanan
Fungsi dari layanan Bank Accounting adalah adalah
mengelola setiap transaksi yang memiliki hubungan
dengan perbankan, termasuk cash management
Fitur
- Bank master data
- Cash balance management
- Creation and processing of incoming and outgoing
payments
Business Process
Owner
Pengguna
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability
- RTO
- RPO
- Response Time
Sistem TI Terkait
Dukungan dan
Dokumentasi
pengguna adalah:
Manual Aplikasi
Proses untuk
layanan
unit TI terkait
Tanggung jawab
ditekankan:
Lampiran 9.1.2

lainnya
3.1.5 Travel Management

Deskripsi Layanan
Fungsi dari layanan Travel Management adalah
mengelola setiap kegiatan perjalanan termasuk
pemesanan dan penjadwalan perjalanan serta mengelola
setiap pengeluaran dan pemasukan yang terkait dengan
perjalanan.
Fitur
- Travel Requests
- Travel Planning
- Travel Expenses
- Payment Reimbursement
Business Process
Owner
Pengguna
Seluruh Pegawai PT Wijaya Karya (Persero) Tbk
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability:
- RTO:
- RPO:
- Response Time:
Sistem TI Terkait
SAP:
Payroll
Dukungan dan
Manual Aplikasi
Proses untuk
mendapatkan
layanan
Lampiran 9.1.2

unit TI terkait
Tanggung jawab
pengguna
ditekankan:
lainnya
3.1.6 Fund Management

Deskripsi Layanan
Fungsi dari layanan fund Management adalah mengelola
pendapatan dan pengeluaran untuk masing-masing
tanggung jawab, serta mengendalikan transaksi kedepan
sesuai dengan anggaran yang disalurkan, dan untuk
mengontrol pengeluaran diluar anggaran yang telah
ditentukan.
Fitur
- Pengelolaan Anggaran
Business Process
Owner
Pengguna
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability:
- RTO:
- RPO:
- Response Time:
Sistem TI Terkait
-
Dukungan dan
Dokumentasi
pengguna adalah:
Manual Aplikasi
Lampiran 9.1.2
Proses untuk Pelaksanaan permintaan layanan dilakukan oleh user

unit TI terkait
Tanggung jawab
pengguna
ditekankan:
lainnya
3.2 Layanan Financial Control
3.2.1 Cost Element Accounting

Deskripsi Layanan
Fungsi dari layanan Cost Element Accounting adalah
melacak dan menyusun biaya dalam suatu periode
tertentu
Fitur
Business Process
Owner
Pengguna Seluruh Pegawai PT Wijaya Karya (Persero) Tbk
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability:
- RTO:
- RPO:
- Incident Response Time:
Sistem TI Terkait
SAP:
Material Management
Sales and Distribution
General Ledger
Lampiran 9.1.2
Dukungan dan
Dokumentasi
pengguna adalah:
Manual Aplikasi
Proses untuk
unit TI terkait
Tanggung jawab
pengguna
ditekankan:
lainnya
Lampiran 9.1.2
3.2.2 Cost Center Accounting

Deskripsi Layanan
Fungsi dari layanan Cost Center Accounting adalah
mengelola setiap kegiatan perjalanan termasuk
pemesanan dan penjadwalan perjalanan serta mengelola
setiap pengeluaran dan pemasukan yang terkait dengan
perjalanan.
Fitur
- Cost center
- Profit centers
- Investment centers
Business Process
Owner
Pengguna
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability
- RTO
- RPO
- Incident Response Time
Sistem TI Terkait
SAP:
Material Management
General Ledger
Dukungan dan
Dokumentasi
pengguna adalah:
Manual Aplikasi
Proses untuk
mendapatkan
layanan
unit TI terkait
Tanggung jawab
pengguna
Lampiran 9.1.2

ditekankan:
lainnya
3.2.3 Activity Based Accounting

Deskripsi Layanan
Fitur
Business Process
Owner
Pengguna
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability:
- RTO:
- RPO:
- Response Time:
Sistem TI Terkait
SAP:
Material Management
General Ledger
Dukungan dan
Dokumentasi
pengguna adalah:
Manual Aplikasi
Proses untuk
mendapatkan
layanan
unit TI terkait
Tanggung jawab Penggunaan layanan oleh user mengacu terhadap
Lampiran 9.1.2

ditekankan:
lainnya
Lampiran 9.1.2
3.2.4 Internal Order

Deskripsi Layanan
Fungsi dari layanan Internal Order adalah untuk
merencanakan, mengumpulkan, dan menetapkan biaya
pekerjaan dan tugas internal mulai dari proses awal
hingga penyelesaian akhir dan pengarsipan
Fitur Master Data
Job Cost Estimation
Internal Orders Budget Management
Business Process
Owner
Pengguna
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability:
- RTO:
- RPO:
- Response Time:
Sistem TI Terkait
Dukungan dan
Dokumentasi
pengguna adalah:
Manual Aplikasi
Proses untuk
unit TI terkait
Tanggung jawab
pengguna
ditekankan:
lainnya
Lampiran 9.1.2
3.2.5 Product Cost Controlling

Deskripsi Layanan
Fungsi dari layanan Product Cost Controlling adalah
mengevaluasi data yang dihasilkan di masing-masing
komponen. Serta menyediakan laporan untuk tujuan
analisis.
Fitur Reporting:
-Product Cost Planning
-Cost Object Controlling with subcomponents:
Product Cost by Period
Product Cost by Order
Product Cost by Sales Order
-Costs for Intangible Goods and Services
-Actual Costing/Material Ledger
Business Process
Owner
Pengguna
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability:
- RTO:
- RPO:
- Response Time:
Sistem TI Terkait
SAP:
Product Cost Planning
Cost Object Controlling
Actual Costing/Material Ledger.
Dukungan dan
Manual Aplikasi
Proses untuk
mendapatkan
layanan
unit TI terkait
Lampiran 9.1.2

ditekankan:
lainnya
Lampiran 9.1.2
3.2.6 Profitability Analysis

Deskripsi Layanan
Fungsi dari layanan Profitability Analysis adalah segmen
pasar, yang dapat diklasifikasikan menurut produk,
pelanggan, demand, dan area bisnis.
Fitur Master Data
Business Process
Owner
Pengguna
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability:
- RTO:
- RPO:
- Response Time:
Sistem TI Terkait
SAP:
Profit Center Accounting (EC-PCA)
Dukungan dan
Dokumentasi
pengguna adalah:
Manual Aplikasi
Proses untuk
unit TI terkait
Tanggung jawab
ditekankan:
lainnya
Lampiran 9.1.2
3.2.7 Profit Center Accounting

Deskripsi Layanan
Fungsi dari layanan Travel Management adalah
mengelola keuntungan dan kerugian menggunakan
Periodic Accounting atau pendekatan biaya-penjualan.
Fitur Validation
Substitution
Archiving
Business Process
Owner
Pengguna
Layanan
Jam Layanan
minggu)
Tingkat Layanan
- Availability:
- RTO:
- RPO:
- Response Time:
Sistem TI Terkait
SAP:
Enterprise Controlling
General Ledger Accounting
Dukungan dan
Dokumentasi
pengguna adalah:
Manual Aplikasi
Proses untuk
unit TI terkait
ditekankan:
Lampiran 9.1.2

lainnya
Lampiran 9.1.3
Perjanjian Tingkat Layanan
Version: 1.0
Draft 1
Document Author:
Document Owner:
TI PT. Wijaya Karya (Persero) Tbk
Lampiran 9.1.3
Riwayat Dokumen
Peninjauan Dokumen
Distribusi
Nama Jabatan
Persetujuan

Lampiran 9.1.3
Daftar Isi
2 PIHAK-PIHAK DALAM PERJANJIAN ..................................................... 4
3 LAYANAN YANG TERCAKUP DALAM PERJANJIAN TINGKAT

LAYANAN INI .................................................................................................. 5
3.1 JAM LAYANAN .................................................................................................................. 6
3.2 JAM SERVICE DESK ....................................................................................................... 6
3.3 JAM DUKUNGAN ONSITE ............................................................................................... 6
4 DUKUNGAN LAYANAN .......................................................................... 7
4.1 INSIDEN ............................................................................................................................. 7
4.1.1 Prioritas Insiden dan Target Penyelesaian ..................................... 7
4.2 PERMINTAAN DAN PERUBAHAN LAYANAN ................................................................. 7
4.2.1 Permintaan Layanan ...................................................................... 7
4.2.2 Perubahan Yang Standar ............................................................... 8
4.2.3 Perubahan Yang Tidak Standar ..................................................... 8
4.3 KOMUNIKASI DENGAN PENGGUNA ............................................................................. 8
4.4 TANGGUNG JAWAB PELANGGAN ................................................................................. 8
5 TARGET TINGKAT LAYANAN ................................................................ 9
5.1 SERVICE DESK ................................................................................................................ 9
5.2 TARGET KETERSEDIAAN LAYANAN ........................................................................... 10
5.2.1 Dasar Perhitungan ....................................................................... 10
5.3 TARGET CONTINUITY ....................................... ERROR! BOOKMARK NOT DEFINED.
RTO .......................................................... Error! Bookmark not defined.
RPO .......................................................... Error! Bookmark not defined.
5.4 TARGET PERFORMANCE ................................. ERROR! BOOKMARK NOT DEFINED.
Response Time ......................................... Error! Bookmark not defined.
6 PENONAKTIFAN LAYANAN ................................................................. 10
6.1 PENONAKTIFAN LAYANAN SECARA TERENCANA ................................................... 10
6.2 PENONAKTIFAN LAYANAN SECARA TIDAK TERENCANA....................................... 10
7 KEBERLANJUTAN LAYANAN TI ....................................................... 11
8 PELAPORAN DAN PENINJAUAN LAYANAN ...................................... 11

8.1 PELAPORAN LAYANAN ................................................................................................. 11
8.2 PENINJAUAN LAYANAN ................................................................................................ 11
9 ALOKASI DAN PEMBEBANAN BIAYA ................................................ 12
10 THROUGHPUT ...................................................................................... 12
11 LAMPIRAN A : KONTAK [PENYEDIA LAYANAN] ............................... 13
12 LAMPIRAN B : DAFTAR PERMINTAAN LAYANAN ............................ 14
13 LAMPIRAN C: DAFTAR ISTILAH.......................................................... 15

Lampiran 9.1.3
1 Pihak-Pihak Dalam Perjanjian

Perjanjian ini dibuat antara [Penyedia Layanan TI] dari PT. Wijaya Karya
(Persero) Tbk
dan
 Nama; Jabatan; Tanda Tangan

untuk kemudian secara kolektif disebut sebagai Pelanggan.
Perjanjian ini mencakup penyediaan layanan TI oleh [Penyedia Layanan]

kepada Unit Bisnis dari PT. Wijaya Karya (Persero) Tbk. Perjanjian ini sah dan
berlaku sampai dengan dilakukan perbaikan secara bersama oleh para pihak.
Perjanjian ini ditinjau setiap 1 (satu) tahun. Perubahan minor yang disepakati
oleh kedua belah pihak akan dicatat pada bagian akhir perjanjian ini.
Penandatangan
Pihak Unit Bisnis PT. Wijaya

Karya (Persero) Tbk Pihak [Penyedia Layanan]
Nama………………………………… Nama…………………………………
……………. …………….
Jabatan……………………………… Jabatan………………………………
…………… ……………
Tanggal……………………………… Tanggal………………………………
…………… ……………
Lampiran 9.1.3
2 Layanan Yang Tercakup Dalam Perjanjian Tingkat Layanan Ini
Berikut ini adalah layanan TI yang tercakup dalam Perjanjian Tingkat Layanan
ini:
No Layanan TI
1 [diambil dari Katalog Layanan]
2 Layanan pelayanan administrasi
3 Layanan Employee Administration
Informasi rinci tentang masing-masing layanan didokumentasikan dalam

Katalog Layanan TI.
Fokus utama Perjanjian Tingkat Layanan ini adalah pada layanan produksi
yang menjadi penggerak bisnis organisasi. Namun demikian, layanan non-
produksi yang
terkait erat dengan produksi juga menjadi bagian dari Perjanjian Tingkat
Layanan ini, yakni:
 {contoh: Penjaminan Kualitas}
 {contoh: Pengembangan}
1. Layanan Employee Administration
Layanan non-produksi memiliki tingkat dukungan layanan yang lebih rendah
dibandingkan layanan produksi.
Tingkat layanan yang didefinisikan dalam Perjanjian Tingkat Layanan ini akan
diterapkan pada lokasi-lokasi sebagai berikut:
 {contoh: Kantor Pusat}
 {contoh: Seluruh Kantor Cabang}
Dukungan pada lokasi lain disepakati bersama antara Penyedia Layanan dan
Pelanggan sesuai dengan kebutuhan.
Lampiran 9.1.3
2.1 Jam Layanan

Seluruh layanan yang tercakup dalam Perjanjian Tingkat Layanan ini akan
tersedia pada jam layanan sebagai berikut:
 Jam 7 pagi sampai dengan jam 6 sore; selama 7 (tujuh) hari dalam sepekan,
termasuk hari libur perusahaan}.
2.2 Jam Service Desk

Jam layanan dari Service Desk adalah sebagai berikut:
 jam 8.30 pagi sampai dengan jam 5.30 sore; Hari Senin sampai dengan
Kamis
 jam 8.30 pagi sampai dengan jam 5.00 sore; Hari Jumat
2.3 Jam Dukungan Onsite

Dukungan onsite akan diberikan oleh [Penyedia Jasa] pada jam-jam berikut:
 jam 8.30 pagi sampai dengan jam 5.30 sore; Hari Senin sampai dengan
Kamis
 jam 8.30 pagi sampai dengan jam 5.00 sore: Hari Jumat
Dukungan onsite di luar waktu tersebut (misalnya untuk acara penting

perusahaan) diberikan oleh [Penyedia Layanan] dengan perhitungan layanan
sesuai dengan jumlah jam dukungan onsite yang disepakati.
Lampiran 9.1.3
3 Dukungan Layanan
[Penyedia Layanan] mengoperasikan fungsi Service Desk secara onsite dan
dapat dihubungi melalui telepon, email, aplikasi Service Desk, maupun
mekanisme lain yang disepakati. Seluruh insiden, permintaan layanan, dan
permintaan perubahan harus melalui Service Desk. Hal ini dimaksudkan untuk
memastikan akurasi rekaman dan pelaporan yang dipergunakan untuk
mengevaluasi pencapaian Perjanjian Tingkat Layanan.
3.1 Insiden
3.1.1 Prioritas Insiden dan Target Penyelesaian

Setelah menerima informasi mengenai insiden, Service Desk melakukan
penyusunan prioritas penanganannya:
Prioritas Definisi Target Respon Target Penyelesaian

[Diisi [Diisi dengan definisi [Diisi target [Diisi target penyelesaian
dengan dari insiden] respon insiden] insiden]
prioritas
insiden]
High Aplikasi tidak bisa Memberikan Akan dilakukan perbaikan
diakses oleh user penjelasan awal dengan target
terhadap user penyelesaian 30 Menit
serta menggali
detail insiden dari
user, serta
melakukan
analisa penyebab
terjadinya
insiden.
[Prioritas penanganan insiden ditentukan oleh Analis TI yang ada di Service

Desk berdasarkan prosedur yang berlaku.
Target respon adalah inisiasi awal dalam penanganan insiden, termasuk
penghimpunan informasi tambahan yang diperlukan.
Target Penyelesaian adalah titik waktu dimana pengguna dapat melanjutkan
pekerjaan atau layanan yang gagal atau terganggu.]
3.2 Permintaan dan Perubahan Layanan
3.2.1 Permintaan Layanan

Lampiran 9.1.3
Permintaan layanan berupa perubahan kecil dan berisiko rendah yang dapat
diimplementasikan dalam durasi waktu singkat. Tindak lanjut dari suatu
permintaan layanan disesuaikan dengan skala prioritasnya. Beberapa contoh
permintaan layanan ditunjukkan pada Lampiran B.
3.2.2 Perubahan Yang Standar
Perubahan yang standar dilakukan oleh [Penyedia Layanan] secara terencana,
baik kegiatan maupun pembiayaannya. Perubahan dilakukan sesuai dengan
ketersediaan sumber daya yang dimiliki oleh [Penyedia Layanan], termasuk
ketergantungan pada pihak ketiga.
3.2.3 Perubahan Yang Tidak Standar

Perubahan yang tidak standar berupa perubahan yang memiliki risiko, biaya,
dan kompleksitas relatif tinggi. Pengajuan perubahan yang tidak standar
disampaikan ke Service Desk menggunakan form Pengajuan Perubahan
(Request for Change/RFC).
3.3 Komunikasi Dengan Pengguna

Service Desk mengelola komunikasi yang efektif dengan pengguna sepanjang
siklus pengelolaan insiden, permintaan layanan, maupun perubahan.
Komunikasi dilakukan menggunakan media telepon, email, aplikasi service
desk, maupun mekanisme lain yang diatur dalam prosedur.
3.4 Tanggung Jawab Pelanggan

Hal-hal berikut menjadi tanggung jawab pelanggan untuk dilaksanakan dengan
baik:
 Memberikan informasi kepada Service Desk segera setelah terjadi

kesalahan atau gangguan atau potensi gangguan keamanan.
 Merekam setiap informasi yang kemungkinan diperlukan dalam proses
investigasi.
 Melaporkan insiden sesuai dengan langkah-langkah yang diatur dalam
prosedur.
 Melakukan komunikasi yang efektif dengan staf yang terkait langsung
dengan insiden.
 Jika diperlukan, mengajukan eskalasi sesuai prosedur yang berlaku.
 Mematuhi kebijakan dan prosedur yang terkait dengan penggunaan TI,
termasuk pemeliharaan dan pengamanan perangkat TI.
 Membantu pemeriksaan integritas system dan data pada saat proses
pemulihan layanan.
 Keluar dari jaringan atau system tertentu sesegera mungkin jika diminta
oleh [Penyedia Layanan]
Pelanggan yang melaporkan insiden harus melengkapi sekurang-kurangnya

data sebagai berikut:
 Nama Lengkap
 Unit Bisnis dan Jabatan
Lampiran 9.1.3
 Nomor Kontak
 Nomor Aset (jika ada)
 Deskripsi insiden, permintaan layanan, atau perubahan.
Dampak saat ini maupun potensi dampak yang akan terjadi (misalkan: jumlah
karyawan atau proses bisnis yang terkena dampak)
4 Target Tingkat Layanan
4.1 Service Desk

Dalam memberikan layanan TI, [Penyedia Layanan] memiliki target tingkat
layanan sebagai berikut:
Tingkat Layanan Deskripsi Target
Dari
Insiden dan Prosentase penyelesaian insiden dan X%
Permintaan permintaan layanan yang memenuhi target
Layanan respon.
Prosentase penyelesaian insiden dan X%
permintaan layanan yang memenuhi target
penyelesaian.
Prosentase insiden yang dapat X%
diselesaikan di Service Desk sebagai lini
pertama penaganan insiden.
Perubahan yang Prosentase perubahan yang standar yang X%
standar dapat diselesaikan sesuai dengan waktu
yang disepakati.
Kinerja pencapaian target tingkat layanan tersebut dipaparkan secara rinci
dalam laporan layanan TI setiap 3 (tiga) bulan.
Lampiran 9.1.3
4.2 Target Ketersediaan Layanan

Target ketersediaan layanan dalam Perjanjian Tingkat Layanan ini disepakati
dan ditetapkan sebagai berikut:
1. Ketersediaan: 96,6% dengan asumsi satu hari mati selama satu jam
2. Keamanan:
3. Keberlangsungan:
a. RTO
b. RPO
4. Target Performa
a. Response Time:
4.2.1 Dasar Perhitungan

 Ukuran ketersediaan layanan dihitung berdasarkan Jam Dukungan.
 Waktu yang diperlukan dalam Penonaktifan Layanan Secara Terencana
tidak dihitung sebagai kegagalan ketersediaan layanan.
 Suatu layanan dianggap tersedia jika dapat diakses dari Kantor Pusat.
5 Penonaktifan Layanan
5.1 Penonaktifan Layanan Secara Terencana

Penonaktifan layanan secara terencana merupakan Penonaktifan layanan
yang rentang waktunya direncanakan dan dikontrol secara penuh oleh
[Penyedia Layanan], misalnya: Penonaktifan layanan pada saat pemeliharaan
rutin.
[Penyedia Layanan] memberikan informasi terkait Penonaktifan layanan
secara terencana ini kepada pelanggan sekurang-kurangnya 2 (dua) minggu
sebelum Penonaktifan. [Penyedia Layanan] juga harus melakukan
pembicaraan dengan pelanggan terkait dampak Penonaktifan layanan
terhadap bisnis beserta langkah-langkah antisipasinya.
5.2 Penonaktifan Layanan Secara Tidak Terencana
Penonaktifan layanan secara tidak terencana memerlukan rentang waktu yang
tidak sepenuhnya dapat dikontrol oleh [Penyedia Layanan], misalnya:
pemulihan layanan pada saat terjadi bencana.
Dalam kondisi ini, [Penyedia Layanan] harus:
 Sebelum melakukan Penonaktifan layanan, [Penyedia Layanan]
melakukan komunikasi untuk memastikan bahwa pelanggan telah
memahami sebab Penonaktifan layanan.
 Melakukan pembicaraan dengan pelanggan mengenai waktu terbaik
Penonaktifan layanan untuk meminimalkan dampak yang mungkin terjadi.
 Memberikan informasi mengenai perkiraan waktu yang diperlukan untuk
mengembalikan layanan ke kondisi normal pasca Penonaktifan.
Dalam kondisi terjadi kegagalan layanan, [Penyedia Layanan] memastikan
bahwa pelanggan mendapatkan informasi mengenai kondisi tersebut beserta
perkiraan waktu pemulihan layanan.
Lampiran 9.1.3
6 Keberlanjutan Layanan TI
[Penyedia Layanan] melakukan analisis risiko serta menyusun dan memelihara
Rencana Keberlanjutan Layanan TI. Rencana tersebut ditinjau ulang bersama
dengan Pelanggan sekurang-kurangnya setiap 1 (satu) tahun sekali.
Rencana Keberlanjutan Layanan merinci prioritas layanan yang akan
dipulihkan pada saat terjadi bencana. Rencana tersebut juga merinci kontak
penyedia jasa/barang yang diperlukan untuk memulihkan layanan serta kontak
person di unit bisnis pelanggan yang akan diarahkan dalam pengujian dan
pemeriksaan integritas data pada saat pemulihan.
Rencana Keberlanjutan Layanan harus diuji oleh [Penyedia Layanan] setiap 1
(satu) tahun sekali. Hasil pengujian ditinjau secara menyeluruh untuk
memastikan bahwa seluruh isu yang terkait dengan keberlanjutan layanan
telah diidentifikasi dan ditangani. Pelanggan harus terlibat dalam pengujian
untuk memastikan kecukupan rencana keberlanjutan layanan.
[Penyedia Layanan] bertanggung jawab memastikan keseluruhan backup
dilakukan sesuai dengan prosedur agar Rencana Keberlanjutan Layanan dapat
dijalankan dengan baik.
7 Pelaporan dan Peninjauan Layanan
7.1 Pelaporan Layanan

[Penyedia Layanan] menyusun laporan layanan tiga bulanan yang sekurang-
kurangnya berisi:
 Analisis ketersediaan layanan pada periode tersebut.
 Rincian dari setiap gangguan besar pada system yang terjadi pada periode
tersebut. Dalam rincian itu dipaparkan analisis penyebab, tindakan
penanganan yang dilakukan untuk mengembalikan layanan ke kondisi
normal, dan upaya pencegahan agar gangguan tersebut tidak terulang.
 Data seluruh insiden yang tercatat oleh Service Desk pada periode tersebut,
termasuk pencapaian kinerja layanan terhadap target yang ditentukan.
 Rangkuman kegiatan peningkatan layanan yang dilakukan oleh [Penyedia
Layanan] pada periode tersebut.
 Rangkuman Rencana Peningkatan Layanan, termasuk capaian dari
rencana peningkatan pada periode sebelumnya.
7.2 Peninjauan Layanan
Rapat Peninjauan dan Evaluasi Layanan diselenggarakan setiap 3 (tiga) bulan.
Rapat dihadiri oleh:
 Pelanggan dari unit-unit bisnis
 [Manajer Layanan]
 Jika diperlukan, penyedia jasa dan/atau staf unit bisnis tertentu diundang
sesuai dengan agenda pembahasan.
Rapat diselenggarakan dengan agenda standar berupa peninjauan dan
evaluasi layanan. Bila ada agenda khusus yang akan dibahas dalam rapat,
diinformasikan terlebih dahulu kepada undangan rapat 1 (satu) minggu
sebelum pelaksanaan rapat.
Lampiran 9.1.3
8 Alokasi dan Pembebanan Biaya

Biaya TI dikelola oleh [Manajer Layanan] sesuai dengan kebijakan dan regulasi
keuangan PT. Wijaya Karya (Persero) Tbk.
[Pada bagian ini dapat ditambahkan data alokasi dan pembebanan biaya TI
Organisasi]
[Penyedia Layanan] secara berkala melakukan peninjauan atas metode
pengelolaan biaya TI untuk mengidentifikasi kemungkinan efisiensi biaya serta
peningkatan kualitas layanan TI di PT. Wijaya Karya (Persero) Tbk.
9 Throughput
Tingkat layanan dalam Perjanjian Tingkat Layanan ini didefinisikan dengan
mengacu pada tingkat throughput aktual dari tiap layanan yang dicakup.
Peningkatan signifikan pada tingkat throughput dapat berakibat pada
kemampuan [Penyedia Layanan] dalam memenuhi Perjanjian Tingkat
Layanan. Berikut ini adalah contoh nilai aktual yang menjadi acuan:
Pengukuran Jumlah
Jumlah pengguna jaringan
Jumlah komputer desktop
Jumlah laptop
Jumlah server
Lampiran 9.1.3
10 Lampiran A : Kontak [Penyedia Layanan]

Nama Jabatan Email Telepon
[Diisi dengan [Diisi dengan nama [Diisi dengan alamat [Diisi dengan
nama jabatan/role email penyedia nomor telepon
penyedia penyedia layanan layanan penyedia
layanan] layanan]
Lampiran 9.1.3
11 Lampiran B : Daftar Permintaan Layanan

No Deskripsi Target Penyelesaian
{RQST01} {Permintaan Pengguna Baru} {X hari}
{RQST02} {Permintaan Perubahan {X hari}
Pengguna}
{RQST03} {Permintaan Perangkat} {X hari}
Lampiran 9.1.3
12 Lampiran C: Daftar Istilah

Insiden
Setiap kejadian yang bukan merupakan bagian dari operasi standar layanan
yang menyebabkan interupsi, gangguan, atau penurunan kualitas layanan.
Permasalahan
Penyebab yang belum diketahui dari satu atau beberapa insiden.
Pelanggan
Representasi manajemen dari suatu kelompok pengguna.
Pengguna
Pengguna akhir dari perangkat TI
Permintaan Layanan
Perubahan kecil dan berisiko rendah yang dapat diimplementasikan dalam
durasi waktu singkat.
Perubahan Yang Tidak Standar

Perubahan yang tidak mudah untuk dimodelkan dan biasanya memiliki risiko,
biaya, dan kompleksitas yang tinggi.
TI
Teknologi Informasi
Target Respons
Upaya awal dalam penyelesaian suatu insiden, termasuk pengumpulan
informasi tambahan yang diperlukan.
Target Penyelesaian
Titik waktu dimana pengguna dapat melanjutkan pekerjaan atau layanan yang
gagal atau terganggu.
LAN
Local Area Network
WAN
Wide Area Network
Lampiran 9.1.4
Laporan Layanan
Bulan MMM s.d. Bulan MMM Tahun YYYY
Version: 1.0
Draft 1
Document Author:
Document Owner:
TI PT. Wijaya Karya (Persero) Tbk
Lampiran 9.1.4
Riwayat Dokumen
Peninjauan Dokumen
Distribusi
Nama Jabatan
Persetujuan

Lampiran 9.1.4
Daftar Isi
1 PENDAHULUAN ...................................................................................... 4
2 RANGKUMAN KINERJA TERHADAP TARGET TINGKAT LAYANAN . 5
3 KINERJA SERVICE DESK ...................................................................... 6
3.1 INSIDEN .......................................................................................................................... 6
3.1.1 Jumlah Insiden Yang Dilaporkan dan Diselesaikan Tiap Bulan . 6
3.1.2 Prosentase Insiden Yang Dapat Diselesaikan Dalam Perjanjian
Tingkat Layanan ....................................................................................... 7
3.1.3 Insiden Yang Dapat Diselesaikan Oleh Service Desk................. 8
3.1.4 Insiden Yang Tercatat Berdasarkan Prioritas ............................. 9
3.1.5 Insiden Yang Paling Sering Terjadi............................................. 9
3.2 PERMINTAAN LAYANAN ............................................................................................ 10
3.2.1 Jumlah Permintaan Layanan Yang Disampaikan dan Dipenuhi
Tiap Bulan ............................................................................................... 10
3.2.2 Permintaan Layanan Yang Dapat Dipenuhi Dalam Perjanjian
Tingkat Layanan ..................................................................................... 11
4 KETERSEDIAAN LAYANAN ................................................................. 12
4.1 LAYANAN EMAIL ......................................................................................................... 12
4.2 LAYANAN INTERNET .................................................................................................. 13
4.3 LAYANAN ABC .................................................................................... 14
4.4 PEMBERHENTIAN LAYANAN PADA PERIODE INI .................................................. 15
4.5 PEMBERHENTIAN LAYANAN YANG TIDAK TERENCANA PADA PERIODE INI . 15
4.6 RENCANA PEMBERHENTIAN LAYANAN PADA PERIODE MENDATANG ............ 15
5 PENINGKATAN LAYANAN TI ............................................................. 16
5.1 AKTIVITAS PENINGKATAN PADA PERIODE INI ..................................................... 16
5.2 PENINGKATAN LAYANAN YANG DIRENCANAKAN ................................................ 16
Lampiran 9.1.4
1 Pendahuluan
Dokumen ini dimaksudkan sebagai sarana komunikasi antara [Penyedia
Layanan] dan manajemen PT.Wijaya Karya (Persero) Tbk. Dalam dokumen ini
dilaporkan pencapaian kinerja terhadap Perjanjian Tingkat Layanan dan
informasi lain yang terkait dengan aktivitas [Penyedia Layanan].
Laporan ini mencakup periode [bulan …] sampai dengan [bulan ….] tahun ….
Lampiran 9.1.4
2 Rangkuman Kinerja Terhadap Target Tingkat Layanan

Rangkuman kinerja layanan aktual terhadap target yang ditetapkan dalam
Perjanjian Tingkat Layanan ditunjukkan pada tabel berikut ini:
Pencapaian
Tingkat Pada 3
Deskripsi Target
Layanan Bulan
Terakhir
Insiden Prosentase penyelesaian X% Y%
insiden yang sesuai dengan
target.
Permintaan Prosentase pemenuhan X% Y%
Layanan permintaan layanan yang
sesuai dengan target.
Prosentase insiden yang X% Y%
dapat ditangani oleh
Service Desk
Ketersediaan Ketersediaan layanan X% Y%

Layanan [Aplikasi A]
Ketersediaan layanan X% Y%
[Aplikasi B]
Ketersediaan Layanan X% Y%
[Internet]
Detail informasi kinerja terhadap target dipaparkan pada bagian lain dokumen
ini.
Lampiran 9.1.4
3 Kinerja Service Desk

Potret kinerja Service Desk adalah sebagai berikut:
3.1 Insiden
3.1.1 Jumlah Insiden Yang Dilaporkan dan Diselesaikan Tiap Bulan
Jumlah insiden yang dicatat oleh Service Desk selama periode pelaporan ini
lebih tinggi/lebih rendah/sama dengan perkiraan. Kondisi tersebut disebabkan
oleh:
 [analisis penyebab tinggi/rendahnya insiden, misalnya: bencana,
penambahan pengguna secara signifikan, dll]
Lampiran 9.1.4
3.1.2 Prosentase Insiden Yang Dapat Diselesaikan Dalam Perjanjian

Tingkat Layanan
Prosentase insiden yang berhasil diselesaikan sesuai dengan target dalam
Perjanjian Tingkat Layanan ditunjukkan pada bagan berikut:
Secara umum, kinerja terhadap target dalam Perjanjian Tingkat Layanan cukup
baik, kecuali pada bulan September dimana tingkat layanan kurang dari 90%.
Lampiran 9.1.4
3.1.3 Insiden Yang Dapat Diselesaikan Oleh Service Desk
Prosentase insiden yang dapat diselesaikan oleh Service Desk sebagai first
line ditunjukkan pada bagan berikut:
Target 80% penyelesaian insiden oleh Service Desk secara umum telah
tercapai, kecuali bulan Mei dan September.
Lampiran 9.1.4
3.1.4 Insiden Yang Tercatat Berdasarkan Prioritas

Berikut ini profil prioritas insiden yang terjadi pada periode ini:
3.1.5 Insiden Yang Paling Sering Terjadi

Insiden yang paling sering terjadi pada periode ini dirinci pada bagan berikut:
Lampiran 9.1.4
3.2 Permintaan Layanan
3.2.1 Jumlah Permintaan Layanan Yang Disampaikan dan Dipenuhi

Tiap Bulan
Jumlah permintaan layanan yang diajukan dan jumlah permintaan layanan
yang dapat dipenuhi ditunjukkan pada bagan berikut:
Pada bulan Desember terjadi penurunan yang cukup signifikan karena

beririsan dengan hari libur nasional.
Lampiran 9.1.4
3.2.2 Permintaan Layanan Yang Dapat Dipenuhi Dalam Perjanjian

Tingkat Layanan
Prosentase permintaan layanan yang dapat dipenuhi dalam Perjanjian Tingkat
Layanan ditunjukkan pada bagan berikut:
Lampiran 9.1.4
4 Ketersediaan Layanan
4.1 Layanan Email
Ketersediaan layanan email ditunjukkan pada bagan berikut ini:
Lampiran 9.1.4
4.2 Layanan Internet

Ketersediaan layanan internet ditunjukkan pada bagan berikut ini:
Lampiran 9.1.4
4.3 Layanan ABC

Ketersediaan layanan ABC ditunjukkan pada bagan berikut:
Lampiran 9.1.4
4.4 Pemberhentian Layanan Pada Periode Ini

Berikut adalah Pemberhentian layanan yang direncanakan pada periode ini:
Layanan
Tanggal Waktu Yang Durasi Alasan
Terdampak
Tanggal- Jam:menit Email 1 jam Perbaikan router
bulan- Internet
tahun
4.5 Pemberhentian Layanan Yang Tidak Terencana Pada Periode Ini

Berikut ada Pemberhentian layanan yang tidak terencana yang terjadi pada
periode ini:
Layanan
Terdampak
Tanggal- Jam:menit Email 2 jam Perubahan darurat atas
bulan- Layanan konfigurasi disk server
tahun ABC
4.6 Rencana Pemberhentian Layanan Pada Periode Mendatang

Berikut adalah Pemberhentian layanan yang direncanakan dilakukan pada
periode mendatang:
Layanan
Terdampak
Tanggal- Jam:menit Email 4 jam Upgrade versi perangkat
bulan- lunak
tahun
5
Lampiran 9.1.4
6 Peningkatan Layanan TI
6.1 Aktivitas Peningkatan Pada Periode Ini
Aktivitas peningkatan yang telah dilakukan pada periode ini adalah sebagai
berikut:
Keterangan
Layanan Peningkatan Manfaat
Tambahan
Internet Upgrade koneksi Kecepatan akses Hal ini merupakan
internet meningkat tindak lanjut dari
dari sebelumnya hasil survey
kepuasan pengguna
6.2 Peningkatan Layanan Yang Direncanakan

Aktivitas peningkatan yang akan dilakukan pada periode mendatang adalah
sebagai berikut:
Keterangan
Layanan Peningkatan Manfaat
Tambahan
Email Penambahan Pengguna dapat Hal ini merupakan
fungsionalitas mengakses permintaan
kalender secara manajemen pada
lebih mudah rapat bulan
November.
Lampiran 9.1.5
Operational Level Agreement Genset
PT. Wijaya Karya (Persero). tbk
Klasifikasi Keamanan: Rahasia
Kode Dokumen. ITSM061004

Lampiran 9.1.5
Riwayat Dokumen

0.1 14 01 Draft Awal
September
2018
0.2 1 Oktober 02 Perubahan Nama Sub Bidang
2018
Distribusi
Nama Jabatan
Persetujuan

Lampiran 9.1.5
Pihak-Pihak Dalam Perjanjian

Perjanjian ini dibuat antara Penyedia Layanan TI PT. WIKA dan Penyedia
Layanan Genset.
Perjanjian ini mencakup penyediaan layanan genset yang mendukung layanan

TI. Perjanjian ini sah dan berlaku sampai dengan dilakukan perbaikan secara
bersama oleh para pihak. Perjanjian ini ditinjau setiap 1 (satu) tahun.
Perubahan minor yang disepakati oleh kedua belah pihak akan dicatat pada
bagian akhir perjanjian ini.
Penandatangan
Pihak Penyedia Layanan Genset. PT. WIKA:
Nama……………………………………………….
Jabatan……………………………………………
Tanggal……………………………………………
Tanda Tangan……………………………………………
Pihak Pengelola TI PT. WIKA:
Nama…………………………………………….
Jabatan……………………………………………
Tanggal……………………………………………
Tanda Tangan………………………….......
Lampiran 9.1.5
Operational Level Agreement Genset

Nama Proses / Layanan Penyediaan Layanan Genset
Service Provider
Service User
Tanggal Mulai Berlaku 17 September 2018
Tanggal Habis Berlaku 1 Januari 2019
Periode Review 1 Bulan Sekali
Periode Evaluasi Minimal Satu Tahun Sekali
Lampiran 9.1.5
1. Deskripsi Umum Proses / Layanan

Perjanjian Tingkat Operasional Genset ini bertujuan untuk mendukung
keberlangsungan layanan TI secara keseluruhan, PT. WIKA (Persero). Apabila
layanan Genset terhenti dan tidak dapat memberikan layanannya, ada potensi
terjadinya gangguan keberlangsungan layanan TI, apabila terjadi gangguan pada
suplai listrik, karena tidak ada mekanisme backup yang normalnya disediakan oleh
Genset.
2. Lingkup Layanan
Layanan Genset memberikan jaminan akan ketersediaan layanan sebagai backup
dari suplai listrik yang mendukung layanan TI. Layanan Genset tidak mencakup
penyediaan layanan pada masa maintenance/perbaikan layanan.
Perjanjian Tingkat Operasional Genset mendukung terhadap Layanan yang
disediakan oleh Unit TI yaitu:
No Referensi Layanan Prosentase Target SLA
1.0 Layanan Akunting 94,15 %
2.1 Layanan Akunting

Layanan Komponen
Deskripsi Keterangan
Layanan
Documents Lenovo x3650 M5: - Domain
Management [8871AC1]- Controller
System Server
V3700_02_DS01 Storage
V3700_01_DS01 Storage
Switch Swicth
RO-Inside Router
RO-Inside 2 Router
PIX-4 Firewall
RO-GPINIX/Outside Router
RO-LT 4 Router
Lampiran 9.1.5
3. Waktu Pelayanan
Layanan Genset diberikan ketika terjadi gangguan aliran listrik, sebagai mitigasi suplai
listrik untuk mendukung operasional layanan TI
4. Tingkat Ketersediaan Layanan

Untuk mendukung operasional layanan TI, Layanan Genset memberikan layanan
dengan tingkat ketersediaan 95% yang dihitung per bulan dan response time
maksimal 45 menit setelah listrik mati.
4.1 Dasar Perhitungan
 Ukuran ketersediaan layanan dihitung berdasarkan durasi dukungan layanan
genset;
 Dukungan layanan genset dihitung sejak dukungan layanan UPS selesai;
 Dukungan layanan UPS selama 20 menit sejak listrik mati;
 Penonaktifan layanan secara terencana, tidak dihitung sebagai kegagalan
ketersediaan layanan genset.
5. Komitmen Penyajian Layanan

1. Sub Bidang Mesin, Listrik, Air dan Telekomunikasi menjamin bahwa solusi
untuk permasalahan Genset dapat dipertanggung jawabkan.
2. Sub Bidang Mesin, Listrik, Air dan Telekomunikasi menjamin bahwa proses
analisis solusi untuk permasalahan terkait genset sudah sesuai dengan kaidah
umum yang ada.
6. Formula Penghitungan OLA

Perhitungan nilai OLA adalah :
(Agreed Service Time – downtime) / Agreed Service Time × 100%
Dengan ketentuan :
 Agreed Service Time = tingkat layanan yang disediakan, ketika terjadi
gangguan aliran listrik, dikurangi Penonaktifan Layanan Secara Terencana,
misal: maintenance genset
 Downtime = durasi gangguan yang mengakibatkan tidak tersedianya layanan
genset
7. Mekanisme Pelaporan Performa

Laporan hasil perhitungan OLA dibuat oleh Bidang Penyedia Kelistrikan PT. WIKA
(Persero) dan akan dilaporkan setiap bulan pada awal bulan berikutnya dan
disampaikan kepada Unit TI.
8. Rekonsiliasi
Jika terjadi perselisihan dan perbedaan pendapat maka akan diselesaikan dengan
melakukan rapat bersama yang melibatkan penyedia dan pengguna layanan dibawah
koordinasi Pimpinan Unit TI.
Lampiran 9.1.5
9. Kebijakan dan Prosedur Terkait

No Nama Kebijakan/Prosedur Kategori
1
2
3
4
5
6
7
8
9
10
Lampiran 9.1.6
No. Rev. : : 01 Amd 01
User Satisfaction survey
Bagaimana kepuasan Anda terhadap:
1. Layanan TI secara keseluruhan yang diberikan saat ini?

Sangat Tidak Tidak Puas Puas Sangat Puas
Puas
2. Kemudahan dalam mendapatkan dukungan saat terjadi masalah TI?

Puas
3. Kecepatan penyelesaian masalah TI yang dihadapi?

Puas
4. Kualitas penyelesaian masalah dan dukungan yang diberikan oleh

penyedia layanan TI?
Puas
5. Pemahaman Anda akan jenis-jenis layanan yang diberikan oleh penyedia

layanan TI?
Puas
6. Ketersediaan layanan TI?

Puas
7. Sikap proaktif dari penyedia layanan TI?

Puas
8. Mekanisme komunikasi antara penyedia layanan TI dengan pengguna?

Puas
Catatan Lain Terkait Layanan TI:

…………………………………………………………………………………………………..
…………………………………………………………………………………………………..
…………………………………………………………………………………………………..
…………………………………………………………………………………………………..
…………………………………………………………………………………………………..
Lampiran 9.2.1
3.2.1. Manajemen Pihak Ketiga
Pelaksana
No. Uraian Kegiatan Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning Pengadaan dan Pihak Input Output
GM Sistem Informasi Pihak Ketiga
Management Infrastructure Development & Compliance terkait
Lampiran 9.2.2 Memo GM SI untuk

Mulai Permohonanan pengajuan draft TOR
Penyediaan Jasa TI : dan HPS
Pengajuan hasil studi kelayakan atas Draft TOR, HPS dari
1 solusi (draft TOR, HPS, dsj) untuk prosedur Studi
keperluan pengadaan Kelayakan atas Solusi
TI
Lampiran 9.2.2 BA Penetapan

Proses pengadaan (merujuk kepada
Prosedur Permohonanan Pemenang
prosedur pengadaan yang ada), sampai
2 Penyediaan Jasa TI :
dengan diperoleh pemenang proses Pengadaan
Draft TOR & HPS
pengadaan Memo GM SI
Penyusunan (atau revisi) draft kontrak Draft TOR Draft Kontrak
(oleh fungsi terkait sesuai dengan lingkup BA Penetapan
3 pekerjaan), terutama terkait lingkup Pemenang
pekerjaan dan tingkat mutu dan layanan
yang harus dipenuhi.
Draft Kontrak Memo Pengajuan
Draft Kontrak
Pengajuan draft kontrak kepada pihak
4
pengadaan untuk diselesaikan
Draft Kontrak Kontrak

Penetapan kontrak dengan pihak ketiga Memo Pengajuan
5 Draft Kontrak
atau adendum kontrak
Dokumentasi kickoff
6 Kickoff pekerjaan
Lampiran 9.2.3
Laporan Monitoring
Menyampaikan laporan rutin pencapaian Kinerja Pihak
7 pekerjaan beserta kriteria mutu dan Penyedia Jasa :
layanannya Laporan kemajuan
Jika terkait service management
proyek
Jika terkait IT Infrastructure Lampiran 9.2.3 Lampiran 9.2.3

Laporan Monitoring Laporan Monitoring
Kinerja Pihak Kinerja Pihak
Evaluasi ketercapaian kontrak kerja Jika terkait solution development Penyedia jasa : Penyedia Jasa :
8
(terkait fungsi service management) 1. Kontrak Evaluasi
2. Laporan Kemajuan ketercapaian kontrak
Proyek rutin

Jika terkait planning &
compliance
Evaluasi ketercapaian kontrak kerja Penyedia Jasa Penyedia Jasa :
9
(terkait fungsi IT Infrastructure) 1. Kontrak Evaluasi
Proyek rutin

10
(terkait fungsi IT Infrastructure) 1. Kontrak Evaluasi
Proyek rutin
11
(terkait fungsi planning & compliance) 1. Kontrak Evaluasi
Proyek rutin
Evaluasi apakah kontrak kerja tercapai?
Penyedia Jasa : Penyedia Jasa : Hasil
12 Y T Evaluasi ketercapaian perbaikan
Jika tidak tercapai maka pihak ketiga
kontrak rutin produk/jasa dari
harus melakukan perbaikan
pihak ketiga
Lampiran 9.2.3 Restitusi

Laporan Monitoring
Perhitungan restitusi atas Kinerja Pihak
ketidaktercapaian kriteria dalam kontrak Penyedia Jasa :
13
jika terdapat klausul tersebut dalam Evaluasi ketercapaian
kontrak kontrak rutin
Lampiran 9.2.4
Apakah diperlukan perubahan lingkup Y Memo Kompensasi
14 kontrak? Jika diperlukan, maka
diperlukan revisi kontrak.
T
Y
Apakah masa kontrak masih ada? Jika
masih ada maka akan dilakukan
15 T
monitoring terus menerus atas
pencapaian kontrak.
Selesai
Lampiran 9.2.2
Permohonan Penyediaan Penyedia Jasa TI

Informasi Pemohon
: Diisi nama pemohon yang mengajukan permohonan
Nama Lengkap penggunaan penyedia jasa TI
John Dhoe
: Diisi nama Tim atau SubDiv yang mengajukan permohonan
Tim/SubBag penggunaan penyedia jasa TI
Core Business Application
No. Telp. / Ext. : Jelas
Jasa TI yang Diisi penjelasan mengenai jasa TI yang dibutuhkan untuk dikelola
Dibutuhkan oleh Pihak Penyedia Jasa TI
Layanan pelayanan Infrastrukur
Nama Pihak Diisi dengan nama pihak Penyedia Jasa TI yang telah ditunjuk
Penyedia Jasa langsung dan penjelasan mengenai jasa yang ditawarkan oleh
TI (rekomendasi) Pihak Penyedia Jasa TI yang direkomendasikan
dan Jasa yang 1. PT ABC Menyediakan Jasa pemenuhan aplikasi front end
Ditawarkan pelayanan infrastruktur
2. PT CBA Telco Menyediakan Jasa Infrastruktur Pendukung
Layanan Pelayanan Infrastruktur
3. ......................................................................................................
Tujuan Diisi penjelasan mengenai tujuan penggunaan pihak penyedia jasa
Penggunaan TI
Pihak Penyedia Pemenuhan Layanan pelayanan infrastruktur
Jasa TI
Kriteria Penyedia 1. Pengalaman:
Jasa Memiliki Pengalaman Pekerjaan Sejenis Minimal 5 Kali
Dengan Nilai Kontrak Minimal Rp. Rp 35.000.000.000,00 pada
salah satu pengalaman pekerjaan antara Tahun 2011 s/d 2017
2. Personil:
Memiliki sertifikasi ....
3. Izin Usaha
Surat Izin Usaha Perdagangan (SIUP) - Non Kecil
Tanda Daftar Perusahaan (TDP) - Non Kecil
Dibuat Oleh: Disetujui Oleh:

Tanggal: Tanggal:
User Pemohon Manager User Pemohon
..................................... .....................................
Lampiran 9.2.3
Laporan Monitoring Kinerja Pihak Penyedia Jasa

Informasi Pihak Penyedia Jasa
Nama Perusahaan : Diisi dengan nama pihak penyedia jasa
Alamat Perusahaan : Diisi dengan alamat pihak penyedia jasa
Diisi dengan kegiatan yang dilaksanakan pihak

Jenis Kegiatan :
penyedia jasa
Diisi dengan lokasi kegiatan yang dilaksanakan
Lokasi Kegiatan :
pihak penyedia jasa
diisi dengan nomor dan tanggal Surat Perjanjian
Nomor dan Tanggal SPK :
Kerjasama pihak penyedia jasa
Jangka Waktu
: Diisi dengan jangka waktu pelaksanaan proyek
Pelaksanaan
Tanggal Mulai : Diisi dengan tanggal dimulainya proyek
Tanggal Selesai : Diisi dengan tanggal selesainya proyek
Sesuai
Obyek Monitoring Kinerja Pihak Penyedia Jasa
Ya Tidak
Kualitas Jasa (Quality)
Diisi penjelasan mengenai kualitas jasa yang diberikan oleh Pihak Penyedia Jasa
SLA
Diisi penjelasan mengenai kesesuaian dengan SLA yang telah ditentukan
Penyampaian Jasa (Delivery)
Diisi penjelasan prosentase ketepatan waktu pengiriman deliverable dari Pihak

Penyedia Jasa
Fleksibilitas Penyampaian Jasa (Flexibility)

Lampiran 9.2.3
Sesuai
Obyek Monitoring Kinerja Pihak Penyedia Jasa
Ya Tidak
Diisi penjelasan mengenai ketersediaan waktu penyampaian hasil pekerjaan dari
Pihak Penyedia Jasa
Respon Masalah terhadap Penyampaian Jasa
(Responsiveness)
Diisi penjelasan mengenai respon dari Pihak P enyedia Jasa untuk merespon
masalah yang terjadi di Perusahaan
evaluasi aspek keamanan informasi penyedia jasa
Diisi mengenai evaluasi aspek security penyedia jasa

Tanggal: Tanggal:
Fungsi IT Pimpinan Unit IT
………………………………… …………………………………
*) coret yang tidak perlu

Lampiran 9.2.4
MEMORANDUM
Tanggal : Diisi dengan tanggal saat ini

No. Perihal : Diisi dengan nomor perihal
Kepada : Diisi dengan kepada siapa memo itu
dituju
Dari : Diisi dengan pengirim memo
Lampiran : Diisi dengan berapa halaman lampiran
Perihal : Diisi dengan hal yang ingin
disampaikan
Dengan ini, kami menyatakan:

Nama : PT Wijaya Karya (Persero)
disebut sebagai PIHAK PERTAMA, dan
Nama : PT Pihak Penyedia Jasa
disebut sebagai PIHAK KEDUA.
Berdasarkan perjanjian kerjasama dengan no. …………….…….., dengan

PT ………………….. sebagai PIHAK KEDUA yang menyediakan jasa
….………………, dengan nilai kontrak sebesar Rp ........................................... Telah
melakukan kelalaian dalam memenuhi klausul dari pasal. ……………, dan butir
………… mengenai ……………….
Dengan ini kami PIHAK PERTAMA memberikan kompensasi kepada PIHAK

KEDUA untuk dapat menyelesaikan kewajibannya karena tidak memenuhi
beberapa klausul pada perjanjian kerjasama yang telah disepakati tersebut.
Mohon untuk diperhatikan memo kompensasi ini.
Dibuat oleh:
Fungsi IT
……………………………
Lampiran 9.3.1
3.3.1. Manajemen Kapasitas

Pelaksana
No. Uraian Kegiatan GM Sistem Fungsi Service Fungsi Solution Fungsi IT Planning & Input Output
Fungsi IT Infrastructure
Informasi Management Development Compliance
1. Lampiran Master Lampiran 9.3.2

Plan TI Perencanaan
Mulai 2. Lampiran Draff Kapasitas TI :
Inventarisasi layanan ke depan dan RKAP TI terkait Layanan ke depan
1 sistem informasi dan kapasitas saat
laporan monitoring kapasitas
3. Laporan ini serta trend terkait
monitoring dengannya
kapasitas
Lampiran 9.3.2 Keputusan tentang

Perencanaan perlu atau tidaknya
Analisa kebutuhan penambahan Kapasitas TI : mengupdate
kapasitas ke depan. 1. Analisa Demand rencana kapasitas
Cukup 2. Analisa sebelumnya
2
Jika kapasitas dinilai sudah tidak penggunaan
mencukupi, maka akan dilanjutkan kapasitas dalam
dengan tahapan perencanaan kapasitas TIdak satu siklus
Cukup monitoring
Draft Perencanaan
Penyusunan draft rencana kebutuhan Kapasitas
3 kapasitas untuk infrastruktur TI: fasilitas,
server, jaringan, platform
Draft Perencanaan Perencanaan

Kapasitas Kapasitas yang
telah disetujui
Review kecukupan, jika belum memadai
4 akan dilakukan perbaikan. Jika sudah
memadai, proses perencanaan selesai. T
Y
Lampiran 9.3.3
Laporan Monitoring
Monitoring penggunaan kapasitas Kapasitas
5
sumberdaya TI Hardware :
Log monitoring
kapasitas
Lampiran 9.3.3
Laporan monitoring
Penyusunan laporan rutin penggunaan
6 dan evaluasi
kapasitas sumberdaya TI.
kapasitas
Lampiran 9.3.2
Perencanaan Kapasitas TI
Perencanaan Kapasitas TI
Tujuan
Diisi dengan penjelasan mengenai tujuan dilakukannya perencanaan
kapasitas.
Definisi
Diisi dengan istilah-istilah asing yang digunakan dalam dokumen perencanaan
kapasitas TSI.
Ruang lingkup Perencanaan Kapasitas TI
Diisi dengan penjelasan mengenai batas waktu pelaksanaan dilakukannya
perencanaan kapasitas TSI.
Dasar Perencanaan Kapasitas TI
Diisi dengan penjelasan mengenai risiko-risiko yang akan terjadi, jika tidak
dilakukannya perencanaan kapasitas
Kapasitas Jaringan - Server

Tangg Diisi dengan tanggal melakukan monitoring kapasitas server
al
No. Nama IP Process Memor Used Free Treshol
Server Address or y d
1 Venus 10.105.1. 2 x Intel 4Gb 1.9G 2.1G 80%
45 Xeon b b
Quad
Core
E5506
2 Androme 10.105.1. 2 x Intel 2Gb 1.5G 0.5G 80%
da 87 Xeon b b
Quad
Core
E5506
3 Semafor 10.105.1. 1 x 256Mb 218M 38M 80%
99 Pentium b b
II-350
4 Athena 10.105.1. 2 x Intel 4Gb 2.5G 1.5G 80%
14 Xeon b b
Quad
Core
E5620
Lampiran 9.3.2
Kapasitas Jaringan - Storage

Tanggal Diisi dengan tanggal melakukan monitoring kapasitas storage
Usulan
Total Perkiraan Penambahan
Nama
No. Storage Aplikasi Storage Space
Storage
Saat Ini Habis Storage
free
Contoh Contoh Contoh Contoh Contoh
1 Venus 3X146Gb Email Januari 2013 Tidak perlu
Storage penambahan
2 Andromeda 3X146Gb Virtual September Perlu
server 2012 penambahan
3 Semafor 3X146Gb Web April 2013 Tidak perlu
Server penambahan
4 Athena 3X146Gb Network Mei 2012 Perlu
Tools penambahan
Kapasitas Perangkat Keras TI

Tanggal Diisi dengan tanggal melakukan monitoring kapasitas hardware
No. Hardware Tersedia Rusak Usulan Penambahan
1 Laptop 30 5 Perlu penambahan
2 HardDisk 5 2 Perlu penambahan
3 Router 3 0 Tidak perlu penambahan
Disiapkan Oleh: Disetujui Oleh:

Tanggal: Tanggal:
Fungsi IT Infrastructure Manajer Sistem Informasi
.............................. ..............................
Lampiran 9.3.3
Laporan Monitoring Kapasitas Hardware
Kapasitas Hardware
Hardware
Hardware
Nama Merk/Jenis Pengguna Jumlah yang Kondisi Kondisi Pertambahan Tindak
No. yang Telah Treshold
Hardware Hardware Hardware Hardware Belum Hardware Elektrikal Unit Lanjut
Digunakan
Digunakan
1 Penjelasan Penjelasan Penjelasan Penjelasan Penjelasan Penjelasan Penjelasan Penjelasan Penjelasan Penjelasan Penjelasan
nama merk/jenis mengenai mengenai mengenai mengenai mengenai mengenai mengenai mengenai mengenai
hardware hardware unit bisnis jumlah jumlah jumlah kondisi kondisi kebutuhan treshold kebutuhan
sebagai hardware hardware hardware hardware elektrikal hardware yang telah penambahan
pengguna yang telah yang belum saat ini (daya, dll) diluar ditentukan kapasitas
hardware terpakai terpakai saat ini kebiasaan

Tanggal: Tanggal:
...................................... ......................................
Lampiran 9.4.1
3.4.1. Manajemen Ketersediaan (Availability)
Pelaksana
No. Uraian Kegiatan GM Sistem Fungsi Service Fungsi Solution Fungsi IT Planning Input Output
Informasi Management Development & Compliance
Persyaratan Lampiran 9.4.2

ketersediaan Form Perencanaan
Inventarisasi persyaratan ketersediaan Mulai Availabilty
layanan, berdasarkan perubahan
1
kebutuhan bisnis atau perubahan
layanan ke depan.
Log penggunaan Hasil analisa

ketersediaan saat ketersediaan
ini infrastruktur
Analisa ketersediaan infrastruktur
eksisting
2 pendukung (fasilitas, perangkat keras,
jaringan) Cukup
TIdak
Cukup Hasil analisa Availability Plan
Penyusunan rencana untuk mendukung
ketersediaan
ketersediaan layanan (availability plan
3 infrastruktur
untuk fasilitas, perangkat keras dan
eksisting
jaringan)
Draft Availability Availability Plan

Plan yang telah disetujui
4 Review kecukupan Availability Planning

T
Y
Log monitoring
ketersediaan
5 Monitoring ketersediaan sumberdaya TI
Lampiran 9.4.3
laporan manajemen
Penyusunan laporan rutin ketersediaan
6 Availability layanan
sumberdaya TI.
TI
Lampiran 9.4.2
Perencanaan Availability
Target Target Target

Aplikasi Infrastruktur
No Layanan TI Availability Availability Availability Keterangan
Terkait Terkait
Layanan TI Aplikasi Infrastruktur
1. Nama layanan TI Target Nama aplikasi Target Nama Target Keterangan yang
availability availability infrastruktur TI availability dibutuhkan, misal
layanan TI layanan TI pendukung infrastruktur strategi availability,
TI penyedia jasa dan
pendukung lain sebagainya.
Dibuat Oleh: Diperiksa Oleh: Disetujui Oleh:
Tanggal: Tanggal: Tanggal:
Fungsi IT Fungsi IT Planning & Manajer Sistem

Infrastructure Governance Informasi
...................................... ...................................... ................................

Lampiran 9.4.3
Laporan Monitoring Availability layanan TI

Bulan MMM Tahun YYYY
Version: 1.0
Draft 1
Document Author:
Document Owner:
TI PT. WIJAYA KARYA (Persero) Tbk
Lampiran 9.4.3
Riwayat Dokumen
Peninjauan Dokumen
Distribusi
Nama Jabatan
Persetujuan

Lampiran 9.4.3
Daftar Isi
1 PENDAHULUAN ...................................................................................... 4
2 RINGKASAN AVAILABILITY .................................................................. 5
3 AVAILABILITY MONITORING REPORT ................................................. 6
3.1 SERVICE COMPONENT 1 ........................................................................ 6
3.2 SERVICE COMPONENT 2 ........................................................................ 6
Lampiran 9.4.3
1 Pendahuluan
Dokumen ini dimaksudkan sebagai sarana komunikasi antara [Penyedia

Layanan] dan manajemen PT Wijaya Karya. Dalam dokumen ini dilaporkan
pencapaian kinerja terhadap Perjanjian Tingkat Layanan dan informasi lain
yang terkait dengan aktivitas [Penyedia Layanan].
Laporan ini mencakup periode [bulan …] sampai dengan [bulan ….] tahun ….
Lampiran 9.4.3
2 Ringkasan Availability
Komponen Target Pencapaian

No Outage Dampak Keterangan
Layanan Availability Availability
Nomor Komponen Layanan Target Jumlah Pencapaian Dampak yang ditimbulkan Keterangan yang
availability outage availability diperlukan
komponen dalam
layanan persen
1
2
3
4
Lampiran 9.4.3
3 Availability Monitoring Report

3.1 Service Component 1..
<Hasil monitoring availability component 1>
3.2 Service Component 2...

<Hasil monitoring availability component 1>
Lampiran 9.5.1
3.5.1. Penyusunan Continuity Plan
Pelaksana
No. Uraian Kegiatan Direktur Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning
GM Sistem Informasi Input Output
Penanggung Management Infrastructure Development & Compliance
jawab SI
Daftar aplikasi dan Hasil Risk
Mulai infrastruktur Assessment
Risk Assessment terkait
1 dengan kejadian-kejadian
yang potensial mengganggu
ketersediaan layanan
Daftar proses bisnis Lampiran 9.5.4

dan layanan TI Disaster Recovery
2 Business Impact Analysis Plan:
Hasil Business
Impact Analysist
Konsep struktur
Penyusunan konsep struktur organisasi
3
organisasi untuk menjalakan
continuity plan
Continuity Plan
Penyusunan strategi Strategy
4
recovery- resumption
Recovery Plan
Penyusunan Prosedur Recovery
5
untuk layanan-layanan
Resumption Plan
Penyusunan prosedur Resumption
6
untuk layanan-layanan
Testing Plan
7 Penyusunan rencana testing
Lampiran 9.5.4
Disaster Recovery
Review kecukupan Continuity Plan.
Plan:
8 Draft Continuity
Persetujuan Continuity Plan untuk
Belum memadai Plan yang akan
selanjutnya disahkan oleh direksi
diajukan ke Direksi
terkait.
Sudah dai Draft Continuity Lampiran 9.5.4

mema Plan yang akan Disaster Recovery
diajukan ke Plan:
9 Pengesahan Continuity Plan
Direksi Continuity Plan
yang sudah
disetujui
Dokumentasi
sosialisasi dan
Sosialisasi dan training atas training
10 continuity plan yang telah disusun
kepada unit kerja dan staff terkait
Selesai
Lampiran 9.5.2
3.5.2. Pengujian Continuity Plan
Pelaksana
No. Uraian Kegiatan GM Sistem Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning &
Input Output
Jadwal pengujian Lampiran 9.5.5
Mulai Rencana Pengujian
DRP:
Penyusunan skenario pengujian,
1 Rencana Pengujian
termasuk penetapan kriteria kesuksesan
Notifikasi kepada
Notifikasi kepada fungsi layanan terkait fungsi terkait lain di
2 SI
dengan rencana pengujian
Notifikasi kepada
Notifikasi kepada pengguna relevan pengguna
3
terkait dengan kegiatan pengujian
Lampiran 9.5.6
Service Continuity
Test Report
4 Pengujian continuity plan
Lampiran 9.5.4
Disaster Recovery
Plan
Dokumentasi hasil Dokumentasi
pengujian evaluasi hasil
pengujian
Evaluasi ketercapaian kriteria yang telah
5 Tidak
ditetapkan, khususnya RTO dan RPO.
Tercapai
Dokumentasi
Tercapai training ulang
Apakah dibutuhkan training ulang kepada
pihak-pihak terkait?
6
Jika ya, maka akan dijadwalkan dan
dilaksanakan training ulang
Lampiran 9.5.4
T Disaster Recovery
Apakah dibutuhkan penyesuaian Plan:
conitnuity plan? Jika iya, maka akan Continuity Plan
Y
dilakukan penyesuaian. yang telah
7 disesuaikan
(mekanisme persetujuan mengikuti
proses seperti di penyusunan baru jika
perubahannya bersifat major.)
Selesai
Lampiran 9.5.3
3.5.3. Eksekusi Continuity Plan
Pelaksana
No. Uraian Kegiatan Manajer Sistem Fungsi Service Fungsi Solution Fungsi IT Planning &
Fungsi IT Infrastructure Input Output
Informasi Management Development Compliance
Lampiran 9.5.4
Disaster Recovery
Identifikasi insiden bersifat major dan Manajemen Plan
1 berpotensi bencana berdasarkan deteksi Permintaan Lampiran 9.5.5
dari manajemen insiden Layanan Rencana Pengujian
DRP
Hasil identifikasi Analisa lanjutan

Analisa lanjutan untuk memastikan potensi bencana status bencana
2 bahwa insiden yang dilaporkan akan
berpotensi sebagai disaster
T
Apakah insiden bersifat sebagai
3
disaster?
Y
Lampiran 9.5.6 Notofikasi kepada
Notifikasi kepada Koordinator IT DRP Service Continuity koordinator IT DRP
4 Test Report
untuk melakukan deklrarasi bencana.
Notofikasi kepada Deklarasi Bencana

Deklarasi bencana oleh Koordinator IT koordinator IT DRP
5
DRP
Dokumentasi
recovery data dan
6 Recovery Data dan Sistem Aplikasi aplikasi
Doumentasi
recovery
7 Recovery Infrastruktur infrastruktur
Notifikasi kesiapan
pengalihan ke DRC
Doumentasi
Pengalihan penyelenggaraan Layanan operasional di DRC
8
pada lingkungan DRC
Dokumentasi
kesiapan DC
9 Perbaikan pada lingkungan DC
Apakah lingkungan DC sudah siap untuk T

10
digunakan kembali?
Y
Dokumentasi Dokumentasi
kesiapan DC resumption layanan
11 Pemulihan layanan di DC (resumption)

Selesai
Lampiran 9.5.4
Disaster Recovery Plan

Lampiran 9.5.4
Lampiran I: Form Business Impact Analysis
Business Impact Analysis

1. Kriteria Dampak
Contoh:
Kriteria
ID Extreme (E) Very High (V) High (H) Medium (M) Low (L)
Dampak
D1 Penurunan Adanya gangguan Adanya gangguan Adanya gangguan Adanya gangguan Adanya gangguan
Pendapata layanan layanan layanan layanan layanan
n / potensi menyebabkan menyebabkan menyebabkan menyebabkan menyebabkan
kehilangan penurunan penurunan penurunan penurunan penurunan
pendapatan pendapatan pendapatan pendapatan antara pendapatan
mencapai >10% mencapai 7,5% ≤ antara 5% ≤ 7,5% 2,5% ≤ 5% dari mencapai 2,5%
dari target 10% dari target dari target target pencapaian dari target
pencapaian pencapaian pencapaian pencapaian
Lampiran 9.5.4
2. Interval Waktu Dampak

Contoh:
ID Interval Waktu Dampak
T1 < 1 jam
T2 1 jam s.d < 1 hari
T3 1 hari s.d < 3 hari
T4 3 hari s.d < 1 minggu
T5 1 minggu s.d < 1 bulan
T6 >= 1 bulan
3. Nilai Aspek Dampak

Contoh:
Kriteria T1 T2 T3 T4 T5 T6 Level dampak L M H V E
MTD
Nilai bobot 6 5 4 3 2 1 Nilai bobot 1 2 3 4 5
Lampiran 9.5.4
4. Analisis Kritikalitas Proses Bisnis

Contoh:
Dampak Maks
Proses D1 - Penurunan Pendapatan / Aktivitas Kritis Dan D Score X
No Mtd Kritikalitas
Bisnis Potensi Kehilangan Beban Puncak 1 Mtd Score
T1 T2 T3 T4 T5 T6 Mtd
Deskripsi Proses
Bisnis 1:
Proses 1
1. - L M H V E 15 5 75 65,79
Bisnis 1 jam
Catatan Beban
Puncak:
Deskripsi Proses
Bisnis 2:
Proses 1
2. - L L M M H 9 5 45 39,47
Bisnis 2 jam
Catatan Beban
Puncak:
Lampiran 9.5.4
LAMPIRAN II: FORM PERHITUNGAN RTO DAN RPO
Perhitungan RTO dan RPO

1. Pemetaan Proses Bisnis – Aset TI Pendukung
Contoh:
Proses Bisnis Aset TI Pendukung
No (Diurut Berdasarkan
Aplikasi Infrastruktur Infrastruktur Shared
Kritikalitas)
1. Proses Bisnis 1 Aplikasi 1 Infrastruktur 1 Infrasruktur Shared 1
Aplikasi 2 Infrastruktur 2 Infrasruktur Shared 2
Aplikasi 3 Infrastruktur 3 Infrasruktur Shared 3
... Infrastruktur 4
...
2. Proses Bisnis 2 Aplikasi 4 Infrastruktur 5
Aplikasi 5 Infrastruktur 6
Aplikasi 6 Infrastruktur 7
... Infrastruktur 8
...
2. Perhitungan RTO dan RPO untuk Setiap Aset TI Pendukung

Contoh:
No Aset TI Pendukung RTO RPO
1. Aplikasi 1 20 menit 6 jam
Lampiran 9.5.4
LAMPIRAN III: FORM IT CONTINUITY ORGANIZATIONAL STRUCTURE
IT Continuity Organizational Structure

Contoh:
Lampiran 9.5.4
LAMPIRAN IV: FORM IT CONTINUITY TEST PLAN
IT Continuity Test Plan
ID RTM : ........................................................................................................
Nama Sistem : ........................................................................................................
Pemilik Sistem : ........................................................................................................
Pengembang : ........................................................................................................
1. Incident Response
Bagian ini mendeskripsikan tindakan-tindakan yang dilakukan ketika sudah terjadi
becana maupun akan terjadi becana di Kantor Pusat PT Wijaya Karya (Persero)
Tbk..Tujuan utama respon bencana yaitu untuk menyelamatkan jiwa manusia dan
melokalisasi bencana. Persiapan sebelum terjadi situasi tanggap darurat, diatur
dalam Prosedur Penanganan Kondisi Darurat Kantor Pusat
Bagian ini mencakup hal-hal sebagai berikut:

1. Notifikasi Bencana
2. Kesiapsiagaan
3. Tanggap Darurat
4. Penilaian Kerusakan (Tim Penilaian Dampak)
5. Deklarasi Bencana
Lampiran 9.5.4
Berikut alur incident

response.
Gambar 4 - Alur Incident Response
Keterangan:
D = Hasil Damage Assessment

N = Notifikasi ke Tim Penanggulangan Bencana
1.1. Notifikasi Bencana

Ketika terjadi suatu bencana, dibutuhkan prosedur notifikasi bencana dari staf
PT Wijaya Karya (Persero) Tbk.yang berada pada lokasi tersebut. Prosedur
ini mencakup proses pelaporan situasi bencana, menghubungi pihak
berwenang jika dibutuhkan, dan notifikasi call tree kepada tim-tim BCP DRP.
Prosedur notifikasi bencana itu adalah sebagai berikut.
Lampiran 9.5.4
Tabel 5 - Prosedur Notifikasi Bencana

No Aktivitas Penanggung jawab
1. Identifikasi insiden yang mungkin terjadi di Tim Tanggap
Kantor Pusat. (Referensi: Prosedur Darurat
Penanganan Kondisi Darurat Kantor Pusat)
2. Ketika terjadi bencana, atau mendapatkan Staf PT Wijaya Karya

informasi akan ada bencana, staf PT Wijaya (Persero) Tbk.
Karya (Persero) Tbk.yang berada di lokasi
(on-site) bertanggung jawab untuk
memberikan notifikasi kepada Koordinator
Penanggulangan Bencana setempat.
Notifikasi memuat informasi sesuai dengan
form Notifikasi Bencana. Notifikasi tersebut
melalui jalur telepon, email, maupun secara
langsung kepada Koordinator
Penanggulangan Bencana setempat.
3. Apabila informasi akan adanya bencana Koordinator

berasal dari Cabang dan bencana tersebut Penanggulangan
diprediksikan berpengaruh pada Cabang lain Bencana Cabang
atau pusat maka Koordinator
Penanggulangan Bencana Cabang akan
memberikan notifikasi ke Koordinator
Penanggulangan Bencana Pusat sesuai
dengan informasi dari staf PT Wijaya Karya
(Persero) Tbk..
4. Memberikan notifikasi kepada Koordinator Koordinator
Penanggulangan Bencana Cabang lain akan Penanggulangan
adanya bencana. Bencana Pusat
5. Tim Administrasi melakukan call tree ke Tim Tim Administrasi

Manajemen Krisis atas perintah Koordinator
Penanggulangan Bencana untuk bertemu di
Command Center, jika diperlukan.
6. Jika bencana belum terjadi tetapi bencana Koordinator

diprediksikan akan terjadi maka Koordinator Penanggulangan
Penanggulangan Bencana Bencana
mengkoordinasikan kesiapsiagaan.
Lampiran 9.5.4

7. Jika bencana sudah terjadi, Koordinator Koordinator
Penanggulangan Bencana menginstruksikan Penanggulangan
Tim Tanggap Darurat ke lokasi kejadian Bencana
untuk melakukan tindakan respon segera, jika
diperlukan.
8. Jika bencana sudah terjadi, Koordinator Koordinator

Penanggulangan Bencana juga menghubungi Penanggulangan
tim Tim Penilaian Dampak untuk bersama- Bencana
sama melakukan penilaian awal kerusakan,
apabila memungkinkan.
9. Koordinator Penanggulangan Bencana Koordinator

bersama dengan Tim Penilaian Dampak Penanggulangan
mendatangi lokasi untuk melakukan Bencana dan tim
penilaian kerusakan awal. Tim Penilaian
Dampak
10 Tim Administrasi atas instruksi Koordinator Tim Administrasi

Penanggulangan Bencana menghubungi
pihak yang berwenang (misalnya polisi dan
pemadam kebakaran), jika diperlukan
1.2. Kesiapsiagaan
Kesiapsiagaan dilakukan ketika ada peringatan bencana yang menyatakan
kemungkinan besar akan terjadi di Kantor Pusat. Peringatan dini atau
informasi tersebut berasal dari pihak berwenang seperti BMG.
Lampiran 9.5.4
Tabel 6 - Prosedur Kesiapsiagaan

1. Membahas rencana Tim Manajemen Krisis
penanggulangan bencana salah
satunya rencana tanggap darurat.
2. Menginformasikan kepada seluruh Tim Administrasi

pegawai bahwa akan terjadi bencana
dan tindakan yang harus dilakukan
3. Melakukan penyuluhan kepada tim Koordinator

penanggulangan bencana akan Penanggulangan
tindakan yang harus dilakukan Bencana
terutama tindakan pencegahan dan
tanggap darurat
4. Melakukan koordinasi pelaksanaan Tim Tanggap
tanggap darurat dengan tim tanggap Darurat
darurat dan personil terkait, salah
satunya personil yang diberi tanggung
jawab membawa barang- barang
penting ketika evakuasi. Personil dan
barang tersebut dinyatakan dalam grab
list.
5. Melakukan pengecekan dan Tim Fasilitas dan
memperkuat kendali yang spesifik ke Operasi
masing-masing bencana untuk
mencegah terjadinya bencana
ataupun mengurangi dampak
bencana.
6. Menyiapkan perangkat P3K, evakuasi Tim Tanggap
dan lokalisasi bencana sesuai dengan Darurat
bencana yang akan terjadi.
7. Melakukan pengecekan dan penyiapan Tim Kontinuitas Bidang

drive- away kit untuk masing-masing
Bidang.
8. Melakukan tindakan tanggap darurat, jika Tim Tanggap
diperlukan. Tanggap darurat didasarkan Darurat
pada notifikasi Koordinator
Penanggulangan Bencana.
Lampiran 9.5.4
1.3. Tanggap Darurat

Pada bagian ini, dijelaskan proses utama dalam tanggap darurat. Tujuan
utama tanggap darurat yaitu menyelamatkan jiwa manusia dan mengurangi
dampak bencana. Fungsi utama tersebut dijalankan pada setiap bencana.
Prosedur-prosedur yang tercakup dalam core function tanggap darurat
adalah:
1. Peringatan
2. Evakuasi
3. P3K
4. Pengamanan fasilitas
1.3.1. Peringatan
Proses peringatan bertujuan dalam menyebarkan informasi peringatan
kemungkinan adanya bencana kepada kepada Tim Manajemen Krisis
maupun Tim Tanggap Darurat dan kepada pihak-pihak yang
berwenang (misalnya polisi, pemadam kebaran, dan tim SAR).
Proses peringatan ini sangat vital dan harus tersedia untuk memastikan
Tim Manajemen Krisis, Tim Tanggap Darurat, dan pihak-pihak yang
berwenang, mengambil tindakan perlindungan yang tepat untuk
mencegah adanya korban jiwa, kecelakaan, dan atau kerusakan pada
aset PT. PT Wijaya Karya (Persero) Tbk..
Lampiran 9.5.4
Prosedur Peringatan (Warning) adalah sebagai berikut.

Tabel 7 - Prosedur Peringatan/Warning
No Aktivitas Penanggung
jawab
1. Menerima informasi/peringatan akan Tim
adanya bencana dari Koordinator Tanggap
Penanggulangan Darurat
Bencana
2. Mengaktifkan sistem peringatan bencana di Tim

PT Wijaya Karya (Persero) Tbk.untuk Tanggap
menyebarkan informasi peringatan Darurat
kemungkinan adanya bencana ke seluruh
staf PT. PT Wijaya Karya (Persero) Tbk.,
jika diperlukan.
3. Memberikan arahan kepada pegawai Tim
PT Wijaya Karya (Persero) Tanggap
Tbk.dalam melakukan tindakan Darurat
penyelamatan.
4. Jika situasi bencana dibatalkan atau Tim
dihentikan, Tim Tanggap Darurat Tanggap
melakukan proses penyebaran informasi Darurat
pembatalan/penghentian situasi bencana
kepada pihak-pihak yang terkait
1.3.2. Evakuasi
Proses evakuasi dilakukan untuk memastikan aman dan tertibnya
proses perpindahan staf PT Wijaya Karya (Persero) Tbk.ke lokasi yang
aman/Assembly Point ketika adanya situasi bencana.
Lampiran 9.5.4
Prosedur evakuasi adalah sebagai berikut.

Tabel 8 - Prosedur Evakuasi
jawab
1. Memeriksa wilayah kerja apakah Tim
diperlukan evakuasi penuh Tanggap
Darurat
2. Mengarahkan dan membantu staf PT Tim Tanggap
Wijaya Karya (Persero) Tbk.dari wilayah Darurat
kerja masing-masing ke lokasi Assembly dengan
Point melalui Jalur Evakuasi dengan dibantu Tim
menggunakan lampiran Rute Evakuasi Kontinuitas
Bidangdan
pegawai PT
Wijaya Karya
(Persero) Tbk.
3. Masing-masing Staf PT. PT Wijaya Karya Staf PT Wijaya
(Persero) Tbk., dibantu oleh Karya (Persero)
Tim Tanggap Darurat, jika dimungkinkan Tbk.
membawa barang sesuai pembagian dan Tim Tanggap
tanggung jawab yang ada di Grab List. Darurat
4. Memeriksa apakah semua staf PT Tim

Wijaya Karya (Persero) Tbk.dari wilayah Tanggap
kerja yang bersangkutan sudah berada Darurat
di lokasi Assembly Point
1.3.3. Pertolongan Pertama pada Kecelakaan (P3K)

Proses P3K terdiri dari tindakan-tindakan yang diambil dalam
melindungi staf PT Wijaya Karya (Persero) Tbk.dari efek bencana.
Tindakan-tindakan ini termasuk melakukan tindakan P3K,
menyediakan makanan dan pakaian jika dibutuhkan, dan melakukan
koordinasi dengan pihak berwenang yang terkait (seperti pihak rumah
sakit/instansi kesehatan, tim SAR, tim Penanggulangan Bencana, dan
lain sebagainya).
Lampiran 9.5.4
Prosedur P3K adalah sebagai berikut.

Tabel 9 - Prosedur P3K
jawab
1. Ketika terjadi bencana, Tim Tanggap Tim
Darurat melakukan proses identifikasi Tanggap
seluruh staf PT Wijaya Karya (Persero) Darurat
Tbk.yang berada di lokasi bencana apakah
ada yang terluka atau korban jiwa dan
apakah ada staf PT Wijaya Karya (Persero)
Tbk.yang hilang. Identifikai tersebut
dilakukan secara kontinyu.
2. Jika ada yang terluka, Tim Tanggap Darurat Tim
melakukan proses pertolongan pertama dan Tanggap
jika dibutuhkan menghubungi dan Darurat
berkoordinasi dengan pihak-pihak
berwenang yang terkait seperti rumah sakit
atau instansi medis lainnya
3. Jika ada staf PT Wijaya Karya (Persero) Tim
Tbk.yang hilang, Tim Tanggap Darurat Tanggap
melakukan proses pencarian dan jika Darurat
dibutuhkan menghubungi dan
berkoordinasi dengan pihak-pihak
berwenang
yang terkait seperti tim SAR dan tim Reaksi
Cepat Badan Nasional Penanggulangan
Bencana
4. Menyediakan makanan dan pakaian kepada Tim
staf PT Wijaya Karya (Persero) Tbk.yang Tanggap
membutuhkan dan jika dibutuhkan Darurat
menghubungi dan berkoordinasi dengan
pihak-pihak berwenang terkait seperti tim
Reaksi Cepat Badan Nasional
Penanggulangan Bencana
1.3.4. Pengamanan Fasilitas

Proses pengamanan fasilitas/resource management terdiri dari
tindakan- tindakan yang diambil dalam melindungi fasilitas dan aset PT
Wijaya Karya (Persero) Tbk.yang kritis. Proses ini juga mencakup proses
pengorganisasian sumberdaya PT Wijaya Karya (Persero) Tbk.dalam
menanggulangi bencana.
Lampiran 9.5.4
Prosedur Pengamanan Fasilitas/Resource Management adalah

sebagai berikut.
Tabel 10 - Prosedur Pengamanan Fasilitas
jawab
1. Melakukan proses lokalisasi bencana Tim
dengan menggunakan peralatan yang Tanggap
sesuai dengan sumber bencana tersebut Darurat
(misalnya api, air, listrik, dan lain
sebagainya) dan memprioritaskan
penyelamatan aset-aset yang kritis
2. Jika dibutuhkan, bekerja sama dengan Tim

pihak yang berwenang (Dinas Pemadam Tanggap
Kebakaran Provinsi Sumatera Utara, tim Darurat
medis rumah sakit terdekat, Disnaker
Provinsi Sumatera Utara, dll) tersebut
dalam melakukan proses lokalisasi
bencana. (Referensi: Prosedur
Penanganan Kondisi Darurat Kantor
Pusat).
3. Mengecek kembali barang-barang yang ada Tim Tanggap
dalam Grab List untuk diamankan. Apabila Darurat
ada
yang tertinggal, dilakukan penyelamatan
barang tersebut.
4. Menyiapkan aset-aset yang kritis yang Tim
berhasil diselamatkan untuk dibawa dalam Tanggap
Drive Away Kit Darurat
5. Memastikan kecukupan suplai Tim

perlengkapan- perlengkapan yang Tanggap
dibutuhkan dalam proses respon bencana Darurat
seperti suplai medis, makanan, pakaian,
dan peralatan-peralatan lokalisasi bencana
(seperti fire extinguisher) dan jika
dibutuhkan menghubungi pihak-pihak
supplier untuk memastikan ketercukupan
suplai peralatan-peralatan tersebut
Lampiran 9.5.4
1.4. Penilaian Kerusakan

Setelah diterima laporan adanya kemungkinan suatu situasi bencana, maka
selanjutnya dilakukan proses penilaian kerusakan untuk mengestimasi
kerusakan pada seluruh aset yang dimiliki oleh PT. PT Wijaya Karya (Persero)
Tbk..
Proses penilaian kerusakan terbagi menjadi:
1. Penilaian kerusakan awal dilakukan oleh Koordinator Penanggulangan Bencana untuk

menentukan level kejadian yang akan direkomendasi kepada Direksi
2. Penilaian kerusakan lanjutan dilakukan oleh BCP Koordinator dan tim IT-
DRP untuk membantu perbaikan lokasi utama maupun aktivasi DRC.
1.4.1. Penilaian Kerusakan Awal

Proses penilaian kerusakan awal dilakukan untuk memberikan
rekomendasi tingkat kejadian kepada manajemen. Rekomendasi
tersebut digunakan oleh Direksi untuk menentukan tingkat bencana dan
kemungkinan dibutuhkannya suatu deklarasi bencana (apabila kejadian
tingkat 2 dan 3).
Lampiran 9.5.4
Prosedur penilaian kerusakan awal adalah sebagai berikut.

Tabel 11 - Prosedur Penilaian Kerusakan Awal
Penanggung
No Aktivitas
jawab
1. Melakukan proses penilaian kerusakan Koordinator
awal berdasarkan kriteria sebagai Penanggulanga
berikut: n Bencana dan
Tim Penilaian
 Area kerusakan (estimasi berapa Dampak
luas daerah yang terkena dampak
bencana, termasuk fasilitas yang
rusak)
 Waktu kerusakan (estimasi berapa

lama gangguan pada proses bisnis
terjadi)
2. Menyampaikan hasil penilaian awal ke Koordinator
tim Manajemen Krisis Penanggulang
an Bencana
3. Memberikan rekomendasi kepada Tim

manajemen berdasarkan hasil Penilaian Manajemen
Kerusakan Awal Krisis
1.4.2. Penilaian Kerusakan Lanjutan

Prosedur penilaian kerusakan lanjutan merupakan proses penilaian
kerusakan yang lebih lengkap yang dilakukan untuk membantu proses
aktifkasi DRC dan proses pemulihan.
Prosedur penilaian kerusakan lanjutan adalah sebagai berikut.

Lampiran 9.5.4
Tabel 12 - Prosedur Penilaian Kerusakan Lanjutan

jawab
1. Melakukan proses penilaikan kerusakan Tim Penilaian
lanjutan berdasarkan kriteria penilaian Dampak
kerusakan (dengan menggunakan checklist dibantu Tim
penilaian kerusakan pada lampiran) sebagai Manajemen
berikut: Krisis
 Penyebab dari disruption atau outage
 Potensial adanya tambahan

kerusakan atau disruption
 Status dari infrastruktur fisik

(misalnya kondisi dari listrik,
telekomunikasi, dan AC)
 Status inventori dan fungsional dari
perangkat TI (misalnya berfungsi
penuh, berfungsi sebagian, dan tidak
berfungsi)
 Penyebab kerusakan pada perangkat

TI atau data (misalnya karena air, api
& panas, dampak fisik, dan electrical
surge)
 Perlengkapan yang harus diganti

(misalnya hardware, software,
firmware, dan material-material
pendukung lainnya)
 Perkiraan waktu untuk

pemulihan proses/layanan yang
normal
2. Menyampaikan hasil Penilaian Kerusakan Koordinator
Lanjutan kepada tim BCP DRP (untuk Penanggulan
proses aktifikasi DRC) dan kepada staf PT gan Bencana
Wijaya Karya (Persero) Tbk.yang
berkepentingan dalam proses restorasi
proses bisnis PT Wijaya Karya (Persero)
Tbk.
Lampiran 9.5.4
1.5. Aktivasi BCP DRP

Setelah diterima rekomendasi dari hasil penilaian kerusakan awal, Direksi
menentukan tingkat bencana dan menyiapkan kemungkinan dikeluarkannya
pernyataan deklarasi bencana jika dibutuhkan. Hasil pernyataan deklarasi
bencana itu dibutuhkan untuk memilih tim mana saja yang menjalankan BCP
dan proses koordinasi setiap tim BCP sesuai skenario yang harus dijalankan
oleh masing-masing tim.
Prosedur deklarasi bencana adalah sebagai berikut.
Tabel 13 - Prosedur Deklarasi Bencana

1. Menentukan tingkat kejadian dan Direksi
mendeklarasikan bencana apabila kejadian
menengah dan mayor berdasarkan hasil
rekomendasi Tim Manajemen Krisis
2. Menentukan tim yang harus menjalankan Koordinator

BCP DRP. Penanggulangan
Bencana
3. Melakukan koordinasi kepada seluruh tim (Tim Koordinator

IT DRP, tim Emergency Response, Tim Penanggulangan
Kontinuitas Bidang, Tim Penilaian Dampak, Bencana, Tim IT
dan tim Administration) yang menjalankan DRP, tim Emergency
BCP terkait skenario yang harus dijalankan Response, Tim
oleh masing-masing tim. Kontinuitas Bidang,
Tim Penilaian
Dampak
2. IT Disaster Recovery Plan

2.1 Desain DRC
2.1.1 WAN dan Jaringan Internal

Desain arsitektur Wide Area Network menempatkan Kantor Pusat
sebagai data center primer yang menghubungkan seluruh kantor cabang
atau node cabang. Hubungan ini menggunakan koneksi dual ISP
(Internet Service Provider). Koneksi utama dapat merupakan koneksi
dedicated.
Lampiran 9.5.4
Desain konektivitas internal PT Wijaya Karya (Persero) Tbk.

menggunakan multilayer switch. Switch ini juga disebut core switches,
menyediakan koneksi antara WAN, Internet Layer, Intranet Layer,
Extranet Layer di lingkungan kantor-kantor cabang PT Wijaya Karya
(Persero) Tbk. dan jaringan Kantor Pusat PT Wijaya Karya (Persero)
Tbk. .
Koneksi WAN menggunakan infrastruktur yang dikelola Internet Service

Provider untuk menghubungkan semua unit kerja di lingkungan PT
Wijaya Karya (Persero) Tbk. . Sehingga manajemen jaringan yang
berhubungan dengan WAN dikelola dalam kooordinasi oleh ISP dan PT
Wijaya Karya (Persero) Tbk. .
Desain arsitektur Data Center di lingkungan Kantor Pusat, secara

fungsional terdiri dari beberapa segmen yaitu:
1. Internet Layer, merupakan subnet server untuk akses publik berupa
layanan Internet, misalnya webserver, DNS server, mail server, proxy
server
2. Intranet Layer, merupakan subnet server untuk layanan akses internal
organisasi yang berada pada lokasi lain, misalnya radius server
kantor- kantor cabang
3. Extranet Layer, merupakan subnet server untuk layanan kerjasama
akses eksternal organisasi kepada mitra strategis. Misalnya
pelaporan rutin pada eselon yang lebih tinggi.
4. Remote Access Layer, merupakan subnet untuk layanan akses
mobile untuk user atau karyawan PT Wijaya Karya (Persero) Tbk.
yang bekerja di luar gedung organisasi PT Wijaya Karya (Persero)
Tbk.
5. Internal LAN, yang memberikan layanan data center pada pengguna internal PT
Wijaya Karya (Persero) Tbk. melalui media LAN. Biasanya Internal LAN suatu
organisasi disegmentasi berdasarkan lokasi gedung. Misalnya Internal LAN PT
Wijaya Karya (Persero) Tbk. terdiri atas LAN Gedung A, LAN Gedung B dan LAN
Gedung C.
Model segmentasi data center PT Wijaya Karya (Persero) Tbk. terdapat pada
gambar di bawah.
Lampiran 9.5.4
Gambar 5 - Model Segmentasi Data Center

Lampiran 9.5.4
Secara konseptual, model data center ini bersifat generic sehingga dapat
dikembangkan menjadi disaster recovery center.
Model data center ini dapat berfungsi sebagai disaster recovery center
dari lokasi lain. Sesuai kebutuhan, maka desain data center PT Wijaya
Karya (Persero) Tbk. dapat dipetakan seperti Tabel di bawah ini.
Tabel 14 - Fungsi Data Center pada Setiap Lokasi
No Lokasi Data Center Fungsi
Data Center
1. Kantor Pusat
Disaster Recovery Center
Backup Lokal
Data Center
2. D
Disaster Recovery Center
Backup Lokal
Data Center
3. B
Backup Lokal
Data Center
4. C
Backup Lokal
2.1.2 Model Ketersediaan Layanan Data Center

Desain data center yang berfungsi sebagai disaster recovery center
berfokus ketersediaan layanan (availability). Model ketersediaan ini
disusun berdasarkan:
1. redundansi perangkat, menggunakan perangkat dengan fungsi

redundansi yang identic
2. protokol redundasi, mengaktfikan sistem software untuk

mengendalikan dual koneksi
Model redundansi perangkat pada desain data center dapat

digambarkan pada Gambar berikut.
Lampiran 9.5.4
Gambar 6 - Model Redundansi Perangkat Desain Data Center
Keterangan:
1. Jaringan Extranet
Jaringan ini digunakan untuk melayani kebutuhan koneksi ke luar
jaringan PT Wijaya Karya (Persero) Tbk. namun non public
diantaranya mitra kerja strategis. Extranet Layer dialokasikan bagi
server-server yang diperlukan oleh mitra-mitra tersebut. Koneksi
menuju Extranet Layer ini seperti koneksi Internet Layer yaitu berada
di dalam suatu konsep subnet yang disebut dengan Demilitarized
Zone (DMZ). Demilitarized Zone ini merupakan subnet yang
memfilter koneksi berdasarkan policy akses tertentu.
2. Intranet Layer
Pada Intranet Layer, server digunakan untuk melayani kebutuhan
internal perusahaan. Server-server ini merupakan hosting aplikasi
yang mendukung proses bisnis perusahaan.
3. Remote Access Layer

Lapisan ini memberikan layanan koneksi remote personal untuk
karyawan PT Wijaya Karya (Persero) Tbk. yang berada di luar
gedung PT Wijaya Karya (Persero) Tbk. Layanan ini bersifat
temporer. Karyawan menghubungkan devicenya menggunakan
Lampiran 9.5.4
koneksi VPN (Virtual Privat Network) ke lapisan Remote Access ini.

Identitas karyawan yang diautentikasi oleh server autentikasi. Jika
sesuai, maka karyawan mendapatkan akses remote pada layanan di
dalam DC.
4. Internal LAN
Untuk akses internal organisasi, misalnya layanan pada aplikasi,
user menggunakan media Local Area Network. Local Area Network
ini menghubungkan seluruh bagian gedung pada suatu lokasi.
5. Koneksi Internet
Dual koneksi ISP dapat dimodelkan seperti gambar di bawah ini.
Dual koneksi ideal antar lokasi akan membentuk jaringan full-mesh.
Redundansi koneksi dirancang agar dapar dicapai dengan model
jaringan tersebut. Model Ini didukung dengan peering antar ISP lokal
Indonesia, misalnya dengan IIX. Penyedia koneksi WAN memiliki
hubungan routing antar ISP lokal Indonesia.
Untuk availabilitas, routing BGP yang diaktifkan pada router-router

WAN di tiap lokasi mengaktifkan fitur antara lain:
a. Filtering route, misalnya menggunakan AS_PATH Prepending

b. Administrative Weight, menentukan policy pemilihan koneksi
Fitur tersebut dapat diimplementasikan untuk blok IP Address yang

berbeda untuk subnet lokasi dan koneksi ISP yang berbeda. Dengan
fitur filter advertise, subnet dengan IP Address dari ISP berbeda
dapat dipilih untuk menggunakan ISP yang berbeda pula.
Mekanisme dual ISP ini biasanya menggunakan teknik aliasing, yaitu
setting dua IP Address dari dua ISP pada satu interface.
Lampiran 9.5.4
Gambar 7 - Model Redundansi Jaringan Dual Koneksi ISP
6. Internet Layer
Internet Layer berfungsi sebagai subnet server layanan Internet.
Internet Layer menggunakan dua unit router sebagai gateway ke
Internet. Selanjutnya digunakan dua unit firewall untuk melindungi
keamanan jaringan Internet, Extranet dan Intranet PT Wijaya Karya
(Persero) Tbk. secara keseluruhan.
Server-server yang umumnya ditempatkan di dalam Internet layer antara lain:
a. Mail server: layanan e-mail PT Wijaya Karya

(Persero) Tbk. biasanya domain e-mail menggunakan
domain organisasi terkait
b. Web server: layanan website PT Wijaya Karya (Persero)
Tbk. Biasanya digunakan sebagai layanan informasional
publik.
c. DNS server: layanan resolve domain. Biasanya ISP terkait
menyediakan layanan DNS ini, sehingga dapat dijadikan
backup temporer.
d. FTP server: layanan file sharing untuk konsumsi publik.
Untuk interaktivitas, biasanya layanan file ini ditampilkan
pada website
Lampiran 9.5.4
Penggunaan dua unit ethernet switch, router dan firewall dilakukan

untuk mengatasi terjadinya single point of failure. Model dual koneksi
Internet Layer ini terdapat pada Gambar di bawah.
Gambar 8 - Model Dual koneksi pada Koneksi Internet, Switch Utama, dan
Switch Internal
2.1.3 Redundansi Koneksi Internet

Pada level koneksi Internet sebagai jaringan publik server Internet,
mekanisme dual koneksi dari dua ISP mulithoming menyediakan
ketersediaan koneksi. Model failover terdapat pada Gambar di bawah
ini.
Lampiran 9.5.4
Gambar 9 - Model Failover Dengan Redundansi
2.1.4 Redundansi Default Gateway

Pada level router gateway LAN, dual perangkat router ini menjalankan
protokol VRRP (Virtual Redundacy Routing Protocol) untuk
menyediakan ketersediaan default gateway untuk LAN Server Internet.
Suatu virtual router yang bertindak sebagai virtual gateway LAN selalu
berada dalam status up dengan dukungan dual perangkat router. Dual
router ini berada dalam satu subnet virtual router. Mekanisme fail-over
dikendalikan oleh protokol VRRP yang mengaktifkan virtual router.
Mekanisme ini terdapat pada RFC 3768 dan RCF 5798 untuk IPv6.
Protokol lain yang menyediakan konektivitas dengan redundansi router
ini adalah HSRP (Hot Standby Routing Protocol) yang terdapat pada
RFC 2281. Pada level modifikasi, aktivasi HSRP ini juga dapat memiliki
fitur load-balancing. Model redundansi default gateway terdapat pada
Gambar di bawah.
Lampiran 9.5.4
Router 1 Router 2
Virtual Router
Switch 2
LAN LAN
Gambar 10 - Model Redundansi Default Gateway
2.1.5 Redundansi Switch

Pada level switch dan LAN, dapat digunakan STP (Spanning
Tree Protocol) yang menyediakan redundant links jika
terdapat link yang mengalami kegagalan. Standarisasi
protokol ini terdapat pada IEEE 802.1D. Konvergensi yang
lebih cepat distandarkan oleh protokol IEEE 802.1w yang
pada perkembangannya menjadi IEEE 802.1D-2004 yang
menyebabkan STP menjadi obsolete.
Gambar 11 - Model Redundansi Switch

Lampiran 9.5.4
2.1.6 Redundansi Koneksi Server

Pada level server Internet, dapat digunakan protokol
redundansi pada layer 2 (OSI Layer) yang menghubungkan
dual NIC (Network Interface Card) server dengan dual koneksi
ke pada dua port switch. Protokol ini dikenal dengan Link
Aggregation Protocol yang distandarisasi oleh IEEE 802.3ad.
Gambar 12 - Redundansi Koneksi Server
Referensi untuk desain DRC secara detail dapat dilihat pada bagian
lampiran L.
2.2 Persyaratan dan Strategi Mitigasi TI

Sesuai dengan persyaratan waktu pemulihan, layanan TI dengan kritikalitas
high sebagai berikut.
Tabel 16 – Layanan TI Kategori Kritikalitas High
No Layanan Kategori Kritikalitas High

1. Website
2. Email Corporate
3. Akses Internet
Layanan yang tersebut di atas menggunakan infrastruktur jaringan.

Berdasarkan BIA, infrastruktur jaringan merupakan aset TI yang memiliki
tingkat kritikalitas high. Layanan dengan tingkat kritikalitas high menggunakan
strategi mitigasi hot-backup.
Layanan TI yang memiliki tingkat kritikalitas medium sebagai berikut.

Lampiran 9.5.4
Tabel 17 - Layanan TI Kategori Kritikalitas Medium
No Layanan Kategori Kritikalitas Medium

1. DMS
Sedangkan layanan TI TI yang memiliki tingkat kritikalitas low sebagai berikut.
Tabel 18 - Layanan TI Kategori Kritikalitas Low
No Layanan Kategori Kritikalitas Low

1. Portal
2.2.1 Strategi Mitigasi TI

Strategi mitigasi berupa backup layanan aplikasi yang mengolah data
akan memiliki salinan aplikasi dengan data yang sesuai. Salinan aplikasi
dan data yang berfungsi sebagai backup ini akan disimpan pada lokasi
yang aman dari ancaman bencana. Pada saat terdapat gangguan pada
aplikasi dan data utama, maka salinan aplikasi dan data akan beroperasi
sebagai pengganti aplikasi dan data utama tadi.
Terdapat dua macam moda strategi backup ini:

a. Local Standby
Strategi mitigasi untuk aplikasi dan data pada yang berada pada data
center disebut Local Standby. Strategi mitigasi ini berfokus pada
segmen.
1. Back End yang berupa subnet hosting aplikasi

2. Back End yang berupa subnet database.
b. Moda remote: aktivasi DRC pada lokasi lain
Strategi mitigasi berupa backup pada data center lain menggunakan
aktivasi koneksi dan layanan WAN (Wide Area Network). Data center
pada lokasi lain ini terpisah secara geografis dari lokasi bencana.
Akses user pada sistem yang terkena bencana dialihkan pada
layanan backup yang berjalan pada data center lain. Data center lain
yang beroperasi melayani user pada status ini, dari persepsi mitigasi,
disebut Disaster Recovery Center (DRC).
Lampiran 9.5.4
2.2.2 Teknologi Strategi Mitigasi

Teknologi mitigasi yang digunakan berupa:
1. Teknologi virtualisasi untuk mitigasi aplikasi
2. Teknologi NAS untuk mitigasi data
3. Protokol redundansi untuk dual koneksi jaringan.
a. Teknologi Virtualisasi
Perkembangan teknologi virtualisasi bermula pada sekitar tahun
1960-an. Pada saat ini, teknologi virtualisasi berupa implementasi
Virtual Machine pada server backup DC merupakan teknologi
yang relatif efisien.
Efisiensi ini meliputi:

a) Fleksibilitas penggunaan sumber daya pada mesin fisik
sesuai jumlah aplikasi
b) Backup aplikasi yang berupa copy software aplikasi
c) Efisiensi penggunaan daya listrik dalam perspektif green-
data center
Teknologi virtualisasi meliputi abstraksi sumber daya mesin
fisik pada pada mesin virtual. Sumber daya yang divirtualkan
berupa:
a) Pemrosesan CPU
b) Memory
b. Teknologi NAS
Pemilihan model backup data biasanya menggunakan kriteria:
a) Data Availability yaitu ketersediaan data dengan
mekanisme fail-over, misalnya teknik mirroring data
b) Performance, yaitu kecepatan akses I/O pada media
storage.
c) Storage Capacity, berupa peningkatan densitas area
storage.
d) Lower Storage Cost, berupa efisiensi aktivitas manajemen
penyimpanan data
Salah satu teknologi yang mengimplementasikan kriteria di
atas adalah teknologi Network Attached-Storage (NAS).
Ketersediaan data dan performance pada NAS

diimplementasikan dengan NVRAM cache yang menyimpan
data sesuai dengan dinamika perubahan. Pada saat sistem
failure, data pada NVRAM tidak berubah. Selain itu terdapat fitur
failover aktif-aktif jika dioperasikan pada model cluster dengan
Lampiran 9.5.4
load balancing. Snapshot dapat dilakukan dengan software

manajemen NAS. Selain itu replikasi dapat dilakukan antar host
pada jaringan yang berbeda.
Pada beberapa tipe NAS, sudah mengimplementasikan pre-

configured RAID arrays. Fleksibilitas kapasitas penyimpanan
dilakukan dengan fitur hot- swappable dan built-in hot spare
disks.
Komponen individual NAS biasanya lebih rendah, dan dengan

satu tipe host untuk beberapa protokol. Dengan demikian, satu
tipe disk untuk satu tipe host dapat memudahkan maintenance.
Terdapat kombinasi kriteria, yang dapat memiliki solusi tunggal.

Misalnya teknologi kompresi data menaikkan efisiensi kapasitas
dan untuk transfer data akan menekan konsumsi bandwidth.
Sedangkan mekanisme fail-over ke DC untuk kritikalitas tinggi
akan membutuhkan sumber daya yang lebih banyak, jika
diinginkan pada saat yang bersamaan tetap terjadi backup ke
DRC.
Teknologi jaringan untuk mendukung akses device pada

storage biasanya menggunakan Fibre Channel.
c. Redundansi Sistem dan Koneksi Jaringan
Pada level jaringan, strategi availabilitas layanan
diimplementasikan dengan redundansi perangkat. Model
redundansi sistem dan perangkat jaringan dapat dimodelkan
seperti gambar di bawah ini.
Dual ISP sebagai penyedia koneksi WAN menggunakan dua

router yang berbeda pada Aggregation Layer. Implementasi dua
koneksi ini menggunakan routing BGP dengan strategi
ketersediaan koneksi berupa fitur-fitur pada protokol tersebut.
Lampiran 9.5.4
Gambar 13 - Model Redundansi Sistem dan Perangkat Jaringan
Pada Aggregation Layer, terdapat multilayer switch yang

berhubungan back- to-back dan membentuk topologi full-mesh
dengan dua WAN router dan dua switch pada layer di bawahnya.
Jika kedua device ini diaktifkan, akan membentuk redundansi

failover aktif- aktif. Failover aktif-aktif ini akan menghindari
terjadinya status idle satu perangkat. Dalam kondisi ideal,
failover aktif-aktif dapat mendukung fungsi load-balancing.
Sistem availabilitas pada layer ini biasanya difungsikan dengan

Spanning Tree Protocol dengan fitur menghindari looping pada
VLAN (Virtual LAN)
Penggunaan switch pada Layer 2 OSI, dengan fitur VLAN akan

memudahkan manajemen Back End. Fungsi switch
mensegregasi Application Server, Database Server, Storage
Server menjadi VLAN yang berbeda-beda secara logis.
Data center (DC) pada suatu lokasi dapat berfungsi sebagai DRC
untuk lokasi lain. Artinya Untuk memudahkan interoperasionalisasi
Back End pada tiap DC dapat digunakan cara:
a) Dual koneksi ISP pada tiap lokasi. Koneksi yang saling

Lampiran 9.5.4
berhubungan, dalam bentuk ideal akan membentuk full-

mesh
b) Emulasi subnet pada Back End tiap DC, pada tiap lokasi
Dual koneksi ISP dapat menggunakan MPLS dimodelkan
seperti gambar di bawah ini. Untuk availabilitas, routing BGP
yang diaktifkan pada router-router WAN di tiap lokasi
mengaktifkan fitur antara lain:
a. Filtering route, misalnya menggunakan AS_PATH

Prepending
b. Administrative Weight, menentukan policy pemilihan
koneksi
Fitur tersebut dapat diimplementasikan untuk blok IP Address

yang berbeda untuk subnet lokasi dan koneksi ISP yang
berbeda.
Gambar 14 - Model Jaringan Dual Koneksi ISP menggunakan MPLS
Emulasi subnet pada Back End: Bridging dengan protokol VPLS

(Virtual Private LAN Service)
Untuk memudahkan manajemen IP server pada LAN DC dan

DRC, dapat digunakan teknologi VPLS (Virtual Private LAN
Service). Teknologi ini merupakan suatu kelas dari teknologi
VPN (Virtual Private Network) yang mendukung koneksi multi
site pada satu domain bridge pada suatu jaringan IP/MPLS.
Lampiran 9.5.4
Standarisasi teknologi VPLS ini terdapat pada IETF yaitu pada

RFC 4761 dan 4762.
Teknologi ini merepresentasikan interface Ethernet pada

pengguna layanan, menyederhanakan batasan LAN/WAN bagi
provider ataupun pengguna layanan. Penyediaan layanan
dapat menjadi lebih cepat dan fleksibel. Semua layanan pada
VPLS akan tampak pada satu LAN tunggal, terlepas dari lokasi
geografis tiap LAN pada DC yang berbeda.
Lampiran 9.5.4
2.2.3 Prasyarat Strategi Mitigasi

a. Prasyarat Strategi Mitigasi: Aplikasi dan Data
Strategi mitigasi ini memerlukan prasyarat backup aplikasi dan data
yang tersedia pada saat gangguan. Diasumsikan software aplikasi
dapat dilakukan pengcopy-an secara legal. Pada kondisi normal,
proses prasyarat tersebut dapat dimodelkan dengan gambar di
bawah ini.
Gambar 15 - Model Proses Pembuatan Backup Aplikasi dan Data

pada Local Hot Standby
Pada model tersebut, server backup pada segmen backup

menggunakan virtualisasi.
Pada kondisi normal, proses pembuatan backup berupa:

a) Copy software yang disimpan pada Software repository.
Diasumsikan hanya sedikit perubahan pada software aplikasi,
misalnya update atau patching yang bersifat minor.
b) Data aplikasi berupa volume data. Pada model di atas, backup
volume data ditangani oleh:
- software database management
- software storage management
c) Server backup aplikasi menjalankan Virtual Machine dengan
platform berupa OS (Operating System) yang sama dengan server
utama
Lampiran 9.5.4
d) Segmen utama dan segmen backup dihubungkan oleh

redundansi komunikasi data pada LAN
b. Prasyarat Strategi Mitigasi: Jaringan
Model desain availability infrastruktur jaringan terdapat pada
gambar di bawah. Layanan jaringan ini berhubungan dengan dua
lapisan fungsional (subnet) pada data center. Lapisan itu adalah
subnet Application Server dan Database Server.
Gambar 16 - Model Desain Infrastruktur Jaringan dan Data

Center secara Layer Fungsional
Sesuai dengan BIA, strategi mitigasi untuk infrastruktur jaringan

mengimplikasikan terdapat dual sistem pada desain layanan
jaringan. Redundansi ini dimodelkan secara fungsional pada
gambar di atas
Dual subsistem (router, firewall, switch) pada model di atas

menunjukkan redundansi untuk:
a) Koneksi Internet
b) Koneksi WAN
c) Koneksi LAN Data Center
Agar berhubungan dengan kategori kritikalitas BIA di atas, data

center dibagi- bagi menjadi segmen fungsional. Untuk membagi
segmen data center berdasarkan fungsi sistem layanan, maka dapat
digunakan pendekatan berupa model di bawah ini.
Lampiran 9.5.4
Gambar 17 - Model Data Center dengan Segmentasi Berdasarkan

Layanan Sistem
Pengelompokan entitas menjadi berdasarkan segmentasi
layanan sistem dapat diringkas menjadi Tabel di bawah ini.
Tabel 19 - Segmentasi Data Center berdasarkan Layanan sistem

No Nama Segmentasi
Entitas
1 ISP Penyedia layanan Internet
2. Koneksi WAN Aggregation Layer
3. Internet Layer Front End: server Internet
4 Remote Access Front End: server VPN, remote

Layer access (mobile internal-user)
5 Extranet Layer Front End: subnet untuk layanan

kantor cabang
6 Intranet Layer Layanan internal organisasi (LAN)
7 Application Server Back End: subnet hosting aplikasi
8 Storage Layer Back End: subnet database dan

storage
Lampiran 9.5.4
2.2.4 Desain Strategi Mitigasi

a. Komponen Strategi Mitigasi
Berdasarkan konsep di atas, komponen strategi mitigasi diturunkan dari
kebutuhan operasional PT Wijaya Karya (Persero) Tbk. sebagai berikut:
a) Local Hot-Standby sebagai backup lokal pada data center Kantor Pusat
dan D
d) Local Hot-Standby sebagai backup lokal pada data center B dan C
e) Failover aktif-pasif DC dan DRC. Ini berarti data center pada Kantor Pusat
dan D berfungsi juga sebagai DRC (Disaster Recover Center)
Untuk efisiensi, desain strategi mitigasi disusun dalam dua bagian yaitu desain
strategi mitigasi pada kondisi normal dan desain strategi mitigasi pada kondisi
gangguan.
b. Desain Strategi Mitigasi pada Kondisi Normal

a) Aplikasi
Pada kondisi normal, dilakukan backup aplikasi sebagai berikut:
1. Untuk aplikasi DC Kantor Pusat, terdapat proses salinan software
aplikasi yang disimpan pada software repository lokal DC Kantor
Pusat.
2. Pada DC Cabang A terdapat proses salinan software aplikasi yang
disimpan pada software repository lokal DC.
3. Data center B menyimpan aplikasi dan data lokal B. C
menyimpan aplikasi dan data lokal C.
4. Selain melakukan backup lokal, B dan C melakukan backup
aplikasi yang disimpan pada DC Cabang A
5. Kantor Pusat juga menyimpan backup aplikasi pada DC Cabang A
6. Kantor D juga menyimpan backup aplikasi pada DC Kantor Pusat
Secara ringkas, backup pada kondisi normal berada
Lampiran 9.5.4
7. pada tabel di bawah ini:

Tabel 20 - Lokasi Backup Aplikasi tiap Kantor
No Nama Backup Lokasi Software

repository
1 Aplikasi Kantor  DC Kantor Pusat
Pusat
 DC Cabang A
2 Aplikasi DC  DC Kantor Pusat
Cabang A
 DC Cabang A
3 Aplikasi B  Data center B
 DC Cabang A
4 Aplikasi C  Data center C
 DC Cabang A
b) Data
Pada kondisi normal, dilakukan backup data sebagai berikut:
1. Untuk data aplikasi, terdapat proses backup, misalnya replikasi dan hasil
replikasi data DC Kantor Pusat disimpan pada sistem storage DC Kantor
Pusat
2. Pada DC Cabang A, replikasi dan hasil replikasi data DC Cabang A
disimpan pada sistem storage DC Cabang A
3. Data aplikasi pada B disimpan lokal pada data center B
4. Data aplikasi pada C disimpan lokal pada data center C
5. Data aplikasi pada B dan C, juga disimpan sebagai backup pada DC
Cabang A
6. Kantor Pusat menyimpan backup data pada DC Cabang A Kantor DC
Cabang A menyimpan backup data pada Data Center Kantor Pusat
Lampiran 9.5.4
Tabel 21 - Lokasi Backup Data tiap Kantor
No Nama Backup Lokasi Data Storage

1 Data Kantor Pusat  DC Kantor Pusat
 DC Cabang A
(DRC)
2 Data Kantor D  DC Cabang A

 DC Kantor
Pusat (DRC)
3 Data B  DC B
 DC Cabang A
(DRC)
4 Data C  DC C
 DC Cabang A
(DRC)
c) Desain Strategi Mitigasi pada Kondisi Gangguan

Gangguan dibagi dalam gangguan minor dan mayor.
1. Pada kondisi gangguan minor, ditangani lokal pada DC atau data center
yang berkaitan. Penanganan lokal ini menggunakan backup aplikasi
dan data yang berada pada software repository dan storage lokal.
2. Pada kondisi gangguan major:

 gangguan major pada B atau C: layanan operasional akan dialihkan ke
DC Cabang A dan menggunakan sistem pada DC Cabang A
 gangguan major pada Kantor Pusat: layanan operasional akan
dialihkan ke DC Cabang A dan menggunakan sistem pada DC
Cabang A
 gangguan major pada D: layanan operasional akan dialihkan ke DC
Kantor Pusat dan menggunakan sistem pada DC Kantor Pusat
Secara ringkas, pada gangguan major, lokasi gangguan dan lokasi

backup direpresentasikan pada tabel di bawah.
Tabel 22 - Peta Lokasi Gangguan Major dan Lokasi Backupnya
Lampiran 9.5.4
Lokasi Gangguan Lokasi

No Major Backup Keterangan
1. DC Kantor Pusat DC DC Cabang A berfungsi
Cabang A sebagai DRC untuk
Kantor Pusat
2. DC Cabang A DC Kantor DC Kantor Pusat

Pusat berfungsi sebagai DRC
untuk D
3. Data center B DC DC Cabang A berfungsi
Cabang A sebagai DRC untuk B
4. Data center C DC DC Cabang A berfungsi

Cabang A sebagai DRC untuk C
Lampiran 9.5.4
Disiapkan oleh:
Document Owner(s) Jabatan dalam Proyek
Riwayat Perubahan:
Version Date Author Change Description
[Isi dengan Dokumen pertama dibuat
nama
Document
Owner.]
[Isi dengan [Isi dengan list perubahan pada
nama Change tanggal dan versi ini]
Owner.]  [Perubahan 1]
 [Perubahan 2]
 [Perubahann]
Lampiran 9.5.4
1. Pendahuluan
Tujuan dari dokumen ini adalah untuk merencanakan aktivitas yang diperlukan untuk menguji IT
Service Continuity dan Rencana Ketersediaan secara berkelanjutan. Tujuan dari pengujian
rencana adalah:
• Menilai apakah backup yang dimiliki adalah tepat dan cukup lengkap dalam memulihkan
critical server (server utama)
• Menjadi terbiasa dengan berbagai proses recovery (pemulihan)
• Melakukan validasi prosedur recovery yang ada dan menghasilkan revisi dokumentasi
• Mengidentifikasi item tambahan (software, hardware, dokumentasi dll) yang diperlukan dalam
rangka memulihkan critical business systems (sistem bisnis utama)
• Menilai apakah perlindungan di bawah dukungan kontrak saat ini mencukupi
2. Rencana Pengujian
2.1 Area yang Akan Diuji
Tabel berikut diambil dari Service Continuity Plan, menunjukkan strategi pemulihan yang
perlu diuji.
Layanan yang Strategi Deskripsi Indicative
Ref.
Terpengaruh Pemulihan Contingency Timescale
Lampiran 9.5.4
2.2 Jadwal dan Prioritas Pengujian

Prioritas pengujian berbagai bagian dari rencana adalah sebagai berikut:
Status Rencana
Strategi
Prioritas Pengujian Pengujian Tanggal
Pemulihan
Saat Ini Berikutnya
2.3 Peran dan Tanggungjawab

Peran dalam organisasi yang akan terlibat dalam pengujian mengacu pada IT Service
Management Roles and Responsibilities
2.4 Review Pengujian
Semua tes akan didokumentasikan dan review akan dilakukan untuk menilai
kesuksesan pengujian terhadap sasarannya. Setiap kekurangan akan ditambahkan ke
Service Improvement Plan.
Lampiran 9.5.4
LAMPIRAN V: FORM IT CONTINUITY TEST REPORT
IT Continuity Test Report
ID RTM :
........................................................................................................
Nama Sistem :
........................................................................................................
Pemilik Sistem :
........................................................................................................
Pengembang :
........................................................................................................
Disiapkan oleh:
Riwayat Perubahan:
nama
Document
Owner.]
 [Perubahan 2]
 [Perubahann]
Lampiran 9.5.4
1. Pendahuluan
Tujuan dari dokumen ini adalah untuk melaporkan temuan tes dari aspek IT
Service Continuity Plan yang berlangsung di {lokasi} pada {tanggal}. Tujuan dari
tes adalah sebagai berikut:
• Menilai apakah backup yang dimiliki adalah tepat dan cukup lengkap
memulihkan critical server (server utama)
• Menjadi terbiasa dengan proses restorasi database
• Melakukan validasi prosedur recovery (pemulihan) yang ada dan
menghasilkan revisi dokumentasi
• Mengidentifikasi item tambahan (software, hardware, dokumentasi dll) yang
diperlukan dalam rangka untuk memulihkan critical business systems (sistem
bisnis utama)
• Menilai apakah perlindungan di bawah dukungan kontrak saat ini mencukupi
2. Ringkasan Pengujian
2.1 Tanggal dan Lokasi Pengujian

Pengujian telah dilakukan di {lokasi} pada {tanggal}.
2.2 Kepegawaian
Berikut anggota staf yang terlibat dalam pengujian.
Nama Jabatan Peran dalam Pengujian
2.3 Layanan yang Akan Diuji

Recovery (pemulihan) terhadap layanan berikut direncanakan untuk diuji:
Layanan Platform Nama Server
2.4 Fasilitas yang Disediakan {Penyedia Layanan}

Fasilitas berikut disediakan oleh {Penyedia Layanan} pada hari tersebut:
Lampiran 9.5.4
2.4.1 Hardware dan Operating Systems

Spesifikasi server yang disediakan adalah sebagai berikut:
Layanan Spesifikasi Hardware Spesifikasi Software
2.4.2 Staf Pemasok

{Sebanyak 2 staf pemasok tersedia selama pengujian; keduanya pakar
dalam hal teknis. Keduanya sangat membantu dengan pengetahuan yang
baik dalam bidangnya.}
2.5 Item yang Diperlukan Dalam Pengujian
Item berikut dibawa ke lokasi pengujian:
{Contoh:
• Dua backup mingguan terbaru
• CD instalasi Windows 2003 beserta Service Pack-nya
• Prosedur restorasi Server
• Service Continuity Plan
• Kabel cadangan}
2.6 Urutan Kejadian
2.6.1 Hari Pertama
Waktu Tahap Isu yang Dihadapi Tanggapan
2.6.2 Hari Kedua

Waktu Tahap Isu yang Dihadapi Tanggapan
3. Kesimpulan Pengujian
3.1 Pelajaran yang Diperoleh

Pelajaran berikut diperoleh sebagai hasil dari kegiatan ini:
{contoh:
Lampiran 9.5.4
• Meski kita dapat memulihkan dari rekaman ke server, kita masih

bergantung pada pemasok untuk menuntaskan konfigurasi file batch dan
skrip
• Meski target SLA dipenuhi, tergantung pada kami dalam penyediaan
pra-konfigurasi hardware dimana menjadi tujuan restore (pengembalian)
data
• Kita bisa menyiapkan server terlebih dahulu dengan OS dan DBMS
yang telah terinstall sebelum melibatkan supplier}
3.2 Aksi Tindaklanjut
Tindakan berikut akan ditambahkan pada IT Service Improvement Plan.
Penanggung Skala
Ref. Rekomendasi
Jawab Waktu
3.3 Kesuksesan vs Sasaran

Contoh:
Sasaran Tingkat Kesuksesan
Menilai apakah backup yang dimiliki Terverifikasi
adalah tepat dan cukup lengkap
memulihkan critical server (server utama)
Menjadi terbiasa dengan proses restorasi Tercapai
database
Melakukan validasi prosedur recovery Tercapai
(pemulihan) yang ada dan menghasilkan
revisi dokumentasi
Mengidentifikasi item tambahan (software, Perlu diidentifikasi
hardware, dokumentasi dll) yang hardware yang tepat
diperlukan dalam rangka untuk dimana menjadi tujuan
memulihkan critical business systems restore di masa depan
(sistem bisnis utama)
Menilai apakah perlindungan di bawah Terverifikasi
dukungan kontrak saat ini mencukupi
3.4 Tanggapan
Lampiran 9.5.4
Ini adalah tes pertama yang dilakukan sejak diperkenalkannya sistem dan
dengan demikian telah menambah pengetahuan kita secara signifikan di
sejumlah bidang penting.
Pemeriksaan lebih lanjut akan dilakukan selama periode waktu tertentu untuk
lebih mengembangkan prosedur dan kemampuan recovery (pemulihan).
Lampiran 9.5.4
LAMPIRAN VI: SAMPLE IT DISASTER RECOVERY PLAN
IT Disaster Recovery Plan
ID RTM :
........................................................................................................
Nama Sistem :
........................................................................................................
Pemilik Sistem :
........................................................................................................
Pengembang :
........................................................................................................
Disiapkan oleh:
Riwayat Perubahan:
nama
Document
Owner.]
 [Perubahan 2]
 [Perubahann]
Lampiran 9.5.4
1. Pendahuluan
Teknologi informasi (TI) dan sistem informasi otomatis merupakan elemen penting
dalam kebanyakan proses bisnis. Karena sumber daya TI sangat penting untuk
kesuksesan organisasi, layanan yang diberikan oleh sistem ini penting agar dapat
beroperasi secara efektif tanpa gangguan berlebihan. Disaster Recovery Planning
(DRP) mendukung kebutuhan ini dengan menyediakan rencana menyeluruh dan
prosedur serta langkah-langkah teknis yang dapat memungkinkan sistem dipulihkan
(di-restore) dengan cepat dan efektif setelah terjadi gangguan layanan atau bencana.
IT DRP mengacu pada strategi yang terkoordinasi, melibatkan rencana, prosedur, dan
langkah-langkah teknis yang memungkinkan pemulihan sistem IT, operasi, dan data
setelah terjadi gangguan. Perencanaan pemulihan bencana mencakup pendekatan
berikut untuk beralih dari layanan TI yang terganggu ke Disaster Recovery Centre
dengan:
 Mengembalikan operasional TI di Disaster Recovery Centre
 Memulihkan operasional TI menggunakan Backup Server dan Jaringan
 Melanjutkan transaksi bisnis terakhir yang terkena gangguan layanan TI
menggunakan proses TI yang manual.
Business Continuity Management (BCM) Life Cycle
DRP disusun berdasarkan prinsip-prinsip dan best practices dari siklus hidup BCM,
yang terdiri dari:
 Analisa fungsi bisnis dan kritikalitasnya melalui analisa dampak bisnis
(Business Impact Analysis);
 Perumusan strategi recovery BCM yang tepat dan dapat dikerjakan
berdasarkan BIA;
 Pengembangan dan implementasi rencana;
 Pengujian rencana;
 Penelaahan dan pemeliharaan rencana;
 Audit rencana; dan
 Pelaksanaan program penyadaran serta komunikasi, pelatihan dan pendidikan
dalam BCM.
1.1 Tujuan
Lampiran 9.5.4
Tujuan utama dari Disaster Recovery Plan adalah untuk memastikan

keberlanjutan operasi pada sistem bisnis yang diidentifikasi kritikal, saat terjadi
bencana.
Tujuan spesifik dari rencana:
 Untuk meminimalkan gangguan pada operasi normal bisnis XXX.
 Untuk membatasi tingkat gangguan dan kerusakan.
 Memberikan respons yang cepat dan tepat untuk setiap kejadian yang
tak direncanakan, sehingga mengurangi dampak yang dihasilkan dari
gangguan usaha jangka pendek
 Validasi dokumentasi dan proses termasuk proses pemulihan
(recovery), solusi penggunaan, pembangunan kembali server, daftar
sumber daya dan telepon
 Untuk meminimalkan dampak ekonomi dari gangguan tersebut.
 Untuk menetapkan langkah operasi alternatif di awal.
 Untuk melatih personel dengan prosedur darurat.
 Untuk menyediakan pemulihan layanan yang cepat dan lancar.
 Untuk mengurangi kebingungan selama periode kacau dengan
menetapkan program aksi yang jelas, dan dengan demikian
menyediakan pemulihan tertib dan tepat waktu dari gangguan utama
layanan pengolahan data
 Memberikan jaminan bahwa penggalian ruang lingkup & hasil Disaster
Recovery memenuhi persyaratan Kebijakan dan Pedoman Business
Continuity, persyaratan peraturan lokal, serta audit internal dan
eksternal dan persyaratan kepatuhan
1.2 Ruang Lingkup
1.2.1 Ruang Lingkup Skenario Bencana
Skenario Disaster Recovery yang terdiri dari:

1. Produksi AAA di Produksi NTT di BBB bawah, server sisanya adalah
OK
2. Produksi AAA dan itu cermin di BBB turun, server lain yang OK
3. Produksi CCC di BBB bawah, server sisanya adalah OK
4. AAA - situs Jakarta turun
1.2.2 Fungsi Dukungan Staf

Lampiran 9.5.4
Dukungan kegiatan staf didokumentasikan dalam rencana, untuk

memfasilitasi pemulihan fungsi penting dalam periode waktu tertentu.
Kegiatan dukungan berikut harus dilangsungkan sesegera mungkin setelah
bencana potensial terjadi:
 Komunikasi kepada karyawan
 Dukungan manajemen risiko / asuransi
 Dukungan administrasi pada upaya pemulihan
 Saran hukum dan peraturan
 Dukungan Sumber Daya Manusia
 Percepatan pembelian item pemulihan / pengganti
 Keamanan di lokasi yang terkena dampak
1.3 Otorisasi
Keputusan pernyataan bencana akan diambil oleh CEO (Chief Executive

Officer) setelah berdiskusi dengan Tim ZZZ.
Anggota Tim ZZZ adalah CEO dan Tim Manajemen Senior. Manajer IT - DR
mendapatkan informasi yang diperlukan dari tim tanggap darurat, terkait
dengan Infrastruktur TI yang mendukung kebutuhan Bisnis.
Business Continuity Manager akan mengkoordinasikan semua pemulihan TI
dan bisnis dan kembali ke lokasi utama. Khusus untuk proses Pemulihan IT
akan dikoordinasikan di bawah Manajer DR dan dia akan melaporkan kepada
Manajer Business Continuity. Rencana ini berisi semua informasi yang
diperlukan untuk mengembalikan dan memulihkan sistem yang mendukung
misi kegiatan penting dalam sasaran Recovery Time yang disetujui, yang
didefinisikan dalam dokumen Business Continuity Strategy.
1.4 Asumsi
Semua rencana pemulihan berisi asumsi tentang ketersediaan sistem dan

peralatan yang dibutuhkan untuk melaksanakan rencana. Tinjauan rutin
terhadap asumsi ini diperlukan untuk memastikan bahwa tidak ada hambatan
terhadap kesuksesan pelaksanaan rencana. Menurut prinsip ini, asumsi berikut
ini digunakan dalam melakukan IT Disaster Recovery Plan:
Lampiran 9.5.4
 Personil TI kunci dapat dihubungi saat bencana terjadi untuk memulai IT

DRP dan terlatih dalam peran respon dan pemulihan kondisi darurat
sehingga mereka tersedia untuk mengaktifkan IT DRP.
 Pemulihan didasarkan pada prioritas sebagaimana ditetapkan dalam
tujuan waktu pemulihan (Recovery Time Objective), dan terbatas pada
melanjutkan kembali sistem yang mendukung kegiatan misi kritis;
dengan tingkat yang dapat diterima degradasi layanan dan / atau
operasi tertunda, mengingat tenaga kerja berkurang, peralatan terbatas
dll
 Rencana akan ditinjau tiap setengah tahun sekali dan dilaksanakan
setiap 12 bulan, dibuktikan melalui sign-off, sesuai dengan persyaratan
kebijakan AAA
 Peralatan pusat komputer, termasuk komponen pendukung DC,
terhubung ke uninterruptible power supply (UPS) yang menyediakan
listrik selama 15 menit pada saat kegagalan daya
 Backup aplikasi perangkat lunak dan data yang ada adalah lengkap, dan
tersedia di fasilitas XXX Offsite Storage dan BBB Singapura, dan
mereka akan siap di DR Site tidak kurang dari 15 menit.
 Peralatan, koneksi, dan kemampuan yang diperlukan untuk
mengoperasikan sistem inti tersedia di lokasi CCC dan fasilitas DDD
 Perjanjian layanan dipelihara terhadap hardware Inti Sistem, perangkat
lunak, dan penyedia komunikasi dan vendor untuk mendukung
pemulihan sistem darurat
1.5 xStruktur Dokumen dan Distribusi
Dokumen ini dirancang untuk menuntun pembaca melalui proses yang ada
pada program perencanaan pemulihan bencana TI. Rencana pemulihan teknis
akan berfungsi sebagai Prosedur untuk melaksanakan strategi saat terjadi
gangguan
Bab 1, Pendahuluan, memberikan informasi gambaran dan latar belakang

tentang perencanaan pemulihan bencana, termasuk tujuan dan ruang lingkup
rencana pemulihan bencana, otorisasi dan asumsi rencana pemulihan
bencana, dan struktur dokumen dan distribusi, dan gambaran fasilitas lokasi
pemulihan.
Bab 2, Pemulihan Tim, bagian ini membahas organisasi tim pemulihan dan
peran dan tanggung jawab yang umum ditugaskan kepada personil tim.
Lampiran 9.5.4
Bab 3, Recovery Centre Bencana, Bagian ini menjelaskan tentang lokasi

Disaster Recovery Centre termasuk contact person.
Bab 4, Menanggapi Segera Situasi Darurat, Bagian ini menjelaskan tindakan

yang akan diambil pada saat Manajer DR atau yang ditunjuknya mendapatkan
informasi bahwa situasi darurat di IT Dept mungkin ada, meliputi:
 Penerimaan Notifikasi Bencana
 Pengaktifkan Tim IT DRP
 Penilaian Kerusakan
 Bencana Verifikasi Prosedur
 Deklarasi Bencana
 Pertemuan di Command Centre
 Keputusan Aktivasi
 Pengaktifan The Disaster Recovery Centre
Bab 5, Kembali ke Situs Utama, menjelaskan penghentian rencana

pemulihan bencana, dan kembali dari sistem TI untuk operasi normal.
Bab 6, Prosedur Backup, Bagian ini berisi Kebijakan dan Prosedur backup
untuk aplikasi kritikal.
Bab 7, Pemulihan Anggota Tim, Bagian ini berisi daftar Kontak Pribadi
Pemulihan Anggota Tim, dan bagian ini harus ditinjau setidaknya dua kali
dalam setahun secara berkala.
Bab 8, Pengujian Disaster Recovery dan Prosedur Pemeliharaan, Bagian

ini berisi Kebijakan dan Prosedur bagaimana menguji IT DRP secara bertahap
berdasarkan kompleksitas sistem dan aplikasi. Prosedur Pemeliharaan terdiri
dari Kebijakan dan Prosedur bagaimana mempertahankan IT DRP berkala,
sehingga harus tetap up to date.
Distribusi Panduan
Disaster Recovery Manager bertanggung jawab untuk mendistribusikan
rencana ini. Setiap pemegang rencana, yang tercantum dalam tabel di bawah
ini, menerima satu salinan dari rencana ini. Satu salinan harus disimpan di XXX
Site - Indonesia dan salinan lainnya di DR Site BBB.
Lampiran 9.5.4
Nama Peran Fungsional Lokasi
1.6 Pembaruan Rencana

Manajer IT DRP bertanggung jawab untuk memperbarui rencana dan
memastikan bahwa rencana keseluruhan up-to-date. Pembaruan akan
dilakukan pada versi MS Word di Disaster Recovery Plan, yang disimpan dalam
folder terbatas, pada direktori yang dibagi bersama.
Setiap Sistem dan anggota Tim Telekomunikasi harus menjaga agar dokumen
pemulihan, dan pengembalian ke lokasi Primer adalah bagian dari IT DRP.
Pada saat terjadi bencana atau Pengujian DR, anggota tim pemulihan cukup
mengikuti petunjuk pemulihan berdasarkan dokumen pemulihan.
1.7 Recovery Site Facilities
Strategi umum PLA untuk pemulihan aplikasi kritikal adalah pemeliharaan hot
site dengan peralatan dan fasilitas yang diperlukan untuk mengoperasikan
aplikasi, untuk jumlah minimum pengguna yang membutuhkan akses dalam
situasi bencana.
Lokasi pemulihan bencana XXX terletak di AAA.
Pada AAA, listrik disuplai dari jaringan listrik khusus AAA melalui sistem UPS.
UPS menyediakan listrik 2 x 30 KVA (shared) dengan sumber energi bersih
dan dapat diandalkan (Clean and Reliable Energy) ke peralatan di lokasi
pemulihan (recovery site) dan memiliki kapasitas baterai untuk menjaga
peralatan server dalam ruangan tetap online selama beberapa menit setelah
listrik mati. Untuk mengakomodasi gangguan listrik dalam jangka waktu
berapapun, generator diesel dengan auto start switch telah dipasang. Unit ini
secara otomatis akan mulai dalam beberapa detik saat terjadi kegagalan daya
(power failures). Ini akan memberikan daya untuk ruangan, termasuk lampu
dan sistem pendingin udara, sampai daya penuh (full power) dipulihkan. Gen
Set aktif disediakan jika gangguan listrik terjadi melebihi kapasitas UPS.
Kapasitas maksimum Active Gen set 100 KVA (shared) dan dapat menangani
beban maksimum 8 Jam non stop. Kapasitas tangki bahan bakarnya 1000L.
Lampiran 9.5.4
Fasilitas ini dimaksudkan untuk mengakomodasi peralatan komputasi dan

komunikasi yang dibutuhkan untuk melayani area lokasi DR dan berisi server
cadangan untuk aplikasi dan data kritikal.
Dedicated Command Centre (CC) berada di Hotel atau tempat yang dapat
dicapai sesegera mungkin tanpa dipengaruhi oleh bencana DC. Semua proses
pemulihan, harus dilakukan dan dipimpin dari Command Centre.
Lampiran 9.5.4
2. Tim Pemulihan
2.1 Tanggungjawab Tim
Business Continuity Manager

 Bertindak sebagai orang pertama yang dihubungi untuk semua laporan
insiden yang berpotensi meningkat menjadi Bencana
 Bertindak sebagai titik komunikasi antara tim IT-DRP dengan pengguna
Bisnis
 Mengkoordinasikan semua kordinator Business Continuity yang terkait
dengan proses pemulihan bisnis
 Pembaruan Unit Bisnis untuk memastikan kesadaran mereka terhadap
proses dan prosedur IT-DRP
 Memberikan masukan dan permintaan kepada tim IT-DRP dari
perspektif Unit Bisnis
Manajer IT – DR
bertanggung jawab untuk mengarahkan semua operasi pemulihan, yang
meliputi:
 Menyajikan Komite Eksekutif BCM pembaruan (update) yang diperlukan
tentang situasi dan rekomendasi untuk keputusan penting
 Memastikan bahwa IT-DRP terus up-to-date
 Merencanakan kegiatan pemeliharaan, pengujian dan pelatihan tim IT-
DRP secara periodik
 Mengawasi pembangunan kembali lokasi utama (primary site) dan
memberikan rekomendasi pengembalian ke lokasi utama
 Menyusun laporan pasca-evaluasi setelah peristiwa krisis
 Memastikan semua sumber daya dan dukungan, untuk pelatihan yang
tepat dan pemeliharaan IT DRP, dilakukan secara berkala
 Manajemen Pasca pemulihan. Setelah lokasi pemulihan beroperasi,
pertimbangkan hal berikut:
 Berapa lama pengolahan TI berjalan terus di lokasi pemulihan?
 Dapatkah fasilitas IT di lokasi Plant dipulihkan atau apakah
diperlukan untuk mencari / membangun fasilitas baru?
 Apa peralatan rusak yang bisa diperbaiki? Seberapa cepat?
 Apa peralatan rusak yang harus diganti? Seberapa cepat?
 Apakah kontraktor diperlukan untuk membantu dalam pemulihan?
Lampiran 9.5.4
Kordinator IT – DR
bertanggung jawab untuk mengkoordinasikan semua operasi pemulihan, yang
meliputi:
 Melakukan penilaian kerusakan awal dengan Tim Assessment
Kerusakan
 Menyajikan IT - DR Manajer pembaruan (update) yang diperlukan
tentang situasi dan rekomendasi untuk keputusan penting
 Mengelola proses pemulihan secara keseluruhan dan tim Pemulihan
sistem dalam tingkat teknis
 Memperbarui Rencana IT-DRP
 Menyusun laporan pasca-evaluasi setelah peristiwa krisis
 Manajemen Pasca pemulihan. Setelah lokasi pemulihan beroperasi,
pertimbangkan hal berikut:
 Berapa lama pengolahan TI berjalan terus di lokasi pemulihan?
 Dapatkah fasilitas IT di lokasi Plant dipulihkan atau apakah
diperlukan untuk mencari / membangun fasilitas baru?
 Apa peralatan rusak yang bisa diperbaiki? Seberapa cepat?
 Apa peralatan rusak yang harus diganti? Seberapa cepat?
 Apakah kontraktor diperlukan untuk membantu dalam pemulihan?
Tim Recovery Infrastruktur

 Lakukan langkah-langkah teknis yang diperlukan untuk pemulihan
sistem
 Pastikan kebenaran pemulihan dan keamanan data
 Memantau sistem ditugaskan untuk memastikan stabilitas selama
periode pemulihan seluruh
 Memberikan permasalahan teknis untuk pengguna bisnis dan membuat
laporan pada semua kelainan
 Lakukan prosedur yang diperlukan untuk kembali ke situs utama
 Berpartisipasi dalam pelatihan berkala dan IT-DRP pengujian
 Update porsi yang sesuai dari IT-DRP sesuai dengan rencana
perawatan
Tim Recovery AAA

 Mengembangkan checklist pengujian untuk Aplikasi AAA
 Membantu pengguna sistem untuk melakukan pengujian aplikasi
menggunakan checklist pengujian standar
Lampiran 9.5.4
 Konsolidasi hasil pengujian

 Berpartisipasi dalam pelatihan berkala dan pengujian IT-DRP
 Pembaruan bagian yang sesuai dari IT-DRP sesuai dengan rencana
perawatan
Aplikasi Lokal / Non AAA Team

 Mengembangkan checklist pengujian untuk Aplikasi non AAA
 Membantu pengguna sistem untuk melakukan pengujian aplikasi
menggunakan checklist pengujian standar
 Konsolidasi hasil pengujian
 Berpartisipasi dalam pelatihan berkala dan pengujian IT-DRP
 Pembaruan bagian yang sesuai dari IT-DRP sesuai dengan rencana
perawatan
Lampiran 9.5.4
2.2 DR Team Organization Chart
{Nama Perusahaan Ini} IT DR Team Personnel and Contact

BC Manager
(P)
(A)
IT DR Manager
(P)
(A)
IT DR Coordinator
(P)
(A)
Local Application Recovery

Infrastructure Recovery Team XXX Recovery Team
Team
Leader : Leader :
Leader :
System and Network Member

Member
(P) (P)
(P)
(A) (A)
(A)
(A)
Data Centre (A)
(P)
(A)
Distributed Computing
(P)
(A)
Lampiran 9.5.4
2.3 Anggota Tim Recovery
Personil dan Kontak Tim IT DR XXX

Nomor Telepon
Tanggung Jawab Nama
HP Rumah
Manajer BC
alternate
Manajer IT – DR
alternate
Kordinator IT – DR
alternate
Tim Recovery Infrastruktur
Pimpinan
Sistem dan Jaringan
Data Centre
Service Desk
Tim Recovery XXX

Pimpinan
Anggota
Tim Aplikasi Lokal

Pimpinan
Anggota
Lampiran 9.5.4
2.4 Representasi Diagram Strategi
Disaster
BC Manager upon instruction

from IM (Gold) member to
invoke BC plan
Notify IT DR Manager
Activate Call Tree Perform Initial Damage

Notify BCP Assesment
Meet at Comand Centre

(IT DR Activation)
Notify Critical Vendor Obtain Critical Inventory and

Notify Business Users Notify and Activate DR site
Documentation
Establish Network Connection

Commence System Restoration
Application Testing
BC Manager approval for

Release
System Release for Production
Monitor Progress
Preparation for Return to

Primary Site
3. Disaster Recovery Centre

Disaster Recovery Centre (DRC) XXX dilengkapi dengan sistem dan server yang
diperlukan, yang akan diaktifkan saat aktivasi IT-DRP. Lokasi Disaster Recovery XXX
terletak di:
Lampiran 9.5.4
DR SITE
Alamat :
Nama Kontak :
Email :
Office :
HP :
Fax :
COMMAND CENTRE XXX - INDONESIA

Alamat :
Telepon :
Fax :
Customer Line :
Customer Fax :
4. Immediate Response To Emergency Situation
Bagian ini menjelaskan tindakan yang akan diambil pada saat DR Manager
diinformasikan bahwa situasi darurat di IT Dept mungkin ada. Ini mencakup:
 Menerima Pemberitahuan Bencana
 Aktifasi Tim IT - DR
 Penilaian Kerusakan Awal
 Form Prosedur Verifikasi Bencana
 Deklarasi Bencana
 Bertemu di Command Centre
 Keputusan Aktivasi
 Aktivasi Disaster Recovery Centre
4.1 Menerima Pemberitahuan Bencana
Tanggung Jawab: BC Manager

 Operator Komputer bertugas di Lokasi Pabrik atau Departemen TI
bertanggung jawab untuk menginformasikan BC Manager pada saat situasi
Lampiran 9.5.4
darurat. Ada kemungkinan bahwa pemberitahuan mungkin berasal dari

sumber lain (misalnya Keamanan).
 Jika Bencana terjadi, berkaitan dengan Data Center atau Sistem TI,
Manajer BC akan menginformasikan Manajer IT - DR, dan Manajer DR
akan mengevaluasi situasi, berdasarkan informasi yang diterima.
 Manajer IT - DR akan menginformasikan Manajer BC atau Tim Manajemen
Krisis tentang situasi. Setiap perubahan situasi akan dilaporkan ke Dewan
Pemulihan Bisnis
 Semua laporan pada situasi bencana dimana berpotensi meningkat menjadi
Bencana akan dilaporkan kepada personil berikut:
Primary BC Manager
Nama :
HP :
Rumah :
Alternate BC Manager
Nama :
HP :
Rumah :
4.2 Aktivasi Tim IT – DR
Setelah menerima setiap laporan mengenai situasi dan skenario bencana

potensial, Manajer BC akan mengaktifkan call tree untuk memanggil semua
anggota Tim IT-DR dan Tim BU-DR ke pusat komando yang ditunjuk. Mengacu
pada Appendix E: for Call Tree
4.3 Penilaian Kerusakan Awal
Setelah menerima setiap laporan mengenai situasi dan skenario bencana

potensial, Manajer IT-DR akan melakukan penilaian awal terhadap tingkat
parahnya kerusakan (severity of damage) terhadap pusat produksi TI.
Penilaian harus mencakup:
 Parahnya kerusakan (severity of damage) pada data center dan server
 Aplikasi/Sistem yang terpengaruh
Lampiran 9.5.4
 Perkiraan waktu yang dibutuhkan untuk pemulihan server produksi, jika

dimungkinkan
 Masalah penting lainnya
Setelah penilaian kerusakan awal selesai, Manajer IT - DR akan melaporkan

kepada Tim Manajemen Krisis yang ada di Command Centre. Laporan
Penilaian Kerusakan awal akan membantu tim DR-TI menentukan tindakan
pemulihan yang akan diambil. Tim akan menggunakan Prosedur Verifikasi
Bencana (Appendix R).
4.4 Pertemuan di Disaster Recovery Centre
Manajer BC dan Manajer IT - DR bersama dengan anggota Tim Manajemen

Krisis akan melakukan pertemuan di Command Centre untuk menilai laporan
kerusakan yang disiapkan oleh Manajer TI - DR yang bertanggung jawab untuk
melakukan penilaian kerusakan dari premis utama dan untuk membuat
keputusan aktivasi.
Command Centre adalah fasilitas pertemuan di mana peralatan dan
perlengkapan yang tepat akan tersedia untuk memberikan dukungan
administratif, operasional dan logistik yang diperlukan untuk {Nama
Perusahaan Ini}. Lokasi Command Centre adalah di DRC (atau di suatu tempat
antara DC dan DRC yang aman dari dampak bencana di DC).
4.5 Keputusan Aktivasi
Tim Manajemen Krisis akan meninjau hasil Penilaian Kerusakan Awal. Karena
diminta RTO yang relatif singkat, Tim Manajemen Krisis harus memutuskan
aktivasi IT-DRP dalam waktu yang tidak kurang dari 30 menit setelah terjadinya
pemadaman Data Centre primer.
Penilaian Kerusakan akan menyediakan evaluasi awal yang cepat dari
kerusakan dan aksesibilitas kepada Pemimpin Tim Disaster Recovery;
a) Penilaian akan memperkirakan waktu perbaikan atau pembangunan
kembali di lokasi yang rusak;
Lampiran 9.5.4
b) Tim Disaster Recovery akan menentukan kondisi yang tepat untuk

mengaktivasi rencana berdasarkan tingkat keparahan (severity) dari
situasi; dan
c) Manajer TI - DR dapat membuat rekomendasi kepada Pelaksana
Pemulihan Bencana apakah akan mengaktifkan rencana berdasarkan
jenis bencana.
d) Ketika menentukan aktivasi, ada beberapa kriteria yang harus diambil
sebagai bahan pertimbangan:
Severity of Disaster & damage:

Bencana besar (major disaster) adalah setiap gangguan yang mengakibatkan
lokasi utama (main site) menjadi tidak tersedia dan mendorong keputusan
untuk pergi ke lokasi pemulihan off-site.
Sebaliknya, bencana kecil dianggap terjadi ketika ada perpanjangan atau

antisipasi perpanjangan pemadaman yang membuat operasi tidak tersedia
atau non-fungsional. Hal ini dapat mencakup: masalah hardware; masalah
listrik; masalah jaringan atau pemeliharaan terjadwal.
4.6 Deklarasi Bencana
Responsibility: Business Recovery Council

Kriteria berikut telah disusun untuk mengidentifikasi situasi bencana untuk
XXX:
1. Setiap pemadaman terhadap operasional komputer yang berpotensi
melebihi tingkat kritis pada fungsi bisnis penting, digariskan dalam
rencana ini. Pemadaman mungkin disebabkan oleh hilangnya mesin
tunggal, lantai ruang komputer, atau bangunan yang mengandung lantai
ruang komputer.
 Pemadaman listrik ke Ruang Komputer
 Kebakaran di Ruang Komputer.
 Kerusakan karena air atau asap di Ruang Komputer.
 Bencana Alam
 Sabotase
 Kegagalan mesin lebih dari RTO
Lampiran 9.5.4
2. Bencana Daerah yang berpotensi menyebabkan gangguan bisnis pada

semua lokasi setempat dan ruang komputer.
 Ruang komputer dapat tidak perlu beroperasi karena peniadaan
bisnis yang didukungnya.
 Penilaian rinci oleh manajemen eksekutif terhadap situasi,
diperlukan sebelum menentukan tingkat pemulihan Teknologi
yang akan diterapkan.
3. Segera setelah bencana dinyatakan, dana pra-otorisasi akan

didapatkan oleh Business Recovery Manager, dan rencana pemulihan
bencana penuh akan diikuti.
4. Perkiraan waktu pemadaman (estimated outage time) terhadap sasaran

waktu pemulihan (recovery time objective):
 Jika waktu estimasi pemadaman melebihi Recovery Time
Objective, tim IT-DRP harus serius mempertimbangkan aktivasi
IT-DRP.
Definisi RTO (Recovery Time Objectives):

Waktu yang dibutuhkan aplikasi untuk mulai setelah deklarasi bencana dan
siap digunakan pengguna untuk melanjutkan transaksi bisnis.
Jika rencana ini diaktifkan, kemudian dimulai proses pemulihan dari Langkah
4.6; jika tidak, maka tidak ada tindakan lebih lanjut.
Business Criticality: Mission Critical, RTO:

Mengacu pada Appendix G: Critical Applications
4.7 Aktivasi Disaster Recovery Centre
4.7.1 Prosedur Aktivasi DR Centre
Manajer IT - DR akan memulai proses pemulihan dengan mengaktifkan

DRC. Prosedur aktivasi DRC ada di Appendix N: DRC Activation
Procedure
4.7.2 Notifikasi Tim IT – DR

Lampiran 9.5.4
Notifikasi semua anggota staf tentang situasi yang ada. Jika tidak dapat
menjangkau beberapa individu, minta anggota staf lain untuk
menghubunginya. Setelah dihubungi, mereka harus menelpon Command
Centre untuk mengabari. Jika tidak dapat dihubungi, beberapa peran dan
tanggung jawab perlu kembali ditunjuk pada anggota lain. Anggota staf
disarankan untuk tetap di rumah atau setidaknya dapat dihubungi sampai
ada pemberitahuan lebih lanjut.
4.8 Aktivasi Disaster Recovery Site
Tanggung Jawab: Tim Pemulihan Operasional dan Fasilitas

 Memastikan bahwa Admin DRC di XXX terbuka dan siap menerima tim
pemulihan lainnya.
 Memastikan bahwa backup yang menjadi tanggung jawab tim
Operasional tersedia untuk tim pemulihan lainnya jika diminta oleh
manajer tim pemulihan.
Tanggung Jawab: Tim Pemulihan Infrastruktur, Aplikasi Kritikal, Aplikasi

Penting, dan
Aplikasi Reguler
 Memastikan bahwa backup yang menjadi tanggung jawab tim
Operasional tersedia untuk tim pemulihan lainnya jika diminta oleh
manajer tim pemulihan.
Tanggung Jawab: Tim Pemulihan Desktop

 Memastikan bahwa komputer desktop (yang telah dikonfigurasi) untuk
digunakan tim pemulihan tersedia dalam jumlah yang tepat. Sebagai
kontingensi, mungkin diperlukan untuk meminjam komputer dari
departemen lain.
Tanggung Jawab: Tim Administrasi

 Memastikan bahwa lokasi pemulihan aman. Mintakan sumberdaya dari
keamanan jika diperlukan.
4.8.1 Tetapkan Sumberdaya yang Diperlukan pada DRC

Lampiran 9.5.4
Manajer IT - DR harus memeriksa bahan dan dokumen yang diterima pada

daftar penyimpanan Off-site untuk memastikan semua bahan diterima.
Tanggung Jawab dari: Tim Pemulihan Telekomunikasi, Infrastruktur,

Aplikasi Kritikal, Aplikasi Penting, Aplikasi Reguler, Desktop, Aplikasi
Bisnis, serta Operasional dan Fasilitas
 Masing-masing tim di atas akan menjaga duplikat pasokan peralatan

penting dalam penyimpanan di vendor (penyimpanan Offsite) yaitu PT
XXX.
 Peralatan ini mencakup perangkat keras, perangkat lunak, suku cadang
kritis, alat, rincian konfigurasi, manual, dokumentasi, dll.
Informasikan Pemimpin Tim jika Dokumen Vital Hilang
Jika ada barang penting yang hilang, anggota tim Off-site yang berwenang
harus segera mencari bantuan dari Pemimpin Tim mereka.
4.8.2 Notifikasi Vendor Penting
Koordinator Vendor akan memberikan notifikasi kepada vendor penting yang

mendukung proses pemulihan keseluruhan IT-DRP. Koordinator vendor akan
memantau layanan yang disediakan oleh vendor pemulihan dan akan menjadi
titik penghubung antara vendor tersebut dan {Nama Perusahaan Ini}. Daftar
lengkap vendor penting terletak di Appendix O
4.8.3 Notifikasi Pengguna dan Cabang Bisnis
Manajer BC akan bertanggung jawab untuk menghubungi pengguna dan

cabang bisnis pada saat pemulihan IT-DRP. Rincian proses notifikasi akan
didokumentasikan dalam Business Continuity Plan.
Lampiran 9.5.4
Pengguna bisnis juga harus diinstruksikan untuk meninjau apakah data yang
ada akurat dan telah diperbarui. Pengolahan backlog dan sinkronisasi data
harus dilakukan untuk memastikan integritas data.
4.8.4 Membuat Rencana Perjalanan (Jika Diperlukan)
Tanggung Jawab: Tim Operasional

 Rencana harus dibuat untuk mengirimkan tim pemulihan ke DRC PT
XXX pada YYY
 Memastikan semua backup tape yang penting dan diperlukan dari PT
XXX pada YYY telah tiba di DRC1 PT XXX pada YYY dengan aman dan
tepat waktu, tak lebih dari {... jam}
 Tim Operasional bertanggung jawab untuk menyediakan transportasi ke
DRC, membuat reservasi hotel, memastikan bahwa anggota tim
memiliki dokumen perjalanan yang tepat dan uang tunai yang memadai.
 Mungkin diperlukan untuk memindahkan peralatan. Jika demikian,
pengaturan harus dibuat untuk pengepakan dan pengiriman.
4.8.5 Memulai Restorasi Sistem
Manajer TI - DR akan memberikan penjelasan singkat mengenai tim pemulihan

sistem dan jaringan pada rencana DR yang diputuskan oleh masing-masing
Pimpinan Teknis. Setiap anggota tim pemulihan sistem & jaringan masing-
masing akan mengikuti instruksi manajer IT - DR dan melakukan proses
pemulihan berdasarkan prosedur pemulihan
4.8.6 Prosedur Restorasi untuk Sistem, Aplikasi dan Database
Tim Aplikasi dan Operasi akan lanjut untuk memulihkan sistem TI berdasarkan
lampiran prosedur pemulihan untuk semua sistem dan aplikasi
4.8.7 Membangun Jaringan Komunikasi
Pastikan bahwa semua komunikasi data dan jaringan benar-benar terpasang

dan siap untuk pembangunan kembali (reestablishment).
Lampiran 9.5.4
Tim Pemulihan Jaringan akan bekerja dengan Koordinator vendor & penyedia
telekomunikasi untuk memulihkan jaringan untuk pengguna bisnis & cabang
untuk terhubung kembali, pada DRC.
Setelah Jaringan komunikasi di DRC siap, Tim Jaringan akan mencoba

membangun hubungan komunikasi ke pihak eksternal PT XXX dan penyedia
telekomunikasi.
4.8.8 Pengujian Aplikasi
Setelah semua tim pemulihan sistem/jaringan telah menyelesaikan pemulihan

pada sistem/jaringan yang menjadi tanggungjawabnya, masing-masing
anggota tim pemulihan harus menguji kebenaran dan keamanan sistem yang
mereka pulihkan.
4.8.9 Pemantauan Proses Pemulihan
Manajer IT - DR akan secara konsisten mencatatkan kegiatan dalam Log

Proses Pemulihan. Log proses pemulihan tersedia dalam Appendix M.
Log ini memberikan informasi penting tentang perkembangan pemulihan pada

Tim Manajemen Krisis / Manajemen Senior. Log ini juga berharga ketika
Manajer IT - DR perlu menganalisa dan melacak kemajuan pemulihan.
5. Pengembalian Ke Lokasi Utama
5.1 Pengalihan Kembali Ke Lokasi Utama

Perbaikan atau pembangunan kembali lokasi utama harus dimulai segera
setelah pengelola bangunan dan keamanan sipil mengizinkannya. Dalam
kasus di mana tidak mungkin untuk menggunakan kembali lokasi utama, lokasi
alternatif lain harus disiapkan.
Beberapa hal yang perlu dilakukan sebelum kembali ke lokasi utama adalah:
a. Meninjau dan merencanakan konfigurasi peralatan di lokasi utama;

Lampiran 9.5.4
b. Membantu dalam pemasangan peralatan dan perangkat lunak di lokasi

utama;
c. Membangun kembali lingkungan operasional;
d. Menjamin ketersediaan pasokan yang diperlukan, misalnya, form
persediaan, scratch tape, form printer dan dll.;
e. Memverifikasi bahwa prosedur backup dan restore ada pada tempatnya;
f. Memverifikasi bahwa rotasi off-site mencakup semua file data yang
diperlukan;
g. Memutuskan kapan dan bagaimana mengakhiri proses pada backup site;
h. Backup semua database produksi dan file pendukung yang diperlukan; dan
i. Memindahkan file ke lokasi utama.
Manajer IT - DR akan meninjau kebutuhan dan jadwal pemrosesan untuk

mengidentifikasi waktu terbaik untuk kembali ke lokasi utama. Dia akan
mengembangkan jadwal dan memperoleh persetujuan dari Tim Manajemen
Krisis / manajemen senior
5.2 Mual Ulang Aplikasi dan Database pada Lokasi Utama

Tim pemulihan sistem/jaringan akan membantu dalam menyusun pemulihan
semua file dan database yang dibutuhkan.
5.3 Mendistribusikan Jadwal Pelaksanaan dan Dokumen Lainnya untuk

Lokasi Utama
Manajer BC akan meninjau Jadwal Pelaksanan dan bahan pendukungnya; dan
mempertimbangkan kontrol pekerjaan, media, slot waktu, jadwal dan masukan.
Jadwal Pelaksanaan dari SOP PT XXX (dari hari sebelum terjadinya bencana)
dapat digunakan kembali.
Manajer BC akan menjadwalkan pertemuan staf. Pertemuan ini adalah untuk

menjelaskan secara singkat kepada staf mengenai status pemrosesan dan
memberikan petunjuk lebih lanjut. Staf harus kembali diyakinkan bahwa
operasional komputer akan berjalan seperti biasa mulai dari sekarang dan
seterusnya.
5.4 Memulai Operasional semua Sistem pada Lokasi Utama

Tim pemulihan sistem/jaringan akan melalui Checklist Pengujian Aplikasi
(Lampiran G) untuk memastikan kompatibilitas dari sistem dan sistem aplikasi
Lampiran 9.5.4
sebelum sistem diserahkan kepada Pengguna Bisnis. Hal ini dilakukan untuk
memastikan bahwa sistem yang telah dipulihkan beroperasi secara penuh.
Pemeriksaan menyeluruh diperlukan untuk menghasilkan

konfirmasi/pengesahan. Konfirmasi/pengesahan ini diperlukan untuk
memastikan bahwa seluruh sistem siap dan beroperasi sebelum dinyatakan
seperti itu.
Sistem non-kritikal lainnya harus diperiksa dan juga dikonfirmasi kesiapannya

untuk produksi. Catatan kendali (control log) dan jejak audit (audit trail) harus
dibentuk. Produksi normal dapat berjalan dari sini.
Lampiran 9.5.4
6. Pemulihan Sistem Aplikasi dan Prosedur Backup
6.1 Pemulihan Sistem Aplikasi

Bagian ini menjelaskan pemulihan sistem aplikasi yang digunakan dalam
lingkungan produksi. Daftar aplikasi penting mengacu pada Appendix G:
Critical Applications.
Setiap aplikasi penting memiliki prosedur pemulihan sendiri yang mengacu

pada Appendix P: XXX Application System Form
6.2 Kebijakan Backup and Retensi Backup

Bagian ini menjelaskan metode backup yang digunakan dalam lingkungan
produksi untuk menyajikan kemampuan pemulihan data pada saat pengujian
pemulihan bencana dan bencana.
 XXX
 Backup Tahunan
 Backup Akhir Bulan
 Backup sebelum batch job
 Backup sebelum pelaksanaan
 Backup setelah pelaksanaan
 Backup Pertengahan Bulan
 Backup sebelum pelaksanaan
 Backup setelah pelaksanaan
 Backup Harian
 Backup sesudah batch job
 Backup Khusus
 Backup selesai jika diperlukan untuk tujuan tertentu
Lampiran 9.5.4
 YYY
 Dijadwalkan berdasarkan replikasi harian
 File dan Sistem Database

 Backup harian
 Backup terjadwal oleh ZZZ
6.3 Backup Procedure
 Salinan backup informasi penting dalam jumlah yang cukup, perangkat

lunak dan dokumentasi hardcopy terkait (untuk sistem dan pengguna)
tersedia. Salinan atas harus tersedia pada off-site premis atau back-up
situs
 backup sistem penuh (full system backup) harus dilakukan secara berkala
 Versi terbaru dari perangkat lunak sistem operasi, program produksi,
utilitas sistem dan semua file induk harus dipantau secara ketat
 Semua media backup harus diberi label dengan benar menggunakan
konvensi penamaan standar
 Semua media backup harus diuji secara teratur, bila memungkinkan, untuk
memastikan bahwa mereka dapat dipulihkan bila diperlukan
 Media backup juga harus disimpan off-site dalam lingkungan yang aman
dan akses yang terkendali
 Transportasi ke lokasi backup harus dilakukan secara terkendali dan aman
dengan otorisasi dan pencatatan yang tepat. Prosedur untuk pembuangan
media backup juga ada pada tempatnya
6.4 Lokasi Penyimpanan Backup Offline
PT. ZZZ
Alamat :
Telepon :
Fax :
Nama Kontak :
Email :
Lampiran 9.5.4
7. Pengujian Pemulihan Bencana dan Pemeliharaan IT-DRP
Pengujian Pemulihan Bencana adalah simulasi untuk memastikan keberhasilan

pemulihan Data Center setelah bencana. Karena kebutuhan produksi yang sangat
besar, pengujian pemulihan bencana dibagi kriterianya dalam beberapa fase dan
mengujinya satu per satu. Pengujian pemulihan bencana secara keseluruhan
kemudian dapat dilakukan untuk mensimulasikan pemrosesan data centre secara
lengkap.
Berbagai metodologi dan teknik dapat dilibatkan dalam pengujian pemulihan bencana,
untuk meningkatkan perencanaan pemulihan bencana. Oleh karena itu, manajer
pemulihan bencana harus bekerja sama dengan spesialis teknis dan meninjau
kebutuhan dalam dasar waktu (time basis) yang teratur.
Jadwal Pengujian Pemulihan Bencana

Pengujian Pemulihan Bencana akan dilaksanakan setiap 12 bulan, jadwalnya
harus dikoordinasikan dengan pengguna.
Prosedur Eskalasi
Eskalasi masalah diperlukan bila masalah tidak dapat diperbaiki dalam batasan
waktu perbaikan. Eskalasi berarti meningkatkan masalah dari satu tingkat
keparahan ke tingkat keparahan yang lain, seperti dari tingkat keparahan 3 ke
2, untuk mendedikasikan sumber daya baru atau tambahan untuk masalah.
7.2.1 Keparahan Masalah (Problem Severity)

Tipe Tingkat
Definisi Contoh
Severity Severity
Pengujian  Kegagalan konektivitas

pengguna kritis jaringan untuk beroperasi di
High 1 tidak dapat DR Site.
diselesaikan karena  Aplikasi tertentu tidak dapat
masalah berfungsi secara total
 Konektivitas jaringan ke
Pengujian
salah satu pengguna gagal,
fungsionalitas tapi jaringan lainnya OK.
Medium 2 pengguna vital
terkena dampak  Beberapa fungsi dalam
secara parsial aplikasi tertentu tidak dapat
dilaksanakan.
Lampiran 9.5.4
Tipe Tingkat
Definisi Contoh
Severity Severity
Pengujian
 Beberapa fungsi non-kritis
fungsionalitas non-
Low 3 dalam aplikasi tertentu tidak
vital tidak dapat
dapat dilaksanakan.
diselesaikan
Tipe Tingkat Dukungan untuk

Diperbaiki dalam
Severity Severity Merespon dalam
High 1 30 menit 2 jam
Medium 2 60 menit 3 jam
Low 3 120 menit Akhir pengujian
7.2.2 Prosedur
 Masalah dilaporkan pada Pimpinan Tim Pemulihan terkait
(Jaringan, Operasi, Manajemen Aplikasi, Service Desk), oleh
pengguna dan tercatat pada lembar laporan masalah pemulihan
bencana dengan saran jenis keparahan.
 Jika jenis keparahan yang disarankan oleh pengguna tidak tepat,
pimpinan tim pemulihan terkait akan bernegosiasi dengan
pengguna untuk menetapkan jenis keparahan masalah yang
sesuai untuk masalah ini. Manajer DR menunjuk masalah pada
Pimpinan Tim Pemulihan Terkait, dengan tipe keparahan masalah
yang telah ditetapkan.
 Tim Pemulihan Terkait menanggapi masalah laporan pengguna
dalam interval waktu yang telah disepakati.
 Tim dukungan harus secara rutin mengkomunikasikan status
masalah, seperti kasus yang memerlukan perpanjangan jangka
waktu penyelesaian, kepada Pimpinan Tim Pemulihan Terkait
sehingga masalah pelaporan pengguna dapat diinformasikan
dengan sesuai.
 Masalah dapat dipindahtugaskan ke tim dukungan lainnya pada
saat yang tepat. Tim dukungan yang baru ditunjuk melaporkan
status masalah kepada Pimpinan Tim Pemulihan Terkait.
 Jika masalah tidak dapat diselesaikan dalam jangka waktu
perbaikan yang dikehendaki sesuai keparahan masalah, masalah
Lampiran 9.5.4
dinaikkan ke tingkat keparahan yang lebih tinggi. Dalam hal ini,

Manajer DR juga diinformasikan.
 Pada tingkat keparahan yang tinggi, jika masalah tidak dapat
diselesaikan dalam jangka waktu perbaikan, maka dilaporkan
kepada Manajer DR. Manajer DR akan membahas dan
memutuskan pendekatan untuk mengatasi masalah yang
dilaporkan.
 Tim dukungan mendokumentasikan resolusi masalah pada
Laporan Masalah Pemulihan Bencana dan melapor kepada
Manajer DR.
Alur Kerja Pengujian Pemulihan Bencana

Di bawah alur kerja Pemulihan Pengujian Bencana, empat fase diidentifikasi
untuk seluruh proses. Fase tersebut yaitu Pengaturan Tujuan, Persiapan,
Pengujian Pemulihan Bencana dan Pasca Bencana Pemulihan Pengujian
Evaluasi.
7.3.1 Pengaturan Tujuan

Pengaturan tujuan adalah proses pengujian pemulihan bencana untuk
membagi perencanaan pemulihan bencana secara keseluruhan ke dalam fase-
fase. Setiap fase harus layak (feasible), terjangkau dan terukur dalam
pengujian pemulihan bencana. Oleh karena itu, suatu kerangka kerja
(framework) menyeluruh dapat dibangun dan diuji untuk pemulihan. Kriteria
tujuan dapat berubah dari waktu ke waktu. Namun, tujuan harus menargetkan
pengujian pemulihan bencana secara penuh, di masa depan.
Ketika tujuan pengujian ditentukan, Disaster Recovery Manager akan

mengeluarkan pemberitahuan kepada pengguna dan Data Centre untuk
menggambarkan dengan jelas tentang tujuan pengujian dan jadwal pengujian.
Setelah tujuan tersebut selesai, rencana pengujian akan dibuat dengan

memasukkan parameter pengujian, kriteria pengukuran, grafik tugas (task
charts) dan garis waktu (time lines). Rencana ini akan digunakan untuk
memvalidasi efektivitas prosedur pemulihan dan untuk menjamin dokumen
yang terkait dengan pemulihan bencana dapat dieksekusi dan akurat.
Manfaat lain dari pengujian ini adalah untuk melatih personil yang akan
bertanggung jawab untuk melaksanakan rencana pemulihan. Hasil pengujian
dan masalah yang dihadapi, penting untuk didokumentasikan, diulas dengan
Lampiran 9.5.4
manajemen, dan digunakan untuk memperbarui prosedur saat ini dan

direncanakan dengan bantuan penggunaan dokumentasi rencana aksi.
7.3.2 Persiapan
Setelah tujuan ditetapkan, Manajer DR akan mengirimkan persyaratan kepada
vendor layanan agar mempersiapkan perangkat keras / perangkat lunak terkait.
Sementara itu, staf pelayanan teknis dan staf sistem jaringan akan
memverifikasi apakah konfigurasi dapat dipasang ke pengujian dan dilakukan
modifikasi, jika diperlukan.
Manajer DR akan membentuk kelompok kerja untuk pengujian pemulihan

bencana. Para anggota tim harus berasal dari berbagai departemen yang
berbeda dan mereka akan menyusun prosedur rinci untuk pengujian pemulihan
bencana. Disamping itu, berikut adalah pedoman yang digunakan untuk
persiapan.
Identifiksi Rencana Pengujian

 Identifikasi peserta
 Identifikasi sistem
 Identifikasi aplikasi dan data
 Identifikasi koneksi jaringan
 Identifikasi barang yang digunakan
Tujuan Pengujian
 Identifikasi hasil yang diharapkan
 Penentuan batas waktu penyelesaian tugas-tugas
Kriteria Pengukuran Pengujian
 Penentuan keberhasilan pengujian terhadap hasil yang diharapkan
 Penetapan batas waktu untuk menyelesaikan tugas-tugas
 Evaluasi waktu penyelesaian tugas
Tanggung Jawab Anggota Tim
 Pemantauan aktivitas pengujian
 Pencatatan masalah dan resolusi untuk peninjauan simulasi akhir (post
drill review)
Penentuan Hasil Pengujian (kriteria keberhasilan)
 Successful, jika semua tujuan pengujian terpenuhi sepenuhnya dan
mampu memenuhi RTO yang diharapkan, dengan tanpa atau sedikit
Lampiran 9.5.4
masalah yang dihadapi dimana dapat segera atau dalam waktu singkat
diperbaiki.
 Partially successful, jika tujuan pengujian terpenuhi sebagian dan
dijumpai masalah utama, dimana membutuhkan lebih banyak waktu dan
usaha untuk memperbaikinya, diperlukan kerja sama dengan vendor
pihak ketiga atau memerlukan keterlibatan Manajemen Senior (misalnya
membutuhkan investasi untuk meningkatkan kapasitas sistem DR).
 Fail, jika tujuan pengujian tidak terpenuhi sama sekali atau tidak dapat
dilanjutkan dengan pengujian dan diperlukan pengujian ulang. Catatan:
Untuk pengujian yang gagal, sebutkan tanggal dilaksanakannya
pengujian ulang.
Jadwal garis waktu (timeline schedules) dapat membantu untuk

mengidentifikasi urutan acara. Disamping itu, jadwal ini dapat memberikan
gambaran yang lengkap proses dan membantu orang untuk mengidentifikasi
status pengujian. Sementara itu, jadwal ini dapat berupa Form dan daftar
aktivitas untuk pemulihan bencana.
Jadwal waktu harus berisi hal berikut:

 Pengaturan Tujuan
 Konfirmasi Kebutuhan
 Jadwal Pertemuan Workgroup
 Prosedur penyelesaian jadwal
 Jadwal Backup
 Jadwal Pemindahan Tape
 Jadwal Pengujian Pemulihan Bencana
 Pertemuan dan evaluasi Pasca Pemulihan Bencana
 Laporan Pemulihan Bencana (Disaster Recovery)
 Penandatanganan (signoff) Pengguna
7.3.3 Pengujian Pemulihan Bencana

Setelah rencana pengujian dikonfirmasi, jadwal garis waktu (timeline
schedules) akan digunakan dalam pendokumentasian urutan kegiatan
pengujian pemulihan bencana. Jadwal ini akan membantu semua anggota tim
untuk memahami proses kegiatan dalam satuan jam.
Jadwal harus mencakup hal-hal berikut:

 Memulai pengujian pemulihan bencana
 Restorasi Sistem
Lampiran 9.5.4
 Pengujian Pengguna dan verifikasi

 Laporan cadangan
 Akhir pengujian pemulihan bencana
Perkiraan jam, waktu mulai dan staf dukungan harus dinyatakan dalam jadwal.
Manajer DR akan mencatat waktu aktual, dan akan digunakan untuk
memperkirakan waktu pemrosesan sebenarnya pada pengujian atau
pemulihan bencana di masa depan.
7.3.4 Proses Pengujian Disaster Recovery

 Setelah bencana diumumkan, Manajer IT-DR akan mengaktifkan Rencana
DR dengan memicu proses call tree dan kemudian pada periode waktu
yang ditetapkan semua personel yang terlibat diminta untuk berkumpul di
pusat komando untuk melanjutkan dengan prosedur pemulihan bencana.
 Setelah aktivasi Rencana DR, XXX BC Manajer harus menentukan
Command Centre yang akan diaktifkan. Kemungkinannya adalah
Command Centers ZZZ
 BC Manager XXX akan memberitahu Manajer IT-DR dan anggota Tim
Pemulihan Jaringan & Sistem untuk berkumpul di Command Centre.
 Command Centre akan diinformasikan dan semua server DR akan
dipulihkan di Data Centre ZZZ dan ZZZ dengan segera.
 Tim Operasional DC XXX yang terdiri dari Jaringan dan Sistem, Data
Centre dan Service Desk akan bertanggung jawab untuk mengambil
semua media backup yang relevan dari lokasi penyimpanan offsite dan
mengatur pengiriman ke Command Centre.
 Pimpinan Jaringan akan mengatur untuk mengarahkan DC WAN XXX
konektivitas ZZZ sesuai Rencana DR.
 Tim Pemulihan Aplikasi XXX akan memastikan versi program semua
server disinkronisasikan dengan backup tapes dan memverifikasi database
dengan melakukan pembandingan.
 Tim Pemulihan Aplikasi XXX juga akan memverifikasi semua fungsionalitas
dari server bisnis kritikal yang dipulihkan setelah restorasi.
 Manajer IT-DR akan memberitahu pengguna untuk memulai pengujian
verifikasi pengguna berdasarkan data yang dipulihkan, dan melanjutkan
semua penggunaan sistem setelah konfirmasi kesiapan server DR untuk
kelangsungan bisnis.
 Beberapa pos pengecekan akan dilakukan untuk melacak progress
simulasi. BC Manajer XXX bersama dengan Pimpinan pengguna akan
mengkoordinasikan pos pengecekan. Hal ini akan berlanjut sampai semua
Lampiran 9.5.4
pengguna mengkonfirmasi kelengkapan sesuai dengan rencana pengujian

yang diajukan.
 Setelah konfirmasi pengguna terhadap pengujian selesai, Manager BC
XXX bersama dengan Manajer IT-DR XXX dan Manager DR ZZZ akan
kemudian membuat keputusan untuk mengakhiri simulasi DR.
 Manajer IT-DR XXX akan menginformasikan Tim Jaringan untuk
mengembalikan semua konfigurasi jaringan ke lingkungan produksi aktual.
Semua media, yang diambil untuk pemulihan dari lokasi penyimpanan
offsite, perlu disiapkan untuk diambil oleh tim Operasional DC XXX.
 Manajer IT-DR XXX akan memberitahu pengguna tentang penyelesaian
simulasi DR dan juga dimulainya kembali semua sistem produksi XXX.
7.3.5 Evaluasi Pengujian Pemulihan Pasca Bencana

Setelah pengujian pemulihan bencana dikonfirmasi, evaluasi harus dilakukan
untuk memastikan keakuratan dan kebenaran rencana. Masalah harus
diselesaikan sesegera mungkin dan diuji dalam pengujian pemulihan bencana
berikutnya. Penandatanganan (signoff) pengguna sangat diperlukan untuk
pengujian pemulihan bencana. Manajer DR akan mengirimkan kuesioner
kepada manajer pengguna dan meminta perbaikan untuk pengujian pemulihan
bencana. Disamping itu, laporan pemulihan bencana akan diberikan kepada
pengguna dan IT untuk menggambarkan pengujian secara rinci. Tujuan juga
dapat diatur untuk pengujian pemulihan bencana berikutnya.
Manajer DR akan memperbarui panduan Disaster Recovery setelahnya untuk
memastikan prosedur dan informasi terbaru masuk ke dalam manual, juga
Manajer DR akan menyiapkan laporan yang merinci hasil dari simulasi DR.
Laporan akhir akan dikeluarkan untuk klien dalam waktu satu bulan sejak
tanggal dilakukannya simulasi.
Laporan Pemulihan Bencana

Konten yang direkomendasikan sebagai berikut:
Ringkasan Eksekutif
Bagian ini merupakan ringkasan tingkat tinggi kepada manajemen terkait hasil
pengujian pemulihan bencana. Disarankan untuk menjelaskannya secara rinci,
tetapi diperlukan penekanan pada tujuan yang dicapai setelah pengujian
pemulihan bencana.
Ruang Lingkup
Bagian ini menjelaskan ruang lingkup pengujian pemulihan bencana.
Hasil Pengujian
Lampiran 9.5.4
Bagian ini menyimpulkan hasil pengujian pemulihan bencana. Disarankan

untuk daftar keluar panggung dengan platform untuk kemudahan referensi.
Timeline Pengujian
Bagian ini merangkum waktu aktual selama pengujian pemulihan bencana.
Masalah yang dihadapi selama pengujian pemulihan bencana
Bagian ini menggambarkan masalah yang terjadi selama pengujian pemulihan
bencana. Sementara itu, tindakan yang diambil harus disebutkan untuk
referensi di masa mendatang. Jika tidak dapat memperbaiki, area yang terkena
dampak harus disebutkan juga.
Kesimpulan
Bagian ini menyimpulkan hasil keseluruhan pengujian pemulihan bencana.
Lampiran – Rincian Timeline Aktual
Jadwal waktu grafis (graphical timeline) untuk pengujian pemulihan bencana.
Timeline dasar dan aktual dapat dibandingkan di masa depan.
Lampiran – Penandatanganan (Signoff) Pengguna
Bagian ini mengumpulkan semua signoff pengguna selama pengujian
pemulihan bencana. Ini akan diperlukan selama audit sistem untuk pengujian
pemulihan bencana.
Pemeliharaan IT–DRP
Untuk memastikan efektivitas dan akurasi dari DRP, pemeliharaan harus didukung
oleh Manajer IT-DR dan dilakukan secara berkala olehnya. Berikut ini adalah daftar
tindakan pemeliharaan yang harus dilakukan secara berkala:
Penanggung Jawab
No Tindakan Pemeliharaan Frekuensi
Tindakan
1. Review Informasi Tim & Kontak 3 bulan Manajer IT-DR
Setidaknya sekali
2. Pelatihan Staf IT-DRP Manajer IT-DR
setahun
Setidaknya sekali
3. Pengujian IT-DRP Manajer IT-DR
setahun
Tahunan atau setelah
4. Review Perjanjian Vendor perubahan besar Manajer IT-DR
sistem/perusahaan
Lampiran 9.5.4
Tahunan atau setelah

Semua Tim IT-DR
5. Review Strategi Pemulihan perubahan besar
dengan Manajer BC
sistem/perusahaan
Tahunan atau setelah Manajer IT-DR & Tim
Review Prosedur & Konfigurasi
6. setiap perubahan Pemulihan
Pemulihan Sistem
sistem besar Sistem/Jaringan
7.5.1 Review Informasi Tim & Kontak
Call tree, kontak vendor dan anggota tim harus direview untuk memastikan
informasinya adalah benar. Hal ini dilakukan untuk memastikan bahwa semua
personel dapat dijangkau dalam waktu singkat selama Bencana. Review harus
dilakukan setiap 3 bulan. Semua hardcopy panduan IT-DRP yang disimpan
harus diperbaharui.
7.5.2 Pelatihan Staf IT-DRP
Setiap anggota tim IT-DR harus dilatih sesuai dengan fungsi dan peran mereka
dalam tim. Anggota tim baru di IT-DR harus dilatih tentang peran mereka juga.
Tujuan dari pelatihan staf adalah memastikan setiap anggota menyadari
perannya dan memiliki keahlian untuk melakukan pemulihan. Hal ini harus
dilakukan setiap 6 bulan.
Pelatihan juga harus dilakukan setiap kali konfigurasi sistem / jaringan diubah
atau sistem baru diintegrasikan dengan IT-DRP yang ada.
7.5.3 Pengujian & Latihan IT-DRP

Untuk memastikan bahwa TI di PT XXX relevan dan efektif, pengujian berkala
harus dilakukan. Selain memeriksa hardware dan kebenaran backup,
pengujian IT-DRP juga harus mmebuat tim IT-DR menjadi lebih akrab dengan
prosedur pemulihan dan perannya.
Pengujian IT-DRP secara penuh dilakukan minimal setahun sekali. Tim IT-DR
harus menguji kemampuan dasar pemulihan mereka pada skenario
pemadaman total di lokasi produksi utama (main production site). Latihan
pemulihan harus melibatkan seluruh tim IT-DRP, termasuk pemimpin tim,
vendor dukungan pemulihan dan departemen audit untuk meninjau proses
pengujian.
Faktor-faktor yang harus diperhatikan selama pengujian IT-DRP:

Lampiran 9.5.4
1. Waktu Pemulihan:
 Berapa lama waktu yang dibutuhkan untuk memulihkan sistem kritis
sampai sistem beroperasi dan dapat diakses oleh pengguna?
2. Kebenaran Data:
 Apakah integritas data terpelihara selama pemulihan?
Catatan: Jika data pada lokasi produksi (production site) tidak dapat diakses
dan dipulihkan, data terakhir di DRC akan menjadi satu-satunya data yang
dapat digunakan.
3. Kelancaran Prosedur Pemulihan:
 Apakah ada masalah yang muncul selama pengujian prosedur
pemulihan untuk fungsi bisnis kritikal?
4. Efektivitas Komunikasi Saat Krisis:
 Apakah informasi bencana disampaikan secara efektif dari koordinator
DR ke tim pemulihan dan eksekutif, menggunakan proses call tree?
5. Tingkat kenyamanan dan keakraban tim pemulihan pada tugas-tugas
pemulihan mereka:
 Seberapa familiar tim pemulihan dengan tugas pemulihan mereka?
 Apakah tugasnya dilakukan dengan lancar dan cukup cepat untuk
memenuhi RTO?
7.5.4 Review Perjanjian Vendor

Dukungan dari vendor pemulihan sama pentingnya selama pemulihan
bencana. SLA Vendor harus direview setiap kali perubahan besar dalam
strategi IT-DRP atau restrukturisasi perusahaan. Review tersebut harus juga
dilakukan setiap tahun atau setelah tiap hasil pengujian yang tidak
memuaskan.
7.5.5 Review Strategi Pemulihan

Seiring pertumbuhan bisnis dan perubahan dinamis, sangat penting untuk
memastikan bahwa strategi pemulihan IT-DRP adalah up-to-date dan relevan.
Review dari strategi pemulihan TI harus dilakukan secara berkala; juga harus
dilakukan setiap kali restrukturisasi besar perusahaan atau terjadi perubahan
sistem TI.
7.5.6 Review Prosedur & Konfigurasi Pemulihan Sistem

Demikian juga untuk prosedur pemulihan sistem, review harus dilakukan untuk
setiap perubahan sistem TI utama dan / atau setelah pengujian IT-DRP. Review
periodik juga harus dilakukan untuk memastikan bahwa informasi patch / versi
/ konfigurasi terbaru untuk sistem ini diperbarui.
Lampiran 9.5.4
Lampiran
Lampiran A – Fase 1: Checklist Reaksi Awal
A1. Prosedur Eskalasi
A2. Checklist Tanggapan Langsung (Immediate Response)
A3. Pengarahan Tim
A4. Penilaian Kerusakan
A5. Status Backup
A6. Select a High Level Recovery Strategy
Lampiran B – Fase 2: Checklist Pemulihan Aset Data
B1. Pemulihan Layanan Data dan Telekomunikasi
B2. Pemulihan Ruangan Server
B3. Divert Switchboard to Off-site Location
Lampiran C – Fase 3: Checklist Pelanjutan Proses di Alternate Site
C1. Pengamanan Sistem yang Dipulihkan
Lampiran D – Phase 4: Checklist Pembangunan Kembali Lokasi Baru
D1. Pembersihan, Perbaikan, atau Penggantian Peralatan
Lampiran E – Notifikasi Pegawai / Prosedur Call Tree
Lampiran F – Infrastruktur
Lampiran G – Sistem Kritikal
Lampiran H – Laporan Status Pemulihan
Lampiran I – Form Disaster Recovery Report
Lampiran J – Disaster Recovery Problem Log
Lampiran K – Kontak Vendor
Lampiran L – Damage Assessment Report
Lampiran M – Disaster Recovery Problem Report
Lampiran N – Prosedur Aktivasi DRC
Lampiran O – Dukungan Ruangan Data Center
Lampiran P – Form Sistem Aplikasi XXX
Lampiran Q – Daftar Dokumen
Lampiran R – Disaster Verification Procedure Form
Lampiran 9.5.5
PT WIJAYA KARYA (PERSERO) Tbk
Rencana Pengujian DRP
Jakarta
October 2020
Lampiran 9.5.5
Riwayat Dokumen
Peninjauan Dokumen
Distribusi
Nama Jabatan
Persetujuan
Lampiran 9.5.5
DAFTAR ISI
Riwayat Dokumen.................................................................................................................. 2
Peninjauan Dokumen ............................................................................................................ 2
Distribusi ................................................................................................................................ 2
Persetujuan............................................................................................................................ 2
1. Maksud dan Tujuan ........................................................................................................ 4
2. Peserta ........................................................................................................................... 4
3. Agenda dan Tata Cara Pelaksanaan............................................................................. 5
4. Skenario ......................................................................................................................... 7
Lampiran 9.5.5
1. Maksud dan Tujuan

Maksud dari dilakukannya pengujian DRP adalah:
1. Untuk mengukur pemahaman masing-masing individu dalam Tim DRP terhadap
peran dan tanggung jawab mereka, jika terjadi bencana atau insiden.
2. Untuk mengukur kemampuan Tim DRP dalam membuat keputusan penting
pada situasi emergency atau krisis.
3. Untuk mengukur kemampuan Tim DRP dalam melakukan assessment
kerusakan secara cepat dan akurat.
4. Untuk mengukur kemampuan Tim DRP dalam mengkoordinasikan response
plan yang dilakukan.
5. Untuk mengevaluasi kecukupan dokumen DRP untuk memulihkan dan
mengembalikan operasi bisnis kritikal dalam waktu yang telah ditentukan.
2. Peserta
Para peserta yang diundang dalam pengujian DRP ini dapat dikelompokan menjadi
sebagai berikut.
Kategori peserta Perang dan tanggungjawab
[Diisikan kategori peserta [Diisikan peran dan tanggung jawab peserta
pengujian DRP] pengujian DRP]
Pimpinan Tim DRP Merencanakan, melaksanakan, mendokumentasikan
dan membuat laporan hasil exercise.
Evaluator 1) Mengevaluasi jalannya Exercise dengan

fokus pada langkah-langkah yang dilakukan
oleh para peserta dan kesesuaiannya
dengan DRP dan DRP Policy
(dalam kasus exercise ini
dibantu oleh konsultan) 2) Mengevaluasi kecukupan sumber daya
pendukung untuk mendukung langkah-
langkah yang harus dilakukan (daftar nama,
no telpon, konfigurasi jaringan, legal, dsb)
3) Mengevaluasi kelemahan DRP dan
merekomendasikan perbaikan dokumen
DRP (jika diperlukan).
Peserta (Tim DRP) Menjalankan peran yang bersangkutan dalam Tim

DRP sesuai dengan skenario yang diberikan dengan
fokus pada urutan langkah yang dilakukan untuk
menyikapi situasi-situasi yang diberikan dalam
skenario.
Lampiran 9.5.5
3. Agenda dan Tata Cara Pelaksanaan

Berikut merupakan agenda dan tat acara pelaksanaan pengujian DRP
Penanggung
Jam Acara
jawab
[Diisikan [Diisikan mengenai detail dari acara] [Diisikan penanggung
Informasi jawab agenda]
mengenai
informasi jam
pada
agenda]
09.00-09.15 Penjelasan singkat tata cara pelaksanaan, Fasilitator
pembagian tugas peserta, narasi skenario
dan capaian yang diharapkan.
09.15-12.00 Walk-through sesuai tahapan-tahapan yang Fasilitator,

sudah disusun dalam skenario untuk me-
13.30-14.30 review DRP dan kesiapan organisasi dalam Peserta,
(lanjutan) menghadapi disaster sesuai dengan DRP.
Evaluator
Diskusi dilakukan untuk setiap tahapan
dalam skenario, untuk menentukan:
1. pengambilan keputusan strategis

2. langkah-langkah yang harus dilakukan,
serta
3. sumber daya pendukung yang
diperlukan.
Langkah-langkah:
1. Fasilitator akan memaparkan skenario

per tahapan (step)
2. Untuk setiap tahap akan dilakukan hal-
hal sebagai berikut:
a. Setiap peran (atau group)
harus menentukan langkah
apa yang akan dilakukan
untuk menyikapi step yang
sudah diinformasikan. Setiap
peserta harap menyiapkan
dokumen-dokumen yang
relevan untuk melakukan
langkah-langkah yang akan
diperlukan.
Lampiran 9.5.5
Penanggung
Jam Acara
jawab
b. Setiap peran atau wakil group
menjelaskan langkah yang
dilakukan untuk step tersebut.
c. Diskusi untuk
menyempurnakan langkah-
langkah tersebut, termasuk
komentar dari evaluator.
3. Mengulang langkah (2a), (2b), (2c)
untuk tahap berikutnya dalam skenario.
14.30-15.30 Review secara umum seluruh hasil exercise Fasilitator,

mencakup DRP dan kesiapan organisasi.
Peserta,
Evaluator
15.30-16.30 Perumusan saran-saran untuk perbaikan: Fasilitator,
1. Dokumen DRP Peserta,

2. Kesiapan organisasi mencakup
Evaluator
kesiapan SDM dan sumber daya
pendukungnya
Lampiran 9.5.5
4. Skenario
Berikut merupakan scenario pengujian DRP
Tahapan dalam Skenario Asumsi
[Diisikan mengenai tahapan dari scenario yang [Diisikan asumsi-asumsi dari

akan dijalankan] scenario yang ada]
1) Tanggal 18 Maret 2018, pukul 23.30 WIB telah Tidak terjadi kerusakan fisik
terjadi gempa bumi di sekitar Medan. Gempa yang menyebabkan sistem
tersebut dirasakan oleh semua Staf di Gedung terganggu.
Kantor Pusat yang sedang bertugas malam itu.
Pantauan pernyataan yang dikeluarkan oleh
BMKG menyatakan bahwa gempa tersebut
berkekuatan 4,5 Skala Richter. BCG
menyatakan bahwa semua pihak waspada
karena ada potensi gempa susulan yang
mungkin lebih besar, tetapi tidak dapat
diprediksi magnitude nya.
2) Tanggal 19 Maret 2018 pukul 00.15 terjadi Terjadi kerusakan:

gempa susulan yang lebih besar, mencapai 5,5
1) Sebagian gedung
skala richter berlangsung selama 3 menit.
mengalami keretakan
Bebeapa dinding gedung mengalami retak dan
2) Sebagian perangkat
sebagian kecil sistem terganggu.
mengalami kerusakan
fisik sehingga sebagian
fungsi sistem terganggu
(tidak lebih dari 20%
kapasitas total sistem)
3) Tidak ada korban jiwa
atau luka berat
3) Jam 00.30 supply listrik dari PLN mati Sistem backup listrik masih
berfungsi secara otomatis
4) Jam 01.10 terjadi gempa susulan yang lebih  Sebagian besar

besar sehingga sebagian gedung hancur, perangkatmengalami
termasuk ruang Data Center. kerusakan fisik, sehingga
sistem yang masih
Lampiran 9.5.5
Tahapan dalam Skenario Asumsi
berjalan hanya 30% dari

kapasitas maksimum.
 Supply listrik dari PLN
belum pulih dan
kemungkinan besar tidak
akan pulih dalam waktu
singkat.
 Belum teridentifikasi
adanya korban jiwa, tetapi
banyak yang mengalami
luka berat
5) 03.10 BMKG mengumumkan bahwa kecil Tidak terjadi gempa susulan
kemungkinan akan ada gempa susulan. sesuai dengan informasi dari
BMKG
Dibuat Oleh: Diperiksa Oleh: Disetujui Oleh:
Tanggal: Tanggal: Tanggal:
Fungsi IT Fungsi IT Planning & Manajer Sistem

Infrastructure Compliance Informasi
...................................... ...................................... ......................................

Lampiran 9.5.6
PT WIKA (Persero) tbk
Laporan Hasil Pelaksanaan Pemulihan

Operasi TI
JAKARTA
October 2020
Lampiran 9.5.6
Riwayat Dokumen
Peninjauan Dokumen
Distribusi
Nama Jabatan
Persetujuan
Lampiran 9.5.6
DAFTAR ISI
Riwayat Dokumen ...................................................................................................................... 2
Peninjauan Dokumen ................................................................................................................ 2
Distribusi .................................................................................................................................... 2
Persetujuan ................................................................................................................................ 2
1. Tujuan ................................................................................................................................. 4
2. Peserta................................................................................................................................ 4
3. Notifikasi Bencana .............................................................................................................. 5
A. Template – Pencatatan Kejadian Bencana ................................................................... 7
B. Template – Penilaian kerusakan dan dampak Bisnis ................................................... 8
C. Template – Rencana Pemulihan ................................................................................... 9
D. Template – Lembar Monitoring Pemulihan ................................................................. 10
E. Template – Lembar Penginformasian Stakeholders ................................................... 11
Lampiran 9.5.6
1. Tujuan
Laporan hasil pelaksanaan pemulihan operasi TI disiapkan oleh pimpinan tim Disaster
Recovery. Konten dari pelaporan meliputi
1. Deskripsi dari pemulihan yang dilakukan
2. Stakeholders yang terkait mendapatkan pemberitahuan ketika dilakukan
pemulihan (termasuk melampirkan tanggal)
3. Peran dan tanggungjawab atau aksi yang dilakukan oleh member dari Tim Disaster
Recovery
4. Capaian dari aksi yang dilakukan
5. Penilaian dari dampak terhadap bisnis
6. Penilaian dari efektifitas DRP
7. Pembelajaran yang didapat
2. Peserta
Para peserta yang tergabung dalam ppemulihan DRP ini dapat dikelompokan menjadi
sebagai berikut.
Kategori peserta Perang dan tanggungjawab
[Diisikan kategori peserta [Diisikan peran dan tanggung jawab peserta pengujian
pengujian DRP] DRP]
Pimpinan Tim DRP Merencanakan, melaksanakan, mendokumentasikan dan
membuat laporan hasil exercise.
Evaluator 1) Mengevaluasi jalannya Exercise dengan fokus

pada langkah-langkah yang dilakukan oleh para
peserta dan kesesuaiannya dengan DRP dan DRP
Policy
2) Mengevaluasi kecukupan sumber daya pendukung
untuk mendukung langkah-langkah yang harus
dilakukan (daftar nama, no telpon, konfigurasi
jaringan, legal, dsb)
3) Mengevaluasi pelaksanaan DRP dan
merekomendasikan perbaikan pelaksanaan DRP
(jika diperlukan).
Peserta (Tim DRP) Menjalankan peran yang bersangkutan dalam Tim DRP
sesuai dengan skenario yang diberikan dengan fokus pada
urutan langkah yang dilakukan untuk menyikapi situasi-
situasi yang diberikan dalam skenario.
Lampiran 9.5.6
3. Notifikasi Bencana
Ketika muncul kemungkinan terjadinya suatu bencana, dibutuhkan adanya prosedur
notifikasi bencana dari personel PT. Wika yang berada di lokasi tersebut. Prosedur
tersebut mencakup proses pelaporan situasi bencana, menghubungi pihak berwenang
apabila diperlukan, serta memberikan notifikasi call tree pada tim DRP.
No Aktivitas PIC Tanggal Waktu

1. [Berisikan informasi aktivitas [Berisikan [Berisikan [Berisikan
yang dilakukan] informasi PIC informasi informasi
Terkait] mengenai mengenai waktu
tanggal (jam)
pemberitahuan] pemberitahuan]
2. Menerima informasi DM Data

bencana/akan terjadi bencana center
dari personel TI/Vendor
TI/Pegawai PT. Wika. Laporan
tersebut bisa melalui jalur
telepon, e-mail, maupun secara
langsung. Informasi memuat
informasi yang memadai
menggunakan Form Notifikasi
Bencana.
3. Memberikan informasi bencana DM Data

kepada IT DRP Coordinator. center
4. Jika bencana belum terjadi IT DRP

tetapi baru informasi akan terjadi Coordinator
bencana maka Damage
Assessment & Salvage Team Damage
bersama dengan IT DRP Assessment
Coordinator melakukan estimasi & Salvage
dampak dan mengkoordinasikan Team
kesiapsiagaan.
5. Jika sudah terjadi bencana, IT Damage

DRP Coordinator menghubungi Assessment
tim Damage Assessment & & Salvage
Salvage Team untuk bersama- Team
sama melakukan penilaian
kerusakan, apabila
memungkinkan
6. Mengamankan inventaris dan Damage

dokumentasi penting, jika Assessment
diperlukan atas instruksi dari IT & Salvage
DRP Coordinator. Team
7. Setelah aktivasi IT DRP, IT DRP

notifikasi tim IT DRP. Coordinator
Lampiran 9.5.6
No Aktivitas PIC Tanggal Waktu

notifikasi unit bisnis dan Member
pengguna.

notifikasi pihak ketiga terkait, jika Member
diperlukan.
Lampiran 9.5.6
A. Template – Pencatatan Kejadian Bencana

Ketika terjadi bencana, personel PT. Wika yang berada di lokasi (on-site), apabila
memungkinkan, untuk mengisi form Kejadian Bencana sebagaimana berikut:
Form Kejadian Bencana
Dibuat Oleh Direview Oleh
Nama: Nama:
Nomor Induk Pegawai: Nomor Induk Pegawai:
Jabatan: Jabatan:
No. Telp: No. Telp:
Informasi Bencana
Lokasi Bencana:
Tanggal dan Waktu Bencana:
Deskripsi singkat bencana:
Estimasi korban manusia:
Estimai kerusakan fisik:

Lampiran 9.5.6
B. Template – Penilaian kerusakan dan dampak Bisnis

Dibuat Oleh Nama: Tanggal:
Direview Oleh Nama: Tanggal:
Proses Bisnis
Area Bisnis yang Estimasi Waktu
Kunci yang Dependency
Terdampak Pemulihan
Terdampak
[Berisikan are bisnis [Berisikan proses [Berisikan [Berisikan estimasi
yang terdampak] bisnis kunci yang Depedency] waktu pemulihan
terdampak] dimana kondisi
operasi bias
berjalan secara
normal
Penilaian Dari Dampak Bisnis:

Lampiran 9.5.6
C. Template – Rencana Pemulihan

Dilaksanakan Oleh Nama: Tanggal:
Area Waktu
Aksi
No (Dengan Urutan PIC Dependency Target
pemulihan
Prioritas) Pemulihan
1 [Berisikan [Berisikan [Berisikan PIC [Berisikan [Berisikan
informasi area informasi yang Depedency] target
pemulihan] aksi bertanggungjawab] tanggal
pemulihan pemulihan]
yang
dilakukan]
2
7
Lampiran 9.5.6
D. Template – Lembar Monitoring Pemulihan

No Aksi PIC Waktu Capaian Pembelajaran

Pemulihan Pemulihan
Estimasi Aktual
1 [Berisikan [Berisikan PIC jelas jelas [Berisikan [Berisikan
informasi yang capaian pembelajaran
aksi bertanggungjawab] dari yang didapat]
pemulihan pemulihan]
yang
dilakukan]
6
Lampiran 9.5.6
E. Template – Lembar Penginformasian Stakeholders

Personil, Personil yang bertanggungjawab terhadap kordinasi dan

Kelompol, Unit komunikasi kepada personil atau organisasi yang
yang Tedampak terdampak
Nama Posisi Kontak
Kustomer [Berisikan nama [Berisikan Posisi [Berisikan kontak
stakeholders] Stakeholders] stakeholders (email,
phone)]
Staff dan
Manajemen
Suplier
Media
Pihak Ketiga
Lain-Lain
Lampiran 9.6.1
3.6.1. Penyusunan Security Plan
Pelaksana
No. Uraian Kegiatan GM Sistem Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning
Input Output
Informasi Management Infrastructure Development & Compliance
Hasil Risk Daftar risiko terkait
Assessment dengan keamanan
Mulai
sebelumnya informasi
Inventarisasi potensi risiko yang terkait
1
dengan keamanan informasi
Daftar risiko terkait Security Plan

dengan keamanan
2 Penyusunan Security Plan informasi
Security Plan Hasil review

Security Plan
T
3 Review kecukupan Security Plan
Y
Dokumentasi
sosialisasi
Sosialisasi Security Plan yang telah
4
disusun ke pihak-pihak terkait
Selesai
Lampiran 9.6.2
3.6.2. Assessment Keamanan TI Rutin
Pelaksana
Input Output
Rencana Detail
Kegiatan
Mulai
Assessment
Persiapan kegiatan Vulnerability
1
Assessment
Lampiran 9.6.6
Form Vulnerability
2 Vulnerability Assessment/Monitoring Assessment
Dokumentasi Hasil Dokumentasi hasil

Vulnerability Pentest
3 Penetration Testing Assessment
Dokumentasi
Hardening
Y
Apakah terdapat kerentanan yang dapat T
dieksploitasi?
4
Jika ya, maka akan dilakukan kegiatan
System Hardening
Selesai
Lampiran 9.6.3
3.6.3. Manajemen Akun dan Akses Logical
Pelaksana
Pemilik Akun Kepala Divisi Input Output
Lampiran 9.6.7
Mulai Pengajuan
Perubahan UAM
Permintaan akun baru untuk akses ke
1
fasilitas atau sumberdaya TI yang ada Memo permintaan
akun baru atau
perubahannya
Memo permintaan Disposisi

Dispoisisi permintaan hak akses ke akun baru atau konfigurasi
2 perubahannya akun/hak akses
fungsi pengelolaan hak akses
Disposisi Akun/hak akses

konfigurasi baru atau
3 Konfigurasi akun dan hak akses
akun/hak akses perubahannya
Daftar akun/hak Log monitoring

akses akun/hak akses
4 Monitoring penggunaan hak akses
Log pelanggaran Daftar akun yang

Apakah terjadi pelanggaran atas T hak akses disuspend hak
penggunaan akun dan hak akses? aksesnya
5 Y
Jika ya, maka akan dilakukan suspend
atas akun dan hak akses
Daftar akun yang Memo notifikasi dan

Notifikasi dan rekomendasi kepada GM disuspend hak rekomendasi
6 yang membawahi pemilik akun terakit aksesnya untuk tentang akun yang
pelanggaran hak akses sementara melanggar hak
akses
Pemilik akun yang melanggar hak akses Pengajuan
mengajukan permintaan untuk permintaan
7 pengaktifan akun
pengaktiftan hak aksesnya, jika masih
membutuhkan
Pengambilan keputusan terkait dengan Pengajuan Keputusan Kadiv
akun dan hak akses yang telah permintaan terkait untuk
diberikan: pencabutan hak akses atau pengaktifan akun mengaktifkan
8
pengaktifan kembali dengan ketentuan kembali atau
sanksi merujuk kepada ketentuan yang menghapus akun
berlaku.
Keputusan Kadiv Akun yang aktif
terkait untuk kembali atau daftar
mengaktifkan akun yang dihapus
Penghapus an kembali atau
akun menghapus akun
Penghapusan akun/hak akses atau Pengaktifan
9 pengaktifan kembali akun/hak akses kembali
sesuai dengan keputusan GM terkait akun
Lampiran 9.6.8
Laporan Review
Log Akses Logis
Penyusunan laporan manajemen hak
10
akses rutin
Selesai
Lampiran 9.6.4
3.6.4. Manajemen Antimalware
Pelaksana
No. Uraian Kegiatan Pengguna GM Sistem Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning &
Input Output
Desktop/Laptop Informasi Management Infrastructure Development Compliance
Dokumentasi
instalasi Network-
Mulai
based Antimalware
Instalasi dan konfigurasi antimalware
1
pada jaringan komunikasi
Dokumentasi
Instalasi dan konfigurasi antimalware instalasi Host-
2 server yang akan digunakan oleh based Antimalware
seluruh desktop/laptop (server)
Log update
Update rutin antimalware (reguler atau antimalware
3
otomatis)
Log update
Update antimalware di desktop/laptop antimalware
4 menggunakan database yang tersedia
di antimalware server
Status update Laporan monitoring

Monitoring rutin perangkat antimalware di antimalware
5 desktop/laptop terkait status update desktop/laptop
antimalware
Laporan monitoring Dokumentasi

antimalware sosialisasi
Tindak lanjut hasil monitoring status
update antimalware, berupa sosialisasi Daftar
6 atau pembatasan sementara perangkat laptop/desktop
Selesai
yang status antimalwarenya tidak update yang sementara
(jika dibutuhkan) ditangguhkan
aksesnya sampai
dengan
Lampiran 9.6.5
3.6.5. Akses Fisik ke DC/DRC
Pelaksana
No. Uraian Kegiatan Pihak Yang Memerlukan GM Sistem Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning &
Input Output
Akses Fisik Informasi Management Infrastructure Development Compliance
Lampiran 9.6.6
Mulai Form Vulnerability
Assesment
Perencanaan kegiatan pengelolaan hak
1
akses fisik ke DC/DRC
Rencana
pengelolaan hak
akses fisik
Pihak Ketiga Pihak Internal
Hak akses fisik diberikan kepada pihak
2
internal atau pihak ketiga?
Lampiran 9.6.9
Form Permintaan
Hak Akses DC -
Pengajuan permintaan akses fisik ke Internal
3
DC/DRC Lampiran 9.6.5
Permintaan Hak
Akses DC -
Eksternal
Lampiran 9.6.9
Form Permintaan
Hak Akses DC - Evaluasi atas
Evaluasi permintaan dan rekomendasi Internal permintaan hak
4
pemenuhan permintaan Lampiran 9.6.10 akses fisik
T
Permintaan Hak
Akses DC -
Eksternal
5 Apakah hak akses diberikan?

Y
Penetapan keputusan terkait pemberian Evaluasi atas

Lampiran 9.6.11
6 hak akses fisik sementara pihak permintaan hak
Logbook DC
eksternal atas DC/DRC akses fisik
Konfigurasi hak
akses fisik
7 Konfigurasi kontrol akses fisik Lampiran 9.6.7
Pengajuan
Perubahan UAM
Hak akses fisik ke
pihak eksternal
Pemberian akses fisik sementara pihak Lampiran 9.6.7
8
eksternal dengan supervisi di lapangan Pengajuan
Perubahan UAM
Hak akses fisik ke

pihak internal
Pemberian hak ases fisik kepada pihak
9 Lampiran 9.6.7
internal secara terbatas
Pengajuan
Perubahan UAM
Lampiran 9.6.8
Laporan Review
Log Akses Logis
Lampiran 9.6.11
Logging dan surveillance atas kegiatan Log Book Data
10
di dalam lokasi DC/DRC Center
Lampiran 9.6.12
Form Laporan
Review Log Akses
Data Center
T
Apakah masa pemberian hak akses fisik
11
sudah berakhir?
Y
Dokumentasi
Durasi hak akses pencabutan hak
12 Pencabutan hak akses fisik
fisik akses fisik
Selesai
Lampiran 9.6.6
Form Vulnerability Assesment
Threat Origination Description Typical Impact to Data or System Impact Likelihood Risk
Name Identifier Confidentiality Integrity Availability Level
Lampiran 9.6.6
Tabel Security Assessment Results

1
Scheduled
ID Weaknesses Remediation Actions POC Completion Status Risk Level
Date
Lampiran 9.6.7
Pengajuan Perubahan UAM
Informasi Unit Kerja
Unit Kerja : Bidang Cabang Unit Usaha
Nama Unit Kerja :
Informasi Perubahan UAM
Jenis Perubahan UAM :

Grup Jabatan User Document Library Level Akses
Diisi berdasarkan grup Diisi berdasarkan document Diisi berdasarkan level

jabatan user. library. akses yang akan diberikan.
Contohnya: Contohnya: Contohnya:
Staf IT , 1. Terbuka R – Read
2. Terbatas C – Contribute
3. Rahasia A – Approve
4. Sangat Rahasia N - None
5. Eksternal
6. Internal Divisi/Sub Bidang
7. Internal Dinas
Notes:
Pemisahan level akses untuk user-user yang memiliki jabatan yang sama pada unit kerja harus menggunakan 2 grup jabatan atau
lebih yang berbeda pada UAM.
Dibuat Oleh:
Tanggal:
Inisiator Perubahan
Nama dan Jabatan

.......................................
Lampiran 9.6.8
LAPORAN REVIEW LOG AKSES LOGIS

BULAN: Januari
Tanggung Hasil Monitoring Log Akses
No. Aplikasi User-ID Unit Kerja Tanggal Monitoring Solusi
Jawab Logis
1 Diisi dengan user Diisi dengan Diisi dengan divisi Diisi dengan tanggal Diisi dengan keterangan hasil Diisi dengan keterangan
ID atau jabatan jabatan user atau cabang dilakukannya monitoring log akses logis. solusi terhadap insiden
terkait monitoring dari akses logis
Human Rudi Staff Fungsi IT 4 Januari 2018 Tiga kali percobaan login Update password user
Resource Infrastruktur gagal
information
System
Human Rudi Staff Fungsi IT 10 Januari 2018 Akses dari device yang tidak Update patch OS/software
Resource Infrastruktur terdaftar Implementasi firewall
information Access ke modul yang tidak
System teratuorisasi
Dibuat Oleh:
Tanggal :
Fungsi IT Infrastruktur
...................................
Lampiran 9.6.9
Form Permohonan Akses ke Data Center – Internal
No. Formulir
(Diisi oleh Unit ABC12345
Bisnis)
Informasi Permohonan
Nama Budi
Jabatan Staff
Department SPI
Kegiatan Kunjungan Pemeriksaan Aset
Tanggal 2 Januari 2018
Jam 10.00 – 11.30
Counterpart Andi
Jabatan Counterpart Staff Operasi & Pelayanan TI

Tanggal: Tanggal:
User Kepala Fungsi IT Infrastructure
............................................... ...............................................
Lampiran 9.6.9
Diperiksa Oleh : Disetujui Oleh:

Tanggal: Tanggal:
GM Sistem Informasi Kepala Fungsi IT Planning &

Compliance
..............................................
..............................................
Lampiran 9.6.10
Permohonan Akses Data Center - Eksternal

Nomor Surat : XYZ67890
Perihal : Permohonan Akses Data Center
Terhadap nama yang tertera di bawah ini, yang dibuktikan dengan kartu identitas yang
sah (KTP/SIM/Pasport), agar diperbolehkan memasuki Data Center untuk keperluan dan
waktu sebagaimana dijelaskan di bawah ini:
Nama Bunga
Instansi PT. X
Kegiatan
Kunjungan Asessment Data Center
Tanggal (DD/MM/YY) 8 Januari 2018
Jam 13.00 – 14.00
Counterpart Andi
Jabatan
Counterpart Staff Operasi & Pelayanan TI
Pemohon IT Security Supervisor
Nama: …………………………………… Nama: ……………………………………

Tanggal: …………………………………… Tanggal: …………………………………
Lampiran 9.6.11
LOG BOOK DATA CENTER
BULAN: Januari
Masuk Keluar
Nomor Surat
No. Tanggal Nama Divisi Aktivitas Tanda Tanda Pendamping
Waktu Waktu Permohonan
Tangan Tangan
Diisi dengan
Jelas Jelas Jelas Diisi oleh Diisi oleh Diisi oleh jam Diisi oleh jam Diisi oleh tanda Diisi oleh Diisi oleh nama nomor Surat
Nama Divisi uraian kegiatan masuk keluar tangan tanda tangan pegawai Group Permohonan
Pengunjung yang dilakukan pengunjung pengunjung pengunjung pengunjung Dukungan TI Akses Data
Data Center pengunjung di ke Data dari Data ketika masuk ketika keluar yang Center
Data Center Center Center ke Data dari Data mendampingi
Center Center pengunjung di
Data Center
1 2 Januari 2018 Budi SPI Pemeriksaan 10.00 11.30 Andi ABC12345

Aset
2 8 Januari 2018 Bunga PT. X Assessment 13.00 14.00 Andi XYZ67890
DC
Dibuat Oleh: Diketahui Oleh

Tanggal : Tanggal:
Fungsi IT Infrastructure Kepala Fungsi IT Infrastructure
..............................
...................................
Lampiran 9.6.12
Review Log Akses Data Center
Tanggal Hasil Monitoring Log

No. Nama/NIK Unit Kerja Pendamping Insiden Solusi
Monitoring Akses Fisik
1 Diisi dengan Diisi oleh Diisi oleh nama Diisi dengan Diisi dengan Diisi dengan Diisi dengan
Nama Nama Divisi pegawai Group tanggal keterangan hasil keterangan keterangan solusi
pengunjung Pengunjung Dukungnan TI dilakukannya monitoring log akses mengenai insiden terhadap insiden
data center Data yang monitoring fisik yang terjadi selama dari akses fisik
Center mendampingi pemakaian akses
pengunjung di fisik (jika ada)
Data Center
Dibuat Oleh:
.......................................
Lampiran 9.7.1
3.7.1. Manajemen Insiden
Pelaksana
No. Uraian Kegiatan Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning &
GM Sistem Informasi Input Output
Management Infrastructure Development Compliance
Tiket insiden :
Mulai Kategorisasi insiden
Identifikasi Insiden atau permintaan
layanan
Analisa apakah memang insiden atau
1
permintaan layanan? Jika bukan insiden,
akan ke proses Manajemen Permintaan T Manajemen
Layanan Permintaan
Layanan
Y
Logging dan
2 kategorisasi insiden
Pencatatan, kategorisasi dan prioritisasi
Insiden
Apakah insiden bersifat Major dan Y Eksekusi Continuity

3 Plan
berpotensi disaster? Jika ya, maka akan
ke proses Eksekusi Continuity Plan T
Diagnosis awal
insiden
4
Diagnosis awal atas insiden
Diagnosis awal Keputusan eskalasi

Y insiden atau tidak
5
Apakah memerlukan eskalasi?
T
Diagnosis awal Diagnosis lanjutan
6 T insiden
Investigasi dan diagnosis lanjutan
7
Apakah resolusi sudah dapat
diidentifikasi?
T Keputusan eskalasi
8 ke fungsi dukungan
Apakah memerlukan eskalasi ke fungsi teknis
IT Infrastructure? Y Y

9 insiden
Investigasi dan diagnosis oleh Fungsi IT
Infrastructure

10 insiden
Investigasi dan diagnosis oleh Fungsi
Solution Development
Keputusan notifikasi
Apakah memerlukan notifikasi kepada T ke manajemen atau
11
manajemen karena insiden yang terjadi tidak
cukup serius?
Y
Notifikasi kepada
Penyampaian notifikasi kepada manager GM sistem
12 informasi
sistem informasi karena insiden cukup
kritikal dan mungkin akan butuh waktu
lebih lama untuk resolusinya
Diagnosis lanjutan Lampiran 9.7.3

Resolusi insiden dan recovery utk Laporan
13 Penanganan
insiden yang memerlukan eskalasi
(sesuai dengan fungsi masing-masing yg Inisiden &
relevan) Permintaan
Layanan
Diagnosis lanjutan Lampiran 9.7.3
Laporan
Penanganan
14 Inisiden &
Resolusi insiden dan recovery utk
insiden yang tidak memerlukan eskalasi Permintaan
Selesai Layanan
Lampiran 9.7.2
3.7.2. Manajemen Permintaan Layanan
Pelaksana
User Input Output
Permintaan
Mulai
1 Penyampaian permintaan Manajemen

Insiden
Logging dan hasil

validasi permintaan
2 Logging dan validasi permintaan
T
3 Apakah permintaan layanan valid?
Y
Logging dan hasil Kategori dan skala
validasi permintaan prioritas permintaan
4 Kategorisasi dan prioritisasi permintaan
Apakah memerlukan otorisasi yang lebih

T
5
tinggi dari manager sistem informasi?
Y
Permintaan Otorisasi atas
Pemberian otorisasi atas permintaan permintaan
6
yang masuk
Apakah permintaan akan berdampak Y Manajemen

7
terhadap perubahan CI? Konfigurasi
T
Dokumentasi
pemenuhan
Pemenuhan permintaan oleh fungsi permintaan
8 terkait di Departemen Sistem Informasi
(sesuai dengan tipe permintaan)
Selesai
Lampiran 9.7.3
Laporan Penanganan Insiden
Informasi Insiden Atau Kejadian

Nomor Formulir Diisi dengan nomor formulir ketentuan Perusahaan
Nama Pelapor Diisi dengan nama pelapor insiden
Departemen Diisi dengan divisi pelapor insiden
Pelapor
Insiden/Kejadian Diisi dengan deskripsi insiden yang terjadi
Tanggal Diisi dengan tanggal pelaporan insiden
Pelaporan
Insiden
Waktu Pelaporan Diisi dengan waktu pelaporan insiden
Insiden
Deskripsi Solusi Insiden Atau Kejadian *)Diisi oleh Asisten Help Desk
Insiden/kejad Diisi penjelasan mengenai deskripsi insiden yang terjadi
ian
Akibat dari Diisi penjelasan mengenai akibat apabila insiden terjadi
Insiden
Dampak
Terhadap
Sistem Diisi penjelasan mengenai dampak terhadap sistem aplikasi
Tingkat
 Besar  Kecil
Dampak
Prioritas  Mendesak  Tidak Mendesak
Hasil Diisi penjelasan mengenai solusi yang didapatkan dari hasil
Investigasi/S investigasi untuk penanganan insiden
olusi
Solusi Diisi penjelasan mengenai langkah-langkah penanganan
Insiden insiden
Kategori 
 Human Hardwar  Jaringan
Error e
   Lainnya
Aplikasi/Datab Keaman ………………………………………
ase an ….………
Status   Eskalasi
Insiden Selesai ke………...………………………………………….…
……
Tanggal selesai
………………………………………….(DD/MM/YY)
Diselesaikan Oleh: Diketahui Oleh:
Tanggal: Tanggal:
IT Helpdesk Fungsi Service Management
................................. .................................
Lampiran 9.7.3
Hasil Investigasi Helpdesk Administration
Hasil ……………………………………………………………………………
Investiga …………………………………………
si ……………………………………………………………………………
Helpdesk …………………………………………
Administr ……………………………………………………………………………
ation …………………………………………
Tindak ……………………………………………………………………………
Lanjut …………………………………………
Helpdesk ……………………………………………………………………………
Administr …………………………………………
ation ……………………………………………………………………………
…………………………………………
Status  Selesai  Solusi Sementara/Workaround
 Eskalasi ke
……………………………………………………………………………
……………………
Tanggal
selesai .......................................................................... (DD/MM/Y
Y)
No Insiden Evidence

Tanggal: Tanggal:
IT Helpdesk Fungsi Service Management
................................. .................................
Lampiran 9.8.1
3.8.1. Manajemen Permasalahan
Pelaksana
Input Output
Laporan rutin dari Analisa pola

Mulai manajemen insiden keterjadian insiden
Analisa rutin untuk mendeteksi
1 keberadaan permasalahan atas insiden-
insiden yang terjadi
Analisa pola Lampiran 9.8.2

keterjadian insiden Laporan
Penanganan
Pencatatan, kategorisasi dan prioritisasi
2 permasalahan Masalah:
Kategorisasi dan
prioritisasi
permasalahan
Kategorisasi dan Lampiran 9.8.2
prioritisasi insiden Laporan
Investigasi dan diagnosasi atas
Penanganan
permasalahan
3 Masalah:
Hasil investigasi dan
diagnosis
T
Apakah dibutuhkan workaround atas
permasalahan?
4
Y
Dokumentasi
6 Implementasi workaround Manajemen workaround
Insiden
Catatan insiden atau Lampiran 9.8.2

error yang masih Laporan
terjadi Penanganan
7 Analisa lebih lanjut atas atas error atau Masalah:
permasalahan yang masih terjadi Investigasi dan
analisa lanjutan atas
permasalahan yg
masih terjadi
Y Manajemen
8 Apakah dibutuhkan perubahan?
Perubahan
T
Investigasi dan Lampiran 9.8.1
analisa lanjutan atas Laporan
Resolusi permasalahan (sesuai dengan permasalahan yg Penanganan
9 fungsi terkait, mempertimbangkan tipe masih terjadi Masalah:
permasalahan) Dokumentasi
resolusi
permasalahan
10 Apakah permasalahan sudah dapat T

diatasi?
Y
Lampiran 9.8.1
Laporan
Penanganan
Masalah
11 Penutupan permasalahan Selesai
Dokumentasi
penutupan
permasalahan
Lampiran 9.8.2
Laporan Penanganan Masalah
Informasi Masalah Dan Solusi

Nomor Formulir Diisi dengan nomor formulir ketentuan Perusahaan
Nama Pelapor Diisi dengan nama pelapor masalah
Divisi Diisi dengan nama divisi pelapor
Masalah Diisi dengan deskripsi masalah yang terjadi
Dampak Masalah Diisi dengan waktu pelaporan masalah
Kategori Masalah  Jaringan  Database  Hardware  Aplikasi
  Lainnya
Keamanan
Eskalasi Masalah □ Manajer Sistem Informasi
□ Fungsi Service Management
□ Fungsi IT Infrastrukture
□ Fungsi Solution Development
□ Fungsi IT Planning & Compliance
Tanggal Terima Diisi dengan tanggal terima pemberian dokumen masalah
Hasil Investigasi Diisi dengan hasil diagnose masalah yang terjadi
dan Diagnosis
Masalah
Metode Diisi dengan menjelaskan metode pembuatan solusi dari
Pembuatan masalah
Solusi Masalah
Solusi Masalah Diisi dengan solusi yang dibuat dari metode yang telah
dibuat
Efektivitas Diisi dengan dengan deskripsi singkat terkait efektifitas
penanganan penanganan
masalah
Manfaat Solusi Diisi dengan menjelaskan manfaat dari adanya solusi yang
Masalah dibuat
Tanggal Selesai Diisi dengan tanggal selesai masalah terselesaikan

Tanggal: Tanggal:
IT Service Desk Fungsi Service Management
............................................... ...............................................
*) Coret yang tidak perlu

Lampiran 9.9.1
3.9. Manajemen Konfigurasi
Pelaksana
Input Output
Portofolio Layanan Rencana kegiatan

Mulai manajemen
konfigurasi
1 Perencanaan manajemen konfigurasi
Pengembangan Implementasi
2 Identifikasi kebutuhan konfigurasi Aplikasi Infrastruktur
RFC atas CI Lampiran 9.9.2

Manajemen Data Inventaris
Perubahan (CI) Aset
3 Kontrol atas konfigurasi
Logging perubahan
CMDB
CMDB Laporan monitoring

Monitoring dan pemeriksaan rutin atas dan identifikasi
4 status CI
status konfigurasi
CMDB Lampiran 9.9.3

Laporan monitoring Laporan Konfigurasi
5 Verifikasi/audit rutin dan identifikasi CI Laporan verifikasi
atau audit
Lampiran 9.9.2
Data Inventaris Aset

FUNGSI :
Data Asset : Spesifikasi Aset :
Status
No. Penanggung
Nama Asset : Asset ID : Pengguna : (Aktif/Idle/ Merk : Type : Serial No. :
Jawab :
Rusak)
Lampiran 9.9.3
Laporan Konfigurasi
Area : [wilayah TI yang dilaporkan, contoh: Kantor Pusat].......................
Tanggal : ........................................................................................................
Disiapkan oleh:
Riwayat Perubahan:
[Isi dengan nama Dokumen pertama dibuat
Document
Owner.]
[Isi dengan nama [Isi dengan list perubahan pada tanggal
Change Owner.] dan versi ini]
 [Perubahan 1]
 [Perubahan 2]
 [Perubahann]
Lampiran 9.9.3
1. PENDAHULUAN
[Menjelaskan latarbelakang, ruang lingkup laporan.]
2. CONFIGURATION BASELINE
[Menyampaikan configuration baseline yang terakhir disetujui. Configuration baseline

bisa terlampir]
3. PERUBAHAN CONFIGURATION ITEM

[Menyampaikan perubahan configuration item yang terjadi pada area terkait]
Tanggal
Kategori ID Nama Deskripsi Status Nilai Lokasi Pemilik
Pengadaan
{Kategori {ID {Nama {Deskripsi {Status {Tanggal {Nilai {Lokasi {Pemili
CI: setiap CI} CI, CI: pengadaan finans CI saat k CI}
Hardware, CI. D misalnya aktif, CI} ial CI} ini}
Software, tersebu fungsional, tidak
Dokument t sesuai spesifikasi aktif}
asi dengan CI}
format
yang
disepak
ati}
Lampiran 9.9.3
4. RESUME INSIDEN
[Menyampaikan daftar CI yang tidak terotorisasi dan penggunaan hardware, software

yang tidak terotorisasi]
4.1 Resume Insiden
No Configuration Item Insiden Tindakan
[Nama dan deskripsi CI [Deskripsi insiden] [Tindakan yang

termasuk jenis CI] dilakukan]
5. PENUTUP
5.1 RIWAYAT PERUBAHAN

NO. REVISI NO. TANGGAL ISI PERUBAHAN
1. 0.0 (Tgl pertama disahkan)
Lampiran 9.10.1
3.10.1. Manajemen Backup Data
Pelaksana
Input Output
Hasil BIA Lampiran 9.10.4
Mulai Checklist Backup
Identifikasi persyaratan backup data data:
1 berdasarkan kriteria RPO yang Persyaratan backup
dihasilkan dari proses BIA data
Persyaratan backup Arsitektur teknis

data yang telah
Konfigurasi arsitektur teknis terkait untuk
2 terkonfigurasi
mendukung ketercapaian RPO
Data terbackup
Pelaksanaan backup data rutin
3 (menyesuaikan dengan kriteria
kritikalitas layanan)
Hasil pengujian
recovery data
Pengujian secara berkala hasil backup
4 data, apakah dapat digunakan untuk T
mendukung kegiatan recovery?
Y
Lampiran 9.10.5
Berita Acara
Penyusunan laporan rutin kegiatan Backup:
5 Laporan
backup data dan pengujiannya
manajemen backup
Selesai
Lampiran 9.10.2
3.10.2. Manajemen Disposal Data
Pelaksana
No. Uraian Kegiatan Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning Input Output
GM Sistem Informasi
Management Infrastructure Development & Compliance
Ketentuan terkait Rencana

Mulai dengan pengarsipan dan
pengarsipan dan disposal data
Penyusunan rencana pengarsipan dan
1 retensi data
disposal data
Apakah durasi waktu telah terpenuhi Manajemen

2 Backup Data
untuk melakukan pengarsipan data?
Y
Rencana Dokumentasi
pengarsipan dan pengarsipan data
Pengarsipan data ke media yang telah
3 disposal data
ditetapkan
T
Apakah durasi retensi atas data telah

4
terpenuhi?
Y
Rencana Lampiran 9.10.6
pengarsipan dan Form Disposal
disposal data Data:
5 Disposal atas data Dokumentasi
Selesai
disposal data
Lampiran 9.10.3
3.10.3. Manajemen Pengendalian Rekaman
No. Uraian Kegiatan Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning Input Output
GM Sistem Informasi
Management Infrastructure Development & Compliance
Mulai
Mengidentifikasi Rekaman
1
berdasarkan ketentuan
2 Menerima rekaman
Lampiran
Melabelkan tingkat 9.10.7
3
kerahasiaan rekaman Pengendalian
Rekaman
Lampiran
Memperbaharui daftar 9.10.7
4
rekaman Pengendalian
Rekaman
Lampiran
Menyimpan rekaman
9.10.7
5 dengan mematuhi
Pengendalian
ketentuan yang ada
Rekaman
Lampiran
Melakukan pengambilan
9.10.7
6 rekaman yang disimpan
Pengendalian
berdasarkan ketentuan
Rekaman
Lampiran
Melindungi/memelihara
9.10.7
7 rekaman dengan mematuhi
Pengendalian
ketentuan yang ada
Rekaman
Lampiran
Memusnahkan rekaman
9.10.7
8 dengan mematuhi
Pengendalian
ketentuan yang ada Selesai Rekaman
Lampiran 9.10.4
Backup Data
Checklist Backup Data
Form Backup Data

Tanggal dan Waktu
Nama Sistem Aplikasi Nama Data Backup Jumlah Data Backup Status
Backup
Diisi penjelasan mengenai Diisi penjelasan Diisi penjelasan mengenai nama Diisi penjelasan mengenai
tanggal dan waktu mengenai nama sistem data yang akan dilakukan backup jumlah data yang akan di backup
dilakukan backup aplikasi yang 
digunakan, tempat data
akan dilakukan backup
12 – Maret – 2018, 06:30 Aplikas Data transaksi Pembangunan 1000 Record; Periode 1
WIB Jalan Desember 2017, 00:00 WIB – 11 
Maret 2018, 00:00 WIB
Form Backup Data

Tanggal dan Waktu Nama Sistem
Nama Data Backup Jumlah Data Backup Status
Backup Aplikasi
Diisi penjelasan Diisi penjelasan Diisi penjelasan mengenai Diisi penjelasan mengenai
mengenai tanggal dan mengenai nama nama data yang akan jumlah data yang akan di
waktu dilakukan backup sistem aplikasi yang dilakukan backup backup

digunakan, tempat
data akan dilakukan
backup
Lampiran 9.10.4
12 – Maret – 2018, Aplikas Data transaksi Pembangunan 1000 Record; Periode 1

06:30 WIB Jalan Desember 2017, 00:00 WIB – 
11 Maret 2018, 00:00 WIB
Dibuat Oleh: Diketahui Oleh:

Tanggal: Tanggal:
Fungsi IT Infrastructure Manajer Sistem

Informasi
.........................................
.........................................
Lampiran 9.10.5
Berita Acara Backup

Pada hari ini ................, tanggal .........., bulan ...................., tahun .................. ,
Pukul ............... bertempat di Data Center..........., telah dilakukan backup data /
aplikasi milik (Unit Kerja) .............................. , dengan rincian sebagai berikut:
Dilakukan Oleh Diisi penjelasan mengenai nama pihak yang melakukan
backup
Nama Sistem Diisi penjelasan mengenai nama sistem aplikasi yang

digunakan, tempat data akan dilakukan backup
Periode Data Diisi penjelasan mengenai periode dari data yang akan
dilakukan backup
Nama Data atau Diisi penjelasan mengenai nama data atau obyek yang
Obyek Backup akan dilakukan backup
Direktori Penyimpan Diisi penjelasan mengenai direktori penyimpanan data

Data atau Obyek atau obyek yang akan di backup
Backup
Jumlah Data atau Diisi penjelasan mengenai jumlah data atau obyek
Obyek Backup yang akan di backup
Tujuan Backup Diisi penjelasan mengenai tujuan dilakukan backup
Tanggal dan Waktu Diisi penjelasan mengenai tanggal dan waktu dilakukan
Backup backup
Demikian Berita Acara Backup ini dibuat dengan sebenar-sebenarnya untuk dapat
dipergunakan sebagaimana mestinya.
Diselesaikan Oleh: Disetujui Oleh:

Tanggal: Tanggal:
………………………… …………………………
Lampiran 9.10.6
Disposal Data
Informasi Pemohon
Tanggal Diisi dengan tanggal permohonan disposal
Unit Kerja Diisi oleh Unit Kerja yang mengajukan atau membuat form
Nama Pemohon Jelas
Telepon (ext.) Jelas
Informasi Obyek Disposal

Pengguna Aset Diisi dengan nama pengguna dari Aset yang akan di
disposal
Jenis Aset Disposal Perangkat TI: (dipilih salah satu bagian yang akan di
disposal)
 Software
 Hardware
 Lain-lain
Nama Aset Disposal jelas
Alasan Disposal Diisi dengan penjelasan mengenai alasan dilakukan
disposal terhadap Aset yang diajukan
Informasi Tindak Lanjut (Diisi Oleh Divisi Unit Bisnis Infrastructure)

Tanggal Terima Objek Diisi dengan tanggal diterimanya permohonan disposal
untuk Disposal
Software untuk  Office  Antivirus  Patch
Disposal   Lainnya  Lainnya
Lainnya………… ………… …………………
Hardware untuk  Hard disk  Memory  CPU
Disposal  Lainnya  Lainnya

Lainnya………… ………… ………………
Metode Disposal Diisi dengan penjelasan mengenai metode yang akan
dilakukan untuk melakukan disposal terhadap objek yang
diajukan
Lampiran 9.10.6
Pada hari ini ................, tanggal .........., bulan ...................., tahun ................. , Pukul
............... bertempat di Divisi TI, Kantor Pusat PT Wijaya Karya (Persero) tbk telah
dilakukan proses disposal dengan rincian sebagai berikut:
Informasi Disposal
Pemohon Disposal Diisi dengan nama pemohon disposal
Tanggal Pengajuan Diisi dengan tanggal permohonan diajukannya disposal
Disposal
Objek Disposal Diisi dengan software disposal
(Software)
Objek Disposal Diisi dengan hardware disposal
(Hardware)
Tanggal Selesai Diisi dengan tanggal disposal yang telah selesai
Disposal dikerjakan
Alasan Disposal Diisi dengan deskripsi yang menyatakan bahwa disposal
berhasil atau tidak
Metode Disposal Diisi dengan metode yang dilakukan saat disposal
Demikian Berita Acara Disposal ini dibuat dengan sebenar-sebenarnya untuk dapat
dipergunakan sebagaimana mestinya.
Department Unit Bisnis Infrastructure

Dibuat Oleh: Diperiksa Oleh:
Tanggal: Tanggal:
User Pemohon Fungsi Service Development
………………………….. …………………………..
Lampiran 9.10.7
Log Book Pengendalian Rekaman

Tingkat Nama Petugas
Nama Tanggal Jenis Rekaman Kerahasiaan Nama Petugas
No. Metode Validasi
Rekaman Rekaman Rekaman
Rekaman
1. Risalah Rapat 15 Agustus Pembaharuan Softcopy Sangat Rahasia Agus Mulyadi Bambang
Masalah 2018 Priyatno
Kepegawaian Penyimpanan Hardcopy
Pengambilan
Pemusnahan
Pembaharuan Softcopy
Penyimpanan Hardcopy
Pengambilan
Pemusnahan
Pembaharuan Softcopy
Penyimpanan Hardcopy
Pengambilan
Pemusnahan
Lampiran 9.11.1
3.11.2. Manajemen Pemeliharaan Aplikasi
Pelaksana
No. Uraian Kegiatan GM Sistem Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning & Vendor Pemeliharaan
Input Output
Informasi Management Infrastructure Development Compliance Aplikasi
Arsitektur Rencana
Mulai
infrastruktur pemeliharaan
Kontrak terkait software aplikasi
Penyusunan rencana pemeliharaan atas aplikasi
1
software aplikasi
Kriteria penerimaan
atas kegiatan
Penetapan kriteria penerimaan atas
2 pemeliharaan
kegiatan pemeliharaan software aplikasi
software aplikasi
Y
Apakah pemeliharaan dilakukan oleh
3
pihak ketiga (vendor)
T Dokumentasi
kegiatan
4 Kegiatan pemeliharaan oleh vendor pemeliharaan oleh
vendor
Dokumentasi
kegiatan
5 Kegiatan pemeliharaan oleh tim internal pemeliharaan oleh
internal
Dokumentasi Evaluasi
Evaluasi penapaian kriterian kinerja kegiatan ketercapaian
6 T
pemeliharaan software aplikasi pemeliharaan kriteria
pemeliharaan
Apakah siklus pemeliharaan software

T
7 aplikasi sudah berakhir sesuai tahun
anggaran atau kontrak?
Y
Laporan
manajemen
Evaluasi kegiatan pemeliharaan pemeliharaan
8 software aplikasi
software aplikasi
Selesai
Lampiran 9.11.2
3.11.1. Manajemen Pemeliharaan Infrastruktur
Pelaksana
No. Uraian Kegiatan GM Sistem Fungsi Service Fungsi IT Fungsi Solution Fungsi IT Planning & Vendor Pemeliharaan
Input Output
Informasi Management Infrastructure Development Compliance Infrastruktur
Mulai
Rencana
Penyusunan rencana pemeliharaan atas Arsitektur
1 pemeliharaan
infrastruktur infrastruktur
infrastruktur
Kriteria penerimaan
Penetapan kriteria penerimaan atas atas kegiatan
2
kegiatan pemeliharaan infrastruktur pemeliharaan
infrastruktur
Y
Apakah pemeliharaan dilakukan oleh
3
pihak ketiga (vendor)
T Dokumentasi
kegiatan
4 Kegiatan pemeliharaan oleh vendor
pemeliharaan oleh
vendor
Dokumentasi
kegiatan
5 Kegiatan pemeliharaan oleh tim internal
pemeliharaan oleh
internal
Dokumentasi Evaluasi
Evaluasi penapaian kriterian kinerja T
6 kegiatan ketercapaian kriteria
pemeliharaan infrastruktur
pemeliharaan pemeliharaan
Apakah siklus pemeliharaan infrastruktur

T
7 sudah berakhir sesuai tahun anggaran
atau kontrak?
Y
Laporan
Evaluasi kegiatan pemeliharaan manajemen
8
infrastruktur pemeliharaan
Selesai infrastruktur

09 Wika-Mif-Pm-03.01 - Prosedur Operasi Teknologi Informasi (01 Amd 01)

Diunggah oleh

Hak Cipta:

Format Tersedia

09 Wika-Mif-Pm-03.01 - Prosedur Operasi Teknologi Informasi (01 Amd 01)

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

09 Wika-Mif-Pm-03.01 - Prosedur Operasi Teknologi Informasi (01 Amd 01)

Diunggah oleh

Hak Cipta:

Format Tersedia

PT WIJAYA KARYA (Persero) Tbk No. Dok : WIKA-MIF-PM-03.

PROSEDUR OPERASI TEKNOLOGI INFORMASI 01 Juli 2020 30 Juni 2023

Sebab Perubahan : Restrukturisasi Organisasi

Peraturan Peralihan : Tidak ada

Tanggal 29 Juni 2021 29 Juni 2021

Prosedur Operasi Teknologi Informasi

No. Revisi Amd. Tanggal Perubahan

2.0 RUANG LINGKUP

5.0 KETENTUAN UMUM

5.3.2.3 Fasilitas: catudaya listrik, sistem pendinginan (HVAC = Heating,

5.5 Manajemen Keberlangsungan Layanan

5.6 Manajemen Keamanan TI

b. Insiden yang harus dieskalasi ke Fungsi IT Infrastructure atau

5.10.1.1 Backup Data dilakukan sesuai dengan persyaratan RPO layanan

5.11.2.3 Jika infrastruktur disediakan oleh pihak ketiga, kontrak pekerjaan

5.12.3 Penyimpanan Rekaman

Manajemen Keamanan Informasi disimpan dalam database yang

5.12.4 Perlindungan Rekaman

5.12.5 Pengambilan Rekaman

5.12.6 Pemusnahan Rekaman

5.12.6.2 Petugas Pengendalian Rekaman di masing – masing fungsi perlu

6.0 PROSEDUR DAN URUTAN KERJA

9.3 Manajemen Kapasitas

9.9 Manajemen Konfigurasi

3.1.2. Manajemen Tingkat Layanan

Lampiran 9.1.2 Lampiran 9.1.2

Lampiran 9.1.2 Laporan evaluasi

Semua output di 1. Lampiran 9.1.6

PT WIJAYA KARYA (PERSERO)

Versi Tanggal Nomor RFC Ringkasan Perubahan

Jadwal Peninjauan Berikutnya

Nama Jabatan Tanda Tangan Tanggal

3 DRAFT KATALOG LAYANAN 8

Untuk penyusunan Katalog Layanan TI WIJAYA KARYA (PERSERO) TBK,

sumber: Mark O’Loughlin, The Service Catalog – A Practitioner Guide.

KATEGORI LAYANAN PENYUSUN

2.3 Kerangka Profil Layanan

3 Draft Katalog Layanan

3.1.1 General Ledger

3.1.2 Account Receivable and Payable

3.1.3 Asset Accounting

Dukungan dan Beberapa dokumentasi yang potensial akan membantu

3.1.4 Bank Accounting

- Aturan-aturan internal PT Wijaya Karya (Persero) Tbk

3.1.5 Travel Management

disepakati dan selanjutnya akan dieskalasikan kepada

3.1.6 Fund Management

Proses untuk Pelaksanaan permintaan layanan dilakukan oleh user

3.2 Layanan Financial Control

3.2.1 Cost Element Accounting

3.2.2 Cost Center Accounting

aspek berikut ini direkomendasikan untuk lebih

3.2.3 Activity Based Accounting

aspek berikut ini direkomendasikan untuk lebih

3.2.4 Internal Order

3.2.5 Product Cost Controlling

Tanggung jawab Penggunaan layanan oleh user mengacu terhadap

3.2.6 Profitability Analysis