ERP ITソリューション塾 2015年12月14日

ERPとは 2

ERPシステム 登場の歴史的背景 ERP メインフレーム時代 部分最適 複製システム・分散システム時代 部分最適 ERP時代 全体最適 業務 業務 業務 業務 業務 業務 業務 業務 業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 業務 機能 業務 機能 業務 機能 業務 機能 SYS SYS SYS SYS SYS SYS SUB SYS SUB SYS SUB SYS 業務 機能 統合マスター データベース ERP 業務 機能 部分最適 から 全体最適 へ 【図解】コレ１枚でわかるERPの歴史   1960年代に入り、ビジネス用途で使えるコンピューターが、普及しはじめます。当時、業務は、電話や紙の伝票の受け渡しで行われていましたが、その業務の流れをコンピューターのプログラムに置き換えようという使い方です。当時は、個々の業務の現場で使われている紙の伝票の流れに合わせて、プログラムのフローを設計したことから、業務個別に最適化されたシステムが作られてゆきました。 ただ、このようなシステムであっても、電話や伝言、紙の伝票での業務処理に比べれば、作業の生産性は劇的に向上したことから、情報システムの開発需要は、どんどん増えてゆきます。ただ、当時は、ユーザー企業の情報システム部門が、それぞれ独自に自社の業務に合わせてプログラムを内製するのが普通であったため、この需要に追いつけなくなってゆきました。 この状況を打開するため、最初から個々の業務に最適化された情報システムを作るのではなく、既に完成し稼働しているプログラムをコピーして、新しい業務に合わせて変更しなければならない部分だけを修正し、需要の増加に応えていたのです。それでも、完全に業務の流れに対応できないときは、人的な運用で代替することで凌いでいました。 また、1980年代に入り、小型のミニコンピューター（ミニコン）やオフィース・コンピューター（オフコン）、パーソナルコンピュータ（パソコン）が登場します。当時業務システムとして使われていた大型のメインフレームでのシステム開発では、要望してもすぐに開発してもらえず、コストも掛かることから、業務部門は、独自にこれら小型のコンピューターを導入し、さらにパッケージ・ソフトウェアを使って個別システムを構築するようになります。 このような取り組みにより、情報システムの適用範囲は拡大してゆきましたが、部分最適なシステムが増えたために、業務間の連係がうまく行えなかったり、データの不整合や二重入力といった弊害が増えたりと、いろいろな問題を抱えるようになったのです。 そんな中で、業務の重複や無駄を廃し、業務の効率化を図りたいという需要が高まってゆきます。また、エンロン事件やワールドコム事件のような、大規模な不正が大きな社会問題となったことなどもあり、内部統制への関心も高まります。そのために一貫性や完全性が保証されたデータで経営や業務状況を把握したいという需要も増えてゆきました。 そこで、これまで業務個別に最適化され開発されてきた情報システムを全社最適の視点で再構築しようという気運が高まります。そこで、全社最適の観点での業務プロセスを再構築し、業務個別に構築されていたマスターデータを全社で統合したデータベースに集約するとともに、その統合化されたデータベースを中核に業務システムを構築する「ERP（Enterprise Resource Planning）システム」が、注目されるようになったのです。 現場の業務をそのままシステム化 元の書類の流れに合わせたシステム 部分最適なシステム構築 様々な部門が様々なシステムを導入 重複業務（顧客マスター登録など） 別々のDB（顧客データなど） システム間でデータの互換性が無い 業務 機能 業務 機能 部門SYS 部門 SYS 部門SYS 業務 機能 業務 機能 業務 機能 業務 機能 業務のシステム化 業務システムの適用領域拡大 業務システムの統合化

個別業務システムとERPシステムの違い 個別業務システム ERPシステム 販売 生産 物流 販売 生産 物流 統合データベース 購買 会計 人事 購買 会計 人事

