Arsitektur Teknis E-Purchasing

18 Oct 2010

Tulisan ini merupakan lanjutan catatan pengembangan e-catalog. Desain umum e-purchasing/e-catalog yang dibuat oleh tim ITB telah memasuki akhir. Aspek-aspek yang mesti digarap masih cukup banyak, antara lain:

1. Arsitektur teknis
2. Desain sistem secara rinci
3. Regulasi
4. Tata kelola
5. Strategi implementasi

Tulisan kali ini fokus pada arsitektur teknis e-catalog. Pasal 110 Perpres 54 tahun 2010 menyebutkan bahwa LKPP menyelenggarakan katalog elektronik (e-catalog). Secara sederhana dapat ditafsirkan bahwa LKPP memiliki satu server di Jakarta yang berisi katalog barang/jasa seperti yang dimiliki SEPP Depkominfo. Pada tahap awal e-catalog akan terfokus pada kendaraan bermotor. Dari sisi volume, data kendaraan bermotor tidak akan terlalu banyak; mungkin tidak sampai 500 jenis kendaraan. Pada setiap kendaraan akan ada data spesifikasi teknis kendaraan serta brosur yang biasa digunakan untuk media pemasaran. Data ini tidak terlalu besar; mungkin tidak sampai 20-50 MB untuk satu jenis kendaraan (asalkan dengan format data yang wajar). Artinya, jika seluruh jenis kendaraan masuk ke dalam sistem akan ada sekitar 50 GB data; jumlah yang relatif kecil dibandingkan data e-tendering.

Seperti pada kasus e-tendering, e-catalog akan menghadapi permasalahan yang sama terkait dengan infrastruktur teknologi informasi. Layanan e-tendering pada aplikasi SPSE tidak diimplementasikan secara terpusat; silakan membaca posting saya terdahulu untuk pembahasan lengkap. Data-data pada e-catalog relatif statis (jarang berubah), sementara itu pengguna e-catalog tersebar di seluruh Indonesia dengan beragam kondisi jaringan internet; bahkan tanpa internet sama sekali kecuali melalui VSAT (satelit). Untuk mempercepat akses, sistem e-catalog akan menggunakan infrastrukur SPSE yang telah ada. Dengan demikian, pengguna sistem akan mendapatkan akses yang cepat karena tidak mengakses server dari Jakarta. Pengguna e-catalog sama dengan pengguna e-tender. Meskipun pada pepres dinyatakan bahwa LKPP menyelenggarakan katalog elektronik namun tataran teknis data-data e-catalog didistribusikan di server-server SPSE sementara data di server LKPP berfungsi sebagai acuan.

Penyedia barang/jasa akan mengadakan kontrak payung dengan LKPP (pasal 110 ayat 3). Proses update ke katalog pun akan dilakukan oleh penyedia di server LKPP. Pada periode tertentu — tengah malam misalnya –, data dari LKPP akan didistribusikan ke seluruh SPSE. Dengan kata lain, aplikasi SPSE yang ada saat ini akan memiliki tambahan fungsi e-catalog.

Desain Teknis E-Catalog

Pada gambar di atas, box berwarna merah merupakan elemen e-catalog/e-purchasing. Box E-catalog berada di LKPP. Di sini, ATPM melakukan update data catalog kendaraan yang mereka produksi. Sementara itu, box e-purchasing berada di area LPSE. Dealer, ULP, dan Panitia berada melakukan transaksi di sini. Verifikasi Dealer dapat dilakukan di LPSE terdekat. Mekanisme ADP telah memungkinkan penyedia cukup mendaftar di satu LPSE saja. Setelah penyedia/dealer terdaftar di satu LPSE maka perlu ada langkah berikutnya dari ATPM (atau mungkin LKPP) untuk melakukan verifikasi tahap kedua. Verifikasi ini untuk memastikan bahwa dealer tersebut merupakan agen atau penjual dari produk kendaraan tertentu.

Mirroring E-Catalog

Dari semua pengguna e-purchasing/e-catalog, ULP/Panitia merupakan pengguna yang paling banyak berinteraksi dengan sistem. ULP/Panitia melakukan aktifitas antara lain:

  1. Mencari dan membandingkan kendaraan
  2. Membuat surat permintaan penawaran
  3. Melakukan evaluasi penawaran mengumumkan hasil e-purchasing

Untuk itu, ULP & panitia harus mendapat akses yang cukup cepat. Dengan menempatkan modul e-purchasing di LPSE akan meningkatkan kinerja sistem ditinjau dari sisi panitia pengadaan. Sementara itu data e-catalog dapat di-mirror dari pusat (LKPP) pada periode tertentu. Data e-catalog ini relatif statis dan satu arah sehingga dapat ditangani dengan mudah.

Yang perlu mendapat perhatian adalah data-data yang terkait dengan dealer di sebuah LPSE. Sistem ADP saat ini mengagregasikan sedikit informasi tentang penyedia (nama, alamat, NPWP, email) namun tidak menyimpan data transaksional. Jika sistem e-purchasing menggunakan pendekatan yang sama maka data transaksi e-purchasing di sebuah LPSE tidak perlu ditransfer ke LPSE lain. Informasi yang cukup penting misalnya tentang stok. Apakah stok kendaraan perlu ditampilkan di dalam sistem? Jika iya, maka perlu ada mekanisme sinkronisasi data. Data stok ini dapat disimpan di server e-catalog LKPP.


TAGS Arsitektur Pengembangan


-

Author

Follow Me