ボッシュ社(Bosch) – SAPソリューションを核にしたテンプレート


Bosch Corporationは世界最大の自動車部品メーカーです(2017年時点)。売上高は約10兆円(781億ユーロ)、うち自動車事業は60%強の5兆9千億円です。ちなみに自動車部品のトップ5はBosch, Denso (4兆9千億), Magna(4兆2千3百億), ZF(+TRW)(4兆1千7百億), Continental(3兆9千億)です。ここ数年、自動車部品メーカーの合従連衡、買収が進展し、順位の入れ替わりが激しくなっています。
Bosch社の従業員数は40万人超、世界拠点は50か国超、260拠点以上に上ります。

Bosch_autobahn8

今回はBosch社がSAP S/4HANAをベースにグローバルテンプレート展開を進める手法について少しばかり研究してみたいと思います。ベースにした資料はRBEI (Robert Bosch Engineering and Business Solutions)から公表されたものです。

 

SAPという思想もしくは道具

Bosch社事例に入る前に、そもそもSAP S/4HANAをベースにするということを少し考えてみたいと思います。
筆者は前職の部品メーカーで生産管理部に所属し、欧州工場のSAPソリューション導入プロジェクトマネージャーを務めていたので、その間、SAPを自社にとって「何者?」と認識するか、考えに考え続けていたのです。(何者?なんて認識論を考えるほうがヘンと言えばヘンですが、まずは、対象を認識し定義するところから始めるのは、若いころから叩き込まれた「思考様式」なのです)
SAPソリューションを使うことは既定路線だったのです。欧州OEMとの取引において、何も知らずに飛び込むのですから、自前のしくみ(システム)、それも日本のOEMに特化したガチガチのしくみベースで内示を受け、順序指示を受け出荷し、請求照合を行うのはムリがある、それも半年でカタチにしないといけない、そう考えるとSAPしかなかったのです。
SAPしかない、他の選択肢がない、ということは本来、あまり深く考えないということです。考えに考え尽くす行動様式からすれば、ヘンなのですが、顧客は欧州のOEMで、実行するのは欧州の地なのですから、ここは単純に郷に入りては郷に従え、と言うことになるわけです。

さて、現地のコンサルタントから渡されたのは、「ビジネス・プロセス・マトリクス」というSAPソリューションのプロセスと機能をベースにした業務定義事前準備一覧表です。これにO X (要否)をつけていくのです(もちろん、全部単純に割り切れないので、C=by Condition とかマイルールで一部を保留にするのですが)。
この過程で疑問がいろいろと湧いてきます。VMI (Vendor Managed Inventory)という考え方があり機能があります。日本語で言えば(水道の)コック方式です。自社内に仕入先所有の在庫を置かせて好きなときに好きなだけ使う(出庫した分だけ後で精算)方式です。一見便利だけれど絶対やってはいけない方式だと叩き込まれてきました。サプライチェーンの原則はタクトタイム=生産速度統制です。だから内示を渡してタクトタイムを示す、仕入先はそれを見て生産速度能力を準備し、同期のとれたサプライチェーンを維持しようと努める、この原則に真っ向対立する考えとしくみがVMIなのですから、「思想的に誤っている」わけです。思想的に誤っているものを織り込んでいるしくみは誤っていると言わざるを得ません。
ここで、現地コンサルタントと徹底した話し合いになるのですが、彼曰く「SAPシステムは道具である。道具に思想を見つけようとして『誤っているとか誤ってないとか』、そういう議論をすること自体がナンセンスだ」と。「思想を持つのは、生産管理屋の仕事であり、PMの仕事である、SAPシステムは道具として生産管理やPMから取捨選択を受ければいいだけの対象である」と。よって、「VMIがふさわしくなければ採用しなければいい」と。

SAPシステム=道具論(そして業務プロセスを決めるのは自分)に依って立つ、よい道具を有効に、自分の考えに従って使う(しかし、顧客であるOEMの意向には従う)、と割り切ったのでした(これもまた、郷に入りては郷に従う、です) 。ちなみにこのコンサルタントはMagna Interior欧州の生産管理Director経験者でした。そういうものなのだな・・と。

Why SAPとHow SAP

日本の自動車業界でのSAPソリューション普及率は極めて低いまま25年近くが経過しました。最近ではトヨタ自動車がSAPシステムを経理に採用とプレス発表(2018年7月23日)されましたが、経理分野以外はなかなか採用が進みません。
Why SAPという訴求が足らないのでは?という見方もあります。しかし、一方で、それはWhyという命題の置き方自体がずれているのでは?という見方もあります。
先述した筆者の欧州経験では、思想を追求することがナンセンスと明確に割り切りました。それよりも、どうやって、短期間で上手に使いこなし、顧客OEMからお墨付きをもらうか、が重要であると認識しました。今でもSAPシステムは欧州工場で恙なく稼働しています。導入した後も淡々と維持できるか、これもまた重要であるということです。さすれば、

