Tips Pokja untuk Pengadaan Aplikasi dan Perangkat TI

Pendahuluan

Pengadaan aplikasi dan perangkat TI berbeda dari pengadaan barang umum karena menyentuh aspek teknis yang kompleks: interoperabilitas sistem, keamanan data, lisensi perangkat lunak, model layanan cloud, dan dukungan purna-jual jangka panjang. Kelompok kerja pengadaan (Pokja) yang menangani paket TI perlu paham lebih dari sekadar aturan pengadaan: mereka harus mengerti konsep arsitektur TI, siklus hidup perangkat lunak, manajemen lisensi, serta risiko keamanan siber. Tanpa pemahaman ini, dokumen pengadaan mudah menimbulkan masalah-spesifikasi yang terlalu sempit mengunci vendor, tapi spesifikasi terlalu umum menyebabkan penawaran tidak relevan atau berkualitas rendah.

Artikel ini memberi panduan praktis bagi Pokja untuk menyiapkan, mengevaluasi, dan mengelola pengadaan aplikasi dan perangkat TI dengan efektif. Fokusnya pada langkah-langkah yang dapat cepat diaplikasikan: bagaimana menyusun persyaratan fungsional & non-fungsional, apa saja kompetensi yang harus ada di dalam Pokja, tips menulis RFP/RFQ yang jelas, kriteria evaluasi teknis dan komersial yang relevan, hingga kiat mengatur kontrak-termasuk SLA, hak kekayaan intelektual, serta rencana transisi (exit strategy). Kami juga membahas aspek penting seperti pemilihan model lisensi (perpetual vs subscription), keamanan data, serta tata cara uji terima (acceptance testing) dan commissioning.

Tujuan utama: membantu Pokja membuat keputusan yang menyeimbangkan kebutuhan fungsional organisasi, keamanan dan tata kelola data, kemampuan teknis vendor, serta nilai terbaik bagi anggaran publik. Bahasa dibuat sederhana agar mudah dipahami, dan setiap bagian disusun agar menjadi checklist praktis yang dapat dipakai langsung oleh tim pengadaan di instansi pemerintahan maupun organisasi swasta. Selanjutnya kita masuk ke detail: mulai dari ruang lingkup permasalahan hingga tindakan operasional yang harus ada di dokumen pengadaan dan manajemen kontrak.

1. Memahami Lingkup Pengadaan Aplikasi dan Perangkat TI

Sebelum menyusun dokumen pengadaan, Pokja harus memetakan dengan jelas lingkup paket TI. “Aplikasi dan perangkat TI” bisa mencakup perangkat keras (server, storage, workstation, jaringan), perangkat lunak (aplikasi, middleware, database), layanan cloud (IaaS/PaaS/SaaS), integrasi sistem, dukungan operasional (maintenance, helpdesk), pelatihan pengguna, dan migrasi data. Menentukan ruang lingkup secara tepat menghindarkan ambiguitas yang sering menyebabkan perubahan kontrak (change order) yang mahal.

Langkah awal yang praktis: pisahkan kebutuhan menjadi tiga lapis-fungsi bisnis (apa yang harus dilakukan sistem), non-fungsional (kinerja, skalabilitas, backup), dan aspek operasional (dukungan, SLA, pemeliharaan). Fungsi bisnis membantu menilai kecocokan solusi (mis. modul pembayaran, modul kepegawaian), sementara non-fungsional melindungi organisasi dari kegagalan teknis (mis. waktu respon, throughput, toleransi kesalahan). Aspek operasional memastikan solusi bisa dikelola setelah implementasi-mis. ketersediaan dokumentasi, akses ke kode sumber atau API, dan kemampuan vendor menyediakan dukungan lokal.

Identifikasi juga integrasi yang diperlukan: apakah sistem baru harus terhubung ke sistem keuangan, SSO (single sign-on), atau e-government? Integrasi menentukan kebutuhan API, protokol keamanan, dan alur data antar-sistem. Pokja perlu meminta diagram arsitektur target minimal (high-level) dari calon penyedia saat proses pra-kualifikasi atau RFI/RFQ.

