第1章から第8章までの学習を通して、様々なワークフローアプリを作成できるようになりました。
第9章では、実際の業務を想定し、業務をワークフローアプリとして実装することに挑戦しましょう。今までの章で学んだことを振り返りながら進めます。
実際の業務を想定する
営業担当が受注しようとしている案件を、上司である営業部長に報告し、承認を得るワークフローアプリ「受注承認」を作成します。「受注承認」では、新規の発注元の場合には受注して問題がない会社かどうかを管理部に確認することにします。
ワークフローアプリにするのは、具体的には次のような業務です。
営業担当のオアフは、新しい案件を受注したので、 Questetra にデータを登録し、上司である営業部長のスマトラに登録した内容で受注してよいか確認を依頼します。
スマトラは、登録された内容を確認し、次のいずれかを行います。
- 受注内容に問題がない場合、発注元が既存の取引先もしくは管理部によって問題ないことが確認済みであれば、そのまま承認する
- 受注内容に問題がなくても、新規の発注元の場合は、発注元が問題ないかを管理部に確認する
- 登録内容に問題があっても軽微な修正で済む場合は、登録内容を修正するよう申請をオアフに差し戻す
- 問題が重大で解決が難しい場合は、案件の受注を却下する
スマトラから案件を差し戻されたオアフは、データを修正し、スマトラに再度確認を依頼します。
管理部所属の社員であるカナリアは、スマトラからの依頼を受けて発注元情報を確認します。問題がなければその旨を、問題があれば具体的な問題点をスマトラに報告します。
スマトラの承認後、案件の受注金額が100万円より少なければ、この時点でこの案件についての業務は完了します。もし受注金額が100万円以上であれば、社長にメールで連絡して業務が完了します。
文章だと中々理解しづらいですね。また現実には、ワークフローを定義する際になって、初めて必要な処理に気づくこともあるかと思います。実際にワークフローアプリを作成する際は、ノーコードでアプリを作成できる Questetra の特長を活かして、モデラでワークフロー図を編集し、意見を貰いながら行う方がよいでしょう。
ここでは、トレーニングとして上の文章の内容を基にアプリ「受注承認」を設計してみてください。
ワークフローアプリ設計のポイント
ワークフローアプリを設計する前に、ポイントをおさらいしましょう。ワークフローアプリを作成するには、次の3つを定義する必要がありました。
- どのように業務を進めるのか（ワークフロー図）
- 誰が各工程の処理を担当するか（処理担当者）
- どのようなデータを取り扱うか（データ項目）
どのように業務を進めるのか
アプリを作成する際には、処理するタスクの種類とそれらの処理順序を決め、設定する必要があります。設定するには、タスクやプロセス処理の種類に応じたアイコンを配置し、アイコンをフローによって繋いで処理順序を示したワークフロー図を作成します。
誰が各工程の処理を担当するか
業務を遂行するためにどのようなタスクが必要かを明らかにしたら、関連するタスクのグループ毎に処理を担当するユーザを設定します。これはスイムレーンの処理担当者で設定するのでしたね。
どのようなデータを取り扱うか
ワークフローの中では、様々なデータを受け渡しながら処理していきます。受け渡すデータの種類と名称は、データ項目で設定します。
それでは、それぞれについて考えていきましょう。
ワークフロー図を描く
どのように業務を進めるのか考え、「受注承認」のワークフロー図を作成しましょう。
プロセスはオアフが開始し、受注内容の登録を行います。第4章で学んだように、開始イベントとヒューマンタスクを設置し、フローで接続しましょう。人が作業するタスクは、全てヒューマンタスクで表せます。そして、このタスクを処理したら、次はどのタスクに移行するでしょうか？
スマトラが行うタスクは複雑ですね。判断の選択肢がいくつかあり、選択肢によって次のタスクが異なるようです。ボタンラベルにて次に行われるタスクを選択できることは、第7章で学びました。選択肢が増えても、ボタンラベルを使えば実現できそうです。
他に場合によって処理が異なる部分としては、受注金額が100万円以上なら社長にメールを送る、100万円を下回るなら送らないという処理があります。これは、データ項目の値を条件にして処理経路を切り替えることで実現できそうです。データ項目の値を条件にした処理経路の切り替えも第7章で行いました。
最後に、自動化できそうなところはないか考えてみましょう。社長にメールで報告するタスクは、自動化できそうです。第8章では、ワークフローの途中でメールを自動送信できることを学びました。
作成できたら、設定例で確認してみましょう。
＋ 設定例
登録内容の修正は、案件登録とは別のタスクにしています。これは、マイタスクにて割り当てられているタスクの一覧を見た時に、手を付けていない案件なのか差し戻された案件なのかを判断しやすくするためです。
また、今回は自動処理工程［データ更新］を使っていません。第8章では、送信前にメール本文を確認するため、確認のヒューマンタスクの前に［データ更新］を使って整形文を作成する必要がありました。ここでは確認タスクを入れずにメールを送信するので、［メッセージ送信中間イベント（メール）］の［本文（プレーンテキスト）］で整形文を作成しています。もちろん［データ更新］を使っても問題ありません。
メール送信先の指定方法として、今回は［メッセージ送信中間イベント（メール）］の設定ダイアログで［To］の項目に実際の宛先のメールアドレスを直接入力してください。
［メッセージ送信中間イベント（メール）］の近くに［注釈］を配置しています。処理についての説明やメモを記載でき、ワークフローでどのような処理が行われるかを理解しやすくなります。
処理担当者を設定する
次に、「受注承認」の各工程の処理担当者を設定しましょう。登場人物としては、次の4名が登場しました。
- オアフ（営業担当）
- スマトラ（営業部長）
- カナリア（管理部所属の社員）
- 社長
この中で社長は、100万円以上の案件を受注した際のメールの送信先なので、処理担当者ではなさそうです。その他の、営業担当、営業部長、管理部所属の社員はどのように指定できるでしょうか？ワークフロー図のスイムレーンにて設定しましょう。
オアフ、スマトラ、カナリア、とユーザを直接指定することもできますが、それでは業務が属人化してしまいます。また、メンバーの昇進や異動などにも対応できません。第5章で学んだように［組織］の情報を使って設定してみましょう。
また、［役職］も利用しましょう。第7章でもプロセスを開始したユーザの上司を指定するために［役職］を利用しました。本チュートリアルでは、「リーダ」という［役職］があり、社長、部長など組織の長に付けていました。営業部のリーダである営業部長の指定、もしくは営業部長以外の営業部社員の指定に使えそうです。
設定できたら、例と比較してみましょう。
＋ 設定例
営業担当、営業部長、管理部所属の社員がそれぞれどのように設定できるか見てみましょう。
営業担当
営業部長を除く、営業部に直接所属するユーザを指定しています。
このチュートリアルで想定した組織には営業部の下位組織に所属するメンバが現在いませんが、いる場合は『組織「20 営業部」より下位組織に所属するメンバ（役職なし）』も指定することで、営業部全体の［役職］が設定されていないユーザを指定できます。
なお、開始イベントがあるスイムレーンの処理担当者が、プロセスを開始できるユーザなので、このアプリのプロセスは、営業担当で指定されているユーザになります。
営業部長
営業部長だけを指定すれば良いので、営業部に直接所属している［役職:リーダ」であるユーザを指定しています。
本チュートリアルで設定している［役職］は、「リーダ」だけなので、「（役職あり）」のメンバを指定することでも問題ありません。
管理部所属の社員
管理部長を含む管理部に直接所属する社員を対象にしました。部長を除く場合は、「（役職なし）」を選びます。
現在は、管理部の下位組織に所属するユーザがいませんが、いる場合は、『組織「10 管理部」より下位組織に所属するメンバ』も指定することで、管理部下の全ユーザを指定することになります。
データ項目を設定する
最後は、データ項目の設定です。どんなデータ項目が「受注承認」のワークフローを処理する為に必要になるでしょうか？
まず、受注案件情報として、受注内容と受注金額が必要です。次に、受注予定日や担当する社員も記載するとよさそうです。発注元の情報としては、社名や住所、担当者名、担当者の連絡先（電話番号、メール）などが必要ですし、発注元を照会した後に結果を記載する項目も必要になりそうです。
そして、これらはどのデータ型に格納するのがよいでしょうか？これまでに、文字型、数値型、日付型、日時型、ユーザ型を扱いましたが、どれが適切でしょうか？
また、他にはどのようなデータ項目が必要になりそうでしょうか？
必要なデータ項目を洗い出したら、第6章を思い出しながら、入力フォームのレイアウト設定を行いましょう。各データ項目に対する編集の可否も忘れずに設定しましょう。
設定できたら、例と比較してみましょう。
＋ 設定例
営業担当が入力するデータ項目は、ほぼ必須項目にしています。ただし、「発注元担当者電話番号」は、メールやビデオ通話でのみしかやり取りせず、電話番号がわからないケースを考えて必須にはしていません。必須にしたデータ項目は、「編集可」に設定されたタスクにおいて、入力しないとタスクの処理を完了できません。そのため、入力しない可能性のあるデータ項目は、必須にしないようにしてください。
備考欄は、掲示板型データ項目で作成しています。掲示板型では、文章を入力すると、入力者・入力日時と共に文章が追記されます。そして、追記された文章は、変更できません。そのため、案件に関係するメンバ間のやり取りを記録する用途に利用できます。
各データ項目に対する編集の可否は、次のように設定しました。
| 受注案件登録 | 受注内容確認 | 登録内容修正 | 新規発注元照会 | |
|---|---|---|---|---|
| 受注内容 |  （編集可） |  （表示） | （編集可） | （表示） |
| 受注金額 | （編集可） | （表示） | （編集可） | （表示） |
| 受注予定日 | （編集可） | （表示） | （編集可） | （表示） |
| 担当営業 | （編集可） | （表示） | （編集可） | （表示） |
| 発注元社名 | （編集可） | （表示） | （編集可） | （表示） |
| 発注元住所 | （編集可） | （表示） | （編集可） | （表示） |
| 発注元担当者氏名 | （編集可） | （表示） | （編集可） | （表示） |
| 発注元担当者メールアドレス | （編集可） | （表示） | （編集可） | （表示） |
| 発注元担当者電話番号 | （編集可） | （表示） | （編集可） | （表示） |
| 発注元照会結果 |  （非表示） | （表示） | （表示） | （編集可） |
| 備考 | （編集可） | （編集可） | （編集可） | （編集可） |
入力内容の確認の際に間違えて変更してしまうことを防ぐために、入力・編集する必要があるユーザ以外は表示に留めています。
受注案件登録のタスクでの入力フォームは、次のようになります。
「発注元照会結果」は、「受注案件登録」のタスクでは入力したり参照したりすることはないので、非表示にしています。
想定した業務に沿うように、ワークフロー図、処理担当者、データ項目を設定できたでしょうか？
ここまでできれば、後は実際にワークフローアプリを作って修正することの繰り返しです。例えば、「受注承認」アプリで営業部長もプロセスを開始したいならば、スイムレーン「営業担当」の処理担当者設定において、『組織「20 営業部」より下位組織に所属するメンバ（役職なし）』となっているところを、［役職］は空欄として指定すれば、営業部長もプロセスを開始できるようになります。
色々なアプリを作り、業務や組織の状況に合わせて改良していってください。ここまでできれば、後は実際にワークフローアプリを作って修正することの繰り返しです。色々なアプリをご自身で作ってみてください。
以上でチュートリアルは終了です。お疲れさまでした。
Questetra BPM Suite の基本操作や機能を紹介しましたが、いかがでしたか？ Questetra BPM Suite を活用して、日々の業務プロセスの自動化や見える化にチャレンジしましょう！
次のページでは、Questetra をさらに便利に使える機能など、ワークフローアプリの作成や改善、運用に役立つ情報を付録として紹介していますので、興味のある方はぜひご覧ください。