Optimalisasi Stok dengan Konfigurasi Min-Max & Auto Purchase Request
T
Kembali ke Blog

Optimalisasi Stok dengan Konfigurasi Min-Max & Auto Purchase Request

Tutorial
Tim Pilar Inovasi 07 Aug 2026 6 min baca 2,865 kata 93
Pelajari strategi optimalisasi stok menggunakan konfigurasi min-max dan otomatisasi permintaan pembelian. Tingkatkan efisiensi, kurangi biaya, dan pastikan ketersediaan barang krusial di fasilitas kesehatan Anda.

Manajemen inventori yang buruk adalah salah satu penyebab inefisiensi terbesar di fasilitas kesehatan (faskes). Bayangkan sebuah rumah sakit yang kehabisan reagen vital di tengah operasi mendesak, atau klinik yang menimbun obat-obatan hingga kadaluarsa, menyebabkan kerugian finansial signifikan. Fenomena overstocking dan understocking ini bukan hanya mengganggu operasional, tetapi juga berdampak langsung pada kualitas pelayanan pasien dan profitabilitas. Data menunjukkan, faskes dengan manajemen stok yang tidak optimal dapat mengalami kerugian hingga 10-15% dari total nilai inventori tahunan akibat kadaluarsa, kerusakan, atau biaya penyimpanan yang berlebihan. Artikel ini akan mengupas tuntas solusi praktis dan mendalam untuk mengatasi masalah tersebut melalui implementasi konfigurasi Min-Max dan sistem Auto Purchase Request (PR). Kami akan membahas konsep dasar, detail implementasi teknis, contoh kode, penanganan error, best practices, dan FAQ, memastikan Anda memiliki panduan actionable untuk meningkatkan efisiensi logistik faskes Anda.

Konsep Dasar Min-Max & Auto Purchase Request

Manajemen stok Min-Max adalah strategi inventori yang menetapkan batas minimum (Min) dan maksimum (Max) untuk setiap item di gudang. Ketika jumlah stok suatu item mencapai atau turun di bawah batas Min, sistem akan memicu permintaan pembelian. Permintaan ini bertujuan untuk mengisi kembali stok hingga mencapai batas Max. Tujuan utamanya adalah untuk menyeimbangkan antara ketersediaan barang yang memadai dan biaya penyimpanan yang terkontrol, menghindari kekurangan (out-of-stock) maupun kelebihan stok (overstock). Sebagai contoh, jika sebuah klinik menetapkan Min level 50 box untuk sarung tangan steril dan Max level 200 box, maka ketika stok tersisa 50 box, sistem akan meminta pembelian 150 box untuk mencapai kembali 200 box.

Penentuan nilai Min dan Max tidak bisa sembarangan. Beberapa faktor krusial yang perlu dipertimbangkan meliputi: Lead Time Supplier (waktu dari pemesanan hingga barang diterima), Demand History (data konsumsi historis), Safety Stock (stok pengaman untuk mengantisipasi fluktuasi permintaan atau keterlambatan supplier), dan Service Level yang diinginkan. Contoh perhitungan sederhana: Jika rata-rata konsumsi harian jarum suntik adalah 100 unit, lead time supplier 3 hari, dan safety stock yang diinginkan untuk 2 hari konsumsi, maka Min Level dapat dihitung sebagai (Rata-rata Konsumsi Harian x Lead Time) + Safety Stock = (100 x 3) + (100 x 2) = 300 + 200 = 500 unit. Untuk Max Level, bisa ditentukan berdasarkan kapasitas penyimpanan atau periode pemesanan, misalnya 1 bulan konsumsi (3000 unit).

Auto Purchase Request (PR) adalah fitur otomatisasi yang terintegrasi dengan konfigurasi Min-Max. Ketika sistem mendeteksi bahwa stok suatu item telah mencapai atau melampaui batas Min, secara otomatis sistem akan membuat draf permintaan pembelian. Otomatisasi ini menghilangkan kebutuhan untuk pengecekan stok manual yang rentan kesalahan dan memakan waktu. Manfaat integrasi Min-Max dan Auto PR sangat signifikan: efisiensi waktu staf, akurasi data yang lebih tinggi, pengurangan risiko out-of-stock, optimalisasi biaya penyimpanan, dan peningkatan transparansi dalam proses pengadaan. Hal ini memungkinkan faskes untuk lebih fokus pada pelayanan pasien, dengan jaminan ketersediaan alat dan obat yang kritis.

