Pengalaman baru: menjadi anggota IT Steering Committee

Tertanggal mulai 30 Mei 2012, saya menjadi anggota IT Steering Committee dari pihak eksternal di salah satu BUMN transportasi. Ini merupakan pengalaman pertama, dan sekaligus tantangan untuk membumikan teori-teori dalam berbagai buku, framework dan standar tentang IT Strategy Committee atau IT Steering Committee.

Secara garis besar pekerjaannya adalah sebagai berikut:

  1. Memberikan masukan tentang agenda-agenda penting yang harus diambil keputusan pada pertemuan reguler IT Steering Committee. Untuk tahapan kritis saat ini, pertemuan tersebut bisa per bulan atau per 2 bulan.
  2. Membantu “working group” untuk menyiapkan bahan-bahan yang akan dibawa dalam pertemuan ITSC tersebut. Kajian di sini dikerjakan secara remote dengan tim internal mereka. Topiknya bisa sangat bermacam-macam, tergantung dengan setting agenda yang telah ditetapkan di depan.
  3. Ikut menghadiri rapat ITSC dan sekaligus memberikan pendapat tentang pembahasan agenda, misalnya tentang alternatif-alternatif solusi yang bisa diambil.

Rasanya memang setengah konsultan dan setengah klien. Tantangan terbesar adalah bagaimana bisa merasakan apa yang terjadi seperti mereka merasakan.

Manajemen Investasi: Kelemahan Utama IT Blueprint

IT Blueprint itu bisa strategis, bisa tidak. Kualitas sebuah IT Blueprint akan ditentukan seberapa besar dampaknya atas organisasi atau perusahaan. Semakin strategis kalau dampaknya semakin besar.

Mungkin 90% orang yang mengerjakan IT Blueprint itu basic utamanya memang orang TI. Karena orang TI, seringkali terlalu asyik membuat desain teknikal yang sophisticated. That’s right, but not enough. Dalam sebuah presentasi tender di salah satu BUMN yang akhirnya kami menangkan, kami ditanya tentang apakah kunci dari IT Blueprint yang akan kami usulkan itu akan jalan? Saat itu saya jawab: Manajemen Investasi TI!! Sebaik apa pun Bapak/Ibu punya desain teknis arsitektur aplikasi, arsitektur infrastruktur dan organisasi TI, tak akan bisa dijalankan kalau tak ada manajemen investasinya.

Manajemen investasi ini setidaknya menginformasikan:

  1. Apa hubungan sebuah proyek TI dengan agenda strategis bisnis?
  2. Apa value yang akan tercipta dengan implementasi TI ini?
  3. Berapa cost project yang harus disiapkan dalam sebuah durasi tahun tertentu?
  4. Berapa benefit kuantitatif dan kualitatif atas proyek TI yang akan dijalankan?
  5. Bagaimana studi kelayakan ekonominya? Mau pakai apa? Cost-Benefit Analysis, IRR, Payback Period, ……..

Manajemen investasi ini sebaiknya dikemas lagi dalam dokumen-dokumen Business Case. Kalau menggunakan pendekatan Program/Project Portfolio, minimal setiap Program TI (setiap program TI akan terdiri dari beberapa proyek TI) akan memiliki business case ini. Business case ini berisi 5 poin utama di atas, plus manajemen risiko dan manajemen perubahan yang dibutuhkan.

Jadi “tool marketing” dari IT Blueprint itu pasnya bukan dokumen IT Blueprint yang biasanya tebal-tebal itu, tapi business case program. Jadi IT Blueprint kita bahasakan dalam bahasa bisnis. Sepertinya ke depan cara-cara seperti di atas akan lebih memberikan dampak bagi organisasi.

KESIMPULAN: Membuat IT Blueprint itu tak susah, yang susah itu melaksanakannya. Manajemen Investasi dan Business Case diperlukan untuk memudahkan pelaksanaan yang susah itu.

Persoalan umum implementasi TI di Rumah Sakit

Program CPE kedua tentang Penyusunan IT Blueprint untuk Rumah Sakit alhamdulillah berjalan lancar kira-kira 2 minggu yang lalu. Yang menarik dari penyelenggaraan kedua ini adalah tipikal pesertanya. Jika di penyelenggaraan pertama pesertanya mayoritas memang orang TI, di penyelenggaraan kedua ini adalah manajemen eksekutif rumah sakit dan bahwan owner rumah sakit (dalam hal ini RS swasta).

Tentu saja cara pandangnya jadi agak beda, dan karena itu pula materi-materi dimodifikasi ulang. Intinya lebih ditekankan kepada hal-hal strategis seperti:

  1. Seberapa strategis sih TI untuk rumah sakit?
  2. Bagaimana memposisikan TI sebagai alat untuk menjadi competitive/comparative advantage dibandingkan dengan RS lain?
  3. Plus state-of-the-art arsitektur aplikasi dan infrastruktur

