PBI 9/15/PBI/2007 mengadopsi FFIEC IT Examination Handbook?

Tahun lalu saya ada training tentang PBI ITRM ini. Pemahaman saya, PBI tentang ITRM untuk Bank Umum ini tidak akan terlalu jauh dari bagaimana Basel II menetapkan kriteria pengelolaan risiko operasional, karena risiko terkait TI merupakan bagian dari risiko operasional. Setelah pelajari berbagai publikasi tentang Basel, saya juga menemukan sekumpulan dokumen menarik tentang IT Examination Handbook. Serangkaian dokumen ini dirisilis oleh FFIEC (Federal Financial Institution Examinations Council), sebuah lembaga di US sono yang secara umum profilnya sbb:

The Council is a formal interagency body empowered to prescribe uniform principles, standards, and report forms for the federal examination of financial institutions by the Board of Governors of the Federal Reserve System (FRB), the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administration (NCUA), the Office of the Comptroller of the Currency (OCC), and the Office of Thrift Supervision (OTS), and to make recommendations to promote uniformity in the supervision of financial institutions. In 2006, the State Liaison Committee (SLC) was added to the Council as a voting member. The SLC includes representatives from the Conference of State Bank Supervisors (CSBS), the American Council of State Savings Supervisors (ACSSS), and the National Association of State Credit Union Supervisors (NASCUS).

Jadi tugas FFIEC ini menetapkan prinsip, standar dan form-form report, serta membuat rekomendasi untuk memastikan keseragaman dalam melaksanakan supervisi institusi keuangan di US sana. FFIEC ini mempublikasikan InfoBase yang berisi IT Booklet, Resources, Presentation dan Glossary yang ditujukan untuk menyediakan Just-In-Time Training untuk regulasi baru dan topik lain yang menjadi concern para auditor/penguji di lembaga berikut:

  • Federal Reserve Board
  • Federal Deposit Insurance Corporation
  • National Credit Union Administration
  • Office of Comptroller of the currency
  • Office of Thrift supervision

Berikut ini adalah link untuk infobase tersebut:

http://www.ffiec.gov/ffiecinfobase/index.html

Dan berikut ini adalah link untuk IT Booklet yang isinya merupakan IT Examination Handbook:

http://www.ffiec.gov/ffiecinfobase/html_pages/It_01.html

Nah, jika dibandingkan dengan dengan publikasi Surat Edaran BI yang menjelaskan lebih detail tentang PBI 9/15/PBI/2007 yaitu SE No. 30/DPNP maka kita akan mendapatkan kemiripan yang sangat antara IT Examination Handbook dengan SE No. 30/DPNP. SE No. 30/DPNP terdiri dari 10 bab, sedangkan IT Examination Handbook terdiri dari 10 dokumen. Yang tidak dirujuk dalam SE No. 30/DPNP hanya “Wholesale Payment System”.

Saya sudah sempat membandingkan konten masing-masing bab dalam SE No. 30/DPNP dan dokumen terkait dalam FFIEC IT Examination Handbook. TIdak persis sama, tetapi sangat mirip dan memang telah dimodifikasi.

Untuk regulasi sekelas PBI, saya membayangkan seharusnya BI juga merilis logbook yang akan menjelaskan kepada kita apa saja referensi yang digunakan, apa metodologi yang digunakan dan alasan-alasan apa saja yang digunakan untuk menyesuaikan berbagai referensi tadi dengan kebutuhan Indonesia, jika memang harus mengadopsi. Mungkin ini ada dan saya tidak tahu, tetapi ketika nyari-nyari ke website BI kok tidak ketemu ya? Mungkin ada yang tahu?

Dari beberapa seri training yang kami selenggarakan, ada banyak keluhan dari TI bank-bank khususnya bank menengah kecil tentang implementasi PBI ITRM ini. Pertanyaan paling dasar: tepatkan konstruksi regulasi ITRM untuk bank umum seperti PBI ini? Kalau kita bandingkan dengan ISO 27005 (Security Risk Management) maka kita dapat melihat perbedaan yang sangat mencolok dengan PBI ini.

ITRM menurut saya lebih ditekankan pada orientasi proses, apakah sebuah bank sudah menjalankan PROSES MANAJEMEN RISIKO TI? Karena profil risiko tiap bank bisa beda, proses manajemen risiko TI yang dijalankan bisa sama, tetapi konstruksi kontrol TI-nya bisa berbeda-beda.

