Inpres 75 40

January 5, 2012 | | 3 Comments

Inpres ini resminya bernama Inpres nomor 17 tahun 2012 tentang Aksi Pencegahan dan Pemberantasan Korupsi Tahun 2012. Salah satu poin yang terkait dengan e-procurement adalah target penerapan e-procurement sebesar 75% anggaran di Kementerian/Lembaga/Institusi lain serta 40% di Daerah. Dari situlah kami menyebutnya Inpres 75-40.

Masuknya target e-procurement pada inpres merupakan salah satu bukti bahwa kita semua, penyelenggara LPSE seindonesia, dapat meyakinkan para pimpinan bahwa Indonesia dapat menyelenggarakan e-procurement.  Nilai paket 53 trilyun yang dilelang selama 2011 merupakan bukti keberhasilan tersebut. Ini semua merupakan hasil kerja keras tim LKPP serta semua pengelola LPSE seluruh indonesia.

Nah, sekarang yang menjadi pertanyaan adalah bagaimana mengukur 75% dan 40% tersebut? Angka 75% artinya 75 dari 100. Lha seratus persennya dari mana? Berbagai pendapat muncul tentang ‘penyebut’ dari 75/100. Pendapat tersebut antara lain:

  1. Dari paket yang diumumkan pada Rencana Umum Pengadaan (RUP)
  2. Dari belanja barang dan jasa (baik yang dilelang, swakelola, dan penunjukan langsung)
  3. Dari data RKA KL

Yang menjadi masalah adalah bagaimana mendapatkan ketiga jenis data tersebut. Sistem RUP belum tersedia. Data dari RKA KL mungkin cukup valid namun cukup sulit untuk mendapatkan data tersebut dari setiap instansi. Untuk pemda, jauh lebih sulit lagi karena jumlahnya banyak dan distribusi yang sangat tersebar.

Data yang paling mudah didapat adalah data dari Inaproc. Di sana telah ada lelang yang e-proc dan non eproc. Artinya, total lelang (eproc dan non eproc) menjadi penyebutnya.  Data ini cukup akurat dengan asumsi semua instansi mengumumkan lelang di Inaproc. Namun demikian, metode ini tidak dapat memonitor prosentase lelang tiap bulan karena tidak ada acuan ‘100′ tadi.

Rakor ke-7 LPSE Nasional  yang diselenggarakan minggu lalu di Sanur - Bali, dihadiri 700 orang lebih (termasuk panitia). Sekitar 2 milyar biaya dikeluarkan untuk penyelenggaraannya.

Ada satu daerah yang berminat ketempatan rakor LPSE Nasional tahun depan. Mungkin jumlah peserta yang hadir dapat mencapai 1000 orang atau lebih.  Biasanya, LKPP menyelenggarakan 2 kali rakor setahun. Rakor pertama di Jakarta dan rakor kedua di luar jakarta (Batam, Balikpapan, Bali).  Persiapan rakor ternyata cukup panjang. Ketika kita baru selesai menyelenggarakan rakor ke-7, kita sudah dihadapkan untuk persiapan rakor ke-8.

Ada wacana untuk menyelenggarakan rakor cukup 1 kali mengingat jumlah peserta yang semakin besar. Kemungkinan akan diselenggarakan di luar Jakarta dengan pertimbangan ekonomi daerah. Hem…. Menarik juga.

Rakor ke-7 minggu lalu mungkin telah mendatangkan 2-3 milyar rupiah ke Bali untuk hotel serta transportasi serta belanja 700 orang selama di Bali. Uang sebesar ini mungkin tidak ada artinya untuk ukuran Bali, namun jika untuk daerah lain bisa jadi cukup signifikan. Jika ada banyak kegiatan pemerintah pusat yang dialihkan ke daerah-daerah tentau uang yang mengalir ke daerah menjadi cukup besar.

Konsolidasi Data

