BoQ, WBS, dan Cost Codes: Cara Kontraktor Menghubungkan Ruang Lingkup, Jadwal, dan Biaya

Bill of Quantities (BoQ), Work Breakdown Structure (WBS), dan Cost Codes tidak menjelaskan hal yang sama.

 

• BoQ menjelaskan ruang lingkup yang terukur dan komersial.
• WBS menjelaskan bagaimana dan kapan pekerjaan dilaksanakan.
• Cost Codes menjelaskan bagaimana kontraktor mengklasifikasikan dan mengendalikan sumber daya serta pengeluaran.

 

Bagi kontraktor kompleks, tujuannya bukan memaksa dimensi-dimensi ini ke dalam satu hierarki. Sebaliknya, tujuannya adalah membangun hubungan yang terkelola di antara dimensi-dimensi tersebut. Hasilnya, manajemen dapat menelusuri ruang lingkup fisik, jadwal, sumber daya, biaya, komitmen, progres, dan hasil keuangan kembali ke baseline proyek yang sama.

 

Singkatnya, itulah fondasi kontrol proyek terintegrasi.

 

Mengapa Proyek Memerlukan Tiga Struktur?

 

Dalam praktiknya, orang memandang proyek dari beberapa perspektif yang sah.

 

• Klien mungkin bertanya: Berapa kuantitas yang telah Anda serahkan dan berapa yang dapat Anda tagihkan?
• Planner bertanya: Aktivitas mana yang seharusnya sedang berjalan sekarang?
• Cost Controller bertanya: Anggaran dan Cost Code mana yang harus menyerap pengeluaran ini?
• Site manager bertanya: Sumber daya apa yang telah kita konsumsi untuk menghasilkan progres hari ini?
• Akhirnya, finance bertanya: Ke mana transaksi yang dihasilkan harus diposting?

 

Tentu saja, tidak satu pun dari pertanyaan ini yang salah.

 

Sebaliknya, kesalahannya adalah mengharapkan satu struktur untuk menjawab semuanya.

 

Kita semua sepakat bahwa: WBS saja tidak cukup untuk pengendalian biaya proyek

 

Pertanyaan berikutnya adalah: WBS harus dihubungkan dengan apa?

 

Bagi banyak lingkungan kontraktor, jawabannya dimulai dengan tiga dimensi:

 

BoQ ↔ WBS ↔ Kode Biaya

 

Apa yang Dikendalikan BoQ?

 

Bill of Quantities (BoQ), terutama, adalah representasi ruang lingkup yang terkuantifikasi dan komersial.

 

BoQ menjawab:

 

• Apa yang kita serahkan?
• Berapa banyak yang kita serahkan?
• Bagaimana pekerjaan itu diukur dan dinilai?

 

Satu baris BoQ dapat memuat:

 

• deskripsi;
• satuan pengukuran;
• kuantitas;
• tarif;
• nilai;
• klasifikasi komersial atau kontraktual.

 

Namun, saat estimasi dilakukan, BoQ menjadi jauh lebih kuat. Itu terjadi ketika estimator menguraikan setiap item yang terukur menjadi sumber daya yang diperlukan untuk memproduksinya.

 

Contohnya:

 

1 m³ beton bertulang

 

mungkin memerlukan:

 

• X jam kerja pada spesialisasi tertentu;
• Y ton tulangan;
• Z m³ ready-mix concrete;
• kuantitas bekisting yang ditentukan;
• jam alat berat;
• sumber daya subkontraktor.

 

DANAOS Projects memiliki model estimasi berbasis BoQ yang didasarkan pada cost recipes/productivity templates yang teruji di lapangan dan berdasarkan data site konstruksi yang realistis.

 

Karena itu, BoQ menjawab pertanyaan ekonomi yang tidak dapat dijawab jadwal semata:

 

Keluaran terukur apa yang harus dihasilkan oleh sumber daya ini?

 

Apa yang Dikendalikan WBS?

 

Work Breakdown Structure (WBS) mengorganisasi pelaksanaan proyek.

 

Struktur ini memecah proyek menjadi paket kerja yang semakin mudah dikelola dan dibatasi waktu. Selain itu, struktur ini menyediakan kerangka tempat tim mengorganisasi aktivitas, tanggung jawab, dan jadwal.

 