ERPシステムとは 購買 生産 販売 会計 購買 生産 販売 会計 個別業務システム ERPシステム 業務個別に プロセス 個別 システム 個別 システム 個別 システム 個別 システム ERPシステム 購買 生産 販売 会計 業務システム 経営 個別DB 個別DB 個別DB 個別DB 全社統合DB データベース 業務個別に プロセス・データの整合性を確保 会社全体として業務間の プロセス・データの整合性を保証 【図解】コレ１枚でわかるERPシステム   ERP（Enterprise Resource Planning）とは、企業経営の基本となる資源要素（ヒト・モノ・カネ・情報）を会社全体で一元的に把握し、それを適切に分配して有効活用する計画手法であり、その計画を重視する経営手法のことです。このERP経営を実現するための情報システムが、ERPシステムです。 業務個別に作られた情報システムは、それぞれ、台帳や帳票を収めたマスターファイルと業務処理を行うためのプログラムで構成されています。このようなシステムの場合、個々の業務処理には最適化されていますが、他の業務間の連係がうまく行えなかったり、似たような業務を重複して行っていたり、データの不整合や二重入力といった弊害が増えたりと、いろいろな問題を抱えることになります。例えば、「顧客情報」は、お客様の購買情報を管理し、販促キャンペーンでチラシを郵送するために販売システムで使われます。また、お客様に荷物を輸送する必要がある場合は、物流システムにも必要ですし、請求書を発行し、入金を確認するためには、会計システムでも使われます。しかし、マスターファイルが、個別に管理されていると、顧客情報が変更されたり、商品を販売したことで情報が更新されたりした場合、関係する全てのデータを書き換えなくてはなりません。また、ある業務システムのプログラムが修正された場合、影響をうける他の業務システムのプログラムを洗い出し、それを修正しなくてはなりません。 一方、ERPシステムは、会社全体で統合化されたマスター・データベースを用意します。全ての業務処理は、この統合化されたデータベースを使用します。そのため、データの一貫性は保証され、データの不整合や二重入力の手間はかかりません。また、データ相互の関連は、業務の流れ（ワークフロー）と一体となってデータベースに格納されますので、業務プロセス全体の整合性も保証されます。 さらに、データが全て一元的管理され、常に最新の状態に保たれていることから、会社全体の動きや状況をリアルタイムで捉えることができます。 ただ、このようなERPシステムを構築するためには、既に業務毎に個別最適化された業務プロセスを見直し、会社全体で最適化された業務プロセスに再構築しなければなりません。このような取り組みをBPR（Business Process Re-engineering）と言います。また、個別に作られたマスターファイルを整理し、統一のデータベースに作り直さなければなりません。 既に個々の業務の現場に最適化されたシステムが稼働し、それに馴れている人たちからは、抵抗されることも少なくありません。会社全体が抱える課題や現状についての危機感を正しく共有し、経営トップの強力なリーダーシップの元に取り組まなければ、実効性のあるERPシステムを構築することは、困難と言えるでしょう。 特　徴 処理にタイムラグが発生 二重入力によりマスターの分散 個別設計・構築 データやプロセスの不整合 個別維持管理による運用負担 プロセス全体の可視性なし リアルタイム処理 マスターの統合 全体最適化された設計・構築 データやプロセスの整合性を保証 プロセス全体の可視性を確保