Beberapa yang menarik dan menjadi kesimpulan dari training adalah sbb:

  1. Setelah membahas berbagai case yang ada, akhirnya dapat kesimpulan bersama: TI itu strategis lho untuk Rumah Sakit-Rumah Sakit di Indonesia.
  2. Setidaknya poin pertama menjadi referensi penting. Nah, tapi nilai strategis TI bagi RS-RS di Indonesia masih jauh dari potensi yang sebenarnya ada. Beberapa persoalan berikut ini yang sempat dibahas dalam sesi training kemarin itu.
    • Strategic Alignment yang masih rendah – RS-RS di Indonesia secara umum masih belum memiliki pola bagaimana menurunkan arahan strategis TI yang diturunkan dari rencana bisnis RS. Karena pembahasan ini jarang sekali dilakukan, akhirnya implementasi TI di RS mayoritas hanya mengikuti trend: sistem informasi ini dan itu…. Kalau tetangga pakai itu, ya kita butuh itu…. sederhananya begitu. Jadi secara faktual memang TI belum dianggap hal strategis, walaupun teorinya disadari strategis.
    • Kapasitas manajemen TI yang belum optimal Struktur organisasi di RS-RS pemerintah sudah ditetapkan oleh regulasi dari depkes. Nah, regulasi dari Depkes ini sepertinya belum “tersibghoh” dengan panduan Tata Kelola TI yang dikeluarkan oleh Dewan TIK Nasional. Mau membuat Komite TI juga agak susah, karena berdasarkan regulasi tersebut sebuah komite harus di bawah salah satu direktur. Hal ini tidak dihadapi oleh RS swasta. Jadi ada bbrp RS swasta yang posisi TI di leher, sehingga jauh lebih powerfull.
    • IT Leadership yang masih lemah – Harus diakui bahwa mayoritas RS masih memandang TI hanya sekedar supporting, alat untuk ngolah data dan buat laporan. Nothing else. Manajemen eksekutif RS belum memposisikan TI sebagai aset strategis bagi bisnis RS. Faktor ini, ditambah dengan faktor kapasitas manajemen TI yang terbatas, berkelindan menjadi sebuah titik lemah utama implementasi TI di RS Indonesia.
    • SDM TI RS yang masih lemah SDM TI di RS Indonesia, mostly, belum sekuat seperti di sektor-sektor bisnis lainnya. Mungkin ini terkait dengan persepsi atas TI yang belum dianggap aset strategis di atas.
    • Tingkat kegagalan yang tinggi dalam implementasi sistem informasi – Yang menarik, ternyata jarang sekali RS yang bisa sekali jadi untuk implementasi aplikasi SIM Rumah Sakit mereka. Kegagalan 3-4 kali ternyata banyak sekali ditemui. Apakah ini karena ketidakmampuan vendor-vendornya ataukan pola hubungan TI (plus vendor) dengan BPO (Business Process Owner) di RS yang tidak baik? Perlu ditelaah lebih lanjut untuk hal ini.
    • Sistem banyak tapi tetap susah mendapatkan informasi manajemen – Sistem aplikasi banyak dikembangkan, tetapi masih pulau-pulau terpisah. Kalau mau terintegrasi, banyak yg akhirnya harus memakai solusi satu vendor. Tentu saja ada risiko di sini.

Semoga bermanfaat untuk mentransformasi RS di Indonesia, sehingga masyarakat lebih suka membelanjakan dananya di RS Indonesia daripada ke RS negeri tetangga yang menampung uang-uang hasil jarahan dari negeri kita ini. Sudah sumberdaya kita dicuri, uang hasil korupsi ditampung mereka, eh… sakit pun kita lebih suka ke sana.

Sorry utk paragraf terakhir.

Komite TI di Rumah Sakit?

Dari training bulan Desember 2009 (IT Blueprint Untuk RS) banyak sharing tentang permasalahan yang ada di penyelenggaraan TI Rumah Sakit. Yang menarik adalah beragamnya posisi TI dalam struktur organisasi. Ada yang di leher, ada yang di bawah salah satu direktur (dipimpin Manajer TI), atau ada yang hanya sebuah seksi yang menjadi bagian dari kesekretariatan.

Ada statemen dari peserta yang menarik: “Kalau ditanya ke pimpinan apakah TI itu penting, maka semua pimpinan akan selalu bilang bahwa TI itu penting. Tapi dalam kenyatannya tidaklah seperti itu. Untuk mendapatkan dana bagi pengembangan tidaklah mudah. Mayoritas kesibukan adalah menghandle hal-hal operasional harian, sehingga aspek strategis hampir tidak tersentuh”.

Kalau melihat best-practices IT Governance, sepertinya aspek IT Leadership di mayoritas RS Indonesia mungkin belum terlalu kuat. Mungkin ini jadi sebab utama mengapa alignment TI dan Bisnis RS jarang sampai pada level strategis, sehingga mayoritas keberadaan TI di RS hanya untuk otomasi proses bisnis saja. Mungkin masih jarang RS yang menempatkan TI sebagai aspek strategis, sebagai salah satu strategi meningkatkan customer retention atau bahkan memenangkan persaingan. Secara umum dari peserta training sepertinya yg menjadi value dari TI masih terbatas pada efisiensi saja, walaupun belum ada yang sampai bisa membuat analisa kuantitatif tentang ini.

