Perangkat Lunak Advanced Planning and Scheduling: Cara Mengevaluasi APS

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

Perangkat lunak advanced planning and scheduling menyusun jadwal yang mematuhi batasan nyata. Pelajari cara menentukan kebutuhan Anda, membandingkan alat APS, dan menguji salah satunya dengan data Anda sendiri.

Automatically translated with AI from the original post. Read the English original

Perangkat lunak advanced planning and scheduling, yang biasanya disebut APS, menghitung rencana produksi yang sesuai dengan batasan nyata: jam mesin, shift, keterampilan, alat, dan material. Ini adalah langkah lanjutan dibanding rencana yang hanya mencantumkan apa yang harus diproduksi dan kapan material dibutuhkan. Panduan ini ditujukan untuk perencana produksi dan pimpinan operasional yang harus memutuskan apakah mereka memerlukan APS dan bagaimana menilai pilihan yang ada, tanpa membiarkan vendor menentukan kriteria bagi mereka.

Poin Penting

• Perangkat lunak advanced planning and scheduling menambahkan penjadwalan berbasis kapasitas dan pengurutan di atas apa yang dilakukan MRP, sehingga pesanan yang bersaing dan sumber daya yang terbatas menjadi bagian dari rencana.
• Tentukan masalah Anda sebelum melihat produk: berapa banyak pesanan yang bersaing, seberapa sering rencana gagal, dan apa batasan yang sebenarnya.
• Periksa apa yang sudah dilakukan sistem ERP Anda terkait kapasitas terbatas (finite capacity) sebelum membeli apa pun. Sebagian fitur tersebut hanya berlaku untuk sumber daya tertentu yang perlu Anda aktifkan.
• Evaluasi alat berdasarkan pemodelan batasan, transparansi, penggantian manual oleh perencana, stabilitas penyusunan ulang rencana, dan upaya untuk menjaga data master tetap bersih.
• Uji dengan data Anda sendiri: putar ulang satu minggu di masa lalu dan bandingkan jadwal alat dengan apa yang benar-benar terjadi.

Apa itu perangkat lunak advanced planning and scheduling?

Kamus APICS, yang dikutip oleh ASCM, menggambarkan sistem APS sebagai program komputer yang menggunakan algoritma matematika lanjutan atau logika untuk melakukan optimasi pada fungsi perencanaan dan penjadwalan. Definisi itu cukup luas. Definisi yang lebih praktis berasal dari Fraunhofer IPA (makalah berbahasa Jerman, terjemahan saya sendiri). Makalah ini menempatkan APS di samping dua kelas perangkat lunak lain, yaitu supply chain management di tingkat jaringan dan manufacturing execution di tingkat produksi, dengan ERP di tingkat perusahaan. Makalah ini juga menjelaskan tiga langkah logika perencanaan.

MRP pada bentuk awalnya hanya menghitung kebutuhan material. Langkah berikutnya menambahkan kebutuhan kapasitas berbasis beban, tetapi tetap belum memperhitungkan pesanan yang bersaing untuk sumber daya yang sama. APS menambahkan penjadwalan kapasitas dan pengurutan, sehingga pesanan yang bersaing dan ketersediaan material menjadi bagian dari hasil. Di situlah intinya. Anda mendapatkan jadwal yang benar-benar bisa dijalankan, bukan sekadar daftar kebutuhan.

Artikel ini memandang dari sudut pandang pembeli: apa yang perlu diputuskan lebih dulu, kriteria mana yang penting, dan bagaimana mengujinya. Untuk definisi singkat dari istilah ini, lihat entri advanced planning and scheduling di situs ini.

Di mana posisi APS antara ERP dan lantai produksi?

ISA menggambarkan ISA-95 sebagai seperangkat standar internasional untuk mengintegrasikan sistem logistik dengan sistem kendali manufaktur. Dalam modelnya, perencanaan bisnis dan logistik, tempat sistem ERP berada, berada di level 4. Manajemen operasi manufaktur, termasuk MES, berada di level 3. APS biasanya bekerja di ruang di antara keduanya: ia menerima pesanan dan data master dari level atas, menyusun jadwal, lalu menyerahkannya ke lantai produksi.

