ERPとは ITソリューション塾・福岡 2017年8月22日.

Presentation on theme: "ERPとは ITソリューション塾・福岡 2017年8月22日."— Presentation transcript:

1 ERPとは ITソリューション塾・福岡 2017年8月22日

2 ERPとは 2

3 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 業務 機能 業務 機能 業務 機能 業務 機能 業務のシステム化 業務システムの適用領域拡大 業務システムの統合化

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

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

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

7 「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経営実現を加速するための手段」ととらえ、カスタマイズや追加独自開発を極力少なくする取り組みを行わなければ、本来の価値を引き出すことができないことを理解しておく必要があります。

8 ERPシステム/パッケージとクラウドでの利用形態
アプリケーション SaaS 業務遂行に必要なソフトウエア 標準アプリケーション （クラウド・サービス） 他のクラウド・サービス タレント・マネージメント マーケティング・オートメーション 経費管理　など プラットフォーム PaaS 開発や実行に必要なソフトウエア ユーザー個別 アプリケーション インフラストラクチャー IaaS プロセッサー、メモリー、ストレージ、 ネットワークなどのシステム資源、施設 標準アプリケーション （パッケージ・ライセンス） ユーザー個別 アプリケーション ホステッド・プライベートクラウド

9 SAPの製品ラインナップ

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

11 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システムでは、コストに見合わず、その維持管理に、十分な人材を割くこともできない。 政治情勢や経済状況の変化が予測できず、事業を直ちに統廃合しなければならないことも考えられる。

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

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

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

15 BPRとERP 15

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

17 システム開発手法の変遷 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ということができます。

18 Enterprise Architecture
巨大な組織の業務手順や情報システムの標準化、組織の最適化を進め、効率よい組織の運営を図るための方法論 1987年にJohn A. Zachman(ジョン・A・ザックマン)氏が提唱 大企業・政府機関 米連邦政府 日本の電子政府 EAには、全社的な観点から業務を見直し、効率化するビジネス戦略の側面と、データの標準化やIT技術の活用というIT戦略の側面があります。経営改革の概念も含んでいるのです。 ビジネス戦略とIT戦略を結び付け、個々のシステムをデザインする際に従うべき規範や、業務とシステムの“あるべき姿”に到達するためのプロセスを定めることで全体最適化を図るのが目的です。 EAは4つのアーキテクチャから構成されています。 ・ビジネス・アーキテクチャ（BA：政策・業務体系） ・アプリケーション・アーキテクチャ（AA：適用処理体系） ・データ・アーキテクチャ（DA：データ体系） ・テクノロジ・アーキテクチャ（TA：技術体系） EAの起源は、1987年に「IBM Systems Journal」誌で提案された「Zachmanフレームワーク」とされます。1990年代に米連邦政府がEAの作成を義務づけたことから注目され、大企業がEAに取り組みました。日本でも東京三菱銀行や松下電器産業が取り組んだということです。日本政府も2003年から電子政府の取り組みのなかでEAを位置づけています。 しかし、EAは厳格すぎ、大規模すぎてうまくいかない例も多かったとされます。日本の電子政府の取り組みも、最近はトーンダウン気味のようです。 このEAの中のビジネスアーキテクチャの中に、プロセスモデルの定義があります。この部分にフォーカスし、プロセスモデルの最適化を行うために考えられたのが、ビジネスプロセスリエンジニアリングということができます。 厳格過ぎ、大規模過ぎでうまくいかない例も – 最近見直しの機運

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