「ERP」と「ERPシステム」と「ERPパッケージ」 ERP Enterprise Recourse Planning あるべき姿のひな形を使って、経営や業務の全体最適化を加速 企業経営の基本となる資源要素（ヒト・モノ・カネ・情報）を 適切に分配し有効活用する計画を重視する経営手法 ERP システム ERP経営を実現するための 情報システム ERP パッケージ ERP経営を支える理想的な業務プロセスをパッケージ化した情報システム 業務分析や業務プロセスの標準化(BPR)に手間やコストがかかり、実現が困難 【図解】コレ１枚でわかるERPとERPシステムとERPパッケージの違い   「ERP」と「ERPシステム」と「ERPパッケージ」の違いをご存知でしょうか。よく似た言葉ですが、それぞれに意味が違います。歴史的な背景を踏まえながら、その違いを解説します。 ERP ERP（Enterprise Resource Planning）とは、企業経営の基本となる資源要素（ヒト・モノ・カネ・情報）を会社全体で一元的に把握し、それを適切に分配して有効活用する計画手法であり、その計画を重視する経営手法です。 ERPという言葉は、製造業における資材所要量計画 (MRP：Material Requirements Planning) といわれる生産資材を管理し、計画する手法から派生した言葉で、資材以外の人員、設備など製造に必要なすべての資源を管理し、さらに、企業全体の在庫、決済、資産の管理を行うように発展したのがERP（企業資源計画）です。情報システムそのものを意味する言葉ではありません。 ERPシステム ERP経営を実現するための情報システムです。ERP経営を実現するためには、会社全体で業務の重複や無駄を排除し、部門個別に最適された業務プロセスではなく、会社全体として最適な業務プロセスを実現しなければなりません。そのためには、徹底した業務分析と業務プロセスの改革、標準化に取り組まなくてはなりません。この取り組みは、BPR（Business Process Re-engineering）と呼ばれています。ERPシステムは、このBPRを実施した結果明確にされた、全体最適化された業務プロセスを前提に構築される情報システムです。 ERPパッケージ 企業規模が大きくなればなるほど、部門の利害はぶつかり、部門を越えた会社全体での最適化をめざすBPRは困難を極めます。加えて、ビジネス環境の変化は、業務プロセスを常に変化させ、全体最適を維持するために業務プロセスの継続的見直しと最適化を行うこと（BPM：Business Process Management）は、容易ではありません。その変更に合わせてERPシステムに手を加え続けるとなると、手間もコストも膨大なものになってしまいます。そこで、登場したのか、ERPパッケージです。 ERPパッケージは、ERP経営を支える理想的（ベストプラクティス）な業務プロセスを予めパッケージ化した情報システムです。 ERPパッケージには、ERP経営を実践する上で必要となる業務プロセスや全社データを一元的に把握、管理するためのデータ構造のひな形が、業種や業務に応じたテンプレートとして、予め用意されています。このテンプレートを使い、業務の変革をすすめ、ERP経営の実現を加速しようというのです。 本来であれば、ERPパッケージが提供するベストプラクティスに沿ってBPRを推進すれば、ERP経営が実現できるわけですが、既に個別最適化された業務プロセスを持つ各業務部門が、それに合わせることは容易なことではありません。そんな現実を踏まえながら、最低限のテンプレートのカストマイズ、および、独自開発システムで対応できれば、ERPパッケージ導入の効果を享受することが可能となります。 ERPパッケージを、自社独自の基幹業務システムを開発するに当たり、最初から全てを作るのではなく、パッケージの機能を流用することで開発生産性を高めるための手段と捉えている企業もあります。しかし、それは、ERPパッケージ本来の目的でありません。「ERP経営実現を加速するための手段」ととらえ、カスタマイズや追加独自開発を極力少なくする取り組みを行わなければ、本来の価値を引き出すことができないことを理解しておく必要があります。

ERPシステムの全体像 ERPシステム 統合データ アナリティクス 可視化 可視化・分析・計画 アプリケーション 営業・販売 経理・財務 効率的義用務運営 リアルタイム経営 内部統制 ERPパッケージ利用のメリット ベストプラクティスの活用 法律・制度変更への迅速な対応 構築に関わる期間とコストの削減 経営 営業・販売 可視化 可視化・分析・計画 アプリケーション 経理・財務 営業・販売 アプリケーション アナリティクス 経理・財務 アプリケーション 統合データ 倉庫・物流 アプリケーション 調達・管理 アプリケーション 【図解】コレ１枚でわかるERPシステムのメリット   ERPシステムの価値は、以下の3つだといえるでしょう。 効率的業務運営 従来業務ごとに分散し、分断されていたマスターデータ（製品や取引先など）や取引データ（各種伝票など）を、統合データベースによって一元管理できます。そのため、全ての業務処理は、単一のデータを参照し、更新されるため、ある業務処理が実行されると同時に、そのデータに関連する全ての業務にもその更新が反映されます。 例えば、顧客情報が更新されると、それを使用する販売、会計、出荷などの全ての業務システムが、更新された同一のデータをすぐに利用できるため、業務プロセス全体で直ちに整合性が担保され、部門間の連携がスピーディに行えます。また、同じデータを複数の業務システムに個別に入力する、あるいは転記すると言った手間がなくなり、業務の効率化が実現されます。 また、販売、生産、会計など複数の業務をつなぐ処理手順（ワークフロー）も統合データベースで管理されます。そのため、業務の流れとデータ更新の整合性が常に担保されることから、正確で円滑な業務処理が実現されます。 リアルタイム経営 業務に関わるデータは、常に全体として最新の状況が反映されていることに加え、売上や原価、在庫や進捗などの数字も全て一元的に管理されているため、会社全体の状況をリアルタイムで把握することが可能になります。BI（Business Intelligence）アプリケーションなどを使用し、経営や業務の状況を分析、可視化し、経験や勘ではなく、データに基づく意志決定を正確、迅速に行うことを可能とします。 内部統制 統合データベースによるデータの整合性の保証、また、ワークフローに基づく利用者権限や利用履歴の一元管理により、会社の業務全般にわたっての内部統制が、容易に行える環境を整えます。 これらパッケージとして導入する場合、以下の３つのメリットを享受することができます。 ベスト・プラクティスの活用 ERPパッケージの開発元や導入支援企業は、多くのユーザーでの実務経験を収集し、それぞれの業種や業務に応じたベスト・プラクティスのテンプレートを提供しています。 ERPパッケージには、業務処理に必要な基本機能をプログラムとして実装していますが、それらをどのように使用するかをプログラムそのものに手を加えることなく、パラメーターやスクリプト言語によって設定できます。その設定のセットが、テンプレートです。このテンプレートを使うことで、他社のノウハウやベスト・プラクティスを利用することで、自社のERP経営に向けた業務改革を加速させることができます。 法律・制度変更への迅速な対応 自社で独自の情報システムを構築する場合、税務や会計などの法律や制度が替わるたびに、プログラムの改修が必要になります。ERPパッケージでは、このような変更をパッケージの開発元が実施し、対応してくれます。そのため、制度変更への対応の負担が少なく、迅速に対応することができます。 構築に関わる期間とコストの削減 ERPパッケージを導入するに当たっては、現状業務の分析と整理、ERPパッケージが提供するテンプレートとのギャップを明らかにしなくてはなりません。その上で、変えなくてはならない業務プロセスは何か、テンプレートの何をカスタマイズするか、追加すべきプログラムは何かを明確にします。 本来であれば、ERPパッケージが提供するベストプラクティスに沿って業務改革（BPR：Business Process Reengineering）し、パッケージをそのまま利用することが導入コストと期間という点では望ましいと言えますが、既に各企業において最適化された業務プロセスを変更することは容易ではありません。そんな現実を踏まえながら、BPRを推進することで、独自開発を減らすことができれば、導入・構築に関わる期間短縮とコスト削減の効果を大きくすることができます。 生産・製造 アプリケーション 人事・給与 アプリケーション 倉庫・物流 調達・管理 ERPシステム 倉庫・物流 調達・管理

