Arnav Mishra, Co-Founder dan CTO Doss – Seri Wawancara

Arnav Mishra, Co-Founder dan CTO Doss, adalah insinyur full-stack dan pemimpin teknis dengan latar belakang yang meliputi startup awal dan sistem infrastruktur skala besar. Sebelum menjadi co-founder Doss, ia adalah insinyur pendiri di Siteline, di mana ia membangun sistem inti termasuk arsitektur izin, integrasi ERP, dan kerangka kerja otomatisasi, sementara juga berkontribusi pada perekrutan, operasi pendapatan, dan budaya perusahaan. Sebelumnya dalam karirnya, ia memegang posisi insinyur di Rubrik dan magang di perusahaan seperti Uber dan VMware, mengembangkan keahlian dalam infrastruktur cloud, sistem data, dan otomatisasi. Di samping pekerjaannya, ia telah terlibat aktif dalam mentorship dan pengembangan bakat melalui organisasi seperti Techquitable Futures dan Contrary, mencerminkan komitmen yang lebih luas untuk mendukung generasi insinyur berikutnya.

Doss adalah perusahaan perangkat lunak modern yang fokus pada mereinventasi sistem ERP tradisional melalui Platform Sumber Daya Adaptif (ARP), platform operasional yang fleksibel dan asli AI yang dirancang untuk menggabungkan dan mengotomatisasi alur kerja bisnis. Dibangun sebagai alternatif komposisi untuk solusi ERP warisan, Doss memungkinkan perusahaan untuk mengelola persediaan, pengadaan, keuangan, dan pengiriman dalam satu sistem yang beradaptasi dengan operasi dunia nyata daripada memaksa proses kaku. Platformnya menggabungkan lapisan data terpusat, alur kerja tanpa kode, dan analitik waktu nyata, memungkinkan bisnis untuk mengirimkan dengan cepat, mengintegrasikan dengan alat yang ada, dan terus mengembangkan operasional mereka tanpa implementasi yang panjang atau konsultan yang mahal.

Motivasi untuk membangun DOSS berasal dari Wiley yang melihat perangkat lunak warisan mengganggu bisnis manufaktur ayahnya, dan keduanya kemudian melihat masalah serupa secara langsung saat bekerja dengan pabrik dan rantai pasokan perangkat keras. Bagaimana pengalaman itu membentuk keputusan Anda untuk menjadi co-founder DOSS dan memikirkan kembali sistem ERP dari awal?

Sebelum DOSS, saya adalah insinyur pendiri di sebuah startup FinTech. Alasan #1 mengapa pembeli kami – CFO, Akuntan, dll – tidak akan menggunakan solusi kami adalah karena mereka “terlalu sibuk mengimplementasikan ERP”. Ketika saya menyelidiki lebih dalam ke tanah kuno ERP, saya terkejut oleh model implementasi yang ada.

Apa yang saya lihat terus-menerus adalah kegagalan fundamental yang sama: implementasi membutuhkan bulan atau tahun, biaya ratusan ribu hingga jutaan dolar, dan terhambat sepenuhnya oleh konsultan manusia dengan tagihan per jam. Kemudian, setelah ERP dikirim, itu berhenti berubah. Bisnis terus berkembang; sistem tidak. Itu adalah masalah arsitektur, bukan masalah konfigurasi. Anda tidak bisa memperbaiki jalan keluarnya.

Sebagai pembangun perangkat lunak, perbandingan terdekat yang bisa saya pikirkan adalah sebagai berikut: bayangkan dunia di mana alat paling penting yang Anda gunakan – sebagai pengembang, katakanlah GitHub – dibangun khusus untuk perusahaan Anda selama bertahun-tahun oleh agen konsultasi pihak ketiga. Kemudian, setelah produk selesai, konsultan itu pergi tanpa pemeliharaan, perbaikan fitur, atau dukungan. Insinyur akan memberontak.

Tidak ada perusahaan teknologi modern yang bisa beroperasi dengan model seperti itu. Wiley dan saya sama-sama sampai pada kesimpulan yang sama: satu-satunya cara untuk memperbaikinya adalah dengan membangun dari awal.

DOSS memposisikan diri sebagai platform operasional asli AI yang dirancang untuk menggantikan sistem ERP tradisional seperti SAP atau Oracle (ORCL ). Apa perbedaan arsitektur fundamental yang membuat ERP asli AI memungkinkan hari ini yang tidak memungkinkan satu dekade yang lalu?

