)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
Pemilihan ERP perusahaan membutuhkan dua keputusan: memilih platform yang sesuai dengan bisnis dan memilih mitra yang mampu mengimplementasikan, mendukung, dan terus menyempurnakannya. Bagi organisasi berbasis proyek, ini berarti mengevaluasi keahlian industri, pengendalian proyek yang terhubung, akuntabilitas implementasi, adopsi pengguna, integrasi, dan kesinambungan layanan jangka panjang. Daftar fitur memang berguna, tetapi tidak dapat menunjukkan bagaimana sistem—dan orang-orang di baliknya—akan bekerja ketika proyek berubah, integrasi gagal, atau tim lapangan membutuhkan dukungan.
Misalnya, demonstrasi ERP dapat menunjukkan bahwa sistem mampu membuat pesanan pembelian, mencatat biaya, dan menghasilkan dasbor.
Namun, demonstrasi itu belum tentu menunjukkan apakah solusi tersebut akan menghubungkan permintaan dari lapangan dengan lingkup dan anggaran. Selain itu, solusi harus terhubung dengan aktivitas terjadwal, wewenang persetujuan, dan konsekuensi keuangan yang tepat.
Bahkan, demonstrasi itu juga tidak menetapkan siapa yang bertanggung jawab ketika keterhubungan tersebut tidak berjalan.
Karena itulah saya meyakini bahwa evaluasi ERP perusahaan harus menjawab dua pertanyaan:
Apakah platform ini memahami cara bisnis kami beroperasi?
Apakah penyedia ini dapat membantu kami mengimplementasikan, mengoperasikan, dan terus menyempurnakannya?
Perspektif siklus hidup ini tercermin dalam panduan implementasi Dynamics 365 dari Microsoft. Panduan ini mencakup strategi dan implementasi hingga persiapan dan operasi berkelanjutan. Dengan kata lain, perjalanan aplikasi perusahaan tidak berakhir pada saat penerapan.
Karena itu, bagi kontraktor dan organisasi berbasis proyek lainnya, evaluasi harus melampaui perbandingan modul. Evaluasi menuju ujian yang jauh lebih menuntut: kesesuaian operasional, dengan bukti dari proses bisnis nyata dan dukungan akuntabilitas yang jelas.
1. Keahlian industri harus dibuktikan melalui logika bisnis
Penyedia ERP harus memahami lebih dari sekadar istilah yang lazim di perusahaan konstruksi.
Sebaliknya, penyedia harus memahami hubungan antara komitmen komersial perusahaan, proses produksi, sumber daya, dan hasil keuangannya.
Sebagai contoh, perhatikan tiga struktur proyek yang berbeda.
- Bill of Quantities—BoQ—mengidentifikasi item pekerjaan terukur beserta kuantitasnya. Analisis sumber daya terhadap item-item tersebut dapat mendukung estimasi biaya internal kontraktor. Namun, harga jual kepada klien dan biaya pelaksanaan internal tidak otomatis sama.
- Work Breakdown Structure—WBS—menata lingkup proyek menjadi komponen yang terkelola. Jadwal terkait memperkenalkan aktivitas, ketergantungan, durasi, dan tanggal. Karena itu, WBS itu sendiri tidak sama dengan jadwal secara keseluruhan.
- Kode Biaya menyediakan klasifikasi internal untuk mengakumulasi, menganalisis, dan merekonsiliasi pengeluaran serta biaya sumber daya.
Practice Standard for Work Breakdown Structures dari Project Management Institute menggambarkan WBS sebagai struktur untuk menata seluruh lingkup proyek. Perbedaan ini penting ketika menilai apakah penyedia benar-benar memahami pengendalian proyek. Sebaliknya, penyedia mungkin hanya memakai singkatan yang sudah umum.
DANAOS Insights membahas hubungan antara dimensi-dimensi ini dalam Menetapkan Baseline Kinerja Proyek. Artikel itu menghubungkan BoQ, WBS, klasifikasi biaya, perencanaan sumber daya, dan otorisasi pekerjaan.
Singkatnya, ujian praktisnya sederhana:
Dapatkah penyedia menjelaskan bagaimana perubahan kuantitas memengaruhi kebutuhan sumber daya, pengadaan, pelaksanaan, biaya, dan prakiraan—bukan hanya cara memasukkan perubahan tersebut?
Namun, hal ini tidak membenarkan klaim bahwa platform perusahaan umum tidak memiliki fungsi proyek. Oracle, misalnya, mendokumentasikan transaksi Primavera Unifier yang memuat kode CBS dan WBS sekaligus. Fungsi itu nyata. Namun, fungsi itu sendiri tidak membuktikan apakah implementasi tertentu menghadirkan alur kerja operasional berbasis BoQ yang lengkap bagi kontraktor.
Evaluasi konfigurasi dan proses dalam proposal—bukan stereotip tentang vendornya.
2. Ganti demonstrasi yang terpisah-pisah dengan pengujian proyek menyeluruh
Karena itu, saran saya adalah memberikan satu skenario proyek yang representatif kepada penyedia dalam daftar pendek. Kemudian, minta mereka mendemonstrasikan seluruh urutannya.
Misalnya, gunakan paket pekerjaan fondasi sebagai ilustrasi. Ini adalah skenario evaluasi, bukan studi kasus pelanggan.
Mulailah dengan lingkup terukur dan estimasi berbasis sumber daya. Selanjutnya, tetapkan anggaran resmi, kaitkan pekerjaan dengan jadwal proyek, dan tentukan kode biaya yang relevan.
Kemudian, minta penyedia mendemonstrasikan bagaimana informasi yang sama mendukung:
Permintaan dari lapangan, persetujuan, pesanan pembelian, pengiriman, dan pemakaian material. Selain itu, catatan tenaga kerja dan alat berat, progres terukur, sertifikat subkontraktor, dan posisi biaya akhirnya.
Selanjutnya, tambahkan perubahan.
Naikkan kuantitas. Tunda pengiriman. Tolak sebagian pekerjaan setelah inspeksi. Catat waktu menganggur peralatan tambahan. Akhirnya, ajukan variasi yang belum mendapat persetujuan.
Sekarang, periksa apakah sistem mempertahankan perbedaan-perbedaan yang penting:
Misalnya, material yang tiba belum tentu material yang terpakai.
Demikian pula, material yang terpakai belum tentu progres fisik yang lolos inspeksi.
Selain itu, biaya yang terjadi belum tentu variasi yang klien setujui.
Terakhir, revisi prakiraan tidak boleh diam-diam menimpa baseline awal yang resmi.
Di setiap tahap, tanyakan: Siapa yang mencatat kejadiannya, siapa yang mengotorisasi, apa yang berubah di tahap selanjutnya, dan bukti apa yang tersisa?
Panduan strategi pengujian ERP dari Microsoft, misalnya, menekankan persyaratan bisnis, hasil pengujian yang terdokumentasi, kesiapan produksi, dan persetujuan pengguna bisnis. Semua ini merupakan landasan penerimaan yang lebih kuat daripada sekadar demonstrasi yang rapi.
Namun, tujuannya bukan membuat demonstrasi menjadi sulit.
Sebaliknya, tujuannya adalah mengetahui apakah solusi tersebut tetap koheren ketika proyek menjadi sulit.
3. Kemampuan implementasi adalah bagian dari apa yang Anda beli
Platform yang andal tidak mengonfigurasi dirinya sendiri sesuai organisasi.
Karena itu, implementasi harus menetapkan bagaimana perusahaan, proyek, pengguna, sumber daya, pemasok, anggaran, hak akses, dan alur kerja akan beroperasi bersama.
Panduan strategi implementasi dari Microsoft secara eksplisit membahas tujuan bisnis, ukuran keberhasilan, serta tanggung jawab pelanggan dan mitra. Selain itu, panduan ini membahas metodologi, umpan balik, dan adopsi. Panduan ini memperlakukan implementasi sebagai upaya bisnis dan teknologi yang terkoordinasi.
Bagi pembeli perusahaan, saya menerjemahkannya menjadi tiga persyaratan.
- Pertama, temui tim pelaksana—bukan hanya tim penjualan. Tanyakan siapa yang akan memimpin desain proses, migrasi data, integrasi, pelatihan, dan dukungan pasca-go-live. Periksa pengalaman relevan dan ketersediaan mereka yang sebenarnya.
- Kedua, klasifikasikan setiap persyaratan penting. Apakah persyaratan itu tersedia dalam produk standar atau melalui konfigurasi? Atau, apakah persyaratan itu bergantung pada integrasi, memerlukan pengembangan khusus, atau masih ada dalam peta jalan?
- Ketiga, tetapkan kriteria penerimaan sebelum pengembangan mulai. Sepakati perilaku sistem, data uji, pengguna yang bertanggung jawab, dan bukti untuk persetujuan.
Dengan kata lain, “Kami dapat mendukung itu” tidak cukup tepat.
Sebaliknya, pembeli perlu mengetahui bagaimana caranya, oleh siapa, dengan biaya berapa, dengan ketergantungan apa, dan berdasarkan kriteria penerimaan apa.
DANAOS menggambarkan kombinasi pengetahuan industri, implementasi, dan dukungan berkelanjutan melalui Integrated Digital Delivery. Pembeli sebaiknya menerjemahkan setiap proposisi layanan semacam itu—termasuk milik kami—menjadi rencana implementasi yang spesifik dan sudah menjadi kesepakatan.
Singkatnya, mitra tepercaya seharusnya memperjelas perbedaan-perbedaan tersebut, bukan mengaburkannya.
4. Integrasi harus menjaga makna, bukan sekadar memindahkan data
Tentu, sebuah antarmuka dapat berhasil mentransfer transaksi, tetapi tetap membiarkan proses bisnis tidak terkendali dengan baik.
Misalnya, pesanan pembelian mungkin sampai ke ERP korporat. Namun, sistem penerima mungkin tidak mempertahankan alokasi proyek, status persetujuan, atau hubungannya dengan anggaran yang mendasarinya.
Karena itulah evaluasi integrasi harus menelaah lebih dari sekadar konektivitas.
Tanyakan sistem mana yang memiliki setiap data induk. Tetapkan arah dan frekuensi pertukaran data. Selain itu, tentukan cara memperbaiki transaksi yang gagal, cara mencegah duplikasi, dan cara melakukan rekonsiliasi.
Yang terpenting, identifikasi siapa yang bertanggung jawab ketika sebuah proses melintasi batas antara dua sistem.
Daftar periksa strategi integrasi dan tata kelola dari Microsoft merekomendasikan pengujian integrasi dalam kondisi realistis serta penelaahan dampaknya di hulu dan hilir.
DANAOS Insights membahas hubungan antara proyek dan keuangan dalam Kode Biaya dalam ProjectVIEW ERP: Integrasi dengan Oracle Fusion dan SAP. Pendekatan dalam artikel tersebut menggunakan pemetaan kode biaya untuk menghubungkan operasi proyek dengan pelaporan perusahaan.
Akibatnya, hal ini menimbulkan pilihan arsitektur yang penting.
Kontraktor dapat mengadopsi ERP konstruksi terintegrasi di seluruh operasinya, atau mempertahankan platform korporat dan menghubungkan sistem operasional khusus konstruksi ke dalamnya. Ikhtisar integrasi ERP pihak ketiga dari DANAOS menjelaskan peran ProjectVIEW ERP baik sebagai pelengkap maupun pengganti. Namun, tim tetap perlu merancang dan memvalidasi lingkup yang tepat untuk setiap organisasi.
Mitra yang kredibel seharusnya merekomendasikan arsitektur yang sesuai dengan bisnis—bukan secara otomatis program penggantian terbesar.
5. Adopsi pengguna adalah hasil proses, bukan jumlah login
Pertama, masuk ke ERP tidak membuktikan bahwa seseorang menggunakannya secara efektif.
Misalnya, bagi insinyur lapangan, adopsi dapat berarti mencatat progres pada paket pekerjaan yang benar. Adopsi juga berarti mengajukan kebutuhan material melalui proses resmi dan melampirkan bukti untuk peninjauan.
Sementara itu, bagi bagian pengadaan, adopsi dapat berarti memproses permintaan pembelian tanpa membuat ulang informasi di spreadsheet lain.
Akhirnya, bagi bagian keuangan, adopsi dapat berarti menelusuri biaya kembali ke transaksi operasional yang menghasilkannya.
Karena itu, saya akan mengukur adopsi melalui kualitas dan kelengkapan proses bisnis, bukan sekadar jumlah akun aktif.
Indikator yang berguna antara lain proporsi transaksi wajib yang tuntas di dalam sistem dan jeda antara kejadian di lapangan dan pencatatannya. Selain itu, ukur frekuensi pengajuan yang gagal dan jumlah rekonsiliasi manual yang masih tersisa.
Daftar periksa manajemen perubahan dari Microsoft mencakup pengujian skenario kerja sehari-hari, umpan balik pelatihan, transfer pengetahuan, serta pengukuran adopsi dan penggunaan.
Organisasi Pembelajar: Bagaimana ProjectVIEW ERP Mempercepat Transformasi Digital dari DANAOS mengembangkan keterkaitan antara proses yang terstandardisasi, retensi pengetahuan, dan pembelajaran operasional yang berkelanjutan.
Pendekatan onboarding dan pelatihan ProjectVIEW ERP mencakup sesi terstruktur, champion dari pihak klien, materi rekaman, dan dukungan tindak lanjut. Pembeli dapat memeriksa elemen konkret ini ketika menilai rencana adopsi.
Namun, tujuannya bukan membuat karyawan bergantung pada penyedia untuk setiap tindakan rutin.
Tujuannya adalah membuat organisasi semakin mampu mengoperasikan sistem dengan baik.
6. Mitra yang kuat tidak dapat menggantikan kepemimpinan yang berkomitmen
Penyedia memiliki tanggung jawab. Begitu pula klien.
Pertama, penyedia harus memberikan fungsi sesuai kesepakatan, menjelaskan keterbatasan, mendukung pengguna, dan mengelola kewajiban pelaksanaannya.
Sementara itu, klien harus menunjuk pemilik proses, menyediakan dan memvalidasi data, mengalokasikan waktu pengguna, menyelesaikan perbedaan pendapat internal, dan menetapkan wewenang persetujuan.
Bahkan, tidak ada penyedia perangkat lunak yang dapat memutuskan atas nama kontraktor departemen mana yang memiliki proses bisnis yang menjadi sengketa. Penyedia juga tidak dapat menentukan eksekutif mana yang berwenang menyetujui komitmen luar biasa.
DANAOS Insights menegaskan hal ini dalam Mendobrak Silo: Mengapa Komitmen Manajemen Sangat Penting bagi Keberhasilan ERP di Konstruksi, dengan menekankan sponsor, alokasi sumber daya, dan keterlibatan kepemimpinan yang berkelanjutan.
Microsoft juga merekomendasikan manajemen perubahan yang sebanding dengan risiko dan kompleksitas organisasi, alih-alih memperlakukannya sebagai aktivitas umum di akhir implementasi.
Pandangan saya adalah bahwa mitra ERP tepercaya harus bersedia menantang klien secara konstruktif.
Misalnya, hal itu dapat berarti mengidentifikasi klasifikasi biaya yang tidak konsisten atau tanggung jawab yang tidak jelas. Selain itu, mitra dapat menolak usulan kustomisasi yang hanya mereproduksi proses yang tidak efisien.
Menyetujui setiap permintaan tidak sama dengan bertindak demi kepentingan klien.
7. Tetapkan hasil bisnis sebelum menghitung modul yang diterapkan
Tonggak penerapan memberi tahu manajemen apa yang telah terpasang.
Namun, tonggak itu, dengan sendirinya, tidak menunjukkan apa yang telah membaik.
Karena itu, saya akan menetapkan sejumlah kecil ukuran operasional sebelum peluncuran, dengan penanggung jawab yang jelas dan metode perhitungan bersama.
Visibilitas komersial dan biaya: Dapatkah tim mengidentifikasi anggaran saat ini, biaya aktual, komitmen yang belum terealisasi, dan sisa prakiraan tanpa penghitungan ganda? Seberapa cepat tim dapat menilai dampak suatu perubahan?
Pelaksanaan dan produktivitas: Dapatkah tim mengaitkan jam kerja, penggunaan peralatan, dan pemakaian material yang tercatat dengan hasil fisik yang sesuai? Selain itu, apakah tim membandingkannya terhadap lingkup, satuan, dan aturan pengukuran yang konsisten?
Keandalan proses: Berapa lama tim memerlukan waktu untuk menyetujui permintaan pembelian, menyelesaikan pengecualian data, atau merekonsiliasi catatan proyek dan korporat? Solusi sementara apa yang masih tersisa?
Tentu saja, ini adalah usulan ukuran evaluasi, bukan klaim tentang persentase perbaikan yang pasti.
Digital, Data and Technology Playbook dari pemerintah Inggris memberikan prinsip pengadaan yang berguna. Prinsip itu berfokus pada kebutuhan pengguna, hasil, dan nilai sepanjang siklus hidup, alih-alih memperlakukan pembelian solusi awal sebagai keseluruhan keputusan. Pemerintah Inggris menulis panduan ini untuk pengadaan publik; namun, prinsip evaluasinya juga berguna bagi pembeli perusahaan.
Oleh karena itu, business case ERP harus membuat target perbaikan dapat diuji.
8. Dukungan jangka panjang harus spesifik secara operasional
“Termasuk dukungan” menyisakan terlalu banyak pertanyaan.
Misalnya, pengguna mana yang mendapat dukungan? Pada jam berapa dan dalam bahasa apa? Siapa yang menangani integrasi yang gagal? Bagaimana tim mengeskalasi insiden mendesak? Siapa yang menguji pembaruan sebelum masuk ke lingkungan produksi?
Panduan strategi dukungan dari Microsoft memisahkan lingkup, tim, dan operasi dukungan. Panduan ini juga membahas jam layanan, wilayah geografis, bahasa, prioritas, dan eskalasi.
Bagi kontraktor, saya akan menguji model layanan tersebut dengan situasi praktis:
Sebuah lokasi proyek tidak dapat mengajukan permintaan pembelian yang mendesak, persetujuannya terhambat, dan tim yang bertanggung jawab berada di zona waktu lain. Apa yang terjadi selanjutnya?
Karena itu, jawabannya harus mengidentifikasi saluran pelaporan, penanggung jawab insiden, jalur eskalasi, solusi sementara bagi bisnis, dan proses komunikasi.
Selain itu, perjanjian tingkat layanan harus membedakan respons dari pemulihan dan penyelesaian akhir. Menerima tiket tidak sama dengan memulihkan proses yang terdampak.
Model dukungan ProjectVIEW ERP dari DANAOS menjelaskan pengelolaan tiket, manajemen masalah, dan eskalasi berdasarkan persyaratan tingkat layanan. Namun, klien harus memeriksa komitmen yang tepat terhadap lingkup layanan dalam kontraknya.
Kualitas hubungan menjadi terlihat ketika terjadi masalah—bukan hanya ketika semuanya berjalan normal.
9. Kepercayaan mencakup transparansi tentang kesinambungan, biaya, dan pengakhiran
Hubungan jangka panjang tidak seharusnya bergantung pada membuat pengakhiran menjadi tidak praktis.
Saran saya adalah menilai pengaturan kesinambungan dan pengakhiran sebelum penandatanganan, bersama dengan implementasi dan dukungan.
Tanyakan bagaimana organisasi dapat mengambil kembali data, dokumen, riwayat transaksi, dan informasi konfigurasi yang relevan. Tetapkan format, tanggung jawab, dan biaya terkait.
Tinjau kapasitas pelaksanaan penyedia, arah produk, dan ketergantungan pada individu kunci. Selain itu, periksa bukti keamanan dan pemulihan yang sesuai dengan model penerapan pilihan.
Kemudian, evaluasi gambaran komersial secara utuh: implementasi, langganan, integrasi, kustomisasi, pelatihan, peningkatan versi, upaya staf internal, dan transisi pada akhirnya.
Bagian uji tuntas pemasok dan perencanaan pengakhiran dalam UK Digital, Data and Technology Playbook secara eksplisit membahas kondisi keuangan pemasok, kesinambungan, dan perencanaan dini untuk transfer pengetahuan dan data.
Mitra yang kredibel seharusnya nyaman membahas isu-isu ini.
Kepercayaan menjadi lebih kuat ketika tanggung jawab jelas dan klien tetap memegang kendali atas informasi bisnisnya.
10. AI membuat pemilihan ERP yang disiplin menjadi lebih penting—bukan sebaliknya
Namun, demonstrasi AI tidak boleh menghilangkan kebutuhan untuk mengevaluasi logika bisnis, hak akses, dan akuntabilitas.
Untuk setiap kemampuan AI dalam proposal, tanyakan data apa yang dapat diaksesnya dan bagaimana tim memeriksa keluarannya. Selain itu, tanyakan tindakan apa yang dapat dilakukannya dan di mana persetujuan manusia tetap wajib.
Bedakan juga dengan jelas antara fungsi yang tersedia saat ini, uji coba terkendali, dan peta jalan masa depan.
Misalnya, NIST AI Risk Management Framework menyediakan landasan yang kredibel untuk memasukkan aspek keterpercayaan dan manajemen risiko ke dalam desain, pengembangan, penggunaan, dan evaluasi sistem AI.
Ekosistem ProjectVIEW AI dari DANAOS menampilkan sumber daya bantuan informasi dan pengetahuan yang tersedia saat ini, bersama arah yang lebih luas untuk agen AI dan operasi cerdas. Karena itu, pembeli sebaiknya memverifikasi ketersediaan dan persyaratan penerapan setiap kasus penggunaan. Pembeli tidak boleh memperlakukan visi keseluruhan sebagai daftar fitur yang sudah lengkap.
Pandangan DANAOS Projects adalah bahwa AI harus beroperasi di sekitar data proyek dan proses bisnis yang terkendali.
Dengan kata lain, pertanyaan yang relevan bukan sekadar, “Apakah ERP ini memiliki AI?”
Melainkan: “Dapatkah kami memahami, mengatur, dan memverifikasi tindakan AI-nya?”
Bagaimana ProjectVIEW ERP sesuai dengan evaluasi ini
DANAOS membangun arsitektur ProjectVIEW ERP dengan menghubungkan BoQ, WBS, dan Kode Biaya di seluruh proses komersial, operasional, dan keuangan.
DANAOS Insights menjelaskan pendekatan ini dalam Bagaimana ProjectVIEW ERP Mencapai Pengendalian Biaya yang Sesungguhnya: Mendalami Arsitektur Modul Terintegrasi. Artikel tersebut menjelaskan bagaimana estimasi, pengadaan, transaksi lapangan, subkontrak, dan informasi keuangan berkontribusi pada struktur pengendalian proyek yang sama.
Bagi organisasi yang sedang melakukan evaluasi, proposisi yang relevan adalah kombinasi fungsi khusus proyek dan layanan untuk menjalankannya.
Namun, pembeli harus menerapkan disiplin evaluasi yang sama pada ProjectVIEW seperti pada setiap platform lain dalam daftar pendek.
Minta kami mendemonstrasikan proses Anda. Periksa rancangan integrasinya. Temui tim implementasi. Sepakati kriteria penerimaan. Tinjau rencana adopsi dan tanggung jawab dukungan.
Proposisi kemitraan hanya bermakna jika pembeli dapat mengujinya.
Penutup
Pembeli ERP perusahaan memilih lebih dari sekadar perangkat lunak.
Sebaliknya, mereka memilih logika bisnis, kemampuan pelaksanaan, tanggung jawab operasional, dan hubungan yang harus berlanjut setelah go-live.
Platform yang tepat tidak dapat menutupi implementasi yang tidak efektif.
Demikian pula, mitra yang tepat tidak dapat menutupi ketidaksesuaian produk yang mendasar.
Dan keduanya tidak dapat menutupi organisasi yang tidak mau memiliki proses dan keputusannya sendiri.
Karena itu, pemilihan ERP terbaik menjawab satu pertanyaan yang menuntut:
Platform dan mitra mana yang dapat menunjukkan bagaimana bisnis kami akan beroperasi lebih baik—dan tetap bertanggung jawab atas peran mereka dalam mewujudkannya?
Pertanyaan itu jauh lebih berguna daripada menanyakan sistem mana yang memiliki daftar fitur terpanjang.