オンプレミス型からクラウド型へのシフト http://www.strategyand.pwc.com/media/file/Beyond-ERP.pdf 継続してオンプレミスでERPを導入するニーズは20％にとどまっており、クラウドで利用できるのを前提とした利用で、オンプレミスと連携できる環境を求めている比率が64%となっています。 Pwcのデータに調査によると、オンプレミスERPは2016年までに30％減少減少し、クラウド型のERPが追い抜く状況となっている。 http://www.epicor.com/company/whats-next.aspx

OSS ERP http://it.impressbm.co.jp/articles/-/11256?page=3

ERPシステムの成り立ち 10

部分最適なシステム構築 サイロ化 現場の業務をそのままシステム化 ・元々の「書類の流れ」に合わせたシステム ・部分最適なシステム構築 ・様々な部門が様々なシステムを導入 ・重複する業務（顧客マスターの登録など） ・別々のDB（顧客データなど） ・システム間でデータの互換性が無い 1964年に発表された世界初の汎用機であるIBM System360は、「360度全ての用途に使える」コンピュータでした。 生産管理・販売管理・会計処理などをひとつのシステムで行うことができました。 1台のマシンで全てのアプリを動かすわけですから、開発・運用もほとんどの場合ひとつの会社が請け負います。 システム構成や他のアプリも熟知していますから、アプリ間の連携がとれない、などという事態は起こらなかったわけです。 しかし、メインフレームは数十億円もするシステムですから、導入できる企業は限られています。 1970年代以降、ダウンサイジングの波が起こり、コンピュータの価格が劇的に下がり、それまでコンピュータを導入できなかった企業にも浸透しはじめたのです。 その結果、事業部門毎に様々なシステムが入ることになりました。IT部門が頑張って整合性をとろうとする動きもあったでしょうが、全ての面倒を見ることはできません。 様々なシステムが、個々の事業部門の要求仕様に従って構築されたのです。どうしても、他部門のシステムとの統合にまで考えがおよばないケースもあったでしょう。 システム毎にメーカーが違ったり、開発業者が違うケースもあります。導入時期が違えば、使う技術も変わります。 しかし、発注元である現場部門としては、自分達の要求が満たされることが第一の目的です。 要求仕様をどう作るかというと、皆さんも経験があるでしょうが、現場でどういった業務を行っているかをヒアリングするのがまずは第一歩です。 その業務の流れを、そのままコンピュータ化するのがシステム開発です。いわば「その時点での『書類の流れ』をシステム上に実装したもの」ということができます。 このようなシステムの作り方だと、他のシステムとの連携も、必要最小限しか考慮されないでしょう。部門内の業務をメインに考えられた「部分最適のシステム」ができあがります。 そうなると、顧客マスターの登録業務を会計部門でも営業部門でも製造部門でも行っていたりすることになります。 各々の部門が「顧客マスター」のデータベースを持ち、どれが本物のマスターなのかが分からなくなります。正確な顧客リストが出せなくなるわけです。 うっかりすると、各マスター間で互換性が無く、名寄せもできない、などということが起こっても不思議ではありません。 このように、お互いに連携が不足で、孤立化した状況を「システムのサイロ化」などと言います。サイロとは、北海道などに良くある、牧草を入れておく塔のような建物のことです。お互いに孤立してますよね。 サイロ化

