本文へスキップします。

H1

JILSニュース

お知らせ詳細

あなたの会社は大丈夫?国際物流DXのよくある失敗事例/連載コラム

国際物流強靭化

「可視化からはじめる国際物流DX」という大テーマのもと、前回(第4回)は「国際物流DX成功の第一歩!3つの可視化から始めよう」というテーマで、DXの第一歩として取り組むべき3つの可視化について見ていきました。

第5回の今回は、前回の推奨アクションとは逆に推奨しないアクションについて、国際物流DXの失敗事例を見ながら説明していきたいと思います。

ハービット株式会社 代表取締役 仲田紘司 氏
東京大学および同大学院卒業後、日本郵船に入社。コンテナ船の営業として輸出入・三国間等数十社の荷主・フォワーダーを担当。既存産業のデジタル化への課題感からアクセンチュアに入社し、DX案件を中心に業界横断で多数の大手企業に対するコンサルティングを経験。プラグ・アンド・プレイ・ジャパンにて大手企業のオープンイノベーション支援を経て、現職。国際物流強靭化推進研究会メンバー ○企業WEBサイト(https://harbitt.com

国際物流に限らないどの領域にも共通するような一般的なDXの失敗事例については、「DX 失敗 事例」等のキーワードでインターネットで検索すれば多くの記事が見つかります。例えば経済産業省の「DXレポート」等でもDXの失敗事例については触れられていますので、まだ読まれたことがない方はこの機会に是非ご一読されるとよいかと思います。

「DXの失敗については既にそれだけ多くの記事があるのに、なぜまたコラムを書こうとしているのか?」と問われると、一言で言えば「それでも(類似した)失敗事例が絶えないから」です。DXの失敗事例について書かれた多くの記事・文献については、

  • 国際物流に特化した内容のものはない
  • 内容が抽象的で実際の取り組みのなかで活かせるイメージが沸かない

といったお声を多く伺うため、今回は「国際物流に特化」し、「事例を挙げながらできるだけ具体的に」失敗事例とそこからの学びについて書くように努めます。

なお、国際物流のDXについては多くの場合自社システムを開発するよりも外部企業のシステムを導入するケースの方が多いですので、今回は外部IT企業(以下、IT企業と呼ぶ)のSaaS等システム導入によってDXを目指すケースを想定しています。

以下、3つの失敗事例について具体的な事例と事例からの学びを説明していきます。

ケース1.目的が不明確。後から考えようとしている

「システム導入が目的化してしまっている」と言っても過言ではないケースです。
国際物流に限らずですが、「可視化したいと思って可視化システムを導入したら見事に上手くいった!」という事例はほぼ聞いたことがありません。しかしながら、DXにおいて重要であるデータに関しても「まずはデジタル化してデータで可視化できるようにしよう。分析についてはその後考えよう(データさえあればいかようにも分析できるはずだ)」というようなスタンスを多々見受けます。

ケース2.検証や根拠なくIT企業の主張を鵜呑みにしてしまう

「弊社はこういうことを実現したい」と自社の国際物流DX構想をIT企業に伝えることは、比較的多くの企業において適切に実施されているように見受けます。一方で、それに対して高い確率でIT企業側は「できます」と主張しますが、それをほぼ検証することなく鵜呑みにして導入し、後々痛い目を見る事例が非常に多いです。

ケース3.導入したら終わりになってしまっている

他の業務もあって多忙ななか、どうしても導入まででプロジェクトが一区切りとなり、導入後はあまり工数を割けないという事情はわかりますが、よいシステムを導入してもそれが「使われる」→「期待した成果が出る」とならなければ意味がありません。しっかりモニタリングする体制・手順を定めておくことが重要なのです。

というのも、フレート管理にしてもブッキングにしてもトラッキングにしても、システム的にはさほど難しくないことのようですが、落とし穴は意外と多いものです。「最もブランド力があり導入企業も多い企業を選んだから大丈夫に違いない」と思う気持ちは理解できますが、導入を決めた担当者は安心しきって導入後まったく気にかけていなかったものの、半年や1年経ってシステムを利用する現場の担当者と会話すると「全然使われていない」実態がわかったというケースは悲しいほど多いです。

学び1.実現したい理想形、必要データを最低限明らかにする

A社はDXを推進すべくフレート管理システムを導入したものの、残念ながら1年で解約してしまいました。プロジェクトの担当者に詳細を伺った際に、以下の点が気になりました。

  • そもそも「フレート管理」に最初に取り組んだ理由は「何となくコスト削減に繋がりそうだから」
  • 具体的に何のためにどのような分析をしたいかは事前に考えておらず、導入後データを見て考える予定だった

これは断言できるのですが「まずは導入し、活用方法は後から考える」という考え方ではほぼ間違いなく失敗します。そうではなく「データ分析から得たいアウトプットを先に定義する→実現可能なことを確認してから導入を決める」という順序が重要です。

この点をA社に伺ったところ「導入後に社内で議論したところ「計画通りの船会社のアロケーションで積まれているかを管理したい」という重要なユースケースが浮かんできました。しかし導入したシステムにはこのユースケースをカバーする機能がなかったため解約しました」とのことでした。

この事例からの学びは、先に実現したい理想形を描くべきということです。(この点に関しては、第4回のコラムで詳しく触れていますのでそちらをご参照ください。)
少なくとも「●●を分析をして、その結果〇〇を実現/XX%改善したい」というイメージを社内で整理したうえで、それを実現できるソリューション(システム等)を探しましょう。

A社の事例では活用できるデータの有無に関しては大きな問題になりませんでしたが、第1回でも触れた通りDXの究極の目的はデータ活用と言っても過言ではなく、分析に使えるデータの有無はDXにおいて重要です。「分析しようとしたら必要なデータがなかった」「データはあるが相当時間をかけて前処理しなければそのまま分析には使えない」といったケースは非常に多いです。したがって上記に加えて「●●を分析をして、その結果〇〇を実現/XX%改善したい。そのためには□□のデータが必要」とデータについてまで考えられているとより失敗を減らせます。

学び2.細かすぎると思うくらい確認・検証する

B社はブッキングシステムを導入したものの、思った成果が出ずに継続利用すべきか悩んでしまっています。B社は「どの船社でも対応可能」という説明を受けて(ブッキングシステムでは他の選択肢が多くなかったこともあり)導入を決めました。これ自体はそれほど間違っていないような気もしますが、システムが関係してくると「○○でないと使えない」「●●の場合は××になる」等前提条件や例外が出てくるケースは非常に多いです。

そのため導入前に「細かすぎるのでは?」と感じるくらい丁寧に確認しておくことがおすすめです。B社のケースでは、ソリューション選定の過程で例えば以下を確認しておくことで失敗する確率をより低減させることができたでしょう。

  • 「どの船社でも」とは具体的にどの船社ですか?
  • 「対応可能」に条件や例外はありますか?
  • 「対応可能」とは、具体的にはどのような流れでどれくらいの期間で利用可能になるのですか?

また、B社のケースでは「結局メールでブッキングしている」という事象が生じてしまっていますが、このあたりも可能であれば事前に実際のデータで検証してみる等しておいた方が安全です。実際の輸送において主要パターンのブッキングをトライアルで実施してみることで、「この船社は弊社の従来の方法のままではシステムでブッキングできない」等の制約が浮かび上がってきます。実際のデータでの検証が難しくても、サンプルのデータを提供して確認する程度は最低限やっておくのがおすすめです。

学び3.導入後も定期的にモニタリングする

C社は動静可視化システムを導入したものの、思った効果が得られていないことが後から発覚してしまいました。これもよくある話で、DX関連のプロジェクトはシステム導入直後から何の問題もなく効果が出るケースばかりではありません。

当然問題が生じていることがわかっても「改善できる部分」と「改善できない部分」があり、後者は一度導入してしまうとどうしようもないので導入前にしっかり確認しておくしかありません。C社のケースでも可視化できない貨物がある点や予測精度の低さに関しては改善が難しい部分もあるため、これは上記2つ目の学びとして挙げているように、導入前にしっかり確認・検証しておくべき点です。

一方で、改善できる部分もありましたし、C社の場合は導入後1年以上経って問題が発覚していますが、早期に検知できていればより早く手を打てていたわけです。

この点については、導入したら終わりではなく「元々期待した可視化ができているのか」「可視化は効果に繋がっているのか」「(効果が出ていないなら)今後効果が出る見通しは立っているのか」等、少なくとも導入後運用が軌道に乗るまでをプロジェクトのスコープとしておく、もしくは最低限モニタリングしておく等の対応をとることで防止することができたでしょう。

IT企業側もこのあたりまでサポートしてくれる企業は多いので、導入検討の段階で、導入後のサポート等についても確認しておいた方がよいですし、社内のリソースも必要になりますので、導入後のモニタリング等の運用やその体制についても事前に議論しておきましょう。

おわりに

今回は国際物流DXの失敗事例にフォーカスし、3つのよくある失敗とそこから得られる学びについて見ていきました。

失敗事例を見ると「やりたくなくなった…」という方もいらっしゃるかもしれませんが、安心してください。国際物流に限らず、DXの成功事例として挙げられている企業はむしろ他社よりもたくさんの失敗を積み重ねてきた企業なのです。失敗せずに大成功を収めている企業はいないと言っても過言ではありません。今回は失敗事例からの学びを3つ挙げましたが、最も大きな失敗は「何も動かないこと」であり、「失敗を責める文化」です。

当然「少し考えれば避けられた失敗」や「同じ失敗を繰り返すこと」は避けたいですが、基本的にDXは仮説検証の繰り返しであり、失敗したということは何かを検証して学んだということです。避けられる失敗を避けるという意味で今回の内容が何かのお役に立つと嬉しいですが、過度に失敗を恐れず、是非DXにチャレンジしていきましょう。

本連載の最終回である次回は、過去5回の内容をまとめつつ、自社に合う国際物流DXの進め方について触れたいと思います。

一覧へ戻る