Memilih vendor TI BPR perlu mempertimbangkan kemampuan membangun sistem sekaligus mendukung pengawasan bank. Harga, tampilan demo, dan kecepatan pengerjaan merupakan bahan penilaian, tetapi belum menjawab keamanan data, kelangsungan layanan, serta akses terhadap bukti ketika terjadi masalah.
Sebagai ilustrasi, dua vendor menawarkan aplikasi pengajuan kredit dengan fitur serupa. Vendor pertama memasukkan dokumentasi integrasi, uji hak akses, dan serah terima operasional. Vendor kedua hanya menyebut aplikasi selesai serta garansi perbaikan. Kedua penawaran itu belum sebanding meskipun jumlah menunya sama.
POJK 34 Tahun 2025 memberikan dasar untuk memeriksa hubungan kerja dengan penyedia jasa TI. Artikel ini menerjemahkan sebagian kebutuhan tersebut menjadi pertanyaan pengadaan dan bahan kontrak. Pembahasan lebih luas tersedia pada panduan kewajiban TI BPR.
Pahami Tanggung Jawab Bank Saat Menggunakan Vendor
Pasal 27 pada naskah POJK 34 Tahun 2025 memperbolehkan penggunaan pihak penyedia jasa TI. Namun, bank tetap bertanggung jawab terhadap penyelenggaraan TI dan wajib melakukan pengawasan. Keputusan memakai vendor tidak memindahkan seluruh tanggung jawab kepada pengembang.
Peraturan tersebut juga mengatur kemampuan sumber daya manusia, pengendalian TI, penyediaan informasi, kerahasiaan, kelangsungan layanan, serta persyaratan perjanjian. Penyedia jasa TI harus berbentuk badan hukum yang berkedudukan di Indonesia sebagaimana Pasal 27 ayat (5).
Karena itu, pemeriksaan vendor perlu melibatkan fungsi TI dan pemilik proses. Bagian pengadaan dapat membantu membandingkan dokumen komersial, sedangkan kepatuhan dan manajemen risiko menilai kebutuhan pengendalian sesuai perannya. Jangan meminta satu pihak menilai seluruh aspek hanya dari presentasi penjualan.
Mulai Dari Masalah Yang Akan Diselesaikan
Sebelum mengundang vendor, tuliskan masalah dalam bentuk yang bisa diperiksa. Contohnya, perubahan data pengajuan tidak memiliki riwayat, persetujuan masih terpisah dari dokumen, atau status pengiriman ke core banking sulit dipastikan. Hindari brief yang hanya berbunyi “buat aplikasi sesuai POJK”.
Sertakan alur kerja, peran pengguna, jumlah sistem terkait, dan batas pengembangan. Jelaskan apakah pekerjaan mencakup integrasi, migrasi, infrastruktur, atau pemeliharaan. Bila informasi belum lengkap, minta tahap discovery yang menghasilkan spesifikasi, bukan harga tetap dengan asumsi tersembunyi.
Gunakan checklist kesiapan TI BPR untuk menyiapkan bahan awal. Dengan brief yang sama, bank dapat membandingkan jawaban vendor terhadap kebutuhan yang sama pula. Jika brief belum memiliki dasar pemeriksaan yang cukup, mulai dengan assessment TI BPR yang memiliki lingkup dan keluaran jelas.
Pertanyaan Apa Yang Harus Dijawab Vendor TI BPR?
Pertanyaan berikut membantu mengubah klaim menjadi bukti. Daftar ini merupakan rekomendasi evaluasi; bukan formulir resmi atau daftar sertifikasi wajib dari OJK.
| Topik | Pertanyaan Kepada Vendor | Bukti Yang Diminta |
|---|---|---|
| Pemahaman proses | Bagaimana aplikasi memisahkan pembuatan dan persetujuan? | Alur kerja dan skenario uji |
| Integrasi | Bagaimana menangani data gagal terkirim atau terkirim ulang? | Desain integrasi dan demonstrasi kegagalan |
| Hak akses | Bagaimana kewenangan per jabatan dan cabang diterapkan? | Matriks peran serta hasil uji |
| Jejak audit | Bagaimana aktivitas ditelusuri dan dilindungi? | Contoh catatan sintetis dan kontrol akses |
| Operasional | Siapa menangani gangguan di luar jam kerja? | Lingkup dukungan dan jalur eskalasi |
| Pengakhiran | Bagaimana data serta dokumen diserahkan saat kontrak berakhir? | Rencana transisi dan format ekspor |
Jawaban yang baik menyebut kondisi, batas layanan, dan pihak yang bertanggung jawab. Pernyataan “semua aman” tanpa penjelasan lebih sulit dinilai daripada jawaban yang terbuka tentang keterbatasan.
Uji Demo Dengan Skenario Yang Disiapkan Bank
Jangan hanya mengikuti alur demo yang dipilih vendor. Siapkan kasus sederhana menggunakan data sintetis: pengguna membuat pengajuan, pihak lain menyetujui, lalu sistem mengirim data ke aplikasi tujuan. Setelah itu, minta vendor menunjukkan riwayat aktivitasnya.
Tambahkan satu skenario penolakan akses dan satu kegagalan integrasi. Periksa apakah aplikasi menjelaskan status dengan benar. Jika koneksi terputus setelah permintaan diterima sistem tujuan, bagaimana vendor mencegah pengiriman ulang menghasilkan data ganda? Skenario ini dibahas lebih rinci pada integrasi LOS dengan core banking BPR.
Demo tidak menggantikan pengujian penerimaan. Namun, demo berbasis kasus bank membantu menemukan asumsi lebih awal. Untuk merinci kasus tersebut, gunakan panduan pengembangan aplikasi BPR sebagai bahan penyusunan kebutuhan.
Periksa Cara Vendor Mengakses Data Dan Lingkungan Bank
Tanyakan data apa yang diperlukan selama pengembangan serta bagaimana data uji disiapkan. Pengembang tidak selalu membutuhkan salinan lengkap database nasabah. Banyak pemeriksaan awal dapat dilakukan dengan struktur data, contoh yang disamarkan, atau data sintetis.
Selanjutnya, bahas akses ke lingkungan pengembangan, pengujian, dan produksi. Siapa yang menyetujui akses? Berapa lama akses berlaku? Bagaimana aktivitas dukungan dicatat? Akses administrator permanen tanpa pemilik yang jelas perlu dievaluasi sebelum kontrak berjalan.
Periksa juga keterlibatan penyedia cloud dan subkontraktor. Pasal 27 memuat persyaratan persetujuan tertulis bank ketika vendor mengalihkan sebagian kegiatan atau melakukan subkontrak. Susunan pihak yang terlibat perlu terlihat sejak awal, termasuk lokasi layanan dan tanggung jawabnya.
Kontrak Harus Menjelaskan Hasil Dan Batas Pekerjaan
Perjanjian kerja sama perlu memuat cakupan, hak dan kewajiban, serta ketentuan terkait penyedia jasa TI sebagaimana Pasal 27. Terjemahkan itu ke keluaran yang dapat diperiksa: spesifikasi disepakati, aplikasi, dokumentasi, hasil uji, panduan operasional, dan serah terima.
Pisahkan pekerjaan yang termasuk harga dari pekerjaan tambahan. Sebagai contoh, perubahan API vendor core banking dapat berada di luar kendali pengembang baru. Kontrak sebaiknya menjelaskan siapa yang mengurus akses, biaya pihak ketiga, dan penyesuaian jika dokumentasi integrasi tidak sesuai kenyataan.
Hak penggunaan aplikasi, kepemilikan kode, lisensi komponen, dan akses repositori juga perlu disepakati. Jangan menganggap semua otomatis menjadi milik bank atau semua pasti ditahan vendor. Ketentuan komersial tersebut harus tertulis sesuai kebutuhan keberlanjutan layanan.
Bedakan Waktu Respons Dan Waktu Pemulihan
Dalam perjanjian tingkat layanan, respons berarti vendor mulai menangani laporan. Pemulihan berarti layanan kembali dapat digunakan sesuai kriteria yang ditetapkan. Keduanya perlu dibedakan agar bank tidak mengira balasan tiket sama dengan masalah selesai.
Definisikan tingkat gangguan berdasarkan dampaknya terhadap proses bank. Tentukan jam dukungan, kanal laporan, pihak penerima eskalasi, dan pembaruan informasi selama insiden. Bila layanan bergantung pada vendor lain, jelaskan koordinasinya. Periksa pembagian peran tersebut dalam rencana backup dan disaster recovery BPR.
Pasal 27 mencantumkan pemenuhan tingkat layanan dan pemberitahuan kejadian kritis. Bank juga memiliki kewajiban pelaporan sendiri. Karena itu, waktu pemberitahuan vendor kepada bank perlu memberi ruang bagi bank untuk menilai kejadian dan menjalankan kewajibannya, bukan baru dimulai setelah investigasi vendor selesai.
Siapkan Mekanisme Pengakhiran Sejak Awal
Hubungan kerja yang baik tetap membutuhkan exit clause. Periksa format ekspor, kelengkapan dokumen, dukungan transisi, pengembalian akses, dan penanganan salinan data setelah layanan berakhir. Pastikan keputusan itu mempertimbangkan kebutuhan penyimpanan serta kewajiban hukum terkait.
Pasal 28 mengatur tindakan ketika kondisi tertentu mengganggu atau menghentikan penyediaan jasa TI. Penghentian vendor perlu menjaga kelangsungan layanan dan data bank. Karena itu, rencana transisi lebih bermanfaat jika dipersiapkan ketika layanan masih berjalan normal.
Untuk vendor yang telah digunakan sebelum pemberlakuan aturan, baca ketentuan peralihan Pasal 51. Perpanjangan kontrak merupakan kesempatan meninjau kesenjangan. Jangan menerjemahkan masa peralihan menjadi pembebasan umum dari pengawasan vendor.
Bandingkan Biaya Selama Masa Penggunaan
Minta pemisahan biaya discovery, pembangunan, lisensi, hosting, pemeliharaan, dukungan, perubahan, dan transisi. Penawaran awal yang rendah dapat memakai asumsi jumlah pengguna atau penyimpanan yang berbeda. Bandingkan berdasarkan kebutuhan dan periode yang sama.
Tanyakan pula biaya pengujian keamanan, uji pemulihan, serta bantuan penyediaan bukti. Jelaskan bagian yang dikerjakan vendor utama dan bagian yang membutuhkan spesialis lain. Klaim mampu menangani semuanya harus didukung kapasitas dan lingkup yang jelas.
Hasil evaluasi sebaiknya mencatat kekuatan, kekurangan, ketergantungan, serta risiko yang diterima bank. Bobot harga dan teknis dapat ditetapkan oleh bank; tidak ada angka pembobotan universal yang otomatis cocok untuk semua pengadaan.
Membuka Pembahasan Dengan Layana.id
Layana.id memiliki layanan custom development untuk pembahasan kebutuhan pengembangan sistem. Bagi BPR, diskusi dapat dimulai dari aplikasi internal, alur persetujuan, integrasi, dan kebutuhan pencatatan aktivitas. Lingkup serta kelayakannya perlu diperiksa terhadap sistem bank yang berjalan.
Siapkan tiga bahan: masalah prioritas, gambaran aplikasi yang terlibat, dan hasil yang ingin dibuktikan saat serah terima. Jika kebutuhan utamanya keterlacakan, sertakan pertanyaan dari panduan audit trail sistem BPR.
Bahas kebutuhan partner TI BPR bersama Layana.id dengan meminta ruang lingkup dan kriteria penerimaan yang tertulis. Vendor yang tepat perlu dapat menjelaskan apa yang dikerjakan, bagaimana hasilnya diuji, serta bagian yang tetap menjadi keputusan bank. Itulah dasar kerja sama yang dapat diawasi setelah aplikasi mulai digunakan.
Aplikasi Finance Karya Layana
Aplikasi nasabah, alur pengajuan kredit, dan web admin untuk KB Bukopin Finance, BPR CMA, serta BPR MSA.
KB Bukopin Finance
Dari Simulasi Ke Pengajuan Pembiayaan
Aplikasi Android dan web admin untuk informasi produk, simulasi pembiayaan, serta pengumpulan pengajuan calon nasabah. Lingkup proyek mencakup perancangan integrasi e-KYC Privy.ID, skor kredit pihak ketiga CLIK, dan pengembangan skoring berbasis data internal.
BPR CMA
Alur Kredit Dalam Genggaman Tim
Aplikasi mobile dan web admin untuk pengajuan serta survei kredit. Cakupannya membantu marketing dan komite kredit mengelola pengecekan data, exposure, serta analisis jaminan. Pengajuan dan status pekerjaan menjadi bagian dari alur yang dapat ditelusuri tim.
MSA On Hand
Layanan Nasabah Dan Komunitas UMKM
Aplikasi BPR Madani Sejahtera Abadi untuk pengajuan kredit, pembukaan rekening dan deposito, pembayaran, serta forum komunitas. Lingkup proyek Layana juga mencakup web admin, pengelolaan pengajuan oleh marketing dan notaris, serta laporan operasional.
MSA on Hand tersedia di Google Play dengan PT. Layana Computindo Sentratama tercantum sebagai developer.
Gunakan sesi evaluasi untuk meminta penjelasan alur, pembagian tanggung jawab, batas integrasi, dan keluaran serah terima. Tampilan aplikasi membantu menilai pekerjaan desain; bukti pengujian, dukungan, dan kontrol tetap perlu diminta sesuai lingkup pengadaan.
Bicarakan Aplikasi BPR Anda
Ceritakan proses yang masih manual, sistem yang digunakan, dan fitur yang ingin dibuat. Tim Layana dapat membantu membahas kebutuhan, batas integrasi, dan tahapan pengembangan.
Referensi
- POJK Nomor 34 Tahun 2025, khususnya Pasal 27–28 dan 51.
- Regulasi Dan FAQ Resmi OJK.