BoQ menjawab:

 

• Di mana pekerjaan ini berada?
• Bagaimana pelaksanaannya dipecah?
• Kapan harus terjadi?

 

U.S. GAO menyebut WBS sebagai landasan untuk mendefinisikan pekerjaan proyek dan membangun kerangka terintegrasi untuk jadwal, biaya, dan Earned Value Management.

 

Panduan Estimasi dan Penilaian Biaya GAO AS

 

Namun, WBS dan BoQ tidak dapat saling dipertukarkan.

 

• Satu item BoQ dapat berkontribusi pada beberapa aktivitas WBS.
• Sebaliknya, satu aktivitas WBS dapat mengonsumsi beberapa item BoQ atau tipe sumber daya.

 

Karena itu, hubungan tersebut dapat berupa:

 

satu-ke-satu

 

satu-ke-banyak

 

atau

 

banyak-ke-banyak

 

tergantung pada struktur komersial dan pelaksanaan proyek.

 

Karena alasan ini, pemetaan lebih berguna daripada memaksa struktur-struktur tersebut menjadi identik.

 

Apa yang Dikendalikan Cost Codes?

 

Cost Codes, atau Cost Control Accounts membentuk fungsi Cost Breakdown Structure (CBS), serta menyediakan lensa manajemen internal.

 

Mereka menjawab:

 

• Jenis biaya apakah ini?
• Harus terakumulasi di mana?
• Siapa yang bertanggung jawab atasnya?

 

Sebagai contoh, kontraktor mungkin ingin membedakan:

 

• tenaga kerja;
• beton;
• tulangan;
• bahan bakar;
• alat berat;
• subkontrak;
• pekerjaan sementara;
• biaya tidak langsung site;
• mobilisasi;
• overhead.

 

Tentu saja, klien tidak selalu perlu melihat proyek melalui struktur tersebut.

 

Demikian pula, scheduler tidak selalu perlu merencanakannya melalui struktur itu.

 

Namun, Cost Controller dan CFO perlu melakukannya.

 

Inilah sebabnya sistem kontrol proyek independen juga menjaga hubungan antara struktur pelaksanaan dan struktur biaya.

 

Sistem kontrol proyek enterprise yang independen juga mengakui perlunya lebih dari satu struktur proyek.

 

Oracle Primavera Unifier, misalnya, mendukung transaksi biaya proyek yang memuat baik kode WBS maupun CBS. Hasilnya, transaksi yang sama dapat dirangkum ke WBS Sheet dan Cost Sheet sekaligus.

 

Itu merupakan bukti penting bahwa kontrol proyek multidimensi tidak unik bagi DANAOS Projects.

Bagaimana Perbedaan BoQ ↔ WBS ↔ Cost Codes dibandingkan dengan WBS + CBS?

 

Namun, ada juga perbedaan arsitektural yang penting.

 

 

Bagi kontraktor, perbedaan itu sangat berarti.

 

• Sebuah Cost Breakdown Structure dapat memberi tahu manajemen di mana sebuah biaya berada.
• Demikian pula, WBS dapat memberi tahu manajemen di mana dan kapan tim melaksanakan pekerjaan.

 

Namun BoQ atau ruang lingkup terkuantifikasi yang setara menjawab pertanyaan penting lainnya:

 

Keluaran terukur apa yang sedang diserahkan, dalam kuantitas berapa, dan pada nilai komersial berapa?

 

Di sinilah arsitektur BoQ ↔ WBS ↔ Cost Codes pada ProjectVIEW ERP berbeda.

 

Dengan kata lain, BoQ menambahkan dimensi kuantitas dan komersial yang diperlukan untuk mengaitkan biaya dan jadwal kembali ke output fisik yang terukur.

 

Hal itu memungkinkan pertanyaan seperti:

 

• Berapa kuantitas yang seharusnya dihasilkan oleh aktivitas WBS ini?
• Sumber daya apa yang dianggarkan estimator per unit output?
• Kuantitas berapa yang benar-benar telah selesai?
• Sumber daya apa yang telah dikonsumsi kru untuk mencapainya?
• Berapa biaya satuan aktual yang dihasilkan?
• Berapa banyak material yang masih harus diamankan oleh pengadaan?
• Lalu, kuantitas berapa yang dapat disertifikasi atau ditagihkan oleh kontraktor?
• Bagaimana kuantitas yang tersisa akan memengaruhi cost-to-complete?

 

