Apa itu Cara Mencatat Risalah Rapat dalam Pengembangan Sistem dari Perspektif Hukum

Ketika sebuah perusahaan mendelegasikan pengembangan sistem ke perusahaan lain, seringkali kasusnya adalah bahwa kontrak yang disepakati dengan cap perusahaan dari direktur utama dan dokumen definisi persyaratan yang dibuat oleh manajer tidak selalu jelas tentang apa yang harus dibuat dan sampai kapan. Hal ini karena dalam banyak pengembangan sistem, spesifikasi yang awalnya tidak jelas ditentukan melalui pertukaran email dan telepon di tingkat staf, dan perubahan spesifikasi yang disesuaikan dengan perubahan situasi, permintaan penambahan fungsi, dan permintaan kerjasama terkait masalah yang muncul, semuanya dilakukan setiap hari dalam pertemuan yang dipimpin oleh manajer.

Dari perspektif memperlancar pengembangan sistem dan mempersiapkan diri untuk kemungkinan sengketa, penting untuk membuat dan mengelola dokumen untuk memperlancar jalannya proyek pengembangan sistem.

Artikel ini akan menjelaskan cara menyimpan catatan rapat dan materi rapat yang digunakan dalam rapat kemajuan pengembangan sistem dari perspektif hukum.

Mengapa Manajemen Dokumen Penting dalam Pengembangan Sistem

Dalam proyek pengembangan sistem, sangat penting untuk mencatat isi pertukaran dalam pertemuan konfirmasi, serta kemajuan dan latar belakang proyek, bahkan dari sudut pandang hukum. Alasan untuk ini dapat dijelaskan dalam dua poin berikut.

Untuk Mencegah Perselisihan di Masa Depan

Pengembangan sistem biasanya melibatkan banyak pihak, baik dari sisi pengguna maupun vendor. Oleh karena itu, jika ada ketidaksesuaian dalam pemahaman antara pengguna dan vendor tentang sejauh mana peran masing-masing dan apa yang mereka terima sebagai kewajiban, hal ini dapat menghambat kemajuan proyek di masa depan.

Lebih lanjut, fakta bahwa banyak orang terlibat dalam proyek dapat berarti bahwa “apa yang dikatakan oleh setiap orang sedikit berbeda, dan tidak jelas siapa yang benar”, yang dapat dengan mudah menimbulkan masalah komunikasi.

Dalam arti memastikan tidak ada ketidaksesuaian dalam pemahaman antara kedua belah pihak, sangat bermanfaat untuk merangkum isi kesepakatan yang telah dibentuk dalam bentuk tulisan, dan juga mengumpulkan materi yang dapat diperiksa oleh semua pihak yang terlibat (pada waktu masing-masing) akan membantu untuk menyelaraskan langkah-langkah semua pihak yang terlibat.

Sebagai catatan, menggunakan pengetahuan hukum sebagai cara untuk mencegah terjadinya konflik sebelumnya juga sering disebut sebagai manajemen hukum preventif.

Sebagai Langkah Jika Terjadi Sengketa di Masa Depan

Selain itu, jika kita menjelaskan pentingnya manajemen dokumen dari sudut pandang yang sedikit berbeda dari manajemen hukum preventif yang disebutkan sebelumnya, kita juga dapat menyebut “manajemen krisis” dalam konteks mengantisipasi situasi di mana konflik sebenarnya terjadi.

Misalkan ada beberapa masalah dan proyek dihentikan sebelum hasil akhir selesai, atau jika tidak memenuhi tenggat waktu awal, mari kita bayangkan situasi di mana hal itu berubah menjadi masalah hukum. Baik dari sisi pengguna maupun vendor, meskipun mereka mungkin mengatakan, “Ada alasan untuk apa yang terjadi,” jika catatan tidak dibuat dalam bentuk tulisan, mereka tidak akan dapat membuktikan klaim mereka dan mungkin dirugikan dalam persidangan.

Khususnya dalam masalah yang timbul dari “tidak memenuhi tenggat waktu,” titik-titik penting seperti “kapan dan bagaimana masalah ditemukan,” “kapan permintaan untuk perubahan spesifikasi diajukan,” dan “bagaimana vendor mencoba menanggapi permintaan tambahan fungsi dari pengguna” sering menjadi titik kunci yang dapat mempengaruhi hasil persidangan. Jika banyak masalah “saya mengatakannya, saya tidak” muncul dalam situasi ini, akan sulit untuk mengharapkan penyelesaian konflik yang adil.

Apa yang Penting dalam Catatan Rapat Pengembangan Sistem?

Jenis Rapat dalam Pengembangan Sistem

