Teknologi optimasi matematis untuk kapal kargo

 (research.google)
1 poin oleh GN⁺ 2024-06-07 | 1 komentar | Bagikan ke WhatsApp
  • Tim Operations Research di Google Research merilis Shipping Network Design API, yang mengoptimalkan desain jaringan, jadwal, dan rute kontainer kapal kontainer reguler secara bersamaan
  • Masalah ini menjadi kompleks hingga skala 500 kapal dan 200 pelabuhan pada patokan WorldLarge, karena harus menentukan urutan kunjungan kapal ke pelabuhan, waktu kedatangan dan keberangkatan, serta rute asal-tujuan kontainer secara bersamaan
  • Pendekatan awal berupa dual column generation dan CP-SAT menemukan solusi optimal yang dapat dibuktikan untuk skala kecil dan menengah, tetapi untuk masalah skala besar diperlukan heuristik yang menggabungkan large neighborhood search dan variable neighborhood search
  • Dalam benchmark LINERLIB, throughput kontainer untuk WorldSmall, EuropeAsia, Pacific, dan Mediterranean masing-masing meningkat 35%, 14%, 35%, 32%, sementara jumlah kapal yang digunakan turun 7%, 15%, 4%, 23%
  • Google memandang metode ini sebagai metode pertama yang dapat menyelesaikan masalah desain jaringan dan penjadwalan pada skala WorldLarge, dan menyediakan Shipping Network Design API sebagai bagian dari Operations Research APIs di masa mendatang

Masalah mengoptimalkan jaringan pengapalan kontainer secara bersamaan

  • 90% barang dunia bergerak melalui laut, dan kapal kargo besar dapat membawa muatan sepanjang 0,25 mil, berbobot 250 ribu ton, berisi 12.000 kontainer, dengan nilai total 1 miliar dolar AS
  • Berbeda dari pesawat, kereta, dan truk, kapal kargo beroperasi hampir terus-menerus dan bergerak mengikuti rute sirkular di laut
  • Rute dan jadwal yang tidak efisien menyebabkan kontainer tertahan di pelabuhan, kapal menunggu di laut, keterlambatan aliran logistik, dan juga berdampak pada harga produk
  • Shipping Network Design API dari Google mengimplementasikan solusi baru untuk masalah ini
    • Lebih cepat dan lebih skalabel daripada upaya yang telah dikenal sebelumnya
    • Dapat menggandakan keuntungan perusahaan pelayaran kontainer, mengangkut 13% lebih banyak kontainer, dan beroperasi dengan 15% lebih sedikit kapal

Tiga keputusan yang harus diselesaikan bersama oleh LSNDSP

  • Liner Shipping Network Design and Scheduling Problem, yaitu LSNDSP, menangani tiga keputusan secara bersamaan
    • Desain jaringan: menentukan urutan kapal mengunjungi pelabuhan
    • Jadwal jaringan: menentukan kapan kapal tiba dan berangkat
    • Penentuan rute kontainer: memilih perjalanan yang dilalui kontainer dari asal ke tujuan
  • Perusahaan pelayaran kontainer harus menyelesaikan ketiga masalah tersebut, tetapi biasanya menanganinya secara berurutan
  • Menyelesaikan ketiganya secara bersamaan meningkatkan tingkat kesulitan, tetapi memperbesar kemungkinan menemukan solusi yang lebih baik
  • Hasil desain jaringan bermuara pada service line yang diikuti oleh sejumlah kecil kapal
    • Misalnya, bisa berupa rute dari Asia Timur melewati Terusan Suez menuju Eropa Selatan
    • Service line diumumkan bersama tanggalnya, sehingga pengirim barang tahu kapan dan di mana harus menyiapkan kontainer

