Software Konstruksi Bukan Satu Pasar: Penjelasan Solusi Spesifik, Platform Proyek, dan ERP Konstruksi

Mengapa kontraktor besar perlu membedakan software tingkat tugas, platform tingkat proyek, dan ERP konstruksi tingkat perusahaan sebelum membahas “integrasi”

 

Saat ini, perusahaan konstruksi dikelilingi oleh berbagai software.

 

Software penjadwalan. Software estimasi biaya. Aplikasi perhitungan kuantitas (quantity take-off). Platform BIM. Common Data Environment. Sistem manajemen dokumen. Alat pengadaan. Aplikasi lapangan. Sistem akuntansi. Sistem Manajemen Sumber Daya Manusia. Sistem Manajemen Gudang. Platform pengendalian proyek. Platform manajemen konstruksi. Sistem Enterprise Resource Planning (ERP).

 

Selain itu, hampir setiap vendor kini mengklaim menawarkan “platform terintegrasi”, “satu sumber kebenaran (single source of truth)”, atau “solusi end-to-end”.

 

Akibatnya, hal ini menimbulkan masalah mendasar.

 

Kita menggunakan kata-kata yang sama untuk menggambarkan sistem yang bertujuan menyelesaikan tingkatan bisnis konstruksi yang sama sekali berbeda.

 

• Aplikasi penjadwalan mungkin terintegrasi sempurna untuk penjadwalan.
• Common Data Environment mungkin menyediakan satu sumber kebenaran yang sangat baik untuk dokumentasi proyek.
• Platform manajemen proyek mungkin menghubungkan ratusan pemangku kepentingan dalam pelaksanaan satu proyek.

 

 

Karena itu, untuk memahami teknologi konstruksi dengan benar, saya percaya kita perlu membagi pasar ke dalam tiga lapisan besar:

 

1. Aplikasi untuk tujuan spesifik

 

2. Platform konstruksi berorientasi proyek (lapisan konstruksi)

 

3. Sistem ERP konstruksi tingkat perusahaan

 

Tentu saja ada tumpang tindih di antara ketiganya.

 

Bahkan, batas-batasnya semakin kabur seiring vendor memperluas fungsionalitas, mengakuisisi aplikasi lain, dan membangun ekosistem integrasi.

 

Namun, pembedaan ini tetap penting.

 

Karena pertanyaan sesungguhnya bukanlah:

 

“Berapa banyak fitur yang dimiliki software ini?”

 

Pertanyaan sesungguhnya adalah:

 

Tingkat organisasi mana yang dikelola oleh software tersebut?

 

Pertanyaan itu mengubah segalanya.

 

---

 

1. Aplikasi Konstruksi untuk Tujuan Spesifik: Menyelesaikan Satu Masalah dengan Sangat Baik

 

Kategori pertama mencakup aplikasi yang khusus menangani tugas, disiplin, atau tantangan operasional tertentu.

 

Contohnya meliputi:

 

• penjadwalan dan perencanaan;
• perhitungan kuantitas (quantity take-off);
• estimasi biaya;
• pemodelan BIM;
• anotasi dokumen;
• reality capture;
• manajemen keselamatan;
• telematika peralatan;
• penggajian;
• akuntansi;
• pengadaan;
• pemeliharaan aset;
• pelaporan lapangan;
• manajemen mutu.

 

Aplikasi-aplikasi ini bernilai justru karena spesialisasinya.

 

Misalnya, ambil contoh Oracle Primavera P6.

 

Oracle menggambarkan Primavera P6 Enterprise Project Portfolio Management sebagai solusi untuk memprioritaskan, merencanakan, mengelola, dan mengevaluasi proyek, program, dan portofolio. Keunggulannya mencakup penjadwalan, sumber daya, pemantauan progres, dan manajemen portofolio proyek. Oracle juga secara eksplisit menyatakan bahwa P6 dapat berbagi data dengan sistem keuangan, human capital, dan ERP.

 

Itulah yang memang seharusnya kita harapkan.

 

Dengan kata lain, Primavera tidak perlu menjadi sistem penggajian, pengadaan, pergudangan, dan buku besar kontraktor untuk menjadi platform penjadwalan yang unggul.

 

Tanggung jawab utamanya berbeda.

 

Demikian pula, sistem Quantity Take-Off (QTO) khusus, sistem estimasi, aplikasi BIM, platform telematika alat berat, dan teknologi reality capture dapat menyelesaikan masalahnya masing-masing. Bahkan, hasilnya lebih baik daripada kemampuan aplikasi perusahaan berskala besar.

 

Kekuatan software untuk tujuan spesifik adalah kedalaman.

 

Sebaliknya, keterbatasan alaminya adalah cakupan organisasi.

 

Aplikasi khusus biasanya menciptakan apa yang dapat kita sebut:

 

Kebenaran Tingkat Tugas

 

Perencana memercayai Primavera untuk jadwal.

 

Estimator memercayai sistem estimasi untuk perkiraan biaya.

 

Tim BIM memercayai modelnya.

 

Quantity surveyor memercayai aplikasi QTO.

 

Manajer alat berat memercayai platform telematika.

 

Masing-masing mungkin benar dalam domainnya.

 

Masalah muncul ketika perusahaan perlu memahami bagaimana semua kebenaran itu saling memengaruhi.

 

---

 

2. Platform Konstruksi Berorientasi Proyek: Menciptakan Kebenaran Tingkat Proyek

 

