Bisakah AI Menemukan Cara Kerja Perusahaan? Ya. Namun Penemuan Bukanlah Hal yang Sama dengan Kebenaran Operasional.

 

Ada narasi kuat yang sedang muncul seputar AI perusahaan:

 

Hubungkan AI ke enterprise, biarkan AI mengamati data dan aktivitas pengguna di seluruh sistem, merekonstruksi cara organisasi bekerja, mengoptimalkan proses tersebut, dan pada akhirnya mengotomasinya melalui agen AI.

 

Memang, ada banyak kebenaran di dalamnya.

 

Teknologi seperti process mining, task mining, object-centric process mining, enterprise ontologies, dan agentic AI membawa Business Process Management (BPM) tradisional dan Robotic Process Automation (RPA) ke tingkat yang sama sekali berbeda.

 

Namun, ada perbedaan arsitektural penting yang mudah hilang dalam narasi AI:

 

Mengamati proses bisnis bukanlah hal yang sama dengan memiliki transaksi bisnis yang melahirkannya.

 

Dan merekonstruksi enterprise dari jejak digitalnya sangat berbeda dengan mengoperasikan enterprise melalui sistem transaksional spesifik domain.

 

1. Bagaimana Sebenarnya AI "Mengamati" Sebuah Enterprise?

 

Pertama, AI tidak secara ajaib memahami apa yang terjadi di dalam perusahaan.

 

Sebaliknya, AI membutuhkan bukti.

 

Dalam praktiknya, salah satu sumber bukti terpenting adalah event log yang dihasilkan oleh sistem operasional.

 

Setiap kali pengguna membuat invoice, menyetujui purchase order, mem-posting goods receipt, menyelesaikan work order, atau menutup service ticket, sistem yang mendasarinya dapat menghasilkan sebuah event.

 

Event process-mining konvensional biasanya memerlukan setidaknya:

 

Case ID + Activity + Timestamp

 

Contohnya:

 

PO-1057 → Purchase Requisition Created → 09:02 PO-1057 → Requisition Approved → 11:43 PO-1057 → Purchase Order Issued → 15:21 PO-1057 → Material Received → tiga minggu kemudian PO-1057 → Invoice Approved → empat minggu kemudian

 

Kumpulkan jutaan event ini, lalu algoritma dapat merekonstruksi proses aktual yang diikuti organisasi.

 

Ini adalah Process Mining.

 

Alih-alih bertanya kepada karyawan bagaimana proses pengadaan bekerja, sistem merekonstruksinya dari bukti. Dengan kata lain, sistem menunjukkan bagaimana ribuan transaksi pengadaan benar-benar bergerak melalui enterprise.

 

Kemudian sistem dapat mengidentifikasi:

 

• variasi proses;
• bottleneck;
• loop dan rework;
• urutan yang tidak biasa;
• keterlambatan persetujuan;
• penyimpangan kepatuhan;
• aktivitas yang duplikat;
• dan peluang otomatisasi yang potensial.

 

Ini sudah jauh lebih ilmiah daripada workshop BPM tradisional. Lagipula, pendekatan ini bertumpu pada bukti transaksional yang teramati, bukan hanya pada wawancara dan diagram proses yang disusun secara manual.

 

2. Namun, Apa yang Terjadi di Luar ERP?

 

Di sinilah Task Mining memperluas gambaran.

 

Lagipula, tidak setiap aktivitas bisnis menghasilkan peristiwa ERP yang bersih.

 

Misalnya, seorang karyawan dapat:

 

membuka email → mengunduh file Excel → menyalin kuantitas → membuka SAP → mencari PO → berpindah ke aplikasi lain → menyalin nilai → kembali ke Excel → mengirim email persetujuan.

 

Teknologi task mining, pada gilirannya, dapat menangkap unsur-unsur aktivitas desktop ini.

 

Tergantung pada teknologi dan konfigurasinya, hal ini dapat mencakup interaksi aplikasi, peristiwa browser, klik, tindakan keyboard, elemen UI, dan tangkapan layar.

 

Algoritma machine learning kemudian dapat mengelompokkan ribuan observasi ini dan mengidentifikasi urutan yang berulang.

 

Alih-alih sekadar menemukan:

 

Purchase Order Dibuat → Purchase Order Disetujui

 