Oracle dan SAP dibangun di era di mana, untuk mencapai distribusi yang dimaksimalkan, mereka perlu menyederhanakan bidang konfigurasi ERP menjadi editor berbasis GUI yang relatif tidak teknis yang dapat dikirimkan oleh konsultan dalam skala besar. Untuk mempertahankan praktik terbaik, mereka mengunci sejumlah besar sistem inti dan hanya memungkinkan komposisi di tepi. Namun, dalam kenyataan, ketika Anda melihat spektrum semua bisnis di dunia, aplikasi bisnis mereka memerlukan fleksibilitas maksimal.

Apa yang diaktifkan oleh dunia asli AI adalah transformasi rekayasa perangkat lunak dari kerajinan menjadi mesin yang diindustrikan. Tidak lagi kita membutuhkan pengrajin perangkat lunak untuk membuat sistem kode; sebaliknya, kita bergerak ke dunia di mana throughput perangkat lunak adalah faktor komputasi dan token.

Doss telah dirancang dengan tepat ini dalam pikiran.

Kami membangun ZSL, bahasa domain spesifik deklaratif (DSL) yang menjelaskan implementasi DOSS pelanggan secara keseluruhan dalam kode. Pikirkan apa yang dilakukan “Terraform” untuk upaya Infrastruktur sebagai Kode, tetapi diterapkan pada logika aplikasi bisnis. Dengan mendefinisikan ERP dalam bahasa pemrograman dengan dimensi yang relatif rendah, kami dapat mengirimkan agen dalam skala untuk mengirimkan solusi ERP.

Setelah ZSL ditulis, bagian paling penting dari arsitektur adalah memasukkan praktik terbaik ke dalam platform itu sendiri untuk mencegah agen membangun implementasi berkualitas rendah. Tim kami telah mengirimkan sistem terdistribusi yang dapat diskalakan dengan scheduler kernel-level untuk mengambil beban pekerjaan ERP yang berfluktuasi. Selain itu, kami membangun sistem database HTAP yang menggabungkan bagian paling penting dari database transaksional seperti Postgres dan kemampuan analitis dari Gudang Data.

Dengan membangun platform untuk memiliki kekuatan skala perusahaan sejak awal, sistemnya diatur untuk distribusi agen sepenuhnya. Apa yang dulunya membutuhkan tim konsultan berbulan-bulan atau bertahun-tahun sekarang dapat diparalelisasi dalam skala menggunakan infrastruktur agen dalam sistem loop tertutup kami.

Banyak perusahaan masih mengandalkan spreadsheet dan alat yang terfragmentasi untuk pengadaan, persediaan, dan manajemen pesanan. Apa blind spot operasional terbesar yang muncul ketika data bisnis inti tidak diunifikasi menjadi satu sumber kebenaran?

Masalah terbesar adalah bahwa keputusan dibuat berdasarkan informasi yang sudah ketinggalan zaman atau tidak lengkap. Jika data persediaan Anda tinggal di satu tempat, pesanan pembelian di tempat lain, dan pesanan penjualan di tempat ketiga, Anda selalu melakukan rekonsiliasi, secara manual, lambat, dan setelah fakta. Dengan waktu seseorang menyadari bahwa persediaan salah atau supplier tertinggal, itu sudah menjadi masalah dalam bisnis.

Verve Coffee Roasters adalah contoh yang baik di mana ini rusak dalam praktek. Mereka menjalankan operasi di seluruh grosir, wholesale, DTC, dan kafe di AS dan Jepang, tetapi mengelola semuanya di seluruh sistem yang terputus dengan tidak ada visibilitas persediaan waktu nyata. Mereka kehabisan kopi mereka sendiri di lokasi lalu lintas tinggi dan mengalami stok kritis selama peluncuran retailer utama yang merusak hubungan retail kunci. Data itu ada di suatu tempat; itu hanya tidak terhubung dengan cara yang memungkinkan siapa pun untuk bertindak atasnya tepat waktu.

