Perbedaan BCP dan DRP

Terdapat definisi yang mengatakan bahwa BCP adalah terkait dengan segala sesuatu yang berhubungan dengan usaha untuk mempertahankan kelangsungan business process suatu unit kerja atau organisasi sedangkan DRP adalah terkait dengan segala sesuatu yang berhubungan dengan usaha untuk mempertahankan kelangsungan proses sistem produksi teknologi informasi, meskipun di dalam singkatan DRP sama sekali tidak ada kata IT, tetapi itulah kira-kira definisi yang berlaku dan kebanyakan orang cenderung untuk setuju dan mengikuti persepsi seperti itu karena dirasakan definisi tersebut praktis dan sederhana.


Kelihatannya perlu ada tinjauan kembali mengenai defininsi di atas. Jangan-jangan penggunaan definisi tersebut dilakukan tanpa dipikirkan secara mendalam, mari kita tinjau kembali penggunaan istilah atau definisi tersebut. Sebetulnya Business Continuity Plan dan Disaster Recovery Plan adalah dua hal yang kurang lebih arti atau maksud dan tujuannya sama tetapi sudut pandangnya saja yang berbeda. BCP ibaratnya adalah bagaimana cara menjaga kesehatan seseorang atau bagaimana cara menjaga kelangsungan hidup dan DRP adalah bagaimana tata cara melakukan penyembuhan.
Jadi sebetulnya kurang cocok jika dikatakan bahwa BCP adalah segala sesuatu yang berhubungan dengan usaha untuk mempertahankan kelangsungan business process suatu unit kerja atau organisasi dan DRP adalah segala sesuatu yang berhubungan dengan usaha untuk mempertahankan kelangsungan proses sistem produksi teknologi informasi.
Mungkin yang lebih tepat adalah bahwa Company Wide Business Continuity Plan adalah kurang lebih sama dengan Company Wide Disaster Recovery Plan dan IT Operation Continuity Plan sama dengan IT Operation Disaster Recovery Plan. IT Operation Continuity Plan merupakan bagian dari Company Wide Business Continuity Plan atau IT Operation Disaster Recovery Plan adalah bagian dari Company Wide Disaster Recovery Plan.
Ada juga yang mengatakan bahwa BCP adalah mengenai pembuatan perencanaan dan frame-work untuk menjamin bahwa proses bisnis dapat terus berlanjut dalam keadaan emergensi. Sedangkan DRP adalah mengenai pemulihan cepat dari keadaan emergensi atau bencana, sehingga hanya mengakibatkan dampak minimum bagi organisasi atau perusahaan.
Ada kegiatan yang diberi nama disaster recovery test, tetapi apakah business continuity test merupakan istilah yang tepat?, ada yang lebih memilih dengan istilah crisis simulated test sebagai pengganti istilah business continuity test.
Terlepas dari apakah istilah BCP dan DRP itu tepat atau tidak, untuk sementara marilah kita kembali ke definisi di atas yang mengatakan bahwa BCP adalah terkait dengan segala sesuatu yang berhubungan dengan usaha untuk mempertahankan kelangsungan business process suatu unit kerja atau organisasi sedangkan DRP adalah terkait dengan segala sesuatu yang berhubungan dengan usaha untuk mempertahankan kelangsungan proses sistem produksi teknologi informasi.
Untuk melihat perbedaan BCP dengan DRP dapat dilakukan dengan melihat dan menganalisa secara langsung dari pengalaman secara nyata pada saat melakukan BCP test dan DRP test.
Berikut ini adalah contoh rincian kegiatan yang dilakuan pada saat melakukan BCP test dan DRP test. Dengan melihat dan menganalisa seluruh rincian kegiatan tersebut diharapkan kita akan melihat dan memahami perbedaan antara BCP dan DRP.

BCP Test
Pada saat melakukan BCP test, contoh urutan kegiatannya adalah sebagai berikut : diumumkan keadaan dalam kondisi darurat/bencana, seluruh pegawai perlu dievakuasi dan berkumpul di assembly point, BCP coordinator memberikan arahan, pegawai berangkat ke alternate site, pegawai melakukan persiapan di alternate site untuk melakukan pekerjaan, menjalankan test script, selesai.
Di dalam BCP test, kegiatannya cenderung melibatkan personil seluruh level yang ada di dalam suatu organisasi, kegiatannya diutamakan pada penyelamatan personil kemudian dilanjutkan pada pemulihan proses bisnis, mulai dari deklarasi keadaan dalam kondisi darurat/bencana, seluruh pegawai perlu dievakuasi keluar gedung yang dipandu oleh floor marshal dan berkumpul di assembly point, BCP coordinator memberikan arahan, pegawai berangkat ke alternate site, pegawai melakukan persiapan di alternate site untuk melakukan pekerjaan, menjalankan test script, selesai.

DRP Test
Saat melakukan DRP test kira-kira contoh urutan kegiatannya adalah sebagai berikut : diumumkan keadaan dalam kondisi darurat/bencana, pindahkan operasi IT dari main data center ke disaster recovery center (DRC), lakukan test script di DRC, setelah test script selesai dilakukan pindahkan operasi IT dari DRC ke main data center, selesai.
Berbeda dengan BCP test, pada saat DRP test, setelah diumumkan keadaan dalam kondisi darurat/bencana, kegiatan lebih difokuskan pada pemulihan operasional IT, kegiatannya adalah langsung memindahkan operasi IT dari main data center ke disaster recovery center (DRC), kemudian selanjutnya melakukan test script di DRC, setelah test selesai pindahkan operasi IT dari DRC ke main data center, selesai.
Dari penjelasan secara langsung dari pengalaman melakukan BCP test dan DRP test tersebut di atas mudah-mudahan dapat dilihat dan dipahami secara jelas perbedaan antara BCP dan DRP tanpa harus mempelajari dan memahami dari teori.

Membangun IT Quality Assurance

Artikel ini menceritakan pengalaman penulis dalam membangun unit kerja IT Quality Assurance di dalam suatu perusahaan.
Apa itu IT Quality Assurance (ITQA) ?. Mengapa harus ada ITQA?. Dalam memahami ITQA kebanyakan orang masih sering tertukar dengan IT Quality Control (ITQC).
Apa bedanya ITQA dengan ITQC?. QA focus kepada process untuk menghasilkan produk, sedangkan QC focus kepada produk yang dihasilkan. QA cenderung defect  prevention, sedangkan QC cenderung defect detection. Untuk melihat perbedaan QA dengan QC dan dapat dilihat pada bahasan tentang QA vs QC.