Fraunhofer IPA mencatat bahwa ERP biasanya menjadi master untuk data perencanaan, seperti item master, bill of materials, dan routing. Itu menunjukkan di mana pekerjaan data Anda akan berada. Jika catatan-catatan tersebut keliru di ERP, APS mana pun akan menjadwalkan hal yang salah dengan sangat efisien.

Makalah yang sama menunjukkan bahwa pasar APS dan MES banyak tumpang tindih. Tanyakan sejak awal siapa yang memegang dispatching di lantai produksi. Sistem eksekusi manufaktur mencatat apa yang benar-benar terjadi. APS memutuskan apa yang seharusnya terjadi berikutnya. Jika keduanya mengklaim daftar pekerjaan, perencana dan supervisor akan bekerja dengan dua daftar.

Masalah apa yang perlu diselesaikan oleh alat ini?

Fraunhofer IPA menyarankan untuk menentukan fokus aplikasi dan kebutuhan terlebih dahulu, biasanya melalui analisis kondisi saat ini (as-is) dan konsep kasar, sebelum mengevaluasi perangkat lunak. Lakukan itu dengan menjawab pertanyaan-pertanyaan berikut:

1. Berapa banyak pesanan yang bersaing untuk sejumlah kecil sumber daya yang sama? Jika sedikit, spreadsheet mungkin masih memadai.
2. Seberapa sering rencana gagal selama satu shift, dan mengapa? Mesin berhenti, bahan tidak tersedia, atau pesanan mendesak?
3. Apa kendala yang sebenarnya: mesin, tenaga kerja terampil, alat, tungku, atau dudukan uji?
4. Apakah waktu setup bergantung pada urutan pekerjaan? Jika ya, penjadwalan urutan memiliki nilai yang nyata.
5. Siapa yang menyusun jadwal saat ini, berapa lama waktu yang dibutuhkan, dan seberapa sering jadwal itu diulang?
6. Keputusan apa yang ingin Anda serahkan kepada alat ini, dan mana yang tetap berada di tangan perencana?

Kemudian periksa apa yang sudah bisa dilakukan ERP Anda. Sebagai contoh, Microsoft mendokumentasikan perencanaan dan penjadwalan kapasitas terbatas (finite capacity) di Dynamics 365 Supply Chain Management. Dengan fitur ini, pesanan rencana yang tidak muat dalam kapasitas yang tersedia akan digeser ke tanggal ketika kapasitas tersedia. Namun, fitur ini hanya efektif untuk sumber daya yang Anda aktifkan, menggunakan time fence yang menentukan berapa hari yang diperlakukan sebagai kapasitas terbatas, dan Microsoft memperingatkan bahwa time fence satu hari kemungkinan terlalu pendek bagi sebagian besar produsen. Microsoft juga menyatakan bahwa kapasitas terbatas sebaiknya tidak digunakan jika kapasitas berubah mengikuti kebutuhan, misalnya kapasitas berbasis shift. Jika kendala Anda menyerupai itu, Anda sudah mendapatkan pemahaman sebelum berbicara dengan vendor mana pun. ERP Anda mungkin berbeda, jadi carilah batasan serupa dalam dokumentasinya. Gagasan terkait tentang penjadwalan kapasitas terbatas (finite capacity scheduling) menjadi dasar dari semua ini.

Kriteria apa yang membedakan satu APS dari yang lain?

Daftar fitur tampak mirip. Kriteria berikut membedakan alat-alat ini dalam praktik.

