IoTそれ自体は目的ではない　 ー SAPジャパン 村田氏 インタビュー（2/2）

SAPジャパン株式会社 インダストリークラウド事業本部 IoT/IR4 (Internet of Things/Fourth Industrial Revolution) ディレクター村田氏へのインタビュー後編。

・前編：IoTそれ自体は目的ではない　 ー SAPジャパン 村田氏 インタビュー（1/2）

コンプレッサーのビジネスモデル転換の事例

 
ー SAPが関係しているIoT事例をご紹介いただけますか。

村田：　まずはよく言われる「モノからサービスへ」の典型例として、ケーザー・コンプレッサー社が「コンプレッサーを売らずに圧縮空気を売る」という新しいビジネスモデルに進出した事例です。客先の工場にコンプレッサーを持っては行くのですが、電力会社との契約も、運転も保守もケーザー社が行いますので、お客さんは基本的に何もする必要がありません、そのかわり実際に圧縮空気を使った分だけお金を払ってください、という売り方を始めました。

上の図で整理をしたのですが、縦軸の左側が従来の「競争軸」です。要はコンプレッサーを作っていて、製品の品質軸で競合他社と戦っていました。それに横軸、つまりIoTとIoPという新しい技術を組み合わせることによって、合わせ技で左上から右上にシフトしたのです。

もともと、お客様企業が本当にほしかったのは「圧縮空気が安定供給されること」という状態であって、コンプレッサーという箱がほしかったわけではない。それなら「箱」を売るかわりに「箱が果たす機能」だけをサービスとして売ろう、というわけです。

ーSAPのIoTモジュールと言っている部分ですが、これはコンプレッサーの中になんらかのチップを埋めたり、モジュールを埋めたりするという感じなのですか？

村田：　広い意味ではそうです。実際にはコンプレッサー自身がある程度のセンサーというか、監視モジュールがもともと入っていました。ただ従来型のモノでは、操作盤が本体の横についていて、保守に行ったエンジニアがUSBメモリを刺せばデータが取れる、という状態だったのですが、まずはそれをリモートで取ってきて監視できるようにしたというのが第一段階です。

次に、多くの機器から上がってきたデータを処理することによって、例えばどの閾値がどこまで上がったらどの故障に繋がるのか、を分析します。そして最終的には予測保守、「プレディクティブ・メンテナンス」、つまり機器が壊れる前にそれを予測して先回りして修理してしまう、という状態を目指しています。

ーSAPの製品としてみた時には、やはりクラウドの部分が製品であって、センサーが情報を取得してSAPに渡すところまでは他社のシステムとなるということですね。

村田：　基本はそうです。現在は、HANAをクラウドにおいてHANA Cloud Platform (HCP)を使うのが一番よくある形です。HCPはHANAベースのPaasで、HANAの上に様々な機能がサービスとして提供されており、それらをパーツとして組み合わせることで早く確実にアプリケーションを作ることができます。

HCPの特徴は、HANAベースなので、処理がリアルタイムで速いことです。またSAP ERP等との接続モジュールが用意されているので、既存のSAPのお客様からすると使いやすいことです。

ーHANAは処理速度が速いということですが、MQTTブローカーの役割も果たすことができるのですか？

村田：　 MQTTや、RCPでつなぐケースもあります。 一方でHCPをほぼそのまま使ったのが、シーメンスの事例です。シーメンスが「Cloud for Industry」という名前で出しているサービスの一部に、HCPを使っていただいています。

ーこんなことができるようになってきているのですね。

村田： シーメンスとSAP、お互いに一番筋のいい、非常に良い使い方をしている事例だと思います。

ハンブルグ港湾局の事例

村田：　ハンブルグ港の事例もご紹介します。ハンブルグ港はドイツ最大の貿易港ですが、海に面していません。エルベ川を河口から100kmくらい遡った内陸部にあるので、物理的にはもう拡張の余地がありません。ところが取扱い貨物の量は増え続けており、向う10～15年でさらに2倍以上になると予想されています。つまり、物理的には拡張できないが、スループットを2倍以上に増やさなくてはならない、という状況に追い込まれているのです。

そこでハンブルグ港湾局は、IoTを使った施策に着手しました。一言でいうと、製造業でいう「ジャストインタイム」です。

コンテナ船の場合、結局、船がタクトを握っているんです。船が接岸するまでは何も下ろせませんし、上げることもできません。したがって船が接岸するタイミングに合わせて、その船に関連するトラックだけをヤードに入れる、逆にいうと船が来るまではコンテナも来させないようにする、という運用を目指しているのです。

世界中どこでも、トラックの運転手さんは、できる限り早く到着しようとするものです。早く着いて怒られることはないですが、遅れるとペナルティ取られますから。しかしハンブルグ港では、早く来るとコンテナヤードが一杯になってしまう。そこで、ジャストインタイムで、船が来るのに合わせてそれに関係するトラックだけを港内に入れる、という方式を目指したのです。

https://www.youtube.com/watch?v=62rm94mAGog

実際にはまだまだ発展途上です。去年2月にトラック2,000台で運用を始めましたが、実際は１日33,000台くらい来るそうなのです。

ーそんなに来るんですか。

村田：　だから10年がかりで取り組んでいるということです。

ートラック側にもセンサーっていうか、やり取りするものが無いといけないですよね。でも、いくらセンサーでトラックの位置が特定できても、他にもクルマはあるのだから、自然渋滞は回避できないですよね、港湾局は。

村田：　そうなんですが、港が都市の真ん中にあるので、港に来るトラックが渋滞をひき起こすのです。

幸いにも船は、100km下流から来るので、あと何時間後に港に着くかが、大体読めるのです。そこで、もし船が遅れたら、トラックの順番も入れ替えてやればよい。そして、最終的には全自動化するのが目標です。

ー船側が「どこのトラックの、◯◯さんという運転手が持っている荷物」という情報をきちんと持っていないと、この指示は出せないですよね。船側の情報を集めるのも凄く大変な気がします。

村田：　そのとおりです。船会社も何百もありますが、全社を参加させないと、最終的には上手くいかないでしょうね。簡単ではないですけど、ハンブルグ港にとっては他に選択肢がないのでやらざるをえない。

港湾局は、船、鉄道、跳ね橋、道路、駐車場、など全部見ていますし、実際の港湾での上げ下ろしをやっている港湾業者はどの船とどのトラックのどの荷物が紐付いているかというデータは持っているので、それらを全体の最適化のために共有してやっていくってことになります。

ーなるほど、本日はありがとうございました。

【関連リンク】
・SAPジャパン

編集部

IoTに関する様々な情報を取材し、皆様にお届けいたします。