Memilih vendor sistem informasi akademik adalah keputusan yang konsekuensinya bertahan lima sampai sepuluh tahun, jauh melampaui masa kontrak pengembangannya. Biaya terbesar dari pilihan yang salah bukan biaya pengembangan yang terbuang, melainkan biaya berpindah: migrasi data penilaian beberapa angkatan, pelatihan ulang seluruh pengguna, dan satu sampai dua tahun akademik dengan sistem yang berjalan setengah-setengah. Karena itu kriteria penilaian yang baik tidak berfokus pada daftar fitur — hampir semua vendor dapat menyediakan fitur yang sama — melainkan pada hal-hal yang mahal diperbaiki setelah kontrak ditandatangani: struktur data, model kepemilikan, kemampuan integrasi, dan keberlanjutan vendor.
Delapan kriteria berikut disusun untuk menilai vendor mana pun. Setiap kriteria dilengkapi pertanyaan yang sebaiknya diajukan saat presentasi vendor, beserta bentuk jawaban yang layak dipercaya. Gunakan kriteria ini untuk menilai semua kandidat, termasuk kami.
1. Kesesuaian dengan struktur kurikulum institusi Anda
Ini kriteria paling menentukan, dan paling sering dilewati karena terdengar teknis. Sejak standar nasional pendidikan tinggi bergerak dari pengaturan rinci menjadi kerangka, setiap perguruan tinggi merumuskan capaian pembelajaran lulusannya sendiri — dengan jumlah, penamaan, dan struktur yang bisa berbeda antar institusi, bahkan antar program studi dalam satu institusi.
Akibatnya, sistem yang strukturnya dipatok di dalam kode program akan menuntut pekerjaan pengembang setiap kali kurikulum direvisi.
Tanyakan: “Jika program studi kami menambah satu CPL di tengah tahun akademik, apa yang harus dilakukan — konfigurasi oleh admin kami sendiri, atau permintaan perubahan ke tim Anda?”
Jawaban yang layak dipercaya: vendor memperlihatkan prosesnya langsung di sistem, bukan menjelaskannya secara lisan. Minta diperagakan, bukan dideskripsikan. Jawaban “bisa dikustomisasi” tanpa penjelasan mekanismenya perlu diperjelas, karena kustomisasi lewat perubahan kode berbeda jauh konsekuensinya dengan konfigurasi lewat antarmuka.
2. Rekam jejak pada segmen yang sama dengan institusi Anda
Pengalaman vendor di perguruan tinggi umum tidak otomatis berlaku untuk politeknik, dan pengalaman di perguruan tinggi swasta tidak otomatis berlaku untuk perguruan tinggi keagamaan negeri yang punya alur pelaporan dan struktur kurikulum tersendiri.
Tanyakan: “Sebutkan dua institusi dengan jenis dan ukuran yang mirip dengan kami yang sistemnya sudah berjalan, dan izinkan kami menghubungi mereka.”
Jawaban yang layak dipercaya: nama institusi yang spesifik, dan kesediaan vendor memfasilitasi kontak. Penolakan memberi referensi dengan alasan kerahasiaan masih wajar untuk satu atau dua klien, tetapi tidak wajar kalau berlaku untuk semua.
3. Model kepemilikan source code dan data
Kriteria ini menentukan kemandirian institusi dalam jangka panjang, dan sering baru disadari ketika institusi ingin berpindah vendor atau mengembangkan sendiri.
Tanyakan tiga hal terpisah, karena ketiganya sering dijawab bersamaan padahal berbeda: siapa pemilik source code setelah serah terima; siapa pemilik data akademik; dan apakah data dapat diekspor dalam format terbuka tanpa biaya tambahan.
Jawaban yang layak dipercaya: ketentuan tertulis di dalam kontrak, bukan pernyataan lisan saat presentasi. Perhatikan juga perbedaan antara kepemilikan source code dan hak memodifikasinya — sebagian kontrak memberikan salinan kode tetapi melarang modifikasi oleh pihak lain.
4. Kemampuan integrasi dengan sistem yang sudah berjalan
SIAKAD jarang berdiri sendiri. Umumnya ia perlu terhubung dengan pelaporan nasional, sistem keuangan, perpustakaan, pembayaran melalui bank, dan autentikasi terpusat.
Tanyakan: “Integrasi mana dari daftar kami yang sudah pernah Anda kerjakan di proyek nyata, dan mana yang akan menjadi pengembangan baru?”
Jawaban yang layak dipercaya: pemisahan yang jelas antara “sudah pernah” dan “bisa dikerjakan”. Keduanya sah, tetapi yang kedua mengandung risiko jadwal yang perlu masuk perhitungan. Vendor yang menjawab “semua bisa” tanpa memisahkan keduanya sedang memindahkan risiko itu kepada Anda.
5. Model implementasi dan pelatihan pengguna
Kegagalan implementasi SIAKAD lebih sering disebabkan pengguna yang tidak terbiasa daripada perangkat lunak yang tidak berfungsi. Dosen dan staf administrasi adalah pengguna yang paling menentukan, dan mereka punya pekerjaan lain.
Tanyakan: “Siapa yang melatih, berapa sesi, untuk berapa orang, dan apa yang terjadi kalau setelah tiga bulan masih ada unit yang belum memakai sistem?”
Jawaban yang layak dipercaya: jumlah sesi dan peserta yang tertulis dalam kontrak, bukan janji “pelatihan sampai bisa”. Tanyakan juga apakah tersedia dokumentasi untuk pengguna akhir, bukan hanya untuk administrator.
6. Dukungan setelah go-live dan ketentuan layanan
Masa paling rawan sebuah SIAKAD adalah pekan pertama KRS dan pekan penginputan nilai di akhir semester. Pada saat itulah kecepatan respons vendor menentukan, dan pada saat itu pula semua kliennya mengalami beban puncak bersamaan.
Tanyakan: “Berapa masa garansi, apa yang tercakup dan apa yang tidak, berapa waktu respons yang dijanjikan, dan bagaimana prioritas ditentukan saat beberapa klien melapor bersamaan?”
Jawaban yang layak dipercaya: waktu respons yang dinyatakan dalam satuan jam kerja beserta definisi tingkat keparahan masalah. Perhatikan perbedaan antara waktu respons dan waktu penyelesaian — keduanya sering tertukar dalam penawaran.
7. Keamanan dan perlindungan data
SIAKAD menyimpan data pribadi mahasiswa dan dosen dalam jumlah besar. Sejak berlakunya Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi, institusi sebagai pengendali data memikul tanggung jawab atas pemrosesan yang dilakukan vendor sebagai pemroses.
Tanyakan: “Di mana data disimpan secara fisik, siapa di pihak Anda yang dapat mengakses data produksi kami, bagaimana prosedur backup dan pemulihannya, dan apakah ada perjanjian pemrosesan data terpisah?”
Jawaban yang layak dipercaya: lokasi penyimpanan yang jelas, daftar peran yang punya akses, dan kesediaan menandatangani perjanjian pemrosesan data. Pertanyaan tentang pemulihan sebaiknya ditanyakan dalam bentuk “kapan terakhir kali pemulihan dari backup benar-benar diuji” — keberadaan backup dan kemampuan memulihkannya adalah dua hal berbeda.
8. Keberlanjutan vendor
Kontrak pengembangan selesai dalam hitungan bulan, tetapi sistem akan dipakai bertahun-tahun. Vendor yang berhenti beroperasi meninggalkan institusi dengan sistem yang tidak bisa dikembangkan lagi.
Tanyakan: “Berapa lama perusahaan ini beroperasi, berapa orang di tim teknis, dan apa yang terjadi pada sistem kami jika perusahaan berhenti beroperasi?”
Jawaban yang layak dipercaya: untuk pertanyaan terakhir, jawaban terbaik adalah ketentuan tertulis mengenai penyerahan source code dan dokumentasi dalam kondisi tersebut. Vendor yang belum pernah memikirkan pertanyaan ini biasanya akan terlihat dari jawabannya.
Satu catatan yang perlu disampaikan secara terbuka: ukuran perusahaan bukan jaminan keberlanjutan, dan perusahaan kecil tidak otomatis lebih berisiko. Yang lebih menentukan adalah apakah pengetahuan tentang sistem Anda terdokumentasi atau hanya ada di kepala satu dua orang. Pertanyaan yang lebih berguna daripada “berapa besar perusahaan Anda” adalah “kalau pengembang yang mengerjakan sistem kami berhenti bekerja, siapa yang bisa melanjutkan dan dari dokumen apa?”
Kerangka penilaian yang bisa dipakai langsung
Tabel di bawah dapat disalin ke spreadsheet dan diisi untuk setiap kandidat. Kolom bobot sengaja dibiarkan sebagai saran, bukan ketentuan — sesuaikan dengan kondisi institusi Anda. Institusi yang baru pertama kali memasang SIAKAD biasanya perlu memberi bobot lebih besar pada kriteria 5 dan 6; institusi yang berpindah dari sistem lama perlu memberi bobot lebih besar pada kriteria 3 dan 4.
| Kriteria | Saran bobot | Pertanyaan penentu | Nilai 1–5 |
|---|---|---|---|
| 1. Kesesuaian struktur kurikulum | 20% | Menambah CPL: konfigurasi admin atau permintaan ke vendor? | |
| 2. Rekam jejak segmen sejenis | 15% | Dua institusi serupa yang bisa dihubungi | |
| 3. Kepemilikan source code dan data | 15% | Ketentuan tertulis dalam kontrak | |
| 4. Kemampuan integrasi | 15% | Mana yang sudah pernah, mana yang baru | |
| 5. Implementasi dan pelatihan | 10% | Jumlah sesi dan peserta dalam kontrak | |
| 6. Dukungan dan ketentuan layanan | 10% | Waktu respons dalam jam kerja, per tingkat keparahan | |
| 7. Keamanan dan perlindungan data | 10% | Lokasi data, akses, uji pemulihan terakhir | |
| 8. Keberlanjutan vendor | 5% | Siapa yang melanjutkan, dari dokumen apa |
Satu peringatan soal penggunaan tabel ini. Penilaian berbobot membantu membandingkan, tetapi jangan dipakai secara mekanis. Kriteria 1 dan 3 bersifat menggugurkan: vendor yang struktur penilaiannya tidak dapat dikonfigurasi, atau yang tidak mau menuliskan ketentuan kepemilikan data dalam kontrak, sebaiknya tidak diselamatkan oleh nilai tinggi di kriteria lain.
Lima tanda yang perlu diwaspadai
Daftar fitur yang sangat panjang tanpa satu pun peragaan langsung. Jumlah fitur mudah dituliskan. Minta diperagakan tiga alur yang paling sering dipakai institusi Anda: input nilai oleh dosen, KRS oleh mahasiswa, dan penarikan laporan ketercapaian CPL oleh program studi.
Janji kenaikan peringkat akreditasi. Sistem informasi memudahkan penyediaan data dan mengurangi pekerjaan manual, tetapi penilaian akreditasi mencakup banyak aspek di luar sistem. Vendor yang menjanjikan hasil akreditasi sebaiknya diminta menjelaskan dasar klaimnya.
Penawaran harga tanpa rincian lingkup. Satu angka total tanpa rincian modul, jumlah pengguna, lingkup integrasi, dan cakupan pemeliharaan hampir selalu menimbulkan perselisihan di tengah proyek. Minta rincian, bukan diskon.
Tenggat yang terlalu cepat untuk ukuran lingkupnya. Penawaran yang menjanjikan SIAKAD terintegrasi penuh dalam enam pekan untuk institusi dengan belasan program studi perlu dipertanyakan. Jadwal yang realistis adalah tanda vendor yang pernah mengerjakannya.
Keengganan memberi akses ke lingkungan uji sebelum kontrak. Vendor yang yakin pada sistemnya biasanya bersedia memberi akses terbatas untuk dicoba. Keengganan total pada tahap ini perlu ditanyakan alasannya.
Kapan sistem siap pakai lebih tepat daripada custom
Sebagian institusi tidak membutuhkan pengembangan custom, dan menyadarinya lebih awal akan menghemat banyak waktu serta biaya. Pengembangan custom sebaiknya tidak dipilih dalam tiga kondisi berikut.
Ketika alur akademik institusi tidak punya kekhasan yang berarti. Kalau struktur kurikulum, alur penerimaan mahasiswa, dan pola penilaian institusi Anda pada dasarnya sama dengan praktik umum, sistem siap pakai akan lebih murah, lebih cepat berjalan, dan sudah teruji di banyak institusi lain. Membangun dari awal sesuatu yang sudah tersedia hanya menambah biaya dan risiko.
Ketika tenggat lebih pendek daripada waktu pengembangan yang wajar. Institusi yang harus memiliki sistem berjalan dalam dua bulan sebaiknya memasang sistem siap pakai lebih dahulu, lalu mempertimbangkan pengembangan custom pada siklus berikutnya. Memaksakan pengembangan custom di bawah tenggat yang terlalu pendek biasanya berakhir pada sistem yang separuh selesai di tengah tahun akademik — kondisi yang lebih buruk daripada kedua pilihan semula.
Ketika belum ada unit yang akan merawat sistem. Sistem custom menuntut setidaknya satu orang di pihak institusi yang memahami konfigurasinya dan menjadi penghubung ke vendor. Institusi tanpa unit teknologi informasi atau tanpa penanggung jawab yang jelas akan lebih terbantu oleh sistem siap pakai dengan dukungan vendor yang terstandardisasi.
Sebaliknya, pengembangan custom umumnya lebih tepat bila institusi punya kekhasan kurikulum yang tidak terakomodasi sistem siap pakai, perlu integrasi dengan sistem internal yang sudah berjalan, atau menghadapi perubahan kurikulum yang berkelanjutan sehingga membutuhkan struktur penilaian yang dapat dikonfigurasi sendiri.
Ringkasnya
Biaya terbesar dari pemilihan vendor SIAKAD yang keliru bukan biaya pengembangan, melainkan biaya berpindah beberapa tahun kemudian. Karena itu dua kriteria yang paling menentukan adalah seberapa jauh struktur penilaian dapat dikonfigurasi tanpa mengubah kode program, dan apa yang tertulis dalam kontrak mengenai kepemilikan source code dan data. Keduanya sulit dan mahal diperbaiki setelah kontrak ditandatangani, sementara kekurangan fitur umumnya masih bisa ditambahkan di kemudian hari.
Ajukan delapan pertanyaan di atas kepada setiap kandidat, minta peragaan langsung alih-alih penjelasan lisan, dan minta jawaban atas kriteria 1 dan 3 dituangkan dalam kontrak.
PT Arkatama Multi Solusindo mengembangkan sistem informasi akademik untuk perguruan tinggi, politeknik, dan sekolah tinggi di Indonesia, termasuk Siakad Link yang dirancang mengikuti kurikulum berbasis Outcome-Based Education. Kami menyarankan Anda menilai kami dengan kriteria yang sama, dan bersedia menjawab kedelapan pertanyaan di atas secara tertulis. Jika institusi Anda sedang menyusun pemilihan vendor, konsultasi awal untuk memetakan kebutuhan dapat dilakukan tanpa biaya dan tanpa ikatan.
Bacaan terkait
Sumber
- Permendiktisaintek Nomor 10 Tahun 2026 tentang Perubahan atas Permendiktisaintek Nomor 39 Tahun 2025 tentang Penjaminan Mutu Pendidikan Tinggi — berlaku 16 Juli 2026
- Kemdiktisaintek: Perguruan Tinggi Fleksibel Kembangkan Standar Kompetensi Lulusan
- Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi
