情報を統括するチームが、仮に「上がってきた情報を全てソノママ出している」ようであれば、そんなチームに存在価値はない。むしろ存在しない方が良い。つまり「収集する・発信する」に加え、「フィルタする・補完する・整理する」と言った各機能が期待されるのだ。
さりとて、トラブル発生で社内から大量の情報が押し寄せた時に、広報窓口が十分な情報発信機能を維持し続ける事は容易ではない。
<各タスク名>
0.共有すべきかも知れない情報の登録、1a.一次確認(緊急)、1b.一次確認(通常)、2a.記事化(緊急/新規)、2a+.記事化(緊急/既存)、2b.記事化(通常/新規)、2b+.記事化(通常/既存)
[社内情報発信-IR関連情報:「1a.一次確認(緊急)」画面]
このワークフロー定義では、「組織内の多種多様なニュース情報を仕分けするタスク」から始まる。最終的には、広報担当によって読みやすくなった記事が、会社専用の情報ポータルサイト(※)に掲載/蓄積される。広報担当にとっての注力点は「トピックス名(記事名)だけで、どれだけの情報を伝えるか」だ。これらの情報がその後、広報担当役員や会社代表が記者会見に使われるかもしれない。
※Blog/ECM/CMS/wikiなどに、ワークフローシステムから自動投稿される。既存記事に対する追加情報は、既存投稿のコメント欄に付記される。
なお、各広報担当の活動は全て記録される。つまり一か月も運用すると「記事化処理の所要時間」や「日次の処理限界」などが、分かってくる。そうすれば、緊急時の広報担当臨時増員についても合理的な計画が可能になるだろう。
ちなみに、『情報ポータルサイト』における各記事の閲覧権限には工夫が必要だ。例えばIR関連の情報を全社員が早い段階で閲覧できると適時開示の観点でマズイ。組織規模によっては、広報チーム内の業務フローとして取り扱いを変えた方が良い。
<各タスク名>
0.共有すべきかも知れない情報の登録、1a.一次確認(緊急)、1b.一次確認(通常)、2a.記事化(緊急/新規)、2a+.記事化(緊急/既存)、2b.記事化(通常/新規)、2b+.記事化(通常/既存)、2a-ir.IR記事化(緊急)、2b-ir.IR記事化(通常)、3.IR発表/ポータル掲載
0 件のコメント :
コメントを投稿