Masalah yang lebih halus adalah bahwa fragmentasi menyembunyikan bentuk sebenarnya dari operasi Anda. Anda tidak bisa melihat hubungan antara keterlambatan di hulu dan masalah pengiriman di hilir jika kedua hal itu tinggal di alat yang terpisah. Anda berakhir dengan mengelola gejala, mempercepat pesanan, membangun stok pengaman, dan menjalankan pemeriksaan manual daripada memahami apa yang sebenarnya terjadi. Sistem yang terunifikasi tidak hanya menyelamatkan waktu pada rekonsiliasi. Ini mengubah apa yang bisa Anda lihat dan tanyakan.

Pada intinya, bayangkan menjalankan bisnis perusahaan tanpa akses ke sistem kontrol versi (Git), alat observabilitas (DataDog), atau database terpusat untuk menanyakan informasi darinya.

Implementasi ERP secara historis memerlukan tim konsultan besar dan bulan – atau bahkan tahun – penerapan. Bagaimana AI mengubah ekonomi dan kompleksitas implementasi perangkat lunak operasional di dalam bisnis nyata?

Model implementasi tradisional adalah hasil yang muncul dari praktik perangkat lunak yang berusia generasi. Kami tidak lagi hidup di dunia itu.

Ada insentif yang tidak tepat dalam implementasi ERP saat ini – semakin lama implementasi dan semakin tidak efektif, semakin banyak uang yang diterima oleh pelaksana. Sebagian besar pembangun tidak akan memanfaatkan ini; namun, mereka tidak pernah termotivasi untuk bergerak dengan kecepatan dan kualitas.

Lebih lanjut, rasio pengeluaran konsultasi terhadap pengeluaran perangkat lunak dalam keterlibatan ERP tradisional berjalan sekitar 9:1, sehingga Anda menghabiskan sembilan dolar untuk konsultan untuk setiap dolar yang Anda habiskan untuk perangkat lunak itu sendiri. Untuk perusahaan besar, itu sangat menyakitkan. Untuk bisnis pasar menengah, itu menghambat. Jadi mereka baik-baik saja dengan perangkat lunak yang tidak benar-benar sesuai dengan cara mereka beroperasi, menunda proyek, atau meninggalkannya di tengah jalan.

AI mengubah ekonomi unit ini sepenuhnya. Sebaliknya implementasi konsultasi, implementasi DOSS adalah basis kode. Ketika waktu implementasi kami terus menyusut, kami dapat menyelaraskan insentif dengan model “bayar pada pengiriman” daripada “bayar saat Anda pergi”. Ketika bisnis berubah, sistem berubah bersamanya. Kebutuhan akan ruang konsultan dan slide deck panjang tidak lagi relevan.

Keberhasilan di Doss berarti menggantikan pengeluaran layanan TI global sebesar $1,86 triliun dengan implementasi agen dan pemeliharaan menggunakan ZSL sebagai bahasa untuk perangkat lunak aplikasi bisnis. Keberhasilan di Doss adalah mengkomoditaskan semua aplikasi bisnis dalam skala.

Anda telah mengirimkan DOSS dengan perusahaan yang beroperasi di lingkungan dunia nyata seperti manufaktur, logistik, dan barang konsumen. Apa tantangan yang tidak terduga yang muncul ketika AI bertemu dengan data operasional yang kacau?

Tantangan itu jarang AI. Itu adalah data yang Anda minta untuk bernalar tentangnya.

Setiap bisnis yang kami kerjakan telah mengumpulkan tahun-tahun pekerjaan operasional. Data itu secara teknis ada, itu hanya tidak tinggal di tempat yang karyawan, apalagi sistem agen, bisa bertindak secara andal.

Contoh yang bagus adalah produsen perabot Jerman yang membuat potongan yang dibuat sesuai dengan pesanan. Ketika kami datang, mereka memiliki 10 tahun data sejarah yang tersebar di 8 format file khusus dengan 11 objek data yang berbeda dan sinkronisasi 3PL yang berjalan pada salinan manual dari folder FTP. Logika bisnisnya spesifik dengan dimensi khusus, konfigurasi, metode pembayaran, dan lokasi showroom, dan seluruh sistem perlu bekerja dalam bahasa Jerman. Tidak ada skema siap pakai untuk itu. Mereka harus membayar ribuan euro setiap kali mereka ingin mengubah opsi konfigurasi sederhana, seperti opsi status untuk pesanan pembelian.

