BPMの改善ステップの文言変更とステップ６について

　前回のコラムの予告通り、今回は「BPMN図以外にBPMSを導入するときに必要な情報」ということを述べてみたいと思います。
前回、お知らせしましたBPMのマンガの中にもありますが「BPMN図を描いたらBPMSでアプリケーションシステムができる」という説明を２０００年代後半のベンダーの説明を聞き「どこにデータの情報があるのか？」などと疑問を持ちました。当時BPMはバズワードだと言われた原因になったと思います。　　

　BPMNが制定される目標が「簡単なフローチャートを描くことによって、あまり技術的でない人たちがトランザクション型のアプリケーションを構築できるようになる。」（「あなたが描いているのはBPMN図ではありません」参照）ということ、まだBPMが手法としては成熟していないとしても乱暴な説明をしていたと思います。
　前々回のコラム（ＢＰＭの理解を阻害する業務フローとシステムに関する固定概念）に書いた「BPMの改善ステップ」のステップ５の「プロトタイプ」という文言を修正することも合わせて述べたいと思います。

１．BPMの改善ステップとステップ５の文言修正について

　BPMの改善ステップのステップ５「プロトタイプ」「プロトタイピング」という言葉に違和感があり修正をしたいと考えていました。ステップ５で出来上がるアプリケーションシステムはプロトタイプでは無いからです。書籍も、動画も画像もすべてこの文言になっており、今年から来年にかけて動画と画像は修正をしたいと考えています。（書籍も、間違った表現が他にもあり来年度中には改版をしたいと思います。）

以下の内容に変更をしようと考えています。

　ステップ５はBPMSの基本機能を使った「業務の標準化改善」を行います。業務マニュアルが動きBPMSの基本機能で「業務を間違わずに確実にできる」ようにするためのノンプログラミングの自動化も含まれます。ステップ６の自動化開発を行わなくても、ステップ５までで大きな業務の改善が実現し稼働することができます。以前からお伝えしているようにBPMの本丸はステップ５までであり、ここまでは「システム開発」として位置付けてはいけません。実務者が主体的に行うBPMNとBPMSを使った業務の標準化改善（業務プロセス改善）となります。
　またステップ５までは、基幹システムの要件定義工程に置き換えることができます（本件は「BPM入門　基礎知識＋事例セミナー」でお話しをしています）。

２．ステップ５のためのステップ４のデータ情報

　「プロセスデータ関連表」が必要になります。プロセスデータ関連表を熟考しておくとステップ５の基本部分は機械的な作業で設定することができます。
①BPMN図の「ユーザータスク」がBPMSの画面と一致していること（一致しているように描く方法はBPM入門セミナー、レベル１セミナーでお伝えしています。）
②その画面に、何のデータを表示、入力させたいかを明らかにする。（具体的にはレベル２セミナーでお伝えしています。）
③一つ一つのユーザータスク（画面）で②を実施するとプロセス全体で使うデータが洗い出せます。
それらをまとめたものがプロセスデータ関連表となります。
プロセスデータ関連表をどのように使い、実務者でもBPMSが設定できることを知るにもレベル２セミナーを受講していただければと思います。
このページで全てをお伝えすることはできないです。

３．ステップ６のための情報

　ステップ６は従来でいう「システム開発」でありBPMSのローコード開発機能を使って「作業の自動化」を実現する部分になります。先に述べたようにステップ５までは「システム開発」ではないので、各社が有している「システム開発標準」の対象外にすべきです。
しかしながら（こちらもBPM入門セミナーの事例で具体的に説明してますが）ステップ６(システム開発）はプロセスデータ関連表だけでは情報が不足し「ロジック調査表」「プロセス間連携表」が必要となる場合があります。
　
　ステップ６からは一般的なシステム開発の管理を行っても良いのですがドキュメント類を減らすためにBPMのための開発標準が必要です。BPMN図とプロセスデータ関連表と、それらを元にステップ５でBPMSに設定されたプロセスアプリケーションで、多くの開発ドキュメントを省くことができるからです。各社が有している「システム開発標準」にBPMのステップ６を実施するには、何が省略できるか、何を代替資料にできるかを明記する必要があります。（「ＢＰＭ「体制」「しくみ」の重要性:PMBOKの壁？」参照）
　それはビジネスアジリティを向上させるためです。一般的なシステムはBPRであるためにシステムができたときが改善終了です。BPMは、PDCAサイクルを回し組織の内外の環境の変化（業務課題解決も含む）に素早く対応できる能力（ビジネスアジリティ）を向上させることが目的です。従来のシステム開発標準に則ってドキュメントを作成しレビューなどを行っているとビジネスアジリティを向上させることができないからです。
　ここは今後「BPM研究会（仮称）」で、広く参加者を集めて議論し結果を発表していきたいと思います。参加者基準（基本無償です、なるべく門戸は開きたいと思います。）を設けた後に募集していきたいと思います。

４．まとめ　

　BPMの改善ステップ５と６の間には線引きが必要であること、ステップ５で必要な情報とステップ６を実施するにはステップ５までの情報だけでは不足することがあることを述べました。実施者で言うとステップ５までは実務者が主体で行い、ステップ６はIT担当者が担当すると考えて良いでしょう。
　BPMSによってもステップ５と６の間には差が発生します。どれだけノンプログラミング（ノーコードという言葉はローコードと聞き間違えるので使わないです。）で実装できるかに差があるからです。顧客（実務者）の声を聴いて進化させているBPMSと、そうでないBPMSでは差が出ていると感じます。声を聴いて進化させないのは「システム開発」をする部分を沢山残し、開発コストを増やしお金儲けをしたい。という意思なのかと捉えてしまうのは私だけでしょうか。もうそういう時代は終わるのではないか、終わって欲しいと思います。
　次回は・「BPMSでできることと、できないこと（実施すべきでないこと）」とBPMNの関係について
　または・SFAやCRMなどで実施できるというプロセス管理とBPMにおけるプロセス管理の違い
　について述べてみたいと思います。　　　

関連ページ