Ruang lingkup layanan yang jelas tanpa keraguan: 10 unsur agar klien tahu apa yang dibelinya

Federal Acquisition Regulation Amerika Serikat yang berlaku untuk layanan berbasis kinerja menganjurkan agar pekerjaan terutama dijelaskan melalui hasil yang diperlukan, bukan dengan menentukan secara rinci bagaimana pekerjaan harus dilakukan atau hanya menyebut jumlah jam. Aturan itu juga merujuk pada standar kinerja yang dapat diukur dan, dalam pernyataan tujuan, mencantumkan unsur seperti tujuan, cakupan, periode dan tempat pelaksanaan, latar belakang, hasil yang diperlukan, serta batasan operasional. [1]

Digital, Data and Technology Playbook Pemerintah Inggris juga mendorong spesifikasi yang jelas dan berorientasi pada hasil. Panduan tersebut secara tegas menyarankan fokus pada pengguna dan masalah yang perlu diselesaikan, bukan menetapkan solusi teknis sejak awal. [2]

Panduan Inggris terkini tentang alokasi risiko dan pendekatan harga juga menyatakan bahwa ukuran kinerja harus dapat diukur dan objektif, serta pemasok harus dimintai pertanggungjawaban atas hasil yang benar-benar dapat mereka pengaruhi. [3]

Sumber-sumber ini berasal dari pengadaan publik dan bukan templat universal untuk semua layanan. Namun, sumber tersebut menunjukkan prinsip yang sangat berguna: cakupan yang baik harus menyebut hasil yang diharapkan, cara menilainya, dan batas tanggung jawab.

Deskripsi yang baik harus sekaligus membantu:

Klien - memahami apa yang akan diterima, apa yang tidak akan diterima, dan apa yang dibutuhkan dari pihaknya.

Spesialis - menetapkan batas tanggung jawab, asumsi, dan titik ketika permintaan baru menjadi perubahan cakupan.

Kedua pihak - menyepakati cara yang wajar untuk menentukan bahwa pekerjaan yang disepakati telah selesai.

Jika deskripsi hanya menjalankan salah satu fungsi ini dengan baik, masih dapat tersisa banyak ruang untuk perselisihan atau penafsiran yang berbeda.

Mulailah dengan menjelaskan mengapa layanan tersebut dibutuhkan.

Jangan mulai dengan daftar alat atau aktivitas jika klien belum memahami tujuannya.

Daripada:

"Konfigurasi analitik, laporan, dan peristiwa."

lebih baik:

"Tujuannya adalah memperoleh data yang dapat dipercaya mengenai tahapan formulir tempat pengguna paling sering berhenti, sehingga tim dapat mengidentifikasi bagian yang perlu diperbaiki."

Pendekatan ini sesuai dengan prinsip menjelaskan kebutuhan dan hasil, bukan memaksakan solusi, sebagaimana dianjurkan dalam Digital, Data and Technology Playbook Inggris. [2]

Tujuan menjawab "mengapa?", sedangkan hasil menjawab "apa yang harus ada atau menjadi benar ketika pekerjaan selesai?"

Hasil dapat berupa:

• dokumen yang selesai,
• fitur yang berfungsi,
• konfigurasi yang sudah diterapkan,
• penelitian yang selesai beserta kesimpulannya,
• sekumpulan materi yang sudah disiapkan,
• sesi yang sudah dilaksanakan dengan ringkasan yang ditentukan.

Untuk layanan berbasis kinerja, FAR menjelaskan kebutuhan terutama melalui hasil yang diperlukan, bukan hanya cara pekerjaan dilakukan. [1]

Ini tidak berarti setiap layanan harus menjamin hasil bisnis yang tidak dapat dikendalikan oleh spesialis. Spesialis dapat berkomitmen untuk meluncurkan kampanye sesuai cakupan yang disepakati, tetapi jaminan kenaikan penjualan 30% dapat bergantung pada banyak faktor di luar kendali penyedia.

Cakupan harus menyebut bagian pekerjaan yang secara nyata termasuk dalam kesepakatan.

Dalam proyek situs web, misalnya, dapat mencakup:

