Saya akan katakan sesuatu yang jarang diakui kebanyakan engineer: memakai Google Sheets sebagai database seringkali adalah keputusan yang tepat. Separuh operasional UKM di Indonesia berjalan di atas spreadsheet, dan itu bukan tanpa alasan. Gratis, semua orang sudah tahu cara pakainya, bisa diakses dari HP mana saja, dan Anda bisa merestrukturnya dalam hitungan detik tanpa perlu memanggil developer.
Saya pernah melihat perusahaan distribusi mencatat ratusan juta rupiah nilai order bulanan lewat Sheet yang tertata rapi. Itu berhasil. Jadi ini bukan artikel yang bilang spreadsheet itu tidak profesional. Ini artikel tentang di titik mana Google Sheets sebagai database berhenti berfungsi, karena kegagalannya jarang terjadi bertahap. Semua baik-baik saja, baik-baik saja, baik-baik saja, lalu tiba-tiba di suatu hari Selasa angka stok Anda salah dan tidak ada yang tahu sebabnya.
Mengetahui pola kegagalan ini lebih awal berarti Anda bisa naik kelas dengan tenang, bukan bermigrasi dalam keadaan panik.
Mengapa Sheets Bekerja Sangat Baik di Awal
Harus diakui memang begitu adanya. Untuk tim dua sampai lima orang yang mengelola beberapa ribu baris data, Sheets memberikan hal-hal yang bahkan sering tidak dimiliki software custom sekalipun:
- Zero deployment. Ubah kolom, tambah formula, share link. Selesai.
- Melek digital untuk semua orang. Staf admin, kepala gudang, dan akuntan Anda semuanya sudah bisa filter dan menjumlahkan data.
- Kolaborasi bawaan. Komentar, riwayat edit, bisa dilihat bersamaan secara real-time.
- Integrasi gratis. Google Forms memasukkan data, Apps Script mengeluarkannya.
Sistem pengganti apa pun harus bisa mengalahkan semua itu, dan inilah sebabnya nasihat "bangun saja sistem yang benar" dari para engineer sering tidak mempan. Spreadsheet menang karena keunggulan yang nyata.
Pola Kegagalan 1: Edit Bersamaan dan Tabrakan yang Diam-Diam Terjadi
Sheets menangani edit bersamaan di level sel dengan cukup baik. Yang tidak bisa ditanganinya adalah logika bisnis yang berjalan bersamaan.
Contoh konkret: dua staf admin sama-sama mengecek kolom stok item A, keduanya melihat sisa 3 unit, dan keduanya mencatat penjualan 2 unit. Database sungguhan bisa diperintahkan "cek dan kurangi dalam satu langkah atomik." Spreadsheet tidak bisa. Kedua edit berhasil tersimpan, sheet Anda sekarang menunjukkan angka 1 atau minus 1 tergantung timing, dan Anda sudah menjanjikan 4 unit padahal stok cuma 3.
Pada volume rendah, manusia masih bisa menangkap kesalahan ini. Pada 50 transaksi atau lebih per hari yang melibatkan banyak orang, mereka berhenti menangkapnya, dan Anda baru tahu dari komplain pelanggan yang marah.
Pola Kegagalan 2: Sort Tak Sengaja yang Merusak Semua Baris
Ini yang paling banyak menghancurkan operasional berbasis spreadsheet dibanding hal lain. Seseorang menyeleksi kolom C, mengurutkannya untuk mencari sesuatu, dan tidak sadar bahwa yang ter-sort hanya kolom itu saja. Sekarang setiap nama pelanggan berpasangan dengan nomor telepon dan nilai order milik orang lain. Data baris 214 tercecer ke ratusan baris lain.
Version history bisa menyelamatkan Anda kalau ada yang segera menyadarinya. Pada praktiknya, kerusakan baru ditemukan berhari-hari kemudian, setelah puluhan edit sah lain menumpuk di atasnya, dan mengurainya berarti akhir pekan penuh rekonsiliasi manual.
Database membuat kategori kesalahan ini secara struktural mustahil terjadi. Satu baris ya satu baris. Field-fieldnya tidak bisa terkocok sendiri-sendiri.
Pola Kegagalan 3: Tanpa Validasi, Data Sampah Menumpuk
Kolom database yang didefinisikan sebagai angka akan menolak "2jt", "2.000.000", "2,000,000", maupun "dua juta". Spreadsheet menerima semuanya dengan senang hati, dan formula SUM Anda diam-diam melewatkan yang tidak bisa diparsing.
Selama berbulan-bulan, ini menumpuk jadi masalah:
| Gejala | Akar masalah |
|---|---|
| Total tidak sesuai kenyataan | Teks tersimpan di kolom angka |
| Pelanggan duplikat | Tidak ada unique constraint, "Budi S" vs "Budi Santoso" |
| Data yatim (orphan) | Baris order menunjuk ke baris pelanggan yang sudah dihapus |
| Kekacauan tanggal | 05/03/2022 dibaca Maret oleh satu orang, Mei oleh orang lain |
Aturan validasi data di Sheets membantu, tapi sifatnya cuma anjuran dan gampang dilewati lewat copy-paste. Tidak ada yang menegakkannya, jadi tidak ada yang mengikutinya saat tenggat mendesak.
Pola Kegagalan 4: Permission Cuma Ada Dua Pilihan, Semua atau Tidak Sama Sekali
Sharing di Sheets pada dasarnya cuma punya tiga level: view, comment, edit. Operasional bisnis butuh granularitas yang lebih halus dari itu. Tim sales Anda seharusnya bisa update status order tapi tidak boleh menyentuh harga. Staf gudang seharusnya bisa lihat kuantitas tapi tidak margin pelanggan. Intern Anda seharusnya bisa menambah baris tapi tidak menghapusnya.
Di Sheets, siapa pun yang punya akses edit bisa mengedit apa saja, menghapus apa saja, dan mengunduh seluruh file. Poin terakhir ini layak diperhatikan: ketika seorang karyawan resign, dia bisa saja membawa pergi seluruh daftar pelanggan Anda di folder download-nya, dan Anda tidak akan pernah tahu. Protected ranges menambal sebagian masalah ini, tapi merawatnya seiring sheet yang terus membesar jadi pekerjaan paruh waktu tersendiri.
Pola Kegagalan 5: Skala, Tembok yang Membosankan
Google Sheets punya batas 10 juta sel, tapi performanya sudah menurun jauh sebelum mencapai angka itu. Lewat 30 sampai 50 ribu baris dengan formula, siap-siap menghadapi lag beberapa detik di setiap edit, gagal load di HP lawas, dan chain VLOOKUP yang butuh semenit untuk kalkulasi ulang. Tim Anda mulai menyimpan salinan lokal untuk menghindari lag, dan sekarang Anda punya lima versi kebenaran yang saling bertentangan, yang justru lebih parah dari kegagalan mana pun di atas.
Jalan Naik Kelas, Tanpa Panik
Sinyal untuk pindah bukan jumlah baris. Sinyalnya adalah ketika biaya akibat kesalahan sudah melebihi biaya software. Beberapa ambang batas jujur dari yang saya lihat pada UKM Indonesia:
- Lebih dari tiga orang mengedit setiap hari, atau ada proses di mana dua orang bekerja di baris yang sama.
- Keputusan uang diambil langsung dari sheet, seperti komitmen stok atau persetujuan kredit.
- Lebih dari satu jam per minggu dihabiskan untuk memperbaiki atau merekonsiliasi data. Itu sudah jadi item gaji, bukan sekadar gangguan kecil.
Kalau sudah kena dua dari tiga ambang batas itu, naik kelas secara bertahap:
- Tahap 1, rapikan struktur yang ada. Satu sheet per entitas (pelanggan, order, produk), kolom ID di semua tabel, validasi data di kolom-kolom kritis, protected ranges di formula. Biaya: satu sore yang fokus.
- Tahap 2, tools database no-code. AirTable atau tools sejenis memberi Anda struktur record sungguhan, tipe field, dan permission per tabel sambil tetap terasa seperti spreadsheet. Kisaran Rp 150 sampai 300 ribu per user per bulan. Cukup memadai sampai puluhan ribu record.
- Tahap 3, sistem custom kecil di atas database sungguhan, biasanya hanya untuk satu atau dua alur kerja di mana kesalahan berdampak uang nyata, dengan Sheets tetap dipakai untuk sisanya. Build fokus semacam ini untuk UKM biasanya berkisar Rp 80 sampai 250 juta tergantung scope, dan risiko terbesarnya bukan teknologinya, melainkan scope creep.
Jangan langsung lompat dari Tahap 1 ke ERP penuh hanya karena ditakut-takuti vendor. Kebanyakan perusahaan yang saya temui belum siap untuk ERP, dan ERP yang prematur gagal lebih parah daripada spreadsheet mana pun.
Yang Perlu Dibawa Pulang
Google Sheets sebagai database adalah tahap yang sah dalam pertumbuhan perusahaan, bukan kesalahan yang perlu dimalukan. Kesalahannya adalah bertahan melewati titik di mana tabrakan diam-diam, sort yang rusak, dan data tanpa validasi mulai memakan biaya lebih besar dari software yang bisa mencegahnya.
Perhatikan tiga ambang batas tadi: banyak editor harian, keputusan uang diambil dari sheet, dan waktu rekonsiliasi mingguan. Kena dua dari itu, mulai Tahap 1 minggu ini juga. Perusahaan yang celaka bukan yang memakai spreadsheet. Mereka adalah yang tidak pernah memutuskan kapan harus berhenti.