ERP dan Leadership

Saat ini tim saya sedang membantu salah satu perusahaan untuk mengimplementasikan ERP. Level perusahaan ini Enterprise, jadi alternatif ERP Package yang akan diimplementasikan ERP sekelas SAP, Oracle dsj. Berikut ini kira-kira SOW-nya:

  1. Merekomendasikan pilihan produk ERP Package yg tepat
  2. Membantu penyusunan TOR, dengan fokus pada SOW, estimasi kebutuhan investasi dan pendampingan Manajemen Perubahan (organisasi dan individu)
  3. Membantu dalam pemilihan implementor-nya (rekomendasi kandidat-kandidat implementor, penetapan pemenang tetap di Tim Internal)
  4. Melakukan supervisi atas implementasi oleh implementor

Setelah 1 bulan baca kondisi lingkungan, semakin saya yakin kalau implementasi ERP itu harus disikapi bukan sebagai implementasi teknologi, bukan itu…. Perspektif paling dasar yg perlu disadari adalah bahwa itu adalah usaha untuk transformasi bisnis. Kalau di perusahaan yang akan implementasi ERP ini, dia bilang bahwa itu adalah usaha dia untuk memiliki World Class Service.

Kemarin sudah kick-off, dihadiri DIrut, Dirkeu dan hampir seluruh Senior Manager di perusahaan itu. Semoga ini awal yg baik, terutama karena komitmen Leadership sangat kuat. Bahkan mereka minta dijadwalkan rutin pertemuan Steering Committee (terdiri dari Direksi dan Senior Manager): 1 bulan, tri wulanan?

Statistik mengatakan kalau faktor leadership adalah faktor yang menjadi CSF (Critical Success Factor) untuk implementasi inisiatif ERP kayak gini.

Tak cuma komitmen yang dibutuhkan di Leadership ini, tapi cuma kepercayaan atas asas-asas profesional: hanya pilihan produk dan implementor terbaik yang dipilih. Karena nilainya guede, cerita Dirut dan Dir. Keuangannya: sudah banyak pihak yang menanyakan hampir tiap hari, dan tentu saja jaringan-jaringan politik juga bermain, karena ini BUMN. Tapi ada yg melegakan, kami tak mendapat “titipan” apa pun, jadi bisa bekerja dengan lebih tenang.

Sedihnya TI di pemerintahan kita…

Beberapa minggu lalu dalam sebuah aktifitas untuk identifikasi kebutuhan data dan sumber-sumber data dalam rangka pengembangan Datawarehouse-Business Intelligence di salah satu departemen, salah satu tim pengambil data kecele setengah mati karena ditolak di salah satu direktorat:

Anda tidak bawa “modal”?

Duh, bukankah kalau sistem DW-BI ini jadi akan memudahkan mereka juga? Dan bukankah itu data bukan punya mereka, itu punya negara!!!!!!! Pengin nonjok saja itu wajah orang yg ngomong sangat sangat sangat tak pada tempatnya itu. Ngambil data di hampir semua bagian juga sangat sangat sulit.

Yang kedua yang paling aneh tapi nyata, kalau buat DW-BI itu seharusnya data-source dari sistem-sistem traksaksional harus sudah jalan, sehingga posisi strategis DW-BI untuk bisa mendukung monitoring proses bisnis, monitoring kinerja dan pengambilan keputusan benar-benar bisa optimal. Dalam kasus yg saya sedang alami ini, data-source sangat-sangat tak terstruktur, tak sistematis dan bisa dibilang mayoritas masih manual!! Benar-benar ini proyek tergila yang saya pernah jalani. Kapok… benar-benar kapok ngerjain yg kayak gini di pemerintahan.

Yang bikin sangat sedih, bagaimana keputusan nasional terkait keberadaan departemen ini ya? Bagaimana kualitas kebijakan dan keputusan nasional strategis kalau datanya saja masih amburadul seperti ini? Untuk apa rakyat harus bayar pajak kalau penyelenggaraan negara ini masih saja seperti ini? Ini benar-benar seperti masuk dunia pra-sejarah saja….

Duh, semoga dimudahkan dalam waktu tersisa ini. Lebih pening ngurus hal-hal yang non-teknis seperti ini dibandingkan diharuskan overtime berhari-hari tapi jelas ujungnya. Semoga Anda tak mengalami yang seperti ini…

Apa kriteria kepatuhan atas PBI 9/15/PBI/2007?

