48
1 Copyright © Questetra,Inc. All right Reserved. Questetra ハンズオンセミナー ビギナー向け業務プロセス設計 その2 Wifi に接続し、今日利用する Questetra BPM Suite ログインできることを確認してください。 SSID/パスワード ホワイトボードに記載

Questetra ハンズオンセミナー ビギナー向け業務プロセス設計 その2 2014/12/10

Embed Size (px)

Citation preview

1Copyright © Questetra,Inc. All right Reserved.

Questetra ハンズオンセミナービギナー向け業務プロセス設計その2

Wifiに接続し、今日利用する Questetra BPM Suite にログインできることを確認してください。

SSID/パスワード ホワイトボードに記載

アジェンダ

• その1のおさらい

• 処理担当者の設定で、組織を活用する

• 処理担当者で、上司を設定する

• 通知について

その1のおさらい 1/2

プロセスモデル

• 組織が特定の業務を遂行する上において、守るべきルール

• 「業務ルール」「規定」など

プロセス

• プロセスモデルに従って実際に行われる、特定の一連業務

• 特定の「稟議」「申請」「案件」「問い合わせ対応」など

従うべきルール

ルールにそって動く実際の業務

その1のおさらい 2/2

プロセスモデルの3要素

• プロセス図(業務フロー図)– 工程、および工程の前後関係

• データ項目(タスク処理画面)– 取り扱うデータ– タスク処理画面(入力画面)

• 処理担当者– 誰が各タスクを処理するか

処理担当者の設定で、組織を活用する

ユーザと組織・ロール

• Questetraには「ユーザ」「組織」「ロール」の概念– 組織とロールは、複数のユーザをグループ化するためのもの– 組織とロールは、プロセスモデルの担当者設定で使用する

• 組織はツリー構造で、ルートは1つ– 企業の組織構造を、そのまま反映させる前提

• ロールはツリー構造を持たない– 企業の組織とは異なった、グループを作るためのもの– 例えば組織横断的なグループなど、組織を補助する目的

• 全ユーザは、いずれかの組織に所属しなければならない– 所属しなければ、ワークフローの各機能が使用できない

• 組織への所属に際して、「リーダ」「メンバ」の属性がある– 「リーダ」「メンバ」の属性も、プロセスモデルの「担当者設定」で使用

全社

開発部 営業部

営業1課

営業2課

管理部

ユーザと組織

• https://seminar-ja.questetra.net

• いずれも@questetra.com

• 1人目がリーダ

• 全社

– SouthPole

• 営業部

– Hawaii

• 営業1課

– Galapagos

– Oahu

• 営業2課

– Solomon

– Midway

– 管理部

• Sumatera

• Maldives

– 開発部

• Canarias

• SaintHelena

全社

開発部 営業部

営業1課

営業2課

管理部

処理担当者の設定で、組織を活用する

プロセスモデルを新規作成し、以下のプロセス図にしてください

• タスクやスイムレーンの名称変更を忘れずに

担当者設定で、”担当者2” のスイムレーンの設定を以下の通りに

処理担当者の設定で、組織を活用する

担当者設定で、”担当者1” のスイムレーンの設定を以下の通りに

処理担当者の設定で、組織を活用する

保存後、「開発中のバージョン○のリリース」をし、プロセスを開始できるかどうか確認してください

ユーザと組織

• いずれも@questetra.com

• 1人目がリーダ

• 全社

– SouthPole

• 営業部

– Hawaii

• 営業1課

– Galapagos

– Oahu

• 営業2課

– Solomon

– Midway

– 管理部

• Sumatera

• Maldives

– 開発部

• Canarias

• SaintHelena

全社

開発部 営業部

営業1課

営業2課

管理部

処理担当者の設定で、組織を活用する

• 開始イベントのあるスイムレーンでは、担当者設定の意味が異なる

• 「該当業務のプロセスを開始できるのは誰か」という意味に

• それ以外のスイムレーンでは、「そのスイムレーンで発生した仕事を処理できるのは誰か」