Sebagai ilustrasi, sebuah rumah sakit dengan 500 tempat tidur memiliki kebutuhan reagen PCR yang sangat tinggi. Jika reagen tersebut memiliki Min Level 100 kit dan Max Level 300 kit, dengan lead time 5 hari. Setiap kali stok reagen PCR turun menjadi 100 kit, sistem secara otomatis menghasilkan PR untuk 200 kit. PR ini kemudian diteruskan ke bagian pengadaan untuk ditinjau dan disetujui. Tanpa sistem ini, staf gudang harus secara manual memantau ratusan item dan membuat PR, yang sangat tidak efisien dan rentan terhadap human error. Dengan otomatisasi, proses menjadi lebih cepat, akurat, dan proaktif, memastikan bahwa reagen vital selalu tersedia saat dibutuhkan, sejalan dengan standar pelayanan yang diatur dalam regulasi seperti PMK No. 78 Tahun 2014 tentang Pelayanan Darah yang menekankan pentingnya ketersediaan bahan habis pakai.

Detail Implementasi dalam Sistem ERP/SIMRS

Implementasi Min-Max dan Auto Purchase Request memerlukan arsitektur sistem yang terintegrasi, umumnya sebagai bagian dari modul inventori dan pengadaan dalam sistem ERP (Enterprise Resource Planning) atau SIMRS (Sistem Informasi Manajemen Rumah Sakit). Fondasi utamanya adalah database yang terstruktur dengan baik. Kita membutuhkan tabel seperti items (untuk master data barang), inventory_levels (untuk menyimpan stok aktual dan konfigurasi Min-Max per item), serta purchase_requests (untuk mencatat setiap permintaan pembelian yang dibuat). Integrasi antar tabel ini krusial untuk memastikan aliran data yang mulus.

Dalam konteks teknologi, stack yang umum digunakan untuk sistem enterprise modern bisa meliputi: Backend berbasis PHP dengan framework Laravel 11.x, berjalan di PHP 8.3. Untuk Database, PostgreSQL 16 adalah pilihan yang kuat dan andal, mendukung volume data besar dan transaksi kompleks. Frontend dapat dibangun dengan Vue.js 3 untuk antarmuka pengguna yang responsif. Untuk proses otomatisasi dan pengiriman notifikasi, Message Queue seperti RabbitMQ 3.12.x dapat digunakan untuk menangani tugas-tugas background secara asinkron, seperti memproses auto PR atau mengirim notifikasi ke bagian pengadaan.

Alur kerja otomatisasi dimulai dengan sebuah penjadwal (scheduler) atau cron job yang berjalan secara berkala, misalnya setiap 4 jam atau sekali sehari. Tugas penjadwal ini adalah untuk memindai tabel inventory_levels. Untuk setiap item, sistem akan membandingkan current_stock dengan min_level yang telah dikonfigurasi. Jika current_stock <= min_level, maka sistem akan memicu pembuatan entri baru di tabel purchase_requests. Entri ini akan mencakup detail item, kuantitas yang diminta (biasanya hingga mencapai max_level), tanggal permintaan, dan status awal (misalnya, 'Pending Approval').

Logika inti pemicu auto PR dapat dirumuskan sebagai berikut: IF current_stock <= min_level AND NOT EXISTS(pending_pr_for_this_item) THEN GENERATE_PURCHASE_REQUEST(item_id, quantity_to_order). Penting untuk menambahkan kondisi NOT EXISTS(pending_pr_for_this_item) untuk mencegah duplikasi PR jika ada PR yang sudah dibuat namun belum diproses. Setelah PR dibuat, sistem dapat mengirim notifikasi otomatis ke manajer pengadaan melalui email atau integrasi ke modul e-procurement. Integrasi dengan modul lain seperti akuntansi (untuk pencatatan biaya) dan penerimaan barang (untuk memperbarui stok setelah barang datang) juga esensial untuk siklus pengadaan yang lengkap dan transparan. Standar seperti FHIR R4 atau HL7 v2.5.1 dapat digunakan jika ada kebutuhan integrasi dengan sistem eksternal atau bridging data antar faskes, meskipun untuk internal ERP/SIMRS, RESTful API seringkali lebih praktis.

