چند بار باید یک نرم‌افزار را از نو بسازیم؟
در سرمایه‌گذاری فناوری لجستیک، چه زمانی توسعه اختصاصی لازم است و چه زمانی رشد راهکار موجود یا همکاری در زیرساخت مشترک، مسئله صنعت را بهتر حل می‌کند؟
ورود شرکت‌های بزرگ حمل‌ونقل به سرمایه‌گذاری در فناوری، اتفاقی است که باید از آن استقبال کرد.
در مرداد ۱۴۰۵، شرکت‌های ترکیب حمل‌ونقل و راه‌آهن حمل‌ونقل در قالب یک تفاهم‌نامه سه‌جانبه، به‌عنوان سرمایه‌گذار وارد پروژه راه‌اندازی یک پلتفرم هوشمند خدمات حمل بار بین‌المللی شدند و مقرر شد توسعه‌دهنده محصول نیز انتخاب شود. اصل این اتفاق، فارغ از اینکه محصول نهایی چه خواهد بود، پیام مهمی دارد:
سرمایه‌گذاری در حمل‌ونقل دیگر فقط خرید واگن، کامیون، زمین و تجهیزات نیست؛ فناوری نیز بخشی از زیرساخت رقابت شده است [ ۱ ].
اما هرچه این نوع سرمایه‌گذاری بیشتر می‌شود، یک سؤال هم مهم‌تر می‌شود:
قبل از اینکه محصول جدیدی بسازیم، آیا بررسی کرده‌ایم چیزی که به آن نیاز داریم قبلاً ساخته شده یا نه؟ و اگر ساخته شده، سؤال مهم‌تر این است: چرا به اندازه کافی رشد نکرده است؟ ضعف محصول؟ کمبود سرمایه؟
کمبود مشتری؟ عدم استقبال کاربران؟ دشواری اتصال به سایر سامانه‌ها؟ یا پراکندگی بازار میان چند راهکار مشابه؟
گاهی مشکل این نیست که نرم‌افزار نداریم
در ایران همین امروز محصولات تخصصی متعددی برای حمل‌ونقل، فورواردری، کشتیرانی، عملیات کانتینری و حمل ریلی وجود دارند. بعضی از آنها هم صرفاً نمونه آزمایشی نیستند.
برای مثال، شرکت ساینا از سال ۱۴۰۱ راهکار لجستیکی خود را در شرکت ترکیب حمل‌ونقل مستقر کرده است؛
سامانه‌ای که بخش‌هایی مانند مدیریت واگن و قطار، فرآیند حمل، رهگیری، قراردادها و درخواست حمل را پوشش می‌دهد [ ۲ ].
شرکت ناب‌افزار ایرانیان نیز «کاروان» را برای شرکت‌های فورواردری و نمایندگی خطوط کشتیرانی توسعه داده و قابلیت‌هایی مانند اعلام نرخ، رزرو، رهگیری، اسناد، پرداخت و اتصال سیستمی با خطوط، دپوها، بندر، گمرک و سایر شرکای تجاری برای آن معرفی کرده است [ ۳ ].
اما تجربه‌ای که شخصاً در مذاکرات با مدیران ناب‌افزار برای من قابل تأمل بود، مربوط به یکی از همین قابلیت‌هاست.
در آن مذاکرات درباره ماژول بوکینگ کانتینر کاروان توضیح داده شد که یکی از مشکلات رشد آن، استقبال و استفاده ناکافی کاربران بوده است.
ساختن قابلیت، الزاماً به معنی ساختن بازار برای آن نیست.
ممکن است محصول از نظر فنی قابلیت داشته باشد، اما اگر تعداد کافی از خطوط، فورواردرها یا صاحبان کالا از آن استفاده نکنند، فرصت رشد واقعی پیدا نمی‌کند. و از اینجا یک چرخه دشوار آغاز می‌شود: مشتری کمتر یعنی درآمد کمتر؛ درآمد کمتر یعنی منابع محدودتر برای توسعه؛ و توسعه کندتر نیز می‌تواند جذب مشتریان بعدی را دشوارتر کند.
یک مثال آشناتر
سال‌هایی که بازار تاکسی اینترنتی ایران در حال شکل‌گیری بود، فقط اسنپ و تپسی در میدان نبودند. پلتفرم‌هایی مثل «دینگ» نیز با قابلیت‌هایی مانند رزرو سفر، تاکسی در اختیار و خدمات سازمانی وارد بازار شدند. در همان زمان تقریباً هر ماه خبر ورود یک سرویس جدید منتشر می‌شد [۴].
اما در چنین بازاری، داشتن اپلیکیشن خوب کافی نیست. مسافر معمولاً جایی می‌رود که راننده بیشتری باشد؛ راننده هم پلتفرمی را ترجیح می‌دهد که مسافر بیشتری داشته باشد. بنابراین بازیگری که زودتر به مقیاس برسد، مزیتی پیدا می‌کند که صرفاً با افزودن چند قابلیت نرم‌افزاری جبران نمی‌شود.
ارزش بعضی محصولات، با تعداد کاربرانشان افزایش پیدا می‌کند.
همین اتفاق می‌تواند در یک پلتفرم بوکینگ کانتینر رخ دهد. اگر خطوط کافی روی آن حضور نداشته باشند، فورواردر انگیزه چندانی برای استفاده روزانه ندارد. و اگر فورواردر و صاحب کالای کافی نباشند، خط کشتیرانی نیز دلیل زیادی برای صرف هزینه و اتصال سیستم خود نمی‌بیند. پس مسئله فقط توسعه نرم‌افزار نیست؛ ساختن بازار برای نرم‌افزار هم هست.
وقتی همان بازار محدود را چند قسمت کنیم
این موضوع در بازارهای تخصصی مهم‌تر می‌شود. بازار یک نرم‌افزار تخصصی برای فورواردری، کشتیرانی یا حمل بین‌المللی ایران، بازاری با میلیون‌ها خریدار بالقوه نیست.
اگر در چنین بازاری چند مجموعه برای حل تقریباً یک مسئله مشابه، محصولات مستقل بسازند، ممکن است هر محصول فقط بخشی از مشتریان را جذب کند؛ سرمایه توسعه بین چند تیم تقسیم شود؛ داده و بازخورد عملیاتی پراکنده شود؛ و هیچ‌کدام به اندازه‌ای نرسند که توسعه مستمر آنها از نظر اقتصادی جذاب باشد.
این رابطه را نمی‌توان بدون داده درباره تک‌تک محصولات ایرانی قطعی دانست. اما سؤال مهمی ایجاد می‌کند:
آیا ممکن است صنعت همزمان از کمبود فناوری شکایت کند و شرکت‌های فناوری نیز از کمبود مشتری و سرمایه برای توسعه همان فناوری رنج ببرند؟
اگر پاسخ در بعضی حوزه‌ها مثبت باشد، راه‌حل الزاماً ساخت محصول بیشتر نیست.
البته توسعه اختصاصی هم می‌تواند تصمیم درستی باشد
این بحث به معنی مخالفت با توسعه داخلی فناوری نیست. شرکتی که می‌خواهد سیستم قیمت‌گذاری، مدیریت مشتری، تحلیل داده یا فرآیند عملیاتی اختصاصی خودش را بسازد، ممکن است کاملاً منطقی تصمیم بگیرد تیم نرم‌افزار داخلی ایجاد کند. فناوری در اینجا می‌تواند بخشی از مزیت رقابتی بنگاه باشد.
مسئله زمانی متفاوت می‌شود که یک قابلیت اساساً برای تعامل میان چندین شرکت ساخته می‌شود. مثلاً اگر ده‌ها شرکت باید درباره بوکینگ، وضعیت کانتینر، اسناد یا رویدادهای حمل با یکدیگر اطلاعات ردوبدل کنند، آیا لازم است هرکدام زبان و مسیر ارتباطی متفاوتی تعریف کنند؟
اینجا مرز مهمی میان فناوری اختصاصی بنگاه و زیرساخت مشترک صنعت شکل می‌گیرد.
رقابت لازم است؛ دوباره‌کاری نه
راه‌حل هم این نیست که کل صنعت فقط یک نرم‌افزار داشته باشد. انحصار یک تأمین‌کننده می‌تواند وابستگی، کاهش نوآوری و نگرانی درباره مالکیت داده ایجاد کند.
پس سؤال واقعی «یک نرم‌افزار یا چند نرم‌افزار؟» نیست.
کدام بخش باید رقابتی باشد و کدام بخش بهتر است مشترک باشد؟
ده شرکت می‌توانند ده نرم‌افزار متفاوت داشته باشند، اما لازم نیست ده تعریف متفاوت برای یک رویداد حمل یا ده استاندارد ناسازگار برای تبادل اطلاعات ایجاد کنند.
تجربه جهانی چه می‌گوید؟
در صنعت ریلی آمریکای شمالی، شرکت‌های ریلی همچنان رقیب‌اند و سیستم‌های اختصاصی خود را دارند، اما بخشی از زیرساخت اطلاعاتی مشترک صنعت از طریق Railinc اداره می‌شود. Railinc، زیرمجموعه Association of American Railroads، بیش از ۳۰۰ میلیون تراکنش اطلاعاتی در روز پردازش می‌کند و به‌عنوان ستون فقرات دیجیتال شبکه ریلی باری عمل می‌کند [۵].
در کشتیرانی کانتینری نیز ده خط بزرگ جهان که حدود ۷۵ درصد تجارت کانتینری جهانی را نمایندگی می‌کنند، از طریق DCSA روی استانداردهای مشترک دیجیتال کار می‌کنند. هدف DCSA این نیست که همه خطوط یک نرم‌افزار داشته باشند؛ هدف این است که سیستم‌های مختلف بتوانند با زبان و استاندارد مشترک با یکدیگر ارتباط برقرار کنند [ ۶ ].
INTTRA نمونه عملی دیگری است. امروز شبکه Ocean Bookings آن امکان ارتباط فورواردرها و صاحبان کالا با بیش از ۱۰۰ Carrier و NVOCC را از طریق یک اتصال مشترک فراهم می‌کند؛ بدون اینکه مشتری مجبور باشد سیستم داخلی خودش را کنار بگذارد [ ۷ ].
شرکت‌ها لازم نیست برای رقابت، زیرساخت ارتباط با یکدیگر را هم هر بار از نو بسازند.
شاید سؤال اول سرمایه‌گذاری را اشتباه می‌پرسیم
وقتی یک نیاز فناوری در سازمان شناسایی می‌شود، معمولاً یکی از اولین سؤال‌ها این است: چه کسی این نرم‌افزار را برای ما می‌سازد؟ شاید ترتیب بهتری وجود داشته باشد.
ابتدا بپرسیم: آیا محصول مناسبی در بازار وجود دارد؟ اگر هست ولی کامل نیست، آیا می‌توان آن را توسعه داد؟ آیا شرکت فناوری مناسبی وجود دارد که بتوان روی آن سرمایه‌گذاری یا با آن شریک شد؟ اگر مسئله میان چند شرکت مشترک است، آیا می‌توان تقاضا و سرمایه را تجمیع کرد؟ و فقط اگر این مسیرها جواب ندادند، از صفر بسازیم.
اول جست‌وجو، بعد سرمایه‌گذاری، و در صورت لزوم ساخت.
مهم‌ترین سرمایه همیشه پول نیست
این نکته به‌ویژه درباره پلتفرم‌های لجستیکی مهم است. یک شرکت نرم‌افزاری ممکن است علاوه بر سرمایه نقدی، به چیزی کمیاب‌تر احتیاج داشته باشد: کاربر واقعی.
اگر یک انجمن بتواند چند خط کشتیرانی، چند فورواردر و چند صاحب کالای بزرگ را برای اجرای یک راهکار مشترک کنار هم قرار دهد، ارزشی ایجاد می‌کند که شرکت نرم‌افزاری به‌تنهایی به‌سادگی نمی‌تواند ایجاد کند.
اینجاست که نقش اصناف می‌تواند از «سفارش‌دهنده نرم‌افزار» فراتر برود. تشکل حرفه‌ای می‌تواند مسئله مشترک اعضا را شناسایی کند؛ راهکارهای موجود را بررسی کند؛ کاربران اولیه را برای پایلوت کنار هم بیاورد؛ استانداردهای ارتباطی مشترک ایجاد کند؛ و اگر سرمایه لازم است، سرمایه اعضا را روی مسئله‌ای متمرکز کند که ارزش مشترک می‌سازد.
در این مدل، انجمن قرار نیست شرکت نرم‌افزاری شود؛ قرار است معمار همکاری فناورانه صنعت باشد.
قبل از پروژه بعدی، یک سؤال
شاید قبل از هر سرمایه‌گذاری مهم فناوری در حمل‌ونقل، یک مرحله ساده لازم باشد:
چه چیزی قبلاً ساخته شده و چرا به اندازه کافی رشد نکرده است؟ اگر مشکل محصول است، محصول بهتر بسازیم. اگر مشکل سرمایه است، سرمایه وارد کنیم. اگر مشکل کمبود مشتری است، بازار اولیه ایجاد کنیم. اگر مسئله اتصال سیستم‌هاست، استاندارد مشترک تعریف کنیم. و اگر قابلیت موردنظر واقعاً مزیت رقابتی یک بنگاه است، همان بنگاه باید آن را برای خودش توسعه دهد.
این نگاه، مخالفت با ساخت نرم‌افزار جدید نیست. هدفش این است که سرمایه محدود صنعت بیشتر صرف نوآوری واقعی شود و کمتر صرف تکرار چیزی که پیش‌تر ساخته شده است.
رقابت در بازار، همکاری در زیرساخت
ورود شرکت‌های حمل‌ونقل به سرمایه‌گذاری فناورانه اتفاق مثبتی است. اما بلوغ مرحله بعد شاید صرفاً افزایش تعداد پروژه‌های نرم‌افزاری نباشد.
بلوغ واقعی زمانی آغاز می‌شود که بتوانیم پاسخ دهیم:
کدام فناوری را باید خودمان بسازیم، کدام فناوری موجود را باید رشد دهیم و کدام مسئله را بهتر است با هم حل کنیم؟
پاسخ همه موارد «همکاری» نیست. پاسخ همه موارد هم «توسعه اختصاصی» نیست.
در بازار با هم رقابت کنیم؛ در زیرساخت مشترک، هزینه حل یک مسئله را چند بار پرداخت نکنیم.
منابع منتخب
خبر سرمایه‌گذاری مشترک شرکت‌های ترکیب حمل‌ونقل و راه‌آهن حمل‌ونقل — tarkibtrans.ir
استقرار ساینا لجستیک در شرکت ترکیب حمل‌ونقل — saynasystem.com
گزارش معرفی سرویس تاکسی اینترنتی دینگ — digiato.com