platform kemudian dapat menemukan aktivitas manusia yang mengelilingi transaksi tersebut.

 

Singkatnya, inilah asal mula gagasan populer tentang AI yang “mengamati bagaimana perusahaan bekerja.”

 

Namun, ini bukan sihir.

 

Sebaliknya, ini pada dasarnya adalah:

 

Peristiwa Digital + Telemetri Interaksi Pengguna + Konteks + Analisis Statistik/ML → Rekonstruksi Proses

 

3. Dari Process Mining ke Object-Centric Process Mining

 

Namun, process mining tradisional memiliki keterbatasan penting.

 

Dalam praktiknya, perusahaan nyata tidak beroperasi di sekitar satu “kasus” yang terpisah.

 

Sebagai contoh, sebuah purchase order dapat berkaitan sekaligus dengan:

 

• beberapa baris purchase order;
• berbagai material;
• satu atau lebih pemasok;
• faktur;
• pengiriman;
• proyek;
• production order;
• kontrak;
• karyawan;
• aset.

 

Object-Centric Process Mining (OCPM) modern berupaya mempertahankan hubungan-hubungan ini.

 

Alih-alih merekonstruksi hanya urutan linear di sekitar satu Case ID, pendekatan ini memodelkan interaksi di antara berbagai objek bisnis.

 

Hasilnya, model menjadi lebih mendekati:

 

Pemasok ↔ PO ↔ Material ↔ Faktur ↔ Pengiriman ↔ Proyek

 

Ini merupakan perkembangan penting karena realitas perusahaan bersifat relasional, bukan sekadar berurutan.

 

4. Lalu Hadirlah Lapisan Semantik atau Ontologi

 

Selanjutnya, platform seperti Palantir melangkah lebih jauh.

 

Platform ini dapat mengubah data dari ERP, CRM, MES, SCM, basis data, dokumen, dan sistem eksternal menjadi objek perusahaan.

 

Hasilnya, sebuah baris database menjadi sesuatu yang bermakna:

 

• Pemasok
• Purchase Order
• Karyawan
• Mesin
• Proyek
• Faktur

 

Platform kemudian membangun hubungan di antara objek-objek tersebut.

 

Contohnya:

 

• Pemasok → memasok → Material
• Material → dibutuhkan oleh → Proyek
• Purchase Order → diterbitkan kepada → Pemasok
• Faktur → merujuk ke → Purchase Order
• Mesin → dialokasikan ke → Proyek

 

Dengan cara ini, platform menciptakan representasi perusahaan yang dapat dibaca mesin.

 

Lalu lapisan berikutnya menambahkan:

 

• Data + Logika + Tindakan + Keamanan

 

Akibatnya, agen AI tidak lagi sekadar mengambil baris database.

 

Sebaliknya, AI dapat bernalar tentang objek perusahaan, memahami hubungannya, memanggil logika yang telah disetujui, dan berpotensi mengeksekusi tindakan yang berwenang.

 

Ini sangat kuat.

 

Namun, perhatikan satu hal penting:

 

Dari mana sebagian besar objek dan transaksi perusahaan itu berasal?

 

Sering kali dari ERP, CRM, SCM, MES, HR, manajemen proyek, dan sistem operasional lainnya.

 

Dengan kata lain, lapisan kecerdasan sedang menciptakan representasi yang lebih kaya dari realitas operasional.

 

Namun, hal itu tidak serta-merta menghilangkan sistem yang menghasilkan realitas tersebut.

 

5. Bagaimana Data Diperiksa?

 

Inilah mungkin bagian terpenting dari pembahasan ini.

 

Lagipula, platform perusahaan tidak bisa begitu saja menyerap semuanya dan menganggapnya sebagai kebenaran.

 

Karena itu, pipeline data engineering menggunakan mekanisme seperti:

 

• Validasi skema — apakah data yang masuk memiliki struktur yang diharapkan?
• Validasi tipe — apakah quantity berupa numerik, date benar-benar tanggal, currency direpresentasikan dengan benar?
• Pemeriksaan kelengkapan — apakah ada field wajib yang hilang?
• Pemeriksaan keunikan — apakah muncul objek duplikat?
• Pemeriksaan referensial — apakah pemasok, PO, karyawan, atau proyek ini benar-benar ada?
• Aturan transformasi — bagaimana pipeline harus menormalisasi format dari sistem sumber yang berbeda?
• Data lineage — dari mana nilai ini berasal dan transformasi apa yang menghasilkan nilai tersebut?
• Pemeriksaan kesehatan — apakah data berhenti datang, berubah secara tak terduga, atau melanggar ekspektasi yang ditetapkan?

 

