Bagi kontraktor di UEA, mengendalikan banyak proyek membutuhkan lebih dari sekadar dasbor terkonsolidasi. Dibutuhkan model operasional bersama yang menghubungkan lingkup, anggaran, jadwal, sumber daya, komitmen, dan kinerja aktual setiap proyek. ERP konstruksi harus mempertahankan kendali per proyek dan per entitas hukum, sekaligus memberikan visibilitas kepada manajemen atas seluruh portofolio. Tujuannya adalah mengoordinasikan pembelian, mengalokasikan sumber daya, mengidentifikasi eksposur biaya, dan mendukung keputusan yang tepat waktu—tanpa memaksa setiap proyek mengikuti struktur pelaksanaan yang identik.
Bayangkan sebuah kontraktor yang mengerjakan pengembangan hunian di Dubai, paket infrastruktur di Abu Dhabi, dan pekerjaan utilitas di Sharjah.
Setiap proyek memiliki klien, program, ketentuan komersial, dan prioritas pelaksanaannya sendiri. Namun, proyek-proyek tersebut dapat bersaing untuk kapasitas pengadaan, pemasok, peralatan, tenaga kerja spesialis, dan modal kerja yang sama.
Akibatnya, keputusan yang menguntungkan satu lokasi proyek dapat menimbulkan masalah di lokasi lain.
Misalnya, memindahkan ekskavator dapat menyelesaikan kebutuhan mendesak, tetapi menunda proyek lain. Mengonsolidasikan pembelian material dapat memperbaiki harga negosiasi, tetapi menambah kebutuhan penyimpanan. Mempercepat konstruksi dapat meningkatkan progres fisik, tetapi juga menambah kebutuhan kas dalam waktu dekat.
Menurut pandangan saya, pengendalian konstruksi multi-proyek bukan sekadar penjumlahan laporan masing-masing proyek.
Dengan kata lain, ini adalah kemampuan untuk memahami—dan mengatur—hubungan antarproyek.
1. Mengapa konteks UEA penting
Pertama, skala dan keragaman pembangunan di UEA menjadikan hal ini persoalan operasional yang penting.
Dalam pengumuman persetujuan pembangunan 2025 tertanggal 12 Maret 2026, Departemen Munisipalitas dan Transportasi Abu Dhabi melaporkan persetujuan yang mencakup hampir 75 juta meter persegi luas lantai kotor. Ini adalah persetujuan pembangunan—bukan konstruksi yang telah selesai atau pendapatan kontraktor.
Sementara itu, pengumuman Dubai Metro Blue Line dari Otoritas Jalan dan Transportasi tertanggal 9 Juni 2025 menggambarkan proyek sepanjang 30 kilometer dengan 14 stasiun baru. Ini menunjukkan lingkungan pelaksanaan yang berbeda: infrastruktur transportasi yang melibatkan banyak lokasi, antarmuka, dan paket pekerjaan.
Namun, pembaca tidak boleh menggabungkan contoh-contoh ini menjadi perkiraan ukuran pasar yang dibuat-buat. Relevansinya bersifat operasional: kontraktor membutuhkan sistem yang mampu menangani berbagai jenis proyek dalam kerangka manajemen yang konsisten.
Selain itu, kerangka tersebut harus mengakomodasi persyaratan khusus UEA. Persyaratan ini mencakup proses pembayaran tenaga kerja, pembatasan kerja pada musim panas, dan penerapan faktur elektronik secara bertahap.
Kebutuhannya bukan sekadar ERP yang tersedia di UEA. Kebutuhannya adalah model operasional yang sesuai dengan cara kontraktor melaksanakan proyek di UEA.
2. Apa sebenarnya arti “satu platform operasional”?
Satu platform operasional tidak seharusnya berarti satu berkas proyek yang sangat besar.
Selain itu, platform ini juga tidak berarti setiap pengguna dapat mengakses informasi keuangan setiap anak perusahaan.
Sebaliknya, saya akan mendefinisikannya melalui tiga lapisan yang saling terhubung.
- Fondasi perusahaan yang sama. Klasifikasi sumber daya, data pemasok, konvensi kode biaya, aturan dokumen, dan definisi pelaporan yang berlaku bersama.
- Pengendalian proyek yang terpisah. Setiap proyek mempertahankan lingkup, versi anggaran, jadwal, kontrak, batas persetujuan, prakiraan, dan tanggung jawabnya sendiri.
- Koordinasi tingkat portofolio. Manajemen yang berwenang dapat menelaah gabungan kebutuhan sumber daya, eksposur pengadaan, kebutuhan kas, dan pengecualian proyek.
Sebagai contoh, DANAOS Insights membahas perbedaan ini dalam ERP multi-perusahaan untuk organisasi berbasis proyek. Menurut artikel itu, visibilitas terpusat harus berjalan berdampingan dengan kendali operasional dan keuangan di tingkat entitas.
Singkatnya, prinsip desainnya sederhana:
Standarkan informasi yang penting untuk pengendalian. Pertahankan perbedaan yang penting untuk pelaksanaan.
Misalnya, proyek gedung dan proyek jalan dapat berbagi klasifikasi korporat untuk biaya peralatan tanpa menggunakan Work Breakdown Structure atau asumsi produktivitas yang sama.
Dengan kata lain, kode biaya yang sama tidak membenarkan tingkat produksi yang sama.
3. Hubungkan lingkup, jadwal, dan struktur biaya setiap proyek
Sebelum mengonsolidasikan informasi, kontraktor membutuhkan fondasi yang andal di tingkat proyek.
Karena itu, pendekatan DANAOS menghubungkan:
BoQ ↔ WBS ↔ Kode Biaya
- Bill of Quantities (BoQ)—atau struktur lingkup terkuantifikasi yang setara— menyediakan item pekerjaan dan kuantitas yang menjadi dasar analisis sumber daya dan biaya.
- Work Breakdown Structure (WBS) menata lingkup proyek. Aktivitas, ketergantungan, dan kalender yang terkait dengannya membentuk jadwal pelaksanaan.
- Kode Biaya menyediakan klasifikasi internal untuk mengakumulasi dan menganalisis biaya proyek.
Artikel berikut menjelaskan hubungan ini: BoQ, WBS, dan Kode Biaya: Menghubungkan Lingkup, Jadwal, dan Biaya. Selain itu, DANAOS merancang ProjectVIEW ERP untuk mengaitkan dimensi-dimensi ini, bukan memperlakukannya sebagai struktur pelaporan yang tidak saling berhubungan.
Bagi kontraktor multi-proyek, karena itu, saya menyarankan untuk memperluas prinsip tersebut melalui pemetaan korporat yang terkelola.
Setiap transaksi lapangan harus mengidentifikasi proyek dan paket pekerjaan terkait, sekaligus mempertahankan klasifikasi untuk pelaporan grup. Selain itu, aturan pemetaan harus mencegah sistem menghitung kuantitas atau biaya yang sama berulang kali. Risiko ini muncul ketika hubungannya melintasi beberapa aktivitas atau kategori pelaporan.
Dengan demikian, kontraktor dapat mengajukan dua pertanyaan berbeda tanpa kehilangan keterkaitan di antara keduanya:
“Apa yang sedang terjadi pada paket pekerjaan ini?”
“Di mana jenis eksposur yang sama muncul di bagian lain perusahaan?”
Untuk latar belakang lebih lanjut, misalnya, lihat baseline kinerja proyek yang terintegrasi.
4. Sentralisasikan pengadaan tanpa kehilangan akuntabilitas proyek
Tim pengadaan pusat perlu memahami lebih dari sekadar total kuantitas permintaan dari beberapa lokasi proyek.
Selain itu, tim tersebut harus mengetahui spesifikasi, kebutuhan resmi, stok yang tersedia, alokasi proyek, dan tanggal pengiriman wajib.
Misalnya, tiga proyek meminta material serupa.
Sebelum menerbitkan pesanan pembelian baru, proses operasional harus memastikan apakah stok yang sesuai sudah tersedia. Kemudian, proses itu harus memeriksa apakah proyek lain sudah mencadangkan stok tersebut. Akhirnya, proses itu harus menilai apakah pemindahan akan mengganggu proyek yang saat ini memegangnya.
Setelah itu, bagian pengadaan memutuskan apakah akan memindahkan, membeli secara terpisah, atau mengonsolidasikan kebutuhan.
DANAOS Insights menjelaskan urutan ini dalam tantangan pengadaan berbasis proyek. Alur kerja dalam artikel tersebut menghubungkan permintaan lapangan dengan konteks anggaran, ketersediaan stok, realokasi material, dan pembelian.
Oleh karena itu, persyaratan pengendaliannya adalah mempertahankan tujuan pengiriman dan tanggung jawab komersial di sepanjang proses.
Misalnya, permintaan penawaran gabungan tidak boleh menghapus alokasi proyek. Perjanjian kerangka tidak boleh menghilangkan kendali atas tanggal pengiriman. Pemindahan stok harus tetap menyimpan jejak otorisasi dan penilaiannya.
Selain itu, perusahaan harus merancang pemindahan antar-entitas hukum yang terpisah bersama tim keuangan. Pemindahan ini bukan perpindahan biasa antargudang.
Sentralisasikan keputusan pembelian jika bermanfaat. Pastikan akuntabilitas tetap melekat pada proyek dan entitas yang menggunakan sumber daya tersebut.
5. Kelola tenaga kerja dan peralatan sebagai sumber daya bersama—tetapi terbatas
Pertama, perencanaan sumber daya portofolio harus membedakan ketersediaan dari kesesuaian.
Misalnya, sebuah mesin mungkin tersedia secara fisik tetapi sudah masuk alokasi proyek lain. Sebuah regu kerja mungkin kosong minggu depan tetapi tidak memiliki spesialisasi yang relevan. Selain itu, pemindahan mungkin layak secara teknis tetapi tidak menarik secara komersial setelah tim memperhitungkan biaya mobilisasi dan produksi yang hilang.
Karena itu, saya akan mensyaratkan agar keputusan sumber daya mempertimbangkan komitmen yang ada, kesiapan, tanggal kebutuhan, upaya pemindahan, dan konsekuensinya bagi proyek yang melepaskan sumber daya.
Fungsi manajemen alat berat ProjectVIEW mencakup alokasi, ketersediaan, utilisasi, dan proses terkait pemeliharaan alat berat. Semua ini merupakan masukan penting bagi model sumber daya yang terkoordinasi.
Kondisi kerja di UEA harus masuk dalam rencana
Kebijakan Pencegahan Stres Panas Kerja 2026 UEA melarang pekerjaan di bawah sinar matahari langsung dan di area terbuka antara pukul 12.30 dan 15.00. Larangan ini berlaku dari 15 Juni hingga 15 September 2026, dengan pengecualian dan persyaratan perlindungan tertentu.
Bagi perencanaan proyek, karena itu, implikasinya praktis: kalender, asumsi shift, dan prakiraan sumber daya harus mencerminkan kondisi kerja yang berlaku. Sebaliknya, rencana sumber daya portofolio dengan asumsi ketersediaan yang keliru akan tetap tidak andal, secanggih apa pun tampilan dasbornya.
Penggajian dan produktivitas proyek menjawab pertanyaan yang berbeda
Panduan Wages Protection System dari MoHRE mengatur pembayaran upah melalui lembaga keuangan resmi.
Untuk pengendalian proyek, saya juga akan mensyaratkan alokasi waktu kerja resmi ke proyek dan aktivitas yang tepat. Kemudian, tim menilai waktu kerja itu terhadap hasil fisik.
Dengan kata lain, membayar pekerja dengan benar dan memahami biaya pekerjaan adalah tanggung jawab yang saling terkait. Namun, keduanya bukan pengendalian yang sama.
6. Bandingkan prakiraan biaya akhir—bukan hanya pengeluaran hingga saat ini
Misalnya, sebuah proyek bisa masih memiliki sisa anggaran yang besar tetapi tetap mengarah pada pembengkakan biaya.
Informasi yang hilang adalah komitmen yang sudah kontraktor buat dan perkiraan biaya pekerjaan yang tersisa.
Hubungan Estimate at Completion standar adalah:
Prakiraan biaya akhir = biaya aktual hingga saat ini + perkiraan biaya untuk menyelesaikan pekerjaan yang tersisa.
Contoh ilustratif proyek senilai AED 100 juta
Misalkan sebuah proyek memiliki anggaran biaya resmi sebesar AED 100 juta.
Pada tanggal pelaporan, biaya aktual yang telah terjadi, termasuk akrual terkait, adalah AED 35 juta.
Kemudian, prakiraan biaya pekerjaan tersisa yang sudah terikat komitmen adalah AED 40 juta. Angka ini tidak termasuk apa pun yang sudah tercakup dalam biaya aktual. Selain itu, tim memperkirakan pekerjaan tersisa tanpa komitmen sebesar AED 30 juta.
Dengan demikian, prakiraan biaya akhirnya adalah:
AED 35 juta + AED 40 juta + AED 30 juta = AED 105 juta.
Proyek tersebut baru mengeluarkan AED 35 juta, tetapi prakiraannya sudah menunjukkan pembengkakan biaya AED 5 juta.
Tentu saja, ini adalah contoh hipotetis, bukan hasil pelanggan ProjectVIEW. Contoh ini mengasumsikan lingkup, aturan penilaian, dan tanggal pelaporan yang konsisten.
Karena itu, rekonsiliasi sangat penting. Jangan menambahkan nilai awal pesanan pembelian ke biaya aktual jika sebagian dari pesanan tersebut sudah terjadi. Hal itu akan menghitung eksposur yang sama dua kali.
Di seluruh portofolio, saya akan meninjau perubahan prakiraan beserta penyebabnya. Penyebab itu misalnya revisi kuantitas, produktivitas, harga pengadaan, biaya preliminaries tambahan, atau perubahan lingkup resmi.
Sisa anggaran bukan bukti bahwa tim dapat menyelesaikan pekerjaan yang tersisa di dalamnya.
7. Pisahkan progres fisik, sertifikasi, dan kas
Kontraktor membutuhkan informasi yang terhubung, tetapi bukan definisi yang saling menggantikan.
Untuk keperluan manajemen, saya menyarankan perbedaan yang jelas antara beberapa status. Pertama, pekerjaan yang tim catat sebagai selesai. Kemudian, pekerjaan yang lolos penerimaan sesuai proses yang berlaku. Selanjutnya, pekerjaan bersertifikat untuk pembayaran, faktur yang terbit, dan kas yang masuk.
Demikian pula, sistem harus membedakan perubahan yang teridentifikasi dari variasi resmi.
Jika tidak, manajemen dapat salah membaca laporan progres yang optimistis sebagai posisi kas yang aman. Bahkan, manajemen dapat memperlakukan potensi pemulihan sebagai hak komersial yang telah disepakati.
Oleh karena itu, model operasional harus menghubungkan kuantitas, dokumen pendukung, ketentuan kontrak, status peninjauan, dan transaksi keuangan yang relevan sambil mempertahankan perbedaan-perbedaan tersebut.
Pembahasan DANAOS tentang pengendalian biaya di luar BoQ kontraktual menjelaskan masalah terkait. Struktur komersial dapat terlalu teragregasi untuk mengendalikan sumber daya dalam pelaksanaan.
Singkatnya, saran saya adalah mempertahankan baseline awal, revisi resmi, dan prakiraan saat ini sebagai tampilan yang dapat diidentifikasi.
Selain itu, catat potensi eksposur perubahan tanpa diam-diam menulis ulang anggaran resmi atau mengasumsikan bahwa setiap jumlah yang diklaim akan dipulihkan.
8. Berikan PMO tampilan portofolio berbasis pengecualian
Namun, Project Management Office tidak perlu memeriksa setiap transaksi untuk menemukan titik yang memerlukan intervensi.
Sebaliknya, saya akan menyusun tinjauan portofolionya berdasarkan sejumlah kecil pertanyaan keputusan.
- Eksposur biaya: Proyek mana yang prakiraannya memburuk, dan apa yang berubah sejak tanggal pelaporan sebelumnya?
- Eksposur pengiriman: Material, persetujuan, atau sumber daya apa yang belum siap dan mengancam aktivitas mendatang?
- Konflik sumber daya: Di mana tim telah menjanjikan regu kerja atau peralatan yang sama untuk kebutuhan yang tumpang tindih?
- Eksposur komersial dan kas: Sertifikasi, penagihan, saldo retensi, atau pembayaran pemasok mana yang memerlukan perhatian?
- Keandalan data: Proyek mana yang memiliki laporan lapangan terlambat, pemetaan yang belum tuntas, atau transaksi tanpa rekonsiliasi?
Selain itu, setiap pengecualian harus mengarah pada penanggung jawab yang jelas, bukti pendukung, dan tindakan lanjutan—bukan sekadar indikator berwarna.
Karena itu, dalam demonstrasi ERP, minta penyedia untuk bergerak dari tampilan portofolio ke proyek, paket pekerjaan, dan transaksi yang mendasarinya.
Ikhtisar peran manajemen proyek dan pengendalian biaya dari DANAOS memberikan titik awal yang relevan. Halaman itu membantu menelaah informasi yang tersedia bagi manajer proyek.
Laporan terkonsolidasi hanya berguna jika manajemen dapat menjelaskan apa yang ada di baliknya.
9. Bangun kesiapan faktur elektronik UEA ke dalam model operasional
Faktur elektronik merupakan alasan praktis untuk menelaah bagaimana transaksi proyek terhubung dengan proses keuangan entitas pelaksana kontrak.
Berdasarkan perubahan jadwal faktur elektronik yang diumumkan pada 10 Mei 2026, Kementerian Keuangan memperpanjang batas waktu penunjukan Accredited Service Provider bagi kelompok usaha besar tertentu hingga 30 Oktober 2026. Sementara itu, penerapan wajib tetap pada 1 Januari 2027. Pengumuman tersebut berlaku bagi usaha dalam cakupan dengan pendapatan tahunan di atas AED 50 juta.
Panduan faktur elektronik UEA dari Kementerian juga membuat perbedaan penting: faktur elektronik adalah data faktur elektronik yang terstruktur. PDF, dokumen hasil pindaian, atau email bukanlah faktur elektronik dengan sendirinya.
Bagi kontraktor multi-proyek, saya akan menguji proses mulai dari transaksi dasar hingga pembuatan faktur. Kemudian, pengujian berlanjut ke pertukaran dengan penyedia layanan, penanganan status, dan rekonsiliasi.
Penilaian harus mempertahankan referensi proyek dan informasi entitas yang benar, sambil menangani pengecualian dan nota kredit secara konsisten.
Jangan berasumsi bahwa produk berlabel “ERP UEA” memiliki solusi menyeluruh yang tervalidasi untuk setiap struktur perusahaan. Pastikan penerapan, konfigurasi, dan kesiapan integrasinya bersama tim keuangan dan tim implementasi yang bertanggung jawab.
Rujukan regulasi mencerminkan informasi resmi per tinjauan September 2026.
10. Bagaimana ProjectVIEW ERP mendukung model operasional
Pendekatan ProjectVIEW ERP menghubungkan informasi lingkup, pelaksanaan, dan biaya proyek melalui arsitektur BoQ ↔ WBS ↔ Kode Biaya.
Modul Cost Control mendokumentasikan keterhubungan antara anggaran, progres proyek, alokasi sumber daya, dan perangkat penjadwalan, termasuk Oracle Primavera P6 dan Microsoft Project.
Modul Procurement and Purchasing menangani sourcing, penawaran harga, pembelian, dan kebutuhan proyek terkait.
Bersama dengan kemampuan multi-perusahaannya, fungsi-fungsi ini mendukung model operasional DANAOS. Dalam model ini, transaksi khusus proyek yang mengalir ke kerangka bersama untuk koordinasi dan manajemen.
Namun, satu platform operasional tidak selalu berarti harus mengganti setiap aplikasi spesialis.
Pendekatan integrasi ERP untuk Oracle dan SAP dari DANAOS menjelaskan ProjectVIEW yang beroperasi secara mandiri atau berdampingan dengan ERP korporat. Namun, tim tetap perlu merancang lingkup dan kepemilikan integrasi untuk setiap klien.
Selain itu, evaluasi harus menetapkan sistem mana yang memiliki setiap data. Evaluasi juga harus menjelaskan cara sistem bertukar pembaruan dan cara tim menyelesaikan transaksi yang gagal.
Demikian pula, tim harus menilai “visibilitas real-time” terhadap pengambilan data, persetujuan, dan sinkronisasi yang sebenarnya—bukan menganggapnya sebagai pengganti.
11. Uji tiga proyek yang saling terhubung sebelum berkomitmen pada peluncuran
Skenario penerimaan yang saya sarankan menggunakan tiga proyek representatif dengan kondisi pelaksanaan yang berbeda.
Mulailah dengan anggaran dan jadwal proyek. Tambahkan kebutuhan material bersama, permintaan peralatan yang saling bersaing, dan subkontraktor yang bekerja di lebih dari satu proyek.
Kemudian, uji apakah solusi tersebut dapat:
- Mengonsolidasikan pembelian sambil mempertahankan alokasi proyek dan tanggal pengiriman.
- Memindahkan sumber daya tanpa kehilangan otorisasi, penilaian, atau akuntabilitas.
- Memperbarui biaya aktual dan prakiraan tanpa menghitung komitmen dua kali.
- Mempertahankan hak akses yang terpisah per proyek dan per entitas.
- Menjelaskan pengecualian portofolio melalui transaksi yang mendasarinya.
Selanjutnya, tambahkan pengiriman yang terlambat, revisi kuantitas, dan perubahan yang belum mendapat persetujuan.
Namun, tujuannya bukan untuk membuktikan bahwa perangkat lunak dapat menampilkan nama beberapa proyek.
Tujuannya adalah memastikan apakah organisasi dapat mengoordinasikan proyek-proyek tersebut sambil tetap mengendalikan masing-masing proyek.
Untuk cakupan produk yang relevan, lihat ERP konstruksi untuk kontraktor umum
.
Penutup
Portofolio kontraktor UEA tidak boleh menjadi kumpulan anggaran yang terputus dan saling bersaing untuk sumber daya yang sama.
Sebaliknya, sentralisasi juga tidak boleh menghapus perbedaan komersial dan operasional antarproyek.
Pandangan DANAOS Projects adalah bahwa pengendalian multi-proyek yang efektif membutuhkan logika bisnis bersama dengan akuntabilitas di tingkat proyek.
Karena itu, manajemen harus dapat melihat kebutuhan, komitmen, dan pemakaian sumber daya. Selain itu, manajemen harus melihat pengiriman yang sudah terjadi dan hal yang masih berisiko.
Pertanyaannya bukan sekadar:
“Bisakah ERP kami mengelola banyak proyek?”
Melainkan:
“Bisakah kami mengambil keputusan pada satu proyek sambil memahami—dan mengendalikan—konsekuensinya bagi bagian lain dari bisnis?”
Itulah ujian bagi satu platform operasional.
