Assign modules on offcanvas module position to make them visible in the sidebar.

Main Menu

nilai proyek mengkerut

 

Statemen pada judul di atas bukan gurauan. Tetapi merupakan pengalaman nyata yang bahkan bisa dialami oleh siapa saja. Di situ kita melihat bahwa nilai proyek 250 juta bisa menyusut hanya menjadi 150 juta saja. Dalam kasus yang lain, yang perlu dijadikan pegangan di situ adalah prosentasenya. Turun sekitar 40% dari nilai awal. Angka yang saya tuliskan disini sebenarnya riil, namun untuk pembahasan cakupan proyek yang lebih luas, angka nilai proyek bisa dimaknai sebagai simbol untuk memahamkan keadaan secara umum.
 

Apa yang saya ceritakan di sini merupakan pengalaman saya sendiri saat menjalankan usaha di Amanah Solution. Mengapa saya tulis? Ya tentu saja agar bisa kita jadikan sebagai bahan pembelajaran bagi kita semua para proyekker yang memang setiap harinya bergelut dalam dunia proyek.
 
 

Di awal selalu ada komitmen dari Kedua Pihak

Sebagaimana proyek-proyek lain, biasanya di awal kerjasama selalu dimulai dengan perasaan senang dan persahabatan diantara kedua belah pihak.

Pada prosesnya selalu diawali dengan gimana kita menawarkan jasa ke pihak klien/ owner proyek. Tentunya setelah diawali dengan nego-nego dalam beberapa tahapan, dan pada akhirnya setelah itu terjadi deal. Dan saat penandatanganan kerjasama tentunya disertai dengan iktikad baik dari kedua belah pihak. Berdasarkan pengalaman saya yang saya ketahui, hampir tidak ada proyek yang sedari awal tidak ada niatan baik dari kedua belah pihak yang bersepakat. Baru, komitmen terhadap terselesaikannya sebuah proyek dengan baik itu akan terlihat ketika masuk fase penggarapan.

 

Yang paling mencolok yang terjadi di dunia proyek pekerjaan Sistem Informasi adalah di mana di perjalanan penggarapan terjadi perubahan kebutuhan. Proses bisnis sebuah lembaga itu biasanya selalu dinamis/ berubah. Sehingga grand desain yang sudah dirancang di awal dapat berubah karena mengikuti ritme dari transaksi bisnis pada lembaga itu. Awalnya perubahan tersebut hanya sedikit namun lama-lama bisa menjadi banyak seiring dengan semakin “dinikmatinya” oleh pihak owner proses bisnis yang ada di software yang dikerjakan tersebut.
 

Seringnya perubahan sistem transaksional pada software Sistem Informasi yang dibangun adalah merupakan perluasan ruang lingkup. Jarang sekali yang merupakan penyempitan ruang lingkup. Meskipun bahkan dalam kasus penyempitan ruang lingkup ini juga membutuhkan effort untuk eksekusinya, tapi jarang kejadian penyempitan ruang lingkup tersebut di lapangan.
 

Perluasan ruang lingkup ini seringnya membuat vendor pemula tidak bisa berbuat apa-apa. Para vendor tidak memiliki senjata bagaimana untuk menghentikan hal ini. Padahal yang namanya perluasan Ruang Lingkup pastinya memunculkan pembengkakan biaya. Namun biasanya vendor tidak dapat berbuat apa-apa meskipun seharusnya vendor berhak atas biaya tambahan. Disini tentu saja merupakan ancaman serius pekerjaan proyek IT tidak dapat terselesaikan. Vendor bisa kehabisan energi karena dana yang cekak.

 

Proyek 250 Juta bisa Mengkerut Hanya Menjadi 150 Juta SajaProyek 250 Juta bisa Mengkerut Hanya Menjadi 150 Juta Saja

 

Berikut adalah hal-hal penyebab mengapa sampai terjadi perluasan Ruang Lingkup dan titik krusial mengapa hal tersebut tidak bisa berkonsekuensi menambah anggaran untuk vendor.

 

Faktor Penyebab Pertama : Tidak adanya kesadaran owner proyek.

Maksudnya adalah Owner tidak mau tahu keadaan kita yang telah dipaparkan. Maunya mereka, sistem harus bisa mengcover sebagaimana yang mereka kehendaki. Mereka tidak mau tahu apakah sistem tersebut logis atau tidak logis, butuh atau tidak butuh, membutuhkan effort atau tidak. Padahal sudah dijelaskan beberapa kali pertemuan bahwa perubahan (pembengkakan) ruang lingkup pekerjaan membutuhkan effort yang besar yang ber konsekuensi pada pembengkakan biaya operasional di pihak vendor. Tetapi owner yang dalam hal ini adalah pegawai dari owner tetap tidak mau tau. Sudah dijelaskan dengan baik poin-poin yang telah mengembang dari perjanjian awal yang bahkan pembengkakan itu mencapai lebih dari 50 % tetapi mereka tidak mau tau hal ini. Alasannya jika poin-poin yang dikehendaki tersebut tidak ada maka software tidak akan bisa dipakai. Padahal tidak ada di perjanjian awal. Dilemanya disitu, klaim sepihak.

 