• 「営業部」「開発部」に所属しているユーザは、プロセスを開始できる

• 「管理部」に所属しているユーザは、プロセスを開始できない

• 「確認」の仕事は来る

処理担当者の設定で、組織を活用する

• 設定に該当するユーザが1人しかいない場合

• 仕事は、自動的にそのユーザのものとなる

• 設定に該当するユーザが2人以上いる場合

• 仕事は「誰かが引き受けてくれるのを待つ」(引き受け待ち)状態に– 対象ユーザに依頼メール

• 仕事は、引き受けたユーザのものとなる

いずれにせよ、管理部ユーザの仕事になる

少し脱線 「開始したプロセス」を見る

• 「開始したプロセス」か「処理したタスク」

• タスクとプロセスの違いは工程のレベルで見るか、全体で見るかの違い

• プロセス(インスタンス)には、「工程名」や「締め切り」の属性はない

• 「マイタスク」「引き受け待ち」は、「工程のレベル」で見ている。「全体のレベル」で見ていない。

設定に該当するユーザが1人もいない場合

• 設定に該当するユーザが、1人もいない場合にどうなるか

• 「確認」の仕事は、「コントロール権限」ユーザにメールで通知され、「エラー」一覧に入る

– 「コントロール権限」は権限の1種

– 該当プロセスモデルの全プロセスを制御できる権限を持つ

• 「エラー」一覧からは「処理」できない「強制割当」で他のユーザに– 「エラー」一覧は、「コントロール権限」を持つユーザだけが持つ特別なメニュー

管理部に所属するユーザを 0 にします

処理担当者の設定で、組織を活用する

先ほど作成したプロセスモデルの編集画面に移動

① ②

担当者設定で、”担当者1” のスイムレーンの設定を以下の通りに

処理担当者の設定で、組織を活用する

保存後、「開発中のバージョン○のリリース」をし、管理部ユーザもプロセスを開始できることを確認してください

ユーザと組織

• いずれも@questetra.com

• 1人目がリーダ

• 全社

– SouthPole

• 営業部

– Hawaii

• 営業1課

– Galapagos

– Oahu

• 営業2課

– Solomon

– Midway

– 管理部

• Sumatera

• Maldives

– 開発部

• Canarias

• SaintHelena

全社

開発部 営業部

営業1課

営業2課

管理部

処理担当者の設定で、組織を活用する

• 「組織:全社に直接所属している人」は「全社」組織に所属しているユーザ“のみ”が対象

• 「組織:全社より下位組織に所属している人」は「開発部」「営業部」「管理部」…に所属しているユーザが対象

– 「全社」は除かれる

• この2つを組み合わせると、全ユーザが対象になる

全社

開発部 営業部

営業1課

営業2課

管理部

処理担当者で、上司を設定する

担当者設定の種類

• 組織で指定

– 〇〇に直接所属する人/のリーダ

– 〇〇の下位組織に所属する人/のリーダ

• ユーザで指定

• プロセスデータで指定

– 組織型やユーザ型データで指定されたユーザ/組織

• スイムレーンを用いた相対的な指定

– スイムレーン〇〇のタスクを処理した人より上位組織の人など

• ロールで指定– ロール〇〇に所属する人

課題

次のような、簡単な有給休暇の申請業務を、クエステトラ上に実装してください

申請内容は

• 申請者(代理申請はNG)

• 有給休暇の日付(1日のみでも、複数日指定できても、どちらでもOK)

• 理由

必ず、上司の承認が必要

最後は、帳簿に記録するため、管理部が確認する

つまり「申請」「上司の承認」「管理部の確認」の3ステップ

上司や管理部による差し戻しは、ないものとする

申請日が会社の休業日とか、有給休暇の残日数が足りないとか、細かい点は省略

「上司の承認」の処理担当者の設定がポイント

「上司の承認」の処理担当者設定

以下、3つの方法、それぞれで試してみます

• プロセスデータで指定

– 組織型やユーザ型データで指定されたユーザ/組織

• スイムレーンを用いた相対的な指定