Kategori kedua muncul karena konstruksi memiliki karakteristik unik lainnya:

 

Sebuah proyek jarang dilaksanakan oleh satu perusahaan saja.

 

Proyek besar dapat melibatkan:

 

• Pemilik proyek;
• Engineer atau Konsultan;
• Kontraktor Utama;
• mitra Joint Venture;
• subkontraktor;
• pemasok;
• perancang;
• manajer proyek;
• quantity surveyor;
• otoritas pemerintah;
• inspektur independen.

 

Organisasi-organisasi ini perlu bertukar informasi dalam jumlah sangat besar tanpa harus berada dalam satu perusahaan yang sama.

 

Mereka bertukar:

 

gambar, RFI (permintaan informasi), submittal, korespondensi, permintaan perubahan, catatan inspeksi, kontrak, model, jadwal, foto, dokumen, dan informasi komersial.

 

Akibatnya, hal ini memunculkan kebutuhan akan platform konstruksi berorientasi proyek.

 

Objek pengorganisasian alaminya adalah proyek.

 

Procore

 

Misalnya, Procore adalah contoh yang kuat.

 

Procore menyediakan lingkungan manajemen konstruksi yang luas seputar pelaksanaan proyek, manajemen lapangan, manajemen komersial, dan alur kerja keuangan proyek.

 

Namun, arsitektur Procore sendiri juga menunjukkan pembedaan yang penting.

 

Alat Integrasi ERP-nya menghubungkan Procore dengan sistem seperti Viewpoint Vista, Spectrum, Sage, NetSuite, CMiC, QuickBooks, Acumatica, Workday, dan lainnya. Selain itu, Procore menggambarkan integrasi ini sebagai mekanisme untuk menghubungkan informasi proyek konstruksi dengan lingkungan ERP atau akuntansi perusahaan.

 

Hal itu tidak melemahkan proposisi Procore.

 

Sebaliknya, hal itu justru membantu mendefinisikannya.

 

Procore dapat menjadi lapisan manajemen konstruksi yang sangat andal, sementara platform lain tetap bertanggung jawab atas fungsi akuntansi perusahaan dan ERP.

 

---

 

Autodesk Construction Cloud

 

Autodesk Construction Cloud mengikuti prinsip arsitektur yang serupa.

 

Autodesk menyediakan kemampuan manajemen konstruksi yang luas serta ekosistem integrasi. Ekosistem ini menghubungkan Autodesk Construction Cloud dengan aplikasi ERP dan keuangan eksternal.

 

Bahkan, Autodesk secara eksplisit menerbitkan panduan tentang cara menghubungkan lingkungan konstruksinya dengan sistem ERP dan keuangan. Tujuannya adalah menghilangkan entri ganda dan menyinkronkan informasi keuangan antara lapangan dan kantor.

 

Sekali lagi, ini menggambarkan perbedaan antara teknologi pelaksanaan proyek dan tulang punggung perusahaan.

 

---

 

Oracle Aconex

 

Sementara itu, Oracle Aconex mungkin memberikan salah satu contoh paling jelas dari apa yang saya sebut Kebenaran Tingkat Proyek.

 

Oracle menggambarkan Aconex sebagai Common Data Environment (CDE) — lingkungan sentral yang menghubungkan organisasi, proses, dan informasi proyek.

 

Aconex sangat kuat karena setiap organisasi yang terlibat dalam proyek tetap memegang kendali atas informasinya. Pada saat yang sama, organisasi tersebut berkolaborasi dalam lingkungan proyek bersama. Bahkan, Oracle secara eksplisit menggambarkannya sebagai sistem yang menciptakan satu sumber kebenaran untuk proyek.

 

Pilihan kata tersebut penting:

 

untuk proyek.

 

Dengan kata lain, Aconex dapat menyediakan catatan proyek yang otoritatif berisi dokumen, komunikasi, model, persetujuan, dan keputusan.

 

Itu sangat bernilai.

 

Namun, kebenaran proyek dan kebenaran perusahaan belum tentu sama.

 

---

 

Trimble ProjectSight

 

Trimble ProjectSight memberikan contoh lain yang berguna.

 

Dokumentasi Trimble saat ini memungkinkan pengguna menautkan perusahaan dan proyek di dalam ProjectSight langsung dengan lingkungan ERP. Kemudian, pengguna dapat menyinkronkan Kontrak dan Purchase Order dengan ERP tersebut.

 

Sekali lagi, arsitektur itu sendiri memberi tahu kita sesuatu.

 

Platform proyek mengelola alur kerja konstruksi.

 

Sementara itu, ERP tetap menjadi sistem perusahaan.

 

---

 

3. ERP Konstruksi Tingkat Perusahaan: Mengelola Kontraktor, Bukan Hanya Proyek

 

Sekarang kita sampai pada kategori ketiga.

 

Kontraktor bukan sekadar kumpulan proyek.

 

Kontraktor adalah sebuah perusahaan.

 

Bahkan, kontraktor besar sering kali jauh lebih kompleks dari itu.

 

Mereka dapat terdiri dari:

 

• beberapa badan hukum;
• anak perusahaan;
• Joint Venture;
• unit bisnis;
• operasi regional;
• ratusan proyek yang berjalan bersamaan;
• ribuan karyawan;
• armada peralatan;
• yard produksi atau fabrikasi;
• gudang;
• subkontraktor;
• pemasok;
• beberapa mata uang;
• beberapa yurisdiksi pajak;
• sistem penggajian yang berbeda;
• hierarki persetujuan korporat;
• Bagan Akun (Chart of Accounts) yang berbeda.

 

