Kebanyakan pemilik bisnis menandatangani kontrak software seperti menandatangani paket telepon: lihat sekilas harganya, lihat sekilas fiturnya, langsung tanda tangan. Negosiasi kontrak software terasa menakutkan karena vendor menyajikan persyaratannya seolah sudah baku. Padahal tidak. Saya sudah duduk di kedua sisi meja ini, sebagai vendor yang membangun sistem dan sebagai penasihat teknis yang mereview kontrak sebelum klien menandatanganinya, dan polanya selalu sama: klausul yang paling penting justru yang tidak pernah dibaca siapa pun, dan vendor akan mengalah pada klausul itu jika Anda memintanya sebelum tanda tangan, tidak pernah sesudahnya.
Ini bukan soal menekan harga lebih murah. Ini soal memastikan bahwa jika hubungan kerja ini berantakan, di tengah pembangunan, di tengah masa kontrak, atau saat perpanjangan, Anda tidak menjadi pihak yang tidak mendapat apa-apa.
Kepemilikan data dan format ekspor
Ini klausul yang paling banyak menjebak bisnis dalam lock-in yang tak terlihat. Data Anda, data pelanggan, riwayat transaksi, level inventori, harus tertulis eksplisit dalam kontrak sebagai milik Anda, bukan milik vendor, terlepas dari siapa yang membangun database-nya.
Yang lebih penting dari kepemilikan adalah format ekspor. Vendor bisa secara teknis menyerahkan "data Anda" dalam bentuk dump proprietary yang tidak bisa dibaca dan tetap mengklaim itu sudah sesuai kesepakatan. Tegaskan poin-poin berikut:
- Ekspor dalam format standar (CSV, SQL dump, atau JSON), bukan tool ekspor proprietary yang mengharuskan software mereka untuk membacanya.
- Batas waktu maksimal untuk menyediakan ekspor saat diminta, bukan hanya saat kontrak berakhir.
- Tidak ada biaya tambahan untuk ekspor format standar, meski biaya wajar untuk ekspor format kustom itu masuk akal.
Saya pernah melihat sebuah perusahaan multifinance bernegosiasi tiga bulan soal harga tapi melewatkan klausul ini sepenuhnya, lalu menghabiskan enam minggu berjuang mengeluarkan data pelanggan dari format vendor saat mereka akhirnya pindah sistem. Minta contoh hasil ekspor sebelum tanda tangan. Kalau vendor ragu-ragu, keraguan itu sudah menjadi jawabannya.
Escrow source code
Jika sistemnya dibangun khusus untuk Anda, dan Anda membayar untuk itu, Anda perlu klausul escrow source code: kode disimpan oleh pihak ketiga netral (atau, yang lebih praktis untuk UKM di Indonesia, disimpan di repository bersama yang tercatat aksesnya) dan dirilis ke Anda jika vendor bangkrut, menghilang, atau melanggar kontrak secara material.
Ini bukan penghinaan bagi vendor. Vendor yang serius dan tidak punya yang disembunyikan akan setuju, karena kondisi pemicunya sempit dan wajar. Jika vendor menolak escrow secara mentah-mentah, tanyakan alasannya. Kadang jawaban jujurnya adalah bahwa sistem "kustom" itu sebenarnya adalah inti kode bersama yang tidak berlisensi dan secara hukum tidak bisa mereka serahkan, informasi yang berguna sebelum Anda berkomitmen enam atau tujuh digit rupiah.
Kriteria penerimaan yang terikat pada milestone pembayaran
Deliverable yang samar menghasilkan sengketa yang samar. "Fase 2 selesai" tidak berarti apa-apa jika tidak ada yang mendefinisikan apa itu fase 2. Setiap milestone pembayaran dalam kontrak harus dipetakan ke daftar kriteria penerimaan tertulis: fitur spesifik, test case spesifik, proses sign-off spesifik dengan jumlah hari kerja yang jelas untuk Anda mereview dan memutuskan menerima atau mendaftar defect.
Tanpa ini, Anda akan berakhir membayar 30% di muka, 40% pada milestone yang tidak bisa didefinisikan siapa pun, dan 30% saat "go-live", yang akan diklaim vendor sudah terjadi begitu mereka men-deploy apa pun, entah itu benar-benar berfungsi atau tidak. Saya menulis lebih jauh soal pola kegagalan ini di kisah horor proyek software; milestone yang samar adalah biang keladi yang berulang.
Waktu respons dukungan yang bergigi
Klausul SLA (service level agreement) yang berbunyi "kami akan merespons secepatnya" tidak melindungi siapa pun. Negosiasikan angka yang spesifik:
| Tingkat keparahan | Waktu respons | Target penyelesaian |
|---|---|---|
| Kritis (sistem down) | 1-2 jam | Hari yang sama |
| Tinggi (fitur utama rusak) | 4-8 jam | 1-2 hari kerja |
| Sedang (bug minor) | 1 hari kerja | 1 minggu |
| Rendah (kosmetik, permintaan enhancement) | 2-3 hari kerja | Siklus rilis berikutnya |
Kaitkan penalti finansial, kredit layanan atau diskon pada invoice berikutnya, dengan keterlambatan respons pada tingkat kritis. Tanpa penalti, SLA hanya sekadar saran. Dengan penalti, vendor akan menempatkan staf sesuai kebutuhan.
Klausul bantuan transisi dan exit
Klausul yang selalu dilewatkan semua orang karena hari tanda tangan bukan hari putus, sampai akhirnya benar-benar terjadi. Bantuan exit harus menegaskan:
- Periode transisi yang jelas (biasanya 30-90 hari) di mana vendor tetap mendukung sistem selagi Anda bermigrasi keluar.
- Kewajiban transfer pengetahuan: dokumentasi, panggilan handover, jawaban atas pertanyaan teknis dari tim atau vendor baru Anda.
- Tidak ada biaya baru yang diciptakan saat exit untuk layanan yang sebelumnya sudah termasuk.
Saya pernah menyaksikan vendor memperlakukan proses keluar klien yang tidak puas sebagai leverage, memperlambat akses, "menemukan" biaya baru, menunda ekspor data hingga melewati titik di mana tim klien masih bisa bertindak secara wajar. Klausul bantuan exit tertulis menghilangkan leverage itu sebelum ia sempat ada. Ini terhubung langsung dengan memiliki data pelanggan Anda sendiri: klausul kepemilikan data tanpa klausul bantuan exit hanya separuh terlindungi.
Kapan sebenarnya harus bersikeras
Tidak semua klausul layak diperjuangkan, dan memperlakukan setiap negosiasi sebagai pertarungan hanya menghabiskan goodwill yang akan Anda butuhkan nanti. Bersikeraslah pada: ekspor data, IP/escrow, kriteria penerimaan, bantuan exit. Bersikaplah wajar pada: definisi waktu respons (minta angka yang realistis, bukan angka agresif yang memaksa vendor menambah staf berlebihan dan menaikkan harga), dan batas liabilitas minor yang memang sudah standar industri.
Uji yang saya gunakan: apakah saya akan nyaman jika klausul ini dibacakan di depan hakim, dengan saya sebagai vendor? Jika sebuah klausul hanya masuk akal dengan asumsi semuanya berjalan lancar, itu bukan klausul kontrak, itu optimisme. Perbaiki sekarang, atau bersiaplah menegosiasikannya ulang dalam kondisi yang lebih buruk nanti, saat Anda tidak punya leverage tersisa dan sistem yang tidak sanggup Anda tinggalkan. Jika tim Anda belum yakin bagaimana menyusun ini sebelum tanggal tanda tangan, itu adalah percakapan dua jam yang layak dilakukan sebelum kontrak, bukan sesudahnya. Bicara dengan partner kami jika Anda ingin sepasang mata kedua untuk meninjau kontrak sebelum Anda menandatanganinya.
Kesimpulan
Negosiasikan lima klausul ini sebelum tanda tangan, bukan sesudahnya: format ekspor data, escrow source code, kriteria penerimaan per milestone, waktu respons SLA yang bergigi finansial, dan bantuan exit dengan periode transisi yang jelas. Vendor akan mengalah pada kelima hal ini jika diminta di meja negosiasi. Tidak satu pun akan mereka alah begitu tintanya kering dan Anda paling membutuhkannya.