手動受付と自動受付でプロセスは開始します。社員の誰か(誰でも申請できるようになっています)が、手動でプロセスを開始し無料体験版希望者の情報を入力(1. 申込情報入力)する場合と、体験版の希望者がWebフォームへ入力することでプロセスが自動起動する場合があります。
申し込みが行われると、テスト実行かどうかが自動確認され、テスト実行である場合には、情報システム部の担当者に受付データの内容が確認表示され(0. テスト入力の確認)実際の登録作業は行われずにプロセスは終了します。
テスト実行かどうかの判定条件は、自由に設定できます。例えば『申込者氏名』の文字列が「test」で開始される場合はテスト実行と判断する、というように設定できます。
テスト受付ではない場合は、関係者に受付があったことが通知されます。その後、アカウントの自動発行処理が行われます。アカウントの自動発行は、アカウント発行プロセスを「メッセージ送信中間イベント(HTTP)」で呼び出し、アカウント発行結果を「メッセージ受信中間イベント(HTTP)」で受け取ることとしています。
その後に問題のないアカウント発行であるかどうか、情報システム部の担当者が確認をします(3. アカウント発行の検証)。入力に間違いがあるなど自動発行に失敗した場合は、情報システム部の担当者が申請内容を自分で確認して処理します(2. 手動アカウント発行)。
アカウント発行後、見込顧客となるものかどうかの自動判断が行われた後、セールス担当者による営業活動に引き継がれます(4. 引合情報確認、および 5. 電話営業結果入力)。
以上のプロセスフローでは、「無料体験版の申し込みデータをシステムがきちんと受け取っているか」を「情報システム部」がテスト実行できるようになっていました。
次は、「無料体験版の申し込みデータからの『自動アカウント発行処理』がきちんと動作しているか」を「一般社員」がテスト実行できるようにします。
今度は申し込みが行われた段階ではテスト実行かどうかの判断は行われず、そのままアカウントの自動発行処理が実施されます。アカウントの自動発行処理が完了後(3. アカウント発行の検証)、テスト実行かどうかの判断が行われます。
自動実行の場合は社員に自動発行の結果が通知され(0. テスト入力の確認)、システムの動作が確認できるようになっています。
実際の業務実行だけでなく、様々な理由で動作確認のために実行が必要になることがあります。例えば、Webの申し込みフォームがきちんと動作していてBPMに申込情報が受け渡されているのかどうか、申込フォームからテスト申込みをしたい場合があります。
しかし、BPMは業務を自動化することで効率化しますが、自動化されているためにテスト実行が難しくなってしまう場合があります。例えば、テスト申込みをするたびに申込が自動処理されてしまって体験版が郵送されてくるようでは困ります。
そこで、入力されたデータが特定の条件を満たす場合はテスト実行と判断し、プロセスを途中で中断させる仕組みをプロセスフローの要所に設けておくことで、業務の自動化による効率化とテスト実行による動作確認の安心を両立させることができます。
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License
本記事のサンプルは ワークフローサンプル様の
「自動処理のテスト」を想定した体験版受付フロー を元にしております。
ダウンロード&インポートで、記事で紹介したプロセスフローをすぐに利用できます。
業務プロセスのモデル化から業務の進捗、処理状況、ボトルネックまでPDCAに必要な要素をすべて「見える化」ビジネスプロセスの最適解を導く
お気軽に製品の機能を体験いただける「DataSpider BPM」の無償評価版をご用意。
評価版のご案内