Pada akhirnya, proyek menggunakan sumber daya milik perusahaan ini.

 

Dan inilah alasan Enterprise Resource Planning ada sejak awal.

 

Oleh karena itu, ERP konstruksi tingkat perusahaan perlu mengelola bukan hanya proyek, tetapi juga hubungan antara proyek dan perusahaan.

 

Contoh kategori ini mencakup sistem seperti Trimble Viewpoint Vista, CMiC, Sage X3 Construction, dan DANAOS ProjectVIEW ERP, meskipun arsitektur, kedalaman fungsional, dan pasar sasarannya sangat berbeda.

 

---

 

Viewpoint Vista

 

Trimble menggambarkan Vista sebagai solusi ERP konstruksi yang terintegrasi penuh, yang mencakup area seperti:

 

• job costing;
• manajemen keuangan;
• penggajian;
• SDM;
• peralatan;
• manajemen layanan;
• operasi lokasi proyek;
• analitik.

 

Dokumentasi Vista menggambarkan dengan tepat apa arti integrasi perusahaan. Misalnya, transaksi penggajian dapat memperbarui Job Cost, Buku Besar, Manajemen Peralatan, Utang Usaha, dan struktur keuangan lainnya.

 

Itu lebih dari sekadar berbagi dokumen atau menyinkronkan sebuah field.

 

Itu adalah integrasi transaksional.

 

---

 

CMiC

 

CMiC secara eksplisit menggambarkan arsitekturnya sebagai ERP konstruksi yang dibangun di atas Single Database Platform.

 

Solusinya menggabungkan Keuangan Konstruksi dan Manajemen Proyek, sementara Alur Kerja dan Analitik beroperasi di keduanya.

 

Lingkungan keuangannya mencakup akuntansi, penggajian, Human Capital Management, peralatan, dan persediaan, sementara lingkungan manajemen proyeknya meluas ke pengendalian proyek, pengadaan, mutu, keselamatan, gambar, dan dokumentasi.

 

Sekali lagi, pembeda pentingnya adalah cakupan.

 

Aplikasi ini tidak sekadar mengelola apa yang terjadi di dalam proyek.

 

Sebaliknya, aplikasi ini menghubungkan aktivitas proyek secara langsung dengan proses keuangan dan operasional perusahaan.

 

---

 

Sage X3 Construction

 

Sage X3 Construction memberikan contoh lain.

 

Sage memosisikan solusi ini di bidang estimasi, manajemen proyek, penghitungan biaya proyek, pengadaan, dan persediaan. Selain itu, solusi ini mencakup manajemen kontrak, manajemen keuangan, SDM, penggajian, dan analitik.

 

Yang penting, solusi ini juga mendukung banyak proyek, mata uang, dan entitas bisnis.

 

Ini adalah karakteristik ERP.

 

Karena itu, sistem harus memahami baik:

 

struktur proyek

 

maupun

 

struktur korporat.

 

---

 

Kategori Ini Tidak Mutlak — Dan Itu Penting

 

Pasar software tidak statis.

 

• Misalnya, vendor manajemen proyek terus menambahkan fungsionalitas keuangan.
• Sebaliknya, vendor ERP terus menambahkan kemampuan lapangan dan manajemen proyek.
• Vendor penjadwalan meluas ke pengendalian proyek.

 

Sementara itu, platform CDE semakin banyak mendukung alur kerja, proses komersial, dan analitik.

 

Microsoft Dynamics 365 Project Operations adalah contoh yang sangat baik dari perpaduan ini.

 

Microsoft menyediakan Project Operations dalam berbagai konfigurasi penerapan. Konfigurasi tersebut mencakup lingkungan inti berorientasi proyek dan lingkungan yang terintegrasi dengan Dynamics 365 Finance. Selain itu, Microsoft secara eksplisit membedakan antara fungsionalitas Project Operations dan penerapan yang terintegrasi dengan ERP.

 

Dalam arsitektur yang terintegrasi dengan ERP, Microsoft menyinkronkan data antara Dataverse dan Dynamics 365 Finance menggunakan teknologi dual-write, sementara Finance menyediakan kerangka akuntansi proyek dan keuangan.

 

Jadi, artikel ini tidak bermaksud menciptakan kotak-kotak software yang artifisial.

 

Kategori-kategori tersebut menggambarkan tanggung jawab arsitektural.

 

Sebuah platform dapat berperan di beberapa lapisan.

 

Namun pada akhirnya, setiap arsitektur perusahaan tetap harus menjawab:

 

Sistem mana yang mengelola kebenaran yang mana?

 

---

 

Kebenaran Tugas, Kebenaran Proyek, dan Kebenaran Perusahaan

 

Pembedaan ini dapat diringkas menjadi tiga tingkat.

 

Aplikasi untuk tujuan spesifik

 

Menciptakan Kebenaran Tugas

 

 

 

 

Platform berorientasi proyek

 

Menciptakan Kebenaran Proyek

 

 

 

 

 

ERP tingkat perusahaan

 

Menciptakan Kebenaran Perusahaan

 

 

 

 

 

 

 

 

Kebenaran-kebenaran ini saling melengkapi.

 

