
Kenapa estimasi tiba yang terlihat akurat saat kendaraan berangkat bisa meleset satu atau dua jam ketika armada sudah berada di jalan? Dynamic ETA logistik adalah estimasi waktu tiba yang diperbarui terus-menerus berdasarkan kondisi perjalanan aktual, bukan hanya jarak dan waktu rencana awal. Tujuannya adalah memberi prediksi yang semakin relevan ketika kendaraan bergerak, berhenti, terkena kemacetan, mengalami antrean, atau menghadapi perubahan urutan stop.
Dalam operasi distribusi, trucking, 3PL, dan freight forwarding, ETA bukan sekadar informasi untuk pelanggan. ETA yang cukup akurat membantu dispatcher mengambil keputusan, warehouse menyiapkan receiving, customer service memberi informasi proaktif, dan tim operasional mendeteksi potensi keterlambatan sebelum berubah menjadi failed delivery.
Key Takeaways: Dynamic ETA Logistik yang Efektif
Dynamic ETA bekerja baik ketika perusahaan tidak hanya mengandalkan GPS. Posisi kendaraan adalah satu input, tetapi prediksi waktu tiba membutuhkan kombinasi data perjalanan, traffic, stop, service time, time window, histori, dan exception. Semakin lengkap konteks yang dibaca sistem, semakin realistis estimasi yang dihasilkan.
Beberapa prinsip utama yang perlu diperhatikan:
- bedakan planned time, estimated time, dan actual time agar performa dapat diukur dengan jelas;
- ETA harus dihitung ulang setelah event penting, bukan hanya saat kendaraan berangkat;
- traffic real-time perlu dibaca bersama data historis karena kondisi jalan dapat berubah cepat;
- dwell time di customer atau hub sering sama pentingnya dengan waktu berkendara;
- time window dan appointment harus menjadi constraint dalam perhitungan downstream stop;
- ETA yang berubah signifikan perlu memicu alert atau customer notification;
- akurasi ETA harus diukur dengan error dalam menit, bukan hanya status “on time” atau “late”.
Dokumentasi Google Maps Routes API membedakan static duration dengan durasi yang memperhitungkan kondisi traffic. Oracle Transportation Management juga membedakan Planned, Estimated, dan Actual arrival/departure time pada shipment stop. Dua konsep ini menunjukkan bahwa ETA operasional seharusnya diperlakukan sebagai data yang dinamis, bukan angka tetap.
Apa Itu Dynamic ETA Logistik?
Dynamic ETA logistik adalah prediksi waktu kedatangan yang diperbarui selama perjalanan berdasarkan data terbaru. Jika ETA statis hanya menggunakan rute dan durasi awal, dynamic ETA membaca perubahan posisi kendaraan, kecepatan, kemacetan, waktu berhenti, urutan stop, serta kejadian yang memengaruhi perjalanan.
Tujuan utamanya bukan menghasilkan angka yang selalu tepat sampai menit terakhir. Dalam operasi nyata, kondisi lapangan tidak sepenuhnya dapat diprediksi. Yang lebih penting adalah menghasilkan estimasi yang cukup akurat, diperbarui pada waktu yang tepat, dan mampu memberi sinyal lebih awal ketika target layanan mulai berisiko.
ETA statis dan ETA dinamis
ETA statis biasanya dihitung sekali berdasarkan jarak dan kecepatan rata-rata. Misalnya kendaraan berangkat pukul 08.00 untuk perjalanan yang diperkirakan tiga jam, sehingga ETA awal adalah 11.00. Jika terjadi antrean 35 menit di lokasi pertama, ETA ke lokasi berikutnya tetap tidak berubah bila sistem tidak melakukan recalculation.
Dynamic ETA menghitung ulang prediksi setelah memperoleh event baru. Ketika kendaraan keluar dari stop pertama pukul 09.20, sistem dapat menilai kembali posisi, traffic, sisa jarak, service time berikutnya, serta time window customer. Hasilnya bisa mengubah ETA dari 11.00 menjadi 11.42 dan langsung memberi tanda bahwa appointment pukul 11.30 berisiko terlewat.
Planned, estimated, dan actual time
Dalam sistem transportasi yang matang, tiga waktu perlu disimpan terpisah. Planned time adalah jadwal yang disepakati atau dibentuk saat planning. Estimated time adalah perkiraan terbaru. Actual time adalah waktu kejadian sebenarnya ketika armada tiba atau meninggalkan lokasi.
Oracle Transportation Management mendokumentasikan tiga set waktu tersebut pada shipment stop. Setelah tender diterima, planned time dapat tetap sebagai baseline, sementara estimated time dapat berubah mengikuti update operasional dan actual time digunakan untuk membandingkan realisasi terhadap rencana. Struktur ini penting karena tanpa baseline yang tetap, perusahaan sulit mengukur seberapa besar deviasi dan seberapa akurat prediksi sebelumnya.
7 Data yang Membuat Dynamic ETA Logistik Lebih Akurat
Tidak ada satu sumber data yang cukup untuk menghasilkan ETA yang kuat. Bahkan lokasi GPS yang sangat presisi belum tentu memberi prediksi baik jika sistem tidak mengetahui armada sedang menunggu bongkar, customer hanya menerima sampai pukul 16.00, atau kendaraan harus melakukan empat stop sebelum tujuan akhir.
Tujuh kelompok data berikut dapat dijadikan fondasi saat perusahaan merancang ETA engine, dashboard transportasi, atau integrasi antara TMS, driver app, telematics, dan map service.
1. Posisi GPS, timestamp, dan kecepatan kendaraan
Posisi GPS adalah titik awal untuk mengetahui seberapa jauh kendaraan telah bergerak dari rencana. Sistem sebaiknya menyimpan latitude, longitude, timestamp, heading bila tersedia, dan kecepatan. Timestamp sangat penting karena koordinat tanpa waktu dapat memberi kesan kendaraan berada di lokasi terbaru padahal data sudah tertunda beberapa menit.
Frekuensi update juga perlu realistis. Tracking setiap beberapa detik belum tentu diperlukan untuk operasional freight, sementara update terlalu jarang membuat ETA lambat merespons perubahan. Perusahaan dapat menentukan interval berdasarkan jenis layanan, nilai shipment, kebutuhan customer, dan biaya telematics.
2. Traffic real-time dan traffic historis
Kondisi traffic dapat mengubah waktu perjalanan secara signifikan terutama di area perkotaan seperti Jabodetabek, Surabaya, Bandung, Medan, dan koridor industri. Google Maps Routes API menyediakan opsi TRAFFIC_AWARE dan TRAFFIC_AWARE_OPTIMAL yang menggunakan kondisi traffic saat menghitung durasi, sedangkan static duration tidak memasukkan kondisi traffic saat ini.
Data historis tetap penting karena live traffic hanya menggambarkan kondisi saat ini. Untuk departure time yang berada di masa depan, pola historis membantu memperkirakan kecenderungan jam sibuk. Karena itu, ETA engine sebaiknya mampu membedakan “apa yang terjadi sekarang” dan “apa yang biasanya terjadi pada jam tersebut”. Referensi teknis dapat dilihat pada Google Maps Routes API traffic options.
3. Rute aktual dan urutan stop
ETA ke customer keempat tidak cukup dihitung dari posisi kendaraan ke customer keempat. Sistem perlu mengetahui customer kedua dan ketiga masih harus dikunjungi, termasuk jarak antar stop, kemungkinan reroute, serta urutan yang telah dioptimalkan. Perubahan satu stop dapat memengaruhi seluruh ETA downstream.
Karena itu, dynamic ETA sebaiknya terhubung dengan hasil route optimization logistik. Jika dispatcher memindahkan urutan stop karena customer belum siap menerima barang, ETA perlu dihitung ulang untuk seluruh stop sesudahnya, bukan hanya tujuan yang dipindahkan.
4. Dwell time, loading, unloading, dan service time
Dalam pengiriman multi-drop, kendaraan dapat menghabiskan banyak waktu dalam keadaan tidak bergerak. Durasi bongkar 15 menit yang berubah menjadi 55 menit bisa lebih besar dampaknya daripada tambahan jarak beberapa kilometer. Karena itu, service time per customer perlu menjadi input perencanaan dan terus dikalibrasi dari data aktual.
Dwell time dapat dibentuk berdasarkan tipe lokasi, jenis komoditas, jumlah koli, pallet, aktivitas dokumen, antrean dock, dan histori customer. Misalnya outlet retail mungkin rata-rata membutuhkan 20 menit, sementara DC modern trade memerlukan 70 menit karena appointment, pemeriksaan dokumen, dan antrean receiving.
5. Time window, appointment, dan jam operasional lokasi
ETA yang paling cepat belum tentu ETA yang valid. Kendaraan bisa tiba pukul 06.30 tetapi warehouse baru menerima kendaraan pukul 08.00. Sistem perlu memahami jam buka, delivery window, appointment start-end, hari libur, dan toleransi keterlambatan agar estimasi mencerminkan waktu operasional yang sebenarnya.
Oracle Transportation Management menjelaskan bahwa appointment dan estimated arrival dapat berdampak pada estimated departure serta waktu stop downstream. Prinsip ini sangat relevan untuk operasi Indonesia yang melayani distribution center, pabrik, pelabuhan, atau customer dengan jadwal receiving ketat. Detail konsep Planned, Estimated, dan Actual dapat dilihat pada Oracle Transportation Management Shipment Stop Details.
6. Kondisi driver, kendaraan, dan aturan perjalanan
ETA tidak hanya dipengaruhi jalan. Istirahat driver, pergantian pengemudi, pembatasan kendaraan, kapasitas, kondisi ban, kebutuhan pengisian BBM, serta larangan jam tertentu dapat mengubah waktu tiba. Untuk operasi long haul, ETA yang mengabaikan rest time cenderung terlalu optimistis.
Pada armada tertentu, pembatasan rute karena tinggi kendaraan, berat, jenis muatan, atau akses lokasi juga perlu dipertimbangkan. Data kendaraan dan driver sebaiknya berada dalam master yang terhubung dengan TMS sehingga ETA engine tidak menghitung perjalanan berdasarkan asumsi kendaraan penumpang biasa.
7. Data historis performa, exception, dan pola customer
Data historis membantu menjawab pertanyaan yang tidak terlihat dari peta. Apakah customer A selalu membutuhkan bongkar dua kali lebih lama pada hari Senin? Apakah rute tertentu konsisten mengalami keterlambatan setelah pukul 15.00? Apakah transporter tertentu memiliki response time lebih lambat ketika terjadi breakdown?
Histori juga perlu menghubungkan ETA dengan delivery exception management. Ketika exception seperti vehicle breakdown, receiver not available, road closure, atau document issue terjadi, sistem perlu menyesuaikan ETA dan menyimpan penyebab deviasi sebagai data pembelajaran untuk evaluasi berikutnya.
Tabel Data Minimum untuk Mesin ETA
Perusahaan tidak perlu langsung membangun model prediktif kompleks. Langkah awal yang lebih penting adalah memastikan data minimum tersedia, konsisten, dan memiliki timestamp. Tabel berikut dapat menjadi checklist ketika tim IT dan operasional mengevaluasi kesiapan dynamic ETA.
Frekuensi update pada tabel adalah contoh desain, bukan standar universal. Interval ideal tetap bergantung pada tipe layanan dan kebutuhan bisnis.
| Data | Sumber | Contoh Update | Dampak ke ETA |
|---|---|---|---|
| GPS & timestamp | Telematics/Driver App | 1–5 menit | Menentukan posisi aktual |
| Traffic | Map/Traffic API | Real-time | Menyesuaikan travel duration |
| Stop sequence | TMS/Route Planner | Saat reroute | Mengubah ETA downstream |
| Service time | Driver App/TMS | Setiap stop | Mengoreksi waktu berhenti |
| Time window | Master Customer | Saat ada perubahan | Menentukan feasible arrival |
| Vehicle/driver constraint | FMS/TMS | Per trip | Mencegah ETA terlalu optimistis |
| Historical performance | Data Warehouse/BI | Harian/mingguan | Kalibrasi pola aktual |
Bagaimana Alur Perhitungan Dynamic ETA?
Alur paling sederhana dimulai dari planned route dan planned arrival. Setelah kendaraan berjalan, sistem membaca event baru lalu menghitung ulang sisa perjalanan. Recalculation dapat dilakukan berdasarkan interval waktu atau event tertentu, misalnya kendaraan meninggalkan stop, deviasi rute, kemacetan meningkat, atau service time melebihi batas.
Secara praktis, workflow dapat disusun seperti berikut:
- ambil posisi kendaraan dan timestamp terbaru;
- validasi apakah kendaraan masih mengikuti rute aktif;
- ambil kondisi traffic dan sisa travel duration;
- tambahkan sisa service time dan constraint stop berikutnya;
- hitung ETA untuk stop terdekat;
- propagasi perubahan ke seluruh stop downstream;
- bandingkan ETA baru dengan appointment atau SLA;
- buat alert jika deviasi melewati threshold.
ETA yang baik bukan sekadar angka kedatangan. ETA harus menjadi early warning yang memberi tim cukup waktu untuk mengambil tindakan sebelum SLA benar-benar terlewat.
Sistem sebaiknya tidak mengirim notifikasi setiap kali ETA bergeser satu atau dua menit. Gunakan threshold, misalnya perubahan lebih dari 15 menit, perubahan status dari “on track” menjadi “at risk”, atau prediksi terlambat melewati appointment. Dengan begitu, user tidak mengalami alert fatigue.
Contoh Dynamic ETA pada Distribusi Multi-Drop di Surabaya
Bayangkan satu armada distribusi berangkat dari warehouse Surabaya pukul 08.00 untuk delapan customer di Surabaya, Sidoarjo, dan Gresik. Planned ETA customer keempat adalah 11.15. Pada customer kedua, proses bongkar yang direncanakan 20 menit ternyata membutuhkan 55 menit karena antrean receiving.
Jika sistem hanya memakai ETA awal, customer keempat tetap terlihat akan dikunjungi pukul 11.15. Dynamic ETA membaca actual departure dari customer kedua, traffic terbaru, dan sisa stop. ETA customer keempat kemudian berubah menjadi 12.05. Karena appointment customer tersebut berakhir pukul 11.45, status dapat berubah menjadi At Risk sebelum armada benar-benar terlambat.
Dispatcher memiliki beberapa opsi: menukar urutan stop, menghubungi customer untuk memperpanjang appointment, mengalokasikan shipment tertentu ke kendaraan lain, atau mempertahankan rute dan menginformasikan keterlambatan secara proaktif. Nilai bisnis dynamic ETA berada pada waktu tambahan untuk mengambil keputusan tersebut.
Kasus seperti ini juga menunjukkan pentingnya Logistics Control Tower. Control tower yang menampilkan ETA, deviasi, exception, dan prioritas tindakan jauh lebih berguna daripada dashboard yang hanya menampilkan titik kendaraan di peta.
KPI untuk Mengukur Akurasi ETA
Perusahaan perlu mengukur apakah ETA membaik dari waktu ke waktu. KPI yang hanya menyatakan “delivery on time” tidak cukup karena on-time performance mengukur hasil layanan, sedangkan ETA accuracy mengukur kualitas prediksi.
Beberapa KPI yang dapat digunakan adalah Mean Absolute Error, persentase ETA dalam toleransi, prediction lead time, dan persentase alert yang diberikan sebelum SLA terlewat. KPI perlu dipisahkan per tipe layanan, wilayah, transporter, dan customer karena karakter perjalanan berbeda.
Mean Absolute Error dalam menit
Mean Absolute Error (MAE) dapat dihitung sebagai rata-rata nilai absolut selisih antara ETA terakhir yang dinilai dengan actual arrival. Jika lima shipment memiliki error 8, 12, 15, 5, dan 10 menit, MAE-nya adalah 10 menit. Semakin kecil angka ini, semakin dekat prediksi terhadap realisasi.
Perusahaan perlu menentukan titik evaluasi ETA. ETA lima menit sebelum tiba pasti cenderung lebih akurat daripada ETA dua jam sebelumnya. Karena itu, metrik dapat dibagi menjadi ETA error 120 menit sebelum arrival, 60 menit sebelum arrival, dan 30 menit sebelum arrival.
Prediction lead time dan alert usefulness
Prediction lead time mengukur seberapa jauh sebelum actual late event sistem sudah mendeteksi risiko. Jika shipment terlambat pada pukul 14.00 tetapi sistem sudah memberi sinyal pada 12.45, tim memiliki 75 menit untuk melakukan mitigasi.
KPI tambahan dapat berupa persentase late shipment yang sudah ditandai At Risk minimal 30 menit sebelumnya. Ini lebih operasional daripada sekadar mencari ETA paling presisi karena prediksi yang sedikit kurang presisi tetapi diberikan lebih awal sering lebih berguna untuk pengambilan keputusan.
Dynamic ETA dalam TMS dan Operasi Transportasi
Dynamic ETA akan lebih bernilai jika tidak berdiri sebagai aplikasi peta terpisah. Data perlu terhubung dengan order, shipment, kendaraan, driver, customer, appointment, ePOD, carrier, dan exception. Dengan hubungan tersebut, perubahan ETA dapat memicu tindakan sesuai konteks bisnis.
SOLOG Transportation Management System dapat menjadi salah satu referensi platform untuk mengelola proses transportasi secara terintegrasi. Saat menilai TMS, perusahaan sebaiknya tidak hanya menanyakan apakah sistem memiliki GPS tracking, tetapi juga apakah status perjalanan, route plan, ETA, exception, dan bukti pengiriman dapat dikonsolidasikan dalam satu histori shipment.
Di industri global, penggunaan analytics untuk ETA sudah diterapkan pada berbagai moda. Pada 23 Mei 2022, DHL Global Forwarding menyatakan fitur Smart ETA di myDHLi dapat memprediksi kedatangan ocean freight hingga 48% lebih akurat dibanding informasi yang diberikan carrier pada konteks implementasi mereka. Fakta ini tidak boleh dijadikan benchmark langsung untuk trucking Indonesia, tetapi menunjukkan bahwa kualitas ETA dapat ditingkatkan melalui penggabungan data dan analytics. Sumber aslinya tersedia di DHL Group.