Pada saat awal, memang agak sulit juga untuk meyakinkan orang-orang, bahwa pengertian ITQA berbeda dengan ITQC. Sering orang mengira bahwa ITQA harus terlibat dalam setiap proses produksi IT, padahal seharusnya ITQA lebih focus pada proses untuk menghasilkan produk IT tersebut, tugas ITQA seharusnya  adalah mendefinisikan proses, review efektifitas proses. Area yang menjadi perhatian ITQA dapat dilihat pada artikel IT Quality Assurance.
Kadang-kadang salah pengertian tentang QA vs QC tersebut disalahgunakan baik disadari ataupun tidak. Contohnya dalam area pengembangan aplikasi, karena ada salah pengertian tentang fungsi ITQA, unit kerja ITQA ditugaskan untuk memastikan kualitas sistem aplikasi yang akan masuk ke produksi dengan cara diminta untuk melakukan review aplikasi tersebut, dengan segala macam cara unit kerja tersebut bekerja keras berusaha memastikan kualitas dari aplikasi tersebut. Sebetulnya hal tersebut tidak akan pernah efektif, karena sebetulnya yang bertanggungjawab terhadap kualitas suatu produk adalah si pembuat produk tersebut.
Di mana letak penyalahgunaannya?. Karena unit kerja ITQA dianggap yang paling bertanggungjawab terhadap kualitas produk, maka jika terjadi kesalahan pada produk tersebut maka ITQA yang disalahkan, bukan si pembuat produk tersebut.
Kembali ke contoh ITQA yang berusaha untuk melakukan review terhadap kualitas aplikasi, usaha tersebut berdasarkan pengalaman sangat-sangat tidak efektif, mengapa?.
Karena dapat dibayangkan bagaimana ada orang lain selain si pembuat program aplikasi yang berusaha untuk melakukan pemeriksaan kualitas program, padahal seperti diketahui seorang programmer akan selalu mengerahkan usaha dan upayanya untuk memastikan bahwa kualitas program yang dibuatnya memenuhi harapan sehingga keterkaitan “emosional” antara program dengan programmernya sangat erat, bagaimana mungkin petugas ITQA dapat menyaingi programmer dalam hal keterkaitan “emosional” dengan program yang dibuat?.
Seorang programmer akan mengetahui dengan pasti seluk-beluk sampai ke yang rinci dari program yang dibuatnya, tetapi petugas ITQA pasti tidak akan mampu menyaingi si programmer.
Jika diinginkan, akan dengan mudahnya seorang programmer mengganti titik dengan koma atau sebaliknya dari suatu program, dan petugas ITQA kemungkinan besar tidak akan dapat melacaknya. Itulah sebabnya usaha untuk membentuk ITQA yang secara langsung memeriksa/memastikan kualitas suatu produk tidak akan pernah efektif, karena sebetulnya yang bertanggungjawab terhadap kualitas suatu produk adalah si pembuat produk tersebut.
Lalu apa yang seharusnya dilakukan?.
Dalam contoh pengembangan aplikasi, terdapat tiga kegiatan utama yaitu Software Management, Software Engineering dan Software Assurance.
Lalu bagaimana Quality Assurance masuk ke dalam proses pengembangan aplikasi?.
Adanya usaha untuk melakukan pengembangan aplikasi sesuai best pratices atau ketentuan yang berlaku adalah merupakan salah satu contoh implementasi dari IT Quality Assurance. Disamping itu aspek quality assurance dalam kegiatan pengembangan aplikasi juga dapat dimasukkan ke dalam software specification dan software design.
Demikian pula adanya usaha untuk melakukan pengelolaan operasional, network dan security IT sesuai best pratices atau ketentuan yang berlaku adalah merupakan salah satu contoh implementasi dari IT Quality Assurance.
Komponen dari IT Quality Assurance adalah IT Management, IT Confidentiality, IT Integrity dan IT Availability. Dilihat dari komponen-komponen di atas terlihat bahwa cakupan IT Quality Assurance sangat luas bahkan dapat dikatakan cakupan dari IT Quality Assurance adalah seluruh area yang ada di IT.
Bagaimana cakupan yang luas tersebut dapat tertangani oleh fungsi IT Quality Assurance?. Itulah pentingnya dipahami bahwa fokus dari IT Quality Assuarnce adalah pada proses untuk menghasilkan suatu produk, bukan fokus pada produk yang dihasilkan. Fungsi yang fokus pada produk yang dihasilkan adalah IT Quality Control.
Keberadaan IT Quality Assurance dalam suatu organisasi harus berbentuk suatu unit kerja yang permanen, tetapi keberadaan IT Quality Control dalam suatu organisasi tidak berbentuk suatu unit kerja yang permanen tetapi merupakan perwujudan dari adanya kepatuhan yang optimal untuk menerapkan proses yang telah ditetapkan dalam menghasilkan suatu produk.
Jika di dalam suatu organisasi seluruh proses yang diperlukan dalam menghasilkan produk terdefinisi dan tersedia dengan baik maka artinya quality assurance dari organisasi tersebut baik. Jika di dalam suatu organisasi kepatuhan terhadap implementasi proses untuk menghasilkan produk berjalan dengan baik maka artinya quality control dari organisasi tersebut baik.
Jika yang bertanggungjawab terhadap kualitas produk yang dihasilkan adalah ITQC, apakah ITQA tidak bertanggungjawab terhadap kualitas produk IT?, padahal pasti tujuan adanya ITQA adalah dalam rangka memastikan bahwa kualitas produk IT yang dihasilkan adalah sesuai dengan harapan.
Tentu saja ITQA bertanggungjawab terhadap kualitas produk IT. Seperti disebutkan di atas ITQA fokus pada proses untuk menghasilkan produk dan ITQA fokus pada produk yang dihasilkan.
Untuk memahami di mana letaknya tanggungjawab ITQA terhadap kualitas produk IT, mari kita memahaminya dengan melihat dari sudut pandang tanggung jawab, kewenangan dan pendelegasian. Seperti diketahui bahwa kewenangan dapat didelegasikan sedangkan tanggungjawab tidak dapat didelegasikan.
ITQA bertanggungjawab tehadap kualitas produk IT, bentuk implementasi pertanggungjawabannya adalah dengan cara ITQA mendelegasikan kewenangan memastikan kualitas tersebut melalui cara pendefinisian proses sedemikian rupa sehingga dapat menghasilkan produk yang berkualitas.
Jika produk yang dihasilkan tidak memenuhi persyaratan kualitas yang telah ditentukan, maka tugas ITQA untuk melakukan review dan koreksi (jika diperlukan) terhadap proses yang ada.