PBI 9/15/PBI/2007, dengan format dokumen seperti itu, lebih cenderung membuat STANDARISASI KONTROL TI dibandingkan mendorong bank-bank umum menjalankan proses manajemen risiko TI-nya sendiri. Kalau memang ini benar terjadi, maka berbagai keluhan dari pihak perbankan sekarang ini tentang betapa berdarah-darahnya mereka yang harus mengimplementasikan PBI ITRM ini jadi masuk akal, karena lebih ke standarisasi kontrol dibandingkan dengan keberjalanan proses.

COBIT dan Blueprint TI

Baru-baru ini saya membaca hasil kerja dari sebuah perusahaan yang judul kerjaanya adalah penyusunan rencana induk TIK di sebuah departemen. Ada dua lingkup besar: Audit TI dan Penyusunan Rencana Induk sebagai kelanjutan dari hasil Audit TI. Audit TI menggunakan COBIT, memilih 20 proses dari 34 proses COBIT.

Apakah COBIT tepat digunakan untuk keperluan penyusunan Rencana Induk TI seperti ini?

Mungkin biar kita obyektif menganalisanya, kita perlu tahu apakah Rencana Induk TI itu? Di Indonesia ini ada berbagai macam istilah: Rencana Induk, Master Plan, Blueprint, Rencana Strategis. Kalau best practice sih ya adanya Strategic Plan, Detail Plan dan Annual Plan, silakan dilihat di COBIT untuk ini. Kalau dibuat sederhana, IT Plan harus berisi setidaknya berikut ini:

  • Dokumentasi arsitektur bisnis
  • Dokumentasi arsitektur informasi
  • DOkumentasi arsitektur aplikasi
  • Dokumentasi arsitektur teknologi
  • Dokumentasi tata kelola (IT Governance)
  • Manajemen portofolio (roadmap program/proyek, kebutuhan investasi, cost-benefit analysis/ROI/dsj)

Audit TI menggunakan COBIT dalam pekerjaan di atas, yang keluaran akhirnya adalah maturity level untuk 20 proses yang dipilih, apakah tepat untuk input sebuah Rencana Induk TI?

Coba bedakan dua hal berikut ini:

  • Arsitektur bangunan
  • Cara pengelolaan bangunan

Tentu saja beda antara dua hal itu. Nah, cara audit seperti yang saya kemukakan dalam pekerjaan yang saya review itu HANYA MENYENTUH CARA PENGELOLAAN. COBIT itu bukan referensi Arsitektur TI, COBIT itu referensi kontrol TI atau Tata Kelola TI. Menurut saya, adalah tidak tepat menggunakan COBIT sebagai pendekatan utama kegiatan audit yang akan digunakan sebagai input penyusunan Cetak Biru Arsitektur TI. Pertanyaan-pertanyaan ini tidak akan bisa dijawab dengan audit menggunakan COBIT:

  • Apalah prinsip-prinsip TI yang ada sesuai dengan kebutuhan arsitektur bisnis?
  • Manakah proses-proses bisnis utama yang dukungan TI-nya kurang, manakah yang belum?
  • Apa risiko kondisi eksisting TI terhadap pencapaian tujuan bisnis organisasi/perusahaan?

Menurut saya ini kesalahan paling sering orang menggunakan COBIT untuk mengaudit TI. COBIT tidak dapat digunakan untuk untuk semua hal, karena dia memposisikan dirinya sebagai IT Control Framework dan IT Governance Model, berarti dia hanya bisa digunakan sebagai referensi untuk implementasi/audit IT Control (utk berbagai tipe sistem TI, walaupun untuk detailnya COBIT harus menengok banyak standar/framework lain yang lebih aplikatif) dan IT Governance.

Audit Arsitektur TI

Auditing IT Architecture

Apakah IT Architecture itu? Kalau dalam dunia sipil, Arsitektur Bangunan menjelaskan tentang desain detail sebuah bangunan: bagaimana bentuk detail bangunan dan apa saja bahan yang digunakan; tentu saja merujuk kepada satu hal paling mendasar: bangunan itu diperuntukkan untuk apa? Demikian pula Arsitektur TI, dia merupaka DESAIN dan SPESIFIKASI “bangunan” TI di sebuah organisasi atau perusahaan. Idealnya Arsitektur TI itu mencerminkan strategi bisnis, dan potensi TI sangat luar biasa dalam domain ini. Organisasi atau perusahaan yang terbawa arus “Demam TI” tidak akan pernah menghasilkan nilai tambah yang berarti. Hanya organisasi atau perusahaan yang memiliki Arsitektur TI yang paling tepatlah yang paling bisa mendayagunakan TI untuk bisnisnya.