システム開発手法の変遷 Enterprise Architecture Business Process Re-engineering 従来は部分最適な業務システム 個別にシステム設計開発 現場の仕事をそのままシステム化 「その時点」での技術を使って開発 他システムとの連携は必要に応じて設計・実装 全社的最適化という視点はない 全社最適化手法 EA Enterprise Architecture BPR Business Process Re-engineering ERP Enterprise Resource Planning Enterprise Architecture 複雑化し非効率化した巨大な組織の業務手順や情報システム、組織を全社規模で最適化し、効率よい組織の運営を図るという考え方または方法論。 EAにより、巨大な組織内で複数の業務システムが別個に運用されていたものを標準化し、導入・運用コストの削減、重複した業務内容の統合を通じて組織の運営コストの削減を目指す。 Business Process Re-engineering 高度に専門化され、プロセスが分断された分業型組織を改革するため、組織やビジネスルールや手順を根本的に見直し、ビジネスプロセスに視点を置き、組織、職務、業務フロー、管理機構、情報システムを再設計し、最終的顧客に対する価値を生み出す一連の改革。 このように、ダウンサイジングによってコンピュータが普及した代わりに、企業内に部分最適の業務システムが乱立してしまいました。 システム間の連携が充分に考えられておらず、必要になった時点で開発する、などといった二度手間が生じるようになってきたのです。全社的な観点から見た開発効率としては、良くはありません。 これは、システムの設計開発にあたって全体的な視点というものが欠けていたことが原因です。 この反省に立って、全社的な視点からシステム開発を考えようという動きが起こりました。1980年代に提唱されたEnterprise Architectureです。 EAは、複雑化し非効率化した巨大な組織の業務手順や情報システムを抜本から見直し、全体規模で最適化しようとする、非常に大きな枠組みの考え方です。EAにより、システムへの要件が決まり、それをベースにシステムを構築すれば、全体最適化されたITシステムを構築できます。 このEAという大きな考え方の中で、ビジネスプロセスに注目し、これを根本的に見直していこうという部分がBPRということができます。

Business Process Re-engineering ビジネスプロセスの改善に注目 企業改革を目的としてビジネスプロセスを見直し ビジネスプロセスの視点で職務、業務フロー、管理機構、情報システムを再設計するという経営コンセプト ビジネスプロセスの考え方は1980年代に製造業の品質管理手法として考案されたシックスシグマが最初 1990年に元マサチューセッツ工科大学教授のマイケル・ハマー（Michael Hammer）がHarvard Business Review誌に論文を発表 BPRの原点は古典的なビジネス構造の否定 「重大で現代的なパフォーマンス基準を劇的に改善するために、ビジネス・プロセスを根本的に考え直し、抜本的にそれをデザインし直す」 1990年代終わりになると、非連続的な大改革が逆に大混乱を招く 1997年、MITシステムダイナミックス・グループが 「リエンジニアリングの70％は失敗」などと報告 BPRという考え方は、EAよりも少し後、1990年に元マサチューセッツ工科大学教授のマイケル・ハマーが発表した論文が始まりとされます。 http://www.itmedia.co.jp/im/articles/0401/14/news089.html ただ、ビジネスプロセスという考え方そのものの歴史はもう少し古く、1980年代にモトローラやGEなどが取り組んだ品質管理手法であるシックスシグマが取り入れたのが最初と言われています。 ハマーは、高度に専門化され、プロセスが分断された分業型組織に見られる職能別の古典的なビジネス構造を全面的に否定し、プロセス志向の新たな組織構造・価値観・評価システムをゼロから作り出すことを勧め、抜本的な変化を起こすための一連の手順としてBPRを考え出しました。 BPRの定義は「コスト、品質、サービス、スピードのような、重大で現代的なパフォーマンス基準を劇的に改善するために、ビジネス・プロセスを根本的に考え直し、抜本的にそれをデザインし直すこと」です。 これは要するに「既存のやり方は全部駄目」という考え方で、BPRの導入はまず既存のプロセスの破壊から始まったのです。 このため、BPRを導入しようとした企業の多くが「プロセスの見直しのしすぎ」で混乱に陥り、97年にはBPRの70%が失敗に終わったという報告が出されました。 しかし、逆に言えば30%の企業では効果があったとも言えます。業態や取り扱い製品の違いなどによるものなのでしょうが、BPRの考え方そのものが間違っていたわけではなく、やり方がよくなかったということでしょう。