Namun, tidak dapat saling menggantikan.

 

---

 

Common Data Environment Belum Tentu Sebuah ERP

 

Pembedaan ini layak mendapat perhatian khusus karena istilah CDE dan Single Source of Truth telah terlalu sering digunakan.

 

Oracle mendefinisikan Common Data Environment sebagai lingkungan berbasis cloud tempat peserta yang berwenang menyimpan dan mengakses informasi proyek konstruksi.

 

Itu adalah definisi yang tepat.

 

Karena itu, CDE dapat menjadi lingkungan otoritatif untuk:

 

• dokumen;
• gambar;
• model;
• korespondensi;
• revisi;
• persetujuan;
• catatan proyek.

 

Namun, ERP harus menjawab serangkaian pertanyaan yang berbeda:

 

• Siapa pemilik material tersebut?
• Gudang mana yang menyimpannya?
• Pemasok mana yang telah dibayar?
• Badan hukum mana yang mengontrak pemasok tersebut?
• Proyek mana yang menggunakan material tersebut?
• Kode biaya mana yang terpengaruh?
• Jurnal akuntansi apa yang dihasilkan?
• Perlakuan pajak apa yang diterapkan?
• Bagaimana transaksi tersebut memengaruhi arus kas?
• Bagaimana pengaruhnya terhadap profitabilitas proyek?

 

Ini adalah transaksi perusahaan, bukan sekadar informasi proyek.

 

CDE proyek dan ERP perusahaan dapat — dan sering kali seharusnya — berjalan berdampingan.

 

Namun, menyebut keduanya sebagai “Single Source of Truth” tanpa mendefinisikan domainnya akan menimbulkan kebingungan.

 

---

 

Konektivitas Bukanlah Integrasi

 

Ini mungkin poin terpenting dari seluruh pembahasan.

 

Saat ini hampir setiap aplikasi perusahaan memiliki API.

 

Namun, itu tidak berarti setiap aplikasi perusahaan telah terintegrasi.

 

API dapat mengirimkan:

 

• nomor pemasok,
• Purchase Order,
• faktur,
• kode proyek,
• nilai biaya,
• kuantitas,
• dokumen,
• atau status.

 

Hal ini membuktikan bahwa sistem dapat berkomunikasi.

 

Namun, hal ini tidak membuktikan bahwa sistem-sistem tersebut menggunakan logika bisnis yang sama.

 

Sebaliknya, integrasi perusahaan yang sesungguhnya membutuhkan jauh lebih banyak.

 

Integrasi tersebut membutuhkan:

 

• master data bersama;
• pengenal (identifier) bersama;
• struktur organisasi bersama;
• logika alur kerja bersama;
• kesinambungan transaksi;
• rekonsiliasi keuangan;
• tata kelola akses;
• jejak asal data (data lineage);
• akuntabilitas.

 

Sebagai contoh, pertimbangkan kasus konstruksi sederhana.

 

Sebuah lokasi proyek membutuhkan 2.000 meter kabel.

 

Namun, kebutuhan tersebut seharusnya tidak sekadar menjadi Purchase Order.

 

Sebaliknya, kebutuhan itu mungkin perlu terhubung dengan:

 

Proyek → BoQ → Aktivitas WBS → Kode Biaya → Kode Material → Pemasok → Paket Pengadaan → Gudang → GRN → Pengeluaran ke Lapangan → Konsumsi Aktual → Biaya → Akuntansi

 

• Pertama, Jadwal menentukan kapan proyek membutuhkan material.
• Kemudian, Pengadaan menentukan bagaimana dan dari siapa perusahaan memperoleh material tersebut.
• Gudang mencatat penerimaan.
• Sementara itu, Lapangan mencatat konsumsi.
• Pengendalian Biaya membandingkan konsumsi dengan progres fisik.
• Keuangan mengakui kewajiban dan pembayaran.
• Akhirnya, Manajemen mengevaluasi dampaknya terhadap profitabilitas proyek dan arus kas.

 

Jika setiap departemen membangun ulang transaksi itu secara terpisah di software masing-masing, perusahaan tersebut tidak memiliki proses yang terintegrasi.

 

Sebaliknya, perusahaan hanya memiliki beberapa basis data yang secara berkala berusaha saling menyesuaikan.

 

Itu adalah hal yang sangat berbeda.

 

---

 

Masalah Digital Konstruksi Bukan Lagi Kekurangan Software

 

Industri ini sudah memiliki software dalam jumlah sangat besar.

 

Namun, masalah yang lebih besar adalah fragmentasi.

 

McKinsey mengidentifikasi teknologi konstruksi sebagai pasar yang sangat terfragmentasi, dengan dominasi solusi spesifik (point solution). Selain itu, McKinsey mengamati bahwa ketidakpuasan terhadap integrasi berbagai solusi spesifik turut mendorong pergerakan industri menuju platform terintegrasi.

 

• Pengamatan tersebut tetap sangat relevan.
• Kita menghabiskan bertahun-tahun mendigitalkan tugas-tugas individual.
• Akibatnya, kini kita harus mengintegrasikan pulau-pulau digital hasil upaya tersebut.

 

Tantangannya telah bergeser dari:

 

“Bagaimana kita mendigitalkan proses ini?”

 

menjadi:

 

“Bagaimana kita membuat semua proses yang telah didigitalkan merepresentasikan realitas bisnis yang sama?”

 

---

 