Pada level proses, tim juga menggunakan teknik penting lainnya:

 

Conformance Checking

 

Di sini, platform membandingkan proses yang ditemukan dengan model proses yang diharapkan atau yang telah disetujui.

 

Contohnya:

 

Diharapkan

 

• Requisition → Approval → PO → Receipt → Invoice → Payment

 

Teramati

 

Requisition → PO → Receipt → Invoice → Approval → Payment

 

Hasilnya, teknologi dapat mendeteksi bahwa eksekusi aktual menyimpang dari proses yang diharapkan.

 

Jelas, itu sangat berguna.

 

Namun, hal ini menyingkap persoalan filosofis yang penting.

 

Dari mana definisi proses yang “benar” itu berasal?

 

Pada akhirnya, seseorang harus mendefinisikan aturan bisnis.

 

• AI dapat menemukan apa yang terjadi.
• Berikutnya, AI dapat menghitung urutan mana yang paling sering terjadi.
• AI dapat mengidentifikasi korelasi antara perilaku tertentu dan hasil yang lebih baik.
• Terakhir, AI dapat merekomendasikan proses yang didesain ulang.

 

Namun frekuensi tidak menetapkan kebenaran.

 

Jika 5.000 karyawan berulang kali menjalankan workaround yang sama, AI mungkin berhasil menemukan proses yang dominan.

 

Dalam hal itu, AI telah menemukan perilaku organisasi.

 

Namun, AI belum tentu menemukan kebijakan organisasi.

 

6. Inilah Perbedaan Kritis Antara Observasi dan Generasi Transaksi

 

Sebagai contoh, pertimbangkan pengadaan.

 

Sebuah platform process mining mungkin mengamati:

 

Permintaan Material → Approval → RFQ → Evaluasi → PO → Pengiriman → Faktur

 

Namun, platform operasional harus benar-benar membuat dan mengendalikan:

 

• ID Material
• Kuantitas yang Diminta
• Kuantitas yang Disetujui
• Ketersediaan Anggaran
• Pemasok
• Mata Uang
• Harga Satuan
• Pajak
• Ketentuan Kontrak
• Otoritas Persetujuan
• Biaya yang Telah Dikomitmenkan
• Pergerakan Persediaan
• Posting Akuntansi

 

Sistem tidak bisa sekadar menyimpulkan nilai-nilai tersebut secara statistik setiap kali transaksi terjadi.

 

Sebaliknya, nilai-nilai tersebut harus sesuai dengan aturan yang telah ditentukan, otorisasi, master data, anggaran, dan struktur akuntansi.

 

Karena itu, sistem perusahaan memang dirancang deterministik.

 

Untuk transaksi yang terkendali:

 

Input Tervalidasi + Aturan Bisnis yang Disetujui = Transaksi yang Dapat Diprediksi

 

Dengan kata lain, keterprediksian bukanlah ketertinggalan teknologi.

 

Itu adalah mekanisme pengendalian.

 

7. Karena Itu, AI Menciptakan Lapisan Baru, Bukan Necessarily Lapisan Pengganti

 

Secara sederhana, arsitektur perusahaan yang muncul terlihat kurang lebih seperti ini:

 

Sistem Pencatatan ERP | CRM | SCM | MES | HR | Sistem Proyek

 

↓

 

Transaksi Operasional & Log Peristiwa

↓

 

Integrasi / Data Fabric

 

↓

 

Process & Task Mining

 

↓

 

Lapisan Semantik / Ontologi

 

↓

 

Penalaran & Prediksi AI

 

↓

 

Agen AI & Orkestrasi

 

↓

 

Tindakan Terkendali

 

↓

 

Sistem Operasional

 

Hasilnya, ini menciptakan loop kecerdasan tertutup.

 

Lapisan AI mengamati perusahaan, memahaminya, merekomendasikan atau memulai tindakan, tetapi tindakan yang terkendali pada akhirnya memengaruhi objek dan transaksi bisnis operasional.

 

