エンドレスハウザー社にみる、対競合差別化+顧客中心主義


製造業が競合他社に打ち勝つためには、何か差別化要因を生み出す必要があります。しかしながら、行き過ぎた差別化は結果的に利用側に別の苦労を生み出すことになりかねません。
本稿では、筆者が2007年から興味をもって観察し続けてきた計測器メーカー エンドレスハウザー社 (Endress+Hauser 以下 EH) を取り上げ、同社の苦心について共有したいと思います。

製品そのもので差別化できない場合

医薬品、化学、石油・ガス、ユーティリティ、製紙など、プロセス系プラントで用いられている計測器には、パイプを流れる液体量を測る流量計や、タンク内の液体水位を測るレベル計などのメーターがあります。流量計の代表として コリオリ式質量流量計 があります。質量流量とはある定点を単位時間中に通り抜ける流体の質量(単位の例:kg/s)を指します。

リンクした wikipedia を参照すると、質量流量の測定原理が掲載されています。詳細は理解できなくても(筆者も理解できていません!)流体物理学という原理に基づいて構成されたものが コリオリ式質量流量計 だということがわかります。どのメーカーであっても、この原理に基づけば、同じ機能の製品を作ることができる、言葉を返すと、同じ原理に基づいて製品開発を行っている以上、製品そのもので差別化を図ることが極めて難しい、ということになります。

一般的に、製品の差別化要因はQCD (品質の高さ、コストの安さ、デリバリーの正確さ) だと言われます。しかしながら、原理が共有化されていてシンプルな計測器の場合、QCDはほぼ同じになってしまうのです。以下、各社のコリオリ式製品の写真を掲載します。計測器を挟み込むパイプ断面距離も標準化されている結果、どれもほぼ同じ形にならざるを得ないこと、差別化要素はメーカーを示すカラーリング程度、ということが見て取れます。

EHの流量計

EHの流量計

Emersonの流量計

Emersonの流量計

YOKOGAWAの流量計

YOKOGAWAの流量計

他にも、Applicator というEH独自アプリケーションをリリースしていました。ベースとなる製品選択を容易にし、かつ、オプション品を構成することで長桁品番を自動生成させることができます。この機能を使うことで、ユーザは自分の必要な製品構成を理解したうえで、直接見積りプロセスをキックすることができます。このアプリケーションは12年の間にさらに洗練されたUIに変わり現役です。

製品で差別化できないのであれば、製品情報で差別化しよう

産業機械製造業の変化によって、2006年頃EHが直面していた悩みは次のようなものでした。

  • 製品がコモディタイズ化した結果、
  • 知的財産と著作権が他社に容易に盗用される。
  • それにより、業界内での顧客ローヤルティが低下する。

QCDでの差別化が難しい中、競合に打ち勝ちマーケットシェアを拡大させる必要に迫られ、アフターマーケットでのサービスの機会を逃さないために必要とされる戦略は次のようなものでした。

  • 顧客ローヤルティを向上させるにはどうしたらよいか。
  • それに加えて、新しい収入獲得経路も確立しなければならない。
  • そのためには、革新的なソリューションを提供する必要がある。

EHは、その「革新的なソリューション」として、製品情報の提供の仕組みを選びました。

プラントを構成する機器 (以下、アセット) は、アセット本体に関するさまざまな付加情報を必要とします。例えば、

  • ユーザマニュアル
  • 技術情報
  • 安全基準文書
  • プロダクトの状況
  • 仕入先の都合、イベント
  • 測定データ
  • 各種認定書
  • …その他、
  • 各ソフトウェアのバージョン
  • スペアパーツの情報
  • 図面類

等々。

製品情報DB W@M

EHではこれらの情報を一元に集約することにしました。アセットに紐づく構造化されたマスタデータを、従業員のみならず、顧客、ディストリビュータ、フィールドサービス、部品ベンダーなど仕入れ先、などあらゆるステークホルダーで共有しようというものです。その情報基盤として、W@Mという製品DBを作り、各ステークホルダ向けポータル機能を開発、リリースしました。SAPが提供を開始したSOA基盤の SAP NetWeaver に含まれる SAP Enterprise Portal が最大活用されていました。

EH portal

ECCのバリコンを利用して、SAP NetWeaver に含まれる SAP Enterprise Portal 上にUIを作りこんだのです。マウスオーバーすると、そのシリアル番号が振られたアセットの定格や製品デリバリーの状態などが一目でわかりました。

シリアル番号から製品情報を牽く

SAP NetWeaver の Enterprise Portalを利用したUI。シリアル番号から製品情報を牽くことができる

スペアパーツ情報も図面付きで表示できる

スペアパーツ情報など、製品関連情報も図面付きで表示できる

 W@Mを核にアフターメンテナンスプロセスを標準化する

シリアル番号さえわかれば、出荷時製品構成、設置情報、必要なスペアパーツ情報を芋づる式に入手できます。EHの従業員だけでなく、顧客であるプラントオペレータもそれが可能である、というところがこの仕組みのミソでした。

EHはW@Mを核に、アフタメンテナンスのB2Bプロセスを標準化させることで、より早く、正確なメンテナンスサービスを提供することができるようになりました。