Mengapa Kontraktor Besar Membutuhkan ERP sebagai Tulang Punggung

 

Bagi kontraktor berskala perusahaan, beberapa hal pada akhirnya membutuhkan satu pemilik di tingkat korporat.

 

1. Master Data

 

Harus ada pihak yang mengelola:

 

• material,
• spesialisasi tenaga kerja,
• karyawan,
• pemasok,
• subkontraktor,
• alat berat,
• kode biaya,
• perusahaan,
• mata uang,
• satuan ukur,
• proyek,
• gudang,
• rekening bank.

 

Jika setiap aplikasi proyek memiliki versi yang berbeda, integrasi berubah menjadi rekonsiliasi tanpa akhir.

 

---

 

2. Konsekuensi Keuangan

 

Hampir setiap aktivitas konstruksi pada akhirnya memiliki konsekuensi keuangan.

 

• Tenaga kerja membutuhkan biaya.
• Material membutuhkan biaya.
• Alat berat membutuhkan biaya.
• Subkontraktor membutuhkan biaya.
• Keterlambatan membutuhkan biaya.
• Perubahan membutuhkan biaya.

 

Bahkan progres pun penting secara komersial karena progres pada akhirnya menjadi:

 

sertifikasi → pendapatan → faktur → Piutang Usaha → kas.

 

Oleh karena itu, manajemen konstruksi dan manajemen keuangan tidak dapat terus-menerus terpisah.

 

---

 

3. Sumber Daya Korporat

 

Proyek tidak secara mandiri memiliki tenaga kerja, peralatan, hubungan pemasok, kas, atau pengetahuan korporat perusahaan.

 

Sebaliknya, perusahaanlah yang memiliki sumber daya tersebut dan mengalokasikannya ke berbagai proyek.

 

Artinya, pelaksanaan proyek pada akhirnya harus terhubung kembali dengan manajemen sumber daya perusahaan.

 

---

 

4. Manajemen Portofolio

 

Seorang Manajer Proyek mengelola satu proyek.

 

Seorang CEO tidak.

 

CEO mengelola perusahaan yang memiliki portofolio proyek.

 

Oleh karena itu, manajemen puncak membutuhkan konsistensi di seluruh:

 

• proyek,
• unit bisnis,
• negara,
• anak perusahaan,
• Joint Venture,
• mata uang,
• dan periode pelaporan.

 

Dengan demikian, tingkat tata kelola tersebut membutuhkan model perusahaan.

 

---

 

Arsitektur yang Tepat Bukan “Satu Aplikasi untuk Segalanya”

 

Ini adalah pembedaan penting lainnya.

 

Namun, mendukung ERP sebagai tulang punggung tidak berarti menentang software khusus.

 

Itu adalah pandangan yang naif secara teknologi.

 

Kontraktor dapat dengan sah menggunakan:

 

• Primavera P6 untuk penjadwalan.
• Revit atau Tekla untuk desain dan BIM.
• Aconex sebagai CDE kontraktual.

 

Sistem reality capture khusus untuk visualisasi lokasi proyek.

 

Telematika alat berat khusus.

 

Aplikasi rekayasa khusus.

 

Bahkan, mungkin ada platform wajib dari Klien yang tidak dapat kontraktor ganti.

 

Prinsip arsitektur yang tepat adalah:

 

Aplikasi khusus di tepi. ERP di inti.

 

Dengan kata lain, aplikasi khusus menjalankan tugas yang menjadi tujuan perancangannya.

 

Sementara itu, ERP mengorkestrasi konsekuensi komersial, operasional, dan keuangan di seluruh perusahaan.

 

Masalahnya bukan memiliki banyak aplikasi.

 

Masalahnya adalah memiliki banyak pusat gravitasi.

 

---

 

Di Mana Posisi DANAOS ProjectVIEW ERP?

 

DANAOS ProjectVIEW ERP terutama termasuk dalam kategori ketiga:

 

ERP Konstruksi Tingkat Perusahaan

 

DANAOS merancang ProjectVIEW sebagai solusi perusahaan untuk organisasi konstruksi multidisiplin, multinasional, dan multifungsi dengan operasi yang tersebar. Dokumentasi teknis DANAOS menggambarkan modul-modulnya sebagai aplikasi untuk tujuan spesifik yang selaras dengan departemen-departemen perusahaan konstruksi, tetapi berbagi master file dan sumber daya sistem yang sama di dalam satu platform terpusat.

 

Cakupannya meliputi:

 

• Estimasi dan Tender;
• Penganggaran dan Pengendalian Biaya;
• Pengadaan dan Pembelian;
• Manajemen Gudang dan Material;
• Manajemen Subkontraktor;
• Produksi dan Fabrikasi;
• Alat Berat dan Pemeliharaan;
• HRMS dan Manajemen Tenaga Kerja;
• Kontrak Pelanggan;
• Akuntansi dan Keuangan;
• Dokumen;
• Analitik;
• alur kerja;
• aplikasi lapangan;
• portal eksternal.

 

Prinsip dasarnya penting.

 

Artinya, DANAOS tidak merancang modul-modul ini sebagai pulau-pulau departemen yang terpisah.

 

Sebaliknya, modul-modul tersebut beroperasi di atas struktur proyek dan perusahaan yang sama.

 

Arsitektur SaaS DANAOS saat ini menggambarkan ProjectVIEW ERP sebagai ERP kelas konstruksi dengan 10+1 modul perusahaan. Modul-modul ini mencakup proses Komersial, Operasional, Produksi, dan Keuangan.

 

