Cara Mengelola Multi-Farm dengan ERP Terpusat: Arsitektur, Sinkronisasi Stok, dan KPI

Mengelola tiga farm layer dengan total 45.000 ekor seharusnya tidak jauh lebih rumit daripada mengelola satu. Kenyataannya, banyak operations manager justru kehilangan kendali saat jumlah farm bertambah. Di satu lokasi produksi telur dicatat di spreadsheet, di lokasi lain laporan harian dikirim lewat WhatsApp lalu direkap staf admin dua hari kemudian. Akibatnya Hen Day Production (HDP) antar-kandang tidak pernah bisa dibandingkan apel ke apel, stok pakan di gudang pusat tidak sinkron dengan pemakaian riil, dan selisih opname 3-5 persen dianggap wajar padahal nilainya puluhan juta rupiah per bulan. Pola masalah ini identik dengan yang kami temui saat membangun SIMRS multi-cabang atau SIM Klinik dengan beberapa unit layanan: bukan kurang aplikasi, tetapi data yang terpecah. Solusinya adalah satu ERP terpusat dengan aturan main yang tegas. Artikel ini membedahnya dari sisi arsitektur, sinkronisasi stok, hingga KPI.

Fondasi Arsitektur: Satu Database Induk, Banyak Identitas Farm

Keputusan pertama yang menentukan segalanya adalah apakah Anda memakai satu database bersama atau satu database per farm. Untuk skala 3 sampai 30 farm, satu database PostgreSQL 16 dengan kolom farm_id di setiap tabel transaksional jauh lebih efisien. Database terpisah per farm baru masuk akal bila ada entitas hukum berbeda dengan kewajiban pelaporan pajak terpisah, atau lokasi di yurisdiksi lain. Pada model database bersama, aktifkan Row Level Security (RLS) sehingga query aplikasi tidak bisa bocor ke farm lain meski developer lupa menambahkan klausa WHERE farm_id = .... Kebocoran data antar-farm adalah insiden yang paling mahal untuk diperbaiki setelah sistem berjalan setahun.

Kedua, tetapkan hierarki master data secara kaku: company, farm, kandang (house), lalu flock atau batch. Setiap level punya kode unik yang dipakai konsisten di semua modul. Master pakan, obat, dan strain ayam wajib memakai kode internal, bukan nama bebas yang diketik manual. Kami sering menemukan gudang pusat mencatat BR-1P sementara farm mencatat Brans Pur 1, dan stok tidak pernah cocok. Gunakan versioning pada master item agar perubahan harga atau komposisi tidak merusak laporan historis.

Ketiga, siapkan lapisan API yang offline-first. Node.js 20 LTS dengan Fastify 4 atau Laravel 11 sama-sama memadai. Untuk farm di area bersinyal lemah, misalnya dataran tinggi di sekitar Magelang, aplikasi kandang menyimpan transaksi ke SQLite lokal lalu mengirim antrean sinkronisasi saat jaringan tersedia. Setiap entri membawa client_uuid sebagai idempotency key sehingga pengiriman ulang tidak pernah membuat duplikat data.

Sinkronisasi Pakan dan Obat: Kunci Rekonsiliasi Tanpa Selisih

Sumber selisih terbesar di multi-farm bukan pencurian, melainkan pemindahan stok antar-lokasi yang dicatat dua kali secara terpisah. Aturannya sederhana: transfer antar-farm harus berupa satu dokumen dengan dua jurnal otomatis, yaitu pengurangan di farm asal dan penambahan di farm tujuan, dengan nomor dokumen yang sama. Jangan pernah membiarkan staf mencatat pengeluaran di satu farm dan penerimaan di farm lain sebagai dua aktivitas independen.

Secara teknis, gunakan upsert idempoten dengan constraint unik pada kombinasi farm, flock, dan tanggal. Ini membuat proses sinkronisasi aman dijalankan berulang kali, termasuk saat perangkat kandang mengirim ulang data yang sama. Jalankan job rekonsiliasi malam hari yang membandingkan stok buku dengan hasil opname dan menghasilkan variance report. Ambang toleransi yang wajar adalah 1 persen untuk pakan curah dan 2 persen untuk obat serta vitamin; selisih di atas itu otomatis memicu work order investigasi, bukan sekadar dicatat sebagai catatan kaki di laporan bulanan.

Contoh implementasi di PostgreSQL 16 untuk menampung log harian dari banyak farm sekaligus:

INSERT INTO daily_logs (farm_id, flock_id, log_date, feed_kg, egg_kg, mortality)
VALUES (:farm_id, :flock_id, :log_date, :feed_kg, :egg_kg, :mortality)
ON CONFLICT (farm_id, flock_id, log_date)
DO UPDATE SET feed_kg  = EXCLUDED.feed_kg,
              egg_kg   = EXCLUDED.egg_kg,
              mortality = daily_logs.mortality + EXCLUDED.mortality;