Risiko khusus TI wajib diinventaris: isu lisensi (open-source vs proprietary), kepemilikan kode (IP), keberlanjutan vendor, ketersediaan suku cadang perangkat keras, dan pemenuhan standar keamanan/data privacy (mis. UU Perlindungan Data Pribadi atau aturan setempat). Untuk layanan cloud, periksa lokasi data center (data residency), enkripsi data at-rest dan in-transit, penyediaan backup, dan prosedur pemulihan bencana.

Terakhir, buatlah ruang lingkup modular-pecah paket besar menjadi fase atau modul. Pendekatan bertahap (phased delivery) memudahkan manajemen risiko, uji terima per fase, dan memungkinkan organisasi belajar sambil berjalan. Pokja sebaiknya menyiapkan skenario fallback (mis. fallback on-premise atau vendor cadangan) jika vendor gagal memenuhi komitmen. Dengan pemetaan lingkup yang matang, pembuatan RFP, evaluasi teknis, dan perencanaan kontrak akan lebih efektif dan praktis.

2. Komposisi Pokja dan Kompetensi yang Diperlukan

Pokja pengadaan TI harus terdiri dari kombinasi keahlian: pengadaan publik, arsitektur TI, keamanan siber, operasional IT, keuangan, serta legal/kontrak. Komposisi ideal tidak selalu membutuhkan semua orang sehari-hari, tetapi harus ada akses cepat ke sumber daya ahli tersebut-baik internal maupun eksternal (konsultan). Berikut peran kunci yang praktis:

1. Ketua Pokja (PPK/Pejabat Pengadaan) – bertanggung jawab keputusan administratif dan kepatuhan prosedural. Dia menjadi penghubung dengan pimpinan.
2. Ahli Teknis / Arsitek TI – menulis spesifikasi teknis, mengevaluasi solusi arsitektur, dan memimpin uji integrasi serta acceptance testing.
3. Spesialis Keamanan Informasi – memastikan persyaratan keamanan, enkripsi, kontrol akses, dan kepatuhan regulasi.
4. Pengelola Operasional / Admin Sistem – menilai kebutuhan operasional, manajemen patch, backup, dan persyaratan SLM (Service Level Management).
5. Keuangan / Anggaran – menghitung TCO (Total Cost of Ownership), lisensi, biaya implementasi & pemeliharaan.
6. Legal / Kontrak – merancang klausul IP, data protection, SLA, dan mekanisme penyelesaian sengketa.
7. Perwakilan Pengguna (Business Owner) – memastikan kebutuhan fungsional sesuai proses bisnis nyata, mengevaluasi User Acceptance Testing (UAT).
8. Manajer Proyek / PMO – menyiapkan rencana implementasi, timeline, manajemen risiko, dan reporting.

Jika Pokja tidak memiliki salah satu kompetensi di atas, rekomendasi praktis adalah mengontrak konsultan teknis atau meminta dukungan unit TI pusat sebelum tender diterbitkan. Konsultan dapat membantu menyusun TOR/RFP, melakukan proof-of-concept (PoC), dan menilai klaim vendor terkait arsitektur atau keamanan.

Selain itu, Pokja perlu menetapkan peran dan tanggung jawab (RACI matrix) agar tidak terjadi tumpang tindih tugas atau keputusan yang terlambat. Contoh: siapa yang memutuskan perubahan scope teknis? Siapa yang berhak menandatangani acceptance document? Menetapkan delegasi wewenang mempercepat proses pengadaan dan implementasi.

Jangan lupakan aspek pelatihan anggota Pokja-terutama untuk yang tidak berlatar belakang TI. Workshop singkat tentang arsitektur cloud, model lisensi perangkat lunak, dan konsep keamanan dasar (enkripsi, IAM, backup, RTO/RPO) membuat evaluasi teknis lebih bermakna. Pokja yang kompeten mengurangi risiko salah memilih solusi dan memperkuat posisi negosiasi saat kontrak.