JIka membaca PBI 9/15/PBI/2007 dan SE No. 30/DPNP (lebih khusus di lampiran SE-nya), ada 10 area utama yang akan direview untuk memastikan kepatuhan atas PBI:

  • Manajemen
  • Pengembangan dan pengadaan
  • Aktifitas operasional TI
  • Jaringan komunikasi
  • Pengamanan informasi
  • Business continuity plan
  • End user computing
  • Electronic banking
  • Audit intern teknologi informasi
  • Penggunaan pihak penyedia jasa TI

Kalau dilihat dari Lampiran tentang laporan apa saja yang harus diserahkan oleh Bank ke BI, menurut saya dapat ditarik secara high level bahwa kriteria kepatuhan atas PBI adalah:

  • Keberadaan dan jalannya struktur & peran tata kelola dalam manajemen risiko, yaitu:
    • Dewan Komisaris
    • Dewan Direksi
    • IT Steering Committee
    • Pejabat Bidang TI
    • Organisasi TI
  • Jalannya PROSES Manajemen Risiko TI, yaitu:
    • Keberadaan framework manajemen risiko (setiap bank akan punya framework sendiri-sendiri, sesuai dengan karakteristik bisnisnya. SE eksplisit mengatakan ini). Effort di domain ini harus serius dilakukan setiap bank, karena mensintesa framework yang sesuai dengan karakter bisnis dan manajemen bukan persoalan sederhana.
    • Jalannya siklus manajemen risiko: assessment, analisa dan mitigasi. Dokumentasi sebagai bukti jalannya proses ini harus disertakan.
  • Kecukupan kontrol dalam bentuk rencana, kebijakan dan prosedur (desain dan operasional), yaitu:
    • IT Strategic Plan
    • Kebijakan prosedur terkait dg pengembangan dan pengadaan
    • Kebijakan prosedur terkait dg Aktifitas operasional TI
    • Kebijakan prosedur terkait dg Jaringan komunikasi
    • Kebijakan prosedur terkait dg Pengamanan informasi
    • Kebijakan prosedur terkait dg Business continuity plan
    • Kebijakan prosedur terkait dg End user computing
    • Kebijakan prosedur terkait dg Electronic banking
    • Kebijakan prosedur terkait dg Audit intern teknologi informasi
    • Kebijakan prosedur terkait dg Penggunaan pihak penyedia jasa TI

Cara pandang di atas sebenarnya merujuk pada kriteria kepatuhan dalam rangka sertifikasi ISO 27000 (information security management system) atau ISO 20000 (IT Service Management). Intinya ada [1] struktur yang menjalankan proses, [2] jalannya proses dan [3] kontrol yang memadai.

Karena kata akhir status kepatuhan adalah haknya BI, jadi pihak auditor eksternal yang membantu auditor internal fitting-the-gap hanya bisa berpegang pada lingkup laporan yang harus disampaikan Bank ke BI. Dari situ pinter-pinternya kita saja membuat portofolio program yg paling efisien.

Mungkin kalau ada yg punya pendapat lain bisa sharing juga.

Ikhtisar Panduan Audit TI dalam rangka kepatuhan atas PBI 9/15/PBI/2007

Berikut ini adalah ikhtisar (ringkasan) lingkup Panduan Audit TI dalam rangka kepatuhan atas PBI No. 9/15/PBI/2007. Salah satu aspek kepatuhan ini adalah keberadaan dan berjalannya fungsi Audit Internal di setiap bank.

konstruksi-panduan-audit-it-pbi-it-risk-management

Tentu saja pembagian kriteria panduan dalam kategori umum dan khusus hanya dilakukan untuk mempermudah pemahaman dan penggunaan saja. Panduan Umum berlaku atas seluruh sistem TI, jadi mirip-mirip sama standarlah kalau merujuk ke cara pandang ISACA. Sedangkan Panduan Khusus hanya diperuntukkan spesifik sistem terkait, misalnya panduan khusus audi e-banking ya hanya berlaku untuk e-banking saja.

Saat ini kami sedang menyelesaikan breakdown audit dan kontrol TI dalam rangka kepatuhan atas PBI No. 9/15/PBI/2007 ini.

Sharing data ilegal??

Suatu saat ada sebuah perusahaan asuransi menelpon untuk menawarkan produknya. Ternyata dia dapat data dari sebuah Bank BUMN, dimana saya punya kartu kredit di situ. Ini tidak hanya sekali dua kali, tapi berkali-kali. Pernah juga ternyata perusahaan yang menghubungi itu mendapatkan data dari sebuah operator telekomunikasi, dimana saya punya nomor postpaid di situ.