なぜSAP?という問いを発することも、答えることもナンセンスである

では、どのように考えるかです。
ここにBosch and SAPのビデオがあります。この中では、なぜSAP?とは語っていません。どうやってうまくできたかという事例。筆者は、「うまくできたという事例があるという事実が、SAPでやればうまくやれるだろうという推定になる。」と理解することにしました。SAPじゃなかったらできなかった、という証明はない、それは分からない、そういう突き詰め方はあまり得策ではない、ということです。
では、例えば、Bosch社のグローバルテンプレート展開において、「うまくできた(厳密には、できつつある、ですが)」という事例では、「こういうふうにやった」という証明書がある、「こういうアプローチでした(あるいはアプローチをしている)」というものがあります。それを以下に、筆者の解釈として述べることにします。
つまりは、Why解釈ではなく、How解釈として、です。

Howの解釈

ひとつは、会社というものをいったんバラして、つまり、今こういう部門があって、こういう仕事があってということをいったん解体して、会社というものを再定義する方法です。
言い換えれば、どんな業務のしくみがあるか、分類・構造化して再定義する方法です。これが、全体のフレームを決めることになります。

各極(リージョン)に対して各事業(部門)の垂直のしくみで動く業務
人事のような各極通しのサービスのしくみで動く業務
世界各事業を合算するようなしくみで動く業務
需給計画や販売のように世界中で統合されたしくみで動く業務

このように俯瞰的に再構成が行われています。
(「ひとつは」と書いたのは、このアプローチが最初に採られたかどうかは分からないからです。俯瞰的にバラして俯瞰的に再構成、ということがそれ自体単独でできるのか、以下に記すような、ディテール側からのアプローチとの合わせ技ではないか?とも解釈できるからです。)

会社の仕事をサービスレベルにバラして、抽象化したサービスの固まりとして再定義する手法はSOA(Service Oriented Architecture)的なアプローチと解釈できます。
プロセス・チェーン・マップという手法が採られています。
業務をプロセス・チェーンで描き下したとき、以下の7つに定義づけられるという仮説です。
即ち、

  1. I2C : Inquire to Contract (OEMからの受注獲得プロセス)
  2. S2C : Samples to Customer (OEMへサンプル品(試作品も)を送って評価してもらうプロセス)
  3. O2C : Order to Cash (通常の内示・需給から在庫・納入を経て支払を受けるプロセス)
  4. P2S : Produce to Stock (生産計画から生産実行および品質管理プロセス)
  5. P2P : Purchase to Pay (生産調達/物品購買から支払のプロセス)
  6. D2P : Design to Product (設計から量産へのプロセス)
  7. I2I : Idea to Innovation (アイデアをイノベーションに昇華させるプロセス)

 

これは非常によくできています。まずはプロセスを抽象化してモデル化するということです。
さらにConnected Processという概念を採用しています。まさに、仕事を「サービス」として再定義することです。例えば Customer Order はサンプル品のときも試作のときも量産のときも補給のときも「顧客注文」ハンドリング業務という「サービス」と定義づけられるのです。さらに、Planning (計画、品番・日付・量・場所を定義して扱うサービスです)、Warehousing (倉庫、在庫扱い)、Shipping (出荷)、Invoicing (請求)、Quality Management (品質実績管理、検査。出荷製品も入庫材料もです)、Accounting (会計仕訳、転記)。これらは別々の業務プロセスチェーンの間で共通に現れるサービスです。サービスとしての再定義がこのように行われたことが分かります。

ここまで、SAPシステムの業務プロセスも機能も出てきませんが、実はSAPシステム(R/3であってもSAP S/4HANAであっても)も業務を分類・構造化して機能に振り分けて表象させているので、SAP製品の知識があれば、暗黙的に分類・構造を援用していると解釈できます。既にして、SAPソリューションを「どう使うか」実践していることになります。

ここから、部品メーカーとしての仕事を構造化して、道具としてのSAPシステムを当てはめることになります。フレームマトリクスは多分にSAPシステムの切り分け方になっています。機能の内容を明示的に当てはめるにはフレームもまたSAP的であることが必要だからです。しかしながら、あくまでも「業務フレーム」なので、SAPシステムは当てはめるべき道具です。
SAP S/4HANAが主な道具として当てはめられるのは、

  1. Marketing, Sales & Service
  2. 財務会計
  3. 資産管理
  4. 生産
  5. サプライチェーン(倉庫含む)
  6. 調達
  7. R&D (ただしプロジェクト管理や文書管理)

