Upload
akihiro-hatanaka
View
114
Download
2
Embed Size (px)
DESCRIPTION
「Questetra BPM Suite」は、Drag&Dropの簡単操作で、業務ルールや業務の流れを設定し、業務プロセスを定義することができるツールです。プログラミングやシステムの知識がなくても、ブラウザだけで、誰でも簡単に業務システムを作成できます。
Citation preview
1Copyright © Questetra,Inc. All right Reserved.
Questetraハンズオンセミナー「業務プロセス設計 ステップアップ編」
Wifiに接続し、今日利用する Questetra BPM Suite にログインできることを確認してください。
SSID/パスワード ホワイトボードに記載
アジェンダ
• ビギナー編のおさらい
• 処理担当者の設定で、組織を活用する
• 処理担当者で、上司を設定する
• 通知について
ビギナー編のおさらい 1/2
プロセスモデル
• 組織が特定の業務を遂行する上において、守るべきルール
• 「業務ルール」「規定」など
プロセス
• プロセスモデルに従って実際に行われる、特定の一連業務
• 特定の「稟議」「申請」「案件」「問い合わせ対応」など
従うべきルール
ルールにそって動く実際の業務
ビギナー編のおさらい 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” のスイムレーンの設定を以下の通りに
処理担当者の設定で、組織を活用する
保存後、「開発中のバージョン○のリリース」をし、プロセスを開始できるかどうか確認してください
処理担当者の設定で、組織を活用する
• 開始イベントのあるスイムレーンでは、担当者設定の意味が異なる
• 「該当業務のプロセスを開始できるのは誰か」という意味に
• それ以外のスイムレーンでは、「そのスイムレーンで発生した仕事を処理できるのは誰か」
• 「営業部」「開発部」に所属しているユーザは、プロセスを開始できる
• 「管理部」に所属しているユーザは、プロセスを開始できない
• 「確認」の仕事は来る
処理担当者の設定で、組織を活用する
• 設定に該当するユーザが1人しかいない場合
• 仕事は、自動的にそのユーザのものとなる
• 設定に該当するユーザが2人以上いる場合
• 仕事は「誰かが引き受けてくれるのを待つ」(引き受け待ち)状態に– 対象ユーザに依頼メール
• 仕事は、引き受けたユーザのものとなる
いずれにせよ、管理部ユーザの仕事になる
処理担当者の設定で、組織を活用する
• 設定に該当するユーザが、1人もいない場合– 今回は「管理部」所属のユーザが1人もいない
• 仕事は、「コントロール権限」ユーザにメールで通知され、「エラー」一覧に入る
– 「コントロール権限」はプロセスモデル単位の権限の1種
• プロセスモデルの詳細ページから「権限の編集」
• 「エラー」一覧からは「処理」できない「強制割当」で他のユーザに– 「エラー」一覧は、「コントロール権限」を持つユーザだけが持つ特別なメニュー
管理部に所属するユーザを 0 にして、試してください
担当者設定で、”担当者1” のスイムレーンの設定を以下の通りに
処理担当者の設定で、組織を活用する
保存後、「開発中のバージョン○のリリース」をし、管理部ユーザもプロセスを開始できることを確認してください
処理担当者の設定で、組織を活用する
• 「組織:全社に直接所属している人」は「全社」組織に所属しているユーザ“のみ”が対象
• 「組織:全社より下位組織に所属している人」は「開発部」「営業部」「管理部」…に所属しているユーザが対象
– 「全社」は除かれる
• この2つを組み合わせると、全ユーザが対象になる
全社
開発部 営業部
営業1課
営業2課
管理部
処理担当者で、上司を設定する
担当者設定の種類
• 組織で指定
– 〇〇に直接所属する人/のリーダ
– 〇〇の下位組織に所属する人/のリーダ
• ユーザで指定
• プロセスデータで指定
– 組織型やユーザ型データで指定されたユーザ/組織
• スイムレーンを用いた相対的な指定
– スイムレーン〇〇のタスクを処理した人より上位組織の人など
• ロールで指定– ロール〇〇に所属する人
課題
次のような、簡単な有給休暇の申請業務を、クエステトラ上に実装してください
申請内容は
• 申請者(代理申請はNG)
• 有給休暇の日付(1日のみでも、複数日指定できても、どちらでもOK)
• 理由
必ず、上司の承認が必要
最後は、帳簿に記録するため、管理部が確認する
つまり「申請」「上司の承認」「管理部の確認」の3ステップ
上司や管理部による差し戻しは、ないものとする
申請日が会社の休業日とか、有給休暇の残日数が足りないとか、細かい点は省略
「上司の承認」の処理担当者の設定がポイント
「上司の承認」の処理担当者設定
以下、3つの方法、それぞれで試してみます
• プロセスデータで指定
– 組織型やユーザ型データで指定されたユーザ/組織
• スイムレーンを用いた相対的な指定
– スイムレーン〇〇のタスクを処理した人より上位組織の人など
• ロールで指定– ロール〇〇に所属する人
1. 「上司」に相当するユーザ型データ項目を追加
2. 担当者設定で追加したデータ項目を指定
3. 「申請」時に、申請者に「上司」を入力してもらう形に
「上司」をプロセスデータで指定 1/2
「上司の承認」は、データで指定したユーザに割りあたることを確認してください
「上司」をプロセスデータで指定 2/2
○• 解りやすい
• あらゆる場合に対応できる
ו 厳格にルールを適応できない
– 間違った「承認者」を指定することも可能
「上司」の処理担当者の設定を
「『申請者』のタスクを処理した人と同じ組織のリーダ」に
「上司」を「申請者」からの相対的な指定で 1/3
「上司の承認」が、申請プロセスを開始したユーザの所属組織のリーダに割りあたることを確認してください
「上司」を「申請者」からの相対的な指定で 2/3
「同じ組織のリーダ」を指定したが、他に5パターン
営業2課のユーザから見ると
• 同じ組織(営業2課)
• 親組織(営業部)
• より上位組織(営業部と全社)
それぞれ「人(リーダ+メンバ)」または「リーダ」の2パターン
全部で 3×2=6パターン
全社
開発部 営業部
営業1課
営業2課
管理部
「上司」を「申請者」からの相対的な指定で 3/3
○• 厳格にルールを適応できる
ו NGパターンがある
– 「同じ組織のリーダ」という指定だと、リーダの人が申請すると、自分自身が「上司として承認」することになる(業務ルール上、認められているなら問題ない)
– 「親組織のリーダ」という指定だと、社長(ルート組織のリーダ)の申請に対して承認者がいなくなる(おそらく社長は有給休暇を申請しない)
• 「部長」や「課長」といった特定のポジションを指定できない– 組織にレベルの概念が無いため
承認者を「部長」や「課長」にするためには 1/3
• 「部長」ロールを作成してください– 「システム設定」→「ロール一覧」→「ロール新規作成」
• 「部長」であるユーザを、「部長」ロールに所属させてください
担当者設定で、”担当者2” のスイムレーンの設定を以下の通りに
承認者を「部長」や「課長」にするためには 2/3
「上司の承認」が、申請プロセスを開始したユーザの「部長」に割りあたることを確認してください
承認者を「部長」や「課長」にするためには 3/3
○• 厳格にルールを適応できる
• NGパターンが少ない– 「部長」より上位にいる人が申請しない
ו プロセスモデルの設定が高度
• 複数のポジションを兼任しているユーザがいると、うまく動作しない場合がある
「上司の承認」の設定についてのまとめ
• プロセスデータで指定
• スイムレーンを用いた相対的な指定
• ロールで指定
• (厳密に、承認者を計算する方法)
現状、「これさえ知っておけば良い」という方法はない
最初は、厳密性よりも、設定が容易な方をお勧めします
厳密で穴が少ない
設定が容易
通知について
標準の通知機能
• いくつかのタイミングで通知
– オファーされた時(「引き受け待ち」のタスクが発生したとき)
– 割り当てられた時(「マイタスク」が発生したとき)
– 締め切り1日前/1時間前/締め切り後○時間おき
• 通知方法が2種類
– メール/タスクフィード(社内SNS)
• ユーザ自信が受け取りタイミングを制御
– プロセスモデルの設計者が、ユーザの設定に関わらず「必ず通知する」ことは今のところはできない
タスクの締め切り
• タスクごとに「締め切り日時」を設定可能– 一覧表示や、通知で活用される
• 締め切り日時の指定方法– データ項目で指定
– プロセスが開始してから
– タスクが発生してから
• 該当タスクにトークンが到達してから
• 締め切り時の処理– 何もしない(通知するだけ)
– タスクを終了させる
締め切り時にメール通知がされることを確認してくださいユーザ側の通知設定の変更も必要
標準の通知機能
○• 該当タスクの関係者に、通知が行われる
• セキュリティも考慮して、通知が行われる– 見えるべきでないデータが見えることはない
ו ユーザが通知を「受け取らない」設定にしていると、通知されない
• 通知の内容を、カスタマイズすることはできない
プロセスの途中で、任意の通知メールを送る 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種類ある