• analisis situs saat ini,
• penyusunan arsitektur informasi,
• desain sejumlah tampilan yang telah ditentukan,
• versi perangkat seluler,
• penerapan desain yang telah disetujui,
• dokumentasi serah terima dasar.

Tujuannya bukan membuat daftar sepanjang mungkin. Tujuannya adalah menyebut unsur utama yang memengaruhi beban kerja dan harapan sebelum pekerjaan dimulai.

Cakupan menjelaskan pekerjaan, sedangkan hasil serahan menjelaskan apa yang benar-benar diterima klien.

Contohnya:

• berkas sumber,
• laporan dalam format tertentu,
• modul yang berfungsi,
• repositori kode,
• sekumpulan materi grafis,
• rekaman,
• dokumentasi,
• daftar rekomendasi,
• akses ke lingkungan yang sudah dikonfigurasi.

Jika bentuk hasil penting, sebutkan. "Laporan" dapat berarti dua halaman teks atau dokumen terperinci dengan analisis, prioritas, dan contoh. Nama saja tidak selalu cukup.

Kriteria penerimaan menjawab pertanyaan: bagaimana para pihak dapat menentukan bahwa hasil yang disepakati telah diserahkan sesuai persyaratan?

Kriteria dapat berkaitan dengan:

• kelengkapan,
• kesesuaian dengan spesifikasi yang disepakati,
• format tertentu,
• fungsi pada perangkat atau lingkungan yang ditentukan,
• jumlah maksimum kesalahan dalam kategori tertentu,
• waktu penyelesaian,
• parameter mutu yang ditetapkan.

FAR mensyaratkan agar standar kinerja dalam kontrak layanan berbasis kinerja dapat diukur dan disusun sehingga kinerja dapat dinilai. [1]

Panduan Inggris tentang risiko juga menyatakan bahwa ukuran harus objektif dan berkaitan dengan hasil yang dapat dipengaruhi pemasok. [3]

Karena itu, "klien akan puas" jauh kurang berguna dibanding kriteria yang terhubung dengan hasil tertentu yang dapat diamati.

Layanan sering bergantung pada tindakan pihak lain.

Sebaiknya dinyatakan apakah klien harus menyediakan:

• akses ke sistem,
• konten atau materi,
• data,
• informasi merek,
• keputusan dan persetujuan,
• orang penghubung,
• lingkungan pengujian,
• tanggapan dalam waktu tertentu.

Jika kurangnya masukan dari klien dapat menghentikan pekerjaan, hal itu harus jelas.

Tanggung jawab atas jadwal tidak seharusnya ditulis seolah-olah spesialis mengendalikan tindakan yang sebenarnya berada di luar kendalinya.

Harga dan jadwal sering hanya berlaku jika asumsi tertentu terpenuhi.

Contoh:

• basis data yang ada tersedia dan berfungsi dengan baik,
• klien memiliki hak atas materi yang diberikan,
• sistem eksternal memiliki antarmuka yang berfungsi,
• proyek tidak memerlukan pemindahan data historis,
• jumlah versi bahasa ditetapkan sebelumnya,
• keputusan dibuat oleh satu orang yang ditunjuk.

Panduan GAO tentang estimasi biaya yang dapat dipercaya menempatkan cakupan yang jelas, dasar teknis, aturan dan asumsi, serta analisis risiko dan ketidakpastian sebagai bagian penting dari proses estimasi yang baik. [7]

Layanan kecil tidak perlu menyalin proses yang dibuat untuk program besar. Namun prinsipnya tetap berguna: jika estimasi bergantung pada sesuatu yang mungkin ternyata tidak benar, nyatakan hal itu.

Pengecualian bukan tanda penawaran yang lemah. Sering kali justru menunjukkan bahwa komitmen telah didefinisikan dengan baik.

Jika sesuatu mudah dianggap sebagai bagian dari layanan, sebaiknya dinyatakan secara tegas bahwa hal itu tidak termasuk.

Contoh:

• pembelian lisensi,
• pembuatan konten,
• gambar berbayar,
• terjemahan,
• pemeliharaan setelah peluncuran,
• pekerjaan pada sistem lain,
• revisi tanpa batas,
• biaya layanan pihak ketiga.