Apa tugas IT Quality Assurance?

Apa itu IT Quality Assurance (ITQA) ?. Dalam memahami ITQA kebanyakan orang masih sering tertukar dengan IT Quality Control (ITQC).
Awalnya memang agak sulit juga untuk meyakinkan orang-orang, bahwa pengertian ITQA berbeda dengan ITQC. Sering orang mengira bahwa ITQA harus terlibat dalam setiap proses produksi IT, padahal seharusnya ITQA lebih focus pada proses untuk menghasilkan produk IT tersebut, tugas ITQA seharusnya  adalah mendefinisikan proses, review efektifitas proses.



Kadang-kadang salah pengertian tentang QA vs QC tersebut disalahgunakan baik disadari ataupun tidak.
Contohnya dalam area pengembangan aplikasi, karena ada salah pengertian tentang fungsi ITQA, unit kerja ITQA sering ditugaskan untuk memastikan kualitas sistem aplikasi yang akan masuk ke produksi dengan cara diminta untuk melakukan review aplikasi tersebut, dengan segala macam cara unit kerja tersebut bekerja keras berusaha memastikan kualitas dari aplikasi tersebut.
Sebetulnya usaha dan kerja keras tersebut tidak akan pernah efektif, karena sebetulnya yang bertanggungjawab terhadap kualitas suatu produk adalah si pembuat produk tersebut.
QC fokus pada produk yang dihasilkan sedangkan QA fokus pada proses untuk menghasilkan produk, itulah inti perbedaan antara QC dan QA.

Meningkatkan citra departemen TI Anda

Terkadang citra stereotip dari departemen Anda membuat Anda terhambat di dalam menyelesaikan pekerjaan yang perlu Anda selesaikan. Silakan simak artikel di bawah ini mengenai cara untuk melawan citra tersebut untuk keuntungan karyawan dan perusahaan secara keseluruhan.
Bagi kita yang telah bekerja di industri IT, tentu kita juga menyadari citra departemen IT di kebanyakan perusahaan. Sombong, kasar, obstruktif, ini adalah hanya beberapa kata yang biasanya dikaitkan dengan IT. Stereotip-stereotip yang seperti ini dapat membatasi efektivitas dan membuat sulit bagi departemen TI Anda untuk melakukan tugasnya. Meningkatkan citra departemen TI Anda adalah sesuatu yang tidak hanya bermanfaat bagi karyawan Anda, tetapi juga bagi perusahaan secara keseluruhan.


Tunjukkan bahwa Anda adalah manusia
Kesalahan paling umum yang dibuat oleh departemen TI adalah bahwa mereka lupa bahwa mayoritas pekerjaan mereka adalah berbasis layanan pelanggan. Ini berarti bahwa ada banyak interaksi manusia yang dibutuhkan dan Anda harus belajar untuk berurusan dengan orang lain.
Terlalu sering, karena sebagian besar masalah IT dapat diselesaikan jarak jauh, anggota departemen TI akan menghabiskan hampir seluruh waktu mereka di kantor masing-masing. Hal ini penting untuk terlibat di kantor dan tidak bersembunyi di departemen IT.
Sering keluar dari departemen TI akan memberikan Anda kesempatan untuk bertemu dengan pengguna dan membangun hubungan dengan mereka. Hal ini juga memberi mereka kesempatan untuk menempatkan wajah dan nama ke departemen TI yang jauh lebih sulit untuk menempatkan konotasi negatif. Ini mungkin ide yang baik untuk sesekali pergi tatap-muka membantu para pengguna meskipun saat sedang tidak diperlukan karena ini akan membantu mereka memahami saat memperbaiki masalah IT. Hal ini akan membantu pengguna mengingat bahwa departemen TI terdiri dari manusia dan bukan sekelompok robot yang ajaib yang dapat menyelesaikan semua masalah mereka secara cepat.
Membangun hubungan yang baik dengan pengguna akan membuat segalanya lebih mudah bagi semua orang. Anda tidak akan terlalu frustrasi dengan permintaan mereka dan mereka juga akan lebih sabar dan menghargai usaha Anda untuk menemukan solusi bagi mereka.

Berkomunikasi dan mendidik
Menjaga komunikasi dengan pengguna serta terus mendidik mereka akan meningkatkan citra dan efisiensi departemen TI Anda.
Komunikasi adalah sesuatu yang penting di seluruh perusahaan, demikian pula komunikasi antara pengguna dan departemen IT adalah salah satu contoh komunikasi yang sangat penting. Dengan menjaga jalur komunikasi yang terbuka dengan pengguna Anda dapat menunjukkan bahwa departemen Anda dapat diakses dan mudah untuk dihubungi. Hal ini akan meningkatkan image Anda di dalam perusahaan serta meningkatkan efisiensi karena pengguna akan lebih nyaman datang lebih awal kepada Anda untuk menyelesaikan masalah, daripada menunggu sampai masalah berkembang menjadi besar.
Pendidikan adalah juga penting di dalam meningkatkan citra departemen Anda. Menginformasikan pengguna tentang solusi TI dasar dapat menguntungkan kedua belah pihak dan dapat dilakukan dalam beberapa cara. Salah satu cara untuk melakukan ini adalah dengan mengadakan pertemuan atau workshop dengan karyawan dari setiap departemen di mana Anda dapat bekerja langsung dengan pengguna untuk membantu mereka lebih memahami proses TI.
Games / kompetisi dapat dimasukkan ke dalam lokakarya tersebut dan bisa diberikan hadiah untuk menambahkan beberapa kegembiraan. Menyediakan mereka yang hadir kesempatan untuk memenangkan hadiah undian juga bisa digunakan sebagai insentif. Cara lain untuk menjaga agar para pengguna selalu diberi informasi adalah dengan memasukkan kolom TI bulanan dalam buletin perusahaan yang menawarkan tips dan saran untuk masalah dasar TI. Hal ini akan meningkatkan citra departemen karena para pengguna akan melihat Anda sebagai orang yang benar-benar membantu dan juga bisa menghemat waktu karena pengguna mungkin dapat memperbaiki masalah mereka sendiri daripada harus menghubungi TI.