Tantangan itu bukan kompleksitas teknis dari satu bagian. Itu adalah bahwa setiap bisnis memiliki versi berbeda dari masalah ini, dan Anda tidak bisa sepenuhnya memprediksi sampai Anda berada di dalam datanya. Pekerjaan itu adalah mengambil cetakan akurat tentang bagaimana bisnis sebenarnya beroperasi, bukan memetakan datanya ke dalam template generik dan berharap itu sesuai.

Untuk membangun solusi yang bekerja untuk dunia nyata, Anda membutuhkan platform dengan fleksibilitas maksimal. Hanya kemudian AI bisa berguna dalam memahami model data yang mendasarinya, dan membangun model yang bekerja untuk setiap pelanggan.

Ada banyak diskusi tentang kopilot AI dan agen otonom dalam perangkat lunak bisnis. Di mana Anda melihat AI menambahkan nilai terbesar dalam alur kerja operasional saat ini, dan di mana pengawasan manusia masih tetap penting?

Pada skala, AI memiliki kemampuan untuk mengganggu semua pekerjaan operasional.

Dalam cakrawala dekat, model dan agen Doss harus dapat mengubah inti konsultan teknis dalam mengimplementasikan aplikasi bisnis serta konsultan manajemen dalam mengirimkan rekomendasi strategis. Doss akan memiliki repositori data terstruktur dan terkait terbesar yang mewakili skema dan informasi operasional bisnis. Agen kami dapat menggunakan data itu untuk mengirimkan rekomendasi yang dapat diskalakan.

Nilai paling jelas saat ini lebih spesifik dari itu. Ini ada di pekerjaan yang berulang, berbasis aturan, dan saat ini dilakukan oleh orang-orang yang memiliki prioritas strategis lain: memproses pesanan pembelian, merekonsiliasi persediaan, dan mengarahkan keputusan pengiriman. Tugas-tugas ini memiliki input dan output yang ditentukan dengan baik, dan AI dapat menanganinya secara andal dalam skala.

Untuk saat ini, pengawasan manusia sangat penting di mana biaya keputusan yang salah tinggi, dan sistem belum memiliki konteks yang cukup untuk percaya diri. Saat ini, model yang tepat bukanlah agen otonom yang menggantikan pengambilan keputusan manusia secara keseluruhan; itu adalah agen yang menangani pekerjaan volume tinggi yang ditentukan dengan baik sehingga orang dapat fokus pada keputusan yang benar-benar memerlukan penilaian mereka.

Banyak perusahaan mencoba melapisinya dengan AI di atas tumpukan perangkat lunak yang ada. Menurut Anda, mengapa memasang AI di atas sistem warisan sering kali gagal dibandingkan dengan membangun AI secara langsung ke dalam fondasi platform?

Sistem warisan tidak dibangun untuk dinalar oleh AI. Model data, API, cara informasi disusun, semuanya dirancang untuk interaksi manusia melalui antarmuka. Ketika Anda mencoba melapisinya dengan AI, Anda meminta AI untuk bekerja di sekitar keterbatasan yang tidak dirancang untuk bekerja di sekitarnya.

Bahwa masalah yang lebih dalam adalah model implementasi. Dalam ERP tradisional, konfigurasi sistem disimpan dalam sistem itu sendiri. Ini bukan kode yang bisa dibaca, diuji, atau diterapkan. Tidak ada cara bagi agen untuk memahami apa yang dilakukan sistem, apalagi mengubahnya dengan aman. Kami membangun ZSL secara khusus sehingga konfigurasi adalah basis kode yang benar: dapat dibaca, diuji, dan diterapkan dalam sistem loop tertutup. Kami sedang membangun siklus pengembangan perangkat lunak agen sepenuhnya (SDLC). Itu adalah prasyarat untuk AI agar benar-benar beroperasi pada sistem daripada hanya duduk di atasnya.

Bagaimana Anda melihat antarmuka sistem operasional bisnis akan berkembang ketika AI menjadi mampu menghasilkan alur kerja dan berinteraksi secara langsung dengan sistem operasional?

Pertanyaan antarmuka sebenarnya adalah tentang siapa yang perlu menggunakan sistem. Saat ini, antarmuka ERP dibangun di sekitar sejumlah kecil pengguna kuat, orang-orang yang dilatih pada sistem selama implementasi. Semua orang lain baik tidak bisa menggunakannya atau mendapatkan versi yang didegradasi.