Tidak perlu mencantumkan semua hal yang tidak akan dilakukan spesialis. Pengecualian paling berguna adalah hal-hal yang secara realistis mungkin dianggap klien sebagai bagian dari layanan.

Jadwal sebaiknya menjelaskan lebih dari sekadar "sekitar dua minggu" jika kemajuan bergantung pada persetujuan atau materi dari klien.

Sebaiknya jelaskan:

• peristiwa apa yang memulai hitungan waktu,
• apakah ada tahap antara,
• keputusan apa yang menutup setiap tahap,
• berapa lama klien harus merespons jika hal itu memengaruhi jadwal,
• bagaimana keterlambatan dikomunikasikan,
• bagaimana penerimaan akhir dilakukan.

Untuk layanan sederhana, beberapa kalimat dapat cukup. Dalam kerja sama yang lebih besar, tahapan membantu kedua pihak memahami apa yang sudah selesai dan apa yang harus terjadi selanjutnya.

Deskripsi layanan yang baik harus menjelaskan apa yang terjadi jika muncul kebutuhan baru setelah pekerjaan dimulai.

Mekanisme praktis dapat sangat sederhana:

"Pekerjaan di luar cakupan yang dijelaskan memerlukan konfirmasi atas cakupan baru, dampaknya pada jadwal, dan setiap harga tambahan sebelum pekerjaan tersebut dimulai."

Sebaiknya juga dinyatakan dengan jelas:

• model harga,
• harga atau cara menghitungnya,
• aturan pembayaran,
• biaya tambahan yang mungkin muncul,
• aturan untuk putaran revisi tambahan.

Ini tidak menghilangkan perubahan. Ini menjadikan perubahan sebagai keputusan yang disengaja, bukan perluasan tersembunyi dari komitmen awal.

Cakupan yang jelas tidak berarti setiap langkah pekerjaan spesialis harus ditentukan terlebih dahulu.

Digital, Data and Technology Playbook Inggris memperingatkan terhadap penentuan solusi secara berlebihan dan menyatakan bahwa spesifikasi berbasis hasil dapat memberi ruang kepada pemasok untuk mengusulkan cara yang lebih efektif dalam menyelesaikan masalah. [2]

FAR juga mengutamakan penjelasan mengenai hasil yang diperlukan daripada menentukan secara tepat bagaimana pekerjaan harus dilakukan. [1]

Karena itu:

"situs web harus mendukung skenario yang disepakati dengan benar pada perangkat yang ditentukan"

dapat menjadi persyaratan yang lebih baik daripada menentukan detail penerapan jika teknologi itu sendiri bukan batasan penting.

Tentu saja, pada beberapa layanan cara kerja penting karena keamanan, kepatuhan, integrasi, atau standar teknis tertentu. Dalam hal tersebut, cara kerja perlu dijelaskan.

Saat menentukan cakupan, penting untuk membedakan antara:

hasil langsung dari pekerjaan spesialis dan hasil bisnis yang juga bergantung pada faktor lain.

Spesialis dapat berkomitmen untuk:

• menyiapkan dan meluncurkan kampanye dalam cakupan yang disepakati,
• melakukan analisis,
• menyerahkan sejumlah materi yang telah ditentukan,
• menerapkan fungsi yang memenuhi kriteria yang ditetapkan.

Diperlukan kehati-hatian jauh lebih besar terhadap jaminan penjualan, jumlah pelanggan, posisi mesin pencari, atau hasil lain yang bergantung pada pasar, anggaran, produk, tindakan klien, atau sistem eksternal.

Panduan Inggris terkini tentang alokasi risiko secara tegas menyatakan bahwa pemasok seharusnya bertanggung jawab atas hasil yang dapat mereka pengaruhi. [3]

Deskripsi yang baik tidak melemahkan tanggung jawab. Deskripsi menempatkan tanggung jawab di tempat yang memang memiliki kendali.

Tidak setiap layanan memerlukan dokumen beberapa halaman.

Untuk tugas sederhana, seluruh informasi penting dapat dimuat dalam beberapa paragraf. Untuk proyek yang lebih besar, cara berpikir yang sama dapat berkembang menjadi spesifikasi terperinci, jadwal, kriteria penerimaan, dan proses perubahan formal.