– スイムレーン〇〇のタスクを処理した人より上位組織の人など

• ロールで指定– ロール〇〇に所属する人

1. 「上司」に相当するユーザ型データ項目を追加

2. 担当者設定で追加したデータ項目を指定

3. 「申請」時に、申請者に「上司」を入力してもらう形に

「上司」をプロセスデータで指定 1/2

「上司の承認」は、データで指定したユーザに割りあたることを確認してください

「上司」をプロセスデータで指定 2/2

○• 解りやすい

• あらゆる場合に対応できる

ו 厳格にルールを適応できない

– 間違った「承認者」を指定することも可能

「上司」を「申請者」からの相対的な指定で 1/4

先ほど作成したプロセスモデルの編集画面に移動

① ②

「上司」の処理担当者の設定を

「スイムレーン:『申請者』のタスクを処理した人と同じ組織のリーダ」に

「上司」を「申請者」からの相対的な指定で 1/4

「上司の承認」が、申請プロセスを開始したユーザの所属組織のリーダに割りあたることを確認してください

ユーザと組織

• いずれも@questetra.com

• 1人目がリーダ

• 全社

– SouthPole

• 営業部

– Hawaii

• 営業1課

– Galapagos

– Oahu

• 営業2課

– Solomon

– Midway

– 管理部

• Sumatera

• Maldives

– 開発部

• Canarias

• SaintHelena

全社

開発部 営業部

営業1課

営業2課

管理部

「上司」を「申請者」からの相対的な指定で 3/4

「同じ組織のリーダ」を指定したが、他に5パターン

営業2課のユーザから見ると

• 同じ組織(営業2課)

• 親組織(営業部)

• より上位組織(営業部と全社)

それぞれ「人(リーダ+メンバ)」または「リーダ」の2パターン

全部で 3×2=6パターン

全社

開発部 営業部

営業1課

営業2課

管理部

「上司」を「申請者」からの相対的な指定で 4/4

○• 厳格にルールを適応できる

ו NGパターンがある

– 「同じ組織のリーダ」という指定だと、リーダの人が申請すると、自分自身が「上司として承認」することになる(業務ルール上、認められているなら問題ない)

– 「親組織のリーダ」という指定だと、社長(ルート組織のリーダ)の申請に対して承認者がいなくなる(おそらく社長は有給休暇を申請しない)

• 「部長」や「課長」といった特定のポジションを指定できない– 組織にレベルの概念が無いため

承認者を「部長」や「課長」にするためには 1/3

• 「部長」ロールを作成してください– 「システム設定」→「ロール一覧」→「ロール新規作成」

• 「部長」であるユーザを、「部長」ロールに所属させてください

担当者設定で、”担当者2” のスイムレーンの設定を以下の通りに

承認者を「部長」や「課長」にするためには 2/3

「上司の承認」が、申請プロセスを開始したユーザの「部長」に割りあたることを確認してください

ユーザと組織

• いずれも@questetra.com

• 1人目がリーダ

• 全社

– SouthPole

• 営業部

– Hawaii

• 営業1課

– Galapagos

– Oahu

• 営業2課

– Solomon

– Midway

– 管理部

• Sumatera

• Maldives

– 開発部

• Canarias

• SaintHelena

全社

開発部 営業部

営業1課

営業2課

管理部

承認者を「部長」や「課長」にするためには 3/3

○• 厳格にルールを適応できる

• NGパターンが少ない– 「部長」より上位にいる人が申請しない

ו プロセスモデルの設定が高度

• 複数のポジションを兼任しているユーザがいると、うまく動作しない場合がある

「上司の承認」の設定についてのまとめ

• プロセスデータで指定

• スイムレーンを用いた相対的な指定

• ロールで指定

• (厳密に、承認者を計算する方法)

現状、「これさえ知っておけば完璧」という方法はありません。

最初は、厳密性よりも、設定が容易な方をお勧めします。

厳密で穴が少ない

設定が容易

通知について

標準の通知機能

• いくつかのタイミングで通知