Faktor Penyebab Kedua : Pihak vendor, yang dalam hal ini adalah Amanah Solution tidak ketat dalam membedakan antara Owner dengan makna para manajemen/ decision maker mereka, dengan owner dengan makna pegawai mereka.

Pada awal-awal kerjasama pada waktu itu kita menganggap bahwa owner itu ya sama aja antara manajemen dengan pegawainya. Padahal tidak boleh demikian. Mengapa? Karena pada dasarnya manajemen merupakan subjek yang harus kita bantu kinerjanya nya agar bagaimana software yang sudah jadi nanti harus bisa membantu pekerjaan dari manajemen ini. Sedangkan pegawai adalah salah satu variabel objek gimana harus diperlakukan sebagai variabel, karena mereka nanti merupakan pemakai dari software ini. Dan harus dipertimbangkan pula bahwa pegawai harusnya diperlakukan bahwa mereka tidak mau tau tentang kebutuhan manajemen (decision maker). Karena mereka sifatnya adalah bekerja untuk manajemen. Mereka tidak butuh kepada laporan dashboard perkembangan perusahaan/ lembaga tempat dia bekerja. Kepentingan pegawai hanyalah kemudahan melakukan entri data. Mereka tidak ada kepentingan sama sekali dengan hasil laporan/ analisa data. Sebuah software sistem informasi yang baik tidak akan dapat memberikan laporan yang dibutuhkan oleh manajemen ketika salah satu dari variabel sistem informasi yakni software atau SDM nya tidak menjalankan tugas dan fungsinya secara baik. Di sini sekali lagi saya sampaikan bahwa kesalahan di awal dari vendor biasanya tidak membedakan antara manajemen dengan pegawai. Atau sebenarnya sudah kita implementasikan pembagian ini, namun masih tidak terlalu ketat dalam pembagian ini.

 

Faktor Penyebab Ketiga : Owner/ manajemen lebih mendukung pegawainya.

Sebenarnya faktor penyebab yang ini adalah imbas dari faktor penyebab kedua diatas, yakni karena di awal tidak di bedakan antara manajemen dengan pegawai maka di perjalanan nya sudah pasti manajemen memposisikan sebagai pihak kubu berseberangan dengan vendor. Dimana dengan statusnya tersebut manajemen pun sama dengan pegawai yakni minta dilayani oleh Amanah Solution. Oleh karena itu jika terjadi perbedaan pendapat antara vendor dengan pegawai, otomatis manajemen pun membela atau berada di pihak pegawai. Ini lebih menyulitkan lagi bagi vendor untuk menyuarakan pandangan.

 

Faktor Penyebab Keempat : Tidak adanya pihak ketiga yang kompeten sebagai tempat mengadu.

Sudah sejak awal pembicaraan kontrak tidak menempatkan sebuah pihak pun sebagai pihak penengah jika terjadi perbedaan pendapat yang tajam yang tidak bisa diselesaikan di lapangan antara kedua belah pihak. Padahal keberadaan pihak ketiga merupakan variabel yang sangat penting demi terselesaikannya proyek IT secara tepat waktu dan dengan kualitas yang bisa dipertanggungjawabkan. Pada kontrak kerjasama hanya disebutkan bahwa jika terjadi permasalahan akan diselesaikan di wilayah hukum dari di mana proyek tersebut dilaksanakan. Sebenarnya kalau kontraknya seperti ini, hal itu cukup aneh mengingat nilai proyek yang dilaksanakan hanyalah tidak seberapa. Jadi otomatis tidak sebanding jika dibandingkan biaya yang harus dikeluarkan jika harus mengurus konflik ke ranah hukum. Jadi kalau seperti ini, jadinya hanya seperti formalitas belaka dari sebuah kontrak kerjasama. Sesuatu yang tidak mungkin dilaksanakan di lapangan. Apalagi jika turut mempertimbangkan aspek sosial jika klausul ini diimplementasikan. Tentu akan mencoret nama lembaga. Harusnya dicantumkan tambahan klausul untuk menunjuk pihak ketiga yang mengawal proyek dari awal sampai akhir tuntas serah terima.  

 

