Faurecia社の”たられば”ライフサイクル収益企画 – 工場も品番もまだ決まってないけど市場は待っている


Faurecia社は日本では一般にフォルシアと表記されるフランスの自動車部品メーカーです。売上高は17,525 百万€(2兆2千億円), 営業利益率 7.3% (1,274 百万€ (1,600億円))で、11万人の従業員、37か国320カ所の拠点,、35の研究開発施設を構える自動車シート・内装品のトップメーカーのひとつです。実際の事業構成は、シート43% (FAS)、内装品31% (FIS)、クリーンモビリティ(排気系とEV/FCV部品) 26% (FCM)であり、日本のOEM向け規模は大きくなく、VW、FORD、PSA向けで約半分を占めています。ここ数年の主要戦略は1)スマート・ライフ・オンボード(具体的製品ではcockpit of the future)、2)サスティナブル・モビリティ(燃料電池関連や軽量化)の二つです。CASEと直截的に言うのではなく、さりげなくそのコア技術を担うリーダー的サプライヤを目指す、と言っているようです。最近の日本ではクラリオン買収で話題になりました。ちなみに筆者の元同僚(フランス人、Faurecia社出身)は「フォーレシア」と発音していました。日本のマスコミでは、フォルシア、フォーレシアが混在しているようですが、筆者はFaurecia社と記述しながら内心では「フォーレシア」と発音しています。閑話休題。

FAS : Faurecia Automotive Seating

FIS : Faurecia Interior Systems

FCM : Faurecia Clean Mobility

SAP HANA カラム型データベースを最初に見たときの想像 「モヤっと」も「カチッと」も

筆者が2010年代初め、自動車シート・内装部品メーカーの欧州生産管理部に籍を置いていた(つまりFaurecia社のライヴァル企業です)ころ、SAP HANAのカラム型データベースを見て最初に想像したのは、1) 製品企画や生産準備、原価企画のような「品番や工場・ラインコード未確定」期間に、モヤっとした情報(つまり品番がない、機能名だけある)とカチッとしたデータ(品番もラインコードもマスタに登録されている)の混在を同時に扱えるのでは‥??、ということと、2) 部品展開に適したデータベース設計ができるかも‥?? – 階層型DB、IMS™はまさに部品展開のためのデータベース構造でしたが、RDBはそうではありませんでした – ということの2点でした。

そのときSAPソリューションを号口生産向けに導入中で、「カチッとしたデータ」でマスタを構築中であったのですが、その前の生産準備期間ではあらゆるデータはEXCELで扱っていました。扱うしかなかったのです。一方で、何かしらのブレークスルーがきっとあるはずだと思っていました。EXCELはそのときどきで自由に行も列も変えられるし、キーに相当するものを予めカチッと決めないでも仕事に取り掛かれます。モヤっとした状態で、なおかつ、観点や切り口が多種多様・その時々の必要に応じて変幻自在なフェーズに合うことは合うのですが、いかんせん、どんなに工夫しても1ファクトで共有するのは難しい。。。SAP HANAのカラム型を見たときそれを解決できるのではないか、ただの直感ですが、そう想像できたのです。

もう一つの直感は、部品表がRDB化されて以来ずっと付きまとっていた違和感を突き破れるのでないかというものでした。もともと親和性の高かった部品表と階層型データベースの関係がRDBによって引き離されてきた歴史から、何らか違うカタチで一歩抜け出せるのではないかという想像です。RDBで部品展開、MRP実行にはずっと困難がついて回っていましたから。

IMS™はIBM Corporation(米国)の商標, Information Management System. ここでいうIMSは階層型のデータベース管理システム(DBMS)であるIMS DB(IMS Database Manager).

欧州の部品メーカーも同じようなことを考えていた

そのころ、Faurecia社がSAPソリューションをベースにシステム刷新をグローバル展開するという話は伝わってきていました。このビデオは2014年のもので、Faurecia社のCIOにSAP HANAのテクノロジー活用を聞く、という構成になっています。7分近い長い動画です。

この中でのメイントピックスはふたつ、1) 量産前フェーズにおける製品ライフサイクル収益企画と 2) 部品表・部品所要量高速展開です。
部品メーカーがずっと取り組んできた課題なので当然といえば当然ではありますが、まったく世の中には同じようなことを考える人たちがいるものです。そしてまた、そこにテクノロジーが成熟してきて、実現が可能になる、さらにニーズとシーズがジャストミートするタイミングがある、筆者の前職時代ではまだ想像の域だったものを、実現化させていた会社があったということです。