Berkepribadian dan hindari jargon
Akhirnya, hal sederhana yang dapat Anda lakukan untuk meningkatkan citra departemen TI Anda adalah hanya dengan berkepribadian. Jika Anda ramah dan sabar dengan pengguna, maka mereka akan memberikan sikap yang sama. Di sini berlaku “Aturan emas” dan penting untuk diingat bahwa jika Anda kasar dan pendek dengan pengguna mereka tidak mungkin akan mendengarkan saran Anda sehingga malah dapat menyebabkan Anda frustrasi dalam memperbaiki masalah yang sama dan berulang-ulang.
Juga, ingatkan diri Anda bahwa Anda berinteraksi dengan orang yang tidak tahu banyak tentang teknologi seperti Anda (jika tidak tentu mereka akan berada di departemen TI). Hal ini penting untuk menghindari jargon dan istilah yang bagi mereka yang tidak terbiasa dengan TI mungkin tidak mengerti. Hal ini perlu dilakukan tanpa banyak berbicara ke orang-orang, karena melakukan hal tersebut hanya akan menyebabkan kebencian saja. Ini luar biasa bagaimana dapat menguntungkannya hanya dengan bersikap sopan saja dapat membawa keberhasilan bagi keseluruhan departemen Anda.
Meningkatkan citra departemen TI Anda di dalam perusahaan Anda dapat berkontribusi langsung terhadap departemen yang lebih sukses dan efektif. Sebuah reputasi yang baik untuk departemen Anda akan membuatnya lebih mudah (dan lebih sedikit stress) dalam melakukan pekerjaan Anda. Meskipun ada beberapa pandangan negatif dan stereotip yang terkait dengan TI, adalah hal yang mungkin untuk mengambil langkah-langkah yang dapat ditindaklanjuti menuju penghapusan stereotip ini dan meningkatkan image Anda ke tingkat yang tinggi.

Betapa luasnya tugas dan tanggung jawab IT Security

Segala sesuatu yang terkait dengan CIA (confidentiality, integrity dan availability) relevant untuk dijadikan sebagai tugas dan tanggung jawab IT Security. Dapat dibayangkan betapa luasnya ruang lingkup tugas dan tanggung jawab IT Security.
Semua tentu sepakat bahwa tugas dari IT security pasti terkait dengan CIA tersebut. Jika dilihat dari sudut pandang unit kerja IT, seluruh bagian yang ada di dalam unit kerja IT pasti memiliki seluruh atau sebagian aspek yang ada di dalam CIA.



