Apa itu statement of work (SOW)? Panduan kontrak jasa

Apa itu statement of work (SOW)? Statement of work, biasa disingkat SOW, adalah bagian dari kontrak jasa yang menjelaskan secara rinci apa yang akan diserahkan, kapan, oleh siapa, dan dengan biaya berapa. Jika Anda bertanya apa itu statement of work, anggap saja ini dokumen tingkat proyek yang berada di bawah ketentuan hukum. Dalam praktiknya, sebagian besar sengketa berjudul "ini bukan yang kita sepakati" dimenangkan atau kalah di dokumen inilah.

Apa saja isi sebuah statement of work?

SOW menjelaskan satu pekerjaan tertentu. Ia tidak berusaha mencakup seluruh hubungan antara dua perusahaan. SOW yang disusun dengan baik biasanya memuat blok inti yang sama.

• Ruang lingkup pekerjaan: apa yang akan dilakukan penyedia jasa, dengan kata kerja yang jelas, dan apa yang tidak akan dilakukannya.

• Deliverables: hasil konkret, misalnya database yang sudah dimigrasikan, panduan merek, atau 40 jam dukungan.

• Jadwal dan milestone: tanggal atau durasi yang terikat pada deliverables, bukan "akhir kuartal" yang samar.

• Biaya dan jadwal pembayaran: harga tetap, time and materials, atau kombinasi keduanya, beserta pemicu invoice.

• Kriteria penerimaan: cara pihak klien memutuskan bahwa sebuah deliverable sudah selesai.

• Peran dan ketergantungan: siapa yang menyediakan akses, data, persetujuan, atau lingkungan uji, dan kapan.

• Proses perubahan: cara ruang lingkup, harga, atau tanggal diubah setelah pekerjaan dimulai.

Inilah yang sebenarnya dikatakan struktur ini: SOW mengubah ide kesepakatan lisan menjadi sesuatu yang bisa dibaca dan diverifikasi oleh pihak ketiga. Pihak ketiga itu sering kali hakim, auditor, atau rekan baru yang mewarisi proyek tersebut.

Apa bedanya SOW dengan MSA, proposal, atau purchase order?

Kebingungan biasanya muncul dari dokumen-dokumen yang tampak mirip dan berdekatan dalam satu kesepakatan.

Master services agreement (MSA) memuat ketentuan hukum yang berlaku umum: tanggung jawab, kekayaan intelektual, kerahasiaan, perlindungan data, pengakhiran, dan hukum yang mengatur. MSA ditandatangani sekali. Setiap SOW kemudian menempel padanya dan mencakup satu proyek. Satu MSA bisa menaungi belasan SOW selama beberapa tahun.

Proposal adalah dokumen penjualan. Ia menjelaskan apa yang ingin dilakukan penyedia jasa dan mengapa Anda sebaiknya memilih mereka. Proposal biasanya tidak mengikat, dan sering dipakai ulang sebagai draf pertama SOW. Di situlah masalah dimulai, karena bahasa pemasaran berakhir di dalam kontrak.

Purchase order adalah otorisasi pembayaran. Ia mencantumkan harga dan jumlah, jarang ruang lingkupnya. Hanya mengandalkan purchase order untuk proyek jasa berarti pekerjaannya tidak terdefinisi.

Untuk pekerjaan sekali jalan, satu perjanjian gabungan dengan SOW sebagai lampiran bisa saja sudah cukup. Pemisahan antara MSA dan SOW baru terasa manfaatnya ketika Anda akan terus membeli dari penyedia yang sama.

Setiap kali SOW baru dibuat, periksa juga apakah MSA yang menaunginya masih berlaku dan sudah mencakup layanan yang akan dikerjakan. SOW yang berdiri di atas MSA yang belum diperbarui sering kali menyimpan celah yang baru terlihat ketika proyek sudah berjalan.

Dokumen mana yang menang jika MSA dan SOW bertentangan?

Ini pertanyaan yang paling sering dilewatkan, dan justru di sinilah uang paling sering hilang.

Sebagian besar perjanjian yang disusun dengan hati-hati mengikuti pola sederhana. MSA mengatur ketentuan hukum. SOW mengatur ruang lingkup, jadwal, dan biaya. Klausul urutan prioritas (order of precedence) menyatakan hal itu dalam satu atau dua kalimat dan menyebut dokumen mana yang berlaku jika keduanya bertentangan.