---

 

Logika Inti Konstruksi ProjectVIEW: BoQ ↔ WBS ↔ Kode Biaya

 

Konstruksi menghadirkan tantangan ERP tersendiri karena dimensi-dimensi dasarnya berasal dari sumber yang berbeda.

 

Bill of Quantities — BoQ memberi tahu kita apa yang Klien harapkan untuk kontraktor serahkan dan dalam kuantitas berapa.

 

Work Breakdown Structure — WBS memberi tahu kita bagaimana kontraktor akan mengurutkan pekerjaan dari waktu ke waktu.

 

Struktur Kode Biaya memberi tahu kita bagaimana kontraktor mengklasifikasikan pengeluaran dan sumber daya secara internal.

 

Struktur-struktur ini saling berkaitan.

 

Namun, tidak identik.

 

Oleh karena itu, logika bisnis ProjectVIEW mengaitkan:

 

BoQ ↔ WBS ↔ Kode Biaya

 

DANAOS menggambarkan hal ini sebagai inti proyek yang menghubungkan lingkup, waktu, dan biaya.

 

Secara internal, dokumentasi ProjectVIEW menggambarkan hubungan ini sebagai integrasi tiga arah antara BoQ Klien, WBS penjadwalan, dan Kode Biaya internal. Tujuannya adalah mengaitkan biaya, waktu, dan sumber daya.

 

Hal ini lebih penting daripada yang terlihat pada awalnya.

 

Karena kita tidak dapat mengukur kinerja konstruksi hanya melalui progres jadwal.

 

Bayangkan lapangan melaporkan:

 

“Aktivitas telah selesai 50%.”

 

Pertanyaan yang seharusnya muncul adalah:

 

50% menurut apa?

 

Pertama, tim dapat mengukur progres fisik melalui kuantitas atau persentase yang selesai terhadap BoQ atau WBS yang relevan.

 

Namun, Pengendalian Biaya memerlukan pertanyaan kedua:

 

Sumber daya apa yang digunakan untuk mencapai 50% tersebut?

 

Tenaga kerja.

 

Material.

 

Alat berat.

 

Subkontraktor.

 

Sumber daya tidak langsung.

 

Jika kuantitas yang dicapai, tingkat produksi, waktu, dan biaya yang digunakan tidak selaras dengan baseline, berarti ada sesuatu yang berubah.

 

Di titik itulah manajemen konstruksi menjadi pengendalian ekonomi, bukan sekadar pelaporan progres.

 

---

 

Mengapa ProjectVIEW Tetap Terintegrasi dengan Primavera, BIM, SAP, dan Oracle

 

Jika ProjectVIEW adalah ERP, mengapa perlu diintegrasikan dengan sistem lain?

 

Karena tulang punggung perusahaan tidak boleh menjadi alasan untuk isolasi teknologi.

 

DANAOS merancang ProjectVIEW agar terhubung dengan teknologi konstruksi khusus, termasuk Oracle Primavera P6, Microsoft Project, dan lingkungan BIM.

 

ProjectVIEW juga dapat terhubung dengan platform perusahaan pihak ketiga seperti SAP atau Oracle melalui API bila diperlukan. Dokumentasi teknis DANAOS secara eksplisit mengakomodasi arsitektur hibrida semacam ini.

 

Hal ini terutama penting bagi grup multinasional yang sangat besar.

 

Misalnya, sebuah perusahaan induk mungkin telah menstandardisasi SAP atau Oracle secara global untuk fungsi Keuangan.

 

Namun, mengganti platform tersebut mungkin tidak realistis secara komersial dan juga tidak perlu secara teknologi.

 

Dalam skenario tersebut:

 

SAP/Oracle dapat tetap menjadi ERP Keuangan Korporat, sementara

 

ProjectVIEW menjadi Lapisan Operasional Konstruksi yang mengelola proses-proses khusus konstruksi yang lebih mendalam.

 

Itu adalah arsitektur yang sah.

 

Dengan demikian, software yang sama dapat memainkan peran berbeda tergantung pada penerapannya.

 

---

 

Jadi, Apa Sebenarnya Arti “Single Source of Truth”?

 

Istilah ini seharusnya tidak berarti bahwa setiap byte data harus secara fisik berada di satu basis data.

 

Definisi tersebut sudah usang.

 

Sebaliknya, perusahaan modern dapat secara sah mengoperasikan beberapa system of record.

 

Namun, persyaratannya adalah kepemilikan data harus jelas dan tidak ambigu.

 

Sebagai contoh:

 

• Primavera dapat memiliki jadwal yang disetujui.
• Lingkungan BIM dapat memiliki model terkini.
• Aconex dapat memiliki catatan dokumen kontraktual.

 

ERP dapat memiliki transaksi pemasok, karyawan, akuntansi, pengadaan, dan biaya.

 

Pada akhirnya, yang penting adalah semua sistem yang terlibat mengetahui:

 

sistem mana yang memiliki kebenaran yang mana,

 

pengenal mana yang menghubungkan mereka,

 

dan

 

bagaimana sebuah transaksi berpindah di antara mereka tanpa kehilangan maknanya.

 

Itulah arsitektur perusahaan.

 

---

 

Bagaimana Kontraktor Menguji Apakah Sebuah Platform Benar-Benar Terintegrasi?

 

