Cara Membuat Term of Reference (TOR) Proyek: Autopsi Dokumen Pengunci Vendor B2B

Meja perundingan di ruang direksi itu terasa panas. Pihak perusahaan (Klien) bersikeras bahwa fitur sinkronisasi database otomatis sudah sepantasnya masuk ke dalam paket pembuatan aplikasi. Di seberang meja, vendor IT dengan wajah tegang membela diri, menyatakan bahwa fitur tersebut tidak pernah dibahas di awal dan merupakan pekerjaan tambahan (Add-on) senilai 50 juta rupiah. Kedua belah pihak saling menunjuk. Kontrak proyek senilai setengah miliar itu terancam batal, deadline sudah molor dua bulan, dan semua ini berakar dari satu dokumen setebal lima halaman yang dibuat secara amatir: Term of Reference (TOR).

Dalam ekosistem proyek Business-to-Business (B2B), menulis TOR bukan sekadar menggugurkan kewajiban administrasi sebelum melempar tender. TOR adalah kitab suci operasional. Ia adalah pagar betis hukum yang memisahkan antara ekspektasi direktur dengan eksekusi vendor di lapangan. Jika TOR Anda penuh dengan celah bahasa yang bersayap (Ambiguitas), Anda sama saja menyerahkan cek kosong kepada vendor nakal untuk memeras Anda di tengah jalan melalui Scope Creep (Pembengkakan ruang lingkup kerja).

Kita akan membedah forensik secara brutal cara membuat term of reference tor proyek yang anti-debat. Lupakan format akademik yang bertele-tele. Kita akan merancang dokumen spesifikasi yang mengikat leher vendor, dari membatasi kriteria teknis agar tidak disusupi perusahaan abal-abal, hingga menautkan TOR secara absolut dengan Owner Estimate (RAB). Ini adalah panduan bertahan hidup bagi para Project Manager di hutan rimba pengadaan korporat.

Regulasi Standar Spesifikasi Pengadaan Korporat

Mendesain acuan kerja tidak bisa menggunakan gaya bahasa sastra. Anda harus tunduk pada kaidah hukum perikatan dan standar kejelasan lelang (Procurement).

Berdasarkan prinsip pengadaan yang merujuk pada pedoman PMBOK (Project Management Body of Knowledge) dan standar Peraturan LKPP tentang Penyusunan Spesifikasi Teknis/KAK:

• Dokumen Kerangka Acuan Kerja (KAK) atau TOR mutlak harus mendefinisikan batasan (Out of Scope) dengan kejelasan yang sama tingginya dengan daftar pekerjaan yang diminta (In Scope) untuk mencegah sengketa penafsiran.
• Penyebutan merek (Brand) tertentu pada spesifikasi teknis dilarang keras dalam tender terbuka, melainkan wajib menggunakan deskripsi ekuivalensi (Setara/Memenuhi Standar ASTM/ISO tertentu).
• Setiap tonggak penyelesaian (Milestone) wajib dikaitkan secara langsung dengan Kriteria Penerimaan (Acceptance Criteria) yang dapat diukur secara matematis atau fisik, bukan kualitatif.

Bagi tim pengadaan (Procurement) Anda, mendalami literatur standar penyusunan kerangka acuan adalah garis pertahanan pertama sebelum uang muka proyek dicairkan ke rekening pihak ketiga.

5 Komponen Absolut TOR yang Tidak Bisa Ditawar

Dokumen TOR yang mematikan tidak butuh 50 halaman. Ia hanya butuh struktur yang padat, presisi, dan tidak memberi ruang untuk imajinasi vendor. Jika salah satu dari 5 pilar ini hilang, proyek Anda akan runtuh.

1. Latar Belakang & Objective (Tujuan): Jangan menulis “Kami ingin membuat aplikasi baru.” Tuliskan metrik rasa sakitnya. “Sistem antrean manual saat ini menyebabkan waktu tunggu truk di gudang logistik mencapai 3 jam per unit. Tujuan proyek ini adalah membangun aplikasi penjadwalan yang memangkas waktu tunggu truk menjadi maksimal 45 menit.” Ini memberikan vendor konteks masalah yang nyata.

2. Ruang Lingkup (Scope of Work / SOW): Ini adalah jantung dokumen. Pecah menjadi peluru (Bullet Points). “Membuat modul Login, Modul GPS Tracking, dan Dasbor Admin.” Lalu, yang paling krusial, buat sub-bab: OUT OF SCOPE (Di luar lingkup). “Integrasi dengan sistem perbankan (Payment Gateway) dan pembelian Hardware/Server adalah tanggung jawab Klien, BUKAN tanggung jawab Vendor.” Pagar batas inilah yang menghentikan vendor meminta tambahan uang. Memahami batasan lingkup ini identik dengan taktik pada Optimasi Database Skala Besar, di mana batasan query menentukan hidup matinya server.