20 ビジネスプロセス 定型的プロセス ひとまとまりの目的が定義できる 順序関係がある 販売管理のビジネスプロセス 入力と出力がある
受注 請求 入金 出荷 入力と出力がある 階層化されている ところで、ビジネスプロセスとは何か、というのは、実は大変に難しい問題なんですが、ここではあまり深いところまでは行かずに、ビジネスプロセスとは何かを考えて行きましょう。 例えば、とある企業における販売管理の業務プロセスを考える場合、こういった流れになったとします。受注して、請求処理をして、入金を確認したら商品を出荷する、という流れです。 この販売管理プロセス自身、さらに細かいプロセスから構成されます。例えば、請求処理であれば、金額・納期の確認や請求書の発行、発送といったプロセスに分解できるでしょう。 一方で、このプロセスは、より上位のプロセスの一部でもあります。営業活動や製造・在庫管理などと連携しています。 ビジネスプロセスの要件としては、一連の作業をひとまとめにして、ひとつの目的を達成できること、というのがあります。 そして、情報の入出力があること。どういった情報が必要で、プロセスの終わりにどういった情報を出力するかを明確に定義できなければなりません。そして、守るべき順序があります。さらに、ご覧のようにビジネスプロセスは階層化されています。 このように業務手順を分解してビジネスプロセスに落とし込むことにより、業務の流れが可視化され、繋がりが明確になり、どのような情報がどのように流れているのかがわかるようになります。 それらが明らかになることにより、ビジネス環境の変化が起きた場合に、どこを直せば良いかがすぐにわかり、変化に柔軟に対応できるようになります。 さらに、このようにビジネスプロセスを明確にしておくことにより、ITシステムへの実装がやりやすくなります。このあとお話しするSOAに結び着くわけです。 ビジネスプロセスを考えるときに特に難しいのが、どこまでをひとつのプロセスとして切り出すか、という「粒度」の問題なんですが、ITシステムとして考える場合には、開発するシステムの目的とか業務内容によって都度考えて行く、ということにしかなりませんので、ここでは突っ込みません。そここそが難しい、という問題はあるわけですけれども。 業務の流れ、繋がりを可視化 変化への柔軟な対応 サービス化、ITとの連動 (SOA)

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

22 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に基づき全社最適化を行い、各業務システム間の連携まで含めてシステムを開発する考え方とそのための統合型パッケージ

23 SOA (Service Oriented Architecture)
従来型のシステム構築手法による販売管理システム 受注 請求・入金 出荷 ビジネスプロセスに合わせてシステムを構築していない場合、後で変更するのが大変 他のシステムとの連携を考えていない場合 (インターフェースの標準化が行われていない)、後から付け加えるのは大変な作業になる 伝票のフローに沿ったシステム 要求仕様 販売管理プロセス 業務上の一処理に相当する機能をサービスとして実装 (共通のI/Fを定義) 受注 請求 入金 出荷 プロセス単位で サービス化 情報のフローに沿ったシステム SOAによる実装とは、ビジネスプロセスに対応させたモジュール構成とすることです。具体的な例を挙げて説明しましょう。 もう一度、先ほどの販売管理のプロセスを使いましょう。とある企業における販売管理の業務プロセスです。 受注して、請求処理をして、入金を確認したら商品を出荷する、という流れです。 一般的なシステム開発では、先ほどもお話ししたように、現在行っているプロセスを元にして要求仕様を作成します。 プログラマは、要求仕様を元に実装計画を作ります。ここでは、請求・入金は会計的処理なので一つのモジュールにしよう、という決定が下されたとします。 こうして、受注処理モジュール、請求・入金確認モジュール、出荷管理モジュールの3つでシステムを構築します。 ところが、競合状況が厳しくなり、顧客からの要望により、請求後、入金を確認できる前に出荷するというプロセスに変更する必要が出てきました。 この際、システム側でうまく対応できるかどうかは運次第です。要求仕様にはそんなことは書いてありませんから、モジュールの構造上そんなことはできないかも知れません。あるいは、そんな事態にも対応できるよう、設計されているかもしれません。 対応できなければ、改修に多額の費用と時間をかけるか、プロセスの変更を断念するかという選択になります。どちらの場合でも、ビジネスに良い影響がある訳はありません。 SOAの考え方は、ビジネスプロセスをサービスとして捉え、プロセス単位でモジュール化することです。モジュール間のインターフェースさえきちんとしていれば、先ほどのようなプロセスの組み替え要求にも柔軟かつ迅速に対応できるわけです。 言い換えれば、従来型は書類の流れに沿って作られたシステムであり、SOAによる実装は、情報の流れに注目した手法であると言うことができるでしょう。 もちろんこれは相当に単純化したモデルであり、元になるビジネスプロセスがしっかり見直され、粒度も適切である必要があります。 SOAによる販売管理システム 受注 請求 入金 出荷 プロセスの各業務単位(サービス)に合わせてソフトウェアを作ってあるので、後でプロセスが変わっても柔軟に対応できる サービス間でやりとりするデータの種類とフォーマットをXML等で決めて標準化 さらに、各ソフトをWebアプリ (Webサービス)にしておくと、将来のクラウド対応など、柔軟性が高まる ビジネスプロセスの変更にも柔軟に対応可能 受注 出荷 請求 入金