顧客側のオペレータが機器検査を行い、メンテナンスの必要があると判断した場合には、EHにその旨を依頼します。interactive formsという「穴あきPDF」をUIに用いていました。そこに記載されたデータは、そのままEHのアフタメンテナンスシステムに取り込まれ、メンテナンスプロセス開始のトリガとなりました。EH側は、W@Mをフル活用して、必要なスペアパーツを客先プラントのどこに持参すればよいかを判断します。と同時に、修理作業可能なエンジニアをアサイン。またアセットのメンテナンス契約内容に基づき、今回の作業の有償・無償を判断し、会計側のプロセスもキックします。これらのプロセスを標準化させ、素早く効率よく行うことで、他社との差別化を図ろうと考えたわけです。

先にも記載した通り、同じ仕様の製品は競合も提供可能です。既存の客先アセットに異常が発生した場合に、如何に他社に気づかれぬよう、素早く修理・交換するか、が戦略を具現化する決め手であったわけです。これらが2007年のSAP SAPPHIREにてEHが発表した内容でした。

それでも製品そのもので差別化したい

2009年。EHは別の事例を公表しました。液体タンクのレベル計にソフトウェアを組み込み、原液の発注点管理を自動化させたのです。

SupplyCare SAP Integration

SupplyCare® SAP Integration

欧州化学メーカーは社内基幹システムとしてSAP R/3 または SAP ERP を採用しているところが大半でした。原液管理は、タンクの残量があらかじめ定められた発注点を下回っていたら、オペレータが発注依頼を作成し、調達部門が発注伝票を起こしてサプライヤに送信します。EHは、発注点を下回ったことを検知したら構内LANを介してSAP ERPのMMに発注依頼伝票を送り込む機能をソフトウェアとしてレベル計に組み込むことにしました。そのソフトウェアはの名称は SupplyCare SAP Integration。SAPから complementary software (補完ソフトウェア) の認証を取得。レベル計がタンクの状態を見える化し、さらに社内調達プロセスのトリガを引くことまでするようにしたわけです。

SupplyCare Enterpriseの機能群

SupplyCare Enterpriseの機能群

2019年の現在ならばIoTの利用ケースとして、よく耳にするシナリオですが、10年前にそれを実現・市販していたことには驚かされます。

メーカー側が独自性を追求するとオペレータ側が困惑する

ここまでアセットメーカーとしてのEHの意欲的な取り組みを見てきました。

しかし結果的に、顧客側オペレータの机上端末はこんな具合になりました。

オペレータの机上端末

オペレータの机上端末の実態

複数のメーカーから独自に発行されたIDとパスワードが付箋として貼り付けられています。

なぜこのような状態になってしまったのでしょうか。

差別化しにくい製品でも、なんとか競合に対して優位な戦いを展開したい。そのために、アセットの情報を一元集約し、自社メンテナンスプロセスを標準化し、さらにはソフトウェアで新しい差別化要因を創り出したい。いずれもメーカー目線で考えてきた結果です。しかしながらEHだけがこういった取り組みをしていたわけではありません。他社も競って差別化要因を求め、実装していくことで、結果的に顧客であるオペレータにメーカー都合による複雑さを押し付けることになってしまったわけです。

EHは再び考えました。

我々の製品に関する情報戦略は『我々が機器について知っていることは、すべて顧客も知っていてほしい』だ。だからW@Mを作り、機器情報を全部開示した。メンテナンスに関するB2Bプロセスも定義・実装した。しかしながら、顧客のオペレータはEHだけでなく、必然的に複数のアセットメーカーと付き合っていかなければいけない。我々は今こそ、メーカー視点ではなく顧客視点に立たなければいけない。そして顧客が本当に必要としているニーズを感じ取ろう

顧客企業、メーカー企業共同でデザインシンキングワークショップを実施し、本当の課題を洗い出しました。

顧客とメーカーが繋がる、というのは正しい方向性だ。繋がるべきステークホルダーとして、フィールドサービスやスペアパーツのサプライヤを加えてもよい。問題は多種多様な機器情報を構造化して共有マスタにできるか、そして、企業間プロセスをメーカー間で標準化できるか、だ。

それらが実現できれば、メーカー 対 顧客側オペレータ が m:n という複雑なつながりであっても、企業間の仕事を標準化されたB2Bプロセスに流すことができます。

AINのアーキテクチャ

AINのアーキテクチャ

そのための基盤としてSAPに開発が託されたのが Asset Intelligence Network (AIN)です。W@Mでカバーされていたアセットマスタと関連情報が、汎用化されてSaaSに実装されました。顧客オペレータ側からは、アセットの稼働データがIoTで上がるしくみになっています。それらを活用して、企業間協働を標準化することに成功しました。

今後への期待

今、欧州を皮切りに、AINを基盤としたB2Bプロセスの標準化ロールアウトが始まっています。複数の先行顧客がAINをプレミアム契約し、保有するプラントを構成するアセットのメーカーを招いて、AIN上にマスタデータを整備しつあります。

また2019年9月下旬、マドリッドにて International SAP Conference on Intelligent Asset Management という国際会議が開催されました。そのアジェンダを見る限り、誰もがこの新しい取り組みの価値や効果を納得している、とはまだ言い切れないと思います。現実世界に近いシナリオを新しい基盤で再デザインすることで、その価値の理解を深めようという段階であると考えられます。

近い将来、アセットマスタに紐づく稼働データを活用して、アセットのリモート監視、メーカーを越えて標準化された補修プロセスと予知保全、といった高度な運用が、顧客側、メーカー側、フィールドサービス側などのステークホルダー協働によって実現されることを期待したいと思います。

——-

※本稿は公開情報、および若干の弊社内情報をもとに筆者が構成したものであり、Endress+Hauser社のレビューを受けたものではありません。