Dalam proyek pengembangan sistem, berbagai jenis rapat seringkali direncanakan dan dilakukan. Hal ini tidaklah mengherankan, mengingat banyaknya orang yang terlibat dalam proyek tersebut. Banyak programmer dan insinyur yang melakukan implementasi program di lapangan juga sering mengadakan rapat untuk memeriksa kemajuan pekerjaan. Selain itu, mereka juga mungkin melakukan review kode yang telah diimplementasikan untuk memastikan tidak ada masalah seperti kerentanan dalam hal pemeliharaan dan keamanan.

Lebih jauh lagi, tidak hanya rapat pada tingkat pelaksana, tetapi juga rapat di mana direktur perusahaan dan orang-orang yang memiliki otoritas berkumpul. Dalam kasus ini, rapat seringkali berfokus pada arah dan kebijakan keseluruhan proyek pengembangan. Rapat pada tingkat ini, yang bertujuan untuk “mengendalikan” masalah penting, sering disebut sebagai Steering Committee.

Rapat yang Perlu Diperhatikan Adalah Steering Committee

Seperti yang telah disebutkan sebelumnya, berbagai jenis rapat direncanakan di tempat pengembangan sistem, tergantung pada posisi dan tujuan orang yang terlibat. Namun, dari sudut pandang hukum, rapat yang harus diperhatikan adalah Steering Committee. Dibandingkan dengan rapat pengecekan kemajuan dan rapat review pada tingkat pelaksana, Steering Committee sangat penting dalam hal pencegahan berbagai konflik dan strategi penanganan saat konflik terjadi, dan pentingnya dokumentasi harus diakui dengan baik. Alasan mengapa hal ini penting adalah:

1. Steering Committee adalah rapat yang diselenggarakan oleh orang-orang pada tingkat manajemen, dan seringkali menjadi rapat yang terkait dengan pengambilan keputusan penting. Oleh karena itu, rapat ini cenderung diperhatikan secara hukum sebagai indikator bagaimana pengakuan kedua belah pihak, pengguna dan vendor.
2. Untuk rapat pada tingkat pelaksana, biasanya isi rapat tersebut akan tercermin dalam berbagai dokumen desain dan spesifikasi. Oleh karena itu, masalah seperti “kekurangan dokumentasi” jarang terjadi dalam praktiknya. (Namun, jika dokumentasi untuk hal-hal ini juga kurang, perbaikan mungkin diperlukan.)

Itulah beberapa poin yang dapat diangkat.

Contoh Kasus Pengadilan yang Berkaitan dengan Risalah Rapat Komite Pengarah

Berikut ini, kami akan memperkenalkan satu kasus di mana risalah rapat dalam Komite Pengarah dianggap sebagai bukti penting dalam pengadilan. Kasus yang dikutip dalam putusan pengadilan di bawah ini adalah tentang proyek pengembangan sistem yang gagal di tengah jalan, dan pelanggaran kewajiban manajemen proyek oleh pihak vendor diakui. Konten risalah rapat dalam hal ini memiliki arti yang sangat besar dalam pengadilan sebagai penunjuk pemahaman awal masing-masing pihak vendor dan pengguna.

Vendor, berdasarkan risalah rapat Komite Pengarah, menunjukkan bahwa isi risalah tersebut telah dimodifikasi oleh pengguna dan tidak selalu mencerminkan realitas pekerjaan. Namun, Komite Pengarah didirikan dengan tujuan membuat keputusan pada tingkat manajemen senior dalam pengembangan sistem ini, dan manajer yang bertanggung jawab atas pengembangan sistem ini berpartisipasi dari kedua belah pihak, vendor dan pengguna, dan melakukan evaluasi keseluruhan, pembagian hasil dan masalah kemajuan pekerjaan dan jadwal, dan pengambilan keputusan tentang masalah penting. Kemudian, poin-poin yang dibahas di sana direkam oleh vendor dalam bentuk risalah rapat hingga pagi hari kerja setelah pertemuan dan didaftarkan dalam basis data risalah rapat, dan keputusan akhir pertemuan direkam dengan risalah tersebut. Dalam menetapkan risalah, vendor dan pengguna, sambil memahami sepenuhnya arti pencatatan pekerjaan dengan risalah, mempertimbangkan isi dan ekspresinya, dan dapat diasumsikan bahwa mereka telah menetapkan isi yang mencerminkan realitas pertemuan. Khususnya, vendor adalah orang yang menjalankan pengembangan sistem, dan tentu saja mereka sangat memahami arti dan metode pembuatan risalah seperti ini. Oleh karena itu, risalah yang telah ditetapkan harus diperlakukan sebagai mencerminkan realitas pekerjaan Komite Pengarah, dan kecuali ada keadaan khusus, konten pekerjaan yang telah dicatat di sana harus dianggap sebagai sesuatu yang telah diringkas dalam Komite Pengarah pada tanggal tersebut.

