Proyek ini bertujuan untuk membangun sebuah website manajemen proyek untuk PT KaryaIndo Konstruksi dalam waktu 2,5 bulan dengan estimasi biaya Rp 36.025.000,00. Website ini diharapkan dapat memudahkan manajemen dalam mengelola data karyawan, tender proyek, dan perkembangan proyek. Proyek ini akan dilaksanakan melalui beberapa tahapan seperti analisis kebutuhan, perancangan, pengembangan, pengujian
Dokumen tersebut merangkum definisi sistem operasi, layanan utama yang disediakan sistem operasi seperti antarmuka pengguna, eksekusi program, operasi I/O, manajemen berkas, komunikasi, deteksi kesalahan, alokasi sumber daya, akuntansi, proteksi dan keamanan, serta struktur sistem operasi seperti struktur sederhana, pendekatan layer, mikrokernel, modul, mesin virtual, dan mesin virtual Java.
Laporan ini merangkum diagram konteks dan data flow diagram sistem informasi penjualan perusahaan rental komputer. Diagram konteks menggambarkan input dan output sistem seperti data order, barang, dan transaksi dari berbagai pihak. Sedangkan data flow diagram level 0 menggambarkan proses-proses utama sistem seperti pengolahan data order, barang, transaksi, pembelian, dan laporan.
Proyek ini bertujuan untuk membangun sebuah website manajemen proyek untuk PT KaryaIndo Konstruksi dalam waktu 2,5 bulan dengan estimasi biaya Rp 36.025.000,00. Website ini diharapkan dapat memudahkan manajemen dalam mengelola data karyawan, tender proyek, dan perkembangan proyek. Proyek ini akan dilaksanakan melalui beberapa tahapan seperti analisis kebutuhan, perancangan, pengembangan, pengujian
Dokumen tersebut merangkum definisi sistem operasi, layanan utama yang disediakan sistem operasi seperti antarmuka pengguna, eksekusi program, operasi I/O, manajemen berkas, komunikasi, deteksi kesalahan, alokasi sumber daya, akuntansi, proteksi dan keamanan, serta struktur sistem operasi seperti struktur sederhana, pendekatan layer, mikrokernel, modul, mesin virtual, dan mesin virtual Java.
Laporan ini merangkum diagram konteks dan data flow diagram sistem informasi penjualan perusahaan rental komputer. Diagram konteks menggambarkan input dan output sistem seperti data order, barang, dan transaksi dari berbagai pihak. Sedangkan data flow diagram level 0 menggambarkan proses-proses utama sistem seperti pengolahan data order, barang, transaksi, pembelian, dan laporan.
Makalah Perancangan ERD & LRS Pada Sistem Pemesanan HotelMuhammad Iqbal
Makalah ini membahas perancangan Entity Relationship Diagram (ERD) dan Logical Relational Structure (LRS) untuk sistem pemesanan kamar hotel. Terdapat penjelasan tentang database, ERD, dan LRS. Kemudian dilakukan analisis kasus pemesanan kamar hotel untuk merancang ERD dan LRSnya.
Sistem Informasi Posko Keamanan bertujuan untuk mengembangkan aplikasi digitalisasi administrasi posko keamanan yang sebelumnya masih dilakukan secara manual. Aplikasi ini diharapkan dapat mempermudah pencatatan, rekap, dan penyimpanan data secara real-time serta meningkatkan transparansi dan ramah lingkungan melalui laporan digital. Proyek ini akan menghasilkan software, dokumentasi, dan laporan dengan anggaran Rp150 juta dan dijad
Moora adalah multiobjektif sistem mengoptimalkan dua atau lebih attribut yang saling bertentangan secara bersamaan. Metode ini diterapkan untuk memecahkan masalah dengan perhitungan matematika yang kompleks. Moora diperkenalkan oleh Brauers dan Zavadskas pada tahun 2006. Pada awalnya metode ini diperkenalkan oleh Brauers pada tahun 2004 sebagai “Multi-Objective Optimization” yang dapat digunakan untuk memecahkan berbagai masalah pengambilan keputusan yang rumit pada lingkungan pabrik.
Dokumen tersebut membahas tentang analisis proses bisnis yang mencakup definisi proses bisnis, komponen pembentuknya, lingkup pemodelan, dan analisis berbagai aspek seperti urutan proses, sumber daya, dan kebutuhan informasi untuk mendukung proses bisnis suatu organisasi."
Dokumen tersebut membahas tentang proses perancangan diagram entity-relationship (E-R) yang meliputi notasi dasar seperti entitas, atribut, relasi, dan garis penghubung serta kardinalitas hubungan satu banding satu, satu banding banyak, dan banyak banding banyak.
Analisis Kebutuhan (PR5) dalam pembahasan perancangan sistemjannatunaliyah1
Analisis Kebutuhan (PR5) dalam pembahasan perancangan sistem.
Pengembangan sistem informasi dilakukan untuk mendukung kegiatan bisnis dalam organisasi, tahapannya terdiri dari inisialisasi, analisis, desain, dan implementasi. Pengembangan sistem informasi dapat berupa pembuatan suatu sistem baru maupun penambahan atau perubahan modul pada system yang sudah ada. Secara umum, alur pengembangan suatu sistem informasimempunyai beberapa tahapan. Tahapan pengembangan sistem informasi sering kali disebut juga sebagai System Development Life Cycle (SDLC).
Makalah Perancangan ERD & LRS Pada Sistem Pemesanan HotelMuhammad Iqbal
Makalah ini membahas perancangan Entity Relationship Diagram (ERD) dan Logical Relational Structure (LRS) untuk sistem pemesanan kamar hotel. Terdapat penjelasan tentang database, ERD, dan LRS. Kemudian dilakukan analisis kasus pemesanan kamar hotel untuk merancang ERD dan LRSnya.
Sistem Informasi Posko Keamanan bertujuan untuk mengembangkan aplikasi digitalisasi administrasi posko keamanan yang sebelumnya masih dilakukan secara manual. Aplikasi ini diharapkan dapat mempermudah pencatatan, rekap, dan penyimpanan data secara real-time serta meningkatkan transparansi dan ramah lingkungan melalui laporan digital. Proyek ini akan menghasilkan software, dokumentasi, dan laporan dengan anggaran Rp150 juta dan dijad
Moora adalah multiobjektif sistem mengoptimalkan dua atau lebih attribut yang saling bertentangan secara bersamaan. Metode ini diterapkan untuk memecahkan masalah dengan perhitungan matematika yang kompleks. Moora diperkenalkan oleh Brauers dan Zavadskas pada tahun 2006. Pada awalnya metode ini diperkenalkan oleh Brauers pada tahun 2004 sebagai “Multi-Objective Optimization” yang dapat digunakan untuk memecahkan berbagai masalah pengambilan keputusan yang rumit pada lingkungan pabrik.
Dokumen tersebut membahas tentang analisis proses bisnis yang mencakup definisi proses bisnis, komponen pembentuknya, lingkup pemodelan, dan analisis berbagai aspek seperti urutan proses, sumber daya, dan kebutuhan informasi untuk mendukung proses bisnis suatu organisasi."
Dokumen tersebut membahas tentang proses perancangan diagram entity-relationship (E-R) yang meliputi notasi dasar seperti entitas, atribut, relasi, dan garis penghubung serta kardinalitas hubungan satu banding satu, satu banding banyak, dan banyak banding banyak.
Analisis Kebutuhan (PR5) dalam pembahasan perancangan sistemjannatunaliyah1
Analisis Kebutuhan (PR5) dalam pembahasan perancangan sistem.
Pengembangan sistem informasi dilakukan untuk mendukung kegiatan bisnis dalam organisasi, tahapannya terdiri dari inisialisasi, analisis, desain, dan implementasi. Pengembangan sistem informasi dapat berupa pembuatan suatu sistem baru maupun penambahan atau perubahan modul pada system yang sudah ada. Secara umum, alur pengembangan suatu sistem informasimempunyai beberapa tahapan. Tahapan pengembangan sistem informasi sering kali disebut juga sebagai System Development Life Cycle (SDLC).
Dokumen tersebut membahas tentang pembuatan disaster recovery plan standard. Dokumen tersebut menjelaskan bahwa disaster recovery plan dibutuhkan untuk menghindari kerusakan yang parah akibat bencana alam seperti gempa bumi dan tsunami. Dokumen tersebut juga menjelaskan komponen-komponen penting dalam disaster recovery plan seperti kontak personil, back up site, pedoman rencana, inventaris perangkat lunak dan keras, serta uji coba rencana.
Template dokumen Disaster Recovery Plan (DRP) dirancang berdasarkan kerangka kerja ISO 24762:2008 dan ISO 22301 untuk menyediakan pedoman pemulihan bencana bagi perusahaan. Template ini berisi form aset perusahaan, daftar manajemen pendukung, analisis risiko, prioritas risiko tinggi, dan prosedur penanganan darurat.
Aplikasi TrackIt dikembangkan untuk meningkatkan efektivitas pengiriman barang dan mengurangi keluhan masyarakat dengan melacak lokasi barang secara real-time berdasarkan nomor resi. Proyek ini akan menghasilkan dokumen desain sistem, spesifikasi persyaratan, arsitektur sistem, rencana pengujian, dan dokumentasi pengguna. Proyek ini dijadwalkan selesai pada 4 Juni 2017 dengan anggaran Rp200 juta
Kak sistem layanan keuangan negara inspektoratYoshima Putri
Dokumen ini membahas kerangka kerja sistem layanan keuangan negara yang akan dibuat untuk inspektorat. Sistem ini bertujuan untuk mempermudah proses layanan keuangan negara dan mengintegrasikan data keuangan secara online. Dokumen ini juga menjelaskan perancangan sistem, ruang lingkup, metodologi, jadwal, kualifikasi tenaga kerja yang dibutuhkan, dan laporan yang akan dibuat."
Sistem pengelolaan jasa notaris dan PPAT akan dibangun menggunakan model Rapid Application Development (RAD) karena memungkinkan penciptaan sistem fungsional utuh dalam waktu singkat. Model ini menekankan siklus pengembangan cepat dengan menggunakan pendekatan berbasis komponen yang dapat digunakan kembali.
Dokumen ini berisi panduan penulisan Deskripsi Perancangan Perangkat Lunak (DPPL) dengan pendekatan berorientasi proses. DPPL ini terdiri dari beberapa bagian utama yaitu pendahuluan, deskripsi perancangan, matriks keterunutan, dan informasi tambahan. Pendahuluan berisi tujuan, lingkup masalah, definisi, referensi, dan deskripsi umum dokumen. Deskripsi perancangan meliputi rancangan lingkungan implementasi, dekomposisi fung
Sistem ini bertujuan untuk melacak lokasi truk pengiriman barang PT. Ekspedisi Surabaya. Dokumen ini menjelaskan tujuan, lingkup, risiko, hasil yang diharapkan, jadwal, anggaran, dan struktur tim proyek sistem pelacakan truk pengiriman barang tersebut.
Sistem Informasi Koperasi Karyawan Stikom Surabaya bertujuan untuk meningkatkan efisiensi dan transparansi proses simpan pinjam serta manajemen koperasi secara keseluruhan dengan menggunakan sistem berbasis komputer. Proyek ini akan menghasilkan dokumen desain sistem, spesifikasi perangkat lunak, arsitektur sistem, rencana pengujian, dan dokumentasi pengguna. Proyek ini dijadwalkan selesai pada Desember 2011 dengan anggar
1. TEMPLATE PEMBUATAN DOKUMEN DRP
Template ini dibuat dengan berdasarkan langlah-langkah pada standar iso 22301 dan juga beberpa
langkah tambahan terkait dengan langkah DRP.
Adapun bab pembahasan ini berisikan tentang langkah-langkah pengerjaan dokumen disaster
recovery plan.
RIWAYAT REVISI
REVISI
Original 1.0
TANGGAL
NAMA
DESKRIPSI
1|P age
2. DAFTAR ISI
TEMPLATE PEMBUATAN DOKUMEN DRP .................................................................................... 1
1.
PLAN .............................................................................................................................................. 4
1.1.
PURPOSE ............................................................................................................................... 4
1.2.
SCOPE .................................................................................................................................... 4
1.3.
PLAN UPDATING ................................................................................................................. 4
1.4.
DEPENDENCIES ................................................................................................................... 4
1.5.
UNDERSTANDING THE ORGANIZATION ...................................................................... 5
1.5.1.
KEY PERSONNEL CONTACT INFO .......................................................................... 5
1.5.2.
EXTERNAL CONTACT ................................................................................................ 6
1.6.
ORGANIZATIONAL STRUCTURE..................................................................................... 6
1.7.
ANALYZE THE EXISTING SYSTEM ................................................................................. 6
1.7.1.
TRANSLATE STRATEGIES INTO PLAN .................................................................. 7
1.7.2.
BACKUP STRATEGY................................................................................................... 7
1.8.
LEADERSHIP AND PROJECT APPROVAL....................................................................... 7
1.9.
DISASTER RECOVERY POLICY........................................................................................ 7
1.10.
1.11.
2.
BUSINESS IMPACT ANALYSIS ..................................................................................... 7
RISK ASSESSMENT ......................................................................................................... 8
DO ................................................................................................................................................... 8
2.1
DISASTER RECOVERY STRATEGY ................................................................................. 8
2.2
BUSINESS CONTINUITY STRATEGY .............................................................................. 9
2.3
DISASTER RECOVERY PROCEDURE .............................................................................. 9
2.3.1.
RESPONSE PHASE ....................................................................................................... 9
2.3.2.
RESUMPTION PHASE ............................................................................................... 10
2.3.3.
RESTORATION PHASE ............................................................................................. 13
2.4
DOCUMENT MANAGEMENT .......................................................................................... 14
2.4.1
2.5
3.
PLAN DOCUMENTATION STORAGE ..................................................................... 14
COMMUNICATION ............................................................................................................ 14
CHECK ......................................................................................................................................... 14
3.1
3.2
INTERNAL AUDIT ............................................................................................................. 15
3.3
4.
MONITORING, MEASUREMENT, ANALYSIS AND EVALUATION ......................... 14
MANAGEMENT REVIEW ................................................................................................. 16
ACT............................................................................................................................................... 16
4.1.
4.2.
5.
TREATMENT OF NON-CONFORMTIES ......................................................................... 16
CONTINUAL IMPROVEMENT ......................................................................................... 16
APPENDIX A : DISASTER RECOVERY CONTACT- ADMIN CONTACT LIST ................. 16
2|P age
3. 6.
APPENDIX B : SUGGESTED FORM ........................................................................................ 19
3|P age
4. 1. PLAN
1.1.
PURPOSE
Penjelasan mengenai apa tujuan dibentuknya rancangan dokumen ini
1.2.
SCOPE
Tahapan yang berisikan tentang pendefinisan ruang lingkup dan obejctve dari
pembentukan dokumen ini beserta stndart yang digunakan
1.3.
PLAN UPDATING
Berisikan pembaruan-pembaruan apa saja yang terjadi pada DRP agar
memudahkan dalam proses pengujian
1.4.
DEPENDENCIES
Tahapan ini berisikan tentang penguraian ketergantungan suatu key bisni proses
selama pengembangan rencana pemulian bencana, dan apabila diperlukannya
bantuan maka tim DR akan berkodinasi dengan mitra-mitra untuk melakukan
pemulihan
Dependency
User Interface / Rendering
Presentation components
Assumptions
Users (end users, power users, administrators) are unable to access
the system through any part of the instance (e.g. client or server
side, web interface or downloaded application).
Infrastructure and back-end services are still assumed to be
active/running.
Business Intelligence /
Reporting
Processing components
The collection, logging, filtering, and delivery of reported
information to end users is not functioning (with or without the
user interface layer also being impacted).
Standard backup processes (e.g. tape backups) are not impacted,
but the active / passive or mirrored processes are not functioning.
Specific types of disruptions could include components that
process, match and transforms information from the other layers.
This includes business transaction processing, report processing
and data parsing.
Network Layers
Infrastructure components
Connectivity to network resources is compromised and/or
significant latency issues in the network exist that result in
lowered performance in other layers.
Assumption is that terminal connections, serially attached devices
and inputs are still functional.
Loss of SAN, local area storage, or other storage component.
Storage Layer
Infrastructure components
Database Layer
Database storage
components
Hardware/Host Layer
Hardware components
Virtualizations (VM's)
Virtual Layer
Data within the data stores is compromised and is either
inaccessible, corrupt, or unavailable
Physical components are unavailable or affected by a given event
Virtual components are unavailable
Hardware and hosting services are accessible
4|P age
5. Administration
Infrastructure Layer
Support functions are disabled such as management services,
backup services, and log transfer functions.
Other services are presumed functional
Internal/External
Dependencies
Interfaces and intersystem communications corrupt or
compromised
.
1.5.
UNDERSTANDING THE ORGANIZATION
Tahapan yang berisikan tentang segala hal yang berkaitan dengan informasi internal
dan external perusahaan.
1.5.1. KEY PERSONNEL CONTACT INFO
Berisikan segala bentuk informasi seluruh perssonal atau pegawai yang
memiliki peranan penting dalam perusahaan.
Name, Title
Contact Option
Contact Number
Work
Alternate
Mobile
Home
Email Address
Alternate Email
Work
Alternate
Mobile
Home
Email Address
Alternate Email
5|P age
6. 1.5.2.
EXTERNAL CONTACT
Berisikan informasi-informasi yang berkaitan dengan external perusahaan
seperti supplier, vendor, dan sebagainya
Name, Title
Contact Option
Contact Number
Landlord / Property Manager
Hardware Supplier 1
Work
Mobile
Home
Email Address
1.6.
ORGANIZATIONAL STRUCTURE
Tahapan yang berisikan struktur perusahaan secara detail mulai dari jabatan hingga
peran dan tanggung jawab manajemen
1.7.
ANALYZE THE EXISTING SYSTEM
Tahapan ini berisikan analisa terkait dengan sistem yang berada di perusahaan
mulai dari identifikasi resiko sampai dengan penentuan skor terhadap penilaian
sistem yang diterapkan oleh perusahaan.
Critical
System
RTO/RPO
Threat
Prevention
Strategy
Response
Strategy
Recovery
Strategy
6|P age
7. 1.7.1.
TRANSLATE STRATEGIES INTO PLAN
Tahapan untuk menerjemahkan pengembagan rencana pemulian bencana
startegis dengan penambahan Response action steps dan Recovery action
steps.
Critical
System
1.7.2.
Threat
Response
Strategy
Response
action
steps
Recovery
Strategy
Recovery
action
steps
BACKUP STRATEGY
Beberapa perencanaan strategi backup demi upaya melindungi aset dan kunci
proses bisnis perushaan.
KEY BUSINESS PROCESS
1.8.
BACKUP STRATEGY
LEADERSHIP AND PROJECT APPROVAL
Tahapan tentang keputusan yang diambil oleh top managemen untuk memberikan
program kepemimpinan untuk seluruh orang agar dapat memahami peran dan
tanggung jawab serta kemampuan diri masing-masing.
1.9.
DISASTER RECOVERY POLICY
Tahapan yang berisikan kebijakan-kebijakan apa saja yang terkait dengan Businerss
continuity
1.10. BUSINESS IMPACT ANALYSIS
Tahapan yang berisikan proses analisa mengenai pengidentifikasian resiko terhadap
proses utama dari bisnis yang saling bersangkutan satu sama lain, dan juga
memberikan analisa terkait dampak yang terjadi pad setiap resiko tersebut.
7|P age
8. 1.11. RISK ASSESSMENT
Tahapan yang berisikan mengenai proses penilaian resiko ketika terjadi bencana
terhadap proses BSCM
Potential Disaster
Brief Description Of Potential
Consequences & Remedial Actions
Probability Rating
Impact Rating
Flood
3
4
All critical equipment is located on
1st Floor
Fire
3
4
FM200 suppression system installed
in main computer centers. Fire and
smoke detectors on all floors.
Probability: 1=Very High, 5=Very Low ,Impact:
annoyance
1=Total
destruction,
5=Minor
2. DO
2.1
DISASTER RECOVERY STRATEGY
Tahapan yang berisikan berapa rincian rencana beserta skenario yang akan
diimplementasikan ketika proses pemulihan bencana.
Gangguan Data Center
FAILOVER untuk alternative data center
Mengalihkan proses inti ke data center (
tanpa full FAILOVER)
Gangguan terhadap dependensi
(Internal or External)
Mengalihkan fungsi inti ke penyedia layanan
backup/ alternative
Berpartisipasi dalam strategi pemulihan yang
tela tersedia
Operate service level
Take no action
Menunggu untuk pemulihan
layanan, menyediakan komunikasi yang
dibutuhkan kepada para stakeholder
8|P age
9. 2.2
BUSINESS CONTINUITY STRATEGY
Tahapan yang berisikan panduan untuk mengembangkan seluruh strategi dari
Business Continuity dan juga pendefinisian setiap rencana yang dibentuk termasuk
kemampuan evaluasi dari setiap kegiatan Business Continuity
2.3
DISASTER RECOVERY PROCEDURE
Tahapan yang berisikan prosedur yang dibentuk berdasarkan disaster recovery
yanng mana memiliki 3 fase yaitu response, resumpsion, dan restoration
Response Phase: Tindakan langsung setelah terjadinya bencana
•Panggilan cepat
•Keputusan yang diambil untuk strategi pemulihan
•Telah diidentifikasi penuh oleh tim pemulihan
Resumption Phase: Tindakan yang diperlukan untuk
melanjutkan layanan setelah adanya pemberitahuan
•Telah diimplementasikannya prosedur pemulihan
•Berkordinasi dengan departemen lain ketika dibutuhkan
Restoration Phase: Tugas yang diambil untuk mengembalikan
layanan seperti sebelumnya
•Pelaksanaan prosedur rollback
•Operasi telah dipulihkan
2.3.1. RESPONSE PHASE
Tahapan yang berisikan pencatatan seluruh kegiatan beserta komponenkomponennya.
Step
Identify issue, page on
call / Designated
Responsible Individual
(DR TEAM)
Identify the team
members needed for
recovery
Owner
DR
TEAM
Duration
x minutes
Components
Issue communicated / escalated
Priority set
DR
TEAM
x minutes
Selection of core team members required for
restoration phase from among the following
groups:
Operations
9|P age
10. 2.3.2. RESUMPTION PHASE
Selama fase resumption, ada bermacam-macam langkah-langkah yang
diambil untuk mengaktifkan pemulihan berdasarkan jenis masalah.
2.3.2.1. DATA CENTER RECOVERY
Step
Initiate Failover
Complete Failover
Test Recovery
Failover deemed
successful
2.3.2.1.1. FULL DATA CENTER FAILOVER
Owner
Duration
Components
DR
TBD
Restoration procedures identified
TEAM
Risks assessed for each procedure
Coordination points between groups defined
Issue communication process and triage
efforts established
DR
TBD
Recovery steps executed, including
TEAM
handoffs between key dependencies
DR
TBD
Tests assigned and performed
TEAM
Results summarized and communicated to
group
DR
TBD
TEAM
10 | P a g e
11. Gambar dibawah ini adalah salah satu contoh timeline untuk tindakan recovery yang terkait dengan
komponen teknis pada FAILOVER.
Sample Recovery Timeline
T+ 15
T+30
T+45
Recovery Complete
Failback Begins
T+ 15
T+30
T+45
Failback Ends
Detect/Report
Event
Redirect Traffic to
Alternate Data
Center
Redirect traffic to
rebuilt DB and
servers
Failover Database
to Alternate Data
Center
Redirect Internal
Interfaces to
Failover DB
Redirect Internal
Interfaces to
Rebuilt Primary
DB
Redirect External
Interfaces to
Failover DB
Redirect External
Interfaces to
Rebuilt Primary
DB
<Function>
Internal
Dependencies
Rebuild Primary
DB
External
Dependencies
DB Layer
GFS/Network
Layer
Operations
Event Instantiation
Step
Failover UI layer to
backup services
and redirect to
failover DB
Failback UI Layer
to Rebuilt Primary
DB
2.3.2.1.2. REROUTE CRITICAL PROCESSES TO
ALTERNATE DATA CENTER
Owner
Duration
Components
11 | P a g e
12. 2.3.2.1.3. OPERATE SERVICE LEVEL
Owner
Duration
Components
Step
2.3.2.1.4.
Step
Track communication and
status with the core
recovery team.
Send out frequent updates
to core stakeholders with
the status.
2.3.2.2.
Owner
DR
TEAM
Duration
As needed
DR
TEAM
As needed
Components
INTERNAL OR EXTERNAL DEPENDENCY RECOVERY
2.3.2.2.1
Step
TAKE NO ACTION- MONITOR FOR DATA CENTER
RECOVERY
Prosedur ini hanya akn menjadi alternative pilihan jika tidak ada
pilihan lain
REROUTE OPERATIONS TO BACKUPS PROVIDER
Tahapan pengalihan operasi ke penyedia layanan backup
Owner
Duration
Components
2.3.2.2.2 EXECUTE AVAILABLE RECOVERY PROCEDURES
Step
Owner
Duration
Components
Inform other teams about
DR
As needed
technical dependencies
TEAM
DR
As needed
TEAM
2.3.2.2.3
Step
Track communication and
status with the core
recovery team.
Send out frequent updates
to core stakeholders with
the status.
TAKE NO ACTION- MONITOR STATUS
Prosedur ini hanya akn menjadi alternative pilihan jika tidak ada
pilihan lain
Owner
DR
TEAM
Duration
As needed
DR
TEAM
Components
Provide feedback about SharePoint service
availability
As needed
12 | P a g e
13. 2.3.3. RESTORATION PHASE
2.3.3.1 DATA CENTER RECOVERY
Step
Determine whether
failback to original Data
Center will be pursued
Original data center
restored
Complete Failback
2.3.3.1.1. FULL DATA CENTER RESTORATION
Owner
Duration
Components
DR TEAM TBD
Restoration procedures determined
DR TEAM
TBD
Server Farm level recovery
DR Team
TBD
Test Failback
DR Team
TBD
Determine whether
failback was successful
DR TEAM
TBD
Failback steps executed, including handoffs
between key dependencies
Tests assigned and performed
Results summarized and communicated to
group
Issues (if any) communicated to group
Declaration of successful failback and
communication to stakeholder group.
Disaster recovery procedures closed.
Results summarized, post mortem
performed, and DRP updated (as needed).
2.3.3.2 INTERNAL OR EXTERNAL DEPENDENCY RECOVERY
2.3.3.2.1. EXECUTE AVAILABLE RECOVERY PROCEDURES
Step
Owner
DR TEAM
DR TEAM
Duration
As needed
As needed
Components
2.3.3.2.2. TAKE NO ACTION- MONITOR STATUS
Prosedur ini hanya akan menjadi alternative pilihan jika tidak ada
pilihan lain
Step
Track communication and
status with the core
recovery team.
Send out frequent
updates to core
stakeholders with the
status.
Owner
DR TEAM
Duration
Components
As needed
Provide feedback about SharePoint
service availability
DR TEAM
As needed
13 | P a g e
14. 2.4
DOCUMENT MANAGEMENT
Tahapan yang berisikan rencana bagaimana mengelola dokumen terkait dengan
proses dari BCMS
2.4.1 PLAN DOCUMENTATION STORAGE
Rencana untuk mengalokasikan data hasil backup ke dalam sebuah CD atau
berupa hard copy yang akan diterapkan untuk seluruh pegawai.
2.5
COMMUNICATION
Tahapan dimana akan dibentuknya komunikasi terhadap perusahaan dan juga
menentukan beberapa metode, waktu dan conten yang dibutuhkan dalam
peimplementasiannya.
Berikut adalah form untuk metode penunjukan orang dalam hal mengkomunikasikan
informasi.
Persons Selected To Coordinate Communications
Groups of Persons or
Organizations Affected
by Disruption
to Affected Persons / Organizations
Name
Position
Contact Details
Customers
Management & Staff
Suppliers
Media
Stakeholders
Others
3. CHECK
3.1
MONITORING, MEASUREMENT, ANALYSIS AND
EVALUATION
Tahapan yang berisikan beberapa tindakan untuk menindak lanjuti bebeapa kegiatan
yang berkaitan dengan pemulihan bencana yang mana akan dilakukan analisis,
pengukuran dan evaluasi pada tahap ini. Semua dampak beserta tingkat
kerusakannya akan dilakukan evaluasi dan pencatatan untuk mengetahui seberapa
besar dampak bagi perusahaan..
14 | P a g e
15. Berikut adalah salah satu form yang digunakan untuk melakukan proses monitoring
terhadap seluruh kegiatan pemulihan pasca bencana.
Tanggal Penyelesaian
Tugas Recovery
Penanggung Jawab
(Berdasarkan prioritas)
Estimasi
Aktual
Kejadian
yang
teridentifikasi
Informasi lain yang
relevan
1.
2.
3.
4.
5.
6.
7.
3.2
INTERNAL AUDIT
Tahapan yang berisikan pencatatan segala bentuk kegiatan guna dilakukannya
evaluasi bagi perusahaan.
Dampak terhadap Key Bisnis
Deskripsi masalah
Tingkat kerusakan
15 | P a g e
16. 3.3
MANAGEMENT REVIEW
Tahapan yang berisikan tentang strategi oleh pihak managemen dalam melakukan
peninjiaun ulang terhadap hasil audit yang sudah dilakukan. Dan juga akan
ditentukan beberapa kebijakan terkait dengan perubahan-perubahan yang terjadi
setelah dilakukannya audit.
4. ACT
4.1.
TREATMENT OF NON-CONFORMTIES
Tahapan yang berisikan beberapa proses identifikasi evaluasi terkait apa reaksi yang
terjadi apabila dibentuknya beberapa kebijakan untuk mengatasi beberapa hal dari
hasil audit perusahaan pasca bencana.
4.2.
CONTINUAL IMPROVEMENT
Tahapan ini beriskan beberapa proses yang bertujuan untuk memastikan bahwasanya
business continuity management masih berlangsung dengan baik dan memiliki
peningkatan kinerja pasca bencana.
5. APPENDIX A : DISASTER RECOVERY CONTACT- ADMIN CONTACT
LIST
Adanya anggota tim yang memiliki status kritis maka akan dilibatkan dalam prosedur
pemulihan untuk dilakukknya feature set ( pe istimewaan) .
Feature Name
Contact Lists
Kunci utama Internal dan External dependensi yang telah diidentifikasi akan dilakukan
pencatatan pada form di bawah ini.
Dependency Name
Contact Information
16 | P a g e
17. Berikut adalah form untuk Disaster Recovery plan pada sistem perusahaan.
SYSTEM
OVERVIEW
PRODUCTION SERVER
HOT SITE SERVER
APPLICATIONS
(Use bold for Hot Site)
ASSOCIATED SERVERS
Location:
Server Model:
Operating System:
CPUs:
Memory:
Total Disk:
System Handle:
System Serial #:
DNS Entry:
IP Address:
Other:
Provide details
KEY CONTACTS
Hardware Vendor
System Owners
Database Owner
Application Owners
Software Vendors
Offsite Storage
Provide details
Provide details
Provide details
Provide details
Provide details
Provide details
BACKUP STRATEGY FOR
SYSTEM ONE
Daily
Monthly
Quarterly
Provide details
Provide details
Provide details
SYSTEM ONE
DISASTER RECOVERY
PROCEDURE
Provide details
Scenario 1
Total Loss of Data
Provide details
Scenario 2
Total Loss of HW
17 | P a g e
18. Berikut adalah form untuk Voice Communication Disaster Recovery plan di perusahaan
SYSTEM
OVERVIEW
EQUIPMENT
HOT SITE EQUIPMENT
SPECIAL APPLICATIONS
ASSOCIATED DEVICES
Location:
Device Type:
Model No.:
Technical Specifications:
Network Interfaces:
Power Requirements;
System Serial #:
DNS Entry:
IP Address:
Other:
Provide details
KEY CONTACTS
Hardware Vendor
System Owners
Database Owner
Application Owners
Software Vendors
Offsite Storage
Network Services
Provide details
Provide details
Provide details
Provide details
Provide details
Provide details
Provide details
BACKUP STRATEGY for
SYSTEM TWO
Daily
Monthly
Quarterly
Provide details
Provide details
Provide details
SYSTEM TWO
DISASTER RECOVERY
PROCEDURE
Provide details
Scenario 1
Total Loss of Switch
Provide details
Scenario 2
Total Loss of Network
18 | P a g e
19. 6. APPENDIX B : SUGGESTED FORM
Bagian ini mengidentifikasi peran dan tanggung jawab setiap individu untuk menjaga proses
disaster recovery plan berjalan dengan baik.
Pemilik utama dokumen Disaster Recovery Plan adalah :
Orang pertama :
Alternative :
Nama orang yang
memperbarui
dokumen
[Nama]
Tanggal
Deskripsi Pembaruan
Versi #
Di setujui oleh
19 | P a g e
20. Bagian ini berisikan tentang Mangement of DR Activities Form
Selama proses pemulihan bencana seluruh kegiatan akan ditentukan dengan standart
yang digunakan
Akan dilakukan perbaruan secara berkala selama proses pemulihan bencana
Semua tindakan pada seluruh fase akan dilakukan pencatatan
Nama Kegiatan :
Nomor Referensi :
Diskripsi Singkat :
Tanggal & Waktu
Mulai
Tanggal & Waktu
Penyelesaian
Sumber Daya yang
terlibat
Penanggung Jawab
( TANDA TANGAN KORDINATOR )
__________________
20 | P a g e
21. Bagian ini berisikan tentang Disaster Recovery Event recording Form
Seluruh kegiatan pada fase pemulihan bencana harus dicatat
Semua Log Event akan dilakukan pengelolaan oleh pemimpin disaster recovery team
Deskripsi Bencana :
Tanggal mulai :
Tanggal & Waktu pengarahan DR Team :
Kegiatan yang diambil alih oleh DR
Team
Tanggal &
Waktu
Akibat
Tindakan perbaikan
yang diperlukan
Disaster Recovery Team's Work Completed: < Tanggal >
Event Log Passed to Business Recovery Team: < Tanggal >
( TANDA TANGAN KORDINATOR )
__________________
21 | P a g e
22. Bagian ini berisikan tentang Mobilizing The Disaster Recovery Team Form
Format yang digunakan untuk merekam aktivitas yang diambil alih oleh anggota DRT bahwa seluruh
pkerjaan dapat terselesaikan
Deskripsi keadaan darurat :
Tanggal kejadian :
Tanggal Penyelesaian pekerjaan Disaster Recovery Team :
Nama anggota
tim
Detail Kontak
Dihubungi
pada (Tanggal
/Waktu)
Oleh Siapa
Tanggapan
Tanggal
dimulainya
kebutuhan
KOMENTAR :
( TANDA TANGAN KORDINATOR )
__________________
22 | P a g e
23. Bagian ini berisikan tentang Mobilizing The Business Recovery Team Form
Format yang digunakan untuk merekam aktivitas yang diambil alih oleh anggota DRT bahwa seluruh
pkerjaan dapat terselesaikan
Deskripsi keadaan darurat :
Tanggal kejadian :
Tanggal Penyelesaian pekerjaan Business Recovery Team :
Nama anggota
tim
Detail Kontak
Dihubungi
pada (Tanggal
/Waktu)
Oleh Siapa
Tanggapan
Tanggal
dimulainya
kebutuhan
KOMENTAR :
( TANDA TANGAN KORDINATOR )
__________________
23 | P a g e
24. Bagian ini berisikan tentang BUSINESS PROCESS RECOVERY COMPLETION
FORM
Formulir transisi berikut adalah bukti penyelesaian tugas oleh Recovery Team yang disahkan
oleh penandatanganan antara ketua tim dan Pemimpin perusahaan. Form ini dapat disetujui
apabila adanya bukti bahwa setiap proses aktivitas sudah terpulihkan dari bencana.
Name Bisnis Proses
Tanggal Penyelesaian Tugas oleh Business Recovery Team
Tanggal Pengembalian Transisi kepadaUnit Management Bisnis
(Kolom ini berbeda dari kolom penyelesaian)
Saya mengkonfirmasikan bahwa tugas dari Business recovery Team telah selesai pada waktu
yang direncanakan pada Disaster Recovery Plan untuk setiap proses di atas, dan juga bisnis
operasional telah berjalan normal kembali secara efektif.
Nama Pemimpin Business Recovery Team: ________________________________________
Tanda Tangan : ________________________________________________________________
Tanggal : __________________________
(Setiap komentar yang relevan oleh pemimpin BRT akan berhubungannya dengan pengembalian
proses bisnis yang seharusnya di buat disini.)
Saya mengkonfirmasikan bahwa proses bisnis di atas dapat diterima dalam kondisi normal.
Nama : ___________________________________________________________________
Judul : ____________________________________________________________________
Tanda Tangan : ________________________________________________________________
Tanggal : __________________________
24 | P a g e
25. REFERENSI
iso22301. (2001, juni). Dipetik january 2014, dari pecb.org: pecb.org/iso22301
microsoft. (2012, Maret). blogs.technet.com. Dipetik january 2014, dari blogs.technet.com:
http://blogs.technet.com/b/mspfe/archive/2012/03/08/a_2d00_microsoft_2d00_word_2d00_d
ocument_2d00_template_2d00_for_2d00_disaster_2d00_recovery_2d00_planning.aspx
25 | P a g e