Singkatnya, perbedaannya adalah:

 

WBS + CBS = Di mana pekerjaan berada, dan biaya dibebankan ke mana?

 

BoQ + WBS + Cost Codes = Apa yang kita serahkan, di mana dan kapan kita menyerahkannya, dan berapa biayanya bagi kita?

 

 

BoQ × WBS × Cost Codes: Tiga Dimensi dari Realitas Proyek yang Sama

 

Singkatnya, model DANAOS Projects adalah:

 

• BoQ = Ruang Lingkup / Kuantitas / Dimensi Komersial
• WBS = Eksekusi / Dimensi Waktu
• Cost Codes = Klasifikasi Biaya / Dimensi Pengendalian

 

DANAOS menyebut model itu sebagai baseline kinerja proyek terintegrasi.

 

Namun, nilainya tidak semata-mata berasal dari memiliki ketiga struktur tersebut.

 

Sebaliknya, nilai itu berasal dari menjaga hubungan di antara ketiganya.

 

Pertimbangkan satu paket konkret.

 

• BoQ menyatakan: 10.000 m³ beton bertulang
• WBS menyatakan: Pier P05 → Foundation → Concrete Pour 03 → Week 27
• Cost Codes menyatakan: Labour / Concrete / Reinforcement / Formwork / Plant

 

Akibatnya, organisasi kini dapat mengaitkan:

 

apa yang sedang diserahkan

 

dengan

 

di mana dan kapan itu dieksekusi

 

dengan

 

apa biayanya seharusnya

 

dan akhirnya dengan:

 

sumber daya apa yang benar-benar dikonsumsi.

 

Apa yang Menjadi Mungkin Setelah Ketiga Struktur Terkoneksi?

 

1. Penjadwalan berbasis biaya

 

Pertama, planner dapat memecah waktu sumber daya dan anggaran dari lingkup yang terukur melalui aktivitas WBS terkait.

 

Sebagai hasilnya, organisasi dapat melihat bukan hanya berapa biaya proyek akan terjadi, tetapi kapan eksposur ekonomi kemungkinan akan terjadi.

 

2. Perencanaan pengadaan

 

Sebagai contoh, satu item BoQ dapat memerlukan 500 ton reinforcement, dan aktivitas WBS yang terkait dapat dimulai pada Minggu 30. Dalam kasus itu, pengadaan dapat menghitung kuantitas material yang dibutuhkan dan bekerja mundur dari tanggal kebutuhan.

 

Hal ini mengubah pembelian dari:

 

“Site meminta material.”

 

menjadi:

 

“Baseline proyek memprediksi kebutuhan material ini.”

 

3. Pengukuran produktivitas

 

Demikian pula, jika estimasi menetapkan sumber daya yang dibutuhkan per unit output, eksekusi aktual dapat membandingkan:

 

• Kuantitas yang dianggarkan vs kuantitas aktual
• Tenaga kerja: budgeted vs actual
• Alat berat yang dianggarkan vs alat berat aktual
• Biaya satuan yang dianggarkan vs biaya satuan aktual

 

Produktivitas menjadi hubungan antara output dan upaya, bukan sekadar jam kerja.

 

4. Earned Value Management

 

Selain itu, tim dapat mengaitkan kemajuan fisik dengan nilai anggaran dari pekerjaan yang selesai.

 

DANAOS Projects telah mengulas hal ini lebih lanjut dalam pembahasan tentang Earned Value and construction performance control.

 

5. Forecast cost-to-complete

 

Akhirnya, ketika produktivitas aktual, biaya yang telah berkomitmen, dan kuantitas sisa terlihat bersama, proyeksi dapat merespons realitas eksekusi, bukan sekadar mengekstrapolasi pengeluaran akuntansi historis.

 

Apa yang Terjadi Ketika Struktur-Struktur Itu Terputus?

 

Dalam praktik, konsekuensinya biasanya muncul sebagai pekerjaan rekonsiliasi.

 