Salah satu wacana yang ada dalam training ini adalah mungkinkah membentuk Komite TI di Rumah Sakit?

Saya pernah punya pengalaman di dua BUMN yang pada awalnya ownership dari program-program TI sangat lemah, sehingga TI tak terlalu dianggap di perusahaan itu. Salah satu obat mujarab adalah menguatkan IT Leadership dengan pendekatna Komite TI ini. Komite TI dipimpin bukan orang TI, tapi salah satu top executive perusahaan dan beranggotakan seluruh stakeholder, dimana TI ada di situ juga. Komite ini punya dua agenda prioritas misalnya seperti ini:

  1. Menetapkan agenda-agenda TI strategis bagi perusahaan. Jadi nanti kalau agenda strategis itu dieksekusi, maka sponsorship dipastikan didapatkan.
  2. Melakukan review atas kinerja TI dan value yang tercapai dari implementasi TI.

Mungkin ini bisa dipertimbangkan, biar effort TI lebih memiliki value.

Blueprint TI Rumah Sakit

9-10 Desember 2009, minggu lalu, kami menyelenggarakan CPE tentang Penyusunan Blueprint TI untuk Rumah Sakit. Peserta yang hadir di antaranya dari RS Cipto Jakarta, RS Imanuel Bandung, RS Santo Yusuf Bandung, RS Atmajaya Jakarta, RS Pasar Rebo Jakarta, RS Islam Pondok Kopi, RS Islam Cempaka Putih Jakarta, PKU Muhammadiyah Bantul, RS Fatmawati Jakarta, RS Gambiran Kediri.

Berikut ini adalah materi-materi yang dibahas dalam CPE minggu lalu itu:

  1. Strategi Alignment antara TI dan Bisnis Rumah Sakit
  2. State of The Art Arsitektur Aplikasi untuk Rumah Sakit
  3. State of The Art Arsitektur Infrastruktur untuk Rumah Sakit
  4. State of The Art Tata Kelola TI untuk Rumah Sakit
  5. Manajemen Investasi dan Roadmap
  6. Step-by-step penyusunan Blueprint TI untuk Rumah Sakit (disertai template yang telah disediakan sebelumnya)

Berdasarkan sharing yang ada di CPE ini, implementasi TI di Rumah Sakit termasuk bidang yang mungkin termasuk tertinggal dibandingkan dengan bidang-bidang lain. Terutama hal ini terjadi di kabupaten/kota, di luar ibukota propinsi. Implementasi TI untuk membantu proses bisnis Rumah Sakit masih terbatas. Masalah-masalah umum yang ada, yang sempat dishare misalnya adalah:

  1. Permasalahan Arsitektur TI
    • Sudah banyak dikembangkan aplikasi, tetapi aplikasi berdiri sendiri-sendiri sebagai pulau-pulau terpisah.
    • Khususnya untuk Rumah Sakit pemerintah, regulasi hampir tiap tahun berubah dan seringkali perubahan ini cukup drastis merubah proses bisnis, yang pada akhirnya membuat banyak perubahan di sisi sistem aplikasi
    • Aspek keamanan saat ini belum terlalu diprioritaskan, karena masalah harian mayoritas adalah aspek fungsionalitas sistem aplikasi, bagaimana bisa mengakomodir keinginan stakeholder yang bergerak cepat.
    • Infrastruktur TI mayoritas tidak didesain berdasarkan asas-asas desain infrastruktur yang memperhatikan aspek keamanan dan skalabilitas. Mungkin hal ini karena dianggap infrastruktur hanya support saja.
  2. Permasalahan Tata Kelola TI
    • Pengembangan sistem aplikasi seringkali gagal. Beberapa rumah sakit yang hadir di CPE ini ada menceritakan harus melakukan pembongkaran total sehingga baru di implementasi ketiga sistem bisa berjalan. Tentu saja ini melibatkan pergantian produk dan vendor yang berulang.
    • Posisi TI dalam struktur organisasi yang “MojoK”, minjam istilah Pak Rahmat dari RSCM. Posisi yang “mojok” ini dikarenakan persepsi TI yang dianggap bukan hal strategis di Rumah Sakit. Atau kalaupun dianggap strategis, tetapi pada kenyataanya sponshorship dari top management tidaklah terlalu kuat.
    • Organisasi TI mayoritas “dipaksa” untuk hemat SDM, sehingga untuk membuat struktur organisasi yang ideal harus banyak memutar otak.

Terima kasih bagi seluruh peserta atas kepercayaannya. Semoga ke depan benar-benar bisa terlaksana adanya forum penggiat TI untuk Rumah Sakit di Indonesia, seperti yang disampaikan di penutupan training.

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.