Investasi TI itu tidak murah, apalagi daur hidupnya yang tidak panjang-panjang amat, ambillah per 5 tahunan. Satu faktor utama lain yang mesti selalu diperhatikan: tantangan terbesar implementasi TI ternyata adalah manajemen perubahan individu dan organisasi. Semahal apa pun investasi TI digelontorkan, tidak akan berguna kalau manajemen perubahan itu tidak dilakukan. Masalahnya manajemen perubahan itu tidak mudah, jauh lebih mudah pengadaan teknologinya tentu saja. Dengan kata lain, investasi TI itu tidak sederhana, bukan hanya beli aplikasi atau perangkat keras, tetapi mengkombinasikan solusi teknologi tadi dengan pendekatan individu dan organisasi.

Mengapa Audit Arsitektur TI diperlukan? Kalau hal-hal di bawah ini terjadi, mungkin bisa dipertimbangkan mengapa perlu audit Arsitektur TI:

  1. Investasi TI sudah dilakukan sekian tahun, tapi tidak banyak berarti dalam memenangkan persaingan bisnis. Tetap saja tak ada perbedaan signifikan perusahaan kita dengan yang lain.
  2. Aplikasi banyak dibangun, tetapi tetap saja ditemui kesulitan dalam memonitor keberjalanan bisnis. Bahkan mungkin lebih ironis lagi, manajemen atau eksekutif pengambilan keputusannya masih didasarkan pada laporan-laporan manual, di tiap-tiap rapat koordinasi setiap manajer bidang membawa laporan segepok.
  3. Pelaporan-pelaporan bisnis tidak bertambah efisien secara berarti.
  4. Pertukaran informasi dan komunikasi antar staff dan unit kerja masih mengandalkan pola-pola konvensional.
  5. Dulu pakai manual cepat, sekarang pakai berbagai aplikasi malah prosesnya semakin lama?

Jadi Audit Arsitektur TI ini bisa jadi sangat strategis untuk sebuah organisasi atau perusahaan. Setidaknya, berikut ini adalah pertanyaan-pertanyaan yang ingin dijawab dengan Audit Arsitektur TI ini:

  1. Apakah seluruh layanan bisnis telah difasilitasi oleh sistem informasi yang memadai? Untuk setiap layanan bisnis yang telah difasilitasi oleh sistem informasi: apakah keberadaannya benar-benar memberikan nilai berarti bagi bisnis?
  2. Apakah sistem informasi yang ada sekarang ini mengimplementasikan platform yang dapat mengakomodir persyaratan pertumbuhan kapasitas dan keamanan yang memadai?
  3. Apakah seluruh sistem informasi yang ada sekarang ini mengakomodir kebutuhan integrasi sistem?
  4. Apakah informasi yang dihasilkan oleh seluruh sistem informasi dapat digunakan untuk monitoring operasional secara cepat dan dasar pengambilan keputusan yang akurat bagi top level management?
  5. Dan ujungnya: Apakah Arsitektur TI saya saat ini sudah sesuai dengan Arsitektur Bisnis saya?

Semoga di tulisan mendatang bisa dilanjut dengan sekilas pendekatan yang dapat digunakan untuk melakukan Audit Arsitektur TI ini.

TI KPU Dalam Sudut Pandang IT Principles

Seperti yang diduga sebelumnya, TI KPU menuai banyak sekali komplain dan kritikan, dari yang paling halus sampai yang paling keras. Setidaknya dari browsing sana-sini bisa disebutkan ketidaknormalan yang terjadi:

  • Perencanaan TI KPU yang sangat mepet, hanya 3 bulan sebelum pemilu diselenggarakan
  • Hasil perencanaan TI KPU yang disangsikan apakah digunakan atau tidak
  • Kontinuitas TIm PErencana yang tidak dilanjutkan
  • Tender-tender TI KPU (integrasi sistem dan Data Center) yang diputuskan tidak lebih dari 1 bulan sebelum penyelenggaraan Pemilu (silakan lihat di situs KPU untuk yang ini)
  • Sistem tidak mampu menangani beban sehingga KO, baik yang disebabkan oleh keputusan penggunaan situs dinamis (here) atau kapasitas server yang kurang (here)
  • Penggunaan Intelligent Character Recognition (ICR) yang ternyata tidak dalam rekomendasi tim perencana (here)
  • Tim BPPT yang masuk di tengah perjalanan dan harus menerima apa adanya yang sudah jalan