• Perencanaan mempertahankan Primavera P6.
• Sementara itu, estimator menyimpan BoQ dan anggaran asli di Excel atau platform estimating lainnya.
• Pengadaan mengelola pembelian berdasarkan material master.
• Akuntansi membukukan pengeluaran terhadap akun keuangan.
• Akhirnya, tim lapangan melaporkan kemajuan secara terpisah.

 

Akibatnya, organisasi secara teknis memiliki semua data.

 

Namun, hubungan kausal antar data lemah.

 

Consequently, manajemen menghabiskan waktu menjawab pertanyaan seperti:

 

• Aktivitas mana yang menimbulkan biaya ini?
• PO ini mendukung kuantitas BoQ yang mana?
• Output fisik apa yang dihasilkan oleh jam kerja ini?
• Variasi yang mana yang menyebabkan kenaikan forecast?
• Mengapa jadwal baru 70% selesai sementara konsumsi sumber daya sudah 85%?

 

DANAOS Projects telah mengulas masalah yang lebih luas ini dalam The Failure of Generalist ERPs in Capital Projects.

 

Dengan kata lain, persoalannya bukan terutama apakah masing-masing sistem berfungsi dengan benar.

 

Sebaliknya, persoalannya adalah apakah mereka mendeskripsikan realitas proyek yang sama.

 

Bagaimana Ini Bekerja pada Megaproject dengan Banyak Kontraktor?

 

Hal ini menjadi jauh lebih penting di level owner atau program.

 

Misalnya, sebuah megaproject dapat melibatkan beberapa kontraktor, masing-masing dengan:

 

• WBS miliknya sendiri;
• hierarki area fisik yang berbeda;
• Cost Codes miliknya sendiri;
• struktur subkontrak yang berbeda;
• ribuan aset dan objek handover;
• metode yang berbeda untuk mengukur kemajuan fisik.

 

Tidak realistis untuk mengasumsikan bahwa setiap kontraktor akan menggunakan hierarki eksekusi yang identik.

 

Karena itu, solusinya tidak selalu dengan memaksakan satu WBS universal yang sangat besar.

 

Sebaliknya, pendekatan yang lebih kuat adalah membuat dimensi normalisasi bersama di atas atau lintas struktur kontraktor.

 

Hal ini dapat mencakup:

 

• fase proyek;
• disiplin;
• kelas pekerjaan;
• area fisik;
• sistem;
• aset;
• deliverable;
• kontraktor;
• weighted worksteps.

 

Owner kemudian dapat mengaitkan aset atau deliverable dengan WBS masing-masing kontraktor. Pada saat yang sama, owner tetap mengklasifikasikannya melalui dimensi owner yang umum.

 

Akibatnya, owner dapat menganalisis kemajuan berdasarkan:

 

• Kontraktor
• Area
• Disiplin
• Fase Proyek
• Kelas Pekerjaan
• Aset/Sistem

 

sambil tetap mempertahankan struktur eksekusi detail masing-masing kontraktor.

 

Pada gilirannya, hal itu menciptakan fondasi yang lebih kuat untuk kurva S yang dinormalisasi, perbandingan kemajuan lintas kontraktor, dan verifikasi klaim kemajuan yang dapat diaudit.

 

Singkatnya, prinsipnya sama:

 

jangan memaksa setiap pertanyaan kontrol masuk ke satu hierarki saja—pertahankan hubungan antar dimensi yang dikelola.

 

Bagaimana ProjectVIEW ERP Menerapkan Model Ini?

 

ProjectVIEW ERP dibangun di atas asosiasi yang eksplisit:

 

BoQ ↔ WBS ↔ Kode Biaya

 

ProjectVIEW ERP Cost Control Module mendokumentasikan hubungan ini bersama integrasi Oracle Primavera P6/MS Project, alokasi sumber daya, berbagai versi BoQ/WBS, progres aktual di lapangan, tenaga kerja, plant, aktivitas subkontraktor, serta biaya aktual vs anggaran.

 

ProjectVIEW ERP Budget Estimation & Bidding Module menetapkan baseline yang terkuantifikasi dan berbasis sumber daya. Terhadap baseline ini, kontraktor kemudian mengendalikan eksekusi.

 

Selain itu, ProjectVIEW OS for the BUILD World yang lebih luas memperluas prinsip ini ke dalam model data proyek terstruktur yang ditujukan untuk mendukung konstruksi, marine/offshore, mining, shipbuilding, dan lingkungan lain yang digerakkan proyek.

 

