Salah satu teman yang gabung dengan Global Ikhwan (dulu namanya Rufaqa) memposting di milis tentang Club Poligami yang dideklarasikan di Hotel Grand Aquilla Bandung, beritanya ada di Antara. Seperti biasa, ujung-ujungnya apa pun thread-nya adalah junk… junk.. junk… komedi. hehe…

Menurut saya perdebatan poligami dikarenakan adanya pendapat yang berbeda, apa itu hukum poligami. Ada yang berpendapat sebagai PINTU DARURAT dan ada juga yang berpendapat SUNNAH MUAKKAD.

PINTU DARURAT

Darurat ini bisa dalam level individu dan sosial. Dari individu misalnya adalah terjadi sesuatu pada istri sehingga tidak mungkin lagi memenuhi kewajibannya kepada suami. Secara sosial bisa jadi karena terjadi peperangan besar sehingga banyak laki-laki meninggal di pertempuran, sehingga banyak janda yang harus dipelihara kehormatannya. Itu darurat, artinya jika dan hanya jika persyaratannya dipenuhi maka baru boleh poligami. Jadi kalau kondisi normal, ya cukup monogami.

SUNNAH MUAKKAD

Muakkad artinya diutamakan. Seperti tahajud, itu sunnah muakkad. Diutamakan karena hampir-hampir Rasulullah tidak pernah meninggalkannya. Jadi kalo muakkad, berarti sangat disarankan untuk dilakukan.

DARURAT atau MUAKKAD?

Di Al Qur’an memang disebutkan seorang laki-laki muslim dapat beristri 4 wanita, tetapi kalau tidak bisa berbuat adil maka cukuplah 1. Artinya defaultnya ya 1 istri, bukan 4 istri. Berdasarkan pemahaman ini maka saya lebih cenderung setuju dengan pendapat bahwa poligami itu pintu darurat. Islam ini agama yg sangat manusiawi dan jalan tengah, menyadari bahwa mungkin saja itu dibutuhkan tetapi tidak juga melepaskannya begitu saja sehingga bisa disalahgunakan.

Karena itu saya tak setuju dengan Club Poligami, karena poligami adalah pintu darurat bukan disarankan untuk seluruh orang agar melakukan. Membuat Club berarti mempromosikan untuk seluruh orang dan menyarankan seluruh orang untuk melakukannya.

Bulan ini sampai nopember diminta teman untuk gabung buat Roadmap FOSS Indonesia. Kerjaan ini di Kominfo. Pertemuan pertama ketemu dengan beberapa orang dari BPPT/Ristek, Aspiluki dan Pak Made Wiryana sebagai salah satu god father FOSS di Indonesia. Pertemuan yang menarik dengan masukan yang sangat konstruktif.

Kalau 5 tahun ke depan, mungkinkan sebagian besar layanan publik menggunakan FOSS yang diproduksi oleh anak negeri? Mungkinkan 10 tahun ke depan FOSS semakin banyak diadopsi oleh sektor swasta bahkan bisa menjadi salah satu komoditi ekspor, seiring dengan tumbuhnya industri perangkat lunak di Indonesia dan sinergisme dunia pendidikan, pelatihan dan penelitian?

Kami sekarang sedang mengumpulkan berbagai literatur penunjang, khususnya bagaimana FOSS yang sudah berhasil di negara-negara lainnya. Kalau ada masukan, sangat berterima kasih.

Sungguh tak bisa diterima akal, alasan Telkomsel melakukan penyunatan dan perubahan sepihak kesepakatan dengan pelanggannya. Inilah alasan “tak profesional” tersebut:

Pemberlakukan ini didasarkan pada keinginan untuk membatasi 10% abusive user yang secara dominan menghabiskan resources network dengan penggunaan hingga puluhan bahkan ratusan GB yang mengakibatkan gangguan terhadap pengguna lain karena menyebabkan penurunan kualitas secara signifikan.

Apa hubungannya kegiatan 10% abusive user tersebut dengan 90% yang bener? Keduanya, begitu tak berdayanyakah Telkomsel sehingga tak bisa manage pelanggannya sendiri? Bukankah mereka yang megang sendiri end-to-end Arsitektur Teknologinya? Kecuali memang kalo Telkomsel sudah tak mau repot ngurus itu kemudian di-outsource. Tapi ini rasanya tak mungkin.

Walaupun banyak teman-teman di Telkomsel, tapi dalam hal ini saya tak sepakat dengan mereka. Seharusnya praktik seperti ini dihukum keras, karena operator bukan TUHAN yang seenaknya sendiri mengubah kesepakatan dengan pelanggannya. Bukankah operator-operator Telco itu juga dengan keras menghukum pelanggannya yang tak taat dengan kesepakatan awal?

Kalau di Eropa atau Jepang, sudah dihukum berat nih pelayanan kacau seperti ini.

Jadi ya siap-siap saja migrasi besar-besaran pelanggannya yang kecewa ini.

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.

	Federal Reserve Board,
	Federal Deposit Insurance Corporation,
	National Credit Union Administration,
	Office of the Comptroller of the Currency, and
	Office of Thrift Supervision.

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.

Sudah lama saya pengin nulis buku yang terkait dengan IT Assurance. Referensi dalam bahasa Indonesia untuk IT Assurance masih terbatas, walaupun sudah ada beberapa buku yang membahas tentang Audit TI atau implementasi COBIT, yang sempat saya temukan di Gramedia.

Mimpinya bisa bikin buku-buku yang terkait dengan dunia IT Assurance & IT Orchestration, dan kemudian dishare lewat internet. Gruatis…… Kalau melihat istri yang sudah berhasil menerbitkan buku di Mizan, memang harus dicicil, karena kerjaan utama saya bukan penulis. Tetapi memang harus punya frame dulu dari awal, jadi kalau nyicilnya bisa loncat-loncat tak mengapa.