Tanpa klausul itu, Anda bergantung pada cara pengadilan membaca dokumen-dokumen tersebut sebagai satu kesatuan. Di bawah hukum Inggris, misalnya, dokumen kontrak umumnya dibaca sebagai satu perjanjian, sehingga inkonsistensi tidak otomatis saling meniadakan. Ia melahirkan perdebatan, dan perdebatan itu berbiaya.

Berikut contoh redaksi yang perlu dicari, sebagai contoh penyusunan dan bukan nasihat untuk yurisdiksi Anda:

§ Jika terjadi konflik, ketentuan MSA berlaku atas SOW, kecuali bahwa SOW berlaku untuk ruang lingkup, deliverables, jadwal, dan biaya bagi proyek yang dijelaskannya.

Ada satu jebakan yang perlu diwaspadai. SOW yang diam-diam mengesampingkan batas tanggung jawab atau klausul kepemilikan IP "untuk proyek ini saja" sah jika kedua pihak memang menghendakinya. Masalahnya muncul ketika tidak ada yang menyadarinya. Siapa pun yang menandatangani SOW harus membacanya sebagai kontrak, bukan sebagai rencana proyek.

Seperti apa bahasa ruang lingkup yang tahan uji?

Ruang lingkup adalah tempat SOW paling sering gagal. Ruang lingkup yang kabur tidak netral: ia menguntungkan pihak yang lebih siap berdebat di kemudian hari, dan biasanya itu pihak yang punya daya tawar lebih besar.

Ada tiga kebiasaan yang membuat ruang lingkup tetap kokoh.

Pertama, tulis pengecualian. Daftar hal yang tidak termasuk sering lebih berguna daripada daftar hal yang termasuk. Kalimat seperti "Tidak termasuk integrasi dengan sistem penagihan lama milik klien" menyelesaikan percakapan yang jika tidak akan memakan tiga kali rapat.

Kedua, kaitkan deliverables dengan kata benda, bukan kata sifat. "Website yang responsif" bisa diperdebatkan. "Delapan template, diuji pada dua versi terbaru dari empat browser yang disebutkan namanya" bisa diperiksa.

Ketiga, nyatakan asumsi. Jika jadwal bergantung pada klien yang memberi umpan balik dalam lima hari kerja, tuliskan itu, dan tuliskan juga apa yang terjadi pada jadwal jika mereka tidak melakukannya. Klaim keterlambatan jauh lebih mudah dibela ketika ketergantungannya sudah tertulis.

Hindari godaan menyalin templat lalu mengisi bagian kosong. Templat memperlihatkan judul-judulnya, tetapi tidak bisa memberi tahu asumsi mana yang spesifik untuk proyek Anda.

Bagaimana penerimaan dan permintaan perubahan sebaiknya ditulis?

Kriteria penerimaan menjawab satu pertanyaan: kapan sebuah deliverable cukup selesai untuk dibayar? "Berkualitas tinggi" dan "memuaskan klien" tidak menjawabnya. Kriteria yang bisa diuji menjawabnya. Untuk migrasi data, misalnya, bunyinya bisa "seluruh rekaman telah dipindahkan dan laporan rekonsiliasi tidak menunjukkan selisih yang tidak dijelaskan".

Tambahkan mekanisme penerimaan otomatis (deemed acceptance). Pola yang umum adalah deliverable dianggap diterima jika klien tidak mengirim kekurangan secara tertulis dalam jangka waktu tertentu, sering kali sekitar sepuluh hari kerja. Tanpa mekanisme ini, klien bisa menunda persetujuan, dan tagihan terakhir ikut tertunda tanpa batas. Jika Anda klien, dorong adanya masa perbaikan yang jelas bagi penyedia jasa untuk memperbaiki apa yang Anda laporkan, sehingga waktunya adil bagi kedua belah pihak.

Permintaan perubahan layak mendapat perhatian yang sama. Scope creep jarang datang sebagai satu permintaan besar. Ia datang sebagai sepuluh permintaan kecil yang masing-masing tampak wajar. Satu paragraf proses perubahan bisa mencegahnya: setiap perubahan ruang lingkup, harga, atau tanggal memerlukan change order tertulis yang ditandatangani kedua pihak sebelum pekerjaan dimulai. Banyak penyedia jasa kehilangan margin karena SOW mereka memungkinkan kesepakatan lisan.

Harga tetap atau time and materials: mana yang cocok untuk SOW?

Bagian harga mengubah cara risiko dibagi, jadi pilihlah dengan sengaja.

