Berapa Biaya Sebenarnya Membangun Sistem Akademik Mandiri? Kalkulasi 3 Tahun yang Sering Tidak Dihitung

Catatan editorial: Tokoh dan kampus dalam artikel ini adalah fiktif, disusun untuk keperluan ilustrasi. Namun pola dan angka yang digambarkan mencerminkan kondisi yang umum ditemukan di institusi pendidikan tinggi.

SEVIMA.COM- Proposal itu terlihat rapi. Empat puluh dua halaman, lengkap dengan diagram alur, spesifikasi teknis, dan satu angka di halaman ringkasan eksekutif sekitar Rp 500 juta untuk membangun sistem informasi akademik sendiri.

Bu Sari, Wakil Rektor Bidang Administrasi dan Keuangan, membaca halaman itu dua kali. Angkanya memang lebih besar dari penawaran vendor yang masuk bulan lalu, sekitar Rp 17 juta per bulan, atau Rp 612 juta jika dihitung dalam tiga tahun. Selisihnya tidak terlalu jauh. Tapi logikanya terasa masuk akal bayar sekali, sistem jadi milik kampus, tidak ada ketergantungan terhadap mitra.

Yang tidak ada di halaman mana pun adalah biaya tahun kedua dan ketiga.

Kalkulasi yang Tidak Masuk dalam Proposal Anggaran Membangun Sistem Akademik secara Mandiri

Proposal yang diajukan ketika membangun sistem akademik disusun dengan rapi dan mudah dilihat oleh Bu Sari. Beberapa anggaran dibutuhkan untuk sesuatu yang dasar mulai dari gaji developer, server, lisensi tools. Proposal terlihat rapi.

Namun, banyak hal yang tidak masuk dalam kalkulasi yang turut menyita waktu hingga berpotensi menyebabkan anggaran akan membengkak. Yang tidak masuk adalah waktu orang-orang di luar tim IT: Wakil Rektor yang hadir setiap review dua mingguan, staf akademik yang mendampingi pemetaan kebutuhan selama 40-60 jam, Kepala BAAK yang menguji sistem di sela pekerjaan utamanya. 

Jika dihitung dalam jam kerja dan dikali kompensasi per jabatan, angkanya bisa mencapai ratusan juta rupiah, bergantung skala institusi. Sistem yang “milik sendiri” tetap punya harga. Yang berbeda hanya siapa yang membayar dan dalam bentuk apa.

Di akhir tahun pertama, sistem belum selesai. Timeline mundur dua kuartal. Ini bukan soal kemampuan developernya, namun tantangan yang umum dijumpai ketika tim IT mengerjakan sistem domain-spesifik tanpa referensi pengalaman di ekosistem pendidikan tinggi. 

1. Gaji tim maintenance berkelanjutan 

Sistem yang selesai dibangun tetap butuh orang yang merawatnya (maintenance). Untuk kampus skala menengah, ini berarti 1-2 developer tetap setelah go-live. Mengacu pada kisaran umum pasar kerja IT saat ini, gaji developer mid-level berkisar sekitar Rp 7-10 juta per bulan. Dalam tiga tahun, komponen ini saja sudah berada di rentang Rp 250-720 juta, bergantung jumlah orang dan level senioritas yang dibutuhkan.

2. Penyesuaian regulasi Kemdikbud

Format pelaporan PDDikti dan instrumen BAN-PT berubah secara berkala. Setiap siklus perubahan membutuhkan waktu sekitar beberapa bulan pengerjaan untuk menyesuaikan sistem. 

Bagi kampus dengan tim IT yang kecil, ini bukan pekerjaan yang bisa dikerjakan sambil lalu: selama 1-2 bulan itu, tim yang sama harus menghentikan pekerjaan lain atau bekerja dengan kapasitas terbagi.

3. Infrastruktur yang terus berjalan

Biaya server, bandwidth, backup, dan keamanan sistem bukan biaya sekali bayar. Dalam model on-premise, ada biaya listrik, pendingin, dan refresh hardware. Dalam model cloud, ada tagihan bulanan yang naik seiring pertumbuhan data mahasiswa. Komponen ini jarang masuk perhitungan awal karena terasa kecil per bulan, tapi signifikan jika dilihat dalam tiga tahun.

4. Risiko pergantian developer