3. Mengumpulkan Kebutuhan (Requirements Elicitation) yang Jelas

Kegagalan pengadaan TI sering bermula dari kebutuhan yang tidak jelas. Pokja harus memimpin proses elicitation: mengumpulkan kebutuhan fungsional dari pengguna, kebutuhan non-fungsional (kinerja, keamanan), dan batasan operasional. Teknik praktis yang efektif meliputi workshop pengguna, observasi proses, dan review dokumen lama (SOP, laporan masalah).

Mulai dari use case sederhana: minta tiap unit bisnis mendeskripsikan alur kerja utama yang akan didukung aplikasi. Uraikan input-output, volume transaksi, frekuensi, dan waktu kritis. Gunakan persona pengguna untuk menggambarkan kebutuhan UI/UX dasar-mis. admin back-office, operator lapangan, atau publik. Dengan use case, Pokja bisa memetakan fitur wajib vs nice-to-have.

Untuk kebutuhan non-fungsional, prioritaskan aspek yang berisiko tinggi: waktu respon maksimum di jam sibuk, target availability (mis. 99.9%), latency integrasi antar-sistem, kapasitas penyimpanan, dan kebutuhan backup. RTO (Recovery Time Objective) dan RPO (Recovery Point Objective) harus ditentukan untuk mengatur desain backup dan DR (Disaster Recovery).

Data dan keamanan harus dideskripsikan secara konkret: jenis data sensitif, aturan retensi, enkripsi required (mis. AES-256 at-rest), serta compliance yang berlaku (mis. PDPA/GDPR lokal). Jika aplikasi akan beroperasi di cloud, tentukan lokasi data residency, enkripsi, dan persyaratan audit provider cloud.

Juga identifikasi kebutuhan integrasi: protokol (REST API, SOAP), format data (JSON, XML), frekuensi sinkronisasi, dan mekanisme otentikasi (OAuth2, SAML). Pastikan ada persyaratan untuk dokumentasi API dan sandbox/testing environment.

Terakhir, definisikan kriteria acceptance testing. Pokja harus merumuskan skenario UAT yang dapat diukur: daftar test case, kriteria pass/fail, dan jumlah user yang terlibat. Termasuk di dalamnya kriteria penerimaan untuk instalasi, performance test, security penetration test, dan data migration verification. Dokumentasi kebutuhan lengkap memudahkan vendor menyusun solusi tepat, mempermudah evaluasi, dan mengurangi permintaan perubahan selama implementasi.

4. Menyusun RFP/RFQ dan Spesifikasi Teknis yang Efektif

RFP (Request for Proposal) atau RFQ (Request for Quotation) merupakan dokumen kunci. Bagi Pokja, tugasnya membuat dokumen yang cukup rinci agar vendor memahami deliverable tanpa memaksakan teknologi spesifik yang menghambat inovasi. Struktur RFP yang baik meliputi: ringkasan proyek, lingkup kerja, spesifikasi fungsional & non-fungsional, kriteria evaluasi, format penawaran, jadwal, persyaratan kontrak, dan template SLA.

Dalam menulis spesifikasi teknis, gunakan pendekatan performance-based ketimbang technology-based bila memungkinkan. Contoh: daripada menuliskan “harus menggunakan database X”, lebih baik tulis “harus mendukung database relasional yang mampu menampung 10 juta record dengan query < 300ms di jam sibuk”. Ini membuka kompetisi dan mencegah vendor menawar solusi berdasarkan merek tertentu. Namun, bila ada ketergantungan teknis (mis. integrasi ke sistem legacy yang hanya support protokol tertentu), sebutkan secara jelas.

Untuk aplikasi, sertakan diagram arsitektur minimal yang menunjukkan integrasi, flow data sensitif, serta titik akses pihak ketiga. Termasuk persyaratan untuk deployment (on-premise, hybrid, atau cloud) dan lingkungan pengujian. Untuk perangkat keras, cantumkan spesifikasi performa, kompatibilitas, sertifikasi, dan garansi service level.