Dari beberapa fenomena di atas bisa dilakukan analisa sebagai berikut:

  • Dari sisi perencanaan, sulit sekali dikatakan perencanaan TI KPU dilakukan dengan memadai. Tim Perencana TI KPU yang memulai kerja bulan desember 2008 memperlihatkan hal ini. Bagaimana bisa perencanaan sistem sangat kritikal seperti itu dilakukan hanya 4 bulan sebelum hari H? Bagaimana mungkin tender sistem dan infrastruktur dilakukan hanya 1 bulan menjelang hari H? Itu sangat tidak masuk akal.
  • Dari sisi siklus pengembangan dan implementasi sistem, kita bisa lihat dari sisi waktu dan tahapan-tahapan yang harus dilalui. Adalah sangat tidak rasional mempersipakan sistem aplikasi hanya 1 bulan menjelang hari H. Ini bukan menyiapkan modul aplikasi kecil yang bisa dikerjakan oleh 1 orang dengan santai nyambil ngopi. 1 bulan itu harus mengakomodir requirement analysis, development, pengujian, deployment dan training. Kapan training dilakukan ke seluruh operator di 500-an point of service? Sistem overload juga mengindikasikan kalau Load Testing tidak dilakukan, sehingga di tengah jalan harus pinjam server dari BPPT dan Telkom.
  • Tim BPPT masuk di tengah jalan, hanya 1 bulan sebelum hari H. Dan itu pun Tim BPPT harus terima yang sudah jalan. So, bagaimana pengelolaan SDM TI dari awal? Ini sangat tidak bisa diterima kaidah profesional.
  • Terakhir, ternyata hasil real count yang diakui UU itu tetap yang manual. Jadi walaupun TI KPU sehebat apa pun, ternyata hasilnya tidak bisa dianggap hasil final dan legal, karena yang legal tetap yang manual. Jadi untuk apa sistem tabulasi nasional itu?

Dari sisi IT Principles (IT Strategic Roles di sebuah organisasi, yg membedakan satu organisasi dengan yang lainnya, yang menentukan nilai kompetitif implementasi TI di satu perusahaan dengan perusahaan lainnya), keberadaan TI KPU ini jadi terlihat membingungkan, tidak jelas. Karena ketidakjelasan tersebut, maka prioritas sistem juga jadi tidak jelas, termasuk juga prioritas belanjanya.

Terlepas dari semuanya, saya tetap mengapresiasi “semangat komando” teman-teman BPPT dan komunitas yang mau jadi bemper dari segala kesemrawutan TI KPU. Sangat tidak mudah menghandle sesuatu yang tidak ikut merencanakan, yang masuknya di tengah-tengah jalan. Tetap semangat Pak Amien, Pak Agus dll….

IT Bukan Sim Silabim!!

Kurang dari sebulan lagi hajatan terbesar negara ini, PEMILU, akan dilakukan. Hari ini saya coba iseng lihat di website KPU, ada tiga tender terkait TI yang baru diumumkan pemenangnya: Integrasi, Data Center, Komunikasi. Keisengan ini ditriger satu teman yang cerita tentang satu perusahaan di Bandung yang pernah meminjam CV-nya untuk tender di sana, yang ternyata memenangkan satu dari tiga tender itu.

Googling lagi, plus lihat posting di DETIK terkait persiapan TI KPU. Wow…. Berani sekali BPPT “Take Risk” dengan menandatangani MOU untuk membantu KPU. Dengan level kompleksitas nasional seperti itu, dengan waktu tidak lebih dari 1 bulan: APAKAH INI MISSION IMPOSIBLE? Sebenarnya tercapai atau tidak tercapainya sih tergantung netepin target di depannya. Masalahnya, apakah target yang ditetapkan sesuai kebutuhan minimal untuk level nasional ini?

IT bukan Sim Silabim bung!!

Copyright or Copyleft?

Salah satu yang menarik dari dunia industri di abad ini adalah istilah Copyright. Kalau kita menemukan sesuatu, maka kita bisa patenkan itu dan jadi copyright kita. Kalau ada orang pakai untuk keperluan komersial, maka kita akan dapat fee atas paten yang kita kembangkan itu. Salah satu parameter kualitas perguruan tinggi yang di level World Class University salah satunya adalah seberapa banyak paten yang bisa dihasilkan oleh dosen atau penelitinya.

Jadi kalau ditelaah lebih dalam, motif dasar dari Copyright tadi adalah bagaimana memberikan nilai ekonomi atas sebuah penemuan.