Ruang lingkup tugas dan tanggung jawab IT security di dalam IT sangat luas bahkan tak terbatas jika melihatnya secara maksimal sehingga seolah-olah tidak mungkin dapat dikerjakan dengan efektif oleh unit kerja IT security sendirian, tetapi jika melihatnya secara optimal dan dilaksanakan dengan pendekatan yang tepat maka meskipun sangat luas ruang lingkupnya maka tugas dan tanggung jawab IT security akan dapat dilaksanakan secara efektif, bagaimana caranya?.
Semua tentu mengetahui bahwa ada yang lebih luas lagi ruang lingkup tugas dan tanggung jawabnya dibanding dengan IT security, siapakah?. Tentu pimpinan puncak dari suatu organisasi.
Tugas dan tanggung jawab pimpinan puncak suatu organisasi dapat dilaksanakan secara efektif karena pimpinan tersebut menyadari akan pentingnya memahami dengan baik konsep atau persepsi bahwa wewenang dapat didelegasikan dan tanggung jawab tidak dapat didelegasikan. Dapat dibayangkan bagaimana jadinya jika pimpinan suatu organisasi tidak mendelegasikan kewenangannya tetapi menjalankan sendiri seluruh kewenangannya, tentu ia akan kerepotan sendiri sementara pegawainya berleha-leha.
Konsep bahwa wewenang dapat didelegasikan dan tanggung jawab tidak adalah merupakan konnsep yang sangat powerfull di dalam menjalankan manajemen termasuk manajemen IT security dan manajemen lainnya. Manajemen yang tidak percaya dengan konsep tersebut biasanya adalah manajemen yang tidak sabaran karena maunya serba instan.
Inti dari management adalah “how to get the job done”, bagaimana pekerjaan dapat segera diselesaikan, setelah melihat hasilnya, orang rata-rata tidak akan melihat dan menanyakan bagaimana cara melakukan pekerjaan tersebut.
Seperti disebutkan di atas bahwa wewenang dapat didelegasikan tetapi tanggung jawab tidak dapat didelegasikan. Dengan menggunakan konsep inilah “how to get the job done” dapat diimplementasikan dengan optimal.
Pada dasarnya jika memungkinkan seluruh tanggung jawab dan wewenang suatu unit kerja berada pada unit kerja tersebut, tetapi kadang-kadang pada prakteknya dengan luasnya ruang lingkup pekerjaan maka seluruh tanggung jawab dan wewenang yang ada akan sulit jika seluruhnya berada di unit kerja tersebut.
Seperti disebutkan di atas bahwa tanggung jawab tidak dapat didelegasikan, maka pilihan tinggal pada wewenang apakah wewenang akan didelegasikan atau tidak. Keputusan apakah akan mendelegasikan wewenang ke unit lain berada di tangan kepala unit kerja tersebut.
Keputusan untuk mendelegasikan atau tidak mendelegasikan wewenang adalah merupakan pilihan yang sama seperti keputusan untuk melakukan outsource atau tidak, jadi dalam hal ini tidak ada yang salah atau yang benar.
Keputusan pendelegasian wewenang pilihannya bisa menjadi ekstrim yaitu, melakukan pendelegasian seluruh wewenang atau kita sebut desentralisasi, atau sama sekali tidak dilakukan pendelegasian wewenang atau kita sebut sentralisasi. Tetapi tentu saja ada pilihan yang ditengah, yaitu sebagian sentralisasi dan sebagian desentralisasi.
Dengan menggunakan konsep sentralisasi dan desentralisasi wewenang tersebut maka tugas unit kerja dapat dilakukan secara optimal. Seperti disebutkan di atas bahwa pada implementasinya pendelegasian dapat dilakukan secara mixed, misalnya untuk tugas A dilakukan secara sentralisasi dan untuk tugas B dan C dilakukan secara desentralisasi.
Terdapat kekurangan dan kelebihan dari desentralisasi atau sentralisasi. Di dalam desentralisasi kelebihannya adalah tidak perlu mempekerjakan banyak orang pada unit kerja tersebut karena pekerjaan dilakukan oleh unit kerja lain dan kekurangannya adalah perlu diterapkan control yang sangat ketat karena kendali tidak sepenuhnya berada di unit kerja yang bersangkutan, sedangkan di dalam sentralisasi kelebihannya adalah tidak diperlukan control yang sangat ketat karena kendali sepenuhnya berada pada unit kerja yang bersangkutan, kekurangannya adalah perlu dipekerjakan banyak orang.
Kembali ke pembahasan mengenai Ruang Lingkup Tugas Information Technology Security, maka dengan mengacu pada penjelasan di atas seberapa pun luasnya ruang lingkup tugas dan tanggung jawab IT security maka dengan menggunakan pendekatan di atas maka tugas dan tanggung jawab IT security tersebut dapat dilaksanakan secara efektif.
Pendelegasian wewenang juga sebetulnya dapat dilakukan dalam konteks menyelesaikan pekerjaan sehari-hari, karena dalam penyelesaian pekerjaan sehari-hari juga terdapat prinsip “how to get the job done”. Jika ada yang mengkritik itu artinya tidak konsisten, jawabannya adalah selama tanggung jawab tidak ikut didelegasikan maka masih dapat dikatakan konsisten, lain halnya jika tanggung jawab juga didelegasikan.
Dari penjelasan tersebut di atas dapat diambil kesimpulan bahwa pendelegasian wewenang dapat dilakukan secara permanen, semi permanen dan non-permanen dengan syarat tetap memegang teguh prinsip wewenang dapat didelegasikan sedangkan tanggung jawab tidak dapat didelegasikan.
Pendelegasian wewenang yang dilakukan dalam konteks menyelesaikan pekerjaan sehari-hari dikategorikan sebagai pendelegasian wewenang non-permanen.
Menerapkan pendelegasian tugas pada IT security dapat juga didorong dengan menghimbau atau mengkampanyekan bahwa IT security adalah tanggung jawab setiap orang.
Unit kerja IT Security dapat diibaratkan sebagai polisi atau tentara yang bertanggungjawab terhadap keamanan dan pengamanan Negara.
Seperti polisi dan tentara di dalam menjaga keamanan dan pengamanan negara tentu saja perlu adanya partisipasi dari warga atau masyarakat.
Contoh bentuk partisipasi masyarakat dalam security adalah membentuk siskamling (sistem keamanan lingkungan), memperhatikan aspek keamanan rumah (seperti memperhatikan aspek keamanan saat membangun rumah tersebut) dan lingkungan sendiri.
Pada saat masyarakat membuat rumah, sudah selayaknya seluruh aspek keamanan rumah tersebut harus diperhatikan oleh yang membangun rumah tersebut, bukan oleh polisi atau tentara. Akan sangat tidak efisien dan efektif bahkan mungkin sama sekali tidak relevan jika pada saat orang membangun rumah yang diperhatikan hanya aspek-aspek yang non-security saja, tetapi saat menyangkut aspek security seperti pemasangan kunci, pintu, jendela dan teralis segera diserahkan ke polisi atau tentara, tentu ini tidak relevan.
Demikian pula di dalam melakukan development sistem aplikasi, si pembuat aplikasi tersebut harus memperhatikan aspek keamanan aplikasi tersebut secara seksama. Pada saat mengembangkan aplikasi si pembuat aplikasi tidak hanya fokus pada bagaimana aplikasi tersebut bisa berjalan tetapi juga memperhatikan aspek keamanan sistem aplikasi tersebut, aspek keamanan aplikasi tersebut tidak hanya diserahkan ke unit kerja IT security.
Demikian pula dalam hal administrasi security atau user-id, tidak perlu selalu diserahkan ke unit IT security. Selalu memaksakan bahwa IT security harus merupakan satu-satunya unit yang bertanggung jawab mengadministrasikan security itu sama saja diibaratkan masyarakat pemilik rumah harus selalu menitipkan kunci rumahnya ke polisi atau tentara.
Implementasi IT security yang efektif tidak perlu berarti tugas IT security harus selalu dilakukan sepenuhnya oleh unit kerja IT security. Tugas IT security dapat juga sebagai motivator bagi unit kerja lain untuk berpartisipasi dan bertanggungjawab terhadap security.

Ruang Lingkup Tugas Information Technology Security

Telah luas dikenal bahwa pada dasarnya ruang lingkup tugas Information Technology (IT) Security adalah di sekitar CIA (Confidentiality, Integrity dan Availability).
Segala sesuatu yang terkait dengan CIA tersebut relevant untuk dijadikan sebagai tugas dan tanggung jawab IT Security. Dapat dibayangkan betapa luasnya ruang lingkup tugas dan tanggung jawab IT Security.