Apa yang kami bangun adalah antarmuka komposisi, yang memperlakukan antarmuka seperti pembangun situs web. Antarmuka itu sendiri juga didukung oleh ZSL loop tertutup. Setiap orang, CFO, manajer gudang, analis rantai pasokan, mendapatkan dashboard dan tampilan data yang disusun di sekitar cara mereka benar-benar bekerja, bukan di sekitar cara perangkat lunak dikonfigurasi. Ketika AI menangani lebih banyak eksekusi alur kerja yang mendasarinya, antarmuka menjadi kurang tentang entri data dan lebih tentang visibilitas dan pengambilan keputusan. Anda perlu melihat apa yang terjadi, memahami mengapa, dan membuat panggilan penilaian. Perangkat lunak harus menangani sisanya.

Startup seperti DOSS memasuki pasar yang didominasi oleh pemain lama yang telah berdiri selama dekade. Apa kelebihan yang dimiliki startup asli AI ketika bersaing dengan platform perusahaan yang mapan?

Pemain lama memiliki masalah yang berlawanan dengan startup. Mereka memiliki basis yang dipasang yang besar untuk dilindungi. Setiap keputusan arsitektur yang mereka buat harus kompatibel ke belakang. Mereka dapat menambahkan fitur AI ke produk yang ada, tetapi mereka tidak bisa membangun kembali sistem yang mendasarinya tanpa merusak semua yang berjalan di atasnya. Itu bukan kegagalan ambisi; itu struktural.

Dalam ERP secara khusus, mereka juga dibebani dengan keputusan bisnis yang mendorong mereka ke jalur di mana pendapatan didorong oleh layanan konsultasi profesional. Diberi bahwa pengguna menghabiskan sembilan dolar untuk konsultan untuk setiap dolar yang mereka habiskan untuk perangkat lunak itu sendiri, kemampuan untuk mengubah 90% dari pendapatan sumber mereka tidak dapat diterima untuk pemain besar.

Sistem asli AI dapat dirancang dari awal sehingga AI adalah bagian dari arsitektur inti, bukan lapisan di atasnya. Model implementasi, model data, dan cara konfigurasi bekerja semuanya dirancang dengan AI sebagai peserta kelas satu. Itu adalah keuntungan yang menggandakan di mana setiap penerapan membuat sistem lebih baik, dan agen implementasi menjadi lebih mampu dengan setiap pelanggan baru. Jenis loop perbaikan ini tidak ada dalam sistem di mana implementasi masih merupakan keterlibatan konsultasi manusia.

Menghadap ke depan, bagaimana Anda membayangkan AI mengubah “sistem operasional” bisnis dalam lima hingga sepuluh tahun ke depan, terutama dalam bidang seperti visibilitas rantai pasokan, pengambilan keputusan waktu nyata, dan operasi otomatis?

Kami mendirikan DOSS dengan keyakinan bahwa sistem perusahaan akan dapat membangun diri mereka sendiri. Tiga tahun kemudian, kami telah memasuki Fase 2 dari Doss: implementasi mandiri agen. Platform sudah dapat menghasilkan, memvalidasi, dan mengembangkan sistem pelanggan daripada mengandalkan konfigurasi konsultan manual, dan itu menjadi lebih baik dengan setiap penerapan.

Arah ini menuju sistem yang selalu sejalan dengan bisnis. Saat ini, kesenjangan antara cara bisnis beroperasi dan apa yang diketahui perangkat lunak tentang itu adalah bulan atau tahun. Sistem dikonfigurasi pada suatu titik waktu dan tidak berubah sejak itu. Apa yang menjadi mungkin ketika kesenjangan itu tertutup, ketika sistem beradaptasi secara waktu nyata ketika bisnis berubah, adalah kemampuan operasional yang berbeda. Visibilitas waktu nyata bukan hanya pelaporan yang lebih cepat; itu adalah kemampuan untuk menangkap gangguan rantai pasokan sebelum menjadi kegagalan pengiriman. Operasi otomatis bukan hanya tentang efisiensi; itu adalah kemampuan untuk menjalankan bisnis yang lebih kompleks dengan tim yang sama. Itu adalah versi perangkat lunak operasional yang kami bangun menuju.

Terima kasih atas tanggapan yang terperinci, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi Doss.