– オファーされた時(「引き受け待ち」のタスクが発生したとき)

– 割り当てられた時(「マイタスク」が発生したとき)

– 締め切り1日前/1時間前/締め切り後○時間おき

• 通知方法が2種類

– メール/タスクフィード(社内SNS)

• ユーザ自身が受け取りタイミングを制御

– プロセスモデルの設計者が、ユーザの設定を無視して通知する方法も(後ほど)

タスクの締め切り

みなさんのQuestetra BPM Suite に戻ってください

「その1」で作成したプロセスモデルを再編集します

① ②

タスクの締め切り

• タスクごとに「締め切り日時」を設定可能– 一覧表示や、通知で活用される

• 締め切り日時の指定方法– データ項目で指定

– プロセスが開始してから

– タスクが発生してから

• 該当タスクにトークンが到達してから

• 締め切り時の処理– 何もしない(通知するだけ)

– タスクを終了させる

締め切り時にメール通知がされることを確認してくださいユーザ側の通知設定を変更すると、メールが来なくなることも確認してください

ユーザの設定を上書きしての通知

先ほどのプロセスモデルを再編集します

① ②

ユーザの設定を上書きしての通知

• ユーザが「受け取らない」設定にしていても、メール通知することができる

• 通知が必須であるヒューマンタスクで使用

• 設定はユーザ側の通知受信の設定に対応

– オファーされた時

– 割り当てられた時

– 締め切り1日前/1時間前/締め切り後○時間おき

ユーザの設定に関わらず、メール通知される

標準の通知機能

○• 該当タスクの関係者に、通知が行われる

• セキュリティも考慮して、通知が行われる– 見えるべきでないデータが見えることはない

ו 通知の内容を、カスタマイズすることはできない

プロセスの途中で、任意の通知メールを送る 1/4

プロセスモデルを新規作成し、以下のプロセス図にしてください

• 「送信」で使用しているアイテムは、「メッセージ送信中間イベント(メール)」

• Advanced のタブ内にあります

• トークンが到達すると、自動的にメールを送信

プロセスの途中で、任意の通知メールを送る 2/4

• 「メッセージ送信中間イベント(メール)」の設定を以下の通りに

• アンダーバーがついている変数の部分は、「データ埋込」のところから選択して、コピー&ペースト

• 宛先にある固定アドレスは、適当なものを

プロセスを動かして、変数の部分が置き換わって、メールが届くことを確認してください

プロセスの途中で、任意の通知メールを送る 3/4

• 「メッセージ送信中間イベント(メール)」の設定を以下の通りに

• メールに、「プロセス詳細ページ」への URL を埋め込みます

• ${var[applicationRoot]} は、Questetraインスタンスのルートを表すURLhttps://online-demo-ja.questetra.net/OR/ProcessInstance/listView^^^ この部分 ^^^

プロセスを動かして、プロセス詳細へのURLが埋め込まれていることを確認してください

プロセスの途中で、任意の通知メールを送る 4/4

• 「メッセージ送信中間イベント(メール)」の設定を以下の通りに

• 「文字型複数行」「ファイル型」のプロセスデータを定義し、メールに埋込

• 「入力」タスクでの、データ編集許可設定を忘れずに

プロセスを動かして、プロセスデータの値に応じたメールが送信されることを確認してください

プロセスの途中で、任意の通知メールを送る

○• メールの内容を、細かくカスタマイズすることができる

ו セキュリティの考慮は、プロセスモデルの設計者自身に委ねられる– 誰にでも、どのデータでも送ることができる

• 特定のタスクの処理担当者にメールを送るのは、簡単でない

まとめ

• 処理担当者の設定で、組織を活用する– ユーザをグループ化する、組織とロールの概念

– 処理担当者の設定では、組織を活用するのが基本

• 処理担当者で、上司を設定する– 3種類の方法

– 最初は、最も容易な「データを活用する方法」から始めるのが良い

• 通知について– 標準機能と、プロセスモデルでイベントを使用する方法の2種類ある