3. Kualifikasi Tenaga Ahli: Jangan membiarkan vendor mengirimkan programmer magang (Junior) ke proyek bernilai ratusan juta. Tuliskan syarat mutlak: “Vendor wajib menyediakan 1 orang Project Manager dengan sertifikat PMP/Scrum Master aktif, dan 2 orang Senior Developer dengan pengalaman spesifik Node.js minimal 5 tahun yang dibuktikan dengan CV dan Portofolio riil.”

4. Timeline & Milestones: Jangan menulis “Proyek selesai dalam 3 bulan.” Itu terlalu rapuh. Gunakan metode tahapan. “Bulan 1: Penyerahan Desain UI/UX (Maks 2 kali revisi). Bulan 2: Penyerahan kode backend. Bulan 3: Uji coba User Acceptance Test (UAT) dan Go-Live.”

5. Output & Deliverables: Apa wujud fisik atau digital yang harus Anda pegang di akhir proyek? “Aplikasi Source Code mentah, Buku Panduan Pengguna (Manual Book) minimal 20 halaman, dan akses penuh ke arsitektur Cloud Server.”

Kriteria Kualifikasi: Membunuh Vendor Abal-abal di Pintu Masuk

Hancurnya proyek sering kali bermula dari masuknya vendor “Calo”. Mereka menang tender, lalu melemparkan (Sub-contract) pekerjaan tersebut ke freelancer mahasiswa dengan harga murah. Anda tidak bisa melacak pekerjaan mereka.

Untuk mengamankan proyek, TOR Anda harus menyertakan Syarat Kualifikasi Teknis & Legal.
Masukan klausul: “Vendor wajib melampirkan minimal 3 Berita Acara Serah Terima (BAST) proyek sejenis (Software Logistik) yang diselesaikan dalam kurun waktu 3 tahun terakhir dengan nilai kontrak per proyek minimal Rp 200.000.000. Vendor DILARANG mengalihkan pekerjaan utama (Sub-kon) kepada pihak ketiga tanpa persetujuan tertulis dari Direksi Klien.”

Syarat ini akan secara otomatis menyeleksi (Filter-out) CV atau PT baru jadi yang tidak punya pengalaman lapangan, menyisakan hanya pemain kelas berat (Enterprise) di meja presentasi Anda. Pengamanan kontrak ini sejalan dengan kekejaman legalitas pada panduan Klausul Penalti Keterlambatan Vendor IT.

Menghindari Ambiguitas: Area Abu-abu yang Memicu Sengketa

Penyebab utama sengketa di Pengadilan Arbitrase Bisnis adalah kata-kata bersayap. Kata seperti “Terbaik”, “Secukupnya”, “Standar Industri”, atau “User Friendly” adalah haram hukumnya dimasukkan ke dalam TOR.

Jika TOR Anda menulis: “Vendor wajib menyediakan pelatihan untuk karyawan secara maksimal.” Vendor bisa saja hanya mengirimkan satu tautan video YouTube berdurasi 10 menit, dan secara teknis (di mata hukum), mereka sudah memberikan “pelatihan”.

Ganti kalimat abu-abu tersebut menjadi parameter kuantitatif (Bisa dihitung dengan angka). “Vendor wajib menyediakan pelatihan tatap muka langsung (On-site Training) selama 2 hari kerja efektif (8 jam/hari) untuk maksimal 15 orang staf Admin, dilengkapi modul cetak (Hardcopy).” Jika aturannya kaku seperti ini, vendor tidak memiliki celah untuk lari dari tanggung jawab. Ini adalah taktik dekonstruksi bahasa hukum yang sama tajamnya dengan Surat Perjanjian Kerjasama Vendor Anti Penipuan.

Mengawinkan TOR dengan RAB (Owner Estimate)

TOR yang hebat adalah dokumen yang bisa langsung diterjemahkan menjadi angka rupiah. Jangan pernah melempar TOR ke publik tanpa Anda sendiri membuat Rencana Anggaran Biaya (RAB) internal atau Owner Estimate (OE).

Setiap item peluru di bagian Ruang Lingkup (Scope) TOR harus memiliki harga bayangannya di dokumen OE rahasia Anda. Jika di TOR Anda meminta “Modul Keamanan Enkripsi Database”, Anda harus sudah meriset bahwa harga wajar modul itu di pasaran adalah sekitar 15 juta rupiah.

Mengapa ini krusial? Saat 5 vendor memasukkan penawaran harga (Quotation), Anda tidak akan tertipu. Jika ada vendor yang menawar 5 juta, Anda tahu persis mereka akan memotong kualitas enkripsi tersebut. Jika mereka menawar 40 juta, Anda tahu mereka sedang memeras (Mark-up) perusahaan Anda. TOR mengendalikan kualitas, dan OE mengendalikan uang. Keduanya adalah saudara kembar yang tidak boleh dipisahkan saat Anda melakukan pembedahan (Autopsi) proposal vendor di meja negosiasi.