Kesalahan yang Sering Membuat ETA Tidak Akurat
Kesalahan pertama adalah memperlakukan GPS sebagai satu-satunya sumber kebenaran. Lokasi kendaraan memberi tahu “di mana”, tetapi belum menjelaskan “mengapa berhenti”, “berapa lama akan berhenti”, dan “stop apa yang harus dikunjungi berikutnya”. Tanpa konteks tersebut, ETA hanya menjadi perhitungan jarak yang dibungkus dashboard.
Kesalahan kedua adalah tidak menyimpan planned time sebagai baseline. Jika estimated time selalu menimpa jadwal awal, perusahaan kehilangan kemampuan mengukur deviasi. Kesalahan lain yang juga sering terjadi adalah:
- service time semua customer dibuat sama;
- appointment dan jam operasional tidak dimasukkan;
- ETA tidak dihitung ulang setelah departure dari stop;
- perubahan stop sequence tidak memicu downstream recalculation;
- tidak ada threshold untuk alert;
- data GPS terlambat tetapi tetap dianggap real-time;
- akurasi ETA tidak pernah diukur terhadap actual arrival.
Implementasi yang baik biasanya dimulai dari data discipline. Pastikan event arrival/departure konsisten, reason exception terstruktur, timestamp sinkron, dan master customer bersih sebelum mengejar model prediksi yang lebih canggih.
FAQ tentang Dynamic ETA Logistik
Dynamic ETA sering dianggap identik dengan live tracking, padahal keduanya berbeda. Live tracking menunjukkan posisi kendaraan, sedangkan ETA adalah hasil prediksi mengenai kapan kendaraan akan tiba berdasarkan posisi dan berbagai faktor operasional lain.
Berikut beberapa pertanyaan yang sering muncul saat perusahaan mulai mengembangkan ETA yang lebih dinamis.
Apakah dynamic ETA harus menggunakan AI?
Tidak. Dynamic ETA dapat dimulai dari rule-based calculation menggunakan GPS, traffic, route, service time, dan time window. Pendekatan ini sudah jauh lebih baik daripada ETA statis yang tidak pernah diperbarui.
Machine learning atau AI dapat ditambahkan ketika data historis sudah cukup, misalnya untuk memprediksi dwell time customer atau bias durasi pada rute tertentu. Namun model yang canggih tidak akan membantu jika input GPS, stop event, dan master data masih tidak konsisten.
Berapa frekuensi ideal update ETA?
Tidak ada angka universal. Last-mile dengan banyak stop mungkin membutuhkan update lebih sering, sedangkan long haul antarkota dapat menggunakan interval lebih panjang dan event-based recalculation. Fokusnya adalah seberapa cepat perubahan signifikan dapat terdeteksi tanpa membebani sistem dan user.
Pendekatan praktis adalah menghitung ulang ETA ketika ada event penting—arrival, departure, reroute, exception—ditambah interval periodik selama kendaraan bergerak. Sistem dapat menyesuaikan interval berdasarkan jarak ke tujuan atau tingkat risiko SLA.
Apakah ETA yang berubah-ubah akan membingungkan customer?
Bisa, jika setiap perubahan kecil langsung dikirim. Customer lebih membutuhkan estimasi yang stabil dan notifikasi saat perubahan benar-benar material. Karena itu, gunakan threshold dan status seperti On Track, At Risk, dan Delayed daripada mengirim update tiap beberapa menit.
Customer notification juga dapat menggunakan window, misalnya “diperkirakan tiba 13.30–14.00”, jika ketidakpastian masih tinggi. Window dapat dipersempit ketika kendaraan semakin dekat dan confidence prediksi meningkat.
Kesimpulan
Dynamic ETA logistik mengubah estimasi waktu tiba dari angka statis menjadi alat pengendalian operasi. Akurasinya bergantung pada kombinasi GPS, traffic, rute, stop sequence, dwell time, time window, kondisi kendaraan/driver, serta data historis dan exception.
Perusahaan tidak perlu langsung membangun algoritma kompleks. Mulailah dengan memisahkan Planned, Estimated, dan Actual time, memperbaiki event tracking, menghubungkan traffic dan route data, lalu mengukur ETA error secara konsisten. Setelah fondasi data stabil, dynamic ETA dapat berkembang menjadi early warning yang membantu dispatcher, customer service, warehouse, dan pelanggan mengambil keputusan sebelum keterlambatan benar-benar terjadi.