• Pemodelan kendala: Apakah alat ini dapat merepresentasikan batasan nyata Anda? Mesin, tenaga kerja dengan keterampilan tertentu, alat, kalender shift, setup yang bergantung pada urutan, dan pelepasan material.
• Transparansi: Apakah perencana dapat melihat mengapa sebuah pekerjaan berada di posisinya? Jadwal yang tidak bisa Anda jelaskan tidak akan bertahan dalam perdebatan pertama di lantai produksi.
• Aturan prioritas: Dapatkah Anda mengubah aturan (tanggal jatuh tempo, pelanggan, penghematan setup) tanpa bantuan vendor?
• Penggantian manual (override): Dapatkah perencana memindahkan pekerjaan secara manual, dan apakah sistem mencatatnya serta memeriksa ulang sisa jadwal? Tanyakan apa yang terjadi pada sisa jadwal setelah pemindahan manual.
• Perilaku perencanaan ulang: Perencanaan ulang setelah gangguan seharusnya hanya mengubah apa yang memang harus diubah. Jadwal yang menyusun ulang semuanya setiap kali tidak berguna di lantai produksi. Fraunhofer IPA juga mencatat bahwa rencana tidak pernah bisa dieksekusi persis seperti rancangannya, sehingga Anda memerlukan toleransi untuk deviasi antara realisasi dan rencana.
• Antarmuka data: Bagaimana sistem menerima pesanan, routing, dan data kemajuan produksi, dan siapa yang memelihara antarmuka tersebut?
• Waktu eksekusi: Berapa lama sebuah rencana lengkap membutuhkan waktu untuk volume data Anda? Fraunhofer IPA menyebutkan bahwa waktu eksekusi dalam hitungan menit membuat perencanaan yang hanya dijalankan setiap malam menjadi dipertanyakan, tetapi uji dengan volume data Anda sendiri.
• Simulasi: Bisakah Anda menguji skenario tanpa menyentuh jadwal yang sedang berjalan?
• Upaya perencana: Berapa lama waktu yang dibutuhkan untuk menjaga data induk dan aturan tetap berfungsi?
• Biaya dalam beberapa tahun: lisensi, antarmuka, pekerjaan data induk, pelatihan, dan peningkatan versi.

Apa yang sebaiknya Anda tanyakan kepada vendor?

Bawa poin-poin ini ke panggilan pertama. Jawaban yang baik itu spesifik, dan jawaban yang samar juga memberi Anda informasi.

• Tunjukkan jadwal yang dibuat dari data kami, bukan dari pabrik contoh Anda.
• Apa yang terjadi ketika sebuah mesin berhenti pukul 10 pagi? Apa yang berubah, dan apa yang tidak?
• Bagaimana setup yang bergantung pada urutan ditangani?
• Aturan kami yang mana saja yang bisa diubah oleh seorang perencana tanpa bantuan?
• Bagaimana penggantian manual (manual override) dicatat dan ditinjau?
• Kualitas data seperti apa yang Anda butuhkan dari kami, dan apa yang Anda lakukan ketika data tersebut tidak tersedia?
• Siapa yang bertanggung jawab atas antarmuka ke ERP kami dan ke sistem lantai produksi?
• Apa yang biasanya menjadi kesulitan pelanggan dengan proses yang serupa (job shop, repetitif, batch)?
• Bisakah kami mengekspor model, aturan, dan data kami jika kami berhenti berlangganan?

Bagaimana Anda menguji APS sebelum membelinya?

Gunakan replay. Ini cara termurah untuk memisahkan klaim pemasaran dari kecocokan yang sebenarnya.

1. Pilih satu minggu nyata di masa lalu dengan tingkat masalah yang normal.
2. Muat pesanan, routing, kalender, dan sumber daya seperti kondisinya pada awal minggu tersebut.
3. Biarkan alat tersebut membuat jadwal.
4. Bandingkan hasilnya dengan apa yang benar-benar terjadi dan dengan jadwal perencana: pesanan terlambat, jumlah setup, lembur, dan waktu menganggur pada titik kendala (constraint).
5. Sisipkan gangguan, misalnya henti selama dua jam di titik kendala, lalu periksa apa yang berubah pada hasil perencanaan ulang.
6. Minta seorang perencana menggunakannya selama satu hari dan catat setiap titik di mana mereka tidak percaya atau tidak memahami hasilnya.

Sepakati kriteria keberhasilan sebelum Anda mulai. Jika tidak, hasilnya akan diperdebatkan setelahnya.

Contoh: replay dengan angka rekaan

Contoh ini dibuat-buat untuk menunjukkan cara membaca hasil replay. Ini bukan hasil pengukuran.

Minggu nyata perencana memiliki 120 pesanan, dan 14 di antaranya terlambat. Jadwal dari alat tersebut menunjukkan 9 pesanan terlambat. Vendor mungkin akan berhenti di situ dan menyebutnya sebagai kemenangan. Tim yang cermat justru melihat lima pesanan yang "diselamatkan" oleh alat tersebut. Dua di antaranya bergantung pada mesin yang sebenarnya tidak beroperasi selama sebagian besar minggu itu, dan alat tersebut tidak mengetahuinya karena data henti mesin tidak ada dalam input. Satu lainnya bergantung pada waktu routing yang terlalu optimistis. Hanya dua yang merupakan perbaikan yang sebenarnya. Kesimpulan yang jujur adalah "alat ini kemungkinan lebih baik, dan data kami memiliki celah yang sebaiknya kami tutup". Temuan seperti ini berguna dalam kondisi apa pun.