Karena itu, revolusi AI perusahaan bukan sekadar:

 

AI menggantikan ERP.

 

Sebaliknya, interpretasi yang lebih dapat dipertanggungjawabkan secara ilmiah adalah:

 

AI menciptakan lapisan kontrol dan orkestrasi yang cerdas di atas sistem operasional yang semakin terhubung.

 

8. Jadi, Apa yang Berbeda dari ProjectVIEW ERP?

 

ProjectVIEW mendekati masalah yang sama dari arah yang berlawanan.

 

Alih-alih terlebih dahulu mengamati ribuan transaksi yang terpisah dan kemudian berupaya merekonstruksi makna proyeknya, ProjectVIEW memulai dengan model domain yang eksplisit untuk operasi berbasis proyek.

 

Secara khusus, arsitektur dasarnya menghubungkan:

 

BoQ ↔ WBS ↔ Kode Biaya

 

Ini mewakili tiga dimensi berbeda dari realitas proyek:

 

BoQ = Cakupan / Struktur Komersial

 

Apa yang kontraknya kita bangun, dan berapa kuantitas serta nilainya?

 

WBS = Waktu / Struktur Eksekusi

 

Kapan dan melalui aktivitas apa kita akan membangunnya?

 

Cost Codes = Struktur Biaya / Sumber Daya

 

Sumber daya dan biaya apa yang terserap untuk menyerahkannya?

 

Yang penting, kontraktor menetapkan hubungan-hubungan tersebut sebelum eksekusi.

 

Transaksi yang dihasilkan selama eksekusi kemudian mewarisi konteks proyek ini.

 

Karena itu, transaksi material bukan sekadar:

 

20 ton baja dikonsumsi.

 

Sebaliknya, hal itu dapat menjadi:

 

20 ton baja → Proyek X → Item BoQ Y → Aktivitas WBS Z → Cost Code C

 

Perbedaan itu sangat mendasar.

 

9. ProjectVIEW Menghasilkan Data Operasional Terstruktur dari Sumbernya

 

Perhatikan perbedaannya.

 

Misalnya, sebuah platform kecerdasan yang terhubung ke berbagai aplikasi mungkin menemukan bahwa:

 

Karyawan A meminta baja.

 

Kemudian karyawan B menyetujui sesuatu.

 

Pengadaan menerbitkan PO.

 

Berikutnya, gudang mencatat pengiriman.

 

Seorang site engineer mencatat pemakaian.

 

Keuangan kemudian mencatat biaya.

 

Lapisan AI/data kemudian harus menghubungkan peristiwa-peristiwa ini dan membangun relasinya.

 

Sebaliknya, arsitektur ProjectVIEW menjadikan hubungan-hubungan tersebut sebagai bagian dari transaksi operasional itu sendiri.

 

Struktur proyek tidak sekadar disimpulkan di hilir.

 

Struktur itu dikodekan di hulu.

 

Itulah sebabnya dokumentasi ProjectVIEW menggambarkan anggaran proyek serta asosiasi BoQ-WBS-Cost Code sebagai fondasi struktural bagi pengadaan hilir, operasi lapangan, alokasi sumber daya, pengendalian biaya, dan akuntansi.

 

Hasilnya, transaksi lapangan dapat membawa asosiasi BoQ, WBS, dan Cost Code ke analisis biaya dan kinerja berikutnya.

 

10. Ini Tidak Menjadikan Palantir, ServiceNow, atau Process Mining Sebagai Pesaing ERP

 

Bahkan, kesimpulan sebaliknya mungkin lebih menarik.

 

Sebaliknya, mereka bisa saling melengkapi.

 

Misalnya, sebuah perusahaan mungkin memiliki:

 

• SAP atau Oracle yang mengelola keuangan korporat,
• ProjectVIEW yang mengelola eksekusi proyek yang granular dan pengendalian biaya,
• Primavera P6 yang mengelola penjadwalan,
• BIM yang merepresentasikan aset fisik,

 

dan sebuah platform AI/Ontology/Process Intelligence yang bernalar di atas semuanya.

 

Lapisan AI menjadi jauh lebih berguna ketika sistem operasional di bawahnya menghasilkan data yang terstruktur, terkendali, dan kaya secara semantik.

 

Karena itu, hal ini mengarah pada prinsip penting:

 