November 18, 2011 | | Leave a Comment

Penetrasi LPSE ternyata jauh lebih cepat dari yang saya bayangkan. Tahun 2011 relatif tidak banyak fitur yang kami kembangkan karena resource tersedot untuk bug fixing, update patch,  serta pengembangan sistem lain (Inaproc, ADP, dan e-catalog). Salah satu yang belum bisa kami selesaikan adalah konsolidasi data.

Isian kode anggaran (MAK) telah ada pada sistem namun ternyata isinya tidak akurat. Ada yang mengisi namun tidak lengkap karena hanya beberapa digit awal atau beberapa digit terakhir yang dimasukkan.

Implementasi LPSE menggunakan pendekatan geografis. Oleh karena itu, hierarchy instansi tidak lagi relevan.  Politeknik Kesehatan Surakarta yang berada di bawah Kementerian Kesehatan (DIPA-nya berasal dari Kemenkes) tidak melakukan lelang di LPSE Kemenkes namun di LPSE Provinsi Jawa Tengah.

Politeknik Kesehatan Surakarta

Lelang oleh Poltek Kesehatan Surakarta di LPSE Provinsi Jawa Tengah

Kebutuhan yang ada sekarang adalah Kementerian Kesehatan ingin memantau lelang semua satuan kerja di bawahnya terlepas dari satuan kerja tersebut mengadakan lelang di LPSE Kemenkes atau bukan. Saat ini kami di LKPP sedang melakukan konsolidasi data sehingga dapat diperoleh hirarki satuan kerja dan instansinya tanpa melihat LPSE.

Ada juga kasus, bahasa kerennya spin-off atau pemisahan diri. Tahun 2010, LKPP menyelenggarakan lelang e-procurement di LPSE Kementerian Keuangan. Pada tahun 2011, LKPP menyelenggarakan sendiri LPSE sehingga memiliki sistem sendiri.  Beberapa instansi juga berpotensi seperti ini. Salah satunya adalah Kabupaten Bantul.

Kami di LKPP sedang membuat sistem konsilidasi data yang melakukan pemetaan, satuan kerja (hingga November 2011 tercatat 11 ribu satker) A berada di instansi mana. Ini merupakan pekerjaan yang cukup besar. Sepertinya kami juga harus melakukan klarifikasi ke LPSE yang bersangkutan jika kami tidak bisa memutuskan satuan kerja tertentu berada di instansi mana.

Tantangan berikutnya adalah perubahan struktur organisasi yang sering terjadi. Ini juga memerlukan effort tersendiri untuk konsilidasi.

Hari ini kursus Business Continuity Plan. Pada prinsipnya mempersiapkan rencana jika ada bencana terhadap sistem. Pembuatan BCP harus melibatkan semua level di organisasi, mulai dari direktur utama hingga bagian help desk; mulai dari bagian keuangan hingga perencanaan produksi.

Gambarannya seperti apa BCP itu?

Berikut ini ilustrasinya. Bank ABC memiliki data center di kantor pusat di Sudirman - Jakarta. Andaikan kantor pusatnya terjadi kebakaran, bank tersebut harus tetap beroperasi. Jika ada gangguan terhadap core business system maka akan terdapat potensi kehilangan transaksi, katakanlah 100 milyar per jam, dan potensi kerugian 5 milyar per jam.

Nah, untuk mencegah kehilangan pendapatan/keuntungan tersebut, sistem bank harus memiliki BCP. Data-data yang disimpan di data center (kantor pusat) disimpan secara real time ke DRC (Disaster Recovery Center). Penentuan lokasi DRC juga sangat penting. Jika DRC bank tersebut berada di Jakarta maka potensi kehilangan data masih cukup besar, jika ada bencana di Jakarta. Untuk itu, DRC dapat diletakkan di katakanlah Batam atau Singapura.