Secara garis besar Confidentiality terutama terkait dengan physical security, logical security dan segregation of duty, Integrity terutama terkait dengan metodologi atau tahapan pengadaan dan pengembangan aplikasi, Availability terutama terkait dengan availability dari IT operations termasuk BCP, DRP dsb. Penjelasan di atas merupakan salah satu pendapat atau pendekatan bagaimana cara melihat konsep CIA diterapkan. Meskipun pendekatan tersebut cukup bagus dan mudah dimengerti, tetapi ada pendekatan yang sudah lebih luas dikenal, yaitu yang berdasarkan pada konsep standard information security ISO 27000, dimana yang dimaksud dengan CIA adalah aspek CIA dari information.
Jika dilihat dari area yang ada di IT security, dapat mengacu pada konsep atau standard Information Security ISO 27000 atau lebih tepatnya ISO 27002, terdapat 11 area atau domain sebagai berikut:
1.Security policy.
2.Organization of information security.
3.Asset management.
4.Human resources security.
5.Physical and environmental security.
6.Communications and operations management.
7.Access control.
8.Information system acquisition, development, and maintenance.
9.Information security incident management.
10.Business continuity management.
11.Compliance
Timbul pertanyaan apa bedanya IT Security dengan Information Security?. Pembahasannya bisa panjang, tetapi secara singkat IT security adalah bagian dari Information Security, IT security mencakup kira-kira 50% dari total aspek yang ada di dalam Information Security.
Tetapi karena sisa aspek yang 50% lainnya yang ada pada Information Security selain aspek IT security, adalah merupakan aspek-aspek yang relatif mudah untuk dilakukan, seperti masalah dokumentasi dan sebagainya, sehingga dapat diambil kesimpulan bahwa work-load dari IT security mungkin mencakup sekitar 80%-90% dari total work-load yang ada dalam Information Security.
Sehingga dari penjelasan tersebut di atas dapat diambil kesimpulan bahwa IT security adalah kurang lebih sama dengan Information Security.
Jika seluruh ruang lingkup CIA yang ada pada 11 domain atau area Information Security tersebut sepenuhnya harus dikerjakan oleh unit IT Security tentu tidak akan tertangani dengan baik, lalu bagaimana jalan keluarnya?.
Seperti diketahui bahwa kewenangan dapat didelegasikan tetapi tanggung jawab tidak. Dengan menggunakan konsep inilah tugas dan tanggung jawab Information Security dapat diimplementasikan dengan efektif dan optimal.
Pada dasarnya jika memungkinkan seluruh tanggung jawab dan kewenangan IT Security berada di unit IT Security sendiri, tetapi pada prakteknya dengan luasnya cakupan CIA maka seluruh tanggung jawab dan kewenangan yang ada akan sulit jika seluruhnya berada di unit IT Security.
Seperti disebutkan di atas bahwa tanggung jawab tidak dapat didelegasikan, maka pilihan tinggal pada kewenangan apakah kewenangan akan didelegasikan atau tidak. Keputusan apakah akan mendelegasikan kewenangan IT Security ke unit lain berada di tangan kepala unit kerja IT Security.
Keputusan untuk mendelegasikan atau tidak mendelegasikan kewenangan adalah merupakan pilihan yang sama seperti keputusan untuk melakukan outsource atau tidak, jadi dalam hal ini tidak ada yang salah atau yang benar.
Keputusan pendelegasian wewenang pilihannya bisa menjadi ekstrim yaitu, melakukan pendelegasian seluruh wewenang atau kita sebut desentralisasi, atau sama sekali tidak dilakukan pendelegasian wewenang atau kita sebut sentralisasi. Tetapi tentu saja ada pilihan yang ditengah, yaitu sebagian sentralisasi dan sebagian desentralisasi.
Dengan menggunakan konsep sentralisasi dan desentralisasi wewenang tersebut maka tugas IT Security dapat diimplementasikan secara optimal. Seperti disebutkan bahwa pada implementasinya pendelegasian dapat dilakukan secara mixed, misalnya untuk confidentiality dilakukan secara sentralisasi dan untuk integrity dan availability dilakukan secara desentralisasi.
Tentu terdapat kekurangan dan kelebihan dari sentralisasi atau desentralisasi. Di dalam sentralisasi kelebihannya adalah tidak diperlukan control yang sangat ketat karena kendali sepenuhnya ada di unit kerja IT Security, kekurangannya adalah perlu dipekerjakan banyak orang, sedang di dalam desentralisasi kelebihannya adalah tidak perlu banyak mempekerjakan banyak orang dan kekurangannya adalah perlu diterapkan control yang sangat ketat.
Untuk tahap awal, implementasi yang paling mudah adalah secara desentralisasi, kemudian dengan berjalannya waktu dan secara bertahap dan secara selektif implemntasi dilakukan mengarah ke arah sentralisasi. Sebagai contoh, pada tahap awal implementasi dilakukan dengan memilih confidentiality dilakukan secara sentralisasi, sedangkan untuk integrity dan availability dilakukan secara desentralisasi, kemudian dengan berjalannya waktu secara bertahap dan selektif dilihat apakah di integrity dan availability terdapat area-area yang perlu dibuat sentralisasi.
Keputusan untuk melakukan sentralisasi dan desentralisasi bukan masalah benar-salah atau baik-buruk, tetapi itu adalah masalah pilihan, sama seperti dalam pengambilan keputusan untuk melakukan outsource atau tidak. Di dalam melakukan outsource artinya adalah kewenangannya yang didelegasikan tetapi tanggung jawabnya tidak. Kewenangan dapat didelegasikan tetapi tanggung jawab tidak.
Jika kita percaya bahwa melakukan outsource-pekerjaan adalah merupakan hal yang dapat dikerjakan atau dapat diterima, maka tidak ada alasan untuk mengatakan bahwa sentralisasi atau desentralisasi pada IT security adalah hal yang tidak dapat dikerjakan atau tidak dapat diterima.
Jadi di dalam implementasi IT Security juga berlaku prinsip bahwa kewenangan memastikan CIA dapat didelegasikan sebagian atau seluruhnya tetapi tanggung jawab sama sekali tidak dapat didelegasikan.

Ancaman Terbesar Keamanan "Data Center" Berasal dari Internal

BANDUNG, KOMPAS.com - Tugas perusahaan penyedia solusi data center adalah menjaga keamanan data milik pelanggannya secara maksimal.

Namun, semua itu ternyata tidak efektif bila tidak adanya pengawasan terhadap orang-orang di internal pelanggannya itu.

Fakta tersebut terungkap dalam survei yang diadakan tim dari Fakultas Teknologi Informasi dari Swiss German University terhadap beberapa data center yang ada di Indonesia.

Salah satu hasil survei tim tersebut menyebutkan risiko tertinggi masalah keamanan data center ternyata berasal dari lingkungan internal.

Hasil survei ini dipublikasikan di acara International Conference on Cloud Computing and Social Networking 2012, yang merupakan bagian dari e-Indonesia Initiative (eII) Forum ke-8 yang digelar selama dua hari di Bandung, yakni 26 dan 27 April 2012.

Tim ini melakukan survei di Microsoft, CBN, Telkom, dan Hewlett Packard.

"Sebetulnya kami ingin mensurvei lebih banyak perusahaan. Namun beberapa perusahaan menolak untuk disurvei sehingga kami hanya melakukan survei di empat perusahaan. Untuk sementara kami fokuskan mensurvei data center yang terdapat di Indonesia, kecuali Microsoft," jelas Charles saat ditemui Kompas.com.