Daripada bertanya kepada vendor:

 

 

Sebaliknya, tanyakan hal-hal berikut:

 

Di mana master data dibuat?

 

Siapa pemilik data pemasok, material, karyawan, alat berat, Kode Biaya, organisasi, dan proyek?

 

Dapatkah transaksi mempertahankan identitasnya?

 

Dapatkah sebuah kebutuhan bergerak dari permintaan lapangan ke pengadaan, Purchase Order, penerimaan, konsumsi, biaya, dan keuangan tanpa harus dibuat ulang?

 

Dapatkah progres fisik direkonsiliasi dengan konsumsi sumber daya?

 

Dapatkah manajemen memahami apakah biaya yang keluar sebanding dengan kuantitas pekerjaan yang selesai?

 

Dapatkah sistem mengelola struktur korporat?

 

• Banyak perusahaan?
• Anak perusahaan?
• Joint Venture?
• Negara?
• Mata uang?
• Proyek?

 

Dapatkah aktivitas operasional sampai ke Keuangan?

 

Apakah transaksi konstruksi pada akhirnya menghasilkan konsekuensi keuangan yang dapat diaudit?

 

Dapatkah para eksekutif membandingkan proyek secara konsisten?

 

Atau apakah Business Intelligence harus terlebih dahulu menormalkan sepuluh struktur data yang berbeda?

 

Dapatkah sebuah KPI ditelusuri kembali ke transaksinya?

 

Jika manajemen melihat varians biaya, dapatkah pengguna menelusuri lebih dalam untuk menentukan transaksi tenaga kerja, material, alat berat, subkontraktor, atau pengadaan yang menjadi penyebabnya?

 

Pertanyaan-pertanyaan ini mengungkap jauh lebih banyak daripada perbandingan fitur.

 

---

 

Di Mana Posisi AI dalam Hal Ini?

 

Ada alasan lain mengapa pembahasan ini menjadi mendesak.

 

AI.

 

Perusahaan kini berlomba memperkenalkan agen AI, copilot, dan sistem prediktif ke dalam konstruksi.

 

Namun, AI melipatgandakan kualitas data dan proses yang menjadi dasarnya.

 

Misalnya, perusahaan mungkin memiliki catatan pemasok yang saling bertentangan, Kode Biaya yang tidak konsisten, jadwal yang tidak terhubung, definisi material yang duplikat, dan keuangan proyek yang rekonsiliasinya belum selesai. Dalam kondisi itu, AI tidak akan secara ajaib menciptakan kebenaran perusahaan.

 

AI justru mempercepat konsumsi inkonsistensi.

 

Karena itu, data ERP yang terstruktur menjadi penting secara strategis.

 

Arsitektur ProjectVIEW saat ini memosisikan ERP sebagai lapisan proses dan data terstruktur di bawah lingkungan AI-nya. Dalam arsitektur ini, BoQ, WBS, dan Kode Biaya berfungsi sebagai dimensi proyek yang dapat mesin pahami.

 

Sebelum organisasi mengejar AI konstruksi yang otonom, mereka membutuhkan sesuatu yang jauh kurang glamor tetapi jauh lebih penting:

 

data perusahaan yang konsisten.

 

---

 

FAQ

Pertanyaan yang Sering Diajukan

Apa perbedaan antara Software Manajemen Konstruksi dan ERP Konstruksi?

Software Manajemen Konstruksi terutama membantu mengoordinasikan dan mengendalikan pelaksanaan proyek.

ERP Konstruksi menghubungkan pelaksanaan proyek dengan fungsi-fungsi perusahaan seperti pengadaan, persediaan, penggajian, alat berat, akuntansi, keuangan, sumber daya korporat, dan manajemen portofolio.

Apakah Procore sebuah ERP?

Procore menyediakan fungsionalitas manajemen konstruksi dan keuangan proyek yang luas, tetapi Procore sendiri menyediakan integrasi khusus dengan berbagai sistem ERP dan akuntansi. Hal ini menunjukkan kemampuannya untuk berdampingan dengan ERP sebagai tulang punggung perusahaan, alih-alih mengharuskan Procore menjalankan setiap fungsi ERP.

Apakah Autodesk Construction Cloud sebuah ERP?

Autodesk Construction Cloud pada dasarnya adalah lingkungan konstruksi dan pelaksanaan proyek. Selain itu, Autodesk secara aktif mendukung integrasi dengan aplikasi ERP, akuntansi, dan keuangan eksternal.

Apakah CDE sama dengan ERP?

Tidak.

CDE mengelola informasi proyek bersama dan kolaborasi.

Sebaliknya, ERP mengelola sumber daya, transaksi, dan konsekuensi keuangan perusahaan.

Namun, keduanya dapat, dan sering kali seharusnya, beroperasi bersama.

Apakah ERP menghilangkan aplikasi khusus?

Tidak.

Arsitektur perusahaan yang matang harus mempertahankan aplikasi khusus apabila aplikasi tersebut menyediakan fungsionalitas domain yang lebih unggul.

ERP harus mengorkestrasinya.

Dapatkah ERP generik seperti SAP, Oracle, atau Dynamics berfungsi sebagai tulang punggung perusahaan?

Tentu saja.

Platform ERP perusahaan berskala besar dapat menyediakan tulang punggung korporat.