Nah, mengapa pengembangan DRC ini perlu keterlibatan orang keuangan? Ini terkait dengan biaya. Semakin baik kualitas BCP logikanya memerlukan biaya lebih banyak.

Hmmm. Untuk LPSE seperti apa ya?

Lagi-lagi ini menjadi tantangan implementasi LPSE. Di swasta, BCP dapat relatif mudah dikembangkan. Jika direktur sudah memahami maka semuanya menjadi bisa berjalan (terlepas nanti kendala di lapangan). Bagian keuangan juga bisa memutuskan besarnya biaya dan benefit yang akan diperoleh.

Untuk LPSE, memahamkan tim LPSE saja tidak cukup. Kalaupun mereke sudah paham namun biro keuangan tidak paham maka mereka tidak akan menyediakan anggaran yang mencukupi. Kalau tidak ada anggaran, tentu saja BCP akan sangat terbatas.

Contoh. Untuk meningkatkan reliabilitas, server LPSE perlu memiliki backup di colocation di Jakarta. naUntuk ini, LPSE perlu anggaran sewa rak, beli server, serta sewa internet di colocation. Bagian keuangan mungkin menolak anggaran ini karena alasan sederhana: sudah punya ruang server, server, dan internet kok mau sewa lagi; ini pemborosan anggaran.

Nah…. bagaimana solusinya?

Bagaimanapun keterbatasan yang ada, BCP harus dibuat meskipun sangat sederhana. Misalnya, tiap hari data dibackup ke external disk dan dibawa pulang ke rumah. Jika ada masalah dengan server, LPSE akan kehilangan data hanya satu hari.

Tadi siang saya bertemu seorang rekan pengelola LPSE. Dia bercerita bahwa LPSE telah sangat mempercepat proses lelang. Ada puluhan paket pengadaan yang sedang dilelang oleh panitia. Spesifikasinya sebagian besar sama. Find menjadi salah satu fasilitas word processing yang sangat membantu mereka.

Satu hal yang sangat mempercepat adalah tidak diperlukannya pencetakan/printing dokumen. Pada lelang konvensional, pencetakan dan penjilidan memerlukan effort yang tidak sedikit. Jenis lelang tertentu terutama konstruksi memerlukan dokumen dengan jumlah banyak hingga ratusan halaman. Adanya e-procurement telah mengurangi waktu dan biaya pencetakan dokumen.

Interkoneksi LPSE dan SPAN

September 20, 2011 | | 5 Comments

SPAN (Sistem Perbendaharaan dan Anggaran Negara) merupakan sistem yang tengah dikembangkan oleh Kementerian Keuangan. Akhir tahun 2011 ini SPAN akan diujicobakan di beberapa KPPN Jakarta.  SPAN dan e-procurement memiliki kaitan yang erat. Lebih dari 30% nilai APBN digunakan untuk pengadaan barang dan jasa.

Pertemuan awal LKPP, tim pengembangan SPAN, serta LPSE Kementerian Keuangan memberikan gambaran bahwa ada beberapa titik interkoneksi antara kedua sistem. Interkoneksi tersebut berada pada kode anggaran serta nomor kontrak pengadaan. Semoga di awal tahun depan LKPP dapat mulai mengembangan interkoneksinya.

Saya beserta tim pengembangan e-procurement seolah-olah sedang membangun sebuah gedung kantor. Ada yang menjadi arsitek, pemasang instalasi listrik, pembuat saluran air, memasang furniture, mengecat tembok, dan ada juga bagian pemasaran yang menawarkan ruang untuk disewakan. Bagi arsitek, gedung tersebut tampak di layar komputernya sebagai miniatur bangunan tiga dimensi lengkap dengan perabotannya. Bagi pemasang instalasi listrik, dia telah memasang kabel sepanjang 10 ribu meter dan 15 ribu sambungan listrik pada bangunan tersebut. Bagi pembuat saluran air, dia telah memasang 5 ribu batang pipa berbagi ukuran dan memasang sekian ribu sambungan pipa pada puluhan lantai. Bagi pengecat tembok, dia telah menghabiskan ribu liter cat untuk mengecat ribuan meter persegi dinding di puluhan lantai.