Turnover di bidang IT termasuk tinggi dibanding profesi lain. Ketika developer yang menjadi kunci resign, kampus tidak hanya kehilangan tenaga, tapi juga kehilangan pengetahuan tentang sistem yang belum tentu terdokumentasi dengan baik. Biaya rekrutmen, onboarding, dan masa transisi penggantinya tidak pernah ada di proposal awal.

5. Biaya oportunitas manajemen

Proyek pengembangan sistem menyerap waktu banyak pihak di luar tim IT pimpinan yang menghadiri review berkala, staf akademik yang mendampingi pengujian, kepala unit yang memvalidasi alur kerja. Waktu ini tidak muncul di invoice mana pun, tapi tetap punya nilai nyata jika dihitung dalam jam kerja per jabatan.

Strategi Menghitung Biaya Keseluruhan Membangun Sistem 

Untuk menghitung biaya membangun sistem akademik, perguruan tinggi dapat melakukan perhitungan menggunakan Total Cost of Ownership (TCO).

Hasil TCO mencakup seluruh proses yang tidak memberikan nilai tambah serta biaya sisa (scrap), pengerjaan ulang (rework), atau biaya pembuangan lainnya. Untuk itu, Bapak/Ibu dapat menghitung pembangunan sistem akademik ke dalam 3 lapis TCO:

Dari pola yang kami temui selama mendampingi ribuan perguruan tinggi, rujukan perguruan tinggi ada di Lapis 1. Ini lah yang menyebabkan pembengkakan biaya karena tidak menghitung secara keseluruhan. 

3 Lapis ini belum menghitung kerugian jika terjadi serangan. Terlebih di era digital ancaman keamanan data perlu diperhatikan dengan jelas. Dr. Jimmy, S.T., M.I.S., CISA., Direktur Sistem Informasi Manajemen Universitas Surabaya (UBAYA) pernah membahas masalah ini dalam wawancara terkait 5 Tantangan Terbesar dalam Pengelolaan Data Mahasiswa dan Cara Mengatasinya pada Senin, 5 Mei 2025.

“Ancaman terhadap keamanan data sangat nyata, sehingga perguruan tinggi harus memiliki sistem yang dapat melindungi data mahasiswa secara maksimal agar tidak terjadi berbagai ancaman, mulai ransonware, hacking dan berbagai kendala lainnya. Belum lagi kebutuhan manajemen data, ” imbuh Jimmy. 

Untuk menyelesaikan masalah ini, Jimmy menekankan pentingnya pengimplementasian sistem keamanan yang sangat ketat untuk melindungi informasi pribadi mahasiswa. 

Implikasi untuk Keputusan Anggaran

Tujuan dari kalkulasi TCO bukan untuk menjawab apakah kampus harus membangun sendiri atau menggunakan vendor. Keduanya bisa menjadi pilihan yang tepat, bergantung kapasitas, prioritas, dan konteks institusi.

Yang berubah setelah kalkulasi TCO dilakukan adalah kualitas keputusannya.

Kampus yang menghitung Lapis 2 dan 3 sebelum memutuskan tidak akan terkejut di bulan ke-18 ketika tagihan infrastruktur mulai terasa, atau di tahun ketiga ketika developer utama resign bersamaan dengan siklus pembaruan instrumen akreditasi.

Sebaliknya, kampus yang mengevaluasi vendor pun perlu menghitung TCO yang jujur dari sisi mereka: biaya migrasi data, biaya pelatihan staf, risiko ketergantungan vendor, dan fleksibilitas yang mungkin berkurang. Perbandingan yang adil hanya bisa dilakukan kalau kedua sisi dihitung dengan kedalaman yang sama.

Pertanyaan yang perlu ada di meja rapat bukan “mana yang lebih murah di tahun pertama?” tapi “mana yang lebih bisa dipertanggungjawabkan dalam tiga tahun?”

Kampus yang beralih ke platform akademik terpadu seperti SEVIMA Platform, umumnya bukan karena proposal in-house mereka terlalu mahal di atas kertas. Namun karena kalkulasi TCO lengkap menunjukkan bahwa biaya di Lapis 2 dan 3, yang tidak pernah masuk proposal awal, melampaui selisih harga yang semula terlihat signifikan. 

Platform yang sudah menangani ekosistem akademik ratusan kampus membawa satu keuntungan yang tidak terlihat di brosur mana pun. Di mana beban Lapis 2 dan 3 tidak lagi sepenuhnya di pundak tim IT kampus.

Diposting Oleh:

Liza SEVIMA