在宅勤務の業務報告は円滑に!

2011年5月11日
在宅勤務のためにファイアーウォールに「穴」を開けて社内サーバにアクセスさせるより、ある程度の業務情報を「クラウド」において社内サーバアクセスを減らすことを考えたい。ナンでもカンでも重要情報と認定してしまうと、本当に大切なものが守れなくなる。
日本の戦国時代のお城には内堀と外堀があるが、「内堀が広大な城」は侵入を防ぐコストがかかりすぎる。

以下のワークフロー定義は、『在宅勤務日の申請承認はクラウドでしょ!』を拡張し、在宅勤務日の予定を一括して申請するフローだ。在宅勤務日なんて外堀で守っておけば良い程度の情報だ。

ちなみに、一括して申請できるのは便利ながら、逐次で申請するワークフロー定義と異なり、一連の流れに乗った業務報告が出来なくなる(様な気がする)。そんな場合は、1対nの関係にある「申請承認フロー」と「業務報告フロー」を分離すれば良い。


<各タスク名>
1.事前申請、2.承認、3.非承認対応


[在宅勤務-一括申請:メッセージ送信中間イベント設定画面]



<各プロセスデータ名>
  • 件名 ≪例:5月16日 佐藤一郎(氏名部分は自動的に入力されます)≫
▼在宅勤務日の情報▼
  • ユーザ型: 承認上司
  • ユーザ型: 在宅勤務希望社員
  • 日付型: 在宅勤務予定日1*
  • 日付型: 在宅勤務予定日2
  • 日付型: 在宅勤務予定日3
  • 日付型: 在宅勤務予定日4
  • 日付型: 在宅勤務予定日5
▼承認コントロール▼
  • 選択型: 承認フラグ(OK / NG)
  • 掲示板型: 社内通信


上記のワークフロー定義では、翌週1週間分の在宅勤務予定を入力できる。(最大5日)
入力された日に対して、以下のワークフロー定義が起動され、在宅勤務終業時の業務報告に連動する仕組みだ。


<各タスク名>
1.業務報告、1b.業務報告、2.確認、3.不明点対応


[在宅勤務-終業時報告:「2.確認」画面]


<各プロセスデータ名>
  • 件名≪例:5月16日 佐藤一郎(通常、全て自動的に入力されます)≫
▼在宅勤務日の情報▼
  • ユーザ型: 在宅勤務希望社員
  • 日付型: 在宅勤務予定日〔タスク1の締切〕
  • ユーザ型: 承認上司
▼確認コントロール▼
  • 選択型: 不明事項確認フラグ(不明事項アリ / 不明事項ナシ)
  • 掲示板型: 社内通信

0 件のコメント :

コメントを投稿