Karena terkendala masalah perizinan, Charles baru bisa meneliti data center CBN, Telkom, dan Hewlett Packard yang terdapat di Indonesia. Sedangkan data center Microsoft merupakan satu-satunya data center yang diteliti, yang berada di Amerika Serikat.

Charles Lim, dosen dan peneliti dari Swiss German University dan rekannya, Alex Suparman, melakukan survei selama 3 bulan ke perusahaan-perusahaan teknologi tersebut.

Hal-hal yang diteliti dari data center meliputi dual power supply, HVAC system, smoke detection, fire suppression system, fire suppression system, onsite security, cable management, cages, dan telecommunication.

Khusus untuk masalah keamanan, Charles dan rekannya melakukan inspeksi dan meneliti bentuk fisik keamanaan data center, teknologi yang digunakan di data center, dan regulasi yang diterapkan di masing-masing data center tersebut.

Metode survei dilakukan dengan cara-cara berikut ini :
1. Review dokumen-dokumen terkait data center yang disurvei.
2. Wawancara dengan vendor komputasi awan, serta anggota organisasi yang mengurusi data center di masing-masing perusahaan.
3. Melakukan inspeksi ke data center.
4. Observasi mengenai perilaku personel dalam organisasi yang mengurus data center.
5. Melakukan tes kontrol keamanan yang dimiliki data center.

Hasil dari survei diantaranya :
1. Risiko tertinggi masalah keamanan data center ternyata berasal dari lingkungan internal.
2. Microsoft merupakan data center dengan level tinggi yang memberikan perlindungan.
3. Kontrol keamanan merupakan hal yang berpengaruh untuk mereduksi risiko dari serangan.

Dari survei ini, Swiss German University merekomendasikan hal-hal berikut :
1. Buat kebijakan keamanan yang jelas
2. Lakukan tes kontrol keamanan secara berkala
3. Harus membayar pihak ketiga untuk mengevaluasi data center
4. Mulai support untuk pasar mobile

Survei yang dilakukan Charles dan rekannya merupakan awal dari survei-survei lainnya yang lebih luas.

Semakin banyak perusahaan yang terbuka untuk disurvei dan diaudit data center-nya, maka akan memberikan rasa nyaman bagi masyarakat selaku konsumen yang menggunakan jasa perusahaan-perusahaan tersebut.

"Semoga semakin banyak perusahaan yang terbuka bagi pihak ketiga untuk mensurvei keadaan data centernya," tutup Charles.

Green Data Center

Maraknya isu lingkungan hidup terutama Global Warming telah menjadi tema sentral saat ini, tidak terkecuali bagi pelaku bisnis teknologi ICT. Ada berbagai sorotan, gagasan, dan usulan ICT yang berbasis kepada upaya penyelamatan lingkungan hidup demi kemaslahatan umat pada masa yang akan datang, diantaranya Data Center. Selama ini, keberadaan Data Center identik dengan : kebutuhan catu daya listrik yang sangat besar untuk proses komputasi yang kontinnyu (Non Stop), yang akan berdampak pada permasalahan Energi. Menurut lembaga riset global, IDC dan Gartner. IDC menilai bahwa untuk setiap US$1 investasi piranti keras di Data Center, akan muncul tambahan biaya US$0,5 pada Power dan Sistem Pendinginan. Angka tambahan ini naik dua kali lipat dari jumlah tahun sebelumnya. Gartner bahkan memprediksi separuh dari Data Center di dunia pada 2008 akan kekurangan kapasitas Power dan Cooling akibat krisis Energi. Dari permasalahan tersebut, dibutuhkan model baru Data Center yang ramah lingkungan atau Green Data Center.

Untuk menerapkan Green Data Center, banyak hal yang harus dilakukan, diantaranya : Mengaudit efisiensi Data Center, Menggunakan UPS yang memiliki efisiensi hingga 97%, Virtualisasi Server dan Storage Data Center. Selanjutnya, lalukan konsolidasi data Server dan Storage, Penggunaan fitur Manajemen Energi pada CPU, Penggunaan Power Supply dan Voltage Regulator tersertifikasi, Adopsi distribusi Energi terefisien dan Adopsi Sistem Cooling terbaik. Dua langkah terakhir yang tidak kalah pentingnya adalah menerapkan prioritas tindakan dalam mereduksi Energi sekaligus menonaktifkan peralatan ICT yang sudah dalam kondisi idle di sebuah Data Center.

Best Practices in Data Center Relocation

Data center relocations are complex initiatives that cross every aspect of IT and the business. Preparing for success requires an in-depth understanding and proper documentation of all facets of the interrelationships between the technology infrastructure and the supported business operations.
Many organizations make significant investments in new data center facilities, resulting in a state of the art physical plant. A frequent oversight, however, is carrying poor processes, procedures, architecture and documentation into the new site. In order to achieve the desired availability of applications and data, the maturity level of the IT infrastructure and processes must meet or exceed the design criteria of the facility.
Organizational Readiness Determines Scope
In order to understand the scope of preparations and investment required for a smooth relocation, an organization must first evaluate its readiness to undertake the initiative. The maturity of an organization’s IT infrastructure processes, procedures and documentation has a direct correlation to the complexity of the undertaking, and the level of complexity is a major factor in an initiative’s cost and risk to the business.
Organizations with well-documented, actively-managed asset management, disaster recovery, monitoring and management, and change control programs have the essential elements required to successfully complete the data center relocation. They will not have to invest in the discovery, validation or development of information and processes in order to prepare.
Conversely, gaps in these processes and documentation must be addressed prior to or in conjunction with the project. Failure to address gaps will introduce a high degree of risk to the project and could lead to outages that negatively impact the business.