Faktor Penyebab Kelima : Urusannya bukan lagi bagaimana Sistem bisa segera selesai dengan baik, tapi sudah pada urusan menang kalah. Ego yang berbicara.

Dari pihak owner kokoh minta supaya penambahan ruang lingkup tetap diakomodasi sementara dari kita pun tidak memiliki suara yang cukup untuk membendung dari keinginan owner tersebut karena jika kita menolak mereka tidak mau kalah karena yang mereka inginkan mereka memposisikan diri sebagai pihak yang menang sementara vendor adalah di pihak yang kalah.

Secara psikologis mereka memposisikan di posisi yang kuat karena merekalah yang memiliki dana. Dan ini merupakan salah satu imbas bahwa psikologis bahwa di antara mereka semua hanya pegawai yang bekerja, sehingga tanggung jawab terhadap penyelesaian pekerjaan ini nyaris tidak ada. Mereka tidak mau tahu pekerjaan ini selesai atau tidak, yang mereka tahu hanya menang atau kalah. Dan ini merupakan salah satu efek di mana perjanjian di awal pekerjaan banyak terjadi kelemahan yang menyebabkan keadaan menjadi mengerucut hanya menjadi urusan menang kalah di antara dua pihak. Proyek sudah tidak lagi urusan bagaimana solusinya agar proyek terlaksana dengan baik dengan tetap mempertimbangkan kebutuhan dari owner dan juga kebutuhan nutrisi stamina dan energi untuk vendor. Dan sudah pasti secara psikologis, jika urusannya adalah menang kalah, maka yang menang adalah owner karena mereka yang pegang uang.

Hingga akhirnya pada waktu itu, sampai akhirnya pada sebuah titik di mana vendor sudah mengklaim bahwa pekerjaan telah selesai sementara pihak owner mengklaim pekerjaan belum selesai. Klaim-klaiman ini sampai pada titik dimana perbedaan prosentase hasil pekerjaan dari kedua pihak ini mencolok terlalu jauh. Bahkan hanya karena testing dari pegawai pihak owner tidak bisa memasukkan data yang disebabkan hanya karena dia tidak tahu, itu sudah dianggap sebagai kekurangan software yang disamakan dengan error dan diberi nilai 0 %. Ini merupakan sesuatu yang naif sekali. Disini pekerjaan vendor sama sekali tidak dihargai. Dan pihak owner (dalam hal ini adalah para pegawainya) sangat subyektif dalam menilai.

Disini sudah pada satu titik dimana owner sudah tidak peduli pekerjaan selesai atau tidak. Yang dia pedulikan hanyalah kemenangan. Disini vendor sama sekali tidak punya kartu apa-apa kecuali mengharap belas kasihan saja.

 

Faktor Penyebab Kelima : Sistem Pembayaran yang tidak tepat.

Solusi pada waktu itu adalah dimana pihak manajemen dari owner menawarkan dengan dicairkan 50 juta dulu dari yang seharusnya 150 juta kekurangan pembayaran. Dicairkan 50 juta dulu. Sesuatu yg tidak masuk akal bagi vendor tentunya. Jadinya setelah dikalkulasi dengan tambahan uang muka di awal yang 100 juta, total yang diterimakan hanyalah 150 juta saja. jadi proyek yang di awal seharusnya bernilai 250 juta nilainya menjadi hanya 150 juta saja jadinya. Dan itu pun membutuhkan waktu 1 tahun lebih untuk pelunasannya. Disini vendor rugi 2 kali sekaligus. Yakni rugi waktu yakni pembengkakan waktu dari yang seharusnya 6 bulan selesai, menjadi harus 1 tahun lebih. Dan juga rugi bujet. Dari yang semula dianggarkan 250 juta hanya diterimakan cuman 150 juta. Sangat naif sekali.
 

Sebagai catatan : Pada waktu itu kita diberikan uang muka sebesar 100 juta dimana dengan uang muka sejumlah itu tentunya kita bisa memutar operasional tidak kurang dari 4 bulan awal.

------------------------------------------------

 
 

Pelajaran Penting Bagi Kita Semua

