Setiap kali perpustakaan daerah ingin naik kelas secara digital, pertanyaannya hampir selalu sama: beli sistem baru yang mahal, atau pakai saja aplikasi yang sudah ada? Saya ingin menawarkan jawaban ketiga, yaitu membangun ekosistem yang saling terhubung dan bisa disesuaikan sendiri. Di tulisan ini saya uraikan bagaimana bagian-bagiannya saya susun.
Ketika Aplikasi Bawaan Menjadi Penghalang
Ada pola yang berulang saya temui di perpustakaan daerah. Aplikasi otomasinya dipasang sekali saat pengadaan, lalu dipakai apa adanya bertahun-tahun. Selama kebutuhan tidak berubah, semuanya terasa baik-baik saja. Masalah muncul ketika perpustakaan ingin menambah layanan peminjaman mandiri, menyusun laporan dengan format yang diminta dinas, atau menampilkan koleksi digital lokal, dan ternyata aplikasinya tidak punya ruang untuk itu. Meminta modifikasi ke pengembang aslinya memakan waktu dan biaya. Mengubahnya sendiri pun sulit, karena kodenya tertutup atau strukturnya terlalu rumit untuk disentuh admin yang bukan programmer.
Dari keresahan itulah saya mengembangkan Peerpus Operating Management Systems, atau PoMS. Gagasan dasarnya sederhana: sistem otomasi yang ideal bukan satu aplikasi tunggal, melainkan ekosistem yang saling terhubung. Ada peladen web sebagai pusat data dan layanan daring, ada aplikasi desktop untuk staf di meja sirkulasi, dan ada perangkat di sisi pengunjung seperti kiosk peminjaman mandiri. Ketiganya bertukar data dengan basis data yang sama, sehingga satu transaksi, di mana pun terjadinya, tercatat dalam satu sumber data yang konsisten.
Fondasi Web dan Database di Sisi Server
Fondasinya saya bangun dengan PHP dan database MySQL atau MariaDB. Untuk lapisan aplikasinya ada dua jalur. PHP Native memberi kendali penuh dan ringan di server dengan sumber daya terbatas. Framework seperti CodeIgniter atau Laravel memberi struktur, fitur keamanan bawaan, dan kemudahan perawatan ketika sistem membesar atau dikerjakan lebih dari satu orang. Tidak ada pilihan yang mutlak benar. Yang lebih menentukan adalah merancang skema tabel dengan rapi sejak awal, karena struktur database adalah bagian yang paling mahal diubah belakangan, apalagi setelah ribuan data masuk.
Pelajaran teknis yang paling berharga datang dari urusan penyimpanan file. Di tahap awal, wajar kalau PDF buku digital dan hasil pindaian ditaruh langsung di hosting utama, dalam kasus saya sebuah VPS Ubuntu. Cara itu cepat, tetapi kapasitas disk VPS terbatas dan menambahnya berarti biaya bulanan yang terus naik. Karena itu file-file besar saya pisahkan ke layanan object storage seperti Cloudflare R2 atau Backblaze B2, sementara VPS hanya menyimpan aplikasi dan database yang ukurannya kecil.
Dampaknya terasa pada tiga hal. Server menjadi lebih ringan. Koleksi digital lebih aman, karena kerusakan VPS tidak ikut melenyapkan file, dan file bisa disimpan privat lalu dibuka lewat tautan sementara hanya untuk anggota yang berhak. Biayanya pun umumnya lebih murah dibanding menambah disk. Kedua layanan itu mendukung protokol S3, jadi PHP cukup terhubung memakai kredensial API standar.
Saat Internet Terputus: Varian Desktop dan Perangkat Keras
Sistem web saja tidak cukup, dan alasannya praktis: koneksi internet di perpustakaan tidak selalu stabil. Kalau seluruh sirkulasi bergantung pada jaringan, satu gangguan saja membuat meja layanan berhenti. Itu sebabnya PoMS punya varian desktop. Aplikasi ini menyimpan data yang dibutuhkan dalam basis data lokal, sehingga staf tetap bisa meminjamkan dan menerima pengembalian buku saat internet putus. Begitu koneksi pulih, transaksi yang tercatat secara offline disinkronkan ke server pusat. Bagian tersulitnya bukan menyimpan data lokal, melainkan menangani benturan data, misalnya ketika status satu buku tercatat berbeda di dua tempat. Aturan sinkronisasi harus dipikirkan sejak awal.
Di sisi perangkat keras, sistem web saya hubungkan dengan anjungan peminjaman mandiri berbasis RFID. Alurnya kira-kira begini. Pemustaka mengidentifikasi diri lewat kartu anggota, meletakkan beberapa buku di area pembaca, lalu pembaca RFID membaca semua tag sekaligus. Kiosk mengirim identitas setiap buku ke server lewat API. Server memeriksa status keanggotaan dan aturan peminjaman, mencatat transaksi, lalu mengirim konfirmasi ke layar. Pada sistem RFID yang lengkap, status pengaman di tag ikut diperbarui supaya gerbang di pintu keluar tidak berbunyi untuk buku yang dipinjam secara sah. Hasilnya, pemustaka bisa memproses pinjamannya sendiri tanpa bantuan petugas, dan staf punya waktu lebih untuk layanan yang membutuhkan sentuhan manusia.
AI sebagai Asisten Pekerjaan Pustakawan
Bagian yang paling menarik buat saya adalah memakai kecerdasan buatan untuk pekerjaan rutin pustakawan. Dua pekerjaan yang paling menyita waktu di bagian pengolahan adalah menentukan nomor klasifikasi dan menulis sinopsis katalog. Keduanya berulang, berbasis teks, dan bergantung pada pemahaman isi buku, wilayah di mana model bahasa besar cukup membantu.
Secara teknis, caranya tidak rumit. Skrip PHP mengirim judul dan abstrak buku ke API pihak ketiga, misalnya Groq dengan model Llama atau Google Gemini API, lewat permintaan HTTP biasa seperti cURL. Di dalam prompt, saya meminta model memberi saran nomor DDC beserta alasannya, ditambah satu paragraf sinopsis, lalu mengembalikannya dalam format JSON agar mudah diolah. PHP menerima JSON itu dan menampilkannya di layar petugas, semuanya dalam hitungan detik.
Yang tidak boleh dilewatkan, hasil itu adalah saran, bukan keputusan. Model bisa keliru atau mengarang, terutama untuk subjek lintas disiplin, jadi pustakawan tetap memeriksa nomor DDC ke bagan dan membaca sinopsis sebelum menyimpannya. Ada dua catatan praktis lain. API key harus disimpan di sisi server, bukan di kode yang bisa dilihat browser. Data pribadi anggota juga tidak perlu dikirim ke layanan AI; cukup data bibliografis buku, apalagi biaya dihitung per token sehingga kirim secukupnya saja.
Sistem yang Menyesuaikan Pemustaka, Bukan Sebaliknya
Membangun ekosistem perpustakaan digital tidak harus selalu bergantung pada vendor IT yang mahal. Dengan memahami alur database, cara kerja API, dan perangkat keras dasar, pustakawan daerah bisa merancang sistem yang menyesuaikan kebutuhan pemustaka lokal, bukan memaksa pemustaka menyesuaikan diri dengan aplikasi.
Saya tidak bermaksud mengatakan vendor tidak berguna, atau bahwa semua perpustakaan harus membuat sistemnya sendiri. Membangun berarti juga merawat: memperbarui sistem, mencadangkan data, dan menjaga keamanan secara rutin. Tapi bagi perpustakaan yang punya orang yang mau belajar, jalur ini terbuka lebar, dan hasilnya adalah sistem yang benar-benar milik perpustakaan itu sendiri.