Seringkali ini membuat tak nyaman. Masalahnya, si sumber data (bank & operator telco tadi) tidak bisa disalahkan karena ketika kita mengajukan application, di situ kita tidak disediakan pilihan: apakah data kita boleh dishare ke pihak lain atau tidak. Di negara yang menghargai privacy, selalu ada dua pilihan itu.

Seharusnya data-data pribadi itu nggak boleh dishare seperti itu. Yg jadi pertanyaan lagi, adakah kompensasi finansial dari sharing itu, yg didapatkan pihak yang mempunyai database? Kalau ada kompensasi finansial, apakah memang si perusahaan yg menyimpan data nasabah/customernya itu berhak dengan seenaknya melakukan sharing itu? Belum tahu, apakah hal ini sudah dicover oleh UU ITE yang baru disahkan itu.

Manajemen Risiko Perbankan: Satu Alternatif

COMPLIANCE (kepatuhan) atas regulasi hanya salah satu driver dalam bisnis perbankan atau bisnis apa pun. Tapi kalau hanya compliance yang jadi driver, maka sungguh tidak menarik bisnis itu, karena dari hari ke hari kita hanya memenuhi tuntutan regulasi. Capek…. begitu kata orang. Beda dengan kalo kita punya driver untuk memanfaatkan sebuah opportunity bisnis yang lebih menantang, maka itu akan memberi motivasi lebih kuat, karena dibangkitkan dari internal diri atau perusahaan kita.

Dengan cara pandang seperti di atas, maka kalau sebuah bank memperbaiki pengelolaan risikonya hanya karena pengin mematuhi PBI No. 9/15/PBI/2007, selain capek psikologis juga tidak ada banyak nilai tambah yang akan dicapai. Sikap reaktif secara jangka panjang juga tidak akan menyehatkan kondisi manajemen TI. Pertanyaannya, kira-kira apa nilai tambah dari sebuah kepatuhan atas PBI No. 9/15/PBI/2007 dan bagaimana mencapainya?

Selain aspek kepatuhan, berikut ini adalah nilai tambah yang mungkin dapat dirasakan dengan memanfaatkan momentum PBI No. 9/15/PBI/2007:

  1. Manajemen risiko hanya satu domain dalam Tata Kelola TI (IT Governance), sehingga keberadaan tuntutan manajemen risiko TI adalah peluang untuk memperbaiki IT Governance secara keseluruhan: Strategic Alignment, Resource Management, Performance Measurement & Value Delivery.
  2. Kesempatan untuk menajamkan strategic aligment adalah kesempatan untuk menangkap kesempatan-kesempatan baru bisnis. Teknisnya, ini adalah kesempatan untuk melihat kembali Arsitektur TI kita apakah sudah mencerminkan strategi bisnis atau belum.
  3. Kesempatan untuk menajamkan value delivery juga merupakan refleksi kemungkinan untuk meningkatkan efisiensi investasi TI kita.

Menurut saya ada beberapa kriteria berikut yang bisa merefleksikan apakah strategi yang akan kita pakai bisa menciptakan nilai tambah selain kepatuhan:

  1. Apakah arsitektur TI dan rencana TI kita sesuai dengan kebutuhan bisnis?
  2. Apakah program tata kelola yang dimiliki/direncanakan mendukung realisasi dan operasional arsitektur TI dalam rangka dukungannya kepada kebutuhan bisnis?
  3. Apakah program tata kelola, terutama terkait langsung dengan IT Security, terintegrasi dengan implementasi arsitektur IT Security?

