ERP導入をコアとした経営・国内外サプライチェーン改革

本クライアントは大手自動車メーカーで、「経営データの見える化」と「業務プロセス」において、以下の課題を抱えていました。

データ上の課題（経営データの見える化）

• 売上見通し・原価・在庫を把握しにくい
  経営判断に必要な売上見通し・原価・在庫の数値が見えにくい状態でした。
• 売上・原価・在庫の相関が分からない
  売上見通し・原価・在庫がどう影響し合っているかを、一連のストーリーとして説明できませんでした。

プロセス上の課題（業務プロセス・組織運営）

• 顧客交渉がデータに基づいていない
  顧客起因のコスト増、需要変動、特急納品の経緯を十分に把握できていませんでした。そのため顧客との事前・事後の交渉で根拠を示せず、力関係で結論が決まりがちでした。
• 類似製品が乱立している
  顧客ごとの要望に応じた製品づくりを繰り返した結果、似た製品が増えました。これにより、コスト面・製造面での競争力が下がるリスクを抱えていました。
• 生産計画の頻繁な組み直しと低利益案件の発生
  操業度や実際原価が営業担当に共有されていませんでした。そのため生産計画を日々組み直す必要が生じ、利益の低い案件も発生していました。
• 国内外グループ全体の統制が弱い
  国内外の拠点がそれぞれ独自に動いており、自動車メーカーグループとしての力を集約できていませんでした。

レイヤーズは、エンタープライズアーキテクチャー（EA）の4領域であるビジネス・データ・アプリケーション・テクノロジーに、プロジェクトマネジメントを加えた5つの観点から、ERP導入を軸とした改革を支援しました。

①ビジネス改革

• ERP導入だけでは課題は解決しないと合意
  前述の課題は、ERPを導入すれば自動的に解決するものではないという認識をクライアントと共有しました。たとえば、ERPで在庫は可視化できますが、在庫を減らすための指示・実行・モニタリングを担うのは人です。
• KGIの設定とプロジェクト専任者の育成
  ERP導入後のKGIを定めたうえで、各部門からプロジェクト専任者をアサインしました。製造部門出身のメンバーであっても、営業から製造・会計までの業務プロセス全体の検討に関わり、経営改革の視点と部門横断のプロセス・データの知見をプロジェクト活動を通じて身につけました。

②データ改革

• データの流れを一方通行に整理
  錯綜していたデータの流れを、できる限り一方通行に整理しました。
• 「入力の効率化」ではなく「アウトプットの高度化」を目的に設計
  システム導入の目的を「アウトプットの高度化」と定め、経営判断のポイントとアクションを整理しました。そのうえで必要なマスタ・トランザクションを絞り込み、関係しない入力項目を削除しました。これにより、「今の入力画面のほうがよい」「今使っているデータがERPに入力できない」といった失敗要因を取り除きました。
• データ移行量の絞り込み
  システム稼働の2大阻害要因の一つであるデータ移行について、利用用途があるデータだけを現行システムから移行しました。
• マスタ値の見直し
  時間の経過とともに管理目的とずれていたマスタの値を見直しました。あわせて、入力者が値の意味を感覚的に理解できるよう整理し、正確な選択・入力につなげました。

③アプリケーション改革

• Fit to Standardの徹底
  業務をERPの標準機能に合わせる「Fit to Standard」を徹底しました。要件定義の段階からユーザーテストシナリオを使い、引き合いから出荷・会計計上までを繰り返し実行しました。専任者が新しい業務をイメージしたうえで、「なぜ標準機能に合わないのか」「どうすれば合うのか」「現行のやり方を残すと後続業務にどう影響するか」を徹底的に議論しました。
• アドオン開発の回避
  ERPの標準機能に合わない、または機能が不足する部分は個別ソリューションを採用し、アドオン開発を避けました。現行システムを残す選択肢もありましたが、将来の人手不足や機能追加のコストを考慮し、現行システムでの対応は最小限にしました。
• インタフェース開発量の削減
  システム稼働のもう一つの阻害要因であるインタフェース開発について、インタフェースの数を減らすとともに、ETLツールで個々の開発作業を効率化しました。

④テクノロジー改革

• オンプレミスからクラウドへの部分移行
  自社開発・オンプレミス環境から部分的に脱却し、ERPと個別パッケージをクラウド化しました。クラウド化に伴う拠点間の通信量増加を見積もり、ネットワークも増強しました。
• オープン化に伴うセキュリティ対策
  セキュリティリスクの低いオフコン環境からオープンな環境に移行したため、機密性・可用性のリスクをあらためて分析し、対策、リカバリ手順、オフライン時の業務手続きを定めました。
• コミュニケーション基盤の統合
  基幹システムの改革と並行して、Web会議・ファイル共有・チャットなどを統合基盤に移行しました。

⑤プロジェクトマネジメント