Apa saja yang dibutuhkan untuk peluncuran (rollout)?

Sebagian besar adalah data dan kepemilikan, bukan perangkat lunak.

• Routing yang bersih, waktu proses, waktu setup, dan kalender. Rencanakan pembersihan data terlebih dahulu, lalu tetapkan jadwal proyek berdasarkan upaya tersebut, bukan dari slide vendor.
• Pemilik yang ditunjuk secara jelas untuk data induk dan untuk aturan penjadwalan.
• Mulailah dari satu area, sering kali area di sekitar titik kendala. Perluas cakupan ketika perencana sudah mempercayai hasilnya.
• Umpan balik dari lantai produksi: jumlah yang mulai dikerjakan, selesai, dan rusak (scrap), serta henti mesin. Tanpa data ini, jadwal akan menyimpang dari kenyataan dalam hitungan hari.
• Tinjauan mingguan terhadap kepatuhan jadwal selama beberapa bulan pertama. Power BI atau alat pelaporan apa pun dapat menampilkan rencana dibandingkan dengan realisasi.

Kesalahan umum

• Membeli fitur, bukan kecocokan. Daftar modul yang panjang tidak akan membantu jika masalah Anda hanya satu titik kendala.
• Melewatkan pengecekan ERP. ERP Anda mungkin sudah menangani sebagian kebutuhan tersebut.
• Mempercayai data demo. Demo dengan pabrik contoh hanya menunjukkan cara kerja alat dalam kondisi ideal.
• Mengabaikan data induk. Waktu routing yang salah menghasilkan jadwal yang rapi tetapi keliru.
• Menyingkirkan perencana dari proses. Perencana harus bisa melakukan penggantian manual dan melihat alasannya.
• Kepemilikan yang tidak jelas antara APS dan MES. Dua daftar pekerjaan akan menghasilkan dua kebenaran yang berbeda.
• Mengharapkan rencana yang sempurna. Rencana selalu menyimpang. Siapkan toleransi dan rutinitas perencanaan ulang.

Posisi Polaris

Jika kebutuhan Anda adalah rencana yang layak dengan batasan tertentu, iFAKT Polaris bisa menjadi salah satu opsi untuk dipertimbangkan. iFAKT menggambarkan Polaris sebagai AI ditambah digital twin untuk produksi. Modul Polaris Optimizer-nya mengubah grafik pengetahuan produk-proses-sumber daya menjadi rencana produksi yang dapat dijalankan dan dioptimalkan, berdasarkan data ERP real-time, ketersediaan sumber daya, serta batasan seperti shift, zona, keterampilan, dan kapasitas. Modul ini mendeteksi bottleneck, memprioritaskan pesanan, menganalisis dampak gangguan, lalu mengoptimalkan ulang. Apakah solusi ini cocok bergantung pada proses dan data Anda, jadi uji ulang (replay test) yang dijelaskan di atas sebaiknya dilakukan lebih dulu pada area yang sempit.

Topik terkait untuk dijelajahi

• Penjadwalan multi-lokasi. Jika beberapa pabrik berbagi sumber daya atau pesanan, tentukan apakah satu tim atau masing-masing lokasi yang memiliki jadwalnya sendiri.
• Produksi high-mix dan make-to-order. Rute produksi yang unik dan lead time engineering mengubah kemampuan yang harus ditangani oleh alat penjadwalan.
• Sinyal permintaan. Seberapa cepat pesanan atau perubahan dari pelanggan sampai ke jadwal menentukan seberapa sering Anda perlu merencanakan ulang.
• Penjadwalan dan energi. Sebagian pabrik ingin biaya energi menjadi masukan penjadwalan. Tanyakan apakah sebuah alat mendukungnya sebelum hal itu menjadi penting.

Langkah berikutnya

Mengevaluasi perangkat lunak advanced planning and scheduling akan lebih mudah setelah Anda memiliki rumusan masalah tertulis dan data satu minggu lalu untuk diuji ulang. Kumpulkan data pesanan, rute produksi, dan kalender untuk satu minggu terakhir, lalu gunakan sebagai kasus uji dalam diskusi vendor berikutnya.