BPR before ERP integration
効果を導く正しいBPR
図1；BPRの順序
（図をクリックすると大きく表示されます）
解説
システム導入を失敗したクライアントと意見交換しながらその原因を追求した結果、マネジメント・コンサルティングを専門とする弊社が指摘した一つが「BPRを取り入れる順序」である。図1にあるように、システム機能を中心に進める場合、RFPが提出されてIT vendorが決定された後、BPRが実施されている。しかし、このケースで行われているBPRとは「業務改革」ではなく、システムをスムーズに導入するための「機能整理」に過ぎない。結果、スムーズに導入されるどころかアドオンが増えてしまっているケースも多々みられる。
本来BPRを実施すれば、それだけで業績効果がもたらされている。BPRは機能整理ではない。
図2；適合率
（図をクリックすると大きく表示されます）
更に失敗への追い打ちをかけているのが分析レベルの違いである。図2にあるようにシステム機能中心で「Vendor選定」を行った場合は、「アクティビィティ」を中心に適合率を見ているケースが多い。一方で、クライアントの業務を中心に「BPR」を行う場合は、「プロセス」を中心に改善提案を行う。例えば、「請求書発行」というアクティビィティがあったとしよう。おそらくこのアクティビィティはどの企業でも存在するアクティビィティであるが、このレベルで適合率を計ってしまった結果、システム導入時に現場から猛反発を食らった経験のある企業も多いはずである。
理由は、「請求書発行のプロセス」が導入されるシステムと適合していないからである。ましてや、改善が文化として根付いている企業にとっては「プロセス重視」の見方を残しておかないとシステム導入どころか、業務改革にすらつながらない。
図3；システムを導入してどんな効果を期待したいのか？
（図をクリックすると大きく表示されます）
システムが全ての諸問題を解決してくれる万能なツールではない。ましてや業務とは人間が作り出すものであるからこそ尚更システムが解決できるはずもない。だからこそ、業務をシステムに置き換える前にBPRが存在しているのである。
弊社では、BPRを実施する際に「現状業務量を正しく把握する」ことに注力を置いております。改善しない方が効果の大きい業務、改善した方が効果の大きい業務、人間から手離れした方が効果の大きい業務、など、現状業務にはさまざまな種類があります。これらの業務を基本機能業務、及び、補助機能業務に分別することによって、システムの費用対効果も算出できます。
図4；BPRでデザインアプローチを実施
（図をクリックすると大きく表示されます）
システム機能中心に「機能整理」を進めた場合、システムを導入することが目的になってしまっているので現状整理された業務をどのようにしてシステム化できるのかを考察してしまう。よって、アドオンを検討しなければならなくなる。しかし、業務改善を中心に「BPR」を進めた場合、本来システムに期待したい現状を定量的に理解できるので、システム導入の効果も見積もれることになる。
業務改善を中心に「BPR」を進める場合は、まずはデザインアプローチという考え方で短期間で飛躍的な生産性を向上させます。
提案
原因と結果は関連しています。システム導入における失敗の原因をマネジメント・コンサルティングの視点から指摘するならば、その原因は「RFP」と理解しております。図2にあるように、RFPを作成する情報システム部門は「アクティビィティ」レベルで思考し、それを受けたIT vendorも「アクティビィティ」レベルで回答する。しかし、実際にIT導入のプロジェクトが始まった場合、情報システム部門は現場からの声に合わすかのように「プロセス」レベルで思考を始めてしまう。
ITコンサルティング・ファームとしては「アクティビィティ」レベルでの適合率を元に話を進めているので話は合わなくなる。そして、アドオンの話に突入する。しかし、予算がオーバーするならばアドオンは中止せざるをえない。結果、これらのプロジェクトは頓挫したりもしくは力作業一辺倒に陥ってしまうことになる。この時点で要件定義を再実施しても全く効果はない。
図5；マネジメント・コンサルティング・ファームによるシステム導入の進め方
（図をクリックすると大きく表示されます）
弊社では、デザインアプローチというユニークな考え方を使って事前にBPR（業務改革）を実施しマネジメント・コンサルティング・フェーズで一つの効果を出します。次に、本来システムに期待したい内容を定量的に見積もります。
実施事例（一部）
-
製造業S社；売上規模⇒800億
ERP刷新の時期が近づいてきている中で、この刷新作業にシフトしていいのか？ という関心と過去の導入時の大変な御苦労からITとは異なる視点が必要と認識され、業務改革ツールであるマネジメント・ツール、特に、測定技術に関心を持ちBPRを実施。プロジェクトリーダーは、情報システム部門責任者。プロジェクトオーナーは、CIO。
-
製造業N社；売上規模⇒70億
過去のERP導入プロジェクトが難航した経験をお持ちで、その時の苦い経験から導入時におけるIT関係者によるBPRに疑問を持たれた。しかし、時期が来れば刷新はしなければならないのでその時までに今一度BPRを正しく実施し、業務の効率性を定量的に把握しておきたいということで刷新時期に余裕を持ってBPRを実施。プロジェクトリーダーは、情報システム部門責任者。プロジェクトオーナーは、CEO。
参考書籍
「戦略的営業利益向上マネジメント」に関しては、ここをクリック（アマゾン）してください。