Cantumkan pula persyaratan dokumentasi yang wajib diserahkan vendor: manual administrator, manual user, API docs, skema database, serta kode sumber jika ada klausul escrow atau kepemilikan. Jika memungkinkan, mintalah sample deliverable (demo atau PoC) sebagai bagian dari proses seleksi.

Terakhir, jelaskan format evaluasi: bobot teknis vs komersial, ambang minimal teknis, dan apakah ada tahap presentasi/demonstrasi. Berikan contoh tabel penilaian supaya vendor paham bagaimana penawaran mereka akan dinilai. RFP yang jelas meminimalkan tanya jawab berkepanjangan dan mempercepat proses seleksi.

5. Kriteria Evaluasi: Teknis, Keamanan, Interoperabilitas, dan Maintainability

Evaluasi penawaran TI harus seimbang: teknis (kecocokan solusi), keamanan, interoperability, maintainability, dan komersial. Pokja perlu membuat rubrik nilai yang terukur. Berikut elemen penting beserta indikator praktis:

• Kesesuaian Fungsional (fit-to-requirement): nilai berdasarkan berapa persen fitur yang terpenuhi vs daftar kebutuhan. Gunakan matriks fitur: setiap fitur wajib diberi status full/partial/none dan bobot sesuai prioritas.
• Kualitas Arsitektur & Desain: asesmen arsitektur, skalabilitas, desain modular, dukungan untuk CI/CD, dan kesiapan integrasi (adanya API, webhook, message queue).
• Keamanan: verifikasi apakah vendor mengimplementasikan enkripsi at-rest/in-transit, IAM, audit logging, vulnerability management, dan menjalani penetration test dari pihak ketiga. Mintalah bukti sertifikasi keamanan bila ada (ISO 27001).
• Interoperabilitas: dukungan protokol standar (REST/GraphQL/SOAP), import/export data, dan kemampuan untuk Single Sign-On serta integrasi dengan middleware yang ada.
• Maintainability & Supportability: kode yang terdokumentasi, adanya automated tests, rencana patching, ketersediaan tim support lokal, SLA waktu respon, dan RTO/RPO untuk recovery.
• Performance & Scalability: hasil performance test (load & stress), rencana capacity planning, serta indikator maksimal transaksi per detik.
• Deliverability & Track Record Vendor: portofolio proyek serupa, referensi klien, kondisi keuangan, dan kapasitas sumber daya.
• Total Cost of Ownership (TCO): biaya lisensi, biaya implementasi, biaya training, biaya maintenance tahunan, biaya cloud/hosting, dan biaya upgrade jangka panjang.

Buat matriks scoring dengan bobot yang jelas (mis. teknis 60%, komersial 40% atau 70:30 untuk proyek kompleks). Terapkan ambang teknis-vendor yang gagal mencapai skor minimal teknis secara otomatis didiskualifikasi walau harga bagus. Selama evaluasi, dokumentasikan bukti untuk setiap skor agar bila ada sanggahan, tim bisa menjelaskan dasar keputusan.

Untuk aspek keamanan, tempatkan requirement minimal yang harus dipenuhi: enkripsi, audit trail, dan mekanisme patching. Vendor yang tidak memenuhi minimal ini sebaiknya tidak dipertimbangkan untuk solusi yang memproses data sensitif. Dengan rubrik yang jelas, Pokja dapat menilai penawaran secara objektif dan mempertahankan posisi yang kuat dalam negosiasi.

6. Lisensi, Model Komersial, dan Penilaian Biaya

Pembelian TI melibatkan model komersial yang beragam: lisensi perpetual, subscription (SaaS), lisensi per-user, lisensi berbasis kapasitas, serta model hybrid. Pokja harus mengevaluasi bukan hanya harga awal tetapi TCO-Total Cost of Ownership-selama siklus hidup yang wajar (mis. 3-5 tahun).

