日本では台風シーズン到来だ。そして気象警報が発令されると「電話連絡網」が回ってくる。(休校を知らせるための電話伝言ゲーム)

ただ最近では、「メールの普及」「個人情報への配慮」「リアルタイム性の担保」等の理由から、電話連絡網(緊急連絡網)を廃止して、メーリングリストでの情報配信に切り替える学校も多い。

『緊急メール』の配信で注意したいのは「誤解の無い文章の作成」だ。メールでの情報配信は便利なのだが、要らぬ誤解は混乱を助長する。「情報が正確に伝わっているか?」、かならず起案者以外の職員にレビューしてもらってから送信するルールにしたい。

以下のワークフローでは、(1)配信文章の起案、(2)素早いレビュー校正、(3)素早い承認、を考える。(レビューや承認は、スマートフォンが吉!)


<各タスク名>
1.配信文起案、2.配信文校正、3.承認、3b.事後承認

「コンプライアンス体制の基本は『規程書類』だ」
と言う意見を否定するつもりはない。しかし一方で、社員全員に『憲章』や『規程』に興味を持ち続けてもらう事は現実的ではない。

1. コンプライアンス体制を維持する
2. その本質: 全社員が「法令や定款」を守る必要がある
3. その方針: 社内での「相互監視体制」をとるべきだ
4. その方法: 社内の多くに認知された≪目安箱≫を設置しよう。

この思考は正しい。社内に目安箱と言うポストを配置すれば良い。しかし「投稿者の投函時ストレス」「回収者の手間」を考えるに、今どきオンラインで受け付けたい所だ。「紛失すること」も、「もみ消されること」も無いだろう。

※ ≪内部通報システム≫、≪内部告発システム≫と呼ぶ事もできるが、≪目安箱≫と呼ぶのがイイような気がする。


<各タスク名>
1.投稿、2.投稿確認、3.調査&回答文作成、3a. 疑問対応、4.回答掲示

パッケージソフトウェアの制作やウェブサイトの制作は「完成したら終わり」と言うものではない。むしろ『変更要望』と言う更新業務に追われる日々が「始まる」と言った方が良い。時には「不具合」も報告されるだろう。

以下の業務フロー図は、「不具合報告」や「要望」のステータス管理を効率よく行う事を主眼に置いた設計だ。(※ 社員が全員、ワークフローのアカウントを持つケース)

<各タスク名>
1.不具合要望登録、2.回答者指名/優先度設定、3.一次回答、3a. 疑問対応、4.最終回答、5.一次回答確認、6.最終回答確認

[不具合&要望の受付から回答 「2.回答者指名/優先度設定」]


「ID・パスワード」の発行業務は『地味』ではあるが『極めて重要』だ。その運用を誤ると「情報漏洩」や「情報システムの乗っ取り」など、事業継続に大きな支障をきたす可能性すらある。少なくとも、発行ログはきっちりと記録しておきたいものだ。

以下のワークフローでは、

  • A. 人事部門による「入社研修プロセス」から『自動起動』されるケース(新規ID発行)と、
  • B1. 一時雇用者等のためのIDが『申請』されるケース(新規ID発行)、
  • B2. そして社員の『パスワード忘れ』『改名時のID変更』のケース(既存ID更新)、

に対応している。Aはプロセス間連携、BはWebフォーム連携を想定している(プロセスモデル接続API)

当然の話ながら、「アカウント発行」や「アカウント再発行」を行う以上、「アカウント削除」についてもその業務フローを整備したい。「紙面の都合」と言う名の「大人の都合」でまたの機会としたい。

<各タスク名>
0.承認者指名、1.承認、2.認証コード発行、3.認証コードを聞いて入力、4.仮パスワード変更確認、5.確認


[セキュアな パスワード発行: 「2.認証コード発行」画面]