Kendala dari sandar pelabuhan, transshipment, dan keterlambatan

  • Kapal kontainer tidak bisa sandar di pelabuhan kapan pun diinginkan, dan harus menggunakan slot sandar yang telah ditentukan sebelumnya
  • Setelah mendekati pelabuhan, kapal dapat menurunkan jangkar dan menunggu di area labuh lepas pantai sampai waktu sandar tersedia
    • Jika pelabuhan padat, kapal dapat tinggal di area labuh selama beberapa jam atau beberapa hari
  • Jadwal jaringan yang akurat tidak hanya mencakup hari kapal sandar, tetapi juga jam sandarnya
    • Kapal dapat meningkatkan kecepatan agar tepat pada waktu tertentu
    • Kapal juga dapat memilih menurunkan kecepatan untuk menghemat bahan bakar
  • Saat sandar di pelabuhan, crane menurunkan kontainer dan memuat kembali kontainer yang akan dibawa pada pelayaran berikutnya
  • Jika jadwal mundur, dapat terjadi cut-and-run, yaitu kapal meninggalkan pelabuhan sebelum semua kontainer yang dijadwalkan selesai dimuat
    • Kontainer yang tersisa akan dimuat oleh kapal berikutnya
  • Ketika kontainer menghabiskan waktu di pelabuhan perantara dalam perjalanan dari asal ke tujuan, hal itu disebut transshipment
    • Transshipment semakin memperbesar jumlah kemungkinan solusi LSNDSP
    • Ini adalah salah satu dari berbagai kendala yang memengaruhi pembuatan rute kontainer

Metode optimasi: dari column generation hingga neighborhood search

  • Semua masalah optimasi terdiri dari variabel, kendala terhadap variabel, dan fungsi objektif yang akan diminimalkan atau dimaksimalkan
    • Contoh: kapal dan pelabuhan adalah variabel
    • Contoh: jumlah kontainer yang dapat dimuat di kapal adalah kendala
    • Contoh: memaksimalkan jumlah kontainer yang diangkut adalah fungsi objektif
  • Variabel dan kendala biasanya direpresentasikan sebagai matriks; kolom menunjukkan variabel, dan baris menunjukkan kendala
  • Column generation digunakan sebagai teknik umum untuk menguraikan masalah berskala besar
    • Pada awalnya hanya sebagian variabel yang dipertimbangkan
    • Setelah itu, variabel baru, yaitu kolom baru, dibuat untuk memperkirakan masalah asli dengan lebih baik
  • Google mengembangkan pustaka perangkat lunak yang menganalisis masalah dan memprediksi kolom mana yang baik untuk dibuat
    • Pustaka ini akan dirilis sebagai open source melalui MathOpt, sebuah framework mathematical programming

Batasan dua pendekatan dasar

  • Dual column generation memandang desain jaringan dan penentuan rute kontainer sebagai dua masalah yang saling terhubung
    • Setiap masalah terdiri dari masalah pemilihan utama yang memilih opsi terbaik dan masalah pembangkitan tambahan yang mencari opsi yang masuk akal
    • Algoritma shortest path diterapkan pada setiap pasangan masalah untuk menghasilkan opsi yang masuk akal
    • Setelah itu, solver linear programming Glop digunakan untuk memilih opsi terbaik pada masing-masing masalah
    • Column generation diterapkan pada kedua masalah secara bersamaan, dan hasil sementara dari satu masalah dibuat memengaruhi kemajuan masalah lainnya
    • Solusi optimal yang dapat dibuktikan dapat ditemukan, tetapi pendekatan ini hanya skalabel dengan baik sampai masalah skala menengah
  • Implementasi berbasis CP-SAT juga dicoba
    • Menggunakan solver constraint programming Google, CP-SAT
    • Bekerja dengan baik hingga jaringan skala menengah, tetapi tidak skalabel untuk skala masalah pengapalan global
  • Kedua pendekatan menemukan solusi optimal yang dapat dibuktikan untuk masalah kecil dan menengah, tetapi kurang memiliki skalabilitas untuk skala besar

Heuristik untuk penskalaan besar

  • Untuk meningkatkan skalabilitas, diterapkan dua variasi local search yang mencari peluang perbaikan dengan meninjau neighborhood di sekitar solusi yang sudah ada
  • Large neighborhood search menetapkan sebagian solusi, lalu menerapkan metode-metode sebelumnya
    • Contoh: menetapkan kondisi seperti “kapal ini mengunjungi Los Angeles setiap Selasa dua minggu sekali”
    • Ini meningkatkan skalabilitas dengan memperkecil ruang pencarian
  • Variable neighborhood search mengeksplorasi neighborhood pada sisi jaringan maupun jadwal
    • Pencarian diparalelkan dan didistribusikan ke banyak mesin untuk mengevaluasi banyak neighborhood secara bersamaan
    • Ini dapat membatasi ruang pencarian sekaligus mencerminkan pengetahuan dari Operations Research dan industri pelayaran
  • Kedua pendekatan menggunakan cara bertahap: mengunci sebagian dari solusi yang menjanjikan, lalu memulai dari solusi yang sudah baik dan memperbaikinya menjadi solusi yang lebih baik
  • Upaya-upaya sebelumnya tidak mempertimbangkan waktu transportasi karena membuat masalah jauh lebih sulit diselesaikan, tetapi Google mengonfirmasi bahwa memasukkan waktu transportasi sangat meningkatkan kualitas solusi

