Jenis kontrak konstruksi menentukan jauh lebih dari sekadar cara kontraktor dibayar: jenis kontrak juga menentukan bagaimana pengendalian biaya harus dijalankan.
Kontrak menetapkan siapa yang menanggung risiko desain dan risiko biaya, serta cara para pihak mengelola perubahan dan menyertifikasi progres. Pada akhirnya, kontrak juga menetapkan seberapa besar kontraktor terpapar pada pembengkakan biaya.
Hal ini menjadi sangat penting pada proyek EPC, Lump Sum, Turnkey, BOT dan PPP berskala besar. Pada proyek tersebut, struktur komersial dari klien mungkin tidak memuat detail yang cukup untuk mengelola biaya konstruksi yang sebenarnya.
Prinsip utamanya sederhana:
Tingkat pembayaran kepada kontraktor belum tentu merupakan tingkat di mana kontraktor harus mengendalikan biayanya.
Oleh karena itu, bagi kontraktor besar, Bill of Quantities (BoQ) kontraktual hanyalah satu dimensi dari pengendalian proyek.
Pengendalian biaya konstruksi yang sesungguhnya menuntut keterhubungan antara BoQ, Work Breakdown Structure (WBS), Cost Codes dan pelaksanaan aktual di lapangan.
Karena itu, di sinilah ERP khusus konstruksi menjadi sangat penting.
Pertama, FIDIC, EPC, Lump Sum, BOT dan PPP Bukanlah Hal yang Sama
Banyak pihak sering memakai istilah-istilah ini bersamaan, tetapi masing-masing menggambarkan aspek yang berbeda dari pelaksanaan proyek.
- FIDIC menyediakan bentuk standar kontrak konstruksi dan rekayasa.
- EPC — Engineering, Procurement and Construction menggambarkan model pelaksanaan proyek di mana kontraktor bertanggung jawab atas rekayasa, pengadaan dan konstruksi.
- Lump Sum (LS) terutama menggambarkan pengaturan harga. Dalam pengaturan ini, kontraktor sepakat menyelesaikan lingkup pekerjaan tertentu dengan harga yang disepakati. Namun, ketentuan kontrak mengenai variasi dan penyesuaian lainnya tetap berlaku.
- BOT — Build-Operate-Transfer menggabungkan konstruksi dengan masa konsesi, di mana pihak swasta mengoperasikan aset sebelum menyerahkannya.
- PPP — Public-Private Partnership (Kemitraan Pemerintah dan Swasta) bahkan lebih luas. Skema ini biasanya melibatkan hubungan kontraktual jangka panjang antara sektor publik dan swasta. Hubungan tersebut mencakup kombinasi desain, konstruksi, pembiayaan, operasi dan pemeliharaan.
Selain itu, struktur-struktur ini dapat saling tumpang tindih.
Sebuah proyek EPC, misalnya, dapat berjalan sebagai kontrak Lump Sum Turnkey yang menggunakan FIDIC Silver Book.
Oleh karena itu, dari sudut pandang pengendalian biaya, yang penting adalah besarnya risiko komersial, desain, konstruksi dan kinerja yang beralih kepada kontraktor.
Singkatnya, semakin besar risikonya, semakin besar kebutuhan akan granularitas biaya internal.
FIDIC Red, Yellow dan Silver: Alokasi Risiko yang Berbeda
Dalam FIDIC Red Book, Pemberi Kerja secara tradisional menyediakan sebagian besar desain, sementara kontraktor melaksanakan pekerjaan konstruksi.
Hal ini umumnya menciptakan hubungan yang relatif langsung antara desain, kuantitas, pengukuran, progres dan pembayaran.
- FIDIC Yellow Book mengalihkan lebih banyak tanggung jawab desain kepada kontraktor. Akibatnya, kontrak semakin menuntut kontraktor untuk mengelola rekayasa, pengadaan, konstruksi, waktu dan biaya sebagai proses yang saling terhubung.
- FIDIC Silver Book, yang umumnya berkaitan dengan pelaksanaan EPC/Turnkey, mengalihkan tanggung jawab yang jauh lebih besar kepada kontraktor.
Pada dasarnya, Pemberi Kerja membeli sebuah hasil:
Menyerahkan fasilitas, pabrik atau aset infrastruktur yang Pemberi Kerja perlukan sesuai dengan persyaratan, harga dan kewajiban penyelesaian dalam kesepakatan.
Namun bagi kontraktor, mewujudkan hasil tersebut dapat melibatkan puluhan ribu aktivitas, sumber daya, dan pesanan pembelian. Hasil itu juga dapat melibatkan pergerakan material, transaksi tenaga kerja, jam alat berat dan pekerjaan subkontraktor.
Akibatnya, hal ini menimbulkan masalah besar dalam pengendalian biaya.
Paradoks EPC: Harga Komersial yang Sederhana Dapat Menyembunyikan Kompleksitas Konstruksi yang Sangat Besar
Sebagai contoh, bayangkan sebuah BoQ EPC sederhana dengan satu baris seperti:
Pekerjaan Struktur — USD 12 juta
Dari sudut pandang komersial klien, hal itu mungkin sudah sepenuhnya memadai.
Sebaliknya, dari sudut pandang pengendalian biaya kontraktor, hal itu hampir tidak bermakna.
Bahkan, USD 12 juta tersebut dapat mencakup:
galian, dewatering, pembesian, beton, bekisting, baja struktur, tenaga kerja, crane, pompa, pekerjaan sementara, bahan habis pakai, logistik, susut material, subkontraktor spesialis dan sumber daya tidak langsung.
Jika BoQ awal tidak menyediakan tingkat analisis rekayasa ini, kontraktor tidak bisa begitu saja menerima kurangnya detail tersebut.
Karena itu, kontraktor harus menciptakan granularitas itu secara internal.
Di sinilah Cost Codes menjadi penting secara strategis.
Cost Codes Dapat Menjadi Anggaran Kasar Tingkat Pertama
ProjectVIEW ERP menangani pengendalian biaya konstruksi melalui tiga dimensi proyek yang saling terhubung:
BoQ ↔ WBS ↔ Cost Codes
- BoQ mewakili dimensi komersial: apa yang klien beli dan apa yang pada akhirnya kontraktor jual.
- WBS mewakili dimensi pelaksanaan dan waktu: di mana, kapan dan dalam urutan apa tim harus melakukan pekerjaan.
- Cost Code (Cost Control Accounts) mewakili dimensi pengendalian biaya internal: bagaimana kontraktor mengklasifikasikan dan memantau pengeluaran.
Selain itu, ProjectVIEW mendukung penetapan Cost Codes pada anggaran BoQ dan pembentukan hubungan antara anggaran BoQ dan struktur penjadwalan proyek.
Karena itu, ketika BoQ EPC kurang memiliki detail rekayasa, Cost Codes dapat menyediakan dekomposisi kasar internal pertama atas anggaran proyek.
Misalnya, kontraktor dapat mendistribusikan item BoQ tingkat tinggi seperti Pekerjaan Struktur secara internal ke kategori biaya. Kategori ini mencakup pekerjaan tanah, beton, pembesian, bekisting, baja struktur, tenaga kerja, alat berat dan subkontraktor.
Dengan demikian, kontraktor tidak lagi bergantung pada struktur komersial klien untuk menentukan cara mengendalikan proyek secara internal.
WBS Menambahkan Dimensi yang Tidak Dimiliki BoQ: Waktu
Pertama, Cost Codes menjawab:
Jenis biaya apa yang sedang kita keluarkan?
Kemudian, WBS menjawab:
Di mana dan kapan kita melaksanakan pekerjaan?
Selanjutnya, metodologi tender dan penganggaran ProjectVIEW memungkinkan tim mengaitkan sumber daya, asumsi produktivitas dan jangka waktu dengan struktur BoQ dan perencanaan proyek.
Hal ini menciptakan tiga tampilan yang berbeda namun saling terhubung atas proyek yang sama:
BoQ = Komersial
WBS = Waktu dan pelaksanaan
Cost Codes = Klasifikasi biaya
Menghubungkan ketiga dimensi ini membentuk kerangka awal pengendalian biaya proyek.
Namun, kecerdasan yang sesungguhnya muncul ketika konstruksi berjalan.
Pelaksanaan di Lapangan Menciptakan Detail Rekayasa yang Hilang
Singkatnya, anggaran adalah asumsi.
Sebaliknya, konstruksi adalah kenyataan.
Setiap hari, lokasi proyek menghasilkan informasi yang dapat secara bertahap memperkaya anggaran awal.
Pertama, berapa banyak pekerjaan yang telah selesai?
Kemudian, berapa jam kerja yang tim butuhkan?
Berapa banyak material yang terpakai?
Selain itu, berapa jam crane, ekskavator atau peralatan lain yang terpakai?
Berapa banyak pekerjaan subkontrak yang telah selesai dan mendapat sertifikasi?
Lalu, berapa seharusnya biaya progres fisik tersebut?
Dan berapa biaya sebenarnya?
Metodologi pengendalian biaya ProjectVIEW merekam transaksi harian termasuk progres proyek, transaksi karyawan dan transaksi alat berat. Kemudian, sistem menggunakannya untuk membangun gambaran biaya aktual proyek.
Model manajemen konstruksinya yang lebih luas juga menghubungkan material, sertifikasi subkontraktor, produktivitas tenaga kerja dan utilisasi alat berat dengan hubungan BoQ–WBS–Cost Code.
Dengan demikian, anggaran EPC yang relatif kasar mulai berubah menjadi model biaya rekayasa yang terperinci.
Dari Anggaran Kasar ke Analisis Biaya Tingkat Rinci
Pertama, pada tahap tender, kontraktor dapat memulai dengan:
BoQ → Cost Code
Selama perencanaan proyek, ini menjadi:
BoQ → Cost Code → WBS
Selama konstruksi, ini berkembang lebih jauh:
BoQ → Cost Code → WBS → Sumber Daya → Transaksi Harian
Akhirnya, anggaran tingkat tinggi yang semula secara bertahap memperoleh detail operasional tingkat rinci.
Misalnya, manajemen dapat menganalisis anggaran pekerjaan struktur hingga ke aktivitas WBS tertentu, kategori biaya, dan regu kerja. Analisis ini juga mencakup konsumsi material, utilisasi alat berat, sertifikat subkontraktor dan transaksi progres fisik.
Alih-alih hanya mengetahui bahwa pekerjaan struktur melebihi anggaran, manajemen dapat mulai bertanya:
Aktivitas yang mana?
Cost Code yang mana?
Sumber daya yang mana?
Regu kerja yang mana?
Subkontraktor yang mana?
Material yang mana?
Alat berat yang mana?
Hari yang mana?
Dengan kata lain, itu adalah tingkat pengendalian biaya yang secara mendasar berbeda.
Perintah Kerja Harian: Pembedahan Presisi atas Biaya Konstruksi
Pada kenyataannya, kontraktor tidak membangun proyek melalui laporan keuangan bulanan.
Sebaliknya, kontraktor membangun proyek melalui pekerjaan harian.
Karena itu, tingkat tertinggi pengendalian biaya konstruksi adalah kemampuan mengaitkan transaksi operasional dengan struktur komersial, penjadwalan dan biaya proyek.
Oleh karena itu, transaksi kerja harian harus menjawab:
Apa yang sedang kita bangun? — BoQ
Di mana kita membangunnya? — WBS
Kategori pengeluaran apa yang terlibat? — Cost Code
Siapa yang melakukan pekerjaan? — Tenaga kerja atau subkontraktor
Apa yang mereka konsumsi? — Material
Peralatan apa yang mereka perlukan? — Alat berat
Progres apa yang mereka capai? — Progres fisik
Berapa seharusnya biaya progres tersebut? — Anggaran
Berapa biaya sebenarnya? — Biaya Aktual
Inilah yang kami maksud dengan pembedahan presisi atas proyek konstruksi.
Selain itu, ProjectVIEW memperluas logika yang sama ke pengadaan. Tim dapat mengaitkan proses pengadaan material dan gudang dengan BoQ, WBS dan Cost Codes. Akibatnya, pengeluaran tetap terhubung dengan tujuannya dalam proyek sejak permintaan pembelian, pembelian, hingga pemakaian di lapangan.
Kontrak dan sertifikasi subkontraktor juga dapat memuat Cost Codes, sehingga pekerjaan subkontrak masuk ke dalam struktur pengendalian biaya yang sama.
BoQ Harus Menjadi Struktur Biaya yang Hidup
BoQ yang kontraktor terima saat tender tidak boleh tetap menjadi dokumen Excel statis yang terputus dari pelaksanaan.
ProjectVIEW dapat mengimpor BoQ Excel dan mengubahnya menjadi struktur hierarkis baris kode BoQ. Kemudian, tim dapat mengaitkan material, tenaga kerja, alat berat dan subkontraktor dengan baris-baris tersebut selama estimasi.
Begitu konstruksi berjalan, kenyataan mulai memperkaya model awal.
Akibatnya, evolusi digitalnya menjadi:
BoQ Tender
→ Anggaran Berbasis Cost Code
→ Baseline Proyek yang Terhubung dengan WBS
→ Anggaran Sumber Daya
→ Transaksi Harian di Lapangan
→ Biaya Aktual vs Anggaran
→ Varians Produktivitas dan Sumber Daya
→ Tindakan Manajemen
Dengan demikian, ini menutup salah satu kesenjangan informasi yang paling persisten dalam konstruksi:
kesenjangan antara memperkirakan berapa seharusnya biaya konstruksi dan memahami berapa biaya konstruksi yang sebenarnya.
Mengapa Hal Ini Semakin Penting pada Proyek EPC dan Lump Sum
Konsekuensi finansialnya bahkan menjadi sangat signifikan pada kontrak EPC dan Lump Sum.
Sebagai contoh, bayangkan seorang kontraktor memiliki:
Pendapatan kontrak: USD 500 juta
Anggaran biaya: USD 450 juta
Target margin: USD 50 juta
Jika pelaksanaan akhirnya menelan biaya USD 485 juta, tambahan USD 35 juta tidak hilang begitu saja karena BoQ klien kurang detail.
Akibatnya, tambahan itu langsung mengurangi margin kontraktor.
Karena itu, tujuan pengendalian biaya konstruksi tidak bisa hanya sekadar melaporkan pembengkakan biaya setelah terjadi.
Sebaliknya, tujuannya harus mengidentifikasi penyimpangan selagi manajemen masih memiliki waktu untuk bertindak.
Artinya, terus-menerus membandingkan:
Produktivitas tenaga kerja: anggaran vs aktual
Konsumsi material: anggaran vs aktual
Utilisasi alat berat: rencana vs aktual
Biaya subkontraktor: anggaran vs sertifikasi
Progres fisik: rencana vs aktual
Biaya proyek: anggaran vs aktual
Karena itu, model pengendalian biaya ProjectVIEW merekam transaksi lapangan dan membandingkan pelaksanaan dengan baseline proyek. Model ini tidak menunggu akuntansi menjadi tanda pertama bahwa ada sesuatu yang salah.
Dari Pelaporan Biaya Tradisional ke Pengendalian Biaya “Kuantum”
ERP keuangan tradisional sangat baik dalam menjawab:
Berapa yang kita belanjakan?
Namun, rekayasa biaya konstruksi perlu melangkah jauh lebih dalam:
Berapa yang kita belanjakan, di mana kita membelanjakannya, dan sumber daya apa yang mengonsumsinya? Progres fisik apa yang muncul, berapa seharusnya biaya progres itu, mengapa ada penyimpangan dan apa yang masih bisa kita lakukan?
Dengan menghubungkan:
BoQ ↔ WBS ↔ Cost Codes
dan terus-menerus mengisi struktur tersebut dengan:
Tenaga Kerja ↔ Material ↔ Alat Berat ↔ Subkontraktor ↔ Progres
Hasilnya, ProjectVIEW ERP secara bertahap memecah kinerja proyek menjadi unit-unit terukur yang lebih kecil.
Inilah yang kami sebut Pengendalian Biaya “kuantum”: dekomposisi berkelanjutan atas biaya dan kinerja proyek ke dalam elemen operasional yang semakin granular. Dengan begitu, manajemen dapat mengidentifikasi penyimpangan lebih dekat dengan tempat dan waktu asalnya.
Alih-alih baru tahu di akhir bulan bahwa pekerjaan beton melebihi anggaran, manajemen seharusnya dapat menelusuri penyebab operasionalnya.
Singkatnya, itulah perbedaan antara melaporkan pembengkakan biaya dan mengendalikannya.
Benang Merah Digital yang Sesungguhnya: Dari Tender hingga Konstruksi
Banyak kontraktor besar masih beroperasi dengan lapisan teknologi yang terputus-putus.
Misalnya, satu sistem menangani estimasi.
Primavera menangani penjadwalan.
Sementara itu, platform lain mengelola aktivitas lapangan.
Pengadaan berjalan melalui ERP korporat.
Informasi subkontraktor berada di tempat lain.
Akuntansi mencatat transaksi keuangan.
Akhirnya, Excel berusaha merekonsiliasi semuanya.
Hasilnya bukan transformasi digital.
Hasilnya adalah fragmentasi digital.
Sebaliknya, ProjectVIEW ERP mengambil pendekatan berbeda dengan membangun tulang punggung terintegrasi khusus konstruksi yang menghubungkan:
Tender → Penganggaran → Perencanaan → Pengadaan → Pelaksanaan Lapangan → Subkontraktor → Pengendalian Biaya
Pertama, BoQ klien menjadi titik awal komersial.
Cost Codes menyediakan struktur biaya internal kontraktor.
Kemudian, WBS menambahkan jadwal dan pelaksanaan.
Pengadaan menyerap anggaran.
Selanjutnya, transaksi lapangan mencatat kenyataan.
Sertifikasi subkontraktor mencatat produksi eksternal.
Progres mengukur apa yang benar-benar telah terbangun.
Akhirnya, semua informasi tersebut terus-menerus mengalir ke pengendalian biaya proyek.
DANAOS merancang arsitektur ProjectVIEW secara khusus untuk menghubungkan estimasi, pengadaan, subkontraktor, operasi lapangan dan pengendalian biaya. Semua proses ini bertumpu pada dimensi bersama BoQ, WBS dan Cost Codes.
Dengan kata lain, tujuannya bukan sekadar menambah dasbor lain.
Tujuannya adalah tulang punggung digital pengendalian biaya untuk konstruksi.
Dalam EPC, Harga Kontrak Hanyalah Permulaan
Singkatnya, skema FIDIC, EPC, Lump Sum, BOT dan PPP mengalokasikan tanggung jawab dan risiko secara berbeda.
Namun satu prinsip menjadi semakin penting seiring makin banyak risiko yang beralih ke kontraktor:
Kesederhanaan komersial tidak sama dengan kesederhanaan operasional.
Kontraktor EPC mungkin menerima BoQ kontraktual yang relatif tingkat tinggi.
Namun, hal itu tidak membuat pengendalian biaya yang granular menjadi mustahil.
Sebaliknya, hal itu justru membuat pengendalian biaya yang granular semakin penting.
ProjectVIEW ERP mengatasinya dengan menggunakan Cost Codes sebagai elemen penganggaran kasar tingkat pertama. Kemudian, sistem menghubungkannya dengan item BoQ kontraktual dan aktivitas WBS berbasis waktu. Akhirnya, sistem secara bertahap memperkaya struktur ini dengan data konstruksi nyata:
Produktivitas tenaga kerja.
Pemanfaatan material.
Utilisasi alat berat.
Pengadaan.
Sertifikasi subkontraktor.
Progres fisik.
Transaksi harian di lapangan.
Dengan demikian, proyek dapat berkembang secara bertahap dari:
Kontrak → BoQ → Cost Code → WBS → Sumber Daya → Pelaksanaan Harian → Biaya Aktual
Dan di sinilah ERP khusus konstruksi menjadi berbeda secara mendasar dari ERP keuangan generik.
Akuntansi memberi tahu Anda ke mana uang itu pergi.
Rekayasa biaya konstruksi harus memberi tahu Anda mengapa uang itu pergi ke sana—dan cukup dini untuk dapat bertindak.
Kontraktor EPC dan Lump Sum menanggung risiko pelaksanaan yang signifikan. Bagi mereka, perbedaan itu pada akhirnya dapat menentukan apakah mereka melindungi margin proyek atau harus menjelaskan mengapa margin itu hilang.
