なぜ今、BPMなのか？

企業における「記録」ニーズ

「いつ」「誰が」「何を」行ったのか？
それらを記録に残すことは、企業にとって非常に重要です。

• 成果を計測 （目標管理、人事考課）
• 知識を共有 （ナレッジマネジメント、コンピテンシー）
• 業務を改善 （生産性向上、リスクマネジメント、ビジネスコンティニュイティ）

業務の記録ニーズは今に始まった企業要望ではありません。この10年…、いやこの100年を振り返ってみたとしても、「記録コスト」と「記録の価値」の均衡の上に、その適量記録を模索し続けてきた、と言った方が良いかもしれません。

しかし今日、

1. 『スマートフォン』に象徴される情報端末の技術革新
2. 『内部統制』に象徴される可視化ニーズの高揚

の大きく２つの観点から、「更に業務履歴を詳細に記録する」と言うニーズが高まっていると言えるでしょう。

今や「GPS情報」ですら簡単に記録

スマートフォン端末、タブレット端末、ノートパソコン端末・・・、今や一人で複数の情報端末を使う事も珍しくありません。

特にAndroid機やiPhone等のスマートフォン端末は、情報の表示だけでなく、「静止画」や「動画」あるいは「位置情報(GPS)」の記録端末としても、極めて実用性が高い情報端末であると言えます。

企業における情報セキュリティ・ポリシーも、単に「情報端末の社外持ち出し禁止」と言う従来型の伝統的なポリシーだけでは、もはや現実的とは言えません。つまり「社外からのシステム利用」や「私用端末の業務利用」についても、何らかのポリシーの元で利用せざるを得ない状況にあると言えます。

ますます重要視される「コンプライアンス」

一方で、内部統制の流れ(Sox法)や個人情報保護の流れを受け、より精度の高い、より信頼性の高い「証跡記録」が求められています。

紙による業務処理（いわゆる「押印フロー」）では、処理が集中する決裁工程などで、経路ミスや書類紛失が発生してしまうものです。また現実的な話として紙の稟議書類を使っていると、社内規程を守るために「過去日付」を記入してしまうものです。

例：

• 購買の判断：　誰が起案し、誰がいつ決裁したのか？
• クレーム回答：　誰が一次対応し、誰が二次対応し、いつクローズしたのか？
• ＩＲ文書の提出：　誰が作文し、誰と誰がチェックし、誰がいつ最終提出したのか？
• 契約文書の法務確認：　誰が内容確認し、誰がどの様な交渉を行い、誰がいつ最終承認したのか？

「社内での出来事」は正確に、そして自動的に、すなわちコンピュータによって記録されるべきです。言い換えれば、「改ざんや日付詐称が簡単に出来てしまう環境」とは決別すべきだと言えます。

「正確な業務データ」は「業務プロセスの管理」から

• a.記録できる業務データ
• b.記録すべき業務データ
• c.記録しなければならない業務データ

業務記録の種類には様々なものがあります。では企業はどの様な視点で情報システムを設計すれば良いのでしょうか。

1. 『最終的に記録されるべきデータ項目』の設計に注力した情報システム
2. 『業務プロセスの手順(フロー)とその担当者』の設計に注力した情報システム

両者を比較すると 2. の方が圧倒的に面倒です。例えば、最終的に「議案の決定内容」だけが記録されればよいのではなく、「起案者が誰で、途中承認日時はいつなのか」等も記録される必要があります。例えば、最終的に「クレーム内容とその回答文」が保存されれば良いのではなく、「誰が一次回答をし、どこで滞留していたのか」も記録される必要があります。

Questetraは、業務プロセスを管理し続ける事を提案します。

確かに、社内の業務プロセスを管理する事は容易ではありません。
特に、はじめてBPMに取り組む時には、（１）現状の業務の流れを検証し、（２）あるべき業務の流れ図（ワークフロー図）を描き、（３）各工程の処理担当（割当ルール）を決め、（４）各工程の入出力を考え、（５）一人ひとりの処理が記録されるようになるには、相応の手間が存在します。

しかし中期的視点に立てば、これらのビジネスプロセスやビジネスルールの整備こそが、大きな改善につながる活動です。あえて比喩的に言えば

• 「道路」を「整備」してこそ、スムーズな交通が実現できます
• 「流量」を「監視」してこそ、道路網の改善プランが計画できます

社内の業務を既定の業務フローの上に流し、自動記録する事ではじめて、「カイゼン」する事ができるのです。業務プロセス自体を「競争力」の源泉に昇華させることが可能になると言っても過言ではありません。
（参考掲載：　2008年創業時に配布した事業計画書〔全４８ページ〕の序文）

BPMが注目される、その他の理由

テクノロジー革新

従来、業務プロセスの変化にあわせて情報システムを改変するには、システムエンジニアによるプログラミング工数がかかっていました。しかし、Drag＆Dropで業務システムの仕様変更が可能な「MDAテクノロジー」は、システム改変にプログラミング知識を必要としません。すなわち社内にて、あるいは現場責任者自身で、自律的に業務システムを“カイゼン”する事が可能になったと言えます。 ※ Model Driven Architecture

ノーツ移行ニーズ

今日、社内でのシステム運用（オンプレミス／保守ライセンス形態）が標準的であった時代から、クラウドを活用した情報システムが当然と考えるパラダイムシフトが起きつつあります。中でも Lotus Notes に代表されるような、「多機能ながらカスタマイズや運用コストが大きなコスト負担になりがちなワークフローの仕組み」は、より手軽に運用できるシステムに移行していくと言えます。業務フローの改変に対するコスト負担が極めて小さいBPMツールは代替ツールとして期待されます。

DBのフロントエンド・ニーズ

広く社内の情報を吸い上げるBPMツールは、「ERPやDBMSに格納すべき情報」も包含的に収集します。ERPやDBMSの入力更新インターフェースを個別に開発するのではなく、BPMが収集した業務データのうち必要な情報をERPやDBMSが取得する仕組みにすることで、より正確で信頼性の高いデータを格納できる様になります。また業務フロー変更の際にもERPやDBMSへの影響を最小限にとどめる事ができるため、情報システム改変コストの低減や情報システム運用の内製化を実現できます。