24 ビジネスプロセスをサービスとして実装 サービス Webサービス ひとまとまりの機能(サービス)を提供する独立したプロセス単位で実装
入力と出力を定義 順序の入れ替えや機能の追加が容易 販売管理のビジネスプロセス 受注 請求 入金 出荷 Webサービス 例えば、とある企業における販売管理の業務プロセスを考える場合、こういった流れになったとします。受注して、請求処理をして、入金を確認したら商品を出荷する、という流れです。 この販売管理プロセス自身、さらに細かいプロセスから構成されます。例えば、請求処理であれば、金額・納期の確認や請求書の発行、発送といったプロセスに分解できるでしょう。 一方で、このプロセスは、より上位のプロセスの一部でもあります。営業活動や製造・在庫管理などと連携しています。 ビジネスプロセスの要件としては、一連の作業をひとまとめにして、ひとつの目的を達成できること、情報の入出力があること。 どういった情報が必要で、プロセスの終わりにどういった情報を出力するかを明確に定義できなければなりません。 さらに、必要な情報さえ揃っているならば、ビジネスプロセスの単位で独立してそれを繰り返すことができること。 効果が測定できるというのは、アウトプットが明確でそれを定量化できるということです。 そして、ご覧のようにビジネスプロセスは階層化されています。 このように業務手順を分解してビジネスプロセスに落とし込むことにより、業務の流れが可視化され、繋がりが明確になり、どのような情報がどのように流れているのかがわかるようになります。 それらが明らかになることにより、ビジネス環境の変化が起きた場合に、どこを直せば良いかがすぐにわかり、変化に柔軟に対応できるようになります。 さらに、このようにビジネスプロセスを明確にした上で、アプリケーションコンポーネントとして実装したものを「サービス」と呼びます。明確に定義されたインターフェースを持ち、外部から呼び出すことができ、決められた入力に対して出力を返します。 ビジネスプロセスを考えるときに特に難しいのが、どこまでをひとつのプロセスとして切り出すか、という「粒度」の問題なのですが、これは開発するシステムの目的や業務内容によって変わります。 HTTP、XML、Rest、SOAPなどの インターネット技術を使って実装 クラウドへの展開が容易

25 SOAの狙いと成果 柔軟性の向上 管理の容易さ 迅速な開発 業務プロセスを見直し、サービス単位に分割
サービス間のデータ交換ルールを決め、メカニズムを構築 サービス単位でプログラムを開発し、相互に接続 情報システムを分割し、疎結合させる こうしてみると、SOAの本質は「情報システムをビジネスプロセスに分解して個々にサービスとして実装し、お互いを緩く連結してシステムを構築すること」と言えます。 これにより、システムの柔軟性を高め、管理が容易になり、開発速度を向上させることができます。アジャイル開発なども、SOAの考え方が大きく影響しています。 柔軟性の向上 管理の容易さ 迅速な開発

26 補足資料 26

27 エンタープライズ・システム・アーキテクチャー
ビジネス プロセス コスト削減 システム 課題とニーズ 変化への柔軟性 スピード経営 非効率 重複 不整合 欠落 機能不全 グローバル対応 戦略と施策 BPR EA 標準化を目指す アプローチ手法 部分最適から 全体最適へ 向かう取り組み BPM SOA プロセス標準化 のための手法 MDM ESB ERP 経営資源管理の一元化 マスター・データ の一元化 業務基盤強化 から 戦略基盤強化 ETL B I　 原因・理由の探索 集計と統計分析 DWH BA　 計画の最適化 モデル化と シミュレーション

28 他のエンタープライズ・アプリケーションとの関係
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を発展させて、商品を開発し、市場に投入してから発売中止になるまでのすべての期間（ライフサイクル）に渡るデータを一元管理する仕組み。 消費者／購入企業

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