Sebagai bahan pengalaman jika suatu saat mendapatkan proyek lagi maka seharusnya dipikirkan antisipasi kemungkinan-kemungkinan yang terjadi sebagaimana yang diceritakan di atas. Beberapa solusi yang bisa dipertimbangkan adalah sebagaimana berikut :

  1. Yang pertama adalah memberikan biaya 100 % pembayaran adalah di awal pekerjaan. Solusi ini sudah banyak dipraktekkan oleh perusahaan-perusahaan besar vendor pengembang implementasi teknologi sistem informasi seperti IBM, Oracle, JDEdwards, dan lain sebagainya. Namun mereka adalah para pemain besar. Yang mana kekuatan dan tingkat kepercayaan publik sudah kuat ke mereka. Jika solusi ini ditawarkan kepada vendor kecil ya tentu tidak akan mungkin. Karena vendor kecil jelas belum punya nama dan tidak memiliki modal yang besar untuk entertain kepada calon klien.

 

  1. Solusi lain yang bisa di munculkan adalah dengan menunjuk pihak ketiga yg diakui kedua pihak sebagai jembatan penghubung diantara kedua belah pihak. Fungsi dari pihak ketiga ini adalah menjaga agar proyek tetap pada relnya dimana tetap berorientasi pada terselesaikannya proyek dengan baik dan tepat waktu dengan tidak mengorbankan kepentingan salah satu pihak. Dan hendaknya pihak ketiga ini adalah seorang profesional yang terbukti komitmennya dalam menangani proyek-proyek semacam ini. Pihak ketiga ini juga harus disetujui oleh kedua pihak. Pihak ketiga ini hendaknya dicantumkan dalam perjanjian dan dilibatkan ke dalam proyek dari awal pekerjaan sampai dengan selesai. Adapun urusan fee untuk pihak ketiga dapat dibicarakan antara pihak pertama (owner/ manajemen) dan pihak kedua (vendor).

 

  1. Solusi lain yang dapat diambil adalah membagi Pekerjaan ke dalam 2 tahap. 2 pekerjaan tersebut adalah Tahap konsultasi (vendor sebagai konsultan) dan tahap pengerjaan (kontraktor). Tahap konsultasi merupakan tahap dimana disitu dilakukan pekerjaan identifikasi kebutuhan, studi eksisting, sampai dengan rekomendasi sistem dan desain nya kayak apa. Disini ada biaya tentunya dan hasilnya ini boleh dieksekusi boleh tidak sesuai dengan kebutuhan atau keinginan dari owner. Jadi sebaiknya jika ingin mengembangkan sebuah sistem yang bagus maka sebuah lembaga harus melakukan pekerjaan konsultasi ini dulu sampai pada titik dimana hasilnya adalah berupa desain dan core sistem yang jelas yang mudah untuk dilaksanakan implementasinya oleh kontraktor pengerja software sistem informasi. Jadi semua flow dan diagramnya harus benar-benar jelas dan tuntas tanpa ada ambigu sehingga eksekusinya mudah tidak ada perubahan lagi di perjalanan pengembangannya. Dan tentunya waktu yang dibutuhkan untuk pengerjaan ini menjadi sesuai dengan harapan dan time schedule.

 

  1. Sesudah ada gambaran dari adanya beberapa solusi diatas maka yang paling penting dari itu semua adalah : komitmen bersama. Jangan sampai ada lagi di mana pada proses penggarapan nya yang ada adalah hanya menang dan kalah antara vendor dan owner atau pihak pegawai maupun manajemen dari owner proyek. Tetapi yang harus menjadi jiwa dari kegiatan penggarapan ini adalah bagaimana agar sistem bisa benar-benar sesuai dengan kebutuhan dan tidak mendholimi vendor, dan juga bisa terlaksana dengan baik sesuai dengan waktu yang ditentukan.

 

  1. Yang kelima : selalu menggantungkan segala sesuatunya kepada Allah subhaanahu wata’ala. Manusia bisanya hanya berusaha sebatas kemampuannya yang sangat sedikit. Namun keputusan hanya di tangan Allah. Jadikan setiap hambatan sebagai ujian dariNya. Dan bagi yang lulus menghadapinya dengan baik akan mendapatkan pahala dari sisiNya. Ini semua hanyalah urusan dunia yang sangat remeh dibandingkan dengan urusan di akherat nanti. Jangan sampai ada kedoliman demi memperebutkan dunia yang tentu saja akan berkonsekuensi pertanggungjawaban yang berat di akherat nanti.

 

Harapan dari tulisan ini adalah jangan sampai ada lagi kasus dimana proyek yang nilainya 250 juta menjadi 150 juta saja. Yang di mana pada akhirnya sudah tidak ada lagi ambisi dari vendor (saking habisnya energi dan nutrisi) untuk menyelesaikan proyek. Sudah tidak mengharap makanan atau minuman enak lagi, yang ada hanya harapan yang penting ada sesuatu sebagai sedikit air untuk diminum meskipun itu air ledeng tanpa dimasak. Tentu ini sangat memprihatinkan bagi vendor pengerjaan proyek IT, dimana ditekan habis oleh owner yang sudah tidak peduli proyeknya selesai