ワークフローサンプル: 記事原稿作成

ラベル 記事原稿作成 の投稿を表示しています。すべての投稿を表示

「情報を集約し、効率よく共有／発信する」は組織にとって非常に重要な機能だ。
情報を統括するチームが、仮に「上がってきた情報を全てソノママ出している」ようであれば、そんなチームに存在価値はない。むしろ存在しない方が良い。つまり「収集する・発信する」に加え、「フィルタする・補完する・整理する」と言った各機能が期待されるのだ。

さりとて、トラブル発生で社内から大量の情報が押し寄せた時に、広報窓口が十分な情報発信機能を維持し続ける事は容易ではない。

<各タスク名>
0.共有すべきかも知れない情報の登録、1a.一次確認(緊急)、1b.一次確認(通常)、2a.記事化(緊急/新規)、2a+.記事化(緊急/既存)、2b.記事化(通常/新規)、2b+.記事化(通常/既存)

[社内情報発信-IR関連情報：「1a.一次確認(緊急)」画面]

「他の記者の原稿に対してコメントする事」も記者の仕事にしてはどうか？
以下の例は、原稿作成進捗を全てクラウドで管理するだけでなく、他の記者の記事誤植のチェック、加えてコメント評価を行うワークフローだ。（もっとも新聞業界では「FAXに赤ペン」が主流だが）

世の中「スピード」だ。石橋を叩いてチェックしていたのでは価値が無くなっていく。たとえば「ネットメディア記者の原稿」などは、レビューなどに回さず、書き終えたらスグに発表するべきだ。稀に発生する「誤植」や「リンクミス」は、ある程度は許容せざるを得まい。
ん・・・でも・・・、よく考えるに「スピード発表」が完了したからと言って「レビューする必要がなくなった」と言う訳ではない。組織として「誤植」や「リンクミス」は積極的に修正したいものだ。今回は事後修正フローを考えたい。（ソフトウェア業界のバグと似ている？）

『新聞記者も原稿をワークフローで可視化する時代！』で、全世界(？)の記者が書いた記事原稿の流れを可視化する方法を例示した。ただこのままでは、良くある話ながら「同じネタ」を複数の記者が書いてしまう「悲劇」(？)は繰り返される。

極めて単純な仕組みだが、草稿を書いた時点で「同じ部署の記者同士に自動メール共有する仕組み」が効果的だ。

『記者』の仕事はニュース原稿を書くコト。
『デスク』の仕事は記者達の原稿や取材方法をチェックするコト。
『整理記者』の仕事は最終的に掲載分量や掲載位置などを決めるコト。
『翻訳担当者』の仕事は最終原稿を翻訳するコト。

実に「分業体制」が整っていて、かつ「パソコンワーク」が多い。そんな業務で、ワークフローシステムやBPMシステムは大活躍だ。（※ Business Process Management: 業務プロセス管理）

「『翻訳フローは役割が明確だから定義しやすいね』良く分かりました。でも、ウチでは３カ国語に翻訳してるんです…」（アイ、スイマセン）
まず、多言語への翻訳は、同時（パラレル）に行うべきか、順番（シーケンシャル）に行うべきか、が悩ましい。「英語⇒日本語、英語⇒スペイン語、英語⇒中国語」の３業務であれば、同時に走らせるのだろう。すなわち、およそ用語に「揺らぎ」は出ない。

「翻訳フロー」って、ちょっと地味だがワークフロー化すると効果テキメン。
普通の業務フローと違って『役割』が明確で、設計も改善もしやすい。在宅勤務スタッフや外部委託先スタッフのタスクも把握しやすい。
業務フロー設計において「役割分担がダイジだ」とは、Questetraの著作物『ビジネスプロセスモデリングの鉄則』の第3話にも書いてある！

「Blog や Twitter で情報発信したい。でも、原稿のチェックは、しっかり行いたいな」　そんな会社さんは非常に多い。
最近「ワークフローシステム（※）で承認された原稿」を Blog や Twitter へ自動投稿する仕組みが、ちょっとしたブームだ。

つまり「Blog や Twitter のメールで投稿できる仕組み」と「プロセスのデータを『メール送出』できるワークフローシステム」（※）を連携させるわけだ。（メール送信部分が、システム連携のツボ）

※ 『メッセージ送信中間イベント』（BPMN用語）が実装されているワークフローシステム： Questetra BPM Suite 等

『当番制』と言う言葉。聞くだけで、メンドウ！
でも現実、多くの会社に当番制の業務がある。朝礼スピーチや掃除などの≪準備が要らない当番≫もあれば、勉強会講師やブログ投稿など≪準備が必要な当番≫もある。
とある日、社長の御乱心…。「より広くより深く当社を知ってもらう為に【当番制のBlog】を発行するぞぉ！」