Perhatikan bahwa angka mortalitas dijumlahkan, bukan ditimpa, karena kejadian kematian bersifat kumulatif per pengiriman laporan. Kesalahan paling umum adalah menimpa nilai ini sehingga total kematian harian hilang saat ada dua shift yang melapor.

Dashboard KPI Lintas Farm dan Tata Kelola Akses

Tanpa definisi tunggal, setiap farm akan punya rumus HDP dan Feed Conversion Ratio (FCR) versi sendiri, dan rapat evaluasi berubah menjadi debat definisi. Definisikan semua KPI di satu tempat, idealnya sebagai view atau materialized view di database, bukan di file Excel masing-masing kepala farm. KPI minimum yang perlu dipantau harian: HDP, konsumsi pakan per 1.000 ekor, mortalitas harian dan kumulatif, FCR, cost per kg telur, serta Income Over Feed Cost (IOFC).

Untuk penyajian, materialized view yang di-refresh setiap 15 menit sudah cukup untuk kebutuhan operasional dan jauh lebih murah daripada query langsung ke tabel transaksional. Metabase 0.50 atau Grafana 11 dapat membaca view tersebut dan menampilkan peringkat farm secara transparan. Transparansi ini punya efek disiplin: begitu kepala farm tahu angkanya dibandingkan langsung dengan farm lain, kualitas input data meningkat dalam hitungan minggu.

Tata kelola akses harus mengikuti hierarki organisasi. Kepala farm hanya melihat farm sendiri, area manager melihat tiga sampai lima farm di wilayahnya, dan HQ melihat seluruh portofolio. Terapkan role-based access control di lapisan aplikasi dan RLS di lapisan database, lalu aktifkan audit log untuk setiap perubahan master data, harga pakan, dan jurnal koreksi stok. Tanpa audit log, investigasi selisih akan berhenti pada kalimat tidak tahu siapa yang mengubah.

Best Practices

1. Terapkan satu dokumen transfer untuk perpindahan stok antar-farm, jangan dua entri terpisah.
2. Wajibkan idempotency key pada setiap endpoint sinkronisasi dan constraint unik pada kombinasi farm, flock, dan tanggal.
3. Definisikan rumus HDP, FCR, dan IOFC di database sebagai view, bukan di spreadsheet masing-masing farm.
4. Jalankan rekonsiliasi stok otomatis setiap malam dengan ambang toleransi 1 persen pakan dan 2 persen obat.
5. Aktifkan RLS dan audit log sejak hari pertama, bukan setelah insiden pertama terjadi.

FAQ

Apakah satu database untuk semua farm aman dari segi performa?

Aman untuk skala hingga puluhan farm. Dengan indeks komposit pada farm_id dan log_date serta materialized view untuk pelaporan, PostgreSQL 16 masih nyaman di bawah 100 juta baris log harian. Pisahkan database hanya bila volume atau regulasi menuntut.

Bagaimana menangani farm yang sering kehilangan koneksi internet?

Gunakan arsitektur offline-first: aplikasi kandang menulis ke SQLite lokal, menyimpan antrean sinkronisasi, dan mengirim ulang secara otomatis saat koneksi kembali. Idempotency key memastikan data tidak terduplikasi.

Berapa lama implementasi ERP multi-farm yang realistis?

Untuk 3-10 farm dengan satu jenis komoditas, fase dasar seperti master data, pencatatan harian, stok, dan dashboard biasanya selesai 8-12 minggu. Modul akuntansi dan integrasi penggajian menyusul pada fase berikutnya.

Apakah ERP terpusat bisa diintegrasikan dengan sistem yang sudah ada?

Bisa. Sediakan API JSON dengan autentikasi token dan dokumentasi OpenAPI 3.1. Integrasi ke sistem akuntansi, POS retail telur, atau aplikasi penggajian umumnya dilakukan lewat API tersebut, bukan sinkronisasi langsung ke database.

Mengelola multi-farm dengan ERP terpusat bukan proyek pemasangan software, melainkan proyek penyeragaman proses dan data. Mulailah dari master data yang kaku, satu dokumen transfer stok, dan definisi KPI tunggal, lalu bangun otomatisasi di atasnya. Jika Anda sedang mengevaluasi arsitektur ERP untuk beberapa farm, klinik, atau unit layanan, tim konsultan IT kami melayani pengembangan aplikasi SIMRS, SIM Klinik, ERP, POS, dan website untuk wilayah Yogyakarta, DIY, dan Magelang. Diskusikan kebutuhan Anda dan dapatkan peta jalan implementasi yang realistis.

Artikel ini bagian dari edukasi Nugroho Setiawan, konsultan IT Jogja. Solusi terkait: PilarPOS ERP Agriculture SIM Klinik. Butuh konsultasi gratis?