یک پرونده مشترک
مشتری، استعلام، رزرو، کانتینر، اسناد، رویدادها و مالی زیر یک شناسه عملیاتی قابل ردیابی باشند.
در کسبوکار NVOCC، فروش فضا، رزرو دریایی، اطلاعات کانتینر، اسناد House و Master، رویدادهای بندری و تسویههای چندطرفه به یکدیگر وابستهاند. راهکار سپند این اجزا را حول پرونده مشتری و حمل سازماندهی میکند تا تیم فروش، عملیات، اسناد و مالی روی داده مشترک کار کنند.
برای جزئیات عمومی عملیات حمل دریایی به صفحه روش حمل دریایی بروید. این صفحه روی نقش NVOCC، ارتباط فروش فضا با House/Master، کانتینر و نتیجه مالی تمرکز دارد تا با صفحه روش حمل همپوشانی نداشته باشد.
مواردی مانند قالب قانونی سند، شمارهگذاری، محاسبه خودکار هزینه یا دریافت رویداد بیرونی فقط پس از بررسی نمونه و تأیید در پیشنهاد فنی جزو دامنه اجرایی محسوب میشوند.
مشتری، استعلام، رزرو، کانتینر، اسناد، رویدادها و مالی زیر یک شناسه عملیاتی قابل ردیابی باشند.
نسخه، وضعیت بررسی، مسئول و ارتباط HBL با MBL و محموله روشن بماند.
نرخ خرید، فروش، هزینههای جانبی، دریافت و پرداخت به همان پرونده متصل شوند.
NVOCC فقط یک پرونده حمل دریایی نیست. رابطه قرارداد خرید فضا، فروش به مشتری، اسناد House/Master، عملیات کانتینر و تسویه چندطرفه باید از ابتدا مشخص شود.
مسیرها، برنامه حرکت، نوع سرویس، FCL/LCL، نرخهای خرید و نحوه تخصیص فروش به رزرو اصلی را مستند کنید.
تصمیم طراحی: پرونده مادر، رزروها و حملهای زیرمجموعهتعداد HBL زیر MBL، طرفهای سند، اصلاحات، تأیید مشتری و مسئول نهاییسازی را برای هر نوع سرویس روشن کنید.
تصمیم طراحی: رابطه اسناد، نسخهها و وضعیتهاکرایه، هزینه خط، نماینده، خدمات جانبی، دریافت مشتری و پرداختهای مرحلهای را در سطح درست پرونده تعریف کنید.
تصمیم طراحی: مرکز سود و طرفحساب هر هزینهاجزای زیر از صفحات محصول تخصصی تغذیه میشوند و در این صفحه بهعنوان یک سناریوی واحد NVOCC کنار هم قرار میگیرند.
استعلام مشتری، نرخ تأمینکننده، اعتبار نرخ، پیشنهاد فروش و حاشیه هدف قبل از رزرو کنترل میشوند.
ماژول نرخدهی و فروشرزرو تأییدشده، مسیر، طرفها، رویدادها و وضعیت جاری در پرونده عملیات دنبال میشوند.
صفحه حمل دریاییاسناد به مشتری، Booking و حمل مرتبط میشوند و مسئولیت و مهلت کنترل هر نسخه مشخص میماند.
راهکار مدیریت بارنامههزینههای خط، نماینده و خدمات در کنار فروش و تسویه مشتری برای مشاهده نتیجه واقعی ثبت میشوند.
مالی و حسابداری چندارزیهر مرحله مالک و خروجی مشخص دارد؛ داده تأییدشده مرحله قبل مبنای مرحله بعد میشود.
نیاز مشتری، مسیر، تجهیزات، نرخ خرید و پیشنهاد فروش ثبت و تأیید میشود.
اطلاعات رزرو، برنامه حرکت و کانتینرها به پرونده عملیاتی متصل میشوند.
نسخههای HBL/MBL، تأییدها و رویدادهای حمل با مسئول و زمان کنترل میشوند.
هزینهها، درآمدها، دریافت و پرداخت ثبت و نتیجه مالی پرونده بررسی میشود.
این ساختار امکان میدهد تیمها یک وضعیت مشترک ببینند، در حالی که هر واحد مسئولیت و کنترل تخصصی خود را حفظ میکند.
تعهد به مشتری باید با خرید فضا و شرایط خدمت قابل تطبیق باشد.
هر تجهیز و رویداد باید به حمل مربوط متصل باشد.
اصلاح سند یا هزینه باید بدون قطع ارتباط با پرونده قابل ردیابی باشد.
عدد نهایی باید امکان Drill-down تا پرونده، سند یا کانتینر سازنده آن را داشته باشد.
پروندههای تأییدشدهای که برنامه حرکت، تجهیز، مسئول یا داده اسنادی الزامی ندارند.
کاربرد: صف اقدام پیش از Cut-offHBL/MBLهای پیشنویس یا اصلاحشده بر اساس مسئول و مدت توقف در مرحله.
کاربرد: کاهش تأخیر ناشی از چرخه اصلاحکانتینرهای نزدیک پایان مهلت تعریفشده با وضعیت رویدادهای مؤثر.
کاربرد: اولویتبندی پیگیری عملیاتیدرآمد و هزینه واقعی پروندهها برای مقایسه عملکرد مسیر، مشتری و نوع خدمت.
کاربرد: تصمیم قیمت و ادامه سرویسپایلوت محدود، رابطه دادهها و مسئولیتها را پیش از انتقال همه مسیرها قابل اصلاح میکند.
رابطه Booking، Shipment، Container، HBL و MBL با نمونههای واقعی ترسیم شود.
تحویلدادنی: مدل داده و واژهنامه عملیاتیرویدادهای مسیر، مسئول ثبت، منبع تاریخ و قواعد موارد نیازمند اقدام تعریف شوند.
تحویلدادنی: ماتریس Milestone و Exceptionنمونه اسناد، خدمات قابل فروش و هزینه، طرفهای حساب و نقاط تأیید بررسی شوند.
تحویلدادنی: فهرست قالب و سناریوی مالی آزمونچند پرونده باز و جدید در یک مسیر اجرا، داده و گزارش تطبیق و سپس دامنه توسعه داده شود.
تحویلدادنی: گزارش پذیرش فروش، عملیات، اسناد و مالیپاسخ این پرسشها دامنه پیکربندی، انتقال داده و آموزش را تعیین میکند.
چه رابطهای میان HBL، MBL، Shipment و Container در فرایند شما وجود دارد؟
کدام رویدادها، مهلتها و هزینههای کانتینر باید ثبت یا هشدار داده شوند؟
خط، نماینده، تأمینکننده و مشتری با چه ارزها و قواعد تسویهای کار میکنند؟
سود مسیر، مشتری، سرویس یا پرونده در چه مرحلهای باید قابل مشاهده باشد؟
هر صفحه فقط یک نیت اصلی دارد؛ برای موضوع مکمل از مسیر دقیق زیر استفاده کنید.
برای Booking، رویداد بندری، VGM و نقاط کنترل دریایی، صفحه تخصصی روش حمل را بخوانید.
نرمافزار مدیریت حمل دریاییاگر مسئله اصلی شما تخصیص، وضعیت و مهلتهای کانتینر است، صفحه مدیریت کانتینر دقیقتر است.
راهکار مدیریت کانتینربرای تمرکز بر داده، نسخه، تأیید و ارتباط House/Master به راهکار اسناد بروید.
مدیریت بارنامه حملدامنه معمول شامل مشتری و استعلام، نرخ و فروش، Booking دریایی، کانتینر، House و Master Bill of Lading، رویدادها، هزینه، درآمد و گزارش است؛ دامنه دقیق به مدل کسبوکار هر شرکت بستگی دارد.
خیر. صفحه حمل دریایی روی عملیات یک روش حمل تمرکز دارد؛ راهکار NVOCC ارتباط فروش فضا، ساختار House/Master، کانتینر و مالی چندطرفه را در مدل کسبوکار NVOCC کنار هم قرار میدهد.
نمونه واقعی فیلدها، قالب، شمارهگذاری، نسخه، تأیید و ارتباط اسناد خود را در جلسه تحلیل ارائه کنید. دامنه قابل اجرا باید در دمو و پیشنهاد فنی مکتوب تأیید شود.
یک پرونده دارای چند کانتینر، یک Master، چند House، هزینههای ارزی و چند رویداد بندری انتخاب کنید تا ارتباط فروش، عملیات، اسناد و مالی بررسی شود.
ساختار رزرو، کانتینر، House/Master و تسویههای خود را مطرح کنید تا دامنه راهکار در جلسه دمو شفاف شود.