Setelah bangunan selesai, artinya para pekerja telah menyelesaikan pekerjaannya dan tidak pernah berkantor di sana. Tibalah saatnya berbagai perusahaan dan ribuan orang berkantor di sana. Berbagai komentar muncul untuk gedung  tersebut. Ada yang berkata sangat arstisitik, lift-nya bagus, kran airnya bagus, interior mewah, atau toilet yang terlalu sempit. Para pekerja bangunan tadi tidak tahu komentar-komentar membanggakan maupun yang mengkritik atas gedung yang telah mereka kerjakan.

Beberapa hari lalu Pak Invanos berkomentar bawah kita (tim e-procurement) telah membuat terobosan besar untuk sistem pengadaan Indonesia. Bahwa orang tidak lagi membuka koran untuk mencari pengumuman lelang. Bahwa orang tidak lagi diintimidasi untuk memasukkan penawaran lelang. Bahwa melalui e-procurement telah terjadi transaksi 51 trilyun. Kami, sebagai tim pengembangan sendiri belum melihat dari sudut  pandang lain selain e-procurement sebagai kumpulan program bahasa Java dan data-data di Database Postgres. Seperti tukang bangunan tadi melihat gedung dari sudut pandang keahliannya.

Saya coba melihat dengan sudut pandang lain. Kasus heboh lelang 6 trilyun bagi kami hanya sebatas teks dan statement if then else. Namun ternyata implikasinya sangat luar biasa. Begitu pula dengan nilai transaksi 31 trilyun dari Januari-Agustus  2011 yang senilai hampir 10% dari pengadaan pemerintah. Belum lagi dengan ribuan orang yang menjadi melek IT maupun puluh orang yang ‘terpaksa’ menjadi ahli Linux. Ini semua merupakan impact dari sistem yang kami terlibat dalam pengembangannya.

Melihat dari sudut pandang yang lain tersebut juga memberikan manfaat tersendiri bagi kami. Keputusan-keputusan tertentu harus dipertimbangkan dengan matang agar tidak memberikan dampak negatif. Pilihan kata harus tepat agar tidak menimbulkan isu bahkan gugatan hukum. Hmmmm….  Kami juga mencoba untuk membuat pilihan-pilihan kata yang tepat pada setiap teks yang kami ketik.

Saya baru tahu jika server LPSE Kabupaten Kudus berada di Jakarta, tepatnya di IDC yaitu sebuah layanan Data Center.  Saya tidak tahu mengapa sampai diputuskan demikian. Padahal, arsitektur semacam itu tidak direkomendasikan.

Penyedia yang datang ke bidding room di LPSE Kab Kudus ternyata tidak mendapatkan bandwidth yang lebih cepat dibandingkan dari rumah. Hemm…. kabarnya, LPSE akan meningkatkan bandwidth internetnya. Namun solusi itu tidak tepat. Suatu saat ketika jumlah lelang sudah mencapai ratusan, berapapun bandwidth yang disediakan akan tetap kurang ketika puluhan/ratusan orang upload penawaran bersamaan dari bidding room LPSE.

Arsitektur yang direkomendasikan adalah server LPSE berada di instansi masing-masing. Akses dari bidding room ke server dilakukan via LAN. Semoga saja server LPSE Kab Kudus segera diboyong dari Jakarta.

Kuartal ke-4 tahun ini, kantor fokus pada review sistem-sistem yang telah ada. SPSE versi 3 telah beberapa kali direview untuk pengembangan versi 4. Sistem lain: Smart Report dan Inaproc juga direview untuk meningkatkan kualitas.