ビジネスプロセスの継続的な見直し ① ② ③ ① 受注 受注処理 生産 受注 受注処理 生産 例外処理 構成チェック 構成チェック 「望ましい」業務プロセス 書類 「望ましい」 業務プロセスでは効率が悪い 環境の変化により「望ましい」業務プロセスに戻す必要がある 受注 構成チェック 受注処理 生産 ① 問題 発生 例外処理 「修正した」業務プロセス 書類 しかし、ビジネスプロセスの見直しは、一回行ったらそれで終わり、ということにはなりません。具体的な例を挙げてご説明します。 ある製品の受注処理を行う場合の本来望ましい業務プロセスな上のようなものだったとします。 前提として、この製品は構成が難しく、きちんと動かすためには受注した構成を1度工場でチェックするのが望ましいとします。 またこの当時は本社と工場の間がオンライン化されておらず、校正チェックのためには受注書類を1度向上に郵送しなければならないとします。 このような場合受注して書類を工場にいったん送りそれがおおきであればもう一度本社に戻して受注処理を行った後に最終的に生産のためにもう一度工場に送るというプロセスになります。あまりやりそうにない話ですがビジネスプロセスをご理解いただくための例としてお考え下さい。 しかしこの書類のやり取りを郵送で行っていると、いかにも時間がかかります。そこでこの企業では、オーバーヘッドを減らすために、受注処理前の校正チェックを行わないというプロセスを考えました。受注書類を工場に送ると同時に、本社で受注処理をしてしまうのです。そうすれば書類を送るのは1階ですみます。 構成が間違っていた場合には、受注処理をやり直すことになりますが、その可能性が10分低い場合には有効な考え方です。 さて、時代が進み、本社と工場がコンピュータネットワークで接続されかとします。環境の変化です。この場合には書類のやり取りによる時間のロスが発生しませんから、本来望ましい業務プロセスに戻す必要があります。そうすれば例外処理もなくなり更に効率化望めるからです。 しかし大にしてこの望ましい業務プロセスの変更は行われないことが多いようです。業務プロセスの修正から時間が経ってしまうとなぜその業務プロセスを採用しているのか、誰も疑問を持たなくなりますし、過去の経緯を知っている人も少なくなってしまうからです。このため本来望ましい業務プロセスがあるにもかかわらず、効率の劣る業務プロセスを使い続けるという結果になってしまいます。 オーバーヘッド の低減 ネットワークの普及・高速化などの環境変化

BPRからBPMへ BPR BPM BPR継続のための仕組み 改善・再ち構築 分析 モニタリング 設計 実効 業務内容や業務構造・手順を 根本的に見直して売り上げの 拡大やコスト削減を目指す 一連の活動 これがBPRの問題点です。BPRはビジネスプロセスを根底から見直すと言う作業を行いますが、それを継続するという考え方が抜けていました。 これを改善したのがBPM、Business Process Managementです。 BPMではPDCAサイクルを回してBPRに継続的に取り組むための仕組みを作ることを要求しています。