• PMBOKに加えた2つの取り組み
  PMBOKに基づく従来型のプロジェクトマネジメントに加え、「プロアクティブマネジメント」と「プロジェクトマーケティング」を重視しました。
• プロアクティブマネジメント：経営層への定期報告とバッドニュースファースト
  担当役員には毎月、社長には隔月で報告の場を設け、推進の考え方、現況、見通し、他社の成功・失敗事例とポイント、資金・人員・期間の追加要請の可能性を伝えました。信頼関係を築いたうえで、悪い情報ほど早く伝える「バッドニュースファースト」をできる限り実践しました。
• プロジェクトマーケティング：社内への発信とメンバーの結束
  担当役員・社長が報告資料を使って部長級以下に直接語りかけられるよう工夫しました。また、合宿や懇親会でメンバーの慰労と結束を図り、社内から「面白そうなことをやっている」「自分も加わりたい」と思われるような情報発信を意識しました。

主な成果・取り組みは、売上見通しのフォーキャスト管理、製品別原価の導入、販社在庫の削減、決算早期化（個別1営業日・連結5営業日）、間接部門人員の半減などです。また、稼働延期を経て新システムはほぼ混乱なく稼働しました。

なお、在庫削減などのKGIは、新システムの稼働によって即座に達成されるものではなく、システムのアウトプットを活用して人が指示・実行することで達成されます。そのため以下には、実現済みの成果と、実現に向けて検討中の取り組みの両方が含まれます。また、主要なものに絞って記載しているため、【図3】の内容とは一部異なります。

ビジネス改革の成果

• 売上見通しのフォーキャスト管理
  いつ・誰が・何を根拠に見通しを立て、更新したかを記録し、信頼度に応じてフォーキャストを管理できるようにしました。
• 生産スケジュールの週次確定とグループ統合
  引き合い・受注の変動を日々反映するのをやめ、生産スケジュールを週次で確定する形にしました。また、工場別のスケジュール立案を廃止し、企業グループ全体で統合したスケジュールにしました。
• 標準製品と顧客別オプションの切り分け
  従来は顧客別オプションの単位で製品を定義していましたが、標準生産する製品と顧客別オプションを分けて管理するようにしました。
• 製品別原価・標準原価の導入
  製品群別の原価管理から製品別の原価管理に移行しました。標準原価を導入して実際原価・目標原価と比較できるようにし、原価低減活動を可能にしました。
• 販社在庫の削減と外部倉庫の縮小
  製品の販社在庫を削減し、特に月をまたいで為替リスクを抱えることを禁止しました。工場倉庫から顧客へ直送することで金流と物流を分離し、外部倉庫を縮小しました。
• 決算早期化
  個別決算を1営業日、連結決算を5営業日で締める体制にしました。
• 間接部門人員の半減
  間接部門の人員を半減しました。
• 営業・製造・管理部門の役割の明確化
  従来は製造部門が製品群別の粗利に責任を負っていましたが、営業部門は利益計画、製造部門は原価計画、管理部門は販管費計画を担う形に切り分けました。製販間で受け渡すマージンも見直しました。

データ改革の成果

• マスタの標準化と統合管理
  経営管理の観点からマスタを標準化し、拠点ごとに設定していたマスタの管理を統合しました。
• 部門間のデータアクセスの壁を撤廃
  部門ごとに分かれていたデータへのアクセス制限をなくしました。
• トランザクション管理単位の標準化
  ERPのシングルインスタンス化により、トランザクションの管理単位が自然と標準化されました。

アプリケーション改革の成果

• シンプルなシステム構成とメンテナンスフリー化
  ERP導入によりシステム構成をシンプルにし、メンテナンスの手間を大幅に減らしました。
• 業務の標準化と人員の最適配置
  Fit to Standardにより業務を標準化・整流化し、人員の最適配置につなげました。

テクノロジー改革の成果

• オフコンからの脱却の目途
  レガシーなオフコン環境から脱却する目途が立ちました。

プロジェクトマネジメントの成果

• 稼働延期を混乱なく判断し、ほぼ混乱のない稼働を実現
  稼働を2度延期し、当初予定より1年遅れの稼働となりました。しかし、プロアクティブマネジメントによって経営層には苦渋の決断ながら混乱なく延期を判断いただき、新システムはほぼ混乱なく稼働しました。
• 出荷停止を防ぐ「製造出荷物理検証」
  他社で起きている「新システム稼働による出荷停止」事故を教訓に、「製造出荷物理検証」を実施しました。システム操作による仮想的な検証だけで満足せず、新システムのピッキングリストを持って実際に倉庫へ行き、梱包指示に沿って梱包・出荷まで行いました。これにより「頭では理解していたが実際には動けない」事態を防ぎ、データ移行ミスの発見や「困ったときに誰に聞けばよいか」の実地訓練にもつながりました。