Pengadilan Tinggi Tokyo, 26 September Heisei 25 (2013)

Posisi pengadilan tampaknya adalah bahwa jika risalah rapat yang dibuat oleh vendor dan pengguna berdasarkan kesepakatan bersama, itu dapat diharapkan memiliki kekuatan presumsi tertentu sebagai “bukti”. Dari sudut pandang lain, jika Anda mencatat terlalu mudah dalam risalah, ada risiko bahwa itu akan menjadi bukti sebagaimana adanya, dan Anda harus berhati-hati dengan hal ini.

Apa Saja Item Spesifik yang Harus Dicatat dalam Risalah Rapat

Risalah rapat memiliki arti penting sebagai bukti dalam kasus pengadilan, dan juga penting untuk memfasilitasi negosiasi berikutnya antara pihak-pihak yang terlibat, bahkan jika tidak ada pengadilan. Lalu, apa yang harus didokumentasikan dan dicatat dalam risalah rapat? Mari kita uraikan di bawah ini.

Hal-hal yang Harus Dicatat dari Perspektif Pihak Vendor

Pihak vendor memiliki kewajiban manajemen proyek sebagai ahli pengembangan sistem dalam proyek. Artikel berikut menjelaskan secara detail tentang kewajiban ini.

https://monolith.law/corporate/project-management-duties[ja]

Mengingat kewajiban tersebut, hal-hal yang harus dicatat oleh pihak vendor adalah:

1. Fakta dan tanggal penyelesaian setiap tahap pengembangan
2. Riwayat bagaimana mereka merespons permintaan perubahan spesifikasi atau penambahan fungsi dari pihak pengguna
3. Langkah-langkah yang telah diambil untuk meminta kerjasama ketika kemajuan pekerjaan pengembangan terhambat karena alasan pribadi pihak pengguna, dan latar belakangnya

Beberapa hal yang dapat disebutkan di atas.

Sebagai tambahan, artikel berikut menjelaskan hal-hal yang harus dipertimbangkan oleh pihak vendor jika pihak pengguna tidak melakukan penerimaan. Artikel ini menjelaskan bagaimana putusan pengadilan dapat berubah secara signifikan tergantung pada sejauh mana pihak vendor bekerja sama untuk melaksanakan penerimaan pengguna, dengan mengutip teks putusan aktual.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Hal-hal yang Harus Dicatat dari Perspektif Pihak Pengguna

Tentu saja, pengguna juga memiliki kewajiban untuk bekerja sama dalam pengembangan sistem yang akan digunakan di dalam perusahaan mereka. Artikel berikut menjelaskan secara keseluruhan tentang kewajiban ini.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

1. Riwayat tentang apa yang harus diberitahukan oleh pihak pengguna kepada pihak vendor, seperti fungsi yang diinginkan, tampilan layar, dll.
2. Riwayat berbagai masalah yang muncul dalam proses kerja pihak vendor (misalnya, keberangkatan mendadak anggota atau keterlambatan jadwal proses pengembangan yang disebabkan oleh kurangnya penelitian oleh pihak vendor dan penyebabnya)

Sehubungan dengan poin 2 di atas, situasi yang paling mungkin berkembang menjadi masalah yang tidak terduga adalah ketika pengembangan sistem baru dilakukan bersamaan dengan penghapusan sistem lama. Masalah sering terjadi saat memindahkan data dari sistem lama ke sistem baru, dan artikel berikut menjelaskan secara detail tentang masalah hukum yang terkait dengan masalah ini.

Kesimpulan

Itulah panduan tentang cara mencatat risalah rapat dalam pengembangan sistem dari sudut pandang hukum. Selain pengetahuan praktis, penting juga untuk memahami hubungan antara tema-tema seperti ‘hukum’, ‘pengembangan sistem’, dan ‘manajemen dokumen’. Mengingat pengembangan sistem sering melibatkan banyak individu dan organisasi dan mudah berkembang menjadi transaksi komersial berskala besar, maka pencegahan dan penanganan konflik yang mungkin muncul menjadi sangat penting. Dari sudut pandang hukum, keberadaan ‘dokumen’ yang dapat diverifikasi secara objektif oleh siapa pun memiliki arti yang sangat penting dalam hal pemeliharaan bukti.

Memang, mengubah semua interaksi dan perkembangan proyek menjadi bahasa tertulis bisa menjadi beban yang besar dan mungkin tidak realistis. Namun, penting untuk menentukan apa yang penting dari sudut pandang hukum dan mendokumentasikan hal-hal penting tersebut secara tepat. Hal ini seharusnya diakui secara luas oleh semua orang yang terlibat dalam bisnis, baik mereka adalah ahli hukum atau bukan.