Enterprise Resource Planning EA→BPM→ERP 理念 Enterprise Architecture 巨大な組織(enterprise)の業務手順や情報システムの標準化、組織の最適化を進め、効率よい組織の運営を図るための方法論あるいは、そのような組織構造を実現するための設計思想・基本理念(architecture) 全体最適 プロセス ある仕事のスタートから完了までの流れを業務単位（プロセス）に分解して検証し、新しいプロセスが必要になった場合にもできるだけ他のプロセスに影響を与えないように挿入するなど、改善や再構築をしながら常に分析し、ビジネス効率を高めること。Enterprise Archtecture による全社的最適化との連携も重要。 分析 設計 実効 モニタリング 改善・再構築 BPM これまで話してきたように、EAは全体最適を目指すという「理念」です。 このEAの中の、ビジネスプロセスの見直しとそれを継続的に行う仕組みを取り入れた上で、EAが定める4つのアーキテクチャを定義し、全体最適なITシステムを開発するという考え方がERP、その考え方に基づいて構築されたシステムがERPシステムです。 つまり、全体最適なERPシステムの構築のためには、まず全社規模でのBPRを行い、それを元にアプリケーションアーキテクチャ、データアーキテクチャ、テクノロジアーキテクチャを作成することが必要になるということです。これは大変な作業です。 手法/ システム ERP Enterprise Resource Planning BPRに基づき全社最適化を行い、各業務システム間の連携まで含めてシステムを開発する考え方とそのための統合型パッケージ

ERPのグローバル展開と ２層ERP（Two-tier ERP） 17

ERPの理想と現実 2層ERP 理 想 Global Single Instance / One Global Standard 現 実 理　想 国内外のグループ企業の全拠点に同一ERPシステムを導入し、データフォーマットを統一、業務やデータの連係を円滑に行う。その結果、業務処理を効率化でき、経営状況をリアルタイムで把握できるようにする。 Global Single Instance / One Global Standard 拠点毎に個別最適なパッケージを導入 親会社のシステムをひな形とする 親会社のマスターに合うようにデータを変換する 2層ERP 2 Tier ERP 【図解】コレ１枚でわかる２層ERP   企業活動のグローバル化に伴い、経営資源もまたグローバルに全体最適を求められるようになりました。その対応として、国内外のグループ企業の全拠点に同一のERPシステムを導入することで、データフォーマットを統一し、業務やデータの連係を円滑に行うことで、業務処理を効率化し、経営状況をリアルタイムで把握できるようにしようというニーズが高まってきました。全拠点を単一の企業組織のように扱おうというこの考え方は、Global Single Instanceと呼ばれています。 しかし、本社とは異なる事業を行っていたり、海外の地元企業との合弁会社であったり、商習慣が異なっていたりする拠点においては、業務フローやデータ構成が本社と異なることは避けられません。このような拠点に同一のシステムを導入すると、現場の業務内容とERPシステムの機能とのギャップを人手による運用で埋めなくてはならず、逆に業務負担が増えてしてしまうことがあります。 また、本社は、大企業であっても、海外の拠点は、小規模な組織で運用されていることもあり、本社と同様の大規模なERPシステムでは、コスト的に見合わず、その維持管理に、十分な人材を割くこともできません。 また、国によっては、政治情勢や経済状況の変化が、日本のようには予測できず、事業を直ちに統廃合しなければなければならないといったことも考えられます。そのため、本社と同一の大規模なERPシステムを全拠点に導入することは、大きなリスクを伴うことになります。 このようなリスクを回避し、グローバルでの全体最適をめざす手段として登場したのが、「2層ERP（Two-tier ERP）」という考え方です。 2層ERPとは、本社で稼働している大規模なERPシステムとは別に、各拠点の事業内容や規模に応じて最適なERPシステムを導入し、本社のERPシステムと、一定のルールに基づきデータの組み替えを行い円滑なデータ連携を図ろうというものです。本社のERPシステムを「1st tier ERP（または、コアERP）システム」、各拠点のERPシステムを「2nd tier ERPシステム」と呼びます。 各拠点は、それぞれの業務や規模に合わせてERPシステムを選定できるため、先に挙げたリスクを回避できます。加えて、本社は、各拠点のERPシステムのデータをコアERPシステムに容易に取り込むことが可能となり、グローバルな全体最適を実現しやすくなります。 各拠点のERPシステムは、コアERPシステムとのデータ連携が可能であれば、様々なERPパッケージの中から選定することができます。ただ、本社からの運用支援や連携を効率よく行うために、できるだけ同一のものを採用する傾向にはあるようです。 昨今、2nd tier ERPシステムをクラウド版のERPシステムで導入しようという動きが増えています。クラウド版のERPシステムは、サーバ購入や運用管理要員の雇用のためのコストがかからず、短期間での導入できます。更に、ビジネスの展開に合わせて、機能や性能の伸縮を柔軟に行うことできるため、ビジネスの不確実性が高い海外拠点で導入するには、最適な選択肢となっています。このような理由から、クラウドERPを利用した2層ERPの採用は今後増えてゆくものと考えられます。 現　実 本社と同一の大規模ERPシステムの全拠点導入は大きなリスクを伴う 本社と異なる事業、地元企業との合弁、商習慣の違いにより、業務フローやデータ構成が本社と異なる。 同一のシステムを導入すると、現場の業務内容とERPシステムの機能とのギャップを人手による運用で埋めなくてはならず、逆に業務負担が増えてしてしまう。 海外の拠点は、小規模な組織で運用されていることもあり、本社と同様の大規模なERPシステムでは、コストに見合わず、その維持管理に、十分な人材を割くこともできない。 政治情勢や経済状況の変化が予測できず、事業を直ちに統廃合しなければならないことも考えられる。