Berikut ini poin-poin strategi yang dapat dipertimbangkan untuk menciptakan nilai tambah lebih dari implementasi PBI No. 9/15/PBI/2007:

  1. Mandatory – Bank harus memiliki Framework Manajemen Risiko TI yang akan digunakan untuk melakukan assessment, menganalisa, mengukur dan memonitor risiko TI. Risk Register sebagai output akhir harus terjaga konsistensi pendekatannya, dan itulah gunanya ada framework. Keberadaan framework juga akan menjadi satu bahasa referensi antara orang TI, internal auditor, dan bahkan eksekutif.
  2. Mandatory – Bank harus memiliki program tata kelola IT Security, yang berisi kebijakan, standar dan prosedur yang memadai atas area-area security utama yang tercantum di PBI No. 9/15/PBI/2007.
  3. Mandatory – Bank harus memiliki struktur organisasi dan pembagian roles & responsbilities yang baik sehingga program tata kelola IT Security dapat dioperasionalkan secara normal, mulai level dewan komisaris, direksi, komite-komite, manajemen TI sampai dengan end-users.
  4. Suggested – Manajemen TI menyusun IT Security Architecture yang akan menjadi blueprint pengelolaan security di bank bersangkutan. Ini akan menjadi perekat dari program tata kelola IT Security, Operasional IT Security dan pengelolaan program IT Security (awareness, education, risk management, planning).
    • Satu poin spesial dalam Security Architecture adalah bagaimana kita mengelola pattern terkait dengan teknologi: infrastruktur dan aplikasi bisnis. Biasanya ini dikelompokkan dalam Technological Security Architecture.
    • Berbagai kebijakan dan standar harus terintegrasi dalam arsitektur teknologi, karena tidak mungkin mengelola security secara manual saat ini. Berbagai tool dan teknologi harus dipastikan selalu mengikuti dinamika perubahan tata kelola security. Inilah pentingnya IT Security Architecture.
  5. Suggested – Memperluas inisiatif pengembangan program tata kelola security menjadi inisiatif pengembangan Program Tata Kelola TI (IT Governance) dengan menggunakan rujukan standar atau best practice seperti ISO 20000 (ITSM), ISO 27000 (ISMS) atau COBIT. Pendekatan ini dalam jangka menengah-panjang akan membuat TI bank lebih adaptif di masa depan, selain memberikan competitive advantage dalam perspektif persaingan.

PBI No. 9/15/PBI/2007 : Manajemen Risiko TI Bank Umum

BI mengeluarkan peraturan terbaru mengenai Penerapan Manajemen Risiko dalam Penggunaan Teknologi Informasi oleh Bank Umum, melalui PBI No. 9/15/PBI/2007. Dalam konteks Basel II, risiko TI merupakan bagian dari risiko operasional di perbankan. Semakin strategis dan kritikalnya penggunaan TI, maka risiko TI dapat dikatakan sebagai penyumbang terbesar risiko TI operasional sebuah bank.

Apa isi PBI No. 9/15/PBI/2007?

Berikut ini resume sedikit tentangnya:

  1. Lingkup Manajemen Risiko TI (Pasal 2) setidaknya mencakup hal berikut:
    • pengawasan aktif dewan Komisaris dan Direksi;
    • kecukupan kebijakan dan prosedur penggunaan Teknologi Informasi;
    • kecukupan proses identifikasi, pengukuran, pemantauan danpengendalian risiko penggunaan Teknologi Informasi; dan
    • sistem pengendalian intern atas penggunaan Teknologi Informasi.
  2. Kebijakan dan prosedur penggunaan TI setidaknya mencakup area kunci berikut:
    • Manajemen;
    • Pengembangan dan pengadaan;
    • Operasional Teknologi Informasi;
    • Jaringan komunikasi;
    • Pengamanan informasi;
    • Business Continuity Plan;
    • End user computing;
    • Electronic Banking; dan
    • Penggunaan pihak penyedia jasa Teknologi Informasi.
  3. Kewajiban untuk memiliki IT Strategic Plan
  4. Keberadaan Framework Manajemen Risiko TI yang akan digunakan sebagai tool untuk menilai, mengukur dan memonitor keberadaan risiko-risiko TI. PBI memberikan kerangkanya, jadi setiap Bank harus mengembangkan framework sesuai dengan kebutuhannya.
  5. Kewajiban melaporkan aktifitas manajemen risiko yang telah dilakukan oleh Bank ke BI secara reguler. Beberapa form pelaporan telah diberikan di peraturan ini.

Untuk memahami PBI secara tuntas, kita perlu membaca 2 dokumen berikut ini:

  1. Peraturan BI No. 9/15/PBI/2007 dan penjelasannya
  2. Surat Edaran BI No. No. 9/30/DPNP tentang manajemen risiko TI

Dan yang menarik: peraturan ini berlaku efektif 31 Maret 2008 !!

Saya coba upload semuanya di sini, biar tak perlu nyari lagi ke website BI.

  1. Peraturan BI No. 9/15/PBI/2007
  2. Peraturan BI No. 9/15/PBI/2007 – Penjelasan
  3. Surat Edaran BI No. No. 9/30/DPNP
  4. Surat Edaran BI No. No. 9/30/DPNP (penjelasan)

Posting selanjutnya semoga bisa membahas sekilas tentang bagaimana pendekatan yang dapat dilakukan sebuah bank untuk mengimplementasikan Manajemen Risiko TI tersebut: pendekatan, referensi, added-value lain yang bisa di-create.