Kecerdasan AI sebagian merupakan fungsi dari kualitas data operasional.

 

Atau secara lebih formal:

 

Struktur Operasional yang Lebih Baik → Konteks yang Lebih Baik → Penalaran AI yang Lebih Baik → Otomatisasi yang Lebih Aman

 

11. Keunggulan ProjectVIEW Karena Itu Bukan “ERP, Bukan AI”

 

Lagipula, itu akan menjadi positioning yang keliru.

 

Sebaliknya, proposisi yang lebih kuat adalah:

 

ProjectVIEW menyediakan fondasi operasional yang deterministik dan spesifik industri yang di atasnya AI dapat bernalar.

 

Arsitektur ProjectVIEW yang terdokumentasi menetapkan hubungan BoQ, WBS, dan Cost Code di level anggaran dan meneruskan struktur itu ke transaksi berikutnya. Karena itu, pengadaan, manajemen konstruksi, HR, machinery, subcontracting, dan keuangan dapat berinteraksi di sekitar struktur proyek yang sama. Mereka tidak perlu merekonstruksi hubungan tersebut sesudahnya.

 

Dan ProjectVIEW AI dapat melampaui transaksi ProjectVIEW: desain DANAOS saat ini secara eksplisit mempertimbangkan data proyek eksternal termasuk dokumen, informasi EDMS, Primavera P6, catatan lapangan, sistem mutu, dan korespondensi, sambil mempertahankan logika operasi spesifik konstruksi yang diwarisi dari ProjectVIEW ERP.

 

Ini menghasilkan perbedaan arsitektural yang berpotensi penting:

 

Enterprise AI Generik

 

Amati → Ekstrak → Korelasikan → Modelkan → Simpulkan → Rekomendasikan → Bertindak

 

Domain ERP + AI

 

Struktur → Bertransaksi → Memvalidasi → Mengamati → Bernalar → Memprediksi → Mengoptimalkan → Bertindak

 

Kedua pendekatan ini dapat hidup berdampingan.

 

Namun, pendekatan kedua dimulai dengan konteks domain yang jauh lebih eksplisit.

 

12. Masa Depan Bukan ERP vs AI

 

Karena itu, kita mungkin mengajukan pertanyaan yang keliru ketika bertanya:

 

“Akankah AI menggantikan ERP?”

 

AI tak diragukan lagi akan menyerap banyak kemampuan yang secara historis dikaitkan dengan BPM, RPA, analitik, integrasi, dan antarmuka pengguna.

 

Demikian pula, agen akan semakin bekerja lintas aplikasi.

 

Hasilnya, proses akan menjadi lebih dinamis.

 

Bahasa alami mungkin menggantikan banyak layar tradisional.

 

Dan AI akan semakin menemukan serta mendesain ulang alur kerja secara otomatis.

 

Namun, di bawah kecerdasan itu, perusahaan tetap memerlukan representasi yang terkendali dari:

 

• uang,
• persediaan,
• karyawan,
• aset,
• kontrak,
• produksi,
• proyek,
• komitmen,
• biaya,
• dan pendapatan.

 

Semua ini memerlukan identitas, hubungan, izin, validasi, integritas referensial, integritas transaksi, dan auditabilitas.

 

Arsitektur perusahaan masa depan karena itu tampak kurang seperti:

 

AI alih-alih ERP

 

dan lebih seperti:

 

Sistem Operasional + Data Fabric + AI + Agen = Enterprise Cerdas

 

Untuk ProjectVIEW, kami akan merumuskannya secara lebih spesifik lagi:

 

Project ERP Deterministik + AI Tertanam + Orkestrasi Agentik = Sistem Operasi untuk Industri Berbasis Proyek

 

AI dapat menemukan bagaimana suatu organisasi bekerja.

 

AI juga dapat membantu menentukan bagaimana organisasi dapat bekerja lebih baik.

 

Semakin lama, AI juga dapat mengorkestrasi bagaimana tim menyelesaikan pekerjaan.

 

Namun, platform operasional tetap bertanggung jawab atas sesuatu yang secara fundamental berbeda:

 

menetapkan, menghasilkan, dan memelihara realitas bisnis yang terkendali yang menjadi dasar kecerdasan itu.

 

AI seharusnya tidak perlu menebak setiap pagi apa yang sebenarnya sudah diketahui perusahaan.