2層ERP(2-Tier ERP)の考え方 ERPの目指す理想型 本 社 2層ERPの考え方 本 社 子会社 子会社 本　社 子会社 2層ERPの考え方 本　社 子会社 同一経営プロセス/同一アプリケーシュン 同一勘定科目・管理基準 複数企業体が、同一企業体のごときオペレーション 個別経営プロセス/個別アプリケーション 本社勘定科目・管理基準に準拠 複数企業体の個別オペレーション／データ組替連携

Two-tier ERP (2層ERP)の構成 親会社 ERP Business byDesign 子会社

1st Tier 2nd Tier 2層ERPの仕組み データ変換のためのインターフェイス (Core ERP) 販売 生産 物流 大企業向けパッケージ 販売 生産 物流 統合データベース 購買 会計 人事 データ変換のためのインターフェイス 2nd Tier 中小向けパッケージ クラウドERPなども活用 1st Tierとのインターフェイス 販売 生産 物流 購買 会計 人事 統合データベース 販売 生産 物流 購買 会計 人事 統合データベース 販売 生産 物流 購買 会計 人事 統合データベース

補足資料 22

他の手法との関係 MRP PDM MRP ERP PLM SCM SCM ERP CRM CRM PDM PLM 生産 物流 販売 Memo MRP 部品・材料サプライヤー Material Requirements Planning Manufacturing Resource Planning 資材所要量計画。商品を製造する際に必要な部品・材料の種類x数量を把握するための手法。これを発展させ、部品や資材だけでなく、人的資源や生産設備の能力などを勘案して、製造に必要な日程の把握までを行う手法。 生産 PDM 生産計画 研究開発情報 MRP ERP PLM Enterprise Resource Planning 生産に関わるものだけではなく、企業活動に必要なヒト・モノ・カネの情報を一括して把握し、企業活動の全体最適を図る経営手法。 在庫情報 SCM 物流 Supply-Chain Management SCM 小売店や卸店、メーカー、部品・ 材料サプライヤーといったモノの流通にかかわる企業が情報を共有し、仕入れ数量と販売数量を一致させるための仕組み ERP CRM Customer Relationship Management 顧客毎の購買履歴や顧客の属性を管理し、顧客の趣味・嗜好にあわせた最適な商品やサービスを告知、提案するための仕組み。 会計情報 顧客情報 販売 CRM PDM Product Data Management 商品の開発、設計、製造に至る業務に必要なデータを一元管理するシステムのこと。ある製品がどのような部品で構成しているかを表す部品表管理機能を含む 購買情報 PLM Product Life-cycle Management PDMを発展させて、商品を開発し、市場に投入してから発売中止になるまでのすべての期間（ライフサイクル）に渡るデータを一元管理する仕組み。 消費者／購入企業

他の手法との関係 MRP EDI SCM SCP 部品・材料サプライヤー 商品の動きを捉える 消費者／購入企業 ERP 経営資産を捉える Memo 部品・材料サプライヤー ERP 経営資産を捉える 調達管理 調達計画 調達計画 財務会計 MRP 人事給与 生産管理 生産日程 納期回答 資産管理 生産計画 生産計画 請求処理 EDI 販売計画 Electric Data Interchange 請 求 出荷処理 在庫管理 需要予測 SCM 在庫引当 顧客管理 商品の動きを捉える 受注処理 納期回答 SCP 注 文 Supply-chain Planning 消費者／購入企業