Hasil benchmark LINERLIB

  • Evaluasi kinerja menggunakan LINERLIB, benchmark industri untuk masalah desain jaringan pelayaran
    • Benchmark ini mencakup armada, pelabuhan, dan permintaan kontainer dalam skenario pelayaran kontainer
  • Skenario pengujian mencakup WorldSmall, EuropeAsia, dan WorldLarge
    • WorldLarge mencakup 500 kapal, 200 pelabuhan, dan sekitar 140 ribu kontainer
  • Tujuan optimasi bukan sekadar memaksimalkan jumlah kontainer atau meminimalkan jumlah kapal
    • Jika hanya memaksimalkan jumlah kontainer, lebih banyak kapal dapat dikerahkan sehingga biaya operasi meningkat
    • Jika hanya meminimalkan jumlah kapal, bisa muncul waktu pengiriman yang tidak realistis panjang, misalnya mengangkut semua kontainer dengan satu kapal
  • LINERLIB menyeimbangkan hal ini dengan estimasi keuntungan, yaitu pendapatan dari pengiriman tepat waktu dikurangi biaya pelayaran dan biaya penanganan kontainer di pelabuhan
  • Dibandingkan baseline, metode Google merutekan lebih banyak kontainer dengan lebih sedikit kapal
    • WorldSmall: throughput kontainer naik 35%, jumlah kapal turun 7%
    • EuropeAsia: throughput kontainer naik 14%, jumlah kapal turun 15%
    • Pacific: throughput kontainer naik 35%, jumlah kapal turun 4%
    • Mediterranean: throughput kontainer naik 32%, jumlah kapal turun 23%
  • Berdasarkan asumsi ekonomi LINERLIB, estimasi margin keuntungan juga meningkat secara signifikan

API dan materi publikasi lanjutan

Bacaan terkait

