---

ビジネスエンジニアとは、経営戦略のもとに工学的なアプローチでビジネスの改革や再構築を推進するエンジニアです。
ビジネスエンジニアは、経営者を補佐し、ビジネスの運営や情報システムの変革をリードする者、或いは経営者に対して、現場のプロセスや情報システムの改善を提言していく者ということもできます。

特に近年は、スマートフォンやタブレット、クラウド、AI、ロボティクス、IoTといった技術の急速な進展に伴って、技術の活用が企業の競争力や生き残りを決定付ける大きな要因となっています。このような環境下、経営者の多くは、システム部門に対し、ITを活用したビジネスの革新を期待する一方で、システム部門は既存システムの保守で手一杯という現状があります。このようなギャップを埋めていくのが、ビジネスエンジニアの役割ということもできるでしょう。

経営課題を理解し、同時に技術を知り、これらをもとに企業活動のイノベーションを主導できるビジネスエンジニアは、今後更にその重要性を増していくものと考えられます。
それでは、このようなビジネスエンジニアの活動を支えるビジネスエンジニアリング・ツールとはどのようなものでしょうか。ここではビジネスエンジニア、及びビジネスエンジニアリング・ツールが備えるべき要件を整理してみましょう。

---

 

●俯瞰性とドリルダウン

ビジネスの変革をはかる場合、現場のきめ細かい業務プロセスの見直しもさることながら、より本質的な改革を行う場合は、俯瞰的な視点、すなわち経営者の視点が必要になります。この俯瞰的な視点がないとビジネスの改革も小手先だけのものに終始していまいます。
従って、ビジネスエンジニアの活動を支えるビジネスエンジニアリング・ツールも、具体的な現場のプロセスをきめ細かく表現すると共に、企業、又は企業グループ全体を表現できるということが重要になります。
また、ビジネスエンジニアリング・ツールには、これらの「全体」と「ディテール」を相互に、自由に行き来するドリルダウンとドリルアップの機能が求められると同時に、その両者を同じ表記法で表現するシームレス性が欠かせない要件となります。

●ビジネスパーソンにとっての分かりやすさ

システムエンジニアが相手にするものは、主に情報システムそのものです。ここでは、論理的な緻密さや完全性が求められ、ここで使用されるツールや表記法も、UMLやER図など、システムエンジニアリング固有のものが使用されます。このような表記法は、固有の記号や概念などを伴うため、多くの場合、一般のビジネスパーソンには理解できません。
一方で、ビジネスエンジニアが直接的に相手にするのは、経営者や現場のビジネスに従事する人々です。このような人々に、その見方を都度説明しなくてはいけないような専門的なダイアグラムは使用できません。そのダイアグラムが意味するところを初見で理解できるようなフレンドリネスが不可欠です。
また、このような誰もがひと目で理解できるようなダイアグラムは、現場や経営者の中で継続的に活用できることも意味しており、「プロジェクト終了後はキャビネットにしまいこまれて忘れ去られる」ような状況を防ぐこともできます。

●シミュレーション

新しい業務プロセスを設計する際は、システム化・自動化、統合・集約、アウトソーシング／インソーシングなど様々な選択肢の中から、最も効果の高い方式を取捨選択しながら、決定していくことになります。
このようにして業務プロセスを変革する場合、改革の効果がどれだけのものになるかは事前に算定されなければなりません。この評価は、通常コストと時間の２つの観点から評価されます。
局所的な変更であれば、表計算ソフトなどでも計算できますが、複雑な分岐を伴う場合や、大規模、且つ複数個所の変更が連鎖する大規模な変更の場合は、専用のシミュレーションツールが欠かせないものになります。
このようなツールによる計算は、単にプロセス全体のコストや時間の計算だけでなく、顧客へのレスポンス時間の改善度合いや、ボトルネックとなる箇所の検出、プロセス設計を変更した場合のリアルタイムの再計算など、プロセス設計作業の効率化・高度化のために欠かせないものとなります。

●モニタリング

