普通に考えれば、
- 上流に「調査をセットする工程」を作り、
- 下流には、4つに分流させた上で4つの「回答工程」を作る、
この業務フローについては、すでに過去3週に渡ってアレコレ考察してきた。
- 2015-05-18: 真の進捗率は、プロジェクト関係者に聞くしかない!
- 2015-05-25: スクリプト工程、ご利用は計画的に! (平均値の自動算出)
- 2015-06-01: 締切時刻が来れば、その処理が「スキップ」される工程
しかしこれらのワークフロー、、、回答内容こそ見えないものの、「他の調査対象は誰か?」は分かってしまう。それぞれの社員が独立して回答すべきケースにおいて…、あるいは調査を行っていること自体を隠蔽(いんぺい)したいケースにおいては、使いづらい。
※ 調査を4回に分けて行えば良い、ともいう話もあるが、色々メンドウ。。。
以下は、アンケート回答工程を別の業務プロセスとして分離することで、「他の回答者」を隠蔽している。
[進捗報告プロセス(親プロセス)]
[進捗報告プロセス(子プロセス)]
[進捗報告プロセス(子プロセス):「2. 主観の進捗を記入」画面]
これらの2つのワークフローは、親子関係にある。そして親プロセスが持つ情報の内、それぞれの子プロセスに必要な情報だけが継承される仕組みだ。
すなわち、アンケートに回答する社員は、自分以外に誰が回答するのか分からない。
親プロセスは最大で4つの子プロセスを起動し、その後それぞれからの返信を待つ。それぞれの子プロセスは「回答締切時刻」になれば自動的に終了する仕組みなので、親プロセスは「回答締切時刻」まで待てば、すべての子供たちから返事をもらえる仕組みだ。
<データ項目一覧画面:(子プロセス)>
[雛形ダウンロード (無料)]
- 業務テンプレート:
- 企画1に対し回答がN集まる「社内アンケート」のデータ構造 (2014-10-06)
- 子プロセスで業務データを加工する(翻訳プロセス) (2013-12-02)
- 自分の申請をメールで「仮開始」しておく方法 (2014-10-27)
- M225 自動イベント: 業務データを組み込んだHTTPリクエストが、自動的に送信されるように設定する (使い方)
- M226 自動イベント: 特定のURIへのHTTPリクエストを待ち受けるように設定する (使い方)
- M210 引受ルール: 下流工程の処理者を、上流工程にて指名できる様に設定する (使い方)
「[英文記事(English Entry)]」
0 件のコメント :
コメントを投稿