ライフサイクル収益企画にSAP HANAを活用するとは

筆者は新規OEM向けの新ビジネス立上げに携わったことで、確信に至った考えがあります。量産開始後の日常オペレーションにはもはや新たな付加価値はない、昔は量産後も改善を続けることで付加価値を増加させることが可能であったが、今は量産開始時点で大半の勝負はついている、従って、事業企画や先行技術開発から案件獲得(あるいは見送り)、製品化、生産/調達/物流デザインといった量産前の一連の段階を通じてライフサイクル全体の収益性を評価し、収益確保の施策を実施することをスマートかつインテリジェントに進めていくことで付加価値をつけるべきであると。

自動車部品メーカーの、とくに内装系のメーカーの利益率は元来高くはありません。2014年のインタビューでは5% と述べられています。同業他社からも「内装の組付(Tier1の役割)だけに限ればほぼ全社全プロジェクト赤字、組付以外の部品加工(Tier2以下の役割)で利益確保するのが常識、欧・米・日どこも同じ」と聞いたことがあります。2兆円企業で320か所も拠点があるというのは、そもそも苦しいことなのです。

とすれば、OEMから次のクルマの部品を受注するにあたり、コンセプト図が提示される前から収益性を評価する必要があります。それも1つのモデル・シリーズ、モデル内の製品ミックス、1つの地域のクルマだけでなく、次のモデルとの兼ね合い、他社の他モデルに流用できる要素技術、他社の他モデル向けとの混流生産も収益性評価の要素になります。受注できた後も目標原価達成への作りこみ(原価企画)をはじめ、プロジェクト管理、品質プロセス管理、設計変更管理、生産準備進行等が複雑に影響し合うプロセスを統制し続けなくてはなりません。そしてこれらの多元要素管理は、多岐部門と多階層組織のプレーヤーによる情報共有によってなされるもので、トップダウンの経営情報伝達プロセスとは異なる性質のものです。

最初に提起したのは、モヤっとした情報です。上述の多元要素と多元フェーズと多元組織は、全部モヤっとした情報と既存のカチッとしたデータの混在を、いついかなるときも多くのプレーヤーがつつき合い共有し合い、かつ、時が進んで情報もデータも変移していくことを示しています。

データベース技術的に断じるのはなかなか難しいのですが、演繹的手法と帰納的手法は決して対立するものではなく、ビジネスの現場では、1) 演繹と帰納は都合のよいところで恣意的に行ったり来たりする、2) 決定的な判断のキーは微細なデータの分析から取り出される(ときもある)、という経験によれば、それをEXCEL以外で実現する方法は、BIというより、幅広な可能性を内蔵したSAP HANAカラム型データベース技術そのものではないのかというのが、筆者の経験的感想です。そして、インタビューではもちろんそんなことまで開示はしていませんが、Faurecia社がSAP HANAを使って新たなライフサイクル収益企画チャレンジに取り組んだのはまさに同じことではないのか、と深読みできると思います。

その後、Faurecia社の取り組みは下図のように実を結んでいます。>> Faurecia社2018年IR資料

faurecia FY 2018 RESULTS_1

faurecia FY 2018 RESULTS_2

MRP – 高速部品表展開、部品所要量展開 – にSAP HANAを活用するとは

このインタビューのMRP, JIS/JITに関する部分を自動車シート生産実務経験者として、新解釈で翻訳してみました。Faurecia社のBertrand Eteneauさんはevery minuteと言っていてタクトタイムなんて言っていないし、JISではなくJITと言っているんですが、話の意図は1分タクトタイムでかつJIS(Just-In-Sequence)で生産・納入するということです。ご了承ください。

cockpit of the future

前述のとおり、データベースがRDB主流になって以来、部品表の展開処理は階層型DBと比べて親和性の低いRDB上でいかにパフォーマンス維持するかという取り組みだったと思います。Faurecia社のように自動車のシートを扱っていると、構成部品点数はシートセット当たり400点を超えるはずです(通常の2列シートで前席パワーアシスト)。1ラインで日量900台(タクトタイム1分)、シートの場合ロット生産は考えづらく1台流し、12週分で約1,000万構成部品展開の計算量、これに残り40週分の週単位もしくは月単位内示が加わり、さらに確定順序指示による補正をかけていくと、確かに計算量は膨大になります。ちなみに欧州で主流のモジュール内示オーダーでは200モジュール/台くらいなので実際には約半分です。