Contoh Terms of Reference yang diterbitkan Bank Dunia menyatakan bahwa dokumen tersebut harus menjelaskan dengan jelas kebutuhan layanan konsultasi dan harapan pihak yang mengontrak, serta harus disesuaikan dengan proyek tertentu dan keadaan setempat. [4]

Hal terpenting bukan panjangnya. Pertanyaan utamanya adalah apakah informasi yang hilang dapat secara realistis mengubah harga, jadwal, tanggung jawab, atau hasil yang diharapkan.

Deskripsi layanan pada situs atau profil dapat hanya menjadi satu bagian dari proses pembentukan kontrak. Kewajiban hukum tertentu bergantung pada negara, jenis transaksi, status para pihak, dan cara penjualan.

Dalam hubungan bisnis-ke-konsumen di Uni Eropa, portal resmi Your Europe menyebut informasi sebelum kontrak seperti karakteristik utama layanan, total harga termasuk biaya, pengaturan pembayaran dan pelaksanaan, serta durasi kontrak jika relevan. [5]

Panduan Uni Eropa untuk bisnis juga menyatakan bahwa ketentuan standar kontrak konsumen harus adil dan ditulis dalam bahasa yang jelas serta mudah dipahami sehingga konsumen dapat memahami konsekuensi ekonominya. [6]

Persyaratan ini berlaku pada hubungan konsumen tertentu di Uni Eropa. Persyaratan tersebut tidak boleh otomatis diterapkan pada semua transaksi antarbisnis atau wilayah hukum lain.

Artikel ini adalah panduan editorial tentang cara menjelaskan layanan, bukan templat kontrak atau nasihat hukum.

1. Apakah klien memahami masalah atau tujuan yang ditangani layanan?
2. Apakah hasil akhir sudah disebutkan?
3. Apakah jelas apa yang termasuk dalam cakupan?
4. Apakah klien mengetahui hasil konkret yang akan diterima?
5. Apakah ada cara yang wajar untuk menilai bahwa pekerjaan telah selesai?
6. Apakah jelas apa yang harus disediakan atau ditangani klien?
7. Apakah asumsi terpenting terlihat?
8. Apakah pengecualian yang jelas tetapi berpotensi membingungkan sudah dijelaskan?
9. Apakah jadwal dan tahapan mencerminkan ketergantungan di kedua pihak?
10. Apakah jelas apa yang terjadi ketika cakupan berubah?
11. Apakah harga, model harga, dan biaya tambahan disajikan pada tahap yang tepat?
12. Apakah deskripsi menghindari janji atas hasil yang tidak dapat dikendalikan spesialis?

Ujian terbaik untuk deskripsi yang baik sangat sederhana.

Setelah membacanya, klien dan spesialis seharusnya memberikan jawaban yang kurang lebih sama atas pertanyaan berikut:

Apa yang harus dicapai? Apa yang akan dilakukan? Apa yang akan diterima klien? Apa yang tidak termasuk? Apa yang harus dilakukan klien? Bagaimana kita tahu pekerjaan telah selesai? Apa yang terjadi jika cakupan berubah?

Jika jawabannya selaras, harga dan jadwal memiliki konteks yang jauh lebih baik.

Jika jawabannya berbeda, masalah sering kali tidak dimulai saat pelaksanaan. Masalah sudah dimulai di dalam deskripsi layanan.

[1] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Buka sumber

[2] UK Government - The Digital, Data and Technology Playbook
Buka sumber

[3] UK Government - Risk Allocation and Pricing Approaches Guidance Note
Buka sumber

[4] World Bank - Sample Consultants Terms of Reference
Buka sumber

[5] Your Europe - Contract information: what you should know before buying
Buka sumber

[6] Your Europe - Contracts with consumers
Buka sumber

[7] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Buka sumber

Catatan metodologis: sumber-sumber tersebut memiliki cakupan yang berbeda dan tidak membentuk satu standar umum untuk deskripsi layanan. Artikel ini hanya menggunakan prinsip yang benar-benar didukung: fokus pada hasil, keterukuran, cakupan yang jelas, asumsi, tanggung jawab atas faktor yang berada dalam kendali penyedia, dan transparansi informasi bagi klien.