Untuk review Inaproc, LKPP mengundang beberapa LPSE antara lain Kementerian Kesehatan, Universitas Negeri Makasar (UNM), Kementerian Perumahan Rakyat, serta beberapa pejabat LKPP lainnya. Pak Bima, Deputi II LKPP juga hadir membuka acara Review Inaproc yang diselenggarakan 15-16 September 2011 di Jakarta.

UNM kami ajak untuk melihat perspektifnya sebuah LPSE yang banyak mendapat ‘tumpangan’ pengumuman maupun proses lelang e-proc. Masukan penting dari LPSE UNM antara lain
1. Keterbatasan akses internet di berbagi Kabupaten di Sulawesi. Akhirnya LPSE UNM terpaksa harus menerima data berupa file yang harus diketikkan staf LPSE. Padahal pada desain kami, Panitia/ULP sendiri yang harus mengisikan data tersebut di web LPSE.
2. Harapan akses melalui ponsel atau perangkat mobile sejenisnya.

Pak Bima memberi masukan dari sudut pandang pengguna awam. Beliau sebagai pengguna awam agak sulit ketika akan mencari lelang di Inaproc. Pengurutan provinsi berdasarkan abjad juga berbeda dengan kelaziman yang  berlaku. Umumnya, orang mengurutkan provinsi seperti standar BPS.

Arsitektur LPSE yang tidak terlalu ketat terhadap hiarki organisasi memberikan kemudahan akses bagi instansi-instansi di daerah. Satu kabupaten di Sulawesi misalnya, tidak difasilitasi oleh Provinsinya untuk mengumumkan lelang di LPSE. Oleh karena itu, kabupaten tersebut mengumumkan lelangnya di LPSE LKPP. Secara regulasi ini telah memenuhi syarat. Namun ternyata, cara Inaproc menampilkannya menyebabkan data tersebut masuk kelompok Provinsi DKI Jakarta. Ini merupakan PR kami di pengembangan untuk membuat tampilan yang lebih mudah.

Pak Bima juga menyarankan agar adanya fasilitas pencarian pintar. Penyedia yang ingin searching “seragam dinas” misalnya perlu diberi saran kata kunci lain yang serupa; misal “pakaian seragam”, “pakaian dinas”, “baju dinas”. Ide yang pintar, namun kayaknya agak sulit secara teknis. Oke Pak, ntar kami cari teknologinya.

Tanggal 24 Agustus kami mendapat berita di Koran Jawa Pos bahwa LPSE Provinsi Jawa Timur dibobol hacker. Akibatnya, web LPSE Provinsi Jawa Timur berubah menjadi gambar kucing animasi (lihat beritanya).

Gambar yang dimaksud adalah logo Apache Tomcat di bawah ini:

tomcat Sebenarnya tidak ada hacker yang membobol situs LPSE. Gambar kucing tersebut merupakan tampilan default aplikasi Tomcat. Aplikasi Tomcat merupakan aplikasi yang menjalankan SPSE. Ketika itu, server LPSE mengalami gangguan sehingga tampilan default tersebut muncul.

Alhamdulillah kami telah dapat menyelesaikan masalah tersebut. Kini LPSE Provinsi Jawa Timur telah berjalan dengan baik setelah kami tune up servernya menyesuaikan dengan peningkatan jumlah pengguna.

Kami pernah mengalami hal serupa di LPSE Provinsi Jawa Barat pada tahun 2009 dan 2010. Ketika itu, gubernur mewajibkan seluruh lelang dilakukan secara elektronik. Belum lagi LPSE yang secara gencar mengajak instansi lain melakukan lelang di LPSE Provinsi Jawa Barat menyebabkan jumlah paket yang dilelang mencapai ratusan.  Kondisi server yang belum di tune up menyebabkan server sering overload ketika pengguna yang mengakses sangat banyak. Batas akhir pemasukan penawaran yang sama pada banyak paket juga mempengarui jumlah pengakses (concurrent user).