ここでいう「MRP」の解釈は、実際はいろいろとあります。古典的なMRPでは在庫引当を含む正味所要量計算、ロット編成、リードタイム・オフセッティング、レベル・バイ・レベル部品展開、アクティビティ登録、総所要量計算と手順が多いのは確かです。一方で、自動車産業における内示の部品所要量展開(これをMRPと称しているケースが多い)はアウトプットがロット編成ではなく日量数=タクトタイムの逆数=生産速度ですから、必ずしもERPの古典MRPアプリケーション構造に依拠しなくてもよく、データベースとSQLと関数の組み合わせで解くことも可能です。そのまた一方で、順序生産指示にもとづく構成部品の所要(到着時刻と投入時刻と消費時刻と数量)計算は計算対象期間が短い(2時間から72時間程度)とはいえ、最低限分単位(場合によっては秒単位)の精度と計算量が必要で、かつ、多頻度計算が要求されます。インタビューでは単にMRPのパフォーマンスとしか語られていないので、推測するしかありませんが、2番目と3番目の同時実行となるとかなり加重な計算量と想像できます。
このFaurecia社のインタビューでは、SAP HANAのテクノロジーの活用でMRP計算時間のブレークスルーが可能になったと語られています。SAP S/4HANAアプリケーションではなくSAP HANAテクノロジー、つまりデータベース・テクノロジーの文脈で語られていることが重要です。2014年7月のオートモーティブ・フォーラムではSAP HANAをERPに横付け(サイドバイサイド)することでアプリケーションコードの最適化を図ったという報告がされています。それは確かにそうだろうと思います。このときはMRP展開速度の高速化ではなく別の例が挙げられていますが、SAP HANAテクノロジーの活用アイデアとして正当です。さて、それではサイドバイサイド実装するとして、インメモリー・データベースだから速い、というテクノロジー説明に帰するものでしょうか。筆者は経験的に、そうではなくて、プッシュダウンの意味をどう解釈するかではないかと考えています。ここまで何度も挙げたように、部品構成展開計算とデータベース構造あるいはデータベース・マネジメントシステム(DBMS)との親和性の再構築ということが高速部品表展開の要です。ということは、SAP HANAのデータベース・テクノロジーを突き詰めて使い切る、SQLの使い方も関数の活用の仕方も部品構成展開に的を絞って工夫する意味でのプッシュダウンと解釈したらどうかと思うのです。その工夫に応えるだけのテクノロジーが埋め込まれているのがSAP HANAだということです。

参考として、トヨタ自動車がSAP S/4HANA®と SAP HANA®を採用したニュースを挙げておきます。SAP S/4HANAだけでなくSAP HANAと併記しているところがポイントです。

トヨタ自動車、全社共通の経理情報基盤に、SAP S/4HANA®およびSAP HANA®を導入

トヨタ、全社共通の経理基盤 SAPの最新ERPで構築(日経新聞記事)

終わりに

(SAP S/4HANAやR/3に限らず)ERPは実績の収集と分析を強調するだけでなく、企画や予算の用に供するべき、とずっと考えてきました。ただ一方で、ERPは量産段階の実績を扱うのは得意だけれども、モヤっとした情報とマスタの前段階を扱ってフェーズを進めていくのにはあまり向いていないということも感じていました。しかし、企業情報のすべてを取り扱うということは、もうすでに起きたことと、進行しつつある不完全な情報の両方を扱うことであるし、製造業にとっては量産後のオペレーションハンドリングよりも量産前の付加価値を作りこんでいく過程のほうが重要であると考えます。さすれば、オペレーショナル・アプリケーションの定着にも増して、データベースの活用、具体的にはデータベーステクノロジーを利用して自由で高度な業務の実現を企業情報システムの中で追求していく必要があります。
Faurecia社の事例は、SAP HANAテクノロジーに関するものなので、MRPパフォーマンスという即物的成果も含めて語られていますが、筆者としては、成果がはっきり見えず非常に難しい業務であるところの製品ライフサイクル収益企画に取り組むためにSAP HANAを用いてみたところに興味をそそられました。自動車部品メーカーは、常に、1) どんな仕様の部品を 2) どのOEMのどの車向けに 3) どこで作ってどのように運び 4) いくらで作っていくらで売るのか を企画し準備し実行するのかが生命線です。そのために必要な道具は、いくつかのアプリケーション群(PLM/PDM, PS, IBP, PLC, BPC, QM等)と先進的なデータベース・テクノロジー、なによりもその活用の仕方です。今回の記事をそういう文脈で読んでいただけたなら幸いです。

※本稿は公開情報に基づき筆者が構成したもので、フォルシア社(Faurecia S.A.)のレビューを受けたものではありません。