Namun, tujuannya bukan sekadar menampilkan tiga kode pada transaksi yang sama.

 

Sebaliknya, tujuannya adalah memungkinkan pengadaan, sumber daya, subkontraktor, progres lapangan, komitmen, biaya, dan transaksi keuangan mewarisi konteks proyek yang sama.

 

Model Ini Juga Berlaku di Luar Konstruksi

 

Terminologi akan berbeda menurut industrinya.

 

• Sebuah galangan kapal mungkin menggunakan Job Lists, vessel systems, blocks, production work packages, dan repair items.
• Demikian pula, kontraktor marine dapat mengorganisasi pekerjaan berdasarkan vessel, lokasi offshore, kuantitas pengerukan, atau paket instalasi.
• Kontraktor mining dapat mengorganisasi eksekusi berdasarkan area, kuantitas produksi, aktivitas pengembangan, dan armada peralatan.
• Akhirnya, produsen berbasis proyek dapat menggunakan bills of materials, production orders, dan engineered assemblies.

 

ProjectVIEW ERP menyesuaikan model ini ke struktur operasional yang berbeda-beda tersebut.

 

Prinsip universalnya adalah:

 

Ruang Lingkup Terkuantifikasi ↔ Struktur Eksekusi ↔ Struktur Biaya

 

Nama-namanya mungkin berubah.

 

Namun, kebutuhan untuk menghubungkannya tidak berubah.

 

Apa yang Harus Diuji oleh Kontraktor Enterprise?

 

Arsitektur project controls yang praktis harus mampu menjawab:

 

1. Dapatkah Anda menelusuri setiap biaya proyek yang signifikan ke ruang lingkup dan eksekusi?
2. Dapatkah satu item BoQ dipetakan ke beberapa aktivitas WBS bila diperlukan?
3. Demikian pula, dapatkah satu aktivitas WBS menyerap beberapa kategori biaya?
4. Dapatkah kemajuan fisik aktual dikaitkan dengan kuantitas yang terukur?
5. Dapatkah pengadaan menurunkan kebutuhannya dari baseline proyek dan tanggal kebutuhan WBS?
6. Demikian juga, dapatkah tim mengaitkan konsumsi tenaga kerja dan alat berat dengan output yang dihasilkannya?
7. Dapatkah committed cost ditelusuri ke ruang lingkup sebelum invoice ada?
8. Dapatkah variasi mempertahankan hubungan antara BoQ, WBS, Cost Codes, dan revenue?
9. Selain itu, dapatkah manajemen menganalisis proyek berdasarkan beberapa dimensi tanpa menduplikasi data?
10. Dapatkah transaksi operasional pada akhirnya direkonsiliasi dengan keuangan korporat?

 

Jika sistem tidak dapat menjawab pertanyaan-pertanyaan ini secara konsisten, menambah satu dashboard lagi mungkin tidak akan menyelesaikan masalah yang mendasarinya.

 

Sebaliknya, masalahnya kemungkinan bersifat struktural.

 

Kesimpulan: Integrasi Lebih Penting daripada Hirarki

 

BoQ, WBS, dan Cost Codes menjalankan pekerjaan yang berbeda.

 

Akibatnya, mencoba melebur semuanya ke dalam satu struktur dapat menghilangkan konteks yang berguna.

 

Memisahkannya sepenuhnya menciptakan kebutuhan rekonsiliasi.

 

Karena itu, pendekatan yang lebih baik adalah relasional.

 

BoQ memberi tahu kita apa dan berapa banyak.

 

WBS memberi tahu kita di mana, kapan, dan dalam urutan apa.

 

Cost Codes memberi tahu kita sumber daya dan kategori biaya apa yang dikonsumsi proyek.

 

Ketika dimensi-dimensi itu tetap terhubung, kontraktor dapat mengikuti rantai penuh:

 

Estimasi → Anggaran → Jadwal → Pengadaan → Eksekusi → Kemajuan → Biaya → Forecast → Hasil Keuangan

 

Itulah nilai sesungguhnya dari BoQ ↔ WBS ↔ Cost Codes.

 

Bukan tiga kode.

 

Tiga tampilan terkoordinasi dari realitas proyek yang sama.