Harga tetap memindahkan risiko pengerjaan ke penyedia jasa. Cara ini cocok ketika ruang lingkup sudah dipahami dengan baik dan kecil kemungkinan berubah. Cara ini berjalan buruk ketika ruang lingkup masih kabur, karena penyedia jasa akan menambahkan bantalan harga atau berdebat di setiap perubahan.

Time and materials memindahkan risiko usaha ke klien. Cara ini cocok untuk pekerjaan eksploratif, tetapi perlu batas atas atau angka not-to-exceed. Tanpa itu, anggaran hanyalah sebuah opini.

Model hibrida, dengan harga tetap per milestone, sering menjadi kompromi yang paling jujur. Setiap milestone memiliki deliverable, uji penerimaan, dan invoice sendiri, sehingga SOW mudah diaudit dan mudah dihentikan jika proyek menyimpang.

Apa pun pilihannya, samakan dasar perhitungan biaya dengan cara Anda menagih sejak awal. Jika tagihan dihitung per jam tetapi deliverable diukur per milestone, kedua pihak bisa membaca kontrak yang sama dengan dua cara yang berbeda. Tuliskan juga satu contoh perhitungan di dalam SOW supaya angkanya tidak perlu ditebak.

Di mana orang paling sering keliru saat menandatangani SOW?

Setelah membaca banyak dokumen seperti ini, kegagalan yang sama terus muncul.

• Menandatangani SOW sebelum MSA ada, sehingga proyek berjalan tanpa ketentuan tanggung jawab atau IP sama sekali.

• Membiarkan tanggal sebagai "sekitar" tanpa konsekuensi jika terlewat.

• Mendeskripsikan deliverable berdasarkan aktivitas ("menyediakan dukungan") alih-alih hasil ("menanggapi tiket prioritas dalam empat jam kerja").

• Melupakan perlindungan data ketika penyedia jasa akan menangani data pribadi. Di Uni Eropa dan Inggris, itu biasanya berarti perjanjian pemrosesan data menyertai SOW, dan detail yang tepat bergantung pada yurisdiksi yang terlibat.

• Tidak memperbarui SOW setelah perubahan lisan, lalu mengandalkan ingatan setahun kemudian.

Ini bukan risiko teoretis. Ini yang rutin dilihat para pengacara. Tidak satu pun dari hal ini membutuhkan kejeniusan hukum untuk dihindari. Yang dibutuhkan hanyalah seseorang yang membaca dokumen itu perlahan sebelum menandatangani.

Alat apa yang membantu menyusun, menandatangani, dan meninjau SOW?

Alat tidak akan menulis ruang lingkup yang baik untuk Anda, tetapi alat bisa menghilangkan pekerjaan berulang di sekitarnya.

Untuk menyusun dokumen dari blok yang bisa dipakai ulang, dengan persetujuan dan tanda tangan elektronik dalam satu alur, platform dokumen cukup praktis.

Jika Anda hanya butuh tanda tangan, dengan jejak audit dan penerimaan yang luas di kalangan pihak lawan, layanan tanda tangan elektronik khusus sudah cukup.

Untuk tim yang menangani banyak SOW setiap tahun dan perlu mengaitkannya dengan MSA, platform contract lifecycle menjaga hubungan antara ketentuan induk dan setiap dokumen proyek.

Untuk peninjauan awal risiko klausul di dalam Word, add-in peninjauan berbasis AI dapat menandai eksklusi yang hilang atau klausul tanggung jawab yang bertentangan sebelum manusia membacanya.

Tidak ada satu pun alat ini yang menggantikan pengacara ketika taruhannya tinggi. Gunakan perangkat lunak untuk menangkap masalah rutin, lalu bawa hal yang tidak biasa, bernilai besar, atau lintas negara ke penasihat hukum Anda.

Apa yang perlu dilakukan sebelum menandatangani SOW berikutnya?

Tiga langkah ini menutup sebagian besar risiko.

1. Pastikan MSA sudah ada, dan SOW menyatakan dokumen mana yang berlaku untuk ketentuan hukum dibanding ruang lingkup dan biaya.

2. Tulis ulang setiap deliverable agar orang asing bisa memastikan, ya atau tidak, apakah ia sudah diserahkan, lalu tambahkan pengecualian dan asumsi.

3. Pastikan jangka waktu penerimaan, masa perbaikan, dan aturan change order tertulis, lalu lampirkan setiap amandemen pada SOW itu sendiri.

Jika proyeknya besar, melibatkan data pribadi, atau lintas negara, minta penasihat hukum Anda membacanya. Jawabannya akan bergantung pada hukum yang mengatur, dan tinjauan singkat jauh lebih murah daripada sengketa.