Di dunia TI Indonesia, Pak Onno Purbo adalah salah satu orang yang penggerak Copyleft. Beliau sangat mudah mensharing apa pun yang telah dikembangkan dan ditemukan oleh beliau. Yang belajar dari penemuan beliau dan kemudian memproduksi untuk dijual, tidak harus membayar paten ke beliau. Di berbagai kesempatan dan banyak tulisan, beliau mengatakan bahwa walaupun saat ini beliau tidak punya pekerjaan tetap, tidak ada satu pun institusi yang menaunginya, tidak ada gajah (baca ITB) yang menaunginya, ternyata beliau sampai saat ini tidak jatuh miskin, malah rejeki berlimpah.

Tidak setuju Copyright bukan berarti boleh membajak.

Memilih Produk ERP?

Saat ini sedang menghadapi kasus ini di salah satu klien. Apa kriteria pemilihan ERP untuk sebuah perusahaan? Bagaimana menentukan lingkup proses bisnis yang tepat? Mana saja sistem legacy yang harus di-interfacing dengan ERP?

Surfing dan tanya sana-sini ke beberapa teman yang sudah “berkarat” bergelut di dunia ERP, dan coba memahami berbagai uneg-uneg, masukan, kritikan dari berbagai tipe stakeholder, berikut ini adalah beberapa kategori yang sedang dalam pertimbangan:

  1. Kecukupan Portofolio
    • Sudah dipakai di mana saja ERP tersebut di industri yang terkait langsung dengan kita?
    • Bagaimana testimoni dari perusahaan-perusahaan sejenis?
  2. Pemenuhan Fitur Fungsional
    • Apakah produk mampu mengakomodir lingkup proses-proses bisnis perusahaan?
    • Apakah fungsi-fungsi kritikal dan spesifik di perusahaan dapat terakomodir?
    • Apakah berbagai best practices manajemen sudah tercakup dalam aplikasi? Sebagai misal kita sedang punya inisiatif CBHRM (Competency based HRM), apakah itu sudah tercakup di modul HRM?
    • Apakah regulasi-regulasi spesifik (misalnya perpajakan Indonesia yang khas) sudah masuk dalam fitur-fitur fungsional?
  3. Pemenuhan Fitur Teknologi
    • Apakah fitur security cukup memadai? Access control, enkripsi, user management dll?
    • Apakah fitur integrasi mewakili kebutuhan integrasi dengan sistem-sistem legacy, sistem eksternal (misalnya dengan Bank) dan pengembangan ke depannya? Apakah integrasinya open-system atau proprietary?
    • Bagaimana skalabilitas produk terkait dengan deployment yang mungkin bertambah di masa depan atau penambahan modul fungsional?
    • Mungkinkah dilakukan personalisasi?
    • Apakah tersedia fitur untuk performance tuning ketika sistem ERP sudah berjalan? Fitur ini memonitor kinerja setiap aspek teknikal ERP, dan memberikan saran untuk tuning kinerja?
    • Apakah memungkinkan berbagai jenis device pada presentation layer? Apakah memungkinkah akses dari berbagai delivery channel? Apakah application server untuk tiap jenis delivery channel yang memungkinkan telah disediakan?
    • Apakah ada fungsional audit trail untuk seluruh transaksi?
  4. Pricing dan TCO (Total Cost of Ownership)
    • Berapa initial investment untuk lingkup yang ditentukan?
    • Berapa annual licence & technical support?
    • Berapa biaya untuk upgrade versi produk?
  5. Kesenjangan dan Potensi Pengembangan Kapasitas TI Internal
    • Sejauh mana kesenjangan kapasitas teknikal Tim TI atas produk-produk pilihan?
    • Seberapa besar effort pengembangan/upgrade kapasitas Tim TI untuk dapat mengoperasikan dan melakukan pemeliharaan atas ERP yang akan diimplementasikan?
    • Apakah setelah Go Live dan menyelesaikan masa stabilisasi Tim TI diharapkan dapat mandiri untuk melakukan eksplorasi lebih mendalam guna mengakomodir kemungkinan-kemungkinan kustomisasi lanjutan? Kalau iya, seberapa besar kemungkinannya dan pemenuhan faktor-faktor pendukungnya?

Yang menantang setelah ini adalah menyusun worksheet sampai dengan weighting untuk tiap kriteria detail, sehingga tiap produk dapat dinilai secara fair dari berbagai sisi. Tapi sepertinya sebelum memilih, perlu menetapkan dulu kandidatnya, dan saringan pertama yang paling penting adalah memahami level perusahaan kita: enterprise atau SME?