1 komentar

 
GN⁺ 2024-06-07
Komentar Hacker News

  • Saya berada di sisi terminal industri ini, dan meski menarik, ini terlihat sangat akademis
    Saya penasaran apakah ini benar-benar dibuat lewat kolaborasi dengan perusahaan pelayaran. Di sisi terminal, kami sekarang sedang mendalami optimisasi kontainer, dan itu benar-benar nyaris seperti mimpi buruk. Bahkan terminal yang dimiliki perusahaan yang sama pun punya cara operasi yang sangat berbeda, dan istilahnya pun sering berbeda di dalam perusahaan. Kalaupun dioptimalkan untuk satu terminal, di terminal berikutnya 80% harus dibuat ulang, sehingga solusi apa pun sangat sulit diskalakan

    • Kalau melihat masalah optimisasi industri, selalu tampak seperti ada uang sangat besar yang dibiarkan begitu saja, tetapi dalam praktiknya kendala yang berpusat pada manusia dan tidak terdokumentasi membuat pekerjaan menjadi jauh lebih rumit
      Misalnya, para insinyur Jerman menentang penguncian fitur kendaraan sebelum produksi massal, karena kalau begitu mereka tidak bisa memakainya untuk keperluan rekreasi. Di layanan kesehatan, biaya lembur mencapai puluhan miliar sehingga perbaikan jadwal tampak mudah, tetapi ada banyak kendala serikat pekerja dan pasokan rekrutmen juga kurang. Saya penasaran seberapa realistis solusi Google. Apakah kendala seperti rudal Houthi juga dimasukkan? Berdasarkan pengalaman, solusi yang mudah disesuaikan terhadap perubahan tak terduga sering kali lebih bernilai daripada solusi optimal yang bisa dibuktikan
    • Data benchmark yang digunakan untuk evaluasi kinerja berasal dari Maersk: https://github.com/blof/LINERLIB
    • Saya bukan di bidang pelayaran, tetapi sudah 15 tahun bekerja di manufaktur, terutama menangani test engineering dan otomasi, juga manajemen gudang/material serta transportasi/logistik. Gelar master saya di operations research manufaktur
      Saya setuju bahwa optimisasi objektif pada umumnya bersifat akademis. Selalu ada alasan mengapa sulit atau mustahil mengikuti begitu saja versi paling efisien dari proses yang distandardisasi. Kadang alasannya “bodoh” karena faktor manusia, dan sering kali ada alasan rasional yang mencerminkan eksternalitas seperti cuaca, downtime, gangguan rantai pasok, serta sinyal permintaan dan prediksi yang tidak mulus akibat musiman. Meski begitu, menurut saya hampir selalu lebih baik memulai dari proses yang paling efisien lalu menambahkan penanganan pengecualian, daripada membuat proses standar berdasarkan pengecualian yang sudah diketahui. Jika pengecualian dibiarkan menjadi aturan, operasi akan selalu kurang efisien dibandingkan kondisi optimal
    • Saya juga bekerja dengan terminal dan perusahaan transportasi darat. Banyak orang mencoba memecahkan masalah akademis yang “terlihat keren” seperti optimisasi rencana pemuatan, alokasi berth, dan pembagian crane, tetapi sangat sedikit yang benar-benar diimplementasikan
      Industri ini sulit, dan serikat pekerja pelabuhan secara tradisional kuat, sehingga lanskap politiknya makin sulit. Masalah-masalah yang tampak bisa dipisahkan dengan rapi dan diberi nama sebenarnya saling terkait, dan jika berharap algoritme akan “secara ajaib” menyelesaikannya untuk pengguna, hampir selalu gagal. Industri ini dengan mudah menelan para jagoan software yang masuk sambil berpikir, “Bukankah tinggal jalankan traveling salesman problem / constraint solver / pendekatan apa pun yang diinginkan?” Orang pintar jelas dibutuhkan, tetapi harus mulai dengan rendah hati dan berbicara dulu dengan pengguna nyata. Sepertinya tidak ada info kontak di profil Anda; jika ingin bertukar pikiran dengan perusahaan lain di industri ini, silakan kirim email. Kami sedang mengerjakan hal menarik, terutama di segmen terminal di bawah 1 juta TEU per tahun dengan porsi transportasi multimoda yang tinggi
    • Untuk orang di luar bidang ini, saya penasaran apakah Anda bisa menjelaskan lebih detail apa yang sedang Anda kerjakan sekarang

  • Saya sedang membaca The Box, yang membahas sejarah awal kontainerisasi, dan bukunya sangat menarik
    Sangat saya rekomendasikan bagi siapa pun yang mencari bacaan menyenangkan dengan campuran rekayasa, desain, bisnis, dan sejarah. Buku ini juga membuat masalah coding kecil yang saya hadapi terasa konyol

    • Buku yang luar biasa, dan saya setuju dengan rekomendasinya
      Ini mungkin akan banyak dibantah, tetapi saya sungguh-sungguh: menurut saya dampak kontainer laut 20 kaki terhadap dunia lebih besar daripada dampak yang kemungkinan akan dicapai model bahasa besar ke depannya. Baca dulu buku itu lalu beri tahu mengapa saya salah. Tentu saja saya tidak salah
    • Artikel Wikipedia untuk “The Box”: https://en.m.wikipedia.org/wiki/The_Box_(Levinson_book)
    • Di Flexport, buku ini diberikan kepada karyawan baru. Setidaknya begitu beberapa tahun lalu

  • Rupanya pada armada yang sangat besar, optimisasi kontainer masih menjadi masalah yang belum terpecahkan. Saya baru tahu
    Jika operations research Google meningkatkan utilisasi 10–20% dibandingkan solusi yang ada, itu luar biasa

  • Saya sangat penasaran apakah ada pihak yang benar-benar memakai endpoint API yang mereka publikasikan ini: https://developers.google.com/optimization/service/shipping/...
    Meski begitu, cukup keren

    • Berdasarkan pengalaman profesional saya bekerja di Google Cloud pada 2015–2023, API operations research seperti ini cenderung 1) akademis, dan 2) banyak digunakan secara komersial oleh solution architect dan engineer Google Cloud saat membuat solusi bisnis khusus pelanggan yang berjalan di atas GCP
      Contoh utamanya, Route Optimization API juga dipublikasikan dengan cara seperti ini oleh tim operations research perusahaan, lalu setelah mendapat masukan dari beberapa pelanggan alfa, solusi Fleet Engine dibangun di atasnya. Sebelum API operations research diekspos melalui Google Cloud, tidak ada SLA atau jaminan keandalan, jadi menurut saya sebaiknya jangan dipakai selain untuk tujuan akademis. Sekadar pendapat saya
      https://developers.google.com/maps/documentation/transportat...
    • Justru mungkin tidak bertanggung jawab kalau tidak mencobanya. Saya penasaran apakah ini mencakup seluruh bentuk masalah dan kendala yang dihadapi para perencana. Flexport adalah perusahaan berbasis di SF dengan pendapatan 3,3 miliar dolar AS di bidang ini
    • Kuburan Google[1] tumbuh cepat, jadi saya berhati-hati terhadap pengumuman baru Google. API seperti ini tampaknya akan sangat merepotkan ketika harus diganti di masa depan
      [1]: https://killedbygoogle.com/

  • Jika demurrage tidak dipertimbangkan, saya tidak yakin apakah ini benar-benar layak dicoba
    https://developers.google.com/optimization/service/reference...

  • Omega Tau Podcast merilis episode[0] yang sangat bagus tentang pengapalan kontainer, dan juga membahas optimasi penempatan kontainer serta perencanaan rute. Sangat direkomendasikan
    [0]: https://omegataupodcast.net/146-container-shipping/

  • Ungkapan “tidak seperti pesawat, kapal kargo beroperasi hampir terus-menerus” masih bisa diperdebatkan
    Kapal kargo memang banyak melakukan pemeliharaan saat berlayar, tetapi selain itu menurut saya perbedaannya jauh lebih kecil. Di pelabuhan, kapal berputar dengan membongkar dan memuat kargo selama beberapa hari, dan kadang menunggu beberapa jam atau beberapa hari untuk mendapatkan berth. Jika melihat contoh Delta A350, selain waktu turnaround 3 jam di bandara, pada dasarnya pesawat itu bergerak 24 jam sehari: https://www.flightradar24.com/data/aircraft/n513dz

    • Menurut saya saat bongkar muat pun bisa disebut “sedang beroperasi”

  • Ini mengingatkan saya pada pemilik atau manajer tempat seperti restoran lokal yang mengeluh pusing menyusun jadwal staf paruh waktu, bahkan mengatakan itulah alasan mereka dibayar mahal
    Saya sempat berpikir, bukankah itu bisa diselesaikan dengan algoritma?

    • Banyak orang tidak suka jam kerjanya berubah drastis
      Anda mungkin bisa menutup malam ketika separuh staf pergi menonton Taylor Swift, tetapi kalau Anda memanggil orang-orang seperti itu, giliran kerja mereka berikutnya juga harus ditutup lagi oleh orang lain, dan jika terus berlanjut, akan terbentuk jadwal yang sama sekali berbeda dengan orang-orang yang belum pernah bekerja bersama. Ini bisa diperbaiki dengan menambahkan lebih banyak constraint, tetapi menuliskan semuanya dan menentukan prioritasnya saja tidak sederhana. Manusia bukan balok Lego
    • Inilah persis masalah yang ingin saya pecahkan. Saya mendengar cerita yang sama dari hampir semua orang yang menyusun jadwal
      Karena punya latar belakang riset operasi, saya selalu merasa ini aneh. Masalah-masalahnya tampak sederhana untuk dimodelkan dan diselesaikan dengan solver umum, dan nilainya terlihat besar bahkan tanpa teknik canggih. Masalahnya adalah riset operasi secara umum kurang mudah diakses. Kebanyakan solver yang didukung dengan baik meminta kita mendefinisikan masalah dalam paradigma matematis, yang langsung membuat “orang biasa” kewalahan begitu melihatnya. Ada juga solusi siap pakai untuk masalah penjadwalan umum, tetapi jika tidak digunakan sejak awal, tiap bisnis punya variasi uniknya sendiri sehingga sulit diadopsi sepenuhnya. Entah variasi itu tidak didukung, atau tidak jelas bagaimana memasukkannya ke dalam tool. Bahkan ketika ada kemauan untuk memperbaiki penjadwalan, materi yang ditemukan biasanya mengasumsikan pengetahuan awal pemrograman atau matematika yang cukup tinggi. Menurut saya, untuk masalah penjadwalan, seharusnya bisa dibuat lingkungan pemodelan no-code yang dapat digunakan “orang biasa” yang sudah mentok dengan Excel tetapi tidak mampu merekrut pakar riset operasi
    • Ini masalah yang sangat penting, dan banyak software sudah menanganinya
      Hampir semua sistem HR/manajemen tenaga kerja besar memiliki opsi terkait. Misalnya https://www.workday.com/en-us/products/workforce-management/... dan https://www.oracle.com/human-capital-management/workforce-ma..., dan ada banyak vendor khusus juga. Namun seperti yang dikatakan orang lain, sistem seperti ini juga pernah kontroversial. Sebagian digunakan dengan cara yang tidak mempertimbangkan kebutuhan manusia yang wajar. Misalnya menjadwalkan kerja beruntun, mengubah jadwal dengan pemberitahuan mendadak, atau gagal mempertimbangkan keadaan nyata seperti pengasuhan anak yang mungkin bisa diperhitungkan oleh manajer manusia
    • Grup riset operasi yang sama memiliki contoh penjadwalan untuk restoran: https://developers.google.com/optimization/service/schedulin...
    • Saya punya sedikit latar belakang optimasi kombinatorial, jadi pernah terpikir untuk mencoba software di bidang ini atau semacam perencanaan jadwal sekolah
      Namun masalahnya, tiap bisnis punya constraint yang berbeda. Misalnya harus ada minimal satu orang yang bisa memberikan pertolongan pertama di setiap shift, Alice dan Bob tidak akur, seseorang tidak boleh bekerja pada hari Sabtu dua minggu berturut-turut, shift berubah setiap dua minggu, atau harus ada jeda minimal 12 jam antar-shift. Tool yang cukup fleksibel untuk dipakai banyak organisasi kemungkinan akhirnya menjadi terlalu rumit dan sulit digunakan

  • Saya masih penasaran dengan perencanaan pemuatan untuk kapal-kapal seperti ini
    Sepertinya ini masalah yang harus diselesaikan secara aproksimatif pada tahap setelah perencanaan rute tiap kontainer. Perencanaan pemuatan muncul belakangan, dan memiliki batasan yang jauh lebih bergantung pada situasi dibanding perspektif tingkat sistem global. Bahkan dengan perkiraan kasar yang optimistis, crane dermaga melakukan 30–50 perpindahan per jam, dengan 2 atau 4 unit per kapal, bahkan sampai 6 unit jika banyak, dan muatan harus dibongkar berlapis-lapis seperti mengupas kulit. Ultra Large Container Vessel berkapasitas 14.501 TEU atau lebih, New Panamax 10.000–14.500 TEU, Post-Panamax 5.101–10.000 TEU, dan Panamax 3.001–5.100 TEU. Jika 24.000 TEU dianggap sebagai 12 ribu kontainer 40 kaki, maka 4 crane × 50 kontainer per jam per crane × 24 jam per hari = sekitar 1.200 kontainer per hari.
    https://en.wikipedia.org/wiki/Stowage_plan_for_container_shi...
    Selain ketersediaan di pelabuhan, perencanaan pemuatan kapal juga memiliki kriteria terkait berat, keseimbangan, daya listrik, dan nilai kargo yang dapat diterima. Karena artikel menyebut keberangkatan lebih awal dari pelabuhan, saya jadi penasaran dengan overhead semacam ini dan mencoba membuat perhitungan kasar

    • Ada ceramah yang diunggah online oleh seorang peneliti dari Technical University of Denmark(DTU), dan ini cukup bagus sebagai pengantar untuk masalah pemuatan: https://www.youtube.com/watch?v=9ltz4G-lPdg
      Dari sudut pandang orang yang benar-benar terlibat di bidang ini, ada banyak cara untuk membuat pekerjaannya lebih mudah. Merencanakan per blok berdasarkan hatch cover, lalu mengelompokkan kontainer menurut tujuan, ukuran, dan berat serta memperlakukannya sebagai dapat saling menggantikan adalah hal mendasar. Setelah itu, jika rencana dikirim dari kapal ke terminal sebelum operasi dimulai, terminal juga mengetahui posisi kontainer di yard sehingga bisa melakukan optimisasi dan relokasi. Jika diputuskan untuk mengabaikan detail tiap kontainer dan hanya berfokus pada grup, perencanaan pemuatan menjadi jauh lebih mudah. Dengan pekerjaan yang jauh lebih sedikit, hasilnya sangat mirip, dan terminal juga mendapat fleksibilitas lebih besar untuk mengoptimalkan operasinya