Semoga….

Enterpreneurship Rasulullah

Oleh Aa Gym

Ternyata dalam kajian Rasulullah, ada masa hidup beliau yang kurang kita bahas yaitu bagaimana Muhammad menjadi menjadi profesional. Rasulullah sebagai bukti bahwa dengan memiliki jiwa enterpreneur maka orang akan mampu mengendalikan apa saja.

Usia 6 tahun beliau sudah yatim piatu dan tidak punya pegangan. Sampai usia 8 tahun 2 bulan kakek yang membina dan mendidiknya wafat, setelah itu ia dalam perlingungan pamannya Abu Thalib yang tidak sekaya kakeknya, mulai saat itulah pemuda kecil Muhammad menggembala kambing, mencari nafkah sendiri.

Bayangkan umur 12 tahun, Rasul sudah diajak pamannya berdagang ke Syiria yang jaraknya ribuan kilometer. Sepulang dari perjalanan itu, beliau sering bisnis bahkan sampai ke seluruh Jazirah Arab sudah terkenal seorang profesional muda bernama Muhammad. Subhanallah, ketika meminang Siti Khadijah beliau memberi mas kawin sebesar dua puluh ekor unta muda atau hampir setengah miliar rupiah.

Mulailah tanamkan jiwa enterpreneur pada anak-anak kita. Mempersiapkan keturunan kita juga merupakan tanggung jawab kita kepada umat ke depan. Didik anak-anak kita dari kecil, buat jadi mandiri, bebas, berani bertanggung jawab supaya dia percaya diri.

Para kaum muda, bertekadlah mulai sekarang kalau saya lulus sekolah saya ingin membuat pekerjaan sendiri, tidak perlu melamar kemanapun. Hikmahnya, yang pertama adalah hati-hati dengan masa kecil. Para mahasiswa sebaiknya sambil kuliah sambil cari nafkah. Pengalaman harus sudah dirintis. Kedua, nabi Muhammad sebelum diangkat sebagai nabi tidak punya apa-apa setelah itu dapat menjadi orang kaya tanpa modal. Karena modal yang beliau punyai adalah Al Amin yaitu orang yang kredibel (dipercaya). Mulai sekarang kita harus buat catatan langkah untuk menjadi orang terpercaya dalam kehidupan kita.

Tiap kita itu sudah ditentukan rizkinya. Rizki dapat dibagi menjadi tiga macam, pertama adalah rizki yang sudah dijamin pasti ada yaitu makan. Yang harus kita takuti adalah makan makanan yang kita tidak tahu halal dan haramnya.

Rizki yang kedua adalah rezeki yang digantungkan. Sesungguhnya Allah tidak akan merubah nasib suatu kaum, sampai kaum itu merubah nasibnya sendiri. Bekerja keras itu urusan fisik, bekerja cerdas itu urusan otak dan bekerja ikhlas itu urusan hati. Kalau ketiganya berjalan baru ketemu.

Rezeki yang ketiga adalah rezeki yang dijanjikan. Kita harus jatahkan setiap mendapatkannya harus langsung dikeluarkan sedekah atau zakatnya. Tidak akan berkurang harta dengan sedekah, kecuali bertambah dan bertambah.

Orang mau apa saja “jujurlah” kuncinya. Begitulah sifat nabi Muhammad SAW Jadi jangan takut tidak punya uang tapi takutlah tidak barokah. Rasulullah ternyata orang yang cakap dalam pekerjaannya dan orientasinya memberikan kepuasan. Karunia Allah itu tidak identik dengan uang tapi identik dengan kemuliaan setiap saat. Yang pasti tidak pernah rugi orang yang selalu dalam kejujuran dan kebaikan.

Dalam Islam kita itu untung kalau berhasil menguntungkan sebanyak mungkin orang. Jangan mengukur keuntungan lewat uang. Jangan ukur kesuksessan dengan uang. Kesukessan adalah ketika kita punya ilmu, pengalaman, nama baik dan menjadi barokah. Uang itu bonus dari Allah dan kecil artinya.

Jiwa enterpreneurship itu tergantung dari kredibilitas dan faktor kreativitas yang berani melakukan hal-hal baru. Orang-orang yang kreatif itu adalah orang yang selalu belajar setiap saat. Jadi setiap kita punya uang jangan sampai menempel di hati. Setiap kita punya uang harus diinvestasikan untuk mencari ilmu, penambah wawasan, dan modal untuk beramal.

Saudara-saudara sekalian, Rasulullah itu zuhud padahal di dalam genggamannya, hasilnya jadi mulia. Dengan tiga rumus ini yaitu satu jujur dan terpercaya, dua cakap, dan tiga memuaskan, maka pilihannya kita harus maju terus pantang mundur sampai ajal menjemput kita. Insya Allah.

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.

KPU hari ini berencana akan mengajak Dewan TIK Nasional (DeTIKNas) untuk melakukan Audit Internal atas TI KPU. Saya kenal dengan beberapa orang kunci di Tim EvaTIK DeTIKNas ini. Semoga berjalan dengan baik auditnya, setidaknya mereka-mereka ini punya pengalaman dan international credential untuk kerjaan audit. Jadi tidak asal bunyi seperti banyak komentar di koran-koran sekarang ini.

Semoga juga KPU masih sehat nalarnya, jadi memberikan space yang rasional untuk pelaksanaan audit. Karena kalau space yg tepat tak dikasih, ya sama saja audit tidak ada gunanya. Mau tahu caranya ngakalin auditor sehingga “seolah-olah” jadi stempel? Rahasianya di “Space Management” tadi….

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….