Code Sample untuk Otomatisasi

Untuk memberikan gambaran konkret, mari kita lihat contoh implementasi teknis menggunakan Laravel 11.x dan PostgreSQL 16. Pertama, kita perlu mendefinisikan struktur database untuk menyimpan informasi inventori dan permintaan pembelian. Berikut adalah contoh migrasi Laravel untuk tabel inventory_items dan purchase_requests:

<?php declare(strict_types=1); use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Schema\Blueprint; use Illuminate\Support\Facades\Schema; class CreateInventoryAndPurchaseTables extends Migration { public function up(): void { Schema::create('inventory_items', function (Blueprint $table) { $table->id(); $table->string('item_code')->unique(); $table->string('item_name'); $table->string('unit_of_measure'); $table->integer('current_stock')->default(0); $table->integer('min_level'); $table->integer('max_level'); $table->decimal('unit_price', 15, 2)->nullable(); $table->string('supplier_id')->nullable(); $table->integer('lead_time_days')->default(0); $table->timestamps(); }); Schema::create('purchase_requests', function (Blueprint $table) { $table->id(); $table->foreignId('inventory_item_id')->constrained('inventory_items')->onDelete('cascade'); $table->string('request_number')->unique(); $table->integer('requested_quantity'); $table->enum('status', ['PendingApproval', 'Approved', 'Rejected', 'Ordered', 'Completed'])->default('PendingApproval'); $table->text('notes')->nullable(); $table->timestamp('request_date')->useCurrent(); $table->unsignedBigInteger('requested_by_user_id')->nullable(); $table->timestamps(); }); } public function down(): void { Schema::dropIfExists('purchase_requests'); Schema::dropIfExists('inventory_items'); } }

Migrasi ini menciptakan dua tabel penting. Tabel inventory_items menyimpan data master barang beserta konfigurasi min_level, max_level, dan current_stock. Kolom lead_time_days juga disertakan untuk potensi perhitungan yang lebih kompleks. Tabel purchase_requests mencatat setiap permintaan pembelian, dengan inventory_item_id sebagai foreign key yang menghubungkan ke item inventori, requested_quantity, dan status permintaan. Kolom requested_by_user_id bisa digunakan jika ada kebutuhan untuk mencatat siapa yang melakukan approval atau pembuatan PR manual, meskipun untuk auto PR akan diisi oleh sistem.

Selanjutnya, kita akan membuat sebuah perintah (command) Laravel yang dapat dijalankan secara terjadwal (misalnya, melalui cron job). Perintah ini akan memindai semua item inventori, memeriksa kondisi Min-Max, dan secara otomatis membuat permintaan pembelian jika diperlukan. Logic ini akan memanfaatkan Eloquent ORM Laravel dan sistem Queue untuk proses background yang efisien.