Five Steps to a Successful Data Center Relocation
Step 1 – Perform a readiness assessment
Performing a best practices check-up for infrastructure management provides a baseline of the organization readiness to undertake this initiative. The objective is to evaluate the accuracy and completeness of processes, procedures and documentation. Focus areas include:
§ Support Structure – Are problem management, notification and escalation processes current and documented?
§ Service Level Agreements – Do they exist? Are they documented? Are they current?
§ Documentation – Do the five basic documents (configuration, startup, shutdown, backup, recovery) exist for each asset? Is there a central repository? Is there a document control system? Is the documentation current?
§ Asset Management – Does a current system exist that reflects all assets and related portfolio information?
§ Maintenance Contracts – Are these consolidated into a single data source, preferably the asset management system? Do the maintenance contracts reflect service levels proportionate to criticality and usage of the assets? Are contract expirations proactively managed?
§ Financial Management – Does all information related to environment lifecycle costs exist in a central repository (asset management system)? Does a total cost of ownership (TCO) model exist for each asset?
§ Change Control – Is there an actively managed process that tracks and audits all changes to the environment, including facilities, hardware, software, applications and data structures?
§ Architecture – Is the IT architecture well defined and documented? Is the architecture team involved in the design and validation of initiatives?
§ Capacity Planning – Does an automated system exist to track the usage baseline and deltas in the environment at a component level?
§ Performance Management – Does an automated system exist to track the baseline and deltas of the environment’s performance to a component level?
§ Monitoring and Management – Does an automated system exist to track the availability and service levels of the IT environment? Are support and escalation procedures automated and current?
§ Business Initiatives – Is there an overall perspective on the parallel initiatives that will be undertaken by IT and the business during the life of the data center relocation project? Are the impacts and resource requirements understood and documented?
§ Stakeholder Management – Have the basic requirements and value proposition for the data center relocation project been communicated to the business and internal/external partners? Has a communication plan been established and implemented?
§ Resource Availability – Is there a commitment of resources from each of the stakeholder groups in direct relation to the project timeline?
§ Industry Regulations – Are the compliance ramifications of the project understood and overseen by a certified organization?
§ Logistics – Have the decisions related to the location of the destination facility been finalized? Is there a strategy for the location of assets by class by facility?
§ Relocation Project – Has the project executive defined the basic initiative timeline? Is there a dedicated project manager? Does a corporate project management office (PMO) exist and has this initiative been registered with the PMO?
§ Disaster Recovery Plans – Do current validated plans exist for each environment? Because a data center relocation is essentially a managed disaster recovery event for which the IT environment will be reestablished at a different location, disaster recovery is the most pertinent area to the success of the project. A thorough disaster recovery plan provides key information about the interrelationships between the infrastructure and the business, the criticality of applications and data, and the mechanisms to mitigate risk.
Based on the project timeline, a determination needs to be made for each gap area on whether to implement a long-term or interim solution.
Step 2 – Assess the environment
This phase of the project involves gathering, combining and correlating information about assets and their use in support of the business. Analogous to a disaster recovery plan, this step baselines the environment and begins the process of asset classification. Each asset must be identified and the portfolio of information regarding its use and interrelationship to the whole environment must be established and documented. The output of this phase is the asset repository that reflects the current inventory, technical and business interrelationships, and supporting asset lifecycle information. Best practices include automated asset discovery and tracking, and the use of an industry standard repository such as a configuration management database (CMDB) that is capable of providing a comprehensive view of all aspects of each asset.
Step 3 – Design, validate and plan the project
Building upon the assessment, each asset must be correlated to the business function it supports. This step parallels the disaster recovery process of defining recovery groups; for the sake of this project, these groups will be referred to as “move groups.” Each move group represents a consolidated collection of assets that support a key business function or IT support function.
Each move group is analyzed for its criticality to the business and assigned a corresponding ranking. The disaster recovery plan for each move group is consulted, along with the technical architecture employed for availability and recovery. The result is a relocation methodology tailored for each move group based on the service level agreement, risk mitigation capabilities that currently exist and an approved business case for additional investment required to support availability or limit risk during the relocation.
The output of this project phase will be an overall project plan that includes detailed task plans, time budgets, and resource and contingency plans. A relocation calendar should detail the timing of move events in relation to business initiatives and cycles. A communication plan and command center structure should be documented and validated with all stakeholders.
Step 4 – Implement the plan
This phase is where the detailed analysis and planning pays off. Each stakeholder should understand his or her role and tasks. Decisions regarding contingencies and timelines have been established. The command center coordinates the activities, tracks and communicates progress, and performs problem management and escalation coordination. Successes and failures are documented and utilized post-relocation to improve the process for subsequent events.
Step 5 – Manage the environment post-relocation
Upon completion of the data center relocation, it is imperative to take one additional step: the incorporation of knowledge, updated processes, procedures and documentation into the normal support structure of the IT infrastructure. The relocation project will have validated or generated current information about the IT infrastructure. As change is constant in information technology, this information will have a limited shelf life. In the normal course of business, these processes, procedures and documentation all too often become a low priority for compared to the demands of the business on IT organizations. Quickly incorporating this information and implementing a process to continually refresh it will achieve a far greater long-term result than solely the relocation of assets.
The Long-term Benefits of a Successful Data Center Relocation
The benefits of carefully planned and executed data center relocation go well beyond what meets the eye of the user or customer. Done correctly, the end result is not only a seamless transition for the business, but also the creation of a set of business continuity disciplines that can validate or provide groundwork for disaster recovery and business continuity planning – as well as IT and physical security, asset management, systems documentation, change control, operating standards and processes, capacity planning, maintenance and license management, service and operating level agreements, business alignment and data center facility management.
In other words, successful data center relocation can completely transform the overall operating environment – its processes, procedures, documentation and personnel – in a way that has significant, lasting benefits for an organization’s disaster recovery readiness as well as day-to-day operational efficiencies.
About the Author:
As the director of Forsythe's data center relocation services practice, Fred Latala is responsible for the company's overall data center relocation strategy, vision, best-practice models, and the quality of solutions delivered. Latala has more than 20 years of experience in internal and external IT management roles.
By Fred Latala

Data konversi AC

Berikut ini Data konversi untuk Energy AC :

1 kW = 3412 btuh

1 kCal = 3.968 btuh

1 TR = 3.517 kW

1 PK = 9000 btuh

Sedangkan untuk work conversion 1 HP = 0.745 kW

berguna untuk menentukan besaran besaran penentuan AC

sekedar contoh:

Umumnya AC yang dijual dalam satuan PK:
1/2 PK = 5000 BTU
3/4 PK = 7000 BTU
1 PK = 9000 BTU
1-1/2 = 12000 BTU

Kalau untuk penggunaan rumus sederhana = 500 BTU/m²

Jadi untuk kamar tidur 3 x 4 m² = 12 m² x 500 BTU = 6000 BTU, cukup memakai AC 3/4 PK.