Namun, pertanyaan bagi kontraktor adalah apakah sistem tersebut secara bawaan memiliki logika bisnis khusus konstruksi yang memadai. Jika tidak, kontraktor memerlukan lapisan operasional konstruksi tambahan.

Apakah ProjectVIEW ERP hanya platform manajemen proyek?

Tidak.

Arsitektur ProjectVIEW ERP mencakup proses Komersial, Operasional, dan Keuangan. Selain itu, ProjectVIEW ERP memiliki kemampuan multi-perusahaan dan multi-proyek serta modul khusus konstruksi yang berbagi data perusahaan yang sama.

Dapatkah ProjectVIEW berdampingan dengan SAP atau Oracle?

Ya.

 

DANAOS mendukung integrasi dengan lingkungan ERP eksternal ketika grup korporat yang lebih besar ingin mempertahankan platform keuangan korporat yang sudah ada.

 

---

 

Pertanyaan Transformasi Digital yang Sesungguhnya

 

Selama satu dekade terakhir, industri konstruksi sangat berfokus pada digitalisasi proses-proses individual.

 

Itu memang diperlukan.

 

Namun, kita kini memasuki tahap berikutnya.

 

Tantangannya bukan lagi sekadar:

 

“Dapatkah kita mendigitalkan tugas ini?”

 

Tantangannya adalah:

 

“Dapatkah kita membuat setiap proses digital menggambarkan realitas bisnis yang sama?”

 

Hal itu membutuhkan arsitektur.

 

Selain itu, hal itu membutuhkan tata kelola.

 

Hal itu membutuhkan master data.

 

Bahkan, hal itu membutuhkan kesinambungan transaksi.

 

Hal itu membutuhkan keterhubungan antara lapangan dengan kantor, proyek dengan perusahaan, dan pada akhirnya progres fisik konstruksi dengan konsekuensi keuangannya.

 

Aplikasi untuk tujuan spesifik akan tetap penting.

 

Platform kolaborasi proyek akan tetap penting.

 

CDE akan tetap penting.

 

Aplikasi penjadwalan akan tetap penting.

 

BIM akan tetap penting.

 

Namun, kontraktor besar tetap membutuhkan sesuatu di pusatnya.

 

Sesuatu yang harus memahami perusahaan.

 

Sesuatu yang harus memahami sumber dayanya.

 

Sesuatu yang harus memahami setiap proyek.

 

Sesuatu yang harus mengubah aktivitas konstruksi menjadi biaya, pendapatan, arus kas, dan profitabilitas.

 

Sesuatu yang pada akhirnya harus merekonsiliasi:

 

Apa yang kita janjikan untuk dibangun

 

Kapan kita merencanakan untuk membangunnya. Sumber daya apa yang kita gunakan. Berapa biaya sebenarnya. Dan nilai apa yang kita peroleh.

 

Itulah peran ERP Konstruksi.

 

Aplikasi untuk tujuan spesifik mengoptimalkan tugas.

 

Platform berorientasi proyek mengoordinasikan proyek.

 

ERP Konstruksi mengelola perusahaan.

 

Akhirnya, di sinilah DANAOS ProjectVIEW ERP beroperasi:

 

bukan sebagai aplikasi tambahan di sekitar proyek konstruksi, melainkan sebagai tulang punggung perusahaan khusus konstruksi yang mengorkestrasi perusahaan di baliknya.

 

---

 

Sumber dan Bacaan Lanjutan

 

LinkedIn — Panduan Visibilitas Pencarian AI LinkedIn merekomendasikan artikel panjang sebagai aset untuk membangun otoritas dan menekankan terminologi yang jelas, judul berbentuk pertanyaan, bagian jawaban yang dapat berdiri sendiri, serta bahasa kategori yang konsisten untuk pengambilan informasi oleh AI. LinkedIn: How to Maximize AI Visibility for Your LinkedIn Posts

 

McKinsey — Fragmentasi Teknologi Konstruksi dan Integrasi Platform McKinsey: Rise of the Platform Era — The Next Chapter in Construction Technology

 

Oracle Primavera P6 Enterprise Project Portfolio Management Oracle Primavera P6 EPPM

 

Oracle Aconex — Kolaborasi Proyek dan Common Data Environment Manajemen Proyek Konstruksi Oracle Aconex

 

Integrasi ERP Procore Dokumentasi Integrasi ERP Procore

 

Autodesk Construction Cloud — Integrasi ERP dan Keuangan Autodesk: Integrasi ERP dan Keuangan Konstruksi

 

Trimble ProjectSight — Integrasi ERP Integrasi ERP Trimble ProjectSight

Trimble Viewpoint Vista — ERP Konstruksi ERP Konstruksi Trimble Vista

 

CMiC — ERP Konstruksi Platform ERP Konstruksi CMiC

 

Sage X3 Construction Sage X3 Construction ERP

 

Microsoft Dynamics 365 Project Operations Dokumentasi Microsoft Dynamics 365 Project Operations

 

DANAOS — ProjectVIEW OS dan Arsitektur BoQ ↔ WBS ↔ Kode Biaya ProjectVIEW OS: Sistem Operasi untuk Konstruksi

 

DANAOS — Mengapa ERP Harus Didahulukan sebelum AI Berjalan Sebelum Berlari: Mengapa ERP Didahulukan sebelum AI

 

DANAOS — Arsitektur SaaS dan Cakupan Fungsional ProjectVIEW ERP Kerangka Kerja SaaS Induk DANAOS ProjectVIEW ERP