Embed Size (px)
Citation preview
1Copyright © Questetra,Inc. All right Reserved.
Questetra ハンズオンセミナービギナー向け業務プロセス設計その２
Wifiに接続し、今日利用する Questetra BPM Suite にログインできることを確認してください。
SSID／パスワード ホワイトボードに記載
アジェンダ
• その１のおさらい
• 処理担当者の設定で、組織を活用する
• 処理担当者で、上司を設定する
• 通知について
その１のおさらい 1/2
プロセスモデル
• 組織が特定の業務を遂行する上において、守るべきルール
• 「業務ルール」「規定」など
プロセス
• プロセスモデルに従って実際に行われる、特定の一連業務
• 特定の「稟議」「申請」「案件」「問い合わせ対応」など
従うべきルール
ルールにそって動く実際の業務
その１のおさらい 2/2
プロセスモデルの３要素
• プロセス図（業務フロー図）– 工程、および工程の前後関係
• データ項目（タスク処理画面）– 取り扱うデータ– タスク処理画面（入力画面）
• 処理担当者– 誰が各タスクを処理するか
処理担当者の設定で、組織を活用する
ユーザと組織・ロール
• Questetraには「ユーザ」「組織」「ロール」の概念– 組織とロールは、複数のユーザをグループ化するためのもの– 組織とロールは、プロセスモデルの担当者設定で使用する
• 組織はツリー構造で、ルートは１つ– 企業の組織構造を、そのまま反映させる前提
• ロールはツリー構造を持たない– 企業の組織とは異なった、グループを作るためのもの– 例えば組織横断的なグループなど、組織を補助する目的
• 全ユーザは、いずれかの組織に所属しなければならない– 所属しなければ、ワークフローの各機能が使用できない
• 組織への所属に際して、「リーダ」「メンバ」の属性がある– 「リーダ」「メンバ」の属性も、プロセスモデルの「担当者設定」で使用
全社
開発部 営業部
営業1課
営業2課
管理部
ユーザと組織
• https://seminaｒ-ja.questetra.net
• ユーザ名とパスワードはhttp://www.questetra.com/ja/trial/
• 所属は次の通り
• １人目がリーダ
• 全社
– SouthPole
• 営業部
– Hawaii
• 営業1課
– Galapagos
– Oahu
• 営業2課
– Solomon
– Midway
• 管理部
– Sumatera
– Maldives
• 開発部
– Canarias
– SaintHelena
全社
開発部 営業部
営業1課
営業2課
管理部
処理担当者の設定で、組織を活用する
プロセスモデルを新規作成し、以下のプロセス図にしてください
• タスクやスイムレーンの名称変更を忘れずに
担当者設定で、”担当者2” のスイムレーンの設定を以下の通りに
処理担当者の設定で、組織を活用する
担当者設定で、”担当者1” のスイムレーンの設定を以下の通りに
処理担当者の設定で、組織を活用する
保存後、「開発中のバージョン○のリリース」をし、SouthPole および Hawaii で
プロセスを開始できるかどうか確認してください
処理担当者の設定で、組織を活用する
• 「組織：全社に直接所属している人」は「全社」組織に所属しているユーザ“のみ”が対象
• 「組織：全社より下位組織に所属している人」は「開発部」「営業部」「管理部」…に所属しているユーザが対象
– 「全社」は除かれる
• この２つを組み合わせると、全ユーザが対象になる
全社
開発部 営業部
営業1課
営業2課
管理部
処理担当者の設定で、組織を活用する
• 開始イベントのあるスイムレーンでは、担当者設定の意味が異なる
• 「該当業務のプロセスを開始できるのは誰か」という意味に
• それ以外のスイムレーンでは、「そのスイムレーンで発生した仕事を処理できるのは誰か」
• 「営業部」「開発部」に所属しているユーザは、プロセスを開始できる
• 「管理部」に所属しているユーザは、プロセスを開始できない
• 「確認」の仕事は来る
処理担当者の設定で、組織を活用する
先ほど作成したプロセスモデルの編集画面に移動
① ②
③
担当者設定で、”担当者1” のスイムレーンの設定を以下の通りに
処理担当者の設定で、組織を活用する
保存後、「開発中のバージョン○のリリース」をし、SouthPoleもプロセスを開始できることを確認してください
処理担当者の設定で、組織を活用する
• 設定に該当するユーザが１人しかいない場合
• 仕事は、自動的にそのユーザのものとなる
• 設定に該当するユーザが２人以上いる場合
• 仕事は「誰かが引き受けてくれるのを待つ」（引き受け待ち）状態に– 対象ユーザに依頼メール
• 仕事は、引き受けたユーザのものとなる
いずれにせよ、管理部ユーザの仕事になる
少し脱線 「開始したプロセス」を見る
• 「開始したプロセス」か「処理したタスク」
• タスクとプロセスの違いは工程のレベルで見るか、全体で見るかの違い
• プロセス（インスタンス）には、「工程名」や「締め切り」の属性はない
• 「マイタスク」「引き受け待ち」は、「工程のレベル」で見ている。「全体のレベル」で見ていない。
処理担当者で、上司を設定する
担当者設定の種類
• 組織で指定
– 〇〇に直接所属する人／のリーダ
– 〇〇の下位組織に所属する人／のリーダ
• ユーザで指定
• プロセスデータで指定
– 組織型やユーザ型データで指定されたユーザ／組織
• スイムレーンを用いた相対的な指定
– スイムレーン〇〇のタスクを処理した人より上位組織の人など
• ロールで指定– ロール〇〇に所属する人
課題
次のような、簡単な有給休暇の申請業務を、クエステトラ上に実装してください
申請内容は
• 申請者（代理申請はＮＧ）
• 有給休暇の日付（１日のみでも、複数日指定できても、どちらでもＯＫ）
• 理由
必ず、上司の承認が必要
最後は、帳簿に記録するため、管理部が確認する
つまり「申請」「上司の承認」「管理部の確認」の3ステップ
上司や管理部による差し戻しは、ないものとする
申請日が会社の休業日とか、有給休暇の残日数が足りないとか、細かい点は省略
「上司の承認」の処理担当者の設定がポイント
「上司の承認」の処理担当者設定
以下、３つの方法、それぞれで試してみます
• プロセスデータで指定
– 組織型やユーザ型データで指定されたユーザ／組織
• スイムレーンを用いた相対的な指定
– スイムレーン〇〇のタスクを処理した人より上位組織の人など
• ロールで指定– ロール〇〇に所属する人
1. 「上司」に相当するユーザ型データ項目を追加
2. 担当者設定で追加したデータ項目を指定
3. 「申請」時に、申請者に「上司」を入力してもらう形に
「上司」をプロセスデータで指定 1/2
「上司の承認」は、データで指定したユーザに割りあたることを確認してください
「上司」をプロセスデータで指定 2/2
○• 解りやすい
• あらゆる場合に対応できる
ו 厳格にルールを適応できない
– 間違った「承認者」を指定することも可能
「上司」を「申請者」からの相対的な指定で 1/4
先ほど作成したプロセスモデルの編集画面に移動
① ②
③
「上司」の処理担当者の設定を
「スイムレーン：『申請者』のタスクを処理した人と同じ組織のリーダ」に
「上司」を「申請者」からの相対的な指定で 1/4
Oahu で申請すると、Galapagos が承認者にMidway で申請すると、Solomon が承認者になる
ユーザと組織
• いずれも@questetra.com
• １人目がリーダ
• 全社
– SouthPole
• 営業部
– Hawaii
• 営業1課
– Galapagos
– Oahu
• 営業2課
– Solomon
– Midway
– 管理部
• Sumatera
• Maldives
– 開発部
• Canarias
• SaintHelena
全社
開発部 営業部
営業1課
営業2課
管理部
「上司」を「申請者」からの相対的な指定で 3/4
「同じ組織のリーダ」を指定したが、他に５パターン
営業２課のユーザから見ると
• 同じ組織（営業２課）
• 親組織（営業部）
• より上位組織（営業部と全社）
それぞれ「人（リーダ＋メンバ）」または「リーダ」の２パターン
全部で ３×２＝６パターン
全社
開発部 営業部
営業1課
営業2課
管理部
「上司」を「申請者」からの相対的な指定で 4/4
○• 厳格にルールを適応できる
ו NGパターンがある
– 「同じ組織のリーダ」という指定だと、リーダの人が申請すると、自分自身が「上司として承認」することになる（業務ルール上、認められているなら問題ない）
– 「親組織のリーダ」という指定だと、社長（ルート組織のリーダ）の申請に対して承認者がいなくなる（おそらく社長は有給休暇を申請しない）
• 「部長」や「課長」といった特定のポジションを指定できない– 組織にレベルの概念が無いため
「上司の承認」の設定についてのまとめ
• プロセスデータで指定
• スイムレーンを用いた相対的な指定
• （スイムレーンを用いた相対的な指定とロールの組み合わせ）
• （厳密に、承認者を計算する方法）
現状、「これさえ知っておけば完璧」「設定も簡単」という方法はありません。
最初は、厳密性よりも、設定が容易な方をお勧めします。
厳密で穴が少ない
設定が容易
通知について
標準の通知機能
• いくつかのタイミングで通知
– オファーされた時（「引き受け待ち」のタスクが発生したとき）
– 割り当てられた時（「マイタスク」が発生したとき）
– 締め切り１日前／１時間前／締め切り後○時間おき
• 通知方法が2種類
– メール／タスクフィード（社内ＳＮＳ）
• ユーザ自身が受け取りタイミングを制御
– プロセスモデルの設計者が、ユーザの設定を無視して通知する方法も（後ほど）
タスクの締め切り
みなさんのQuestetra BPM Suite に戻ってください
「その１」で作成したプロセスモデルを再編集します
① ②
③
タスクの締め切り
• タスクごとに「締め切り日時」を設定可能– 一覧表示や、通知で活用される
• 締め切り日時の指定方法– データ項目で指定
– プロセスが開始してから
– タスクが発生してから
• 該当タスクにトークンが到達してから
• 締め切り時の処理– 何もしない（通知するだけ）
– タスクを終了させる
締め切り時にメール通知がされることを確認してくださいユーザ側の通知設定を変更すると、
メールが来なくなることも確認してください
ユーザの設定を上書きしての通知
先ほどのプロセスモデルを再編集します
① ②
③
ユーザの設定を上書きしての通知
• ユーザが「受け取らない」設定にしていても、メール通知することができる
• 通知が必須であるヒューマンタスクで使用
• 設定はユーザ側の通知受信の設定に対応
– オファーされた時
– 割り当てられた時
– 締め切り１日前／１時間前／締め切り後○時間おき
ユーザの設定に関わらず、メール通知される
標準の通知機能
○• 該当タスクの関係者に、通知が行われる
• セキュリティも考慮して、通知が行われる– 見えるべきでないデータが見えることはない
ו 通知の内容を、カスタマイズすることはできない
プロセスの途中で、任意の通知メールを送る 1/4
プロセスモデルを新規作成し、以下のプロセス図にしてください
• 「送信」で使用しているアイテムは、「メッセージ送信中間イベント（メール）」
• Advanced のタブ内にあります
• トークンが到達すると、自動的にメールを送信
プロセスの途中で、任意の通知メールを送る 2/4
• 「メッセージ送信中間イベント（メール）」の設定を以下の通りに
• アンダーバーがついている変数の部分は、「データ埋込」のところから選択して、コピー＆ペースト
• 宛先にある固定アドレスは、適当なものを
プロセスを動かして、変数の部分が置き換わって、メールが届くことを確認してください
プロセスの途中で、任意の通知メールを送る 3/4
• 「メッセージ送信中間イベント（メール）」の設定を以下の通りに
• メールに、「プロセス詳細ページ」への URL を埋め込みます
• ${var[applicationRoot]} は、Questetraインスタンスのルートを表すURLhttps://online-demo-ja.questetra.net/OR/ProcessInstance/listView^^^ この部分 ^^^
プロセスを動かして、プロセス詳細へのURLが埋め込まれていることを確認してください
プロセスの途中で、任意の通知メールを送る 4/4
• 「メッセージ送信中間イベント（メール）」の設定を以下の通りに
• 「文字型複数行」「ファイル型」のプロセスデータを定義し、メールに埋込
• 「入力」タスクでの、データ編集許可設定を忘れずに
プロセスを動かして、プロセスデータの値に応じたメールが送信されることを確認してください
プロセスの途中で、任意の通知メールを送る
○• メールの内容を、細かくカスタマイズすることができる
ו セキュリティの考慮は、プロセスモデルの設計者自身に委ねられる– 誰にでも、どのデータでも送ることができる
• 特定のタスクの処理担当者にメールを送るのは、簡単でない
まとめ
• 処理担当者の設定で、組織を活用する– ユーザをグループ化する、組織とロールの概念
– 処理担当者の設定では、組織を活用するのが基本
• 処理担当者で、上司を設定する– 3種類の方法
– 最初は、最も容易な「データを活用する方法」から始めるのが良い
• 通知について– 標準機能と、プロセスモデルでイベントを使用する方法の２種類ある