新しいプロセスを現実の業務に適用したとしても、これで終わりではありません。所定の効果が出ているかを継続的にチェックしていく必要があります。また、もしここで計画通りの効果が出ていない場合は、問題点を抽出して更なる改善策を適用していく必要があります。
このようなモニタリングの重要性は、更改直後のプロセスに限った話ではありません。所要コストやトータル所要時間、顧客へのレスポンス時間なども含め、企業内の重要なプロセスについて、所定の目標値に対してどのような状況になっているかを常にモニタリングしていけば、企業競争力の維持向上の上で極めて重要な取組となります。尚、この際ベンチマークとする指標は、プロセス設計に際して算定した設計値や経営目標値の場合もありますし、例えばライバル企業の値などを指標として設定し管理する方策なども有効です。
このモニタリングは、プロセス単位で行う場合以外に、各組織単位で行う場合もあります。プロセス単位のモニタリングは主にコストや所要時間が主な評価項目になりますが、組織ベースのモニタリングの場合は、売上、人員、コストなどが評価項目になります。
このようなモニタリング結果は、経営幹部が直接、リアルタイムで参照できる状態にしておくことも重要です。このように、経営の状況がリアルタイムで把握できる環境は、正確でスピーディな経営判断を可能にし、またこのような環境を構築し、提供することがビジネスエンジニアの役目ということもできます。

 

●多角的なビジネス表現

ビジネスを改革する目的は、業務の効率化やコストの削減だけではありません。新商品の開発、顧客満足度の向上、売上・利益の向上、新たな対顧客チャネルの構築、企業グループの再編、ビジネスリスクの低減など、ビジネス改革の目的は多岐に渡ります。
従って、このような目的の達成を支援するビジネスエンジニアは、売上、商品体系、顧客セグメント、ビジネスリスクなど、ビジネスを取り巻く様々な要素について検討を加え、実行プランを策定しなければなりません。
このようなビジネスの変革を検討し、これを表現するツールとして、例えばフローチャートでは不十分です。フローチャートは、処理の手順や、その手順を実行する部署については表記できますが、これはビジネスの一断面にすぎません。
ビジネスエンジニアの活動を支えるビジネスエンジニアリング・ツールは、「誰が」「いつ」「何を」「どのように」「どれだけの売上・収益を」「どれだけのコストで」「どのようなリスクを伴って」など、その5W2H＋αを可能な限り幅広く表現することが求められます。
この場合、ビジネスにおける5W2H＋αとは以下の表にあるようなものです。

 

視点	ビジネス表現上のキーワードの例
WHAT（何を）	商品・製品、サービス、部品、原材料、各種の対象物・モノ、データ、概念
WHY（なぜ）	作業の目的、事業戦略、経営戦略、経営理念
WHEN（いつ）	計画、スケジュール、開始時間・開始タイミング、終了期限・時限
WHO（誰が）	組織、職位、顧客、仕入先、外部関係者、情報システム、ロボット、自動化機器
WHERE（どこで）	（組織、拠点、地域、販売チャネル、店舗）
HOW（どのように）	処理手順、処理プロセス、遂行手段、販売チャネル
HOW MUCH（いくらで）	売上、利益、コスト、所要時間、人員数
その他（＋α）	ビジネスリスク　など

 

●ビジネスエンジニアリング・ツールのその他の要件

ビジネスエンジニアリング・ツールが具備すべき、その他の要件をみてみましょう。

・システム開発との親和性

近時、ビジネス改革を行う際、そこに情報システムが介在しない場合は皆無と言ってよいでしょう。新商品を開発する場合でも、新たな顧客チャネルを構築する場合でも、その実行や運営管理には何らかの形で情報システムの開発・改修が必要になります。従って、ビジネスエンジニアが策定した実行プランを表現するビジネスエンジニアリング・ツールの成果物は、大きな再構成や再解釈を経ることなく、可能な限りスムースにシステム開発工程に継承されることが望ましいということになります

。

・チーム・コラボレイト

ビジネスの改革する実行プランは、一人の者が全てを策定するのは困難であり、通常、チームでプランを策定することになります。従って、ビジネスエンジニアリング・ツールは、複数の検討メンバーの作業成果を統合するためのチーム・コラボレイト支援機能をもつことが望まれます。