Untuk perangkat lunak on-premise, pertimbangkan biaya lisensi awal, biaya maintenance & support tahunan (biasanya % dari lisensi), biaya infrastruktur (server, storage), serta biaya tenaga operasional. Untuk SaaS, biaya berlangganan biasanya mencakup hosting & maintenance, tetapi perhatikan biaya tambahan (ekspor data, integrasi premium, overage fees). Pastikan klausul harga jelas: apakah ada kenaikan harga tahunan, bagaimana struktur penagihan, dan apakah ada minimum commitment period.

Periksa juga syarat lisensi: apakah lisensi terikat host, instance, atau pengguna? Apakah ada batasan mobilitas (mis. tidak boleh dipindah ke cloud lain)? Untuk open-source, periksa lisensi (GPL, MIT, Apache) dan implikasinya terhadap distribusi atau modifikasi software. Untuk penggunaan komersial, beberapa lisensi open-source membawa kewajiban distribusi source code jika dilakukan modifikasi tertentu.

Evaluasi opsi finansial: apakah model subscription lebih murah dibanding membeli perpetual plus maintenance? Gunakan TCO calculator sederhana untuk membandingkan skenario. Sertakan biaya tak terduga seperti training, kustomisasi, migrasi, dan biaya transisi jika perpindahan vendor di masa depan diperlukan.

Juga penting mengecek mekanisme audit lisensi-beberapa vendor melakukan audit periodik yang dapat menimbulkan biaya denda jika tidak patuh. Pokja harus meminta transparansi atas metode audit dan batasan kewenangan vendor dalam audit.

Terakhir, sertakan klausul cost control dalam kontrak: plafon harga, cap on overage (batas atas biaya tambahan), dan opsi renegosiasi saat volume jauh berbeda dari estimasi awal. Ketentuan ini melindungi organisasi dari lonjakan biaya yang tidak proporsional. Dengan penilaian biaya yang matang, Pokja dapat merekomendasikan model yang memberikan nilai terbaik sesuai kebutuhan dan kapabilitas keuangan organisasi.

7. Menyusun Kontrak: SLA, Jaminan, IP, dan Exit Strategy

Kontrak TI harus melindungi kepentingan pembeli dalam hal kualitas layanan, keamanan data, dan continuity. Beberapa klausul kunci yang wajib diperhatikan:

• Service Level Agreement (SLA): definisikan metrik availability, waktu respon incident (severity levels), waktu perbaikan, dan credit/pinalti jika SLA gagal. Contoh: availability 99.9% per bulan, response P1 dalam 1 jam, dan kredit layanan untuk downtime melebihi threshold.
• Jaminan & Retensi: tentukan garansi atas bug/fault dan retensi pembayaran sampai acceptance testing sukses. Jaminan juga bisa berupa performance bond untuk proyek besar.
• Ownership & IP: jelaskan siapa memegang hak IP atas kode sumber, customizations, dan dokumentasi. Jika organisasi membutuhkan hak penuh (mis. ownership/escrow source code), cantumkan klausul escrow dengan pihak ketiga, atau minimal hak lisensi yang luas untuk fallback.
• Data Protection & Privacy: atur siapa bertanggung jawab atas perlindungan data, enkripsi, akses, serta mekanisme reporting bila terjadi breach. Untuk cloud, tentukan lokasi data (data residency) dan tanggung jawab backup.
• Change Control: prosedur formal untuk request change yang memengaruhi scope, cost, atau timeline-termasuk approval workflow dan penilaian dampak biaya.
• Termination & Exit Management: prosedur terminasi for cause/for convenience, kewajiban transfer data, format data, serta bantuan transisi (knowledge transfer, export of data) dan periode support pasca-terminasi.
• Liability & Indemnity: batas tanggung jawab finansial vendor, exclusion clauses, serta mekanisme indemnity terkait pelanggaran IP atau data breach.
• Dispute Resolution: forum penyelesaian sengketa (mediasi/arbitrase/pengadilan), choice of law, dan jurisdiction.

Khusus untuk kode sumber atau kustomisasi, pertimbangkan klausul escrow: vendor menaruh source code pada pihak ketiga yang dapat diakses pembeli jika vendor gagal memenuhi kewajiban atau pailit. Escrow mengurangi risiko lock-in.