<?php declare(strict_types=1); namespace App\Console\Commands; use App\Models\InventoryItem; use App\Models\PurchaseRequest; use Illuminate\Console\Command; use Illuminate\Support\Facades\DB; use Illuminate\Support\Str; class GenerateAutoPurchaseRequests extends Command { protected $signature = 'inventory:generate-auto-pr'; protected $description = 'Generates automatic purchase requests for items below min stock level.'; public function handle(): int { $this->info('Starting automatic purchase request generation...'); $items = InventoryItem::whereColumn('current_stock', '<=', 'min_level') ->where('min_level', '>', 0) // Only process items with min_level configured ->get(); if ($items->isEmpty()) { $this->info('No items found below min stock level. Exiting.'); return self::SUCCESS; } foreach ($items as $item) { // Check if there's already a pending PR for this item $existingPendingPr = PurchaseRequest::where('inventory_item_id', $item->id) ->whereIn('status', ['PendingApproval', 'Ordered']) ->exists(); if ($existingPendingPr) { $this->warn("Skipping item '{$item->item_name}' (ID: {$item->id}) - Pending PR already exists."); continue; } $quantityToOrder = $item->max_level - $item->current_stock; if ($quantityToOrder <= 0) { $this->warn("Skipping item '{$item->item_name}' (ID: {$item->id}) - Quantity to order is zero or negative."); continue; } try { DB::beginTransaction(); $pr = PurchaseRequest::create([ 'inventory_item_id' => $item->id, 'request_number' => 'PR-' . date('Ymd') . '-' . Str::upper(Str::random(5)), 'requested_quantity' => $quantityToOrder, 'status' => 'PendingApproval', 'notes' => 'Generated automatically due to low stock level. Current: ' . $item->current_stock . ', Min: ' . $item->min_level . '.' ]); DB::commit(); $this->info("Generated PR '{$pr->request_number}' for '{$item->item_name}' (Qty: {$quantityToOrder})."); // Optionally, dispatch a notification job here // dispatch(new SendPurchaseRequestNotification($pr)); } catch (\Exception $e) { DB::rollBack(); $this->error("Failed to generate PR for '{$item->item_name}' (ID: {$item->id}): " . $e->getMessage()); } } $this->info('Automatic purchase request generation completed.'); return self::SUCCESS; } }

Perintah inventory:generate-auto-pr ini akan mengambil semua item dari tabel inventory_items di mana current_stock kurang dari atau sama dengan min_level. Sebelum membuat PR baru, sistem memeriksa apakah sudah ada PR yang sedang dalam status 'PendingApproval' atau 'Ordered' untuk item yang sama, untuk mencegah duplikasi. Jika tidak ada PR yang tertunda, sistem akan menghitung quantityToOrder (perbedaan antara Max Level dan Current Stock) dan membuat entri baru di tabel purchase_requests dengan status 'PendingApproval'. Penggunaan transaksi database (DB::beginTransaction() dan DB::commit()) memastikan integritas data. Baris komentar dispatch(new SendPurchaseRequestNotification($pr)); menunjukkan titik di mana notifikasi dapat dikirim secara asinkron kepada pihak terkait, misalnya melalui email atau integrasi ke dashboard pengadaan. Command ini dijalankan melalui Laravel scheduler, misalnya $schedule->command('inventory:generate-auto-pr')->dailyAt('02:00');.

Contoh Payload & Penanganan Error

Dalam sistem yang terintegrasi, seringkali terdapat kebutuhan untuk mengirimkan data permintaan pembelian ke modul lain, seperti modul e-procurement atau bahkan ke sistem supplier melalui API. Berikut adalah contoh payload JSON yang realistis untuk sebuah Purchase Request, yang mencakup detail penting untuk proses pengadaan:

{ "purchase_request_id": "PR-20240726-001", "request_date": "2024-07-26T10:00:00Z", "requested_by": "SystemAutomated", "status": "PendingApproval", "items": [ { "item_id": "ITM-001", "item_name": "Jarum Suntik 1ml", "requested_quantity": 500, "unit_price": 500.00, "total_price": 250000.00, "min_level_snapshot": 300, "current_stock_snapshot": 250, "max_level_snapshot": 700 } ], "notes": "Generated automatically due to low stock level for ITM-001." }

Payload JSON di atas menyediakan informasi lengkap tentang permintaan pembelian. purchase_request_id adalah identifikasi unik PR. request_date adalah stempel waktu kapan PR dibuat. requested_by menunjukkan sumber permintaan (dalam hal ini, sistem otomatis). Bagian items adalah array yang berisi detail setiap barang yang diminta, termasuk item_id, item_name, requested_quantity, dan harga estimasi. Penting juga untuk menyertakan min_level_snapshot, current_stock_snapshot, dan max_level_snapshot. Snapshot ini merekam kondisi stok dan konfigurasi Min-Max saat PR dibuat, yang sangat berguna untuk audit trail dan analisis di kemudian hari, terutama jika konfigurasi Min-Max berubah seiring waktu. notes memberikan konteks tambahan, seperti alasan otomatisasi.

Meskipun sistem otomatisasi dirancang untuk efisiensi, potensi error selalu ada. Salah satu error umum dapat terjadi jika ada inkonsistensi data atau batasan bisnis yang tidak terpenuhi. Contoh error message yang mungkin muncul saat memproses permintaan pembelian adalah:

{ "status": 400, "code": "INVENTORY_MIN_MAX_VIOLATION", "message": "Requested quantity (500) exceeds maximum order quantity (400) for item ITM-001 based on current stock and max level configuration.", "details": { "item_id": "ITM-001", "requested_quantity": 500, "max_order_quantity": 400 } }

Error ini mengindikasikan bahwa kuantitas yang diminta (500 unit) melebihi batas maksimum yang diizinkan untuk item tersebut, mungkin karena ada batasan pembelian per transaksi atau konfigurasi Max Level yang lebih rendah dari yang diperkirakan. Penanganan error semacam ini harus dilakukan dengan cermat. Pertama, sistem harus mencatat error ini ke dalam log aplikasi dengan detail yang memadai (misalnya, menggunakan Sentry atau ELK stack). Kedua, notifikasi harus dikirimkan kepada admin sistem atau manajer pengadaan agar mereka dapat meninjau dan mengambil tindakan korektif. Tindakan korektif bisa berupa penyesuaian kuantitas PR secara manual, perubahan konfigurasi Min-Max di master data, atau bahkan penangguhan PR hingga masalah diatasi. Penting untuk memiliki mekanisme validasi yang kuat di sisi backend sebelum PR diproses lebih lanjut, untuk mencegah data yang tidak valid masuk ke sistem atau dikirim ke pihak eksternal.

Best Practices

  1. Tinjau & Sesuaikan Parameter Min-Max Secara Berkala: Dinamika permintaan di faskes sangat fluktuatif, dipengaruhi oleh tren penyakit, musim, atau perubahan protokol medis. Oleh karena itu, parameter Min dan Max untuk setiap item harus ditinjau dan disesuaikan setidaknya setiap 3-6 bulan. Gunakan data historis konsumsi dan analisis tren untuk membuat keputusan yang berbasis data, bukan asumsi.
  2. Integrasi Data Real-time: Pastikan sistem inventori terhubung secara real-time dengan semua titik input dan output barang, seperti Point of Sale (POS) farmasi, modul penerimaan barang dari supplier, dan modul pengeluaran barang ke unit perawatan. Akurasi data stok adalah kunci sukses otomatisasi Min-Max dan Auto PR.
  3. Validasi & Persetujuan Berjenjang: Meskipun PR dibuat secara otomatis, penting untuk tetap memberlakukan proses validasi dan persetujuan berjenjang. PR yang dihasilkan sistem harus melewati tinjauan oleh manajer inventori atau pengadaan sebelum menjadi Purchase Order (PO) yang dikirim ke supplier, memastikan kontrol dan mitigasi risiko kesalahan.
  4. Monitoring & Notifikasi Proaktif: Siapkan dashboard yang jelas untuk memantau status stok dan PR yang dihasilkan. Implementasikan sistem notifikasi (email, SMS, atau push notification) untuk anomali stok (misalnya, stok turun drastis di luar perkiraan), kegagalan pembuatan auto PR, atau PR yang tertunda persetujuannya.
  5. Pelatihan Pengguna yang Komprehensif: Pastikan semua staf yang terlibat dalam siklus inventori dan pengadaan memahami cara kerja sistem, terutama dalam hal input data yang akurat (penerimaan, pengeluaran, transfer antar gudang). Kesalahan kecil di awal dapat berdampak besar pada akurasi Min-Max dan efektivitas auto PR.
  6. Manajemen Master Data yang Akurat & Terpusat: Data master barang (nama, kode, unit, harga standar), data supplier (lead time, kontak), dan data konfigurasi Min-Max harus selalu up-to-date dan terpusat. Inkonsistensi master data adalah penyebab utama kegagalan sistem otomatisasi inventori.
  7. Skalabilitas & Kinerja Sistem: Seiring pertumbuhan faskes, volume data dan transaksi akan meningkat. Pastikan arsitektur sistem dirancang untuk skalabilitas, dengan penggunaan indeks database yang tepat, optimasi query, dan potensi penggunaan microservices jika diperlukan, agar kinerja sistem tetap optimal.

FAQ

  1. Apa bedanya Min-Max dengan metode Reorder Point (ROP)? Min-Max menetapkan dua batas: Min untuk memicu pemesanan, dan Max untuk menentukan kuantitas pesanan agar stok tidak melebihi batas atas. ROP hanya fokus pada satu titik pemicu pemesanan ulang. Keunggulan Min-Max adalah kontrol ganda yang lebih baik terhadap overstocking, sedangkan ROP lebih sederhana dan cocok untuk item dengan permintaan stabil tanpa batasan kapasitas penyimpanan yang ketat. Keduanya menggunakan perhitungan safety stock dan lead time.
  2. Bagaimana jika permintaan barang sangat fluktuatif? Untuk barang dengan permintaan yang sangat fluktuatif, seperti obat-obatan musiman atau reagen pandemi, Min-Max perlu disesuaikan lebih sering, mungkin mingguan atau bulanan. Pertimbangkan untuk mengintegrasikan metode peramalan yang lebih canggih (misalnya, moving average atau exponential smoothing) untuk memprediksi permintaan di masa depan, kemudian gunakan hasil prediksi tersebut untuk menginformasikan penyesuaian nilai Min dan Max secara dinamis.
  3. Apakah semua item perlu dikelola dengan Min-Max? Tidak selalu. Item dengan nilai rendah (C-class dalam analisis ABC) dan konsumsi yang sangat tidak teratur mungkin lebih cocok dikelola dengan metode yang lebih sederhana seperti visual inspection atau two-bin system. Fokuskan implementasi Min-Max pada item A-class (nilai tinggi, konsumsi krusial) dan B-class (nilai menengah, konsumsi stabil) untuk mendapatkan dampak efisiensi terbesar.
  4. Bagaimana cara mengukur keberhasilan implementasi ini? Keberhasilan dapat diukur melalui beberapa metrik kunci: penurunan biaya penyimpanan (akibat berkurangnya overstock), penurunan insiden out-of-stock (meningkatkan ketersediaan), peningkatan turn-over ratio inventori, peningkatan akurasi stok fisik vs. sistem, dan efisiensi waktu staf yang sebelumnya dihabiskan untuk pengecekan stok manual dan pembuatan PR.
  5. Apa tantangan utama dalam implementasi Auto PR? Tantangan utama meliputi akurasi data master (lead time supplier, harga, satuan), fluktuasi lead time supplier yang tidak stabil, perubahan mendadak dalam permintaan pasien (misalnya, wabah penyakit), dan resistensi pengguna terhadap sistem baru. Penting untuk memiliki strategi manajemen perubahan yang kuat dan dukungan manajemen puncak.
  6. Bisakah sistem ini diintegrasikan dengan e-procurement? Tentu saja. Auto PR yang dihasilkan oleh sistem inventori dapat langsung diteruskan ke platform e-procurement internal atau eksternal melalui API. Integrasi ini mempercepat proses dari permintaan menjadi Purchase Order (PO) yang valid, mengurangi waktu siklus pengadaan, dan memungkinkan faskes untuk memanfaatkan diskon volume atau negosiasi harga yang lebih baik dengan supplier.

Optimalisasi stok melalui konfigurasi Min-Max dan Auto Purchase Request bukanlah sekadar fitur tambahan, melainkan pondasi krusial bagi efisiensi operasional faskes modern. Dengan implementasi yang tepat, sistem ini mampu mengurangi risiko kekurangan atau kelebihan stok, menekan biaya operasional, dan pada akhirnya, meningkatkan kualitas pelayanan pasien. Membangun sistem yang andal membutuhkan pemahaman mendalam tentang proses bisnis dan keahlian teknis yang kuat. Jika Anda membutuhkan solusi ERP atau SIMRS yang terintegrasi dengan fitur optimalisasi stok Min-Max dan Auto Purchase Request, yang dirancang khusus untuk kebutuhan unik fasilitas Anda, jangan ragu untuk menghubungi Nugroho Setiawan. Kami siap membantu merancang, mengembangkan, dan mengimplementasikan sistem yang akan membawa efisiensi dan akurasi ke level berikutnya di faskes Anda.

Terakhir diperbarui 08 Aug 2026

Komentar

Komentar ditinjau sebelum tampil.

Belum ada komentar. Jadilah yang pertama!