筆者は業務フレームと言っていますが、これを「バリューチェーン」と言います。ほぼ全てにおいてSAP S/4HANAが網羅的に持つ機能群を当てはめることができます。どのように使うか、そのものと言えます。別の言い方をすれば、「このように使える(それもほぼ全てに)」ということです。

かたやバリューチェーンではなく、システム視点横断的基礎ツール(道具)を考えると、GRC (Governance, Risk & Compliance), DMS (Document Management System, Database Migration Service), SOLMAN, BASIS, UI5, Fiori, Analytics等が当然にして必要になってきますから、SAP当てはめという作業には欠かせません。
これで、業務・システム一体となって、SAPソリューションをどう使うか、明示できます。

実は、バリューチェーン定義では欠けているものがあります。ここは残念ながら、この手法の弱点です。足りないのは量産に至るまでの「構えの作り込み」の過程です。SAPの場合、マスタは「完成型」なので(もちろん更新は常にリアルタイムですが、それはいろいろ試行錯誤を重ねて「決まった」後の完成型をリアルタイムに反映・保持できるという意味なので)、決まっていない状態を「業務プロセス」や「マスタ」で写し取ることができないのです。上記のバリューチェーンの(a)から(f)は量産で動いているある製品の量産断面だけを写し取っています。現実には自動車部品メーカーでは、構想図だけの状態の製品や試作中のやり直し、量産品が同時に入り混じっています。一番簡単な理由は、自動車のモデルが常に五月雨的に立上り・打ち切られているからです。ここは悩ましいところで、筆者は「重層断面定義のシステムモデルジレンマ」と呼んでいます。上記のプロセス・チェーン・マップでは描き表せるのですが、バリューチェーンでは軸が足りない。今後の課題です。

かなり長くなりましたが、ここまでで会社の業務を抽象化して再定義、SAPソリューションを当てはめることをして、モデルとしての立案ができました。ここから、具体的にどの極のどの事業体にどんな導入アプローチをするか、を定義します。
対象の事業体の位置づけの定義は重要です。日本の部品メーカーでもそうですが、各極各事業体によって、製品も工法も顧客も異なるし、生産・販売ボリュームも異なる、さらに管理レベル(ほとんど人材とその習熟、あるいは産業集積の成熟度に左右されると思いますが)の違い、現行システムの違いがあります。
何分類に分けてもいいのですが、ここではSAPグローバルテンプレート適用を念頭にしていますから、「どのように導入していくか」の観点で、対象を4つのProfileに分類しています。(a) Lean, (b) Full, (c) Tailored, (d) Full Vanilla (中小事業体という意味のようです)。
この分類された対象事業体について、(a) BBP (Business Blue Print), (b) Porting Development, (c) New Development, (d) Data Cleansing, (e) Training, (f) OCM(Organizational Change Management)の6つの観点から、4 x 6 のマトリクスにしてSAP適用をあてはめています。
例えば、Leanに対しては既にSAPで稼働中であることも踏まえ、BBPも差分に留め、新規開発はしない、組織変更も最小限にとどめる、等の適用を定義しています。
この手法は、きわめて明示的でかつ、適用される(展開対象である)事業体にとっても論理的でわかりやすいと思います。
一方で、実は、SAPシステムをどのように使うか、きわめて詳細にチェックがなされたうえでのロジカルマトリクスであると読み取れます。ここでも、マトリクスの構造自体にSAPシステムの使い方のHowが埋め込まれていると思います。

終わりに

Bosch社が、Why SAPを明確に語らなくても、このように使うのだ、このように使って、上手にテンプレート展開している、これが、Why SAPではなくHow SAPで証明できる、本当のWhy SAPなのである、と筆者は考えます。しかしながら、日本の自動車産業にSAPソリューションを理解してもらう活動はまだまだ長い道のりであると考えています。繰り返しになりますが、例えばここで示したように、雰囲気やイメージではなくて、具体的かつ詳細に「どのようにやったか」を伝えること、何分類に定義したか、何対何のマトリクスで整理したか、どんな分析・定義軸をもったか、事例が具体的で詳細であれば、日本の自動車産業のお客様たちは、自らの思考様式(思考回路)でイメージを膨らませ、自ら再定義が可能だと信じています。そのとき、「あぁ、SAPシステムはこのように使うのだ、道具であっても、自らの思想と思考があれば、道具の枠を超えた道具になりうるのだ」と理解していただきたいと思っています。

※本稿は公開情報に基づき筆者が構成したもので、ボッシュ社 Bosch Corporation)のレビューを受けたものではありません。