Pastikan kontrak memuat deliverable measurable (milestone & acceptance criteria), pembayaran terikat milestone, dan holdback sampai masa garansi. Draft kontrak harus direview oleh tim legal dan teknis untuk memastikan bahasa teknis cukup jelas dan bisa ditegakkan. Kontrak yang kuat meminimalkan sengketa dan menjamin kontinuitas layanan.

8. Pelaksanaan, UAT, Penerimaan, dan Transfer Operasiona

Tahap implementasi kritikal: Pokja perlu mengawasi milestone, quality gates, dan melakukan Acceptance Testing (UAT) yang terstruktur. Buat rencana implementasi yang memecah pekerjaan menjadi fase: development, testing, pilot, rollout, dan post-go-live support.

UAT harus berbasis skenario nyata dari pengguna-daftar test case yang dipakai untuk menilai fungsionalitas, integrasi, dan performa. Pokja menetapkan pass/fail criteria per test case dan jumlah percobaan yang diizinkan untuk perbaikan. Keberhasilan UAT harus didokumentasikan melalui Berita Acara Serah Terima (BAST) atau dokumen acceptance resmi.

Lakukan juga performance testing (load & stress) untuk memastikan aplikasi tahan beban sesuai kebutuhan. Untuk aplikasi yang kritikal, lakukan security testing termasuk penetration test oleh pihak ketiga. Semua temuan harus ditutup atau disepakati mitigasi sebelum penerimaan final.

Pengelolaan data migration adalah area berisiko: rancang rencana migrasi dengan backup, validasi data, dan cutover plan. Lakukan dry-run migrasi pada environment testing. Pokja perlu memverifikasi integritas data pasca-migrasi melalui sample checks dan reconciliation reports.

Transfer operasional meliputi training pengguna, penyusunan SOP operasional, dan knowledge transfer ke tim internal. Pastikan vendor menyediakan dokumentasi lengkap: admin manual, operational runbook, dan eskalasi kontak. Jika ada SLA, tentukan mekanisme pelaporan insiden dan dashboard monitoring.

Selama masa warranty/pemeliharaan awal, monitor KPI performa dan kepuasan pengguna. Pokja harus memiliki mekanisme remediasi-jika vendor gagal menutup issue sesuai SLA, ada langkah eskalasi hingga penalti atau pengaktifan jaminan. Dokumentasikan semua issue dan penanganannya untuk evaluasi vendor.

Penutupan proyek harus disertai laporan akhir: ringkasan deliverable, status penerimaan, daftar temuan, biaya final, dan rekomendasi. Laporan ini menjadi dasar pembayaran akhir dan evaluasi pasca-implementasi.

Kesimpulan

Pengadaan aplikasi dan perangkat TI memerlukan persiapan, keahlian, dan pengawasan yang lebih mendalam dibanding pengadaan konvensional. Pokja yang efektif menggabungkan kompetensi teknis, keamanan, bisnis, keuangan, dan legal sehingga mampu merancang RFP yang tepat, melakukan evaluasi komprehensif, serta menegosiasikan kontrak yang melindungi kepentingan organisasi. Kunci praktik baik meliputi: memetakan lingkup secara jelas, menyusun kebutuhan fungsional dan non-fungsional yang terukur, menggunakan rubrik evaluasi objektif (termasuk keamanan dan maintainability), mengevaluasi model lisensi berdasar TCO, serta merancang kontrak dengan SLA dan exit strategy yang kuat.

Pada fase implementasi, Pokja harus aktif mengawasi UAT, performance & security testing, migrasi data, dan transfer operasional agar penerapan solusi berjalan mulus. Dokumentasi, reporting, dan mekanisme remediasi harus disiapkan sejak awal untuk menjaga akuntabilitas dan memudahkan audit. Terakhir, terus lakukan evaluasi pasca-implementasi dan pembelajaran agar proses pengadaan TI berikutnya menjadi lebih cepat, lebih aman, dan lebih ekonomis.