Sisi Gelap Vendor: Membajak TOR Klien untuk “Lock-In”

Sebagai praktisi sepuluh tahun, saya harus memperingatkan Anda tentang taktik kotor “Pre-Sales” yang sering dilakukan vendor raksasa. Seringkali, perusahaan (Klien) yang kebingungan menyusun TOR akan meminta bantuan dari salah satu vendor langganan mereka untuk “Tolong buatkan draf spesifikasi awalnya”.

Ini adalah jebakan maut. Vendor tersebut akan dengan senang hati membuatkan TOR gratis yang terlihat sangat profesional. TAPI, mereka akan menyisipkan 1 atau 2 baris syarat teknis yang sangat spesifik dan aneh, yang kebetulan HANYA BISA dipenuhi oleh teknologi/lisensi eksklusif milik perusahaan mereka sendiri (Vendor Lock-in). Ketika TOR tersebut dijadikan dokumen tender resmi, 10 vendor kompetitor lain otomatis akan gugur secara administratif karena tidak bisa memenuhi syarat “gaib” tersebut. Vendor pertama tadi menang tender dengan mudah (Tender Arisan). Jangan pernah membiarkan peserta tender memegang pena untuk menulis aturan main tender tersebut.

Sya masih emosi kadang kalo nginget kasus taun 2022 di sebuah pabrik tekstil di Karawang. Direkturnya ngamuk ke vendor software gara gara aplikasi absensi wajah (Face Recognition) yang baru dipasang ga bisa ngebaca wajah karyawan yang lagi pake masker sama helm proyek. Si vendor dengan entengnya bilang, “Lho Pak, di dokumen TOR awal cuma ditulis Sistem Absensi Kamera Wajah Cepat, ga ada satupun tulisan harus nembus masker industri.” Pas sya disuruh ngaudit dokumen TOR mereka, emang bener. Dokumennya cuma dibikin dua lembar doang sama staf HRD pabrik yang ga paham IT sama sekali. Bahasanya kek anak SD ngarang bebas. Disitu sya bilang ke direkturnya, “Pak, di pengadilan B2B, lu ga bisa nuntut hal yang ga tertulis. Vendor bukan dukun yang bisa baca pikiran lu.” Hari itu juga kontraknya kita putus, bayar denda, dan sya susun ulang TOR baru yang setebel 12 halaman. Isinya ngatur sampe resolusi pixel minimal kamera dan tingkat toleransi error akurasi algoritma. Lu mau main di liga Enterprise? Lu harus nulis dokumen sekaku besi beton, jangan lembek kek agar agar.

Pertanyaan Kritis Spesifikasi Pengadaan (FAQ)

Apakah dokumen TOR harus disahkan oleh Notaris agar memiliki kekuatan hukum?

Tidak perlu. TOR (Term of Reference) pada dasarnya adalah lampiran teknis (Technical Attachment). Kekuatan hukumnya muncul HANYA KETIKA TOR tersebut dilampirkan dan disebut secara eksplisit (Dilekatkan) di dalam batang tubuh Surat Perintah Kerja (SPK) atau Surat Perjanjian Kerjasama (Kontrak Utama) yang ditandatangani oleh kedua Direktur di atas materai. Selama ia melekat pada kontrak, TOR bersifat mengikat secara legal (Legally Binding).

Bagaimana jika di tengah proyek berjalan, Klien ingin menambahkan fitur baru yang tidak ada di TOR awal?

Dilarang keras memaksa vendor mengerjakan fitur tambahan tanpa mekanisme resmi, karena itu adalah pelanggaran lingkup (Scope Creep). Solusi profesionalnya adalah Anda (Klien) harus menerbitkan dokumen Change Request (Form Permintaan Perubahan). Vendor akan merespons form tersebut dengan penawaran waktu tambahan dan biaya tambahan (Additional Cost). Jika disepakati, baru dibuatkan Adendum (Perubahan Kontrak). Hukum fisika proyek: Fitur bertambah, maka biaya atau waktu MUTLAK harus ikut bertambah.

Di mana saya bisa mengunduh format draf standar TOR untuk modifikasi infrastruktur IT?

Anda tidak boleh menggunakan format generik dari Google mentah-mentah, karena spesifikasi server dan interior sangat berbeda pendekatannya. Namun, untuk kerangka struktural (Outline) tingkat korporat, kami telah menyusun draf absolut yang biasa digunakan untuk mengunci vendor B2B. Silakan gunakan format dasar ini dan modifikasi sesuai dengan batasan lingkup (Out of Scope) proyek spesifik Anda.